部署应用到集群中

部署容器镜像

直接部署 hub.docker 上的镜像容器

#kubectl run testapp --image=容器地址
kubectl run testapp --image=ccr.ccs.tencentyun.com/k8s-tutorial/test-k8s:v1

使用 kubectl get pod 可以查看已经部署的应用

kubectl get pod

Pod

Pod 是 k8s 系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在 k8s 上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展 Pod 对象功能的，比如控制器对象是用来管控 Pod 对象的，Service 或者 Ingress 资源对象是用来暴露 Pod 引用对象的，PersistentVolume 资源对象是用来为 Pod 提供存储等等，k8s 不会直接处理容器，而是 Pod，Pod 是由一个或多个 container 组成。

Pod 是 Kubernetes 的最重要概念，每一个 Pod 都有一个特殊的被称为” 根容器 “的 Pause 容器。Pause 容器对应的镜 像属于 Kubernetes 平台的一部分，除了 Pause 容器，每个 Pod 还包含一个或多个紧密相关的用户业务容器

• Pod s vs 应用：每个 Pod 都是应用的一个实例，有专用的 IP
• Pod s vs 容器：一个 Pod 可以有多个容器，彼此间共享网络和存储资源，每个 Pod 中有一个 Pause 容器保存所有的容器状态， 通过管理 pause 容器，达到管理 pod 中所有容器的效果
• Pod s vs 节点：同一个 Pod 中的容器总会被调度到相同 Node 节点，不同节点间 Pod 的通信基于虚拟二层网络技术实现
• Pod s vs Pod：普通的 Pod 和静态 Pod

Pod 特性

资源共享

一个 Pod 里的多个容器可以共享存储和网络，可以看作一个逻辑的主机。共享的如 namespace,cgroups 或者其他的隔离资源。

多个容器共享同一 network namespace，由此在一个 Pod 里的多个容器共享 Pod 的 IP 和端口 namespace，所以一个 Pod 内的多个容器之间可以通过 localhost 来进行通信，所需要注意的是不同容器要注意不要有端口冲突即可。不同的 Pod 有不同的 IP, 不同 Pod 内的多个容器之前通信，不可以使用 IPC（如果没有特殊指定的话）通信，通常情况下使用 Pod 的 IP 进行通信。

一个 Pod 里的多个容器可以共享存储卷，这个存储卷会被定义为 Pod 的一部分，并且可以挂载到该 Pod 里的所有容器的文件系统上。

生命周期短暂

Pod 属于生命周期比较短暂的组件，比如，当 Pod 所在节点发生故障，那么该节点上的 Pod 会被调度到其他节点，但需要注意的是，被重新调度的 Pod 是一个全新的 Pod, 跟之前的 Pod 没有半毛钱关系。

平坦的网络

K8s 集群中的所有 Pod 都在同一个共享网络地址空间中，也就是说每个 Pod 都可以通过其他 Pod 的 IP 地址来实现访问。

Pod 定义

apiVersion: v1
kind: Pod
metadata:
  # 元数据
  name: string
  namespace: string
  labels:
    # 标签
    - name: string
  annotations:
    # 注解
    - name: string
spec:
  containers: # pod 中的容器列表，可以有多个容器
    # 容器列表
    - name: string
      # 容器名称
      image: string
      # 容器中的镜像
      imagePullPolicy: [Always|Never|IfNotPresent]
      # 获取镜像的策略
      # 默认值为Always，每次都尝试重新下载镜像
      command: [string]
      # 容器的启动命令列表（不配置的话使用镜像内部的命令）
      args: [string]
      # 启动参数列表
      workingDir: string
      # 容器的工作目录
      volumeMounts:
        # 挂载到容器内部的存储卷设置
        - name: string
          mountPath: string
          # 存储卷在容器内部Mount的绝对路径
          readOnly: boolean
          # 默认值为读写
      ports:
        # 容器需要暴露的端口号列表
        - name: string
          containerPort: int
          # 容器要暴露的端口
          hostPort: int
          # 容器所在主机监听的端口
          # 容器暴露端口映射到宿主机的端口
          # 设置hostPort时同一台宿主机将不能再启动该容器的第2份副本
          protocol: string
          # TCP和UDP，默认值为TCP
      env:
        # 容器运行前要设置的环境列表
        - name: string
          value: string
      resources:
        limits:
          # 资源限制，容器的最大可用资源数量
          cpu: string
          memory: string
        requests:
          # 资源限制，容器启动的初始可用资源数量
          cpu: string
          memory: string
      livenessProbe:
        # Pod内部容器健康检查的设置
        exec:
          command: [string]
        httpGet:
          # 通过HTTP GET检查健康
          path: string
          port: number
          host: string
          scheme: string
          httpHeaders:
            - name: string
              value: string
        tcpSocket:
          # 通过TCP Socket检查健康
          port: number
        initialDelaySeconds: 0
        # 首次检查时间
        timeoutSeconds: 0
        # 检查超时时间
        periodSeconds: 0
        # 检查间隔时间
        successThreshold: 0
        failureThreshold: 0
      securityContext:
        # 安全配置
        privileged: false
  restartPolicy: [Always|Never|OnFailure]
  # 重启策略，默认值为Always
  nodeSelector: object
  # 节点选择，表示将该Pod调度到包含这些label的Node上
  # 以key:value格式指定
  imagePullSecrets:
    - name: string
  hostNetwork: false
  # 是否使用主机网络模式，弃用Docker网桥，默认否
  volumes:
    # 在该Pod上定义共享存储卷列表
    - name: string
      emptyDir: {}
    - hostPath:
        path: string
    - secret:
        secretName: string
        items:
          - key: string
            path: string
    - configMap:
        name: string
        items:
          - key: string
            path: string

在 kubernetes 中对运行容器的要求为：容器的主程序需要一直在前台运行，而不是后台运行。应用需要改造成前 台运行的方式。如果我们创建的 Docker 镜像的启动命令是后台执行程序，则在 kubelet 创建包含这个容器的 pod 之 后运行完该命令，即认为 Pod 已经结束，将立刻销毁该 Pod。如果为该 Pod 定义了 RC，则创建、销毁会陷一个无 限循环的过程中。Pod 可以由 1 个或多个容器组合而成。

Pod 的分类

普通 Pod

普通 Pod 一旦被创建，就会被放入到 etcd 中存储，随后会被 Kubernetes Master 调度到某个具体的 Node 上并进行绑定，随后该 Pod 对应的 Node 上的 kubelet 进程实例化成一组相关的 Docker 容器并启动起来。在默认情 况下，当 Pod 里某个容器停止时，Kubernetes 会自动检测到这个问题并且重新启动这个 Pod 里某所有容器， 如果 Pod 所在的 Node 宕机，则会将这个 Node 上的所有 Pod 重新调度到其它节点上。

静态 Pod

静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod, 它们不能通过 API Server 进行管理，无法与 ReplicationController、Deployment 或 DaemonSet 进行关联，并且 kubelet 也无法对它们进行健康检查。

Pod 生命周期和重启策略

Pod 的状态

状态值	说明
Pending	API Servert 已经创建了该 Pod, 但 Pod 中的一个或多个容器的镜像还设有创建，包括镜像下载过程
Running	Pod 内所有容器已创建，且至少一个容器处于运行状态、正在启动状态或正在重启状态
Completed	Pod 内所有容器均成功执行退出，且不会再重启
Failed	Pod 内所有容器均已退出，但至少一个容器退出失败
Unknown	由于某种原因无法获取 P0d 状态，例如网络通信不畅

Pod 重启策略

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

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

常见状态转换

Pod 包含的容器数	Pod 当前的状态	发生事件	Pod 的结果状态
			RestartPolicy=Always	RestartPolicy=OnFailure	RestartPolicy=Never
包含一个容器	Running	容器成功退出	Running	Succeeded	Succeeded
包含一个容器	Running	容器失败退出	Running	Running	Failure
包含两个容器	Running	1 个容器失败退出	Running	Running	Running
包含两个容器	Running	容器被 OOM 杀掉	Running	Running	Failure

Pod 资源配置

每个 Pod 都可以对其能使用的服务器上的计算资源设置限额，Kubernetes 中可以设置限额的计算资源有 CPU 与 Memory 两种，其中 CPU 的资源单位为 CPU 数量，是一个绝对值而非相对值。Memory 配额也是一个绝对值，它的单 位是内存字节数。

Kubernetes 里，一个计算资源进行配额限定需要设定以下两个参数： Requests 该资源最小申请数量，系统必须满足要求 Limits 该资源最大允许使用的量，不能突破，当容器试图使用超过这个量的资源时，可能会被 Kubernetes Kill 并重启。

案例

编写一个 pod.yaml 配置 YAML 文件

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  # 定义容器，可以多个
  containers:
    - name: test-k8s # 容器名字
      image: ccr.ccs.tencentyun.com/k8s-tutorial/test-k8s:v1 # 镜像

再使用 kubectl 命令运行指定配置文件

kubectl apply -f pod.yaml

查看容器

kubectl get pod

Controller 控制器

Replication Controller

Replication Controller (RC) 是 Kubernetes 系统中核心概念之一，当我们定义了一个 RC 并提交到 Kubernetes 集群中以后，Master 节点上的 Controller Manager 组件就得到通知，定期检查系统中存活的 Pod, 并确保目标 Pod 实例的数量刚好等于 RC 的预期值，如果有过多或过少的 Pod 运行，系统就会停掉或创建一些 Pod. 此外我们也可以通过修改 RC 的副本数量，来实现 Pod 的动态缩放功能。

kubectl scale rc nginx --replicas=5

由于 Replication Controller 与 Kubernetes 代码中的模块 Replication Controller 同名，所以在 Kubernetes v1.2 时， 它就升级成了另外一个新的概念 Replica Sets。

官方解释为下一代的 RC，它与 RC 区别是：Replica Sets 支援基于集合的 Label selector, 而 RC 只支持基于等式的 Label Selector。

我们很少单独使用 Replica Set, 它主要被 Deployment 这个更高层面的资源对象所使用，从而形成一整套 Pod 创建、删除、更新的编排机制。最好不要越过 RC 直接创建 Pod， 因为 Replication Controller 会通过 RC 管理 Pod 副本，实现自动创建、补足、替换、删除 Pod 副本，这样就能提高应用的容灾能力，减少由于节点崩溃等意外状况造成的损失。即使应用程序只有一个 Pod 副本，也强烈建议使用 RC 来 定义 Pod

Replica Set

ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector（ReplicationController 仅支持等式）。

Kubernetes 官方强烈建议避免直接使用 ReplicaSet，而应该通过 Deployment 来创建 RS 和 Pod。由于 ReplicaSet 是 ReplicationController 的代替物，因此用法基本相同，唯一的区别在于 ReplicaSet 支持集合式的 selector。

Deployment

Deployment 是 Kubenetes v1.2 引入的新概念，引入的目的是为了更好的解决 Pod 的编排问题，Deployment 内部使用了 Replica Set 来实现。Deployment 的定义与 Replica Set 的定义很类似，除了 API 声明与 Kind 类型有所区别：

app.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  # 部署名字
  name: test-k8s
spec:
  replicas: 2 # 副本数量即Pod数量
  # 用来查找关联的 Pod，所有标签都匹配才行
  selector:
    matchLabels:
      app: test-k8s # tag: 自定义名称
  # 定义 Pod 相关数据
  template:
    metadata:
      labels:
        app: test-k8s
    spec:
      # 定义容器，可以多个
      containers:
      - name: test-k8s # 容器名字
        image: ccr.ccs.tencentyun.com/k8s-tutorial/test-k8s:v1 # 镜像

部署

kubectl apply -f app.yaml

查看容器情况

kubectl get pod

可以观察到有两个前缀为我们自定义容器名称的容器，后缀为随机生成的两个容器，由我们配置文件的 副本数 来控制会部署多少个容器

查看 Deployment 情况

kubectl get deployment

查看 pod 的更多信息

kubectl get pod -o wide

可以查询容器的 ip 运行在哪个节点上

Deployment 通过 label 关联起来 Pods

Label 是 Kubernetes 系统中另一个核心概念。一个 Label 是一个 key=value 的键值对，其中 key 与 value 由用户自己指 定。Label 可以附加到各种资源对象上，如 Node、Pod、Service、RC，一个资源对象可以定义任意数量的 Label， 同一个 Label 也可以被添加到任意数量的资源对象上，Label 通常在资源对象定义时确定，也可以在对象创建后动态添加或删除。

Label 的最常见的用法是使用 metadata.labels 字段，来为对象添加 Label，通过 spec.selector 来引用对象

Horizontal Pod Autoscaler

Horizontal Pod Autoscal (Pod 横向扩容 简称 HPA) 与 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况，来确定是否需要针对性地调整目标 Pod 的副本数，这是 HPA 的 实现原理。

Kubernetes 对 Pod 扩容与缩容提供了手动和自动两种模式：

• 手动模式通过 kubectl scale 命令对一个 Deployment/RC 进行 Pod 副本数量的设置。
• 自动模式则需要用户根据某个性能指标或者自定义业务指标，并指定 Pod 副本数量的范围，系统将自动在这个范围内根据性能指标的变化进行调整。

手动扩容和缩容

kubectl scale deployment frontend --replicas 1

自动扩容和缩容

HPA 控制器基本 Master 的 kube-controller-manager 服务启动参数 --horizontal-pod-autoscaler-sync-period 定义的时长 (默认值为 30s), 周期性地监测 Pod 的 CPU 使用率，并在满足条件时对 RC 或 Deployment 中的 Pod 副 本数量进行调整，以符合用户定义的平均 Pod CPU 使用率。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          resources:
            requests:
              cpu: 50m
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
    - port: 80
  selector:
    app: nginx
---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: app/v1beta1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50 # 一旦CPU利用率超过50%，它将增加Pod的副本数量以分担负载。如果CPU利用率低于50%，它将减少Pod的副本数量以节省资源。

部署应用演示

部署一个 nodejs web 应用，源码地址：Github (opens new window)

# 部署应用
kubectl apply -f app.yaml
# 查看 deployment
kubectl get deployment
# 查看 pod
kubectl get pod -o wide
# 查看 pod 详情
kubectl describe pod pod-name
# 查看 log
kubectl logs pod-name
kubectl logs pod-name -f
# 进入 Pod 容器终端， -c container-name 可以指定进入哪个容器。
kubectl exec -it pod-name -- bash
# 伸缩扩展副本
kubectl scale deployment test-k8s --replicas=5
# 把集群内端口映射到节点
kubectl port-forward pod-name 8090:8080
# 查看历史
kubectl rollout history deployment test-k8s
# 回到上个版本
kubectl rollout undo deployment test-k8s
# 回到指定版本
kubectl rollout undo deployment test-k8s --to-revision=2
# 重启 Deployment 中的所有 Pod
kubectl rollout restart deployment/<deployment-name>
# 删除部署
kubectl delete deployment test-k8s
# 删除pod
kubectl delete po pod-name
# 强制删除pod
kubectl delete po pod-name --force --grace-period=0
# 查看全部
kubectl get all
# 重新部署
kubectl rollout restart deployment test-k8s
# 命令修改镜像，--record 表示把这个命令记录到操作历史中
kubectl set image deployment test-k8s test-k8s=ccr.ccs.tencentyun.com/k8s-tutorial/test-k8s:v2-with-error --record
# 暂停运行，暂停后，对 deployment 的修改不会立刻生效，恢复后才应用设置
kubectl rollout pause deployment test-k8s
# 恢复
kubectl rollout resume deployment test-k8s
# 输出到文件
kubectl get deployment test-k8s -o yaml >> app2.yaml
kubectl get deployment test-k8s -o json
# 删除全部资源
kubectl delete all --all

更多官网关于 Deployment (opens new window) 的介绍

Pod 报错问题

如果你运行 kubectl describe pod/pod-name 发现 Events 中有下面这个错误

在每个节点创建文件 /run/flannel/subnet.env 写入以下内容，配置后等待一会就好了

vim /run/flannel/subnet.env

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

重新查看

kubectl get pod
kubectl describe pod/pod-name

将 Pod 部署到指定节点

将 Pod 指定到某个节点运行：nodeselector (opens new window)

首先给节点起别名

# 获取节点name
kubectl get nodes
# 起别名
kubectl label nodes <your-node-name> disktype=ssd
# 查看别名是否生效
kubectl get nodes --show-labels

app.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
  	# disktype: 节点别名
    disktype: ssd

限制资源使用

限定 CPU、内存总量：文档 (opens new window)

资源名称	描述
limits.cpu	所有非终止状态的 Pod，其 CPU 限额总量不能超过该值。
limits.memory	所有非终止状态的 Pod，其内存限额总量不能超过该值。
requests.cpu	所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。
requests.memory	所有非终止状态的 Pod，其内存需求总量不能超过该值。
hugepages-<size>	对于所有非终止状态的 Pod，针对指定尺寸的巨页请求总数不能超过此值。
cpu	与 requests.cpu 相同。
memory	与 requests.memory 相同。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.nvidia.com/gpu: 4

查看指定容器的资源配置

kubectl get pod
kubectl describe pod/pod-name

工作负载分类

• Deployment 适合无状态应用，所有 pod 等价，可替代
• StatefulSet 有状态的应用，适合数据库这种类型。
• DaemonSet 在每个节点上跑一个 Pod，可以用来做节点监控、节点日志收集等
• Job & CronJob Job 用来表达的是一次性的任务，而 CronJob 会根据其时间规划反复运行。

官方文档 (opens new window)

Deployment 的问题

• 每次只能访问一个 pod，没有负载均衡自动转发到不同 pod
• 访问还需要端口转发
• Pod 重创后 IP 变了，名字也变了