Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Implementasi referensi load balancing Lapisan 7 NGINX

Google Distributed Cloud (GDC) dengan air gap menyediakan load balancer Lapisan 4 (L4) terkelola bawaan, tetapi banyak aplikasi perusahaan memerlukan kemampuan Lapisan 7 (L7) lanjutan, seperti pemilihan rute berbasis host, pengelolaan TLS terpusat, dan pemisahan traffic yang kompleks. Secara historis, hal ini dilakukan menggunakan Ingress API, yang kini dianggap sebagai fitur yang dibekukan dalam komunitas Kubernetes.

Arsitektur referensi ini menyediakan solusi load balancing Lapisan 7 yang dikelola sendiri. Dengan men-deploy pengontrol open source NGINX Gateway Fabric yang populer di Cluster Standar GDC, pelanggan dapat merutekan traffic L7 ke lingkungan hybrid dengan lancar. Arsitektur ini menggunakan TLS Termination (HTTPRoute) untuk merutekan traffic berdasarkan Server Name Indication (SNI) ke pod dalam container bawaan dan aplikasi yang dihosting di Virtual Machine eksternal.

Arsitektur

Diagram arsitektur untuk load balancing Lapisan 7 NGINX di GDC dengan air gap.

Komponen utama solusi ini meliputi:

Klien: Entity yang memulai permintaan HTTPS untuk berinteraksi dengan aplikasi.
Cluster Standar GDC: GDC menyediakan cara bawaan untuk membuat Cluster Vanilla Kubernetes. Dalam solusi ini, cluster akan menghosting LB L7 dan pengontrolnya, beserta workload dan layanan headless untuk VM eksternal
Load Balancer L4 GDC: Load balancer L4 bawaan yang berfungsi sebagai titik entri, mendistribusikan traffic TCP/443 langsung ke Pod Kubernetes yang menjalankan pengontrol Gateway.
Gateway Controller: Operator NGINX yang berjalan di Cluster Standar. Gateway API memantau resource Gateway API (seperti Gateway dan HTTPRoute) dan memperbarui proxy yang mendasarinya secara dinamis. Nginx Gateway Fabric akan digunakan untuk solusi ini.
Gateway (dengan HTTPRoute): Resource Kubernetes standar yang menentukan port pemantauan fisik (443) dan aturan pemilihan rute host berbasis SNI dengan TLS Termination.
Workload dalam Container (Pod): Deployment Kubernetes standar yang diekspos secara internal dengan Service Kubernetes reguler.
Workload Berbasis VM (Eksternal): Workload yang dihosting di VM eksternal pada jaringan project, yang diekspos ke proxy dengan Service Kubernetes headless dan endpoint kustom yang berisi IP langsung VM.
Harbor Registry: Container Registry pribadi yang digunakan untuk menyimpan dan menyajikan image proxy dan aplikasi di lingkungan air-gapped.

Di Cluster Standard, Anda akan membuat empat namespace:

Namespace nginx-gateway yang menghosting resource Nginx Gateway Fabric:
Namespace load-balancer yang menghosting resource Gateway:
Namespace vm-app menghosting IP VM eksternal vm-app, layanan headless, EndpointSlice yang mengarah ke IP eksternal, dan HTTPRoute untuk Gateway:
Namespace hello-app menghosting Deployment, Service, HTTPRoute, dan Gateway untuk workload container demo:

Sebelum memulai

Sebelum men-deploy solusi ini, pastikan Anda telah memenuhi prasyarat berikut:

Software yang diperlukan: helm, docker, kubectl

Login CLI dan penyiapan lokal: Download gdcloud CLI dari konsol GDC dan siapkan lingkungan Anda secara lokal.

export USER_NAME="USER_NAME"
export PROJECT_ID="PROJECT_ID"
export ZONE="ZONE"
export ORG_NAME="ORG_NAME"
export GDC_URL="GDC_URL"

gdcloud components install gdcloud-k8s-auth-plugin

gdcloud config set core/organization_console_url \
  https://console.$ORG_NAME.$ZONE.$GDC_URL
gdcloud config set core/zone $ZONE
gdcloud config set core/project ${PROJECT_ID}

gdcloud auth login # use --login-config-cert option in case of TLS error

Penyiapan Project: Buat project di lingkungan GDC dengan air gap untuk menyimpan resource.
```
gdcloud projects create $PROJECT_ID
```

Peran IAM: Berikan peran Cluster Admin dan Standard Cluster Admin kepada pengguna Anda untuk mengelola resource Kubernetes, dan peran Harbor Instance Admin untuk mengirim image.

# Grant standard cluster and cluster admin roles
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=cluster-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=standard-cluster-admin

# Grant Harbor instance admin role
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=harbor-instance-admin

Membuat cluster standar

Bagian ini memandu Anda dalam proses menyiapkan cluster Kubernetes standar dalam lingkungan GDC dengan air gap. Cluster standar menyediakan fondasi yang fleksibel dan tangguh untuk men-deploy berbagai workload, termasuk Nginx Gateway Controller, dan aplikasi kustom Anda. Langkah-langkah berikut akan memastikan cluster Anda dikonfigurasi dengan benar dan dapat diakses untuk deployment berikutnya.

Identifikasi jenis image virtual machine yang tersedia dengan menjalankan:
```
gdcloud compute machine-types list
```
Pilih jenis mesin yang sesuai untuk worker node cluster Anda. Untuk tutorial ini, sebaiknya gunakan jenis mesin dengan minimal 4 vCPU.
```
export MACHINE_TYPE="MACHINE_TYPE"
```

Dapatkan kubeconfig server API pengelolaan dan tetapkan alias:

export CLUSTER_NAME="CLUSTER_NAME"

KUBECONFIG=kubeconfig-admin.yaml gdcloud clusters \
  get-credentials ${ORG_NAME}-admin

alias km="kubectl --kubeconfig kubeconfig-admin.yaml"

Buat cluster standar dengan 2 worker node:

km create -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: ${CLUSTER_NAME}
  namespace: ${PROJECT_ID}
spec:
  nodePools:
  - machineTypeName: ${MACHINE_TYPE}
    nodeCount: 2
    name: ${CLUSTER_NAME}-node-pool
EOF

Untuk mengetahui detail selengkapnya tentang opsi yang tersedia, lihat dokumentasi.

Pembuatan cluster Standard dapat memerlukan waktu hingga 60 menit. Untuk memeriksa status, gunakan perintah berikut:

km get clusters/${CLUSTER_NAME} \
  -n ${PROJECT_ID} \
  --watch

Setelah cluster siap, output akan menampilkan status Running, seperti ini:

NAME         STATE     K8S VERSION
my-cluster   Running   1.30.12-gke.300

Setelah cluster siap, ambil kredensialnya:

KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \
  get-credentials ${CLUSTER_NAME} \
  --standard \
  --project ${PROJECT_ID} \
  --zone ${ZONE}

Buat alias agar perintah kubectl lebih ringkas di bagian selanjutnya dalam panduan ini. Alias ini akan digunakan untuk berinteraksi dengan cluster standar:
```
alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
```
Buat namespace untuk pengontrol, aplikasi dalam container demo "hello-app", dan aplikasi demo berbasis VM:
```
kk create namespace load-balancer
kk create namespace hello-app
kk create namespace vm-app
```

Membuat dan mengintegrasikan Harbor Registry

Harbor adalah registry image container dengan dukungan bawaan di GDC dengan air gap. Bagian ini memandu Anda melakukan langkah-langkah untuk mengintegrasikan Harbor Registry dengan cluster standar, termasuk mengonfigurasi kredensial dan secret untuk mengaktifkan pengambilan dan pengiriman image yang aman.

Buat instance Harbor di project Anda.
Buat project Harbor di instance Harbor Anda.

Menetapkan variabel lingkungan:

export HARBOR_INSTANCE_NAME="HARBOR_INSTANCE_NAME"
export HARBOR_INSTANCE_URL="HARBOR_INSTANCE_URL"
export HARBOR_PROJECT="HARBOR_INSTANCE_PROJECT"
export IMAGE_PULL_SECRET_NAME="harbor-secret"

docker --config=./docker login ${HARBOR_INSTANCE_URL}

Buat secret di cluster standar:

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n load-balancer

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n hello-app

Men-deploy aplikasi demo dalam container

Bagian ini menjelaskan deployment aplikasi dalam container demo (hello-app) dalam cluster Kubernetes GDC dengan air gap Anda. Anda akan membuat resource Deployment dan Service Kubernetes yang diperlukan untuk menjalankan hello-app dan mengeksposnya secara internal dalam cluster, sehingga menyiapkannya untuk akses menggunakan load balancer L7.

Upload contoh image untuk aplikasi dalam container demo ke Harbor:

docker pull gcr.io/google-samples/hello-app:1.0 \
  --platform linux/amd64
docker tag gcr.io/google-samples/hello-app:1.0 \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0

Deploy manifes berikut di cluster standar:

cat << EOF > hello-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
  namespace: hello-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-server
        image: ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: ${IMAGE_PULL_SECRET_NAME}
---
apiVersion: v1
kind: Service
metadata:
  name: hello-app
  namespace: hello-app
spec:
  type: ClusterIP
  selector:
    app: hello-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
EOF

kk apply -f hello-app.yaml

Kemudian, pastikan deployment dan layanan sudah ada:

kk get svc,deploy -n hello-app

Men-deploy aplikasi demo di VM

Bagian ini menjelaskan deployment aplikasi demo dalam virtual machine (VM) di luar cluster Kubernetes Anda. Dengan menyiapkan server HTTP di VM, Anda akan menyimulasikan aplikasi eksternal yang dapat diekspos oleh load balancer, yang menunjukkan kemampuannya untuk mengelola traffic ke resource di dalam dan di luar cluster.

Pertama, buat VM untuk aplikasi demo

Buka konsol GDC di browser web Anda.
Pilih project yang sama dengan tempat Anda membuat cluster Kubernetes standar.
Buka menu, lalu klik Virtual machines.
Klik Create Instance.
Beri nama VM vm-workload. Image 2 vCPU sudah cukup untuk contoh ini.
Untuk boot disk image, pilih distribusi Ubuntu 22.04, yang dilengkapi dengan Python yang telah diinstal sebelumnya.
Klik Create.
Tunggu beberapa menit hingga VM siap.
Buat koneksi SSH ke VM:
1. Di konsol GDC, klik VM.
2. Klik Connect with SSH.

Setelah Anda terhubung ke konsol SSH, jalankan perintah berikut:

mkdir ~/simple-server
cd ~/simple-server
echo 'Welcome to my VM!' > index.html
python3 -m http.server --bind 0.0.0.0 8080 &

Untuk merutekan traffic ke VM, buat Service headless (tanpa pemilih). Alamat ini akan dipetakan secara manual ke alamat IP internal VM menggunakan resource EndpointSlice.

kk apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: vm-app-svc
  namespace: vm-app
spec:
  ports:
  - protocol: TCP
    port: 443
    targetPort: 443
EOF

Dapatkan alamat IP VM vm-workload dengan menjalankan

gdcloud compute instances list --project ${PROJECT_ID} \
  | grep workload-vm | awk '{print $3}'

Output-nya adalah alamat IP VM yang akan diperlukan untuk menyiapkan resource EndpointSlice.

Buat resource EndpointSlice yang akan terhubung ke Service tanpa pemilih VM-app dan alamatkan IP VM yang akan menjadi tujuan perutean traffic.

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: vm-app-endpoints
  namespace: vm-app
  labels:
    kubernetes.io/service-name: vm-app-svc
addressType: IPv4
ports:
  - port: 8080
endpoints:
  - addresses:
    - "VM_IP"
    conditions:
      ready: true

Membuat sertifikat yang ditandatangani sendiri

Bagian ini memandu Anda dalam proses pembuatan sertifikat TLS yang ditandatangani sendiri untuk aplikasi Anda. Panduan ini menggunakan sertifikat yang ditandatangani sendiri untuk kemudahan, tetapi di lingkungan produksi, Anda harus menggunakan sertifikat tingkat produksi, seperti yang dijelaskan dalam Opsional: Menggunakan sertifikat siap produksi. Sertifikat ini sangat penting untuk mengaktifkan penghentian HTTPS di Gateway Nginx, sehingga memastikan komunikasi terenkripsi antara klien dan load balancer untuk workload berbasis container dan VM.

Buat sertifikat untuk aplikasi dalam container:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-containerized.key \
  -out tls-containerized.crt \
  -subj "/CN=k8s-app.example.com" \
  -days 365

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

Buat sertifikat untuk aplikasi VM:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-vm.key \
  -out tls-vm.crt \
  -subj "/CN=vm-app.example.com" \
  -days 365

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Men-deploy NGINX

Bagian ini menguraikan langkah-langkah untuk men-deploy Nginx Gateway Controller, termasuk menginstal Gateway API Custom Resource Definitions (CRD), menyiapkan Nginx Gateway Fabric menggunakan Helm, dan memverifikasi penginstalan dalam cluster standar Anda. Tindakan ini akan menyiapkan infrastruktur untuk perutean Lapisan 7 lanjutan.

Menginstal CRD Gateway API

Gateway API memerlukan Definisi Resource Kustom (CRD) untuk diinstal di cluster sebelum men-deploy pengontrol. Kita akan menggunakan definisi resource kustom (CRD) eksperimental resmi dari project Gateway API (versi 1.2.0 digunakan untuk panduan ini).

Instal CRD eksperimental:

kk apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/experimental-install.yaml

Pastikan CRD berhasil diinstal dengan menjalankan kk get crd gateways.gateway.networking.k8s.io.

Menginstal NGINX Gateway Fabric

Deploy pengontrol NGINX Gateway Fabric menggunakan Helm. Pengontrol ini akan memantau resource Gateway API dan mengonfigurasi NGINX untuk menangani traffic.

Tetapkan tag image NGINX:

helm template nfg oci://ghcr.io/nginx/charts/nginx-gateway-fabric | grep "image:" # get the tag of the nginx-gateway-fabric (in following case 2.4.2)

export NGINX_TAG="2.4.2"

Tarik image NGINX Gateway Fabric dan NGINX, lalu kirim ke registry Harbor Anda:

docker pull ghcr.io/nginx/nginx-gateway-fabric:${NGINX_TAG}
docker tag ghcr.io/nginx/nginx-gateway-fabric:${NGINX_TAG} \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx-gateway-fabric:${NGINX_TAG}
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx-gateway-fabric:${NGINX_TAG}

docker pull nginx:1.27.3
docker tag nginx:1.27.3 \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx:1.27.3
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx:1.27.3

Buat namespace nginx-gateway dan tambahkan secret pull image Harbor:

kk create namespace nginx-gateway

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n nginx-gateway

Deploy NGINX Gateway Fabric dengan Helm, yang mengarah ke image di registry Harbor Anda:

KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml helm upgrade --install ngf \
  oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
  --create-namespace -n nginx-gateway \
  --set nginxGateway.image.tag="${NGINX_TAG}" \
  --set nginxGateway.image.repository="${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx-gateway-fabric" \
  --set nginx.image.repository="${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/nginx" \
  --set nginxGateway.serviceAccount.imagePullSecret="${IMAGE_PULL_SECRET_NAME}" \
  --set nginx.imagePullSecret="${IMAGE_PULL_SECRET_NAME}"

Deployment Kubernetes menarik image dengan aman dari Harbor menggunakan secret yang disediakan (${IMAGE_PULL_SECRET_NAME}), yang berisi kredensial akun robot Harbor.

Pastikan resource GatewayClass diterima:
```
kk get gatewayclass
```
Anda akan melihat nginx tercantum dengan ACCEPTED = True.

Membuat instance Gateway

Tentukan instance load balancer logis yang memproses port 443. Kita akan mengonfigurasinya untuk mode Terminate, yang berarti Gateway akan melakukan TLS termination dan mendekripsi traffic sebelum meneruskannya.

Buat dan terapkan gateway.yaml:

cat << EOF > gateway.yaml 
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: load-balancer
spec:
  gatewayClassName: nginx
  listeners:
  - name: https-k8s-workload
    hostname: "k8s-app.example.com"
    port: 443
    protocol: HTTPS
    allowedRoutes: 
      namespaces: 
        from: All
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: tls-containerized 
  - name: https-vm-workload
    hostname: "vm-app.example.com"
    port: 443
    protocol: HTTPS
    allowedRoutes: 
      namespaces: 
        from: All
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: tls-vm 
EOF

kk apply -f gateway.yaml

Pastikan Gateway berhasil di-deploy dengan memeriksa apakah PROGRAMMED adalah True:

kk get gateway my-gateway --n load-balancer

Pastikan load balancer L4 GDC terkelola telah di-deploy sebagai Service bersama Gateway

kk get services -n load-balancer

Pastikan layanan Nginx telah dibuat dan dikonfigurasi, output-nya akan terlihat seperti ini:

NAME               TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)         AGE
my-gateway-nginx   LoadBalancer   10.252.19.148   10.200.32.43   443:30649/TCP   45h

Menentukan logika perutean L7 (HTTPRoute)

Ikat HTTPRoute ke Gateway Anda untuk menentukan cara traffic harus didistribusikan berdasarkan nama host (SNI) yang diminta.

Buat dan terapkan routing.yaml:

cat << EOF > routing.yaml 
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: k8s-http-route
  namespace: hello-app
spec:
  parentRefs:
  - name: my-gateway 
    namespace: load-balancer
  hostnames:
  - "k8s-app.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: hello-app 
      namespace: hello-app
      port: 80          
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: vm-http-route
  namespace: vm-app
spec:
  parentRefs:
  - name: my-gateway
    namespace: load-balancer
  hostnames:
  - "vm-app.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: vm-app-svc  
      namespace: vm-app
      port: 443       
EOF

kk apply -f routing.yaml

Mengambil IP load balancer

Jalankan perintah untuk mendapatkan IP Load Balancer Nginx

kk get services/my-gateway-nginx \
  -n load-balancer \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Hal ini akan diperlukan saat memverifikasi akses ke aplikasi. Ini akan disebut sebagai LOAD_BALANCER_IP.

Membuat VM klien

Ikuti langkah-langkah untuk membuat VM klien

Buka konsol GDC di browser web Anda.
Buka menu, lalu klik Virtual machines.
Klik Create Instance.
Buat VM bernama client, pilih jenis mesin kecil, dan pilih Rocky Linux atau Ubuntu, yang dilengkapi dengan curl yang telah diinstal sebelumnya.
Klik Create.
Tunggu beberapa menit hingga VM siap.
Setelah VM siap, buat koneksi SSH ke VM:
1. Di konsol GDC, klik VM.
2. Klik Connect with SSH.

Memverifikasi akses dan perutean

Untuk menguji pemilihan rute, jalankan perintah curl dari VM klien Anda. Anda dapat terhubung ke kedua aplikasi menggunakan nama host yang ditentukan dengan alamat IP load balancer.

Dengan meneruskan flag --resolve di curl, Anda dapat memaksa nama domain untuk di-resolve ke alamat IP Load Balancer L4 GDC dengan air gap. Perhatikan bahwa kita meneruskan flag -k untuk memercayai sertifikat yang ditandatangani sendiri.

Uji aplikasi dalam container Kubernetes:

curl -k --resolve k8s-app.example.com:443:$LOAD_BALANCER_IP https://k8s-app.example.com -v

Menguji Aplikasi VM Eksternal:

curl -k --resolve vm-app.example.com:443:$LOAD_BALANCER_IP https://vm-app.example.com -v

Jika dikonfigurasi dengan benar, pengontrol Gateway akan berfungsi dengan lancar sebagai TLS terminator dan meneruskan traffic ke tujuan.

Opsional: Menggunakan sertifikat siap produksi

Bagian ini membahas cara memanfaatkan CA Service GDC dengan air gap untuk membuat Root Certificate Authority (CA) pribadi, menerbitkan sertifikat yang ditandatangani untuk workload Anda, serta mengamankan update cluster standar dan VM klien GDC dengan air gap Anda.

Bagian ini menguraikan cara menggunakan CA Service GDC dengan air gap untuk membuat Root Certificate Authority (CA) pribadi dan menerbitkan sertifikat yang valid untuk aplikasi Anda. Dengan menginstal Root CA ini di VM klien, Anda dapat memverifikasi bahwa TLS termination berfungsi lancar dengan sertifikat tepercaya, tanpa perlu mengabaikan peringatan SSL (misalnya, menggunakan curl -k).

Memberikan izin yang diperlukan dan mendapatkan kredensial

Untuk mengelola CA Service dan menerbitkan sertifikat, pengguna Anda memerlukan peran IAM yang sesuai dalam project.

Berikan peran certificate-authority-service-admin dan certificate-requester:

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-authority-service-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-requester

Dapatkan kredensial server API pengelolaan:

gdcloud clusters get-credentials ${ORG_NAME}-admin

Membuat root CA

Anda akan membuat Certificate Authority di server API pengelolaan dalam namespace project Anda.

Terapkan resource CertificateAuthority:

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  name: my-root-ca
  namespace: ${PROJECT_ID}
spec:
  caProfile:
    commonName: "My Root CA"
    duration: 87600h # 10 years
    keyAlgorithm: RSA_2048
    maxChainLength: 1
  caType: ROOT
  keyLocation: HSM
  rotationPolicy:
    cronTime: 0 0 1 1 *
EOF

km -n ${PROJECT_ID} get \
certificateauthority.pki.security.gdc.goog/my-root-ca -ojson \
| jq -r '
.status.conditions[] | select( .type as $id | "Ready" | index($id)) .status'

Menerbitkan dan men-deploy sertifikat

Setelah CA siap, Anda akan meminta sertifikat untuk aplikasi dalam container dan aplikasi berbasis VM. Permintaan ini terjadi di server API pengelolaan, dan kunci yang dihasilkan harus dipindahkan ke cluster standar Anda.

Buat permintaan untuk kedua domain:

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-containerized-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "k8s-app.example.com"
      dnsNames:
      - "k8s-app.example.com"
  signedCertificateSecret: tls-containerized-signed
---
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-vm-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "vm-app.example.com"
      dnsNames:
      - "vm-app.example.com"
  signedCertificateSecret: tls-vm-signed
EOF

Tunggu beberapa saat hingga sertifikat diterbitkan. Anda dapat memverifikasi bahwa cluster tersebut siap saat kondisi Ready bernilai True:

km get certificaterequests -n ${PROJECT_ID}

Mengupdate cluster standar

Jika Anda mengikuti bagian sebelumnya dari panduan ini, Anda memiliki secret yang ditandatangani sendiri di cluster standar. Anda harus menghapusnya sebelum membuat versi baru yang ditandatangani:

kk delete secret tls-containerized -n load-balancer
kk delete secret tls-vm -n load-balancer

kk delete secret tls-containerized -n hello-app
kk delete secret tls-vm -n vm-app

Sekarang, ekstrak sertifikat yang ditandatangani dari server API pengelolaan dan buat secret baru di cluster standar.

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-containerized.key

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-vm.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-vm.key

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Secret baru akan diperoleh secara otomatis dan dimuat ulang oleh load balancer.

Mengonfigurasi kepercayaan klien

Untuk memverifikasi penyiapan, Anda harus memberi tahu VM klien untuk memercayai root CA baru Anda.

Ekstrak sertifikat CA root ke file:

km get secret -n ${PROJECT_ID} my-root-ca-secret \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > my-root-ca.crt

Transfer sertifikat ke VM klien Anda. (Anda dapat menyalin konten my-root-ca.crt dan menempelkannya ke file di VM klien).

Di VM klien, update trust store.

Jika VM client adalah Ubuntu:

sudo cp my-root-ca.crt /usr/local/share/ca-certificates/
sudo chmod 644 /usr/local/share/ca-certificates/my-root-ca.crt
sudo update-ca-certificates

Jika VM client adalah Rocky Linux:

sudo cp my-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Memverifikasi akses

Anda kini dapat mengakses aplikasi menggunakan curl tanpa flag -k. Koneksi akan sepenuhnya dipercaya.