3、kubectl 命令详解

news2025/2/12 7:29:14

kubectl 命令详解

      • kubectl 简介
      • kubectl 常用操作
        • 基本信息查看
        • 命名空间的增删改查操作
          • 查看 pod 信息
        • 项目的生命周期
          • 创建
          • 发布
          • 更新
          • 回滚
          • 删除
          • 金丝雀发布（Canary Release）
        • 声明式管理方法

kubectl 简介

kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口。
kubectl 是官方的CLI命令行工具，用于与 apiserver 进行通信，将用户在命令行输入的命令，组织并转化为 apiserver 能识别的信息，进而实现管理 k8s 各种资源的一种有效途径。
k8s中文文档：http://docs.kubernetes.org.cn/683.html

kubectl 常用操作

查看版本信息

kubectl version [--short]

[root@master01 ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.15", GitCommit:"8f1e5bf0b9729a899b8df86249b56e2c74aebc55", GitTreeState:"clean", BuildDate:"2022-01-19T17:27:39Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.15", GitCommit:"8f1e5bf0b9729a899b8df86249b56e2c74aebc55", GitTreeState:"clean", BuildDate:"2022-01-19T17:23:01Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}
[root@master01 ~]# kubectl version --short
Client Version: v1.20.15
Server Version: v1.20.15

查看资源对象简写

kubectl api-resources

[root@master01 ~]# kubectl api-resources
NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
bindings                                       v1                                     true         Binding
componentstatuses                 cs           v1                                     false        ComponentStatus
... ...
storageclasses                    sc           storage.k8s.io/v1                      false        StorageClass
volumeattachments                              storage.k8s.io/v1                      false        VolumeAttachment

查看集群信息

kubectl cluster-info
kubectl get cs
kubectl get nodes

[root@master01 ~]# kubectl cluster-info
Kubernetes control plane is running at https://192.168.110.10:6443
CoreDNS is running at https://192.168.110.10:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
[root@master01 ~]# kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-2               Healthy   {"health":"true"}
etcd-0               Healthy   {"health":"true"}
etcd-1               Healthy   {"health":"true"}
[root@master01 ~]# kubectl get nodes
NAME             STATUS   ROLES    AGE   VERSION
192.168.110.20   Ready    <none>   21h   v1.20.15
192.168.110.30   Ready    <none>   19h   v1.20.15

配置kubectl自动补全

source <(kubectl completion bash)

node节点查看日志

journalctl -u kubelet -f
基本信息查看

命令格式

kubectl get <resource> [-o wide|json|yaml] [-n namespace]
获取资源的相关信息       -o 指定输出格式       -n 指定命令空间
--all-namespaces 或 -A ：表示显示所有命名空间
--show-labels ：显示所有标签
-l app ：仅显示标签为app的资源
-l app=nginx ：仅显示包含app标签，且值为nginx的资源

查看 master 节点状态
componentstatuses 缩写 cs

kubectl get componentstatuses/cs

[root@master01 ~]# kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok
scheduler            Healthy   ok
etcd-1               Healthy   {"health":"true"}
etcd-0               Healthy   {"health":"true"}
etcd-2               Healthy   {"health":"true"}
命名空间的增删改查操作

查看命名空间
命令空间的作用：用于允许不同<命名空间>的<相同类型>的<资源重名>的。
namespace 缩写 ns

kubectl get namespace/cs

[root@master01 ~]# kubectl get ns
NAME                   STATUS   AGE
default                Active   21h
kube-flannel           Active   19h
kube-node-lease        Active   21h
kube-public            Active   21h
kube-system            Active   21h
kubernetes-dashboard   Active   16h

查看某 命名空间 的所有资源（默认是 default）

kubectl get all [-n default]

[root@master01 ~]# kubectl get all -n kube-flannel
NAME                        READY   STATUS    RESTARTS   AGE
pod/kube-flannel-ds-m86br   1/1     Running   0          19h
pod/kube-flannel-ds-qkjw9   1/1     Running   0          19h

NAME                             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/kube-flannel-ds   2         2         2       2            2           <none>          19h

创建命名空间 sunny

kubectl create ns sunny

[root@master01 ~]# kubectl create ns sunny
namespace/sunny created
[root@master01 ~]# kubectl get ns
NAME                   STATUS   AGE
default                Active   22h
kube-flannel           Active   19h
kube-node-lease        Active   22h
kube-public            Active   22h
kube-system            Active   22h
kubernetes-dashboard   Active   16h
sunny                  Active   6s

删除命名空间app

kubectl delete namespace sunny

[root@master01 ~]# kubectl delete namespace sunny
namespace "sunny" deleted

副本控制器

在命名空间 sunny 创建副本控制器（deployment）来启动Pod（nginx-sl）

kubectl create deployment nginx-sl --image=nginx  -n sunny

[root@master01 ~]# kubectl create deployment nginx-sl --image=nginx  -n sunny
deployment.apps/nginx-sl created

查看某 命名空间 下的 pod 信息

kubectl get pod -n sunny

[root@master01 ~]# kubectl get pod -n sunny
NAME                       READY   STATUS    RESTARTS   AGE
nginx-sl-8c57b4768-t7wxf   1/1     Running   0          112s

描述某个资源的详细信息

kubectl describe deployment nginx-sl -n sunny
kubectl describe pod nginx-sl-8c57b4768-t7wxf -n sunny

[root@master01 ~]# kubectl describe deployment nginx-sl -n sunny
Name:                   nginx-sl
Namespace:              sunny
CreationTimestamp:      Tue, 11 Feb 2025 09:35:22 +0800
... ...
NewReplicaSet:   nginx-sl-8c57b4768 (1/1 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  3m57s  deployment-controller  Scaled up replica set nginx-sl-8c57b4768 to 1

扩缩容

kubectl scale deployment nginx-sl --replicas=4 -n sunny	# 扩容
kubectl scale deployment nginx-sl --replicas=2 -n sunny	# 缩容

[root@master01 ~]# kubectl scale deployment nginx-sl --replicas=4 -n sunny
deployment.apps/nginx-sl scaled
[root@master01 ~]# kubectl get pod -n sunny                                    NAME                       READY   STATUS              RESTARTS   AGE
nginx-sl-8c57b4768-4q9l4   0/1     ContainerCreating   0          15s
nginx-sl-8c57b4768-8vvn6   1/1     Running             0          5m10s
nginx-sl-8c57b4768-fkrwf   1/1     Running             0          15s
nginx-sl-8c57b4768-j8xtv   0/1     ContainerCreating   0          15s
[root@master01 ~]# kubectl scale deployment nginx-sl --replicas=2 -n sunny
deployment.apps/nginx-sl scaled
[root@master01 ~]# kubectl get pod -n sunny
NAME                       READY   STATUS    RESTARTS   AGE
nginx-sl-8c57b4768-8vvn6   1/1     Running   0          5m32s
nginx-sl-8c57b4768-fkrwf   1/1     Running   0          37s

删除副本控制器

kubectl delete deployment nginx-sl -n sunny
kubectl delete deployment/nginx-sl -n sunny

[root@master01 ~]# kubectl delete deployment/nginx-sl -n sunny
deployment.apps "nginx-sl" deleted
[root@master01 ~]# kubectl get deployment -n sunny
No resources found in sunny namespace.
查看 pod 信息

kubectl exec可以跨主机登录容器，docker exec 只能在容器所在主机上登录

kubectl exec -it nginx-sl-8c57b4768-t7wxf bash -n sunny

[root@master01 ~]# kubectl exec -it nginx-sl-8c57b4768-t7wxf bash -n sunny
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@nginx-sl-8c57b4768-t7wxf:/#

查看Pod中容器的日志

kubectl logs nginx-sl-8c57b4768-t7wxf -n sunny

[root@master01 ~]# kubectl logs nginx-sl-8c57b4768-t7wxf -n sunny
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
... ...
2025/02/11 01:35:23 [notice] 1#1: start worker process 30
2025/02/11 01:35:23 [notice] 1#1: start worker process 31

删除（重启）pod资源
由于存在deployment/rc之类的副本控制器，删除pod也会重新拉起来

kubectl delete pod nginx-sl-8c57b4768-t7wxf -n sunny

[root@master01 ~]# kubectl delete pod nginx-sl-8c57b4768-t7wxf -n sunny
pod "nginx-sl-8c57b4768-t7wxf" deleted
[root@master01 ~]# kubectl get pod -n sunny
NAME                       READY   STATUS    RESTARTS   AGE
nginx-sl-8c57b4768-8vvn6   1/1     Running   0          102s

若pod无法删除，总是处于terminate状态，则要强行删除pod

kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示过渡存活期，默认30s，在删除pod之前允许pod慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod
项目的生命周期

项目的生命周期：创建–>发布–>更新–>回滚–>删除

创建

kubectl create命令
创建并运行一个或多个容器镜像。
创建一个deployment 或job 来管理容器。
命令帮助：

kubectl create --help

启动 nginx 实例，暴露容器端口 80，设置副本数 3

kubectl create deployment nginx-sl --image=nginx:1.14 --port=80 --replicas=3 -n sunny

[root@master01 ~]# kubectl create deployment nginx-sl --image=nginx:1.14 --port=80 --replicas=3 -n sunny
deployment.apps/nginx-sl created
[root@master01 ~]# kubectl get deployment -n sunny -o wide
NAME       READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES       SELECTOR
nginx-sl   3/3     3            3           2m51s   nginx        nginx:1.14   app=nginx-sl
[root@master01 ~]# kubectl get pods -n sunny -o wide
NAME                        READY   STATUS    RESTARTS   AGE    IP              NODE             NOMINATED NODE   READINESS GATES
nginx-sl-75f8657bd9-g9b2n   1/1     Running   0          3m6s   10.244.60.78    192.168.110.20   <none>           <none>
nginx-sl-75f8657bd9-jzw5t   1/1     Running   0          3m6s   10.244.60.77    192.168.110.20   <none>           <none>
nginx-sl-75f8657bd9-xzldd   1/1     Running   0          3m6s   10.244.193.68   192.168.110.30   <none>           <none>
[root@master01 ~]# kubectl get all
NAME           READY   STATUS    RESTARTS   AGE
pod/dns-test   1/1     Running   0          19h
pod/nginx      1/1     Running   0          17h

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP   22h
发布

kubectl expose命令
将资源暴露为新的 Service。
命令帮助：
kubectl expose --help
为deployment的nginx创建service，并通过Service的8080端口转发至容器的80端口上，Service的名称为nginx-service，类型为NodePort

kubectl expose deployment nginx-sl --port=8080 --target-port=80 --name=nginx-service --type=NodePort -n sunny
或者
kubectl create service nodeport nginx-service --tcp=8080:80 -n sunny

[root@master01 ~]# kubectl expose deployment nginx-sl --port=8080 --target-port=80 --name=nginx-service --type=NodePort -n sunny
service/nginx-service exposed
[root@master01 ~]# kubectl delete service --all -n sunny
service "nginx-service" deleted
[root@master01 ~]# kubectl create service nodeport nginx-service --tcp=8080:80 -n sunny
service/nginx-service created

service 的 type 类型：
1、ClusterIP（默认类型）：分配一个集群内部的虚拟 IP 地址，仅在集群内部可访问。例如Pod和Pod之间的通信，如果是Kubernetes集群外的请求访问是不行的。
2、NodePort：宿主机上开启一个特定端口（默认范围 30000-32767），直接与Pod的端口相连，实现访问 nodeIP:nodePort 能够直接访问到Pod。用途：允许外部访问，但通常用于开发或测试。
3、LoadBalancer：使用外接负载均衡器完成到服务的负载分发，此模式需要使用云服务商提供的负载均衡器，将请求分发到所有的Node上，再结合kube-proxy实现流量接入：
外部客户端 -> 云负载均衡器 -> Kubernetes 节点 -> kube-proxy -> Pod
4、LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部云环境支持的，外部服务发送到这个设备上的请求，会被设备负载均衡转发到K8S集群中。
5、externalName：将外部服务映射到集群内部，并以DNS的形式用于Pod中服务对外部服务访问。

查看pod网络状态详细信息和 Service暴露的端口

kubectl get pods,svc -o wide -n sunny

[root@master01 ~]# kubectl get pods,svc -o wide -n sunny
NAME                            READY   STATUS    RESTARTS   AGE   IP              NODE             NOMINATED NODE   READINESS GATES
pod/nginx-sl-75f8657bd9-g9b2n   1/1     Running   0          53m   10.244.60.78    192.168.110.20   <none>           <none>
pod/nginx-sl-75f8657bd9-jzw5t   1/1     Running   0          53m   10.244.60.77    192.168.110.20   <none>           <none>
pod/nginx-sl-75f8657bd9-xzldd   1/1     Running   0          53m   10.244.193.68   192.168.110.30   <none>           <none>

NAME                    TYPE       CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE   SELECTOR
service/nginx-service   NodePort   10.0.0.27    <none>        8080:38329/TCP   11m   app=nginx-sl

查看关联后端的节点

kubectl get endpoints -n sunny

[root@master01 ~]# kubectl get endpoints -n sunny
NAME            ENDPOINTS                                          AGE
nginx-service   10.244.193.68:80,10.244.60.77:80,10.244.60.78:80   10m

查看 service 的描述信息

kubectl describe svc nginx -n sunny

[root@master01 ~]# kubectl describe svc nginx -n sunny
Name:                     nginx-service
Namespace:                sunny
Labels:                   app=nginx-sl
Annotations:              <none>
Selector:                 app=nginx-sl
Type:                     NodePort
IP Families:              <none>
IP:                       10.0.0.27
IPs:                      10.0.0.27
Port:                     <unset>  8080/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  38329/TCP
Endpoints:                10.244.193.68:80,10.244.60.77:80,10.244.60.78:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

在 node01 节点上操作，查看负载均衡端口

yum install ipvsadm -y
ipvsadm -Ln

#外部访问的IP和端口
TCP  192.168.110.20:38329 rr
  -> 10.244.60.77:80              Masq    1      0          0
  -> 10.244.60.78:80              Masq    1      0          0
  -> 10.244.193.68:80             Masq    1      0          0
#pod集群组内部访问的IP和端口
TCP  10.0.0.27:8080 rr
  -> 10.244.60.77:80              Masq    1      0          0
  -> 10.244.60.78:80              Masq    1      0          0
  -> 10.244.193.68:80             Masq    1      0          0

在 node02 节点上操作，同样方式查看负载均衡端口

访问

curl 10.0.0.27
curl 192.168.110.20:38329

在master01操作 查看访问日志

kubectl logs [容器名]
更新

kubectl set
更新：更改现有应用资源一些信息。
命令帮助：
kubectl set --help
查看当前 nginx 的版本号

curl -I http://192.168.110.20:38329
curl -I http://192.168.110.30:38329

[root@master01 ~]# curl -I http://192.168.110.20:38329
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 11 Feb 2025 03:25:58 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 04 Dec 2018 14:44:49 GMT
Connection: keep-alive
ETag: "5c0692e1-264"
Accept-Ranges: bytes

将nginx 版本更新为 1.15 版本

kubectl set image deployment/nginx nginx=nginx:1.15

[root@master01 ~]# kubectl set image deployment/nginx-sl nginx=nginx:1.15 -n sunny
deployment.apps/nginx-sl image updated
[root@master01 ~]# curl -I http://192.168.110.20:38329
HTTP/1.1 200 OK
Server: nginx/1.15.12
Date: Tue, 11 Feb 2025 03:27:51 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 16 Apr 2019 13:08:19 GMT
Connection: keep-alive
ETag: "5cb5d3c3-264"
Accept-Ranges: bytes
#更新需要时间

处于动态监听 pod 状态，由于使用的是滚动更新方式，所以会先生成一个新的pod，然后删除一个旧的pod，往后依次类推

kubectl get pods -w

滚动更新通过参数 maxSurge 和 maxUnavailable 来控制副本替换的数量
maxSurge：此参数控制滚动更新过程中副本总数的超过 DESIRED 的上限。maxSurge 可以是具体的整数（比如 3），也可以是百分百，向上取整。maxSurge 默认值为 25%。
例如，DESIRED 为 10，那么副本总数的最大值为 10 + 10 * 25% = 13，即 CURRENT 为 13。

maxUnavailable：此参数控制滚动更新过程中，不可用的副本相占 DESIRED 的最大比例。maxUnavailable 可以是具体的整数（比如 3），也可以是百分百，向下取整。 maxUnavailable 默认值为 25%。
例如，DESIRED 为 10，那么可用的副本数至少要为 10 - 10 * 25% = 8，即 AVAILABLE 为 8。

因此 maxSurge 值越大，初始创建的新副本数量就越多；maxUnavailable 值越大，初始销毁的旧副本数量就越多。
理想情况下，DESIRED 为 10 的滚动更新的过程应该是这样的：
首先创建 3 个新副本使副本总数达到 13 个。
然后销毁 2 个旧副本使可用的副本数降到 8 个。
当这 2 个旧副本成功销毁后，可再创建 2 个新副本，使副本总数保持为 13 个。
当新副本通过 Readiness 探测后，会使可用副本数增加，超过 8。
进而可以继续销毁更多的旧副本，使可用副本数回到 8。
旧副本的销毁使副本总数低于 13，这样就允许创建更多的新副本。
这个过程会持续进行，最终所有的旧副本都会被新副本替换，滚动更新完成。

更新好后的 Pod 的 ip 会改变

kubectl get pods -o wide

[root@master01 ~]# kubectl get pods -o wide -n sunny
NAME                        READY   STATUS    RESTARTS   AGE   IP              NODE             NOMINATED NODE   READINESS GATES
nginx-sl-7554b9bbfd-5ffbb   1/1     Running   0          25m   10.244.60.81    192.168.110.20   <none>           <none>
nginx-sl-7554b9bbfd-kzzjz   1/1     Running   0          26m   10.244.60.80    192.168.110.20   <none>           <none>
nginx-sl-7554b9bbfd-zlhzp   1/1     Running   0          26m   10.244.193.69   192.168.110.30   <none>           <none>
回滚

kubectl rollout
命令帮助：
kubectl rollout --help

查看历史版本

kubectl rollout history deployment/nginx-sl -n sunny

[root@master01 ~]# kubectl rollout history deployment/nginx-sl -n sunny
deployment.apps/nginx-sl
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

执行回滚到上一个版本

kubectl rollout undo deployment/nginx-sl -n sunny

[root@master01 ~]# kubectl rollout undo deployment/nginx-sl -n sunny
deployment.apps/nginx-sl rolled back
[root@master01 ~]# curl -I http://192.168.110.20:38329
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 11 Feb 2025 03:56:57 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 04 Dec 2018 14:44:49 GMT
Connection: keep-alive
ETag: "5c0692e1-264"
Accept-Ranges: bytes

执行回滚到指定版本

kubectl rollout undo deployment/nginx-sl --to-revision=2 -n sunny

[root@master01 ~]# kubectl rollout history deployment/nginx-sl -n sunny
deployment.apps/nginx-sl
REVISION  CHANGE-CAUSE
2         <none>
3         <none>

[root@master01 ~]# kubectl rollout undo deployment/nginx-sl --to-revision=2 -n sunny
deployment.apps/nginx-sl rolled back

检查回滚状态

kubectl rollout status deployment/nginx-sl -n sunny

[root@master01 ~]# kubectl rollout status deployment/nginx-sl -n sunny
deployment "nginx-sl" successfully rolled out
[root@master01 ~]# curl -I http://192.168.110.20:38329
HTTP/1.1 200 OK
Server: nginx/1.15.12
Date: Tue, 11 Feb 2025 03:59:43 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 16 Apr 2019 13:08:19 GMT
Connection: keep-alive
ETag: "5cb5d3c3-264"
Accept-Ranges: bytes
删除

kubectl delete
删除副本控制器

kubectl delete deployment/nginx-sl -n sunny

[root@master01 ~]# kubectl delete deployment/nginx-sl -n sunny
deployment.apps "nginx-sl" deleted

删除service

kubectl delete svc/nginx-service -n sunny

[root@master01 ~]# kubectl delete svc/nginx-service -n sunny
service "nginx-service" deleted
[root@master01 ~]# kubectl get all -n sunny
No resources found in sunny namespace.
金丝雀发布（Canary Release）

Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

模拟金丝雀发布
环境

[root@master01 ~]# kubectl get pod
NAME                    READY   STATUS    RESTARTS   AGE
nginx                   1/1     Running   0          19h
nginx-d9d8cf5c7-4mjm8   1/1     Running   0          2m48s
nginx-d9d8cf5c7-jvt2v   1/1     Running   0          12s
nginx-d9d8cf5c7-kzbpv   1/1     Running   0          2m48s
nginx-d9d8cf5c7-mpwbv   1/1     Running   0          2m48s
nginx-d9d8cf5c7-nm4ph   1/1     Running   0          12s

更新deployment的版本，并配置暂停deployment

kubectl set image deployment/nginx nginx=nginx:1.17 && kubectl rollout pause deployment/nginx

[root@master01 ~]# kubectl set image deployment/nginx nginx=nginx:1.17 && kubectl rollout pause deployment/nginx
deployment.apps/nginx image updated
deployment.apps/nginx paused

监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令

kubectl get pods -w

[root@master01 ~]# kubectl rollout status deployment/nginx
Waiting for deployment "nginx" rollout to finish: 3 out of 5 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 3 out of 5 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 3 out of 5 new replicas have been updated...
... ...

确保更新的pod没问题了，继续更新

kubectl rollout resume deployment/nginx

[root@master01 ~]# kubectl rollout resume deployment/nginx
deployment.apps/nginx resumed

查看最后的更新情况

kubectl get pods -w

[root@master01 ~]# kubectl get pods -w
NAME                     READY   STATUS        RESTARTS   AGE
nginx                    1/1     Running       0          20h
nginx-7f4fc68488-7lfl8   1/1     Running       0          7s
nginx-7f4fc68488-dfk92   1/1     Running       0          7s
nginx-7f4fc68488-dq6n6   1/1     Running       0          9m23s
nginx-7f4fc68488-qzj4q   1/1     Running       0          9m23s
nginx-7f4fc68488-xxmh2   1/1     Running       0          9m23s
nginx-d9d8cf5c7-jvt2v    0/1     Terminating   0          10m
nginx-d9d8cf5c7-kzbpv    0/1     Terminating   0          12m
nginx-d9d8cf5c7-kzbpv    0/1     Terminating   0          12m
nginx-d9d8cf5c7-kzbpv    0/1     Terminating   0          12m
nginx-d9d8cf5c7-jvt2v    0/1     Terminating   0          10m
nginx-d9d8cf5c7-jvt2v    0/1     Terminating   0          10m
声明式管理方法

适用场景：对资源的修改操作
管理方式：依赖于资源配置清单文件对资源进行管理
资源配置清单文件有两种格式：yaml（人性化，易读），json（易于api接口解析）
对资源的管理，是通过事先定义在统一资源配置清单内，再通过陈述式命令应用到k8s集群里
语法格式：kubectl create/apply/delete -f xxxx.yaml

查看资源配置清单

kubectl get deployment nginx -o yaml

[root@master01 ~]# kubectl get deployment nginx -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "2"
  creationTimestamp: "2025-02-11T04:41:06Z"
  generation: 5
  labels:
    app: nginx
  managedFields:
  - apiVersion: apps/v1
    fieldsType: FieldsV1
... ...
  readyReplicas: 5
  replicas: 5
  updatedReplicas: 5

解释资源配置清单

kubectl explain deployment.metadata

kubectl explain deployment.metadata
KIND:     Deployment
VERSION:  apps/v1

... ...

     allowed to change on PUT operations.

     Populated by the system. Read-only. More info:
     http://kubernetes.io/docs/user-guide/identifiers#uids

修改资源配置清单并应用
离线修改：
修改yaml文件，并用 kubectl apply -f xxxx.yaml 文件使之生效
注意：当apply不生效时，先使用delete清除资源，再apply创建资源

#导出配置文件
kubectl get service nginx -o yaml > nginx-svc.yaml
#修改
vim nginx-svc.yaml
#删除
kubectl delete -f nginx-svc.yaml
#加载
kubectl apply -f nginx-svc.yaml
#查看
kubectl get svc

在线修改：
直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效（如port: 888）
此修改方式不会对yaml文件内容修改

删除资源配置清单
陈述式删除：

kubectl delete service nginx

声明式删除：

kubectl delete -f nginx-svc.yaml

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2296722.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Java在大数据处理中的应用：从MapReduce到Spark

Java在大数据处理中的应用：从MapReduce到Spark

Java在大数据处理中的应用&#xff1a;从MapReduce到Spark 大数据时代的到来让数据的存储、处理和分析变得前所未有的重要。随着数据量的剧增&#xff0c;传统的单机计算方式已经无法满足处理需求。为了解决这个问题&#xff0c;许多分布式计算框架应运而生&#xff0c;其中Ma…
阅读更多...
深入理解QT的View-Model-Delegate机制和用法

深入理解QT的View-Model-Delegate机制和用法

文章目录 Model-View-Delegate机制Model(数据模型)设置模型属性访问元素操作元素数据排序封装好的模型View(视图)显示数据数据选择Delegate(代理)数据选择易用封装类QListWidgetQTreeWidgetQTableWidget元素拖拽代理模型参考示例Model-View-Delegate机制 Qt的View/Model/Deleg…
阅读更多...
深入理解指针初阶：从概念到实践

深入理解指针初阶：从概念到实践

一、引言 在 C 语言的学习旅程中&#xff0c;指针无疑是一座必须翻越的高峰。它强大而灵活&#xff0c;掌握指针&#xff0c;能让我们更高效地操作内存&#xff0c;编写出更优化的代码。但指针也常常让初学者望而生畏&#xff0c;觉得它复杂难懂。别担心&#xff0c;本文将用通…
阅读更多...
重庆西站公路桥梁自动化监测

重庆西站公路桥梁自动化监测

1.项目概述 重庆西站属于渝黔铁路的配套工程&#xff0c;是承担兰渝、川黔、渝昆等多条铁路的特级客运站&#xff0c;未来重庆铁路三大客运站之一。作为我国西部地区规模最大的火车站、重庆西站于2014年在沙坪坝区上桥开工建设,该站东临内环高速&#xff0c;西靠中梁山&#x…
阅读更多...
头条百度批量采集软件说明文档

头条百度批量采集软件说明文档

旧版说明文档《头条号文章批量采集软件4.0版本说明文档&#xff01;头条/微头条文章批量采集》 头条的采集软件已经更新了好多个版本了&#xff0c;一直没有做详细的介绍文档&#xff0c;最近更新了一些功能进去&#xff0c;一块来写一下说明文档。 1、主界面 2、头条作者采集…
阅读更多...
【面试】面试常见的智力题

【面试】面试常见的智力题

引言 在技术面试中&#xff0c;除了考察编程能力和算法知识外&#xff0c;智力题也是常见的考察方式。智力题不仅能够测试候选人的逻辑思维能力&#xff0c;还能反映其解决问题的创造力和应变能力。本文将整理一些常见的面试智力题&#xff0c;并详细分析解题思路&#xff0c;…
阅读更多...
【动态规划】风扫枯杨，满地堆黄叶 - 9. 完全背包问题

【动态规划】风扫枯杨，满地堆黄叶 - 9. 完全背包问题

本篇博客给大家带来的是完全背包问题之动态规划解法技巧. &#x1f40e;文章专栏: 动态规划 &#x1f680;若有问题 评论区见 ❤ 欢迎大家点赞 评论 收藏 分享 如果你不知道分享给谁,那就分享给薯条. 你们的支持是我不断创作的动力 . 王子,公主请阅&#x1f680; 要开心要快乐顺…
阅读更多...
BGP基础协议详解

BGP基础协议详解

BGP基础协议详解 一、BGP在企业中的应用二、BGP概述2.1 BGP的特点2.2 基本配置演示2.3 抓包观察2.4 BGP的特征三、BGP对等体关系四、bgp报文4.1 BGP五种报文类型（重点）4.2 BGP报文格式-报文头格式4.3 Open报文格式4.4 Update报文格式4.5 Notification报文格式4.6 Route-refre…
阅读更多...
LeetCode刷题---数组---840

LeetCode刷题---数组---840

矩阵中的幻方 https://leetcode.cn/problems/magic-squares-in-grid/submissions/598584907/ 题目&#xff1a; 3 x 3 的幻方是一个填充有 从 1 到 9 的不同数字的 3 x 3 矩阵&#xff0c;其中每行&#xff0c;每列以及两条对角线上的各数之和都相等。 给定一个由整数组成…
阅读更多...
Visual Studio踩过的坑

Visual Studio踩过的坑

统计Unity项目代码行数 编辑-查找和替换-在文件中查找 查找内容输入 b*[^:b#/].*$ 勾选“使用正则表达式” 文件类型留空 也有网友做了指定&#xff0c;供参考 !*\bin\*;!*\obj\*;!*\.*\*!*.meta;!*.prefab;!*.unity 打开Unity的项目 注意&#xff1a;只是看&#xff0…
阅读更多...
【深度学习入门实战】基于Keras的手写数字识别实战（附完整可视化分析）

【深度学习入门实战】基于Keras的手写数字识别实战（附完整可视化分析）

​ 本人主页：机器学习司猫白 ok，话不多说，我们进入正题吧 项目概述 本案例使用经典的MNIST手写数字数据集，通过Keras构建全连接神经网络，实现0-9数字的分类识别。文章将包含： 关键概念图解完整实现代码训练过程可视化模型效果深度分析环境准备 import numpy as np impo…
阅读更多...
SkyWalking 10.1.0 实战：从零构建全链路监控，解锁微服务性能优化新境界

SkyWalking 10.1.0 实战：从零构建全链路监控，解锁微服务性能优化新境界

文章目录 前言一、集成SkyWalking二、SkyWalking使用三、SkyWalking性能剖析四、SkyWalking 告警推送4.1 配置告警规则4.2 配置告警通知地址4.3 下发告警信息4.4 测试告警4.5 慢SQL查询 总结 前言 在传统监控系统中&#xff0c;我们通过进程监控和日志分析来发现系统问题&…
阅读更多...
【通俗易懂说模型】反向传播（附多元分类与Softmax函数）

【通俗易懂说模型】反向传播（附多元分类与Softmax函数）

&#x1f308; 个人主页&#xff1a;十二月的猫-CSDN博客 &#x1f525; 系列专栏&#xff1a; &#x1f3c0;深度学习_十二月的猫的博客-CSDN博客 &#x1f4aa;&#x1f3fb; 十二月的寒冬阻挡不了春天的脚步&#xff0c;十二点的黑夜遮蔽不住黎明的曙光 目录 1. 前言 2. …
阅读更多...
128，【1】buuctf [极客大挑战 2019]PHP

128，【1】buuctf [极客大挑战 2019]PHP

进入靶场 提示了备份文件 抓包&#xff0c;扫描 扫描出了两个有反应的 访问index.php没反应&#xff0c;但www.zip成功下载了文件 index.php里得到如下有用信息 <?phpinclude class.php;$select $_GET[select];$resunserialize($select);?> 所以我们要通过GET 方…
阅读更多...
系统思考—双环学习

系统思考—双环学习

前几天&#xff0c;一个企业高管向我提到&#xff1a;“我们调整了N次方案&#xff0c;市场策略、团队激励、管理制度&#xff0c;能改的全改了&#xff0c;怎么还是不见起色&#xff1f;” 这让我想到典型的单环学习&#xff0c;简单来说就是&#xff1a;发现问题 → 采取行动…
阅读更多...
QTreeView和QTableView单元格添加超链接

QTreeView和QTableView单元格添加超链接

QTreeView和QTableView单元格添加超链接的方法类似，本文仅以QTreeView为例。 在QTableView仿Excel表头排序和筛选中已经实现了超链接的添加，但是需要借助delegate，这里介绍一种更简单的方式，无需借助delegate。 一.效果 二.实现 QHTreeView.h #ifndef QHTREEVIEW_H #def…
阅读更多...
【MySQL篇】行格式详解

【MySQL篇】行格式详解

MySQL行格式详解 文章目录 MySQL行格式详解&#x1f389; 什么是行格式&#x1f431;‍&#x1f464; 如何查看行格式&#x1f431;‍&#x1f680; InnoDB 行格式有哪些&#xff1f;&#x1f431;‍&#x1f3cd; Compact 行格式&#x1f6a9; 额外信息&#x1f680; 变长字段…
阅读更多...
嵌入式知识点总结 操作系统 专题提升(五)-内存

嵌入式知识点总结 操作系统 专题提升(五)-内存

针对于嵌入式软件杂乱的知识点总结起来&#xff0c;提供给读者学习复习对下述内容的强化。 目录 1.在1G内存的计算机能否malloc&#xff08;1.2G&#xff09;&#xff1f;为什么&#xff1f; 2.malloc能申请多大的空间&#xff1f; 3.内存管理有哪几种方式&#xff1f; 4.什…
阅读更多...
动手学深度学习---深层神经网络

动手学深度学习---深层神经网络

目录 一、神经网络1.1、模型训练1.2、损失函数1.2.1、分类&#xff1a;hinge loss/合页损失/支持向量机损失1.2.2、分类&#xff1a;交叉熵损失(softmax分类器)1.2.2.1 二分类交叉熵损失1.2.2.2 多分类交叉熵损失 1.2.3、回归&#xff1a;误差平方和&#xff08;SSE&#xff09…
阅读更多...
java基础6（黑马）

java基础6（黑马）

一、static 1.static修饰成员变量 static&#xff1a;叫静态&#xff0c;可以修饰成员变量、成员方法。 成员变量按照有无static&#xff0c;分两种。 类变量&#xff1a;有static修饰&#xff0c;属于类&#xff0c;在计算机中只有一份&#xff0c;会被类的全部对象共享。…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023