Kubernetes其他運(yùn)維經(jīng)驗(yàn)

IT那活兒發(fā)布于2023-01-11 13:19 / 1885人閱讀

Kubernetes其他運(yùn)維經(jīng)驗(yàn)

點(diǎn)擊上方“IT那活兒”公眾號(hào)，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了！！！

PART1

Kubernetes核心技術(shù)Pod

1.1 Pod概述

Pod 是 k8s 系統(tǒng)中可以創(chuàng)建和管理的最小單元，是資源對(duì)象模型中由用戶創(chuàng)建或部署的最小資源對(duì)象模型，也是在 k8s 上運(yùn)行容器化應(yīng)用的資源對(duì)象，其他的資源對(duì)象都是用來支撐或者擴(kuò)展 Pod 對(duì)象功能的，比如控制器對(duì)象是用來管控 Pod 對(duì)象的，Service 或者Ingress 資源對(duì)象是用來暴露 Pod 引用對(duì)象的，PersistentVolume 資源對(duì)象是用來為 Pod提供存儲(chǔ)等等，k8s 不會(huì)直接處理容器，而是 Pod，Pod 是由一個(gè)或多個(gè) container 組成Pod 是 Kubernetes 的最重要概念，每一個(gè) Pod 都有一個(gè)特殊的被稱為”根容器“的 Pause容器。

Pause 容器對(duì)應(yīng)的鏡像屬于 Kubernetes 平臺(tái)的一部分，除了 Pause 容器，每個(gè) Pod還包含一個(gè)或多個(gè)緊密相關(guān)的用戶業(yè)務(wù)容器。

1）Pod vs 應(yīng)用

每個(gè) Pod 都是應(yīng)用的一個(gè)實(shí)例，有專用的 IP。

2）Pod vs 容器

一個(gè) Pod 可以有多個(gè)容器，彼此間共享網(wǎng)絡(luò)和存儲(chǔ)資源，每個(gè) Pod 中有一個(gè) Pause 容器保存所有的容器狀態(tài)，通過管理 pause 容器，達(dá)到管理 pod 中所有容器的效果。

3）Pod vs 節(jié)點(diǎn)

同一個(gè) Pod 中的容器總會(huì)被調(diào)度到相同 Node 節(jié)點(diǎn)，不同節(jié)點(diǎn)間 Pod 的通信基于虛擬二層網(wǎng)絡(luò)技術(shù)實(shí)現(xiàn)。

4）Pod vs Pod

普通的 Pod 和靜態(tài) Pod。

1.2 Pod 特性

1）資源共享

一個(gè) Pod 里的多個(gè)容器可以共享存儲(chǔ)和網(wǎng)絡(luò)，可以看作一個(gè)邏輯的主機(jī)。共享的如namespace,cgroups 或者其他的隔離資源。

多個(gè)容器共享同一 network namespace，由此在一個(gè) Pod 里的多個(gè)容器共享 Pod 的 IP和端口 namespace，所以一個(gè) Pod 內(nèi)的多個(gè)容器之間可以通過 localhost 來進(jìn)行通信,所需要注意的是不同容器要注意不要有端口沖突即可。不同的 Pod 有不同的 IP,不同 Pod 內(nèi)的多個(gè)容器之前通信，不可以使用 IPC（如果沒有特殊指定的話）通信，通常情況下使用 Pod的 IP 進(jìn)行通信。一個(gè) Pod 里的多個(gè)容器可以共享存儲(chǔ)卷，這個(gè)存儲(chǔ)卷會(huì)被定義為 Pod 的一部分，并且可以掛載到該 Pod 里的所有容器的文件系統(tǒng)上。

2）生命周期短暫

Pod 屬于生命周期比較短暫的組件，比如，當(dāng) Pod 所在節(jié)點(diǎn)發(fā)生故障，那么該節(jié)點(diǎn)上的 Pod會(huì)被調(diào)度到其他節(jié)點(diǎn)，但需要注意的是，被重新調(diào)度的 Pod 是一個(gè)全新的 Pod,跟之前的Pod 沒有半毛錢關(guān)系。

3）平坦的網(wǎng)絡(luò)

K8s 集群中的所有 Pod 都在同一個(gè)共享網(wǎng)絡(luò)地址空間中，也就是說每個(gè) Pod 都可以通過其他Pod的IP地址來實(shí)現(xiàn)訪問。

1.3 Pod 定義

下面是 yaml 文件定義的 Pod 的完整內(nèi)容：

apiVersion: v1
kind: Pod
metadata:
//元數(shù)據(jù)
name: string
namespace: string
labels:
-name: string
annotations:
-name: string
spec:
containers:
//pod 中的容器列表，可以有多個(gè)容器
- name: string
//容器的名稱
image: string //容器中的鏡像
imagesPullPolicy: [Always|Never|IfNotPresent]//獲取鏡像的策略，默認(rèn)值為Always，每次都嘗試重新下載鏡像
command: [string]
//容器的啟動(dòng)命令列表（不配置的話使用鏡像內(nèi)部的命令） args:
[string]
//啟動(dòng)參數(shù)列表
workingDir: string
//容器的工作目錄 volumeMounts:
//掛載到到容器內(nèi)部的存儲(chǔ)卷設(shè)置
-name: string
mountPath: string
//存儲(chǔ)卷在容器內(nèi)部 Mount 的絕對(duì)路徑 readOnly: boolean
//
默認(rèn)值為讀寫
ports: //容器需要暴露的端口號(hào)列表
-name: string
containerPort: int //容器要暴露的端口
hostPort: int //容器所在主機(jī)監(jiān)聽的端口（容器暴露端口映射到宿主機(jī)的端口，設(shè)置hostPort 時(shí)同一臺(tái)宿主機(jī)將不能再啟動(dòng)該容器的第 2 份副本）
protocol: string
//TCP 和 UDP，默認(rèn)值為 TCP env:
//容器運(yùn)行前要設(shè)置的環(huán)境列表
-name: string value: string
resources:
limits:
//資源限制，容器的最大可用資源數(shù)量 cpu: Srting
memory: string
requeste:
//資源限制，容器啟動(dòng)的初始可用資源數(shù)量 cpu: string
memory: string
livenessProbe:
//pod 內(nèi)容器健康檢查的設(shè)置 exec:
command: [string] //exec 方式需要指定的命令或腳本 httpGet:
//通過 httpget 檢查健康
path: string port: number host: string scheme: Srtring httpHeaders:
- name: Stirng value: string
tcpSocket:
//通過 tcpSocket 檢查健康
port: number initialDelaySeconds: 0//首次檢查時(shí)間 timeoutSeconds: 0
//檢查超時(shí)時(shí)間
periodSeconds: 0
//檢查間隔時(shí)間
successThreshold: 0
failureThreshold: 0 securityContext:
//安全配置
privileged: falae
restartPolicy: [Always|Never|OnFailure]//重啟策略，默認(rèn)值為 Always
nodeSelector: object //節(jié)點(diǎn)選擇，表示將該 Pod 調(diào)度到包含這些 label 的 Node 上，以key:value 格式指定
imagePullSecrets:
-name: string
hostNetwork: false
//是否使用主機(jī)網(wǎng)絡(luò)模式，棄用 Docker 網(wǎng)橋，默認(rèn)否
volumes: //在該 pod 上定義共享存儲(chǔ)卷列表
-name: string emptyDir: {} hostPath:
path: string secret:
secretName: string item:
-key: string path: string
configMap: name: string items:
-key: string
path: string

1.4 Pod 的基本使用方法

在 kubernetes 中對(duì)運(yùn)行容器的要求為：容器的主程序需要一直在前臺(tái)運(yùn)行，而不是后臺(tái)運(yùn)行。應(yīng)用需要改造成前臺(tái)運(yùn)行的方式。如果我們創(chuàng)建的 Docker 鏡像的啟動(dòng)命令是后臺(tái)執(zhí)行程序，則在 kubelet 創(chuàng)建包含這個(gè)容器的 pod 之后運(yùn)行完該命令，即認(rèn)為 Pod 已經(jīng)結(jié)束，將立刻銷毀該 Pod。如果為該 Pod 定義了 RC，則創(chuàng)建、銷毀會(huì)陷入一個(gè)無限循環(huán)的過程中。

Pod 可以由 1 個(gè)或多個(gè)容器組合而成。

1）一個(gè)容器組成的 Pod 的 yaml 示例

# 一個(gè)容器組成的 Pod：

apiVersion: v1 kind: Pod metadata:
name: mytomcat labels:
name: mytomcat spec:
containers:
- name: mytomcat image: tomcat ports:
- containerPort: 8000

2）多個(gè)容器組成的 Pod 的 yaml 示例

#兩個(gè)緊密耦合的容器：

apiVersion: v1 kind: Pod metadata:
name: myweb labels:
name: tomcat-redis
spec:
containers:
-name: tomcat image: tomcat ports:
-containerPort: 8080
-name: redis image: redis ports:
-containerPort: 6379

3）創(chuàng)建

4）查看

5）刪除

1.5 Pod 的分類

Pod 有兩種類型：

1）普通 Pod

普通 Pod 一旦被創(chuàng)建，就會(huì)被放入到 etcd 中存儲(chǔ)，隨后會(huì)被 Kubernetes Master 調(diào)度到某個(gè)具體的 Node 上并進(jìn)行綁定，隨后該 Pod 對(duì)應(yīng)的 Node 上的 kubelet 進(jìn)程實(shí)例化成一組相關(guān)的 Docker 容器并啟動(dòng)起來。在默認(rèn)情況下，當(dāng) Pod 里某個(gè)容器停止時(shí)，Kubernetes會(huì)自動(dòng)檢測(cè)到這個(gè)問題并且重新啟動(dòng)這個(gè) Pod 里某所有容器，如果 Pod 所在的 Node 宕機(jī)，則會(huì)將這個(gè) Node 上的所有 Pod 重新調(diào)度到其它節(jié)點(diǎn)上。

2）靜態(tài) Pod

靜態(tài) Pod 是由 kubelet 進(jìn)行管理的僅存在于特定 Node 上的 Pod,它們不能通過 API Server進(jìn)行管理，無法與 ReplicationController、Deployment 或 DaemonSet 進(jìn)行關(guān)聯(lián)，并且kubelet 也無法對(duì)它們進(jìn)行健康檢查。

1.6 Pod 生命周期和重啟策略

1）Pod 的狀態(tài)

2）Pod 重啟策略

Pod 的重啟策略包括 Always、OnFailure 和 Never，默認(rèn)值是 Always

3）常見狀態(tài)轉(zhuǎn)換

PART2

Kubernetes部署性能監(jiān)控平臺(tái)

2.1 概述

開源軟件 cAdvisor（Container Advisor）用于監(jiān)控所在節(jié)點(diǎn)的容器運(yùn)行狀態(tài)，當(dāng)前已經(jīng)被默認(rèn)集成到 kubelet 組件內(nèi)，默認(rèn)使用 tcp 4194 端口。

在大規(guī)模容器集群，一般使用Heapster+Influxdb+Grafana 平臺(tái)實(shí)現(xiàn)集群性能數(shù)據(jù)的采集，存儲(chǔ)與展示。

2.2 環(huán)境準(zhǔn)備

2.2.1 基礎(chǔ)環(huán)境

Kubernetes + heapster + Influxdb + grafana

2.2.2 原理

Heapster：集群中各 node 節(jié)點(diǎn)的 cAdvisor 的數(shù)據(jù)采集匯聚系統(tǒng)，通過調(diào)用 node 上 kubelet 的 api，再通過 kubelet 調(diào)用 cAdvisor 的 api 來采集所在節(jié)點(diǎn)上所有容器的性能數(shù)據(jù)。Heapster 對(duì)性能數(shù)據(jù)進(jìn)行聚合，并將結(jié)果保存到后端存儲(chǔ)系統(tǒng)，heapster 支持多種后端存儲(chǔ)系統(tǒng)，如 memory，Influxdb 等。
Influxdb：分布式時(shí)序數(shù)據(jù)庫（每條記錄有帶有時(shí)間戳屬性），主要用于實(shí)時(shí)數(shù)據(jù)采集，時(shí)間跟蹤記錄，存儲(chǔ)時(shí)間圖表，原始數(shù)據(jù)等。Influxdb 提供 rest api 用于數(shù)據(jù)的存儲(chǔ)與查詢。
Grafana：通過 dashboard 將 Influxdb 中的時(shí)序數(shù)據(jù)展現(xiàn)成圖表或曲線等形式，便于查看集群運(yùn)行狀態(tài)。

Heapster，Influxdb，Grafana 均以 Pod 的形式啟動(dòng)與運(yùn)行。

2.2.3 部署 Kubernetes 集群性能監(jiān)控

2.2.3.1 準(zhǔn)備 images

kubernetes 部署服務(wù)時(shí)，為避免部署時(shí)發(fā)生 pull 鏡像超時(shí)的問題，建議提前將相關(guān)鏡像pull 到相關(guān)所有節(jié)點(diǎn)（以下以 kubenode1 為例），或搭建本地鏡像系統(tǒng)。需要從 gcr.io pull 的鏡像，已利用 Docker Hub 的"CreateAuto-Build GitHub"功能（Docker Hub 利用 GitHub 上的 Dockerfile 文件 build 鏡像），在個(gè)人的 Docker Hubbuild 成功，可直接 pull 到本地使用。

2.2.3.2 下載 yaml 范本

2.2.3.3 heapster-rbac.yaml

2.2.3.4 heapster.yaml

hepster.yaml 由 3 個(gè)模塊組成：ServiceAccout，Deployment，Service。

1）ServiceAccount

默認(rèn)不需要修改 ServiceAccount 部分，設(shè)置 ServiceAccount 資源，獲取 rbac 中定義的權(quán)限。

2）Deployment

3）Service

默認(rèn)不需要修改 Service 部分。

4）Service

默認(rèn)不需要修改 Service 部分，注意 Service 名字的對(duì)應(yīng)即可。

2.2.3.5 grafana.yaml

grafana.yaml 由 2 個(gè)模塊組成：Deployment，Service。

1）Deployment

# 修改處：第 16 行，變更鏡像名；

# 修改處：第 43 行，取消注釋；“GF_SERVER_ROOT_URL”的 value 值設(shè)定后，只能通過API Server proxy 訪問 grafana；

# 修改處：第 44 行，注釋本行；

# INFLUXDB_HOST 的 value 值設(shè)定為 influxdb 的 service 名，依賴于集群 dns，或者直接使用 ClusterIP。

[root@kubenode1 influxdb]# sed -i s|gcr.io/google_containers/heapster-grafana-
amd64:v4.4.3|netonline/heapster-grafana-amd64:v4.4.3|g grafana.yaml
[root@kubenode1 influxdb]# sed -i 43s|# value:|value:|g grafana.yaml
[root@kubenode1 influxdb]# sed -i 44s|value:|# value:|g grafana.yaml
[root@kubenode1 influxdb]# cat grafana.yaml
……
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: monitoring-grafananamespace: kube-system
spec:
replicas: 1
template:
metadata:
labels:
task: monitoring
k8s-app: grafana
spec:
containers:
- name: grafana
image: netonline/heapster-grafana-amd64:v4.4.3
ports:
- containerPort: 3000
protocol: TCP
volumeMounts:
- mountPath: /etc/ssl/certs
name: ca-certificates
readOnly: true
- mountPath: /var
name: grafana-storage
env:
- name: INFLUXDB_HOST
value: monitoring-influxdb
- name: GF_SERVER_HTTP_PORT
value: "3000"
# The following env variables are required to make Grafana accessible
via
# the kubernetes api-server proxy. On production clusters, we
recommend
# removing these env variables, setup auth for grafana, and expose
the grafana
# service using a LoadBalancer or a public IP.
- name: GF_AUTH_BASIC_ENABLED
value: "false"
- name: GF_AUTH_ANONYMOUS_ENABLED
value: "true"
- name: GF_AUTH_ANONYMOUS_ORG_ROLE
value: Admin
- name: GF_SERVER_ROOT_URL
# If youre only using the API Server proxy, set this value instead:
value: /api/v1/namespaces/kube-system/services/monitoring-
grafana/proxy
# value: /
volumes:
- name: ca-certificates
hostPath:
path: /etc/ssl/certs
- name: grafana-storage
emptyDir: {