devops

引言 在當今的技術世界中，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....

👨‍💻簡介 《 Zeabur - 部署服務 從未如此簡單》 從來沒想過部署可以如此的方便快速，第一次接觸到Zeabur的時候覺得他跟一般的雲端服務商差不多，架設網站用個vm之類的，但仔細去摸索後才發現他是個想讓開發人員專注在寫扣這件事上，不需去管任何infra相關事項的一個服務，像是架設wordpress需要sql，就簡單的點兩下即可完成， 或是自己建立在github的部落格，也是一鍵點擊下去建立，並且厲害的是能自動識別github部落格的類型，主流的hexo、hugo都能自動辨識。 在介面上則是將一個專案用到的服務集中式的管理，Zeabur能夠全部部署在一起，不需去處理連線的問題，在一個單一的組態檔案中來管理服務所需的所有變數，不需要使用.env下去做設定，讓使用者有開箱即用的一流體驗。 今天就用Zeabur來快速建立wordpress，讓大家看看Zeabur的使用方式。 🔰基礎介紹 Zeabur 簡介 Zeabur 是一個主打「一鍵部署」的 PaaS 平台，類似的產品台灣的開發者一般比較流行使用 GitHub Pages（前端）以及 Render、Flyio（後端），Zeabur 相比於這些競爭對手，最大的特點在於： 官方文件、技術支援都有中文 ，且主機位於 GCP 台灣機房 操作更簡單，把 GitHub 上面的程式部署上線真的只需要「一鍵」 一個專案往往會有前端、後端、資料庫 … 各種服務，Zeabur 能夠全部部署在一起，方便管理 🎯setup 1. 建立project 登入官網後先點選Create Project來建立一個專案，接著輸入專案名稱並點選create 建立成功就會在主控台看到剛剛建立的專案了，我們點選剛剛建立的專案來繼續建立我們需要的服務 2. 建立service 點選Add Service 2.1 新增mysql service 因為wordpress需要連接mysql，因此我們先建立mysql服務 點下去等個幾秒mysql就建立好了，就是這麼的方便快速 2.2 新增wordpress database 接著我們點選Connect透過terminal連接到mysql去建立資料庫 建立完成後接著回到專案底下來繼續新增我們的wordpress服務 2.3 新增wordpress service 到這一步wordpress已完成建立 2.4 建立wordpress domain 建立完成後來接著建立domain 點選我們剛剛建立成功的domain來訪問我們的wordpress，點開後就會顯示wordpress的相關設定 2.5 設定wordpress後台 看到這個畫面就代表我們的wordpress已經設定完成了 登入後即可進入到wordpress的後台 點選左上角即可訪問我們的網站 以上就是使用zeabur來架設wordpress的設定過程，統整下來真的都是靠點選來建立所需的服務，並且服務是集中式的管理，也因為架設的主機是在GCP的台灣機房，因此速度體驗上也是沒什麼問題，並且官方有提供免費方案可以提供使用者進行免費試用，有興趣的人可以去嚐鮮體驗看看一建部署的強大威力🤓 📚Reference 🔗官方網站 -> Zeabur - Deploying your service with one click 🔗Github -> Zeabur (github....

甚麼是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。...

服務上雲後有時會需要固定一組IP主動對外發出連線，這時要考慮安全性與獨立性的問題，在爬文後發現了GCP推出的Cloud NAT，本篇文章簡單介紹一下這個工具的使用。 什麼是Cloud NAT GCP Cloud NAT是GCP上的一種服務，它提供了一個管理和部署Google Cloud上的NAT（Network Address Translation）的解決方案。 GCP Cloud NAT能夠讓使用者在不公開VM或GKE的外網IP情況下，透過共用一組IP對外溝通，外部服務無法直接存取Cloud NAT 閘道後的任何資源，確保了服務的安全性。 什麼時候使用Cloud NAT 在需要使用私有IP地址與外網連接時，可以使用Cloud NAT。 例如：在Pod訪問外網時需要固定Public IP的情境下會使用到。 如何使用Cloud NAT 準備環境 設定gcloud至正確專案 gcloud config set project <PROJECT_ID> 建立VPC網路與子網路 建立一台無外網的vm，region選asia-east1 ，zone選asia-east1-b，網路選剛剛建立的nat-network，子網選nat-subnet-192 建立防火牆並允許35.235.240.0/20網段，允許tcp 22 port，目標為無外網的vm 到IAP頁面並選擇SSH和TCP資源設定權限 到剛剛建立的vm curl httpbin.org/ip，此時應該是無法連線到外部 設定NAT 到Cloud NAT建立NAT gateway，並選擇稍早創建的VPC以及創建Router 這時候在curl一次就會有一組對外ip了，此ip即為nat自動幫我們創建的外部ip 有了 Cloud NAT ，可以在不使用外部ip的情況下，與外網連線且同時阻擋了由外部的存取，增加了不少安全性，降低主機被攻擊的風險。 Reference Cloud NAT overview | Google Cloud Set up Cloud NAT with Compute Engine | Google Cloud 利用 Cloud NAT 維持雲端的獨立性與安全性 - PeerOne Technology 皮偶玩互動科技 - Medium

什麼是 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...

標題：15 Best Practices when working with Docker 連結：15 Best Practices when working with Docker | by Ali Zeynalli | Dec, 2022 | Medium 本篇文章作者根據經驗以及自身研究整理出了15個使用Docker的技巧與提示 1. 進行中的工作不應保存在未命名、已停止的容器中 如果進行中的工作保存在不好的容器中，可能會導致資料丟失、風險以及安全問題、不利於協作 2. 定期清理Image 幫助釋放存儲空間，優化Docker引擎性能，減少安全風險，以及維持主機整潔，易於管理。 3. 使用授權的相依套件 可以帶來更好的合法性、安全性、可靠性、支持性和法律責任。 4. 將變化很大的部分放在 DockerFile 的末尾 因為Docker會將每個步驟緩存為一個單獨的容器，重複的操作將不會重新執行，將變化較大的部分放在最後可提高性能 5. 不要在容器啟動時就獲取相依套件 避免在容器啟動時獲取依賴包帶來的問題，並提高容器的啟動速度和可管理性。最佳實踐是在構建Image時就獲取依賴包，並將它們打包到Image中。另外，還可以使用多階段構建和緩存等技術來優化構建過程，提高構建速度和效率。 6. 不要掛載共享資料夾 有助於提高容器的可移植性、安全性、可重現性和可管理性。 7. 保持Image simple and small 可以提高應用程序的可移植性、降低安全風險、減少Image大小、提高Image構建和管理效率。 8. 從頭開始構建 最大限度地減少相依 9. Tag Image 使用合理的Tag，有助於對Image進行排序 10. 使用小型基礎Image 例如-slim或-alpine，可以帶來更明確的依賴項、更少的儲存、更少的安全漏洞和攻擊面以及更快的構建時間。 11. 使用官方Image 帶來可靠性、安全性、活躍的社群支持以及易用性等好處。 12. 創建臨時容器 Dockerfile定義的Image應該盡可能是臨時的，提供隔離環境、避免依賴衝突、快速清理、易於重複，提高工作效率與可靠性，方便快速測試，不必擔心對主機有影響。 13. 使用multi-stage構建 幫助減小Docker Image的大小，優化構建速度，簡化構建過程，以及提高Docker Image的安全性。...