6 posts tagged with "GCP"

當環境中有多組 GCP 帳號要登入存取時，譬如一組個人帳號，一組 service account，這時後可以透過 gcloud 的一些指令才切換與檢視

$ gcloud config configurations list

NAME       IS_ACTIVE  ACCOUNT                                              PROJECT                COMPUTE_DEFAULT_ZONE  COMPUTE_DEFAULT_REGION
default    False      [email protected]                                   first-project
name2      False      [email protected]
name3      True       [email protected]

如果要切換可以使用

$ gcloud config configurations activate name2

進行切換，這時候 gcloud command 就可以轉移過去了。 如果有用 GKE 的，還要額外呼叫一次 gcloud container clusters update 去更新 KUBECONFIG

GCS 本身對於存放的資料有不同分類，包含

1. STANDARD
2. NEARLINE
3. COLDLINE
4. ARCHIVE

分類的設定可以從

1. 預設值 Storage class
2. 設定 Lifecycle Rule，針對超過一定天數的檔案自動調整不同的分類

這幾個分類對消費者來說最大的影響可能就是存取與維護成本 以Cloud Storage pricing來說

存放本身的價格就是 STANDARD > NEARLINE > COLDLINE > ARCHIVE

但是如果今天想要存取資料(Retrieval fees)來說則要特別注意 STANDARD 本身免費，後面三者價格依序提高，其中以 COLDLINE 來說是 $0.02 GB

因此若需要存取 GCS 的話，則特別要注意目前檔案的屬性以及存取量，然後評估一下可能的花費 若有需要大量長期存取的，記得要切換成 STANDARD 模式，若幾乎不存取的就直接往後搬移減少儲存花費。

GCP 的世界中透過 Cloud NAT 來處理對外流量，由該 NAT GW 進行 SNAT 的轉換。 之前遇到一個問題是某對外服務的連線會不定時 timeout 無法連線，輾轉各種測試最後終於發現問題出在 Cloud NAT 上

Cloud NAT 上有一個設定稱為 Port Reservation 該設定會影響 Cloud NAT 要如何幫後方所有流量進行 SNAT，要用哪個 Source IP 以及哪個 Source Port 去處理。

其中有一個設定是 "Minimum Ports per VM"，這個欄位的意思是每個 VM 上可以對相同目標 (IP + Port) 同時發起多少條連線 舉例來說，假設今天想要連接 1.2.3.4:2345 這個網站，且設定為 32，那就代表這個 VM 上最多只能有 32 條連線，超過的就會被 Cloud NAT 丟掉而無法處理，最後產生 timeout

如果今天 VM 規格夠大，上面部署 GKE 同時有多個相同副本的 Pod 同時運行，那就有可能會踩到這個數字導致連線 timeout，可以到 Cloud NAT 的設定將其調整，預設應該是 64。

另外 Cloud NAT 本身對外流量都會收費，要計算流量資訊需要到 VPC 去打開 Logging 紀錄，這個 Logging 也需要特別設定取樣頻率，因為會收費 所以設定完成後，就可以於 Cloud Logging 收到相關資訊，可以把 Logging 轉換為 Metrics 去計算流量的走向，譬如以 IP/hostname 為基準去分析到底流量都跑去那，再透過這個資訊來除錯省錢

GCP 提供 OS login 等方式可以讓使用者透過 gcloud compute ssh 等方式登入到沒有 public IP 的機器上，但是每次設定上總是卡各種權限 而預設的 IAM Roles 裡面又沒有相關的身份可以一次搞定，常常要到處找到底缺哪個角色 經過一番努力跟嘗試後，確認只要給予下列權限就可以執行 gcloud compute ssh

compute.instances.osLogin
compute.instances.setMetadata
compute.instances.use
iam.serviceAccounts.actAs
iap.tunnelInstances.accessViaIAP
networkmanagement.connectivitytests.create
serviceusage.services.enable

因此創立一個新角色給予上面的權限，然後再把該角色綁定到目標使用者或群組，應該就可以透過 gcloud compute ssh 到遠方機器了。

GCP CloudSQL 本身的收費機制常見取決於

1. 機器等級強度，若有開 HA 模式則價格兩倍
2. 硬碟使用量

其中 (1) 的主要是由 vCPU 與 Memory 的用量來決定價格，詳細資訊可以參閱網頁介紹

另外 CloudSQL 本身是可以直接升級機器強度的，可以手動也可以透過 Terraform 來管理，不過升級過程中 副會處於 downtime 不能存取階段，升級時間處決於當前機器的強度與資料量，短則一分鐘，長20分鐘都有可能。

另外硬碟使用量的部分有兩種設定機制

1. 固定硬碟用量
2. 動態調整用量，當硬碟用量超過 90% 以上後就會自動調整用量

另外硬碟用量也會有收費的問題，假如當硬碟用量清空想要縮小硬碟用量，這部分目前還沒有辦法操作，需要開 Support ticket 請 GCP 幫忙縮小硬碟空間。

透過基本的 GKE + Serviec + Ingress 部署網站後通常都沒有太多存取問題，但是對於公開服務這件事情就需要考量資安，所有網站是否都需要經過認證與授權才可以讓外部存取？ 有些第三方服務開源版本可能不方便銜接或是沒有實作這一塊，這時候可以透過 GCP 的 Identity-Aware Proxy(IAP) Gateway 快速搭建一個機制，所有存取該網站的人都會被導向 Google 登入，且只有符合設定 domain 的人登入後才可以存取網站內容。

流程需要

1. 到 OAuth 2.0 Consent 頁面那邊去創立一個物件，並且取得 client_id 以及 client_secret.
2. 產生一個 Secret 物件包含對應的 client_id 與 client_secret
3. 產生一個 BackendConfig 的物件，將上述的 secret 綁定到該 Backend 物件
4. 將 BackendConfig 與 Service 物件綁定

前三個步驟可以參考官網設定 Enabling IAP for GKE

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backend"}'
  name: dev-service
  namespace: dev
spec:
  ports:
    - name: http2
      port: 80
      protocol: TCP
      targetPort: 8080
    - name: https
      port: 443
      protocol: TCP
      targetPort: 8443
  selector:
    app: service
  sessionAffinity: None
  type: ClusterIP

一切設定完畢後，接下來還要到 GKE 那邊開啟 IAP 的設定，參考 Setting up IAP access