Kubernetes中Pod介绍
1、Pod介绍
Pod 是 kubernetes 最重要的基本概念，每个 Pod 都有一个特殊的被称为根容器的 Pause 容器。Pause 容器对应
的镜像属于 kubernetes 平台的一部分，除了 Pause 容器，每个 Pod 还包含一个或多个紧密相关的用户业务容
器，Pod的组成如下所示。
为什么 kubernetes 会设计出一个全新的 Pod 的概念并且 Pod 有这样特殊的组成结构?
原因之一：在一组容器作为一个单元的情况下，我们难以简单地对整体进行判断及有效地行动。比如，一个容器
死亡了，此时算是整体死亡么? 是N/M的死亡率么? 引入业务无关并且不易死亡的 Pause 容器作为 Pod 的根容
器，以它的状态代表整个容器组的状态，就简单、巧妙地解决了这个难题。
原因之二：Pod 里的多个业务容器共享 Pause 容器的 IP，共享 Pause 容器挂接的 Volume，这样既简化了密切关
联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。
kubernetes 为每个 Pod 都分配了唯一的 IP 地址，称之为 Pod IP，一个 Pod 里的多个容器共享 Pod IP 地址。
kubernetes 要求底层网络支持集群内任意两个 Pod 之间的 TCP/IP 直接通信，这通常采用虚拟二层网络技术来实
现，例如 Flannel、Open vSwitch 等，因此我们需要牢记一点：在 kubernetes 里，一个 Pod 里的容器与另外主
机上的 Pod 容器能够直接通信。
Pod 其实有两种类型：普通的 Pod 及静态 Pod(Static Pod)。后者比较特殊，它并没被存放在 kubernetes 的 etcd
存储里，而是被存放在某个具体的 Node 上的一个具体文件中，并且只在此 Node 上启动、运行。而普通的 Pod
一旦被创建，就会被放入 etcd 中存储，随后会被 kubernetes Master 调度到某个具体的 Node 上并进行绑定，随
后该 Pod 被对应的 Node 上的 kubelet 进程实例化成一组相关的 Docker 容器并启动。在默认情况下，当 Pod 里
的某个容器停止时，kubernetes 会自动检测到这个问题并且重新启动这个 Pod (重启 Pod 里的所有容器)，如果
Pod 所在的 Node 宕机，就会将这个 Node 上的所有 Pod 重新调度到其他节点上。Pod、容器与 Node 的关系如
下所示。
kubernetes 里的所有资源对象都可以采用 YAML 或者 JSON 格式的文件来定义或描述。
下面是我们在之前的入门案例里用到的 myweb 这个 Pod 的资源定义文件：
apiVersion: v1
# 副本控制器RC
kind: ReplicationController
metadata:
# RC的名称,全局唯一
name: myweb
spec:
# Pod副本的期待数量
replicas: 2
selector:
# 符合目标的Pod拥有此标签
app: myweb
# 根据此模板创建Pod的副本(实例)
template:
metadata:
labels:
# Pod副本拥有的标签,对应RC的Selector
app: myweb
spec:
# Pod内容器的定义部分
containers:
# 容器的名称
- name: myweb
# 容器对应的 Docker Image
image: kubeguide/tomcat-app:v1
ports:
# 容器应用监听的端口号
- containerPort: 8080
env:
- name: MYSQL_SERVICE_HOST
value: 'mysql'
- name: MYSQL_SERVICE_PORT
value: '3306'
Kind 为 Pod 表明这是一个 Pod 的定义，metadata 里的 name 属性为 Pod 的名称，在 metadata 里还能定义资
源对象的标签，这里声明 myweb 拥有一个 name=myweb 的标签。在 Pod 里所包含的容器组的定义则在spec属
性中声明，这里定义了一个名为 myweb、对应镜像为 kubeguide/tomcat-app:v1 的容器，该容器注入了名为
MYSQL_SERVICE_HOST=‘mysql’ 和 MYSQL_SERVICE_PORT=‘3306’ 的环境变量(env关键字)，并且在 8080 端口
(containerPort)启动容器进程。
Pod 的 IP 加上这里的容器端口(containerPort)，组成了一个新的概念—Endpoint，它代表此 Pod 里的一个服务
进程的对外通信地址。一个 Pod 也存在具有多个 Endpoint 的情况，比如当我们把 Tomcat 定义为一个 Pod 时，
可以对外暴露管理端口与服务端口这两个 Endpoint。
我们所熟悉的 Docker Volume 在 kubernetes 里也有对应的概念—Pod Volume，后者有一些扩展，比如可以用
分布式文件系统 GlusterFS 实现后端存储功能；Pod Volume 是被定义在 Pod 上，然后被各个容器挂载到自己的
文件系统中的。
这里顺便提一下 Kubernetes 的Event概念，Event 是一个事件的记录，记录了事件的最早产生时间、最后重现时
间、重复次数、发起者、类型，以及导致此事件的原因等众多信息。Event 通常会被关联到某个具体的资源对象
上，是排查故障的重要参考信息，之前我们看到 Node 的描述信息包括了 Event，而 Pod 同样有 Event 记录，当
我们发现某个 Pod 迟迟无法创建时，可以用 kubectl describe pod xxxx 来查看它的描述信息，以定位问题的
成因，比如下面这个 Event 记录信息表明 Pod 里的一个容器被探针检测为失败一次：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 21s default-scheduler Successfully assigned default/myweb to slave2
Normal Pulling 20s kubelet Pulling image "kubeguide/tomcat-app:v3"
Warning Failed 0s kubelet Failed to pull image "kubeguide/tomcat-app:v3": rpc error: code = Unknown desc = Error response from daemon: manifest for kubeguide/tomcat-app:v3 not found: manifest unknown: manifest unknown
Warning Failed 0s kubelet Error: ErrImagePull
每个 Pod 都可以对其能使用的服务器上的计算资源设置限额，当前可以设置限额的计算资源有 CPU 与 Memory
两种，其中 CPU 的资源单位为 CPU(Core) 的数量，是一个绝对值而非相对值。
对于绝大多数容器来说，一个 CPU 的资源配额相当大，所以在 Kubernetes 里通常以千分之一的 CPU 配额为最小
单位，用 m 来表示。通常一个容器的 CPU 配额被定义为 100～300m，即占用 0.1～0.3 个 CPU。由于 CPU 配额
是一个绝对值，所以无论在拥有一个 Core 的机器上，还是在拥有 48 个 Core 的机器上，100m 这个配额所代表的
CPU 的使用量都是一样的。与 CPU 配额类似，Memory 配额也是一个绝对值，它的单位是内存字节数。
在 Kubernetes 里，一个计算资源进行配额限定时需要设定以下两个参数。
-
Requests：该资源的最小申请量，系统必须满足要求。
-
Limits：该资源最大允许使用的量，不能被突破，当容器试图使用超过这个量的资源时，可能会被
Kubernetes 杀掉并重启。
通常，我们会把 Requests 设置为一个较小的数值，符合容器平时的工作负载情况下的资源需求，而把 Limit 设置
为峰值负载情况下资源占用的最大量。下面这段定义表明 MySQL 容器申请最少 0.25 个 CPU 及 64MiB 内存，在
运行过程中 MySQL 容器所能使用的资源配额为 0.5 个 CPU 及 128MiB 内存：
spec:
containers:
- name: db
image: mysql:5.7
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
上边的内容只是简单的介绍，后面会详细地进行介绍。
2、Pod定义详解
YAML 格式的 Pod 定义文件的完整内容如下：
对各属性的详细说明如下所示：
Kind 为 Pod 表明这是一个 Pod 的定义，metadata 里的 name 属性为 Pod 的名称，在 metadata 里还能定义资
源对象的标签。
Pod的 IP 加上这里的容器端口(containerPort)，组成了一个新的概念—Endpoint，它代表此 Pod 里的一个服务进
程的对外通信地址。一个 Pod 也存在具有多个 Endpoint 的情况，比如当我们把 Tomcat 定义为一个 Pod 时，可
以对外暴露管理端口与服务端口这两个 Endpoint。
我们所熟悉的Docker Volume在kubernetes里也有对应的概念—Pod Volume，后者有一些扩展，比如可以用分布
式文件系统 GlusterFS 实现后端存储功能；Pod Volume 是被定义在 Pod 上，然后被各个容器挂载到自己的文件
系统中的。
3、Pod的基本用法
在对 Pod 的用法进行说明之前，有必要先对 Docker 容器中应用的运行要求进行说明。
在使用 Docker 时，可以使用 docker run 命令创建并启动一个容器。而在 Kubernetes 系统中对长时间运行容器
的要求是：其主程序需要一直在前台执行。如果我们创建的 Docker 镜像的启动命令是后台执行程序，例如 Linux
脚本：nohup ./start.sh，则在 kubelet 创建包含这个容器的 Pod 之后运行完该命令，即认为 Pod 执行结束，将
立刻销毁该 Pod。如果为该 Pod 定义了 ReplicationController，则系统会监控到该 Pod 已经终止，之后根据 RC
定义中 Pod 的 replicas 副本数量生成一个新的 Pod。一旦创建新的 Pod，就在执行完启动命令后陷入无限循环的
过程中。这就是 Kubernetes 需要我们自己创建的 Docker 镜像并以一个前台命令作为启动命令的原因。
对于无法改造为前台执行的应用，也可以使用开源工具 Supervisor 辅助进行前台运行的功能。Supervisor 提供了
一种可以同时启动多个后台应用，并保持 Supervisor 自身在前台执行的机制，可以满足 Kubernetes 对容器的启
动要求。关于 Supervisor 的安装和使用，请参考官网 http://supervisord.org 的文档说明。
下面对 Pod 对容器的封装和应用进行说明。
Pod 可以由 1 个或多个容器组合而成，下面的例子中，名为 frontend 的 Pod 只由一个容器组成。
配置文件 001-frontend.yaml 的内容：
apiVersion: v1
kind: Pod
metadata:
name: frontend
labels:
name: frontend
spec:
containers:
- name: frontend
image: kubeguide/guestbook-php-frontend
env:
- name: GET_HOSTS_FROM
value: env
ports:
- containerPort: 80
[root@master cha3]# kubectl apply -f 001-frontend.yaml
pod/frontend created
[root@master cha3]# kubectl get pod
NAME READY STATUS RESTARTS AGE
frontend 1/1 Running 0 21s
这个 frontend Pod 在成功启动之后，将启动 1 个 Docker 容器。
另一种场景是，当 frontend 和 redis 两个容器应用为紧耦合的关系，并组合成一个整体对外提供服务时，应将这
两个容器打包为一个 Pod，如下所示。
配置文件 002-frontend-localredis-pod.yaml 的内容如下：
apiVersion: v1
kind: Pod
metadata:
name: redis-php
labels:
name: redis-php
spec:
containers:
- name: frontend
image: kubeguide/guestbook-php-frontend:localredis
ports:
- containerPort: 80
- name: redis
image: kubeguide/redis-master
ports:
- containerPort: 6379
属于同一个 Pod 的多个容器应用之间相互访问时仅需要通过 localhost 就可以通信，使得这一组容器被绑定在了
一个环境中。
运行 kubectl create 命令创建该 Pod：
[root@master cha3]# kubectl create -f 002-frontend-localredis-pod.yaml
pod/redis-php created
查看已经创建的 Pod：
[root@master cha3]# kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend 1/1 Running 0 5m9s
redis-php 2/2 Running 0 19s
可以看到 READY 信息为 2/2，表示 Pod 中的两个容器都成功运行了。
查看这个 Pod 的详细信息，可以看到两个容器的定义及创建的过程( Event 事件信息)：
[root@master cha3]# kubectl describe pod redis-php
Name: redis-php
Namespace: default
Priority: 0
Node: slave2/192.168.21.202
Start Time: Sun, 02 Jul 2023 10:03:41 +0800
Labels: name=redis-php
Annotations: <none>
Status: Running
IP: 10.244.140.68
IPs:
IP: 10.244.140.68
Containers:
frontend:
Container ID: docker://9990568e9fcd1e0cfd375a444fc6fb013daa4df7dd5dccc0c33f2ffb83dcd2b4
Image: kubeguide/guestbook-php-frontend:localredis
Image ID: docker-pullable://kubeguide/guestbook-php-frontend@sha256:37c2c1dcfcf0a51bf9531430fe057bcb1d4b94c64048be40ff091f01e384f81e
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sun, 02 Jul 2023 10:03:42 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-qkxd6 (ro)
redis:
Container ID: docker://1244ef09f32b6e5f06c14c79fc0f979533cd3dca92020022e56e05ccf490f740
Image: kubeguide/redis-master
Image ID: docker-pullable://kubeguide/redis-master@sha256:e11eae36476b02a195693689f88a325b30540f5c15adbf531caaecceb65f5b4d
Port: 6379/TCP
Host Port: 0/TCP
State: Running
Started: Sun, 02 Jul 2023 10:03:44 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-qkxd6 (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-qkxd6:
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 2m16s default-scheduler Successfully assigned default/redis-php to slave2
Normal Pulled 2m15s kubelet Container image "kubeguide/guestbook-php-frontend:localredis" already present on machine
Normal Created 2m15s kubelet Created container frontend
Normal Started 2m15s kubelet Started container frontend
Normal Pulling 2m15s kubelet Pulling image "kubeguide/redis-master"
Normal Pulled 2m13s kubelet Successfully pulled image "kubeguide/redis-master" in 1.795814295s
Normal Created 2m13s kubelet Created container redis
Normal Started 2m13s kubelet Started container redis
这里顺便提一下 kubernetes 的 Event 概念，Event 是一个事件的记录，记录了事件的最早产生时间、最后重现
时间、重复次数、发起者、类型，以及导致此事件的原因等众多信息。Event 通常会被关联到某个具体的资源对象
上，是排查故障的重要参考信息。当我们发现某个 Pod 迟迟无法创建时，可以用 kubectl describe pod xxxx 来查
看它的描述信息，以定位问题的成因，一个 Event 记录信息表明 Pod 里的一个容器被探针检测为失败一次。例
如：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 21s default-scheduler Successfully assigned default/myweb to slave2
Normal Pulling 20s kubelet Pulling image "kubeguide/tomcat-app:v3"
Warning Failed 0s kubelet Failed to pull image "kubeguide/tomcat-app:v3": rpc error: code = Unknown desc = Error response from daemon: manifest for kubeguide/tomcat-app:v3 not found: manifest unknown: manifest unknown
Warning Failed 0s kubelet Error: ErrImagePull
4、静态Pod
静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod，它们不能通过 API Server 进行管理，无法与
ReplicationController、Deployment 或者 DaemonSet 进行关联，并且 kubelet 无法对它们进行健康检查。静态
Pod 总是由 kubelet 创建的，并且总在 kubelet 所在的 Node 上运行。
创建静态 Pod 有两种方式：配置文件方式和 HTTP 方式。
4.1 配置文件方式
首先需要时设定 kubelet 启动参数 --pod-manifest-path 或者在 kubelet 的配置文件中设定 staticPodPath，
指定的路径是kubelet监控的路径(如果k8s集群由kubeadm搭建，那默认存储在录/etc/kubernetes/manifests
下)，kubelet 会定期的扫描该目录下的 YAML/JSON 文件来创建/修改/删除静态 Pod。
注意：声明文件是标准的 Pod 定义文件，以 JSON 或者 YAML 格式存储在指定目录；kubelet 扫描目录的时候会
忽略以点开头的文件。
查看当前节点 kubelet 监控静态文件的路径。
使用 systemctl cat kubelet 命令查看通过 systemd 配置的与 kubelet 有关的所有配置文件的路径与内容。
[root@master ~]# systemctl cat kubelet
# /usr/lib/systemd/system/kubelet.service
[Unit]
Description=kubelet: The Kubernetes Node Agent
Documentation=https://kubernetes.io/docs/
Wants=network-online.target
After=network-online.target
[Service]
ExecStart=/usr/bin/kubelet
Restart=always
StartLimitInterval=0
RestartSec=10
[Install]
WantedBy=multi-user.target
# /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/et
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS v
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user sho
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be so
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
通过查看配置文件 /var/lib/kubelet/config.yaml 可以当前节点 kubelet 监控静态文件的路径为：
/etc/kubernetes/manifests。
[root@master cha3]# cat /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
anonymous:
enabled: false
webhook:
cacheTTL: 0s
enabled: true
x509:
clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
mode: Webhook
webhook:
cacheAuthorizedTTL: 0s
cacheUnauthorizedTTL: 0s
cgroupDriver: systemd
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
logging: {}
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
rotateCertificates: true
runtimeRequestTimeout: 0s
shutdownGracePeriod: 0s
shutdownGracePeriodCriticalPods: 0s
staticPodPath: /etc/kubernetes/manifests # 该路径
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
[root@master cha3]# ls /etc/kubernetes/manifests
etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml
在目录 /etc/kubernetes/manifests 中放入 003-static-web.yaml 文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
name: static-web
spec:
containers:
- name: static-web
image: nginx
ports:
- name: web
containerPort: 80
等待一会儿，查看本机中已经启动的容器：
[root@master cha3]# docker ps | grep static-web
2162d73def94 nginx "/docker-entrypoint.…" 25 seconds ago Up 25 seconds k8s_static-web_static-web-master_default_d281bcc9e1031be157468bab81ab2b96_0
59252476a5ef registry.aliyuncs.com/google_containers/pause:3.4.1 "/pause" 43 seconds ago Up 41 seconds k8s_POD_static-web-master_default_d281bcc9e1031be157468bab81ab2b96_0
可以看到一个 Nginx 容器已经被 kubelet 成功创建了出来。
到 Master 上查看 Pod 列表，可以看到这个 static pod：
[root@master cha3]# kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend 1/1 Running 0 53m
redis-php 2/2 Running 0 48m
static-web-master 1/1 Running 0 88s # 该pod
修改 Static Pod 直接修改当前节点 kubelet 监控静态文件的目录下 Pod 声明文件即可自动修改静态Pod配置。
由于静态 Pod 无法通过 API Server 直接管理，所以在 Master 上尝试删除这个 Pod 时，会使其变成 Pending 状
态，且不会被删除。
[root@master cha3]# kubectl delete pod static-web-master
pod "static-web-master" deleted
[root@master cha3]# kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend 1/1 Running 0 55m
redis-php 2/2 Running 0 50m
static-web-master 0/1 Pending 0 4s
过一会 kubelet 会自动重启 Pod：
[root@master cha3]# kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend 1/1 Running 0 56m
redis-php 2/2 Running 0 51m
static-web-master 1/1 Running 0 49s
删除该 Pod 的操作只能是到其所在节点上将其定义文件 003-static-web.yaml 从
/etc/kubernetes/manifests目录下删除。
[root@master cha3]# rm -f /etc/kubernetes/manifests/003-static-web.yaml
再次查看 Pod：
[root@master cha3]# kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend 1/1 Running 0 58m
redis-php 2/2 Running 0 53m
4.2 HTTP方式
通过设置 kubelet 的启动参数 --manifest-url，kubelet 将会定期从该 URL 地址下载 Pod 的定义文件，并
以 .yaml 或 .json 文件的格式进行解析，然后创建 Pod，其实现方式与配置文件方式是一致的。
Environment="KUBELET_SYSTEM_PODS_ARGS=--manifest-url=<manifest-url>"
重启节点 kubelet 服务使配置生效：
systemctl daemon-reload
systemctl restart kubelet
5、Pod容器共享Volume
同一个 Pod 中的多个容器能够共享 Pod 级别的存储卷 Volume。Volume 可以被定义为各种类型，多个容器各自
进行挂载操作，将一个 Volume 挂载为容器内部需要的目录，如下所示。
在下面的例子中，在 Pod 内包含两个容器：tomcat 和 busybox，在 Pod 级别设置 Volume “app-logs”，用于
tomcat 向其中写日志文件，busybox 读日志文件。
配置文件 004-pod-volume-applogs.yaml 的内容如下：
apiVersion: v1
kind: Pod
metadata:
name: volume-pod
spec:
containers:
- name: tomcat
image: tomcat
ports:
- containerPort: 8080
volumeMounts:
- name: app-logs
mountPath: /usr/local/tomcat/logs
- name: busybox
image: busybox
command: ["sh", "-c", "tail -f /logs/catalina*.log"]
volumeMounts:
- name: app-logs
mountPath: /logs
volumes:
- name: app-logs
emptyDir: {}
[root@master cha3]# kubectl create -f 004-pod-volume-applogs.yaml
pod/volume-pod created
[root@master cha3]# kubectl get pod
NAME READY STATUS RESTARTS AGE
frontend 1/1 Running 0 79m
redis-php 2/2 Running 0 74m
volume-pod 2/2 Running 0 50s
这里设置的 Volume 名为 app-logs，类型为 emptyDir，也可以设置为其他类型，挂载到 tomcat 容器内的
/usr/local/tomcat/logs 目录，同时挂载到 logreader 容器内的 /logs 目录。
tomcat 容器在启动后会向 /usr/local/tomcat/logs 目录写文件，logreader 容器就可以读取其中的文件了。
logreader 容器的启动命令为 tail -f /logs/catalina*.log，我们可以通过 kubectl logs 命令查看
logreader 容器的输出内容：
[root@master cha3]# kubectl logs volume-pod -c busybox
02-Jul-2023 03:17:28.766 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/usr/local/tomcat/temp
02-Jul-2023 03:17:28.781 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [1.2.31] using APR version [1.7.0].
02-Jul-2023 03:17:28.781 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true], UDS [true].
02-Jul-2023 03:17:28.785 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1k 25 Mar 2021]
02-Jul-2023 03:17:29.134 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
02-Jul-2023 03:17:29.157 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [731] milliseconds
02-Jul-2023 03:17:29.243 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
02-Jul-2023 03:17:29.243 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/10.0.14]
02-Jul-2023 03:17:29.254 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
02-Jul-2023 03:17:29.263 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [105] milliseconds
这个文件为 tomcat 生成的日志文件 /usr/local/tomcat/logs/catalina.<date>.log 的内容。登录 tomcat
容器进行查看：
[root@master cha3]# kubectl exec -ti volume-pod -c tomcat -- /bin/bash
root@volume-pod:/usr/local/tomcat# ls
BUILDING.txt LICENSE README.md RUNNING.txt conf logs temp webapps.dist
CONTRIBUTING.md NOTICE RELEASE-NOTES bin lib native-jni-lib webapps work
root@volume-pod:/usr/local/tomcat#
root@volume-pod:/usr/local/tomcat# ls logs
catalina.2023-07-02.log localhost_access_log.2023-07-02.txt
root@volume-pod:/usr/local/tomcat# exit
exit
[root@master cha3]# kubectl exec -ti volume-pod -c tomcat -- ls /usr/local/tomcat/logs
catalina.2023-07-02.log localhost_access_log.2023-07-02.txt
[root@master cha3]# kubectl exec -ti volume-pod -c tomcat -- tail /usr/local/tomcat/logs/catalina.2023-07-02.log
02-Jul-2023 03:17:28.766 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/usr/local/tomcat/temp
02-Jul-2023 03:17:28.781 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [1.2.31] using APR version [1.7.0].
02-Jul-2023 03:17:28.781 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true], UDS [true].
02-Jul-2023 03:17:28.785 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1k 25 Mar 2021]
02-Jul-2023 03:17:29.134 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
02-Jul-2023 03:17:29.157 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [731] milliseconds
02-Jul-2023 03:17:29.243 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
02-Jul-2023 03:17:29.243 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/10.0.14]
02-Jul-2023 03:17:29.254 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
02-Jul-2023 03:17:29.263 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [105] milliseconds
查看 busybox：
[root@master cha3]# kubectl exec -ti volume-pod -c busybox -- ls
bin dev etc home logs proc root sys tmp usr var
[root@master cha3]# kubectl exec -ti volume-pod -c busybox -- ls logs
catalina.2023-07-02.log localhost_access_log.2023-07-02.txt
[root@master cha3]# kubectl exec -ti volume-pod -c busybox -- tail /logs/catalina.2023-07-02.log
02-Jul-2023 03:17:28.766 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/usr/local/tomcat/temp
02-Jul-2023 03:17:28.781 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [1.2.31] using APR version [1.7.0].
02-Jul-2023 03:17:28.781 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true], UDS [true].
02-Jul-2023 03:17:28.785 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1k 25 Mar 2021]
02-Jul-2023 03:17:29.134 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
02-Jul-2023 03:17:29.157 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [731] milliseconds
02-Jul-2023 03:17:29.243 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
02-Jul-2023 03:17:29.243 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/10.0.14]
02-Jul-2023 03:17:29.254 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
02-Jul-2023 03:17:29.263 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [105] milliseconds
6、总结
本节最后给出 Pod 及 Pod 周边对象的示意图作为总结，如下所示，后面部分还会涉及这张图里的对象和概念，
以进一步加强理解。
3245
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
