深入理解Kubernetes service - 你真的理解service吗?

本文是关于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 - kube-proxy架构分析

本文是关于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作为一个『代理软件』如果当工作与 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....

 ·  · 

Go中的类型断言与类型转换

类型断言 类型断言 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....

 ·  · 

git在windows上常用配置

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...

 ·  ·