Pod

pod 可以有多個 副本，比如 slave 實際上是 pod 的副本，單一的 pod 存在唯一的 node 上。

• IP 分配的單位， pod 容器共享
• pod 容器共享 volume, pod所有容器可以共享多個 docker 容器的 fs 下的 volume
• 同一個pod 容器可以共享 IPC UTS namespace
• pod 擁有屬性 labels，key 獨一無二，1當成是 map

pod 信息有：

• Shared storage, as Volumes
• Networking, as a unique cluster IP address
• Information about how to run each container, such as the container image version or specific ports to use

我們之前說過， pod 類似邏輯主機， 在邏輯主機中運行的進程共享諸如 CPU 、 RAM、 網絡接口等資源。 入們會期望進程也能共享磁盤， 但事實并非如此。 需要謹 記 一 點， pod 中的每個容器都有自己獨立的文件系統， 因為文件系統來自容器鏡像。

pods

apiVersion: v1 kind: Pod # P 要大寫 metadata:name: mwish-bot spec:containers:- image: redisname: mredisports:- containerPort: 6379protocol: TCP

然后在這里可以：

kubectl create -f p.yaml

第一次 check 的時候：

? k8s kubectl get pods NAME READY STATUS RESTARTS AGE mwish-bot 0/1 ContainerCreating 0 55s

等鏡像被拉下來就是 running 了。

? k8s kubectl get pods NAME READY STATUS RESTARTS AGE mwish-bot 1/1 Running 0 6m2s

（這個時候 docker ps 竟然沒有，不科學？）

然后可以看 log:

mwish-bot 1/1 Running 0 6m2s ? k8s kubectl logs mwish-bot 1:C 08 Feb 2020 19:17:28.146 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1:C 08 Feb 2020 19:17:28.146 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=1, just started 1:C 08 Feb 2020 19:17:28.146 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf 1:M 08 Feb 2020 19:17:28.153 * Running mode=standalone, port=6379. 1:M 08 Feb 2020 19:17:28.153 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 1:M 08 Feb 2020 19:17:28.154 # Server initialized 1:M 08 Feb 2020 19:17:28.155 * Ready to accept connections

開啟端口轉發之后，就可以連接了：

kubectl port-forward mwish-bot 6379:6379

然后：

redis-cli

可以操作。

我們可以拿到標簽：

? k8s kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS mwish-bot 1/1 Running 0 10m <none>

加上標簽之后可以根據標簽過濾：

? k8s kubectl get pods -L env NAME READY STATUS RESTARTS AGE ENV mwish-bot 1/1 Running 0 25s prod

對于pod 還有 ns:

? k8s kubectl get po --namespace kube-system NAME READY STATUS RESTARTS AGE coredns-d5947d4b-cxp4s 1/1 Running 1 38h coredns-d5947d4b-czpwz 1/1 Running 1 38h etcd-minikube 1/1 Running 0 38h kube-addon-manager-minikube 1/1 Running 0 38h kube-apiserver-minikube 1/1 Running 0 38h kube-controller-manager-minikube 1/1 Running 0 38h kube-proxy-jcvd4 1/1 Running 0 38h kube-scheduler-minikube 1/1 Running 0 38h storage-provisioner 1/1 Running 0 38h

• ns
• selector
• 你可以給固定節點打 tag

你可以用來給 node 打 tag, 比如 gpu = true , 便于調度。

Probe

用于檢測。其實你可以看看 redis 的 k8s-yaml

實際上有個 livenessProbe，例如：

https://github.com/spotahome/redis-operator/blob/89d5715fe74842e81b870ed6522949316a08dcdf/operator/redisfailover/service/generator.go#L282

這里會讓 redis cli 去 ping. 實際上應用 OOM 之類的可能容器還在，但是服務事實上是不可用的。可能有的還會在 http 上綁定 /health

ReplicaContoller

ReplicationController是一種Kubemetes資源，可確保它的pod始終保持運行狀態。 如果pod因任何原因 消失(例如節點從集群中消失或由于該pod已從節點中逐出)， 則ReplicationController 會注意到缺少了pod并創建替代pod。

• 對于沒有 rc 甚至什么都沒有的， node 掛了就真的掛了
• 有托管的話，會創建一個新的 replica.

ReplicationController會持續監控正在運行的pod列表， 并保證相應 ” 類型” 的 pod的數目與期望相符。 如正在運行的pod太少， 它會根據pod模板創建新的副本。 如正在運行的pod太多， 它將刪除多余的副本。

ReplicationController 不是根據pod類型來執行 操作的， 而是根據pod是否匹配某個標簽選擇器(前 一 章 中了解了它們)。

包括的內容有：

• label selector
• count
• pod template

它能:

• 確保 一 個 pod (或多個 pod 副本)持續運行， 方法是在現有 pod 丟失時啟動 一 個新 pod。
• 集群節點發生故障時， 它將為故障節 點 上運 行的所有 pod (即受 ReplicationController 控制的節點上的那些 pod) 創建替代副本。
• 它能輕松實現 pod的水平伸縮 手動和自動都可以(參見第 15 章中的 pod的水平自動伸縮)。

(pod 實例永遠不會重新安置到另一個節點。 相反， ReplicationController 會 創建一個全新的 pod 實例， 它與正在替換的實例無關。)

可以通過 scale 等方式擴展 replica set.

下面我們創建了一個 ReplicationController:

? k8s cat p-rc.yaml apiVersion: v1 kind: ReplicationController metadata:name: rs-mwish-bot spec:replicas: 3selector:app: mwish-bottemplate:metadata:labels:app: mwish-botspec:containers:- name: mwish-botimage: redisports:- containerPort: 6379

apply 之后可以 get pods :

? k8s kubectl get pods NAME READY STATUS RESTARTS AGE mwish-bot 1/1 Running 0 8m15s rs-mwish-bot-fh8j8 1/1 Running 0 2m55s rs-mwish-bot-q4ntt 1/1 Running 0 2m55s

讓我們 delete 原來的 pod 吧：

? k8s kubectl get pods NAME READY STATUS RESTARTS AGE mwish-bot 1/1 Running 0 8m15s rs-mwish-bot-fh8j8 1/1 Running 0 2m55s rs-mwish-bot-q4ntt 1/1 Running 0 2m55s ? k8s kubectl delete pod mwish-bot pod "mwish-bot" deleted ? k8s kubectl get pods NAME READY STATUS RESTARTS AGE rs-mwish-bot-5ld94 0/1 ErrImagePull 0 20s rs-mwish-bot-fh8j8 1/1 Running 0 3m41s rs-mwish-bot-q4ntt 1/1 Running 0 3m41s ? k8s

（為什么會 ErrImagePull...)

? k8s kubectl get pods NAME READY STATUS RESTARTS AGE rs-mwish-bot-5ld94 1/1 Running 0 50s rs-mwish-bot-fh8j8 1/1 Running 0 4m11s rs-mwish-bot-q4ntt 1/1 Running 0 4m11s

好了，恢復了。

我們看看 rc :

? k8s kubectl get rc NAME DESIRED CURRENT READY AGE rs-mwish-bot 3 3 3 5m7s

由于我們是按照標簽來的，所以我們 overwrite 一下標簽，有趣的就來了：

? k8s kubectl label pod rs-mwish-bot-5ld94 app=nmsl --overwrite pod/rs-mwish-bot-5ld94 labeled ? k8s kubectl get pods NAME READY STATUS RESTARTS AGE rs-mwish-bot-5ld94 1/1 Running 0 7m35s rs-mwish-bot-fh8j8 1/1 Running 0 10m rs-mwish-bot-q4ntt 1/1 Running 0 10m rs-mwish-bot-tvpr7 0/1 ContainerCreating 0 5s

下面我們再試試更改 scale, 你當然可以更新它的 yaml 文件，不過你更可以：

? k8s kubectl scale rc rs-mwish-bot --replicas=5 replicationcontroller/rs-mwish-bot scaled ? k8s kubectl get pods NAME READY STATUS RESTARTS AGE rs-mwish-bot-5ld94 1/1 Running 0 20m rs-mwish-bot-fh8j8 1/1 Running 0 23m rs-mwish-bot-nbtfr 0/1 ContainerCreating 0 6s rs-mwish-bot-pvfg9 0/1 ContainerCreating 0 6s rs-mwish-bot-q4ntt 1/1 Running 0 23m rs-mwish-bot-tvpr7 1/1 Running 0 12m

---

kubectl delete 刪除 ReplicationController 時， pod 也會被刪除。 但是由于由 ReplicationController 創建的 pod 不是 ReplicationController 的組成部分， 只是由其進行管理， 因此可以只刪除 ReplicationController 并保待 pod 運行

ReplicaSet 是 rc 的升級版，不是 v1 的一部分。提供了更強的選擇器。但是目前我不介紹吧。ReplicationController 應該替換為 ReplicaSet 和 Deployment, 它們提供類似的功能和更強的能力。

DeamonSet

你可以看到現有的 DeamonSet:

? k8s kubectl get ns NAME STATUS AGE chaos-testing Active 23h default Active 23h kube-node-lease Active 23h kube-public Active 23h kube-system Active 23h ? k8s kubectl get ds No resources found. ? k8s kubectl get ds -n kube-system NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE kube-proxy 1 1 1 1 1 <none> 23h local-volume-provisioner 1 1 1 1 1 <none> 23h ? k8s? 執行批處理任務的 pod 應通過 Kubernetes Job 資源創建， 而不是直接或通過
ReplicationController 或類似對象創建。 ? 需要在未來某個時候運行的 Job 可以通過 CronJob 資源創建。

Job 這幾節我就簡單看了下, 假設：

• 你有一個運行中的集群
• 你希望運行一個測試腳本

比如說我們希望對一個 tidb 的數據庫集群跑 go-tpc https://github.com/pingcap/go-tpc:

FROM golang:alpine3.10 AS build_baseRUN apk add --no-cache gcc make bash git curlENV GO111MODULE=on RUN mkdir /src WORKDIR /src COPY go.mod . COPY go.sum .RUN go mod downloadCOPY . .RUN make buildFROM alpine:3.8RUN apk update && apk upgrade && apk add --no-cache bash curl wgetCOPY --from=0 /src/bin/* /bin/

這個時候，我們把這個 dockerfile 編譯成鏡像然后 push 到 http://docker.io 之后，可以寫一個對應的 yaml 來描述 job:

apiVersion: batch/v1 kind: Job metadata:name: run-go-tpcnamespace: mwish-1k-test spec:template: metadata:name: run-go-tpcspec:containers:- name: run-go-tpcimage: mwish117/mwish-go-tpccommand: ["/bin/go-tpc", "tpcc", "-H", "10.23.255.222", "--warehouses", "1000", "-T", "200", "run"]restartPolicy: Never

它會創建一個 "${run-go-tpc}-${random}" 的名字, 然后運行這個 Job.

總結

以上是生活随笔為你收集整理的pod实例数是什么意思_[灌水] Kubernetes In Action: Pod的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。