Kubernetes筆記(3) - 資源管理基礎

Kubernetes系統將一切事物都抽象爲API資源，其遵循REST架構風格組織並管理這些資源及其對象，同時還支持經過標準的HTTP方法（POST、PUT、PATCH、DELETE和GET）對資源進行增、刪、改、查等管理操做。
Kubernetes的資源對象大致可分爲

• 工做負載（Workload）
• 服務發現和負載均衡（Discovery & LB）
• 配置和存儲（Config & Storage）
• 集羣（Cluster）
• 元數據（Metadata）

資源對象及API羣組

工做負載

Pod是工做負載型資源中的基礎資源，它負責運行容器，併爲其解決環境性的依賴。它被Pod控制器管理，但因爲應用程序有無狀態和有狀態的區分，它們對環境的依賴及工做特性有很大的不一樣，所以分屬兩種不一樣類型的Pod控制器來管理。
管理無狀態應用的控制器：

• ReplicationController
• ReplicaSet
• Deployment

ReplicationController和ReplicaSet的做用都是確保每一個Pod副本在任一時刻都符合目標數量。但ReplicationController是上一代的控制器，已基本廢棄。
Deployment用於管理無狀態的持久化應用，例如HTTP服務器；它用於爲Pod和ReplicaSet提供聲明式更新，是建構在ReplicaSet之上的更爲高級的控制器。

管理有狀態應用的控制器：

• StatefulSet

StatefulSet用於管理有狀態的持久化應用，如database服務程序；其與Deployment的不一樣之處在於StatefulSet會爲每一個Pod建立一個獨有的持久性標識符，並會確保各Pod之間的順序性。

另外還有兩個比較特別的Workload控制器：

• DaemonSet
• Job控制器

DaemonSet經常使用於運行集羣存儲守護進程——如glusterd和ceph，還有日誌收集進程——如fluentd和logstash，以及監控進程——如Prometheus的Node Exporter、collectd、Datadog agent和Ganglia的gmond等。‰

Job控制器用於管理運行完成後便可終止的應用，例如批處理做業任務。

服務發現和負載均衡

Kubernetes使用標準的資源對象來負責服務發現和負載均衡，包括：

• Service資源
• Endpoint資源
• Ingress資源

配置與存儲

Docker使用Volume來進行數據的持久化，K8S也爲此提供了
Volume資源，並且它基於標準的CSI（Container Storage Interface）接口，支持多種類型的存儲系統。

另外，Docker在啓動容器時須要注入環境變量，K8S也爲此提供了ConfigMap資源，它能夠環境變量或存儲卷的方式接入到Pod資源的容器中，而且可被多個同類的Pod共享引用。Secret資源則用於提供密碼等敏感配置信息。

集羣級資源

上述資源都屬於名稱空間級別，可由相應的項目管理員所管理。Kubernetes還存在一些集羣級別的資源，用於定義集羣自身配置信息，它們僅應該由集羣管理員進行操做。

• Namespace: 資源對象名稱的做用範圍，絕大多數對象都隸屬於某個名稱空間，默認屬於default.
• Node: Kubernetes集羣的工做節點，其標識符在當前集羣中必須是惟一的.
• Role: 名稱空間級別的由規則組成的權限集合，可被RoleBinding引用.
• ClusterRole: Cluster級別的由規則組成的權限集合，可被RoleBinding和ClusterRoleBinding引用.
• RoleBinding: 將Role中的許可權限綁定在一個或一組用戶之上，它隸屬於且僅能做用於一個名稱空間.
• ClusterRoleBinding: 將ClusterRole中定義的許可權限綁定在一個或一組用戶之上;它可以引用全局名稱空間中的ClusterRole，並能經過Subject添加相關信息.

元數據型資源

元數據型資源用於爲集羣內部的其餘資源配置其行爲或特性，如HorizontalPodAutoscaler資源可用於自動伸縮工做負載類型的資源對象的規模，Pod模板資源可用於爲pod資源的建立預製模板，而LimitRange則可爲名稱空間的資源設置其CPU和內存等系統級資源的數量限制等。

資源在API中的組織形式

除了kubectl，也可使用curl、postman等工具做爲HTTP客戶端直接經過API Server在集羣上操做資源對象，可是Kubernetes集羣默認僅支持HTTPS的訪問接口，它需進行一系列的認證檢查，因此首先須要在本地主機上爲API Server啓動一個代理網關

kubectl proxy --port=8080

而後就能夠發起請求了，好比獲取集羣的namespace list：

curl localhost:8080/api/v1/namespaces

與執行這樣的命令獲得的結果相同：

kubectl get namespaces -o json

全部的response都包含相同的一級字段：kind、apiVersion、metadata、spec、status。
其中kind、apiVersion分別表示對象所屬的資源類型和API的版本。

metadata字段

metadata字段用於描述對象的屬性信息，其內嵌多個字段用於定義資源的元數據，例如name和labels等。這些字段分爲必要字段和可選字段兩大類。好比名稱空間級別的資源的必選字段包括有

• namespace：指定當前對象隸屬的名稱空間，默認值爲default。‰
• name：設定當前對象的名稱，在其所屬的名稱空間的同一類型中必須惟一。‰
• uid：當前對象的惟一標識符，其惟一性僅發生在特定的時間段和名稱空間中

可選字段一般是指由Kubernetes系統自行維護和設置，或者存在默認值，或者自己容許留空。用戶經過配置清單建立資源時，一般僅須要給出必選字段，可選字段可按需指定，對於用戶未明肯定義的嵌套字段，則須要由一系列的finalizer組件自動予以填充。

spec和status字段

spec來描述所指望的對象應該具備的狀態，status字段則用來記錄對象的當前狀態。在定義資源配置清單時，spec是必須定義的字段，status字段則由Kubernetes負責填充或更新，用戶不能手動進行定義。

上述字段的子節點的內容隨資源的種類不一樣而有較大的區別，可使用kubectl explain來具體查看，好比

kubectl explain pods
kubectl explain pods.spec

資源對象管理

總體來講，K8S提供了兩類資源管理的方式：陳述式和聲明式
陳述式側重於告訴計算機如何執行操做，run、expose、delete和get等命令都屬於此類；
聲明式側重於構建程序邏輯而無須詳細描述其實現流程，用戶只須要設按期望的狀態，系統即能自行肯定須要執行的操做以確保達到用戶指望的狀態，全部的操做都經過apply命令來完成。

kubectl命令可以讀取.yaml .yml或.json爲格式的文件。-f選項能夠指定配置清單的路徑、URL或目錄，且可重複使用屢次。若是指定的目錄路徑存在子目錄中時，可以使用-R選項來遞歸獲取子目錄中的配置清單。

能夠爲每一個資源使用專用的配置清單，也能夠將多個相關的資源（例如，屬於同一個應用或微服務）組織在同一個配置清單中。不過，若是是YAML格式的配置清單，多個資源彼此之間要使用「---」符號做爲單獨的一行進行資源分割

管理namespace資源

namespace資源屬於集羣級別的資源，用於將集羣分隔爲多個隔離的邏輯分區以配置給不一樣的用戶、租戶、環境或項目使用，namespace下又包含了pod、service等資源。
Kubernetes的namespace資源與Linux系統的名稱空間是各自獨立的概念。前者僅用於限制資源對象名稱的做用域。
kubectl get namespaces命令可查看全部的namespaces資源，kube-system主要用於運行系統級資源，而default下則包含那些未指定名稱空間的資源。
kubectl describe namespaces <namespace>命令可查看指定namespace的詳細信息。
查看namespace級別的資源須要指定namespace名稱，好比

kubect get pods -n kube-system

聲明式建立namespace資源

使用apply命令基於如下配置清單建立namespace資源

3_namespace-example.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: dev
spec:
  finalizers:
  - kubernetes

~ kubectl apply -f 3_namespace-example.yaml 
namespace/dev created

建立namespace資源所需的屬性較少，簡單起見，kubectl爲其提供了一個封裝的專用陳述式命令kubectl create namespace <namespace>

刪除Namespace資源

刪除Namespace資源會級聯刪除其包含的全部其餘資源對象

kubectl delete namespace dev

也能夠爲其指定--force --grace-period 選項

管理pod資源

首先定義以下資源清單：
3_pod-example.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1

建立Pod資源
陳述式對象配置方式：

kubectl create -f 3_pod-example.yaml

聲明式對象配置方式：

kubectl apply -f 3_pod-example.yaml

查看pod狀態

kubectl get -f 3_pod-example.yaml
或
kubectl get pod pod-example

同時可使用-o yaml/json選項獲取詳細的資源清單。
describe命令可查看活動對象的詳細信息。

kubectl describe -f 3_pod-example.yaml 
或
kubectl describe pod pod-example

更新Pod資源
對於活動對象，並不是其每一個屬性值都支持修改，好比沒法修改Pod資源對象的metadata.name字段，除非刪除並重建它。對於那些支持修改的屬性，好比，容器的image字段，可將其完整的配置清單導出於配置文件中並更新相應的配置數據，然後使用replace命令基於陳述式對象配置的管理機制進行資源對象的更新。

~ kubectl get pods pod-example -o yaml > pod-example-update.yaml
將image修改成ikubernetes/myapp:v2後執行：
~ kubectl replace -f pod-example-update.yaml
操做成功會提示：
pod/pod-example replaced

上述使用了陳述式對象配置方式更新活動對象的配置，replace命令要重構整個資源對象，因此它必須基於完整格式的配置信息才能進行活動對象的徹底替換。若要基於此前的配置文件進行替換，就必須使用--force選項刪除此前的活動對象，然後再進行新建操做。

~ kubectl replace -f 3_pod-example.yaml --force
pod "pod-example" deleted
pod/pod-example replaced

後面介紹會介紹更推薦的聲明式管理方式。
刪除Pod資源
陳述式命令方式：

kubectl delete pod pod-example

陳述式對象配置管理方式：

kubectl delete -f 3_pod-example.yaml

陳述式對象配置 VS 聲明式

陳述式命令、陳述式對象配置、聲明式三種管理K8S資源的方式中，後兩種都是使用配置清單，但它們區別較大：
陳述式對象配置管理機制中，同時指定的多個資源必須進行同一種操做，並且其replace命令是經過徹底替換現有的活動對象來進行資源的更新操做，對於生產環境來講，這並不是理想的選擇。
聲明式對象配置操做在管理資源對象時將配置信息保存於目標對象的註解中，並經過比較活動對象的當前配置、前一次管理操做時保存於註解中的配置，以及當前命令提供的配置生成更新補丁從而完成活動對象的補丁式更新操做。
好比要更新pod鏡像，只須要修改最初的3_pod-example.yaml，而後apply，系統就會進行補丁式更新操做。
而資源對象的刪除操做依然可使用apply命令，但要同時使用--prune選項，命令的格式爲「kubectl apply -f --prune -l 」。但這個命令要慎用，由於它將基於標籤選擇器過濾出全部符合條件的對象，並檢查由-f指定的目錄中是否存在某配置文件已經定義了相應的資源對象，那些不存在相應定義的資源對象將被刪除。所以，刪除資源對象的操做依然建議使用陳述式對象配置方式。

學習資料

《Kubernetes實戰進階》 馬永亮著