背景 对于整个 Kubernetes 集群来说，随着业务不断地打磨，新增指标，那么对于 Prometheus 特性来说，那么内存 与 存储的使用势必是增加。这是对于存储压力是很重的，通常情况下，使用 Prometheus，都会是用于 Kubernetes 集群中，而 应用于 Kubernetes 集中的存储势必是 PVC 之类的网络存储。 这种场景中，我将尝试拆解如何分析和配置 Prometheus 以显著的减少其资源使用并解决高基数问题 高基数 基数 (cardinality) 通俗来说是一个集合中的元素数量 [1] 基数的来源通常为： label 的数量 series(指标) 的数量 时间：label 或者 series 随时间而流失或增加，通常是增加 那么这么看来高基数就是，label, series, 时间这三个集合的笛卡尔积，那么高基数的情况就很正常了。 而高基数带来的则是 Prometheus 资源使用，以及监控的性能。下图是 Grafana Lab 提到的一张图，很好的阐述了高基数这个问题 图：Prometheus中的基数 Source：https://grafana.com/blog/2022/02/15/what-are-cardinality-spikes-and-why-do-they-matter 如图所示：一个指标 server_responses 他的 label 存在两个 status_code 与 environment ，这代表了一个集合，那他的 label value 是 1~5xx，这个指标的笛卡尔积就是10。 那么此时存在一个问题，如何能定位 基数高不高，Grafana Lab 给出了下面的数据 [1]，但是我不清楚具体的来源或者如何得到的这些值。也就是 label:value 低基数：1: 5 标准基数：1: 80 高基数：1: 10000 为什么指标会指数级增长 在以 Kubernetes 为基础的架构中，随着抽象级别的提高（通常为Pod, Label, 以及更多抽象的拓扑），指标的时间序列也越来越多。因为在这种基础架构中，在传统架构中运行的一个应用的单个裸机，被许多运行分散在许多不同节点上的许多不同微服务的 Pod 所取代。在这些抽象层中的每一个都需要一个标签，以便可以唯一地标识它们，并且这些组件中的每一个都会生成自己的指标，从而创建其独特的时间序列集。...

场景 在配置代理后，GET 请求的变量全部失效，配置如下 text 1 2 3 location /fw { proxy_pass http://127.0.0.1:2952; } 我的需求是，/fw/ 的都发往 2952端口，但实际情况是404，原因为“在没有指定 URI 的情况下，在1.12版本后会传递原有的URI” 这时会导致一个404错误，因为我的后端接口本身就是 /fw/xxx/ 会出现重复 接下来做了一个变量传递 text 1 2 3 location ~* /fw/(?<section>.*) { proxy_pass http://127.0.0.1:2952/fw/$section; } 这时存在一个问题，就是 GET 请求的变量无法传递过去 解决 nginx 官方给出一个样例，说明了，存在某种情况下，nginx 不会确定请求 URI 中的部分参数 使用正则表达式时 在 localtion 名称内 例如，在这个场景下，proxy_pass 就会忽略原有的请求的URI，而将拼接后的请求转发 text 1 2 3 4 location /name/ { rewrite /name/([^/]+) /users?name=$1 break; proxy_pass http://127.0.0.1; } 那么这服务我遇到的问题，nginx官方给出了使用方式 当在 proxy_pass 中需要变量，可以使用 $request_uri; 另外也可以使用 $is_args$args 参数 来保证原有的请求参数被传递...

vue项目部署在裸机Linux上运行正常，部署在docker中nginx出现下列错误 text 1 Nginx "rewrite or internal redirection cycle while internally redirecting to "/index.html" 表现在用户界面 500 Internal Server Error 原因：nginx配置路径不对，改成正确的后恢复

基本概念 从版本 2.4 开始，如果包包含.config.yaml ，可以使用包配置，包配置可以使用配置文件来设置包中资源通用的值，例如 API 凭证、连接详细信息、限制和阈值。这些值在运行时可供操作和传感器使用。 包配置和 Action 参数之间的区别在于，配置通常包含包中所有资源通用的值，并且很少更改。动作参数是随每个动作调用动态提供的，并且可能会发生变化 - 例如，它们可能来自映射某些输入事件的规则。 包配置遵循基础架构即代码方法，并存储在特殊目录中的 YAML 格式文件中（默认情况下 /opt/stackstorm/configs）。每个包都为此配置文件定义自己的架构。 配置 Schema 配置文件的结构是一个 YAML 格式的文件，它定义了该包的配置文件。该配置由包作者自行编写，包含有关每个可用配置项的信息，例如名称, Secret等）。该文件已命名 config.schema.yaml 并位于包目录 /opt/stackstorm/packs/<mypack> 的根目录中。 这是一个示例包配置文件： yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 --- api_key: description: "API key" type: "string" required: true api_secret: description: "API secret" type: "string" secret: true required: true region: description: "API region to use" type: "string" required: true default: "us-east-1" private_key_path: description: "Path to the private key file to use" type: "string" required: false 在该示例中，配置文件由 4 项 配置组成 (api_key, api_secret, region, private_key_path)...

什么是容器中的多进程管理 在容器中的主进程 (main running process) 是指 Dockerfile中 ENTRYPOINT 或 CMD 指定运行的命令，通常情况下一个进程（服务）为一个容器；也存在一种场景，就是主进程会fork多个子进程，例如nginx，不过这种多进程通常为nginx主进程进行管理。而一些场景下，我们的业务本身就需要多个启用独立的多个进程。 在Docker官方提到了在容器中运行多个服务的方式，官方提出，应该避免这种情况 but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application. 但也给出了如何管理多进程的一种思路， Use a wrapper script Use Bash job controls Use a process manager 下面就通过官方给出的这三种方式阐述容器中的多进程管理 Use a wrapper script 对于使用脚本来管理多进程来说，本质上是可以实现多进程的启动，但是你没法去监控(管理)多个进程的运行时，例如 Nginx + PHP 模式， PHP或nginx全部挂掉，只要脚本还在运行，那么这个容器的生命周期还是处于Running Use Bash job controls 这种模式是利用了Bash的后台模式进行短暂的切换进程，但有些镜像不提供Bash这时应该怎么办 Use a process manager 进程管理器，通常情况下大家想到的就是顶顶大名的 supervisor 和 systemd，但这两个程序运行的环境十分苛刻，例如 supervisor 是Python开发的程序，运行需要依赖 Python；而 systemd 的运行条件更为苛刻，例如需要额外运行dbus-damon进行注册到dbus总线之上，这种进程管理器可能运行的进程比我们要管理的进程都要多。在这种场景下，有一个部署简单，配置简单，无依赖的轻量级容器多进程管理器 s6-overlay...

Deployment Recommended Cluster Architecture - rancher Hardware recommendations - etcd A simple shell script for backing up etcd v2 and v3 datastores Considerations for large clusters - kubernetes cluster Operating etcd clusters for Kubernetes Recommended performance and scalability practices Binary deploy script pure shell Managing Kubernetes Traffic with F5 NGINX Eraser - Cleaning up Images from Kubernetes Nodes 对于不同规模的 Kubernetes 集群所需要的 etcd 规模推荐 datree: allowing you to scan your k8s configs during development Performance etcd: getting 30% more write/s 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路 各组件参数配置调优 万级K8s集群背后etcd稳定性及性能优化实践 K8s 集群稳定性：LIST 请求源码分析、性能评估与大规模基础服务部署调优 Comparing comparing Kubernetes ingress controller Troubleshooting 一次Etcd集群宕机引发的思考 Stern: allows you to tail multiple pods on Kubernetes Diagnosis Kubernetes 自动化诊断工具：k8sgpt-operator ktop: displays useful metrics information about kubernetes cluster Dashboard KDash - A fast and simple dashboard for Kubernetes Security Kubernetes 加固指南 Popeye 扫描实时 Kubernetes 集群并报告已部署资源和配置的潜在问题 Test kube-monkey It randomly deletes Kubernetes (k8s) pods in the cluster encouraging and validating the development of failure-resilient services....

为什么去除polkit验证 在2021年询问过firewalld项目组，firewalld在dbus通讯时，会进行两部认证 policy kit 和 UID checking，正是因为这种情况，使得firewalld不能够通过TCP/IP连接，如果你需要连接，因为存在 UID checking ，这时会因为没有UID会报错。 firewalld needs to do some authorization on the dbus request. It currently tries two ways, in order of preference: policy kit UID checking Neither of these are available over a TCP/IP dbus connection. [1] 如何去除polkit 首选需要确定你的firewalld版本，例如Centos7系列，那么你的 firewalld 版本为 0.6.3，那么你需要修改的包为 python-firewall-0.6.3, 在 debian11 上 firewalld版本默认为 0.9.3，那么需要关注的版本为：python3-firewall_0.9.3 在确定版本后直接从github仓库进行拉去修改就可以 bash 1 2 git fetch v0.9.3 git checkout v0.9.3 对于 python-firewall-0.6.3 来说。直接注释掉 slip.dbus.polkit.require_auth 就可以了...

如果不小心提交github提交错了，而 --amend 也不能修改提交者的信息，可以通过尝试下面的方式 Checkout bash 1 git checkout --orphan <latest_branch> Add all the files bash 1 git add -A Commit the changes bash 1 git commit -am "commit message" Delete the branch bash 1 git branch -D main Rename the current branch to main bash 1 git branch -m main Finally, force update your repository bash 1 git push -f origin main 缺点是：所有该分支的提交记录都将被删除 Reference how to delete all commit history in github?...

deb 概述 deb包（.deb）是 Debian 和基于 Debian衍生操作系统（如Ubuntu）中使用的一种软件包的格式。deb是一种基于 Unix ar [3] (Unix archiver) 的归档文件。其中包含二进制文件、配置文件和其他软件所需的资源。deb包可用于安装、升级和卸载软件包。通常，Debian操作系统的用户使用apt（Advanced Package Tool）等软件包管理器工具来管理deb包。通过这些工具，用户可以轻松下载、安装和管理软件包，而无需手动编译、安装和解决软件包之间的依赖关系。 deb VS rpm 包的归档格式不同：deb是基于 ar 的归档模式，而RPM是基于 cpio 的归档模式 包的结构不同：deb包要求必须包含一个 DEBIAN 目录；而RPM不需要以来额外的目录结构 包的依赖机制不同： Deb使用epoch，而RPM使用build number：在Deb中，epoch是一个可选的字段，它允许呈现基准日期之前的先前版本。而在RPM中，build number表示软件包编译的次数。因此，在Deb中，为了解决版本控制问题，epoch是非常重要的，而在RPM中，则更关注build number。 Deb使用逆向依赖关系，而RPM使用依赖关系：在Deb中，依赖项是从包本身向外扩展，在解决依赖问题时可以通过逆向依赖关系进行。而在RPM中，则更喜欢使用依赖关系直接指向其他包。 Deb允许代理软件包，而RPM则不允许代理软件包：Deb中，软件包可以使用另一种软件包的代理来提供功能。在RPM中，软件包需要直接引用相关的软件包。这意味着在Deb中，对于版本控制，可以用另一种代理软件包来解决问题，而在RPM中必须直接引用包。 Deb允许多重依赖关系，RPM则不允许：Deb允许使用多个依赖项列表，以便包与不同版本的库兼容。在RPM中，需要在每个包中定义依赖项和其版本，不能使用多重依赖。 deb包的分析 deb包的结构 deb 最重要的是 控制文件 Control ，该文件记录了deb包与其安装的程序的信息。 在deb包内部包含一组模拟 Linux 文件系统的文件夹，例如 /usr, /usr/bin, /opt等等。 放置在其中一个目录中的文件将在安装期间复制到实际文件系统中的相同位置。 因此，例如将二进制文件放入 <.deb>/usr/local/bin/binaryfile 将被安装到 /usr/local/bin/binaryfile. 对于deb 包的命名是遵循着一个特定的格式： text 1 <name>_<version>-<revision>_<architecture>.deb <name> 构建的deb包名称，如nginx <version> 程序的版本号 ，如1.20 <revision> 当前 deb 包的版本号 <architecture> 表示构建出的包的操作系统架构，如，amd64、i386 如果你构建一个nginx-1.20的arm操作系统下的，那么deb包名格式则为 nginx_1.20-1_arm64.deb control文件 [2] Deb软件包（....

telnet：busybox-extras net-tools: net-tools tcpdump: tcpdump wget: wget dig nslookup: bind-tools curl: curl nmap: nmap wget ifconfig nc traceroute.. : busybox ssh: openssh-client ss iptables: iproute2 ethtool: ethtool yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 FROM alpine MAINTAINER RUN sed -i 's@http://dl-cdn.alpinelinux.org/@https://mirrors.aliyun.com/@g' /etc/apk/repositories RUN apk add --no-cache --virtual .persistent-deps \ curl \ tcpdump \ iproute2 \ bind-tools \ ethtool \ busybox-extras \ libressl \ openssh-client \ busybox CMD [ "tail", "-f" ]

D-Bus 是 Linux 系统中的一种通信机制，用于在进程之间进行通信。D-Bus 配置文件则是一种用于配置 D-Bus 的文件，其中包含有关系统总线 (system bus)，会话总线 (session bus) 和各种系统服务的详细信息。 本文将解析 D-Bus 配置文件，侧重点则为权限的配置 配置文件的基本结构 D-Bus 配置文件使用 XML 格式进行编写，具有以下基本结构： xml 1 2 3 4 5 6 7 8 9 10 11 12 <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/D-Bus/1.0/busconfig.dtd"> <busconfig> <policy group="wheel"> <!-- policy rules go here --> </policy> <policy context="default"> <!-- policy rules go here --> </policy> <include filename="other-config.xml"/> <listen>unix:path=/var/run/D-Bus/system_bus_socket</listen> </busconfig> 什么是D-Bus Policy？ D-Bus Policy是D-Bus配置文件中最重要的字段之一，用于定义D-Bus服务的访问控制策略。D-Bus Policy包含了一组规则，用于限制D-Bus服务的使用者对D-Bus服务的访问，确保D-Bus服务的安全性。...

创建型模式 工厂模式 概念说明 工厂模式 (factory pattern) 是在父类中提供一个创建对象的方法，是用于创建不同类型的对象，而无需指定对象的真实的类 工厂模式的特点： 对客户端隐藏对象创建的复杂逻辑 可以通过修改工厂类来创建对象而不影响客户端代码 提供创建对象的单一来源。 单个工厂类用以各组件保持一致性。 允许子类创建对象类型 图：工厂设计模式的示意图 Source：https://www.techcrashcourse.com/2015/10/factory-design-pattern.html 图片说明： Owl, Eagle, Sparrow 类都必须实现 Brid 接口， 该接口声明了一个名为 fly() 的方法。 每个类都将以不同的方式实现该方法。而使用工厂模式后的代码机构则为图所示，当 Owl, Eagle, Sparrow 实现了共同的接口，就可以将其对象传递给客户代码， 而无需提供额外数据。 而 “调用工厂方法的代码” 称为 “客户端代码”，这样可以做到 “不需要了解不同子类返回实际对象之间的差别”。客户端代码将所有 Brid Sanctuary 视为抽象的 Brid ，这样 ”客户端代码“ 知道所有鸟类对象都提供 fly() 方法， 但是并不关心其实现方式。 代码实现 brid.go go 1 2 3 4 5 package main type Brid interface { Fly() } Owl.go go 1 2 3 4 5 type Owl struct {} func (g *Owl) Fly() { fmt....

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

概述 在之前有一个系列提到了扩展proxier，但可能细心的同学注意到，作为一个外部的LB，市场上存在一些开源的为kubernetes集群提供的LB，这不是舍近求远吗？而 Google工程师 Adam Dunstan 的 文章 [1] 对比了这些LB的区别（中文翻译备份 [2] ），例如： MetalLB：最流行的 负载均衡控制器 PureLB：新产品 (文章作者 Adam Dunstan 参与了 PureLB的开发工作) OpenELB：相对较新的产品，最初该LB仅关注路由方向 文章提出了一个LB实现的基本目标为：必要的简单网络组件，与可扩展的集群操作 启动受控的集群service/应用的外部访问 外部资源的预配置 易于整合自动化的工作流程（CI/CD） 那么这些LB与 kube-proxy 甚至于 IPVS/IPTables 有什么区别呢？ 这些LB的核心是为集群service提供一个外部IP，而service功能本身还是由 kube-proxy,IPVS 提供，在这点 MetalLB 介绍中提到了这个问题 In layer 2 mode, all traffic for a service IP goes to one node. From there, kube-proxy spreads the traffic to all the service’s pods. [3] After the packets arrive at the node, kube-proxy is responsible for the final hop of traffic routing, to get the packets to one specific pod in the service....

本文是关于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所需要创建的。...

前言 MIUI13 石锤了内置反诈APP后，我的是MIUI12, 接到公安的私人电话，系统直接弹出国家反诈的弹窗，关键我是印度版的Rom，一身冷汗，估计当局审查是通过系统组件更新了，直接装Pixel Experience，以后换设备永远不换最新的，让网友们踩坑吧 注：隐私是一种权利，电信诈骗请问 骗子怎么知道我的金融信息，怎么知道我的出入境信息。上海公安10亿信息泄露是怎么情况，当公权力无法保证用户隐私时，请不要实名制，参考韩国。隐私权参考欧洲 操作 进入fastboot(power button + volume button up)，然后使用数据线连接至PC(windows),然后下载MiFlash 首次弹出时需要安装驱动，以便PC可以识别到手机 给手机安装TWRP [1]，通过搜索找到你的手机型号 例如 Redmi Note5。(可以去小米ROM网上对照下你的手机代号时什么例如 Note7 Pro 代号为 紫罗兰 violet) 在下载时TWRP网站上会提示你先安装 Play Stroe(这是包含了adb fastboot等工具的工具包，有的话可以不装) 安装步骤可以参考 [2] 选择 Wipe – Advance Wipe – 选上 System, Data, Dalvik, Cache 四个擦除 下载 firmware 与 PixelExperience 去 https://download.pixelexperience.org/ 下载 PixelExperience 找到自己的手机型号，参考1 去 https://xiaomifirmwareupdater.com/firmware/ 下载 fireware 找到自己的手机型号，参考1 注：建议直接搜代号如violet，搜型号太多不好找 向手机复制 firmware [3] 和固件 fw_violet_miui_VIOLET_9.9.3_79d3ccd33b_9.0.zip PixelExperience_violet-10.0-20191021-1744-BETA-OFFICIAL.zip 复制命令参考 [10] 按先后顺序安装后，重启就安装好google pixel experience了 enjoy 🤞...

本文是关于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解析的第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....