Code Guide

外观

K8S使用总结(二)

约 28905 字大约 96 分钟

2025-09-04

1. Kubernetes介绍

1.1 kubernetes组件

一个kubernetes集群主要是由控制节点(master)、**工作节点(node)**构成，每个节点上都会安装不同的组件。

master：集群的控制平面，负责集群的决策 ( 管理 )

  • ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制
  • Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上
  • ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等
  • Etcd ：负责存储集群中各种资源对象的信息

node：集群的数据平面，负责为容器提供运行环境 ( 干活 )

  • Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器
  • KubeProxy : 负责提供集群内部的服务发现和负载均衡
  • Docker : 负责节点上容器的各种操作

1.2 kubernetes概念

Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器

Controller：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等

Service：pod对外服务的统一入口，下面可以维护者同一类的多个pod

Label：标签，用于对pod进行分类，同一类pod会拥有相同的标签

NameSpace：命名空间，用来隔离pod的运行环境

2. 部署

见 Linux环境部署.md

3. 资源管理

3.1 资源管理介绍

在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。

kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务，所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。

kubernetes的最小管理单元是pod而不是容器，所以只能将容器放在Pod中，而kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。

Pod可以提供服务之后，就要考虑如何访问Pod中服务，kubernetes提供了Service资源实现这个功能。

当然，如果Pod中程序的数据需要持久化，kubernetes还提供了各种存储系统。

学习kubernetes的核心，就是学习如何对集群上的Pod、Pod控制器、Service、存储等各种资源进行操作

3.2 YAML语言介绍

基本变量

对象

# 对象
# 形式一(推荐):
heima:
  age: 15
  address: Beijing
# 形式二(了解):
heima: {age: 15,address: Beijing}

数组

# 数组
# 形式一(推荐):
address:
  - 顺义
  - 昌平  
# 形式二(了解):
address: [顺义,昌平]

3.3 资源管理方式

命令式对象管理：直接使用命令去操作kubernetes资源 kubectl run nginx-pod --image=nginx:1.17.1 --port=80

  • 命令式对象配置：通过命令配置和配置文件去操作kubernetes资源kubectl create/patch -f nginx-pod.yaml
  • 声明式对象配置：通过apply命令和配置文件去操作kubernetes资源kubectl apply -f nginx-pod.yaml
类型操作对象适用环境优点缺点
命令式对象管理对象测试简单只能操作活动对象，无法审计、跟踪
命令式对象配置文件开发可以审计、跟踪项目大时，配置文件多，操作麻烦
声明式对象配置目录开发支持目录操作意外情况下难以调试

3.3.1 命令式对象管理

kubectl命令

kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。kubectl命令的语法如下：

kubectl [command] [type] [name] [flags]

comand：指定要对资源执行的操作，例如create、get、delete

type：指定资源类型，比如deployment、pod、service

name：指定资源的名称，名称大小写敏感

flags：指定额外的可选参数

# 查看所有pod
kubectl get pod --kubecongig config -n namespace
# 查看某个pod
kubectl get pod pod_name --kubecongig config -n namespace
# 查看某个pod,以yaml格式展示结果
kubectl get pod pod_name -o yaml --kubecongig config -n namespace

资源类型

kubernetes中所有的内容都抽象为资源，可以通过下面的命令进行查看:

kubectl api-resources

经常使用的资源有下面这些：

资源分类资源名称缩写资源作用
集群级别资源nodesno集群组成部分
namespacesns隔离Pod
pod资源podspo装载容器
pod资源控制器replicationcontrollersrc控制pod资源
replicasetsrs控制pod资源
deploymentsdeploy控制pod资源
daemonsetsds控制pod资源
jobs控制pod资源
cronjobscj控制pod资源
horizontalpodautoscalershpa控制pod资源
statefulsetssts控制pod资源
服务发现资源servicessvc统一pod对外接口
ingressing统一pod对外接口
存储资源volumeattachments存储
persistentvolumespv存储
配置资源configmapscm配置
secrets配置

操作

kubernetes允许对资源进行多种操作，可以通过--help查看详细的操作命令

kubectl --help

经常使用的操作有下面这些：

命令分类命令翻译命令作用
基本命令create创建创建一个资源
edit编辑编辑一个资源
get获取获取一个资源
patch更新更新一个资源
delete删除删除一个资源
explain解释展示资源文档
运行和调试run运行在集群中运行一个指定的镜像
expose暴露暴露资源为Service
describe描述显示资源内部信息
logs日志输出容器在 pod 中的日志输出容器在 pod 中的日志
attach缠绕进入运行中的容器进入运行中的容器
exec执行容器中的一个命令执行容器中的一个命令
cp复制在Pod内外复制文件
rollout首次展示管理资源的发布
scale规模扩(缩)容Pod的数量
autoscale自动调整自动调整Pod的数量
高级命令applyrc通过文件对资源进行配置
label标签更新资源上的标签
其他命令cluster-info集群信息显示集群信息
version版本显示当前Server和Client的版本

3.3.3 声明式对象配置

如果资源不存在，就创建，相当于 kubectl create

如果资源已存在，就更新，相当于 kubectl patch

扩展：kubectl可以在node节点上运行吗 ?

kubectl的运行是需要进行配置的，它的配置文件是$HOME/.kube，如果想要在node节点运行此命令，需要将master上的.kube文件复制到node节点上，即在master节点上执行下面操作：

# 主节点执行
scp  -r  ~/.kube   k8s.node2:~/

4. 实战入门

4.1 Namespace

Namespace是kubernetes系统中的一种非常重要资源，它的主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离。

# 默认创建的namespace
NAME              STATUS   AGE
default           Active   45h     #  所有未指定Namespace的对象都会被分配在default命名空间
kube-node-lease   Active   45h     #  集群节点之间的心跳维护，v1.13开始引入
kube-public       Active   45h     #  此命名空间下的资源可以被所有人访问（包括未认证用户）
kube-system       Active   45h     #  所有由Kubernetes系统创建的资源都处于这个命名空间

查看

YAML语法

# ns-dev.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: dev

4.2 Pod

Pod是kubernetes集群进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中。

Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。

Pod相关命令

kubernetes没有提供单独运行Pod的命令，都是通过Pod控制器来实现的

YAML配置

4.3 Label

一些常用的Label 示例如下：

  • 版本标签："version":"release", "version":"stable"......
  • 环境标签："environment":"dev"，"environment":"test"，"environment":"pro"
  • 架构标签："tier":"frontend"，"tier":"backend"

当前有两种Label Selector：

  • 基于等式的Label Selector name = slave 选择所有包含Label中key="name"且value="slave"的对象env != production选择所有包括Label中的key="env"且value不等于"production"的对象
  • 基于集合的Label Selectorname in (master, slave) 选择所有包含Label中的key="name"且value="master"或"slave"的对象name not in (frontend) 选择所有包含Label中的key="name"且value不等于"frontend"的对象

标签的选择条件可以使用多个，此时将多个Label Selector进行组合，使用逗号","进行分隔即可。例如：

name=slave,env!=production

name not in (frontend),env!=production

Label相关命令

YAML配置

4.4 Deployment

在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。

Pod控制器其中的一种是 Deployment 命令操作

配置操作

4.5 Service

Service可以看作是一组同类Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。

操作一：创建集群内部可访问的Service

# 暴露Service
kubectl expose deploy nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n dev
# 查看service
kubectl get svc  -n dev -o wide
# 这里产生了一个CLUSTER-IP，这就是service的IP，在Service的生命周期中，这个地址是不会变动的
# 可以通过这个IP访问当前service对应的POD
curl 10.109.179.231:80

操作二：创建集群外部也可访问的Service

配置方式

创建一个svc-nginx.yaml，内容如下：

5. Pod详解

5.1 Pod介绍

5.1.1 Pod结构

每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：

  • 用户程序所在的容器，数量可多可少
  • Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：
    • 可以以它为依据，评估整个Pod的健康状态
    • 可以在根容器上设置Ip地址，其它容器都此Ip（Pod IP），以实现Pod内部的网路通信

5.1.2 Pod定义

在kubernetes中基本所有资源的一级属性都是一样的，主要包含5部分：

  • apiVersion 版本，由kubernetes内部定义，版本号可以用 kubectl api-versions 查询到
  • kind 类型，由kubernetes内部定义，版本号可以用 kubectl api-resources 查询到
  • metadata 元数据，主要是资源标识和说明，常用的有name、namespace、labels等
  • status 状态信息，里面的内容不需要定义，由kubernetes自动生成
  • spec 描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述

在上面的属性中，spec是接下来研究的重点，常见子属性：

  • containers <[]Object> 容器列表，用于定义容器的详细信息
  • nodeName 根据nodeName的值将pod调度到指定的Node节点上
  • nodeSelector <map[]> 根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node 上
  • hostNetwork 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
  • volumes <[]Object> 存储卷，用于定义Pod上面挂在的存储信息
  • restartPolicy 重启策略，表示Pod在遇到故障的时候的处理策略

5.2 Pod配置

主要来研究pod.spec.containers属性

5.2.1 基本配置

# 创建Pod
kubectl apply -f pod-base.yaml
kubectl get pod -n dev
# 可以通过describe查看内部的详情
# 此时已经运行起来了一个基本的Pod，虽然它暂时有问题
kubectl describe pod pod-base -n dev

5.2.2 镜像拉取

imagePullPolicy，用于设置镜像拉取策略，kubernetes支持配置三种拉取策略：

  • Always：只使用远程

  • IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像【默认】

  • Never：只使用本地

# 创建Pod
kubectl create -f pod-imagepullpolicy.yaml
# 查看Pod详情
# 此时明显可以看到nginx镜像有一步Pulling image "nginx:1.17.1"的过程
kubectl describe pod pod-imagepullpolicy -n dev

5.2.3 启动命令

在前面的案例中：busybox并不是一个程序，而是类似于一个工具类的集合，kubernetes集群启动管理后，它会自动关闭。解决方法就是让其一直在运行，这就用到了command配置。command，用于在pod中的容器初始化完毕之后运行一个命令。

每隔3秒向文件中写入当前时间

"/bin/sh","-c", 使用sh执行命令

touch /tmp/hello.txt; 创建一个/tmp/hello.txt 文件

while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;

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

5.2.4 环境变量

env，环境变量，用于在pod中的容器设置环境变量。

# 创建Pod
kubectl create -f pod-env.yaml
# 进入容器，输出环境变量
kubectl exec pod-env -n dev -c busybox -it /bin/sh
/ # echo $username
admin
/ # echo $password
123456

这种方式不是很推荐，推荐将这些配置单独存储在配置文件中

5.2.5 端口设置

# 创建Pod
kubectl create -f pod-ports.yaml
# 查看pod
kubectl get pod pod-ports -n dev -o yaml

5.2.6 资源配额

  • limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启

  • requests ：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动

5.3 Pod生命周期

我们一般将pod对象从创建至终的这段时间范围称为pod的生命周期，它主要包含下面的过程：

  • pod创建过程

  • 运行初始化容器（init container）过程

  • 运行主容器（main container）

    • 容器启动后钩子（post start）、容器终止前钩子（pre stop）
    • 容器的存活性探测（liveness probe）、就绪性探测（readiness probe）

  • pod终止过程

在整个生命周期中，Pod会出现5种状态（相位），分别如下：

  • 挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中

  • 运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成

  • 成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启

  • 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态

  • 未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致

5.3.1 创建和终止

pod的创建过程

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

pod的终止过程

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

5.3.2 初始化容器

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

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

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

  • 提供主容器镜像中不具备的工具程序或自定义代码

  • 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足

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

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

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

5.3.3 钩子函数

  • 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
……
# 创建pod
kubectl create -f pod-hook-exec.yaml
# 查看pod
kubectl get pods  pod-hook-exec -n dev -o wide
# 访问pod
curl 10.244.2.48

5.3.4 容器探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例" 摘除 "，不承担业务流量。kubernetes提供了两种探针来实现容器探测，分别是：

  • liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器

  • readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量

livenessProbe 决定是否重启容器，readinessProbe 决定是否将请求转发给容器。

上面两种探针目前均支持三种探测方式：

  • Exec命令：在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常
……
  livenessProbe:
    exec:
      command:
      - cat
      - /tmp/healthy
……

TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常

……      
  livenessProbe:
    tcpSocket:
      port: 8080
……

HTTPGet：调用容器内Web应用的URL，如果返回的状态码在200和399之间，则认为程序正常，否则不正常

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

*方式一：Exec

# 创建Pod
kubectl create -f pod-liveness-exec.yaml
# 查看Pod详情
kubectl describe pods pod-liveness-exec -n dev
# 观察上面的信息就会发现nginx容器启动之后就进行了健康检查
# 检查失败之后，容器被kill掉，然后尝试进行重启（这是重启策略的作用，后面讲解）
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
kubectl get pods pod-liveness-exec -n dev
# 当然接下来，可以修改成一个存在的文件，比如/tmp/hello.txt，再试，结果就正常了......

方式二：TCPSocket

# 创建Pod
kubectl create -f pod-liveness-tcpsocket.yaml
# 查看Pod详情
kubectl describe pods pod-liveness-tcpsocket -n dev
# 观察上面的信息，发现尝试访问8080端口,但是失败了
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
kubectl get pods pod-liveness-tcpsocket  -n dev
# 当然接下来，可以修改成一个可以访问的端口，比如80，再试，结果就正常了......

方式三：HTTPGet

# 创建Pod
kubectl create -f pod-liveness-httpget.yaml
# 查看Pod详情
kubectl describe pod pod-liveness-httpget -n dev
# 观察上面信息，尝试访问路径，但是未找到,出现404错误
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
kubectl get pod pod-liveness-httpget -n dev
# 当然接下来，可以修改成一个可以访问的路径path，比如/，再试，结果就正常了......

5.3.5 重启策略

  • Always ：容器失效时，自动重启该容器，这也是默认值。

  • OnFailure ： 容器终止运行且退出码不为0时重启

  • Never ： 不论状态为何，都不重启该容器

重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。

# 创建Pod
kubectl create -f pod-restartpolicy.yaml
# 查看Pod详情，发现nginx容器失败
kubectl  describe pods pod-restartpolicy  -n dev
# 多等一会，再观察pod的重启次数，发现一直是0，并未重启   
kubectl  get pods pod-restartpolicy -n dev

5.4 Pod调度

在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足的需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做呢？这就要求了解kubernetes对Pod的调度规则，kubernetes提供了四大类调度方式：

  • 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出

  • 定向调度：NodeName、NodeSelector

  • 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity

  • 污点（容忍）调度：Taints、Toleration

5.4.1 定向调度【强制策略】

NodeName

这种方式，其实是直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。

NodeSelector

NodeSelector用于将pod调度到添加了指定标签的node节点上。

kubectl label nodes node1 nodeenv=pro
ubectl label nodes node2 nodeenv=test

5.4.2 亲和性调度

上一节，介绍了两种定向调度的方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用Node列表也不行，这就限制了它的使用场景。

基于上面的问题，kubernetes还提供了一种亲和性调度（Affinity）。它在NodeSelector的基础之上的进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活。

Affinity主要分为三类：

  • nodeAffinity(node亲和性）: 以node为目标，解决pod可以调度到哪些node的问题

  • podAffinity(pod亲和性) : 以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题

  • podAntiAffinity(pod反亲和性) : 以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题

关于亲和性(反亲和性)使用场景的说明：

亲和性：如果两个应用频繁交互，那就有必要利用亲和性让两个应用的尽可能的靠近，这样可以减少因网络通信而带来的性能损耗。

反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性。

NodeAffinity

NodeAffinity规则设置的注意事项：

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

PodAffinity

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

PodAntiAffinity

PodAntiAffinity主要实现以运行的Pod为参照，新创建的Pod跟参照pod不在一个区域中的功能。与上面的PodAffinity是一种相反策略

5.4.3 污点和容忍

污点（Taints）

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

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

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

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

污点API

# 设置污点
kubectl taint nodes k8s.node1 key=value:policy
# 去除污点
kubectl taint nodes k8s.node2 key:policy-
# 去除所有污点
kubectl taint nodes k8s.node2 key-
# 查看污点
kubectl describe node k8s.node1 | grep Taints
注意：使用kubeadm搭建的集群，默认就会给master节点添加一个污点标记,所以pod就不会调度到master节点上.

容忍（Toleration）

污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝

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

6. Pod控制器详解

6.1 Pod控制器介绍

Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类：

  • 自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建

  • 控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建

什么是Pod控制器

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。

在kubernetes中，有很多类型的pod控制器，每种都有自己的适合的场景，常见的有下面这些：

  • ReplicationController：比较原始的pod控制器，已经被废弃，由ReplicaSet替代
  • ReplicaSet：保证副本数量一直维持在期望值，并支持pod数量扩缩容，镜像版本升级
  • Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本
  • Horizontal Pod Autoscaler：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷
  • DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务
  • Job：它创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务
  • Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行
  • StatefulSet：管理有状态应用

6.2 ReplicaSet(RS)

ReplicaSet的主要作用是保证一定数量的pod正常运行，它会持续监听这些Pod的运行状态，一旦Pod发生故障，就会重启或重建。同时它还支持对pod数量的扩缩容和镜像版本的升降级。

ReplicaSet的资源清单文件：

在这里面，需要新了解的配置项就是spec下面几个选项：

  • replicas：指定副本数量，其实就是当前rs创建出来的pod的数量，默认为1
  • selector：选择器，它的作用是建立pod控制器和pod之间的关联关系，采用的Label Selector机制在pod模板上定义label，在控制器上定义选择器，就可以表明当前控制器能管理哪些pod了
  • template：模板，就是当前控制器创建pod所使用的模板板，里面其实就是前一章学过的pod的定义

ReplicaSet Demo

扩缩容

镜像升级

# 编辑rs的容器镜像 - image: nginx:1.17.2
kubectl edit rs pc-replicaset -n dev
# 再次查看，发现镜像版本已经变更了
kubectl get rs -n dev -o wide
# 同样的道理，也可以使用命令完成这个工作
# kubectl set image rs rs名称 容器=镜像版本 -n namespace
kubectl set image rs pc-replicaset nginx=nginx:1.17.1  -n dev
# 再次查看，发现镜像版本已经变更了
kubectl get rs -n dev -o wide

删除ReplicaSet

# 使用kubectl delete命令会删除此RS以及它管理的Pod
# 在kubernetes删除RS前，会将RS的replicasclear调整为0，等待所有的Pod被删除后，在执行RS对象的删除
kubectl delete rs pc-replicaset -n dev
kubectl get pod -n dev -o wide
# 如果希望仅仅删除RS对象（保留Pod），可以使用kubectl delete命令时添加--cascade=false选项（不推荐）。
kubectl delete rs pc-replicaset -n dev --cascade=false
kubectl get pods -n dev
# 也可以使用yaml直接删除(推荐)
kubectl delete -f pc-replicaset.yaml

6.3 Deployment(Deploy)

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

Deployment主要功能有下面几个：

  • 支持ReplicaSet的所有功能

  • 支持发布的停止、继续

  • 支持滚动升级和回滚版本

Deployment的资源清单文件：

Deployment Demo

扩缩容

镜像更新

deployment支持两种更新策略:重建更新和滚动更新,可以通过strategy指定策略类型,支持两个属性:

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

重建更新

  1. 编辑pc-deployment.yaml,在spec节点下添加更新策略
spec:
  strategy: # 策略
    type: Recreate # 重建更新
  1. 创建deploy进行验证

滚动更新

  1. 编辑pc-deployment.yaml,在spec节点下添加更新策略
  1. 创建deploy进行验证

滚动更新的过程：

镜像更新中rs的变化

# 查看rs,发现原来的rs的依旧存在，只是pod数量变为了0，而后又新产生了一个rs，pod数量为4
# 其实这就是deployment能够进行版本回退的奥妙所在，后面会详细解释
[root@k8s-master01 ~]# kubectl get rs -n dev
NAME                       DESIRED   CURRENT   READY   AGE
pc-deployment-6696798b78   0         0         0       7m37s
pc-deployment-6696798b11   0         0         0       5m37s
pc-deployment-c848d76789   4         4         4       72s

版本回退

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

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

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

金丝雀发布

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

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

删除Deployment

# 删除deployment，其下的rs和pod也将被删除
kubectl delete -f pc-deployment.yaml

6.4 Horizontal Pod Autoscaler(HPA)

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

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

接下来，我们来做一个实验

1 安装metrics-server

metrics-server可以用来收集集群中的资源使用情况

2 准备deployment和servie

创建pc-hpa-pod.yaml文件，内容如下：

# 创建service
[root@k8s-master01 1.8+]# kubectl expose deployment nginx --type=NodePort --port=80 -n dev

3 部署HPA

创建pc-hpa.yaml文件，内容如下：

# 创建hpa
[root@k8s-master01 1.8+]# kubectl create -f pc-hpa.yaml
horizontalpodautoscaler.autoscaling/pc-hpa created

# 查看hpa
[root@k8s-master01 1.8+]# kubectl get hpa -n dev
NAME     REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
pc-hpa   Deployment/nginx   0%/3%     1         10        1          62s

4 测试

使用压测工具对service地址192.168.5.4:31830进行压测，然后通过控制台查看hpa和pod的变化

hpa变化

deployment变化

pod变化

6.5 DaemonSet(DS)

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

DaemonSet控制器的特点：

  • 每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上

  • 当节点从集群中移除时，Pod 也就被垃圾回收了

下面先来看下DaemonSet的资源清单文件

创建pc-daemonset.yaml，内容如下：

6.6 Job

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

  • 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量

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

Job的资源清单文件：

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

创建pc-job.yaml，内容如下：

6.7 CronJob(CJ)

CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。也就是说，CronJob可以在特定的时间点(反复的)去运行job任务。

CronJob的资源清单文件：

Cron表达式的详细用法 - 简书 (jianshu.com)

7. Service详解

7.1 Service介绍

在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信息转换成对应的访问规则。

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算法。

7.2 Service类型

Service的资源清单文件：

  • ClusterIP：默认值，它是Kubernetes系统自动分配的虚拟IP，只能在集群内部访问

  • NodePort：将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务

  • LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持

  • ExternalName： 把集群外部的服务引入集群内部，直接使用

7.3 Service使用

7.3.1 实验环境准备

在使用service之前，首先利用Deployment创建出3个pod，注意要为pod设置app=nginx-pod的标签

7.3.2 ClusterIP类型的Service

Endpoint

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

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

负载分发策略

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

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

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

7.3.3 HeadLiness类型的Service

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

7.3.4 NodePort类型的Service

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

7.3.5 LoadBalancer类型的Service

LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部环境支持的，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。

7.3.6 ExternalName类型的Service

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

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

7.4 Ingress介绍

在前面课程中已经提到，Service对集群之外暴露服务的主要方式有两种：NotePort和LoadBalancer，但是这两种方式，都有一定的缺点：

  • NodePort方式的缺点是会占用很多集群机器的端口，那么当集群服务变多的时候，这个缺点就愈发明显

  • LB方式的缺点是每个service需要一个LB，浪费、麻烦，并且需要kubernetes之外设备的支持

基于这种现状，kubernetes提供了Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。工作机制大致如下图表示：

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

  • ingress：kubernetes中的一个对象，作用是定义请求如何转发到service的规则

  • ingress controller：具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，比如Nginx, Contour, Haproxy等等

Ingress（以Nginx为例）的工作原理如下：

  1. 用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service

  2. Ingress控制器动态感知Ingress服务规则的变化，然后生成一段对应的Nginx反向代理配置

  3. Ingress控制器会将生成的Nginx配置写入到一个运行着的Nginx服务中，并动态更新

  4. 到此为止，其实真正在工作的就是一个Nginx了，内部配置了用户定义的请求转发规则

7.5 Ingress使用

7.5.1 环境准备

搭建ingress环境

kubectl apply -f ingress-control.yaml
kubectl get pod -n ingress-nginx
# 查看service
kubectl get svc -n ingress-nginx

准备service和pod

为了后面的实验比较方便，创建如下图所示的模型

7.5.2 Http代理

# 创建
kubectl apply -f pc-ingress-http.yaml
# 查看
sudo kubectl get ing ingress-http -n dev
# 查看详情
sudo kubectl describe ing ingress-http  -n dev
# 注意看上面的Address栏

7.5.3 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=itheima.com"

# 创建密钥
kubectl create secret tls tls-secret --key tls.key --cert tls.crt
# 创建
kubectl create -f ingress-https.yaml
# 查看
kubectl get ing ingress-https -n dev
# 查看详情
kubectl describe ing ingress-https -n dev

8. 数据存储

为了持久化保存容器的数据，kubernetes引入了Volume的概念。

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

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

  • 简单存储：EmptyDir、HostPath、NFS

  • 高级存储：PV、PVC

  • 配置存储：ConfigMap、Secret

8.1 基本存储

8.1.1 EmptyDir

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

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

  • 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留

  • 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）

接下来，通过一个容器之间文件共享的案例来使用一下EmptyDir。

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

# 创建Pod
kubectl create -f volume-emptydir.yaml
# 查看pod
kubectl get pods volume-emptydir -n dev -o wide
# 通过podIp访问nginx
curl 10.42.2.9
# 通过kubectl logs命令查看指定容器的标准输出
kubectl logs -f volume-emptydir -n dev -c busybox

8.1.2 HostPath

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

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

8.1.3 NFS

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

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

nfs安装见 Linux环境配置
# 查看主节点挂载目录
showmount -e
# 创建pod
kubectl create -f volume-nfs.yaml
# 查看pod
kubectl get pods volume-nfs -n dev
# 查看nfs服务器上的共享目录，发现已经有文件了
ls /root/data/

8.2 高级存储

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

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

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

  • 存储：存储工程师维护

  • PV： kubernetes管理员维护

  • PVC：kubernetes用户维护

8.2.1 PV

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

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个暴露的路径。

  1. 准备NFS环境
  1. 创建
# 创建 pv
sudo kubectl apply -f pv-test001.yaml
# 查看pv
kubectl get pv -o wide

8.2.2 PVC

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

PVC 的关键配置参数说明：

  • 访问模式（accessModes）

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

  • 选择条件（selector） 通过Label Selector的设置，可使PVC对于系统中己存在的PV进行筛选

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

  • 资源请求（Resources ） 描述对存储资源的请求

实验

# 创建pvc
sudo kubectl apply -f pvc-test001.yaml
# 查看pvc
sudo kubectl get pvc  -n dev -o wide
# 查看pv
sudo kubectl get pv -o wide

8.2.3 生命周期

8.3 配置存储

8.3.1 ConfigMap

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

# 创建configmap
sudo kubectl create -f pc-configmap.yaml
# 查看configmap详情
sudo kubectl describe cm configmap -n dev

8.3.2 Secret

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

  1. 首先使用base64对数据进行编码
echo -n 'admin' | base64 #准备username
# YWRtaW4=
echo -n '123456' | base64 #准备password
# MTIzNDU2
  1. 接下来编写secret.yaml，并创建Secret
apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: dev
type: Opaque
data:
  username: YWRtaW4=
  password: MTIzNDU2
# 创建secret
kubectl create -f secret.yaml
# 查看secret详情
kubectl describe secret secret -n dev
  1. 创建pod-secret.yaml，将上面创建的secret挂载进去：

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

9. 安全认证

9.1 访问控制概述

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

客户端

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

  • User Account：一般是独立于kubernetes之外的其他服务管理的用户账号。

  • Service Account：kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识。

认证、授权与准入控制

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

  • Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证

  • Authorization（授权）： 判断用户是否有权限对访问的资源执行特定的动作

  • Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。

9.2 认证管理

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机构下发根证书、服务端证书及私钥给申请者

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

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

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

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

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

9.3 授权管理

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

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

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

  • AlwaysDeny：表示拒绝所有请求，一般用于测试

  • AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（Kubernetes默认的策略）

  • ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制

  • Webhook：通过调用外部REST服务对用户进行授权

  • Node：是一种专用模式，用于对kubelet发出的请求进行访问控制

  • RBAC：基于角色的访问控制（kubeadm安装方式下的默认选项）

RBAC(Role-Based Access Control) 基于角色的访问控制，主要是在描述一件事情：给哪些对象授予了哪些权限

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

  • 对象：User、Groups、ServiceAccount

  • 角色：代表着一组定义在资源上的可操作动作(权限)的集合

  • 绑定：将定义好的角色跟用户绑定在一起

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

  • Role、ClusterRole：角色，用于指定一组权限

  • RoleBinding、ClusterRoleBinding：角色绑定，用于将角色（权限）赋予给对象

Role、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引用ClusterRole进行授权

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

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

实战：创建一个只能管理dev空间下Pods资源的账号

  1. 创建账号

2） 创建Role和RoleBinding，为devman用户授权

[root@k8s-master01 pki]# kubectl create -f dev-role.yaml
role.rbac.authorization.k8s.io/dev-role created
rolebinding.rbac.authorization.k8s.io/authorization-role-binding created
  1. 切换账户，再次验证

9.4 准入控制

通过了前面的认证和授权之后，还需要经过准入控制处理通过之后，apiserver才会处理这个请求。

准入控制是一个可配置的控制器列表，可以通过在Api-Server上通过命令行设置选择执行哪些准入控制器：

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,
                      DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

只有当所有的准入控制器都检查通过之后，apiserver才执行该请求，否则返回拒绝。

当前可配置的Admission Control准入控制如下：

  • AlwaysAdmit：允许所有请求

  • AlwaysDeny：禁止所有请求，一般用于测试

  • AlwaysPullImages：在启动容器之前总去下载镜像

  • DenyExecOnPrivileged：它会拦截所有想在Privileged Container上执行命令的请求

  • ImagePolicyWebhook：这个插件将允许后端的一个Webhook程序来完成admission controller的功能。

  • Service Account：实现ServiceAccount实现了自动

  • SecurityContextDeny：这个插件将使用SecurityContext的Pod中的定义全部失效

  • ResourceQuota：用于资源配额管理目的，观察所有请求，确保在namespace上的配额不会超标

  • LimitRanger：用于资源限制管理，作用于namespace上，确保对Pod进行资源限制

  • InitialResources：为未设置资源请求与限制的Pod，根据其镜像的历史资源的使用情况进行设置

  • NamespaceLifecycle：如果尝试在一个不存在的namespace中创建资源对象，则该创建请求将被拒绝。当删除一个namespace时，系统将会删除该namespace中所有对象。

  • DefaultStorageClass：为了实现共享存储的动态供应，为未指定StorageClass或PV的PVC尝试匹配默认的StorageClass，尽可能减少用户在申请PVC时所需了解的后端存储细节

  • DefaultTolerationSeconds：这个插件为那些没有设置forgiveness tolerations并具有notready:NoExecute和unreachable:NoExecute两种taints的Pod设置默认的“容忍”时间，为5min

  • PodSecurityPolicy：这个插件用于在创建或修改Pod时决定是否根据Pod的security context和可用的PodSecurityPolicy对Pod的安全策略进行控制

10.DashBoard

之前在kubernetes中完成的所有操作都是通过命令行工具kubectl完成的。其实，为了提供更丰富的用户体验，kubernetes还开发了一个基于web的用户界面（Dashboard）。用户可以使用Dashboard部署容器化的应用，还可以监控应用的状态，执行故障排查以及管理kubernetes中各种资源。

10.1 部署Dashboard

  1. 下载yaml，并运行Dashboard

2）创建访问账户，获取token

3）通过浏览器访问Dashboard的UI

在登录页面上输入上面的token

出现下面的页面代表成功

10.2 使用DashBoard

本章节以Deployment为例演示DashBoard的使用

查看

选择指定的命名空间dev，然后点击Deployments，查看dev空间下的所有deployment

扩缩容

在Deployment上点击规模，然后指定目标副本数量，点击确定

编辑

在Deployment上点击编辑，然后修改yaml文件，点击确定

查看Pod

点击Pods, 查看pods列表

操作Pod

选中某个Pod，可以对其执行日志（logs）、进入执行（exec）、编辑、删除操作

Dashboard提供了kubectl的绝大部分功能，这里不再一一演示

贡献者

codingLab

版权归属：codingLab

许可证：bugcode

Code Guide © 2020-2025

项导文档说明

2025-08-17
- 已迁移至 docs.code-guide