前文我们了解了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 ~]#
提示：有了这个配置文件，我们就可以照猫画虎定义其他名称空间；
[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名称即可；
[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 ~]#
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所在主机的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端口，看看是否能够被访问？
提示：访问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；
原文链接：/kubernetes/995336.html