《kubernetes权威指南第五版》读书笔记

修改kubeadm的默认配置

　　kubeadm的初始化控制平面（init）命令和加入节点（join）命令均可以通过指定的配置文件修改默认参数的值。kubeadm将配置文件以ConfigMap形式保存到集群中，便于后续的查询和升级工作。kubeadm config子命令提供了对这组功能的支持。

kubeadm config print init-defaults：输出kubeadm init命令默认参数的内容。
kubeadm config print join-defaults：输出kubeadm join命令默认参数的内容。
kubeadm config migrate：在新旧版本之间进行配置转换。
kubeadm config images list：列出所需的镜像列表。
kubeadm config images pull：拉取镜像到本地。

kubeadm config print init-defaults >init-default.yaml

　　对生成的文件进行编辑，可以按需生成合适的配置。例如，若需要自定义镜像的仓库地址、需要安装的Kubernetes版本号及Pod的IP地址范围

kubeadm config images list：列出所需的镜像列表

　　如果无法访问k8s.gcr.io，则可以使用国内镜像托管站点进行下载，例如https：//1nj0zren.mirror.aliyuncs.com，这可以通过修改Docker服务的配置文件（默认为/etc/docker/daemon.json）进行设置，例如：
　　然后，使用kubeadm config images pull命令或者docker pull命令下载上述镜像，

kubeadm config images pull --config=init-config.yaml

　　在镜像下载完成之后，就可以进行安装了。

　　在开始之前需要注意：kubeadm的安装过程不涉及网络插件（CNI）的初始化，因此kubeadm初步安装完成的集群不具备网络功能，任何Pod（包括自带的CoreDNS）都无法正常工作。而网络插件的安装往往对kubeadm init命令的参数有一定要求

创建和使用命令行插件

　　为了扩展kubectl的功能，Kubernetes从1.8版本开始引入插件机制，在1.14版本时达到稳定版。
　　用户自定义插件的可执行文件名需要以“kubectl-”开头，复制到$PATH中的某个目录（如/usr/local/bin）下，然后就可以通过kubectl <plugin-name>运行自定义插件了。
　　例如，通过Shell脚本实现一个名为hello的插件，其功能为在屏幕上输出字符串“hello world”。创建名为“kubectl-hello”的Shell脚本文件
　　通过插件机制，可以将某些复杂的kubectl命令简化为运行插件的方式。例如想创建一个命令来查看当前上下文环境（context）中的用户名，则可以通过kubectl config view命令进行查看

使用kubectl plugin list命令可以查看当前系统中已安装的插件列表

Pod深入了解

pod生命周期和重启策略

Pod在整个生命周期中被系统定义为各种状态

　　pod的创建过程

用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer
apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端
apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动
scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer
node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer
apiServer将接收到的pod状态信息存入etcd中

　　pod的终止过程

用户向apiServer发送删除pod对象的命令
apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
将pod标记为terminating状态
kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行
pod对象中的容器进程收到停止信号
宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见

　　初始化容器

　　初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：

初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成
初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行

　　初始化容器有很多的应用场景，下面列出的是最常见的几个：

提供主容器镜像中不具备的工具程序或自定义代码
初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足

　　接下来做一个案例，模拟下面这个需求：

　　假设要以主容器来运行nginx，但是要求在运行nginx之前先要能够连接上mysql和redis所在服务器

　　为了简化测试，事先规定好mysql(192.168.90.14)和redis(192.168.90.15)服务器的地址

apiVersion: v1
kind: Pod
metadata:
  name: pod-initcontainer
  namespace: dev
spec:
  containers:
  - name: main-container
    image: nginx:1.17.1
    ports: 
    - name: nginx-port
      containerPort: 80
  initContainers:
  - name: test-mysql
    image: busybox:1.30
    command: ['sh', '-c', 'until ping 192.168.90.14 -c 1 ; do echo waiting for mysql...; sleep 2; done;']
  - name: test-redis
    image: busybox:1.30
    command: ['sh', '-c', 'until ping 192.168.90.15 -c 1 ; do echo waiting for reids...; sleep 2; done;']

# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-initcontainer.yaml
pod/pod-initcontainer created

# 查看pod状态
# 发现pod卡在启动第一个初始化容器过程中，后面的容器不会运行
root@k8s-master01 ~]# kubectl describe pod  pod-initcontainer -n dev
........
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  49s   default-scheduler  Successfully assigned dev/pod-initcontainer to node1
  Normal  Pulled     48s   kubelet, node1     Container image "busybox:1.30" already present on machine
  Normal  Created    48s   kubelet, node1     Created container test-mysql
  Normal  Started    48s   kubelet, node1     Started container test-mysql

# 动态查看pod
[root@k8s-master01 ~]# kubectl get pods pod-initcontainer -n dev -w
NAME                             READY   STATUS     RESTARTS   AGE
pod-initcontainer                0/1     Init:0/2   0          15s
pod-initcontainer                0/1     Init:1/2   0          52s
pod-initcontainer                0/1     Init:1/2   0          53s
pod-initcontainer                0/1     PodInitializing   0          89s
pod-initcontainer                1/1     Running           0          90s

# 接下来新开一个shell，为当前服务器新增两个ip，观察pod的变化
[root@k8s-master01 ~]# ifconfig ens33:1 192.168.90.14 netmask 255.255.255.0 up
[root@k8s-master01 ~]# ifconfig ens33:2 192.168.90.15 netmask 255.255.255.0 up

创建pod，观察状态变化

　　钩子函数

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

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

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

　　钩子处理器支持使用下面三种方式定义动作：

Exec命令：在容器内执行一次命令

……
  lifecycle:
    postStart: 
      exec:
        command:
        - cat
        - /tmp/healthy
……

TCPSocket：在当前容器尝试访问指定的socket

……      
  lifecycle:
    postStart:
      tcpSocket:
        port: 8080
……

HTTPGet：在当前容器中向某url发起http请求

……
  lifecycle:
    postStart:
      httpGet:
        path: / #URI地址
        port: 80 #端口号
        host: 192.168.5.3 #主机地址
        scheme: HTTP #支持的协议，http或者https
……

　　以exec方式为例，演示下钩子函数的使用，创建pod-hook-exec.yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: pod-hook-exec
  namespace: dev
spec:
  containers:
  - name: main-container
    image: nginx:1.17.1
    ports:
    - name: nginx-port
      containerPort: 80
    lifecycle:
      postStart: 
        exec: # 在容器启动的时候执行一个命令，修改掉nginx的默认首页内容
          command: ["/bin/sh", "-c", "echo postStart... > /usr/share/nginx/html/index.html"]
      preStop:
        exec: # 在容器停止之前停止nginx服务
          command: ["/usr/sbin/nginx","-s","quit"]
# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-hook-exec.yaml
pod/pod-hook-exec created

# 查看pod
[root@k8s-master01 ~]# kubectl get pods  pod-hook-exec -n dev -o wide
NAME           READY   STATUS     RESTARTS   AGE    IP            NODE    
pod-hook-exec  1/1     Running    0          29s    10.244.2.48   node2   

# 访问pod
[root@k8s-master01 ~]# curl 10.244.2.48
postStart...

演示

Pod的重启策略（RestartPolicy）应用于Pod内的所有容器

Pod的重启策略包括Always、OnFailure和Never，默认值为Always。

Always：当容器失效时，由kubelet自动重启该容器。
OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器。
Never：不论容器运行状态如何，kubelet都不会重启该容器。

　　kubelet重启失效容器的时间间隔以sync-frequency乘以2n来计算，例如1、2、4、8倍等，最长延时5min，并且在成功重启后的10min后重置该时间

　　Pod的重启策略与控制方式息息相关，当前可用于管理Pod的控制器包括ReplicationController、Job、DaemonSet，还可以通过kubelet管理（静态Pod）。每种控制器对Pod的重启策略要求如下

RC和DaemonSet：必须设置为Always，需要保证该容器持续运行
Job：OnFailure或Never，确保容器执行完成后不再重启
kubelet：在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查

Pod常见的状态转换场景

　　RC的继任者其实并不是Deployment，而是ReplicaSet，因为ReplicaSet进一步增强了RC标签选择器的灵活性。之前RC的标签选择器只能选择一个标签，而ReplicaSet拥有集合式的标签选择器，可以选择多个Pod标签
　　其实，Kubernetes的滚动升级就是巧妙运用ReplicaSet的这个特性来实现的，同时，Deployment也是通过ReplicaSet来实现Pod副本自动控制功能的。我们不应该直接使用底层的ReplicaSet来控制Pod副本，而应该通过管理ReplicaSet的Deployment对象来控制副本

Pod健康检查和服务可用性检查

探针的种类

　　Kubernetes对Pod的健康状态可以通过三类探针来检查：LivenessProbe、ReadinessProbe及StartupProbe，其中最主要的探针为LivenessProbe与ReadinessProbe，kubelet会定期执行这两类探针来诊断容器的健康状况。

（1）LivenessProbe探针：用于判断容器是否存活（Running状态），如果LivenessProbe探针探测到容器不健康，则kubelet将“杀掉”该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的值永远是Success。
（2）ReadinessProbe探针：用于判断容器服务是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod，Service与Pod Endpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready状态变为False，则系统自动将其从Service的后端Endpoint列表中隔离出去，后续再把恢复到Ready状态的Pod加回后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。需要注意的是，ReadinessProbe也是定期触发执行的，存在于Pod的整个生命周期中。
（3）StartupProbe探针：某些应用会遇到启动比较慢的情况，例如应用程序启动时需要与远程服务器建立网络连接，或者遇到网络访问较慢等情况时，会造成容器启动缓慢，此时ReadinessProbe就不适用了，因为这属于“有且仅有一次”的超长延时，可以通过StartupProbe探针解决该问题

探针均可配置以下三种实现方式

（1）ExecAction：在容器内部运行一个命令，如果该命令的返回码为0，则表明容器健康

　　通过运行cat/tmp/health命令来判断一个容器运行是否正常。在该Pod运行后，将在创建/tmp/health文件10s后删除该文件，而LivenessProbe健康检查的初始探测时间（initialDelaySeconds）为15s，探测结果是Fail，将导致kubelet“杀掉”该容器并重启它

……
  livenessProbe:
    exec:
      command:
      - cat
      - /tmp/healthy
……

（2）TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。

……      
  livenessProbe:
    tcpSocket:
      port: 8080
……

（3）HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康

……
  livenessProbe:
    httpGet:
      path: / #URI地址
      port: 80 #端口号
      host: 127.0.0.1 #主机地址
      scheme: HTTP #支持的协议，http或者https
……

对于每种探测方式，都需要设置initialDelaySeconds和timeoutSeconds两个参数，它们的含义分别如下。

initialDelaySeconds：启动容器后进行首次健康检查的等待时间，单位为s。
timeoutSeconds：健康检查发送请求后等待响应的超时时间，单位为s。当超时发生时，kubelet会认为容器已经无法提供服务，将会重启该容器。

　　如下代码片段是StartupProbe探针的一个参考配置，可以看到，这个Pod可以有长达30×10=300s的超长启动时间：

pod调度策略

Deployment或RC：全自动调度

　　Deployment或RC的主要功能之一就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量
　　Pod由系统全自动完成调度。它们各自最终运行在哪个节点上，完全由Master的Scheduler经过一系列算法计算得出，用户无法干预调度过程和结果
　　除了使用系统自动调度算法完成一组Pod的部署，Kubernetes也提供了多种丰富的调度策略，用户只需在Pod的定义中使用NodeSelector、NodeAffinity、PodAffinity、Pod驱逐等更加细粒度的调度策略设置，就能完成对Pod的精准调度

NodeSelector：定向调度

　　除了用户可以自行给Node添加标签，Kubernetes也会给Node预定义一些标签，包括：

kubernetes.io/hostname；
beta.kubernetes.io/os（从1.14版本开始更新为稳定版，到1.18版本删除）；
beta.kubernetes.io/arch（从1.14版本开始更新为稳定版，到1.18版本删除）；
kubernetes.io/os（从1.14版本开始启用）；
kubernetes.io/arch（从1.14版本开始启用）。

　　NodeSelector通过标签的方式，简单实现了限制Pod所在节点的方法。亲和性调度机制则极大扩展了Pod的调度能力，主要的增强功能如下。

更具表达力（不仅仅是“符合全部”的简单情况）。
可以使用软限制、优先采用等限制方式，代替之前的硬限制，这样调度器在无法满足优先需求的情况下，会退而求其次，继续运行该Pod。
可以依据节点上正在运行的其他Pod的标签来进行限制，而非节点本身的标签。这样就可以定义一种规则来描述Pod之间的亲和或互斥关系。

　　亲和性调度功能包括节点亲和性（NodeAffinity）和Pod亲和性（PodAffinity）两个维度的设置。节点亲和性与NodeSelector类似，增强了上述前两点优势；Pod的亲和与互斥限制则通过Pod标签而不是节点标签来实现，也就是上面第4点内容所陈述的方式，同时具有前两点提到的优点

NodeAffinity：Node亲和性调度

　　NodeAffinity意为Node亲和性的调度策略，是用于替换NodeSelector的全新调度策略。目前有两种节点亲和性表达。

RequiredDuringSchedulingIgnoredDuringExecution：必须满足指定的规则才可以调度Pod到Node上（功能与nodeSelector很像，但是使用的是不同的语法），相当于硬限制。
PreferredDuringSchedulingIgnoredDuringExecution：强调优先满足指定规则，调度器会尝试调度Pod到Node上，但并不强求，相当于软限制。多个优先级规则还可以设置权重（weight）值，以定义执行的先后顺序。

　　IgnoredDuringExecution的意思是：如果一个Pod所在的节点在Pod运行期间标签发生了变更，不再符合该Pod的节点亲和性需求，则系统将忽略Node上Label的变化，该Pod能继续在该节点上运行。
　　下面的例子设置了NodeAffinity调度的如下规则。

required DuringS chedulingIgnoredDuringExecution：要求只运行在amd64的节点上（beta.kubernetes.io/arch In amd64）。
preferredDuringSchedulingIgnoredDuringExecution：要求尽量运行在磁盘类型为ssd（disk-type In ssd）的节点上。

　　NodeAffinity规则设置的注意事项如下。

如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能最终运行在指定的Node上。
如果nodeAffinity指定了多个nodeSelectorTerms，那么其中一个能匹配成功即可。
如果在nodeSelectorTerms中有多个matchExpressions，则一个节点必须满足所有matchExpressions才能运行该Pod。

PodAffinity：Pod亲和与互斥调度策略

　　与节点亲和性类似，Pod亲和性的操作符也包括In、NotIn、Exists、DoesNotExist、Gt、Lt。
　　原则上，topologyKey可以使用任意合法的标签Key赋值，但是出于性能和安全方面的考虑，对topologyKey有如下限制。

在Pod亲和性和RequiredDuringScheduling的Pod互斥性的定义中，不允许使用空的topologyKey。
如果Admission controller包含了LimitPodHardAntiAffinityTopology，那么针对Required DuringScheduling的Pod互斥性定义就被限制为kubernetes.io/hostname，要使用自定义的topologyKey，就要改写或禁用该控制器。
在PreferredDuringScheduling类型的Pod互斥性定义中，空的topologyKey会被解释为kubernetes.io/hostname、failure-domain.beta.kubernetes.io/zone及failure-domain.beta.kubernetes.io/region的组合。

　　如果不是上述情况，就可以采用任意合法的topologyKey了。

　　PodAffinity规则设置的注意事项如下

除了设置Label Selector和topologyKey，用户还可以指定Namespace列表进行限制，同样，使用Label Selector对Namespace进行选择。Namespace的定义和Label Selector及topologyKey同级。省略Namespace的设置，表示使用定义了affinity/anti-affinity的Pod所在的命名空间。如果Namespace被设置为空值（""），则表示所有命名空间。
在所有关联requiredDuringSchedulingIgnoredDuringExecution的matchExpressions全都满足之后，系统才能将Pod调度到某个Node上

Pod Priority Preemption：Pod优先级调度

　　在Kubernetes 1.8版本之前，当集群的可用资源不足时，在用户提交新的Pod创建请求后，该Pod会一直处于Pending状态，即使这个Pod是一个很重要（很有身份）的Pod，也只能被动等待其他Pod被删除并释放资源，才能有机会被调度成功。

　　Kubernetes 1.8版本引入了基于Pod优先级抢占（Pod Priority Preemption）的调度策略，此时Kubernetes会尝试释放目标节点上低优先级的Pod，以腾出空间（资源）安置高优先级的Pod，这种调度方式被称为“抢占式调度”。在Kubernetes 1.11版本中，该特性升级为Beta版本，默认开启，在后续的Kubernetes 1.14版本中正式Release。如何声明一个负载相对其他负载更重要？我们可以通过以下几个维度来定义：Priority：优先级；QoS：服务质量等级；系统定义的其他度量指标。

　　优先级抢占调度策略的核心行为分别是驱逐（Eviction）与抢占（Preemption），这两种行为的使用场景不同，效果相同。Eviction是kubelet进程的行为，即当一个Node资源不足（under resource pressure）时，该节点上的kubelet进程会执行驱逐动作，此时kubelet会综合考虑Pod的优先级、资源申请量与实际使用量等信息来计算哪些Pod需要被驱逐；当同样优先级的Pod需要被驱逐时，实际使用的资源量超过申请量最大倍数的高耗能Pod会被首先驱逐。对于QoS等级为“Best Effort”的Pod来说，由于没有定义资源申请（CPU/Memory Request），所以它们实际使用的资源可能非常大。Preemption则是Scheduler执行的行为，当一个新的Pod因为资源无法满足而不能被调度时，Scheduler可能（有权决定）选择驱逐部分低优先级的Pod实例来满足此Pod的调度目标，这就是Preemption机制

　　优先级为100000，数字越大，优先级越高，超过一亿的数字被系统保留，用于指派给系统组件

DaemonSet：在每个Node上都调度一个Pod

　　这种用法适合有这种需求的应用。

在每个Node上都运行一个GlusterFS存储或者Ceph存储的Daemon进程。
在每个Node上都运行一个日志采集程序，例如Fluentd或者Logstach。
在每个Node上都运行一个性能监控程序，采集该Node的运行性能数据，例如Prometheus Node Exporter、collectd、New Relic agent或者Ganglia gmond等。

　　DaemonSet调度不同于普通的Pod调度，所以没有用默认的Kubernetes Scheduler进行调度，而是通过专有的**DaemonSet Controller**进行调度。但是随着Kubernetes版本的改进和调度特性不断丰富，产生了一些难以解决的矛盾，最主要的两个矛盾如下。

普通的Pod是在Pending状态触发调度并被实例化的，DaemonSet Controller并不是在这个状态调度Pod的，这种不一致容易误导和迷惑用户。
Pod优先级调度是被Kubernetes Scheduler执行的，而DaemonSet Controller并没有考虑到Pod优先级调度的问题，也产生了不一致的结果。
从Kubernetes 1.18开始，DaemonSet的调度默认切换到Kubernetes Scheduler进行，**从而一劳永逸地解决了以上问题及未来可能的新问题。因为默认切换到了Kubernetes Scheduler统一调度Pod，因此DaemonSet也能正确处理Taints和Tolerations的问题。

Taints和Tolerations（污点和容忍）

　　Pod的Toleration声明中的key和effect需要与Taint的设置保持一致，并且满足以下条件之一。

operator的值是Exists（无须指定value）。
operator的值是Equal并且value相等。
如果不指定operator，则默认值为Equal。

　　另外，有如下两个特例

空的key配合Exists操作符能够匹配所有键和值。
空的effect匹配所有effect

　　几种特殊情况

如果在剩余的Taint中存在effect=NoSchedule，则调度器不会把该Pod调度到这一节点上。
如果在剩余的Taint中没有NoSchedule效果，但是有PreferNoSchedule效果，则调度器会尝试不把这个Pod指派给这个节点。

Job：批处理调度

　　考虑到批处理的并行问题，Kubernetes将Job分以下三种类型

（1）Non-parallel Jobs：通常一个Job只启动一个Pod，除非Pod异常，才会重启该Pod，一旦此Pod正常结束，Job将结束。
（2）Parallel Jobs with a fixed completion count：并行Job会启动多个Pod，此时需要设定Job的.spec.completions参数为一个正数，当正常结束的Pod数量达至此参数设定的值后，Job结束。此外，Job的.spec.parallelism参数用来控制并行度，即同时启动几个Job来处理Work item。
（3）Parallel Jobs with a work queue：任务队列方式的并行Job需要一个独立的Queue，Work item都在一个Queue中存放，不能设置Job的.spec.completions参数，此时Job有以下特性。

每个Pod都能独立判断和决定是否还有任务项需要处理。
如果某个Pod正常结束，则Job不会再启动新的Pod。
如果一个Pod成功结束，则此时应该不存在其他Pod还在工作的情况，它们应该都处于即将结束、退出的状态。
如果所有Pod都结束了，且至少有一个Pod成功结束，则整个Job成功结束

Cronjob：定时任务

　　首先，确保Kubernetes的版本为1.8及以上
　　其次，需要掌握Cron Job的定时表达式，它基本上照搬了Linux Cron的表达式

pod的容灾调度

　　为了满足这种容灾场景下的特殊调度需求，在Kubernetes 1.16版本中首次引入Even Pod Spreading特性，用于通过topologyKey属性识别Zone，并通过设置新的参数topologySpreadConstraints来将Pod均匀调度到不同的Zone
　　关键的参数是maxSkew。maxSkew用于指定Pod在各个Zone上调度时能容忍的最大不均衡数：值越大，表示能接受的不均衡调度越大；值越小，表示各个Zone的Pod数量分布越均匀。
　　为了理解maxSkew，我们需要先理解skew参数的计算公式：skew[topo]=count[topo]-min（count[topo]），即每个拓扑区域的skew值都为该区域包括的目标Pod数量与整个拓扑区域最少Pod数量的差，而maxSkew就是最大的skew值

假如在上面的例子中有3个拓扑区域，分别为Zone A、Zone B及Zone C，有3个目标Pod需要调度到这些拓扑区域，那么前两个毫无疑问会被调度到Zone A和Zone B
可以手动计算每个Zone的skew，首先计算出min（count[topo]）是0，对应Zone C，于是Zone A的skew=1-0=1，Zone B的skew=1-0=0，Zone C的skew=0-0=0，于是第3个Pod应该被放在Zone C，此时min（count[topo]）的值就变成了1，而实际的maxSkew的值为0，符合预期设置。如果我们把maxSkew设置为2，则在这种情况下，第3个Pod被放在Zone A或Zone B都是符合要求的

StatefulSet

　　在创建StatefulSet之前，需要确保在Kubernetes集群中管理员已经创建好共享存储，并能够与StorageClass对接，以实现动态存储供应的模式
　　为了完成MongoDB集群的搭建，需要部署以下三个资源对象。

一个StorageClass：用于StatefulSet自动为各个应用Pod申请PVC。
一个Headless Service（clusterIP: None）：用于设置MongoDB实例的域名。
一个StatefulSet

　　mongo-sidecar作为MongoDB集群的管理者，将使用此Headless Service来维护各个MongoDB实例之间的集群关系，以及集群规模变化时的自动更新

StatefulSet的常见应用场景

集群进行扩容,仅需要通过对StatefulSet进行scale操作（或修改yaml文件）
自动故障修复
- 实例或其所在主机发生故障，则StatefulSet将会自动重建该实例，并保证其身份（ID）和使用的数据（PVC）不变

Service

Service概念和原理

　　Service是Kubernetes实现微服务架构的核心概念，通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上

　　Service用于为一组提供服务的Pod抽象一个稳定的网络访问地址，是Kubernetes实现微服务的核心概念。通过Service的定义设置的访问地址是DNS域名格式的服务名称，对于客户端应用来说，网络访问方式并没有改变（DNS域名的作用等价于主机名、互联网域名或IP地址）。Service还提供了负载均衡器功能，将客户端请求负载分发到后端提供具体服务的各个Pod上

　　Service主要用于提供网络服务，通过Service的定义，能够为客户端应用提供稳定的访问地址（域名或IP地址）和负载均衡功能，以及屏蔽后端Endpoint的变化，是Kubernetes实现微服务的核心资源

　　Service不仅具有标准网络协议的IP地址，还以DNS域名的形式存在。Service的域名表示方法为<servicename>.<namespace>.svc.<clusterdomain>，servicename为服务的名称，namespace为其所在namespace的名称，clusterdomain为Kubernetes集群设置的域名后缀。服务名称的命名规则遵循RFC 1123规范

Service负载均衡机制

　　kube-proxy的代理模式、会话保持机制和基于拓扑感知的服务路由机制（EndpointSlices）

kube-proxy的代理模式

　　kube-proxy提供了以下代理模式（通过启动参数--proxy-mode设置）

userspace模式：用户空间模式，由kube-proxy完成代理的实现，效率最低，不再推荐使用。
iptables模式：kube-proxy通过设置Linux Kernel的iptables规则，实现从Service到后端Endpoint列表的负载分发规则，效率很高。但是，如果某个后端Endpoint在转发时不可用，此次客户端请求就会得到失败的响应，相对于userspace模式来说更不可靠。此时应该通过为Pod设置readinessprobe（服务可用性健康检查）来保证只有达到ready状态的Endpoint才会被设置为Service的后端Endpoint。
ipvs模式：在Kubernetes 1.11版本中达到Stable阶段，kube-proxy通过设置Linux Kernel的netlink接口设置IPVS规则，转发效率和支持的吞吐率都是最高的。ipvs模式要求Linux Kernel启用IPVS模块，如果操作系统未启用IPVS内核模块，kube-proxy则会自动切换至iptables模式。同时，ipvs模式支持更多的负载均衡策略，如下所述。
- rr：round-robin，轮询。
- lc：least connection，最小连接数。
- dh：destination hashing，目的地址哈希。
- sh：source hashing，源地址哈希。
- sed：shortest expected delay，最短期望延时。
- nq：never queue，永不排队。
kernelspace模式：Windows Server上的代理模式

会话保持机制

　　Service支持通过设置sessionAffinity实现基于客户端IP的会话保持机制，即首次将某个客户端来源IP发起的请求转发到后端的某个Pod上，之后从相同的客户端IP发起的请求都将被转发到相同的后端Pod上，配置参数为service.spec.sessionAffinity

　　同时，用户可以设置会话保持的最长时间，在此时间之后重置客户端来源IP的保持规则，配置参数为service.spec.sessionAffinityConfig.clientIP.timeoutSeconds

基于拓扑感知的服务路由机制制（EndpointSlices）

将外部服务定义为Service

　　普通的Service通过Label Selector对后端Endpoint列表进行了一次抽象，如果后端的Endpoint不是由Pod副本集提供的，则Service还可以抽象定义任意其他服务，将一个Kubernetes集群外部的已知服务定义为Kubernetes内的一个Service，供集群内的其他应用访问，常见的应用场景包括：

已部署的一个集群外服务，例如数据库服务、缓存服务等；
其他Kubernetes集群的某个服务；
迁移过程中对某个服务进行Kubernetes内的服务名访问机制的验证。

　　对于这种应用场景，用户在创建Service资源对象时不设置Label Selector（后端Pod也不存在），同时再定义一个与Service关联的Endpoint资源对象，在Endpoint中设置外部服务的IP地址和端口号

将Service暴露到集群外部

目前Service的类型如下。

ClusterIP：Kubernetes默认会自动设置Service的虚拟IP地址，仅可被集群内部的客户端应用访问。当然，用户也可手工指定一个ClusterIP地址，不过需要确保该IP在Kubernetes集群设置的ClusterIP地址范围内（通过kube-apiserver服务的启动参数--service-cluster-ip-range设置），并且没有被其他Service使用。
NodePort：将Service的端口号映射到每个Node的一个端口号上，这样集群中的任意Node都可以作为Service的访问入口地址，即NodeIP：NodePort。
LoadBalancer：将Service映射到一个已存在的负载均衡器的IP地址上，通常在公有云环境中使用。
ExternalName：将Service映射为一个外部域名地址，通过externalName字段进行设置

Service支持的网络协议

TCP：Service的默认网络协议，可用于所有类型的Service。
UDP：可用于大多数类型的Service，LoadBalancer类型取决于云服务商对UDP的支持。
HTTP：取决于云服务商是否支持HTTP和实现机制。
PROXY：取决于云服务商是否支持HTTP和实现机制。
SCTP：从Kubernetes 1.12版本引入，到1.19版本时达到Beta阶段，默认启用，如需关闭该特性，则需要设置kube-apiserver的启动参数--feature-gates=SCTPSupport=false进行关闭

　　Kubernetes从1.17版本开始，可以为Service和Endpoint资源对象设置一个新的字段“AppProtocol”，用于标识后端服务在某个端口号上提供的应用层协议类型，例如HTTP、HTTPS、SSL、DNS等，该特性在Kubernetes 1.19版本时达到Beta阶段，计划于Kubernetes 1.20 版本时达到GA阶段。要使用AppProtocol，需要设置kube-apiserver的启动参数--feature-gates=ServiceAppProtocol=true进行开启，然后在Service或Endpoint的定义中设置AppProtocol字段指定应用层协议的类型

Kubernetes的服务发现机制

环境变量方式

　　在一个Pod运行起来的时候，系统会自动为其容器运行环境注入所有集群中有效Service的信息。Service的相关信息包括服务IP、服务端口号、各端口号相关的协议等，通过{SVCNAME}_SERVICE_HOST和{SVCNAME}_SERVICE_PORT格式进行设置。其中，SVCNAME的命名规则为：将Service的name字符串转换为全大写字母，将中横线“-”替换为下画线“_”

DNS方式

　　Service在Kubernetes系统中遵循DNS命名规范，Service的DNS域名表示方法为<servicename>.<namespace>.svc.<clusterdomain>，其中servicename为服务的名称，namespace为其所在namespace的名称，clusterdomain为Kubernetes集群设置的域名后缀（例如cluster.local），服务名称的命名规则遵循RFC 1123规范的要求

　　对于客户端应用来说，DNS域名格式的Service名称提供的是稳定、不变的访问地址，可以大大简化客户端应用的配置，是Kubernetes集群中推荐的使用方式。
　　目前由CoreDNS作为Kubernetes集群的默认DNS服务器提供域名解析服务

　　Service定义中的端口号如果设置了名称（name），则该端口号也会拥有一个DNS域名，在DNS服务器中以SRV记录的格式保存：_<portname>._<protocol>.<servicename>.<namespace>.svc.<clusterdomain>，其值为端口号的数值

Headless Service

　　Headless Service的概念是这种服务没有入口访问地址（无ClusterIP地址），kube-proxy不会为其创建负载转发规则，而服务名（DNS域名）的解析机制取决于该Headless Service是否设置了Label Selector

Headless Service没有设置Label Selector

如果Headless Service没有设置Label Selector，则Kubernetes将不会自动创建对应的Endpoint列表。DNS系统会根据下列条件尝试对该服务名设置DNS记录：

如果Service的类型为ExternalName，则对服务名的访问将直接被DNS系统转换为Service设置的外部名称（externalName）；
如果系统中存在与Service同名的Endpoint定义，则服务名将被解析为Endpoint定义中的列表，适用于非ExternalName类型的Service。

端点分片与服务拓扑

　　Service的后端是一组Endpoint列表，为客户端应用提供了极大的便利。但是随着集群规模的扩大及Service数量的增加，特别是Service后端Endpoint数量的增加，kube-proxy需要维护的负载分发规则（例如iptables规则或ipvs规则）的数量也会急剧增加，导致后续对Service后端Endpoint的添加、删除等更新操作的成本急剧上升。

　　举例来说，假设在Kubernetes集群中有10000个Endpoint运行在大约5000个Node上，则对单个Pod的更新将需要总计约5GB的数据传输，这不仅对集群内的网络带宽浪费巨大，而且对Master的冲击非常大，会影响Kubernetes集群的整体性能，在Deployment不断进行滚动升级操作的情况下尤为突出。

　　Kubernetes从1.16版本开始引入端点分片（Endpoint Slices）机制，包括一个新的EndpointSlice资源对象和一个新的EndpointSlice控制器。从Kubernetes 1.17版本开始，EndpointSlice机制默认是启用的（在1.16版本中需要通过设置kube-apiserver和kube-proxy服务的启动参数--feature-gates="EndpointSlice=true"进行启用）

　　另外，kube-proxy默认仍然使用Endpoint对象，为了提高性能，可以设置kube-proxy启动参数--feature-gates="EndpointSliceProxying=true"让kube-proxy使用EndpointSlice，这样可以减少kube-proxy与master之间的网络通信并提高性能。Kubernetes从1.19版本开始默认开启该特性

　　EndpointSlice通过对Endpoint进行分片管理来实现降低Master和各Node之间的网络传输数据量及提高整体性能的目标。对于Deployment的滚动升级，可以实现仅更新部分Node上的Endpoint信息，Master与Node之间的数据传输量可以减少100倍左右，能够大大提高管理效率

　　默认情况下，在由EndpointSlice控制器创建的EndpointSlice中最多包含100个Endpoint，如需修改，则可以通过kube-controller-manager服务的启动参数--max-endpoints-per-slice设置，但上限不能超过1000

　　EndpointSlice的关键信息如下。
（1）关联的服务名称：将EndpointSlice与Service的关联信息设置为一个标签kubernetes.io/service-name=webapp，该标签标明了服务名称。
（2）地址类型AddressType：包括以下3种取值类型

IPv4：IPv4格式的IP地址
IPv6：IPv6格式的IP地址。
FQDN：全限定域名。

（3）在Endpoints列表中列出的每个Endpoint的信息。

Addresses：Endpoint的IP地址。
Conditions：Endpoint状态信息，作为EndpointSlice的查询条件。
Hostname：在Endpoint中设置的主机名hostname。
TargetRef：Endpoint对应的Pod名称。
Topology：拓扑信息，为基于拓扑感知的服务路由提供数据。

　　目前EndpointSlice控制器自动设置的拓扑信息如下。

kubernetes.io/hostname：Endpoint所在Node的名称。
topology.kubernetes.io/zone：Endpoint所在的Zone信息，使用Node标签topology.kubernetes.io/zone的值，例如上例中的Node拥有“topology.kubernetes.io/zone：north”标签。
topology.kubernetes.io/region：Endpoint所在的Region信息，使用Node标签topology.kubernetes.io/region的值。

（4）EndpointSlice的管理控制器：通过endpointslice.kubernetes.io/managed-by标签进行设置，用于存在多个管理控制器的应用场景中

DNS服务搭建和配置指南

kubernetes中的dns发展史

　　在Kubernetes 1.2版本时，DNS服务是由SkyDNS提供的，它由4个容器组成：kube2sky、skydns、etcd和healthz

　　从Kubernetes 1.4版本开始，SkyDNS组件便被KubeDNS替换，主要考虑的是SkyDNS组件之间通信较多，整体性能不高。KubeDNS由3个容器组成：kubedns、dnsmasq和sidecar，去掉了SkyDNS中的etcd存储，将DNS记录直接保存在内存中，以提高查询性能

　　从Kubernetes 1.11版本开始，Kubernetes集群的DNS服务便由CoreDNS提供。CoreDNS是CNCF基金会孵化的一个项目，是用Go语言实现的高性能、插件式、易扩展的DNS服务端，目前已毕业。

　　CoreDNS解决了KubeDNS的一些问题，例如dnsmasq的安全漏洞、externalName不能使用stubDomains进行设置，等等。CoreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS。它没有使用多个容器的架构，只用一个容器便实现了KubeDNS内3个容器的全部功能

　　coreDNS的架构

修改每个Node上kubelet的启动参数，在其中加上以下两个参数。

◎　--cluster-dns=169.169.0.100：为DNS服务的ClusterIP地址。
◎　--cluster-domain=cluster.local：为在DNS服务中设置的域名。
然后重启kubelet服务。

部署CoreDNS服务

　　部署CoreDNS服务时需要创建3个资源对象：1个ConfigMap、1个Deployment和1个Service。在启用了RBAC的集群中，还可以设置ServiceAccount、ClusterRole、ClusterRoleBinding对CoreDNS容器进行权限设置

　　Deployment“coredns”主要设置CoreDNS容器应用的内容，其中，replicas副本的数量通常应该根据集群的规模和服务数量确定，如果单个CoreDNS进程不足以支撑整个集群的DNS查询，则可以通过水平扩展提高查询能力。由于DNS服务是Kubernetes集群的关键核心服务，所以建议为其Deployment设置自动扩缩容控制器，自动管理其副本数量。

　　另外，对资源限制部分（CPU限制和内存限制）的设置也应根据实际环境进行调整

　　Service“kube-dns”是DNS服务的配置，这个服务需要设置固定的ClusterIP地址，也需要将所有Node上的kubelet启动参数--cluster-dns都设置为这个ClusterIP地址

CoreDNS的配置说明

　　CoreDNS的主要功能是通过插件系统实现的。CoreDNS实现了一种链式插件结构，将DNS的逻辑抽象成了一个个插件，能够灵活组合使用

常用的插件如下。

loadbalance：提供基于DNS的负载均衡功能。
loop：检测在DNS解析过程中出现的简单循环问题。
cache：提供前端缓存功能。
health：对Endpoint进行健康检查。
kubernetes：从Kubernetes中读取zone数据。
etcd：从etcd中读取zone数据，可用于自定义域名记录。
file：从RFC1035格式文件中读取zone数据。
hosts：使用/etc/hosts文件或者其他文件读取zone数据，可用于自定义域名记录。
auto：从磁盘中自动加载区域文件。
reload：定时自动重新加载Corefile配置文件的内容。
forward：转发域名查询到上游DNS服务器上。
prometheus：为Prometheus系统提供采集性能指标数据的URL。
pprof：在URL路径/debug/pprof下提供运行时的性能数据。
log：对DNS查询进行日志记录。
errors：对错误信息进行日志记录。

　　域名“cluster.local”设置了一系列插件，包括errors、health、ready、kubernetes、prometheus、forward、cache、loop、reload和loadbalance，在进行域名解析时，这些插件将以从上到下的顺序依次执行

数据存储

基本存储

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

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

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

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

EmptyDir

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

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

　　在一个Pod中准备两个容器nginx和busybox，然后声明一个Volume分别挂在到两个容器的目录中，然后nginx容器负责向Volume中写日志，busybox中通过命令将日志内容读到控制台。

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

View Code

HostPath

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

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

apiVersion: v1
kind: Pod
metadata:
  name: volume-hostpath
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/access.log"]
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  volumes:
  - name: logs-volume
    hostPath: 
      path: /root/logs
      type: DirectoryOrCreate  # 目录存在就使用，不存在就先创建后使用

View Code

关于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
2）接下来，要在的每个node节点上都安装下nfs，这样的目的是为了node节点可以驱动nfs设备

# 在node上安装nfs服务，注意不需要启动
[root@k8s-master01 ~]# yum install nfs-utils -y
3）接下来，就可以编写pod的配置文件了，创建volume-nfs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-nfs
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/access.log"] 
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  volumes:
  - name: logs-volume
    nfs:
      server: 192.168.5.6  #nfs服务器地址
      path: /root/data/nfs #共享文件路径
4）最后，运行下pod，观察结果

# 创建pod
[root@k8s-master01 ~]# kubectl create -f volume-nfs.yaml
pod/volume-nfs created

# 查看pod
[root@k8s-master01 ~]# kubectl get pods volume-nfs -n dev
NAME                  READY   STATUS    RESTARTS   AGE
volume-nfs        2/2     Running   0          2m9s

# 查看nfs服务器上的共享目录，发现已经有文件了
[root@k8s-master01 ~]# ls /root/data/
access.log  error.log

View Code

高级存储

　　由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。

PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。
PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

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

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

PV

　　PV是存储资源的抽象，下面是资源清单文件:

apiVersion: v1  
kind: PersistentVolume
metadata:
  name: pv2
spec:
  nfs: # 存储类型，与底层真正存储对应
  capacity:  # 存储能力，目前只支持存储空间的设置
    storage: 2Gi
  accessModes:  # 访问模式
  storageClassName: # 存储类别
  persistentVolumeReclaimPolicy: # 回收策略

　　PV 的关键配置参数说明：

存储类型

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

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

访问模式（accessModes）

用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：
- ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
- ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
- ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
需要注意的是，底层不同的存储类型可能支持的访问模式不同
回收策略（persistentVolumeReclaimPolicy）

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

PV可以通过storageClassName参数指定一个存储类别
- 具有特定类别的PV只能与请求了该类别的PVC进行绑定
- 未设定类别的PV则只能与不请求任何类别的PVC进行绑定
状态（status）

一个 PV 的生命周期中，可能会处于4中不同的阶段：
- Available（可用）：表示可用状态，还未被任何 PVC 绑定
- Bound（已绑定）：表示 PV 已经被 PVC 绑定
- Released（已释放）：表示 PVC 被删除，但是资源还未被集群重新声明
- Failed（失败）：表示该 PV 的自动回收失败

使用NFS作为存储，来演示PV的使用，创建3个PV，对应NFS中的3个暴露的路径。

准备NFS环境
# 创建目录
[root@nfs ~]# mkdir /root/data/{pv1,pv2,pv3} -pv

# 暴露服务
[root@nfs ~]# more /etc/exports
/root/data/pv1     192.168.5.0/24(rw,no_root_squash)
/root/data/pv2     192.168.5.0/24(rw,no_root_squash)
/root/data/pv3     192.168.5.0/24(rw,no_root_squash)

# 重启服务
[root@nfs ~]#  systemctl restart nfs
创建pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv1
spec:
  capacity: 
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv1
    server: 192.168.5.6

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv2
spec:
  capacity: 
    storage: 2Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv2
    server: 192.168.5.6
    
---

apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv3
spec:
  capacity: 
    storage: 3Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv3
    server: 192.168.5.6
# 创建 pv
[root@k8s-master01 ~]# kubectl create -f pv.yaml
persistentvolume/pv1 created
persistentvolume/pv2 created
persistentvolume/pv3 created

# 查看pv
[root@k8s-master01 ~]# kubectl get pv -o wide
NAME   CAPACITY   ACCESS MODES  RECLAIM POLICY  STATUS      AGE   VOLUMEMODE
pv1    1Gi        RWX            Retain        Available    10s   Filesystem
pv2    2Gi        RWX            Retain        Available    10s   Filesystem
pv3    3Gi        RWX            Retain        Available    9s    Filesystem

View Code

PVC

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

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

　　PVC 的关键配置参数说明：

访问模式（accessModes）

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

选择条件（selector）

通过Label Selector的设置，可使PVC对于系统中己存在的PV进行筛选
存储类别（storageClassName）

PVC在定义时可以设定需要的后端存储的类别，只有设置了该class的pv才能被系统选出
资源请求（Resources ）

描述对存储资源的请求

创建pvc.yaml，申请pv
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
  namespace: dev
spec:
  accessModes: 
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc2
  namespace: dev
spec:
  accessModes: 
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc3
  namespace: dev
spec:
  accessModes: 
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
# 创建pvc
[root@k8s-master01 ~]# kubectl create -f pvc.yaml
persistentvolumeclaim/pvc1 created
persistentvolumeclaim/pvc2 created
persistentvolumeclaim/pvc3 created

# 查看pvc
[root@k8s-master01 ~]# kubectl get pvc  -n dev -o wide
NAME   STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE   VOLUMEMODE
pvc1   Bound    pv1      1Gi        RWX                           15s   Filesystem
pvc2   Bound    pv2      2Gi        RWX                           15s   Filesystem
pvc3   Bound    pv3      3Gi        RWX                           15s   Filesystem

# 查看pv
[root@k8s-master01 ~]# kubectl get pv -o wide
NAME  CAPACITY ACCESS MODES  RECLAIM POLICY  STATUS    CLAIM       AGE     VOLUMEMODE
pv1    1Gi        RWx        Retain          Bound    dev/pvc1    3h37m    Filesystem
pv2    2Gi        RWX        Retain          Bound    dev/pvc2    3h37m    Filesystem
pv3    3Gi        RWX        Retain          Bound    dev/pvc3    3h37m    Filesystem   
创建pods.yaml, 使用pv
apiVersion: v1
kind: Pod
metadata:
  name: pod1
  namespace: dev
spec:
  containers:
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]
    volumeMounts:
    - name: volume
      mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc1
        readOnly: false
---
apiVersion: v1
kind: Pod
metadata:
  name: pod2
  namespace: dev
spec:
  containers:
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","while true;do echo pod2 >> /root/out.txt; sleep 10; done;"]
    volumeMounts:
    - name: volume
      mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc2
        readOnly: false
# 创建pod
[root@k8s-master01 ~]# kubectl create -f pods.yaml
pod/pod1 created
pod/pod2 created

# 查看pod
[root@k8s-master01 ~]# kubectl get pods -n dev -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP            NODE   
pod1   1/1     Running   0          14s   10.244.1.69   node1   
pod2   1/1     Running   0          14s   10.244.1.70   node1  

# 查看pvc
[root@k8s-master01 ~]# kubectl get pvc -n dev -o wide
NAME   STATUS   VOLUME   CAPACITY   ACCESS MODES      AGE   VOLUMEMODE
pvc1   Bound    pv1      1Gi        RWX               94m   Filesystem
pvc2   Bound    pv2      2Gi        RWX               94m   Filesystem
pvc3   Bound    pv3      3Gi        RWX               94m   Filesystem

# 查看pv
[root@k8s-master01 ~]# kubectl get pv -n dev -o wide
NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM       AGE     VOLUMEMODE
pv1    1Gi        RWX            Retain           Bound    dev/pvc1    5h11m   Filesystem
pv2    2Gi        RWX            Retain           Bound    dev/pvc2    5h11m   Filesystem
pv3    3Gi        RWX            Retain           Bound    dev/pvc3    5h11m   Filesystem

# 查看nfs中的文件存储
[root@nfs ~]# more /root/data/pv1/out.txt
node1
node1
[root@nfs ~]# more /root/data/pv2/out.txt
node2
node2

View Code

生命周期

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

资源供应：管理员手动创建底层存储和PV
资源绑定：用户创建PVC，kubernetes负责根据PVC的声明去寻找PV，并绑定

在用户定义好PVC之后，系统将根据PVC对存储资源的请求在已存在的PV中选择一个满足条件的
- 一旦找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了
- 如果找不到，PVC则会无限期处于Pending状态，直到等到系统管理员创建了一个符合其要求的PV
PV一旦绑定到某个PVC上，就会被这个PVC独占，不能再与其他PVC进行绑定了
资源使用：用户可在pod中像volume一样使用pvc

Pod使用Volume的定义，将PVC挂载到容器内的某个路径进行使用。
资源释放：用户删除pvc来释放pv

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

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

配置存储

ConfigMap

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

　创建configmap.yaml，内容如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap
  namespace: dev
data:
  info: |
    username:admin
    password:123456

# 创建configmap
[root@k8s-master01 ~]# kubectl create -f configmap.yaml
configmap/configmap created

# 查看configmap详情
[root@k8s-master01 ~]# kubectl describe cm configmap -n dev
Name:         configmap
Namespace:    dev
Labels:       <none>
Annotations:  <none>

Data
====
info:
----
username:admin
password:123456

Events:  <none>
接下来创建一个pod-configmap.yaml，将上面创建的configmap挂载进去

apiVersion: v1
kind: Pod
metadata:
  name: pod-configmap
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    volumeMounts: # 将configmap挂载到目录
    - name: config
      mountPath: /configmap/config
  volumes: # 引用configmap
  - name: config
    configMap:
      name: configmap
# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-configmap.yaml
pod/pod-configmap created

# 查看pod
[root@k8s-master01 ~]# kubectl get pod pod-configmap -n dev
NAME            READY   STATUS    RESTARTS   AGE
pod-configmap   1/1     Running   0          6s

#进入容器
[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的内容, 容器中的值也会动态更新

View Code

Secret

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

首先使用base64对数据进行编码
[root@k8s-master01 ~]# echo -n 'admin' | base64 #准备username
YWRtaW4=
[root@k8s-master01 ~]# echo -n '123456' | base64 #准备password
MTIzNDU2
接下来编写secret.yaml，并创建Secret
apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: dev
type: Opaque
data:
  username: YWRtaW4=
  password: MTIzNDU2
# 创建secret
[root@k8s-master01 ~]# kubectl create -f secret.yaml
secret/secret created

# 查看secret详情
[root@k8s-master01 ~]# kubectl describe secret secret -n dev
Name:         secret
Namespace:    dev
Labels:       <none>
Annotations:  <none>
Type:  Opaque
Data
====
password:  6 bytes
username:  5 bytes
创建pod-secret.yaml，将上面创建的secret挂载进去：
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    volumeMounts: # 将secret挂载到目录
    - name: config
      mountPath: /secret/config
  volumes:
  - name: config
    secret:
      secretName: secret
# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-secret.yaml
pod/pod-secret created

# 查看pod
[root@k8s-master01 ~]# kubectl get pod pod-secret -n dev
NAME            READY   STATUS    RESTARTS   AGE
pod-secret      1/1     Running   0          2m28s

# 进入容器，查看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
至此，已经实现了利用secret实现了信息的编码。

View Code

首先使用base64对数据进行编码

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

接下来编写secret.yaml，并创建Secret

apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: dev
type: Opaque
data:
  username: YWRtaW4=
  password: MTIzNDU2

# 创建secret
[root@k8s-master01 ~]# kubectl create -f secret.yaml
secret/secret created

# 查看secret详情
[root@k8s-master01 ~]# kubectl describe secret secret -n dev
Name:         secret
Namespace:    dev
Labels:       <none>
Annotations:  <none>
Type:  Opaque
Data
====
password:  6 bytes
username:  5 bytes

创建pod-secret.yaml，将上面创建的secret挂载进去：

apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    volumeMounts: # 将secret挂载到目录
    - name: config
      mountPath: /secret/config
  volumes:
  - name: config
    secret:
      secretName: secret

# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-secret.yaml
pod/pod-secret created

# 查看pod
[root@k8s-master01 ~]# kubectl get pod pod-secret -n dev
NAME            READY   STATUS    RESTARTS   AGE
pod-secret      1/1     Running   0          2m28s

# 进入容器，查看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

至此，已经实现了利用secret实现了信息的编码。