Kubernetes(K8S)之学废了（五）:Pod详解

Pod详解

---

一、Pod介绍？

pod结构

每个pod种可以有一个或多个容器，这些容器可分为两类:

• 用户程序所在的容器，数量可多可少
• Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：
  1.可以以它为依据，评估整个Pod的健康状态 。
  2.可以在根容器上设置/p地址，其它容器都共享来此ID(Pod IP)，以实现Pod内部的网路通信,这里是Pod内部的通讯;Pod之间的通讯采用虚拟二层网络技术来实现，我们目前环境用的是FLannel

Pod的定义

下面是pod 的资源清单，也就是yaml配置文件

#小提示： 在这里，可通过一个命令来查看每种资源的可配置项：
kubectl explain 资源类型 查看某种资源可以配置的一级属性
kubectl explain 资源类型 •属性 查看属性的子属性

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

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

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

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

二、Pod配置

主要来研究 pod.spec.containers 属性，这也是pod配置中最为关健的一项配置

kubectl explain pod.spec.containers

基本配置

创建pod-base.yml,定义了一个简单的pod配置，里面有两个容器，nginx是一个轻量级web容器，busybox是一个小巧的linux命令集合

apiVersion: v1 
kind: Pod 
metadata: 
	name: pod-base 
	namespace: dev1 
	labels: 
		user: heima 
spec: 
	containers: 
	- name: nginx 
	  image: nginx:1.17.1
	  imagePullPolicy: IfNotPresent
	- name: busybox 
	  image: busybox:1.30

#创建pod
kubectl apply -f pod-base.yml
#查看pod状况
#  READY 1/2 代表pod中有两个容器，一个已经准备就绪，另一个未就绪
# RESTART 代表重启次数，一个容器故障，pod尝试重启它
kubectl get pod -n dev
[root@k8s-master ~]# kubectl get pod pod-base -n testing
NAME       READY   STATUS              RESTARTS   AGE
pod-base   1/2     ContainerCreating   0          31s

# 通过describe 查看pod详细信息 可以看到有容器启动失败，这是因为留了一个坑
kubectl describe pod pod-base -n dev

镜像拉取imagePullPolicy

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

•   Always：总是从远程仓库拉取镜像（一直远程下载）
•  fNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像（本地有就本地 本地没有就远程下 载）
•  Never：只使用本地镜像，从不去远程仓库拉取，本地没有就报错 （一直使用本地）

默认值说明：

如果镜像tag为具体版本号，默认策略是：IfNotPresent 如果镜像tag为：latest（最終版本） ，默认策略是always

启动命令command

在前面的案例中，一直有一个问题没有解决，就是的busybox容品一直没有成功运行，那么到底是什么原因导 致这个容器的故障呢？
原来busybox并不是一个程序，而是类似于一个工具类的集合，kubernetes集群启动管理后，它会自动关闭。
解決方法就是让其一直在运行，这就用到了command配置，

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

apiVersion: v1 
kind: Pod 
metadata: 
	name: pod-command 
	namespace: dev 
spec: 
	containers: 
	- name: nginx 
	  image: nginx:1.17.1 
	- name: busybox 
	  image: busybox:1.30 
	command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo S(date +3T) >> /tmp/hello.txt; sleep 3; done;"] 

command，用于在pod中的容器初始化完毕之后运行一个命令。 稍微解释下上面命令的意思

“/bin/sh”,”-c"， 使用sh执行命令
touch /tmp/hello.txt; 创建一个/tmp/hello.txt文件
while true;do /bin/echo $(date +%7) >>/tmp/hello.txt; sleep 3;done; 每隔3秒向文件 写入当前时间

进入pod中某容器内，可以看

kubectl exec [pod名称] -n [命名空间] -it -c [容器名] /bin/bash 
# kubectl exec pod-command -n dev -it -c busybox /bin/sh
# tail -f /tmp/hello.txt

特别说明：
通过上面发现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参数

环境变量ENV（了解）

以此创建出来的pod，就有了环境变量，进入容器可以看到环境变量的内容

但这中方法不推荐，后面会讲到使用文件去配置

端口设置containerPort

# 查看端口的配置
kubectl explain pod.spec.containers.ports

KIND: Pod
VERSION: v1
RESOURCE: ports <[]0bject>
FIELDS:
    name <string>   ＃端口名称，如果指定，必须保证name在pod中是唯一的
    containerPort<integer>   #容器要监听的端口(0<x<65536)
    hostPort <intege>   # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本（一般省略）
    hostIP <string>   ＃要将外部端口鄉定到的主机IP（一般省略）
    protocol <string>   ＃端口协议。必须是UDP、TCP或SCTP。默认为“TCP”