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

rwby高达eva

于 2024-07-14 02:16:31 发布

点赞数

文章标签： kubernetes 容器云原生

文章目录

前言
一、APIServer Yaml文件解析

APIServer证书文件
APIServer三种探针

启动探针
可读性探针
生存性探针

APIServer其他参数
APIServer其他配置项

二、Scheduler Yaml文件解析

Scheduler证书配置
Scheduler两个探针

启动探针
生存性探针

Scheduler其他参数
Scheduler其他配置项

三、Controller-Manager Yaml文件解析

Controller-Manager 证书配置
Controller-Manager 两种探针

启动探针
生存性探针

Controller-Manager其他参数
Controller-Manager其他配置项

四、Etcd Yaml文件解析

Etcd证书文件
Etcd两种探针

启动探针
生存性探针

Etcd其他参数
Etcd其他配置项
Etcd 进程

尾声

前言

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:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: 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.key
    image: k8s.gcr.io/kube-apiserver:v1.21.0   # 镜像
    imagePullPolicy: IfNotPresent  # 镜像拉取策略，如果本地不存在就拉取  IfNotPresent Always Never
    livenessProbe:      # 生存性探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)
      failureThreshold: 8
      httpGet:
        host: 192.168.100.155
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-apiserver   # pod的名称
    readinessProbe:    # 可读性探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)
      failureThreshold: 3
      httpGet:
        host: 192.168.100.155
        path: /readyz
        port: 6443
        scheme: HTTPS
      periodSeconds: 1
      timeoutSeconds: 15
    resources:   # 资源请求量，request下限，limit上限，scheduler根据request对比机器上的free来调度，hpa根据 top metrics 自动扩缩容
      requests:
        cpu: 250m
    startupProbe:   # 启动探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)  
      failureThreshold: 24
      httpGet:
        host: 192.168.100.155
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:  # 目录挂载
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
    - mountPath: /etc/kubernetes/pki   # 所有的证书，都从宿主机读入到apiserver容器里面去
      name: k8s-certs
      readOnly: true
  hostNetwork: true   
  priorityClassName: system-node-critical
  volumes:
  - hostPath:
      path: /etc/ssl/certs   #  这个目录不存在
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/pki     #  这个目录不存在
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /etc/kubernetes/pki   #  这个目录存在，所有的证书，都从宿主机读入到apiserver容器里面去
      type: DirectoryOrCreate
    name: k8s-certs
status: {}

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.

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/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
    - mountPath: /etc/kubernetes/pki   # 所有的证书，都从宿主机读入到apiserver容器里面去
      name: k8s-certs
      readOnly: true
  volumes: # 宿主机目录
  - hostPath:
      path: /etc/ssl/certs   #  这个目录是linux机器的ssl认证 (http+ssl/tls=https)
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/pki     #  这个目录是linux机器的证书
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /etc/kubernetes/pki   #  这个目录存在，所有的证书，都从宿主机读入到apiserver容器里面去
      type: DirectoryOrCreate
    name: k8s-certs

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

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

APIServer三种探针

apiserver的健康检查

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

启动探针

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

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

可读性探针

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

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

生存性探针

livenessProbe:      # 生存性探针(生存性探针和可读性探针整个过程中运行，启动探针仅仅启动的时候用到)
  failureThreshold: 8
  httpGet:
    host: 192.168.100.155
    path: /livez
    port: 6443
    scheme: HTTPS # 指定协议是https，因为是探针访问apiserver，需要双向认证，所以是https
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 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 或 ::），则将使用所有接口。

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

如上图，当 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 引导身份验证。

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

特权容器

–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个cpu
  hostNetwork: 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: null
  labels:
    component: kube-scheduler
    tier: control-plane
  name: kube-scheduler
  namespace: 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=0
    image: k8s.gcr.io/kube-scheduler:v1.21.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 127.0.0.1
        path: /healthz
        port: 10259
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-scheduler
    resources:
      requests:
        cpu: 100m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 127.0.0.1
        path: /healthz
        port: 10259
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/kubernetes/scheduler.conf
      name: kubeconfig
      readOnly: true
  hostNetwork: true
  priorityClassName: system-node-critical
  volumes:
  - hostPath:
      path: /etc/kubernetes/scheduler.conf
      type: FileOrCreate
    name: 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: kubeconfig
      readOnly: true
  volumes: # 宿主机中目录
  - hostPath:
      path: /etc/kubernetes/scheduler.conf
      type: FileOrCreate
    name: kubeconfig

Scheduler两个探针

启动探针

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

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

生存性探针

livenessProbe:
  failureThreshold: 8
  httpGet:
    host: 127.0.0.1
    path: /healthz
    port: 10259
    scheme: HTTPS   # 指定协议是https，因为是探针访scheduler，需要双向认证，所以是https
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 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 个CPU
  hostNetwork: 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: null
  labels:
    component: kube-controller-manager
    tier: control-plane
  name: kube-controller-manager
  namespace: 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=true
    image: k8s.gcr.io/kube-controller-manager:v1.21.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 127.0.0.1
        path: /healthz
        port: 10257
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-controller-manager
    resources:
      requests:
        cpu: 200m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 127.0.0.1
        path: /healthz
        port: 10257
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
    - mountPath: /usr/libexec/kubernetes/kubelet-plugins/volume/exec
      name: flexvolume-dir
    - mountPath: /etc/kubernetes/pki
      name: k8s-certs
      readOnly: true
    - mountPath: /etc/kubernetes/controller-manager.conf
      name: kubeconfig
      readOnly: true
  hostNetwork: true
  priorityClassName: system-node-critical
  volumes:
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/pki
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /usr/libexec/kubernetes/kubelet-plugins/volume/exec
      type: DirectoryOrCreate
    name: flexvolume-dir
  - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate
    name: k8s-certs
  - hostPath:
      path: /etc/kubernetes/controller-manager.conf
      type: FileOrCreate
    name: 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-certs
      readOnly: true
    - mountPath: /etc/pki   # 步骤4：这个目录是linux机器的证书
      name: etc-pki
      readOnly: true
    - mountPath: /usr/libexec/kubernetes/kubelet-plugins/volume/exec # 步骤3：宿主机->容器，/nodeagent~uds/uds文件
      name: flexvolume-dir
    - mountPath: /etc/kubernetes/pki  # 步骤2：宿主机 -> 容器
      name: k8s-certs
      readOnly: true
    - mountPath: /etc/kubernetes/controller-manager.conf  # 步骤1:宿主机 -> 容器, controller-manager访问apiserver
      name: kubeconfig
      readOnly: true
  volumes: # 宿主机目录
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/pki   
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /usr/libexec/kubernetes/kubelet-plugins/volume/exec
      type: DirectoryOrCreate
    name: flexvolume-dir
  - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate
    name: k8s-certs
  - hostPath:
      path: /etc/kubernetes/controller-manager.conf
      type: FileOrCreate
    name: kubeconfig

Controller-Manager 两种探针

启动探针

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

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

生存性探针

livenessProbe:
  failureThreshold: 8
  httpGet:
    host: 127.0.0.1
    path: /healthz
    port: 10257
    scheme: HTTPS # 
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 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/16
  ipipMode: Always
  natOutgoing: 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 地址池控制能力。

–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-manager
    resources:
      requests:
        cpu: 200m   # 每个Container至少需要 0.2 个CPU
  hostNetwork: 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-certs
  volumes:
  - hostPath:
      path: /etc/kubernetes/pki/etcd
      type: DirectoryOrCreate
    name: etcd-certs
  - hostPath:
      path: /var/lib/etcd
      type: DirectoryOrCreate
    name: etcd-data

Etcd两种探针

启动探针

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

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

生存性探针

livenessProbe:
  failureThreshold: 8
  httpGet:
    host: 127.0.0.1
    path: /health
    port: 2381
    scheme: HTTP  # 指定协议为http，自己访问自己 127.0.0.1，这里不是 https 了
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 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: etcd
    resources:  # 资源
      requests: # 下限
        cpu: 100m   # 每个Container至少需要 0.1 个CPU
        ephemeral-storage: 100Mi  # 每个container至少100Mi磁盘        memory: 100Mi   # 内存为100M
  hostNetwork: 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，如下：

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

如上图，执行 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 官网就可以了，见组件工具

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

其他配置项方面：
(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查看，也有专门的文章。

原创作者: u_15287666 转载于: https://blog.51cto.com/u_15287666/11443681

rwby高达eva

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Kubernetes_APIServer_证书_03_四个静态Pod Yaml文件解析

文章目录前言一、APIServer Yaml文件解析APIServer证书文件APIServer三种探针启动探针可读性探针生存性探针APIServer其他参数APIServer其他配置项二、Scheduler Yaml文件解析Scheduler证书配置Scheduler两个探针启动探针生存性探针Scheduler其他参数...
复制链接

扫一扫