黑皮考町

Azure AKS Outbound 流量最佳化 - 為什麼選擇 NAT Gateway 而不是 Load Balancer 前言 當部署 Azure Kubernetes Service (AKS) 叢集時，如何高效管理出站流量 (Outbound Traffic) 是影響系統穩定性、可擴展性和成本優化的關鍵因素。傳統上，AKS 會透過 Azure Load Balancer 來處理出站流量，但這種方式有諸多限制。因此，使用 Azure NAT Gateway 是更優秀的選擇。 為什麼 NAT Gateway 比 Load Balancer 更適合 AKS 出站流量？ 1. 避免 SNAT Port 枯竭 當使用 Azure Load Balancer 作為 AKS 的出站流量處理方式時，會透過 Source Network Address Translation (SNAT) 來分配臨時埠 (Ephemeral Ports)，但這些埠數量有限，對於高流量環境來說很容易 耗盡 (SNAT Exhaustion) 。 2. 提供固定的 Outbound IP，增強安全性 透過 NAT Gateway，AKS 叢集的所有出站流量都會透過 單一的靜態 Public IP ，使安全控管更加容易，可確保外部服務僅允許來自特定 IP 的請求。 3. 更佳的擴展性與效能 更高吞吐量： 支援高達 50 Gbps 的流量處理能力。 自動擴展： 無需手動調整，適用於動態擴展的 AKS 叢集。 4. 降低成本與簡化設定 使用 Azure Load Balancer 處理出站流量時，會產生額外的 SNAT 規則管理成本 ，且 Load Balancer 本身的收費也會隨著規模增加。相比之下， NAT Gateway 的計價方式更簡單。 Terraform 設定範例 - 如何在 AKS 上配置 NAT Gateway 1. 建立 NAT Gateway 的靜態 Public IP resource "azurerm_public_ip" "natg...

使用 Nginx Ingress Controller 進行 MQTT L4 負載均衡 在 Kubernetes 中，當你希望為 MQTT (Message Queuing Telemetry Transport) 提供 L4 (Layer 4) 負載均衡 ，可以使用 Nginx Ingress Controller 來管理 TCP 流量 。由於 MQTT 運行在 TCP 層 ，並不適用於 HTTP/2，因此需要特別配置。 為什麼選擇 Nginx Ingress Controller？ 支援 TCP 負載均衡 ：可直接處理 MQTT 連線。 與 Kubernetes 無縫整合 ：利用 ConfigMap 設定 TCP 服務。 可擴展與高可用性 ：透過 Kubernetes 自動擴展。 支援 TLS 加密 ：可進行安全通訊。 步驟 1：安裝並配置 Nginx Ingress Controller 首先，請確保你的 Kubernetes 叢集 已安裝 Nginx Ingress Controller ，這可以透過 Helm Chart 來快速安裝： helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm install nginx-ingress ingress-nginx/ingress-nginx \ --set controller.publishService.enabled=true \ --set tcp.1883="default/mqtt-service:1883" 步驟 2：使用 ConfigMap 配置 TCP 負載均衡 由於 MQTT 使用 TCP ，我們需要定義 ConfigMap 來讓 Nginx Ingress Controller 處理 TCP 連線 。 apiVersion: v1 kind: ConfigMap metadata: name: tcp-services namespace: ingress-nginx data: "1883...

  Kubernetes中的TLS應用 隨著資訊傳遞速度的快速增加和數據的廣泛使用，保障資料安全性已成為一個至關重要的議題。特別是在大規模應用中，例如容器化環境下的 Kubernetes（k8s）集群，通信安全性無疑是一個極為重要的環節。而透過 Transport Layer Security（TLS）技術的應用，我們能夠有效地保障通信的安全性。 Transport Layer Security（TLS）技術的應用 在資訊傳輸中，若敏感資料如使用者帳號和密碼以明文形式傳送，這對駭客來說是易於竊取的。因此，我們採用加密技術來保護這些敏感資訊，將其加密後再傳送給伺服器進行解密（即對稱加密）。 然而，在傳送加密金鑰的過程中，金鑰本身可能被竊取，這樣一來駭客就有可能用偷來的金鑰來解密敏感資訊。為了解決此問題，伺服器會生成一對公鑰（Public Key）和私鑰（Private Key）。公鑰會傳送給瀏覽器，瀏覽器使用公鑰將金鑰加密後再傳送回伺服器。伺服器可以使用私鑰解密獲取金鑰，這樣一來就能保障金鑰在傳遞過程中的安全性（即非對稱加密）。 然而，即使使用了非對稱加密，駭客仍然有可能透過釣魚網站的方式誘使使用者交出金鑰，因此我們需要確認連線對象是否是合法的網站。 建立連線時，瀏覽器會要求伺服器提供證書以驗證其身份。此證書包含了伺服器的公鑰以及發行機構的訊息。通過驗證這個證書，我們可以確認公鑰的合法性，從而判斷連線對象是否是合法的網站。 然而，駭客也有可能偽造證書，因此為了避免這種情況的發生，各個證書授權機構會生成一對公私鑰。在發出證書之前，證書授權機構會使用私鑰對證書進行加密。這樣一來，瀏覽器在獲得證書後可以使用內建的公鑰對其進行解密，以驗證證書的合法性。 TLS 在 Kubernetes 中的重要性 在 Kubernetes 集群中，無論是 API Server、Pod 之間的通信，還是其他組件之間的通信，都需要得到安全保護。TLS 技術的應用使得這些通信變得安全可靠，有效地防止了敏感信息的泄露和不良攻擊的發生。 為了識別各個元件的身份，我們在 Kubernetes 環境中設置了相應的 client certificate 和 server certificate。 舉例來說，System admin user、Kube Scheduler、Kube Controll ...

Kubernetes 系統中 ETCD 備份還原教學 在 Kubernetes 系統中，ETCD 是一個關鍵的組件，負責存儲系統中的所有配置資料。為了確保在災難發生時可以快速恢復系統狀態，定期備份和還原 ETCD 是至關重要的。以下是一個簡單的教學，介紹了如何在 Kubernetes 系統中進行 ETCD 的備份和還原。 備份 ETCD 1. 使用以下指令查找 ETCD 對外的連接端點： bash kubectl describe pods -n kube-system etcd-controlplane | grep advertise-client-urls    獲取到 Endpoint，例如：https://10.1.218.16:2379。 2. 使用以下指令查找憑證位置： bash kubectl describe pods -n kube-system etcd-controlplane | grep pki    確定憑證位置，例如：    - Cert File: /etc/kubernetes/pki/etcd/server.crt    - Key File: /etc/kubernetes/pki/etcd/server.key    - CA Cert File: /etc/kubernetes/pki/etcd/ca.crt 3. 使用以下指令備份 ETCD 資料庫： bash ETCDCTL_API=3 etcdctl \ --endpoints=https://10.1.220.8:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key snapshot save /opt/cluster1.db 還原 ETCD 1. 使用以下指令還原 ETCD 資料庫： bash ETCDCTL_API=3 etcdctl \ --endpoints=https://10.1.220.8:2379 \ --cacert=/et...

  How to use a Google Cloud Persistent Disk (PD) as a Persistent Volume (PV) in Kubernetes 什麼是 Persistent Volume（PV） Persistent Volume（PV）是 Kubernetes 中用來管理儲存資源的抽象化物件。系統管理員可以透過 PV 來管理集群中的實體儲存媒體。 要怎麼使用 Persistent Volume （PV） 要使用 Persistent Volume（PV），首先需要宣告 Persistent Volume Claim（PVC），並透過 PVC 來要求儲存空間。一旦 PVC 被宣告，Kubernetes 就會根據 PVC 中指定的條件尋找適合的 PV 來滿足 Pod 的需求，並將 PV 掛載到 Pod 中。 在 Google Cloud 的公有雲服務裡提供了一種叫做 Cloud Persistent Disk 的服務，它是一種持久性的存儲解決方案，可供 Kubernetes 中的應用程式使用。若想要在 Kubernetes 中使用 Cloud Persistent Disk 作為 Persistent Volume（PV），可參考以下作法： 方法一 Static Provisioning： 在 GCP 上建立 Cloud Persistent Disk（PD）： bash gcloud compute disks create my-disk --size=10GB --zone=us-central1-a 建立 PersistentVolume (PV) YAML： yaml apiVersion: v1 kind: PersistentVolume metadata: name: my-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain gcePersistentDisk: pdName: my-disk fsType: ext4 建立 PersistentVolumeClaim (PVC) YAML： yaml...

  Best practice to set requests & limits for CPU & memory on Kubernetes 設定適當的 Resource Requests & Limits 是確保在 Kubernetes 集群上部署的 Pod 能夠順利運行並保持穩定性的關鍵步驟。透過合理地管理和調整資源，我們可以最大程度地提升系統的性能和可靠性，同時有效地利用集群中的資源，實現資源的最佳利用。 Kubernetes Limits and Requests 請求（Requests） 指定容器運行所需的最低 CPU 和記憶體量。當 Kubernetes 的 Scheduler 調度 Pod 資源時，會根據這個值進行決策。 限制（Limits） 定義容器可消耗的最大 CPU 和記憶體量。透過限制，可以防止容器超用資源，避免資源匱乏和潛在的性能下降。 Best Practice 在設定 CPU 的請求和限制時，建議不設定 CPU 的限制。這是因為在某些情況下，如果 Pod 需要額外的資源且集群中還有可用資源，就可以動態提供給 Pod 使用。 針對記憶體的請求和限制，最佳做法是將請求和限制設定為相同的值。這樣做的目的是為了避免 Pod 過度使用節點上的資源，進而觸發 Out of Memory（OOM）機制，導致 Pod 異常終止。 yaml apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mycontainer image: myimage resources: requests: memory: "512Mi" cpu: "100m" limits: memory: "512Mi" # 設置為跟 requests 相同的值 Pod Eviction 當節點資源不足，觸發 Out of Memory（OOM）時，Kubernetes 就會進行 Pod Eviction 來釋放資源。這時Kubelet 根據 Pod 的記憶體使用情況和其重要性來決定哪個 Pod 該被「犧牲」...