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”