一、Pod管理

• pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元
• Pod （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） 容器； 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， 这些容器是相对紧密的耦合在一起的。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。
• 就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。
• 每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例 以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。 在 Kubernetes 中，这通常被称为 副本（Replication）。通常使用一种工作负载资源及其控制器 来创建和管理一组 Pod 副本。

01_创建与删除pod

集群内部可以访问，外部无法直接访问

• 创建pod：
  kubectl run nginx --image=myapp:v1
  
• 集群内部可以访问
  
• 集群外部无法直接访问
  
  
  
• 删除pod
  kubectl delete pod nginx

02_Deployment控制器管理pod

• 创建
  kubectl create deployment nginx --image=myapp:v1
  

• 删除pod后会又自动创建一个新的pod
  kubectl delete pod nginx-67f9d9c97f-qdgvq

• 彻底删除
  kubectl delete deployments nginx

03_扩容与缩容

–replicas：在deployment控制器的基础上
kubectl scale deployment --replicas=2 nginx

04_创建service并外部访问

ClusterIP：默认类型，自动分配一个仅集群内部可以访问的虚拟IP

• kubectl expose deployment nginx --port=80
  

• 集群内部可以访问
  
  

• 集群外部不可访问
  

NodePort 暴露端口：外部客户端访问（可以通过NodeIP：NodePort来访问）

• kubectl edit svc nginx （修改 type: NodePort）
  

• 查看端口号kubectl get svc
  

• 内部访问集群
  

• 外部访问集群
  

• 创建时指定类型为NodePort：
  kubectl expose deployment nginx --port=80 --type=NodePort

05_更新与回滚

• 更新pod镜像
  kubectl set image deployment nginx myapp=myapp:v2
  
• 回滚
  kubectl rollout history deployment nginx查看历史版本
  kubectl rollout undo deployment nginx --to-revision=1回滚
  
  

二、资源清单

kubectl api-versions：查询命令
kubectl explain pod查询帮助文档

• apiVersion：group/version 指明api资源属于哪个群组和版本，同一个组可以有多个版本

• kind：标记创建的资源类型

• metadata：元数据

   name：对象名称，
   namespace：对象所属的命名空间，
   labels：指定资源标签（键值数据）
  

• spec：定义目标资源的期望状态

简单pod示例

kubectl apply -f pod.yml #创建
kubectl delete -f pod.yml #删除

#pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
spec:
  containers:
  - name: nginx
    image: myapp:v1
    imagePullPolicy: IfNotPresent

Deployment控制器示例

kubectl apply -f deployment.yml #创建
kubectl delete -f deployment.yml #删除

#deployment.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      #nodeSelector:
      #  kubernetes.io/hostname: server3
      #nodeName: server3
      #hostNetwork: true
      containers:
      - name: nginx
        image: myapp:v1
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 0.5
            memory: 512Mi
                  - name: busybox
        image: busybox
        imagePullPolicy: IfNotPresent
        stdin: true
        tty: true
      - name: busybox
        image: busybox
        imagePullPolicy: IfNotPresent
        stdin: true
        tty: true

• 资源控制器

cpu: 100m
        memory: 100Mi
      limits:
        cpu: 0.5
        memory: 512Mi

kubectl describe pod nginx-79cc587f-ntjdb查看pod详细信息

• 节点控制器

  nodeSelector:
    kubernetes.io/hostname: server3
  nodeName: server3#与前两行作用相同，选择其一即可

• 使用主机网络模式

  hostNetwork: true

• 同一个pod内创建多个容器

   - name: busybox
    image: busybox
    imagePullPolicy: IfNotPresent
    stdin: true
    tty: true

标签

• 打标签
  kubectl label nodes server3 app=nginx
  
• 更改标签
  kubectl label nodes server3 app=myapp --overwrite
  

三、Pod生命周期

pod生命周期官方文档

01_pod阶段

• Pod 的 status 字段是一个 PodStatus 对象，其中包含一个 phase 字段。
• Pod 的阶段（Phase）是 Pod 在其生命周期中所处位置的简单宏观概述。 该阶段并不是对容器或 Pod
  状态的综合汇总，也不是为了成为完整的状态机。

phase取值	说明
Pending（悬决）	Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间，
Running（运行中）	Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
Succeeded（成功）	Pod 中的所有容器都已成功终止，并且不会再重启。
Failed（失败）	Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
Unknown（未知）	因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

02_容器状态

Waiting （等待）

• 如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。 处于 Waiting
  状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像 仓库拉取容器镜像，或者向容器应用 Secret 数据等等。 当你使用kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。

Running（运行中）

• Running 状态表明容器正在执行状态并且没有问题发生。 如果配置了 postStart 回调，那么该回调已经执行且已完成。 如果你使用kubectl 来查询包含 Running 状态的容器的 Pod 时，你也会看到 关于容器进入 Running 状态的信息。

Terminated（已终止）

• 处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含Terminated 状态的容器的 Pod 时，你会看到 容器进入此状态的原因、退出代码以及容器执行期间的起止时间。
  如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行。

03_容器探针

三种探针：

• livenessProbe：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器，
  并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success(成功)。
• readinessProbe：指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。如果容器不提供就绪态探针，则默认状态为 Success。
• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被
  禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。

示例1:存活探针

• vim live.yml

#live.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busyboxplus
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

kubectl create -f live.yml创建pod

kubectl describe pod liveness-exec查看pod状态
kubectl get pod已经重启

示例2

#live.yml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
 - name: liveness
    image: myapp:v1
    livenessProbe:#存活探针
      tcpSocket:
        port: 80#更改为8080
      initialDelaySeconds: 2
      periodSeconds: 3
    readinessProbe:#就绪探针
      httpGet:
        path: /hostname.html#更改为不存在的test.html
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 3

• 更改为8080：内部默认检测的是8080端口，需要说明port: 80，不然会一致重启寻找8080
  
• 更改为不存在的test.html，非就绪状态
  

04_init初始化容器

init容器官方文档
vim init.yml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: myapp:v1
  initContainers:
  - name: init-myservice
    image: busyboxplus
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

kubectl create -f init.yml无法解析域名，一直处于初始化状态

kubectl logs myapp-pod init-myservice查看日志

vim service.yml

---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

kubectl create -f service.yml pod状态正常

四、控制器

控制器官方文档

01_Deployment

一个 Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。
适用于：

• 创建pod与ReplicaSet
• 滚动更新和回滚
• 扩容与缩容
• 暂停与恢复

02_ReplicaSet

可以单独使用，但主要被Deployment用于协调pod创建、删除、更新的机制

• ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。
• 保证给定数量的、完全相同的 Pod 的可用性。
• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行（与控制器ReplicationController功能相同）

工作原理

• RepicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板等等。每个 ReplicaSet 都通过根据需要创建和 删除 Pod 以使得副本个数达到期望值， 进而实现其存在价值。当 ReplicaSet需要创建新的 Pod 时，会使用所提供的 Pod 模板。
• ReplicaSet 通过 Pod 上的 metadata.ownerReferences 字段连接到附属Pod，该字段给出当前对象的属主资源。 ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主ReplicaSet 的标识信息。正是通过这一连接，ReplicaSet 知道它所维护的 Pod 集合的状态， 并据此计划其操作行为。
• ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 OwnerReference 或者其OwnerReference 不是一个 控制器，且其匹配到 某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得.
• vim ra.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:

• vim rs.yml 更改replicas: 6
  
• kubectl label pod deployment-6456d7c676-6wf7f app=myapp --overwrite更改其中一个pod的标签为myapp，通过标签匹配，nginx数量不为3，新建标签为nginx的pod。

• vim rs.yml 3个标签为nginx的pod会滚动更新

image: myapp:v2

原rs1回收，新建rs2

• vim rs.yml回滚

image: myapp:v1

• kubectl expose deployment deployment --port=80暴露端口
  
  修改其中某一pod标签
  
  
  kubectl describe svc deployment查看详情
  
  kubectl edit svc deployment修改控制器标签

 selector:
    app: myapp

03_DaemonSet

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet 的一些典型用法：

• 在每个节点上运行集群守护进程
• 在每个节点上运行日志收集守护进程
• 在每个节点上运行监控守护进程

一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。 一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求.

vim daemonset.yml 每个节点一个，会自动分配每个节点一个

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    k8s-app: zabbix-agent
spec:
  selector:
    matchLabels:
      name: zabbix-agent
  template:
    metadata:
      labels:
        name: zabbix-agent
    spec:
      containers:
      - name: zabbix-agent
        image: zabbix-agent

04_Job

Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。 随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。 删除 Job 的操作会清除所创建的全部 Pods。

一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job 对象会启动一个新的 Pod。

• 仅执行一次任务

vim job.yml计算 π 到小数点后 2000 位，并将结果打印出来

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

05_Cronjob基于时间调度

• 基于时间调度的 Job

vim cronjob.yml每分钟打印出当前时间和问候消息

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busyboxplus
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure