這篇文章主要為大家分享Kubernetes管理pod資源對象的方法。文中還介紹了Kubernetes中的Namespace，希望大家通過這篇文章能有所收獲。
Deployment、Service、Pod是k8s最核心的3個資源對象
Deployment：最常見的無狀態應用的控制器，支持應用的擴縮容、滾動升級等操作。
Service：為彈性變動且存在生命周期的Pod對象提供了一個固定的訪問接口，用于服務發現和服務訪問。
Pod：是運行容器以及調度的最小單位。同一個pod可以同時運行多個容器，這些容器共享net、UTS、IPC，除此之外還有USER、PID、MOUNT。
ReplicationController：用于確保每個Pod副本在任意時刻都能滿足目標數量，簡單來說，它用于每個容器或容器組總是運行并且可以訪問的：老一代無狀態的Pod應用控制器。
RwplicatSet：新一代的無狀態的Pod應用控制器，它與RC的不同之處在于支持的標簽選擇器不同，RC只支持等值選擇器（鍵值對），RS還額外支持基于集合的選擇器。
StatefulSet：用于管理有狀態的持久化應用，如database服務程序，它與Deployment不同之處在于，它會為每一個pod創建一個獨有的持久性標識符，并確保每個pod之間的順序性。
DaemonSet：用于確保每一個節點都運行了某個pod的一個副本，新增的節點一樣會被添加到此類pod，在節點移除時，此pod會被回收。
Job：用于管理運行完成后即可終止的應用，例如批量處理做作業任務；
- Pending：Pod已經被創建，但是一個或者多個容器還未創建，這包括Pod調度階段，以及容器鏡像的下載過程。
- Running：Pod已經被調度到Node，所有容器已經創建，并且至少一個容器在運行或者正在重啟。
- Succeeded：Pod中所有容器正常退出。
- Failed：Pod中所有容器退出，至少有一個容器是一次退出的。
Pod是能夠被創建、調度和管理的最小單元；
每個Pod都有一個獨立的IP；
一個Pod由一個或多個容器構成，并共享命名空間和共享存儲等；Pod所有容器在同一個Node上；
容器生命周期管理；
對資源使用進行限制，resources（requests、limits）；
對容器進行探測：livenessProbe；
集群內的Pod之間都可以任意訪問，這一般是通過一個二層網絡來實現的。
在Docker中，容器是最小的處理單元，增刪改查的對象是容器，容器是一種虛擬化技術，容器之間是隔離的，隔離是基于Linux Namespace實現的。
而在K8S中，Pod包含一個或者多個相關的容器，Pod可以認為是容器的一種延伸擴展，一個Pod也是一個隔離體，而Pod內部包含的一組容器又是共享的（包括PID、Network、IPC、UTS）。除此之外，Pod中的容器可以訪問共同的數據卷來實現文件系統的共享。
創建Pod時，可以指定計算資源（目前支持的資源類型有CPU和內存），即指定每個容器的資源請求（Request）和資源限制（Limit），資源請求是容器所需的最小資源需求，資源限制則是容器不能超過的資源上限。關系是： 0<=request<=limit<=infinity
Pod的資源請求就是Pod中所有容器資源請求之和。K8S在調度Pod時，會根據Node中的資源總量（通過cAdvisor接口獲得），以及該Node上已使用的計算資源，來判斷該Node是否滿足需求。
資源請求能夠保證Pod有足夠的資源來運行，而資源限制則是防止某個Pod無限制地使用資源，導致其他Pod崩潰。特別是在公有云場景，往往會有惡意軟件通過搶占內存來平臺。
具體配置請見http://blog.csdn.net/liyingke112/article/details/77452630
Pod主要是在容器化環境中建立一個面向應用的“邏輯主機”模型，它可以包含一個或多個相互間緊密聯系的容器。當其中任一容器異常時，該Pod也隨之異常。
一pod多容器，讓多個同應用的單一容器整合到一個類虛擬機中，使其所有容器共用一個vm的資源，提高耦合度，從而方便副本的復制，提高整體的可用性。
同個Pod下的容器之間能更方便的共享數據和通信，使用相同的網絡命名空間、IP地址和端口區間，相互之間能通過localhost來發現和通信。
在同個Pod內運行的容器共享存儲空間（如果設置），存儲卷內的數據不會在容器重啟后丟失，同時能被同Pod下別的容器讀取。
相比原生的容器接口，Pod通過提供更高層次的抽象，簡化了應用的部署和管理，不同容器提供不同服務。Pod就像一個管理橫向部署的單元，主機托管、資源共享、協調復制和依賴管理都可以自動處理。
核心原則是：將多個應用分散到多個Pod中
原因：基于資源的合理應用；擴縮容，不同應用應該有不同的擴縮容策略等。
如果容器之間不是必須運行在一起的話，那么就放到不同的Pod里
如果容器之前是相互獨立的組件，那么就放到不同的Pod里
如果容器之前擴縮容策略不一樣，那么就放到不同的Pod里
結論：單Pod單容器應用，除非特殊原因
| 主機 | IP地址 | 服務 |
|---|---|---|
| master | 192.168.1.21 | k8s |
| node01 | 192.168.1.22 | k8s |
| node02 | 192.168.1.23 | k8s |
基于https://blog.51cto.com/14320361/2464655 的實驗繼續進行
默認的名稱空間：Default
Namespace（命名空間）是kubernetes系統中的另一個重要的概念，通過將系統內部的對象“分配”到不同的Namespace中，形成邏輯上分組的不同項目、小組或用戶組，便于不同的分組在共享使用整個集群的資源的同時還能被分別管理。
Kubernetes集群在啟動后，會創建一個名為“default”的Namespace，如果不特別指明Namespace，則用戶創建的Pod、RC、Service都被系統創建到“default”的Namespace中。
[root@master ~]# kubectl get namespaces
[root@master ~]# kubectl describe ns default
[root@master ~]# kubectl create ns bdqn[root@master ~]# kubectl get namespaces
[root@master ~]# kubectl explain ns
//查看nasespace的yaml文件的格式[root@master ~]# vim test-ns.yaml
apiVersion: v1
kind: Namespace
metadata:
name: test[root@master ~]# kubectl apply -f test-ns.yaml [root@master ~]# kubectl get ns
[root@master ~]# kubectl delete ns test
[root@master ~]# kubectl delete -f test-ns.yaml 注意：namespace資源對象進用于資源對象的隔離，并不能隔絕不同名稱空間的Pod之間的通信。那是網絡策略資源的功能。
可使用--namespace或-n選項
[root@master ~]# kubectl get pod -n kube-system
[root@master ~]# kubectl get pod --namespace kube-system [root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
name: test-pod
spec:
containers:
- name: test-app
image: 192.168.1.21:5000/web:v1pod的yaml文件不支持replicas字段
[root@master ~]# kubectl apply -f pod.yaml [root@master ~]# kubectl get pod
ps：這個pod因為是自己創建的，所以刪除之后k8s并不會自動生成，相當于docker中創建
[root@master ~]# vim pod.yaml
kind: Pod #資源類型
apiVersion: v1 #api版本
metadata:
name: test-pod #指定控制器名稱
namespace: bdqn #指定namespace（名稱空間）
spec:
containers: #容器
- name: test-app #容器名稱
image: 192.168.1.21:5000/web:v1 #鏡像[root@master ~]# kubectl apply -f pod.yaml [root@master ~]# kubectl get pod -n bdqn
//根據namespace名稱查看
Always：鏡像標簽為“laster”或鏡像不存在時，總是從指定的倉庫中獲取鏡像。
IfNotPresent：僅當本地鏡像不存在時才從目標倉庫下載。
Never：禁止從倉庫中下載鏡像，即只使用本地鏡像。
注意：對于標簽為“laster”或者標簽不存在，其默認的鏡像下載策略為“Always”，而對于其他的標簽鏡像，默認策略為“IfNotPresent”。
[root@master ~]# vim pod.yaml
kind: Pod #資源類型
apiVersion: v1 #api版本
metadata:
name: test-pod #指定控制器名稱
namespace: bdqn #指定namespace（名稱空間）
spec:
containers: #容器
- name: test-app #容器名稱
image: 192.168.1.21:5000/web:v1 #鏡像
imagePullPolicy: IfNotPresent #獲取的策略
ports:
- protocol: TCP
containerPort: 80 [root@master ~]# kubectl delete pod -n bdqn test-pod [root@master ~]# kubectl apply -f pod.yaml [root@master ~]# kubectl get pod -n bdqn 
[root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
name: test-pod
namespace: bdqn
spec:
containers:
- name: test-app
image: 192.168.1.21:5000/web:v1
imagePullPolicy: IfNotPresent
ports:
- protocol: TCP
containerPort: 90 #改一下端口[root@master ~]# kubectl delete pod -n bdqn test-pod [root@master ~]# kubectl apply -f pod.yaml [root@master ~]# kubectl get pod -n bdqn -o wide
會發現修改的90端口并不生效，他只是一個提示字段并不生效。
[root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
name: test-pod
namespace: bdqn
labels: #標簽
app: test-web #標簽名稱
spec:
containers:
- name: test-app
image: 192.168.1.21:5000/web:v1
imagePullPolicy: IfNotPresent
ports:
- protocol: TCP
containerPort: 90 #改一下端口[root@master ~]# vim test-svc.yaml
apiVersion: v1 #api版本
kind: Service #資源類型
metadata:
name: test-svc #指定控制器名稱
namespace: bdqn #指定namespace（名稱空間）
spec:
selector: #標簽
app: test-web #標簽名稱（須和pod的標簽名稱一致）
ports:
- port: 80 #宿主機端口
targetPort: 80 #容器端口會發現添加的80端口生效了，所以不能亂改。
[root@master ~]# kubectl apply -f test-svc.yaml[root@master ~]# kubectl get svc -n bdqn 
[root@master ~]# kubectl describe svc -n bdqn test-svc 
[root@master ~]# curl 10.98.57.97 
Pod的重啟策略（RestartPolicy）應用與Pod內所有容器，并且僅在Pod所處的Node上由kubelet進行判斷和重啟操作。當某個容器異常退出或者健康檢查失敗時，kubelet將根據RestartPolicy的設置來進行相應的操作。
Always：（默認情況下使用）但凡Pod對象終止就將其重啟；
OnFailure：僅在Pod對象出現錯誤時才將其重啟；
Never：從不重啟；
每個容器啟動時都會執行一個進程，此進程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果進程退出時返回碼非零，則認為容器發生故障，Kubernetes 就會根據 restartPolicy 重啟容器。
下面我們模擬一個容器發生故障的場景，Pod 配置文件如下：
[root@master ~]# vim healcheck.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: healcheck
name: healcheck
spec:
restartPolicy: OnFailure #指定重啟策略
containers:
- name: healcheck
image: busybox:latest
args: #生成pod時運行的命令
- /bin/sh
- -c
- sleep 20; exit 1 [root@master ~]# kubectl apply -f healcheck.yaml[root@master ~]# kubectl get pod -o wide
[root@master ~]# kubectl get pod -w | grep healcheck
在上面的例子中，容器進程返回值非零，Kubernetes 則認為容器發生故障，需要重啟。但有不少情況是發生了故障，但進程并不會退出。
[root@master ~]# kubectl create ns xgp[root@master ~]# kubectl get ns xgp 
[root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
name: test-pod
namespace: xgp
labels:
app: test-web
spec:
restartPolicy: Never
containers:
- name: www
image: 192.168.1.21:5000/web:v1
imagePullPolicy: Never
args:
- /bin/sh
- -c
- sleep 90; exit 1
ports:
- protocol: TCP
containerPort: 80[root@master ~]# kubectl apply -f pod.yaml [root@master ~]# kubectl get pod -n xgp -w | grep test-pod
刪除test-pod
[root@master ~]# kubectl delete pod -n xgp test-pod
[root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
name: test-pod
namespace: xgp
labels:
app: test-web
spec:
restartPolicy: Never
containers:
- name: www
image: 192.168.1.21:5000/web:v1
imagePullPolicy: Never
ports:
- protocol: TCP
containerPort: 80[root@master ~]# vim svc.yaml
apiVersion: v1
kind: Service
metadata:
name: test-svc
namespace: xgp
spec:
selector:
app: test-web
ports:
- port: 80
targetPort: 80[root@master ~]# kubectl apply -f svc.yaml [root@master ~]# kubectl get pod -o wide -n xgp 
[root@master ~]# curl 10.244.1.21
看完上述內容，你們對pod資源對象有進一步的了解嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
