kubernetes之常用核心資源對象
- 2022 年 6 月 23 日
- 筆記
- Kubernetes
部門產品線本身是做DEVOPS平台,最近部署架構也在往K8S上靠了,不得不學一下K8S。自己搭建了K8S集群與harbor倉庫來學習。
1、kubernetes之常用核心資源對象
1.1、K8s服務部署
Kubernetes: 用來編排(管理)容器的,但是kubernetes不直接部署容器,而是通過部署一個pod服務來間接管理容器,pod內部封裝的是一個容器。
1.2、POD
POD是kubernetes集群的最小任務調度單元。
Kubernetes里的所有資源對象都可以採用YAML或者JSON格式的文件來定義描述。比如下面的POD定義:
apiVersion: v1
kind: Pod
metadata:
name: mytomcat
labels:
name: mytomcat
spec:
containers:
- name: mytomcat
image: harbor.hyz.com/library/mytomcat:v1
prots:
- containerPort: 8080
1.3、標籤label
標籤定義:標籤用於區分對象(比如Pod、Service),鍵/值對存在;每個資源對象可以有多個標籤,通過標籤關聯對象。
Kubernetes中任意API對象都是通過Label進行標識,Label的實質是一系列的Key/Value鍵值對,其中key於value由用戶自己指定。
Label可以附加在各種資源對象上,如Node、Pod、Service、RC等,一個資源對象可以定義任意數量的Label,同一個Label也可以被添加到任意數量的資源對象上去。
Label是Replication Controller和Service運行的基礎,二者通過Label來進行關聯Node上運行的Pod。
我們可以通過給指定的資源對象捆綁一個或者多個不同的Label來實現多維度的資源分組管理功能,以便於靈活、方便的進行資源分配、調度、配置等管理工作。
一些常用的Label如下:
版本標籤:”release”:”stable”,”release”:”canary”……
環境標籤:”environment”:”dev”,”environment”:”qa”,”environment”:”production”
架構標籤:”tier”:”frontend”,”tier”:”backend”,”tier”:”middleware”
分區標籤:”partition”:”customerA”,”partition”:”customerB”
品質管控標籤:”track”:”daily”,”track”:”weekly”
問題: 在伺服器部署的容器雲環境中,有成千上萬個POD服務,那麼副本控制器是如何知道哪些pod服務被當前的副本控制器控制?
答案: 通過標籤確定哪些服務屬於誰控制;
1.4、volume
Volume是kubernetes抽象出來的數據存儲資源對象;和docker的volume沒有關係,volume數據卷會把存儲介質(磁碟,網路文件系統)中數據掛載到pod服務內容的容器中,volume是k8s管理的數據卷;
小結:
1、volume數據卷本身並不存儲數據,只是把數據給掛載到pod服務內部的容器中去,volume僅僅是k8s管理的資源對象
2、pod內部服務容器宕機了,volume數據卷不會丟失。
3、pod服務宕機,消失了。Volume數據卷也會消失,且數據全部丟失。
1.5、副本控制器
副本控制器資源對象名稱: ReplicationController(淘汰,只支援單個標籤選擇器), ReplicaSet(目前使用這款副本控制器,支援符合標籤選擇器)
作用:用來保證服務副本數量與預期所設定的數量保持一致,也就是說服務永遠保證服務處於高可用狀態。
場景:當服務上線部署後,一段時間後某一個服務(POD)宕機了,副本控制器立馬對服務進行重建,永遠保證服務數量等於之前所設定數量(例如: 規定服務集群服務數量=3,副本控制將會永遠保證服務數量為3);
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: tomcat-demo
image: harbor.hyz.com/library/mytomcat:v1
imagePullPolicy: IfNotPresent
env:
- name: GET_HOST_FROM
value: dns
ports:
- containerPort: 80
問題1: ReplicaSet副本控制器僅僅是控制POD副本數量(僅僅是一個副本控制器),不支援滾動更新,擴容縮容等;因此必須引入Deployment資源對象,實現服務滾動更新,擴容縮容。
1.6、Deployment
Deployment為Pod和ReplicaSet 提供了一個 聲明式定義方法,相當於RC/RS的升級版。其中一個最大升級功能是我們可以隨時知道當前pod「部署」的進度。
典型的應用場景:
(1)、定義Deployment 來創建 Pod 和 ReplicaSet
(2)、滾動升級和回滾應用
(3)、擴容和索容
(4)、暫停和繼續 Deployment
Deployment不僅僅可以滾動更新,而且可以進行回滾,如果發現升級到V2版本後,發現服務不可用,可以回滾到V1版本。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
1.7、DaemonSet
DaemonSet確保全部(或者一些 [ node打上污點(可以想像成一個標籤),pod如果不定義容忍這個污點,那麼pod就不會被調度器分配到這個node ])Node上運行一個Pod的副本。當有Node加入集群時,也會為他們新增一個Pod。當有Node從集群移除時,這些Pod也會被回收。刪除DaemonSet將會刪除他創建的所有Pod,使用DaemonSet 的一些典型用法:
(1)在每個Node上運行日誌收集Daemon,例如:fluentd、logstash.
(2)在每個Node上運行監控Daemon,例如:Prometheus Node Exporter
小結: DeamonSet控制器,讓每一個node節點都部署一個相同服務(副本),因此deamonSet通常被用來部署一些公共的服務。
這些公共服務,每一個節點都需要;
例如:
需求: 在服務集群網路中,收集每一個節點的日誌(每一個節點都需要部署一個收集日誌程式)
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-logstash
namespace: default
labels:
k8s: logstash
spec:
selector:
matchLabels:
name: daemonset-logstash
template:
metadata:
labels:
name: daemonset-logstash
spec:
tolerations:
# 這些容忍度設置是為了讓守護進程在控制平面節點上運行
# 如果你不希望控制平面節點運行 Pod,可以刪除它們
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
containers:
- name: logstash
image: logstash
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
參考://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/