antony@notes:~/kubernetes$ cat "Cluster-Architecture-Installation-and-Configuration.md"

Cluster Architecture, Installation,and Configuration

2022-08-24· kubernetes ·Certified Kubernetes Administrator (CKA) Study Guide

Cluster Architecture, Installation,and Configuration

:::warning

:::spoiler 目錄

[TOC]

:::

前言

根據章節名稱，課程的第一部分是指您期望 Kubernetes 管理員完成的典型任務。這些任務包括了解 Kubernetes 集群的架構組件、從頭開始設置集群以及維護集群。

有趣的是，本節還涵蓋了集群的安全方面，更具體地說是基於角色的訪問控制 (RBAC)。您應該了解如何將操作權限映射到一組用戶或程序的 API 資源。

在本章結束時，您將了解安裝和維護 Kubernetes 集群的工具和過程。此外，您將了解如何為具有代表性的真實用例配置 RBAC。

本章概括地介紹了以下概念：

了解 RBAC ( Role-Based Access Control )
使用 kubeadm 安裝集群
使用 kubeadm 升級 Kubernetes 集群版本
使用 etcdctl 備份和恢復 etcd
了解高可用 Kubernetes 集群

RBAC

在 Kubernetes 中，您需要先進行身份驗證，然後才能向 API resource 發出請求。
只有某些用戶應該具有完全訪問權限，而大多數用戶具有隻讀訪問權限（並且可能具有更改系統的權限），具體取決於角色。
例如，應用程序開發人員不需要管理集群節點。他們只需要傾向於運行和配置他們的應用程序所需的對象。
RBAC 通過允許或禁止訪問管理 API 資源來定義 account、group 和 process 的策略

RBAC High-Level Overview

RBAC 有助於實現各種用例：

為不同角色的用戶建立一套系統來訪問一組 Kubernetes 資源
控制在 Pod 中運行的程序以及它們可以通過 Kubernetes API 執行的操作
限制每個命名空間某些資源的可見性 RBAC 由三個關鍵構建塊組成，如下圖所示。它們一起將 API 原語及其允許的操作連接到所謂的主題，即 user, a group, or a ServiceAccount。

以下列表按術語細分了職責：

Subject The user or process that wants to access a resource
Resource The Kubernetes API resource type (e.g., a Deployment or node)
Verb The operation that can be executed on the resource (e.g., creating a Pod or deleting a Service)

Creating a Subject

user account 和 group 不存儲在 Kubernetes 數據庫 etcd 中，並且適用於在集群外部運行的程序。
service account 作為 Kubernetes 中的對象存在，並由集群內部運行的程序使用。

User accounts and groups

用戶應該由 Kubernetes Cluster 的管理員管理，然後將帳戶的憑據分發給真實的人或供外部程序使用。
需要對用戶調用 API Server 進行身份驗證。 Kubernetes 為這些 API 請求提供了多種身份驗證方法。表 2-1 顯示了驗證 RBAC 主題的不同方式。

表 2-1。管理 RBAC 主題的身份驗證策略

Authentication strategy	Description
X.509 client certificate	Uses an OpenSSL client certificate to authenticate
Basic authentication	Uses username and password to authenticate
Bearer tokens	Uses OpenID (a flavor of OAuth2) or webhooks as a way to authenticate

為簡單起見，以下步驟演示了創建使用 OpenSSL 客戶端證書進行身份驗證的用戶。這些操作必須使用 cluster-admin Role 對象執行。在考試期間，您不必自己創建用戶。您可以假設已為您執行了相關設置。因此，您無需記住以下步驟：

Log into the Kubernetes control plane node and create a temporary directory that will hold the generated keys. Navigate into the directory:
```
$ mkdir cert && cd cert
```

Create a private key using the openssl executable. Provide an expressive file name, such as <username>.key:

$ openssl genrsa -out rbean.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
....+++++
.....................................+++++
e is 65537 (0x010001)

$ ls
rbean.key

-out outfile，Output the key to specified file
2048，長度

Create a certificate sign request (CSR) in a file with the extension .csr.
```
$ openssl req -new -key rbean.key -out rbean.csr -subj "/CN=rbean/O=rbean"

$ ls
rbean.csr  rbean.key
```
- You need to provide the private key from the previous step.
- -new， New request
- -key，Private key to use
- -out，Output file
- -subj，Set or modify request subject
- The -subj option provides the username (CN) and the group (O).
最後，使用 Kubernetes 集群證書頒發機構 (CA) 簽署 CSR。以下命令簽署 CSR 並使其有效期為 364 天：
```
$ sudo openssl x509 -req -in rbean.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out rbean.crt -days 364
Signature ok
subject=/CN=johndoe/O=cka-study-guide
Getting CA Private Key
```
- CA 通常可以在目錄 /etc/kubernetes/pki 中找到，並且需要包含文件 ca.crt 和 ca.key。
- -x509，Output a x509 structure instead of a cert request (Required by some CA’s)
- -in，Input file
通過在 kubeconfig 中為 rbean 設置用戶條目，在 Kubernetes 中創建用戶。指向 CRT 和密鑰文件。在 kubeconfig 中為 rbean 設置上下文條目：
```
$ kubectl config set-credentials rbean --client-certificate=rbean.crt --client-key=rbean.key
User "rbean" set.

$ kubectl config set-context rbean-context --cluster=k8s.org --user=rbean
Context "rbean-context" created.
```
- set-credentials，Set a user entry in kubeconfig
- --client-certificate="": Path to a client certificate file for TLS.
- --client-key=""， Path to a client key file for TLS.
- set-context，Set a context entry in kubeconfig
- --cluster=""， The name of the kubeconfig cluster to use
- --user=""， The name of the kubeconfig user to use

切換到 rbean 用戶

$ kubectl config use-context rbean-context
Switched to context "rbean-context".

$ kubectl config current-context
rbean-context

use-context，Set the current-context in a kubeconfig file
current-context，Display the current-context

ServiceAccount

用戶代表一個真實的人，他通常使用 kubectl 可執行文件或 UI 儀表板與 Kubernetes Cluster 進行交互。一些服務應用程序（例如在 Pod 內運行的 Helm）需要通過 RESTful HTTP 調用向 API 服務器發出請求，從而與 Kubernetes Cluser 進行交互。例如，Helm 圖表將定義業務應用程序所需的多個 Kubernetes 對象。 Kubernetes 使用 ServiceAccount 通過身份驗證令牌向 API 服務器驗證 Helm 服務程序。可以將此 ServiceAccount 分配給 Pod 並映射到 RBAC 規則。

Kubernetes Cluster 已經附帶了一個 ServiceAccount，即默認命名空間中的默認 ServiceAccount。任何沒有明確分配 ServiceAccount 的 Pod 都使用默認的 ServiceAccount。

強制創建自定義 ServiceAccount

$ kubectl create serviceaccount build-bot
serviceaccount/build-bot created

創建 ServiceAccount 的聲明方式看起來非常簡單。您只需提供適當的種類和名稱

apiVersion: v1
kind: ServiceAccount
metadata:
name: build-bot

Listing ServiceAccounts

$ kubectl get serviceaccount
NAME        SECRETS   AGE
build-bot   0         4m1s
default     0         6d17h

Rendering ServiceAccount Details

創建對像後，API 服務器會創建一個包含 API 令牌的 Secret，並將其分配給 ServiceAccount。 Secret 和令牌名稱使用 ServiceAccount 名稱作為前綴。您可以使用 describe serviceaccount 命令發現 ServiceAccount 的詳細信息，如下所示：

$ kubectl describe serviceaccount build-bot
Name:                build-bot
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>

因此，您應該能夠找到默認和構建機器人 ServiceAccount 的 Secret 對象：

$ kubectl get secret

Assigning a ServiceAccount to a Pod

$ kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
pod/nginx created

檢視 yaml 檔

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

Understanding RBAC API Primitives

Role
- Role API Primitives 聲明了該規則應操作的 API 資源及其操作。
- 例如，“允許列出和刪除 Pod”，或者“允許查看 Pod 的日誌”，甚至兩者都具有相同的 Role 。任何未明確說明的操作均被禁止為一旦它與主題綁定。
RoleBinding
- binds the Role object to the subject(s).
- It is the glue for making the rules active.
- 例如，“將允許更新服務的 Role 綁定到用戶 John Doe”。

Default User-Facing Roles

Sample Exercises

Create the ServiceAccount named api-access in a new namespace called apps. :::warning :::spoiler 題目翻譯 : 建立一個名字叫做 api-access 的 ServiceAccount 在名字叫 apps 的 namespace 空間。 :::
用命令直接建 namespace 和 serviceaccount
```
$ kubectl create namespace apps

$ kubectl create serviceaccount api-access -n apps
```
編輯 namespace 的 yaml 檔
```
apiVersion: v1
kind: Namespace
metadata:
  name: apps
```
Create the namespace from the YAML file:
```
$ kubectl create -f apps-namespace.yaml
```
編輯 serviceaccount 的 yaml 檔
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-access
  namespace: apps
```
Run the create command to instantiate the ServiceAccount from the YAML file:
```
$ kubectl create -f api-serviceaccount.yaml
```
Create a ClusterRole with the name api-clusterrole, and create a ClusterRoleBinding named api-clusterrolebinding. Map the ServiceAccount from the previous step to the API resources pods with the operations watch, list, and get.
:::warning :::spoiler 題目翻譯 : 建立一個名字叫做 api-clusterrole 的 Clusterrole ，然後再建立一個名字 api-clusterrolebinding 的 Clusterrolebinding，讓上一題的 ServiceAccount 對於 pod 的操作只能 watch, list, 和 get。 :::
Use the create clusterrole command to create the ClusterRole imperatively:
```
$ kubectl create clusterrole api-clusterrole --verb=watch,list,get --resource=pods
```
- --resource=， Resource that the rule applies to
- --verb=， Verb that applies to the resources contained in the rule
If you’d rather start with the YAML file, use content shown in the file apiclusterrole.yaml:
```
$ nano api-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: api-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["watch","list","get"]
```
Use the create clusterrolebinding command to create the ClusterRoleBinding imperatively.
```
$ kubectl create clusterrolebinding api-clusterrolebinding serviceaccount=apps:api-access --clusterrole=api-clusterrole
```
- serviceaccount=，Service accounts to bind to the clusterrole, in the format <namespace>:<name>
- --clusterrole=，ClusterRole this ClusterRoleBinding should reference
The declarative approach of the ClusterRoleBinding could look like the one in the file api-clusterrolebinding.yaml:
```
$ nano api-clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: api-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: api-clusterrole
subjects:
- apiGroup: ""
  kind: ServiceAccount
  name: api-access
  namespace: apps
```
Create the ClusterRoleBinding from the YAML file:
```
$ kubectl create -f api-clusterrolebinding.yaml
```
Create a Pod named operator with the image nginx:1.21.1 in the namespace apps. Expose the container port 80. Assign the ServiceAccount api-access to the Pod. Create another Pod named disposable with the image nginx:1.21.1 in the namespace rm. Do not assign the ServiceAccount to the Pod. :::warning :::spoiler 題目翻譯 : 在名字叫做 apps 的 namespace 中，由名字叫做 api-access 的 ServiceAccount，用 nginx:1.21.1 的 image ，建立一個名字叫做 operator 的 pod ，Container 開一個 80 的 port number。不要用 ServiceAccount 在名字叫做 rm 的 namespace 中，用 nginx:1.21.1 的 image，建立另一個名字叫 disposable 的 pod。 :::
```
$ kubectl run operator --image=nginx:1.21.1 --restart=Never --port=80 serviceaccount=api-access -n apps
$ kubectl create namespace rm
$ kubectl run disposable --image=nginx:1.21.1 --restart=Nerver -n rm
```
Open an interactive shell to the Pod named operator. Use the command-line tool curl to make an API call to list the Pods in the namespace rm. What response do you expect? Use the command-line tool curl to make an API call to delete the Pod disposable in the namespace rm. Does the response differ from the first call? You can find information about how to interact with Pods using the API via HTTP in the reference guide. :::warning :::spoiler 題目翻譯 :
用一個交談式的貝殼程式，連到名字叫做 operator 的 pod。用 curl 命令做一個 API Call，請求內容是能列出名字是 rm 的 namespace 裡 pod 資訊。用 curl 命令做一個 API Call，請求內容是刪除在 rm 的 namespace 裡名字叫做 disposable 的 pod ，第一個回應的結果與第二個有何不同 ? API 參考文件連結 :::
```
$ kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
https://120.96.143.73:6443
```
- kubectl config view，Displays merged kubeconfig settings or a specified kubeconfig file.
- --minify，remove all information not used by current-context from the output
- -o，Output format. jsonpath=…
Navigate to the directory app-a/ch02/upgrade-version of the checked-out GitHub repository bmuschko/cka-study-guide. Start up the VMs running the cluster using the command vagrant up. Upgrade all nodes of the cluster from Kubernetes 1.20.4 to 1.21.2. The cluster consists of a single control plane node named k8s-control-plane, and three worker nodes named worker-1, worker-2, and worker-3. Once done, shut down the cluster using vagrant destroy -f. Prerequisite: This exercise requires the installation of the tools Vagrant and VirtualBox. :::warning :::spoiler 題目翻譯 : 連線到 https://github.com/bmuschko/cka-study-guide/tree/master/app-a/ch02/upgrade-version 這個 Github 網站，用 vagrant up 命令啟動 K8S Cluster ，將所有 K8S Cluster 的 node 從 1.20.4 升級到 1.21.2 的版本。 K8S Cluster 需要一台名字叫 k8s-control-plane 的 control plane node，和 3 台 work node ，名字分別是 work-1, work-2, work-3。以上動作完成後，使用 vagrant destroy -f 關閉 K8S Cluster。先決條件：本練習需要安裝 Vagrant 和 VirtualBox 工具。 :::
Navigate to the directory app-a/ch02/backup-restore-etcd of the checked-out Git‐Hub repository bmuschko/cka-study-guide. Start up the VMs running the cluster using the command vagrant up. The cluster consists of a single control plane node named k8s-control-plane and two worker nodes named worker-1 and worker-2. The etcdctl tool has been preinstalled on the node k8s-controlplane. Back up etcd to the snapshot file /opt/etcd.bak. Restore etcd from the snapshot file. Use the data directory /var/bak. Once done, shut down the cluster using vagrant destroy -f. Prerequisite: This exercise requires the installation of the tools Vagrant and VirtualBox. :::warning :::spoiler 題目翻譯 : 連線到 https://github.com/bmuschko/cka-study-guide/tree/master/app-a/ch02/backup-restore-etcd 這個 Github 網站，用 vagrant up 命令啟動 K8S Cluster ，K8S Cluster 需要一台名字叫 k8s-control-plane 的 control plane node，和 2 台 work node ，名字分別是 work-1, work-2。etcdctl 套件已經先裝在 k8s-controlplane 這台 node 上。將 etcd 備份到名字叫 /opt/etcd.bak 的 snapshot file。從 snapshot file 中恢復(? etcd 。以上動作完成後，使用 vagrant destroy -f 關閉 K8S Cluster。先決條件：本練習需要安裝 Vagrant 和 VirtualBox 工具。 :::

Kubernetes-Cluster-build.v2 Kubernetes-Objects