部門產品線本身是做DEVOPS平臺,最近部署架構也在往K8S上靠了,不得不學一下K8S。自己搭建了K8S叢集與harbor倉庫來學習。
Kubernetes: 用來編排(管理)容器的,但是kubernetes不直接部署容器,而是通過部署一個pod服務來間接管理容器,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
標籤定義:標籤用於區分物件(比如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服務被當前的副本控制器控制?
答案: 通過標籤確定哪些服務屬於誰控制;
Volume是kubernetes抽象出來的資料儲存資源物件;和docker的volume沒有關係,volume資料卷會把儲存媒介(磁碟,網路檔案系統)中資料掛載到pod服務內容的容器中,volume是k8s管理的資料卷;
小結:
1、volume資料卷本身並不儲存資料,只是把資料給掛載到pod服務內部的容器中去,volume僅僅是k8s管理的資源物件
2、pod內部服務容器宕機了,volume資料卷不會丟失。
3、pod服務宕機,消失了。Volume資料卷也會消失,且資料全部丟失。
副本控制器資源物件名稱: 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資源物件,實現服務捲動更新,擴容縮容。
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
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
參考:https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/