kubectl 命令使用与解释--陈述式-声明式等等等等
文章目录
- 一、陈述式资源管理
-
- 1.查看版本信息
- 2.查看资源对象简写
- 3.查看集群信息
- 4.配置 kubectl 自动补全
- 5.node 节点查看日志
- 二、基本信息查看
-
- 1.查看删除创建命令空间
- 2.扩缩容
- 三、项目的生命周期
-
-
- 1.创建kubectl run命令
- 2、发布kubectl expose命令
-
- 2.1 Service的作用
- 2.2 Service的类型
- 2.3 查看Pod网络状态详细信息和Service暴露端口
- 2.4 查看关联后端的节点
- 2.5 查看service的描述信息
- 2.6 访问查看
- 2.7 查看访问日志
- 3、更新kubectl set
-
- 3.1 获取修改模板
- 3.2 查看当前nginx的版本号
- 3.3 将nginx版本更新为1.15
- 3.4 监听pod状态
- 3.5 查看pod的ip变化
- 4、回滚kubectl rollout
-
- 4.1 查看历史版本
- 4.2 执行回滚到上一个版本
- 4.3 执行回滚到指定版本
- 4.4 检查回滚状态
- 5、删除kubectl delete
-
- 5.1 删除副本控制器
- 5.2 删除service
-
- 四、金丝雀发布/灰度发布（Canary Release）
-
- 1、金丝雀发布简介
- 2、更新deployment的版本，并配置暂停deployment
-
- 2.1 创建pods
- 2.2 发布服务
- 2.3 查看nginx版本
- 2.4 定义版本change-cause
-
- 2.4.1查看历史版本
- 2.4.2定义版本
- 2.4.3再次查看历史版本
- 2.4.4更新nginx版本为1.15并配置暂停
- 2.4.5观察更新状态
- 2.4.6监控更新的过程
- 2.4.7查看nginx版本
- 2.4.8查看并更新历史版本change-cause
- 2.4.9resume继续更新
- 2.4.10查看最后的更新情况
- 五、声明式管理
-
- 1. 声明式管理方法介绍
- 2.查看资源配置清单
- 3. 解释资源配置清单
- 4、修改资源配置清单并应用
-
- 1.离线修改、修改yaml文件
- 2.删除资源
- 3.新建资源
- 4.在线修改
- 5、删除资源配置清单
-
- 1.陈述式删除
- 2.声明式删除
一、陈述式资源管理
-
kubernetes集群管理集群资源的唯一入口是通过相应的方法调用apiserver的接口
-
kubectl是官方的CLI命令行工具，用于与apiserver 进行通信，将用户在命令行输入的命令，组织并转化为apiserver能识别的信息，进而实现管理k8s 各种资源的一种有效途径
-
对资源的增、删、查操作比较方便，但对改的操作就不容易了
-
kubectl 的命令大全:
kubectl --help
k8s中文文档: http://docs.kubernetes.org.cn/683.html
1.查看版本信息
[root@master1 ~]# kubectl version
2.查看资源对象简写
[root@master1 ~]# kubectl api-resources
3.查看集群信息
[root@master1 ~]# kubectl cluster-info
4.配置 kubectl 自动补全
[root@master1 ~]# source <(kubectl completion bash)
5.node 节点查看日志
[root@node1 ~]# journalctl -u kubectl -f
二、基本信息查看
#基本格式
kubectl get <resource> [-o wide | jsonlyaml] [-n namespace]
#获取资源的相关信息，-n指定命令空间，-o指定输出格式resource可以是具体资源名称，如pod nginx-xxx;也可以是资源类型，如pod; 或者all (仅展示几种核心资源，并不完整)
#参数
--all-namespaces 或-A :表示显示所有命令空间，
--show-labels :显示所有标签
-l app:仅显示标签为app的资源
-l app=nginx :仅显示包含app标签，且值为nginx的资源
#示例：
[root@master1 ~]# kubectl get pods -A
#查看master 节点状态
[root@master1 ~]# kubectl get cs
1.查看删除创建命令空间
#作用：命令空间的作用:用于允许不同命令空间的相同类型的资源重名的
[root@master1 ~]# kubectl get namespace
[root@master1 ~]# kubectl get ns #缩写
#指定查看default命名空间的所有资源
[root@master1 ~]# kubectl get all -n default
#创建命令空间
[root@master1 ~]# kubectl create ns jjj
[root@master1 ~]# kubectl get ns
#删除命名空间
[root@master1 ~]# kubectl delete namespace jjj
[root@master1 ~]# kubectl get ns
#在默认命名空间kube-public 创建副本控制器( deployment) 来启动Pod (nginx-qqq )
创建分为两种 run 和 creste deployment
run：用于创建一个自主式静态pod
create deployment：用于创建pod 之后通过 deployment 控制器管理pod
[root@master1 ~]# kubectl create deployment nginx-qqq --image=nginx -n kube-public
#描述某个资源的详细信息
[root@master1 ~]# kubectl describe deployments.apps nginx-qqq -n kube-public
[root@master1 ~]# kubectl get pod -n kube-public
[root@master1 ~]# kubectl describe pod nginx-qqq-6c8455787b-ccrwl -n kube-public
#查看命名空间kube-public中的pod信息
[root@master1 ~]# kubectl get pod -n kube-public #拉去的有点慢我就不等了
#kubect1 exec可以跨主机登录容器，docker exec只能在容器所在主机上登录
[root@master1 ~]# kubectl exec -it nginx-qjm-6fd8bb65cf-rx4gz bash -n default
#删除(重启)pod资源，由于存在deployment/rc之类的副本控制器，删除pod也会重新拉起来
[root@master1 ~]# kubectl delete pod nginx-qjm-6fd8bb65cf-6b4d2 -n default
#若pod无法删除，总是处于terminate状态，则要强行删除pod
#grace-period表示过渡存活期，默认30s， 在删除pod之前允许pod慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod
[root@master1 ~]# kubectl delete pod nginx-qjm-6fd8bb65cf-9bwnq -n default --force --grace-period=0
2.扩缩容
[root@master1 ~]# kubectl scale deployment nginx-qjm --replicas=4 -n default #扩容
[root@master1 ~]# kubectl scale deployment nginx-qjm --replicas=2 -n default #缩容
#查看标签
若想查看在那个命名空间，加 -A
[root@master1 ~]# kubectl get pods --show-labels
例：
--all-namespaces 或-A :表示显示所有命令空间，
--show-labels :显示所有标签
-l app:仅显示标签为app的资源
-l app=nginx :仅显示包含app标签，且值为nginx的资源
三、项目的生命周期
项目的生命周期:创建–>发布–>更新–>回滚–>删除
1.创建kubectl run命令
创建并运行一个或多个容器镜像
创建一个deployment或job来管理容器
kubectl run --help查看使用帮助
#启动nginx实例，暴露容器端口80，设置副本数3
kubectl run nginx-deployment --image=nginx:1.14 --port=80 --replicas=3
#若使用run报错：k8sv1.18.0以后的版本， --replicas以后弃用该命令，推荐使用deployment创建pods，我这里用的是1.21.3版本
想创建多个实例时可以使用：kubectl create deployment pg102 --image=pg:12
–port=5432 --replicas=3 来进行创建；
查看pod: kubectl get pod，用来查看使用命令创建的所有实例
查看deploy：kubectl get deploy，用来查看实例所创建的数量；
高于1.17版本的建议以后直接使用create deployment创建pod管理器方式创建pod;
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
2、发布kubectl expose命令
将资源暴露为新的Service
- 为Deployment的nginx创建Service，并通过Service的80端口转发至容器的80端口上，Service的名称为nginx-service，类型为NodePort
kubectl expose deployment nginx2 --port=80 --target-port=80 --name=nginx-service --type=NodePort
2.1 Service的作用
- Kubernetes之所以需要Service，一方面是因为Pod的IP不是固定的（Pod可能会重建），另一方面是因为一组Pod实例之间总会有负载均衡的需求
- Service通过Label Selector实现的对一组的Pod的访问
- 对于容器应用而言，Kubernetes提供了基于VIP（虚拟IP）的网桥的方式访问Service，再由Service重定向到相应的Pod
2.2 Service的类型
- ClusterIP:提供一个集群内部的虚拟IP以供Pod访问（Service默认类型）
- NodePort:在每个Node上打开一个端口以供外部访问，Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的，通过NodeIP:NodePort的方式
- LoadBalancer:通过外部的负载均衡器来访问，通常在云平台部署LoadBalancer还需要额外的费用
2.3 查看Pod网络状态详细信息和Service暴露端口
kubectl get pods,svc -o wide
2.4 查看关联后端的节点
kubectl get endpoints
2.5 查看service的描述信息
kubectl describe svc nginx
2.6 访问查看
curl 10.96.83.182
kubectl describe svc nginx | grep NodePort
curl 192.168.113.126:31979
2.7 查看访问日志
kubectl get pod
kubectl logs []
3、更新kubectl set
更改现有应用资源一些信息
kubectl set --help查看使用帮助
3.1 获取修改模板
kubectl set image --help获取
3.2 查看当前nginx的版本号
curl -I 192.168.113.126:31979
3.3 将nginx版本更新为1.15
kubectl set image deployment/nginx nginx=nginx:1.15
3.4 监听pod状态
处于动态监听pod状态，由于使用的是滚动更新方式，所以会先生成一个新的pod，然后删除一个旧的pod，往后以此类推
注：更新规则可通过“kubetl describe deployment nginx”的“RollingUpdateStrategy”查看，默认配置为“25% max unavailable, 25% max surge”，即按照25%的比例进行滚动更新
kubectl get pods -w
3.5 查看pod的ip变化
curl -I 192.168.113.126:31979
kubectl get pod -o wide
4、回滚kubectl rollout
对资源进行回滚管理
kubectl rollout --help查看使用帮助
4.1 查看历史版本
kubectl rollout history deployment/nginx
4.2 执行回滚到上一个版本
kubectl rollout undo deployment/nginx
kubectl get pods -o wide
#查看nginx当前版本
curl -I 192.168.113.126:31979
4.3 执行回滚到指定版本
#查看历史版本
kubectl rollout history deployment/nginx
#回到revison2，即1.15版本
kubectl rollout undo deployment/nginx --to-revision=2
#查看pod的ip变化
kubectl get pods -o wide
#查看当前nginx版本
curl -I 192.168.113.126:31979
4.4 检查回滚状态
kubectl rollout status deployment/nginx
5、删除kubectl delete
5.1 删除副本控制器
kubectl delete deployment/nginx
5.2 删除service
kubectl delete svc/nginx-service
四、金丝雀发布/灰度发布（Canary Release）
1、金丝雀发布简介
Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停（pause）”或“继续（resume）”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，在筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布
2、更新deployment的版本，并配置暂停deployment
2.1 创建pods
kubectl create deployment nginx-test --image=nginx:1.14 --replicas=3
kubectl get pods,deploy -o wide
2.2 发布服务
kubectl expose deploy nginx-test --port=80 --target-port=80 --name=nginx-service --type=NodePort
kubectl get svc -o wide
2.3 查看nginx版本
curl -I 192.168.113.126:31811
kubectl describe deployment nginx-test | grep Image
2.4 定义版本change-cause
2.4.1查看历史版本
在不定义CHANGE-CAUSE的情况下，缺省值为，当历史版本较多时，不便于咱们回滚时辨认版本号。因此，建议定义CHANGE-CAUSE为服务版本以帮助咱们辨认当前服务
kubectl rollout history deploy/nginx-test
2.4.2定义版本
一般通过修改配置的方式定义change-cause
[root@master ~]# kubectl edit deploy/nginx-test
......
kind: Deployment
metadata:
annotations:
#下行可定义历史版本revision
deployment.kubernetes.io/revision: "1"
#在Deployment的matadata项下的annotations中如下行定义change-cause
kubernetes.io/change-cause: "nginx1.14"
......
2.4.3再次查看历史版本
kubectl rollout history deploy/nginx-test
2.4.4更新nginx版本为1.15并配置暂停
kubectl set image deploy/nginx-test nginx=nginx:1.15 && kubectl rollout pause deploy/nginx-test
2.4.5观察更新状态
kubectl rollout status deploy/nginx-test
2.4.6监控更新的过程
可以看到已经新增了一个pod，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
kubectl get pods -w
2.4.7查看nginx版本
kubectl get pod -o wide
2.4.8查看并更新历史版本change-cause
kubectl rollout history deploy/nginx-test
[root@master ~]# kubectl edit deploy/nginx-test
kind: Deployment
metadata:
annotations:
#下行的revison自动更新为2
deployment.kubernetes.io/revision: "2"
#修改下行的change-cause为nginx1.15
kubernetes.io/change-cause: nginx1.15
kubectl rollout history deployment/nginx-test
2.4.9resume继续更新
测试新版本没问题继续更新
kubectl rollout resume deploy/nginx-test
2.4.10查看最后的更新情况
kubectl get pods -w
五、声明式管理
1. 声明式管理方法介绍
- 适合于对资源的修改操作
- 声明式资源管理方法依赖于资源配置清明文件对资源进行管理
- 资源配置清单文件有两种格式：yaml（人性化，易读），json（易于api接口解析）
- 对资源的观念里，是通过实现定义在同一资源配置清单内，再通过陈述式命令应用到k8s集群里
- 语法格式：kubectl create/apply/delete -f -o yaml
2.查看资源配置清单
kubectl get deploy/nginx -o yam
kubectl get service nginx-service -o yaml
3. 解释资源配置清单
kubectl explain deployment.metadata
kubectl explain service.metadata
4、修改资源配置清单并应用
1.离线修改、修改yaml文件
修改yaml文件：并用kubectl apply -f xxxx.yaml文件使之生效
注意：当apply不生效时，先使用delete清除资源，再apply创建资源
kubectl get service nginx-service -o yaml > nginx-svc.yaml
2.删除资源
kubectl delete -f nginx-svc.yaml
3.新建资源
kubectl apply -f nginx-svc.yaml
#查看service资源
kubectl get svc
4.在线修改
直接使用kubectl edit service nginx-service在线编辑配置资源清单并保存退出即时生效（如port: 888）
PS：此修改方式不会对yaml文件内容修改
kubectl edit service nginx-service
#查看service资源
kubectl get svc
5、删除资源配置清单
1.陈述式删除
kubectl delete service nginx-service
2.声明式删除
kubectl delete -f nginx-svc.yaml
详解k8s中的port:
port
port是k8s集群内部访问service的端口，即通过clusterIP:port可以从Pod所在的Node上访问到servicenodePort
nodePort是外部访问k8s集群中service的端口，通过nodeIP:nodePort可以从外部访问到某个servicetargetPort
targetPort:是Pod的端口，从port或nodePort来的流量经过kube-proxy反向代理负载均衡转发到后瑞Pod的targetPort上，最后进入容器containerPort
containerPort是Pod内部容器的端口，targetPort映射到containerport.
查看api 资源版本标签
kubectl api-versions
admi ssionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1 #如果是业务场景一般首选使用apps/v1
apps/v1beta1 #带有beta字样的代表的是测试版本，不用在生产环境中
apps/v1beta2
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/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
events.k8s.io/v1beta1
extensions/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1beta1
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
写一个yaml文件demo
mkdir /opt/demo
cd /opt/demo
kubectl explain deployment
vim nginx-deplqyment.yaml
#解释
apiVersion: apps/v1 #指定api版本标签
kind: Deployment
#定义资源的类型/角色，deployment为副本控制器，此处资源类型可以是Deployment、Job、 Ingress、 Service等
metadata: #定义资源的元数据信息，比如资源的名称、namespace、标签等信息
name: nginx-deployment #定义资源的名称，在同一个namespace空间中必须是唯一的
labels: #定义资源标签(Pod的标签)
app: nginx
spec: #定义deployment资源需要的参数属性，诸如是否在容器失败时重新启动容器的属性
replicas: 3 #定义副本数量
selector: #定义标签选择器
matchLabels: #定义匹配标签
app: nginx #匹配上面的标签，需与上面的标签定义的app保持一致
template: #定义业务模板，如果有多个副本，所有副本的属性会按照模板的相关配置进行匹配
metadata:
labels:
app: nginx
spec:
containers: #定义容器属性
-name: nginx #定义一个容器名，一个-name:定义一个容器
image: nginx:1.15.4 #定义容器使用的镜像以及版本
ports:
- containerPort: 80 #定义容器的对外的端口
deployment.yaml文件详解
apiVersion: extensions/v1beta1 #接口版本
kind: Deployment #接口类型
metadata:
name: cango-demo #Deployment名称
namespace: cango-prd #命名空间
labels:
app: cango-demo #标签
spec:
replicas: 3
strategy:
rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间
maxSurge: 1 #滚动升级时会先启动1个pod
maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
template:
metadata:
labels:
app: cango-demo #模板名称必填
sepc: #定义容器模板，该模板可以包含多个容器
containers:
- name: cango-demo #镜像名称
image: swr.cn-east-2.myhuaweicloud.com/cango-prd/cango-demo:0.0.1-SNAPSHOT #镜像地址
command: [ "/bin/sh","-c","cat /etc/config/path/to/special-key" ] #启动命令
args: #启动参数
- '-storage.local.retention=$(STORAGE_RETENTION)'
- '-storage.local.memory-chunks=$(STORAGE_MEMORY_CHUNKS)'
- '-config.file=/etc/prometheus/prometheus.yml'
- '-alertmanager.url=http://alertmanager:9093/alertmanager'
- '-web.external-url=$(EXTERNAL_URL)'
#如果command和args均没有写，那么用Docker默认的配置。
#如果command写了，但args没有写，那么Docker默认的配置会被忽略而且仅仅执行.yaml文件的command（不带任何参数的）。
#如果command没写，但args写了，那么Docker默认配置的ENTRYPOINT的命令行会被执行，但是调用的参数是.yaml中的args。
#如果如果command和args都写了，那么Docker默认的配置被忽略，使用.yaml的配置。
imagePullPolicy: IfNotPresent #如果不存在则拉取
livenessProbe: #表示container是否处于live状态。如果LivenessProbe失败，LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉container，并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为Success，如果container没有提供LivenessProbe，则也认为是Success；
httpGet:
path: /health #如果没有心跳检测接口就为/
port: 8080
scheme: HTTP
initialDelaySeconds: 60 ##启动后延时多久开始运行检测
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe:
httpGet:
path: /health #如果没有心跳检测接口就为/
port: 8080
scheme: HTTP
initialDelaySeconds: 30 ##启动后延时多久开始运行检测
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
resources: ##CPU内存限制
requests:
cpu: 2
memory: 2048Mi
limits:
cpu: 2
memory: 2048Mi
env: ##通过环境变量的方式，直接传递pod=自定义Linux OS环境变量
- name: LOCAL_KEY #本地Key
value: value
- name: CONFIG_MAP_KEY #局策略可使用configMap的配置Key，
valueFrom:
configMapKeyRef:
name: special-config #configmap中找到name为special-config
key: special.type #找到name为special-config里data下的key
ports:
- name: http
containerPort: 8080 #对service暴露端口
volumeMounts: #挂载volumes中定义的磁盘
- name: log-cache
mount: /tmp/log
- name: sdb #普通用法，该卷跟随容器销毁，挂载一个目录
mountPath: /data/media
- name: nfs-client-root #直接挂载硬盘方法，如挂载下面的nfs目录到/mnt/nfs
mountPath: /mnt/nfs
- name: example-volume-config #高级用法第1种，将ConfigMap的log-script,backup-script分别挂载到/etc/config目录下的一个相对路径path/to/...下，如果存在同名文件，直接覆盖。
mountPath: /etc/config
- name: rbd-pvc #高级用法第2中，挂载PVC(PresistentVolumeClaim)
#使用volume将ConfigMap作为文件或目录直接挂载，其中每一个key-value键值对都会生成一个文件，key为文件名，value为内容，
volumes: # 定义磁盘给上面volumeMounts挂载
- name: log-cache
emptyDir: {}
- name: sdb #挂载宿主机上面的目录
hostPath:
path: /any/path/it/will/be/replaced
- name: example-volume-config # 供ConfigMap文件内容到指定路径使用
configMap:
name: example-volume-config #ConfigMap中名称
items:
- key: log-script #ConfigMap中的Key
path: path/to/log-script #指定目录下的一个相对路径path/to/log-script
- key: backup-script #ConfigMap中的Key
path: path/to/backup-script #指定目录下的一个相对路径path/to/backup-script
- name: nfs-client-root #供挂载NFS存储类型
nfs:
server: 10.42.0.55 #NFS服务器地址
path: /opt/public #showmount -e 看一下路径
- name: rbd-pvc #挂载PVC磁盘
persistentVolumeClaim:
claimName: rbd-pvc1 #挂载已经申请的pvc磁盘
Pod yaml文件详解
apiVersion: v1 #必选，版本号，例如v1
kind: Pod #必选，Pod
metadata: #必选，元数据
name: string #必选，Pod名称
namespace: string #必选，Pod所属的命名空间
labels: #自定义标签
- name: string #自定义标签名字
annotations: #自定义注释列表
- name: string
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: string #必选，容器名称
image: string #必选，容器的镜像名称
imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略：Alawys表示总是下载镜像，IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像
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 #内存清楚，容器启动的初始可用数量
livenessProbe: #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
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的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
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的存储卷，挂载集群与定义的secre对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
Service yaml文件详解
apiVersion: v1
kind: Service
matadata: #元数据
name: string #service的名称
namespace: string #命名空间
labels: #自定义标签属性列表
- name: string
annotations: #自定义注解属性列表
- name: string
spec: #详细描述
selector: [] #label selector配置，将选择具有label标签的Pod作为管理
#范围
type: string #service的类型，指定service的访问方式，默认为
#clusterIp
clusterIP: string #虚拟服务地址
sessionAffinity: string #是否支持session
ports: #service需要暴露的端口列表
- name: string #端口名称
protocol: string #端口协议，支持TCP和UDP，默认TCP
port: int #服务监听的端口号
targetPort: int #需要转发到后端Pod的端口号
nodePort: int #当type = NodePort时，指定映射到物理机的端口号
status: #当spce.type=LoadBalancer时，设置外部负载均衡器的地址
loadBalancer: #外部负载均衡器
ingress: #外部负载均衡器
ip: string #外部负载均衡器的Ip地址值
hostname: string #外部负载均衡器的主机名
围
type: string #service的类型，指定service的访问方式，默认为
#clusterIp
clusterIP: string #虚拟服务地址
sessionAffinity: string #是否支持session
ports: #service需要暴露的端口列表
- name: string #端口名称
protocol: string #端口协议，支持TCP和UDP，默认TCP
port: int #服务监听的端口号
targetPort: int #需要转发到后端Pod的端口号
nodePort: int #当type = NodePort时，指定映射到物理机的端口号
status: #当spce.type=LoadBalancer时，设置外部负载均衡器的地址
loadBalancer: #外部负载均衡器
ingress: #外部负载均衡器
ip: string #外部负载均衡器的Ip地址值
hostname: string #外部负载均衡器的主机名