K8s基础知识学习笔记及部分源码剖析

在学习b站黑马k8s视频资料的基础上，查阅了配套基础知识笔记和源码剖析，仅作个人学习和回顾使用。

参考资料：

概念 | Kubernetes

四层、七层负载均衡的区别 - Perfectionist - 博客园 (cnblogs.com)

kube-apiserver 的设计与实现 · 田飞雨 (tianfeiyu.com)

Kubernetes(K8S) 入门进阶实战完整教程，黑马程序员K8S全套教程（基础+高级）_哔哩哔哩_bilibili

k8s基础知识学习配套黑马_just_be_brave的博客-CSDN博客

文章目录

K8s基础知识学习笔记及部分源码剖析
- 命令
- - 1 explain
  - 2 label
- Pod
- - 1 镜像拉取策略
  - 2 docker进入容器的命令
  - 3 钩子函数
Pod调度
- 1 定向调度
- 2 亲和性调度
- - 2.1 nodeAffinity
  - 2.2 podAffinity
  - 2.3 podAntiAffinity
- 3 污点和容忍
- - 污点（taints）
  - 容忍（tolerations）
Pod调度器Scheduler
- 1 Scheduler结构体
- - 1.1 SchedulerCache
  - 1.2 SchedulerAlgorithm
  - 1.3 NextPod
Pod控制器
- ReplicaSet
- Deployment
- Horizontal Pod Autoscaler（HPA）
- DaemonSet(DS)
- Job
- CronJob
Service
- 1 概念
- 2 资源清单
- 3 HeadLiness
- 4 Nodeport
- 5 ExternalName
补充：四层、七层负载均衡
Ingress
- Http代理
- Https代理
Volume
- EmptyDir
- HostPath
- NFS
- PV和PVC
- - 1 PV
  - 2 PVC
  - 3 Pod使用
  - 4 PV和PVC的生命周期
- 配置存储
- - ConfigMap
  - Secret
安全认证
- 认证管理
- 授权管理
- - Role、ClusterRole
  - RoleBinding、ClusterRoleBinding
kube-apiserver 启动流程分析
- kube-apiserver的组件
- main
- NewAPIserverCommand
- - Complete
- Run
- - CreateServerChain

命令

1 explain

kubectl explain pod

2 label

get标签：

kubectl get pod --show-labels

注意是labels不是label。

打标签：

kubectl label pod <poname> -n <nsname> version=1.0 --overwrite

为名称空间下的pod打上version=1.0的标签，注意–overwrite不能丢。

删除标签：

kubectl label pod <poname> -n <nsname> version-

删除pod上version的标签。

选择器：

kubectl get pod -l "version=1.0" -n <nsname> --show-labels

选择命名空间中pod带有version=1.0标签的pod。

Pod

1 镜像拉取策略

imagePullPolicy      <string>Image pull policy. One of Always, Never, IfNotPresent. Defaults to Alwaysif :latest tag is specified, or IfNotPresent otherwise. Cannot be updated.

2 docker进入容器的命令

# 进入pod中的busybox容器，查看文件内容
# 补充一个命令: kubectl exec pod名称 -n 命名空间 -it -c 容器名称 /bin/sh  在容器内部执行命令
# 使用这个命令就可以进入某个容器的内部，然后进行相关操作了
# 比如，可以查看txt文件的内容
[root@k8s-master01 pod]# kubectl exec pod-command -n dev -it -c busybox /bin/sh

-it 交互式，-c管理员

利用了docker中的配置：

特别说明：
通过上面发现command已经可以完成启动命令和传递参数的功能，为什么这里还要提供一个args选项，用于传递参数呢?这其实跟docker有点关系，kubernetes中的command、args两项其实是实现覆盖Dockerfile中ENTRYPOINT的功能。1 如果command和args均没有写，那么用Dockerfile的配置。2 如果command写了，但args没有写，那么Dockerfile默认的配置会被忽略，执行输入的command3 如果command没写，但args写了，那么Dockerfile中配置的ENTRYPOINT的命令会被执行，使用当前args的参数4 如果command和args都写了，那么Dockerfile的配置被忽略，执行command并追加上args参数

3 钩子函数

钩子函数能够感知自身生命周期中的事件（时间点），并在相应的时刻到来时运行用户指定的程序代码。

kubernetes在主容器的启动之后和停止之前提供了两个钩子函数：

post start：容器创建之后执行，如果失败了会重启容器。
pre stop：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作。

Pod调度

1 定向调度

定向调度，指的是利用在pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过pod运行失败而已。

NodeName用于强制约束将Pod调度到指定的Name的Node节点上。这种方式，其实是直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。

apiVersion: v1
kind: Pod
metadata:name: pod-nodenamenamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1nodeName: node1 # 指定调度到node1节点上

NodeSelector用于将pod调度到添加了指定标签的node节点上。它是通过kubernetes的label-selector机制实现的，也就是说，在pod创建之前，会由Scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node，然后将pod调度到目标节点，该匹配规则是强制约束。

apiVersion: v1
kind: Pod
metadata:name: pod-nodeselectornamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1nodeSelector: nodeenv: pro # 指定调度到具有nodeenv=pro标签的节点上

2 亲和性调度

Affinity主要分为三类：

nodeAffinity(node亲和性）: 以node为目标，解决pod可以调度到哪些node的问题
podAffinity(pod亲和性) : 以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
podAntiAffinity(pod反亲和性) : 以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题

2.1 nodeAffinity

查看配置项：

pod.spec.affinity.nodeAffinityrequiredDuringSchedulingIgnoredDuringExecution  Node节点必须满足指定的所有规则才可以，硬限制nodeSelectorTerms  节点选择列表matchFields   按节点字段列出的节点选择器要求列表matchExpressions   按节点标签列出的节点选择器要求列表(推荐)key    键values 值operator 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, LtpreferredDuringSchedulingIgnoredDuringExecution 优先调度到满足指定的规则的Node，软限制 (倾向)preference   一个节点选择器项，与相应的权重相关联matchFields   按节点字段列出的节点选择器要求列表matchExpressions   按节点标签列出的节点选择器要求列表(推荐)key    键values 值operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Ltweight 倾向权重，在范围1-10

关系符使用说明：

- matchExpressions:- key: nodeenv              # 匹配存在标签的key为nodeenv的节点operator: Exists- key: nodeenv              # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点operator: Invalues: ["xxx","yyy"]- key: nodeenv              # 匹配标签的key为nodeenv,且value大于"xxx"的节点operator: Gtvalues: "xxx"

样例：

apiVersion: v1
kind: Pod
metadata:name: pod-nodeaffinity-requirednamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1affinity:  #亲和性设置nodeAffinity: #设置node亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制nodeSelectorTerms:- matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签- key: nodeenvoperator: Invalues: ["xxx","yyy"]

样例：

apiVersion: v1
kind: Pod
metadata:name: pod-nodeaffinity-preferrednamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1affinity:  #亲和性设置nodeAffinity: #设置node亲和性preferredDuringSchedulingIgnoredDuringExecution: # 软限制- weight: 1preference:matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签(当前环境没有)- key: nodeenvoperator: Invalues: ["xxx","yyy"]

NodeAffinity规则设置的注意事项：

NodeAffinity规则设置的注意事项：
1 如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能运行在指定的Node上
2 如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可
3 如果一个nodeSelectorTerms中有多个matchExpressions ，则一个节点必须满足所有的才能匹配成功
4 如果一个pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的节点亲和性需求，则系统将忽略此变化

2.2 podAffinity

查看配置项：

pod.spec.affinity.podAffinityrequiredDuringSchedulingIgnoredDuringExecution  硬限制namespaces       指定参照pod的namespacetopologyKey      指定调度作用域labelSelector    标签选择器matchExpressions  按节点标签列出的节点选择器要求列表(推荐)key    键values 值operator 关系符 支持In, NotIn, Exists, DoesNotExist.matchLabels    指多个matchExpressions映射的内容preferredDuringSchedulingIgnoredDuringExecution 软限制podAffinityTerm  选项namespaces      topologyKeylabelSelectormatchExpressions  key    键values 值operatormatchLabels weight 倾向权重，在范围1-100

topologyKey用于指定调度时作用域,例如：
如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围
如果指定为beta.kubernetes.io/os,则以Node节点的操作系统类型来区分

样例：

apiVersion: v1
kind: Pod
metadata:name: pod-podaffinity-requirednamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1affinity:  #亲和性设置podAffinity: #设置pod亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签- key: podenvoperator: Invalues: ["xxx","yyy"]topologyKey: kubernetes.io/hostname

2.3 podAntiAffinity

PodAntiAffinity主要实现以运行的Pod为参照，让新创建的Pod跟参照pod不在一个区域中的功能。它的配置方式和选项跟PodAffinty是一样的。

样例：

apiVersion: v1
kind: Pod
metadata:name: pod-podantiaffinity-requirednamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1affinity:  #亲和性设置podAntiAffinity: #设置pod反亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配podenv的值在["pro"]中的标签- key: podenvoperator: Invalues: ["pro"]topologyKey: kubernetes.io/hostname

3 污点和容忍

污点（taints）

前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来。

Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。

污点的格式为：key=value:effect, key和value是污点的标签，effect描述污点的作用，支持如下三个选项：

1 PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
2 NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
3 NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离

PreferNoSchedule:尽量不要来，除非没办法
NoSchedule：就是不准来，已经来的就算了
NoExecute：新的不要来，来的赶紧走

污点命令：

# 设置污点
kubectl taint nodes node1 key=value:effect# 去除污点
kubectl taint nodes node1 key:effect-# 去除所有污点
kubectl taint nodes node1 key-

查看污点：

 kubectl describe node 10.100.100.131-master | grep Taints:  -A1

容忍（tolerations）

我们可以在node上添加污点用于拒绝pod调度上来，但是如果就是想将一个pod调度到一个有污点的node上去，就要使用到容忍。

注意：容忍是作用在pod上的，污点是作用在node上的。

apiVersion: v1
kind: Pod
metadata:name: pod-tolerationnamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1tolerations:      # 添加容忍- key: "tag"        # 要容忍的污点的key，这里是tagoperator: "Equal" # 操作符value: "shark"    # 容忍的污点的value，这里是sharkeffect: "NoExecute"   # 添加容忍的规则，这里必须和标记的污点规则相同

容忍的配置：

kubectl explain pod.spec.tolerations
......
FIELDS:key       # 对应着要容忍的污点的键，空意味着匹配所有的键value     # 对应着要容忍的污点的值operator  # key-value的运算符，支持Equal和Exists（默认），配Exists就不用配value了effect    # 对应污点的effect，空意味着匹配所有影响tolerationSeconds   # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间

Pod调度器Scheduler

调度器监视还未被调度的新的pod，它试图去找到适合它们的node，并且将绑定信息写回api-server。

调度器中使用PodInfo来辅助pod的调度：

type PodInfo struct {Pod                        *v1.PodRequiredAffinityTerms      []AffinityTermRequiredAntiAffinityTerms  []AffinityTermPreferredAffinityTerms     []WeightedAffinityTermPreferredAntiAffinityTerms []WeightedAffinityTermParseError                 error
}

PodInfo是Pod的包装器，带有额外的预先计算的信息以加速处理。这些信息通常是不可变的(例如，预处理的pod间亲和选择器)。

亲和性调度与反亲和性调度：

// AffinityTerm is a processed version of v1.PodAffinityTerm.
type AffinityTerm struct {Namespaces        sets.StringSelector          labels.SelectorTopologyKey       stringNamespaceSelector labels.Selector
}

1 Scheduler结构体

调度器的struct结构体：

type Scheduler struct {// It is expected that changes made via SchedulerCache will be observed// by NodeLister and Algorithm.SchedulerCache internalcache.CacheAlgorithm core.ScheduleAlgorithm// NextPod should be a function that blocks until the next pod// is available. We don't use a channel for this, because scheduling// a pod may take some amount of time and we don't want pods to get// stale while they sit in a channel.NextPod func() *framework.QueuedPodInfo// Error is called if there is an error. It is passed the pod in// question, and the errorError func(*framework.QueuedPodInfo, error)// Close this to shut down the scheduler.StopEverything <-chan struct{}// SchedulingQueue holds pods to be scheduledSchedulingQueue internalqueue.SchedulingQueue// Profiles are the scheduling profiles.Profiles profile.Mapclient clientset.Interface
}

1.1 SchedulerCache

定义了一个名为SchedulerCache的 internalcache.Cache类型，其作用是期待通过SchedulerCache所做的改变将被NodeLister和Algorithm观察到。

Cache收集pod的信息，并提供节点级的聚合信息。它的目的是使得gerericScheduler做高效的查找。Cache的操作以pod为中心。它基于pod事件进行增量更新。Pod事件通过网络发送。

我们不能保证所有事件的可靠交付：我们使用Reflector从远程进行列出并监视。Reflector可能很慢，并做了一个重新列表，这将导致丢失事件。

1.2 SchedulerAlgorithm

定义了一个名为Algorithm的core.ScheduleAlgorithm类型，ScheduleAlgorithm是一个接口，由知道如何在机器上实现pod的调度。

type ScheduleAlgorithm interface {Schedule(context.Context, framework.Framework, *framework.CycleState, *v1.Pod) (scheduleResult ScheduleResult, err error)// Extenders returns a slice of extender config. This is exposed for testing.Extenders() []framework.Extender
}

返回ScheduleResult，即调度结果：

// ScheduleResult represents the result of one pod scheduled. It will contain
// the final selected Node, along with the selected intermediate information.
type ScheduleResult struct {// Name of the scheduler suggest hostSuggestedHost string// Number of nodes scheduler evaluated on one pod scheduledEvaluatedNodes int// Number of feasible nodes on one pod scheduledFeasibleNodes int
}

ScheduleResult展现了一个pod的最终调度结果，将包含最终被选择的node，以及选择的中间信息。

SuggestedHost是调度器建议的主机名，EvaluatedNodes是调度器所评估的node数量，FeasibleNodes是可行的node数量。

1.3 NextPod

NextPod应该是一个阻塞函数，直到下一个pod可用。我们不使用通道，因为安排一个pod可能需要一些时间，且我们不希望pod在一个通道中变得陈旧。NextPod函数返回一个QueuedPodInfo的指针：

// QueuedPodInfo is a Pod wrapper with additional information related to
// the pod's status in the scheduling queue, such as the timestamp when
// it's added to the queue.
type QueuedPodInfo struct {*PodInfo// The time pod added to the scheduling queue.Timestamp time.Time// Number of schedule attempts before successfully scheduled.// It's used to record the # attempts metric.Attempts int// The time when the pod is added to the queue for the first time. The pod may be added// back to the queue multiple times before it's successfully scheduled.// It shouldn't be updated once initialized. It's used to record the e2e scheduling// latency for a pod.InitialAttemptTimestamp time.Time// If a Pod failed in a scheduling cycle, record the plugin names it failed by.UnschedulablePlugins sets.String
}

QueuedPodInfo是一个Pod包装器，它具有与调度队列中Pod状态相关的附加信息，例如将Pod添加到队列时的时间戳。

Pod控制器

ReplicaSet：保证副本数量一直维持在期望值，并支持pod数量扩缩容，镜像版本升级
Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本
Horizontal Pod Autoscaler（HPA）：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷
DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务（例如：监控日志）
Job：它创建的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务（做计算或者准备资源）
Cronjob：通过控制Job来控制Pod，它创建的Pod负责周期性任务控制，不需要持续后台运行
StatefulSet：管理有状态应用

ReplicaSet

样例：

apiVersion: apps/v1
kind: ReplicaSet
metadata:name: pc-replicasetnamespace: dev
spec:replicas: 3selector: matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1

修改yaml实现扩缩容、镜像升级等：

kubectl edit rs pc-replicaset -n dev

scale命令实现扩缩容：

# 当然也可以直接使用命令实现
# 使用scale命令实现扩缩容， 后面--replicas=n直接指定目标数量即可
kubectl scale rs pc-replicaset --replicas=2 -n dev

set image命令实现镜像升级：

# kubectl set image rs rs名称 容器=镜像版本 -n namespace
[root@k8s-master01 ~]# kubectl set image rs pc-replicaset nginx=nginx:1.17.1  -n dev

Deployment

为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。值得一提的是，这种控制器并不直接管理pod，而是通过管理ReplicaSet来简介管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大。

apiVersion: apps/v1
kind: Deployment # 类型
metadata: name:namespace: labels:controller: deploy
spec: replicas: 3 # 副本数量revisionHistoryLimit: 3 # 保留历史版本，默认是10paused: false # 暂停部署，默认是falseprogressDeadlineSeconds: 600 # 部署超时时间（s），默认是600strategy: # 策略type: RollingUpdate # 滚动更新策略rollingUpdate: # 滚动更新maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数maxUnavailable: 30% # 最大不可用状态的 Pod 的最大值，可以为百分比，也可以为整数selector: # 选择器，通过它指定该控制器管理哪些podmatchLabels:      # Labels匹配规则app: nginx-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [nginx-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80

样例：

apiVersion: apps/v1
kind: Deployment
metadata:name: pc-deploymentnamespace: dev
spec: replicas: 3selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1

扩缩容

scale命令实现扩缩容：

kubectl scale deploy pc-deployment --replicas=5  -n dev

更新策略

deployment支持两种更新策略:重建更新(Recreate)和滚动更新(RollingUpdate)

可以通过strategy指定策略类型：

strategy：指定新的Pod替换旧的Pod的策略， 支持两个属性：type：指定策略类型，支持两种策略Recreate：在创建出新的Pod之前会先杀掉所有已存在的PodRollingUpdate：滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本PodrollingUpdate：当type为RollingUpdate时生效，用于为RollingUpdate设置参数，支持两个属性：maxUnavailable：用来指定在升级过程中不可用Pod的最大数量，默认为25%。maxSurge： 用来指定在升级过程中可以超过期望的Pod的最大数量，默认为25%。

版本回退

可以在创建deployment的时候加–record=true，这样可以记录操作

kubectl create -f pc-deployment.yaml --record=true

deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能：

kubectl rollout：版本升级相关功能，支持下面的选项：

status 显示当前升级状态
history 显示升级历史记录
pause 暂停版本升级过程
resume 继续已经暂停的版本升级过程
restart 重启版本升级过程
undo 回滚到上一级版本（可以使用–to-revision回滚到指定版本）

# 查看当前升级版本的状态
kubectl rollout status deploy pc-deployment -n dev# 查看升级历史记录
kubectl rollout history deploy pc-deployment -n dev# 如果在创建的时候不加--record=true，就只能看到REVISION
REVISION  CHANGE-CAUSE
1         kubectl create --filename=pc-deployment.yaml --record=true
2         kubectl create --filename=pc-deployment.yaml --record=true
3         kubectl create --filename=pc-deployment.yaml --record=true# 版本回滚
# 这里直接使用--to-revision=1回滚到了1版本，如果省略这个选项，就是回退到上个版本，就是2版本
kubectl rollout undo deployment pc-deployment --to-revision=1 -n dev

其实deployment之所以可是实现版本的回滚，就是通过记录下历史rs来实现的，一旦想回滚到哪个版本，只需要将当前版本pod数量降为0，然后将回滚版本的pod提升为目标数量就可以了。

金丝雀发布（灰度发布）

Deployment控制器支持控制更新过程中的控制，如“暂停(pause)”或“继续(resume)”更新操作。

比如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

# 更新deployment的版本，并配置暂停deployment
kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment  -n dev

Horizontal Pod Autoscaler（HPA）

可以通过手工执行kubectl scale命令实现Pod扩容或缩容，但是这显然不符合Kubernetes的定位目标——自动化、智能化。 Kubernetes期望可以实现通过监测Pod的使用情况，实现pod数量的自动调整，于是就产生了Horizontal Pod Autoscaler（HPA）这种控制器。

HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。

安装metrics-server：

# 安装git
[root@k8s-master01 ~]# yum install git -y
# 获取metrics-server, 注意使用的版本
[root@k8s-master01 ~]# git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
# 修改deployment, 注意修改的是镜像和初始化参数
[root@k8s-master01 ~]# cd /root/metrics-server/deploy/1.8+/
[root@k8s-master01 1.8+]# vim metrics-server-deployment.yaml修改这个文件
hostNetwork: true
image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
args:
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP# 安装metrics-server
[root@k8s-master01 1.8+]# kubectl apply -f ./# 查看pod运行情况
[root@k8s-master01 1.8+]# kubectl get pod -n kube-system
metrics-server-6b976979db-2xwbj   1/1     Running   0          90s# 使用kubectl top node 查看资源使用情况
[root@k8s-master01 1.8+]# kubectl top node
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k8s-master01   289m         14%    1582Mi          54%
k8s-node01     81m          4%     1195Mi          40%
k8s-node02     72m          3%     1211Mi          41%
[root@k8s-master01 1.8+]# kubectl top pod -n kube-system
NAME                              CPU(cores)   MEMORY(bytes)
coredns-6955765f44-7ptsb          3m           9Mi
coredns-6955765f44-vcwr5          3m           8Mi
etcd-master                       14m          145Mi
...
# 至此,metrics-server安装完成

部署HPA：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:name: pc-hpanamespace: dev
spec:minReplicas: 1  #最小pod数量maxReplicas: 10 #最大pod数量targetCPUUtilizationPercentage: 3 # CPU使用率指标scaleTargetRef:   # 指定要控制的nginx信息apiVersion: apps/v1kind: Deploymentname: nginx

DaemonSet(DS)

DaemonSet类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本。一般适用于日志收集、节点监控等场景。也就是说，如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建。

apiVersion: apps/v1 # 版本号
kind: DaemonSet # 类型
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: daemonset
spec: # 详情描述revisionHistoryLimit: 3 # 保留历史版本updateStrategy: # 更新策略type: RollingUpdate # 滚动更新策略rollingUpdate: # 滚动更新maxUnavailable: 1 # 最大不可用状态的 Pod 的最大值，可以为百分比，也可以为整数selector: # 选择器，通过它指定该控制器管理哪些podmatchLabels:      # Labels匹配规则app: nginx-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [nginx-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80

Job

Job，主要用于负责**批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)**任务。Job特点如下：

当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量
当成功结束的pod达到指定的数量时，Job将完成执行

资源清单：

apiVersion: batch/v1 # 版本号
kind: Job # 类型
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: jobspec: # 详情描述completions: 1 # 指定job需要成功运行Pods的次数。默认值: 1parallelism: 1 # 指定job在任一时刻应该并发运行Pods的数量。默认值: 1activeDeadlineSeconds: 30 # 指定job可运行的时间期限，超过时间还未结束，系统将会尝试进行终止。backoffLimit: 6 # 指定job失败后进行重试的次数。默认是6manualSelector: true # 是否可以使用selector选择器选择pod，默认是falseselector: # 选择器，通过它指定该控制器管理哪些podmatchLabels:      # Labels匹配规则app: counter-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [counter-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: counter-podspec:restartPolicy: Never # 重启策略只能设置为Never或者OnFailurecontainers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]

关于重启策略设置的说明：如果指定为OnFailure，则job会在pod出现故障时重启容器，而不是创建pod，failed次数不变如果指定为Never，则job会在pod出现故障时创建新的pod，并且故障pod不会消失，也不会重启，failed次数加1如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了，所以不能设置为Always

CronJob

CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象。

Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。

也就是说，CronJob可以在**特定的时间点(反复的)**去运行job任务。

资源清单：

apiVersion: batch/v1beta1 # 版本号
kind: CronJob # 类型
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: cronjobspec: # 详情描述schedule: # cron格式的作业调度运行时间点,用于控制任务在什么时间执行concurrencyPolicy: # 并发执行策略，用于定义前一次作业运行尚未完成时是否以及如何运行后一次的作业failedJobHistoryLimit: # 为失败的任务执行保留的历史记录数，默认为1successfulJobHistoryLimit: # 为成功的任务执行保留的历史记录数，默认为3startingDeadlineSeconds: # 启动作业错误的超时时长jobTemplate: # job控制器模板，用于为cronjob控制器生成job对象;下面其实就是job的定义metadata:spec:completions: 1parallelism: 1activeDeadlineSeconds: 30backoffLimit: 6manualSelector: trueselector:matchLabels:app: counter-podmatchExpressions: 规则- {key: app, operator: In, values: [counter-pod]}template:metadata:labels:app: counter-podspec:restartPolicy: Never containers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 20;done"]

需要重点解释的几个选项：

schedule: cron表达式，用于指定任务的执行时间*/1    *      *    *     *<分钟> <小时> <日> <月份> <星期>分钟 值从 0 到 59.小时 值从 0 到 23.日 值从 1 到 31.月 值从 1 到 12.星期 值从 0 到 6, 0 代表星期日多个时间可以用逗号隔开； 范围可以用连字符给出；*可以作为通配符； /表示每...
concurrencyPolicy:Allow:   允许Jobs并发运行(默认)Forbid:  禁止并发运行，如果上一次运行尚未完成，则跳过下一次运行Replace: 替换，取消当前正在运行的作业并用新作业替换它

Service

1 概念

在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。

为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。

Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。

样例：

# 10.97.97.97:80 是service提供的访问入口
# 当访问这个入口的时候，可以发现后面有三个pod的服务在等待调用，
# kube-proxy会基于rr（轮询）的策略，将请求分发到其中一个pod上去
# 这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点上访问都可以。
[root@node1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.97.97.97:80 rr-> 10.244.1.39:80               Masq    1      0          0-> 10.244.1.40:80               Masq    1      0          0-> 10.244.2.33:80               Masq    1      0          0

kube-proxy目前支持三种工作模式:

userspace 模式

userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。

iptables 模式

iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。

ipvs模式

ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。

查看svc：

kubectl get svc

缩写svc。

kubectl expose deployment -n <nsname> <deployname> --name=svc-nginx --type=ClusterIP
--port=80 --target-port=80

ClusterIP是固定的类型，不能拼错。同时ClusterIP也是一个默认类型，不指定也会设置。service在创建的时候的expose是借助deployment对其管理下的pod进行网络地址的映射，实际在运行过程中是不经过deployment。

ClusterIP为集群内部才能访问的IP。如果要创建外部也可以访问的svc，需要修改type为NodePort。

2 资源清单

kind: Service  # 资源类型
apiVersion: v1  # 资源版本
metadata: # 元数据name: service # 资源名称namespace: dev # 命名空间
spec: # 描述selector: # 标签选择器，用于确定当前service代理哪些podapp: nginxtype: # Service类型，指定service的访问方式clusterIP:  # 虚拟服务的ip地址，可以指定分配一个，若不写则会自动生成一个，写None则会创建HeadLinesssessionAffinity: # session亲和性，支持ClientIP、None两个选项ports: # 端口信息- protocol: TCP port: 3017  # service端口targetPort: 5003 # pod端口nodePort: 31122 # 主机端口

其中type指定的service类型如下：

ClusterIP：默认值，它是Kubernetes系统自动分配的虚拟IP，只能在集群内部访问
NodePort：将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务
LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持
ExternalName：把集群外部的服务引入集群内部，直接使用

样例：

apiVersion: v1
kind: Service
metadata:name: service-clusteripnamespace: dev
spec:selector:app: nginx-podclusterIP: 10.97.97.97 # service的ip地址，如果不写，默认会生成一个type: ClusterIPports:- port: 80  # Service端口       targetPort: 80 # pod端口

Endpoint

Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。

一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说，service和pod之间的联系是通过endpoints实现的。

kubectl get endpoints

endpoints中的s不能省略。

负载分发策略

对Service的访问被分发到了后端的Pod上去，目前kubernetes提供了两种负载分发策略：

1.如果不定义，默认使用kube-proxy的策略，比如随机、轮询；

2.基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都会转发到固定的一个Pod上此模式可以使在spec中添加sessionAffinity:ClientIP选项。

这样创建的svc规则一般会在后面带上persistent 10800的属性。

3 HeadLiness

在某些场景中，开发人员可能不想使用Service提供的负载均衡功能，而希望自己来控制负载均衡策略，针对这种情况，kubernetes提供了HeadLiness Service，这类Service不会分配Cluster IP，如果想要访问service，只能通过service的域名进行查询。

apiVersion: v1
kind: Service
metadata:name: service-headlinessnamespace: dev
spec:selector:app: nginx-podclusterIP: None # 将clusterIP设置为None，即可创建headliness Servicetype: ClusterIPports:- port: 80    targetPort: 80

4 Nodeport

在之前的样例中，创建的Service的ip地址只有集群内部才可以访问，如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是将service的端口映射到Node的一个端口上，然后就可以通过NodeIp:NodePort来访问service了。

apiVersion: v1
kind: Service
metadata:name: service-nodeportnamespace: dev
spec:selector:app: nginx-podtype: NodePort # service类型ports:- port: 80nodePort: 30002 # 指定绑定的node的端口(默认的取值范围是：30000-32767), 如果不指定，会默认分配targetPort: 80

5 ExternalName

ExternalName类型的Service用于引入集群外部的服务，它通过externalName属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部的服务了。

apiVersion: v1
kind: Service
metadata:name: service-externalnamenamespace: dev
spec:type: ExternalName # service类型externalName: www.baidu.com  #改成ip地址也可以

补充：四层、七层负载均衡

所谓四层就是基于IP+端口的负载均衡，七层就是基于URL等应用层信息的负载均衡。同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。

二层负载均衡通过一个虚拟MAC地址接收请求，然后再分配到真实的MAC地址；

三层负载均衡通过一个虚拟IP地址接收请求，然后再分配到真实的IP地址；

四层负载均衡通过虚拟IP+端口接收请求，然后再分配到真实的服务器；

七层负载均衡通过虚拟的URL或主机名接收请求，然后再分配到真实的服务器。

四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。比如四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。

Ingress

Service对集群之外暴露服务的主要方式有两种：NotePort和LoadBalancer，但是这两种方式，都有一定的缺点。

1.NodePort方式的缺点是会占用很多集群机器的端口，那么当集群服务变多的时候，这个缺点就愈发明显；
2.LB方式的缺点是每个service需要一个LB外部设备，浪费、麻烦，并且需要kubernetes之外设备的支持；

基于这种现状，kubernetes提供了Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。

实际上，Ingress相当于一个7层的负载均衡器，是kubernetes对反向代理的一个抽象，它的工作原理类似于Nginx，可以理解成在Ingress里建立诸多映射规则，Ingress Controller通过监听这些配置规则并转化成Nginx的反向代理配置 , 然后对外部提供服务。简而言之，就是最后访问的时候实际上是Nginx在工作，Ingress只是定义了规则，然后转换这些规则。在这里有两个核心概念：

1.ingress：kubernetes中的一个对象，作用是定义请求如何转发到service的规则
2.ingress controller：具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，比如Nginx, Contour, Haproxy等等

Http代理

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: ingress-httpnamespace: dev
spec:rules:- host: nginx.shark.comhttp:paths:- path: /backend:serviceName: nginx-serviceservicePort: 80- host: tomcat.shark.comhttp:paths:- path: /backend:serviceName: tomcat-serviceservicePort: 8080

查看：

kubectl describe ing ingress-http

Https代理

# 生成证书
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/C=CN/ST=BJ/L=BJ/O=nginx/CN=shark.com"# 创建密钥
kubectl create secret tls tls-secret --key tls.key --cert tls.crt

yaml：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: ingress-httpsnamespace: dev
spec:tls:- hosts:- nginx.com- tomcat.comsecretName: tls-secret # 指定秘钥rules:- host: nginx.shark.comhttp:paths:- path: /backend:serviceName: nginx-serviceservicePort: 80- host: tomcat.shark.comhttp:paths:- path: /backend:serviceName: tomcat-serviceservicePort: 8080

Volume

容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。

Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。

kubernetes的Volume支持多种类型，比较常见的有下面几个：

1.简单存储：EmptyDir、HostPath、NFS
2.高级存储：PV、PVC
3.配置存储：ConfigMap、Secret

EmptyDir

EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。

EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时， EmptyDir中的数据也会被永久删除。 EmptyDir用途如下：

1.临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留
2.一个容器需要从另一个容器中获取数据的目录（多容器共享目录）

资源清单：

apiVersion: v1
kind: Pod
metadata:name: volume-emptydirnamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80volumeMounts:  # 将logs-volume挂在到nginx容器中，对应的目录为 /var/log/nginx- name: logs-volumemountPath: /var/log/nginx- name: busyboximage: busybox:1.30command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件中内容volumeMounts:  # 将logs-volume 挂在到busybox容器中，对应的目录为 /logs- name: logs-volumemountPath: /logs#从这里开始声明volumes: # 声明volume， name为logs-volume，类型为emptyDir- name: logs-volumeemptyDir: {}

HostPath

EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。

HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。

资源清单：

apiVersion: v1
kind: Pod
metadata:name: volume-hostpathnamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80volumeMounts:- name: logs-volumemountPath: /var/log/nginx- name: busyboximage: busybox:1.30command: ["/bin/sh","-c","tail -f /logs/access.log"]volumeMounts:- name: logs-volumemountPath: /logs#从这里开始声明volumes:- name: logs-volumehostPath: path: /root/logstype: DirectoryOrCreate  # 目录存在就使用，不存在就先创建后使用

关于type的值的一点说明：

关于type的值的一点说明：DirectoryOrCreate 目录存在就使用，不存在就先创建后使用Directory   目录必须存在FileOrCreate  文件存在就使用，不存在就先创建后使用File 文件必须存在 Socket  unix套接字必须存在CharDevice  字符设备必须存在BlockDevice 块设备必须存在

NFS

HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了，此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。

NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。

# 在nfs上安装nfs服务
[root@nfs ~]# yum install nfs-utils -y# 准备一个共享目录
[root@nfs ~]# mkdir /root/data/nfs -pv# 将共享目录以读写权限暴露给192.168.5.0/24网段中的所有主机
[root@nfs ~]# vim /etc/exports
[root@nfs ~]# more /etc/exports
/root/data/nfs     192.168.5.0/24(rw,no_root_squash)# 启动nfs服务
[root@nfs ~]# systemctl restart nfs

资源清单：

apiVersion: v1
kind: Pod
metadata:name: volume-nfsnamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80volumeMounts:- name: logs-volumemountPath: /var/log/nginx- name: busyboximage: busybox:1.30command: ["/bin/sh","-c","tail -f /logs/access.log"] volumeMounts:- name: logs-volumemountPath: /logs#从这里开始声明volumes:- name: logs-volumenfs:server: 192.168.5.6  #nfs服务器地址path: /root/data/nfs #共享文件路径

PV和PVC

使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。

PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。

PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

使用了PV和PVC之后，工作可以得到进一步的细分：

存储：存储工程师维护
PV： kubernetes管理员维护
PVC：kubernetes用户维护

1 PV

PV是存储资源的抽象，资源清单：

apiVersion: v1
kind: PersistentVolume
metadata:name: pv
spec:nfs: # 存储类型，与底层真正存储对应path: /root/data/pvserver: 192.168.5.6capacity:  # 存储能力，目前只支持存储空间的设置storage: 2GiaccessModes:  # 访问模式- ReadWriteManystorageClassName: # 存储类别persistentVolumeReclaimPolicy: Retain # 回收策略

PV是一种集群级别的资源，没有namespace，PV是跨namespace来使用的。

存储类型

底层实际存储的类型，kubernetes支持多种存储类型，每种存储类型的配置都有所差异

存储能力（capacity）

目前只支持存储空间的设置( storage=1Gi )，不过未来可能会加入IOPS、吞吐量等指标的配置

访问模式（accessModes）

用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：

ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
需要注意的是，底层不同的存储类型可能支持的访问模式不同

回收策略（persistentVolumeReclaimPolicy）

当PV不再被使用了之后，对其的处理方式。目前支持三种策略：

Retain （保留）保留数据，需要管理员手工清理数据
Recycle（回收）清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*
Delete （删除）与 PV 相连的后端存储完成 volume 的删除操作，当然这常见于云服务商的存储服务
需要注意的是，底层不同的存储类型可能支持的回收策略不同。

存储类别（storageClassName）

PV可以通过storageClassName参数指定一个存储类别

具有特定类别的PV只能与请求了该类别的PVC进行绑定
未设定类别的PV则只能与不请求任何类别的PVC进行绑定

状态（status）

一个 PV 的生命周期中，可能会处于4中不同的阶段：

Available（可用）：表示可用状态，还未被任何 PVC 绑定
Bound（已绑定）：表示 PV 已经被 PVC 绑定
Released（已释放）：表示 PVC 被删除，但是资源还未被集群重新声明
Failed（失败）：表示该 PV 的自动回收失败

2 PVC

PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息。

资源清单:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pvcnamespace: dev
spec:accessModes: # 访问模式selector: # 采用标签对PV选择storageClassName: # 存储类别resources: # 请求空间requests:storage: 5Gi

PVC 的关键配置参数说明：

访问模式（accessModes）

用于描述用户应用对存储资源的访问权限。

选择条件（selector）

通过Label Selector的设置，可使PVC对于系统中己存在的PV进行筛选。

存储类别（storageClassName）

PVC在定义时可以设定需要的后端存储的类别，和PV做对应，只有设置了该class的PV才能被系统选出。

资源请求（Resources ）

描述对存储资源的请求。

3 Pod使用

用PVC申请PV之后，可以在pod中使用PVC

apiVersion: v1
kind: Pod
metadata:name: pod1namespace: dev
spec:containers:- name: busyboximage: busybox:1.30command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]volumeMounts:- name: volumemountPath: /root/volumes:- name: volumepersistentVolumeClaim:claimName: pvcreadOnly: false

4 PV和PVC的生命周期

PVC和PV是一一对应的，PV和PVC之间的相互作用遵循以下生命周期：

1.资源供应：管理员手动创建底层存储和PV。

2.资源绑定：用户创建PVC，kubernetes负责根据PVC的声明去寻找PV，并绑定在用户定义好PVC之后，系统将根据PVC对存储资源的请求在已存在的PV中选择一个满足条件的PV。

1.如果能够找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了
2.如果找不到，PVC则会无限期处于Pending状态，直到等到系统管理员创建了一个符合其要求的PV
3.PV一旦绑定到某个PVC上，就会被这个PVC独占，不能再与其他PVC进行绑定了

3.资源使用：用户可在Pod中像Volume一样使用PVC

Pod使用Volume的定义，将PVC挂载到容器内的某个路径进行使用。

4.资源释放：用户删除pvc来释放pv

当存储资源使用完毕后，用户可以删除PVC，与该PVC绑定的PV将会被标记为**“已释放（Released）”**，但还不能立刻与其他PVC进行绑定。通过之前PVC写入的数据可能还被留在存储设备上，只有在清除之后该PV才能再次使用。

5.资源回收：kubernetes根据pv设置的回收策略进行资源的回收

对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收，才能供新的PVC绑定和使用。

配置存储

ConfigMap

ConfigMap是一种比较特殊的存储卷，它的主要作用是用来存储配置信息的。

apiVersion: v1
kind: ConfigMap
metadata:name: configmap    #对应挂载的名字namespace: dev
data:info: |username:adminpassword:123456

查看cm：

 kubectl describe cm configmap -n dev

pod挂载：

apiVersion: v1
kind: Pod
metadata:name: pod-configmapnamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1volumeMounts: # 将configmap挂载到目录- name: configmountPath: /configmap/configvolumes: # 引用configmap- name: configconfigMap:name: configmap

查看内容：

#进入容器
[root@k8s-master01 ~]# kubectl exec -it pod-configmap -n dev /bin/sh
# cd /configmap/config/
# ls
info
# more info
username:admin
password:123456# 可以看到映射已经成功，每个configmap都映射成了一个目录
# key--->文件     value---->文件中的内容
# 此时如果更新configmap的内容, 容器中的值也会动态更新

Secret

在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。它主要用于存储敏感信息，例如密码、秘钥、证书等等。

base64对数据进行编码：

[root@k8s-master01 ~]# echo -n 'admin' | base64 #准备username
YWRtaW4=
[root@k8s-master01 ~]# echo -n '123456' | base64 #准备password
MTIzNDU2

创建secret：

apiVersion: v1
kind: Secret
metadata:name: secret   #对应挂载的名字namespace: dev
type: Opaque
data:username: YWRtaW4=password: MTIzNDU2

pod挂载：

apiVersion: v1
kind: Pod
metadata:name: pod-secretnamespace: dev
spec:containers:- name: nginximage: nginx:1.17.1volumeMounts: # 将secret挂载到目录- name: configmountPath: /secret/configvolumes:- name: configsecret:secretName: secret

解码：

# 进入容器，查看secret信息，发现已经自动解码了
[root@k8s-master01 ~]# kubectl exec -it pod-secret /bin/sh -n dev
/ # ls /secret/config/
password  username
/ # more /secret/config/username
admin
/ # more /secret/config/password
123456

安全认证

Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。

客户端

在Kubernetes集群中，客户端通常有两类：

1.User Account：一般是独立于kubernetes之外的其他服务管理的用户账号。
2.Service Account：kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识。

认证、授权与准入控制

ApiServer是访问及管理资源对象的唯一入口。任何一个请求访问ApiServer，都要经过下面三个流程：

1.Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证
2.Authorization（授权）：判断用户是否有权限对访问的资源执行特定的动作
3.Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。

认证管理

Kubernetes集群安全的最关键点在于如何识别并认证客户端身份，它提供了3种客户端身份认证方式：

HTTP Base认证：通过用户名+密码的方式认证

    这种认证方式是把“用户名:密码”用BASE64算法进行编码后的字符串放在HTTP请求中的Header Authorization域里发送给服务端。服务端收到后进行解码，获取用户名及密码，然后进行用户身份认证的过程。

HTTP Token认证：通过一个Token来识别合法用户

    这种认证方式是用一个很长的难以被模仿的字符串--Token来表明客户身份的一种方式。每个Token对应一个用户名，当客户端发起API调用请求时，需要在HTTP Header里放入Token，API Server接到Token后会跟服务器中保存的token进行比对，然后进行用户身份认证的过程。

HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式

HTTPS认证大体分为3个过程：

1.证书申请和下发

  HTTPS通信双方的服务器向CA机构申请证书，CA机构下发根证书、服务端证书及私钥给申请者

2.客户端和服务端的双向认证

 1> 客户端向服务器端发起请求，服务端下发自己的证书给客户端，客户端接收到证书后，通过私钥解密证书，在证书中获得服务端的公钥，客户端利用服务器端的公钥认证证书中的信息，如果一致，则认可这个服务器2> 客户端发送自己的证书给服务器端，服务端接收到证书后，通过私钥解密证书，在证书中获得客户端的公钥，并用该公钥认证证书信息，确认客户端是否合法

3.服务器端和客户端进行通信

  服务器端和客户端协商好加密方案后，客户端会产生一个随机的秘钥并加密，然后发送到服务器端。服务器端接收这个秘钥后，双方接下来通信的所有内容都通过该随机秘钥加密

Kubernetes允许同时配置多种认证方式，只要其中任意一个方式认证通过即可。

授权管理

授权发生在认证成功之后，通过认证就可以知道请求用户是谁，然后Kubernetes会根据事先定义的授权策略来决定用户是否有权限访问，这个过程就称为授权。

每个发送到ApiServer的请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则会返回错误。

APIServer目前支持以下几种授权策略：

AlwaysDeny：表示拒绝所有请求，一般用于测试
AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（Kubernetes默认的策略）
ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
Webhook：通过调用外部REST服务对用户进行授权
Node：是一种专用模式，用于对kubelet发出的请求进行访问控制
RBAC：基于角色的访问控制（kubeadm安装方式下的默认选项）
RBAC(Role-Based Access Control) 基于角色的访问控制，主要是在描述一件事情：给哪些对象授予了哪些权限

其中涉及到了下面几个概念：

对象：User、Groups、ServiceAccount
角色：代表着一组定义在资源上的可操作动作(权限)的集合
绑定：将定义好的角色跟用户绑定在一起
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lPtcRLMI-1633354912852)(Kubenetes.assets/image-20200519181209566.png)]

RBAC引入了4个顶级资源对象：

Role、ClusterRole：角色，用于指定一组权限
RoleBinding、ClusterRoleBinding：角色绑定，用于将角色（权限）赋予给对象

Role、ClusterRole

一个角色就是一组权限的集合，这里的权限都是许可形式的（白名单）：

Role资源清单：

# Role只能对命名空间内的资源进行授权，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:namespace: dev #role需要namespacename: authorization-role
rules:
- apiGroups: [""]  # 支持的API组列表,"" 空字符串，表示核心API群resources: ["pods"] # 支持的资源对象列表verbs: ["get", "watch", "list"] # 允许的对资源对象的操作方法列表

ClusterRole资源清单：

# ClusterRole可以对集群范围内资源、跨namespaces的范围资源、非资源类型进行授权
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:name: authorization-clusterrole
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]

需要详细说明的是，rules中的参数：

apiGroups: 支持的API组列表

"","apps", "autoscaling", "batch"

resources：支持的资源对象列表

"services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs",
"nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets",
"horizontalpodautoscalers","replicationcontrollers","cronjobs"

verbs：对资源对象的操作方法列表

"get", "list", "watch", "create", "update", "patch", "delete", "exec"

RoleBinding、ClusterRoleBinding

角色绑定用来把一个角色绑定到一个目标对象上，绑定目标可以是User、Group或者ServiceAccount。

RoleBinding：

# RoleBinding可以将同一namespace中的subject绑定到某个Role下，则此subject即具有该Role定义的权限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:name: authorization-role-bindingnamespace: dev #指定namespace
subjects:
- kind: User    #绑定目标可以是User、Group或者ServiceAccountname: sharkapiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: authorization-roleapiGroup: rbac.authorization.k8s.io

ClusterRoleBinding：

# ClusterRoleBinding在整个集群级别和所有namespaces将特定的subject与ClusterRole绑定，授予权限
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:name: authorization-clusterrole-binding
subjects:
- kind: User    #绑定目标可以是User、Group或者ServiceAccountname: sharkapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: authorization-clusterroleapiGroup: rbac.authorization.k8s.io

RoleBinding引用ClusterRole进行授权

RoleBinding可以引用ClusterRole，对属于同一命名空间内ClusterRole定义的资源主体进行授权。

    一种很常用的做法就是，集群管理员为集群范围预定义好一组角色（ClusterRole），然后在多个命名空间中重复使用这些ClusterRole。这样可以大幅提高授权管理工作效率，也使得各个命名空间下的基础性授权规则与使用体验保持一致。

样例：

# 虽然authorization-clusterrole是一个集群角色，但是因为使用了RoleBinding
# 所以shark只能读取dev命名空间中的资源
kind: RoleBinding   #RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:name: authorization-role-binding-nsnamespace: dev
subjects:
- kind: Username: sharkapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRole   #ClusterRolename: authorization-clusterroleapiGroup: rbac.authorization.k8s.io

kube-apiserver 启动流程分析

kube-apiserver的组件

kube-apiserver 共由 3 个组件构成（Aggregator、KubeAPIServer、APIExtensionServer），这些组件依次通过 Delegation 处理请求：

Aggregator：暴露的功能类似于一个七层负载均衡，将来自用户的请求拦截转发给其他服务器，并且负责整个 APIServer 的 Discovery 功能；
KubeAPIServer ：负责对请求的一些通用处理，认证、鉴权等，以及处理各个内建资源的 REST 服务；
APIExtensionServer：主要处理 CustomResourceDefinition（CRD）和 CustomResource（CR）的 REST 请求，也是 Delegation 的最后一环，如果对应 CR 不能被处理的话则会返回 404。

Aggregator 和 APIExtensionsServer 对应两种主要扩展 APIServer 资源的方式，即分别是 AA 和 CRD。

main

apiserver是主API服务器，也是集群的主API服务器。它负责提供集群管理API。kube-apiserver 是通过其 Run 方法启动主逻辑的，在Run 方法调用之前会进行解析命令行参数、设置默认值等。

// apiserver is the main api server and master for the cluster.
// it is responsible for serving the cluster management API.
package mainfunc main() {rand.Seed(time.Now().UnixNano())pflag.CommandLine.SetNormalizeFunc(cliflag.WordSepNormalizeFunc)//新建apiservercommand := app.NewAPIServerCommand()logs.InitLogs()defer logs.FlushLogs()if err := command.Execute(); err != nil {os.Exit(1)}
}

NewAPIserverCommand

Package app通过绑定API、master和APIServer基础设施来完成创建Kubernetes APIServer所需的所有工作。可以直接或通过hyperkube框架配置和调用它。

NewAPIServerCommand函数使用默认参数创建一个*cobra.Command的对象，Kubernetes API Server验证和配置API对象的数据，这些对象包括pods、services、replicationcontroller等。API Server提供RESTful API操作，并提供集群共享状态的前端，所有其他组件通过共享状态进行交互。

REST，表示性状态转移（representation state transfer）。简单来说，就是用URI表示资源，用HTTP方法(GET, POST, PUT, DELETE)表征对这些资源的操作。

// NewAPIServerCommand creates a *cobra.Command object with default parameters
func NewAPIServerCommand() *cobra.Command {// NewServerRunOptions创建一个新的带有默认参数的ServerRunOptionss := options.NewServerRunOptions()cmd := &cobra.Command{Use: "kube-apiserver",Long: `The Kubernetes API server validates and configures data
for the api objects which include pods, services, replicationcontrollers, and
others. The API Server services REST operations and provides the frontend to the
cluster's shared state through which all other components interact.`,// stop printing usage when the command errorsSilenceUsage: true,PersistentPreRunE: func(*cobra.Command, []string) error {// silence client-go warnings.// kube-apiserver loopback clients should not log self-issued warnings.rest.SetDefaultWarningHandler(rest.NoWarnings{})return nil},RunE: func(cmd *cobra.Command, args []string) error {verflag.PrintAndExitIfRequested()fs := cmd.Flags()cliflag.PrintFlags(fs)err := checkNonZeroInsecurePort(fs)if err != nil {return err}// 设置ServerRunOptions默认值// completedOptions是调用Complete(s)返回的ServerRunOptions指针completedOptions, err := Complete(s)if err != nil {return err}// 主要检查 object 中字段的合法性。if errs := completedOptions.Validate(); len(errs) != 0 {return utilerrors.NewAggregate(errs)}// 用completedOptions参数启动api-serverreturn Run(completedOptions, genericapiserver.SetupSignalHandler())},Args: func(cmd *cobra.Command, args []string) error {for _, arg := range args {if len(arg) > 0 {return fmt.Errorf("%q does not take any arguments, got %q", cmd.CommandPath(), args)}}return nil},}fs := cmd.Flags()namedFlagSets := s.Flags()verflag.AddFlags(namedFlagSets.FlagSet("global"))globalflag.AddGlobalFlags(namedFlagSets.FlagSet("global"), cmd.Name())options.AddCustomGlobalFlags(namedFlagSets.FlagSet("generic"))for _, f := range namedFlagSets.FlagSets {fs.AddFlagSet(f)}usageFmt := "Usage:\n  %s\n"cols, _, _ := term.TerminalSize(cmd.OutOrStdout())cmd.SetUsageFunc(func(cmd *cobra.Command) error {fmt.Fprintf(cmd.OutOrStderr(), usageFmt, cmd.UseLine())cliflag.PrintSections(cmd.OutOrStderr(), namedFlagSets, cols)return nil})cmd.SetHelpFunc(func(cmd *cobra.Command, args []string) {fmt.Fprintf(cmd.OutOrStdout(), "%s\n\n"+usageFmt, cmd.Long, cmd.UseLine())cliflag.PrintSections(cmd.OutOrStdout(), namedFlagSets, cols)})return cmd
}

Complete

在启动过程中调用的Complete函数：

// Complete set default ServerRunOptions.
// Should be called after kube-apiserver flags parsed.
func Complete(s *options.ServerRunOptions) (completedServerRunOptions, error) {...}

completedServerRunOptions是一个私有包装，强制在Run调用之前调用Complete()，返回一个ServerRunOption的指针：

// completedServerRunOptions is a private wrapper that enforces a call of Complete() before Run can be invoked.
type completedServerRunOptions struct {*options.ServerRunOptions
}

Run

Run 方法的主要逻辑为：

1、调用 CreateServerChain 构建服务调用链并判断是否启动非安全的 http server，http server 链中包含 apiserver 要启动的三个 server：CreateKubeAPIServer、createAPIExtensionsServer、createAggregatorServer，以及为每个 server 注册对应资源的路由和配置项等；
2、调用 server.PrepareRun 进行服务运行前的准备，该方法主要完成了健康检查、存活检查和OpenAPI路由的注册工作；
3、调用 prepared.Run 启动 https server；

// Run runs the specified APIServer.  This should never exit.
func Run(completeOptions completedServerRunOptions, stopCh <-chan struct{}) error {// To help debugging, immediately log versionklog.Infof("Version: %+v", version.Get())// 构建服务调用链ServerChain并判断是否启动了非安全的http serverserver, err := CreateServerChain(completeOptions, stopCh)if err != nil {return err}// 进行服务运行前的准备，该方法主要完成了健康检查、存活检查和OpenAPI路由的注册工作；prepared, err := server.PrepareRun()if err != nil {return err}return prepared.Run(stopCh)
}

CreateServerChain

server 的初始化使用委托模式，通过 DelegationTarget 接口，把基本的 API Server、CustomResource、Aggregator 这三种服务采用链式结构串联起来，对外提供服务。

CreateServerChain 是完成 server 初始化的方法，里面包含 APIExtensionsServer、KubeAPIServer、AggregatorServer 初始化的所有流程，最终返回 aggregatorapiserver.APIAggregator 实例。

初始化流程主要有：http filter chain 的配置、API Group 的注册、http path 与 handler 的关联以及 handler 后端存储 etcd 的配置。其主要逻辑为：

1、调用 CreateKubeAPIServerConfig 创建 KubeAPIServer 所需要的配置，主要是创建 master.Config，其中会调用 buildGenericConfig 生成 genericConfig，genericConfig 中包含 apiserver 的核心配置；
2、判断是否启用了扩展的 API server 并调用 createAPIExtensionsConfig 为其创建配置，apiExtensions server 是一个代理服务，用于代理 kubeapiserver 中的其他 server，比如 metric-server；
3、调用 createAPIExtensionsServer 创建 apiExtensionsServer 实例；
4、调用 CreateKubeAPIServer初始化 kubeAPIServer；
5、调用 createAggregatorConfig 为 aggregatorServer 创建配置并调用 createAggregatorServer 初始化 aggregatorServer；

// CreateServerChain creates the apiservers connected via delegation.
func CreateServerChain(completedOptions completedServerRunOptions, stopCh <-chan struct{}) (*aggregatorapiserver.APIAggregator, error) {nodeTunneler, proxyTransport, err := CreateNodeDialer(completedOptions)if err != nil {return nil, err}kubeAPIServerConfig, serviceResolver, pluginInitializer, err := CreateKubeAPIServerConfig(completedOptions, nodeTunneler, proxyTransport)if err != nil {return nil, err}// If additional API servers are added, they should be gated.apiExtensionsConfig, err := createAPIExtensionsConfig(*kubeAPIServerConfig.GenericConfig, kubeAPIServerConfig.ExtraConfig.VersionedInformers, pluginInitializer, completedOptions.ServerRunOptions, completedOptions.MasterCount,serviceResolver, webhook.NewDefaultAuthenticationInfoResolverWrapper(proxyTransport, kubeAPIServerConfig.GenericConfig.EgressSelector, kubeAPIServerConfig.GenericConfig.LoopbackClientConfig))if err != nil {return nil, err}apiExtensionsServer, err := createAPIExtensionsServer(apiExtensionsConfig, genericapiserver.NewEmptyDelegate())if err != nil {return nil, err}kubeAPIServer, err := CreateKubeAPIServer(kubeAPIServerConfig, apiExtensionsServer.GenericAPIServer)if err != nil {return nil, err}// aggregator comes last in the chainaggregatorConfig, err := createAggregatorConfig(*kubeAPIServerConfig.GenericConfig, completedOptions.ServerRunOptions, kubeAPIServerConfig.ExtraConfig.VersionedInformers, serviceResolver, proxyTransport, pluginInitializer)if err != nil {return nil, err}aggregatorServer, err := createAggregatorServer(aggregatorConfig, kubeAPIServer.GenericAPIServer, apiExtensionsServer.Informers)if err != nil {// we don't need special handling for innerStopCh because the aggregator server doesn't create any go routinesreturn nil, err}return aggregatorServer, nil
}

PIServer；

5、调用 createAggregatorConfig 为 aggregatorServer 创建配置并调用 createAggregatorServer 初始化 aggregatorServer；

// CreateServerChain creates the apiservers connected via delegation.
func CreateServerChain(completedOptions completedServerRunOptions, stopCh <-chan struct{}) (*aggregatorapiserver.APIAggregator, error) {nodeTunneler, proxyTransport, err := CreateNodeDialer(completedOptions)if err != nil {return nil, err}kubeAPIServerConfig, serviceResolver, pluginInitializer, err := CreateKubeAPIServerConfig(completedOptions, nodeTunneler, proxyTransport)if err != nil {return nil, err}// If additional API servers are added, they should be gated.apiExtensionsConfig, err := createAPIExtensionsConfig(*kubeAPIServerConfig.GenericConfig, kubeAPIServerConfig.ExtraConfig.VersionedInformers, pluginInitializer, completedOptions.ServerRunOptions, completedOptions.MasterCount,serviceResolver, webhook.NewDefaultAuthenticationInfoResolverWrapper(proxyTransport, kubeAPIServerConfig.GenericConfig.EgressSelector, kubeAPIServerConfig.GenericConfig.LoopbackClientConfig))if err != nil {return nil, err}apiExtensionsServer, err := createAPIExtensionsServer(apiExtensionsConfig, genericapiserver.NewEmptyDelegate())if err != nil {return nil, err}kubeAPIServer, err := CreateKubeAPIServer(kubeAPIServerConfig, apiExtensionsServer.GenericAPIServer)if err != nil {return nil, err}// aggregator comes last in the chainaggregatorConfig, err := createAggregatorConfig(*kubeAPIServerConfig.GenericConfig, completedOptions.ServerRunOptions, kubeAPIServerConfig.ExtraConfig.VersionedInformers, serviceResolver, proxyTransport, pluginInitializer)if err != nil {return nil, err}aggregatorServer, err := createAggregatorServer(aggregatorConfig, kubeAPIServer.GenericAPIServer, apiExtensionsServer.Informers)if err != nil {// we don't need special handling for innerStopCh because the aggregator server doesn't create any go routinesreturn nil, err}return aggregatorServer, nil
}