企业实战--kubernetes(二)---pod命令行方式管理

关注

原创最新推荐文章于 2026-04-27 00:09:23 发布 395 阅读 AI 写同款· GEO 优化 ›

零基础学kubernetes（k8s）必看教程，带你10分钟快速实战入门k8s 作为一个工作十余年，拥有比较丰富的计算机网络运维、主机运维、云计算平台运维、自动化运维开发经验的老鸟，我来说说我当初刚接触Kubernetes时的一些感受以及学习技巧。阅读详情

一、Pod是什么

Pod是Kubernetes中能够创建和部署的最小单元，是Kubernetes集群中的一个应用实例，总是部署在同一个节点Node上。Pod中包含了一个或多个容器，还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境，Docker则是最流行的容器环境。

单容器Pod，最常见的应用方式。
多容器Pod，对于多容器Pod，Kubernetes会保证所有的容器都在同一台物理主机或虚拟主机中运行。多容器Pod是相对高阶的使用方式，除非应用耦合特别严重，一般不推荐使用这种方式。一个Pod内的容器共享IP地址和端口范围，容器之间可以通过 localhost 互相访问。

Pod带来的好处

Pod并不提供保证正常运行的能力，因为可能遭受Node节点的物理故障、网络分区等等的影响，整体的高可用是Kubernetes集群通过在集群内调度Node来实现的。通常情况下我们不要直接创建Pod，一般都是通过Controller来进行管理，但是了解Pod对于我们熟悉控制器非常有好处。
Pod做为一个可以独立运行的服务单元，简化了应用部署的难度，以更高的抽象层次为应用部署管提供了极大的方便。
Pod做为最小的应用实例可以独立运行，因此可以方便的进行部署、水平扩展和收缩、方便进行调度管理与资源的分配。
Pod中的容器共享相同的数据和网络地址空间，Pod之间也进行了统一的资源管理与分配。

Kubernetes中Pod控制器

pod的管理主要有RC(RS)、Deployment、StatefulSet、DaemonSet和Job（CronJob）等

Replication Controller

Replication Controller简称RC，简单来说，RC可以保证在任意时间运行Pod的副本数量，能够保证Pod总是可用的。总维持pod是指定的副本数量运行。

Replication Set
Replication Set简称RS，随着Kubernetes的发展，RS在RC的基础上做了一些扩展，官方已经推荐使用RS和Deployment来代替RC了。

apiVersion: v1
kind: ReplicationController/Replication Set
metadata:
  name: rc-test
  labels:
    name: rc
spec:
  replicas: 3
  selector:
    name: rc
 ...................................

Deployment

主要职责和RC一样的都是保证Pod的数量和健康，二者大部分功能都是完全一致的，可以看成是一个升级版的RC控制器。比如一些官方组件kube-dns、kube-proxy也都是使用的Deployment来管理的.

新特性如下：

RS的全部功能：Deployment具备上面描述的RC的全部功能
事件和状态查看：可以查看Deployment的升级详细进度和状态
回滚：当升级Pod的时候如果出现问题，可以使用回滚操作回滚到之前的任一版本
版本记录：每一次对Deployment的操作，都能够保存下来，这也是保证可以回滚到任一版本的基础
暂停和启动：对于每一次升级都能够随时暂停和启动

  apiVersion: apps/v1beta1
    kind: Deployment
    metadata:
      name: test
      labels:
        k8s-app: test
    spec:
      replicas: 3
      template:
        metadata:
          labels:
            app: mysql
      ....................................

DaemonSet

DaemonSet适用于在每个Node都需要运行一个Pod的时候使用，比如：每一个Node上运行一个日志采集、性能监控的Pod,可以通过DaemonSet来实现

  apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: node-ds-test
    spec:
      selector:
        matchLabels:
          name: node-ds-test
      template:
        metadata:
          labels:
    ...........................

StatefulSet

StatefulSet是Kubernetes提供的管理有状态应用的负载管理控制器API。在Pods管理的基础上，保证Pods的顺序和一致性。与Deployment一样，StatefulSet也是使用容器的Spec来创建Pod，与之不同StatefulSet创建的Pods在生命周期中会保持持久的标记

  apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: web
    spec:
      serviceName: "nginx"
      replicas: 2
      selector:
         matchLabels:
           app: nginx
      template:
        metadata:
    ...........................

Job/CronJob

K8S中，通常用Job来创建一个任务，注意job是执行一个的任务。如需要任务定时周期的去执行。CronJob就出场了，CronJob其实就是在Job的基础上加上了任务调度。

apiVersion: batch/v1
kind: Job/CronJob
metadata:
  name: job-test
spec:
  template:
    metadata:
      name: job-test
    spec:
      restartPolicy: Never

二、通过命令来管理pod

官方推荐我们使用yaml文件的形式来管理pod，我们先用命令的方式来管理pod：

以下就是一些常用的kubectl管理命令

#查看所有 pod 列表,  -n 后跟 namespace, 查看指定的命名空间  -o wide 查看详细信息
kubectl get pod
kubectl get pod -n kube  
kubectl get pod -o wide


# 查看 RC 和 service 列表， -o wide 查看详细信息
kubectl get rc,svc
kubectl get pod,svc -o wide  
kubectl get pod <pod-name> -o yaml


# 显示 Node 的详细信息
kubectl describe node server2


# 显示 Pod 的详细信息, 特别是查看 pod 无法创建的时候的日志
kubectl describe pod <pod-name>
eg:
kubectl describe pod nginx


# 根据 yaml 创建资源, apply 可以重复执行，create 不行
kubectl create -f pod.yaml
kubectl apply -f pod.yaml


# 基于 pod.yaml 定义的名称删除 pod 
kubectl delete -f pod.yaml 


# 删除所有包含某个 label 的pod 和 service
kubectl delete pod,svc -l name=<label-name>


# 删除所有 Pod
kubectl delete pod --all


# 查看 endpoint 列表
kubectl get endpoints


# 执行 pod 的命令
kubectl exec <pod-name> -- date
kubectl exec <pod-name> -- bash
kubectl exec <pod-name> -- ping 172.25.63.1


# 通过bash获得 pod 中某个容器的TTY，相当于登录容器
kubectl exec -it <pod-name> -c <container-name> -- bash
eg:
kubectl exec -it nginx -- bash


# 查看容器的日志
kubectl logs <pod-name>
kubectl logs -f <pod-name> # 实时查看日志
kubectl log  <pod-name>  -c <container_name> # 若 pod 只有一个容器，可以不加 -c 


# 查看注释
kubectl explain pod
kubectl explain pod.apiVersion

# 查看节点 labels
kubectl get node --show-labels

三、pod命令管理实践

创建自主式pod

运行一个pod：

可以使用kubectl run --help查看运行的帮助

[root@server1 ~]# kubectl run nginx --image=nginx
pod/nginx created

查看运行的pod：

[root@server1 ~]# kubectl get pod
NAME    READY   STATUS              RESTARTS   AGE
nginx   0/1     ContainerCreating   0          3m56s

查看默认namespace的pod：

[root@server1 ~]# kubectl get pod -n default
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          4m31s

查看pod的详细信息：

[root@server1 ~]# kubectl describe pod nginx
Name:         nginx
Namespace:    default
Priority:     0
Node:         server2/172.25.63.2			#这个pod运行在哪个节点上
Start Time:   Sat, 18 Apr 2020 00:43:38 +0800
Labels:       run=nginx					#pod的label
Annotations:  <none>
Status:       Running
IP:           10.244.1.2			#pod的ip地址
IPs:
  IP:  10.244.1.2
Containers:
  nginx:
  ......

此时，集群内部的任意节点可以访问pod，但是集群外部无法直接访问：
现在再运行一个容器来访问nginx：

[root@server1 ~]# kubectl run test -it --image=radial/busyboxplus --restart=Never
If you don't see a command prompt, try pressing enter.
/ # 
/ # curl 10.244.1.2			#访问第一个pod的ip地址即可。

上述命令中--restart=Never表示退出之后不重启，默认会重启。

当pod不使用时可以将其删除

删除pod：

[root@server1 ~]# kubectl delete pod nginx 
pod "nginx" deleted
[root@server1 ~]# kubectl delete pod test 
pod "test" deleted

指定pod控制器为deployment

默认创建pod时使用自主式的pod管理器，这种自主创建的pod再删除时会直接删除，我们也可以指定pod管理器deployment来创建pod，这种管理器在pod删除时会帮我们自动启动：

首先用两种方式创建pod：

[root@server1 ~]# kubectl run nginx --image=nginx
pod/nginx created
[root@server1 ~]# kubectl create deployment myapp --image=ikubernetes/myapp:v1deployment.apps/myapp created

查看pod信息：
[root@server1 ~]# kubectl get pod -o wide
NAME                     READY   STATUS              RESTARTS   AGE     IP           NODE      NOMINATED NODE   READINESS GATES
myapp-5d587c4d45-vw5z5   0/1     ContainerCreating   0          13s     <none>       server3   <none>           <none>
nginx                    1/1     Running             0          5m32s   10.244.1.3   server2   <none>           <none>

删除自主pod：
[root@server1 ~]# kubectl delete pod nginx 
pod "nginx" deleted
[root@server1 ~]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
myapp-5d587c4d45-vw5z5   1/1     Running   0          116s

可以看到已经被删除，接下来删除指定deployment的pod：

[root@server1 ~]# kubectl delete pod myapp-5d587c4d45-vw5z5
pod "myapp-5d587c4d45-vw5z5" deleted
[root@server1 ~]# kubectl get pod
NAME                     READY   STATUS              RESTARTS   AGE
myapp-5d587c4d45-nplqk   0/1     ContainerCreating   0          26s

可以看到删除pod后deployment又帮我们启动了pod。

pod拉伸

基于deployment我们也可以实现拉伸pod的目的：

[root@server1 ~]# kubectl scale --replicas=2 deployment myapp

在这里插入图片描述

拉伸成功，同理也可以实现缩减的效果。

集群内部pod之间访问

此时的pod在集群外部和pod外部并不能被访问，只能在pod内部被访问，要实现集群内部pod外部访问就要借助service，service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service成为微服务。

解下来创建service：

[root@server1 ~]# kubectl expose deployment myapp --port=80 --target-port=80
service/myapp exposed

此时pod客户端可以通过service的名称访问后端的两个pod，其中Cluster ip为默认类型，自动分配一个仅集群内部可以访问的虚拟ip。

[root@server1 ~]# kubectl get deployments.apps 
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
myapp   2/2     2            2           7m24s
[root@server1 ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   4h25m
myapp        ClusterIP   10.104.223.76   <none>        80/TCP    32s
[root@server1 ~]# kubectl describe svc myapp 
Name:              myapp
Namespace:         default
Labels:            app=myapp
Annotations:       <none>
Selector:          app=myapp
Type:              ClusterIP
IP:                10.104.223.76
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.1.4:80,10.244.2.8:80		#两个pod的地址
Session Affinity:  None
Events:            <none>

之后测试访问：

[root@server1 ~]# kubectl run test -it --image=radial/busyboxplus
If you don't see a command prompt, try pressing enter.
/ # 
/ # curl 10.104.223.76

在这里插入图片描述

集群外部访问pod

当然这种方式也只能在集群内部访问，要想实现集群外部访问，我们可以使用NodePort类型暴露端口，让外部客户端访问Pod。

NodePort：在ClusterIp基础上为Service在每台机器上绑定一个端口，这样就可以通过NodeIP:NodePort来访问该服务。

由于集群已经创建，因此要实现集群外部访问需要更改集群网络类型：

[root@server1 ~]# kubectl edit svc myapp

将ClusterIp该为NodePort
在这里插入图片描述当然也可以在创建service时加--type=NodePort指定类型。

kubectl expose deployment myapp --port=80 --target-poet=80 --type=NodePort
kubectl get pod -o wide
kubectl get svc myapp

查看暴露出来的端口：

[root@server1 ~]# kubectl get svc myapp
NAME    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
myapp   NodePort   10.104.223.76   <none>        80:32516/TCP   6m47s

端口为32516，因此可以使用以下方式访问pod：

[root@foundation63 kiosk]# curl 172.25.63.3:32516
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@foundation63 kiosk]# curl 172.25.63.2:32516
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

pod的应用版本更新和回滚

接下来实现pod的版本更新和回滚：

[root@server1 ~]# kubectl set image deployments myapp myapp=ikubernetes/myapp:v2 --record 
deployment.apps/myapp image updated

查看更新历史：

[root@server1 ~]# kubectl rollout history deployment myapp
deployment.apps/myapp 
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image deployments myapp myapp=ikubernetes/myapp:v2 --record=true

查看版本：

[root@server1 ~]# curl 172.25.63.3:32516
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

可以看出已经更新成了v2版本。

回滚到v1：

[root@server1 ~]# kubectl rollout undo deployment myapp --to-revision=1
deployment.apps/myapp rolled back