Kubernetes集羣命令的管理工具kubectl實例講解
前言
前一篇文章部署了Kubernetes集羣的Dashboard界面，帶領大家體驗了可視化界面的便捷性和易操作性。那麼本文將重點介紹Kubernetes集羣命令的管理工具之kubectl。講解的方式是通過實際例程來演示講解。
kubectl常用命令講解
1、kubectl get ——獲取列出一個或多個資源的信息
目前使用比較多的如下所示，我們可以將參數使用逗號分隔，依舊可以區分顯示
[root@master01 ~]# kubectl get cs,node,pod 分別指的是獲取集羣狀態信息（健康檢查）、節點信息狀態以及pod資源
NAME STATUS MESSAGE ERROR
componentstatus/controller-manager Healthy ok
componentstatus/scheduler Healthy ok
componentstatus/etcd-0 Healthy {"health":"true"}
componentstatus/etcd-2 Healthy {"health":"true"}
componentstatus/etcd-1 Healthy {"health":"true"}
NAME STATUS ROLES AGE VERSION
node/192.168.0.129 Ready <none> 3d13h v1.12.3
node/192.168.0.130 Ready <none> 3d13h v1.12.3
NAME READY STATUS RESTARTS AGE
pod/nginx-dbddb74b8-cnhsl 1/1 Running 0 2d14h
當然，這裏沒有加其他的可選項，因此表示選擇默認（default），也可以使用一些可選項，常用的例如-o或者-n ，前者表示output，後者表示namespace，具體且看下方實例演示
-o選項使用案例演示
#列出Pod以及運行Pod節點信息。
[root@master01 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-dbddb74b8-cnhsl 1/1 Running 0 2d14h 172.17.70.2 192.168.0.130 <none>
#以json格式輸出一個pod的信息
[root@master01 ~]# kubectl get -o json pod nginx-dbddb74b8-cnhsl
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"creationTimestamp": "2020-05-05T12:22:26Z",
"generateName": "nginx-dbddb74b8-",
"labels": {
"pod-template-hash": "dbddb74b8",
"run": "nginx"
},
"name": "nginx-dbddb74b8-cnhsl",
"namespace": "default",
"ownerReferences": [
{
"apiVersion": "apps/v1",
"blockOwnerDeletion": true,
"controller": true,
"kind": "ReplicaSet",
"name": "nginx-dbddb74b8",
"uid": "94a3b2b1-8ec5-11ea-8aa8-000c29d0c9f9"
}
],
"resourceVersion": "39250",
"selfLink": "/api/v1/namespaces/default/pods/nginx-dbddb74b8-cnhsl",
"uid": "14843893-8ecb-11ea-8aa8-000c29d0c9f9"
},
"spec": {
"containers": [
{
"image": "nginx",
"imagePullPolicy": "Always",
"name": "nginx",
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"volumeMounts": [
{
"mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
"name": "default-token-sj4gb",
"readOnly": true
}
]
}
],
"dnsPolicy": "ClusterFirst",
"nodeName": "192.168.0.130",
"priority": 0,
"restartPolicy": "Always",
"schedulerName": "default-scheduler",
"securityContext": {},
"serviceAccount": "default",
"serviceAccountName": "default",
"terminationGracePeriodSeconds": 30,
"tolerations": [
{
"effect": "NoExecute",
"key": "node.kubernetes.io/not-ready",
"operator": "Exists",
"tolerationSeconds": 300
},
{
"effect": "NoExecute",
"key": "node.kubernetes.io/unreachable",
"operator": "Exists",
"tolerationSeconds": 300
}
],
"volumes": [
{
"name": "default-token-sj4gb",
"secret": {
"defaultMode": 420,
"secretName": "default-token-sj4gb"
}
}
]
},
"status": {
"conditions": [
{
"lastProbeTime": null,
"lastTransitionTime": "2020-05-05T12:22:26Z",
"status": "True",
"type": "Initialized"
},
{
"lastProbeTime": null,
"lastTransitionTime": "2020-05-05T12:22:41Z",
"status": "True",
"type": "Ready"
},
{
"lastProbeTime": null,
"lastTransitionTime": "2020-05-05T12:22:41Z",
"status": "True",
"type": "ContainersReady"
},
{
"lastProbeTime": null,
"lastTransitionTime": "2020-05-05T12:22:26Z",
"status": "True",
"type": "PodScheduled"
}
],
"containerStatuses": [
{
"containerID": "docker://db449db7ce9277cdf803aa7650af23d3909dc5df2069e7a47eea38c5b1c8abcd",
"image": "nginx:latest",
"imageID": "docker-pullable://nginx@sha256:86ae264c3f4acb99b2dee4d0098c40cb8c46dcf9e1148f05d3a51c4df6758c12",
"lastState": {},
"name": "nginx",
"ready": true,
"restartCount": 0,
"state": {
"running": {
"startedAt": "2020-05-05T12:22:41Z"
}
}
}
],
"hostIP": "192.168.0.130",
"phase": "Running",
"podIP": "172.17.70.2",
"qosClass": "BestEffort",
"startTime": "2020-05-05T12:22:26Z"
}
}
-n使用案例演示（此處是先前搭建了Dashboard所產生的結果）
[root@master01 ~]# kubectl get pod,svc -n kube-system
NAME READY STATUS RESTARTS AGE
pod/kubernetes-dashboard-7dffbccd68-z6xcj 1/1 Running 0 10h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes-dashboard NodePort 10.0.0.212 <none> 443:30001/TCP 11h
#備註，其中svc表示的是service簡寫，上篇博客有談到過，可以使用kubectl api-resources查看可簡寫的內容參數all參數的作用：列出所有不同的資源對象
[root@master01 ~]# kubectl get all
NAME READY STATUS RESTARTS AGE
pod/nginx-dbddb74b8-cnhsl 1/1 Running 0 2d14h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3d14h
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx 1 1 1 1 2d14h
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-dbddb74b8 1 1 1 2d14h
2、kubectl create——通過配置文件名或stdin創建一個集羣資源對象
所支持的文件格式爲json以及yaml格式的文件，具體的案例之前在部署Dashboard時使用了多次這裏就不在演示了，可以直接訪問我的上一篇文章進行查看理解。使用最多的選項也是-f
3、kubectl run ——創建並運行一個或多個容器鏡像、創建一個deployment 或job 來管理容器
該命令前面也使用過，可能時間比較久了，這邊還是在演示和深入一波
我們先創建一個nginx的pod資源，這裏爲了區別之前的nginx的pod資源這裏我們換一個名字即可
#運行啓動一個nginx pod資源
[root@master01 ~]# kubectl run nginx-test --image=nginx:latest
kubectl run --generator=deployment/apps.v1beta1 is DEPRECATED and will be removed in a future version. Use kubectl create instead.
deployment.apps/nginx-test created
#查看pod列表
[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-dbddb74b8-cnhsl 1/1 Running 0 2d15h
nginx-test-bf5c79777-fs9jz 1/1 Running 0 17s
#查看控制器，一個deployment控制器是爲Pods和 ReplicaSets提供描述性的更新方式的
[root@master01 ~]# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 2d16h
nginx-test 1 1 1 1 26s
4、kubectl expose——將資源暴露爲新的Kubernetes Service
說明：指定deployment、service、replica set、replication controller或pod ，並使用該資源的選擇器作爲指定端口上新服務的選擇器。deployment 或 replica set只有當其選擇器可轉換爲service支持的選擇器時，即當選擇器僅包含matchLabels組件時纔會作爲暴露新的Service
在下面的整體案例中會進行演示。其中需要額外注意的是其相關的選項配置參數，這裏我先講一下該命令的相關解釋
#使用kubectl expose --help查看使用手冊
[root@master01 ~]# kubectl expose --help
Expose a resource as a new Kubernetes service.
#對該命令的作用總體說明
#下方是詳細介紹以及一些相關配置設置的說明
Looks up a deployment, service, replica set, replication controller or pod by name and uses the selector for that
resource as the selector for a new service on the specified port. A deployment or replica set will be exposed as a
service only if its selector is convertible to a selector that service supports, i.e. when the selector contains only
the matchLabels component. Note that if no port is specified via --port and the exposed resource has multiple ports, all
will be re-used by the new service. Also if no labels are specified, the new service will re-use the labels from the
resource it exposes.
Possible resources include (case insensitive):
pod (po), service (svc), replicationcontroller (rc), deployment (deploy), replicaset (rs)
#下面是給出的一些操作例程實例
Examples:
# Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000.
kubectl expose rc nginx --port=80 --target-port=8000
# Create a service for a replication controller identified by type and name specified in "nginx-controller.yaml",which serves on port 80 and connects to the containers on port 8000.
kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000
# Create a service for a pod valid-pod, which serves on port 444 with the name "frontend"
kubectl expose pod valid-pod --port=444 --name=frontend
# Create a second service based on the above service, exposing the container port 8443 as port 443 with the name
"nginx-https"
kubectl expose service nginx --port=443 --target-port=8443 --name=nginx-https
# Create a service for a replicated streaming application on port 4100 balancing UDP traffic and named 'video-stream'.
kubectl expose rc streamer --port=4100 --protocol=udp --name=video-stream
# Create a service for a replicated nginx using replica set, which serves on port 80 and connects to the containers on
port 8000.
kubectl expose rs nginx --port=80 --target-port=8000
# Create a service for an nginx deployment, which serves on port 80 and connects to the containers on port 8000.
kubectl expose deployment nginx --port=80 --target-port=8000
#一下是可選項的設置與介紹
Options:
--allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in
the template. Only applies to golang and jsonpath output formats.
--cluster-ip='': ClusterIP to be assigned to the service. Leave empty to auto-allocate, or set to 'None' to create
a headless service.
--dry-run=false: If true, only print the object that would be sent, without sending it.
--external-ip='': Additional external IP address (not managed by Kubernetes) to accept for the service. If this IP
is routed to a node, the service can be accessed by this IP in addition to its generated service IP.
-f, --filename=[]: Filename, directory, or URL to files identifying the resource to expose a service
--generator='service/v2': 使用 generator 的名稱. 這裏有 2 個 generators: 'service/v1' 和 'service/v2'.
爲一個不同地方是服務端口在 v1 的情況下叫 'default', 如果在 v2 中沒有指定名稱.
默認的名稱是 'service/v2'.
-l, --labels='': Labels to apply to the service created by this call.
--load-balancer-ip='': IP to assign to the LoadBalancer. If empty, an ephemeral IP will be created and used
(cloud-provider specific).
--name='': 名稱爲最新創建的對象.
-o, --output='': Output format. One of:
json|yaml|name|templatefile|template|go-template|go-template-file|jsonpath-file|jsonpath.
--overrides='': An inline JSON override for the generated object. If this is non-empty, it is used to override the
generated object. Requires that the object supply a valid apiVersion field.
--port='': 服務的端口應該被指定. 如果沒有指定, 從被創建的資源中複製
--protocol='': 創建 service 的時候伴隨着一個網絡協議被創建. 默認是 'TCP'.
--record=false: Record current kubectl command in the resource annotation. If set to false, do not record the
command. If set to true, record the command. If not set, default to updating the existing annotation value only if one
already exists.
-R, --recursive=false: Process the directory used in -f, --filename recursively. Useful when you want to manage
related manifests organized within the same directory.
--save-config=false: If true, the configuration of current object will be saved in its annotation. Otherwise, the
annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future.
--selector='': A label selector to use for this service. Only equality-based selector requirements are supported.
If empty (the default) infer the selector from the replication controller or replica set.)
--session-affinity='': If non-empty, set the session affinity for the service to this; legal values: 'None',
'ClientIP'
--target-port='': Name or number for the port on the container that the service should direct traffic to.
Optional.
--template='': Template string or path to template file to use when -o=go-template, -o=go-template-file. The
template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
--type='': Type for this service: ClusterIP, NodePort, LoadBalancer, or ExternalName. Default is 'ClusterIP'.
#下面是該命令的使用語法格式
Usage:
kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP|SCTP] [--target-port=number-or-name]
[--name=name] [--external-ip=external-ip-of-service] [--type=type] [options]
Use "kubectl options" for a list of global command-line options (applies to all commands).其中需要額外注意的是最後一個type可選項，該可選項表示的是爲此服務（Service）提供的類型，默認是以ClusterIP形式作爲通信方式，如果方便我們後面查看驗證就需要使用後面的一些方式來執行。
5、kubectl delete——通過配置文件名、stdin、資源名稱或label選擇器來刪除資源
支持json和yaml格式的文件，可以只指定一種類型的參數：文件名、資源名稱或label選擇器
說明：有些資源，如pod，支持優雅的（graceful）刪除，因爲這些資源一般是集羣中的實體，所以刪除不可能會立即生效，這些資源在強制終止之前默認定義了一個週期（寬限期），但是你可以使用--grace-period flag來覆蓋該值，或者通過pass --now設置該週期爲1。
如果託管Pod的Node節點已經停止或者無法連接API Server，使用delete命令刪除Pod需等待時間更長。要強制刪除資源，需指定- force flag，且設置週期（寬限期）爲0。
如果執行強制刪除Pod，則調度程序會在節點釋放這些Pod之前將新的Pod放在這些節點上，並使之前Pod立即被逐出。
簡單演示
假設現在需要刪除剛剛運行的pod資源我們可以這樣執行
[root@master01 ~]# kubectl delete deploy/nginx-test
deployment.extensions "nginx-test" deleted
[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-dbddb74b8-cnhsl 1/1 Running 0 2d16h
nginx-test-bf5c79777-fs9jz 0/1 Terminating 0 47m
[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-dbddb74b8-cnhsl 1/1 Running 0 2d16h
其中Terminating表示正在結束的狀態
6、kubectl rollout——對資源進行管理
可用資源包括deployments和daemonsets，一般用於服務的版本回滾操作，在完整演示中我們會詳細講解
7、kubectl scale——擴容或縮容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod數量
說明：scale也可以指定多個前提條件，如：當前副本數量或 --resource-version ，進行伸縮比例設置前，系統會先驗證前提條件是否成立。
先簡單瞭解一下該命令的含義
8、kubectl set——配置應用資源
一般用於更改現有應用資源一些信息，作爲服務的關係設置
kubectl完整演示
結合上面的相關命令，以一個項目的生命週期來演示基於kubectl命令的管理操作，一個完整的項目的生命週期分爲：創建——發佈——更新——回滾——刪除 這5個操作流程。
1、創建運行
爲了提高演示效果這裏現將之前的資源進行清空（默認命名空間中）
[root@master01 ~]# kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 2d17h
[root@master01 ~]# kubectl delete deploy/nginx
deployment.extensions "nginx" deleted
[root@master01 ~]# kubectl get deploy
No resources found.
[root@master01 ~]# kubectl get pod
No resources found.
通過下面的命令進行nginx pod資源及副本的創建運行
[root@master01 ~]# kubectl run nginx --image=nginx:latest --port=80 --replicas=3
kubectl run --generator=deployment/apps.v1beta1 is DEPRECATED and will be removed in a future version. Use kubectl create instead.
deployment.apps/nginx created
[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-7697996758-hl5h2 1/1 Running 0 70s
nginx-7697996758-k5s8r 1/1 Running 0 70s
nginx-7697996758-n2hrh 1/1 Running 0 70s
[root@master01 ~]# kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 3m48s
其中--port表示pod之間內部的通信端口，--replicas表示副本集數量爲3個
我們看一下是如何調度分配節點的
[root@master01 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-7697996758-hl5h2 1/1 Running 0 2m4s 172.17.54.3 192.168.0.129 <none>
nginx-7697996758-k5s8r 1/1 Running 0 2m4s 172.17.70.3 192.168.0.130 <none>
nginx-7697996758-n2hrh 1/1 Running 0 2m4s 172.17.70.2 192.168.0.130 <none>其中一個pod資源分配在第一個節點，另外兩個在第二個節點
2、對外發布及測試驗證
[root@master01 ~]# kubectl expose deploy nginx --port=80 --target-port=80 --name=nginx-sevice --type=NodePort
service/nginx-sevice exposed
命令解析：
expose表示進行發佈操作
deploy——deployment，以控制器的類型方式
nginx——資源名稱
--target-port表示的是開設的容器端口
--name 表示服務名稱設置
--type表示通信方式類型
該命令執行的含義就是：通過deployment控制器的管理類將nginx資源以NodePort通信方式發佈出去，其中集羣內部通信端口爲80，容器端口也是80
我們來通過命令查看一下
#查看映射端口
[root@master01 ~]# kubectl get svc | grep NodePort
nginx-sevice NodePort 10.0.0.168 <none> 80:38211/TCP 5m48s
對外的端口是38211，10.0.0.168——內部通信的地址
#方便讀者待會對照查看節點分配
[root@master01 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-7697996758-hl5h2 1/1 Running 0 23m 172.17.54.3 192.168.0.129 <none>
nginx-7697996758-k5s8r 1/1 Running 0 23m 172.17.70.3 192.168.0.130 <none>
nginx-7697996758-n2hrh 1/1 Running 0 23m 172.17.70.2 192.168.0.130 <none>
#查看關聯後端服務的節點，發現這相當於做了一次負載均衡。
[root@master01 ~]# kubectl get endpoints | grep nginx-sevice
nginx-sevice 172.17.54.3:80,172.17.70.2:80,172.17.70.3:80 10m
負載均衡驗證解析
說明，在之前的Kubernetes版本（1.8之前），我們在聯繫apiserver時是通過kubelet來實現的，而對外提供服務的時候就無法離開kube-proxy組件服務了。在1.8版本之前使用的是iptables及userspace，而目前使用的是負載均衡lvs也就是我們之前LVS負載均衡中所使用的用戶態工具ipvsadm來管理配置ipvs。
因此我們可以先安裝該工具然後進行驗證查看，因爲我們使用的是NodePort 的type類型方式提供的通信，因此我們需要在node節點上安裝
#安裝
yum install -y ipvsadm
#查看負載均衡
ipvsadm -L -n
結果如下圖
rr表示輪循的負載均衡調度分配方式
查看pod資源信息
#查看其中一個pod資源的描述信息，主要看末尾內容看是否有誤
[root@master01 ~]# kubectl describe pod nginx-7697996758-hl5h2
Name: nginx-7697996758-hl5h2
Namespace: default
Priority: 0
PriorityClassName: <none>
Node: 192.168.0.129/192.168.0.129
Start Time: Wed, 06 May 2020 02:32:47 +0800
Labels: pod-template-hash=7697996758
run=nginx
Annotations: <none>
Status: Running
IP: 172.17.54.3
Controlled By: ReplicaSet/nginx-7697996758
Containers:
nginx:
Container ID: docker://a460abf76fb2829dac75c9408309e3c185774286b213abc24c1c7b0314c324d0
Image: nginx:latest
Image ID: docker-pullable://nginx@sha256:86ae264c3f4acb99b2dee4d0098c40cb8c46dcf9e1148f05d3a51c4df6758c12
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Wed, 06 May 2020 02:33:04 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-sj4gb (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-sj4gb:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-sj4gb
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 2d10h kubelet, 192.168.0.129 pulling image "nginx:latest"
Normal Pulled 2d10h kubelet, 192.168.0.129 Successfully pulled image "nginx:latest"
Normal Created 2d10h kubelet, 192.168.0.129 Created container
Normal Started 2d10h kubelet, 192.168.0.129 Started container
Normal Scheduled 24m default-scheduler Successfully assigned default/nginx-7697996758-hl5h2 to 192.168.0.129查看日誌
第一次是因爲沒有訪問因此不會有日誌生成
[root@master01 ~]# kubectl logs nginx-7697996758-hl5h2
我們進入節點上訪問一次在查看即可
[root@node01 ~]# curl 172.17.54.3
<!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>
再次查看日誌
[root@master01 ~]# kubectl logs nginx-7697996758-hl5h2
172.17.54.1 - - [05/May/2020:19:42:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
3、更新操作及測試驗證
在更新操作之前，我們先來通過上篇文章部署的Dashboard界面來看一下剛剛創建的資源，然後訪問一個nginx的web訪問查看nginx的版本
進行更新操作
[root@master01 ~]# kubectl set image deployment/nginx nginx=nginx:1.14
deployment.extensions/nginx image updated
通過下圖中的命令進行動態監控該操作執行的過程和結果
此時我們再次查看節點分配情況（以及端口號）
[root@master01 ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-6ff7c89c7c-49dsm 1/1 Running 0 9m9s 172.17.54.4 192.168.0.129 <none>
nginx-6ff7c89c7c-bcqdx 1/1 Running 0 8m39s 172.17.70.3 192.168.0.130 <none>
nginx-6ff7c89c7c-hjqvc 1/1 Running 0 8m5s 172.17.70.2 192.168.0.130 <none>
[root@master01 ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3d18h
nginx-sevice NodePort 10.0.0.168 <none> 80:38211/TCP 99m
訪問一下網站查看版本
4、回滾操作及測試驗證
#查看歷史版本
[root@master01 ~]# kubectl rollout history deployment/nginx
deployment.extensions/nginx
REVISION CHANGE-CAUSE
1 <none>
2 <none>
#進行回滾操作
[root@master01 ~]# kubectl rollout undo deployment/nginx
deployment.extensions/nginx
#查看回滾過程狀態
[root@master01 ~]# kubectl rollout status deployment/nginx
Waiting for deployment "nginx" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx" rollout to finish: 1 old replicas are pending termination...
deployment "nginx" successfully rolled out
#上述表示回滾成功
[root@master01 ~]#
我們再次訪問頁面進行查看
5、刪除
#需要刪除pod資源以及服務資源根據控制器和Service來進行刪除
[root@master01 ~]# kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 126m
[root@master01 ~]# kubectl delete deploy/nginx
deployment.extensions "nginx" deleted
[root@master01 ~]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3d19h
nginx-sevice NodePort 10.0.0.168 <none> 80:38211/TCP 110m
[root@master01 ~]# kubectl delete svc/nginx-sevice
service "nginx-sevice" deleted
刪除驗證
[root@master01 ~]# kubectl get pods
No resources found.
[root@master01 ~]# kubectl get deploy
No resources found.
[root@master01 ~]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3d19h