跳到主要內容

發表文章

How to use a Google Cloud Persistent Disk (PD) as a Persistent Volume (PV) in Kubernetes

  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 apiVersi
最近的文章

Best practice to set requests & limits for CPU & memory on Kubernetes

  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 該被「犧牲」

實現多人協作的 Terraform 組態管理:以 GCP Cloud Storage 與 AWS S3 為例

實現多人協作的 Terraform 組態管理:以 GCP Cloud Storage 與 AWS S3 為例 Terraform 是當前主流的基礎設施即代碼(IaC)工具,能夠快速構建基礎設施。然而,在多人協作的環境中,必須確保不同人員之間不會發生 race condition 的情況,以避免潛在的衝突和問題。 為了解決這個問題,Terraform 提供了遠端狀態(remote state)和鎖定(lock)機制。遠端狀態(remote state)指的是將 apply 後的結果存儲在遠端儲存庫中,使得多人可以訪問同一份狀態,從而確保一致性。而鎖定(lock)機制則是避免多人同時修改狀態文件而引發的問題。 Terraform Lock 機制 產生 Lock ID : 當使用者開始對 Terraform 的狀態文件(.state)進行修改時,Terraform 會產生 Lock 相關資訊如下: json { "ID":"be65a702-cd4b-543c-3e5c-9af9bc7b3d18", "Operation":"OperationTypeApply", "Info":"", "Who":"andy51002000@cs-682367130783-default", "Version":"1.7.5","Created":"2024-04-14T07:19:41.825202066Z", "Path":"terraform.tfstate" } 建立 .tflock 文件: 同時,Terraform 會在與狀態文件(.state)相同的目錄下創建一個名為 .tflock 的文件。這個文件用於表示當前狀態文件(.state)的鎖定狀態。 鎖定持續時間: 當使用者開始修改狀態文件(.state)時,該 .tflock 文件會一直存在,直到該使用者完成操作。這樣可以確保其他使用者在該時間段內無法修改同一個狀態文件(.state),從而避免衝突。 鎖定釋放: 當使用者完

AWS CloudFormation CFN -Signal

使用CFN-Signal在AWS CloudFormation中確保部署完成 CloudFormation是AWS提供的一個強大的基礎架構即代碼(Infrastructure as Code)服務,它可以讓我們以JSON或YAML格式定義AWS資源並自動化部署它們。然而,有時候在CloudFormation的 Stack 顯示為CREATE_COMPLETE時,實際上某些資源可能尚未完全部署完成,特別是當EC2實例需要執行一些長時間的初始化腳本時。這種情況下,就需要一種方法來通知CloudFormation,讓它知道部署的確已經完成,這就是CFN-Signal的用途所在。 CFN-Signal是一個工具,它可以發送通知給CloudFormation,告訴它特定資源的初始化過程已經完成。讓我們來看看如何在AWS CloudFormation template 中使用CFN-Signal來確保部署的完整性。 步驟一:安裝pip在EC2 首先,在EC2實例上安裝pip,這是Python的套件管理器。 使用以下命令來安裝pip: bash sudo apt update sudo apt install python3-pip -y 步驟二:安裝CFN-Signal 接下來,需要安裝CFN-Signal。使用pip來安裝它: bash sudo pip3 install cfn-signal 步驟三:發通知給CloudFormation 在部署腳本中,當初始化工作完成時,使用CFN-Signal向CloudFormation發送信號。例如,在User Data腳本中,可以添加類似以下的命令: bash #!/bin/bash   # Your initialization script goes here # Signal to CloudFormation that the resource is successfully initialized /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource MyEC2Instance 這將向CloudFormation發送一個信號,告訴它MyEC2Instance資源的初始化已經完成。請注意,`$?`是退出狀態,如果上一個命令成功執行,它將為