80:31819/TCP 50m
```
- **每個 Pod 有唯一主機名**
- **唯一域名**
### **格式：**
```
主機名稱.service名稱.命名空間.svc.cluster.local
```
### **示例：**
```
nginx-statefulset-0.nginx.default.svc.cluster.local
```
---
### **說明：**
- StatefulSet 通過主機名和域名，確保每個 Pod 都有唯一標識並支持有狀態應用。
- 無頭 Service 的 ClusterIP 為 `None`，允許 Pod 之間直接通信。
---
以下是圖片內容的文字辨識及繁體中文翻譯：
---
## **3. 部署守護進程 DaemonSet**
- **在每個 Node 上運行一個 Pod，新加入的 Node 也同樣運行在一個 Pod 裡面。**
### **示例：**
在每個 Node 節點安裝數據採集工具。
---
### **指令操作：**
1. **部署 DaemonSet：**
```bash
[root@k8smaster ~]# kubectl apply -f ds.yaml
daemonset.apps/ds-test created
```
2. **查看 Pod：**
```bash
[root@k8smaster ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
ds-test-cbk6v 0/1 ContainerCreating 0 0s
ds-test-cx6fk 1/1 Running 0 30s
```
3. **進入 Pod：**
```bash
[root@k8smaster ~]# kubectl exec -it ds-test-cbk6v bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in future versions.
```
4. **查看文件：**
```bash
root@ds-test-cx6fk:/# ls /tmp/log
anaconda boot.log-20200902 containers firewalld
```
---
### **說明：**
- **DaemonSet** 用於確保每個 Node 上都執行一個 Pod，例如安裝系統監控、日誌收集、數據採集等工具。
- **特點：** 新加入的 Node 會自動部署相應的 Pod，適合全局性的守護進程需求。
# ConfigMap
以下是圖片內容的辨識及繁體中文翻譯，並補充完整 **1-4 步驟** 的詳細說明：
---
### **ConfigMap 操作步驟**
#### **1. 創建配置文件**
創建一個配置文件，例如 `redis.properties`：
```bash
[root@k8smaster ~]# vi redis.properties
# 文件內容
redis.host=127.0.0.1
redis.port=6379
redis.password=123456
```
---
#### **2. 創建 ConfigMap**
將配置文件創建為 ConfigMap：
```bash
[root@k8smaster ~]# kubectl create configmap redis-config --from-file=redis.properties
configmap/redis-config created
[root@k8smaster ~]# kubectl get cm
NAME DATA AGE
redis-config 1 10s
```
檢查 ConfigMap 詳情：
```bash
[root@k8smaster ~]# kubectl describe cm redis-config
Name: redis-config
Data:
redis.properties:
redis.host=127.0.0.1
redis.port=6379
redis.password=123456
```
---
#### **3. 以 Volume 形式挂載到 Pod 容器中**
**步驟：**
1. 編寫 YAML 文件，將 ConfigMap 作為 Volume 注入到 Pod 中：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mycontainer
image: busybox
command: ["sh", "-c", "cat /config/redis.properties; sleep 3600"]
volumeMounts:
- name: config-volume
mountPath: /config
volumes:
- name: config-volume
configMap:
name: redis-config
```
2. 應用配置：
```bash
[root@k8smaster ~]# kubectl apply -f cm.yaml
pod/mypod created
```
3. 查看 Pod 狀態並檢查配置：
```bash
[root@k8smaster ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
mypod 1/1 Completed 0 41s
[root@k8smaster ~]# kubectl logs mypod
redis.host=127.0.0.1
redis.port=6379
redis.password=123456
```
---
#### **4. 以變量形式挂載到 Pod 容器中**
**步驟：**
1. 編寫 YAML 文件，將 ConfigMap 值作為環境變量注入：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mycontainer
image: busybox
command: ["sh", "-c", "echo $REDIS_HOST; echo $REDIS_PORT; echo $REDIS_PASSWORD; sleep 3600"]
env:
- name: REDIS_HOST
valueFrom:
configMapKeyRef:
name: redis-config
key: redis.host
- name: REDIS_PORT
valueFrom:
configMapKeyRef:
name: redis-config
key: redis.port
- name: REDIS_PASSWORD
valueFrom:
configMapKeyRef:
name: redis-config
key: redis.password
```
2. 應用配置：
```bash
[root@k8smaster ~]# kubectl apply -f myconfig.yaml
pod/mypod created
```
3. 查看 Pod 狀態並檢查日誌：
```bash
[root@k8smaster ~]# kubectl logs mypod
127.0.0.1
6379
123456
```
---
### **小結**
- **Volume 挂載**：將 ConfigMap 文件直接映射到容器的文件系統中。
- **環境變量注入**：將 ConfigMap 的鍵值對作為環境變量傳遞給容器。
# K8s 安全機制
以下是圖片的文字辨識及繁體中文翻譯：
---
### **Kubernetes 集群安全機制**
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/9Alz4LLG6GVwGnsM-image-1737341555160.png)
#### **1. 概述**
1. **訪問 k8s 集群時**，需要經過三個步驟完成具體操作：
- 第一步：認證
- 第二步：授權
- 第三步：準入控制
2. **訪問過程：**
- 訪問時需要經過 `apiserver`，`apiserver` 做統一認證和驗證，例如門衛。
- 訪問過程中需要 **證書**、**token**，或者用 **用戶名+密碼**。
- 如果訪問 Pod，還需要 **serviceAccount**。
---
#### **第一步 認證：傳輸安全**
- **傳輸安全：**
- 對外不暴露 8080 端口，只能內部訪問，對外使用端口 6443。
- **認證方式：**
- `https` 證書認證：基於 CA 證書。
- `http` token 認證：通過 token 識別用戶。
- `http` 基本認證：使用用戶名+密碼認證。
---
#### **第二步 授權：**
- 基於 RBAC 進行授權操作。
- 基於角色訪問控制。
---
#### **第三步 準入控制：**
- 準入控制器的列表，根據列表決定是否允許執行操作。
---
### **2. RBAC**
### **基於角色的訪問控制**
- **角色：**
- **role**：特定命名空間訪問權限
- **ClusterRole**：所有命名空間訪問權限
- **角色綁定：**
- **roleBinding**：角色綁定到主體
- **ClusterRoleBinding**：集群角色綁定到主體
---
### **主體：**
- **user**：用戶
- **group**：用戶組
- **serviceAccount**：服務帳號
---
這是基於 RBAC 的角色和權限管理，適用於 Kubernetes 的訪問控制。如需進一步說明或具體範例，請隨時告訴我！😊
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/DdkVrwv0FBVX6fQ6-image-1737341811213.png)
以下是圖片中的文字辨識及翻譯成繁體中文：
---
### **1. 創建命名空間**
```bash
[root@m1 lucy]# kubectl create ns roledemo
namespace/roledemo created
```
---
### **2. 在新創建的命名空間中創建 Pod**
```bash
[root@m1]# kubectl run nginx --image=nginx -n roledemo
```
---
### **3. 創建角色**
```bash
[root@m1]# vi rbac-role.yaml
[root@m1]# kubectl apply -f rbac-role.yaml
role.rbac.authorization.k8s.io/pod-reader created
[root@m1]# kubectl get role -n roledemo
NAME AGE
pod-reader 19s
```
---
### **4. 創建角色綁定**
```bash
[root@m1]# vi rbac-rolebinding.yaml
[root@m1]# kubectl apply -f rbac-rolebinding.yaml
rolebinding.rbac.authorization.k8s.io/read-pods created
[root@m1]# kubectl get rolebinding -n roledemo
NAME AGE
read-pods 15s
```
---
### **5. 使用證書識別身份**
```bash
[root@m1 mary]# vi rbac-user.sh
[root@m1 mary]# cp /root/TLS/k8s/ca* ./
[root@m1 mary]# bash rbac-user.sh
2020/09/03 17:03:10 [INFO] generate received request
2020/09/03 17:03:10 [INFO] received CSR
[root@m1 mary]# kubectl get pods -n roledemo
```
---
### **說明：**
1. **命名空間** 用於區分不同的資源和工作負載。
2. **角色和角色綁定** 控制對特定命名空間的訪問權限。
3. **使用證書識別身份** 是基於 RBAC 的身份驗證機制，確保用戶能正確訪問資源。
# Ingress 概述
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/k8k7s6z3OEy6PZa7-image-1737343343204.png)
---
## **Ingress**
### **1. 將端口號對外暴露，通過 IP + 端口號進行訪問**
- **使用 Service 裡面的 NodePort 實現**
---
### **2. NodePort 缺陷**
- **在每個節點上都會起到端口**，在訪問時可以通過任何節點，通過節點 IP + 暴露端口號實現訪問。
- 意味著每個端口只能使用一次，一個端口對應一個應用。
- **實際訪問中都是用域名**，根據不同域名跳轉到不同端口服務中。
---
### **3. Ingress 和 Pod 的關係d**
- **Pod 和 Ingress 是通過 Service 關聯的**。
- **Ingress 作為統一入口**，由 Service 關聯一組 Pod。
---
### **說明：**
- **Ingress** 提供基於域名的訪問路由能力，實現集群內外通信的靈活控制。
- 它比 NodePort 更靈活且節約端口資源，是 Kubernetes 中常用的負載均衡工具之一。
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
## **5. 使用 Ingress**
- **第一步：** 部署 Ingress Controller
- **第二步：** 創建 Ingress 規則
---
我們在這裡選擇官方維護的 NGINX 控制器，實現部署。
---
以下是圖片中的文字辨識及翻譯成繁體中文：
---
## **6. 使用 Ingress 對外暴露應用**
### **(1) 創建 Nginx 應用，對外暴露端口使用 NodePort**
```bash
kubectl create deployment web --image=nginx
kubectl expose deployment web --port=80 --target-port=80 --type=NodePort
```
---
### **(2) 部署 Ingress Controller**
```bash
[root@k8smaster ~]# vi ingress-con.yaml
[root@k8smaster ~]# kubectl apply -f ingress-con.yaml
namespace/nginx-ingress created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
```
---
### **說明：**
1. **NodePort 暴露應用：**
- 通過 `NodePort` 將應用對外暴露，允許外部訪問特定端口。
2. **Ingress Controller 部署：**
- 使用配置文件 `ingress-con.yaml` 部署 Ingress 控制器，啟用基於域名的路由功能。
# helm 概述
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/t6qsyMHUPkTrcAXu-image-1737350287413.png)
### **Helm**
#### **1. Helm 引入**
1. **之前方式部署應用的基本過程：**
- 編寫 YAML 文件：
- Deployment
- Service
- Ingress
2. **如果使用之前方式部署單一應用，少數服務的應用，比較合適：**
- 例如部署微服務項目，可能有幾十個服務，每個服務都有一套 YAML 文件，需要維護大量 YAML 文件，版本管理特別不方便。
---
#### **2. 使用 Helm 可以解決哪些問題？**
1. 使用 Helm 可以把這些 YAML 作為一個整體管理。
2. 實現 YAML 高效複用。
3. 使用 Helm 應用級別的版本管理。
---
#### **3. Helm 介紹**
Helm 是一個 Kubernetes 的包管理工具，類似於 Linux 下的包管理器，如 yum/apt 等，可以很方便地將之前打包好的 YAML 文件部署到 Kubernetes 上。
---
#### **4.Helm 有 3 個重要概念：**
1. **Helm**：
一個命令行客戶端工具，主要用於 Kubernetes 應用 Chart 的創建、打包、發布和管理。
2. **Chart**：
應用描述，一系列用於描述 Kubernetes 資源相關文件的集合。
3. **Release**：
基於 Chart 的部署實體。一個 Chart 被 Helm 運行後將會生成對應的一個 Release；
它會在 Kubernetes 中創建出真實運行的資源對象。
---
#### **5.Helm 在 2019 年發布 V3 版本，和之前版本相比有變化**
1. **V3 版本刪除 Tiller**，架構變化。
2. **Release** 可以在不同命名空間重用。
3. **將 Chart 推送到 Docker 倉庫中**。
---
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
### **1. Helm 安裝**
1. **下載 Helm 安裝壓縮文件，上傳到 Linux 系統中**
```bash
[root@k8smaster ~]# tar zxvf helm-v3.0.0-linux-amd64.tar.gz
linux-amd64/helm
linux-amd64/README.md
linux-amd64/LICENSE
```
2. **解壓 Helm 壓縮文件，將解壓後的 Helm 目錄複製到 `/usr/bin` 目錄下**
```bash
[root@k8smaster linux-amd64]# mv helm /usr/bin
[root@k8smaster linux-amd64]# helm
```
---
### **2. 配置 Helm 倉庫**
#### **(1) 添加倉庫**
```bash
helm repo add 倉庫名稱 倉庫地址
```
示例：
```bash
[root@k8smaster linux-amd64]# helm repo add stable http://mirror.azure.cn/kubernetes/charts
"stable" has been added to your repositories
```
檢查倉庫列表：
```bash
[root@k8smaster linux-amd64]# helm repo list
NAME URL
stable http://mirror.azure.cn/kubernetes/charts
```
---
#### **(2) 更新倉庫地址**
```bash
[root@k8smaster linux-amd64]# helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "aliyun" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. Happy Helming!
```
---
### **(3) 刪除倉庫**
```bash
[root@k8smaster linux-amd64]# helm repo remove aliyun
"aliyun" has been removed from your repositories
```
---
### **說明：**
- 使用 `helm repo remove <倉庫名稱>` 可以刪除已添加的 Helm 倉庫。
- 這樣可以清理不再需要的倉庫條目，保持倉庫列表整潔。
---
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
```bash
[root@k8smaster linux-amd64]# helm search repo weave
NAME CHART VERSION APP VERSION DESCRIPTION
stable/weave-cloud 0.3.7 1.4.0 Weave Cloud is a add-on...
stable/weave-scope 1.1.10 1.12.0 A Helm chart for the We...
[root@k8smaster linux-amd64]# helm install ui stable/weave-scope
NAME: ui
LAST DEPLOYED: Mon Sep 7 14:22:47 2020
NAMESPACE: default
STATUS: deployed
[root@k8smaster linux-amd64]# helm list
NAME NAMESPACE REVISION UPDATED STATUS
ui default 1 2020-09-07 14:22:47.383427149 +0800 CST deployed
[root@k8smaster linux-amd64]# helm status ui
NAME: ui
LAST DEPLOYED: Mon Sep 7 14:22:47 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
```
---
1. **搜索 Helm 倉庫中的 Weave 應用**
- 使用命令 `helm search repo weave`，顯示兩個可用的應用：
- **stable/weave-cloud**：版本 0.3.7，應用版本 1.4.0。
- **stable/weave-scope**：版本 1.1.10，應用版本 1.12.0。
2. **安裝 Weave Scope**
- 使用命令 `helm install ui stable/weave-scope` 將 Weave Scope 安裝到 Kubernetes 中，並命名為 **ui**。
3. **查看已安裝的 Helm 應用列表**
- 使用命令 `helm list`，顯示應用 **ui** 已成功部署，位於命名空間 **default**。
4. **查看應用狀態**
- 使用命令 `helm status ui`，顯示應用名稱 **ui**，狀態為 **deployed**，部署版本為 **1**。
---
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
### **如何自己創建 Chart**
#### **1. 使用命令創建 Chart**
```bash
helm create chart名稱
```
示例：
```bash
[root@k8smaster ~]# helm create mychart
Creating mychart
[root@k8smaster mychart]# ls
charts Chart.yaml templates values.yaml
```
- **Chart.yaml**：當前 Chart 屬性配置信息。
- **templates**：編寫 YAML 文件放到這個目錄中。
- **values.yaml**：YAML 文件可以使用全局變量。
---
#### **2. 在 templates 文件夾創建兩個 YAML 文件**
- **deployment.yaml**
- **service.yaml**
示例：
```bash
[root@k8smaster templates]# ls
deployment.yaml service.yaml
```
---
### **說明：**
1. **Helm create** 命令自動生成 Chart 的目錄結構和必要文件，方便進一步編輯。
2. **templates 文件夾** 是放置 Kubernetes 配置文件（如 Deployment、Service 等 YAML 文件）的地方。
3. **values.yaml** 文件允許定義變量，提供動態和靈活的配置支持。
---
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
### **3. 安裝 mychart**
```bash
[root@k8smaster ~]# helm install web1 mychart/
NAME: web1
LAST DEPLOYED: Mon Sep 7 15:03:17 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
```
---
### **說明：**
1. **命令解釋**：
- `helm install`：用於安裝 Chart。
- `web1`：為此次安裝命名為 `web1`。
- `mychart/`：指定需要安裝的 Chart 目錄。
2. **輸出信息**：
- **NAME**：安裝的應用名稱，這裡是 `web1`。
- **LAST DEPLOYED**：最後部署的時間。
- **NAMESPACE**：部署的命名空間，默認為 `default`。
- **STATUS**：應用部署狀態，這裡是 `deployed`（已部署）。
- **REVISION**：部署的版本號，這裡是 `1`。
- **TEST SUITE**：測試套件信息，這裡是 `None`（沒有測試）。
---
### **4. 應用升級**
```bash
helm upgrade chart名稱
```
示例：
```bash
[root@k8smaster ~]# helm upgrade web1 mychart/
Release "web1" has been upgraded. Happy Helming!
```
---
### **說明：**
1. **命令解釋**：
- `helm upgrade`：用於升級已部署的 Chart 應用。
- `web1`：需要升級的應用名稱。
- `mychart/`：指定升級所基於的 Chart 目錄。
2. **輸出信息**：
- **Release "web1" has been upgraded**：表示應用 `web1` 已成功升級。
---
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
### **實現 YAML 高效複用**
- **通過傳遞參數，動態渲染模板，YAML 內容動態傳入參數生成。**
```bash
[root@k8smaster mychart]# ls
charts Chart.yaml templates values.yaml
```
- **在 Chart 中有 `values.yaml` 文件，定義 YAML 文件全局變量。**
---
### **操作步驟：**
1. **在 `values.yaml` 定義變量和值。**
2. **在具體 YAML 文件中，獲取定義變量值。**
---
### **說明：**
- YAML 文件大體有幾個地方不同的參數：
- **image**
- **tag**
- **label**
- **port**
- **replicas**
---
### **說明：**
使用 `values.yaml` 提高了 Chart 的靈活性，可以輕鬆實現模板的複用和參數化，方便不同環境配置。
---
# k8s 持久化儲存
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
### **數據卷 emptydir，是本地存儲，pod 重啟，數據不存在了，需要對數據持久化存儲**
#### **1. NFS，網絡存儲**
- **pod 重啟，數據還存在的方式**
---
### **第一步：找一台服務器作為 NFS 服務端**
#### **(1) 安裝 NFS**
```bash
yum install -y nfs-utils
```
---
#### **(2) 設置掛載路徑**
```bash
[root@atonline ntest /]# vi /etc/exports
/data/nfs *(rw,no_root_squash)
```
---
#### **(3) 掛載路徑需要創建出來**
```bash
[root@atonline ntest data]# mkdir nfs
[root@atonline ntest data]# ls
nfs
```
---
### **說明：**
1. **emptydir** 是 Kubernetes 中的一種臨時存儲方式，pod 重啟後數據會丟失。
2. **NFS（網絡文件系統）** 提供一種數據持久化存儲解決方案，pod 重啟後數據仍然保留。
3. **操作流程**：
- 安裝 NFS 軟件。
- 配置 NFS 的掛載路徑。
- 確保掛載的目錄已創建。
---
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
### **第二步：在 k8s 集群 node 節點安裝 NFS**
```bash
yum install -y nfs-utils
```
---
### **說明：**
- 在 Kubernetes 集群的每個節點上安裝 **NFS 客戶端工具** (`nfs-utils`)，以便節點能夠掛載 NFS 共享存儲。
---
以下是圖片內容的文字辨識及翻譯成繁體中文：
---
### **第三步：在 NFS 服務器啟動 NFS 服務**
```bash
# systemctl start nfs
# ps -ef | grep nfs
15:03 ? 00:00:00 [nfsd4_callbacks]
```
---
### **第四步：在 k8s 集群部署應用使用 NFS 持久化網絡存儲**
```bash
vi nfs-nginx.yaml
kubectl apply -f nfs-nginx.yaml
[root@k8smaster pv]# kubectl exec -it nginx-depl-6b96bc8d7d-92qhv bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version.
root@nginx-depl-6b96bc8d7d-92qhv:/# ls /usr/share/nginx/html
index.html
```
---
### **說明：**
#### **第三步：啟動 NFS 服務**
1. **啟動 NFS 服務**：通過 `systemctl start nfs`。
2. **驗證 NFS 啟動狀態**：使用 `ps -ef | grep nfs` 查看進程是否正常啟動。
#### **第四步：部署應用並使用 NFS**
1. **編輯 YAML 文件**：創建或修改 `nfs-nginx.yaml` 文件，配置 NFS 為持久化存儲。
2. **應用配置文件**：使用 `kubectl apply` 部署應用。
3. **驗證 NFS 存儲是否生效**：
- 使用 `kubectl exec` 進入 Pod。
- 確認存儲目錄（如 `/usr/share/nginx/html`）內的文件是否存在，例如 `index.html`。
---
### **PV 和 PVC**
1. **PV（Persistent Volume，持久化存儲）：**
- 持久化存儲，對存儲資源進行抽象。
- 對外提供可調用的地方（生產者）。
2. **PVC（Persistent Volume Claim，持久化存儲請求）：**
- 用於調用，不需要關心內部實現細節（消費者）。
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/osWVdYXoaoWBvta2-image-1737425386000.png)
# k8s 監控
### **集群資源監控**
### **1. 監控指標**
- **集群監控**
- 節點資源利用率
- 節點數量
- 運行的 Pods
- **Pod 監控**
- 容器指標
- 應用程序
---
### **2. 監控平台搭建方案：Prometheus + Grafana**
#### **(1) Prometheus**
- 開源的
- 具備監控、報警、數據庫功能
- 以 HTTP 協議定期抓取被監控組件的狀態
- 不需要複雜的集成過程，使用 HTTP 接口接入即可
---
#### **(2) Grafana**
- 開源的數據分析和可視化工具
- 支援多種數據源
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/k2Kgei9VrKUtm41G-image-1737431399886.png)
```YAML
# rbac-setup.yaml
apiGroups: ["*"]
resources:
- nodes
- nodes/proxy
- services
- endpoints
- pods
verbs: ["get", "list", "watch"]
---
apiGroups:
- extensions
resources:
- ingresses
verbs: ["get", "list", "watch"]
nonResourceURLs: ["/metrics"]
verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: prometheus
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: prometheus
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: prometheus
subjects:
- kind: ServiceAccount
name: prometheus
namespace: kube-system
```
# k8s 高可用集群
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/IWsIsOcoqEizYTKK-image-1737445662276.png)
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/g7khJjvP9vaPZrx8-image-1737445931517.png)
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/FqBt277RZDlRMTfT-image-1737447248701.png)
# k8s 部署流程
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/pIMK0hBwUkVbAUvB-image-1737453741721.png)
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/E7Z2huIbJXOtAhJY-image-1737454023904.png)
```
FROM ubuntu:22.04
# 設定時區為台北
ENV TZ=Asia/Taipei
RUN apt-get update && apt-get install -y tzdata && \
ln -sf /usr/share/zoneinfo/$TZ /etc/localtime && \
echo $TZ > /etc/timezone && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
# 複製並執行安裝腳本
COPY install.sh /tmp/install.sh
RUN chmod +x /tmp/install.sh && /tmp/install.sh
```
# k8s核心組件
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/VHfefOFyJ2w3ujxH-image-1737708797625.png)
[](https://bookstack.treemanou.com/uploads/images/gallery/2026-04/wGSVTF0PqNV9DXob-image-1775714710761.png)
**3. k8s 集群架構組件**
- **Master**（主控節點）和 **Node**（工作節點）
**(1) Master 組件**
- **apiserver**
集群統一入口，以 RESTful 方式，交給 etcd 存儲
- **scheduler**
節點調度，選擇 Node 節點應用部署
- **controller-manager**
處理集群中常規的後台任務，一個資源對應一個控制器
- **etcd**
存儲系統，用於保存集群相關的數據
**(2) Node 組件**
- **kubelet**
- Master 排到 Node 節點代表，管理本機容器。
- **kube-proxy**
- 提供網絡代理，負載均衡等操作。
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/9yvSvsn0UIJSvrjb-image-1737710111332.png)
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/xmcWqhFoJCkTOuXa-image-1737712398081.png)
---
**K8S 核心概念**
1. **Pod**
- 最小部署單元
- 一組容器的集合
- 共享網絡
- 生命週期是短暫的
2. **Controller**
- 確保預期的 Pod 副本數量
- 無狀態應用部署
- 有狀態應用部署
- 確保所有的 Node 運行同一個 Pod
- 一次性任務和定時任務
3. **Service**
- 定義一組 Pod 的訪問規則
---
如有其他需求，請隨時告訴我！
[](https://bookstack.treemanou.com/uploads/images/gallery/2025-01/nPoPBQnry7LR1o2F-image-1737708872912.png)
kubectl run podtest --image=nginx
1\. kubectl向apiserver發送一個創建pod的請求，apiserver會將數據放到etcd存儲。
2\. Scheduler通過list-watch的方式，收到未綁定pod資源，通過自身調度算法選擇一個合適的node進行綁定，然後響應給apiserver，把信息更新到etcd中。
3\. Kubelet同樣通過list-watch的方式，收到分配到自己節點上pod，調用docker api創建容器，然後將容器狀態響應給apiserver，同時，把容器的信息、事件及狀態也通過apiserver寫入到etcd中。
# 2026 k8s 需知
從 5 年前（2021年）的 K8s 基礎出發，系統性地梳理了 **2026 年現代化 Kubernetes 架構**的演進。
身為系統建設負責人與架構師，以下是整理的核心重點：
### 1. 基礎架構的根本變革
- **脫離 Docker：** K8s 已移除 Dockershim，底層運行環境轉為 **containerd/CRI-O**。
- **輕量化首選：** **K3s** (K8s/2) 成為主流，適合邊緣運算與本地測試。
- **工具鏈升級：** 建議在 Mac 使用 **OrbStack** 快速啟動 K3s；使用 **Kind** 模擬多節點生產環境。
- **遷移利器：** 使用 **Kompose** 將舊有的 `docker-compose.yaml` 轉換為 K8s 物件。
- **Gateway API 取代 Ingress：** 這是 2026 年最重要的標準。透過角色分離（GatewayClass, Gateway, HTTPRoute）解決權限與配置混亂問題。
- **Service 角色重新定義：**
- **ClusterIP：** 內部通訊基石，實現 Pod 間的備援與負載平衡。
- **NodePort：** 您的實體環境中，對接手動 SLB 的關鍵入口。
- **LoadBalancer：** 雲端自動化專用，在地端手動環境可被 NodePort 取代。
- **ExternalName：** 用於將叢集外部服務（如舊資料庫）內部化。
- **現代交警 Traefik：** K3s 內建，支援自動發現與 Gateway API，負責精準指揮 Traffic。
- **版本與權限控制：** 透過 **Label (v1/v2)** 區分版本，並利用 **HTTPRoute Weight** 實現金絲雀發佈或藍綠部署。
- **Service Mesh (服務網格)：** 如 Istio 或 Cilium，處理東西向流量的加密 (mTLS)、觀測與斷路保護。
- **YAML 物件現代化：** 建議在既有清單中加入 **StorageClass** (動態儲存)、**NetworkPolicy** (零信任安全) 與 **ServiceAccount** (權限管理)。
---
1. **本地實驗：** 在 **OrbStack** 啟動 K8s，將一個簡單服務從 `docker-compose` 透過 `kompose` 搬上去。
2. **網路重構：** 練習不寫 Ingress，直接用 **Gateway API + HTTPRoute** 透過 NodePort 對接您的實體 SLB。
3. **穩定性強化：** 試著部屬兩個版本的 Pod，並在 `HTTPRoute` 調整權重進行流量切分。
- **技術核心：** 內建基於 **K3s** 的輕量化叢集。
- **優勢：**
- **極速啟動：** 啟動 K8s 僅需約 2-5 秒。
- **低資源消耗：** 閒置時幾乎不佔 CPU，且 RAM 是動態分配的。
- **原生網路：** 支援直接透過 `.orb.local` 網域存取叢集內的 Service，不需要手動 `port-forward`。
- **適用場景：** 日常開發、快速測試 API 與微服務。
---
- **技術核心：** 將每個 K8s 節點跑在一個 Docker 容器內。
- **優勢：**
- **模擬多節點：** 透過一個 YAML 配置就能啟動 1 個 Master + N 個 Worker 節點。
- **CI/CD 友好：** 因為底層是 Docker，它可以在 GitLab Runner 或 GitHub Actions 中輕鬆執行。
- **Gateway API 測試：** 非常適合用來測試最新的 Gateway API 或 Service Mesh 配置。
- **適用場景：** 測試集群架構行為（如 Pod 親和性、節點故障轉移）。
---
- **優勢：** 繼承了 K3s 的快速與低資源特性，同時擁有 Kind 的多節點管理能力。
- **適用場景：** 需要模擬多節點但電腦資源（RAM）較為吃緊時。
---
| **工具** | **啟動速度** | **資源佔用** | **模擬多節點** | **推薦等級 (2026)** |
| **OrbStack** | 極快 | 極低 | 較難 (內建單節點) | ⭐⭐⭐⭐⭐ (Mac 首選) |
| **Kind** | 中等 | 中等 | **極易** | ⭐⭐⭐⭐ (架構測試首選) |
| **K3d** | 快 | 低 | 容易 | ⭐⭐⭐⭐ (輕量首選) |
| **Minikube** | 慢 | 高 (需 VM) | 普通 | ⭐⭐ (已逐漸式微) |
---
1. **安裝 OrbStack：** 作為您的 Docker 與基礎 K8s 環境，解決 90% 的開發需求。
2. **搭配 Kind：** 當您需要測試複雜的負載平衡、多節點調度或跨節點網路時，在 OrbStack 上跑 Kind 叢集。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-v1
spec:
replicas: 2
selector:
matchLabels:
app: my-app
version: v1
template:
metadata:
labels:
app: my-app
version: v1
spec:
containers:
- name: nginx
image: nginxdemos/hello:plain-text
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-app-v1
spec:
selector:
app: my-app
version: v1
ports:
- protocol: TCP
port: 80
targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-v2
spec:
replicas: 2
selector:
matchLabels:
app: my-app
version: v2
template:
metadata:
labels:
app: my-app
version: v2
spec:
containers:
- name: nginx
image: nginxdemos/hello:plain-text
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-app-v2
spec:
selector:
app: my-app
version: v2
ports:
- protocol: TCP
port: 80
targetPort: 80
```
---
```
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml
kubectl apply -f https://raw.githubusercontent.com/traefik/traefik/v3.0/docs/content/reference/dynamic-configuration/kubernetes-crd-definition-v1.yml
helm upgrade --install traefik traefik/traefik \
--namespace traefik --create-namespace \
--set ports.web.nodePort=30080 \
--set ports.web.port=8000 \
--set service.type=NodePort \
--set providers.kubernetesGateway.enabled=true \
--set additionalArguments="{--providers.kubernetesgateway,--entrypoints.web.address=:8000}" \
--skip-crds
```
```
kubectl apply -f apps.yaml
kubectl apply -f gateway-api.yml
```
---
```
kubectl get endpoints my-app-v1 my-app-v2
```
```
for i in {1..20}; do
curl -s -H "Host: localhost" http://localhost | grep "Server name"
done
```
---
1. **埠號對齊**：解決了 `Empty reply` 與 `PortUnavailable` 問題。
2. **所有權衝突**：透過重置 Gateway 與正確使用 Helm 參數規避了 `SSA Conflict`。
3. **命名空間授權**：透過 `from: All` 解決了跨 Namespace 404 的問題。
4. **內容識別**：修正了 `grep` 關鍵字，確保能從 Nginx 輸出中精確捕捉版本差異。
