本文是关于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 !...

本文是关于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 ....

haproxy作为一个『代理软件』如果当工作与 HTTP 模式下，所有经由haproxy的的连接的请求和响应都取决于 frondend 中配置的 『http_connection_mode』 即 haproxy 中 frontend 与 backend 的组合，而haproxy 支持 3 种连接模式： KAL keep alive: frontend 中配置为 http-keep-alive ; 这是默认模式，这也是http中的keepalive 表示所有请求和响应都得到处理，连接保持打开状态，但在响应和新请求之间处于空闲状态。 SCL server close : frontend 中配置为 http-server-close ; 接收到响应结束后，面向服务器的连接关闭，但面向客户端的连接保持打开状态 CLO close: frontend 中配置为 httpclose ；连接在响应结束后关闭，并在两个方向上附加 “Connection: close” 。 下列矩阵表示的是通过 frondend 与 backend 之间两端的代理模式，这个模式是对称的 text 1 2 3 4 5 6 7 | KAL | SCL | CLO ----+-----+-----+---- KAL | KAL | SCL | CLO ----+-----+-----+---- mode SCL | SCL | SCL | CLO ----+-----+-----+---- CLO | CLO | CLO | CLO 对于http选项的说明 选项 说明 forwardfor 这个选项同时存在于backend 与 frontend端，但backend中的优先级超过frontend 如果同时设置了这个参数，那么 backend段的子参数将优先与 frontend 一端 httpchk 启用http协议检查来检测server的健康状态，默认情况下状态检查是仅建立一个tcp连接 httpclose 这个选项代表了haproxy 对于http协议持久连接方便的配置 Reference：configuration....

类型断言 类型断言 type assertion 并不是真正的将 interface 类型转换为另一种确定的类型，只是提供了对 interface 类型的值的访问，通常情况下，这是常见的需求 类型断言通过 语法 x.(T) ，这将会确定 x 变量中存储的值是否属于 T 类型，通常场景有两种： 如果 T 不是 interface 类型，而是一个具体的类型，那么这次断言将断言 x 的 动态类型是否与 T 相同 如果 T 是 interface 类型，这次断言 x 的动态类型是否实现了 T go 1 2 3 4 5 6 7 8 9 10 11 12 var x interface{} = "foo" var s string = x.(string) fmt.Println(s) // "foo" s, ok := x.(string) fmt.Println(s, ok) // "foo true" n, ok := x....

Windows git “warning: LF will be replaced by CRLF” [1] bash 1 git config --global core.autocrlf false Disable Credential Manager bash 1 2 3 4 5 git config --global credential.modalprompt false git credential-manager remove -force git credential-manager uninstall --force Multi account management [2] step1: clean globle setting bash 1 2 git config --global --unset user.name git config --global --unset user.email step2： change config file only ssh bash Do not Pop-ups authtication [3] This question is the git shell prompt input user and password in an openssh popup on windows plateform...