Kubernetes其他運維經驗

IT那活兒發布于2023-01-11 13:19 / 1882人閱讀

Kubernetes其他運維經驗

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！

PART1

Kubernetes核心技術Pod

1.1 Pod概述

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

Pause 容器對應的鏡像屬于 Kubernetes 平臺的一部分，除了 Pause 容器，每個 Pod還包含一個或多個緊密相關的用戶業務容器。

1）Pod vs 應用

每個 Pod 都是應用的一個實例，有專用的 IP。

2）Pod vs 容器

一個 Pod 可以有多個容器，彼此間共享網絡和存儲資源，每個 Pod 中有一個 Pause 容器保存所有的容器狀態，通過管理 pause 容器，達到管理 pod 中所有容器的效果。

3）Pod vs 節點

同一個 Pod 中的容器總會被調度到相同 Node 節點，不同節點間 Pod 的通信基于虛擬二層網絡技術實現。

4）Pod vs Pod

普通的 Pod 和靜態 Pod。

1.2 Pod 特性

1）資源共享

一個 Pod 里的多個容器可以共享存儲和網絡，可以看作一個邏輯的主機。共享的如namespace,cgroups 或者其他的隔離資源。

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

2）生命周期短暫

Pod 屬于生命周期比較短暫的組件，比如，當 Pod 所在節點發生故障，那么該節點上的 Pod會被調度到其他節點，但需要注意的是，被重新調度的 Pod 是一個全新的 Pod,跟之前的Pod 沒有半毛錢關系。

3）平坦的網絡

K8s 集群中的所有 Pod 都在同一個共享網絡地址空間中，也就是說每個 Pod 都可以通過其他Pod的IP地址來實現訪問。

1.3 Pod 定義

下面是 yaml 文件定義的 Pod 的完整內容：

apiVersion: v1
kind: Pod
metadata:
//元數據
name: string
namespace: string
labels:
-name: string
annotations:
-name: string
spec:
containers:
//pod 中的容器列表，可以有多個容器
- name: string
//容器的名稱
image: string //容器中的鏡像
imagesPullPolicy: [Always|Never|IfNotPresent]//獲取鏡像的策略，默認值為Always，每次都嘗試重新下載鏡像
command: [string]
//容器的啟動命令列表（不配置的話使用鏡像內部的命令） args:
[string]
//啟動參數列表
workingDir: string
//容器的工作目錄 volumeMounts:
//掛載到到容器內部的存儲卷設置
-name: string
mountPath: string
//存儲卷在容器內部 Mount 的絕對路徑 readOnly: boolean
//
默認值為讀寫
ports: //容器需要暴露的端口號列表
-name: string
containerPort: int //容器要暴露的端口
hostPort: int //容器所在主機監聽的端口（容器暴露端口映射到宿主機的端口，設置hostPort 時同一臺宿主機將不能再啟動該容器的第 2 份副本）
protocol: string
//TCP 和 UDP，默認值為 TCP env:
//容器運行前要設置的環境列表
-name: string value: string
resources:
limits:
//資源限制，容器的最大可用資源數量 cpu: Srting
memory: string
requeste:
//資源限制，容器啟動的初始可用資源數量 cpu: string
memory: string
livenessProbe:
//pod 內容器健康檢查的設置 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//首次檢查時間 timeoutSeconds: 0
//檢查超時時間
periodSeconds: 0
//檢查間隔時間
successThreshold: 0
failureThreshold: 0 securityContext:
//安全配置
privileged: falae
restartPolicy: [Always|Never|OnFailure]//重啟策略，默認值為 Always
nodeSelector: object //節點選擇，表示將該 Pod 調度到包含這些 label 的 Node 上，以key:value 格式指定
imagePullSecrets:
-name: string
hostNetwork: false
//是否使用主機網絡模式，棄用 Docker 網橋，默認否
volumes: //在該 pod 上定義共享存儲卷列表
-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 中對運行容器的要求為：容器的主程序需要一直在前臺運行，而不是后臺運行。應用需要改造成前臺運行的方式。如果我們創建的 Docker 鏡像的啟動命令是后臺執行程序，則在 kubelet 創建包含這個容器的 pod 之后運行完該命令，即認為 Pod 已經結束，將立刻銷毀該 Pod。如果為該 Pod 定義了 RC，則創建、銷毀會陷入一個無限循環的過程中。

Pod 可以由 1 個或多個容器組合而成。

1）一個容器組成的 Pod 的 yaml 示例

# 一個容器組成的 Pod：

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

2）多個容器組成的 Pod 的 yaml 示例

#兩個緊密耦合的容器：

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）創建

4）查看

5）刪除

1.5 Pod 的分類

Pod 有兩種類型：

1）普通 Pod

普通 Pod 一旦被創建，就會被放入到 etcd 中存儲，隨后會被 Kubernetes Master 調度到某個具體的 Node 上并進行綁定，隨后該 Pod 對應的 Node 上的 kubelet 進程實例化成一組相關的 Docker 容器并啟動起來。在默認情況下，當 Pod 里某個容器停止時，Kubernetes會自動檢測到這個問題并且重新啟動這個 Pod 里某所有容器，如果 Pod 所在的 Node 宕機，則會將這個 Node 上的所有 Pod 重新調度到其它節點上。

2）靜態 Pod

靜態 Pod 是由 kubelet 進行管理的僅存在于特定 Node 上的 Pod,它們不能通過 API Server進行管理，無法與 ReplicationController、Deployment 或 DaemonSet 進行關聯，并且kubelet 也無法對它們進行健康檢查。

1.6 Pod 生命周期和重啟策略

1）Pod 的狀態

2）Pod 重啟策略

Pod 的重啟策略包括 Always、OnFailure 和 Never，默認值是 Always

3）常見狀態轉換

PART2

Kubernetes部署性能監控平臺

2.1 概述

開源軟件 cAdvisor（Container Advisor）用于監控所在節點的容器運行狀態，當前已經被默認集成到 kubelet 組件內，默認使用 tcp 4194 端口。

在大規模容器集群，一般使用Heapster+Influxdb+Grafana 平臺實現集群性能數據的采集，存儲與展示。

2.2 環境準備

2.2.1 基礎環境

Kubernetes + heapster + Influxdb + grafana

2.2.2 原理

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

Heapster，Influxdb，Grafana 均以 Pod 的形式啟動與運行。

2.2.3 部署 Kubernetes 集群性能監控

2.2.3.1 準備 images

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

2.2.3.2 下載 yaml 范本

2.2.3.3 heapster-rbac.yaml

2.2.3.4 heapster.yaml

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

1）ServiceAccount

默認不需要修改 ServiceAccount 部分，設置 ServiceAccount 資源，獲取 rbac 中定義的權限。

2）Deployment

3）Service

默認不需要修改 Service 部分。

4）Service

默認不需要修改 Service 部分，注意 Service 名字的對應即可。

2.2.3.5 grafana.yaml

grafana.yaml 由 2 個模塊組成：Deployment，Service。

1）Deployment

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

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

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

# INFLUXDB_HOST 的 value 值設定為 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: {

2.2.4 驗證

2.2.4.1 啟動監控相關服務

2.2.4.2 查看相關服務

2.2.4.3 訪問 dashboard

瀏覽器訪問訪問 dashboard：https://ip:6443/api/v1/namespaces/kube-

system/services/https:kubernetes-dashboard:/proxy

注意：Dasheboard 沒有配置 hepster 監控平臺時，不能展示 node，Pod 資源的 CPU 與內存等 metric 圖形Node 資源 CPU/內存 metric 圖形：

Pod 資源 CPU/內存 metric 圖形：

2.2.4.4 訪問 grafana

END

本文作者：熊靜波

本文來源：IT那活兒（上海新炬王翦團隊）

GPU云服務器云服務器運維經驗運維管理經驗運維項目經驗 it運維經驗

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129488.html

《Kubernetes從上手到實踐》正式上線

摘要：有很大一部分的休息時間都用來完成了我的第一本掘金小冊從上手到實踐小冊已經正式上線，特意送上各位小伙伴一份禮物，小冊折優惠。時間飛逝，轉眼今年又要結束了。感謝還在關注的小伙伴，今年確實更新很少，能不取關的都是真愛... 今年發生了很多事情，留著過幾天年終總結的時候再說。有很大一部分的休息時間都用來完成了我的第一本掘金小冊《Kubernetes 從上手到實踐》 showImg(http...

CarterLi 2019-06-28 16:56 評論0 收藏0
《Kubernetes從上手到實踐》正式上線

摘要：有很大一部分的休息時間都用來完成了我的第一本掘金小冊從上手到實踐小冊已經正式上線，特意送上各位小伙伴一份禮物，小冊折優惠。時間飛逝，轉眼今年又要結束了。感謝還在關注的小伙伴，今年確實更新很少，能不取關的都是真愛... 今年發生了很多事情，留著過幾天年終總結的時候再說。有很大一部分的休息時間都用來完成了我的第一本掘金小冊《Kubernetes 從上手到實踐》 showImg(http...

andot 2019-07-01 16:58 評論0 收藏0
《Kubernetes從上手到實踐》正式上線

摘要：有很大一部分的休息時間都用來完成了我的第一本掘金小冊從上手到實踐小冊已經正式上線，特意送上各位小伙伴一份禮物，小冊折優惠。時間飛逝，轉眼今年又要結束了。感謝還在關注的小伙伴，今年確實更新很少，能不取關的都是真愛... 今年發生了很多事情，留著過幾天年終總結的時候再說。有很大一部分的休息時間都用來完成了我的第一本掘金小冊《Kubernetes 從上手到實踐》 showImg(http...

leon 2019-07-30 18:41 評論0 收藏0
才云科技CTO鄧德源：不可不知的谷歌集群管理經驗

摘要：曾為美國谷歌集群管理組核心成員，主要參與開發集群管理系統。保證系統升級軟硬件錯誤等均能及時被發現并處理，谷歌集群能小時不間斷工作。關于集群管理經驗，首先一定要專注于持久的運維自動化工具開發。本文僅用于學習和交流目的，不得用于商業目的。非商業轉載請注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/art... 訪談嘉賓：鄧德源，才云科技CT...

callmewhy 2019-07-01 16:30 評論0 收藏0
才云科技CTO鄧德源：不可不知的谷歌集群管理經驗

摘要：曾為美國谷歌集群管理組核心成員，主要參與開發集群管理系統。保證系統升級軟硬件錯誤等均能及時被發現并處理，谷歌集群能小時不間斷工作。關于集群管理經驗，首先一定要專注于持久的運維自動化工具開發。本文僅用于學習和交流目的，不得用于商業目的。非商業轉載請注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/art... 訪談嘉賓：鄧德源，才云科技CT...

Pines_Cheng 2019-06-28 15:36 評論0 收藏0
TOP100summit分享實錄 | JFrog高欣：Kubernetes is hard!JFro

摘要：本文內容節選自由主辦的第七屆，架構師高欣分享的的實踐實錄。當然，在部署完成后，我們要做一個監測以便掌握它的運行狀況。規劃配置運行環境在正式部署前，還要考慮如何規劃并配置好運行環境。在使用部署時，可以利用這些命令做驗證，檢驗部署是否正常。 showImg(https://segmentfault.com/img/bVblRHj?w=2880&h=1920); 本文內容節選自由msup主辦...

鄒強 2019-07-01 16:58 評論0 收藏0