寫在前面的話html
前面咱們提到過,純手敲 K8S 名稱管理 K8S 服務只是做爲咱們瞭解 K8S 的一種方案,而咱們最終管理 K8S 的方法仍是經過接下來的資源清單的方式進行管理。node
因此從本章節開始,將會迎來 K8S 的重中之重,咱們可否說咱們會 K8S 就看就看接下來的學習。web
另外,在 K8S 中,咱們須要樹立一個這樣的概念,幾乎能用到的東西均可以把它稱做資源,而這個定義了規則的 yaml 文件就是資源清單。docker
資源清單格式vim
資源清單格式:api
apiVersion: group/apiversion # 若是沒給定 group 名稱,默認 core,可以使用 kubectl api-versions 查看當前全部 kind: # 資源類別 metadata: # 資源元素據 name namespace # K8S 自身的 namespace labels # 標籤,鍵值對 annotations # 資源註解 spec: # 指望的狀態(最重要) status: # 當前狀態,用戶不用定義
查看支持的 apiVersion:app
獲取資源清單一級字段:框架
kubectl explain pod
結果如圖:frontend
獲取資源清單二級字段:tcp
kubectl explain pod.metadata
結果如圖:
同理,查看三級字段繼續使用 . 加關鍵字就好了。
建立第一個 Pod 資源清單
建立一個簡單的 Pod 資源清單:
vim pod-demo.yaml
內容以下:
apiVersion: v1 kind: Pod metadata: name: pod-demo namespace: default labels: app: pod-demo tier: frontend spec: containers: - name: app-container image: ikubernetes/myapp:v1 - name: busy-container image: busybox:latest command: ["/bin/sh", "-c", "sleep 3600"]
簡單說明:在咱們 explain 查看某個關鍵字下面的關鍵字的時候,若是關鍵字的值類型是:<[]Object>,則表明是列表對象,須要使用 -,若是是:<map[string]string>,則是鍵值對,不須要 - 。
在上面的 yaml 中,containers 就是列表對象,而 labels 就是鍵值對。
咱們能夠定義多個容器組成一個 Pod,以前咱們說過 Pod 由一個或者多個容器組成,同時咱們也可使用 command 指令來修改 Pod 中容器的初始運行命令。能夠以列表的形式,也能夠是 yaml 格式。我這裏爲例閱讀性,選用的是列表的形式。
根據文件建立 Pod:
# 建立 kubectl create -f pod-demo.yaml # 查看 kubectl get pods -o wide # 查看詳情 kubectl describe pod pod-demo
結果如圖:
咱們能夠在 describe 中看到咱們在 yaml 中定義的全部信息。甚至更多的包括系統給咱們補全的一些默認信息。
此時咱們能夠內部訪問一下咱們這個 Pod:
同時,資源清單 yaml 文件還給咱們提供了一個方便之處在於,咱們刪除變得更爲簡單:
kubectl delete -f pod-demo.yaml
結果如圖:可能會出現稍微卡一下
標籤選擇
咱們在這裏補充一個知識點,在上面咱們定義的資源清單中,在 metadata 中提到了 labels 標籤選項,那麼對於這個標籤咱們應該如何利用:
# 查看 pod 的標籤 kubectl get pods --show-labels
結果如圖:
標籤篩選:在判斷關係的時候,標籤的關係能夠是 =,!=,in,notin
# 顯示指定標籤的值 kubectl get pods -L app # 顯示包含指定標籤的 pod kubectl get pods -l app --show-labels # 顯示指定標籤爲指定值的 pod kubectl get pods -l app=pod-demo,tier=frontend --show-labels # 關係篩選 kubectl get pods -l "app in (pod-demo,pod-test,pod-dev)"
結果如圖:
給 Pod 打標籤或者修改標籤:
# 給 pod 打標籤 kubectl label pods pod-demo tag=v1.0 # 修改 pod 標籤 kubectl label pods pod-demo tag=v2.0 --overwrite
查看結果:
給節點打標籤:
kubectl label nodes node2 serverType=app
查看同理。
pod.spec 字段
對於 yaml 資源清單,咱們須要知道的是,其主要配置都在 spec 字段中。咱們這裏就針對 Pod 資源的 spec 裏面經常使用的方法作個說明:
pod.spec | |||
---|---|---|---|
containers | 容器相關配置 | ||
name | 容器名稱 | ||
image | 容器鏡像 | ||
imagePullPolicy | 容器獲取策略,Always / Never / IfNotPresent,鏡像版本是 latest 默認 Always | ||
ports | 說明端口。並不是暴露端口 | ||
name | 給這個端口命名,後面能夠根據這個名字調用這個端口 | ||
containerPort | 說明具體端口。並不是暴露端口 | ||
protocol | 協議,UDP / TCP / SCTP,默認 TCP | ||
hostIP | 綁定端口,意義不大,通常默認 0.0.0.0 | ||
command | 運行指定命令,替代 docker 中默認定義的 | ||
args | 參數,若是有配置,docker 中默認的參數將被改配置取代 | ||
livenessProbe | 存活性檢測 | ||
exec | command <[]string>,經過命令來直接探測 | ||
httpGet | HTTP 探測,host 主機通常不配置,port 請求端口,path | ||
tcpSocket | tcp 檢測 | ||
failureThreshold | 探測失敗次數,默認 3 次 | ||
periodSeconds | 每次間隔時間,默認 10 秒 | ||
timeoutSeconds | 超時時間,默認 1 秒 | ||
initialDelaySeconds | 容器啓動後多久開始探測 | ||
readinessProbe | 就緒性檢測 | ||
lifecycle | 生命週期 | ||
postStart | 啓動前,方法和 livenessProbe 相似 | ||
preStop | 啓動後,方法和 livenessProbe 相似 | ||
nodeSelector | 節點標籤選擇器,能夠限定 Pod 運行的節點 | ||
nodeName | 直接指定運行節點 | ||
restartPolicy | 重啓策略,Always / OnFailure / Never,默認 Always |
資源清單示例
在這以前咱們先給一個節點打標籤:
kubectl label nodes node2 serverType=app-server --overwrite
【1】普通的較爲完整的資源清單:
apiVersion: v1 kind: Pod metadata: name: pod-normal-demo namespace: default labels: app: erp tier: frontend release: stable annotations: ezops.cn/create-by: "Dylan" spec: containers: - name: myapp image: ikubernetes/myapp:v1 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 - name: https containerPort: 443 - name: busybox-demo image: busybox:latest imagePullPolicy: Always command: ["/bin/sh", "-c", "sleep 3600"] #args: ["-f", "-h /tmp"] nodeSelector: serverType: app-server restartPolicy: Never
咱們這裏修改了容器內部運行的默認命令。並經過標籤選擇器選擇了指定節點。配置了重啓規則。
kubectl create -f pod-normal-demo.yaml
查看建立結果:
能夠看到已經成功在咱們選擇的 Node 2 節點上面運行起來,查看詳情:(因爲內容太多,我直接貼處理)
Name: pod-normal-demo Namespace: default Priority: 0 PriorityClassName: <none> Node: node2/192.168.100.102 Start Time: Wed, 29 May 2019 09:56:11 +0800 Labels: app=erp release=stable tier=frontend Annotations: ezops.cn/create-by: Dylan Status: Running IP: 10.1.1.14 Containers: myapp: Container ID: docker://e4e97361c6cc533a4533080f06f7b596e0bc0caa954f7f2ef503d6d9a2aae631 Image: ikubernetes/myapp:v1 Image ID: docker-pullable://ikubernetes/myapp@sha256:9c3dc30b5219788b2b8a4b065f548b922a34479577befb54b03330999d30d513 Ports: 80/TCP, 443/TCP Host Ports: 0/TCP, 0/TCP State: Running Started: Wed, 29 May 2019 09:56:12 +0800 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-jr9rz (ro) busybox-demo: Container ID: docker://0cce3f9dcc16b40aabcceb94c44be49e3434bff28dfc6800c7769cd8d1d5948f Image: busybox:latest Image ID: docker-pullable://busybox@sha256:4b6ad3a68d34da29bf7c8ccb5d355ba8b4babcad1f99798204e7abb43e54ee3d Port: <none> Host Port: <none> Command: /bin/sh -c sleep 3600 State: Running Started: Wed, 29 May 2019 09:56:14 +0800 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-jr9rz (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: default-token-jr9rz: Type: Secret (a volume populated by a Secret) SecretName: default-token-jr9rz Optional: false QoS Class: BestEffort Node-Selectors: serverType=app-server Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 18m default-scheduler Successfully assigned default/pod-normal-demo to node2 Normal Pulled 18m kubelet, node2 Container image "ikubernetes/myapp:v1" already present on machine Normal Created 18m kubelet, node2 Created container myapp Normal Started 18m kubelet, node2 Started container myapp Normal Pulling 18m kubelet, node2 Pulling image "busybox:latest" Normal Pulled 18m kubelet, node2 Successfully pulled image "busybox:latest" Normal Created 18m kubelet, node2 Created container busybox-demo Normal Started 18m kubelet, node2 Started container busybox-demo
其中紅色部分就是此次咱們特別定義的一些規則。
【2】存活性檢測資源清單:
apiVersion: v1 kind: Pod metadata: name: liveness-pod namespace: default labels: app: erp tier: frontend release: stable annotations: ezops.cn/create-by: "Dylan" spec: containers: - name: myapp image: ikubernetes/myapp:v1 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 - name: https containerPort: 443 livenessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 10 periodSeconds: 3 restartPolicy: Always
咱們這裏有兩個知識點:
1. ports 裏面定義的 name 咱們在後面是能夠引用的,如 httpGet 的 port 咱們就直接些上面定義的 http。
2. livenessProbe 的應用,再配合 restartPolicy 完成程序自檢和維護。
若是用 exec 命令樣式,能夠用來檢測文件是否存在,如:
livenessProbe: exec: command: ["/bin/test" "-e /tmp/1.txt"]
另外,就緒性檢測和存活性檢測相似。
【3】生命週期 poststart:
apiVersion: v1 kind: Pod metadata: name: poststart-demo namespace: default labels: app: erp annotations: ezops.cn/create-by: "Dylan" spec: containers: - name: httpd-server image: busybox:latest imagePullPolicy: IfNotPresent lifecycle: postStart: exec: command: ["mkdir", "-p"," /data/web/html"] command: ["/bin/sh","-c","sleep 3600"]
小結
本章節初步使用了資源清單,這些關鍵不要求死記硬背,可是必定得知道個大概,基礎得框架咱們得記住。至於其餘詳細得則能夠經過 explain 查詢。
另外咱們以前提了自主式 Pod,咱們這裏創建的都是自主式 Pod,沒有上級管理,由於着刪除了這個 Pod 不會自動重建。