Kubernetes Develop

本文是关于Kubernetes service解析的第5章 深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？ 深入理解Kubernetes service - kube-proxy架构分析 深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性 所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy 前景 这里谈 kube-proxy 如何保证规则的一致性以及提升 kube-proxy 性能点的地方，这也是 kubernetes 使用稳定性的一部分。 kube-proxy 如何做到的CRUD kube-proxy 实际上与其他内置 controller 架构是相同的，实际上也属于一个 controller ，但它属于一个 service, endpoints 的可读可写的控制器，node的读控制器。对于CRUD方面，kube-proxy，在设计上分为 增/改 两方面。正如下面代码所示 pkg/proxy/ipvs/proxier.go go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 func (proxier *Proxier) OnServiceAdd(service *v1.Service) { proxier.OnServiceUpdate(nil, service) } // OnServiceUpdate is called whenever modification of an existing service object is observed....

本文是关于Kubernetes service解析的第2章 深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？ 深入理解Kubernetes service - kube-proxy架构分析 深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性 所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy Endpoint Endpoints 就是 service 中后端的server，通常来说 endpoint 与 service是关联的，例如下面的一个endpoints 资源。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 apiVersion: v1 kind: Endpoints metadata: name: nginx subsets: - addresses: - ip: 172.17.0.2 - ip: 172.17.0.3 ports: - port: 80 name: "111" # 多个端口需要用name - port: 88 name: "222" 而 Endpoints 资源是由控制平面的 Endpoints controller 进行管理的，主要用于将外部server引入至集群内时使用的，例如Kube-apiserver 在集群外的地址，以及external service所需要创建的。...

本文是关于Kubernetes service解析的第4章 深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？ 深入理解Kubernetes service - kube-proxy架构分析 深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性 所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy Overview 在前两部分中，学习了一些 service,于kube-proxy在设计架构，但存在扩展问题将引入了一些问题： 为什么需要了解这部分内容呢？ 与传统架构有什么区别呢？ 于eBPF 的 cilium又有什么区别呢？ 既然eBPF可以做到，那为什么要这部分内容呢？ 接下来的内容将围绕这四个问题展开来讲，而不是代码的讲解，代码可以看置顶 IPVS与iptables在kubernetes中应用时的问题 对于在使用了kubernetes用户以及了解 kube-proxy 架构后，知道当集群规模过大时，service必将增多，而一个service未必是一条iptables/ipvs规则，对于kubernetes这种分布式架构来说，集群规模越大，集群状态就越不可控，尤其时kube-proxy。 为什么单指kube-proxy呢？想想可以知道，pod的故障 或 node 的故障对于kubernetes集群来说却不是致命的，因为 这些资源集群中存在 避免方案，例如Pod的驱逐。而kube-proxy或iptables/IPVS问题将导致服务的不可控 『抖动』例如规则生成的快慢和Pod就绪的快慢不一致，部分节点不存在 service 此时服务必然抖动。 再例如 iptables/IPVS 排查的难度对于普通运维工程师或开发工程师的技术水平有很高的要求，网上随处可见分析该类问题的帖子： kube-proxy源码分析与问题定位 案例分析：怎么解决海量IPVS规则带来的网络延时抖动问题？ ipvs 连接复用引发的系列问题 Investigating Causes of Jitter in Container Networking ContainerNative network LoadBalancer IPVS jitter 对于上述问题，相信遇到了很难定位处理，虽然现在已fixed，并有eBPF技术的加入减少了此类问题的发生，但是eBPF实际同理于IPVS 都是需要对Linux内核有一定了解后才可以，这也就是为什么需要了解这部分 如果需要自定义proxier为什么会解决这个问题 这里就是放大到kubernetes意外的传统架构中，当直接部署于Linux系统上使用nginx等传统LB时就很少有人提到这些问题了，而这些问题存在一个关键字「Container」；而引发这个问题的则是 service。去除 service 的功能，传统架构于Kubernetes架构部署的应用则是相同的，只是区分了名称空间。...

本文是关于Kubernetes service解析的第3章 深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？ 深入理解Kubernetes service - kube-proxy架构分析 深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性 所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy 前提概述 kubernetes集群中运行在每个Worker节点上的组件 kube-proxy，本文讲解的是如何快速的了解 kube-proxy 的软件架构，而不是流程的分析，专注于 proxy 层面的设计讲解，而不会贴大量的代码 kube-proxy软件设计 kube-proxy 在设计上分为三个模块 server 于 proxy： server: 是一个常驻进程用于处理service的事件 proxy: 是 kube-proxy 的工作核心，实际上的角色是一个 service controller，通过监听 node, service, endpoint 而生成规则 proxier: 是实现service的组件，例如iptables, ipvs…. 如何快速读懂kube-proxy源码 要想快速读懂 kube-proxy 源码就需要对 kube-proxy 设计有深刻的了解，例如需要看 kube-proxy 的实现，我们就可以看 proxy的部分，下列是 proxy 部分的目录结构 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 $ tree -L 1 ....

本文是关于Kubernetes service解析的第1章 深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？ 深入理解Kubernetes service - kube-proxy架构分析 深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性 所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy 前景 对于了解kubernetes架构时，已知的是 service 是kubernetes在设计时为了避免Pod在频繁创建和销毁时IP变更问题，从而给集群内服务（一组Pod）提供访问的一个入口。而Pod在这里的角色是 『后端』( backend ) ，而 service 的角色是 『前端』( frontend )。本文将阐述service的生命周期 为什么需要了解这部分内容呢 对于 without kube-proxy来说，这部分是最重要的部分，因为service的生成不是kube-proxy来完成的，而这部分也就是service ip定义的核心。 控制器 service的资源创建很奇妙，继不属于 controller-manager 组件，也不属于 kube-proxy 组件，而是存在于 apiserver 中的一个被成为控制器的组件；而这个控制器又区别于准入控制器。更准确来说，准入控制器是位于kubeapiserver中的组件，而 控制器 则是存在于单独的一个包，这里包含了很多kubernetes集群的公共组件的功能，其中就有service。这也就是在操作kubernetes时 当 controller-manager 于 kube-proxy 未工作时，也可以准确的为service分配IP。 首先在构建出apiserver时，也就是代码 cmd/kube-apiserver/app/server.go go 1 2 3 4 serviceIPRange, apiServerServiceIP, err := master.ServiceIPRange(s.PrimaryServiceClusterIPRange) if err !...