Pod：Kubernetes最小執行單元
目錄
- Pod：Kubernetes最小執行單元
- Pod基本概念理解
- Pod是什么
- 為什么需要Pod
- 通過Pod合理管理容器
- Pod 配置清單
- 運行中的Pod Yaml情況
- 定義一個簡單的Pod Yaml
- 與Pod通信的兩種方式
- 按需組織Pod
- 使用Label組織Pod
- 引入Label的意義
- 關于Label的幾種應用場景
- 與Label使用的相關命令
- 使用Namespace組織Pod
- 使用Label組織Pod
- 其他：
- 查Pod日志
- Pod基本概念理解
Pod基本概念理解
Pod是什么
Pod 是 Kubernetes 應用程式的基本執行單元,它是 Kubernetes 物件模型中創建或部署的最小和最簡單的單元，
一個Pod可以包括一個或者多個容器，當一個pod包含多個容器時，這些容器總是運行于同一個作業節點上，一個pod絕不會跨越多個作業節點，
為什么需要Pod
由上面可以知道，一個Pod由一個或多個容器構成，那這里首先需要問一個問題：為何多個容器（每個容器單行程）比單個容器包含多個行程要好？
我們可以這樣想，一個容器相當于一臺獨立的機器，而這臺機器運行多個行程是利索當然的，我們現在電腦也是這樣做的，容器被設計為每個容器只運行一個行程（除非行程本身產生子行程），像上面那樣一個機器里運行多個行程，記錄每個行程運行的日志資訊是我們必須要做的事情，這些行程的日志是記錄到相同的標準輸出中，此時我們很難確定每個行程分別發生了什么，所以要讓每個行程運行在自己的容器中，這也是Kubernetes和Docker期望做的事情，
由于不能將多個行程聚集在一個單獨的容器中，我們需要另一種更高級的結構來將單行程的多個容器系結在一起提供服務，并將它們作為一個單元進行管理，這就是為什么需要Pod的原因，
通過Pod合理管理容器
將多層應用分散到多個pod中：
如果前端和后端都在同一個容器中，那么兩者將始終在同一臺節點上運行；如果你有一個雙節點Kubemetes集群， 而只有一個單獨的pod,那么你將始終只會用一個作業節點，而不會充分利用第二個節點上的計算資源(CPU和記憶體），因此更合理的做法是將pod拆分到兩個作業節點上，允許Kubemetes將前端安排到一個節點， 將后端安排到另一個節點， 從而提高基礎架構的利用率，
基于擴縮容(scaling)考慮而分割到多個pod中：
對應K8s來說，不能橫向的scale 容器，只能scale pod，此時，如果你的frontend，backend容器屬于同一個Pod，k8s scale pod為2個pod，此時你就有了兩個frontend，backend容器，但真實情況是，你想要兩個backend，一個frontend，通常情況也是這樣，frontend和backend有不同的scaling需求，就不能放在一個Pod里，
何時在Pod中使用多個容器：
這個Pod由，一個主行程和多個輔行程構成，
決定兩個容器放入一個pod中還是兩個單獨的pod，我們需要考慮以下問題：
- 它們需要一起運行還是可以在不同的主機上運行？
- 它們代表的是一個整體還是相互獨立的組件？
- 它們必須一起進行擴縮容(scaling)還是可以分別進行？
Pod 配置清單
manifest是我們經常會遇到的，特別是 config manifest ：配置清單，
在準備manifest時，這里有個非常好用的工具，以pod為例：
-
kubectl explain pod：配置清單KIND: Pod VERSION: v1 DESCRIPTION: Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts FIELDS: apiVersion <string> ... kind <string> ... metadata <Object> ... spec <Object> ... status <Object> ... -
kubectl explain pod.metadata：配置清單里每一項的明細 -
kubectl explain pod.spec.nodeSelector：具體到某一項
運行中的Pod Yaml情況
一個正在運行的pod的完整描述包括三大重要部分，也幾乎在所有Kubemetes資源中都可以找到的三大重要部分：
- metadata 包括名稱、命名空間、標簽和關于該容器的其他資訊，
- spec (specification) 包含pod的明細，例如pod的容器、卷和其他資料，
- status包含運行中的pod的當前資訊，Pod中包含每個容器的資訊和狀態，
一個正在運行的pod的完整描述，其中包含了它的狀態，status部分包含只讀的運行時資料，該資料展示了這個時刻的資源狀態，而在創建新的pod時，并不需要提供status部分，
定義一個簡單的Pod Yaml
這是由一個容器構成的Pod，myapp.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod # Pod name
namespace: myapp
labels:
app: myapp
spec:
containers:
- name: myapp-container # 容器的name
image: busybox:latest
ports:
- containerPort: 8888 # 容器監聽的埠
protocol: TCP
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
- 使用這個yaml檔案
kubectl apply -f myapp.yaml
與Pod通信的兩種方式
1. 通過Service服務發現，Service請看這里，
2. 通過port-forward方式：
具體使用方式：kubectl port-forward -h
# Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
kubectl port-forward pod/mypod 5000 6000
# Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the
deployment
kubectl port-forward deployment/mydeployment 5000 6000
# Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the service
kubectl port-forward service/myservice 5000 6000
# Listen on port 8888 locally, forwarding to 5000 in the pod
kubectl port-forward pod/mypod 8888:5000
# Listen on port 8888 on all addresses, forwarding to 5000 in the pod
kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000
# Listen on port 8888 on localhost and selected IP, forwarding to 5000 in the pod
kubectl port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000
# Listen on a random port locally, forwarding to 5000 in the pod
kubectl port-forward pod/mypod :5000
按需組織Pod
使用Label組織Pod
引入Label的意義
下面這么多pod，功能上有相同有不同的：
使用Label標記：
- 不同功能的橫向維度
- 不同版本的縱向維度
關于Label的幾種應用場景
-
kube-controller行程通過資源物件RC上定義的Label Selector來篩選要監控的Pod副本的數量，從而實作Pod副本的數量始終符合預期設定的全自動控制流程，
-
kupe-proxy行程通過Service的Label Selector來選擇對應的Pod，自動建立器每個Service到對應Pod的請求轉發路由表，從而實作Service的智能負載均衡機制，
--- apiVersion: v1 kind: Pod metadata: labels: # pod設定label app: myapp ...... --- apiVersion: v1 kind: Service metadata: ...... spec: selector: # service中選擇這個label app: myapp ...... --- -
通過對某些Node定義特定的Label,并且在Pod定義檔案中使用NodeSelector這種標簽調度策略，Kube-scheduler行程可以實作Pod定向調度的特性，
# 給node打標簽之后，再用nodeSelector指定 kubectl label nodes node1 myapp.node/whoesnode=mynode
與Label使用的相關命令
- 增 Label
kubectl label pods <pod-name> <label-key>=<label-value>
- 刪 Label
kubectl label pods <label-key>- # 后面是一個 減號
- 查 Label
kubectl get pods --show-labels
kubectl get pods -l mylabel=label1 # 通過label1查pods
kubectl get pods -l mylabel='!label1' # 查排出label1的pods
kubectl get pods -A -L LABEL1,LABEL2
確保使用單引號來圈引電nv, 這樣bashshell才不會解釋感嘆號（感嘆號在bash中有特殊含義，表示事件指示器）
- 改 Label
kubectl label pods <pod-name> <label-key>=<new-value> --overwrite
使用Namespace組織Pod
使用Namespace組織Pods，往往這些Pod是處在同一個專案下的，
其他：
查Pod日志
kubectl logs podname -c containername：查看當前pod的某一容器日志，
但在某些情況下：有個容器因為某些故障被重新調度了，你想知道為什么前一個pod終止了，所以你想看的是前一個容器的日志，而不是當前容器的，
kubectl logs mypod --previous
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/73639.html
標籤：其他