@kubernetes（k8s）的kubectl的使用及资源类型pod生命周期与资源清单详解
kubernetes
一、kubernetes kubectl的使用
1、kubectl 的概述:
kubectl是一个用于操作kubernetes集群的命令行接口，通过利用kubectl的各种命令可以实现各种功能
kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署
2、kubectl的使用
kubectl命令行语法格式： kubectl [command] [type] [name] [flags]
#kubectl使用的参数的说明：
command： #子命令，用于管理和操作Kubernetes集群资源对象的命令，例如：create、delete、describe、get、apply等
type： #资源对象的类型，比如：deployment、pod、service区分大小写，能以单数形式、复数形式或者简写形式表示，如下：
kubectl get pod pod1 #单数形式
kubectl get pods pod1 #复数形式
kubectl get po pod1 #简写形式
name： #资源对象的名称，区分大小写，如果不指定名称，则系统返回属于type的全部对象的列表。
flags： #kubectl子命令的可选参数，例如使用“-s”指定apiserver的URL地址而不用默认值
2、kubectl可操作的资源对象类型
3、kubectl子命令
kuberctl的子命令非常丰富，包括资源对象的创建、删除、查看、修改、配置、运行等
4、kubectl相关参数
kubectl命令行的公共启动参数
5、kubectl输出格式
kubectl命令可以用多种格式对结果进行显示，输出的格式通过-o参数指定：
kubectl [command] [TYPE] [NAME] -o=<output_format>
【kubectl yaml快速生成】
#使用craet命令生成yaml文件（--dry-run ：表示不指定运行）
[root@m01 ~]# kubectl create deployment hzl --image=nginx -o yaml --dry-run > hzl.yaml
W0809 09:55:16.848283 4794 helpers.go:557] --dry-run is deprecated and can be replaced with --dry-run=client.
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: hzl
name: hzl
spec:
replicas: 1
selector:
matchLabels:
app: hzl
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: hzl
spec:
containers:
- image: nginx
name: nginx
resources: {}
status: {}
#
【kubectl常用命令的输出格式】
1）#显示Pod的更多信息
格式：
kubectl get pod <pod-name> -o wide
示列：
[root@m01 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-6799fc88d8-pp4lk 1/1 Running 1 45h
test 1/1 Running 1 2d2h
[root@m01 ~]# kubectl get pod test -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test 1/1 Running 1 2d2h 10.244.1.5 nod01 <none> <none>
2）#以yaml格式显示Pod的详细信息
格式：
kubectl get pod <pod-name> -o yaml
示列：
[root@m01 ~]# kubectl get pod test -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2021-08-01T08:16:50Z"
labels:
run: test
name: test
namespace: default
resourceVersion: "114598"
uid: 345d3f7c-60f2-4d35-94fb-2ef15990717e
........
.....
3）#以自定义列名显示Pod的信息
格式：
kubectl get pod <pod-name> -o=custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
示列：
[root@m01 ~]# kubectl get pod test -o=custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
NAME RSRC
test 114598
4）#基于文件的自定义列名输出（与上面类似）
格式：
kubectl get pods <pod-name> -o=custom-columns-file=template.txt
示列：
template.txt文件的内容为：
NAME RSRC
metadata.name metadata.resourceVersion
输出结果为：
NAME RSRC
Pod-name 52305
【kubectl使用的常用操作示列】
1）#根据yaml配置文件一次性创建service和rc（多个同时创建）
[root@m01 ~]# kubectl create -f my-service.yaml -f my-rc.yaml
2）#根据<directory>目录下所有.yaml、.yml、.json文件的定义进行创建操作（同时创建不同属性的）
[root@m01 ~]# kubectl create -f <directory>
3）#查看所有Pod列表（显示所有pod列表）
[root@m01 ~]# kubectl get pods
4）#查看rc和service列表
[root@m01 ~]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d3h
nginx NodePort 10.101.203.98 <none> 80:30779/TCP 45h
redis NodePort 10.105.17.154 <none> 3307:30399/TCP 40h
[root@m01 ~]# kubectl get rc,service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d3h
service/nginx NodePort 10.101.203.98 <none> 80:30779/TCP 45h
service/redis NodePort 10.105.17.154 <none> 3307:30399/TCP 40h
5）#显示Node的详细信息
格式：
kubectl describe nodes <node-name>
示列：
[root@m01 ~]# kubectl describe nodes nod01
Name: nod01
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
...........
......
6）#显示Pod的详细信息
格式：
kubectl describe pods/<pod-name>
示列：
[root@m01 ~]# kubectl describe pods test
Name: test
Namespace: default
Priority: 0
Node: nod01/192.168.15.56
Start Time: Sun, 01 Aug 2021 16:16:50 +0800
Labels: run=test
.........
......
7）#显示由RC管理的Pod信息（显示详细信息，与上一个一样）
格式：
kubectl describe pods <rc-name>
8）#删除基于pod.yaml文件定义的Pod（指定定义文件进行删除，永久删除pod）
[root@m01 ~]#kubectl delete -f pod.yaml
9）#删除所有包含某个label的Pod和Service
格式：
kubectl delete pods,services -l name=<label-name>
10）#删除所有Pod（清空pod）
[root@m01 ~]# kubectl delete pods --all
11）#在Pod的容器里执行date命令，默认使用Pod中的第1个容器执行
格式：
kubectl exec <pod-name> date
12）#指定Pod中某个容器执行date命令
格式：
kubectl exec <pod-name> -c <container-name> date
示列：
[root@m01 ~]# kubectl exec nginx-6799fc88d8-pp4lk -c nginx date
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
Tue Aug 3 11:36:42 UTC 2021
13）#以bash方式登陆到Pod中的某个容器里
格式：
kubectl exec -it <pod-name> -c <container-name> /bin/bash
示列：
[root@m01 ~]# kubectl exec -it nginx-6799fc88d8-pp4lk -c nginx bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@nginx-6799fc88d8-pp4lk:/# exit
command terminated with exit code 130
14）#查看容器输出到stdout的日志（pod的综合日志）
格式：
kubectl logs <pod-name>
示列：
[root@m01 ~]# kubectl logs nginx-6799fc88d8-pp4lk
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
........
...
15）#跟踪查看容器的日志，相当于tail -f命令的结果（svc的局部日志）
格式：
kubectl logs -f <pod-name> -c <container-name>
示列：
[root@m01 ~]# kubectl logs -f nginx-6799fc88d8-pp4lk -c nginx #实时监控日志
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
.........
...
16）#查看命名空间
[root@m01 ~]# kubectl get namespace
NAME STATUS AGE
default Active 2d4h
kube-node-lease Active 2d4h
kube-public Active 2d4h
kube-system Active 2d4h
二、命名空间(namespace)
Namespace是kubernetes系统中的一种非常重要资源，它的主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离
Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。 这些虚拟集群被称为命名空间
1、查看命名空间
查看集群中的命名空间：namespaces=ns
指定输出格式 命令：kubectl get ns ns名称 -o 格式参数
kubernetes支持的格式有很多，比较常见的是wide、json、yaml
[root@m01 ~]# kubectl get namespaces
NAME STATUS AGE
default Active 2d9h
kube-node-lease Active 2d9h
kube-public Active 2d9h
kube-system Active 2d9h
[root@m01 ~]# kubectl get ns
NAME STATUS AGE
default Active 2d9h
kube-node-lease Active 2d9h
kube-public Active 2d9h
kube-system Active 2d9h
[root@m01 /mnt]# kubectl get ns default
NAME STATUS AGE
default Active 2d11h
[root@m01 /mnt]# kubectl get ns default -o yaml
apiVersion: v1
kind: Namespace
metadata:
creationTimestamp: "2021-08-01T07:56:01Z"
labels:
kubernetes.io/metadata.name: default
name: default
resourceVersion: "209"
uid: 7061e898-4ec8-4c5d-9c7e-2f15fae84ad7
spec:
finalizers:
- kubernetes
status:
phase: Active
[root@m01 /mnt]# kubectl get ns default -o wide
NAME STATUS AGE
default Active 2d11h
[root@m01 /mnt]# kubectl describe ns default #查看描述信息
Name: default
Labels: kubernetes.io/metadata.name=default
Annotations: <none>
Status: Active # Active 命名空间正在使用中 Terminating 正在删除命名空间
No resource quota. # ResourceQuota 针对namespace做的资源限制
No LimitRange resource. # LimitRange针对namespace中的每个组件做的资源限制
#Kubernetes 自动创建的命名空间：
1》default 没有指明使用其它命名空间的对象所使用的默认命名空间 * kube-system Kubernetes 系统创建对象所使用的命名空间
2》kube-public 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。
2、创建命名空间
[root@m01 hzl]# kubectl create ns hzl #创建hzl命名空间
namespace/hzl created
[root@m01 hzl]# kubectl get ns #查看命名空间
NAME STATUS AGE
default Active 2d9h
hzl Active 10s #新创建的命名空间
kube-node-lease Active 2d9h
kube-public Active 2d9h
kube-system Active 2d9h
【使用yaml创建命名空间】
[root@m01 ~]# cat namespce.yaml #编写namespace.yaml文件
kind: Namespace #类型为Namespace
apiVersion: v1 #版本
metadata:
name: hzl-test #命名空间名称
labels:
name: hzl-test-v1
[root@m01 ~]# kubectl create -f namespce.yaml #指定yaml文件进行创建namespace
namespace/hzl-test created
[root@m01 ~]# kubectl get ns #查看namespace
NAME STATUS AGE
default Active 2d9h
hzl Active 7m10s
hzl-test Active 6s #
kube-node-lease Active 2d9h
kube-public Active 2d9h
kube-system Active 2d9h
3、删除命名空间
语法：kubectl delete namespaces < insert-some-namespace-name>
[root@m01 /mnt]# kubectl get ns #查看namespace
NAME STATUS AGE
default Active 2d11h
hzl Active 126m
hzl-test Active 118m
kube-node-lease Active 2d11h
kube-public Active 2d11h
kube-system Active 2d11h
orange-test Active 120m
[root@m01 /mnt]# kubectl delete ns hzl-test #删除namespace ns=namespace
namespace "hzl-test" deleted
[root@m01 /mnt]# kubectl get ns #查看hzl-test已经删除
NAME STATUS AGE
default Active 2d11h
hzl Active 126m
kube-node-lease Active 2d11h
kube-public Active 2d11h
kube-system Active 2d11h
orange-test Active 121m
4、设置默认的命名空间
大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些命名空间中。但是命名空间资源本身并不在命名空间中。而且底层资源，例如 nodes 和持久化卷不属于任何命名空间
#设置默认选择的命名空间
[root@m01 /mnt]# kubectl config set-context --current --namespace=default (设置default为默认的命名空间)
Context "kubernetes-admin@kubernetes" modified.
#查看kubernets所有在命名空间的资源
[root@m01 /mnt]# kubectl api-resources --namespaced=true
NAME SHORTNAMES APIVERSION NAMESPACED KIND
bindings v1 true Binding
configmaps cm v1 true ConfigMap
endpoints ep v1 true Endpoints
events ev v1 true Event
limitranges limits v1 true LimitRange
persistentvolumeclaims pvc v1 true PersistentVolumeClaim
pods po v1 true Pod
...........
......
#查看kubernets部分不在命名空间的资源
[root@m01 /mnt]# kubectl api-resources --namespaced=false
NAME SHORTNAMES APIVERSION NAMESPACED KIND
componentstatuses cs v1 false ComponentStatus
namespaces ns v1 false Namespace
nodes no v1 false Node
persistentvolumes pv v1 false PersistentVolume
mutatingwebhookconfigurations admissionregistration.k8s.io/v1 false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io/v1 false ValidatingWebhookConfiguration
customresourcedefinitions crd,crds apiextensions.k8s.io/v1 false CustomResourceDefinition
...........
......
5、pod使用namespace命名空间
1）#查看镜像
[root@m01 /mnt]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.cn-shanghai.aliyuncs.com/hzl_images/centos 7 4f380adfc10f 5 weeks ago 133MB
2）#资源配置清单yaml文件编写
[root@m01 /mnt]# cat my-pod-namespace.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod-namespace #pod名称
namespace: hzl #命名空间名称
labels:
app: bash
tir: backend
spec:
containers:
- name: bash-container
image: registry.cn-shanghai.aliyuncs.com/hzl_images/centos:7 #镜像名称
command: ['sh','-c','echo hello myfirstpod && sleep 3600']
3）#创建pod指定命名空间为hzl
[root@m01 /mnt]# kubectl create -f my-pod-namespace.yaml
pod/my-pod-namespace created
4）#查看创建的状态
[root@m01 /mnt]# kubectl get pods
NAME READY STATUS RESTARTS AGE
my-pod-namespace 1/1 Running 0 92s
5）#查看创建pod的标签
[root@m01 /mnt]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
my-pod-namespace 1/1 Running 0 3m42s app=bash,tir=backend
三、kubernetes的资源类型
K8S中所有的内容都抽象为资源，资源实例化之后叫做对象。
一般使用yaml格式的文件来创建符合我们预期的pod，这样的yaml文件我们一般成为资源清单
1、名称空间级资源
1》#工作负载型资源(workload)
Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob(ReplicationController在v1.11版本被废弃)
2》#服务发现及负载均衡型资源(ServiceDiscovery LoadBalance)
Service、Ingress、……
3》#配置与存储型资源
Volume(存储卷)、CSI(容器存储接口，可以扩展各种各样的第三方存储卷)
4》#特殊类型的存储卷
ConfigMap(当配置中心来使用的资源类型)、Secret(保存敏感信息)、DownwardAPI(把外部环境中的信息输出给容器)
2、集群级资源
Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding
3、元数据型资源
HPA、PodTemplate、LimitRange
4、常用字段解释
【查看api-version信息】
[root@m01 /mnt]# kubectl api-versions
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/v1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
discovery.k8s.io/v1
discovery.k8s.io/v1beta1
events.k8s.io/v1
events.k8s.io/v1beta1
extensions/v1beta1
flowcontrol.apiserver.k8s.io/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1
node.k8s.io/v1beta1
policy/v1
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
【获取文档使用说明书】
[root@m01 /mnt]# kubectl explain pod
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
四、资源类型pod（资源清单）
【Pod的生命周期】
Pod是kubernetes集群进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中。
可以理解为容器的封装，一个Pod中可以存在一个或者多个容器
Pod能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的Init容器。
【初始化(lnit)容器】
#Init容器与普通容器区别：
1）Init容器总是运行到成功为止
2）每个Init容器都必须在下一个Init容器启动之前成功完成
ps ：如果Pod的Init容器失败，Kubenetes会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod对应的restartPolicy(重启策略)为Never，它就不会重新启动容器
【Init容器的优势】
它可以包含并运行实用工具。出于安全考虑，不建议在应用程序容器镜像中包含这些实用工具的。
他们可以包含使用工具和定制代码来安装，但是不能出现在应用程序容器镜像中。例如：创建镜像没有必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这样的工具。
应用程序容器镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
Init容器使用Linux Namespace，所以相对应用程序容器来说具有不同的文件系统试图。因此，Init容器能够具有Secret的权限，而应用程序容器则不能。
它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供一种简单的阻塞或延迟应用程序容器的启动方法，直到满足先决条件
【示列】
创建一个简单的配置清单： my-nginx-pod.yaml
#配置清单编写
[root@m01 /mnt]# cat my-nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: hzl
spec:
containers:
- image: registry.cn-shanghai.aliyuncs.com/hzl_images/nginx:v1
name: pod
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
使用配置清单（创建、删除)
#创建pod
[root@m01 /mnt]# kubectl create -f my-nginx-pod.yaml
pod/nginx created
#实时查看创建的pod
[root@m01 /mnt]# kubectl get pod nginx -w
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 24s
#查看创建pod标签
[root@m01 /mnt]# kubectl get pod nginx --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx 1/1 Running 0 5m40s <none> #没有标签，配置清单未设置标签
#查看pod上的nginx 的详细信息
[root@m01 /mnt]# kubectl describe pod nginx #只查看nginx的详细信息
Name: nginx
Namespace: hzl
Priority: 0
Node: nod01/192.168.15.56 #存活于nod01节点上
Start Time: Wed, 04 Aug 2021 04:56:26 +0800
Labels: <none> #标签（标签未设定，为空）
Annotations: <none>
Status: Running
IP: 10.244.1.10
IPs:
IP: 10.244.1.10
...........
......
【配置清单详解】
apiVersion: v1 #必选，版本号，例如v1
kind: Pod #必选，资源类型，例如 Pod
metadata: #必选，元数据
name: string #必选，Pod名称
namespace: string #Pod所属的命名空间,默认为"default"
labels: #自定义标签列表
- name: string
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: string #必选，容器名称
image: string #必选，容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略
command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] #容器的启动命令参数列表
workingDir: string #容器的工作目录
volumeMounts: #挂载到容器内部的存储卷配置
- name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean #是否为只读模式
ports: #需要暴露的端口库号列表
- name: string #端口的名称
containerPort: int #容器需要监听的端口号
hostPort: int #容器所在主机需要监听的端口号，默认与Container相同
protocol: string #端口协议，支持TCP和UDP，默认TCP
env: #容器运行前需设置的环境变量列表
- name: string #环境变量名称
value: string #环境变量的值
resources: #资源限制和请求的设置
limits: #资源限制的设置
cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: #资源请求的设置
cpu: string #Cpu请求，容器启动的初始可用数量
memory: string #内存请求,容器启动的初始可用数量
lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
livenessProbe: #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
exec: #对Pod容器内检查方式设置为exec方式
command: [string] #exec方式需要制定的命令或脚本
httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略
nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes: #在该pod上定义共享存储卷列表
- name: string #共享存储卷名称 （volumes类型有很多种）
emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string #Pod所在宿主机的目录，将被用于同期中mount的目录
secret: #类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
【容器探针】
探针是由kubelet对容器执行的定期诊断
要执行诊断，kubelet调用由容器实现的Handler
#三种类型的处理程序：
1》ExecAction： 在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
2》TCPSocketAction：对指定端口上的容器IP地址进行TCP检查。如果端口打开，则诊断为成功的。
3》HTTPGetAction： 对指定的端口和路径上的容器IP地址执行HTTP Get请求。如果响应的状态码大于等于200且小于400，则诊断为成功的
#探测都将获得一下三种结果之一：
1>成功：容器通过了诊断
2>失败：容器未通过诊断
3>未知：诊断失败，因此不会采取任何行动
#探测方式:
1>livenessProbe： 指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success。
2>readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod相匹配的所有Service的端点中删除该Pod的IP地址。初始化延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success
【检测探针–就绪检测】
配置清单编写：readiness.yaml
#编写清单
[root@m01 /mnt]# cat readiness.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-nginx-get
labels:
app: readiness-nginx-get
spec:
containers:
- name: readiness-nginx-get
image: nginx
imagePullPolicy: IfNotPresent
readinessProbe:
httpGet:
port: 80
path: /index1.html
initialDelaySeconds: 1
periodSeconds: 3
restartPolicy: Always
#创建pod
[root@m01 /mnt]# kubectl create -f readiness.yaml
pod/readiness-nginx-get created
[root@m01 /mnt]# kubectl get pods readiness-nginx-get
NAME READY STATUS RESTARTS AGE
readiness-nginx-get 0/1 Running 0 2m47s
#查看未就绪的状态（原因分析）
[root@m01 /mnt]# kubectl describe pod readiness-nginx-get
Name: readiness-nginx-get
Namespace: hzl
Priority: 0
Node: nod01/192.168.15.56
Start Time: Thu, 05 Aug 2021 22:41:41 +0800
Labels: app=readiness-nginx-get
Annotations: <none>
Status: Running
IP: 10.244.1.20
IPs:
IP: 10.244.1.20
Containers:
readiness-nginx-get:
Container ID: docker://fad0df982f78b4d9beae4e29bf05e7eb462888e70a53eda039212dca4b49bad3
Image: nginx
Image ID: docker-pullable://nginx@sha256:8f335768880da6baf72b70c701002b45f4932acae8d574dedfddaf967fc3ac90
Port: <none>
Host Port: <none>
State: Running
Started: Thu, 05 Aug 2021 22:41:49 +0800
Ready: False
Restart Count: 0
Readiness: http-get http://:80/index1.html delay=1s timeout=1s period=3s #success=1 #failure=3
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-q77ss (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
kube-api-access-q77ss:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
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 3m21s default-scheduler Successfully assigned hzl/readiness-nginx-get to nod01
Normal Pulled 3m14s kubelet Container image "nginx" already present on machine
Normal Created 3m14s kubelet Created container readiness-nginx-get
Normal Started 3m13s kubelet Started container readiness-nginx-get
Warning Unhealthy 2m9s (x22 over 3m12s) kubelet Readiness probe failed: HTTP probe failed with statuscode: 404
ps : #注意这句描述, 准备探针失败，状态码404
Readiness probe failed: HTTP probe failed with statuscode: 404
ps : #这个原因是准备探测找到不index1.html页面
#解决方案：
kubectl进入容器格式：
kubectl exec pod名称 -c 容器名称 -it -- /bin/sh 若pod中只有一个容器，可以省略-c
[root@m01 /mnt]# kubectl exec readiness-nginx-get -c readiness-nginx-get -it -- bash
root@readiness-nginx-get:/# cd /usr/share/nginx/html/
root@readiness-nginx-get:/usr/share/nginx/html# ls
50x.html index.html
root@readiness-nginx-get:/usr/share/nginx/html# echo "1234" >index1.html
root@readiness-nginx-get:/usr/share/nginx/html# ls
50x.html index.html index1.html
root@readiness-nginx-get:/usr/share/nginx/html# exit
[root@m01 /mnt]# kubectl get pod readiness-nginx-get
NAME READY STATUS RESTARTS AGE
readiness-nginx-get 1/1 Running 0 14m #状态已就绪
【检测探针–存活检测】
编写配置清单：liveness.yaml
#配置清单编写
[root@m01 /mnt]# cat liveness.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec
labels:
app: liveness-exec
spec:
containers:
- name: liveness-exec
image: busybox
imagePullPolicy: IfNotPresent
command: ['/bin/sh', '-c', 'touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 3600']
livenessProbe:
exec:
command:
- test
- -e
- tmp/live
initialDelaySeconds: 1
periodSeconds: 3
restartPolicy: Always
#创建pod
[root@m01 /mnt]# kubectl get pods liveness-exec
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 0 46s
# 若干时间后， pod已经重启2次
[root@m01 /mnt]# kubectl get pods liveness-exec -w
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 3m4s
liveness-exec 1/1 Running 2 3m20s #过了一段时间后，已经重启了两次
【Pod生命周期钩子】
Pod hook是由Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hook
Hook（钩子）的类型包括两种：
exec： 执行一段命令
HTTP：发送http请求
编写配置清单：hook.yaml
#配置清单
[root@m01 /mnt]# cat hook.yaml
apiVersion: v1
kind: Pod
metadata:
name: hook-pod
labels:
app: hook-pod
spec:
containers:
- name: hook-pod
image: nginx
imagePullPolicy: IfNotPresent
lifecycle:
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
exec:
command:
- /bin/bash
- -c
- echo hello from the postStart handler > /usr/share/message
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
exec:
command:
- /bin/bash
- -c
- echo hello from the postStop handler > /usr/share/message
restartPolicy: Always
#创建pod
[root@m01 /mnt]# kubectl create -f hook.yaml
pod/hook-pod created
[root@m01 /mnt]# kubectl get pods hook-pod
NAME READY STATUS RESTARTS AGE
hook-pod 1/1 Running 0 65s
#测试
[root@m01 /mnt]# kubectl exec hook-pod -it -- bash
root@hook-pod:/# cat /usr/share/message
hello from the postStart handler
【重启策略】
PodSpec中restartPolicy字段，值为Always、OnFailure、Never，默认为Always
restartPolicy适用于所有容器，仅指通过同一节点上的kubelet重新启动容器。
失败的容器由kubelet以5分钟为上限的指数退避延迟(10s、20s、40s…)重启，并在成功执行十分钟后重置
#Pod phase(相位)
Pod的status字段是一个PodStatus对象，PodStatus中由一个phase字段。
相位(phase)是Pod在其生命周期中的简单宏观概述。该阶段并不是对容器或Pod的综合汇总，也不是为了作为综合状态机
#phase(相位)的值：
1>挂起(Pending)： Pod已被Kubernetes系统接受，但有一个或多个容器镜像尚未创建。需要等待一段时间，等待时间包括调度Pod的时间和通过网络下载镜像的时间。
2>运行中(Running)：该Pod已经绑定到了一个节点上，Pod中所有的容器都已经被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
3>成功(Successed)：Pod中的所有容器都被成功终止，并且不会再重启。
4>失败(Failed)： Pod中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
5>未知(Unknown)： 因为某些原因无法取得Pod的状态，通常是因为与Pod所在主机通信失败
本文来自博客园，作者：ଲ一笑奈&何，转载请注明原文链接：https://www.cnblogs.com/zeny/p/15121467.html
