Kubernetes_APIServer_证书_03_四个静态Pod Yaml文件解析

前言

kubectl get nodes 可以看到node有不同的role，一种是master，一种是node，role类型为master就是主节点，有四个静态Pod

一、APIServer Yaml文件解析

/etc/kubernetes/manifest/kube-apiserver.yaml 文件运行成为 apiserver 这个 Pod

整个文件 = apiVersion + kind + metadata + spec

结构和功能相适应：
apiserver的功能：

apiVersion: v1 
kind: Pod      # 类型是Pod，而不是控制器controller，所以副本数就是一个
metadata:annotations:kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 192.168.100.155:6443creationTimestamp: nulllabels:component: kube-apiservertier: control-planename: kube-apiservernamespace: kube-system
spec:containers:- command:- kube-apiserver- --advertise-address=192.168.100.155- --allow-privileged=true - --authorization-mode=Node,RBAC   # 使用 rbac 授权- --client-ca-file=/etc/kubernetes/pki/ca.crt- --enable-admission-plugins=NodeRestriction  # 准入控制器- --enable-bootstrap-token-auth=true- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt- --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt- --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key- --etcd-servers=https://127.0.0.1:2379   # apiserver需要的访问的etcd的地址(如果etcd不运行或连不上，apiserver也启动不了)- --insecure-port=0    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt- --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname- --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt- --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key- --requestheader-allowed-names=front-proxy-client- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt- --requestheader-extra-headers-prefix=X-Remote-Extra-- --requestheader-group-headers=X-Remote-Group- --requestheader-username-headers=X-Remote-User- --secure-port=6443   - --service-account-issuer=https://kubernetes.default.svc.cluster.local- --service-account-key-file=/etc/kubernetes/pki/sa.pub- --service-account-signing-key-file=/etc/kubernetes/pki/sa.key- --service-cluster-ip-range=10.96.0.0/12    # service子网段，这个是- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt- --tls-private-key-file=/etc/kubernetes/pki/apiserver.keyimage: k8s.gcr.io/kube-apiserver:v1.21.0   # 镜像imagePullPolicy: IfNotPresent  # 镜像拉取策略，如果本地不存在就拉取  IfNotPresent Always NeverlivenessProbe:      # 生存性探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)failureThreshold: 8httpGet:host: 192.168.100.155path: /livezport: 6443scheme: HTTPSinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15name: kube-apiserver   # pod的名称readinessProbe:    # 可读性探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)failureThreshold: 3httpGet:host: 192.168.100.155path: /readyzport: 6443scheme: HTTPSperiodSeconds: 1timeoutSeconds: 15resources:   # 资源请求量，request下限，limit上限，scheduler根据request对比机器上的free来调度，hpa根据 top metrics 自动扩缩容requests:cpu: 250mstartupProbe:   # 启动探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)  failureThreshold: 24httpGet:host: 192.168.100.155path: /livezport: 6443scheme: HTTPSinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15volumeMounts:  # 目录挂载- mountPath: /etc/ssl/certsname: ca-certsreadOnly: true- mountPath: /etc/pkiname: etc-pkireadOnly: true- mountPath: /etc/kubernetes/pki   # 所有的证书，都从宿主机读入到apiserver容器里面去name: k8s-certsreadOnly: truehostNetwork: true   priorityClassName: system-node-criticalvolumes:- hostPath:path: /etc/ssl/certs   #  这个目录不存在type: DirectoryOrCreatename: ca-certs- hostPath:path: /etc/pki     #  这个目录不存在type: DirectoryOrCreatename: etc-pki- hostPath:path: /etc/kubernetes/pki   #  这个目录存在，所有的证书，都从宿主机读入到apiserver容器里面去type: DirectoryOrCreatename: k8s-certs
status: {}

APIServer证书文件

对于apisever的所有arg参数来说，证书占了很多一部分，看一下和apiserver相关的所有证书(结构和功能相适应的原则)

通过磁盘映射将宿主机m 的 /etc/kubernetes/pki 下面的所有证书文件，映射到容器里面去了，看一下所有的证书相关的 arg 参数

cat /etc/kubernetes/manifests/kube-apiserver.yaml  # 所需要在证书都在 /etc/kubernetes/pki 目录下# client-ca-file用于验证客户端证书，集群里用的ca是同一个，才不用为不同组件配置不同ca
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt  # 用来生成apiserver访问etcd的密钥和证书- --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt # apiserver访问etcd的证书
- --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key # apiserver访问etcd的密钥- --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt # apiserver访问kubelet的证书
- --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key # apiserver访问kubelet的密钥- --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt  # 代理根证书签发的客户端证书
- --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key  # 代理根证书签发的客户端密钥
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt  # 代理根证书- --service-account-key-file=/etc/kubernetes/pki/sa.pub  # sa公钥
- --service-account-signing-key-file=/etc/kubernetes/pki/sa.key  # sa私钥- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt  # apiserver证书
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key # apiserver密钥

问题：apiserver的启动参数没有用到ca.key，为什么还要从第一台master同步到其他master呢？
回答：因为每个Master上都会生成一个/etc/kubernetes/admin.conf文件，里面的内容其实就是一个客户证书，由ca.key和ca.crt签署的，所以还需要ca.key。

这些证书都是在宿主机 /etc/kubernetes/pki 目录下，是通过 volumeMount 挂盘的方式映射到容器里面，然后 apiserver 启动的时候才可以使用的

    volumeMounts:  # 容器目录- mountPath: /etc/ssl/certsname: ca-certsreadOnly: true- mountPath: /etc/pkiname: etc-pkireadOnly: true- mountPath: /etc/kubernetes/pki   # 所有的证书，都从宿主机读入到apiserver容器里面去name: k8s-certsreadOnly: truevolumes: # 宿主机目录- hostPath:path: /etc/ssl/certs   #  这个目录是linux机器的ssl认证 (http+ssl/tls=https)type: DirectoryOrCreatename: ca-certs- hostPath:path: /etc/pki     #  这个目录是linux机器的证书type: DirectoryOrCreatename: etc-pki- hostPath:path: /etc/kubernetes/pki   #  这个目录存在，所有的证书，都从宿主机读入到apiserver容器里面去type: DirectoryOrCreatename: k8s-certs

在linux中与CA相关的信息在/etc/pki目录下，里面有CA，nssdb，rpm-gpg，tls 目录。其中，CA目录就是我们在当前创建CA所要依赖的目录，tls目录是openssL的配置文件存放目录，要在此文件中修改CA的相对路径为绝对路径。

APIServer三种探针

apiserver的健康检查

启动探针

startupProbe:   # 启动探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)  failureThreshold: 24httpGet:host: 192.168.100.155path: /livezport: 6443scheme: HTTPS # 指定协议是https，因为是探针访问apiserver，需要双向认证，所以是httpsinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15

启动探针含义解释：通过发送 https://192.168.100.155:6443/livez 来验证 apiserver 是否已经启动了，启动探针仅仅启动的时候用到

可读性探针

readinessProbe:    # 可读性探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)failureThreshold: 3httpGet:host: 192.168.100.155path: /readyzport: 6443scheme: HTTPS # 指定协议是https，因为是探针访问apiserver，需要双向认证，所以是httpsperiodSeconds: 1timeoutSeconds: 15

可读性探针含义解释：通过发送 https://192.168.100.155:6443/readyz 来验证 apiserver 是否可读，apiserver 运行时使用，如果失败，报错 unready 当前不可读，可以使用 kubectl describe pod pod-name 看到

生存性探针

livenessProbe:      # 生存性探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)failureThreshold: 8httpGet:host: 192.168.100.155path: /livezport: 6443scheme: HTTPS # 指定协议是https，因为是探针访问apiserver，需要双向认证，所以是httpsinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15

生存性探针含义解释：通过发送 https://192.168.100.155:6443/livez 来验证 apiserver 是否存活，apiserver 运行时使用，如果失败，报错 unlive 当前不可活，可以使用 kubectl describe pod pod-name 看到

APIServer其他参数

  - command:- kube-apiserver- --advertise-address=192.168.100.155- --insecure-port=0    - --secure-port=6443 - --allow-privileged=true - --authorization-mode=Node,RBAC   # 授权模式：使用 rbac 授权- --enable-admission-plugins=NodeRestriction  # 准入控制器：NodeRestriction- --enable-bootstrap-token-auth=true- --etcd-servers=https://127.0.0.1:2379   # apiserver访问etcd(如果etcd不运行或连不上，apiserver也启动不了)- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname  # apiserver与kubelet相互访问- --requestheader-allowed-names=front-proxy-client  # 请求头- --requestheader-username-headers=X-Remote-User  # 请求头- --requestheader-group-headers=X-Remote-Group  # 请求头- --requestheader-extra-headers-prefix=X-Remote-Extra-  # 请求头- --service-account-issuer=https://kubernetes.default.svc.cluster.local- --service-cluster-ip-range=10.96.0.0/12    # service子网段，这个是

command 表示命令，就是镜像启动命令，执行的是 kube-apiserver 二进制文件，后面的都是这个 kube-apiserver 二进制文件的启动参数。

address

–advertise-address string
该参数作用：向集群成员通知 apiserver 消息的 IP 地址，这个地址必须能够被集群中其他成员访问。
该参数设定：这个参数是 kubeadm init 在时候时候指定的，例如 kubeadm init --kubernetes-version=1.21.0 --apiserver-advertise-address=192.168.100.155 --pod-network-cidr=10.244.0.0/16 中通过 --apiserver-advertise-address=192.168.100.155 指定的。
该参数缺省：如果 IP 地址为空，将会使用 --bind-address， 如果未指定 --bind-address，将会使用主机的默认接口地址。

–bind-address string 默认值：“0.0.0.0”
该参数作用：用来监听 --secure-port 端口的 IP 地址。 集群的其余部分以及 CLI/web 客户端必须可以访问所关联的接口。
该参数设定：默认缺省，可以通过 vi /etc/kubernetes/manifests/kube-apiserver.yaml 中手动设定，:wq 保存即可。
该参数缺省：如果为空白或未指定地址（0.0.0.0 或 ::），则将使用所有接口。

如上图，当 bind-address 参数缺省的时候，Local Address的0.0.0.0代表本机上可用的所有任意地址，Foreign Address的0.0.0.0代表任意外部地址；当 bind-address 参数指定的时候，Local Address的 192.168.100.151 代表本机上指定地址，Foreign Address的0.0.0.0代表任意外部地址。

小结：advertise-address 是整个集群通知 apiserver 消息的地址，bind-address 是用来监听 secure-port 的地址。

secret-port和insecure-port

–secure-port int 默认值：6443
带身份验证和鉴权机制的 HTTPS 服务端口。 不能用 0 关闭。

–insecure-port int 默认值：0
不带身份验证和鉴权机制的 HTTPS 服务端口。 默认使用 0 关闭，改为非 0 就是打开一个不需要 认证授权 而直接操作apiserver的通道。

区别： 所有的认证方式都是访问 apiserver 的 secure port 才需要用到的，secure-port:6443是需要认证授权的，insecure-port是不需要认证授权的，apiserver对于secure-port有不同的认证方式。

–enable-bootstrap-token-auth
启用以允许将 “kube-system” 名字空间中类型为 “bootstrap.kubernetes.io/token” 的 Secret 用于 TLS 引导身份验证。

特权容器

–allow-privileged
如果为 true，将允许特权容器。[默认值=false]

授权

–authorization-mode strings 默认值：“AlwaysAllow”
在安全端口上进行 权限认证 的插件的顺序列表(如果权限认证失败，报错 403 Not Forbidden)。 逗号分隔的列表：AlwaysAllow、AlwaysDeny、ABAC、Webhook、RBAC、Node。

准入控制

–enable-admission-plugins strings
除了默认启用的插件（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、PodSecurity、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、ClusterTrustBundleAttest、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook、ResourceQuota）之外要启用的准入插件。 取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、ClusterTrustBundleAttest、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurity、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionPolicy、ValidatingAdmissionWebhook。该标志中插件的顺序无关紧要。

apiserver访问etcd的地址

–etcd-servers strings
要连接的 etcd 服务器列表（scheme://ip:port），以逗号分隔。k8s内部交互是 apiserver 需要访问 etcd 。

apiserver与kubelet相互访问

–kubelet-preferred-address-types strings 默认值：Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP
用于 kubelet 连接的首选 NodeAddressTypes 列表。

requestheader请求头四个字段

–requestheader-allowed-names strings
此值为客户端证书通用名称（Common Name）的列表；表中所列的表项可以用来提供用户名(这里是 front-proxy-client )， 方式是使用 --requestheader-username-headers 所指定的头部。
如果为空，能够通过 --requestheader-client-ca-file 中机构 认证的客户端证书都是被允许的。

–requestheader-username-headers strings
用于查验用户名的请求头部字段列表。建议使用 X-Remote-User。

–requestheader-group-headers strings
用于查验用户组的请求头部列表。建议使用 X-Remote-Group。

–requestheader-extra-headers-prefix strings
用于查验请求头部的前缀列表。建议使用 X-Remote-Extra-。

–service-account-issuer strings
服务帐号令牌颁发者的标识符。 颁发者将在已颁发令牌的 “iss” 声明中检查此标识符。 此值为字符串或 URI。 如果根据 OpenID Discovery 1.0 规范检查此选项不是有效的 URI，则即使特性门控设置为 true， ServiceAccountIssuerDiscovery 功能也将保持禁用状态。 强烈建议该值符合 OpenID 规范： https://openid.net/specs/openid-connect-discovery-1_0.html 。 实践中，这意味着 service-account-issuer 取值必须是 HTTPS URL。 还强烈建议此 URL 能够在 {service-account-issuer}/.well-known/openid-configuration 处提供 OpenID 发现文档。 当此值被多次指定时，第一次的值用于生成令牌，所有的值用于确定接受哪些发行人。

–service-cluster-ip-range string
CIDR 表示的 IP 范围用来为服务分配集群 IP。 此地址不得与指定给节点或 Pod 的任何 IP 范围重叠。 最多允许两个双栈 CIDR。

特别注意：service cidr 不得与指定给节点或 Pod 的任何 IP 范围重叠。 最多允许两个双栈 CIDR。

---

当前 apiserver.yaml 中并没有列出所有参数，其他参数

–admission-control-config-file string
包含准入控制配置的文件。

要想知道这些参数每个代表什么意思，可以查看 k8s 官网 K8S官网APIServer介绍

APIServer其他配置项

    resources:   # 资源请求量，request下限，limit上限，scheduler根据request对比机器上的free来调度，hpa根据 top metrics 自动扩缩容requests:cpu: 250m  # cpu：250m，表示0.25个cpu，单位是container，表示每个container请求0.25个cpuhostNetwork: true   priorityClassName: system-node-critical # 这个Pod优先调度，因为是kube-system里面的静态Pod

解释 hostNetwork: true
(1) hostNetwork: true 这种网络模式 ，相当于 docker run --net=host，采用宿主机的网络命名空间。此时，对于 IP , Pod 的 ip 为 node 节点的ip，即静态Pod；对于 Port 端口，Pod的端口需要保持不与宿主机上的port 端口发生冲突，就是Pod的端口直接映射到宿主机上面去了，需要通过 Service NodePort .
(2) dnsPolicy: ClusterFirst 等效于 hostNetwork: true && dnsPolicy: ClusterFirstWithHostNet，因为当设置了 hostNetwork:true 之后，容器不仅使用宿主机的IP、端口，还是用宿主机的DNS域名解析，dnsPolicy缺省默认值为ClusterFirst，只有在额外设置一下 dnsPolicy: ClusterFirstWithHostNet，才能让POD使用k8s的dns，dns配置在/etc/resolv.conf文件中，如果不加，pod默认使用所在宿主主机使用的DNS，这样会导致容器内不能通过 serviceName.namespace 访问k8s集群中其他 Pod

参考资料：kubernetes中的Cpu和Memory
循序渐进地学习kubernetes网络
k8s-"hostNetwork: true"网络

二、Scheduler Yaml文件解析

apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:component: kube-schedulertier: control-planename: kube-schedulernamespace: kube-system
spec:containers:- command:- kube-scheduler- --authentication-kubeconfig=/etc/kubernetes/scheduler.conf- --authorization-kubeconfig=/etc/kubernetes/scheduler.conf- --bind-address=127.0.0.1- --kubeconfig=/etc/kubernetes/scheduler.conf- --leader-elect=true- --port=0image: k8s.gcr.io/kube-scheduler:v1.21.0imagePullPolicy: IfNotPresentlivenessProbe:failureThreshold: 8httpGet:host: 127.0.0.1path: /healthzport: 10259scheme: HTTPSinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15name: kube-schedulerresources:requests:cpu: 100mstartupProbe:failureThreshold: 24httpGet:host: 127.0.0.1path: /healthzport: 10259scheme: HTTPSinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15volumeMounts:- mountPath: /etc/kubernetes/scheduler.confname: kubeconfigreadOnly: truehostNetwork: truepriorityClassName: system-node-criticalvolumes:- hostPath:path: /etc/kubernetes/scheduler.conftype: FileOrCreatename: kubeconfig
status: {}

Scheduler证书配置

kube-scheduler证书配置：scheduler唯一和其他打交道的就是 scheduler Pod 访问 APIServer，因为Scheduler是静态Pod，是稳定的，所以不需要使用 sa 访问，而是使用 scheduler.conf 这种 x509 客户端证书访问，直接使用了预生成的kubeconfig【涉及文件：/etc/kubernetes/scheduler.conf】

cat /etc/kubernetes/manifests/kube-scheduler.yaml  所需要在证书都在 /etc/kubernetes/scheduler.conf- command:- kube-scheduler- --kubeconfig=/etc/kubernetes/scheduler.conf  # kubeconfig就是scheduler.conf文件- --authentication-kubeconfig=/etc/kubernetes/scheduler.conf  # 认证使用的kubeconfig也是scheduler.conf文件- --authorization-kubeconfig=/etc/kubernetes/scheduler.conf  # 授权使用的kubeconfig也是scheduler.conf文件

–kubeconfig string
已弃用: 包含鉴权和主节点位置信息的 kubeconfig 文件的路径。 如果 --config 指定了一个配置文件，那么这个参数将被忽略。

–authentication-kubeconfig string
指向具有足够权限以创建 tokenaccessreviews.authentication.k8s.io 的 Kubernetes 核心服务器的 kubeconfig 文件。 这是可选的。如果为空，则所有令牌请求均被视为匿名请求，并且不会在集群中查找任何客户端 CA。

–authorization-kubeconfig string
指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的 Kubernetes 核心服务器的 kubeconfig 文件。这是可选的。 如果为空，则所有未被鉴权机制略过的请求都会被禁止。

涉及的文件

    volumeMounts: # 容器中目录- mountPath: /etc/kubernetes/scheduler.conf  # 启动的时候，宿主机 -> 容器name: kubeconfigreadOnly: truevolumes: # 宿主机中目录- hostPath:path: /etc/kubernetes/scheduler.conftype: FileOrCreatename: kubeconfig

Scheduler两个探针

启动探针

startupProbe:failureThreshold: 24httpGet:host: 127.0.0.1path: /healthzport: 10259scheme: HTTPS  # 指定协议是https，因为是探针访scheduler，需要双向认证，所以是httpsinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15

启动探针含义解释：通过发送 https://127.0.0.1:10259/health 来验证 scheduler 是否已经启动了，启动探针仅仅启动的时候用到

生存性探针

livenessProbe:failureThreshold: 8httpGet:host: 127.0.0.1path: /healthzport: 10259scheme: HTTPS   # 指定协议是https，因为是探针访scheduler，需要双向认证，所以是httpsinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15

生存性探针含义解释：通过发送 https://127.0.0.1:10259/health 来验证 scheduler 是否存活，因为这个 探针是配置在 yaml 文件中，yaml 是容器化启动，就是访问容器内的启动进程的 10259 的 health 接口。整个探针 scheduler 运行长时间生效，如果失败，报错 unlive 当前不可活，可以使用 kubectl describe pod pod-name 看到

Scheduler其他参数

  - command:- kube-scheduler- --bind-address=127.0.0.1   # 这两个属性表示scheduler Pod映射到宿主机的ip和端口- --port=0   #  这里为 0，则根本不提供 HTTPS。- --leader-elect=true  

command 表示命令，就是镜像启动命令，执行的是 kube-scheduler 二进制文件，后面的都是这个 kube-scheduler 二进制文件的启动参数。

–bind-address string 默认值：0.0.0.0
监听 --secure-port 端口的 IP 地址。 集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。 如果为空，将使用所有接口（0.0.0.0 表示使用所有 IPv4 接口，“::” 表示使用所有 IPv6 接口）。 如果为空或未指定地址 (0.0.0.0 或 :😃，所有接口将被使用。

–secure-port int 默认值：10259
通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。

[root@w1 ~]# netstat -ntlp | grep schedul
tcp        0      0 127.0.0.1:10259         0.0.0.0:*               LISTEN      85344/kube-schedule 

–leader-elect 默认值：true
在执行主循环之前，开始领导者选举并选出领导者。 如果 scheduler 需要使用多副本来实现高可用性时，可启用此标志。

要想知道这些参数每个代表什么意思，可以查看 k8s 官网 K8S官网Scheduler参数

Scheduler其他配置项

    resources:requests:cpu: 100m   # 每个Container至少需要 0.1 个CPUhostNetwork: true  # ip为Pod所在宿主机IP,容器端口直接映射到宿主机priorityClassName: system-node-critical  # 这个Pod优先调度，因为是kube-system里面的静态Pod

三、Controller-Manager Yaml文件解析

[root@w1 ~]# cat /etc/kubernetes/manifests/kube-controller-manager.yaml 
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:component: kube-controller-managertier: control-planename: kube-controller-managernamespace: kube-system
spec:containers:- command:- kube-controller-manager- --allocate-node-cidrs=true- --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf- --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf- --bind-address=127.0.0.1- --client-ca-file=/etc/kubernetes/pki/ca.crt- --cluster-cidr=10.244.0.0/16- --cluster-name=kubernetes- --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt- --cluster-signing-key-file=/etc/kubernetes/pki/ca.key- --controllers=*,bootstrapsigner,tokencleaner- --kubeconfig=/etc/kubernetes/controller-manager.conf- --leader-elect=true- --port=0- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt- --root-ca-file=/etc/kubernetes/pki/ca.crt- --service-account-private-key-file=/etc/kubernetes/pki/sa.key- --service-cluster-ip-range=10.96.0.0/12- --use-service-account-credentials=trueimage: k8s.gcr.io/kube-controller-manager:v1.21.0imagePullPolicy: IfNotPresentlivenessProbe:failureThreshold: 8httpGet:host: 127.0.0.1path: /healthzport: 10257scheme: HTTPSinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15name: kube-controller-managerresources:requests:cpu: 200mstartupProbe:failureThreshold: 24httpGet:host: 127.0.0.1path: /healthzport: 10257scheme: HTTPSinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15volumeMounts:- mountPath: /etc/ssl/certsname: ca-certsreadOnly: true- mountPath: /etc/pkiname: etc-pkireadOnly: true- mountPath: /usr/libexec/kubernetes/kubelet-plugins/volume/execname: flexvolume-dir- mountPath: /etc/kubernetes/pkiname: k8s-certsreadOnly: true- mountPath: /etc/kubernetes/controller-manager.confname: kubeconfigreadOnly: truehostNetwork: truepriorityClassName: system-node-criticalvolumes:- hostPath:path: /etc/ssl/certstype: DirectoryOrCreatename: ca-certs- hostPath:path: /etc/pkitype: DirectoryOrCreatename: etc-pki- hostPath:path: /usr/libexec/kubernetes/kubelet-plugins/volume/exectype: DirectoryOrCreatename: flexvolume-dir- hostPath:path: /etc/kubernetes/pkitype: DirectoryOrCreatename: k8s-certs- hostPath:path: /etc/kubernetes/controller-manager.conftype: FileOrCreatename: kubeconfig
status: {}

Controller-Manager 证书配置

cat /etc/kubernetes/manifests/kube-controller-manager.yaml  # 所需要在证书都在 /etc/kubernetes/controller-manager.conf- command:- kube-controller-manager- --kubeconfig=/etc/kubernetes/controller-manager.conf  # kubeconfig- --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf  # 认证使用的kubeconfig- --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf # 授权使用的kubeconfig- --root-ca-file=/etc/kubernetes/pki/ca.crt  # 根 ca 证书- --client-ca-file=/etc/kubernetes/pki/ca.crt # 客户端 ca 证书 - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt # 集群签名证书- --cluster-signing-key-file=/etc/kubernetes/pki/ca.key  # 集群签名密钥- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt # 请求头，代理根证书- --service-account-private-key-file=/etc/kubernetes/pki/sa.key  # control-manager使用sa.key,kube-apiserver使用sa.pub

controller-manager.conf文件: controller-manager用来访问apiserver，内容包括 client.crt client.key
sa.key文件:

涉及的文件

    volumeMounts: # 容器目录- mountPath: /etc/ssl/certs  # 步骤5：这个目录是linux机器的ssl认证 (http+ssl/tls=https)name: ca-certsreadOnly: true- mountPath: /etc/pki   # 步骤4：这个目录是linux机器的证书name: etc-pkireadOnly: true- mountPath: /usr/libexec/kubernetes/kubelet-plugins/volume/exec # 步骤3：宿主机->容器，/nodeagent~uds/uds文件name: flexvolume-dir- mountPath: /etc/kubernetes/pki  # 步骤2：宿主机 -> 容器name: k8s-certsreadOnly: true- mountPath: /etc/kubernetes/controller-manager.conf  # 步骤1:宿主机 -> 容器, controller-manager访问apiservername: kubeconfigreadOnly: truevolumes: # 宿主机目录- hostPath:path: /etc/ssl/certstype: DirectoryOrCreatename: ca-certs- hostPath:path: /etc/pki   type: DirectoryOrCreatename: etc-pki- hostPath:path: /usr/libexec/kubernetes/kubelet-plugins/volume/exectype: DirectoryOrCreatename: flexvolume-dir- hostPath:path: /etc/kubernetes/pkitype: DirectoryOrCreatename: k8s-certs- hostPath:path: /etc/kubernetes/controller-manager.conftype: FileOrCreatename: kubeconfig

Controller-Manager 两种探针

启动探针

startupProbe:failureThreshold: 24httpGet:host: 127.0.0.1path: /healthzport: 10257scheme: HTTPS # initialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15

启动探针含义解释：通过发送 https://127.0.0.1:10257/health 来验证 controller-manager 是否已经启动了，启动探针仅仅启动的时候用到

生存性探针

livenessProbe:failureThreshold: 8httpGet:host: 127.0.0.1path: /healthzport: 10257scheme: HTTPS # initialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15

生存性探针含义解释：通过发送 https://127.0.0.1:10257/health 来验证 controller-manager 是否存活，因为这个 探针是配置在 yaml 文件中，yaml 是容器化启动，就是访问容器内的启动进程的 10257 的 health 接口。整个探针 controller-manager 运行长时间生效，如果失败，报错 unlive 当前不可活，可以使用 kubectl describe pod pod-name 看到

Controller-Manager其他参数

  - command:- kube-controller-manager# 管理的Pod的CIDR范围- --allocate-node-cidrs=true- --cluster-cidr=10.244.0.0/16- --service-cluster-ip-range=10.96.0.0/12- --bind-address=127.0.0.1- --port=0   # 使用0关闭端口- --cluster-name=kubernetes- --controllers=*,bootstrapsigner,tokencleaner- --leader-elect=true- --use-service-account-credentials=true

command 表示命令，就是镜像启动命令，执行的是 kube-controller-manager 二进制文件，后面的都是这个 kube-controller-manager 二进制文件的启动参数。

管理的Pod的CIDR范围

–allocate-node-cidrs
基于云驱动来为 Pod 分配和设置子网掩码。

–cluster-cidr string
集群中 Pod 的 CIDR 范围。要求 --allocate-node-cidrs 标志为 true。

–service-cluster-ip-range string
集群中 Service 对象的 CIDR 范围。要求 --allocate-node-cidrs 标志为 true。

例如，执行 kubeadm init --kubernetes-version=1.21.0 --apiserver-advertise-address=192.168.100.155 --pod-network-cidr=10.244.0.0/16 --service-cidr=10.96.0.0/12 这里设置了集群中Pod的 cidr 和 service cidr

kubeadm init --kubernetes-version=v1.21.0 --pod-network-cidr=10.244.0.0/16 --service-cidr=10.96.0.0/12 --ignore-preflight-errors=Swap

例如，在使用 Calico 作为 Kubernetes 集群的网络插件时，可以使用以下 YAML 文件来配置 ippool 选项：

apiVersion: projectcalico.org/v3
kind: IPPool
metadata:name: myippool
spec:cidr: 192.168.0.0/16ipipMode: AlwaysnatOutgoing: true

上述配置文件定义了一个名为 myippool 的 IP 地址池，CIDR 为 192.168.0.0/16。在配置时，需要确保 cluster-cidr 参数和 ippool 中的 CIDR 值不发生冲突，以避免网络配置冲突问题。

controller-manager 的 cluster-cidr 参数和 calico中的ippool 到底哪个才是具体Pod的IP范围

实际上，cluster-cidr 和 ippool 都可以用来指定 Kubernetes 集群中 Pod 的 IP 地址范围。

cluster-cidr 是 Kubernetes 中的一个参数，用于指定 Pod 网络的 IP 地址范围，通常会在 kube-controller-manager 中进行配置。例如：

Copy
kube-controller-manager --cluster-cidr=10.244.0.0/16
这时，Kubernetes 将会为集群内的每个 Node 分配一个 IP 地址，从而为其上运行的 Pod 分配 IP 地址。

在使用 Calico 作为网络插件时，可以使用 ippool 对象来进一步控制 IP 地址的分配行为。 ippool 定义了一个 IP 地址池，其中可以指定可用的 IP 地址范围及其属性，如掩码、路由等。例如：

Copy
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
name: myippool
spec:
cidr: 10.0.0.0/16
在这个例子中，Calico 使用 IP 地址池 myippool 来分配 IP 地址。该 IP 地址池定义了一个 CIDR 值为 10.0.0.0/16，这意味着分配给 Pod 的 IP 地址将位于该范围内。

因此，cluster-cidr 和 ippool 都可以用来指定 Kubernetes 集群中 Pod 的 IP 地址范围。但是，cluster-cidr 更加通用，而 ippool 则提供了更精细的 IP 地址池控制能力。

controller-manager监听的IP地址和端口

–bind-address string 默认值：0.0.0.0
针对 --secure-port 端口上请求执行监听操作的 IP 地址。 所对应的网络接口必须从集群中其它位置可访问（含命令行及 Web 客户端）。 如果此值为空或者设定为非特定地址（0.0.0.0 或 ::）， 意味着所有网络接口都在监听范围。

–secure-port int 默认值：10257
在此端口上提供 HTTPS 身份认证和鉴权操作。若此标志值为 0，则不提供 HTTPS 服务。

[root@w1 ~]# netstat -ntlp | grep control
tcp        0      0 127.0.0.1:10257         0.0.0.0:*               LISTEN      98566/kube-controll 

scheduler 端口是 10259 ，controller-manager 端口是 10257

–cluster-name string 默认值：“kubernetes”
集群实例的前缀。

–controllers strings 默认值：*
要启用的控制器列表。* 表示启用所有默认启用的控制器； foo 启用名为 foo 的控制器； -foo 表示禁用名为 foo 的控制器。
控制器的全集：attachdetach、bootstrapsigner、cloud-node-lifecycle、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、endpointslice、endpointslicemirroring、ephemeral-volume、garbagecollector、horizontalpodautoscaling、job、namespace、nodeipam、nodelifecycle、persistentvolume-binder、persistentvolume-expander、podgc、pv-protection、pvc-protection、replicaset、replicationcontroller、resourcequota、root-ca-cert-publisher、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner、ttl、ttl-after-finished
默认禁用的控制器有：bootstrapsigner 和 tokencleaner。

–leader-elect 默认值：true
在执行主循环之前，启动领导选举（Leader Election）客户端，并尝试获得领导者身份。 在运行多副本组件时启用此标志有助于提高可用性。

–use-service-account-credentials
当此标志为 true 时，为每个控制器单独使用服务账号凭据。

要想知道这些参数每个代表什么意思，可以查看 k8s 官网 K8S官网ControllerManager介绍

Controller-Manager其他配置项

    name: kube-controller-managerresources:requests:cpu: 200m   # 每个Container至少需要 0.2 个CPUhostNetwork: true   # ip为Pod所在宿主机IP,容器端口直接映射到宿主机priorityClassName: system-node-critical  # 这个Pod优先调度，因为是kube-system里面的静态Pod

四、Etcd Yaml文件解析

Etcd证书文件

Etcd 组件两个数据交互：
(1) Etcd对外提供服务，其实就是 Kube-APIserver访问Etcd， 要有一套etcd server证书和apiserver访问etcd的客户端证书 【涉及文件：etcd server.key server.crt，apiserver 的 apiserver-etcd-client.key 和 apiserver-etcd-client.crt 】
(2) Etcd各主节点之间进行通信，要有一套etcd peer证书 【涉及文件：peer.key peer.crt 】

cat /etc/kubernetes/manifests/etcd.yaml  所需要在证书都在 /etc/kubernetes/pki/etcd 目录下- command:- etcd- --cert-file=/etc/kubernetes/pki/etcd/server.crt  # etcd唯一的对外提供服务, apiserver访问etcd- --key-file=/etc/kubernetes/pki/etcd/server.key # etcd唯一的对外提供服务, apiserver访问etcd- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt # # 用来验证etcd服务端证书的ca证书- --peer-client-cert-auth=true  # etcd各主节点之间相互通信 true- --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt  # etcd各主节点之间相互通信- --peer-key-file=/etc/kubernetes/pki/etcd/peer.key  # etcd各主节点之间相互通信- --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt  # 用来验证etcd各主节点之间相互通信证书的ca证书 peer.key peer.crt

涉及的文件

    volumeMounts:- mountPath: /var/lib/etcd   # 步骤2：运行过程中，将 etcd 的数据持久化到磁盘name: etcd-data- mountPath: /etc/kubernetes/pki/etcd   # 步骤1：启动的时候，将etcd需要的证书刷入的容器里name: etcd-certsvolumes:- hostPath:path: /etc/kubernetes/pki/etcdtype: DirectoryOrCreatename: etcd-certs- hostPath:path: /var/lib/etcdtype: DirectoryOrCreatename: etcd-data

Etcd两种探针

启动探针

startupProbe:failureThreshold: 24httpGet:host: 127.0.0.1path: /healthport: 2381scheme: HTTP  # 指定协议为http，自己访问自己 127.0.0.1，这里不是 https 了initialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15

启动探针含义解释：通过发送 http://127.0.0.1:2381/health 来验证 etcd 是否已经启动了，启动探针仅仅启动的时候用到

生存性探针

livenessProbe:failureThreshold: 8httpGet:host: 127.0.0.1path: /healthport: 2381scheme: HTTP  # 指定协议为http，自己访问自己 127.0.0.1，这里不是 https 了initialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15

生存性探针含义解释：通过发送 http://127.0.0.1:2381/health 来验证 etcd 是否存活，因为这个 探针是配置在 yaml 文件中，yaml 是容器化启动，就是访问容器内的启动进程的 2381 的 health 接口。整个探针 etcd 运行长时间生效，如果失败，报错 unlive 当前不可活，可以使用 kubectl describe pod pod-name 看到

Etcd其他参数

  - command:   # 启动命令- etcd  # 二进制文件- --advertise-client-urls=https://192.168.100.151:2379- --client-cert-auth=true- --data-dir=/var/lib/etcd  # 持久化目录# 接口   - --initial-advertise-peer-urls=https://192.168.100.151:2380- --listen-peer-urls=https://192.168.100.151:2380- --initial-cluster=w1=https://192.168.100.151:2380  # - --listen-client-urls=https://127.0.0.1:2379,https://192.168.100.151:2379- --listen-metrics-urls=http://127.0.0.1:2381- --name=w1- --snapshot-count=10000

command 表示命令，就是镜像启动命令，执行的是 etcd 二进制文件，后面的都是这个 etcd 二进制文件的启动参数。

要想知道这些参数每个代表什么意思，可以查看 k8s 官网

Etcd其他配置项

    name: etcdresources:  # 资源requests: # 下限cpu: 100m   # 每个Container至少需要 0.1 个CPUephemeral-storage: 100Mi  # 每个container至少100Mi磁盘        memory: 100Mi   # 内存为100MhostNetwork: true  # ip为Pod所在宿主机IP,容器端口直接映射到宿主机priorityClassName: system-node-critical # 这个Pod优先调度，因为是kube-system里面的静态Pod

ephemeral-storage: 100Mi

每个container至少100Mi磁盘，因为etcd是分布式数据库，存储configmap和secret 到 /var/lib/etcd 目录 ，存储会被持久化到宿主机，所以需要定义一个磁盘空间下限，其他三个 apiserver scheduler kube-controller-manager 都是因为不需要存储数据，所以不定义磁盘空间

参考资料：ephemeral-storage 介绍

Etcd 进程

上面是 etcd 的证书，我们现在来看一下 etcd 的进程， etcd 作为四个静态Pod之一，是运行在 master 节点之上的，我们在 master 节点的宿主机上执行 ps -ef | grep etcd，如下：

如上图，执行 ps -ef | grep etcd 之后，打印出来不止一条，其中有些不是etcd的，只是包含 etcd 关键字，解释一下找到的四条包含 etcd 关键字的进程：
第一个是 etcd Pod Container对应的进程 (只有这条是 etcd 进程本身)，
第二个是 apiserver Pod Container对应的进程，
第三个是 kuboard Pod Container对应的进程，
第四个就是 ps -ef|grep etcd 这行命令本身。

知识点(上图中四行输出怎么看出来的)：
(1) 对于 k8s Pod Container 容器化程序启动的，使用 ps -ef 也是可以在Pod 所在 linux 上看到yaml里面的参数和启动命令，至于到底是哪个，直接查看输出的 CMD 列第一个二进制文件名或者最后一个 xxx.yaml 名基本就可以判断出了
(2) ps -ef|grep xxx 查看到的结果，其中有一个就是 ps -ef | grep xxx 这条命令本身

尾声

对于四个静态Pod，每个静态Pod，分别介绍了 证书和组件交互、探针、其他参数、其他配置项。

各个组件监听的端口

[root@w1 ~]# netstat -ntlp | grep kube
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:10248         0.0.0.0:*               LISTEN      79436/kubelet       
tcp        0      0 127.0.0.1:33613         0.0.0.0:*               LISTEN      79436/kubelet       
tcp6       0      0 :::10250                :::*                    LISTEN      79436/kubelet       
# 小结：PID相同，kubelet服务只有一个进程，但占用三个端口Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN      2627/kube-proxy     
tcp6       0      0 :::10256                :::*                    LISTEN      2627/kube-proxy  
# 小结：PID相同，kube-proxy只有一个进程，但占用两个端口Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:10257         0.0.0.0:*               LISTEN      98566/kube-controll 
tcp        0      0 127.0.0.1:10259         0.0.0.0:*               LISTEN      85344/kube-schedule 
# kube-apiserver只剩下 secure-port 6443, insecure-port 端口已经没有了
tcp6       0      0 :::6443                 :::*                    LISTEN      98921/kube-apiserve 

证书方面：基本是按照 k8s 内部组件交互图来的

探针方面：除了apiserver使用 192.168.100.151 宿主机上的 6443 为探针，其他三个静态Pod都使用自己访问自己 127.0.0.1:port/health 作为探针.

其他参数方面：基本查看 k8s 官网就可以了，见 组件工具

其他配置项方面：
(1) 资源下限方面，只有 etcd 为了给宿主机持久化 /var/lib/etcd 目录下的数据，对磁盘做了下限要求，其他三个静态Pod仅仅对cpu和内存要求
(2) hostNetwork: true 表示Pod IP使用宿主机IP, 端口直接映射到Pod所在宿主机的端口，DNS也是使用宿主机的DNS解析，为了让能够同时解析 serviceName.ns d需要设置为 dnsPolicy: ClusterFirstWithHost
(3) priorityClassName: system-node-critical 将四个静态Pod都设置为优先调度，因为是kube-system里面的静态Pod

最后，四个静态Pod的启动文件在这里，修改并 :wq 保存就可以生效，

[root@w1 ~]# cd /etc/kubernetes/manifests/
[root@w1 manifests]# ll
总用量 16
-rw-------. 1 root root 2187 4月  17 16:21 etcd.yaml
-rw-------. 1 root root 3287 5月  16 00:59 kube-apiserver.yaml
-rw-------. 1 root root 2798 4月  17 16:21 kube-controller-manager.yaml
-rw-------. 1 root root 1384 4月  17 16:21 kube-scheduler.yaml

但是 kube-system 中还有三个网络相关的 Pod ，分别 kube-proxy coredns calico ，还有一个守护进程 kubelet ，它启动配置文件又在哪里。calico的yaml文件是额外apply的，不属于k8s管理，不必多说，可以查看 容器网络 章节；kubelet 有专门的一篇文章，coredns和kube-proxy的启动文件确实找不到，但是可以从当前的运行的控制器/Pod查看，也有专门的文章。