查詢 CIDR CIDR 分配儲存在 API Server 上: cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep range CNI Plugin 配置文件位置 CNI Plugin 配置文件位置在以下位置: /etc/cni/net.d/ 例如: /etc/cni/net.d/10-weave.conflist 列出所有資源名稱 如: pod, deployment, configmap。 kubectl api-resources --namespaced

Kubectl 自動補全 # 自動補全腳本 source <(kubectl completion bash) echo "source <(kubectl completion bash)" >> ~/.bashrc # 把 kubectl 簡化成 k alias k=kubectl complete -o default -F __start_kubectl k –all-namespaces 替代 kubectl -A 建立物件 kubectl apply -f ./my-manifest.yaml # 建立資源 kubectl apply -f ./my1.yaml -f ./my2.yaml # 建立資源從多個

操作簡寫 例如: kubectl get pod pod1 可以寫成 kubectl get po pod1 以下是常用簡寫: certificates = cert, certs certificiaterequests = cr, crs certificatesigningrequests = csr componentstatuses = cs configmaps = cm cronjobs = cj customresourcedefinitions = crd, crds daemonsets = ds deployments = deploy endpoints = ep events = ev horizontalpodautoscalers = hpa ingresses = ing limitranges

Ingress 一句話說 Ingress 就是用不同的 Path 導向不同 Service 的功能。 如我們有2個頁面，一個是網站一個是 API ，分別屬於不同 K8S Service 。 Ingress 可以讓兩個 Service 用以下方式存取: # Web Service 存取

K8S 各種服務使用的 Port ETCD: 2379,2380 port Kube-API: 6443 port Kubelete: 10250 port Kube-scheduler: 10259 port Kube-controller-manager: 10257 port 各種 Service 的內部 IP: 30000 - 32767 port K8S Service 中的 DNS 如果有個 Service 如下: Service Name: web-service Namespace: default 這樣就能用以下三個 URL 來存取 Service: # 同 Namespace

Container Network Interface 容器網路介面 K8S 的 CNI 是指容器網路介面（Container Network Interface），它是一個標準的 API，用於讓 K8S 與不同的網路插件溝通，實現

節點列表 假定我們有以下兩節點: controlplane node01 更新 Control Plane 主節點 假定我們要更新的目標版本是 1.27.0 ，如果要更新別的版本請手動修改以下版本 排空 controlplane 節點: kubectl drain controlplane --ignore-daemonsets 然後執

K8S 使用的儲存與網路介面 K8S 提供了三種開放的接口規範，分別是 CRI、CNI 和 CSI，用於對接不同的後端，實現計算、網路和存儲資源的管理。 只要符合

Kubectx 和 Kubens 是兩個用於簡化 Kubernetes 集群管理的命令行工具。 Kubectx 允許您快速在不同的 Kubernetes 集群和命名空間之間切換。 Kubens 允許您快速在不同的命名空間之間切換。 這兩個工具都

Network Policy K8S Network Policy 是一種 Kubernetes 的功能，可以讓你控制 Pod 之間或 Pod 與外部網路的通訊規則。你可以使用 Network Policy 來定義哪些 Pod 可以互相連接，或者哪些 Pod 可以存取特定的 IP 或埠

Secure Context 設置容器為 no-root 用戶 我們可以加入以下這段: spec: securityContext: runAsUser: 1010 加完之後狀況如下: --- apiVersion: v1 kind: Pod metadata: name: ubuntu-sleeper namespace: default spec: securityContext: runAsUser: 1010 containers: - command: - sleep - "4800" image: ubuntu name: ubuntu-sleeper 也可以寫在Contai

建立一個 Secret 用於儲存映像檔專用 假定我們映像檔來源如下: Name: private-reg-cred Username: dock_user Password: dock_password Server: myprivateregistry.com:5000 Email: dock_user@myprivateregistry.com 我們以此用以下指令建立一個專用的 secret 儲存映像檔伺服器與登入資訊: kubectl create secret

Service Account 介紹 服務帳戶 (Service Account) 是一種由 Kubernetes 管理的帳戶類型，主要用於為 Pod 中執行的程序提供身分。它可以讓 Pod 訪問 Kubernetes API 和其他資源，而無需使用密碼或其他敏感資訊。

Cluster Role 由於有些資源是綁定某一台主機的，例如: Volume 這種存在硬碟上的資源。 並且這些資源橫跨多個 Namespace 與多個 Node ， 如開發環境跟生產環境都需要 Volume 。 而有時候需要

我們是否能在 K8S 建立使用者 並非直接建立，而是採用 x509 建立使用者鑰匙後建立。 K8S 的權限種類 Node 例如每個 Worker Node 都擁有一個權限身份，設置在 kubelet 用來存取 Kube API

K8S API 如果我們需要為 K8S 設置自訂介面，更加自動化，甚至將 K8S 由大語言模型管理，這時候存取 API 就是個需要的功能了。 常見的 API 我們這邊以不一定真實存在的 URL:

K8S 中各部件通訊時如何保障安全 kube-apiserver, kube-controller-manager, kube-scheduler, etcd, kubelet, kube-proxy 都存在著自己的鑰匙與憑證。 具體來說，每個部件都有著對應的憑證與Key: # 預設管理員 admin.crt admin.key # KUBE-SCHEDULER scheduler.crt scheduler.key # KUBE-CONTROLLER-MANAGER controllermanager.crt

失效情況 當 ETCD server 失效，或者 Kube API server 失效時，這時無法使用 kubectl 指令登入查看。 這種時刻，需要做的就是登入該 Server ，然後使用 K8S 採用的容器 Runtime 工具來檢查錯誤報告。

ETCD 的預設 Port ETCD server 預設使用 2379 port，所以當 Log 發生連線 2379 port 失敗時，可能是與 ETCD server 連線發生問題。

檢查 ETCD 登入 Log 我們可以用以下指令查看 etcd 的 client 端登入 Log，包含驗證成功與失敗。 -l 代表詳細內容， -u 代表來自使用者的訊息。 journalctl -u etcd.service -l 或者我們可以採用 kubectl

在外部 ETCD server Restore 回復備份 我們的備份位置: /root/cluster2.db 將要儲存新的 etcd 資料的目錄: /var/lib/etcd-data-new 進行備份回復的指令: ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/etcd/pki/ca.pem --cert=/etc/etcd/pki/etcd.pem --key=/etc/etcd/pki/etcd-key.pem snapshot restore /root/cluster2.db --data-dir /var/lib/etcd-data-new 修改 Service 修改以下檔案: /etc/systemd/system/etcd.service 把 ... [Service] User=etcd Type=notify

用 PS 指令檢查 etcd 的各個配置檔案路徑與參數 有些情況 Kubectl 工具未安裝在 etcd server 上，所以必須要手動用 ps 指令檢查參數: ps aux|grep etcd 結果: etcd 808 0.0 0.0 11218624 56044 ? Ssl 01:58 0:44 /usr/local/bin/etcd --name etcd-server --data-dir=/var/lib/etcd-data

如何檢查Cluster採用的ETCD的IP or URL ? 由於 Kube-API server，記錄著這類的訊息，所以可以調出 Pod 訊息查看 ETCD 的位置。 kubectl -n kube-system describe pod <Kube-API Server 的 Pod 名稱

Config不等於Config Map KubeConfig 為何要使用 KubeConfig ? 由於如果每次使用 kubectl 指令時，都要附上長串的使用者/密碼/憑證路徑，對維運效率的十分有影響的。 如

備份的幾種方式 Velero 可以簡單佈署在 Docker 上的 K8S 備份工具，還有 Web GUI 。 操作簡單功能完整。 此種方式甚至可以把 Volume 一起打包。 (文章撰寫時)是開源免費的。 https://velero.io/docs/v1.13/ Kubectl 備

ETCD 是什麼? K8S 的 ETCD 是一個開源的分散式鍵值儲存系統，用於儲存 Kubernetes 叢集的配置和狀態資料。 它是 Kubernetes 的核心元件之一，為叢集提供以下功能： 共享配置： 儲存 Kubernetes 叢

基本概念 以下是更新 K8S 需要更新的組件: (以下為同版本的組件) kube-apiserver (位於 Master 上) Controller-manager (位於 Master 上) kube-scheduler (位於 Master 上) kubelet (位於 Worker上) kube-proxy (位於 Work

Drain 與 uncordon 在 Kubernetes (K8S) 中，Drain (有排水的意思) 功能可以將 Pod 轉移到其他的 Node。 方便對某個 Node 進行更新。 排空 node01 由於一般會有 Daemonsets，所

Init Containers 在 Kubernetes (K8S) 中，Init Containers 是一種特殊的容器，在 Pod 內的應用容器啟動之前運行。 Init Containers 可以包含一些應用鏡像中不存在的實用工具和安裝腳本。 你可以在 Pod 的規

關於1個Pod中的2個容器共用1個Volume 以下這個YAML中存在1個 Pod app 此 Pod 中有兩個容器app與sidecar。 接著我們注意到以下兩個容

Exec 執行 Pod 中的指令 假定我們的 Pod 稱為 app 。 例如，以下的的指令用來直接看 Pod 中的 Log (當然，這不是好方法，但在一切裝置好之前，也許會用上): kubectl exec -it app cat /log/app.log

命令建立 Secret 直接採用指令來輸入 Secret 的方法: kubectl create secret generic db-secret --from-literal=DB_Host=sql01 --from-literal=DB_User=root --from-literal=DB_Password=password123 YAML 儲存 Secret 將 Secret 轉換成 YAML 編輯: kubectl create secret generic db-secret --from-literal=DB_Host=sql01 --from-literal=DB_User=root --from-literal=DB_Password=password123 --dry-run=client -o yaml > db-secret.yaml 可以看到 Base64 編碼後的 Secret (防止一眼被人

環境變數 我們可以採用以下方式設置環境變數: apiVersion: v1 kind: Pod metadata: labels: name: webapp-color name: webapp-color namespace: default spec: containers: - env: - name: APP_COLOR value: pink image: kodekloud/webapp-color imagePullPolicy: Always name: webapp-color 其中的這一段就是了: - env: - name: APP_COLOR value: pink Config Map 以下是

如果 Dockerfile 跟 K8S 的 YAML 配置的 Entrypoint 與 Command 不一樣呢? 實際上執行的指令會是哪一種? FROM python:3.6-alpine RUN pip install flask COPY . /opt/ EXPOSE 8080 WORKDIR /opt ENTRYPOINT ["python", "app.py"] CMD ["--color", "red"] apiVersion: v1 kind: Pod metadata: name: webapp-green labels: name: webapp-green spec: containers: - name: simple-webapp image: kodekloud/webapp-color command: ["python",

我們觀察以下的 Deployment: apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" creationTimestamp: "2024-02-01T01:17:43Z" generation: 1 name: frontend namespace: default resourceVersion: "1023" uid: 2933b6b7-59b7-412f-b806-8b80a593f61f spec: minReadySeconds: 20 progressDeadlineSeconds: 600 replicas: 4 revisionHistoryLimit: 10 selector: matchLabels: name: webapp strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: creationTimestamp: null labels: name: webapp spec: containers: - image: kodekloud/webapp-color:v1 imagePullPolicy: IfNotPresent name: simple-webapp ports: - containerPort: 8080 protocol:

檢查 Log 只要採用以下方式即可查看 Log 了。 kubectl logs <Pod名稱>

Metrics Server 可以監控 K8S 的 Cluster 上的每個 Node 的 CPU, RAM 等使用。 安裝 最簡單的方式是參照以下網址，直接一行指令安裝: https://github.com/kubernetes-sigs/metrics-server kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml 使用 可以查看 Node 的 CPU 與 RAM 使用率。 kubectl top node 輸

檢查預設的 Scheduler Scheduler 是個 Pod ，位於 kube-system 這個 namespace。 用以下指令查看 Scheduler: kubectl get pod -n kube-system 設置 Service Account 與 Cluster Role 設置如下: ServiceAccount: my-scheduler (kube-system namespace) ClusterRoleBinding: my-scheduler-as-kube-scheduler ClusterRoleBinding: my-scheduler-as-volume-scheduler 同時建立 Config Map 與 Depl

ServiceAccount 和 ClusterRoleBinding ServiceAccount（服務帳戶） ServiceAccount（服務帳戶） 是一種 Kubernetes 資源，用於為 Pod 提供身份。Pod 可以使用 ServiceAccount 來訪問

Static pods 在 Kubernetes 中，Static Pod 是一種特殊的 Pod，它不像一般的 Pod 由 Deployment 或 DaemonSet 等控制器管理，而是直接由特定節點上的 kubelet 进程管理。Static Pod 的主要特點

Daemonsets 這類程式常駐於 Node 上，類似程式的守護進程。 可用以下指令檢查所有 Namespace 的 Daemonsets: kubectl get daemonsets --all-namespace 運行叢集守護進程，例如日誌收集、監控、網路代理程式等。 在所有節點

Resource limits 資源限制 我們可以設置一個 Deployment 最少需要多少資源，與最多消耗多少資源。 具體的用法是在 containers 裏頭寫下 requests 與 limits 項目。 官方的範例: --- apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name:

Node Affinitty 在 Kubernetes 中，Node affinity（節點親和性）是一種用於控制 Pod 調度到哪些節點上的機制。它允許您根據節點的屬性和標籤，指定 Pod 應該调度到哪些

Taints AND Tolerations 在 Kubernetes 中，Taints 和 Tolerations 是一種用於控制 Pod 調度到哪些節點上的機制。 Taints Taint 是一種附加到節點上的鍵值對。它表示該節點不適合運行具有特定容忍度（

Labels and Selectors Labels 是附加到 Kubernetes 對象（例如 Pod、Deployment、Service 等）上的鍵值對。它們可以用來對對象進行分類和標識，以便於管理和查找。

Kube-scheduler kube-scheduler 負責監視新創建的或尚未調度（unscheduled）的 Pod，並選擇一個最佳節點來運行這些 Pod。由於 Pod 中的容器和 Pod 本身可能有不同的要求

MicroK8S Ubuntu 官方提供了一個 snap 套件可以超快的安裝 K8S ， 稱為 MicroK8S。 sudo snap install microk8s --classic --channel=1.28 sudo usermod -a -G microk8s $USER sudo chown -f -R $USER ~/.kube su - $USER 安裝後檢查狀態是否安裝完成 microk8s status --wait-ready 使

Imperative imperative command 指令式命令，例如詳細描述每個需要的步驟。 Declarative command 宣告式命令，僅需要描述期待，實現則由程式自行決定。 如 kubectl run nginx-pod --image=nginx:alpine 就屬於 imperative command。

列出 services kubectl get services 結果如下 controlplane ~ ➜ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 13m kubernetes 的 ClusterIP 是 K8S 預設的服務。 顯示 service 的細部內容 kubectl describe service kubernetes 結果如下。 controlplane ~ ➜ kubectl describe service kubernetes Name: kubernetes Namespace: default Labels: component=apiserver provider=kubernetes

列出 namespaces kubectl get namespaces 列出某 namespaces 裏頭的 pods 例如我們要取得 research namespaces 裏頭的 pod。 kubectl -n research get pods 算出某個 namespaces 裏頭的 pods 數量 kubectl -n research get pods --no-headers | wc -l 手動在某 namespaces 裏頭啟動 pod kubectl -n finance run redis

取得當前有多少 Deployments kubectl get deployments 檢查 Deployments kubectl describe deployment frontend-deployment 用 YAML 執行一個 Deployment 記得 kind: Deployment 開頭要大寫 kubectl apply -f deployment-definition-1.yaml 閱讀 Deployment 官方文檔 kubectl explain deployment

本篇筆記主要談論 ReplicaSet 的基本操作。 ReplicaSet 只能維持 Pod 的數量，不能實現 Pod 的版本更新。如果要更新 Pod 的映像檔或配置，需要手動刪除舊的 Pod，讓 ReplicaSet 根據模板創建

本篇筆記主要談論 kubectl 的基本操作。 列出 default namespace 的 pods kubectl get pods 或者 kubectl get pods -n default 手動運作一個 Nginx 的 pod kubectl run nginx --image=nginx 確認 pod 使用哪個 image 用以下指令顯示 pod 完整細節。 例如我們的