官方文档1：入门 | Kubernetes
官方网址2：https://www.kubernetes.org.cn/kubernetes%e8%ae%be%e8%ae%a1%e6%9e%b6%e6%9e%84
一 架构图
原文网址：Kubernetes概述 - Jacob先生 - 博客园
二 watch-list理解
2.1 创建过程
0.kubectl apply -f pod.yaml
1.kubectl将yaml文件转换为json,提交给apiserver,apiserver将数据存储到etcd中
2.scheduler通过list watch机制监听到创建新Pod的事件，根据Pod属性调度到Node上，同时给Pod打标签指明调度到具体哪个节点，可以通过kubectl get pod -owide查看
3.apiserver拿到调度结果并写入到etcd中
4.kubelet从apiserver获取分配到其所在节点的Pod
5.kubelet调用Docker的/var/run/docker.sock创建容器
6.Docker根据kubelet需求创建容器并把容器的状态汇报给kubelet
7.kubelet将Pod状态更新到apiserver
8.apiserver将状态信息写到etcd中
9.kubectl get pod
2.2 List-Watch 的设计理念 - Informer 设计思路
推荐阅读文章1：理解 K8S 的设计精髓之 List-Watch机制和Informer模块_技术拆解官们的狂欢-CSDN博客_list watch机制
简书带图原文链接：理解 K8S 的设计精髓之 List-Watch机制和Informer模块 - 简书
List-Watch 机制具体是什么样的
Etcd存储集群的数据信息，apiserver作为统一入口，任何对数据的操作都必须经过 apiserver。客户端(kubelet/scheduler/controller-manager)通过 list-watch 监听 apiserver 中资源(pod/rs/rc等等)的 create, update 和 delete 事件，并针对事件类型调用相应的事件处理函数。
那么list-watch 具体是什么呢，顾名思义，list-watch有两部分组成，分别是list和 watch。list 非常好理解，就是调用资源的list API罗列资源，基于HTTP短链接实现；watch则是调用资源的watch API监听资源变更事件，基于HTTP 长链接实现，也是本文重点分析的对象。以 pod 资源为例，它的 list 和watch API 分别为： [List API](https://v1-10.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#list-all-namespaces-63)，返回值为 [PodList](https://v1-10.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#podlist-v1-core)，即一组 pod`。
GET /api/v1/pods
Watch API，往往带上 watch=true，表示采用 HTTP 长连接持续监听 pod 相关事件，每当有事件来临，返回一个 WatchEvent。
GET /api/v1/watch/pods
K8S 的informer 模块封装 list-watch API，用户只需要指定资源，编写事件处理函数，AddFunc, UpdateFunc和 DeleteFunc等。如下图所示，informer首先通过list API 罗列资源，然后调用 watch API监听资源的变更事件，并将结果放入到一个 FIFO 队列，队列的另一头有协程从中取出事件，并调用对应的注册函数处理事件。Informer还维护了一个只读的Map Store 缓存，主要为了提升查询的效率，降低apiserver 的负载。
推荐阅读2：K8S API-Server 源码剖析（一）| 监听机制 List-Watch 剖析_pod
kubernetes 的组件大量地用到了监听机制去获取事件，每个组件有种互不干涉（不直接向另一个组件发送请求）但是却息息相关（时刻监听变化）的感觉，而这种机制的主要实现方式就是 List-Watch 机制，不过很多时候，我们看到很多资料讲 Informer 机制或者 Reflactor 机制来实现监听，但其实他们的本质都是 List-Watch。
这里 List，一般就是指获取全量数据，一个一次性的请求。Watch，一般指获取增量数据，一个持久链接 (Http streaming) 的请求，其原理是采用的是 Chunked transfer encoding。
HTTP 分块传输编码允许服务器为动态生成的内容维持 HTTP 持久链接。通常，持久链接需要服务器在开始发送消息体前发送Content-Length消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。
服务端回复的ehttp header中带有"Transfer-Encoding": "chunked"。客户端收到这种header的response之后会等待后续数据。
另一方面，通过上面描述，我们看到其实监听可以说有两个层面：
1. kubernetes 组件 ( controller, sheduler, kubelet ) 到 apiserver 的层面。
2. apiserver 到 etcd 的层面。
我们在使用 kubectl 发送 List-Watch 请求或者我们在自定义开发 CustomResourceDefinition( CRD ) 的时候，所关心的基本上都是第一个层面的，这段代码的实现主要是在 kubernetes 的 client-go 模块中，这也是本文章想着重阐述的。至于第二个层面，本质上它是使用了 etcd-client 来发送监听请求，这一点我们会在之后关于 etcd 的介绍中详细阐述。
2.1. kubectl 发送 List-Watch 请求
kubectl get pods/my-busybox --watch -v 7
I1206 10:42:24.224542 27145 loader.go:375] Config loaded from file: /root/.kube/config
I1206 10:42:24.236718 27145 round_trippers.go:420] GET https://cls-0126wled.ccs.tencent-cloud.com/api/v1/namespaces/default/pods/my-busybox
I1206 10:42:24.236734 27145 round_trippers.go:427] Request Headers:
I1206 10:42:24.236740 27145 round_trippers.go:431] Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json
I1206 10:42:24.236746 27145 round_trippers.go:431] User-Agent: kubectl/v1.18.0 (linux/amd64) kubernetes/9e99141
I1206 10:42:24.256912 27145 round_trippers.go:446] Response Status: 200 OK in 20 milliseconds
NAME READY STATUS RESTARTS AGE
my-busybox 0/1 Completed 0 5s
I1206 10:42:24.257800 27145 round_trippers.go:420] GET https://cls-0126wled.ccs.tencent-cloud.com/api/v1/namespaces/default/pods?fieldSelector=metadata.name%3Dmy-busybox&resourceVersion=0&watch=true
I1206 10:42:24.257807 27145 round_trippers.go:427] Request Headers:
I1206 10:42:24.257815 27145 round_trippers.go:431] Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json
I1206 10:42:24.257823 27145 round_trippers.go:431] User-Agent: kubectl/v1.18.0 (linux/amd64) kubernetes/9e99141
I1206 10:42:24.259965 27145 round_trippers.go:446] Response Status: 200 OK in 2 milliseconds
my-busybox 0/1 Completed 1 7s
my-busybox 0/1 CrashLoopBackOff 1 8s
my-busybox 0/1 Completed 2 20s
my-busybox 0/1 CrashLoopBackOff 2 21s
推荐阅读文章3：K8S list&watch机制 - 邬迪内斯 - 博客园
三 kubectl渗透 K8s渗透测试之kube-apiserver利用 - cdxy
四 实践http长连接和Linux内核调优
推荐文档：linux内核优化（百万级别长连接，并发测试指南） - 北方客888 - 博客园
概要：
之所以想写一篇大数量级的测试方式，是因为，网上大多数文章要么是给测试代码或者工具，要么是给一堆解释的不是很清楚的参数,再者就是只贴连接数的数量，如果只是达到这么多的连接，却不给出成功失败率，实在是有点耍流氓。
有意思的是这么强势的测试框架居然相关内容这么少,有空读读源码.
本文所有的代码可以在以下链接找到
blog/locust-test at master · youerning/blog · GitHub
参考文档:
Linux之TCPIP内核参数优化:
Linux之TCPIP内核参数优化 - 最初的幸福ever - 博客园
理解 Linux backlog/somaxconn 内核参数:
理解 Linux backlog/somaxconn 内核参数 - Jamin Zhang
Linux下Http高并发参数优化之TCP参数:
https://kiswo.com/article/1017
单台服务器百万并发长连接支持:
单台服务器百万并发长连接支持_马万明的专栏-CSDN博客
结合案例深入解析orphan socket产生与消亡：
[原创]结合案例深入解析orphan socket产生与消亡（一）-阿里云开发者社区
2287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
