Kubernetes的核心物件
API Server提供了RESTful風格的編程介面，其管理的資源是Kubernetes API中的端點，用于存盤某種API物件的集合，例如，內置Pod資源是包含了所有Pod物件的集合，資源物件是用于表現集群狀態的物體，常用于描述應于哪個節點進行容器化應用、需要為其配置什么資源以及應用程式的管理策略等，例如，重啟、升級及容錯機制，另外，一個物件也是一種“意向記錄“——一旦創建，Kubernetes就需要一直確保物件始終存在，Pod、Deployment和Service等都是最常用的核心物件，
Pod資源物件
Pod資源物件是一種集合了一到多個應用容器、存盤資源、專用IP及支撐容器運行的其他選項的邏輯組件，如圖所示，Pod代表著Kubernetes的部署單元及原子運行單元，即一個應用程式的單一運行實體，它通常由共享資源且關系緊密的一個或多個應用容器組成，
Kubernetes的網路模型要求其各Pod物件的IP地址位于同一網路平面內（同一IP網段），各Pod之間可使用其IP地址直接進行通信，無論它們運行于集群內的哪個作業節點上，這些Pod物件都像運行于同一局域網中的多個主機，不過，
Pod物件中的各行程均運行于彼此隔離的容器中，并于容器間共享兩種關鍵資源：網路和存盤卷，
網路：每個
Pod物件都會被分配一個集群內專用的IP地址，也稱為Pod IP，同一Pod內部的所有容器共享Pod物件的Network和UTS名稱空間，其中包括主機名、IP地址和埠等，因此，這些容器間的通信可以基于本地回環介面lo進行，而與Pod外的其他組件的通信則需要使用Service資源物件的ClusterIP及相應的埠完成，存盤卷：用戶可以為
Pod物件配置一組“存盤卷”資源，這些資源可以共享給其內部的所有容器使用，從而完成容器間資料的共享，存盤卷還可以確保在容器終止后重啟，甚至是被洗掉后也能確保資料不會丟失，從而保證了生命周期內的Pod物件資料的持久化存盤，
一個
Pod物件代表某個應用程式的一個特定實體，如果需要擴展應用程式，則意味著為此應用程式同時創建多個Pod實體，每個實體均代表應用程式的一個運行的“副本”(replica)，這些副本化的Pod物件的創建和管理通常由另一組稱為“控制器”(Controller)的物件實作，例如，Deployment控制器物件，創建
Pod時，還可以使用Pod Preset物件為Pod注入特定的資訊，如ConfigMap、Secret、存盤卷、掛載卷和環境變數等，有了Pod Preset物件，Pod模板的創建者就無須為每個模板顯示提供所有資訊，因此，也就無須事先了解需要配置的每個應用的細節即可完成模板定義，基于期望的目標狀態和各節點的資源可用性，
Master會將Pod物件調度至某選定的作業節點運行，作業節點于指向的鏡像倉庫（image register）下載鏡像，并于本地的容器運行時環境中啟動容器，Master會將整個集群的狀態保存于etcd中，并通過API Server共享給集群的各組件及客戶端，
Controller
Kubernetes集群的設計中，Pod是有生命周期的物件，通過手動創建或由Controller（控制器）直接創建的Pod物件會被“調度器”（Scheduler）調度至集群中的某作業節點運行，待到容器應用行程運行結束之后正常終止，隨后就會被洗掉，另外，節點資源耗盡或故障也會導致Pod物件被回收，但
Pod物件本身并不具有“自愈”功能，若是因為作業節點甚至是調度器自身導致了運行失敗，那么它將會被洗掉；同樣，資源耗盡或節點故障導致的回收操作也會洗掉相關的Pod物件，在設計上，Kubernetes使用”控制器“實作對一次性的（用后即棄）Pod物件的管理操作，例如，要確保部署的應用程式的Pod副本數量嚴格反映用戶期望的數目，以及基于Pod模板來創建Pod物件等，從而實作Pod物件的擴縮容、滾動更新和自愈能力等，例如，某節點發生故障時，相關的控制器會將此節點上運行的Pod物件重新調度到其他節點進行重建，控制器本身也是一種資源型別，它有著多種實作，其中與作業負載相關的實作如
Replication Controller、Deployment、StatefulSet、DaemonSet和Jobs等，也可統稱它們為Pod控制器，
Pod控制器的定義通常由期望的副本數量、Pod模板和標簽選擇器（Label Selector）組成，Pod控制器會根據標簽選擇器對Pod物件的標簽進行匹配檢查，所有滿足選擇條件的Pod物件都將受控于當前控制器并計入其副本總數，并確保此數目能夠精確反映期望的副本數，
Service
盡管
Pod物件可以擁有IP地址，但此地址無法確保在Pod物件重啟或被重建后保持不變，這會為集群中的Pod應用間依賴關系的維護帶來麻煩：前端Pod應用（依賴方）無法基于固定地址持續跟蹤后端Pod應用（被依賴方），于是，Service資源被用于在被訪問的Pod物件中添加一個有這固定IP地址的中間層，客戶端向此地址發起訪問請求后由相關的Service資源調度并代理至后端的Pod物件，換言之，
Service是“微服務”的一種實作，事實上它是一種抽象：通過規則定義出由多個Pod物件組合而成的邏輯集合，并附帶訪問這組Pod物件的策略，Service物件挑選、關聯Pod物件的方式同Pod控制器一樣，都是要基于Label Selector進行定義，其示意圖如下
Service IP是一種虛擬IP，也稱為Cluster IP，它專用于集群內通信，通常使用專用的地址段，如“10.96.0.0/12”網路，各Service物件的IP地址在此范圍內由系統動態分配，集群內的
Pod物件可直接請求此類的Cluster IP，例如，圖中來自Pod client的訪問請求即可以Service的Cluster IP作為目標地址，但集群網路屬于私有網路地址，它們僅在集群內部可達，將集群外部的訪問流量引入集群內部的常用方法是通過節點網路進行，實作方法是通過作業節點的IP地址和某埠（NodePort）接入請求并將其代理至相應的Service物件的Cluster IP上的服務埠，而后由Service物件將請求代理至后端的Pod物件的Pod IP及應用程式監聽的埠，因此，圖中的External Clients這種來自集群外部的客戶端無法直接請求此Service提供的服務，而是需要事先經由某一個作業節點（如NodeY）的IP地址進行，這類請求需要兩次轉發才能到達目標Pod物件，因此在通信效率上必然存在負面影響，事實上，
NodePort會部署于集群中的每一個節點，這就意味著，集群外部的客戶端通過任何一個作業節點的IP地址來訪問定義好的NodePort都可以到達相應的Service物件，此種場景下，如果存在集群外部的一個負載均衡器，即可將用戶請求負載均衡至集群中的部分或者所有節點，這是一種稱為“LoadBalancer”型別的Service，它通常是由Cloud Provider自動創建并提供的軟體負載均衡器，不過，也可以是有管理員手工配置的諸如F5一類的硬體設備，簡單來說，
Service主要有三種常用型別：第一種是僅用于集群內部通信的ClusterIP型別；第二種是接入集群外部請求的NodePort型別，它作業與每個節點的主機IP之上；第三種是LoadBalancer型別，它可以把外部請求負載均衡至多個Node的主機IP的NodePort之上，此三種型別中，每一種都以其前一種為基礎才能實作，而且第三種型別中的LoadBalancer需要協同集群外部的組件才能實作，并且此外部組件并不接受Kubernetes的管理，
命令式容器應用編排
部署應用Pod
在
Kubernetes集群上自主運行的Pod物件在非計劃內終止后，其生命周期即告結束，用戶需要再次手動創建類似的Pod物件才能確保其容器中的依然可得，對于Pod數量眾多的場景，尤其是對微服務業務來說，用戶必將疲于應付此類需求，Kubernetes的作業負載（workload）型別的控制器能夠自動確保由其管控的Pod物件按用戶期望的方式運行，因此，Pod的創建和管理大多會通過這種型別的控制器來進行，包括Deployment、ReplicasSet、ReplicationController等，
1）創建Deployment控制器物件
kubectl run命令可用于命令列直接創建Deployment控制器，并以--image選項指定的鏡像運行Pod中的容器，--dry-run選項可以用于命令的測驗，但并不真正執行資源物件的創建程序，
# 創建一個名字叫做nginx的deployment控制器，并指定pod鏡像使用nginx:1.12版本，并暴露容器內的80埠，并指定副本數量為1個，并先通過--dry-run測驗命令是否錯誤，[root@k8s-master ~]# kubectl run nginx --image=nginx:1.12 --port=80 --replicas=1 --dry-run=true[root@k8s-master ~]# kubectl run nginx --image=nginx:1.12 --port=80 --replicas=1deployment.apps/nginx created[root@k8s-master ~]# kubectl get pods #查看所有pod物件NAME READY STATUS RESTARTS AGEnginx-685cc95cd4-9z4f4 1/1 Running 0 89s###引數說明：--image 指定需要使用到的鏡像，--port 指定容器需要暴露的埠，--replicas 指定目標控制器物件要自動創建Pod物件的副本數量，
2）列印資源物件的相關資訊
kubectl get命令可用來獲取各種資源物件的相關資訊，它既能顯示物件型別特有格式的簡要資訊，也能按照指定格式為YAML或JSON的詳細資訊，或者使用Go模板自定義要顯示的屬性及資訊等，
[root@k8s-master ~]# kubectl get deployment #查看所有deployment控制器物件NAME READY UP-TO-DATE AVAILABLE AGEnginx 1/1 1 1 66s###欄位說明：NAME 資源物件名稱READY 期望由當前控制器管理的Pod物件副本數及當前已有的Pod物件副本數UP-TO-DATE 更新到最新版本定義的Pod物件的副本數量，在控制器的滾動更新模式下，表示已經完成版本更新的Pod物件的副本數量AVAILABLE 當前處于可用狀態的Pod物件的副本數量，即可正常提供服務的副本數，AGE Pod的存在時長說明：Deployment資源物件通過ReplicaSet控制器實體完成對Pod物件的控制，而非直接控制，另外，通過控制器創建的Pod物件都會被自動附加一個標簽，格式為“run=<Controller_Name>”，[root@k8s-master ~]# kubectl get deployment -o wide #查看deployment控制器物件的詳細資訊NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORnginx 1/1 1 1 69m nginx nginx:1.12 run=nginx[root@k8s-master ~]# kubectl get pods #查看pod資源NAME READY STATUS RESTARTS AGEnginx-685cc95cd4-9z4f4 1/1 Running 0 72m[root@k8s-master ~]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-685cc95cd4-9z4f4 1/1 Running 0 73m 10.244.1.12 k8s-node1 <none> <none>###欄位說明：NAME pode資源物件名稱READY pod中容器行程初始化完成并能夠正常提供服務時即為就緒狀態，此欄位用于記錄處于就緒狀態的容器數量STATUS pod的當前狀態，其值有Pending、Running、Succeeded、Failed和Unknown等其中之一RESTARTS Pod重啟的次數IP pod的IP地址，通常由網路插件自動分配NODE pod被分配的節點，
3）訪問Pod物件
這里部署的是
pod是運行的為nginx程式，所以我們可以訪問是否ok，在kubernetes集群中的任意一個節點上都可以直接訪問Pod的IP地址，
[root@k8s-master ~]# kubectl get pods -o wide #查看pod詳細資訊NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-685cc95cd4-9z4f4 1/1 Running 0 88m 10.244.1.12 k8s-node1 <none> <none>[root@k8s-master ~]# curl 10.244.1.12 #kubernetes集群的master節點上訪問<!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 andworking. Further configuration is required.</p><p>For online documentation and support please refer to<a href=https://www.cnblogs.com/yanjieli/p/"http://nginx.org/">nginx.org</a>.<br/>Commercial support is available at<a href=https://www.cnblogs.com/yanjieli/p/"http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p></body></html>[root@k8s-node2 ~]# curl 10.244.1.12 #kubernetes集群的node節點上訪問<!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 andworking. Further configuration is required.</p><p>For online documentation and support please refer to<a href=https://www.cnblogs.com/yanjieli/p/"http://nginx.org/">nginx.org</a>.<br/>Commercial support is available at<a href=https://www.cnblogs.com/yanjieli/p/"http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p></body></html>
上面訪問是基于一個pod的情況下，但是，當這個pod由于某種原因意外掛掉了，或者所在的節點掛掉了，那么deployment控制器會立即創建一個新的pod，這時候再去訪問這個IP就訪問不到了，而我們不可能每次去到節點上看到IP再進行訪問，測驗如下：
[root@k8s-master ~]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-685cc95cd4-9z4f4 1/1 Running 0 99m 10.244.1.12 k8s-node1 <none> <none>[root@k8s-master ~]# kubectl delete pods nginx-685cc95cd4-9z4f4 #洗掉上面的podpod "nginx-685cc95cd4-9z4f4" deleted[root@k8s-master ~]# kubectl get pods -o wide #可以看出，當上面pod剛洗掉，接著deployment控制器又馬上創建了一個新的pod，且這次分配在k8s-node2節點上了，NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-685cc95cd4-z5z9p 1/1 Running 0 89s 10.244.2.14 k8s-node2 <none> <none>[root@k8s-master ~]# curl 10.244.1.12 #訪問之前的pod，可以看到已經不能訪問curl: (7) Failed connect to 10.244.1.12:80; 沒有到主機的路由[root@k8s-master ~]# [root@k8s-master ~]# curl 10.244.2.14 #訪問新的pod，可以正常訪問<!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 andworking. Further configuration is required.</p><p>For online documentation and support please refer to<a href=https://www.cnblogs.com/yanjieli/p/"http://nginx.org/">nginx.org</a>.<br/>Commercial support is available at<a href=https://www.cnblogs.com/yanjieli/p/"http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p></body></html>
部署Service物件
簡單來說，一個
Service物件可視作通過其標簽選擇器過濾出的一組Pod物件，并能夠為此組Pod物件監聽的套接字提供埠代理及調度服務，就好比上面做的測驗，如果沒有Service，那么每次都得去訪問pod物件自己的地址等，且那還只是創建了一個pod物件，如果是多個，那么該如何是好？故使用Service解決此問題，
1）創建Service物件(將Service埠代理至Pod埠示例)
"kubectl expose"命令可用于創建Service物件以將應用程式“暴露”（expose）于網路中，
#方法一[root@k8s-master ~]# kubectl expose deployment nginx --name=nginx-svc --port=80 --target-port=80 --protocol=TCP #為deployment的nginx創建service，取名叫nginx-svc，并通過service的80埠轉發至容器的80埠上，service/nginx-svc exposed#方法二[root@k8s-master ~]# kubectl expose deployment/nginx --name=nginx-svc --port=80 --target-port=80 --protocol=TCPservice/nginx-svc exposed###引數說明：--name 指定service物件的名稱--port 指定service物件的埠--target-port 指定pod物件容器的埠--protocol 指定協議[root@k8s-master ~]# kubectl get svc #查看service物件，或者kubectl get serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 25hnginx-svc ClusterIP 10.109.54.136 <none> 80/TCP 41s
這時候可以在kubernetes集群上所有節點上直接訪問nginx-svc的cluster-ip及可訪問到名為deployment控制器下nginx的pod，并且，集群中的別的新建的pod都可以直接訪問這個IP或者這個service名稱即可訪問到名為deployment控制器下nginx的pod，示例：
# master節點上通過ServiceIP進行訪問[root@k8s-master ~]# curl 10.109.54.136 <!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 andworking. Further configuration is required.</p><p>For online documentation and support please refer to<a href=https://www.cnblogs.com/yanjieli/p/"http://nginx.org/">nginx.org</a>.<br/>Commercial support is available at<a href=https://www.cnblogs.com/yanjieli/p/"http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p></body></html>#新建一個客戶端pod進行訪問，這里這個客戶端使用busybox鏡像，且pod副本數量為1個，-it表示進入終端模式，--restart=Never，表示從不重啟，[root@k8s-master ~]# kubectl run client --image=busybox --replicas=1 -it --restart=NeverIf you don't see a command prompt, try pressing enter./ # wget -O - -q 10.109.54.136 #訪問上面創建的（service）nginx-svc的IP<!DOCTYPE html><html><head><title>Welcome to nginx!</title>....../ # / # wget -O - -q nginx-svc #訪問上面創建的（service）名稱nginx-svc<!DOCTYPE html><html><head><title>Welcome to nginx!</title>
2）創建Service物件(將創建的Pod物件使用“NodePort”型別的服務暴露到集群外部)
[root@k8s-master ~]# kubectl run mynginx --image=nginx:1.12 --port=80 --replicas=2 #創建一個deployments控制器并使用nginx鏡像作為容器運行的應用，[root@k8s-master ~]# kubectl get pods #查看創建的podNAME READY STATUS RESTARTS AGEclient 1/1 Running 0 15hmynginx-68676f64-28fm7 1/1 Running 0 24smynginx-68676f64-9q8dj 1/1 Running 0 24snginx-685cc95cd4-z5z9p 1/1 Running 0 16h[root@k8s-master ~]# [root@k8s-master ~]# kubectl expose deployments/mynginx --type="NodePort" --port=80 --name=mynginx-svc #創建一個service物件，并將mynginx創建的pod物件使用NodePort型別暴露到集群外部，service/mynginx-svc exposed[root@k8s-master ~]# [root@k8s-master ~]# kubectl get svc #查看serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 41hmynginx-svc NodePort 10.111.89.58 <none> 80:30884/TCP 10snginx-svc ClusterIP 10.109.54.136 <none> 80/TCP 15h###欄位說明：PORT(S) 這里的mynginx-svc物件可以看出，集群中各作業節點會捕獲發往本地的目標埠為30884的流量，并將其代理至當前service物件的80埠，于是集群外部的用戶可以使用當前集群中任一節點的此埠來請求Service物件上的服務，[root@k8s-master ~]# [root@k8s-master ~]# netstat -nlutp |grep 30884 #查看master節點上是否有監聽上面的30884埠tcp6 0 0 :::30884 :::* LISTEN 7340/kube-proxy[root@k8s-node1 ~]# [root@k8s-node1 ~]# netstat -nlutp |grep 30884 #查看node節點是否有監聽上面的30884埠tcp6 0 0 :::30884 :::* LISTEN 2537/kube-proxy
客戶端訪問kubernetes集群的30884埠
3）Service資源物件的描述
“kuberctl describe services”命令用于列印Service物件的詳細資訊，它通常包括Service物件的Cluster IP，關聯Pod物件使用的標簽選擇器及關聯到的Pod資源的端點等，示例
[root@k8s-master ~]# kubectl describe service mynginx-svcName: mynginx-svcNamespace: defaultLabels: run=mynginxAnnotations: <none>Selector: run=mynginxType: NodePortIP: 10.111.89.58Port: <unset> 80/TCPTargetPort: 80/TCPNodePort: <unset> 30884/TCPEndpoints: 10.244.1.14:80,10.244.2.15:80Session Affinity: NoneExternal Traffic Policy: ClusterEvents: <none>###欄位說明：Selector 當前Service物件使用的標簽選擇器，用于選擇關聯的Pod物件Type 即Service的型別，其值可以是ClusterIP、NodePort和LoadBalancer等其中之一IP 當前Service物件的ClusterIPPort 暴露的埠，即當前Service用于接收并回應的埠TargetPort 容器中的用于暴露的目標埠，由Service Port路由請求至此埠NodePort 當前Service的NodePort，它是否存在有效值與Type欄位中的型別相關Endpoints 后端端點，即被當前Service的Selector挑中的所有Pod的IP及其埠Session Affinity 是否啟用會話粘性External Traffic Policy 外部流量的調度策略
擴容和縮容
所謂的“伸縮（
Scaling）”就是指改變特定控制器上Pod副本數量的操作，“擴容（scaling up）”即為增加副本數量，而“縮容（scaling down）"則指縮減副本數量，不過，不論是擴容還是縮容，其數量都需要由用戶明確給出，
Service物件內建的負載均衡機制可在其后端副本數量不止一個時自動進行流量分發，它還會自動監控關聯到的Pod的健康狀態，以確保將請求流量分發至可用的后端Pod物件，若某Deployment控制器管理包含多個Pod實體，則必要時用戶還可以為其使用“滾動更新”機制將其容器鏡像升級到新的版本或變更那些支持動態修改的Pod屬性，使用
kubect run命令創建Deployment物件時，“--replicas=”選項能夠指定由該物件創建或管理的Pod物件副本的數量，且其數量支持運行時進行修改，并立即生效，“kubectl scale”命令就是專用于變動控制器應用規模的命令，它支持對Deployment資源物件的擴容和縮容操作，
上面示例中創建的Deployment物件nginx僅創建了一個Pod物件，其所能夠承載的訪問請求數量即受限于這單個Pod物件的服務容量，請求流量上升到接近或超出其容量之前，可以通過kubernetes的“擴容機制”來擴招Pod的副本數量，從而提升其服務容量，
擴容示例
[root@k8s-master ~]# kubectl get pods -l run=nginx #查看標簽run=nginx的podNAME READY STATUS RESTARTS AGEnginx-685cc95cd4-z5z9p 1/1 Running 0 17h[root@k8s-master ~]# [root@k8s-master ~]# kubectl scale deployments/nginx --replicas=3 #將其擴容到3個deployment.extensions/nginx scaled[root@k8s-master ~]# [root@k8s-master ~]# kubectl get pods -l run=nginx #再次查看NAME READY STATUS RESTARTS AGEnginx-685cc95cd4-f2cwb 1/1 Running 0 5snginx-685cc95cd4-pz9dk 1/1 Running 0 5snginx-685cc95cd4-z5z9p 1/1 Running 0 17h[root@k8s-master ~]# [root@k8s-master ~]# kubectl describe deployments/nginx #查看Deployment物件nginx詳細資訊Name: nginxNamespace: defaultCreationTimestamp: Thu, 29 Aug 2019 15:29:31 +0800Labels: run=nginxAnnotations: deployment.kubernetes.io/revision: 1Selector: run=nginxReplicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailableStrategyType: RollingUpdate...#由nginx自動創建的pod資源全部擁有同一個標簽選擇器“run=nginx”，因此，前面創建的Service資源物件nginx-svc的后端端點也已經通過標簽選擇器自動擴展到了這3個Pod物件相關的端點[root@k8s-master ~]# kubectl describe service/nginx-svcName: nginx-svcNamespace: defaultLabels: run=nginxAnnotations: <none>Selector: run=nginxType: ClusterIPIP: 10.109.54.136Port: <unset> 80/TCPTargetPort: 80/TCPEndpoints: 10.244.1.15:80,10.244.2.14:80,10.244.2.16:80Session Affinity: NoneEvents: <none>
縮容示例
縮容的方式和擴容相似，只不過是將
Pod副本的數量調至比原來小的數字即可，例如將nginx的pod副本縮減至2個
[root@k8s-master ~]# kubectl scale deployments/nginx --replicas=2deployment.extensions/nginx scaled[root@k8s-master ~]# [root@k8s-master ~]# kubectl get pods -l run=nginxNAME READY STATUS RESTARTS AGEnginx-685cc95cd4-pz9dk 1/1 Running 0 10mnginx-685cc95cd4-z5z9p 1/1 Running 0 17h
洗掉物件
有一些不再有價值的活動物件可使用
“kubectl delete”命令予以洗掉，需要洗掉Service物件nginx-svc時，即可使用下面命令完成：
[root@k8s-master ~]# kubectl get services #查看當前所有的service物件NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 43hmynginx-svc NodePort 10.111.89.58 <none> 80:30884/TCP 96mnginx-svc ClusterIP 10.109.54.136 <none> 80/TCP 17h[root@k8s-master ~]# kubectl delete service nginx-svc #洗掉service物件nginx-svc
有時候要清空某一型別下的所有物件，只需要將上面的命令物件的名稱快取
“--all”選項便能實作，例如，洗掉默認名稱空間中所有的Deployment控制器的命令如下：
[root@k8s-master ~]# kubectl delete deployment --alldeployment.extensions "mynginx" deleted
注意：受控于控制器的Pod物件在洗掉后會被重建，洗掉此類物件需要直接洗掉其控制器物件，不過，洗掉控制器時若不想洗掉其Pod物件，可在洗掉命令上使用“--cascade=false“選項，
雖然直接命令式管理的相關功能強大且適合用于操縱
Kubernetes資源物件，但其明顯的缺點是缺乏操作行為以及待運行物件的可信源，另外，直接命令式管理資源物件存在較大的局限性，它們在設定資源物件屬性方面提供的配置能力相當有限，而且還有不少資源并不支持命令操作進行創建，例如，用戶無法創建帶有多個容器的Pod物件，也無法為Pod物件創建存盤卷，因此，管理資源物件更有效的方式是基于保存有物件配置資訊的配置清單來進行，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/57249.html
標籤：其他