前面讲了如何使用k8s以及对应的k8s的集群如何搭建,对相应的组件的使用也是慢慢了解了,例如pod,deployment等。但是只是使用还不够,本文主要是针对k8s常用的组件进行进阶介绍。
1、Pod进阶
1.1、生命周期(Lifecycle)
官网:https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Pod的生命周期分为五种状态:挂起、运行中、成功、失败、未知状态,平时运行apply命令创建pod以后通过kubectl get pods -o wide可以看到创建的pod到哪个生命周期了。
挂起(Pending): Pod已经被Kubernetes系统接受,但有一个或者多个镜像尚未创建。可能会等待的时间分为两个部分,一个是调度Pod的时间,另一个是通过网络下载镜像的时间,可提前下载好需要的镜像减少等待的时间;
运行中(Running): 该Pod已经绑定到了一个节点上,Pod中所有的容器都已经被创建,至少有一个容器正在运行,或者正在处于启动或重启状态;
成功(Succeeded): Pod中所有的容器都被成功终止,并且不会再重启;
失败(Failed): Pod中的所有容器都已经终止,并且最少有一个容器因为失败终止,也就是说容器以非0的状态退出或者被系统终止;
未知(Unknown): 因为某些原因无法取得Pod的状态,通常是因为与Pod所在主机通信失败。
1.2、重启策略
官网:https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy

Pod的重启策略有三种,但是重启策略只适用于同一节点的容器。
Always: 容器失效时立即重启;
OnFailure: 容器终止运行且退出码不为0时重启;
Never: 永远不重启。
1.3、静态Pod
静态Pod是由kubelet进行管理的,并且存在于特定的Node上。
不能通过API Server进行管理,无法与ReplicationController、Deployment、DaemonSet进行关联,也无法进行健康检查。
1.4、健康检查
官网:https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

通过官网我们可以看到健康检查的方式有三种,检查的结果也是三种,检查结果分为通过检查,检查失败和未知情况(不做任何处理)。
livenessProbe: 判断容器是否存活;如果检查结果失败,则kubelet会杀死所有容器,容器是否重启依赖于其重启策略。如果容器没有提供该探针,则默认为通过检查。
readinessProbe: 判断容器是否能够响应请求;如果检查结果为失败,则将Pod从所有与之匹配的节点中删除。第一次延迟响应之前的检查结果默认为失败,如果容器没有提供该探针,则默认为通过检查。
startupProbe: 判断容器是否启动;如果容器提供了该探针,那么其他探针失败直到该探针的检查结果通过才能继续使用。如果检查结果失败,则kubelet会杀死所有容器,容器是否重启依赖于其重启策略。如果容器没有提供该探针,则默认为通过检查。
1.5、ConfigMap
官网 :https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

ConfigMap说白了就是用来保存配置数据的键值对,也可以保存单个属性,也可以保存配置文件。所有的配置内容都存储在etcd中,创建的数据可以供Pod使用。
1.5.1、如何创建ConfigMap
1.5.1.1、命令行创建
创建一个名称为my-config的configMap,key值是port,value值是’3306’,可以直接使用以下命令:
kubectl create configmap my-config --from-literal=port='3306'
查看该ConfigMap:kubectl get configmap
获取该ConfigMap的yml文件详细信息:kubectl get configmap myconfig -o yaml
1.5.1.2、从配置文件中创建
创建一个文件,名称为my-config.propertie,然后在里面加上port=3306 name = mysql
然后再运行以下命令将该配置文件变成ConfigMap:
kubectl create configmap app --from-file=./my-config.properties
查看命令跟上面一样
1.5.1.3、从目录中创建
创建一层层文件夹,然后再运行命令创建:
mkdir config
cd config
mkdir a
mkdir b
cd ..
kubectl create configmap config --from-file=config/
1.5.1.4、通过yml文件创建
创建一个ConfigMaps.yml文件,可以在里面创建多个ConfigMap,不同的ConfigMap存储的数据不一样,下面yml中data就是每个ConfigMap存储的数据键值对。
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
---
apiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFO
kubectl apply -f ConfigMaps.yml
1.5.2、Pod中ConfigMap的使用
注意: (1)ConfigMap必须在Pod使用它之前创建;(2)Pod只能使用同一个命名空间下的ConfigMap;
1.5.2.1、通过环境变量使用
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: busybox
command: [ "/bin/sh", "-c", "env" ]
env:# Define the environment variable
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config #匹配ConfigMap的name
key: special.how #匹配ConfigMap的data中的key
restartPolicy: Never
可以运行kubectl logs pod-name命令查看打印出来的数据
1.5.2.2、用作命令行参数
在命令行下引用时,需要先设置为环境变量,之后可以用过$(VAR_NAME)设置容器启动命令的启动参数
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod2
spec:
containers:
- name: test-container
image: busybox
command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY)" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config #匹配ConfigMap的name
key: special.how #匹配ConfigMap的data中的key
restartPolicy: Never
运行kubectl logs pod-name命令查看打印出来的数据
1.5.2.3、作为volume挂载使用
将创建的ConfigMap直接挂载到Pod的/etc/config目录下,其中每一个key-value键值对都会生成一个文件,key为文件名,value为内容。
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap2
spec:
containers:
- name: test-container
image: busybox
command: [ "/bin/sh", "-c", "ls /etc/config/" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config
restartPolicy: Never
创建pod:kubectl apply -f pod-myconfigmap-v2.yml
进入Pod:kubectl exec -it pod-name bash
查看运行日志:kubectl logs pod-name
1.5.3、ConfigMap在IngressController中的使用
前面将的IngressController还记得吧(Kubernetes的核心详解),我使用了Ingress Nginx Controller,从官网下载了Ingress Nginx Controller创建需要的yml文件,文件中有很多configMap。如下:

然后我们继续看,能看到Ingress Nginx Controller的Deployment使用名字为ingress-nginx-controller的configMap来作为配置文件,也就是上图我们截图的那个ConfigMap。

其实通过Ingress Nginx Controller的讲解,我们知道Ingress Nginx Controller其实核心就是一个nginx,其肯定也有对应的配置文件/etc/nginx/nginx.conf。如果我们要修改配置文件,之前的方法是直接改配置文件,但是现在既然用了Co

最低0.47元/天 解锁文章
3503





