Kubernetes
2024-06-07 20:12:21 0 举报
AI智能生成
登录查看完整内容
Kubernetes知识体系
作者其他创作
大纲/内容
Informer机制
Subtopic 1
preStop
1. 用户调用 kubectl delete 删除 pod
pod 下线流程
优雅退出
VPA 是解决资源配额 (Pod 的 CPU、内存的 limit/request) 评估不准的问题
VPA
HPA 则要解决的是业务负载压力波动很大,需要人工根据监控报警来不断调整副本数的问题,有了 HPA 后,被关联上 HPA 的 deployment,后续副本数修改就不用人工管理,HPA controller 将会根据业务忙闲情况自动帮你动态调整
CronHPA,即直接按照 cron 的格式设定扩容和缩容时间及对应副本数,这种不需要动态识别业务繁忙度属于静态 HPA,适用于业务流量变化有固定时间周期规律的情况,这种比较简单可以算做 HPA 的一种简单特例
支持 k8s 里 Pod 的所有系统资源 (包括 cpu、memory 等),但是一般只会用 cpu,memory 因为不太敏感而且跟语言相关:大多数语言都有内存池及内置 GC 机制导致进程内存监控不准确
Resource
表示 cpu,memory 等系统资源之外且是由 Pod 自身提供的自定义 metrics 数据,比如用户可以在 web 服务的 pod 里提供一个 promesheus metrics 的自定义接口,里面暴露了本 pod 的实时 QPS 监控指标,这种情况下就应该在 HPA 里直接使用 Pods 类型的 metrics
Pods
表示监控指标不是由 Pod 本身的服务提供,但是可以通过 k8s 的其他资源 Object 提供 metrics 查询,比如 ingress 等,一般 Object 是需要汇聚关联的 Deployment 下的所有的 pods 总的指标
Object
与 Pods 和 Object 不同的是,其监控指标的来源跟 k8s 本身无关,metrics 的数据完全取自外部的系统
External
指标 metrics 的分类
HPA
AutoScale
docker非常适合部署单进程服务,而对于多进程服务而已却无能为力。
当子进程运行完成后,它的进程表条目仍然保留,直到父进程使用wait系统调用获得其退出代码后才会清理进程条目,即收割僵尸进程,僵尸进程无法通过kill命令清除
pause容器被用作Pod中所有容器的父容器,并为每个子容器共享namespace,为子容器提供1号进程,并收集Pod内的僵尸进程
核心:pause 容器
Pod
UDP
Linux内置的标准协议,虽然封包结构较为复杂,但是其所有数据解包封包均在内核完成
VXLAN
没有引入额外的封包解包操作,通讯效率与裸机相差无几。但由于flannel只能修改各个主机上的路由表,一旦主机之间隔了其他路由设备,如三层路由器,这个包就会在路由设备上被丢弃
Host-Gateway
实现方式
flannel
calico
weave
cilium
CNI
headless作用是将负载均衡交由客户端来实现,在Service中的ClusterIP设置为None即可,这样kube-proxy就不会创建相关iptables规则,就会使得在客户端通过DNS解析该service时,就会返回其所对应的的所有endpoint地址,而非一个未指定ClusterIP的service地址。客户端获得了所有的endpoint地址后就可以实现自己的负载均衡机制
headless-service
网络机制
存在内核态与用户态的切换,性能不佳
userspace
与userspace的最大区别在于,kube-proxy利用iptables的DNAT模块实现了Service入口地址到Pod实际地址的转换,免去了一次内核态到用户态的切换
纯粹为防火墙设计,底层路由表的实现基于链表,对路由规则的查询都涉及遍历一次链表
iptables
LVS的负载均衡模块,与iptables同样基于netfilter实现,但是性能更高,具备更好扩展性,底层基于哈希表实现
Direct Routing
使用 ip 包封装 ip包
Tunneling (即 ipip模式)
kube-proxy为了支持端口映射,使用该模式
NAT (Masq 模式)
三种负载均衡算法
不支持端口映射,无法支撑k8s Service的所有场景
2. kube-proxy启动参数指定集群IP地址范围
3. 支持LoadBalancer类型的服务,用于配置白名单
4. 支持NodePort类型的服务,用于在包跨节点前配置 MASQUERADE
IPVS仅用于流量转发,它无法处理kube-proxy的其他问题,如包过滤,SNAT等。故IPVS会在这四种情况需要依赖于 iptables
1. 为什么IPVS的实现还需要借助iptables
QA
IPVS
Load Balancer
实现的是分布式负载均衡,而非集中式负载均衡
kube-proxy
Kubernetes
0 条评论
回复 删除
下一页