Kubernetes 集群管理与核心组件详解

由一个容器或多个容器组成（最少一个容器），是 K8s 中最小的管理元素。同一个 Pod 共享 IP 及权限、主机名称、共享存储设备、命名空间。每个 Pod 都会存在一个 Pause 根容器，这是每一个 Pod 都会去运行的。它就像一个基石，为 Pod 中的其他容器提供基础运行环境。Pause 容器会加载所有必要的运行时、内核模块和设备驱动，以确保 Pod 中的所有容器都能在相同的网络和命名空间中运行。其他的资源对象都是用来支撑或者扩展 Pod 对象功能的。

2. Pod 相位状态

• Pending: Pod 创建过程中，但它尚未被调度完成
• Running: Pod 中所有容器都被创建成功
• Completed 或者 Successed: Pod 所有容器都已经成功终止，并不会被重启
• Failed: Pod 中的所有容器至少有一个容器退出是非 0 状态
• Unknown: 无法正常获取 Pod 对象的状态信息

3. 管理命令

3.1 获取命名空间下容器 (pod) 列表

kubectl get pods -n your_namespace -o wide -w

• -n: 指定命名空间
• -o wide: 显示更加详细信息
• -o name: 只显示名字
• -o yaml/json: 以 yaml/json 语法格式显示资源对象
• -w: 持续监听

3.2 查看 pod 的详细信息

kubectl describe pod your_pod -n your_namespace

3.3 创建 && 运行

kubectl run [pod 名称] --image=[镜像]:[镜像版本] --port=[对外端口] --namespace [namespace]

3.4 删除 pod

kubectl delete pod [pod 名称] -n [命名空间名称]

删除会再次出现？ 因为 pod 是隶属于 Pod 控制器下，控制器会监控 pod 的健康值，出现问题会重启几次失败后删除重新创建，所以会出现删除后再出现的问题。

3.5 进入容器

kubectl exec your_pod -c 容器名称 -n your_namespace -it /bin/bash
kubectl exec myweb -- ls 50x.html index.html

若有很多容器：

# 获取 pod 列表
kubectl get pods -n your_namespace
# 获取 pod 详情
kubectl describe pod your_pod -n your_namespace
# 进入容器内部
kubectl exec your_pod -n your_namespace -it -c your_container /bin/bash

3.6 根据资源对象文件运行命令

kubectl create/apply/delete -f 资源文件名称.yaml

• create: 创建文件中定义的资源
• apply: 创建 (更新) 文件中定义的资源（主要用的就是这个）
• delete: 删除文件中定义的资源

3.7 排错三兄弟

• kubectl get: 查看资源对象的状态信息
• kubectl describe: 查询资源对象的属性信息，Events 下是事物日志，用来排错
• kubectl logs: 查看容器报错信息

4. 污点策略

4.1 概述

污点（Taint）是使节点与 Pod 产生排斥的一类规则。污点策略通过嵌合在键值对上的污点标签进行声明。污点的格式为：key=value:effect。key 和 value 是污点的标签，effect 描述污点的作用。

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

管理污点标签：

• 查看污点标签：kubectl describe nodes [节点名字]
• 设置污点标签：kubectl taint node [节点名字] key=value:污点标签
• 删除污点标签：kubectl taint node [节点名字] key=value:污点标签-

4.2 设置并查看污点标签

# node01 设置污点策略 PreferNoSchedule
kubectl taint node node01 k=v1:PreferNoSchedule
# 查看污点
kubectl describe node node01

4.3 删除污点标签

kubectl taint node node01 k-

四、资源对象文件

1. 资源对象文件相关帮助

1.1 Pod 的资源清单

apiVersion: v1 # 必选，版本号，例如 v1
kind: Pod # 必选，资源类型，例如 Pod
metadata: # 必选，元数据
  name: string # 必选，Pod 名称
  annotations: # 选做，描述信息
    nginx: nginx
  namespace: string # Pod 所属的命名空间，默认为"default"
  labels: # 自定义标签列表
    - name: string
spec: # 必选，Pod 中容器的详细定义
  containers: # 必选，Pod 中容器列表
    - name: string # 必选，容器名称
      image: string # 必选，容器的镜像名称
      imagePullPolicy: [ Always|Never|IfNotPresent ] # 获取镜像的策略
      command: [string] # 容器的启动命令列表
      args: [string] # 容器的启动命令参数列表
      workingDir: string # 容器的工作目录
      volumeMounts: # 挂载到容器内部的存储卷配置
        - name: string
          mountPath: string
          readOnly: boolean
      ports: # 需要暴露的端口库号列表
        - name: string
          containerPort: 80
          hostPort: int
          protocol: string
      env: # 容器运行前需设置的环境变量列表
        - name: string
          value: string
      resources: # 资源限制和请求的设置
        limits: # 资源限制的设置 (上限)
          cpu: string
          memory: string
        requests: # 资源请求的设置 (下限)
          cpu: string
          memory: string
      lifecycle: # 生命周期钩子
        postStart: {}
        preStop: {}
      livenessProbe: # 健康检查设置
        exec: { command: [string] }
        httpGet: { path: string, port: number }
        tcpSocket: { port: number }
        initialDelaySeconds: 0
        timeoutSeconds: 0
        periodSeconds: 0
        successThreshold: 0
        failureThreshold: 0
      securityContext: { privileged: false }
      restartPolicy: [Always | Never | OnFailure]
      nodeName: <string>
      nodeSelector: object
      imagePullSecrets: [{ name: string }]
      hostNetwork: false
      volumes: # 在该 pod 上定义共享存储卷列表
        - name: string
          emptyDir: {}
          hostPath: { path: string, type: DirectoryOrCreate }
          secret: { secretname: string }
          configMap: { name: string }

1.2 最基础 Pod 资源对象文件

---
kind: Pod
apiVersion: v1
metadata:
  name: myweb
spec:
  containers:
    - name: webserver
      image: myos:nginx
status: {}

1.3 自动生成模板命令

生成模板命令：--dry-run=client -o yaml

kubectl run myweb --image=myos:nginx --dry-run=client -o yaml

1.4 查询帮助信息

kubectl explain Pod.spec.restartPolicy

资源文件参数使用"."分割层级结构关系。

2. Pod

2.1 Pod 自定义命令

创建 Pod 时，启动时要执行的自定义命令，如果配置了自定义命令，那镜像中自带的默认命令将不再执行。

---
kind: Pod
apiVersion: v1
metadata:
  name: myweb
spec:
  containers:
    - name: webserver
      image: myos:nginx
      command: ["/bin/bash"]
      args: ["-c", "while sleep 5;do echo \"hello world\" done"]

2.2 restartPolicy 保护策略

指在系统发生故障或意外停机时，系统或应用程序如何处理和恢复的策略。

• Always: 不重启
• Never: 失败就重启
• OnFailure: Pod 会根据策略决定容器结束后是否重启

---
kind: Pod
apiVersion: v1
metadata:
  name: mycmd
spec:
  restartPolicy: Never
  containers:
    - name: linux
      image: myos:8.5
      command: ["sleep"]
      args: ["30"]

2.3 terminationGracePeriodSeconds 宽限期策略

是 K8s 中的 Pod 生命周期策略之一，当容器运行完自己的任务后，会等待一段时间，然后优雅地退出。为避免服务突然中断，造成事务不一致的问题。宽限期默认 30s，不等待为 0s。

---
kind: Pod
apiVersion: v1
metadata:
  name: mycmd
spec:
  terminationGracePeriodSeconds: 0
  restartPolicy: Never
  containers:
    - name: linux
      image: myos:8.5
      command: ["sleep"]
      args: ["30"]

2.4 activeDeadlineSeconds 策略

是 K8s 中的 Pod 生命周期策略之一，允许 Pod 运行的最大时长。如果一个 Pod 的内部程序在运行时出现循环死锁，那么就会永远不停地重复执行。为避免出现循环死锁，允许 Pod 运行的最大时长，等到时间后，强制关闭，并设置 Error 状态。

---
kind: Pod
apiVersion: v1
metadata:
  name: mycmd
spec:
  terminationGracePeriodSeconds: 0
  activeDeadlineSeconds: 60
  restartPolicy: Never
  containers:
    - name: linux
      image: myos:8.5
      command: ["sleep"]
      args: ["300"]

2.5 多容器 Pod

受影响的命令：log, exec, cp。需要以上命令后加 -c 容器名。

---
kind: Pod
apiVersion: v1
metadata:
  name: mynginx
spec:
  terminationGracePeriodSeconds: 0
  restartPolicy: Always
  containers:
    - name: nginx
      image: myos:nginx
    - name: php
      image: myos:php-fpm

注意：如果启动多容器，也根据提供的配置文件，没有明确指定每个容器的端口信息，那就需要在一个 Pod 中，每个容器需要使用不同的端口来避免冲突。

---
kind: Pod
apiVersion: v1
metadata:
  name: web2
spec:
  containers:
    - name: httpd
      image: myos:httpd
      ports:
        - containerPort: 80
    - name: nginx
      image: myos:nginx
      ports:
        - containerPort: 8080

3. Pod 容忍策略

容忍刚好和污点相反，某些时候我们需要在有污点的节点上运行 Pod，这种无视污点标签的调度方式成为容忍。精确匹配：下面 3 个条件必须写全；模糊匹配：不需要写全。

3.1 精确匹配策略

---
kind: Pod
apiVersion: v1
metadata:
  name: myphp
spec:
  tolerations:
    - operator: Equal
      key: k
      value: v1
      effect: NoSchedule
  containers:
    - name: php
      image: myos:php-fpm

3.2 模糊匹配策略

---
kind: Pod
apiVersion: v1
metadata:
  name: myphp
spec:
  tolerations:
    - operator: Exists
      key: k
      effect: NoSchedule
  containers:
    - name: php
      image: myos:php-fpm

4. 优先级与抢占

优先级就是为了保证重要的 Pod 被调度运行。通过配置优先级 PriorityClass 或创建 Pod 时为其设置对应的优先级来确认优先级。PriorityClass 是一个全局资源对象，它定义了从优先级类名称到优先级整数值的映射。优先级在 value 字段中指定，可以设置小于 10 亿的整数值，值越大，优先级越高，默认优先级 0。

PriorityClass 还有两个可选字段：globalDefault 用于设置默认优先级状态，description 用来配置描述性信息。

优先级策略：非抢占优先（调度阶段优先分配，一旦完成不可抢占）、抢占优先（强制调度，资源不足时会抢占低优先级 Pod）。

4.1 非抢占优先级

---
kind: PriorityClass
apiVersion: scheduling.k8s.io/v1
metadata:
  name: high-non
preemptionPolicy: Never
value: 1000
---
kind: PriorityClass
apiVersion: scheduling.k8s.io/v1
metadata:
  name: low-non
preemptionPolicy: Never
value: 500

kubectl apply -f mypriority.yaml
kubectl get priorityclasses.scheduling.k8s.io

创建 Pod：

---
kind: Pod
apiVersion: v1
metadata:
  name: php2
spec:
  nodeSelector:
    kubernetes.io/hostname: node01
  priorityClassName: low-non
  containers:
    - name: php
      image: myos:php-fpm

4.2 抢占优先级

---
kind: PriorityClass
apiVersion: scheduling.k8s.io/v1
metadata:
  name: high
preemptionPolicy: PreemptLowerPriority
value: 1000
---
kind: PriorityClass
apiVersion: scheduling.k8s.io/v1
metadata:
  name: low
preemptionPolicy: PreemptLowerPriority
value: 500

5. Pod 调度策略

将 Pod 分配到合适的计算节点上，并运行。kube-scheduler 是默认调度器，是集群的核心组件。

调度流程：过滤（筛选满足资源请求的节点）和打分（优选得分最高的节点）。绑定（通知 apiserver）。

5.1 定向调度

基于节点名称的调度。在 spec 下面，添加 nodeName 标签，让 Pod 运行在指定节点上面，若目标节点无法运行，它会一直等下去，现实 pending。

---
kind: Pod
apiVersion: v1
metadata:
  name: myhttp
spec:
  nodeName: node-0001
  containers:
    - name: apache
      image: myos:httpd

5.2 标签调度

Pod 标签调度是指通过在 Pod 上设置标签（Label），将 Pod 调度到具有匹配标签的节点上。

管理标签语法格式：

• 设置标签：kubectl label 资源类型 [资源名称] =
• 删除标签：kubectl label 资源类型 [资源名称] -
• 查看标签：kubectl label 资源类型 [资源名称] --show-labels
• 使用标签选择：kubectl get 资源类型 [资源名称] -l =

kubectl get pods --show-labels
kubectl get nodes -l kubernetes.io/hostname=master
kubectl label pod myhttp app=apache
kubectl label pod myhttp app-

使用系统标签调度：

---
kind: Pod
apiVersion: v1
metadata:
  name: myhttp
  labels:
    app: apache
spec:
  nodeSelector:
    kubernetes.io/hostname: node-0002
  containers:
    - name: apache
      image: myos:httpd

6. Pod 资源管理

是 K8s 中用于限制和约束集群中各个命名空间或项目使用资源的方式，避免资源争用和浪费。Pod 资源配额可以限制命名空间或项目中 Pod 使用的 CPU、内存、存储等资源的数量。设置 resources 字段，来实现资源管理。

CPU 资源类型：CPU 资源的约束和请求以毫核（m）为单位。在 K8s 中 1m 是最小的调度单元，CPU 的一个核心可以看作 1000m。

6.1 内存资源配额

---
kind: Pod
apiVersion: v1
metadata:
  name: minpod
spec:
  nodeSelector:
    kubernetes.io/hostname: node-0003
  terminationGracePeriodSeconds: 0
  containers:
    - name: linux
      image: myos:8.5
      command: ["awk","BEGIN{while(1){}}"]
      resources:
        requests:
          memory: 1100Mi

6.2 计算资源配额

---
kind: Pod
apiVersion: v1
metadata:
  name: minpod
spec:
  terminationGracePeriodSeconds: 0
  nodeSelector:
    kubernetes.io/hostname: node-0003
  containers:
    - name: linux
      image: myos:8.5
      command: ["awk","BEGIN{while(1){}}"]
      resources:
        requests:
          cpu: 800m

6.3 综合资源配额

同时设置 CPU 和内存配额时，资源必须满足全部需求。

---
kind: Pod
apiVersion: v1
metadata:
  name: minpod
spec:
  terminationGracePeriodSeconds: 0
  nodeSelector:
    kubernetes.io/hostname: node-0003
  containers:
    - name: linux
      image: myos:8.5
      command: ["awk","BEGIN{while(1){}}"]
      resources:
        requests:
          cpu: 800m
          memory: 1100Mi

6.4 内存 CPU 限额

---
kind: Pod
apiVersion: v1
metadata:
  name: maxpod
spec:
  terminationGracePeriodSeconds: 0
  containers:
    - name: linux
      image: myos:8.5
      command: ["awk","BEGIN{while(1){}}"]
      resources:
        limits:
          cpu: 800m
          memory: 2000Mi

7. 全局资源管理

如果有大量的容器需要设置资源配额，为每个 Pod 设置资源配额策略不方便且不好管理。管理员可以以名称空间为单位（namespace），限制其资源的使用与创建。在该名称空间中创建的容器都会受到规则的限制。K8s 支持的全局资源配额方式有：LimitRange（对单个 Pod 内存、CPU 进行配额）、ResourceQuota（对资源总量进行配额）。

7.1 LimitRange

---
apiVersion: v1
kind: LimitRange
metadata:
  name: mylimit
  namespace: work
spec:
  limits:
    - type: Container
      default:
        cpu: 300m
        memory: 500Mi
      defaultRequest:
        cpu: 8m
        memory: 8Mi

7.2 ResourceQuota

---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: myquota
  namespace: work
spec:
  hard:
    requests.cpu: 1000m
    requests.memory: 2000Mi
    limits.cpu: 5000m
    limits.memory: 8Gi
    pods: 3

五、控制器

控制器是什么？控制器是 K8s 内置的管理工具。可以帮助用户实现 Pod 的自动部署、自维护、扩容、翻滚更新等功能的自动化程序。

为什么要使用控制器？有大量的 Pod 需要维护管理，需要维护 Pod 的健康状态。控制器可以像机器人一样替用户完成维护管理的工作。

Deployment 控制器最常用的无状态服务控制器，由 Deployment、ReplicaSet、Pod 组成，支持集群扩容缩容、滚动、更新、自动维护 Pod 可用性及副本数量等功能。

1. Deployment

功能需要 service 资源对象来对其资源进行访问。当集群中有 Pod 被删除，Deploy 会自动创建新的 Pod 来维护集群的完整性。当 Pod 标签去掉时，会被踢出集群。集群扩缩容、滚动更新策略、历史版本及回滚。

需要新了解的配置项就是 spec 下面几个选项：replicas（指定副本数量）、selector（选择器，建立 pod 控制器和 pod 之间的关联关系）、template（模板，当前控制器创建 pod 所使用的模板）。

imagePullPolicy：确保容器总是使用最新版本的镜像。IfNotPresent：仅当镜像在本地不存在时，才被拉取；Never：设镜像已经存在于本地，不会尝试拉取镜像；Always：确保每次容器启动时都会拉取最新的镜像。

最常用的控制器，资源清单文件：

---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: myweb
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 30%
      maxUnavailable: 30%
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      restartPolicy: Always
      containers:
        - name: webserver
          image: myos:httpd
          imagePullPolicy: Always

1.1 扩缩容

kubectl scale deployment myweb --replicas=3
kubectl create -f nginx-deployment.yaml --record=true
kubectl get deploy myweb -n your_namespace
kubectl get pods -n your_namespace

1.2 镜像更新

deployment 支持两种更新策略：重建更新和滚动更新，可以通过 strategy 指定策略类型。

• type: Recreate（先杀掉所有已存在的 Pod）或 RollingUpdate（杀死一部分，就启动一部分）
• rollingUpdate: maxUnavailable（升级过程中不可用 Pod 的最大数量，默认为 25%）、maxSurge（升级过程中可以超过期望的 Pod 的最大数量，默认为 25%）

1.3 滚动更新策略

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

• status: 显示当前升级状态
• history: 显示升级历史记录
• pause: 暂停版本升级过程
• resume: 继续已经暂停的版本升级过程
• restart: 重启版本升级过程
• undo: 回滚到上一级版本

---
spec:
  revisionHistoryLimit: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

修改镜像，滚动更新集群：

kubectl set image deployment myweb webserver=myos:nginx
kubectl annotate deployments myweb kubernetes.io/change-cause="nginx.v1"
kubectl rollout history deployment myweb

1.4 版本回滚

kubectl rollout undo deployment myweb --to-revision 1
kubectl rollout history deployment myweb

1.5 金丝雀发布

Deployment 控制器支持控制更新过程中的控制，如'暂停 (pause)'或'继续 (resume)'更新操作。比如有一批新的 Pod 资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的 Pod 应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的 Pod 资源滚动更新，否则立即回滚更新操作。

kubectl set image deploy your_deploy_name nginx=nginx:1.17.4 -n your_namespace && kubectl rollout pause deployment your_deploy_name -n your_namespace
kubectl rollout status deploy your_deploy_name -n your_namespace
kubectl get rs -n your_namespace -o wide
kubectl rollout resume deploy your_deploy_name -n your_namespace
kubectl get pods -n your_namespace

1.6 删除控制器方法

kubectl delete deployments myweb
kubectl delete -f mydeploy.yaml

2. DaemonSet

DaemonSet 控制器无法自定义副本数量。所创建的 Pod 与 node 节点绑定，每个 node 上都会允许一个 Pod。当有新 Node 加入集群时，会为他新增 Pod 副本，当 Node 从集群移除时，这些 Pod 也会被回收。典型应用：kube-proxy。

---
kind: DaemonSet
apiVersion: apps/v1
metadata:
  name: myds
spec:
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      restartPolicy: Always
      containers:
        - name: webserver
          image: myos:httpd
          imagePullPolicy: Always

2.1 DS 控制器会受到污点策略的影响

kubectl taint node node-0001 k=v:NoSchedule
kubectl delete -f myds.yaml
kubectl apply -f myds.yaml
kubectl get pods
kubectl taint node node-0001 k=v:NoSchedule-
kubectl delete -f myds.yaml

3. Job/CronJob

3.1 Job

单任务控制器，执行一次任务。CronJob 是 Job 的升级版，基于时间管理的 Job 控制器。restartPolicy 策略会判断 exit 状态码，状态为 0 表示正常，其他都是失败。任务执行出错，会重新执行该任务。

---
kind: Job
apiVersion: batch/v1
metadata:
  name: myjob
spec:
  template:
    spec:
      restartPolicy: OnFailure
      containers:
        - name: myjob
          image: myos:8.5
          command: ["/bin/bash"]
          args: ["-c", "sleep 3; exit $((RANDOM%2))"]

3.2 CronJob

时间定义 schedule: 分 时 日 月 周。会按照时间周期运行。只保留执行三次的结果，多余被删除。

---
kind: CronJob
apiVersion: batch/v1
metadata:
  name: mycj
spec:
  schedule: "* * * * 1-5"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: myjob
              image: myos:8.5
              command: ["/bin/bash"]
              args: ["-c", "sleep 3; exit $((RANDOM%2))"]

4. 基础控制器的区别

4.1 Deployment

Deployment 控制器是最常用的 Controller，可以管理 Pod 的多个副本，并确保 Pod 按照期望的状态运行。它支持两种更新策略：滚动更新和重新创建，默认为滚动更新。在 Deployment 中，如果存在容器异常退出，会自动创建新的 Pod 进行替代；同时，异常多出来的容器也会自动回收。

4.2 DaemonSet

DaemonSet 控制器主要用于在每个节点最多只运行一个 Pod 副本的场景。它的名称暗示了其通常用于运行守护进程（daemon）。当有新的节点加入集群时，DaemonSet 控制器会自动在该节点上创建一个 Pod 副本，当有节点从集群中移除时，DaemonSet 控制器会自动回收该节点上的 Pod 副本。

4.3 CronJob/Job

主要用于运行结束就删除的应用。它并不适合长期持续运行的任务。相反，它的设计目的是为了处理一些特定的、一次性的任务，例如批处理任务、定时任务等。一旦任务完成，Job 控制器就会自动删除相关的 Pod。

5. StatefulSet

StatefulSet 控制器旨在与有状态的应用及分布式统一使用，涉及了 Headless 服务、存储卷、DNS 等相关知识，是一个宽泛而复杂的话题。Headless 服务在配置 StatefulSets 的时候，首先要定义一个 Headless 的服务。在创建 Pod 的时候会自动把<Pod 名称>注册为域名。

5.1 headless 服务

---
kind: Service
apiVersion: v1
metadata:
  name: mysvc2
spec:
  type: ClusterIP
  clusterIP: None
  selector:
    app: httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

5.2 StatefulSet 资源配置文件

---
kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: mysts
spec:
  serviceName: mysvc2
  replicas: 3
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      restartPolicy: Always
      containers:
        - name: webserver
          image: myos:httpd
          imagePullPolicy: Always

6. Horizontal Pod Autoscaler(HPA)控制器

可在 K8s 集群中基于 CPU 利用率或其他应用程序提供的度量指标实现水平自动伸缩的功能，自动缩放 POD 的数量。要在集群中运行，所以先创建集群也需要 ClusterIP 服务。

创建被监控的资源对象：

---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: myweb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      restartPolicy: Always
      containers:
        - name: webserver
          image: myos:httpd
          imagePullPolicy: Always
          resources:
            requests:
              cpu: 200m

创建 HPA：

---
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v1
metadata:
  name: myweb
spec:
  minReplicas: 1
  maxReplicas: 5
  targetCPUUtilizationPercentage: 50
  scaleTargetRef:
    kind: Deployment
    apiVersion: apps/v1
    name: myweb

六、Service

容器带来的问题:

• 自动调度：在 Pod 创建之前，用户无法预知 Pod 所在节点以及 Pod 的 IP 地址
• 一个已经存在的 Pod 在运行过程中，出现故障，Pod 也会在新的节点使用新的 IP 进行部署
• 应用程序访问服务时，地址是不能经常转变的
• 多个相同的 Pod 如何访问他们上面的服务

Service 服务原理:

• 自动感知: 服务会创建一个 clusterIP，对应资源地址，不管 Pod 如何变化，服务总能找到对应的 Pod，且 clusterIP 保持不变
• 负载均衡: 若服务器后端对应多个 Pod，则会通过 IPTables/LVS 规则访问请求最终映射到 Pod 容器内部，自动实现多个容器的负载均衡
• 自动发现: 服务创建时会自动在内部 dns 上注册域名
• 域名: <服务名称>.<名称空间>.svc.cluster.local

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

Service 有 4 种类型：

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

6.1 ClusterIP

默认的 ServiceType，通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。

默认类型: 实现 Pod 的自动感知与负载均衡，是最核心的服务类型，但 ClusterIP 不能对外发布服务，相对外发布服务只能使用 NodePort 或 Ingress。

工作原理: kube-proxy 是在所有节点上运行的代理，可以实现简单的数据转发，设置更新 IPTables/LVS 规则，服务创建时，还提供服务地址 DNS 自动注册与服务发现功能。

创建 service 资源文件模板: kubectl create service clusterip mysvc --tcp=80:80 --dry-run=client -o yaml

---
kind: Service
apiVersion: v1
metadata:
  name: mysvc
spec:
  type: ClusterIP
  clusterIP: 10.245.1.80
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 31122

创建 service

kubectl apply -f mysvc.yaml
kubectl get service

域名解析

dnf -y install bind-utils
kubectl -n kube-system get service kube-dns
host mysvc.default.svc.cluster.local

6.2 nodePort

ClusterIP 服务可以解决集群内应用互访的问题，但外部的应用无法访问集群内的资源。某些应用需要访问集群内的资源，我们就需要对外发布服务。

NodePort 与 Ingress:

• NodePort: 使用基于端口映射 (默认值：30000-32767) 的方式对外发布服务，可以任意发布服务 (四层)
• Ingress: 使用 Ingress 控制器 (一般由 Nginx 或 HAProxy 构成), 用来发布 http,https 服务 (七层，只能发布这两个服务)

7 层负载均衡比 4 层负载均衡更加智能，4 层负载均衡比 7 层负载均衡更加简洁高效。

---
kind: Service
apiVersion: v1
metadata:
  name: mysvc1
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      nodePort: 30080
      targetPort: myhttp

发布服务

kubectl apply -f mysvc1.yaml
kubectl get service

6.3 Ingress

Ingress 服务由 (规则 + 控制器) 组成。使用 Ingress 控制器 (一般由 Nginx 或 HAProxy 构成), 用来发布 http,https 服务 (七层，只能发布这两个服务)。

获取 ingress：

mkdir ingress-controller
cd ingress-controller/
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
# 修改镜像仓库地址
kubectl apply -f ./
kubectl get pod -n ingress-nginx
kubectl get svc -n ingress-nginx

创建 ingress：

---
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: mying
spec:
  ingressClassName: nginx
  rules:
    - host: nsd.tedu.cn
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: mysvc
                port:
                  number: 80

kubectl apply -f mying.yaml
kubectl get ingress
curl -H "Host: nsd.tedu.cn" http://192.168.1.51

七、存储卷管理

容器中的文件在磁盘上是临时存放的，所以：

• 当容器崩溃或重启，kubelet 重启容器后，历史数据会消失
• 容器被删除，容器内的数据也会消失
• 多个容器有共享文件或目录的需求

卷概述：

• 卷是一个抽象化的存储设备
• 卷可以解决容器崩溃或重启，数据丢失的问题
• 可以解决容器或 Pod 被删后数据持久保存的问题
• 可以解决在多个容器内共享数据的问题
• Pod 可以同时使用任意数目的卷

持久卷: 持久卷是集群中的存储资源，里面的内容不会随着 Pod 的删除而消失。 临时卷: 有些应用程序需要额外的存储，但并不关心数据在重启后是否仍可用，卷会遵从 Pod 的生命周期，与 Pod 一起创建和删除。

使用存储卷：在 Pod.spec 下添加 volumes 字段，配置外部存储卷；在 Pod.spec.containers[*] 中添加 volumeMounts 字段，声明卷在容器中挂载位置。

1. 持久卷

1.1 hostPath

本质是使用本地设备，如磁盘，分区，目录等，hostPath 的可用性取决于底层节点的可用性，如果节点变的不健康，那 hostPath 也将不可访问。hostPath 卷里面的数据不会随着 Pod 的结束而消失。

---
kind: Pod
apiVersion: v1
metadata:
  name: web1
spec:
  volumes:
    - name: logdata
      hostPath:
        path: /var/weblog
        type: DirectoryOrCreate
  containers:
    - name: nginx
      image: myos:nginx
      volumeMounts:
        - name: logdata
          mountPath: /usr/local/nginx/logs

type 类型：

1.2 NFS

k8s 中允许将 nfs 存储以卷的方式挂载到你的 Pod 中。在删除 Pod 时，nfs 存储卷会被卸载（umount），而不是被删除。nfs 卷可以在不同节点的 Pod 之间共享数据。

NFS 最大的功能就是在不同节点的不同 Pod 中共享读写数据。本地 NSF 的客户端可以透明地读写位于远端 NFS 服务器上的文件，就像访问本地文件一样。

部署: 需要一台 NFS 服务器，在所有节点都需安装 NFS（因为 Pod 是随机调度的，所以为保证 NFS 存储卷可以正确加载，需在所有 node 节点上都安装 NFS 软件工具包）。

---
kind: Pod
apiVersion: v1
metadata:
  name: web1
spec:
  volumes:
    - name: website
      nfs:
        server: 192.168.1.10
        path: /var/webroot
  containers:
    - name: nginx
      image: myos:nginx
      volumeMounts:
        - name: website
          mountPath: /usr/local/nginx/html

1.3 PV/PVC

PV: 持久卷，资源提供者，有管理员配置，PV 的全称是 Persistent Volume，是持久卷。 VC: 持久卷声明，资源使用者，根据业务需求来配置，PVC 的全称是 Persistent VolumeClaim，是持久卷声明。PVC 会根据客户的需求，自动找到 PV 绑定。

accessMode：存储卷能提供的访问方式:

• ReadWriteOnce: 单节点读写
• ReadOnlyMany: 多节点只读
• ReadWriteMany: 多节点读写
• ReadWriteOnceMany: 在一个 Pod 中只读

volumeMode：提供资源的类型:

• Filesystem: 文件系统，直接 mount 就可以使用
• Block: 块设备，要先格式化在 mount

持久卷 PV

---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-local
spec:
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 30Gi
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /var/weblog
    type: DirectoryOrCreate
---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-nfs
spec:
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
    - ReadOnlyMany
    - ReadWriteMany
  capacity:
    storage: 20Gi
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
    - nolock
  nfs:
    server: 192.168.1.10
    path: /var/webroot

持久卷声明 PVC

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc1
spec:
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 25Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc2
spec:
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 15Gi

Pod 挂载 PVC

---
kind: Pod
apiVersion: v1
metadata:
  name: web1
spec:
  volumes:
    - name: logdata
      persistentVolumeClaim:
        claimName: pvc1
    - name: website
      persistentVolumeClaim:
        claimName: pvc2
  containers:
    - name: nginx
      image: myos:nginx
      volumeMounts:
        - name: logdata
          mountPath: /usr/local/nginx/logs
        - name: website
          mountPath: /usr/local/nginx/html

2. 临时卷

2.1 ConfigMap

提供了向 Pod 注入配置数据的方法，允许你将配置文件与镜像分离，使容器化的应用具有可移植性。在使用之前就要创建好，不是用来保存数据的，其保存的数据不可超过 1MiB。配置环境变量，修改配置文件的参数，数据库地址等。

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: timezone
data:
  TZ: Asia/Shanghai

---
kind: Pod
apiVersion: v1
metadata:
  name: web1
spec:
  containers:
    - name: nginx
      image: myos:nginx
      envFrom:
        - configMapRef:
            name: timezone
      volumeMounts:
        - name: logdata
          mountPath: /usr/local/nginx/logs
        - name: website
          mountPath: /usr/local/nginx/html

2.2 Secret

类似于 ConfigMap，专门用于保存机密数据，因为是加密的。一般用于：配置一些需要加密的环境变量或文件（如 https 证书）、访问需要认证登录的私有镜像仓库（如 harbor 私有仓库）。

通用类型：kubectl create secret generic 名称 [选项/参数] 用于认证登录私有仓库的子类型：kubectl create secret docker-registry 名称 [选项/参数] 用于创建 TLS 证书的子类型：kubectl create secret tls 名称 [选项/参数]

配置登录密钥

kubectl create secret docker-registry harbor-auth --docker server=harbor:443 --docker-username="admin" --docker-password="admin123"
kubectl get secrets harbor-auth -o yaml

认证私有仓库

---
kind: Pod
apiVersion: v1
metadata:
  name: web2
spec:
  imagePullSecrets:
    - name: harbor-auth
  containers:
    - name: apache
      image: harbor:443/myimg/httpd:latest

2.3 emptyDir

本质是一个空目录，可以提供临时空间，同一个 Pod 中的容器也可以来共享数据。随着 Pod 创建而创建，Pod 在该节点上运行期间，一直存在，当 Pod 被节点删除时，临时卷中的数据也会被永久删除。重启 Pod 不会造成 emptyDir 数据的丢失。

临时空间

---
kind: Pod
apiVersion: v1
metadata:
  name: web2
spec:
  imagePullSecrets:
    - name: harbor-auth
  volumes:
    - name: cache
      emptyDir: {}
  containers:
    - name: apache
      image: harbor:443/myimg/httpd:latest
      volumeMounts:
        - name: cache
          mountPath: /var/cache