pod 的简介

Pod是Kubernetes应用程序的最基本执行单元—是你创建或部署Kubernetes对象模型中的最小和最简单的单元。 Pod表示在集群上运行的进程。Pod封装了应用程序的容器（或者在某些情况下是多个容器）、存储资源、唯一的网络标识(IP地址)以及控制容器应该如何运行的选项。 Pod表示一个部署单元：Kubernetes中的应用程序的单个实例，该实例可能由单个容器或少量紧密耦合并共享资源的容器组成。Docker是Kubernetes Pod中最常见的容器，但Pods也支持其他容器。Kubernetes集群中的Pod是如何管理容器的：

1）pod里运行单个容器： pod里只运行一个容器是最常见的Kubernetes使用案例。在这种情况下，你可以将Pod视为单个容器的封装，Kubernetes直接管理Pod，而不是直接管理容器。

2）pod里运行多个需要协同工作的容器：Pod可能封装了一个应用程序，该应用程序由紧密关联并且需要共享资源的多个共同协作的容器组成。这些共同协作的容器可能形成一个统一的服务单元-一个容器将文件从共享卷提供给所有容器使用，而一个单独的“ sidecar”容器则刷新或更新这些文件。Pod将这些容器和存储资源包装在一起，成为一个可管理的实体。

pod是管理多个容器的逻辑

Pod中可以同时运行多个容器。同一个Pod中的容器会自动的分配到同一个 node 上。同一个Pod中的容器共享资源、网络环境，它们总是被同时调度，在一个Pod中同时运行多个容器是一种比较高级的用法，只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个“sidecar”容器来从远端获取资源更新这些文件

一些Pods有init容器和应用容器。 在应用程序容器启动之前，运行初始化容器。Pods为它组成的容器提供两种共享资源：网络和存储。

网络：

每个pod都被分配唯一的IP地址，POD中的每个容器共享网络名称空间，包括IP地址和网络端口。 Pod内部的容器可以使用localhost相互通信。 当POD中的容器与POD之外的实体通信时，它们必须使用共享网络资源（如端口）。

 存储：

Pod可以指定一组共享存储卷。 POD中的所有容器都可以访问共享卷，允许这些容器共享数据。 卷也允许Pod中的持久数据在需要重新启动的情况下存活。 有关Kubernetes如何在POD中实现共享存储的更多信息，可参考https://kubernetes.io/docs/concepts/storage/volumes/

 pod 的工作逻辑

很少在Kubernetes中直接创建单个Pod。这是因为Pods被设计成相对短暂的、一次性的实体。 当一个POD被创建（直接创建，或间接由控制器创建）时，它被安排在集群中的节点上运行。 在进程终止、pod对象被删除、pod由于缺乏资源而被驱逐或节点失败之前，POD仍然位于该节点上

注意：不要将重新启动Pod中的容器与重新启动Pod混淆。POD不是一个进程，而是一个运行容器的环境。Pod一直存在直到被删除为止。

pod本身无法自我修复。如果将Pod调度到发生故障的节点，或者调度操作本身失败，则将Pod删除；同样，由于缺乏资源或Node维护，Pod也被删除。Kubernetes使用称为控制器的更高级别的抽象来处理管理相对一次性的Pod实例的工作。因此，虽然可以直接使用Pod，但在Kubernetes中使用控制器来管理Pod更为常见。

 pod 与控制器的关系

可以使控制器创建和管理多个pod。控制器在pod失败的情况下可以处理副本、更新以及自动修复。例如，如果某个节点发生故障，则控制器会注意到该节点上的Pod已停止工作，并创建了一个替换Pod。调度程序将替换的Pod放置到健康的节点上。可以使用deployment、statefulset、daemonset等控制器管理pod。

使用pod

Pod 可以用于托管垂直集成的应用程序栈（例如，LAMP），但最主要的目的是支持位于同一位置的、共同管理的程序，例如：

1.内容管理系统、文件和数据加载器、本地缓存管理器等。

2.日志和检查点备份、压缩、旋转、快照等。

3.数据更改监视器、日志跟踪器、日志和监视适配器、事件发布器等。

4.代理、桥接器和适配器

5.控制器、管理器、配置器和更新器

 通常，不会用单个 Pod 来运行同一应用程序的多个实例。

pod模板

控制器（如deployment、daemonset、statefulset等）是通过创建pod模板来创建和管理pod的，PodTemplate是用于创建pod的规范，并且包含在deployment、job和daemonset中。每个控制器使用自己内部的Pod模板来创建实际的Pod。PodTemplate是运行应用程序所需的任何控制器的一部分。下面的示例是一个简单的Job的清单，包含一个podtemplate，这个是用来生成pod的模板。该Pod中的容器会打印一条消息，然后暂停。

 

cat job-template.yaml

 

apiVersion: batch/v1

kind: Job

metadata:

  name: hello

spec:

  template:

    # This is the pod template

    spec:

      containers:

      - name: hello

        image: busybox

        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']

      restartPolicy: OnFailure

    # The pod template ends here

　　

修改pod template或切换到新的pod tmplate对已经存在的pod没有影响。 POD不直接接收模板更新,而是创建一个新的POD来匹配修改后的POD模板。例如，控制器可确保正在运行的Pod与当前Pod模板匹配。如果模板已更新，则控制器必须删除现有的Pod并根据更新的模板创建新的Pod。每个控制器都实现自己的规则来处理Pod模板的更改。在节点上，kubelet不直接观察或管理有关Pod模板和更新的任何详细信息。

和pod相关的api对象

kubectl explain pods

上面命令可以看到和pod相关的api对象有哪些，也就是通过资源清单yaml部署一个pod时需要哪些字段

apiVersion

apiVersion定义了此对象表示的版本化模式。服务器应将已识别的模式转换为最新的内部值，并可能拒绝无法识别的值。更多信息参考：

https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

查看k8s集群支持的apiVersion有哪些，可以使用下面的命令：

kubectl api-versions

显示如下支持apiVersion信息：
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
crd.projectcalico.org/v1
discovery.k8s.io/v1beta1
events.k8s.io/v1beta1
extensions/v1beta1
metrics.k8s.io/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1beta1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1

　　查看pod的帮助

[root@master-1 ~]# kubectl explain pods
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind	<string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata	<Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec	<Object>
     Specification of the desired behavior of the pod. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

   status	<Object>
     Most recently observed status of the pod. This data may not be up to date.
     Populated by the system. Read-only. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

　　

kind

Kind是表示此对象表示的REST资源的字符串值。服务器可以从客户端提交请求的端点推断出这一点，说白了就是表示我们要创建什么资源，如deployment、statefulset、pod、service、ingress

查看更详细信息可参考：

https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

metadata

标准对象的元数据。更多信息：

https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

 spec

指定容器的所需行为。更多信息：

https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

status

最近观察到的pod的状态。此数据可能不是最新的。Status不需要在pod或者其他资源中定义，这个默认是存在的，更多信息：https：//git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status

编写pod的yaml

[root@master-1 ~]# cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:  
  annotations:  #注释信息
    dev: chenxi 
  name: chenxi-dev #pod名称
  namespace: default # 名称空间
  labels:      #标签
    dev: chenxi   #标签key与值
spec: # 期望状态
  containers: #定义容器对象列表
  - name: chenxi #容器名字
    image: tomcat:8.5-jre8-alpine #定义容器镜像与版本
    imagePullPolicy: IfNotPresent # 镜像拉取策略 

　　更新创建此pod

[root@master-1 ~]# kubectl apply -f pod.yaml 
[root@master-1 ~]# kubectl get pod
NAME         READY   STATUS    RESTARTS   AGE
chenxi-dev   1/1     Running   0          3m9s
demo-pod     2/2     Running   48         2d

　　查看此pod 的详细信息

[root@master-1 ~]# kubectl describe pods chenxi-dev
Name:         chenxi-dev
Namespace:    default
Priority:     0
Node:         node-1/192.168.10.32
Start Time:   Sun, 14 Aug 2022 09:51:12 +0800
Labels:       dev=chenxi
Annotations:  cni.projectcalico.org/podIP: 172.16.84.134/32
              cni.projectcalico.org/podIPs: 172.16.84.134/32
              dev: chenxi
Status:       Running
IP:           172.16.84.134
IPs:
  IP:  172.16.84.134
Containers:
  chenxi:
    Container ID:   docker://ef427655b5c259281e4c759dc5eaa011b8d1f95c19c14c33bc91cd130339df1e
    Image:          tomcat:8.5-jre8-alpine
    Image ID:       docker-pullable://tomcat@sha256:04feaf74f8bb54b43ea136b150bbc7b58e8a3062aead67ab871f2dbbd5dac5d1
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Sun, 14 Aug 2022 09:51:15 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-xmj6q (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-xmj6q:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-xmj6q
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  4m59s  default-scheduler  Successfully assigned default/chenxi-dev to node-1
  Normal  Pulled     4m56s  kubelet            Container image "tomcat:8.5-jre8-alpine" already present on machine
  Normal  Created    4m56s  kubelet            Created container chenxi
  Normal  Started    4m56s  kubelet            Started container chenxi
您在 /var/spool/mail/root 中有新邮件

　　查看默认名称空间pods的详细调度信息

[root@master-1 ~]# kubectl get pods -o wide
NAME         READY   STATUS    RESTARTS   AGE    IP              NODE     NOMINATED NODE   READINESS GATES
chenxi-dev   1/1     Running   0          19m    172.16.84.134   node-1   <none>           <none>
demo-pod     2/2     Running   48         2d1h   172.16.84.132   node-1   <none>           <none>

　　查看已有名称空间

[root@master-1 ~]# kubectl get ns
NAME              STATUS   AGE
default           Active   2d14h
kube-node-lease   Active   2d14h
kube-public       Active   2d14h
kube-system       Active   2d14h

　　查看指定名称空间pod 的调度信息

[root@master-1 ~]# kubectl get pods -n kube-system -o wide
NAME                                       READY   STATUS    RESTARTS   AGE     IP              NODE     NOMINATED NODE   READINESS GATES
calico-kube-controllers-6949477b58-2mfdh   1/1     Running   1          2d13h   172.16.84.130   node-1   <none>           <none>
calico-node-tlb6d                          1/1     Running   1          2d13h   192.168.10.32   node-1   <none>           <none>
coredns-7bf4bd64bd-9fqkz                   1/1     Running   0          2d1h    172.16.84.131   node-1   <none>           <none>

　　查看指定名称空间某个pod 的调度信息

[root@master-1 ~]# kubectl get pod -n kube-system calico-node-tlb6d -o wide
NAME                READY   STATUS    RESTARTS   AGE     IP              NODE     NOMINATED NODE   READINESS GATES
calico-node-tlb6d   1/1     Running   1          2d13h   192.168.10.32   node-1   <none>           <none>

　　查看pod 的日志信息

# 从 pod nginx 返回快照日志，只有一个容器
kubectl logs nginx

# 从多容器的 pod nginx 中返回快照日志
kubectl logs nginx --all-containers=true

# 从标签 app=nginx 定义的 pod 中的所有容器返回快照日志
kubectl logs -lapp=nginx --all-containers=true

# 从 pod web-1 返回先前终止的 ruby​​ 容器日志的快照
kubectl logs -p -c ruby​​ web-1

# 开始在 pod web-1 中流式传输 ruby​​ 容器的日志
kubectl logs -f -c ruby​​ web-1

# 开始从标签 app=nginx 定义的 pod 中的所有容器流式传输日志
kubectl logs -f -lapp=nginx --all-containers=true

# 仅显示 pod nginx 中最近的 20 行输出
kubectl logs --tail=20 nginx

# 显示最近一小时内来自 pod nginx 的所有日志
kubectl logs --since=1h nginx

# 显示来自具有过期服务证书的 kubelet 的日志
kubectl logs --insecure-skip-tls-verify-backend nginx

# 从名为 hello 的job的第一个容器返回快照日志
kubectl logs job/hello

# 从名为 nginx 的部署的容器 nginx-1 返回快照日志
kubectl  logs deployment/nginx -c nginx-1

[root@master-1 ~]# kubectl logs -f -n kube-system calico-node-tlb6d   #持续输出格式的显示日志 tail -f 命令输出一样

Examples:
  # Return snapshot logs from pod nginx with only one container
  kubectl logs nginx
  
  # Return snapshot logs from pod nginx with multi containers
  kubectl logs nginx --all-containers=true
  
  # Return snapshot logs from all containers in pods defined by label app=nginx
  kubectl logs -lapp=nginx --all-containers=true
  
  # Return snapshot of previous terminated ruby container logs from pod web-1
  kubectl logs -p -c ruby web-1
  
  # Begin streaming the logs of the ruby container in pod web-1
  kubectl logs -f -c ruby web-1
  
  # Begin streaming the logs from all containers in pods defined by label app=nginx
  kubectl logs -f -lapp=nginx --all-containers=true
  
  # Display only the most recent 20 lines of output in pod nginx
  kubectl logs --tail=20 nginx
  
  # Show all logs from pod nginx written in the last hour
  kubectl logs --since=1h nginx
  
  # Show logs from a kubelet with an expired serving certificate
  kubectl logs --insecure-skip-tls-verify-backend nginx
  
  # Return snapshot logs from first container of a job named hello
  kubectl logs job/hello
  
  # Return snapshot logs from container nginx-1 of a deployment named nginx
  kubectl logs deployment/nginx -c nginx-1

　　进入容器

[root@master-1 ~]# kubectl exec --help
在容器中执行命令。

例子：
# 从 pod mypod 运行 'date' 命令获取输出，默认使用第一个容器
kubectl exec mypod -- date

# 从 pod mypod 的 ruby​​-container 中运行 'date' 命令获取输出
kubectl exec mypod -c ruby​​-container -- date

# 切换到原始终端模式，将标准输入从 pod mypod 发送到 ruby​​-container 中的 'bash'

# 并将 stdout/stderr 从 'bash' 发送回客户端
kubectl exec mypod -c ruby​​-container -i -t -- bash -il

# 从pod mypod的第一个容器中列出/usr的内容，并按修改时间排序。
# 如果你想在 pod 中执行的命令有任何共同的标志（例如 -i），
# 您必须使用两个破折号 (--) 来分隔命令的标志/参数。
# 另请注意，不要用引号将您的命令及其标志/参数括起来
# 除非这是你正常执行的方式（即，执行 ls -t /usr，而不是“ls -t /usr”）。
kubectl exec mypod -i -t -- ls -t /usr

# 使用第一个容器从部署 mydeployment 的第一个 pod 中运行 'date' 命令获取输出
默认
kubectl exec deploy/mydeployment -- 日期

# 从服务 myservice 的第一个 pod 运行 'date' 命令获取输出，使用第一个容器
默认
kubectl exec svc/myservice -- 日期

选项：
-c, --container=''：容器名称。如果省略，将选择 pod 中的第一个容器
-f, --filename=[]：用于执行到资源中
--pod-running-timeout=1m0s：等待至少一个的时间长度（如5s、2m或3h，大于零）
吊舱正在运行
-i, --stdin=false：将标准输入传递给容器
-t, --tty=false：标准输入是一个 TTY

用法：
kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- 命令 [args...] [options]

[root@master-1 ~]# kubectl exec chenxi-dev -i -t -- ls -t /usr
bin      lib      libexec  sbin     share    local
[root@master-1 ~]# kubectl exec chenxi-dev -i -t -- ls -t /usr^C
[root@master-1 ~]# kubectl exec chenxi-dev -c chenxi -i -t -- bash -il
chenxi-dev:/usr/local/tomcat#