k8s

引言 在當今的技術世界中，Kubernetes 已成為容器化應用的領導平台。作為一個高效的容器編排系統，它不僅管理著容器的部署和擴展，還提供了必要的自動化支持，以保證應用的高可用性和性能。在這個框架中，自動擴展功能起著至關重要的作用，特別是在面對不斷變化的負載和需求時。 隨著企業和開發者尋求更靈活、更高效的資源管理方式，Kubernetes Horizontal Pod Autoscaler (HPA) 應運而生。HPA 是 Kubernetes 內建的一項機能，旨在自動調整 Pod 的數量以滿足當前的性能需求。這不僅提高了資源的使用效率，也確保了應用的穩定運行，特別是在高流量或不可預測的使用模式下。 HPA 的核心價值在於其能夠基於實際的性能指標（如 CPU 利用率或自定義指標）動態調整 Pod 的數量。這種彈性的擴展機制意味著系統能夠自動應對突發流量，同時在需求降低時縮減資源，從而達到成本效益的最佳平衡。 Horizontal Pod Autoscaler (HPA) 簡介 定義 Kubernetes Horizontal Pod Autoscaler，簡稱 HPA，是一種在 Kubernetes 環境中自動調整 Pod 數量的機制。它根據指定的指標（如 CPU 利用率、記憶體使用量或自定義指標）動態增減 Pod 的數量，以應對應用的負載變化。 工作原理 當 HPA 被部署到 Kubernetes 集群時，它會定期（預設 15 秒）檢查所指定指標的當前值，來判斷是否需要擴展或縮減 Pod 的數量。當這些指標超過或低於預設的閾值時，HPA 會自動增加或減少 Pod 的數量，從而確保應用平穩運行。 主要特點 動態擴展：根據實時的系統負載進行擴展或縮減。 靈活配置：支持多種指標，包括標準指標和自定義指標。 成本效益：通過優化資源使用，減少不必要的開支。 HPA的運作機制 指標類型 CPU 利用率：最常用的自動擴展指標。 自定義指標：根據特定的業務需求或性能指標進行擴展。 決策過程 HPA 決策過程基於預定的指標和閾值。當指標超過或低於設定的閾值時，HPA 會觸發擴展或縮減的操作。 擴展策略 線性擴展：根據指標的增減比例進行擴展或縮減。 自定義策略：可以根據特定需求定制擴展策略。 HPA的設置與配置 基本設置步驟 確定指標：選擇用於自動擴展的指標，如 CPU 利用率或自定義指標。 部署 Metrics Server：安裝 Metrics Server 以提供必要的性能指標數據。 創建 HPA 資源：通過 Kubernetes 的 YAML 文件定義 HPA 資源，指定目標 Pod 和相應的擴展指標。 以下是一個使用 YAML 定義的 HPA 實例： apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 在這個例子中，如果 myapp 的平均 CPU 使用率超過 50%，HPA 會自動增加 Pod 的數量，最多到 10 個副本。當 CPU 使用率下降時，HPA 則會減少 Pod 的數量，但不會少於 1 個副本。...

👨‍💻簡介 在當今的雲計算時代，容器化和微服務架構成為了重要趨勢。Kubernetes，作為領先的容器編排平台，提供了強大的功能來管理和部署應用程式。然而，隨著應用程式和用戶的增加，有效管理誰可以對 Kubernetes 集群執行何種操作變得至關重要。這裡，RBAC (Role-Based Access Control) 機制起到了關鍵作用。 🔰基礎介紹 什麼是 RBAC： RBAC 可以根據角色對用戶進行細粒度的權限管理。它基於三個主要概念：角色（Role）、角色綁定（RoleBinding）和主體（Subjects）。 角色 (Role) 和 ClusterRole： 角色 (Role)：定義了一組權限，這些權限表示對特定 Kubernetes 資源的操作，如建立、讀取、更新和刪除。 ClusterRole：與 Role 類似，但它適用於整個集群範圍，而不是單個命名空間。ClusterRole 可以用來賦予對集群級資源的訪問權限，或者跨所有命名空間的特定資源。 角色綁定 (RoleBinding) 和 ClusterRoleBinding： 角色綁定 (RoleBinding)：將角色的權限賦予給特定的主體。 ClusterRoleBinding：類似於 RoleBinding，但它將 ClusterRole 的權限賦予給整個集群的主體，而不是特定命名空間的主體。 主體 (Subjects)： 可以是用戶、群組或服務帳號。 為什麼要在 Kubernetes 中使用 RBAC？ 在 Kubernetes 中，RBAC 使得管理大型、多用戶的集群變得更為安全和方便。它確保了只有合適的用戶和服務能夠訪問關鍵的 Kubernetes 資源，從而降低了安全風險。 如何使用 RBAC 要開始使用 RBAC，首先要在 Kubernetes 集群中建立角色。例如，你可能有一個角色，只允許對 Pod 資源進行讀取操作。 kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] --- kind: RoleBinding apiVersion: rbac....

甚麼是secret 在 Kubernetes 裡，Secret 就像是一個保險箱，可以放你任何不想公開的東西。比如說密碼、API 金鑰、憑證等，這樣的資料可能會被放在 Pod 裡，但你可以用 Secret 來避免直接在應用程式的程式碼中暴露這些機密資料。 可以說 Secret 就像是 ConfigMap 的一個好朋友，但更專門用來保護機密資料的地方。 為甚麼需要secret 最主要的用意是保護你的敏感資訊，不讓它們在 Pod 或容器中以明文流傳。這樣可以讓我們的應用程式變得更安全，減少機密資訊外洩的風險。還能讓你的秘密資料在不同 Pod 之間分享，並且保有安全性。 何時使用secret 保存必要應用程式的憑證，如 TLS 證書，以確保安全通信。 儲存應用程式所需的金鑰，包括外部服務的 API 金鑰，確保安全連接。 保管敏感的環境變數，如資料庫密碼等機密驗證資訊，維護應用程式安全性。 安全儲存驗證資訊，如 OAuth 令牌，用於與其他應用程式進行安全交互。 維持隱私的配置設定，如設定文件、金鑰路徑等，確保敏感資訊不外洩。 secret的類型有哪些 內建類型 用途 Opaque 使用者定義的任意資料 kubernetes.io/service-account-token 服務帳戶令牌 kubernetes.io/dockercfg ~/.dockercfg 檔案的序列化形式 kubernetes.io/dockerconfigjson ~/.docker/config.json 檔案的序列化形式 kubernetes.io/basic-auth 用於基本身份驗證的憑證 kubernetes.io/ssh-auth 用於 SSH 身份驗證的憑證 kubernetes.io/tls 用於 TLS 客戶端或伺服器端的資料 bootstrap.kubernetes.io/token 啟動引導令牌資料 如何撰寫使用secret 建立secret 聲明式 apiVersion: v1 kind: Secret metadata: name: my-secret data: username: YWRtaW4= # Base64 編碼的 "admin" password: c2VjcmV0cGFzc3dvcmQ= # Base64 編碼的 "secretpassword" 宣告式 從命令行傳遞資訊建立secret kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secretpassword 從檔案建立secret kubectl create secret generic my-secret --from-file=path/to/username....

👨‍💻簡介 今天早上在下kubectl get pods時，突然跳出了以下錯誤 warning Unable to connect to the server: x509: certificate has expired or is not yet valid 下了kubeadm alpha certs check-expiration之後才發現原來是憑證過期 因此紀錄一下解決過程 Information environment NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" docker version Client: Version: 1.13.1 API version: 1.26 Package version: docker-1.13.1-162.git64e9980.el7.centos.x86_64 Go version: go1.10.3 Git commit: 64e9980/1.13.1 Built: Wed Jul 1 14:56:42 2020 OS/Arch: linux/amd64 Server: Version: 1....

甚麼是Kubernetes ConfigMap ConfigMap主要功用是儲存我們服務的設定，這使得我們可以將我們的應用服務具備可移植性，當需要相對應的環境參數時，只需要修改ConfigMap，而不需要去更動到image即可更換成新的部屬環境。 為甚麼需要ConfigMap 最主要的用意是共享相同設定。在初期開發時可能只有幾個服務而直接把設定檔寫死，如果在後期變成微服務的架構下，上百個服務都有自己的設定檔在日後維護下會顯得麻煩，因此有了ConfigMap的出現，幫助我們將環境變數與容器鏡像解藕，便於修改應用設定，減少維護成本 何時使用ConfigMap，ConfigMap使用場景 ConfigMap通常儲存服務的環境變數、命令行參數、配置文件等非機密資料，使用場景有設定檔與容器鏡像分離、多環境支持、共享設定、動態設定更新等等 ConfigMap有哪些特點 解藕配置 -> 將服務的設定檔與容器鏡像分離，使服務在不重新建置新的容器鏡像可修改和管理設定檔，提高容器鏡像的通用性和靈活性 靈活性 -> ConfigMap支援多種格式，並且需要時可動態更新設定，無須重啟服務或重新佈署容器 共享設定 -> ConfigMap允許多個Pod共享同一份設定檔，確保了使用相同設定檔的Pod的一致性，提高設定的可維護性和一致性 集中管理 -> ConfigMap在K8s集群中可以集中管理所有的ConfigMap，不需要逐個修改Pod的設定 如何撰寫使用ConfigMap 創建ConfigMap Imperative(命令式) --from-literal kubectl create configMap myconfig --from-literal=k1=v1 --from-literal=k2=v2 --from-file kubectl create configMap myconfigfromkey --from-file=fromfilekey=from-key Declarative(聲明式) apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very 使用ConfigMap 使用ConfigMap定義容器環境變量 從單一ConfigMap定義容器環境變量 ConfigMap ## create configmap kubectl create configmap special-config --from-literal=special.how=very Pod apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: registry....

什麼是 Kubernetes Deployment? 一樣先來個官網解說 A Deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments. 跟ReplicaSet不同，Deployment的工作主要是為 pod & replicaset 提供了一個宣告式的設定 & 更新方式，透過定義 desired status，Deployment controller 會在所謂的 controlled rate 下達到使用者所期望的狀態，這些機制是由 k8s 自動化完成，因此官方建議應該透過 Deployment 來佈署 pod & replicaset。...

什麼是 Kubernetes ReplicaSet? 先來個官網解說 A ReplicaSet’s purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods. 根據上述描述，Replica Set主要的作用是確保始終都有一定數量的相同Pod可用，保證服務的高可用性。 Kubernetes RS是Kubernetes中的一種控制器，主要用於管理Pod的複製和伸縮，確保Pod的數量。RS具有以下幾種特性 自動管理pod的副本數量：確保指定數量的Pod跟使用者所期望的一致(desired status)，如果發生故障或需要擴展，它會自動創建或刪除Pod。 確保Pod的健康狀態：如果發生故障會對失敗的Pod進行重新調度 創建Pod的Template：當需要新的Pod時會根據定義的Pod Template創建 為什麼需要Replicaset? 在Kubernetes集群中，Pod的管理對於系統的可靠性和彈性至關重要。如果一個Pod發生故障，RS會自動創建一個新的Pod來代替它，確保服務繼續運行。同時，當服務需要擴展以滿足流量增加時，Kubernetes RS也可以自動創建額外的Pod。因此RS解決了以下問題： 確保服務的高可用性和可靠性：RS可以自動維護一定數量的Pod，確保服務在Pod失敗時仍然可以正常運行。 方便服務的擴展：使用RS可以根據需求調整Pod的副本數量，實現服務的快速擴展。 簡化服務管理：RS可以自動調整Pod的數量，減少手動管理的工作量。 Kubernetes Replicaset是如何運作的？ 定義RS，指定所需的Pod副本數量和Pod Template，創建後，ReplicaSet使用定義好的Pod Template創建Pod，並開始監控每個Pod的狀態以及數量是否與定義的一致(desired status)，如果低於指定副本數則會創建Pod，高於指定副本數則會刪除Pod，當Pod被意外刪除時會創建新的Pod來做替代。 什麼時候使用Replicaset？ 使用RS通常適用於以下情況： 需要確保一定數量的Pod正在運行，以保持服務的可用性和可靠性。 需要能夠自動擴展和縮小Pod數量，以應對流量變化和其他需求。 希望能夠自動替換發生故障的Pod，以確保服務的連續運行。 需要管理一個服務的多個Pod，並且希望使用Kubernetes提供的自動化功能，例如調度、網路配置和負載平衡。 Kubernetes Replicaset有哪些特性？ 高可用性：RS的目的是維護一個穩定的Pod副本集，確保始終有一定數量的相同Pod可用，從而保證服務的高可用性。 健康檢查和自動恢復：ReplicaSet可以通過定期檢查Pod副本的健康狀態來確保服務始終運行。當Pod故障或被刪除時，ReplicaSet會自動創建新的Pod來代替故障的Pod，確保服務的可用性及穩定性。 自動擴縮：RS會監視Pod副本數量，並自動創建或刪除Pod副本以確保Pod副本數量達到指定的數量。使服務可以自動擴展和縮放，以應對不同的負載。...

什麼是Kubernetes Service？ 先來個官網的解說 A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them. 白話文就是，訪問Pod用的一個Component。ＸＤ Kubernetes Service是個抽象概念，通過Service，當我們的Pod創建好後，定義訪問它們的策略，該如何去訪問一群相同邏輯的Pod，給Pod提供一組穩定的IP或是Port。 因此也可以把Service當作是一種掛在一群運行相同應用程式前面的LoadBalancer，詳見下圖。 圖片來源 為什麼需要Kubernetes Service？ 因為在Kubernetes集群中，Pod的IP地址是不穩定的，可能因為重新調度或重啟Container而改變了IP。為了使其他應用程式能夠穩定地訪問Pod，需要使用Kubernetes Service。 Kubernetes Service是如何工作的？ 當Pod啟動時，它們會自動註冊到Kubernetes集群中的一個服務發現機制中，例如Kubernetes DNS或etcd。Service會監聽這個服務發現機制，並根據Label Selector選擇要提供服務的Pod。 當其他應用程式需要訪問Pod時，它們可以通過Service的IP和Port進行訪問，Service會將請求根據Label Selector轉發到選定的Pod。由於Service的IP和端口是穩定的，即使Pod的IP地址發生變化，其他應用程式依然可以一直使用相同的IP和Port訪問該Pod。 圖片來源 Kubernetes Service的類型有哪些？ Kubernetes Service有以下四種類型： ClusterIP: 在Kubernetes集群內部使用，通常用於應用程式的內部通訊。 NodePort: 將Pod暴露到Kubernetes集群的外部，並使用Node的IP和一個Static Port進行訪問。 LoadBalancer: LoadBalancer是ClusterIP和NodePort的一種擴展。在公有雲上使用，使用雲供應商提供的LoadBalancer將流量轉發到Service中的Pod。 ExternalName: 允許服務將外部DNS名稱映射到Kubernetes集群內部的svc名稱上。這樣可以在不修改應用程式代碼的情況下實現外部服務的訪問。 圖片來源 Kubernetes Service有哪些功能？ Kubernetes Service具有以下功能： 透明地將請求轉發到Pod中，無需修改應用程式代碼。 提供負載均衡，分散流量到多個Pod中。 支持多種協議，例如TCP、UDP和HTTP。 可以設置Session Affinity，將請求路由到相同的Pod。 可以進行Port轉發，將請求轉發到Pod中的不同Port。 支持跨命名空間訪問。 如何創建和管理Kubernetes Service： 要創建 Kubernetes Service，可以使用以下兩種方式： 宣告式(Declarative) kind: Service apiVersion: v1 metadata: name: my-service spec: # type 一共有四種(ClusterIP, NodePort, LoadBalancer, ExternalName)，預設是 ClusterIP type: ClusterIP # 選擇帶有 "app=MyApp" 的 pod selector: app: MyApp # Service 實際對外服務的設定 ports: # 使用的協定與port，預設為TCP - protocol: TCP port: 80 # Pod對外開放的port，如無設定，預設與spec....

Kubernetes是現代應用程序開發和部署的重要技術，而Pod是Kubernetes中最小的部署單位。Pod是一個或多個container的集合，它們共享一個網路命名空間和一個網路接口。Pod不僅提供了一個簡單而強大的container環境，還可以用於實現多種container編排方案，例如負載平衡、數據管理、多container協作等。 本文將深入探討Kubernetes中的Pod，介紹Pod的基本概念、設計原則和實現方式，以及與其他資源的關係。您將學習如何創建和配置Pod，如何使用Kubernetes管理Pod，以及如何通過Pod實現高效、彈性和可靠的應用程序部署。 什麼是Kubernetes Pod Kubernetes Pod是Kubernetes集群中最小的部署單位。一個Pod可以包含一個或多個container，這些container共享相同的網路和儲存空間。Pod提供了一個環境，讓container可以協同工作，形成一個應用程序。 Pod的結構和特性 Pod包含以下元素： 共享網路空間 (Networking)：Pod 中的所有container共享相同的網路空間，可以在container之間通過 localhost 進行通信。 共享儲存空間 (Shared Storage)：Pod 中的所有container共享相同的儲存空間，可以在container之間共享文件、環境變量等。 容器 (Containers)：Pod 中可以包含一個或多個container，這些container可以共享同一個網路和儲存空間，方便container之間的互相協作。 存活和重啟策略 (Liveness and Restart Policy)：Pod 的存活策略指定了在容器出現異常情況時，Kubernetes 如何應對，如重新啟動 container 或者將其標記為失敗。Pod 的重啟策略則指定了當 Pod 中的所有 container 都停止運行時，Kubernetes 如何進行重啟。 元數據 (Metadata)：Pod 中包含一些元數據，如 Pod 名稱、命名空間、標籤等，這些元數據可以用於管理和監控 Pod。 Pod的特性包括： 生命週期短暫 可以擁有多個container 具有唯一的IP地址 具有獨立的儲存空間 具有網路隔離 如何創建和管理Pod 要創建 Kubernetes Pod，可以使用以下兩種方式： 宣告式（Declarative）：使用 YAML 或 JSON 格式的文件來定義 Pod 的結構、元資料和規格，包括 Pod 名稱、container image、資源限制、網路設定等。 apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: nginx-container image: nginx:latest ports: - containerPort: 80 接著使用kubectl創建pod...

👨‍💻簡介 有時候修改掛載的config檔，無法即時更新，需要重啟pod才會生效，為了解決這個問題，k8s-reloader因此而誕生，透過觀察掛載的configmap或是secret的變化自動對掛載的物件做滾動更新。 以下為在minikube環境下，透過掛載nginx-config檔並搭配reloader這個插件進行熱部署。 🔗github-repo : stakater/Reloader: A Kubernetes controller to watch changes in ConfigMap and Secrets and do rolling upgrades on Pods with their associated Deployment, StatefulSet, DaemonSet and DeploymentConfig – [✩Star] if you’re using it! (github.com) 🔰基礎介紹 運作原理 Reloader偵測所有資源變化，對有變化的資源使用SHA1計算資源的哈西值 Reloader查看是否有設定相關的annotation，並查看有設定annotation資源的特殊環境變量 對有設定annotation的資源比對其哈希值，如果環境變量中哈希值不同，則更新環境變量，如果環境變量不存在，則創建一個 環境變量名稱 ConfigMap：STAKATER_{configmap_name}_CONFIGMAP ，比如 ConfigMap 的名稱為 foo，則生成的環境變量的名稱為：STAKATER_FOO_CONFIGMAP。 Secret：STAKATER_{secret_name}_SECRET ，比如 Secret 的名稱為 foo，則生成的環境變量的名稱為：STAKATER_FOO_SECRET。 環境變量的值 使用 SHA1 計算的 ConfigMap 或者 Secret 的哈希值。 版本需求 k8s版本需 >= 1.9 安裝方式 使用Manifests安裝 kubectl apply -f https://raw....