Joohwan

containerd-CRIOverviewCRI定义了容器和镜像服务的接口，使用Protocol Buffer协议 定义了kubelet与不同容器运行时交互规范 接口包含客户端与服务端 123kubectl xx--containerd-runtime-endpoint=<CRI Server的Uninx Socket>--image-service-endpont=< CRI Serverdr的Uninx Socket> 如果Runtime Service和Image Service在一个gPRC Server中要配置container-runtime-endpoint，当image-service-endpoint为空，默认使用container-runtime-endpoint一致的地址 如果是K8s 1.24以前使用CRI Server需要设置container-runtime=remote（自从kubelet移除了dockershim，这个参数废弃，默认container-runtime=docker Runti...

K8s-kubelet(HTTP服务接口) 基于1.25 kubelet通过HTTP Server对外暴露API，为了确保接口安全，kubelet按照安全等级从低到高顺序支持3种HTTP Server，分别是healthz server、readonly server和kubelet core server 一级类目 二级类目 Path路径 描述 Default Handlerers healthz /healthz 检查kubelet是否健康，重点检查syncLoop是否持续在规定时间内完成。检查syncLoop四因为其他组件故障会间接导致syncLoop不能执行成功 Default Handlerers pods /pods 读取当前节点运行的Pod列表（通过PodManager获取） Default Handlerers stats /stats/summary 读取资源使用状态 Default Handlerers metrics /metrics 读取kubelet监控指标数据 Defaul...

K8s-kubelet(PLEG核心原理) 基于1.25 PLEG是kubelet的一个重要组件，负责监控kubelet管理的节点运行的Pod的生命周期，并生成于生命周期相关的事件 PLEG产生原因在K8s中，kubelet负责维护和管理每个节点上的Pod，不断的调谐Pod的状态以使得符合Spec。 为了实现这个目标，kubelet同时需要支持对Pod Spec和Container Status 的事件监听。对于前者kubelet通过watch不同源的对PodSpec事件实现，对于后者，PLEG之前，不断需要Pod处理协程不断的周期性拉取最新状态，尝试了大量轮询压力。 在kubeletv1.2.0版本引入了PLEG，目标是改善kubelet的可拓展性 减少不必要的处理操作（当状态为发生变化时，不执行无效的调谐操作） 减少对底层容器运行的并发请求，以减轻容器运行时的压力 PLEG架构设计PLEG主要包含俩个核心工作，一是感受容器变化，生成Pod事件，俩是维持一份最新的Pod Status Cache数据供其他组件读取。 kubelet同时接收俩个方向的事件，Pod S...

K8s-kubelet(Cgroup资源隔离以及垃圾回收原理) 基于1.25 什么是Cgroup资源隔离kubelet基于cgroup限制Pod资源使用。cgroup是Linux内核的一个重要功能，用来限制、控制和分离一个进程组的资源（CPU、内存、磁盘I/O） kubelet在创建Pod时，会将其配置的cgroups parent目录传递给容器运行时，使容器运行时创建的进程都会限制到kubelet配置父级cgroup之下。 kubelet负责维护Pod、QoS、Node级别的cgroup配置 Container级别的cgroup直接交给容器运行时实现 cgroup的层级结构 kubelet采用了四级cgroups层级架构存储 Node Level cgroup 为了保证系统运行的稳定性，kubelet支持为系统守护进程预留资源，避免Pod占用整个系统资源，造成系统卡死或者崩溃。 默认情况下，kube-reserved和system-reserved不会启用。 但是启用之后，需要注意守护进程添加了cgroup之后，可能导致配置的上限太小，导致守护进程资源不足退...

K8s-kubelet(Pod生命周期管理) 基于1.25 kubelet以Pod为基本处理单元，负责Pod从创建到消亡的整个生命周期 在1.21中Unknown状态已经被标记为弃用。 CRIkubelet通过CRI RPC管理容器的生命周期，执行容器的lifecycle hook和 startup/liveness/readiness的健康检查，同时根据Pod的重启策略在容器失败退出后自动重启容器，CRI是kubelet管理Pod和容器的基础 Ref:https://github.com/kubernetes/cri-api/blob/2c8d015e0d408208ca8843c1d6e2e2fce1e5dd94/pkg/apis/runtime/v1/api.proto#L34 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717...

K8s-kubelet(Overview) 基于1.25 kubelete的启动流程主要分为5个步骤： Cobra命令参数解析 运行环境检测和设置 Kubelet对象实例化 启动kubelet主服务 启动HTTP Server服务和gRPC Server Cobra命令行参数解析 Ref:https://github.com/kubernetes/kubernetes/blob/88e994f6bf8fc88114c5b733e09afea339bea66d/cmd/kubelet/app/server.go#L123 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211...

K8s-kubelet(Overview) 基于1.25 kubelet是K8s中最重要的节点代理程序，运行在集群的每个节点上。 能够自动将节点注册到集群 将节点上、Pod运行状态和资源使用情况周期性上报到控制平面 同时接受控制平面发送到工作任务、启动停止容器、维护管理Pod 也包含对cAdvusor资源用量监控、容器和镜像垃圾回收 kubelet架构设计kubelet整体架构采用了基于事件的处理模型，通过syncLoop和不断调谐Podtatus和PodSpec差距 PodSpec主要来源自三个来源，kube-apiserver、file和HTTP。 file和HTTP主要用于发现Static类型的Pod kubelet默认每隔20s执行一次检测 PodStatus实际状态主要是通过PLEG周期性扫描冗余运行时的运行状态获取。 PLEG每隔1s，从容器运行时获取Pod和Container信息，并于本地缓存进行对比，发生变更的时候，生成PLEG事件，并且发送给事件订阅者触发执行事件处理程序。 默认，当产生PLEG事件，kubelet会执行sync调谐 kubelet...

K8s-kube-proxy(ipvs代理模式) 基于1.25 在ipvs代理模式，kube-proxy主要通过宿主节点上配置的iptables规则、ipvs规则、IPSet内容、Dummy网卡等信息实现Service的功能，这些配置syncProxyRules func 与ipatbles代理模式，ipvs模式对于新增一个Service，只会在IPSet、ipvs规定上有新增内容，而不产生新的iptables链和规则 ipvs代理模式使用IPSet和ipvs实现IP地址匹配和DNAT操作，因此比iptables线性执行效率更高，更适合较大规模集群的场景 统计Stale Service和Stale Endpoints在ipvs代理模式中，Stale Service和Stale Endpoints的判定逻辑与iptables代理模式相同 初始化iptables内容缓冲区kube-proxy也涉及到一些iptables链和规则的创建，因此使用iptables-restore字节流的形成缓存和刷新iptables规则 在kube-proxy同步开始阶段，会初始化四个内容缓冲区。...

K8s-kube-proxy(iptables代理模式执行流程) 基于1.25 kube-proxy 通过宿主节点上的配置iptables实现Service功能，都有syncProxyRule实现 统计State Service和Stale Endpointsiptables代理模式第一步是针对UDP协议，统计Stale Service和Stable Endpoints Endpoints是所有Service的后端地址 为什么需要针对UDP协议进行统计Stale Service和Stale Endpoints的原因？ 客户端访问Service负载均衡需要依赖NAT协议，而NAT机制又依赖conntrack模块 UDP协议不会TCP协议一样，存在断开链接，客户端和服务端之间的Conntrack记录不会马上被清除，客户端的发出的UDP数据以来按照原有的NAT发送给不存在的服务端，导致丢包，所以UDP Endpoints被销毁的时候，需要手动清除Conntrack记录 如果一个Service不存在任何后端Pod，则NAT机制由于没有服务端的存在，会丢弃UDP数据包。如果此时S...

K8s-kube-proxy(初始化过程) 基于1.25 kube-proxy也使用Cobra解析用户输入参数，初始化Options对象、验证参数有效性，调用Run启动 Ref:https://github.com/kubernetes/kubernetes/blob/88e994f6bf8fc88114c5b733e09afea339bea66d/cmd/kube-proxy/app/server.go#L483 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162// NewProxyCommand creates a *cobra.Command object with default parametersfunc NewProxyCommand() *cobra.Command { opts := NewOptions() cmd := &cobra.Command{...