容器编排系统之Pod资源配置清单基础

时间:2021-06-11 23:00:38

  前文我们了解了k8s上的集群管理工具kubectl的基础操作以及相关资源的管理,回顾请参考https://www.cnblogs.com/qiuhom-1874/p/14130540.html;今天我们来聊一下pod资源配置清单的相关话题;

  我们知道在k8s上管理资源的方式有两种,一种是陈述式接口,一种是声明式接口;在前文我们用kubectl create的方式创建pod控制器,创建service,创建名称空间都是使用的陈述式命令的方式在k8s上管理资源;陈述式命令接口管理k8s上的资源的确很方便,但通常创建出来的资源有很多属性都不是我们期望的,所以陈述式命令在k8s集群上管理资源的方式一般不怎么推荐使用;我们要想自己手动定义一个资源,就需要使用声明式接口来创建资源;那么声明式接口该怎么用呢?很简单,我们只需要写一个描述资源的配置文件,然后使用apply命令指定应用对应的资源配置文件即可;

  要想手写资源的配置文件,我们就需要先了解对应的资源有哪些属性,以及配置清单的语法格式;在k8s上资源配置清单有两种格式,一种是yaml格式,一种是json格式,常用yaml格式;我们在初学时,可以仿照陈述命令创建的资源,输出为yaml格式的配置文件来写;

  示例:使用陈述命令创建一个名称空间,然后查看创建的namespace,输出为yaml格式配置文件

[root@master01 ~]# kubectl get ns
NAME STATUS AGE
default Active 5h16m
kube-node-lease Active 5h16m
kube-public Active 5h16m
kube-system Active 5h16m
[root@master01 ~]# kubectl create ns testing
namespace/testing created
[root@master01 ~]# kubectl get ns
NAME STATUS AGE
default Active 5h17m
kube-node-lease Active 5h17m
kube-public Active 5h17m
kube-system Active 5h17m
testing Active 6s
[root@master01 ~]# kubectl get ns/testing -o yaml
apiVersion: v1
kind: Namespace
metadata:
creationTimestamp: "2020-12-08T11:56:18Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:status:
f:phase: {}
manager: kubectl-create
operation: Update
time: "2020-12-08T11:56:18Z"
name: testing
resourceVersion: "28764"
uid: 00280ecd-b570-4d1c-953c-c79411cc88f9
spec:
finalizers:
- kubernetes
status:
phase: Active
[root@master01 ~]#

  提示:可以看到输出的yaml配置文件格式的内容,里面有很多kv数据,每个字段都有对应的值,我们把这些字段叫做testing名称空间的属性;除了查看输出为yaml格式的配置清单,我们也可以输出为json格式的清单;

  导出testing名称空间的yaml配置文件,并保存为一个模板文件

[root@master01 ~]# kubectl get ns testing -o yaml > ns-template.yaml
[root@master01 ~]# cat ns-template.yaml
apiVersion: v1
kind: Namespace
metadata:
creationTimestamp: "2020-12-08T11:56:18Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:status:
f:phase: {}
manager: kubectl-create
operation: Update
time: "2020-12-08T11:56:18Z"
name: testing
resourceVersion: "28764"
uid: 00280ecd-b570-4d1c-953c-c79411cc88f9
spec:
finalizers:
- kubernetes
status:
phase: Active
[root@master01 ~]#

  提示:有了这个配置文件,我们就可以照猫画虎定义其他名称空间;

  示例:使用模板文件,定义创建一个prod的名称空间;

[root@master01 ~]# cat ns-prod.yaml
apiVersion: v1
kind: Namespace
metadata:
name: prod
spec:
finalizers:
- kubernetes
status:
phase: Active
[root@master01 ~]#

  提示:模板中的很多信息都是自动生成的,我们在创建一个资源时,只需要指定特定的必要的属性;在一个资源配置清单中,通常有5个一级字段,apiVersion字段用于指定当前资源所属的群组,在k8s上有很多群组,其中v1是core v1的缩写,表示核心群组,一般不用更改;kind字段是用于描述该资源的类型,这里需要注意,资源类型名称首字母必须大写;metadata字段使用于描述资源的元数据信息,其中对于namespace类型资源来说,最终要的元数据为name表示该资源实例的名称,这个属性也是必要属性;spec字段是用于描述对应资源我们期望的状态,对于namespace资源来说,spec字段可以不用写;status字段主要用来描述资源当前的状态信息;一般这个字段由k8s集群自身维护,用户可以不用定义;

  使用上述配置清单创建prod名称空间

[root@master01 ~]# kubectl create -f ns-prod.yaml
namespace/prod created
[root@master01 ~]# kubectl get ns
NAME STATUS AGE
default Active 5h45m
kube-node-lease Active 5h45m
kube-public Active 5h45m
kube-system Active 5h45m
prod Active 5s
testing Active 28m
[root@master01 ~]#

  提示:以上使用陈述式命令create指定资源配置文件创建资源,这种方式能够创建资源,但是它不可以多次运行,多次运行会报错对应资源已经存在;

  使用资源配置文件删除资源

[root@master01 ~]# kubectl get ns
NAME STATUS AGE
default Active 5h47m
kube-node-lease Active 5h47m
kube-public Active 5h47m
kube-system Active 5h47m
prod Active 2m21s
testing Active 30m
[root@master01 ~]# kubectl delete -f ns-prod.yaml
namespace "prod" deleted
[root@master01 ~]# kubectl get ns
NAME STATUS AGE
default Active 5h47m
kube-node-lease Active 5h47m
kube-public Active 5h47m
kube-system Active 5h47m
testing Active 30m
[root@master01 ~]#

  提示:通常情况我们删除对应的资源不使用以上方式删除,一般删除都是直接使用陈述式命令来删除资源;使用delete命令,指定资源类型以及资源名称,如果是名称空间级别的资源,还需要指定名称空间;

  使用声明式apply来创建prod名称空间

[root@master01 ~]# kubectl get ns
NAME STATUS AGE
default Active 5h50m
kube-node-lease Active 5h50m
kube-public Active 5h50m
kube-system Active 5h50m
testing Active 33m
[root@master01 ~]# kubectl apply -f ns-prod.yaml
namespace/prod created
[root@master01 ~]# kubectl get ns
NAME STATUS AGE
default Active 5h50m
kube-node-lease Active 5h50m
kube-public Active 5h50m
kube-system Active 5h50m
prod Active 4s
testing Active 33m
[root@master01 ~]# kubectl apply -f ns-prod.yaml
namespace/prod unchanged
[root@master01 ~]# kubectl apply -f ns-prod.yaml
namespace/prod unchanged
[root@master01 ~]#

  提示:apply是一个声明式接口命令,它可以重复执行多次,只要发现对应配置文件中定义的资源属性和当前资源属性不吻合,它就会尝试应用配置文件中属性,让当前资源属性或状态和配置文件中定义的属性和状态保持一致,如果配置文件中的资源状态和属性和当前资源的状态和属性吻合,它就告诉我们配置没有变化;很显然apply这个命令是我们想要用的命令;

  以上就是一个最最简单的使用资源配置清单的方式来创建资源,在k8s上资源有很多类型,不同类型的资源定义的属性各有不同,我们要想写好一个资源配置清单,首先就需要了解对应类型的资源,该有哪些属性,我们怎么才能知道对应资源该有哪些属性呢?很简单查文档呀,我们可以去k8s的官方文档中找对应资源类型的资源清单配置说明;https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20这个网站上k8s-1.20这个版本的相关api说明,我们可以去该网站查询对应类型资源的api字段值的类型,以及字段说明等等;如果你在浏览器中由于各种不可描述的原因,你打不开k8s官网,还有一个办法就是直接在命令行使用命令来查;

  示例:查看ns类型的资源说明

[root@master01 ~]# kubectl explain ns
KIND: Namespace
VERSION: v1 DESCRIPTION:
Namespace provides a scope for Names. Use of multiple namespaces is
optional. 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>
Spec defines the behavior of the Namespace. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status status <Object>
Status describes the current status of a Namespace. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status [root@master01 ~]#

  提示:上述命令就可以列出ns类型的资源应该怎么定义;对应字段的值的类型,其中如果对应字段的值为object,我们还可以使用点号继续查询对应字段的定义说明;

  示例:查看ns类型资源中的spec字段的详细定义说明

[root@master01 ~]# kubectl explain ns.spec
KIND: Namespace
VERSION: v1 RESOURCE: spec <Object> DESCRIPTION:
Spec defines the behavior of the Namespace. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status NamespaceSpec describes the attributes on a Namespace. FIELDS:
finalizers <[]string>
Finalizers is an opaque list of values that must be empty to permanently
remove object from storage. More info:
https://kubernetes.io/docs/tasks/administer-cluster/namespaces/ [root@master01 ~]#

  提示:如果对应字段的值有“[]”表示该字段的值可以是一个对应数据类型的数组或列表;如果后面还-require-表示该字段是必选字段,必须要定义;

  示例:定义自助式pod资源配置清单

[root@master01 ~]# cat pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod-demo
namespace: testing
spec:
containers:
- image: nginx:1.14-alpine
imagePullPolicy: IfNotPresent
name: nginx
resources: {}
dnsPolicy: ClusterFirst
priority: 0
restartPolicy: Always
schedulerName: default-scheduler
[root@master01 ~]#

  提示:以上配置清单中定义了创建一个名为nginx-pod-demo的pod创建方法,其中在metadata字段中最重要的两个字段是name和namespace,如果没有给定这两个字段,名字它会随机生成,名称空间为default;spec字段中最核心的就是containers字段的定义;这个字段的值为一个数组,这意味着一个pod里可以定义多个容器;在配置文件中使用"-"来表示应用列表或数组;image字段用来描述对应容器要用的镜像;imagePullPolicy字段用于描述拖镜像的策略,一般这个字段有三个值,第一个是Never表示从不到互联网上拖镜像,第二个是Always表示不管本地有没有对应镜像,都要到互联网仓库中拖镜像;第三个是IfNotPresent表示如果本地有就不去互联网拖镜像,如果没有就去互联网仓库拖镜像;一般如果对应镜像给出了指定的版本,这里的下载镜像的策略为IfNotPresent,如果指定镜像的版本为latest,这里的策略就是Always;name是用来描述容器的名称;resources这个字段用于描述对应容器的资源限制,比如最小内存和最大内存等等信息;dnsPolicy用于描述使用dns的策略,ClusterFirst表示集群优先,即k8s集群内部的dns服务kube-dns;priority用于描述对应资源的优先级,这个和进程优先级很类似;restartPolicy用于描述重启策略,Always表示,只要对应资源故障就重启;schedulerName用于描述调度器的名称;默认是default-scheduler,表示使用k8s集群默认的调度器;

  应用资源配置清单,创建自助式pod

[root@master01 ~]# kubectl get pod -n testing
No resources found in testing namespace.
[root@master01 ~]# kubectl apply -f pod-demo.yaml
pod/nginx-pod-demo created
[root@master01 ~]# kubectl get pod -n testing
NAME READY STATUS RESTARTS AGE
nginx-pod-demo 1/1 Running 0 3s
[root@master01 ~]#

  提示:可以看到在testing名称空间下就创建了一个名为nginx-pod-demo的pod;

  示例:定义资源清单创建pod,要求在一个pod中运行两个容器

[root@master01 ~]# cat pod-demo2.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod-demo
namespace: prod
spec:
containers:
- image: nginx:1.14-alpine
name: nginx
- image: busybox:latest
imagePullPolicy: IfNotPresent
name: bbox
command:
- /bin/sh
- -c
- "sleep 86400"
[root@master01 ~]#

  提示:command字段的值是一个字符型列表,主要用于描述对应容器里运行的程序命令;除了把列表的每个元素用“-”来引用以外,我们也可以使用 “[]”来引用;

[root@master01 ~]# cat pod-demo2.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod-demo
namespace: prod
spec:
containers:
- image: nginx:1.14-alpine
name: nginx
- image: busybox:latest
imagePullPolicy: IfNotPresent
name: bbox
command: ["/bin/sh","-c","sleep 86400"]
[root@master01 ~]#

  应用配置清单

[root@master01 ~]# kubectl get pod -n prod
No resources found in prod namespace.
[root@master01 ~]# kubectl apply -f pod-demo2.yaml
pod/nginx-pod-demo created
[root@master01 ~]# kubectl get pod -n prod
NAME READY STATUS RESTARTS AGE
nginx-pod-demo 0/2 ContainerCreating 0 5s
[root@master01 ~]#

  提示:可以看到在prod名称空间下有一个名叫nginx-pod-demo的pod处于containercreating状态;表示该pod里的容器正在处于创建状态;其中ready字段下的数字,右边的2表示pod里有2个容器,左边的数字表示有几个容器准备就绪,0表示一个都没有;

  进入prod名称空间下的nginx-pod-demo pod里的bbox容器

[root@master01 ~]# kubectl exec nginx-pod-demo -c bbox -n prod -it -- /bin/sh
/ # ifconfig
eth0 Link encap:Ethernet HWaddr 76:6E:35:38:55:27
inet addr:10.244.3.8 Bcast:10.244.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:480 (480.0 B) TX bytes:42 (42.0 B) lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) / #

  提示:进入pod里的一个容器,如果对应pod里只有一个容器,不用-c指定容器名称,直接指定pod名称即可;如果一个pod里有多个容器,需要用-c选项指定容器的名称;如果进入容器需要执行命令,需要用“--”隔开,后面写要执行的命令;

  查看bbox容器里监听端口

/ # netstat -tnl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
/ # ps aux
PID USER TIME COMMAND
1 root 0:00 sleep 86400
8 root 0:00 /bin/sh
16 root 0:00 ps aux
/ #

  提示:我们在bbox里没有运行任何web服务,它怎么监听80端口呢?原因是在同一个pod里的所有容器都共享同一网络名称空间,这也意味着我们访问bbox里的80,就可以访问到nginx容器;

  测试:访问bbox容器里的80端口,看看是否访问到nginx容器里的服务呢?

/ # wget -O - -q http://127.0.0.1
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p> <p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p>
</body>
</html>
/ #

  提示:可以看到我们在bbox容器里访问lo接口上的80端口能够访问到nginx容器提供的服务;

  查看容器日志

[root@master01 ~]# kubectl get pod -n prod
NAME READY STATUS RESTARTS AGE
nginx-pod-demo 2/2 Running 0 10m
[root@master01 ~]# kubectl logs -n prod nginx-pod-demo -c nginx
127.0.0.1 - - [08/Dec/2020:13:43:37 +0000] "GET / HTTP/1.1" 200 612 "-" "Wget" "-"
[root@master01 ~]#

  提示:如果我们要一直监视着对应容器的日志变化,也可以使用-f,这个有点类似tail命令中的-f选项;

容器编排系统之Pod资源配置清单基础

  提示:如果对应pod只有一个容器,我们只需要指定其pod名称即可;

[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-dep-5bc4d8cc74-cvkbc 1/1 Running 0 3h1m
myapp-dep-5bc4d8cc74-gmt7w 1/1 Running 0 3h1m
myapp-dep-5bc4d8cc74-gqhh5 1/1 Running 0 3h6m
ngx-dep-5c8d96d457-w6nss 1/1 Running 0 4h12m
[root@master01 ~]# kubectl logs ngx-dep-5c8d96d457-w6nss
10.244.0.0 - - [08/Dec/2020:09:43:19 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.244.0.0 - - [08/Dec/2020:10:07:41 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.244.1.0 - - [08/Dec/2020:10:07:46 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.244.0.0 - - [08/Dec/2020:10:31:58 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.244.0.0 - - [08/Dec/2020:10:32:24 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.244.0.0 - - [08/Dec/2020:10:32:29 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.244.0.0 - - [08/Dec/2020:10:36:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
[root@master01 ~]#

  提示:默认不指定名称空间,就是default名称空间;

  pod暴露端口

  所谓暴露端口是指把pod里运行的容器监听的端口暴露到外部网络能够访问的端口上;在k8s上使用资源配置清单创建pod时,我们可以在定义容器时暴露容器的端口;通常暴露端口的方式有两种,一种是共享宿主机的名称空间,让其pod里的网络和宿主机网络名称空间在一个名称空间下;其次是使用端口映射的方式,所谓端口映射就是把pod里容器监听的端口映射在宿主机上的某一个端口;外部网络直接访问对应宿主机端口即可访问到对应pod里的容器;pod所属网络还是pod网络;

  示例:定义资源配置清单,明确定义共享宿主机网络名称空间

[root@master01 ~]# cat pod-demo3.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod-demo3
namespace: prod
spec:
containers:
- image: nginx:1.14-alpine
imagePullPolicy: IfNotPresent
name: nginx
hostNetwork: true
[root@master01 ~]#

  提示:这里需要注意一点,hostNetwork这个字段是spec字段里的属性,缩进要和containers字段对其;

  应用配置清单

[root@master01 ~]# kubectl get pod -n prod
NAME READY STATUS RESTARTS AGE
nginx-pod-demo 2/2 Running 0 43m
[root@master01 ~]# kubectl apply -f pod-demo3.yaml
pod/nginx-pod-demo3 created
[root@master01 ~]# kubectl get pod -n prod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-pod-demo 2/2 Running 0 44m 10.244.3.8 node03.k8s.org <none> <none>
nginx-pod-demo3 1/1 Running 0 15s 192.168.0.45 node02.k8s.org <none> <none>
[root@master01 ~]#

  提示:可以看到应用资源配置清单以后,对应在prod名称空间下就有一个名为nginx-pod-demo3的pod运行起来了,并且其网络为宿主机网络;

  验证:登录node02上查看是否80端口处于监听?

[root@master01 ~]# ssh node02
Last login: Tue Dec 8 16:28:33 2020 from 192.168.0.232
[root@node02 ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:80 *:*
LISTEN 0 128 *:22 *:*
LISTEN 0 100 127.0.0.1:25 *:*
LISTEN 0 128 127.0.0.1:45734 *:*
LISTEN 0 128 127.0.0.1:10248 *:*
LISTEN 0 128 127.0.0.1:10249 *:*
LISTEN 0 128 :::10256 :::*
LISTEN 0 128 :::22 :::*
LISTEN 0 100 ::1:25 :::*
LISTEN 0 128 :::10250 :::*
[root@node02 ~]#

  提示:可以看到node02上80端口已经处于监听状态;

  验证:访问node02的80端口,看看是否访问到对应nginx-pod-demo3 pod里运行的nginx容器呢?

容器编排系统之Pod资源配置清单基础

  提示:在外部使用浏览器访问pod所在主机的ip地址的80端口能够正常访问到对应pod里的容器;

  示例:使用资源清单定义创建pod时,指定将容器端口映射的对应宿主机的某个端口

[root@master01 ~]# cat pod-demo4.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod-demo4
namespace: prod
spec:
containers:
- image: nginx:1.14-alpine
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
hostPort: 8080
name: web
protocol: TCP
[root@master01 ~]#

  提示:在使用资源清单定义暴露容器端口时,需要使用ports字段,该字段的值为一个列表对象,里面主要有containerPort字段,该字段用于描述容器监听端口,hostPort用于描述要把容器端口映射到宿主机上的端口,name用于描述ports这个字段对象的名字,protocol用于描述使用的协议,默认不指定就是TCP,如果指定对应TCP或UDP必须大写;

  应用配置清单

[root@master01 ~]# kubectl get pod -n prod
NAME READY STATUS RESTARTS AGE
nginx-pod-demo 2/2 Running 0 67m
nginx-pod-demo3 1/1 Running 0 23m
[root@master01 ~]# kubectl apply -f pod-demo4.yaml
pod/nginx-pod-demo4 created
[root@master01 ~]# kubectl get pod -n prod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-pod-demo 2/2 Running 0 68m 10.244.3.8 node03.k8s.org <none> <none>
nginx-pod-demo3 1/1 Running 0 24m 192.168.0.45 node02.k8s.org <none> <none>
nginx-pod-demo4 1/1 Running 0 14s 10.244.1.7 node01.k8s.org <none> <none>
[root@master01 ~]#

  提示:可以看到对应的pod已经正常处于运行状态,并且pod网络ip地址也是一个pod网络的地址;该pod被调度到node01上运行;

  验证:查看对应node01上是否监听8080端口?

[root@master01 ~]# ssh node01
Last login: Tue Dec 8 16:30:16 2020 from 192.168.0.232
[root@node01 ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 127.0.0.1:46580 *:*
LISTEN 0 128 *:22 *:*
LISTEN 0 100 127.0.0.1:25 *:*
LISTEN 0 128 127.0.0.1:10248 *:*
LISTEN 0 128 127.0.0.1:10249 *:*
LISTEN 0 128 :::10256 :::*
LISTEN 0 128 :::22 :::*
LISTEN 0 100 ::1:25 :::*
LISTEN 0 128 :::10250 :::*
[root@node01 ~]#

  提示:在pod所在宿主机上并没有发现8080端口处于监听状态;

  验证:访问node01的8080端口,看看是否能够被访问?

容器编排系统之Pod资源配置清单基础

  提示:访问node01的8080端口能够正常访问到对应pod里的容器;这说明端口映射的方式不会监听任何端口,它只会体现在iptables或ipvs规则中;

  查看对应pod所在主机上的iptables规则

[root@node01 ~]# iptables -t nat -nvL|grep 8080
0 0 CNI-HOSTPORT-SETMARK tcp -- * * 10.244.1.0/24 0.0.0.0/0 tcp dpt:8080
0 0 CNI-HOSTPORT-SETMARK tcp -- * * 127.0.0.1 0.0.0.0/0 tcp dpt:8080
1 52 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:10.244.1.7:80
1 52 CNI-DN-fca14cb4785a6479cf635 tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* dnat name: "cbr0" id: "11f45eaf41a77266233e58f57abce144ebf7da0d8924a7ca490d2f64dacc456c" */ multiport dports 8080
[root@node01 ~]#

  提示:在对应pod所在宿主机上的iptables规则中可以看到有一条DNAT规则,明确写了任何源地址访问,访问到目标端口为8080,就DNAT到10.244.1.7的80端口上;而对应10.244.1.7这个地址恰好就是对应的podip地址;

  以上就是使用资源配置清单定义pod资源常用到的一些属性说明和演示,以及pod里的容器端口暴露的两种方式,但是我们手动定义创建pod资源,一旦删除,它不会自动恢复,所以这种自主式pod通常在k8s上应用的很少;通常跑一个pod应该使用pod控制器来跑,这样即便对应的pod故障了,pod控制器能够帮助我们恢复重建pod;