目录
八、kubernetes核心组件之controller manager详解
放在文章首位：
该文章为学习时发现的宝藏集合，为了避免失联仅以留存形式在此。建议去原文阅读：https://blog.csdn.net/qq_42987484/category_9539473.html。
个人认为内容以理解为主，不求记忆，涉及时反复温习即可，相信每次会有新的收获。
六、kubernetes核心组件之apiserver详解
k8s API Server提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。
-
提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；
-
提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;
-
是资源配额控制的入口；
-
拥有完备的集群安全机制;
kube-apiserver提供了k8s的rest api，实现了认证、授权和准入控制等安全功能，同时也负责了集群状态的存储操作。
-
rest api
kube-apiserver支持同时提供https和http api，其中http api是非安全接口，不做任何认证授权机制，不建议生产环境启用，但两个接口提供的rest api格式相同。-
https api 默认监听在6443端口（–secure-port=6443）；
-
http api 默认监听在127.0.0.1的8080端口（使用参数 --insecure-port=8080）；
-
-
访问控制说明
k8s api 每个请求都会经过多阶段的访问控制才会被接受，包括认证、授权及准入控制等。-
认证
开启TLS情况下，所有请求都需要首先认证。k8s支持多种认证机制，并且支持同时开启多个认证插件（仅一个认证通过即可），如认证成功，则用户的username会传入授权模块做进一步的授权验证，而认证失败的请求则返回http 401 。 -
授权
认证之后的请求就到了授权模块，和认证类似，k8s也支持多种授权机制，并支持同时开启多个授权插件（仅一个验证通过即可）。如授权成功，则用户的请求会发送到准入控制模块做进一步的请求验证，失败的请求则返回http403。 -
准入控制
用来对请求做进一步的验证或添加默认参数，不同于认证和授权只关心请求的用户和操作，准入控制还会处理请求的内容，并且仅对创建、更新、删除或连接（如代理）等有效，而对读操作无效。准入控制也支持同时开启多个插件，但他们是依次调用的，只有全部插件都通过的请求才可以允许进入系统。
-
kube-apiserver工作原理图如下：
k8s通过kube-apiserver这个进程提供服务，该进程运行在单个k8s-master节点上，默认有两个端口。
-
本地端口
1.该端口用于接收HTTP请求；
2.该端口默认值为8080，可以通过API Server的启动参数“–insecure-port”的值来修改默认值；
3.默认的IP地址为“localhost”，可以通过启动参数“–insecure-bind-address”的值来修改该IP地址；
4.非认证或授权的HTTP请求通过该端口访问API Server; -
安全端口
1.该端口默认值为6443，可通过启动参数“–secure-port”的值来修改默认值；
2.默认IP地址为非本地（Non-Localhost）网络端口，通过启动参数“–bind-address”设置该值；
3.该端口用于接收HTTPS请求；
4.用于基于Tocken文件或客户端证书及HTTP Base的认证；
5.用于基于策略的授权；
6.默认不启动HTTPS安全访问控制
1 直接访问api
通过本地8080端口使用curl命令能直接获取REST api的信息,例如：
查看版本：
curl 127.0.0.1:8080/api
查看支持的资源对象：
curl 127.0.0.1:8080/api/v1
查看资源对象信息：
curl 127.0.0.1:8080/api/v1/nodes
curl 127.0.0.1:8080/api/v1/pods
curl 127.0.0.1:8080/api/v1/services
curl 127.0.0.1:8080/api/v1/replicationcontrollers
具体到某一个具体的对象：
curl 127.0.0.1:8080/api/v1/nodes/10.0.0.3
指定不同namespace中的对象进行访问：
curl http://127.0.0.1:8080/api/v1/namespaces/default/services/php-apache
直接访问后端服务内容：
curl http://127.0.0.1:8080/api/v1/namespaces/default/services/http:tomcat-service:/proxy/
curl http://127.0.0.1:8080/api/v1/namespaces/default/services/http:php-apache:/proxy/
其他的API信息：
curl 127.0.0.1:8080/apis/batch/v1
2 Kubernetes Proxy
Kubernetes Proxy主要用于代理REST请求。 可以通过这种代理方式将API Server收到的REST请求转发到某个Node上的kubelet上，由Kubelet负责响应。
创建一个Proxy 接口(此处创建一个监听本地10.0.0.1上的8001端口)：
kubectl proxy --port=8001 --accept-hosts=‘.*‘ --address=‘10.0.0.1‘ &
-
如果需要对访问的资源和源地址进行限制，可以使用正则进行匹配，限制对services进行访问：
kubectl proxy --port=8001 --accept-hosts=‘.*‘ --address=10.0.0.1 --reject-paths=‘^/api/v1/services‘
通过此端口可以在外部直接访问此api代理，在新的版本中，访问方式和常规访问的URL一致：
curl http://10.0.0.1:8001/api/v1/pods
curl http://10.0.0.1:8001/api/v1/nodes
curl http://10.0.0.1:8001/api/v1/services
curl http://10.0.0.1:8001/api/v1/replicationcontrollers
curl http://10.0.0.1:8001/api/v1/namespaces/default/pods/tomcat-deployment-65799d5fc4-5dx4h
curl http://10.0.0.1:8001/api/v1/namespaces/default/services/http:php-apache:/proxy/
curl 10.0.0.1:8001/apis/batch/v1
3 kubectl客户端
命令行工具kubectl客户端，通过命令行参数转换为对API Server的REST API调用，并将调用结果输出。
命令格式：kubectl [command] [options]
4 编程方式调用
使用场景：
-
运行在Pod里的用户进程调用kubernetes API,通常用来实现分布式集群搭建的目标;
-
开发基于kubernetes的管理平台，比如调用kubernetes API来完成Pod、Service、RC等资源对象的图形化创建和管理界面。可以使用kubernetes提供的Client Library;
具体可参考https://github.com/kubernetes/client-go
API Server作为集群的核心，负责集群各个功能模块之间的通信，集群中的各个功能模块通过 API Server将信息存入etcd数据库中，获取这些数据就通过 API Server 提供的REST接口通过使用GET,LIST,或者Watch方法，从而实现对各个模块之间的交互。
为了缓解各模块对API Server的访问压力，各功能模块都采用缓存机制来缓存数据，各功能模块定时从API Server获取指定的资源对象信息（LIST/WATCH方法），然后将信息保存到本地缓存，功能模块在某些情况下不直接访问API Server，而是通过访问缓存数据来间接访问API Server。
每个Node节点上的kubelet定期就会调用API Server的REST接口报告自身状态，API Server接收这些信息后，将节点状态信息更新到etcd中。kubelet也通过API Server的Watch接口监听Pod信息，从而对Node机器上的POD进行管理。
| 监听信息 |
kubelet动作 |
|---|---|
| 新的POD副本被调度绑定到本节点 |
执行POD对应的容器的创建和启动逻辑 |
| POD对象被删除 |
删除本节点上相应的POD容器 |
| 修改POD信息 |
修改本节点的POD容器 |
1.4.2 API Server与kube-controller-manager交互
kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口，实时监控Node的信息，并做相应处理。
1.4.3 API Server与kube-scheduler交互
Scheduler通过API Server的Watch接口监听到新建Pod副本的信息后，它会检索所有符合该Pod要求的Node列表，开始执行Pod调度逻辑。调度成功后将Pod绑定到目标节点上。
API Server 主要是和 etcd 打交道，并且对外提供 HTTP 服务，以及进行安全控制，因此它的命令行提供的参数也主要和这几个方面有关。下面是一些比较重要的参数以及说明（不同版本参数可能会有不同）：
| 参数 |
描述 |
|---|---|
|
|
向集群成员发布apiserver的IP地址，该地址必须能够被集群的成员访问。如果为空，则使用 --bind-address，如果 --bind-address未指定，那么使用主机的默认接口。 |
|
|
授权模式 ，安全接口上的授权。默认值：AlwaysAllow |
|
|
监听安全端口的IP地址。必须能被集群的其他以及CLI/web客户机访问 |
|
|
包含HTTPS的默认x509证书的文件。 CA证书，如果有的话，在服务器证书之后连接。如果启用了HTTPS服务，但未提供 --tls-cert-file和–tls-private-key-file，则会为公共地址生成自签名证书和密钥，并将其保存到–cert-dir指定的目录中。 |
|
|
TLS 证书的存放目录,默认为/var/run/kubernetes |
|
|
使用该文件在安全端口通过token身份验证来保护API服务 |
|
|
准入控制过程分两个阶段。第一阶段，运行 mutating admission controllers。第二阶段，运行 validating admission controllers。有些控制器会运行两次。如果任一阶段中的任何控制器拒绝请求，则立即拒绝整个请求，并向最终用户返回错误。默认值为 |
|
|
向集群成员发布apiserver的IP地址，该地址必须能够被集群的成员访问。如果为空，则使用 --bind-address，如果 --bind-address未指定，那么使用主机的默认接口。 |
|
|
kubelet通信使用https，默认值 true |
|
|
CIDR表示IP范围，用于分配服务集群IP。不能与分配给pod节点的IP重叠 (default 10.0.0.0/24) |
|
|
true允许特权模式的容器。默认值false |
|
|
HTTP 访问的地址(default 127.0.0.1) |
|
|
HTTP 访问的端口(default 8080) |
|
|
HTTPS 安全接口的监听地址，必须能被集群的其他以及CLI/web客户机访问，默认为0.0.0.0 |
|
|
HTTPS 安全接口的监听端口,默认为6443 |
|
|
要在etcd中所有资源路径之前添加的前缀,默认为“/registry” |
|
|
etcd服务器列表（格式：//ip:port），逗号分隔 |
|
|
日志存放的目录 |
|
|
日志信息同时输出到stderr及文件 |
|
|
日志信息输出到stderr 而不是文件 |
-
安装（可直接下载二进制文件或kube-apiserver镜像）
二进制文件下载如下：$ wget https://storage.googleapis.com/kubernetes-release/release/v1.0.3/bin/linux/amd64/kube-apiserver $ chmod +x kube-apiserver -
运行
API Server 是通过提供的 kube-apiserver 二进制文件直接运行的，下面的例子指定了 service 分配的 ip 范围，etcd 的地址，和对外提供服务的 ip 地址：/usr/bin/kube-apiserver \ --service-cluster-ip-range=10.20.0.1/24 \ --etcd-servers=http://127.0.0.1:2379 \ --advertise-address=192.168.8.100 \ --bind-address=192.168.8.100 \ --insecure-bind-address=192.168.8.100 \ --v=4
直接访问 8080 端口，API Server 会返回它提供了哪些接口：
curl http://192.168.8.100:8080
{
"paths": [
"/api",
"/api/v1",
"/apis",
"/apis/apps",
"/apis/apps/v1alpha1",
"/apis/autoscaling",
"/apis/autoscaling/v1",
"/apis/batch",
"/apis/batch/v1",
"/apis/batch/v2alpha1",
"/apis/extensions",
"/apis/extensions/v1beta1",
"/apis/policy",
"/apis/policy/v1alpha1",
"/apis/rbac.authorization.k8s.io",
"/apis/rbac.authorization.k8s.io/v1alpha1",
"/healthz",
"/healthz/ping",
"/logs/",
"/metrics",
"/swaggerapi/",
"/ui/",
"/version"
]
}
而目前最重要的路径是 /api/v1，里面包含了 kubernetes 所有资源的操作，比如下面的 nodes：
http http://192.168.8.100:8080/api/v1/nodes
HTTP/1.1 200 OK
Content-Length: 112
Content-Type: application/json
Date: Thu, 08 Sep 2016 08:14:45 GMT
{
"apiVersion": "v1",
"items": [],
"kind": "NodeList",
"metadata": {
"resourceVersion": "12",
"selfLink": "/api/v1/nodes"
}
}
API 以 json 的形式返回，会通过 apiVersion 来说明 API 版本号，kind 说明请求的是什么资源。不过这里面的内容是空的，因为目前还没有任何 kubelet 节点接入到我们的 API Server。对应的，pod 也是空的：
http http://192.168.8.100:8080/api/v1/pods
HTTP/1.1 200 OK
Content-Length: 110
Content-Type: application/json
Date: Thu, 08 Sep 2016 08:18:53 GMT
{
"apiVersion": "v1",
"items": [],
"kind": "PodList",
"metadata": {
"resourceVersion": "12",
"selfLink": "/api/v1/pods"
}
}
添加节点也非常简单，启动 kubelet 的时候使用 --api-servers 指定要接入的 API Server 就行。kubelet 启动之后，会把自己注册到指定的 API Server，然后监听 API 对应 pod 的变化，根据 API 中 pod 的实际信息来管理节点上 pod 的生命周期。
我们可以看到，kubelet 收集了很多关于自身节点的信息，这些信息也会不断更新。这些信息里面不仅包含节点的系统信息（系统架构，操作系统版本，内核版本等）、还有镜像信息（节点上有哪些已经下载的 docker 镜像）、资源信息（Memory 和 Disk 的总量和可用量）、以及状态信息（是否正常，可以分配 pod等）。
现在访问 /api/v1/nodes 就能看到已经添加进来的节点：
使用 curl 执行 POST 请求，设置头部内容为 application/json，传过去文件中的 json 值，可以看到应答(其中 status 为 pending，表示以及接收到请求，正在准备处理)：
curl -s -X POST -H "Content-Type: application/json" http://192.168.8.100:8080/api/v1/namespaces/default/pods --data @nginx_pod.json
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "nginx-server",
"namespace": "default",
"selfLink": "/api/v1/namespaces/default/pods/nginx-server",
"uid": "888e95d0-75a9-11e6-b463-080027c09e5b",
"resourceVersion": "573",
"creationTimestamp": "2016-09-08T09:49:28Z"
},
"spec": {
"volumes": [
{
"name": "nginx-logs",
"emptyDir": {}
}
],
"containers": [
{
"name": "nginx-server",
"image": "172.16.1.41:5000/nginx",
"ports": [
{
"containerPort": 80,
"protocol": "TCP"
}
],
"resources": {},
"volumeMounts": [
{
"name": "nginx-logs",
"mountPath": "/var/log/nginx"
}
],
"terminationMessagePath": "/dev/termination-log",
"imagePullPolicy": "Always"
}
],
"restartPolicy": "Always",
"terminationGracePeriodSeconds": 30,
"dnsPolicy": "ClusterFirst",
"nodeName": "192.168.8.100",
"securityContext": {}
},
"status": {
"phase": "Pending"
}
}
返回中包含了我们提交 pod 的信息，并且添加了 status、metadata 等额外信息。
一段时间去查询 pod，就可以看到 pod 的状态已经更新了：
http http://192.168.8.100:8080/api/v1/namespaces/default/pods
HTTP/1.1 200 OK
Content-Type: application/json
Date: Thu, 08 Sep 2016 09:51:29 GMT
Transfer-Encoding: chunked
{
"apiVersion": "v1",
"items": [
{
"metadata": {
"creationTimestamp": "2016-09-08T09:49:28Z",
"name": "nginx-server",
"namespace": "default",
"resourceVersion": "592",
"selfLink": "/api/v1/namespaces/default/pods/nginx-server",
"uid": "888e95d0-75a9-11e6-b463-080027c09e5b"
},
"spec": {
"containers": [
{
"image": "172.16.1.41:5000/nginx",
"imagePullPolicy": "Always",
"name": "nginx-server",
"ports": [
{
"containerPort": 80,
"protocol": "TCP"
}
],
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"volumeMounts": [
{
"mountPath": "/var/log/nginx",
"name": "nginx-logs"
}
]
},
{
"args": [
"-c",
"tail -f /logdir/access.log"
],
"command": [
"bin/sh"
],
"image": "172.16.1.41:5000/busybox",
"imagePullPolicy": "Always",
"name": "log-output",
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"volumeMounts": [
{
"mountPath": "/logdir",
"name": "nginx-logs"
}
]
}
],
"dnsPolicy": "ClusterFirst",
"nodeName": "192.168.8.100",
"restartPolicy": "Always",
"securityContext": {},
"terminationGracePeriodSeconds": 30,
"volumes": [
{
"emptyDir": {},
"name": "nginx-logs"
}
]
},
"status": {
"conditions": [
{
"lastProbeTime": null,
"lastTransitionTime": "2016-09-08T09:49:28Z",
"status": "True",
"type": "Initialized"
},
{
"lastProbeTime": null,
"lastTransitionTime": "2016-09-08T09:49:44Z",
"status": "True",
"type": "Ready"
},
{
"lastProbeTime": null,
"lastTransitionTime": "2016-09-08T09:49:44Z",
"status": "True",
"type": "PodScheduled"
}
],
"containerStatuses": [
{
"containerID": "docker://8b79eeea60f27b6d3f0a19cbd1b3ee3f83709bcf56574a6e1124c69a6376972d",
"image": "172.16.1.41:5000/busybox",
"imageID": "docker://sha256:8c566faa3abdaebc33d40c1b5e566374c975d17754c69370f78c00c162c1e075",
"lastState": {},
"name": "log-output",
"ready": true,
"restartCount": 0,
"state": {
"running": {
"startedAt": "2016-09-08T09:49:43Z"
}
}
},
{
"containerID": "docker://96e64cdba7b05d4e30710a20e958ff5b8f1f359c8d16d32622b36f0df0cb353c",
"image": "172.16.1.41:5000/nginx",
"imageID": "docker://sha256:51d764c1fd358ce81fd0e728436bd0175ff1f3fd85fc5d1a2f9ba3e7dc6bbaf6",
"lastState": {},
"name": "nginx-server",
"ready": true,
"restartCount": 0,
"state": {
"running": {
"startedAt": "2016-09-08T09:49:36Z"
}
}
}
],
"hostIP": "192.168.8.100",
"phase": "Running",
"podIP": "172.17.0.2",
"startTime": "2016-09-08T09:49:28Z"
}
}
],
"kind": "PodList",
"metadata": {
"resourceVersion": "602",
"selfLink": "/api/v1/namespaces/default/pods"
}
}
可以看到 pod 已经在运行，并且给分配了 ip：172.17.0.2，通过 curl 也可以访问它的服务：
curl -s http://172.17.0.2 | head -n 5
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on Debian!</title>
<style>
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]https://blog.csdn.net/zhonglinzhang/article/details/90697495.
[参考文档]https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/.
[参考文档]https://blog.csdn.net/weixin_30773135/article/details/97820572.
七、kubernetes核心组件之scheduler详解
scheduler是kubernetes的调度器，主要任务是把定义的pod分配到集群的节点上，其在调度时需要考虑一下问题：
-
公平：如何保证每个节点都能被分配资源；
-
资源高效利用：集群所有资源最大化被使用；
-
效率：调度的性能要好，能够尽快的对大批量的pod完成调度工作；
-
灵活：允许用户根据自己的需求控制调度的逻辑；
kubernetes scheduler 作为一个单独的进程部署在 master 节点上，它会 watch kube-apiserver 进程去发现 PodSpec.NodeName 为空的 Pod，然后根据指定的算法将 Pod 调度到合适的 Node 上,这一过程也叫绑定(Bind)。scheduler 的输入是需要被调度的 Pod 和 Node 的信息，输出是经过调度算法筛选出条件最优的 Node，并将该 Pod 绑定到这个 Node 上。Scheduler结构图如下所示：
通过上图我们可以看到，调度器实际上主要是由两个控制循环来完成对pod，service等的调度的。
-
Informer Path
第一个循环Informer Path中，调度器通过一系列的informer来对pod，node，service等信息进行list and watch。当对应资源（比如pod）有改变时，informer会收到来自api server的变化通知，然后informer会将资源的变动信息更新到调度器缓存中用于后续调度算法的判定依据（这里使用cache的好处就是避免了对api server的大量重复的请求操作，特别是后面的调度算法判定阶段，从而提升调度效率）。
如果有新增的资源，比如有个新的pod，那么informer会将其添加到调度队列中。这里的调度队列是一个优先级的队列，它在保证FIFO的基本功能的同时，还能满足调度器的一些特殊操作，比如基于优先级的抢占操作。 -
Scheduling Path
在Scheduling Path中，调度器会从调度队列里不断取出需要调度的资源，然后通过Predicates算法对Scheduler Cache中的Nodes进行过滤，拿到合适的Node列表。然后根据Priorities算法对第一步的Node列表进行打分，选出得分最高的Node。
经过Priorities后，修改资源的nodeName字段为选出的Node，并更新Scheduler Cache中pod和node的信息，然后启动一个异步的线程去请求api server去修改持久化的pod信息。这样做的好处是提高了调度器的调度效率。如果异步线程失败了也无所谓，cache中的信息会随着后续的更新而恢复正常，调度失败的资源会在后续进行重新调度。当然这种基于乐观绑定的设计，就需要kubelet在实际运行资源的时候再次通过基本的调度算法进行确认看当前pod是否能够在当前node运行。同时为了进一步提升调度的效率，调度器对Predicates和Priorities过程都是启动多个线程来并发地对多个资源进行判定，同时在Priorities的阶段以MapReduce的方式来进行打分。整个过程只有在资源出队和更新cache的时候会加锁，从而保证了调度器的执行效率。
请求及Scheduler调度步骤：
-
预选：根据配置的Predicates Policies（默认为DefaultProvider中定义的default predicates policies集合）过滤掉那些不满足这些Policies的的Nodes，剩下的Nodes就作为优选的输入；
-
优选：根据配置的Priorities Policies（默认为DefaultProvider中定义的default priorities policies集合）给预选后的Nodes进行打分排名；
-
选定：根据Priorities得分最高的Node即作为最适合的Node，该Pod就Bind到这个Node；
Scheduler 调度部分流程讲解如下：
-
首先用户通过 Kubernetes 客户端 Kubectl 提交创建 Pod 的 Yaml 的文件，向Kubernetes 系统发起创建 Pod 的资源请求;
-
命令行工具 Kubectl 向 Kubernetes 集群即 APIServer 用 的方式发送“POST”请求，即创建 Pod 的请求;
-
APIServer 接收到请求后把创建 Pod 的信息存储到 Etcd 中;
-
从集群运行那一刻起，资源调度系统 Scheduler 采用 watch 机制就会定时去监控 APIServer获取 Pod 的信息，Scheduler发现 Pod 的属性中 Dest Node 为空时（Dest Node=””）便会立即触发调度流程进行调度;
-
而这一个创建Pod对象，在调度的过程当中有3个阶段：节点预选、节点优选、节点选定，从而筛选出最佳的节点。当最佳节点多于1个时，则进行随机选择；
Priorities算法实现：
对每一个 Node, priority functions 会计算出一个 0-10 之间的数字，表示 Pod 放到该 Node 的合适程度，其中 10 表示非常合适，0 表示不合适，priority functions 集合中的每一个函数都有一个权重 (weight)，最终的值为 weight 和 priority functions 的乘积，而一个节点的 weight 就是所有 priority functions 结果的加和。
例如，有两个 priority functions: priorityFunc1 和 priorityFunc2，对应的 weight 分别为 weight1 和 weight2，那么 NodeA 的最终得分是:
例如有三个node，其调度流程如下图所示：
scheduler 调度策略主要分为两部分Predicates（预选策略）和Priorites（优选策略）。
-
预选策略，Predicates是强制性规则，遍历所有的Node节点，按照具体的预选策略筛选出符合要求的Node列表，如没有Node符合Predicates策略规则，那该Pod就会被挂起，直到有Node能够满足；
-
优选策略，在第一步筛选的基础上，按照优选策略为待选Node打分排序，获取最优者。
一般情况下，使用kube-scheduler的默认调度就能满足大部分需求。kubernetes的调度器是以插件化的形式实现的，方便用户对调度的定制与二次开发。因此用户也可以自定义预选和优选策略。
Predicates其实就相当于一个的filter chain，对当前所有的node list进行过滤，最后得到符合调度条件的node list。
随着版本的演进Kubernetes支持的Predicates策略逐渐丰富，v1.0版本仅支持4个策略，v1.7支持15个策略。目前可用的Predicates策略有：
-
一般策略
这一组 filter是最基础的filter，主要判断对应的node是否满足pod的运行条件。
| 策略 |
描述 |
|---|---|
| PodFitsResources |
用于判断当前node的资源是否满足pod的request的资源条件 |
| PodFitsHost |
用于判断当前node的名字是否满足pod所指定的nodeName |
| PodFitsHostPorts |
Pod对象拥有spec.hostPort属性时,用于判断当前node可用的端口是否满足pod所要求的端口占用 |
| PodMatchNodeSelector |
用于判断当前node是否匹配pod所定义的nodeSelector或者nodeAffinity |
PS: 此外还有个PodFitsPorts策略（计划停用），由PodFitsHostPorts替代
-
Volume相关策略
| 策略 |
描述 |
|---|---|
| NoDiskConflict |
用于判断多个pod所声明的volume是否有冲突， |
| MaxPDVolumeCountPredicate |
用于判断某种volume是否已经超过所指定的数目 |
| VolumeBindingPredicate |
用于检查pod所定义的volume的nodeAffinity是否与node的标签所匹配 |
| NoVolumeZoneConflict |
检查给定的zone限制前提下，检查如果在此主机上部署Pod是否存在卷冲突 |
| NoVolumeNodeConflict |
检查给定的Node限制前提下，检查如果在此主机上部署Pod是否存在卷冲突 |
| MaxEBSVolumeCount |
确保已挂载的EBS存储卷不超过设置的最大值，默认39 |
| MaxGCEPDVolumeCount |
确保已挂载的GCE存储卷不超过设置的最大值，默认16 |
| MaxAzureDiskVolumeCount |
确保已挂载的Azure存储卷不超过设置的最大值，默认16 |
| CheckVolumeBinding |
检查节点上已绑定和未绑定的PVC是否满足需求 |
-
Node相关策略
| 策略 |
描述 |
|---|---|
| MatchNodeSelector |
Pod对象拥有spec.nodeSelector属性时，检查Node节点的label定义是否满足Pod的NodeSelector属性需求 |
| HostName |
如果Pod对象拥有spec.hostname属性，则检查节点名称是不是Pod指定的NodeName |
| PodToleratesNodeTaints |
Pod对象拥有spec.tolerations属性时，仅关注NoSchedule和NoExecute两个效用标识的污点 |
| PodToleratesNodeNoExecuteTaints |
Pod对象拥有spec.tolerations属性时，，是否能接纳节点的NoExecute类型污点, |
| CheckNodeLabelPresence |
仅检查节点上指定的所有标签的存在性, |
| CheckServiceAffinity |
将相同Service的Pod对象放置在同一个或同一类节点上以提高效率, |
| NodeMemoryPressurePredicate |
检查当前node的内存是否充足，只有充足的时候才会调度到该node |
| CheckNodeMemoryPressure |
检查节点内存压力，如果压力过大，那就不会将pod调度至此 |
| CheckNodeDiskPressure |
检查节点磁盘资源压力，如果压力过大，那就不会将pod调度至此 |
| GeneralPredicates |
检查pod与主机上kubernetes相关组件是否匹配 |
| CheckNodeCondition |
检查是否可以在节点报告磁盘、网络不可用或未准备好时将Pod调度其上 |
-
Pod相关策略
| 策略 |
描述 |
|---|---|
| PodAffinityPredicate |
用于检查pod和该node上的pod是否和affinity以及anti-affinity规则匹配 |
| MatchInterPodAffinity |
检查节点是否满足Pod对象亲和性或反亲和性条件 |
而针对于这么多规则，调度器在面对一个待调度的pod的时候会同时启动很多个线程来并发地计算所有node是否满足所有的条件，最后将满足条件的node list 返回。当然对于条件计算是有一定顺序的，通常跟node相关的规则会先计算，这样就可以避免一些没有必要的规则校验，比如在一个内存严重不足的node上面计算pod的affinity是没有意义的。
当调度器通过Predicates拿到可调度的node list之后，我们则需要通过进一步地对比得到最适合调度的node。
kubernetes用一组优先级函数处理每一个待选的主机。每一个优先级函数会返回一个0-10的分数，分数越高表示主机越“好”，同时每一个函数也会对应一个表示权重的值。最终主机的得分用以下公式计算得出：
finalScoreNode = (weight1 * priorityFunc1) + (weight2 * priorityFunc2) + … + (weightn * priorityFuncn)
同样，Priorites策略也在随着版本演进而丰富，v1.0版本仅支持3个策略，v1.7支持10个策略，每项策略都有对应权重，最终根据权重计算节点总分。目前可用的Priorites策略有：
| 策略 |
描述 |
|---|---|
| SelectorSpreadPriority |
对于属于同一个service、replication controller的Pod，尽量分散在不同的主机上。如果指定了区域，则会尽量把Pod分散在不同区域的不同主机上。调度一个Pod的时候，先查找Pod对于的service或者replication controller，然后查找service或replication controller中已存在的Pod，主机上运行的已存在的Pod越少，主机的打分越高。 |
| LeastRequestedPriority |
如果新的pod要分配给一个节点，这个节点的优先级就由节点空闲的那部分与总容量的比值（即（总容量-节点上pod的容量总和-新pod的容量）/总容量）来决定。CPU和memory权重相当，比值最大的节点的得分最高。需要注意的是，这个优先级函数起到了按照资源消耗来跨节点分配pods的作用。计算公式如下： |
| BalancedResourceAllocation |
尽量选择在部署Pod后各项资源更均衡的机器。BalancedResourceAllocation不能单独使用，而且必须和LeastRequestedPriority同时使用，它分别计算主机上的cpu和memory的比重，主机的分值由cpu比重和memory比重的“距离”决定。计算公式如下： |
| NodeAffinityPriority |
节点亲和性选择策略。Node Selectors（调度时将pod限定在指定节点上），支持多种操作符 |
| InterPodAffinityPriority |
pod亲和性选择策略,类似NodeAffinityPriority，提供两种选择器支持。有两个子策略podAffinity和podAntiAffinity |
| NodePreferAvoidPodsPriority(权重1W) |
判断alpha.kubernetes.io/preferAvoidPods属性，设置权重为10000，覆盖其他策略 |
| TaintTolerationPriority |
使用Pod中tolerationList与Node节点Taint进行匹配，配对成功的项越多，则得分越低。 |
| ImageLocalityPriority |
根据主机上是否已具备Pod运行的环境来打分，得分计算：不存在所需镜像，返回0分，存在镜像，镜像越大得分越高。 |
| EqualPriority |
EqualPriority是一个优先级函数，它给予所有节点相等的权重（优先级） |
| ServiceSpreadingPriority |
按Service和Replicaset归属计算Node上分布最少的同类Pod数量，得分计算：数量越少得分越高（ |
| MostRequestedPriority |
在ClusterAutoscalerProvider中，替换LeastRequestedPriority，给使用多资源的节点，更高的优先级。计算公式为： |
Kubernetes scheduler 里的一个重要机制，即：优先级（Priority ）和抢占（Preemption）机制。从 v1.8 开始，kube-scheduler 支持定义 Pod 的优先级，从而保证高优先级的 Pod 优先调度。v1.8 -v1.10默认不开启，从 v1.11 开始默认开启。
-
优先级（Priority ）：Pod对象的重要程度，会影响节点上Pod的调度顺序和驱逐次序；
-
抢占（Preemption）机制：一个Pod对象无法被调度时，调度器会尝试抢占(驱逐)较低优先级的Pod对象，以便可以调度当前Pod；
这里所讲的优先级（Priority ）与调度优选策略中的优先级（Priorities）不同，前面所讲的优先级指的是节点优先级，而我们这里所说的优先级 pod priority 指的是 Pod 的优先级，高优先级的 Pod 会优先被调度，或者在资源不足低情况牺牲低优先级的 Pod，以便于重要的 Pod 能够得到资源部署。
在 Kubernetes 里，优先级和抢占机制是在 Kubernetes 1.8 及其以后的版本才逐步可用的。
注： 抢占不遵循 PodDisruptionBudget；
对于普通的pod，在调度失败之后，其调度任务会被pending，直到该pod被更新或者集群的状态发生变化，调度器才会对这个 Pod 进行重新调度。
但在有时候，我们希望的是这样一个场景。当一个高优先级的 Pod 调度失败后，该 Pod 并不会被“搁置”，而是会“挤走”某个 Node 上的一些低优先级的 Pod 。这样就可以保证这个高优先级 Pod 的调度成功。这个特性，其实也是一直以来就存在于 Borg 以及 Mesos 等项目里的一个基本功能。
优先级和抢占机制，解决的是 Pod 调度失败时该怎么办的问题。当 Pod 无法被调度时，scheduler 会尝试抢占（驱逐）低优先级的 Pod，使得这些挂起的 pod 可以被调度。
-
启用优先级和抢占功能：
在 v1.8-v1.10 版本中的开启方法为(从 v1.11 开始默认开启)：<span style="color:#000000"><code>apiserver 配置: --feature-gates=PodPriority=true --runtime-config=scheduling.k8s.io/v1alpha1=true kube-scheduler 配置: --feature-gates=PodPriority=true </code></span>如果需要关闭优先级和抢占，则可把 PodPriority 这个命令行标识从启动参数中移除，或者将它的值设置为false，然后再重启 API server 和 scheduler。功能关闭后，原来的 Pod 会保留它们的优先级字段，但是优先级字段的内容会被忽略，抢占不会生效，在新的 pod 创建时，您也不能设置 PriorityClassName。
-
创建优先级类别（PriorityClass）：
创建一个不受命名空间约束的PriorityClass对象，它定义了优先级类名跟优先级整数值的映射；
yaml格式如下：<span style="color:#000000"><code> apiVersion: v1 kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false description: "This priority class should be used for XYZ service pods only." </code></span>注意：PriorityClass是非namespace隔离的，是global的。因此metadata下面是不能设置namespace field的。
-
使用优先级和抢占功能：
在创建PriorityClass 之后，您在创建 Pod 时就能在模板文件中指定需要使用的 PriorityClass 的名称。优先级准入控制器通过 priorityClassName 字段查找优先级数值并且填入 Pod 中。如果没有找到相应的 PriorityClass，Pod 将会被拒绝创建。
yaml格式如下：<span style="color:#000000"><code> apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent priorityClassName: high-priority </code></span>
PriorityClass 是一个不受命名空间约束的对象，它定义了优先级类名跟优先级整数值的映射。它的名称通过 PriorityClass 对象 metadata 中的 name 字段指定。值在必选的 value 字段中指定。值越大，优先级越高。
PriorityClass 对象的值可以是小于或者等于 10 亿的 32 位任意整数值。更大的数值被保留给那些通常不应该取代或者驱逐的关键的系统级 Pod 使用。集群管理员应该为它们想要的每个此类映射创建一个 PriorityClass 对象。
PriorityClass 还有两个可选的字段：globalDefault 和 description。globalDefault 表示 PriorityClass 的值应该给那些没有设置 PriorityClassName 的 Pod 使用。整个系统只能存在一个 globalDefault 设置为 true 的 PriorityClass。如果没有任何 globalDefault 为 true 的 PriorityClass 存在，那么，那些没有设置 PriorityClassName 的 Pod 的优先级将为 0。
description 字段的值可以是任意的字符串。它向所有集群用户描述应该在什么时候使用这个 PriorityClass。
注1：如果您升级已经存在的集群环境，并且启用了该功能，那么，那些已经存在系统里面的 Pod 的优先级将会设置为 0。
注2：此外，将一个 PriorityClass 的 globalDefault 设置为 true，不会改变系统中已经存在的 Pod 的优先级。也就是说，PriorityClass 的值只能用于在 PriorityClass 添加之后创建的那些 Pod 当中。
注3：如果您删除一个 PriorityClass，那些使用了该 PriorityClass 的 Pod 将会保持不变，但是，该 PriorityClass 的名称不能在新创建的 Pod 里面使用。
PriorityClass 示例：
有了一个或者多个 PriorityClass 之后，您在创建 Pod 时就能在模板文件中指定需要使用的 PriorityClass 的名称。优先级准入控制器通过 priorityClassName 字段查找优先级数值并且填入 Pod 中。如果没有找到相应的 PriorityClass，Pod 将会被拒绝创建。
下面的 YAML 是一个使用了前面创建的 PriorityClass 对 Pod 进行配置的示例。优先级准入控制器会检测配置文件，并将该 Pod 的优先级解析为 1000000。
<span style="color:#000000"><code>apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
priorityClassName: high-priority
</code></span>Pod 生成后，会进入一个队列等待调度。scheduler 从队列中选择一个 Pod，然后尝试将其调度到某个节点上。如果没有任何节点能够满足 Pod 指定的所有要求，对于这个挂起的 Pod，抢占逻辑就会被触发。当前假设我们把挂起的 Pod 称之为 P。抢占逻辑会尝试查找一个节点，在该节点上移除一个或多个比 P 优先级低的 Pod 后， P 能够调度到这个节点上。如果节点找到了，部分优先级低的 Pod 就会从该节点删除。Pod 消失后，P 就能被调度到这个节点上了。
-
抢占算法（genericScheduler.Preempt）
意义：
选择一个最合适的node用于抢占；
概念：
-
preemptor：发起抢占的pod称为preemptor(抢占者)。
-
victim：如果preemptor在某个node上发起抢占，则该node上被删除的pod称为victim(牺牲者)。
-
nominate：如果preemptor确定要在一个node上发起抢占，则preemptor先被“提名”。
-
nomianted node：preemptor发起抢占所在的node称为“提名node”。
流程：
-
判断pod是否有资格执行抢占（podEligibleToPreemptOthers）：如果pod.status.nominatedNodeName被设置了，并且nominated node上存在正在终止的pod且优先级更低，说明抢占行为正在进行中，那么preemptor(抢占者)不应该再执行抢占，则这次抢占失败。
-
选出可以调度的潜在的node（nodesWherePreemptionMightHelp）：针对所有node，如果node (a) 没有predicate failed，或者(b) 有某种类型的predicate failed但仍然可以抢占，则该node是一个潜在的node。
-
针对潜在node，选择victim pod（selectNodesForPreemption）：以node为粒度，16个goroutine并发处理，对每个node处理流程如下(这是一个模拟过程，node上的pod被“删除”和“释放”的操作都是在该node的副本上执行的)：
(a) . 将当前node上的比preemptor(抢占者)优先级低的pod按优先级从高到低排序；同时也将这些低优先级pod从当前node上删除，这些pod就是候选的victim(牺牲者)。
(b). 检查preemptor(抢占者)是否可以调度到当前node上，如果不能，则当前node不适合抢占，直接返回。
(c). 根据victim(牺牲者)的PDB是否被违反，将victim(牺牲者)划分为两组。每组中的pod顺序依然是按优先级从高到低。
(d). 依次释放“PDB被违反的victim(牺牲者)”和“PDB没有被违反的victim(牺牲者)”，每组的释放顺序仍然是按优先级从高到低。每释放一个victim(牺牲者)就判断preemptor(抢占者)能否调度到当前node上，如果能调度，则这个victim(牺牲者)就可以真正释放；如果不能调度，则这个victim(牺牲者)就必须被真正删除，它们是真正的victim(牺牲者)。
总体来说，这是一个“抓大放小”的过程：先从node上删除一批“候选victim(牺牲者)”，再依次把victim(牺牲者)释放回node上，一边释放一边判断preemptor(抢占者)是否依然能调度到node上，直到获取到一个最小的“不可释放的victim(牺牲者)集合”。
至此，所有可调度的node及每个node对应的 (a) victim， 和(b) “PDB违反数量” 就收集到了。每个node对应的victim列表，仍然是按优先级从高到低，列表中第1个victim的优先级最高，这一点后面会用到。
-
用extenders做一次处理，将node与victim再作一次筛选(processPreemptionWithExtenders)。
-
挑选一个最合适的node用于抢占，这个node就是nominated node（pickOneNodeForPreemption）：依次检查以下规则，如果某个规则的条件满足则返回那个node，后面的规则不再检查。如果满足规则(b)©(d)(e)条件的node有多个，则认为未找到最合适的node，那么继续检查下一个规则。
(a) 没有victim的node：有任意一个这样的node存在即可。
(b)“PDB违反数量”最少的node。
(c)“最高优先级”最小的node：针对每个node，求它的所有victim的最高的优先级，取“最高优先级”最小的node。
(d)“优先级之和”最小的node：针对每个node，求它的所有victim的优先级之和，取该和最小的node。
(e)“victim数量”最少的node。
(f) 第一个node。
-
获取nominated node上的比preemptor的优先级更低的nominated pod,即“已经被提名的pod”（getLowerPriorityNominatedPods）：从schedulingQueue里获取。这些nominated pod原本是要在这个node上发起抢占的，但是由于preemptor比它们优先级更高，所以它们只能让preemptor先抢占。针对这些nominated pod的后续操作就是清除nominated状态。
最后，算法返回：
-
nominated node
-
nominated node上的victim
-
nominated node上的对应的需要被清除“提名”状态的pod
-
判断pod是否可调度到一个node上（podFitsOnNode）
执行完抢占算法之后，preemptor(抢占者)进入调度队列，将在下一个调度周期重新调度。但调度器并不保证preemptor(抢占者)一定会被调度到nominated node上，而是按正常的调度流程执行。在判断一个待调度pod是否能调度到某个node上时，会考虑该node上是否已经存在“nominated pod”，如果存在，将影响待调度pod的调度结果，具体如下：
执行两次predicates算法检查，对应的场景分别是：
场景1：
node上有“nominated pod”。在这些nominated pod中，把比待调度pod的优先级更高或相等的pod加到node上，运行一遍predicates算法。
这一步的意义在于，由于nominated pod的加入，可能失败的predicates是：
(a). 与resource有关的predicates；
(b). pod anti-affinity的predicates；
如果node上有“nominated pod”并且检查成功了，则还要进行第2次检查。
场景2：
node上没有“nominated pod”。这一步的意义在于，调度器并不保证nominated pod一定会调度到该node上，所以在没有nominated pod存在时，当前待调度的pod是有可能调度失败的，因为可能违反pod affinity predicates。
这两次检查的结果可能是：
场景1存在且检查失败 => 返回失败
场景1不存在，场景2检查失败 => 返回失败
场景1存在且检查成功，场景2检查失败 => 返回失败
场景1不存在，场景2检查成功 => 返回成功
场景1存在且检查成功，场景2检查成功 =>返回成功
假定节点 N 启用了抢占功能，以便我们能够把挂起的 Pod P 调度到节点 N 上。只有其它节点的 Pod 被抢占时，P 才有可能被调度到节点 N 上面。下面是一个示例：
-
Pod P 正在考虑节点 N;
-
Pod Q 正运行在跟节点 N 同区的另外一个节点上;
-
Pod P 跟 Pod Q 之间有反亲和性;
-
在这个区域内没有跟 Pod P 具备反亲和性的其它 Pod;
-
为了将 Pod P 调度到节点 N 上，Pod Q 需要被抢占掉，但是 scheduler 不能执行跨节点的抢占。因此，节点 N 将被视为不可调度节点。
如果将 Pod Q 从它的节点移除，反亲和性随之消失，那么 Pod P 就有可能被调度到节点 N 上。
Usage: kube-scheduler [flags]
| 参数 |
描述 |
|---|---|
| --add-dir-header |
如果为 true，则将文件目录添加到标题中 |
| --address string |
监听主机IP地址，默认为0.0.0.0监听主机所有主机接口（弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 请参阅 --bind-address） |
| --algorithm-provider string |
弃用：设置调度算法，ClusterAutoscalerProvider | DefaultProvider，默认为DefaultProvider |
| --alsologtostderr |
设置true则日志输出到stderr，也输出到日志文件 |
| --authentication-kubeconfig string |
指向“核心”kubernetes服务器的kubeconfig文件，具有足够的权限创建tokenaccessreviews. authentic.k8s.io。这是可选的。如果为空，则认为所有令牌请求都是匿名的，在集群中不查找客户端CA。 |
| --authentication-skip-lookup |
如果为 false，则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。 |
| --authentication-token-webhook-cache-ttl duration |
缓存来自 Webhook 令牌身份验证器的响应的持续时间，默认: 10s |
| --authentication-tolerate-lookup-failure |
如果为 true，则无法从集群中查找缺少的身份验证配置是致命的。请注意，这可能导致身份验证将所有请求视为匿名。默认: true |
| --authorization-always-allow-paths stringSlice |
默认: [/healthz]。在授权过程中跳过的 HTTP 路径列表，即在不联系 ‘core’ kubernetes 服务器的情况下被授权的 HTTP 路径。 |
| --authorization-kubeconfig string |
指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的 ‘core’ kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则禁止所有未经授权跳过的请求。 |
| --authorization-webhook-cache-authorized-ttl duration |
缓存来自 Webhook 授权者的 ‘authorized’ 响应的持续时间。默认: 10s |
| --authorization-webhook-cache-unauthorized-ttl duration |
缓存来自 Webhook 授权者的 ‘unauthorized’ 响应的持续时间。默认: 10s |
| --azure-container-registry-config string |
包含 Azure 容器仓库配置信息的文件的路径。 |
| --bind-address ip |
默认: 0.0.0.0。侦听 --secure-port 端口的 IP 地址。集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。如果为空，将使用所有接口（所有 IPv4 接口使用 0.0.0.0，所有 IPv6 接口使用 ::）。 |
| --cert-dir string |
TLS 证书所在的目录。如果提供了–tls-cert-file 和 --tls private-key-file，则将忽略此参数。 |
| --client-ca-file string |
如果已设置，由 client-ca-file 中的授权机构签名的客户端证书的任何请求都将使用与客户端证书的 CommonName 对应的身份进行身份验证。 |
| --config string |
配置文件的路径 |
| --contention-profiling |
弃用: 如果启用了性能分析，则启用锁竞争分析 |
| --feature-gates mapStringBool |
一组 key=value 对，描述了 alpha/experimental 特征开关 |
| --hard-pod-affinity-symmetric-weight int32 |
弃用: RequiredDuringScheduling 亲和力不是对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling 关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 |
| -h, --help |
kube-scheduler 帮助命令 |
| --http2-max-streams-per-connection int |
服务器为客户端提供的 HTTP/2 连接最大限制。零表示使用 golang 的默认值。 |
| --kube-api-burst int32 |
弃用: 发送到kube-apiserver每秒请求量 （default 100） |
| --kube-api-content-type string |
弃用: 发送到kube-apiserver请求内容类型（默认 “application/vnd.kubernetes.protobuf”） |
| --kube-api-qps float32 |
弃用: 与kube-apiserver通信的qps（default 50） |
| --kubeconfig string |
弃用: kubeconfig配置文件路径，该文件包括master认证以及master信息 |
| --leader-elect |
多个master情况设置为true保证高可用，进行leader选举。默认: true |
| --leader-elect-lease-duration duration |
当leader-elect设置为true生效，选举过程中非leader候选等待选举的时间间隔（默认15s） |
| --leader-elect-renew-deadline duration |
leader选举过程中在停止leading，再次renew时间间隔，小于或者等于leader-elect-lease-duration duration，也是leader-elect设置为true生效（默认10s） |
| --leader-elect-resource-lock endpoints |
领导者选举期间用于锁定的资源对象的类型，支持的选项是 endpoints (默认) 和configmaps |
| --leader-elect-resource-namespace string |
在领导者选举期间用于锁定的资源对象的命名空间。默认kube-system |
| --leader-elect-retry-period duration |
当leader-elect设置为true生效，获取leader或者重新选举的等待间隔（默认 2s） |
| --lock-object-name string |
弃用:定义lock对象名字（默认"kube-scheduler"） |
| --lock-object-namespace string |
弃用: 定义lock对象的namespace（默认"kube-system"） |
| --log-backtrace-at traceLocation |
记录日志到file:行号时打印一次stack trace（默认0） |
| --log-dir string |
如果为非空，则在此目录中写入日志文件 |
| --log-file string |
如果为非空，请使用此日志文件 |
| --log-file-max-size uint |
定义日志文件可以增长到的最大值。单位为兆字节。如果值为0，则最大文件大小为无限制。默认1800 |
| 参数 |
描述 |
| 参数 |
描述 |
| --log-flush-frequency duration |
两次日志刷新之间的最大秒数（默认5s） |
| --logtostderr |
写log到stderr（默认 true） |
| --master string |
Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值） |
| --policy-config-file string |
弃用：具有调度程序策略配置的文件。如果未提供 policy ConfigMap 或 --use-legacy-policy-config = true，则使用此文件 |
| --policy-configmap string |
弃用: 包含调度程序策略配置的 ConfigMap 对象的名称。如果 --use-legacy-policy-config = false，则它必须在调度程序初始化之前存在于系统命名空间中。必须将配置作为键为 ‘policy.cfg’ 的 ‘Data’ 映射中元素的值提供 |
| --policy-configmap-namespace string |
弃用: 策略 ConfigMap 所在的命名空间。如果未提供或为空，则将使用 kube-system 命名空间。默认: “kube-system” |
| --port int |
弃用: 没有认证鉴权的不安全端口（默认10251） |
| --profiling |
弃用: 开启性能分析，通过host:port/debug/pprof/查看 |
| --requestheader-allowed-names stringSlice |
客户端证书通用名称列表允许在 --requestheader-username-headers 指定的头部中提供用户名。如果为空，则允许任何由权威机构 --requestheader-client-ca-file 验证的客户端证书。 |
| --requestheader-client-ca-file string |
在信任 --requestheader-username-headers 指定的头部中的用户名之前用于验证传入请求上的客户端证书的根证书包。警告：通常不依赖于传入请求已经完成的授权。 |
| --requestheader-extra-headers-prefix stringSlice |
默认: [x-remote-extra-]。要检查请求头部前缀列表。建议使用 X-Remote-Extra- |
| --requestheader-group-headers stringSlice |
用于检查组的请求头部列表。建议使用 X-Remote-Group。默认: [x-remote-group] |
| --requestheader-username-headers stringSlice |
用于检查用户名的请求头部列表。 X-Remote-User 很常见。默认: [x-remote-user] |
| --scheduler-name string |
弃用: 调度器名，由于哪些pod被调度器进行处理，根据pod的spec.schedulerName（默认"default-scheduler"） |
| --secure-port int |
通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。默认: 10259 |
| --skip-headers |
如果为 true，请在日志消息中避免头部前缀 |
| --skip-log-headers |
如果为true，则在打开日志文件时避免头部 |
| --stderrthreshold severity |
达到或超过此阈值的日志转到 stderr（ 默认: 2） |
| --tls-cert-file string |
包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 |
| --tls-cipher-suites stringSlice |
服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。 |
| --tls-min-version string |
支持的最低 TLS 版本。可能的值：VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 |
| --tls-private-key-file string |
包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。 |
| --tls-sni-cert-key namedCertKey |
默认: []。一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表，并可能带有前缀的通配符段。如果未提供域模式，则获取证书名称。非通配符匹配胜过通配符匹配，显式域模式胜过获取名称。 对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。例如: “example.crt,example.key” 或者 “foo.crt,foo.key:*.foo.com,foo.com”。 |
| --use-legacy-policy-config |
弃用: 设置为 true 时，调度程序将忽略策略 ConfigMap 并使用策略配置文件 |
| -v, --v Level |
日志级别详细程度的数字 |
| --version version[=true] |
打印版本信息并退出 |
| --vmodule moduleSpec |
以逗号分隔的 pattern = N 设置列表，用于文件过滤的日志记录 |
| --write-config-to string |
如果已设置，请将配置值写入此文件并退出。 |
注意：以下kube-schedule安装部署是在k8s的etcd、apiserver组件已部署后的前提下部署验证的；否则单独部署的话，服务启动成功后，服务日志信息会提示dial tcp 127.0.0.1:8080: connect: connection refused等连接拒绝之类的信息，这个是因为kube-schedule是通过访问apiserver获取信息数据的，所以必须先部署好apserver；
-
下载地址:https://github.com/kubernetes/kubernetes （包含了k8s所必须的组件，如kube-apiserver、kubelet、kube-scheduler、kube-controller-manager等等）
-
在windows下进入https://github.com/kubernetes/kubernetes后，点击如CHANGELOG-1.16.md文件查看对应的版本（1.16版本）和下载的文件;
-
选择Server Binaries的kubernetes-server-linux-amd64.tar.gz下载
-
在windows下载后通过lrzsz工具执行rz上传到linux上（linux上无法直接通过wget https://dl.k8s.io/v1.16.4/kubernetes.tar.gz下载）;
-
解压后生成kubernetes目录，把/kubernetes/service/bin/下的kube-scheduler复制到/opt/kubernetes/bin下；
-
创建schduler配置文件kube-scheduler
<span style="color:#000000"><code>cat > /opt/kubernetes/cfg/kube-scheduler <<EOF KUBE_SCHEDULER_OPTS="--logtostderr=true \ --v=4 \ --master=127.0.0.1:8080 \ --leader-elect" EOF 参数说明： * --logtostderr 写log到stderr而不到日志文件 * --v 日志等级 * --master 连接本地apiserver * --leader-elect 当该组件启动多个时，自动选举（HA） </code></span> -
systemd管理schduler,创建kube-scheduler服务文件
<span style="color:#000000"><code>cat > /usr/lib/systemd/system/kube-scheduler.service <<EOF [Unit] Description=Kubernetes Scheduler Documentation=https://github.com/kubernetes/kubernetes [Service] EnvironmentFile=-/opt/kubernetes/cfg/kube-scheduler ExecStart=/opt/kubernetes/bin/kube-scheduler $KUBE_SCHEDULER_OPTS Restart=on-failure [Install] WantedBy=multi-user.target EOF </code></span> -
启动kube-scheduler服务
<span style="color:#000000"><code>systemctl daemon-reload systemctl enable kube-scheduler systemctl start kube-scheduler </code></span> -
验证kube-scheduler服务是否启动成功
<span style="color:#000000"><code>systemctl status kube-scheduler 若失败可通过查看服务日志定位问题： journalctl _PID=<PID>|vim - 执行命令查看scheduler组件是否健康正常 kubectl get cs scheduler -o yaml </code></span>
-
下载kube-scheduler镜像
可在docker hub官网上搜索kube-scheduler合适的镜像下载，如我选择gcrio/kube-scheduler-amd64镜像，执行docker pull gcrio/kube-scheduler-amd64:v1.9.1-beta.0进行下载；
下载后执行docker tag docker.io/gcrio/kube-scheduler-amd64:v1.9.1-beta.0 kube-scheduler:latest生成kube-scheduler:latest镜像 -
配置kube-scheduler镜像启动参数
<span style="color:#000000"><code>KUBE_SCHEDULER_OPTS="--logtostderr=true \ --v=4 \ --master=127.0.0.1:8080 \ --leader-elect" 可通过执行echo $KUBE_SCHEDULER_OPTS查看是否配置成功 </code></span> -
启动kube-scheduler镜像启动
docker run -d --net='host' --name kube-scheduler kube-scheduler:lates kube-scheduler $KUBE_SCHEDULER_OPTS
注意01：若容器内需要通过
localhost或127.0.0.1直接访问宿主机的localhost，则容器运行的网络模式需要设置为host模式，如--net='host'。这样容器内的localhost和宿主机的localhost就是同一个了。
注意02：若容器启动时命令报错，则可能是容器的kube-scheduler命令可能不一样，可在所下载的镜像上查看，如我所下载的镜像查看如下：
注意03：执行docker run运行容器若报错:/usr/bin/docker-current: Error response from daemon: shim error: docker-runc not installed on system.
解决办法01：
cd /usr/libexec/docker/
sudo ln -s docker-runc-current docker-runc
解决办法02：
vi /etc/docker/daemon.json
添加如下内容：
{
“log-level”:“warn”,
“runtimes”: {
“docker-runc”: {
“path”: “/usr/libexec/docker/docker-runc-current”
}
},
“add-runtime”: “docker-runc=/usr/libexec/docker/docker-runc-current”,
“default-runtime”: “docker-runc”
}
保存退出，执行如下动作：
systemctl daemon-reload
systemctl start docker
注意04：若执行docker run命令启动容器报错exec: “docker-proxy”: executable file not found in $PATH；
解决办法：
查看下 docker-proxy 的位置：cat /usr/lib/systemd/system/docker.service | grep prox
创建一条软连接到 /usr/bin/ 下ln -s /usr/libexec/docker/docker-proxy-current /usr/bin/docker-proxy
-
验证kube-scheduler组件是否健康
kube-scheduler容器成功启动后，可通过执行命令查看scheduler组件是否健康正常：<span style="color:#000000"><code>kubectl get cs scheduler -o yaml </code></span>若scheduler组件不健康，则可通过
docker logs kube-scheduler查看kube-scheduler服务日志是否有报错信息来定位问题。
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]https://www.cnblogs.com/peitianwang/p/11579793.html
[参考文档]https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-scheduler/
八、kubernetes核心组件之controller manager详解
Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。
每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。
controller manager 中的 Replication controller(副本控制器) 和 K8S 中的资源 replication controller 不是同一个东西, 为了区别, 此处将资源类型的 replication controller 用RC 表示, controller manager 中的replication controller 仍然用 replication controller 表示,指代副本控制器。
replication controller 的核心作用是保障集群中某个 RC 关联的pod副本数与预设值一致. 当pod 重启策略为always 时(RestartPolicy=Always), Replication Controller 才会管理该 POD 的操作(创建, 销毁, 重启等), 在默认情况下, POD 对象被创建成功后不会消失, 唯一例外是当pod 处于succeed 或failed 状态的实践过长(超时参数由系统设定)时, 该pod 会被系统自动回收, 管理该 pod 的副本控制器将在其他工作节点上重新创建,运行该POD 副本。
RC 中的POD 模版就像模具, POD 一旦通过模版制作出来,就和RC 再也没有联系了. 无论模版如何变化, 甚至换成一个新的模版, 也不会影响到已经创建的POD . 因此POD 可以通过修改标签来脱离 RC 的管控. 改方法可以用于将POD 从集群中迁移, 数据修复等调试。
-
replication controller 的职责
-
确保集群中有且仅有N 个POD的实例, N 是RC 中定义的POD 副本数量;
-
通过调整 RC 的 spec.replicas 属性值来扩容或缩容;
-
通过改变 RC 中的 POD 模版(主要是镜像), 来实现滚动升级;
-
replication controller 的使用场景
-
重新调度。当发生节点故障或Pod被意外终止运行时，可以重新调度保证集群中仍然运行指定的副本数。
-
弹性伸缩。通过手动或自动扩容代理修复副本控制器的spec.replicas属性，可以实现弹性伸缩。
-
滚动升级。创建一个新的RC文件，通过kubectl 命令或API执行，则会新增一个新的副本同时删除旧的副本，当旧副本为0时，删除旧的RC。
当 RC 的spec.relicas 设置为0 时, 相关pod 将会被删除
kubelet在启动时会通过API Server注册自身的节点信息，并定时向API Server汇报状态信息，API Server接收到信息后将信息更新到etcd中。
Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node节点的相关控制功能。流程如下
-
controller manager 判断是否有 --cluster-cidr 参数, 如果有在每个节点设置spec.PodCIDR 并保障cidr 不冲突；
-
逐个读取Node 信息, 多次尝试修改nodeStatusMap中的节点状态信息, 将该节点信息和 Node Controller 的 nodeStatusMap 中保存的信息作比较；
A. 如果判断出没有收到 kubelet 发送的信息, 第一次收到 kubelet 发送的的节点信息, 或在该处理过程中节点状态编程非"健康", 则在 nodeStatusMap 中保存该节点状态信息, 并用 Node Controller 所在节点的系统时间,作为探测时间和节点状态变化时间。
B. 如果判断出在指定时间内受到的新的节点信息, 且节点状态发生变化, 则在 nodeStatusMap 中保存该界节点的状态信息. 并用 Node Controller 所在节点的系统时间,作为探测时间和节点状态变化时间。
C. 如果判断出在指定时间内收到新的节点信息, 但状态没有变化则在 nodeStatusMap 中保存该节点的状态信息. 并用 Node Controller 所在节点的系统时间作为探测时间, 将上次节点信息中的节点状态变化时间作为该节点的状态变化时间. 如果判断出某段时间(gracePeriod) 内没有收到节点状态信息, 则设置节点状态为"位置", 并通过api server 保存节点状态。 -
逐个读取节点信息, 如果节点状态变为非"就绪"状态, 则将节点加入待删除队列, 否则将节点从该队列删除. 如果节点为非就绪状态, 且系统指定了 cloud provider, 则 Node Controller 调用 cloud provider 查看节点, 若发现节点故障 则删除etcd中的信息, 并删除该节点相关的pod 等资源信息。
K8S 的配额管理是通过admiss control 来控制的, admission control 当前提供了两种方式进行配额约束, 分别是 LimitRanger 与 ResourceQuota. 其中 LimitRanger 作用于 POD 和 Container , ResourceQuota 作用于 Namespace。
资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源。 支持三个层次的资源配置管理：
1）容器级别：对CPU和Memory进行限制
2）Pod级别：对一个Pod内所有容器的可用资源进行限制
3）Namespace级别：包括Pod数量、Replication Controller数量、Service数量、ResourceQuota数量、Secret数量、可持有的PV（Persistent Volume）数量
1、k8s配额管理是通过Admission Control（准入控制）来控制的；
2、Admission Control提供两种配额约束方式：LimitRanger和ResourceQuota；
3、LimitRanger作用于Pod和Container；
4、ResourceQuota作用于Namespace上，限定一个Namespace里的各类资源的使用总额。
用户通过API Server可以创建新的Namespace并保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace信息。
如果Namespace被API标记为优雅删除（即设置删除期限，DeletionTimestamp）,则将该Namespace状态设置为“Terminating”,并保存到etcd中。同时Namespace Controller删除该Namespace下的ServiceAccount、RC、Pod等资源对象。
Endpoints表示了一个Service对应的所有Pod副本的访问地址，而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。
如果监测到Service被删除，则删除和该Service同名的Endpoints对象；
如果监测到新的Service被创建或修改，则根据该Service信息获得相关的Pod列表，然后创建或更新Service对应的Endpoints对象。
如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。
Service、Endpoint、Pod的关系：
kube-proxy进程获取每个Service的Endpoints，实现Service的负载均衡功能。
Service Controller是属于kubernetes集群与外部的云平台之间的一个接口控制器。Service Controller监听Service变化，如果是一个LoadBalancer类型的Service，则确保外部的云平台上对该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表。
二、kube-controller-manager启动参数详解
Usage:
kube-controller-manager [flags]
-
Debugging flags
| 参数 |
说明 |
|---|---|
| --contention-profiling |
启用了 profiling，则启用锁争用性分析 |
| --profiling |
开启profilling，通过web接口host:port/debug/pprof/分析性能 |
-
Generic flags
| 参数 |
说明 |
|---|---|
| --allocate-node-cidrs |
是否应在云提供商上分配和设置Pod的CIDR |
| --cidr-allocator-type string |
CIDR分配器的类型 (default “RangeAllocator”) |
| --cloud-config string |
云提供商配置文件路径，空代表没有配置文件 |
| --cloud-provider string |
云提供商，空代表没有云提供商 |
| --cluster-cidr string |
集群中Pod的CIDR范围，要求–allocate-node-cidrs为true |
| |
集群的实例前缀(default “kubernetes”) |
| --configure-cloud-routes |
是否在云提供商上配置allocate-node-cidrs分配的CIDR(default true) |
| --controller-start-interval duration |
启动controller manager的间隔时间 |
| --controllers strings |
需要开启的controller列表，*代表开启所有（默认），‘foo’代表开启foo controller，‘-foo’代表禁止foo controller。 |
| --feature-gates mapStringBool |
key = value对，用于试验 |
| --kube-api-burst int32 |
发送到kube-apiserver每秒请求量 （default 100） |
| --kube-api-content-type string |
发送到kube-apiserver请求内容类型（default “application/vnd.kubernetes.protobuf”） |
| --kube-api-qps float32 |
与kube-apiserver通信的qps（default 50） |
| |
多个master情况设置为true保证高可用，进行leader选举 |
| --leader-elect-lease-duration duration |
当leader-elect设置为true生效，选举过程中非leader候选等待选举的时间间隔（default 15s） |
| --leader-elect-renew-deadline duration |
eader选举过程中在停止leading，再次renew时间间隔，小于或者等于leader-elect-lease-duration duration，也是leader-elect设置为true生效（default 10s） |
| --leader-elect-retry-period duration |
当leader-elect设置为true生效，获取leader或者重新选举的等待间隔（default 2s） |
| --min-resync-period duration |
重新同步周期,在 [MinResyncPeriod-2 * MinResyncPeriod]间取随机值(default 12h0m0s) |
| --node-monitor-period duration |
NodeController同步NodeStatus的时间间隔(default 5s) |
| --route-reconciliation-period duration |
协调由云提供商为节点创建的路由的时间间隔 (default 10s) |
| --use-service-account-credentials |
设置true为每个控制器使用单个service account |
-
Service controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-service-syncs int32 |
允许同时同步的 service 数量。 数字越大=服务管理响应越快，但消耗更多 CPU 和网络资源 |
-
Secure serving flags
| 参数 |
说明 |
|---|---|
| |
监听–secure-port端口的IP地址(default 0.0.0.0) |
| |
TLS证书所在的目录。如果提供了–tls-cert-file和–tls-private-key-file，则将忽略此标志(default “/var/run/kubernetes”) |
| --http2-max-streams-per-connection int |
api server 提供给 client 的HTTP / 2最大 stream 连接数。0 用golang的默认值 |
| |
使用身份验证和授权提供服务的HTTPS端口。0禁用HTTPS |
| --tls-cert-file string |
文件包含HTTPS的默认x509证书的文件。 （如果有CA证书，在服务器证书之后级联）。如果启用了HTTPS服务，但是 --tls-cert-file和–tls-private-key-file 未设置，则会为公共地址生成自签名证书和密钥，并将其保存到–cert-dir的目录中 |
| --tls-cipher-suites strings |
逗号分隔的cipher suites列表。如果省略则使用默认的Go cipher suites |
| --tls-min-version string |
支持最低TLS版本。 主要有：VersionTLS10，VersionTLS11，VersionTLS12 |
| --tls-private-key-file string |
文件包括与 --tls-cert-file 匹配的默认x509私钥 |
| --tls-sni-cert-key namedCertKey |
x509证书和私钥对的文件路径(default []) Examples: “example.crt,example.key” or “foo.crt,foo.key:*.foo.com,foo.com” |
-
Insecure serving flags
| 参数 |
说明 |
|---|---|
| |
为不安全端口提供服务的IP地址(对于所有IPv4设置为0.0.0.0)接口和::所有IPv6接口)。(默认值0.0.0.0)(已弃用:参见 --bind-address代替。) |
| |
为不安全、未经身份验证的访问提供服务的端口。设置为0禁用。(默认10252)(弃用:参见 --secure-port) |
-
Authentication flags
| 参数 |
说明 |
|---|---|
| --authentication-kubeconfig string |
kubeconfig文件指向有权力创建tokenaccessreviews.authentication.k8s.io的核心kubernetes server，如果未设置所有的token请求被视为匿名的，在集群中也不查找client CA |
| --authentication-skip-lookup |
如果设置false，authentication-kubeconfig用来在集群中查找缺失的authentication配置 |
| --authentication-token-webhook-cache-ttl duration |
来自webhook token验证器的缓存响应时间 (default 10s) |
| --client-ca-file string |
如果设置任何请求必须提供其中一个客户端证书签名。则用其中的 Common Name 作为请求的用户名验证 |
| --requestheader-allowed-names strings |
客户端证书通用名称列表，允许在–requestheader-username-headers指定的标头中提供用户名。如果为空，则允–requestheader-client-ca-file中验证的任何客户端证书。 |
| --requestheader-client-ca-file string |
根证书包，用于在信任由–requestheader-username-headers指定的头文件中的用户名之前对传入请求验证客户端证书。警告:通常不要依赖于对传入请求已经进行的授权。 |
| --requestheader-extra-headers-prefix strings |
要检查的请求头前缀列表。建议X-Remote-Extra-。(默认[x-remote-extra -]) |
| --requestheader-group-headers strings |
要检查组的请求标头列表。建议X-Remote-Group。(默认[x-remote-group]) |
| --requestheader-username-headers strings |
检查用户名的请求头列表。X-Remote-User是常用的。(默认[x-remote-user]) |
-
Authorization flags
| 参数 |
说明 |
|---|---|
| --authorization-always-allow-paths strings |
授权期间要跳过的HTTP路径列表，这些路径是经过授权、无须与’核心’kubernetes服务通信(default [/healthz]) |
| --authorization-kubeconfig string |
kubeconfig指向核心的kubernetes服务拥有足够的权力来创建subjectaccessreviews.authorization.k8s.io，也是可选项，如果未设置，则所有请求将被禁止 |
| --authorization-webhook-cache-authorized-ttl duration |
从webhook授权器对于cache验证响应时间(default 10s) |
| --authorization-webhook-cache-unauthorized-ttl duration |
从webhook授权器对于cache验证未响应时间(default 10s) |
-
Attachdetach controller flags
| 参数 |
说明 |
|---|---|
| --attach-detach-reconcile-sync-period duration |
在volume attach detach调整同步等待时间，时间间隔必须大于1s，增加默认值可能导致volume与pod不匹配(default 1m0s) |
| --disable-attach-detach-reconcile-sync |
禁止volume attach detach 调整同步，禁用此功能可能会导致卷与 pod 不匹配 |
-
Csrsigning controller flags
| 参数 |
说明 |
|---|---|
| |
包含peme编码的X509 CA证书的文件名，用于发出集群范围的证书(默认为“/etc/kubernetes/ CA / CA .pem”) |
| |
包含pemm编码的RSA或ECDSA私有密钥的文件名，用于对集群范围的证书进行签名(默认为“/etc/kubernetes/ca/ca.key”) |
| --experimental-cluster-signing-duration duration |
签署证书的期限将会被给出。(默认8760h0m0s) |
-
Deployment controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-deployment-syncs int32 |
允许同时同步的deployment对象的数量，部署数量越大需要的CPU网络load也多(default 5) |
| --deployment-controller-sync-period duration |
同步deployment的周期(default 30s) |
-
Endpoint controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-endpoint-syncs int32 |
同时同步endpoint的数量，也是数量越多需要越多的CPU和network(default 5) |
-
Garbagecollector controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-gc-syncs int32 |
允许同时同步的garbage collector workers数量(default 20) |
| --enable-garbage-collector |
启用通用垃圾收集器，必须与kube-apiserver的相应参数一起使用(default true) |
-
Horizontalpodautoscaling controller flags
| 参数 |
说明 |
|---|---|
| --horizontal-pod-autoscaler-cpu-initialization-period duration |
当CPU samples略过，在pod启动之后的周期(default 5m0s) |
| --horizontal-pod-autoscaler-downscale-stabilization duration |
autoscaler将向后查看并且不会缩小到低于其在此期间提出的任何建议的时间段(default 5m0s) |
| --horizontal-pod-autoscaler-initial-readiness-delay duration |
pod启动后的一段时间，在此期间战备状态的变化将被视为初始战备状态(默认为30秒) |
| --horizontal-pod-autoscaler-sync-period duration |
The period for syncing the number of pods in horizontal pod autoscaler. (default 15s) |
| --horizontal-pod-autoscaler-tolerance float |
水平pod自动调度器所需的实际度量比的最小变化(从1.0开始)需要考虑缩放。(default 0.1) |
-
Namespace controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-namespace-syncs int32 |
允许并发同步的名称空间对象的数量。更大的数字=响应更快的名称空间终止，但是更多的CPU(和网络)负载(默认为10) |
| --namespace-sync-period duration |
同步namespace生命周期更新的周期(default 5m0s) |
-
Nodeipam controller flags
| 参数 |
说明 |
|---|---|
| --node-cidr-mask-size int32 |
集群中节点子网掩码打小(default 24) |
| |
集群service的cidr范围，需要–allocate-node-cidrs设置为true |
-
Nodelifecycle controller flags
| 参数 |
说明 |
|---|---|
| --enable-taint-manager |
如果设置为true则开启NoExecute Taints，将驱逐所有节点上（拥有这种污点的节点）不容忍运行pod (default true) |
| --large-cluster-size-threshold int32 |
NodeController出于驱逐逻辑目的而将集群视为大节点的节点数量。对于这种大小或更小的集群(默认为50),–secondary-node-eviction-rate被隐式覆盖为0 |
| --node-eviction-rate float32 |
当zone健康node失败情况，删除节点上的pod的速率 (default 0.1) |
| --node-monitor-grace-period duration |
在标记节点不健康之前，允许运行节点不响应的时间，必须是n倍的kubelet’s nodeStatusUpdateFrequency，N意味着kubelet报告node状态重试的次数(default 40s) |
| --node-startup-grace-period duration |
在标记节点不健康之前，允许开始节点不响应的时间 (default 1m0s) |
| --pod-eviction-timeout duration |
在失败的节点上删除pod的宽限时间 (default 5m0s) |
| --secondary-node-eviction-rate float32 |
当zone不健康node失败情况，删除节点上的pod的速率，如果集群大小小于 large-cluster-size-threshold，则隐式地将设置为0。(default 0.01) |
| --unhealthy-zone-threshold float32 |
not ready 节点（至少3个）的比例达到该值时，将 Zone 标记为不健康 (default 0.55) |
-
Persistentvolume-binder controller flags
| 参数 |
说明 |
|---|---|
| --enable-dynamic-provisioning |
为支持它的环境启用动态配置 (default true) |
| --enable-hostpath-provisioner |
当没有云提供商运行时开启host path pv配置，这主要适合测试以及开发配置features，host path配置不支持多点集群 |
| --flex-volume-plugin-dir string |
第三方插件路径 (default “/usr/libexec/kubernetes/kubelet-plugins/volume/exec/”) |
| --pv-recycler-increment-timeout-nfs int32 |
NFS scrubber pod添加每Gi到ActiveDeadlineSeconds的时间增量(default 30) |
| --pv-recycler-minimum-timeout-hostpath int32 |
对于HostPath Recycler pod的最小ActiveDeadlineSeconds，仅使用于测试于开发，不使用于多几点集群 (default 60) |
| --pv-recycler-minimum-timeout-nfs int32 |
对于NFS Recycler pod的最小ActiveDeadlineSeconds (default 300) |
| --pv-recycler-pod-template-filepath-hostpath string |
对于hostpaht持久卷重使用定义的模板路径，仅使用于测试于开发，不使用于多几点集群 |
| --pv-recycler-timeout-increment-hostpath int32 |
对于HostPath scrubber pod每增加Gi到ActiveDeadlineSeconds的时间增量，仅使用于测试于开发，不使用于多几点集群 (default 30) |
| --pvclaimbinder-sync-period duration |
同步pv以及pvc的周期 (default 15s) |
-
Podgc controller flags
| 参数 |
说明 |
|---|---|
| --terminated-pod-gc-threshold int32 |
当终止的pod达到该值时，pod garbage collector开始删除终止pod，如果设置<=0，关闭pod garbage collector (default 12500) |
-
Replicaset controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-replicaset-syncs int32 |
允许同时同步的rs数量，Larger number = more responsive replica management, but more CPU (and network) load (default 5) |
-
Replicationcontroller flags
| 参数 |
说明 |
|---|---|
| --concurrent_rc_syncs int32 |
允许并发同步的复制控制器的数目。更大的数字=响应更快的副本管理，但是更多的CPU(和网络)负载(默认5) |
-
Resourcequota controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-resource-quota-syncs int32 |
允许并发同步的资源配额数量。更大的数字=响应性更好的配额管理，但是更多的CPU(和网络)负载(默认5) |
| --resource-quota-sync-period duration |
在系统中同步配额使用状态的周期 (default 5m0s) |
-
Serviceaccount controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-serviceaccount-token-syncs int32 |
允许并发同步的服务帐户令牌对象的数量。更大的数字=响应性更好的令牌生成，但是更多的CPU(和网络)负载(默认5) |
| |
根CA 证书文件路径，如果设置的话将被用于 Service Account 的 token secret 中 |
| |
包含用于对服务帐户令牌签名的pemm编码的私有RSA或ECDSA密钥的文件名 |
-
Ttl-after-finished controller flags
| 参数 |
说明 |
|---|---|
| --concurrent-ttl-after-finished-syncs int32 |
允许并发同步的ttl后完成的控制器工作人员的数量。(默认5) |
-
Misc flags
| 参数 |
说明 |
|---|---|
| --insecure-experimental-approve-all-kubelet-csrs-for-group string |
This flag does nothing. |
| --kubeconfig string |
kubeconfig文件路径，带有验证以及master信息 |
| |
kubernetes api server的地址，将会覆盖kubeconfig设置的值 |
注意：以下kube-schedule安装部署是在k8s的etcd、apiserver组件已部署后的前提下部署验证的；
-
下载地址:https://github.com/kubernetes/kubernetes （包含了k8s所必须的组件，如kube-apiserver、kubelet、kube-scheduler、kube-controller-manager等等）
1.在windows下进入https://github.com/kubernetes/kubernetes后，点击如CHANGELOG-1.16.md文件查看对应的版本（1.16版本）和下载的文件;
2.选择Server Binaries的kubernetes-server-linux-amd64.tar.gz下载；
3.在windows下载后通过lrzsz工具执行rz上传到linux上（linux上无法直接通过wget https://dl.k8s.io/v1.16.4/kubernetes.tar.gz下载）;
4.解压后生成kubernetes目录，把/kubernetes/service/bin/下的kube-controller-manager复制到/opt/kubernetes/bin下； -
创建controller manager配置文件kube-controller-manager
cat > /opt/kubernetes/cfg/kube-controller-manager <<EOF KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=true \ --v=4 \ --master=127.0.0.1:8080 \ --leader-elect=true \ --address=127.0.0.1 \ --service-cluster-ip-range=10.0.0.0/24 \ --cluster-name=kubernetes \ --cluster-signing-cert-file=/opt/kubernetes/ssl/ca.pem \ --cluster-signing-key-file=/opt/kubernetes/ssl/ca-key.pem \ --root-ca-file=/opt/kubernetes/ssl/ca.pem \ --service-account-private-key-file=/opt/kubernetes/ssl/ca-key.pem" EOF -
systemd管理controller manager,创建kube-controller-manager服务文件
cat > /usr/lib/systemd/system/kube-controller-manager.service <<EOF [Unit] Description=Kubernetes Controller Manager Documentation=https://github.com/kubernetes/kubernetes [Service] EnvironmentFile=-/opt/kubernetes/cfg/kube-controller-manager ExecStart=/opt/kubernetes/bin/kube-controller-manager $KUBE_CONTROLLER_MANAGER_OPTS Restart=on-failure [Install] WantedBy=multi-user.target EOF-
启动kube-controller-manager服务
-
-
systemctl daemon-reload systemctl enable kube-scheduler systemctl start kube-scheduler -
验证kube-controller-manager服务是否启动成功
systemctl status kube-controller-manager 若失败可通过查看服务日志定位问题： journalctl _PID=<PID>|vim - 执行命令查看scheduler组件是否健康正常 kubectl get cs controller-manager -o yaml
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-controller-manager/
九、kubernetes核心组件之kubelet详解
在kubernetes集群中，每个Node节点都会启动kubelet进程，用来处理Master节点下发到本节点的任务，管理Pod和其中的容器。kubelet会在API Server上注册节点信息，定期向Master汇报节点资源使用情况，并通过cAdvisor监控容器和节点资源。可以把kubelet理解成【Server-Agent】架构中的agent，是Node上的pod管家。
流程图如下：
Kubelet组件运行在Node节点上，维持运行中的Pods以及提供kuberntes运行时环境，主要完成以下使命：
１．监视分配给该Node节点的 pods
２．挂载pod所需要的volumes
３．下载pod的secret
４．通过docker/rkt来运行pod中的容器
５．周期的执行pod中为容器定义的liveness探针
６．上报pod的状态给系统的其他组件
７．上报Node的状态
整个kubelet也可以按如下模块划分，模块之间相互配合完成Kubelet的所有功能。
上图解析如下：
１．10250 kubelet API，kublet暴露出来的端口，通过该端口可以访问获取node资源以及状态，另外可以配合kubelet的启动参数contention-profiling enable-debugging-handlers来提供了用于调试和profiling的api;
２．4194 cAdvisor，kublet通过该端口可以获取到本node节点的环境信息以及node上运行的容器的状态等内容；
３．10255 readonly API，kubelet暴露出来的只读端口，访问该端口不需要认证和鉴权，该http server提供查询资源以及状态的能力．注册的消息处理函数定义src/k8s.io/kubernetes/pkg/kubelet/server/server.go:149；
４．10248 /healthz –kubelet健康检查,通过访问该url可以判断Kubelet是否正常work, 通过kubelet的启动参数–healthz-port –healthz-bind-address来指定监听的地址和端口．默认值定义在pkg/kubelet/apis/kubeletconfig/v1alpha1/defaults.go；
-
PLEG
PLEG全称为PodLifecycleEvent,PLEG会一直调用container runtime获取本节点的pods,之后比较本模块中之前缓存的pods信息，比较最新的pods中的容器的状态是否发生改变，当状态发生切换的时候，生成一个eventRecord事件，输出到eventChannel中． syncPod模块会接收到eventChannel中的event事件，来触发pod同步处理过程，调用contaiener runtime来重建pod，保证pod工作正常。
-
cAdvisor
cAdvisor集成在kubelet中，起到收集本Node的节点和启动的容器的监控的信息，启动一个Http Server服务器，对外接收rest api请求．cAvisor模块对外提供了interface接口，可以通过interface接口获取到node节点信息，本地文件系统的状态等信息，该接口被imageManager，OOMWatcher，containerManager等所使用 cAdvisor相关的内容详细可参考github.com/google/cadvisor； -
GPUManager
对于Node上可使用的GPU的管理，当前版本需要在kubelet启动参数中指定feature-gates中添加Accelerators=true，并且需要才用runtime=Docker的情况下才能支持使用GPU,并且当前只支持NvidiaGPU,GPUManager主要需要实现interface定义的Start()/Capacity()/AllocateGPU()三个函数； -
OOMWatcher
系统OOM的监听器，将会与cadvisor模块之间建立SystemOOM,通过Watch方式从cadvisor那里收到的OOM信号，并发生相关事件； -
ProbeManager
探针管理，依赖于statusManager,livenessManager,containerRefManager，实现Pod的健康检查的功能。当前支持两种类型的探针：
１．LivenessProbe:用于判断容器是否存活，如果探测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理；
２．ReadinessProbe: 用于判断容器是否启动完成 ；
探针有三种实现方式 :
１．execprobe:在容器内部执行一个命令，如果命令返回码为０，则表明容器健康;
２．tcprobe:通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康;
３．httprobe:通过容器的IP地址，端口号以及路径调用http Get方法，如果响应status>=200 && status<=400的时候，则认为容器状态健康;
-
StatusManager
该模块负责pod里面的容器的状态，接受从其它模块发送过来的pod状态改变的事件，进行处理，并更新到kube-apiserver中; -
Container/RefManager
容器引用的管理，相对简单的Manager，通过定义map来实现了containerID与v1.ObjectReferece容器引用的映射。 -
EvictionManager
evictManager当node的节点资源不足的时候，达到了配置的evict的策略，将会从node上驱赶pod，来保证node节点的稳定性．可以通过kubelet启动参数来决定evict的策略．另外当node的内存以及disk资源达到evict的策略的时候会生成对应的node状态记录。 -
ImageGC
imageGC负责Node节点的镜像回收，当本地的存放镜像的本地磁盘空间达到某阈值的时候，会触发镜像的回收，删除掉不被pod所使用的镜像．回收镜像的阈值可以通过kubelet的启动参数来设置； -
ContainerGC
containerGC负责NOde节点上的dead状态的container,自动清理掉node上残留的容器．具体的GC操作由runtime来实现。 -
ImageManager
调用kubecontainer.ImageService提供的PullImage/GetImageRef/ListImages/RemoveImage/ImageStates的方法来保证pod运行所需要的镜像，主要是为了kubelet支持cni。 -
VolumeManager
负责node节点上pod所使用的ｖolume的管理，主要涉及如下功能 ：Volume状态的同步，模块中会启动gorountine去获取当前node上volume的状态信息以及期望的volume的状态信息，会去周期性的sync volume的状态，另外volume与pod的生命周期关联，pod的创建删除过程中volume的attach/detach流程．更重要的是kubernetes支持多种存储的插件，kubelet如何调用这些存储插件提供的interface。涉及的内容较多，更加详细的信息可以看kubernetes中volume相关的代码和文档。 -
containerManager
负责node节点上运行的容器的cgroup配置信息，kubelet启动参数如果指定 --cgroupPerQos的时候，kubelet会启动gorountie来周期性的更新pod的cgroup信息，维持其正确。实现了pod的Guaranteed/BestEffort/Burstable三种级别的Qos,通过配置kubelet可以有效的保证了当有大量pod在node上运行时，保证node节点的稳定性．该模块中涉及的struct主要包括：
-
runtimeManager
containerRuntime负责kubelet与不同的runtime实现进行对接，实现对于底层container的操作，初始化之后得到的runtime实例将会被之前描述的组件所使用．
当前可以通过kubelet的启动参数–container-runtime来定义是使用docker还是rkt.runtime需要实现的接口定义在src/k8s.io/kubernetes/pkg/kubelet/apis/cri/services.go文件里面； -
podManager
podManager提供了接口来存储和访问pod的信息，维持static pod和mirror pods的关系，提供的接口如下所示 ：
跟其他Manager之间的关系，podManager会被statusManager/volumeManager/runtimeManager所调用，并且podManager的接口处理流程里面同样会调用secretManager以及configMapManager.
Usage:(可使用kubelet -h来查看所有参数)
kubelet [flags]
kubelet启动参数如下：
--address ip kubelet 服务监听的IP地址（设置为 0.0.0.0 监听所有地址）（默认 0.0.0.0 ）
--allow-privileged 如果为 true ，将允许容器请求特权模式
--anonymous-auth 允许匿名请求到 kubelet 服务。未被另一个身份验证方法拒绝的请求被视为匿名请求。匿名请求包含系
统的用户名: anonymous ，以及系统的组名: unauthenticated 。（默认 true ）
--authentication-token-webhook 使用 TokenReview API 来确定不记名令牌的身份验证
--authentication-token-webhook-cache-ttl duration webhook 令牌身份验证器缓存响应时间。（默认2m0s）
--authorization-mode string kubelet 服务的授权模式。有效的选项是 AlwaysAllow 或 Webhook 。Webhook 模式使用 SubjectAccessReview API 来确定授权。(默认“AlwaysAllow”)
--authorization-webhook-cache-authorized-ttl duration 来自 webhook 的已认证响应缓存时间（默认 5m0s）
--authorization-webhook-cache-unauthorized-ttl duration 来自 webhook 的未认证响应缓存时间（默认 30s）
--azure-container-registry-config string Azure 容器注册表配置信息路径
--bootstrap-kubeconfig string 用于获取 kubelet 客户端证书的 kubeconfig 文件路径，如果由 --kubeconfig 指定的文件不存在，将
使用 bootstrap kubeconfig 从 API 服务器请求一个客户端证书，成功后，引用生成证书文件和密钥的 kubeconfig 将被写入 --kubeconfig 指定的文件，客户端证书和
密钥将被保存在 --cert-dir 指定的目录。
--cadvisor-port int32 本地 cAdvisor 端口（默认 4194）
--cert-dir string TLS 证书所在目录。如果 --tls-cert-file 和 --tls-private-key-file 指定的文件存在，当前配置将
被忽略。（默认“/var/run/kubernetes”）
--cgroup-driver string kubelet 用来操作主机上的 cgroups 驱动，可选值有：“cgroupfs”和“systemd”（默认“cgroupfs”）--cgroup-root string 用于 pods 的可选根 cgroup ， 这是由容器运行时在最好的工作基础上处理的，默认：''，也就是使>用容器运行时的默认值。--cgroups-per-qos 开启创建 QoS cgroup 层级，如果设置为 true 将创建顶级 QoS 和容器 cgroups 。（默认 true）
--chaos-chance float 如果大于 0.0 ，引入随机客户端错误及延迟，用来测试。
--client-ca-file string 如果设置，任何带有 client-ca-file 中签名的客户端证书的请求都将通过与客户端证书 CommonName >对应的标识进行身份认证。--cloud-config string 云提供商的配置文件路径，没有配置文件时为空字符串。
--cloud-provider string 云服务提供商。默认情况下， kubelet 将尝试自动检测云提供商，如果不使用云提供商可以指定该参数
为空字符串。（默认“auto-detect”）
--cluster-dns stringSlice DNS 服务器的IP地址列表，逗号分隔。这个值是用于配置指定了“dnsPolicy=ClusterFirst”的容器 DNS 服务器。注意：列表中所有的DNS服务器必须提供相同的记录值，否则集群中的名称解析可能无法正常工作，也就是无法确保连接DNS服务器提供正确的名称解析。--cluster-domain string 集群域名。如果设置， kubelet 将配置所有容器除了主机搜索域还将搜索当前域。 --cni-bin-dir string <警告: Alpha 特性>搜索CNI插件二进制文件的完整路径。默认值：/opt/cni/bin
--cni-conf-dir string <警告: Alpha 特性> 搜索CNI插件配置文件的完整路径。默认值：/etc/cni/net.d
--container-runtime string 运行时使用的容器。可选值：‘docker’和‘rkt’。（默认‘docker’）
--container-runtime-endpoint string [实验]远程运行服务的端点。目前在 Linux 上支持 unix 套接字，在 windows 上支持 tcp 。例如：‘unix:///var/run/dockershim.sock’，‘tcp://localhost:3735’（默认‘unix:///var/run/dockershim.sock’）
--containerized 在容器中运行 kubelet 的实验支持。用于测试。
--contention-profiling 如果启用了分析，启用锁争用分析。
--cpu-cfs-quota 为指定 CPU 限制的容器强制限制 CPU CFS 配额(默认 true)
--docker-disable-shared-pid 当运行 1.13.1 或更高版本的 docker 时，容器运行时接口( CRI )默认在同一个 pod 中的容器使用一>个共享的 PID 名称空间，将此标志设置为对独立的 PID 名称空间用来恢复先前的行为，这个功能将在未来的 Kubernetes 发布版本移除。
--docker-endpoint string 用来通信的 docker 端点。（默认“unix:///var/run/docker.sock”）
--enable-controller-attach-detach 允许附加/分离控制器来管理调度到当前节点的附加/分离卷，并禁用 kubelet 执行任何附加/分离操作(默认 true)
--enable-custom-metrics 支持收集自定义指标。
--enable-debugging-handlers 开启服务用来收集日志及本地运行的容器及命令（默认 true）
--enable-server 开启 kubelet 服务（默认 true）
--enforce-node-allocatable stringSlice 由 kubelet 执行的节点分配执行级别列表，逗号分隔。可选项有 'pods', 'system-reserved' 和 'kube-reserved' 。如果指定后两种，必须同时指定 '--system-reserved-cgroup' 和 '--kube-reserved-cgroup'。 查看 https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md 获取更多细节。 (默认 [ pods ])
--event-burst int32 一个突发事件记录的最大值。 仅当设置 --event-qps 大于0时，暂时允许该事件记录值超过设定值，但
不能超过 event-qps 的值。（默认10）
--event-qps int32 设置为大于0的值，将限制每秒创建的事件数目最大为当前值，设置为0则不限制。（默认为5）
--eviction-hard string 一个清理阈值的集合（例如 memory.available<1Gi ），达到该阈值将触发一次容器清理，(默认“memory.available < 100 mi,nodefs.available < 10%,nodefs.inodesFree < 10%)
--eviction-max-pod-grace-period int32 满足清理阈值时，终止容器组的最大响应时间，如果设置为负值，将使用 pod 设定的值。.
--eviction-minimum-reclaim string 一个资源回收最小值的集合（例如 imagefs.available=2Gi ），即 kubelet 压力较大时 ，执行 pod >清理回收的资源最小值。
--eviction-pressure-transition-period duration 过渡出清理压力条件前， kubelet 需要等待的时间。（默认 5m0S ）
--eviction-soft string 一个清理阈值的集合（例如 memory.available<1.5Gi ），如果达到一个清理周期将触发一次容器清理>。
--eviction-soft-grace-period string 一个清理周期的集合（例如 memory.available=1m30s ），在触发一个容器清理之前一个软清理阈值需>要保持多久。
--exit-on-lock-contention kubelet 是否应该退出锁文件争用。
--experimental-allocatable-ignore-eviction 设置为 true ，计算节点分配时硬清理阈值将被忽略。查看 https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md 获取更多细节。[默认 false]
--experimental-allowed-unsafe-sysctls stringSlice 不安全的 sysctls 或者 sysctl 模式（以*结尾）白名单列表，以逗号分隔。在自己的风险中使用这些>。
--experimental-bootstrap-kubeconfig string 已过时：使用 --bootstrap-kubeconfig
--experimental-check-node-capabilities-before-mount [实验]如果设置为 true , kubelet 将在执行 mount 之前检查基础节点所需组件(二进制文件等)。
--experimental-fail-swap-on 如果在节点上启用了 swap ， kubelet 将启动失败，这是一个维护遗留行为的临时选项，在 v1.6 启动
失败是因为默认启用了 swap。
--experimental-kernel-memcg-notification 如果启用， kubelet 将集成内核 memcg 通知以确定是否达到内存清理阈值，而不是轮询。
--experimental-mounter-path string [实验]二进制文件的挂载路径。保留空以使用默认。
--experimental-qos-reserved mapStringString 一个资源占比的集合（例如 memory=50%），描述如何在QoS级别保留pod资源请求，目前仅支持内存。[>默认 none]
--feature-gates string 一组键值对，用来描述 alpha 或实验特性，选项有：
Accelerators=true|false (ALPHA - default=false)
AdvancedAuditing=true|false (ALPHA - default=false)
AffinityInAnnotations=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllowExtTrafficLocalEndpoints=true|false (default=true)
AppArmor=true|false (BETA - default=true)
DynamicKubeletConfig=true|false (ALPHA - default=false)
DynamicVolumeProvisioning=true|false (ALPHA - default=true)
ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
LocalStorageCapacityIsolation=true|false (ALPHA - default=false)
PersistentLocalVolumes=true|false (ALPHA - default=false)
RotateKubeletClientCertificate=true|false (ALPHA - default=false)
RotateKubeletServerCertificate=true|false (ALPHA - default=false)
StreamingProxyRedirects=true|false (BETA - default=true)
TaintBasedEvictions=true|false (ALPHA - default=false)
--file-check-frequency duration 检查新数据配置文件的周期（默认 20s）
--google-json-key string 用于谷歌云平台服务帐户身份验证的 JSON 密钥。
--hairpin-mode string kubelet 如何设置 hairpin NAT（“发夹”转换）。 这使得当服务可以尝试访问自己时服务端点可以自动
恢复，合法值由 "promiscuous-bridge", "hairpin-veth" 和 "none". (默认 "promiscuous-bridge")
--healthz-bind-address ip 健康检查服务的IP地址。（设置 0.0.0.0 使用所有地址）（默认 127.0.0.1 ）
--healthz-port int32 本地健康检查服务的端口号（默认 10248 ）
--host-ipc-sources stringSlice kubelet 允许 pod 使用主机 ipc 名称空间列表，逗号分隔。（默认[*]）
--host-network-sources stringSlice kubelet 允许 pod 使用主机网络列表，逗号分隔。（默认[*]）
--host-pid-sources stringSlice kubelet 允许 pod 使用主机 pid 名称空间列表，逗号分隔。（默认[*]）
--hostname-override string 如果不是空，将使用该字符作为 hostname 而不是真实的 hostname 。
--http-check-frequency duration 通过 http 检查新数据的周期（默认 20s）
--image-gc-high-threshold int32 镜像占用磁盘比率最大值，超过此值将执行镜像垃圾回收。（默认 85）
--image-gc-low-threshold int32 镜像占用磁盘比率最小值，低于此值将停止镜像垃圾回收。（默认 80）
--image-pull-progress-deadline duration 镜像拉取进度最大时间，如果在这段时间拉取镜像没有任何进展，将取消拉取。（默认 1m0s）
--image-service-endpoint string [实验]远程镜像服务端点。如果没有指定，默认情况下将与容器运行时端点相同。目前在 Linux 上支持
unix 套接字，在 windows 上支持 tcp 。 例如:'unix:///var/run/dockershim.sock', 'tcp://localhost:3735'
--iptables-drop-bit int32 用于标记丢弃数据包的 fwmark 空间位，取值范围[0，31]。(默认 15)
--iptables-masquerade-bit int32 用于标记 SNAT 数据包的 fwmark 空间位，取值范围[0，31]，请将此参数与 kube-proxy 中的相应参数
匹配。（默认 14）
--keep-terminated-pod-volumes 在容器停止后保持容器卷挂载在节点上，这对调试卷相关问题非常有用。
--kube-api-burst int32 与 kubernetes apiserver 会话时的并发数。（默认 10）
--kube-api-content-type string 发送到 apiserver 的请求 Content type 。（默认“application/vnd.kubernetes.protobuf”）
--kube-api-qps int32 与 kubernetes apiserver 会话时的 QPS 。（默认 15
--kube-reserved mapStringString 一个资源预留量的集合（例如 cpu=200m,memory=500Mi, storage=1Gi ） ，即为 kubernetes 系统组件
预留的资源，目前支持根文件系统的 cpu、内存和本地存储。查看 http://kubernetes.io/docs/user-guide/compute-resources 或许更多细节。[默认 none]
--kube-reserved-cgroup string 用来管理 Kubernetes 组件的顶级 cgroup 的绝对名称，这些组件用来管理那些标记‘--kube-reserved’的计算资源。 [默认'']
--kubeconfig string kubeconfig 文件的路径，用来指定如何连接到 API server ，此时将使用 --api-servers 除非设置了
--require-kubeconfig 。（默认“/var/lib/kubelet/kubeconfig”）
--kubelet-cgroups string 可选的 cgroups 的绝对名称来创建和运行 kubelet
--lock-file string <警告: Alpha 特性> kubelet 用于锁文件的路径。
--make-iptables-util-chains 如果为 true ， kubelet 将确保 iptables 工具规则在主机上生效。（默认 true）
--manifest-url string 访问容器清单的 URL 。
--manifest-url-header string 访问容器清单的 URL 的 HTTP 头， key 和 value 之间用:分隔
--max-open-files int kubelet 进程可以打开的文件数目。（默认 1000000）
--max-pods int32 当前 kubelet 可以运行的容器组数目。（默认 110）
--minimum-image-ttl-duration duration 在执行垃圾回收前未使用镜像的最小年龄。例如： '300ms', '10s' or '2h45m'. (默认 2m0s)
--network-plugin string <警告: Alpha 特性> 在 kubelet/pod 生命周期中为各种事件调用的网络插件的名称
--network-plugin-mtu int32 <警告: Alpha 特性> 传递给网络插件的 MTU 值以覆盖缺省值，设置为0将使用默认值 1460
--node-ip string 当前节点的IP地址，如果设置， kubelet 将使用这个地址作为节点ip地址。
--node-labels mapStringString <警告: Alpha 特性> 在集群中注册节点时添加的标签，标签必须为用英文逗号分隔的 key=value 对。
--node-status-update-frequency duration 指定 kubelet 的节点状态为 master 的频率。注意:在修改时要小心，它必须与 nodecontroller 的 nodeMonitorGracePeriod 一起工作。(默认 10s)
--oom-score-adj int32 kubelet 进程的 oom-score-adj 值，范围[-1000, 1000] (默认 -999)
--pod-cidr string 用于 pod IP 地址的 CIDR ，仅在单点模式下使用。在集群模式下，这是由 master 获得的。
--pod-infra-container-image string 每个 pod 中的 network/ipc 名称空间容器将使用的镜像。 (默认 "gcr.io/google_containers/pause-amd64:3.0")
--pod-manifest-path string 包含 pod 清单文件的目录或者单个 pod 清单文件的路径。从点开始的文件将被忽略。
--pods-per-core int32 可以在这个 kubelet 上运行的容器组数目，在这个 kubelet 上的容器组数目不能超过 max-pods ，所>以如果在这个 kubelet 上运行更多的容器组应同时使用 max-pods ，设置为 0 将禁用这个限制。
--port int32 kubelet 服务的端口 (默认 10250)
--protect-kernel-defaults kubelet 的默认内核调优行为。设置之后， kubelet 将在任何可调参数与默认值不同时抛出异常。
--provider-id string 在机器数据库中标识节点的唯一标识符，也就是云提供商
--read-only-port int32 没有认证/授权的只读 kubelet 服务端口。 (设置为 0 以禁用) (默认 10255)
--really-crash-for-testing 设置为 true ，有可能出现应用崩溃。 用于测试。
--register-node 用 apiserver 注册节点 (如果设置了 --api-servers 默认为 true ) (默认 true)
--register-with-taints []api.Taint 用给定的列表注册节点 (逗号分隔 "<key>=<value>:<effect>")。如果 register-node 为 false 将无>操作
--registry-burst int32 拉去镜像的最大并发数，允许同时拉取的镜像数，不能超过 registry-qps ，仅当 --registry-qps 大>于 0 时使用。 (默认 10)
--registry-qps int32 如果大于 0 ，将限制每秒拉去镜像个数为这个值，如果为 0 则不限制。 (默认 5)
--require-kubeconfig 设置为 true ， kubelet 将在配置错误时退出并忽略 --api-servers 指定的值以使用在 kubeconfig >文件中定义的服务器。
--resolv-conf string 用作容器 DNS 解析配置的解析器配置文件。 (默认 "/etc/resolv.conf")
--rkt-api-endpoint string 与 rkt API 服务通信的端点，仅当设置 --container-runtime='rkt' 时有效 (默认 "localhost:15441")
--rkt-path string rkt 二进制文件的路径，设置为空将使用 $PATH 中的第一个 rkt ，仅当设置 --container-runtime='rkt' 时有效。
--root-dir string 管理 kubelet 文件的目录 (卷挂载等). (默认 "/var/lib/kubelet")
--runonce 如果为 true ，将在从本地清单或者远端url生成容器组后退出，除非指定了 --api-servers 和 --enable-server
--runtime-cgroups string 可选的 cgroups 的绝对名称，创建和运行时使用。
--runtime-request-timeout duration 除了 pull, logs, exec 和 attach 这些长运行请求之外的所有运行时请求的超时时间。 当到达超时时
间，kubelet 将取消请求，抛出异常并稍后重试。 (默认 2m0s)
--seccomp-profile-root string seccomp 配置文件目录。 (默认 "/var/lib/kubelet/seccomp")
--serialize-image-pulls 一次拉取一个镜像。建议在安装 docker 版本低于 1.9 的节点或一个Aufs存储后端不去修改这个默认值
。查看问题 #10959 获取更多细节。 (默认 true)
--streaming-connection-idle-timeout duration 在连接自动关闭之前，流连接的最大空闲时间，0 表示永不超时。例如： '5m' (默认 4h0m0s)
--sync-frequency duration 同步运行容器和配置之间的最大时间间隔 (默认 1m0s)
--system-cgroups / 可选的 cgroups 的绝对名称，用于将未包含在 cgroup 内的所有非内核进程放置在根目录 / 中，回滚>这个标识需要重启。
--system-reserved mapStringString 一个 资源名称=量 的集合(例如 cpu=200m,memory=500Mi ) 用来描述为非 kubernetes 组件保留的资源
。 目前仅支持 cpu 和内存。 查看 http://kubernetes.io/docs/user-guide/compute-resources 或许更多细节。 [默认 none]
--system-reserved-cgroup string 顶级 cgroup 的绝对名称，用于管理计算资源的非 kubernetes 组件，这些组件通过'--system-reserved'标识保留系统资源。除了'/system-reserved'。 [默认'']
--tls-cert-file string 包含用于 https 服务的 x509 证书的文件 (中间证书，如果有，在服务器认证后使用)。如果没有提供 --tls-cert-file 和 --tls-private-key-file ， 将会生产一个自签名的证书及密钥给公开地址使用，并将其保存在 --cert-dir 指定的目录。
--tls-private-key-file string 包含 x509 私钥匹配的文件 --tls-cert-file
--version version[=true] 打印 kubelet 版本并退出。
--volume-plugin-dir string <警告: Alpha 特性> 第三方卷插件的完整搜索路径。 (默认 "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/")
--volume-stats-agg-period duration 指定 kubelet 计算和缓存所有容器组及卷的磁盘使用量时间间隔。设置为 0 禁用卷计算。（默认 1m）
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。