当前位置： 首页 > ops >正文

4.pod生命周期和健康检测以及使用kubectl管理Kubernetes容器平台

ops 2025/8/20 13:19:50

pod常见的状态

在K8s集群中，Pod常见的状态如下： 
1、Pending：例如，当你创建一个Pod时，如果你指定了一个特定的节点，但是该节点上已经有其他的Pod运行，并且没有足够的资源来满足你的Pod请求，那么你的Pod将一直处于
Pending 状态，直到有足够的资源被释放或者你重新指定一个节点。2、Running：例如，当你创建一个Pod时，如果你指定了一个Docker容器镜像，并且该镜像
已经被下载到节点上，那么你的Pod将会开始运行，容器会在其中运行，并且Pod将会处于
Running 状态。 3、Succeeded：例如，当你创建一个Pod时，如果你指定了一个具体的任务并且该任务已经成
功完成，那么Pod将会进入Succeeded状态，并且容器将会退出。 4、Failed：例如，当你创建一个Pod时，如果你指定了一个具体的任务并且该任务在执行期间失
败了，那么Pod将会进入Failed状态，并且容器将会退出。 5、Unknown：例如，当你删除一个Pod的控制器时，Kubernetes将会失去对该Pod的监
视，Pod的状态将会变为Unknown。另外，如果Kubernetes系统出现故障或者网络问题，也
有可能导致Pod的状态无法被监视到。 6、ContainerCreating：Pod 已经被Kubernetes 调度到了某个节点上，但是容器还没有开始
创建。 7、Terminating：Pod 正在被删除。 8、CrashLoopBackOff：当一个容器启动失败，并且已经尝试了指定的重启次数（通常是3
次），但是每次都失败了，Kubernetes就会将这个Pod的状态设置为CrashLoopBackOff。这
个状态通常意味着有一些问题需要解决，例如容器配置错误、依赖项缺失等。需要修复这些问题才
能让Pod重新正常运行。 9、ImagePullBackOff：Pod 中的某个容器无法拉取镜像。这通常是因为镜像不存在、认证失败
或者无法连接到镜像仓库。10、CreateContainerConfigError：Pod 中的某个容器无法创建，通常是因为容器配置错误导致的。 11、CreateContainerError：Pod 中的某个容器无法创建，通常是因为资源不足、权限不足等原因导致的。 12、PodInitializing：Pod 正在初始化，包括下载镜像、创建容器等。 
13、Error

pod重启策略

root@ubuntu0:~/matedata/pod# kubectl explain pod.spec.restartPolicy
KIND:     Pod
VERSION:  v1FIELD:    restartPolicy <string>DESCRIPTION:Restart policy for all containers within the pod. One of Always, OnFailure,Never. Default to Always. More info:https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policyKubernetes 提供了三种Pod重启策略，分别是： 
1、Always：无论什么情况下，只要容器退出，或者终止，就会自动重启Pod里的容器。这是默认
的重启策略。 
2、OnFailure：只有当容器以非零状态终止时才会自动重启Pod里的容器，只有当某个容器因为错
误或异常而以非零状态终止时，Kubernetes才会触发Pod的自动重启。如果容器以零状态（也就是正常状态）终止，Kubernetes不会进行自动重启。 
3、Never：Pod里的容器不会被自动重启，除非显式地进行手动操作。always 重启策略
首先创建一个使用Always重启策略的Pod：
root@ubuntu0:~/matedata/pod# cat always-restart-pod.yaml 
apiVersion: v1 
kind: Pod 
metadata: name: always-restart-pod 
spec:nodeName: ubuntu2 restartPolicy: Always containers: - name: always-restart-container image: nginx:latest imagePullPolicy: IfNotPresent root@ubuntu0:~/matedata/pod# kubectl apply -f always-restart-pod.yaml 
pod/always-restart-pod created
root@ubuntu0:~/matedata/pod# kubectl get pods -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
always-restart-pod   1/1     Running   0          3s    10.244.152.74   ubuntu2   <none>           <none>进入到 Pod 内部的容器中：
root@ubuntu0:~/matedata/pod# kubectl exec -it always-restart-pod -- bash
杀死nginx进程
root@always-restart-pod:/#  nginx -s stop 
2025/08/18 03:06:57 [notice] 14#14: signal process started
root@always-restart-pod:/# command terminated with exit code 137
可以看到容器已经重启了一次
root@ubuntu0:~/matedata/pod# kubectl get pods -o wide
NAME                 READY   STATUS    RESTARTS     AGE   IP              NODE      NOMINATED NODE   READINESS GATES
always-restart-pod   1/1     Running   1 (4s ago)   86s   10.244.152.74   ubuntu2   <none>           <none>never 重启策略 
root@ubuntu0:~/matedata/pod# cat never-restart-pod.yaml 
apiVersion: v1 
kind: Pod 
metadata: name: never-restart-pod 
spec: nodeName: ubuntu2restartPolicy: Never containers: - name: always-restart-container image: nginx:latest imagePullPolicy: IfNotPresent 
root@ubuntu0:~/matedata/pod# kubectl apply -f never-restart-pod.yaml 
pod/never-restart-pod created
root@ubuntu0:~/matedata/pod# kubectl get pods -o wide
NAME                READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
never-restart-pod   1/1     Running   0          6s    10.244.152.75   ubuntu2   <none>           <none>进入容器中
root@ubuntu0:~/matedata/pod# kubectl exec -it never-restart-pod -- bash
root@never-restart-pod:/# nginx -s stop
2025/08/18 03:11:14 [notice] 14#14: signal process started
root@never-restart-pod:/# command terminated with exit code 137
root@ubuntu0:~/matedata/pod# 
可以看到并没有重启，
root@ubuntu0:~/matedata/pod# kubectl get pods -o wide
NAME                READY   STATUS      RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
never-restart-pod   0/1     Completed   0          51s   10.244.152.75   ubuntu2   <none>           <none>
上面可以看到容器状态是completed，并且没有重启，这说明重启策略是never，那么pod里容器服务无论如何终止，都不会重启。 onfailure 重启策略 
root@ubuntu0:~/matedata/pod# cat onfailure-restart-pod.yaml 
apiVersion: v1 
kind: Pod 
metadata: name: onfail-restart-pod 
spec:nodeName: ubuntu2 restartPolicy: OnFailure containers: - name: onfail-restart-container image: nginx:latest imagePullPolicy: IfNotPresent 
root@ubuntu0:~/matedata/pod# kubectl apply -f onfailure-restart-pod.yaml 
pod/onfail-restart-pod created
root@ubuntu0:~/matedata/pod# kubectl get pods -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
onfail-restart-pod   1/1     Running   0          4s    10.244.152.76   ubuntu2   <none>           <none>
进入容器内部
root@ubuntu0:~/matedata/pod#  kubectl exec -it onfail-restart-pod -- bash 
杀死nginx进程
root@onfail-restart-pod:/#  nginx -s stop 
2025/08/18 03:14:43 [notice] 14#14: signal process started
root@onfail-restart-pod:/# command terminated with exit code 137
发现退出码是0，，pod里的容器不会重启
root@ubuntu0:~/matedata/pod#  kubectl get pods onfail-restart-pod
NAME                 READY   STATUS      RESTARTS   AGE
onfail-restart-pod   0/1     Completed   0          39s
非正常终止，退出码不为0，pod里的容器会重启

Pod生命周期

Pod的生命周期包括以下几个阶段： 
1、初始化容器（Init Container）阶段： 初始化容器是在Pod启动之前运行的一组容器，它们负责执行一些必要的初始化任务，例如设置环境变量、检查依赖关系、执行数据库迁移等等。只有当所有的初始化容器都成功完成后，主容器才会启动。 
2、主容器（Main Container）阶段： 主容器是Pod中的核心容器，它们负责实际运行应用程序或服务。在启动时，Kubernetes会创建一个或多个主容器，并将它们放置在同一个Pod中。主容器可以是应用程序容器、数据库容器、Web服务器容器等等。 
3、运行时状态（Running State）阶段： 一旦Pod中的所有容器都成功启动，它们会进入Running状态。在这个阶段，容器可以相互通信，并与集群中的其他容器和服务进行交互。 
4、容器重启（Container Restart）阶段： 在Pod运行期间，容器可能会出现故障或崩溃。当容器重新启动时，Kubernetes会记录重启次数，并在出现频繁重启时采取相应的措施，例如自动停止Pod或报警通知管理员。 
5、终止（Termination）阶段： 当Pod不再需要时，Kubernetes会将其终止。在终止阶段，Kubernetes 会向 Pod中的所有容器发送终止信号，并等待它们完成正在进行的工作。一旦所有容器都已经停止，Pod就会被彻底删除。 案例1：演示初始化容器和主容器
假设我们有一个Web应用程序，它需要一个Redis数据库来存储数据。为了确保Web应用程序正常运
行，我们需要在Pod启动之前先启动一个初始化容器，它会检查Redis是否已经准备好，并在必要时等待其准备就绪。一旦Redis准备就绪，初始化容器就会退出，然后主容器开始运行Web应用程序。 
以下是一个简单的Pod配置示例，其中包含了一个初始化容器和一个主容器：root@ubuntu0:~/matedata/pod# cat init.yaml 
apiVersion: v1 
kind: Pod 
metadata: name: my-webapp labels: app: redis 
spec: nodeName: ubuntu2containers: - name: webapp image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 initContainers: - name: init-redis image: busybox imagePullPolicy: IfNotPresent command: ['sh', '-c', 'until nslookup redis; do echo waiting for redis; sleep 2; done;'] 
root@ubuntu0:~/matedata/pod# kubectl apply -f init.yaml 
pod/my-webapp created
root@ubuntu0:~/matedata/pod# kubectl get pods -o wide
NAME                 READY   STATUS      RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
my-webapp            0/1     Init:0/1    0          6s    <none>          ubuntu2   <none>           <none>
在上面的示例中，我们定义了一个名为my-webapp的Pod，其中包含了一个Web容器。此外，我们
还定义了一个名为init-redis的初始化容器，它会执行一个命令来检查Redis是否已经准备就绪。在命令执行期间，初始化容器会等待Redis可用，然后退出。一旦初始化容器退出，主容器就会开始运行Web应用程序。但是我们实际没搭建redis，所以上面容器会一直处在初始化阶段，不会执行主容器。案例2：Pod包含一个初始化容器和一个主容器，主容器会运行一个简单的Web服务器，初始化容器就是写个循环，等待10s。
root@ubuntu0:~/matedata/pod# cat init1.yaml 
apiVersion: v1 
kind: Pod 
metadata: name: my-nginxlabels: app: init-nginx 
spec: nodeName: ubuntu2containers: - name: web image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 command: ["/bin/sh"] args: ["-c", "echo '<h1>Hello Kubernetes!</h1>' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'"] initContainers: - name: init-web image: busybox:1.28 imagePullPolicy: IfNotPresent command: ['sh', '-c', 'echo waiting... && sleep 10'] 
root@ubuntu0:~/matedata/pod# kubectl apply -f init1.yaml 
pod/my-nginx created
root@ubuntu0:~/matedata/pod# kubectl get pods -owide
NAME                 READY   STATUS                  RESTARTS   AGE     IP              NODE      NOMINATED NODE   READINESS GATES
my-nginx             0/1     Init:0/1                0          5s      10.244.152.79   ubuntu2   <none>           <none>10s中就运行成功了
root@ubuntu0:~/matedata/pod# kubectl get pods -owide
NAME                 READY   STATUS                  RESTARTS   AGE     IP              NODE      NOMINATED NODE   READINESS GATES
my-nginx             1/1     Running                 0          25s     10.244.152.79   ubuntu2   <none>           <none>

对Pod内的容器做健康探测

在k8s集群中，可以使用健康探测来监测 Pod 的状态，并根据探测结果来实现自动化容器的重启或故障切换等操作，从而提高应用的可靠性和可用性。下面介绍几种常用的健康探测方式及其应用场景：
1、Liveness Probe（存活探测）： Liveness Probe 用于监测pod内的容器是否处于运行状态。当Liveness Probe 探测失败时，Kubernetes 根据重启策略决定是否重启该容器。适用于需要在容器发生故障时立即进行重启的应用场景，比如 Web 服务器和数据库等应用。
2、Readiness Probe（就绪探测）： Readiness Probe 用于监测pod内的容器是否已经准备好接受流量，即容器是否已经完成初始化并已经启动了应用程序。当容器的 Readiness Probe 探测失败时，Kubernetes 将停止将新的流量转发到该容器。适用于需要应用程序启动较长时间的应用场景，比如大型 Web 应用程序。 
3、Startup Probe（启动探测） Startup Probe 用于监测pod内的容器是否已经启动成功并准备好接受流量。与 Liveness Probe 不同的是，Startup Probe 只会在容器启动时执行一次。当 Startup Probe 探测失败时，Kubernetes 将自动重启该容器。适用于需要较长启动时间的应用场景，比如应用程序需要大量预热或者需要等待外部依赖组件的应用程序。 1、livenessprobe案例
Liveness Probe 用于检查pod内的容器是否在运行，并在容器出现故障时重新启动容器。Liveness Probe 支持三种探针：httpGet、exec 和 tcpSocket。 1）使用 HTTP 接口进行探测：
root@ubuntu0:~/matedata/pod# cat live-http.yaml 
apiVersion: v1 
kind: Pod 
metadata: name: liveness-http 
spec: nodeName: ubuntu2containers: - name: liveness image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 livenessProbe: httpGet: path: /index.html port: 80 initialDelaySeconds: 15 periodSeconds: 20 
root@ubuntu0:~/matedata/pod# kubectl apply -f live-http.yaml 
pod/liveness-http created
root@ubuntu0:~/matedata/pod# kubectl get pods -o wide
NAME            READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
liveness-http   1/1     Running   0          6s    10.244.152.80   ubuntu2   <none>           <none>#YAML文件说明： 
1、initialDelaySeconds：首次探测之前等待的时间，单位是秒。在容器启动之后，等待指定的时间后才开始进行探测，避免容器还未启动完成就开始进行探测，导致探测失败。 
2、periodSeconds：探测器的周期时间，单位是秒。探测器将在每隔一定时间间隔内进行一次探测。默认周期时间是 10 秒。 模拟探测失败的情况：在 Nginx 容器中删除 /usr/share/nginx/html/index.html 文件，这样 httpGet 探针将无法访问该文件，从而导致探测失败。 
进入容器删除/usr/share/nginx/html/index.html 等待20s
root@ubuntu0:~/matedata/pod#  kubectl exec -it liveness-http -- /bin/bash 
root@liveness-http:/# rm -rf /usr/share/nginx/html/index.html 
root@liveness-http:/# 
此时久已经重启一次了
root@ubuntu0:~/matedata/pod# kubectl get pod -w
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   0          90sliveness-http   1/1     Running   1 (1s ago)   3m1s可以看到pod里的容器重启了一次。因为默认的重启策略是always，只要探测失败就重启。2）使用 TCP接口进行探测：
root@ubuntu0:~/matedata/pod# cat live-tcp.yaml 
apiVersion: v1
kind: Pod
metadata:name: livetcp 
spec:nodeName: ubuntu2containers:- name: tcpimage: nginximagePullPolicy: IfNotPresentlivenessProbe:tcpSocket:port: 80initialDelaySeconds: 15periodSeconds: 20  
root@ubuntu0:~/matedata/pod# kubectl apply -f live-tcp.yaml 
pod/livetcp created
此时久已经运行起来了
root@ubuntu0:~/matedata/pod# kubectl get pod -w
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   0          90sliveness-http   1/1     Running   1 (1s ago)   3m1s
livetcp         0/1     Pending   0            0s
livetcp         0/1     ContainerCreating   0            0s
livetcp         0/1     ContainerCreating   0            1s
livetcp         1/1     Running             0            1s模拟探测失败的情况：在 Nginx 容器中停止nginx服务，这样 80端口将无法访问 
进入容器
root@ubuntu0:~/matedata/pod# kubectl exec -it livetcp -- bash
root@livetcp:/# 
停止nginx
root@livetcp:/# nginx -s stop
2025/08/18 13:42:17 [notice] 13#13: signal process started
root@livetcp:/# command terminated with exit code 137
root@ubuntu0:~/matedata/pod# 
此时容器就会重启
livetcp         0/1     Completed           0            101s
livetcp         1/1     Running             1 (2s ago)   102s
可以看到pod里的容器重启了一次。因为默认的重启策略是always，只要探测失败就重启。readinessprobe案例分享 
Readiness Probe 用于检查容器是否已经准备好接收流量。Readiness Probe 支持三种探针：httpGet、exec 和 tcpSocket。
检查机制
使用探针来检查容器有四种不同的方法。 每个探针都必须准确定义为这四种机制中的一种：
exec
在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
grpc
使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC 健康检查。 如果响应的状态是 "SERVING"，则认为诊断成功。
httpGet
对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。
tcpSocket
对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。 如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。root@ubuntu0:~/matedata/pod# cat readiness.yaml 
apiVersion: v1
kind: Pod
metadata:name: readlins
spec:nodeName: ubuntu2containers:- name: readlins1image: nginximagePullPolicy: IfNotPresentreadinessProbe:httpGet:path: /index.htmlport: 80initialDelaySeconds: 1periodSeconds: 2failureThreshold: 3successThreshold: 1
root@ubuntu0:~/matedata/pod# kubectl apply -f readiness.yaml 
pod/readlins created
root@ubuntu0:~/matedata/pod# kubectl get pod -w
NAME       READY   STATUS    RESTARTS   AGE
readlins   0/1     Pending   0          0s
readlins   0/1     ContainerCreating   0          0s
readlins   0/1     ContainerCreating   0          1s
readlins   0/1     Running             0          1s
readlins   1/1     Running             0          2s
上面可以看到pod没有立即ready，因为initialDelaySeconds: 1表示pod启动后1s才开始探测，所以至少要等1s，探测没问题才会就绪#YAML文件说明： 
1、initialDelaySeconds：首次探测之前等待的时间，单位是秒。在容器启动之后，等待指定的时间后才开始进行探测，避免容器还未启动完成就开始进行探测，导致探测失败。 
2、periodSeconds：探测器的周期时间，单位是秒。探测器将在每隔一定时间间隔内进行一次探测。默认周期时间是 10 秒。 
3、failureThreshold：探测失败的阈值，failureThreshold: 3 是指在连续失败了3次探测后，探测就会被认定为失败，容器将被认为是不健康的，并且将被终止并重新启动。 
4、successThreshold：探测成功的阈值，假设 successThreshold: 1，则当容器探测成功一次后，容器将被认为是健康的，继续运行。所以上面最终探测方式如下： 
探测将在容器启动后等待 1 秒钟，然后开始执行。探测周期的时间间隔为 2 秒，也就是每隔 2 秒进行一次探测。如果在探测期间出现 3 次失败，则 Pod 将被标记为 NotReady，如果探测成功一次，才会将其标记为 Ready。模拟探测失败的情况：在 Nginx 容器中删除 /usr/share/nginx/html/index.html 文件，这样 httpGet 探针将无法访问该文件，从而导致探测失败。
root@ubuntu0:~/matedata/pod# kubectl exec -it readlins -- bash
root@readlins:/# rm -rf /usr/share/nginx/html/index.html 
可以看到pod已经不就绪了，删除index.html文件。然后每隔2s探测一次，6s探测
了3次，都失败了，pod内的容器就会处于非就绪状态。
root@ubuntu0:~/matedata/pod# kubectl get pod -w
NAME       READY   STATUS    RESTARTS   AGE
readlins   0/1     Pending   0          0s
readlins   0/1     ContainerCreating   0          0s
readlins   0/1     ContainerCreating   0          1s
readlins   0/1     Running             0          1s
readlins   1/1     Running             0          2s
readlins   0/1     Running             0          106s修复探测失败的情况：重新创建 /usr/share/nginx/html/index.html 文件。
root@readlins:/# echo hello > /usr/share/nginx/html/index.html
此时就就绪了
readlins   0/1     Running             0          106s
readlins   1/1     Running             0          3m46sstartupprobe 案例分享
Startup Probe 用于检查容器是否已经启动完成。Startup Probe 支持三种探针：httpGet、exec 和 tcpSocket。我们使用了 exec 探针。具体步骤如下：1）创建一个名为 my-pod 的 Pod： 
root@ubuntu0:~/matedata/pod# cat start-pod.yaml 
apiVersion: v1 
kind: Pod 
metadata: name: my-pod-start
spec:nodeName: ubuntu2containers:- name: nginx-containerimage: nginximagePullPolicy: IfNotPresentports:- containerPort: 80startupProbe:exec:command:- /bin/sh- -c- /usr/sbin/nginx -tfailureThreshold: 10periodSeconds: 10initialDelaySeconds: 30  #pod启动过30s开始探测，之后就每10s探测一次
root@ubuntu0:~/matedata/pod# kubectl apply -f start-pod.yaml 
pod/my-pod-start created
root@ubuntu0:~/matedata/pod# kubectl get pod -w
NAME           READY   STATUS    RESTARTS   AGE
my-pod-start   0/1     Pending   0          0s
my-pod-start   0/1     ContainerCreating   0          0s
my-pod-start   0/1     ContainerCreating   0          0s
my-pod-start   0/1     Running             0          1s
my-pod-start   0/1     Running             0          40s
my-pod-start   1/1     Running             0          40s
模拟探测失败的情况：在 Nginx 容器中删除 /usr/sbin/nginx 文件，这样 exec 探针将无法检查配置文件的正确性，从而导致探测失败。
root@ubuntu0:~/matedata/pod#  kubectl exec -it my-pod-start  -- /bin/bash 
root@my-pod-start:/#  rm -rf /usr/sbin/nginx  
此时pod的状态
^Croot@ubuntu0:~/matedata/pod# kubectl get pod -w
NAME           READY   STATUS    RESTARTS   AGE
my-pod-start   1/1     Running   0          2m43s

pod启动探测、就绪探测、存活探测先后顺序

1、启动探测：在容器启动之后，立即进行启动探测，如果启动探测失败，则 Kubernetes 认为该容器启动失败，不会再进行后续的探测。 
2、就绪探测：如果启动探测成功，就会进行就绪探测。在容器运行期间，Kubernetes 会定期进行就绪探测，以检查容器是否已经准备好接收请求。如果就绪探测失败，则 Kubernetes 认为该容器还没有准备好接收请求，不会将流量转发到该容器。 
3、存活探测：在容器运行期间，Kubernetes 会定期进行存活探测，以检查容器是否处于健康状态。如果存活探测失败，则 Kubernetes 认为该容器已经出现了故障，需要进行重启或者进行其他的处理。

使用kubectl管理Kubernetes容器平台

 kubectl 创建和删除一个pod 
命令                             说明 
run                        在集群上运行一个pod 
create                     使用文件或者标准输入的方式创建一个pod 
delete                     使用文件或者标准输入以及资源名称或者标签选择器来删除某个pod kubectl run 语法 
kubectl run 和 docker run 一样，kubectl run 能将一个pod运行起来。 
语法： 
kubectl run podNAME --image=image [--env="key=value"] [--port=port]  
#查看kubectl run帮助命令 
[root@xuegod63 ~]# kubectl run --help  
例1：创建一个名字为nginx的pod，使用刚上传到xuegod64和xuegod62上刚上传的nginx:latest 镜像  ，--port=暴露容器端口 80 。 
[root@xuegod63 ~]# kubectl run nginx --image=nginx:latest --image-pull-policy='IfNotPresent'  --port=80 
[root@xuegod63 ~]# kubectl get pod --image-pull-policy='IfNotPresent'   # 如果本地不存在镜像，那么才从外网下载镜像。  默认值为：imagePullPolicy: Always 一直从外网下载镜像，不使用本地的镜像。使用kubectl delete 删除创建的对象 
1. 删除pod 
语法：kubectl delete pod  pod名字 
[root@xuegod63 ~]#   kubectl delete pod nginx 
pod "nginx" deleted 
2.查看pod 
[root@xuegod63 ~]#  kubectl  get pod 
No resources found in default namespace. 
3.查看pod ip和pod调度到哪个节点 
[root@xuegod63 ~]# kubectl get pods -n kube-system -o wide 
4.强制删除pod 
[root@xuegod63 ~]# kubectl run nginx --image=nginx --image-pull-policy='IfNotPresent' --port=80
[root@xuegod63 ~]# kubectl delete pod nginx --force --grace-period=0 5.创建一个pod，但是不运行，可以输出到yaml文件里
[root@xuegod63 ~]# kubectl run nginx --image=nginx --image-pull-policy='IfNotPresent' --port=80 -o yaml --dry-run=client > 1.yaml 11.4  kubectl 其他常用命令和参数说明 
命令           说明 
logs           取得pod中容器的log信息 
exec          在pod中执行一条命令 
cp              从pod拷出或向pod拷入文件 [root@xuegod63 ~]# kubectl logs -f mysql-76f8866f79-mdd69 
#查看pod具体容器日志，-c 
[root@xuegod63 ~]# kubectl logs mysql-76f8866f79-q5cvx -c mysql11.4.2  kubectl exec 
exec 命令用于到pod中执行一条命令，到mysql的镜像中执行cat /etc/my.cnf命令 
[root@xuegod63 ~]# kubectl get pod 
[root@xuegod63 ~]# kubectl  exec  mysql-76f8866f79-j6twz  cat /etc/my.cnf 
例2：使用参数exec -it ，直接登pod上中 
[root@xuegod63 ~]# kubectl  exec  -it mysql-76f8866f79-j6twz -- bash 
bash-4.2# exit 
[root@xuegod63 ~]# kubectl  exec  -it mysql-76f8866f79-j6twz -c mysql --  bash -c 指定进入到pod具体容器里 kubectl cp  
用于从pod中拷出hosts文件到物理机的/tmp下 
[root@xuegod63 ~]# kubectl cp mysql-76f8866f79-j6twz:/etc/hosts  /tmp/hosts 
command terminated with exit code 126    
#报错 
排错方法 
[root@xuegod63 ~]# kubectl  cp --help  
Copy files and directories to and from containers. 
Examples: 
# !!!Important Note!!! 
# Requires that the 'tar' binary is present in your container   #发现想要使用 kubectl cp
你的容器实例中必须有tar库 
# image.  If 'tar' is not present, 'kubectl cp' will fail. #如果镜像中 tar 命令不存在，那么
kubectl cp 将失败 
安装mysql  pod中安装tar命令： 
[root@xuegod63 ~]# kubectl  exec  -it mysql-76f8866f79-j6twz  bash 
创建阿里yum源，默认此镜像中带的是oracle的源，如果不能使用，就自己创建。 
bash-4.2# mv /etc/yum.repos.d/public-yum-ol7.repo /opt/ 
bash-4.2# cat >  /etc/yum.repos.d/CentOS-Base.repo  <<EOF  
[base] 
name=CentOS7 
baseurl=http://mirrors.aliyun.com/centos/7/os/x86_64/ 
gpgcheck=0 
EOF
bash-4.2# yum install tar -y 
在pod中创建一个文件message.log 
bash-4.2#  echo "this is a message from xuegod.cn" >  /tmp/message.log  
bash-4.2# exit
http://www.xdnf.cn/news/18160.html

相关文章：

  • B站 韩顺平 笔记 （Day 23）
  • 力扣（电话号码的字母组合）
  • 理解JavaScript中的函数赋值和调用
  • 0.开篇简介
  • 添加右键菜单项以管理员权限打开 CMD
  • CMake进阶: CMake Modules---简化CMake配置的利器
  • 决策树（2）
  • 火山引擎，燃起了Agent的星星之火
  • Python数据分析：DataFrame，reindex，重建索引。有时候整型变浮点型，有时候又不变？
  • Unity进阶--C#补充知识点--【C#各版本的新功能新语法】C#1~4与C#5
  • 基于多级缓存架构的Redis集群与Caffeine本地缓存实战经验分享
  • BEV:隐式相机视角转换-----BEVFormer
  • JVM 面试精选 20 题（续）
  • 面试经验分享-某电影厂
  • 黎阳之光：以数字之力，筑牢流域防洪“智慧防线”
  • 图像采集卡与工业相机：机器视觉“双剑合璧”的效能解析
  • 【ASP.NET Core】ASP.NET Core中间件解析
  • 如何安全删除GitHub中的敏感文件？git-filter-repo操作全解析
  • PowerBI VS FineBI VS QuickBI实现帕累托分析
  • [WiFi]RealTek RF MP Tool操作说明（RTL8192ES）
  • 编排之神--Kubernetes中的认证授权详解
  • PyTorch数据加载利器：torch.utils.data 详解与实践
  • RNN深层困境：残差无效，Transformer为何能深层？
  • 【RustFS干货】RustFS的智能路由算法与其他分布式存储系统（如Ceph）的路由方案相比有哪些独特优势？
  • MySQL深分页性能优化实战：大数据量情况下如何进行优化
  • 阿里云参数配置化
  • C++入门自学Day14-- deque类型使用和介绍（初识）
  • 私有化部署全攻略：开源模型本地化改造的性能与安全评测
  • IPD流程执行检查表
  • 消费者API