黑皮考町

  私有 GKE 叢集整合 ArgoCD 實現 GitOps 自動部署 前言 為了提升安全性, 企業通常會採用 Private GKE 的叢集架構, 只允許在內網裡存取 Control Plane, 在這種情況下, 若要部署資源到叢集裡, 除了額外再架一個跳板機使用 kubectl 去操作之外, 另一個方式是走 Pull-based 的 GitOps 流程, 安裝一個 Agent 在 GKE 叢集裡,  定時地去掃指定Git Repository 內的 k8s 資源檔, 並將差異同步到 GKE 叢集中 以下介紹如何使用 ArgoCD 來快速地實現以上的流程 Step 1. 安裝 ArgoCD $gcloud container clusters get-credentials cluster --zone us-central1 --project=stage $kubectl create ns argocd $kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml Step 2. Patch ArgoCD Server Service 指派外部 IP 因為在接下來的步驟會需要連線到 ArgoCD Server 上操作, 所以必須先  patch 一個 Load Balancer type 的 Service 給 ArgoCD Server 使它能對外溝通 $kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer","loadBalancerIP":"10.51.0.12"},"metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"}}}' 以上範例使用 Internal Load Balancer 的 Service, 

  快速建立私有 GCE Instance 並整合 Cloud NAT 前言 私有 GCE Instance 能夠減少被駭客攻擊的機會,  因為在做網路配置的時候, 不會特別分派外部 IP 給這類型的 VM, 所有存取 VM 的行為都必須走內網, 但也因為沒有對外的 IP, 所以 VM 裡也沒辦法透過網際網路去下載並且使用第三方的套件 解法： 整合 Cloud NAT 透過 Cloud NAT 位址轉譯的功能, 將 VM 的內部 IP 對應到一組共用的對外 IP 使用 Terraform 建立 VPC, Subnet, GCE VM variable "project" {   default = "test"    } variable "network_name" {   default = "net-123"    } variable "subnet_name" {   default = "subnet-123"    } resource "google_compute_network" "vpc_network" {   project                 = var.project   name                    = var.network_name   auto_create_subnetworks = false } resource "google_compute_subnetwork" "vpc_subnet" {   project                 = var.project   name          = var.subnet_name   ip_cidr_range = "10.51.0.0/23"   region        = "us-central1"   network       = google_compute_network.vpc_network.id } resource "google_service_account

  如何跨專案存取私有 GKE 叢集  在 GKE 的 Control Plane 沒有提供外部 IP  的情況下,  維運人員若想要操作 GKE  則必需走 VPN 的方式才能訪問到 Control Plane  的 API Server 以下示範, 如何在不同的專案底下建立跳板機跟 GKE 叢集,  並透過 VPN 的方式在跳板機上去操作另一個專案下的 GKE 叢集 在 Project A 建立 VPC #1 variable "gke_project" {   default = "prj-1" } variable "gke_network_name" {   default = "net-1" } variable "gke_subnet_name" {   default = "subnet-1" } resource "google_compute_network" "gke_vpc_network" {   project                 = var.gke_project   name                    = var.gke_network_name   auto_create_subnetworks = false } resource "google_compute_subnetwork" "gke_vpc_subnet" {   project                 = var.gke_project   name          = var.gke_subnet_name   ip_cidr_range = "10.51.0.0/23"   region        = "us-central1"   network       = google_compute_network.gke_vpc_network.id } 在 Project B 建立 VPC #2 v variable "proxy_project" {   default

 使用 Terraform + Slack + Cloud Function 快速建立簡易通知系統 前言 要設計一個通知系統, 一般都會需要考慮到前端, 後端, 以及後續部署維運相關的問題, 但其實想要快速建立通知系統並不難, 只要善用雲端資源, 十分鐘也能建立一個簡易的通知系統 以下示範, 如何使用 Slack 作為訊息輸出的前端, 以及整合 Cloud PubSub 和 Cloud Function 作為訊息處理的後端, 最後再以 Terraform 將所有元件的部署流程自動化, 使日後維運更加輕鬆簡易 前端 整合 Slack 時, 需要先取得 Webhook Token  有了 token 就能透過 Slack 的 API 將訊息打到指定的 Channel 中, 使用以下方式來測試 Webhook token 有沒有作用 測試 andy@host: curl -X POST --data-urlencode "payload={\"channel\": \"#etl_job\", \"username\": \"webhookbot\", \"text\": \"This is posted to # etl_job  and comes from a bot named webhookbot.\", \"icon_emoji\": \":ghost:\"}" https://hooks.slack.com/services/T02G1HSTG/AAA4M9NN095/1VDjE3453234292ZTF4IRDEv ok 後端 後端的部分會整合 Cloud PubSub 作為觸發 Cloud Function 以習訊息輸入的來源 Source Code const { IncomingWebhook } = require('@slack/webhook'); exports.handler= async (message, context) => {  const messageData = message.data    ? Buffer.from(mes

如何在 local 端使用 kubectl 操作 private GKE 叢集 Private GKE cluster set up with bastion vm   基於安全考量,  通常在創建 GKE 叢集時, 會選擇 Private Cluster 的部署方式, 將 Control Plan 藏在內網裡, 若想要在 local 端使用 kubectl 來操作 GKE 的話, 會須要一個跳板機(Bastion Host) 將請求 轉送給內網的 Control Plan, 架構如下 然而這個做法有個安全疑慮, 就是當對外 IP 不小心被洩露了, 駭客就能透過它連進跳板機來進行惡意的操作 比較好的做法是,  Cloud IAP + Private 的 Bastion Host  透過 IAP 的TCP 轉送功能, 就不需要分配對外 IP 給 Bastion Host 實際做法如下 環境建立 Step 1. 建立一個新的 Subnet 給 GKE Cluster 使用 gcloud compute networks create k8s-proxy \   --subnet-mode=custom \   --project=backend gcloud compute networks subnets create subnet-cluster \     --network=k8s-proxy \     --range=10.50.0.0/16 \     --region=us-central1 gcloud compute firewall-rules create k8s-proxy-ssh \     --network k8s-proxy \     --allow tcp:22 因為 Cloud IAP 會從  35.235.240.0/20 這個網段連進內網, 所以防火牆需要開放從從 35.235.240.0/20 過來的流量 gcloud compute firewall-rules create allow-ssh-ingress-from-iap \   --direction=INGRESS \   --action=allow \   --rules=tcp:22 \   --source-ranges=35.235.240.0/20