首页  思维导图  详情

Kubernetes

2024-06-07 20:12:21   0  举报





AI智能生成

Kubernetes知识体系

K8S

Kubernetes

作者其他创作

大纲/内容

Informer机制

优雅退出

preStop

Subtopic 1

pod 下线流程

1. 用户调用 kubectl delete 删除 pod

2. apiserver 收到命令请求后, 通过 API 操作 etcd将相关 pod 标记为 terminating 状态, 同时会有一个等待宽限期 30 s

3. endpoint 控制器监控到pod 对象变化, 会将 pod 与 service匹配的 endpoint 从列表中删除

4. kube-proxy 监听到 endpoint 列表变化后, 会重新生成一份完整的 iptables 规则来覆盖原有的规则

5. 工作节点的 kebelet 监听到 pod 状态变化后, 检查pod 是否有配置 preStop , 有配置则同步执行 preStop清理相关资源 . 若宽限期结束后，preStop 仍未执行结束，则发送SIGKILL 信号来强制杀死应用进程

AutoScale

VPA

VPA 是解决资源配额 (Pod 的 CPU、内存的 limit/request) 评估不准的问题

HPA

HPA 则要解决的是业务负载压力波动很大，需要人工根据监控报警来不断调整副本数的问题，有了 HPA 后，被关联上 HPA 的 deployment，后续副本数修改就不用人工管理，HPA controller 将会根据业务忙闲情况自动帮你动态调整

CronHPA，即直接按照 cron 的格式设定扩容和缩容时间及对应副本数，这种不需要动态识别业务繁忙度属于静态 HPA，适用于业务流量变化有固定时间周期规律的情况，这种比较简单可以算做 HPA 的一种简单特例

指标 metrics 的分类

Resource

支持 k8s 里 Pod 的所有系统资源 (包括 cpu、memory 等)，但是一般只会用 cpu，memory 因为不太敏感而且跟语言相关：大多数语言都有内存池及内置 GC 机制导致进程内存监控不准确

Pods

表示 cpu，memory 等系统资源之外且是由 Pod 自身提供的自定义 metrics 数据，比如用户可以在 web 服务的 pod 里提供一个 promesheus metrics 的自定义接口，里面暴露了本 pod 的实时 QPS 监控指标，这种情况下就应该在 HPA 里直接使用 Pods 类型的 metrics

Object

表示监控指标不是由 Pod 本身的服务提供，但是可以通过 k8s 的其他资源 Object 提供 metrics 查询，比如 ingress 等，一般 Object 是需要汇聚关联的 Deployment 下的所有的 pods 总的指标

External

与 Pods 和 Object 不同的是，其监控指标的来源跟 k8s 本身无关，metrics 的数据完全取自外部的系统

Pod

核心：pause 容器

docker非常适合部署单进程服务，而对于多进程服务而已却无能为力。

pause容器被用作Pod中所有容器的父容器，并为每个子容器共享namespace，为子容器提供1号进程，并收集Pod内的僵尸进程

当子进程运行完成后，它的进程表条目仍然保留，直到父进程使用wait系统调用获得其退出代码后才会清理进程条目，即收割僵尸进程，僵尸进程无法通过kill命令清除

网络机制

CNI

flannel

实现方式

UDP

数据在linux用户态进行封包与解包,导致性能不佳

VXLAN

Linux内置的标准协议，虽然封包结构较为复杂，但是其所有数据解包封包均在内核完成

Host-Gateway

没有引入额外的封包解包操作，通讯效率与裸机相差无几。但由于flannel只能修改各个主机上的路由表，一旦主机之间隔了其他路由设备，如三层路由器，这个包就会在路由设备上被丢弃

calico

weave

cilium

headless-service

headless作用是将负载均衡交由客户端来实现，在Service中的ClusterIP设置为None即可，这样kube-proxy就不会创建相关iptables规则，就会使得在客户端通过DNS解析该service时，就会返回其所对应的的所有endpoint地址，而非一个未指定ClusterIP的service地址。客户端获得了所有的endpoint地址后就可以实现自己的负载均衡机制

kube-proxy

Load Balancer

userspace

存在内核态与用户态的切换，性能不佳

iptables

与userspace的最大区别在于，kube-proxy利用iptables的DNAT模块实现了Service入口地址到Pod实际地址的转换，免去了一次内核态到用户态的切换

纯粹为防火墙设计，底层路由表的实现基于链表，对路由规则的查询都涉及遍历一次链表

IPVS

LVS的负载均衡模块，与iptables同样基于netfilter实现，但是性能更高，具备更好扩展性，底层基于哈希表实现

三种负载均衡算法

Direct Routing

Tunneling (即 ipip模式)