kubernetes概念-Pod基本概念

k8s中yaml配置

控制器模板配置

# 创建一个简单的模板
# --dry-run=client(只尝试运行，不实际创建，参数client在kubectl自己测试，参数server提交到k8s API测试)
[root@k8s-master1 ~]# kubectl create deployment web --image=nginx --dry-run=client -o yaml > deployment.yaml
# 编辑生成的文件
[root@k8s-master1 ~]# vim deployment.yaml
# 将不需要的配置去掉，改成如下的配置

效果就是这样

查看他们的标签

service模板配置

# 配置services
[root@k8s-master1 ~]# kubectl expose deployment web2 --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > services.yaml
[root@k8s-master1 ~]# vim services.yaml

删除不需要的

卸载

# 卸载刚刚创建的资源
[root@k8s-master1 ~]# kubectl delete -f deployment.yaml 
deployment.apps "web2" deleted
[root@k8s-master1 ~]# kubectl delete -f services.yaml 
service "web2" deleted

整合

# 可以将这两个整合为一个yaml文件
[root@k8s-master1 ~]# cat deployment.yaml services.yaml > all.yaml
# 但是要注意格式，多个apiVersion之间使用---分割，不然只会创建最后一个apiVersion
# 生成
[root@k8s-master1 ~]# kubectl apply -f all.yaml 
deployment.apps/web2 created
service/web2 created

如果说在yaml文件中有写字段的单词忘记了，可以使用以下命令进行查找

小技巧

# 是可以一层一层 往下寻找
# 查看pods.spec.containers支持那些字段
kubectl explain pods.spec.containers
# 查看deployment支持那些字段
kubectl explain deployment

pod资源了解

部署一个应用涉及最常用的资源有三个(Pod、Deployment、Service)
这节说下Pod的概念

Pod基本概念

Pod的特点

• 一个Pod可以理解为是一个应用实例，提供服务
• Pod中容器始终部署在一个Node上
• Pod中容器共享网络、存储资源

Pod资源共享实现机制

  在一组Pod中正常是可以有多组容器的，那么这些容器中如何进行资源交互的操作呢
  首先拿"日志采集"来说，日志监控可能需要读取容器中的日志文件，但是容器之间是具有隔离性的，那么如何实现这种方式呢，可以通过"Volume"(共享存储)，将文件或目录通过数据卷共享数据的方式解决
  那么"服务监控"呢，可能需要调用一些服务接口，来进行监控，但是首先容器具有隔离性，我可以通过指定IP的方式进行接口的对接，但是如果容器重构呢？IP变化了难道需要从新修改么，这里面引用了Infra这个容器(这个容器通过kubectl get …是没有体现的)，他就是这个Pod中独立的网络命名空间，而该Pod内的其他容器使用类似于docker中"–net=host"的方式，与该容器进行关联，也就是说，我采集业务容器的监控容器不需要在指定固定的IP了，直接通过本地循环+端口的形式来调取业务容器的IP(因为他们在同一个网络中，想想docker的–net=host模式)

Pod小实例

先来了解下Pod的基本使用命令
注：因为Pod中是有多个容器的，-c这个参数可以指定要查看或者进入的容器名称，例如有两个容器名称为web和nginx，我要进入nginx这个使用如下命令：
kubectl exec <Pod名称> -c nginx – bash

含义	命令
创建Pod	kubectl apply -f pod.yaml 或 kubectl run nginx --image=nginx
查看Pod	kubectl get pods
查看详情	kubectl describe pod <Pod名称>
查看日志	kubectl logs <Pod名称> [-c CONTAINER] (可以加上 “-f” 进行实时输出)
进入容器终端	kubectl exec -it <Pod名称> [-c CONTAINER] – bash
删除Pod	kubectl delete pod <Pod名称>

# 我们通过Pod的一个实例来验证下上面的解释
# 先生成一个yaml
[root@k8s-master1 ~]# kubectl run web3 --image=nginx --dry-run=client -o yaml > Pod.yaml

pod-test就是我创建的Pod，可以看到其中有两个容器

登录进去看看，来验证是否共用网络和路径是否挂载

# 现在nginx容器中创建一个index.html文件(因为我的nginx中没有默认页面)
[root@k8s-master1 ~]# kubectl exec -it pod-test -c web -- bash
root@pod-test:/# cd /usr/share/nginx/html/
root@pod-test:/usr/share/nginx/html# echo "aaa" > index.html
# 创建完成后去bs容器中wget下载这个页面，并查看(busybox没有bash，所以使用sh登录)
[root@k8s-master1 ~]# kubectl exec -it pod-test -c bs -- sh
/ # wget 127.0.0.1
/ # cat index.html 
# 可以看到是我刚刚创建的文件内容(这一点说明虽然是两个容器，但是他们共用着一个网络)
aaa
# 还可以通过netstat来查看
/ # netstat -antp
# 可以看出bs这个容器本地也是在监听80端口的，更一步证实了网络是共用的
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -
tcp        0      0 :::80                   :::*                    LISTEN      -

重启策略+健康检查

重启策略

参数	含义
Always	当容器终止退出后，总是重启容器，默认策略
OnFailure	当容器异常退出(退出状态码非0)时，才重启容器
Never	当容器终止退出，从不重启容器

健康检查类型

参数	含义
livenessProbe(存活检查)	如果检查失败，将杀死容器，根据pod的restartPolicy来操作
readinessProbe(就绪检查)	如果检查失败，kubernetes会把Pod从service endpoints中剔除
startupProbe(启动检查)	检查成功才由存活检查接手，用于保护慢启动容器

支持检查的方法

参数	含义
httpGet	发送HTTP请求，返回200-400范围状态码为成功
exec	执行Shell命令返回状态码是0为成功
tcpSocket	发起TCP Socket建立成功

健康检查小案例

创建基本模板

先创建pod，编写好模板后apply生成即可

创建service模板，用来负载创建好的三个pod

验证

咱们从pod日志，ep状态，pod状态等方面来查看它实现的情况如何

分别实时输出这几个指标的情况


pod日志

开始模拟某个pod挂掉

首先就可以看到pod日志已经抛出403后退出(退出是因为重启策略生效了，Pod重建了，相当于重新部署了)

环境变量

[root@k8s-master1 ~]# vim pod-env.yaml

这段内容是我在官网上荡下来改了下，地址

# 进入容器中进行验证(在yaml文件中设置的env变量都有体现出来)
[root@k8s-master1 ~]# kubectl exec -it pod-env -- sh
/ # env | grep MY
MY_POD_SERVICE_ACCOUNT=default
MY_POD_NAMESPACE=default
MY_POD_IP=10.244.169.159
MY_NODE_NAME=k8s-node2
MY_POD_NAME=pod-env
/ # echo $ABC
123456

Init Container(初始化容器)

Init Container： 顾名思义，用于初始化工作，执行完就结束，可以理解为一次性任务

• 支持大部分应用容器配置，但不支持健康检查
• 优先应用容器执行

应用场景

• 环境检查： 例如确保应用容器依赖的服务启动后在启动应用容器
• 初始化配置：例如给应用容器准备配置文件

.这个初始化容器就可pod的辅助容器似的，在一个Pod中在启动一个容器用来辅助主业务
比如说业务容器需要引用一个文件或目录，可以通过init container容器来辅助实现(结合数据卷)

案例

部署一个web网站，网站程序没有打到镜像中，而是希望从代码仓库中动态拉取放到应用容器中(仅做参考用，实际环境不建议)

可以使用下面这个模板，或者使用官方提供的模板，在搜索中搜索initcontainer，地址如下地址，点开第一个即可

这个就表示在运行初始化容器，当初始化容器结束后，就会运行主业务的容器，并且他会退出，类似于一次任务，所以会看到和pod-test这个不通，他有两个容器一直在运行着
容器运行后可以正常访问下，会发现页面时百度的页面

注意，因为这个是一次性的，所以像健康检查什么的是不可以使用的

通过上述，我们知道了两种Pod的类型，initContainers和Containers
而还有一种容器，叫做"Infrastructure Container"，这个呢是一个基础容器，你可以随便找一台k8s节点，使用这条命令查看下"docker ps | grep pause"，这些都是up状态，这个在部署应用的时候根本就没有使用它，这个镜像就是"Infrastructure Container"启的镜像，它维护了一个网络的名命空间，好让其他网络加入进来，这个咱是不进行操作的

Pod中支持的几种类型容器我在总结下

Pod支持类型	含义
Infrastructure Container	基础容器，维护整个Pod网络空间
InitContainers	初始化容器，先于业务容器开始执行
Containers	业务容器，并行运行