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) air-gapped menyediakan load balancer Layer 4 (L4) terkelola bawaan, tetapi banyak aplikasi perusahaan memerlukan kemampuan Layer 7 (L7) lanjutan, seperti perutean berbasis host, pengelolaan TLS terpusat, dan pemisahan traffic yang kompleks. Secara historis, hal ini dicapai menggunakan Ingress API, yang kini dianggap tidak memiliki fitur baru di komunitas Kubernetes.

Arsitektur referensi ini menyediakan solusi load balancing Layer 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 Penghentian TLS (HTTPRoute) untuk merutekan traffic berdasarkan Indikasi Nama Server (SNI) ke pod dan aplikasi dalam container bawaan yang dihosting di Mesin Virtual eksternal.

Arsitektur

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

Komponen utama solusi ini mencakup:

Klien: Entitas yang memulai permintaan HTTPS untuk berinteraksi dengan aplikasi.
Cluster Standar GDC: GDC menyediakan cara bawaan untuk membuat Cluster Kubernetes Vanilla. 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.
Pengontrol Gateway: Operator NGINX yang berjalan di Cluster Standar. Pengontrol ini memantau resource Gateway API (seperti Gateway dan HTTPRoute) serta memperbarui proxy yang mendasarinya secara dinamis. Nginx Gateway Fabric akan digunakan untuk solusi ini.
Gateway (dengan HTTPRoute): Resource Kubernetes standar yang menentukan port listening fisik (443) dan aturan perutean host berbasis SNI dengan Penghentian TLS.
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 di jaringan project, diekspos ke proxy dengan Service Kubernetes headless dan endpoint kustom yang berisi IP langsung VM.
Harbor Registry: Registry container pribadi yang digunakan untuk menyimpan dan menayangkan image proxy dan aplikasi di lingkungan air-gapped.

Di Cluster Standar, Anda 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 GDCH_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 Anda 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, serta 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 kuat untuk men-deploy berbagai workload, termasuk Pengontrol Gateway Nginx, dan aplikasi kustom Anda. Langkah-langkah berikut akan memastikan cluster Anda dikonfigurasi dengan benar dan dapat diakses untuk deployment berikutnya.

Identifikasi jenis image mesin virtual yang tersedia dengan menjalankan:
```
gdcloud compute machine-types list
```
Pilih jenis mesin yang sesuai untuk node pekerja 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 node pekerja:

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 standar 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 Berjalan, 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 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 melalui 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 instance di project Anda.
Buat project Harbor di instance Harbor Anda.

Tetapkan 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 dalam container demo

Bagian ini menjelaskan deployment aplikasi dalam container demo (hello-app) dalam cluster Kubernetes GDC dengan air gap Anda. Anda akan membuat resource Deployment dan Layanan Kubernetes yang diperlukan untuk menjalankan hello-app dan mengeksposnya secara internal dalam cluster, sehingga mempersiapkannya 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 ada:

kk get svc,deploy -n hello-app

Men-deploy aplikasi demo di VM

Bagian ini menjelaskan deployment aplikasi demo dalam mesin virtual (VM) di luar cluster Kubernetes Anda. Dengan menyiapkan server HTTP di VM, Anda akan menyimulasikan aplikasi eksternal yang dapat diekspos oleh load balancer, sehingga 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 VM nama vm-workload. Image 2 vCPU sudah cukup untuk contoh ini.
Untuk image boot disk, pilih distribusi Ubuntu 22.04, yang sudah 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 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 Layanan headless (tanpa pemilih). Layanan 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 Layanan tanpa pemilih VM-app dan menangani IP VM tempat traffic harus dirutekan.

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 membuat 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 dalam container dan berbasis 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 Pengontrol Gateway Nginx, termasuk menginstal Definisi Resource Kustom (CRD) Gateway API, menyiapkan Nginx Gateway Fabric menggunakan Helm, dan memverifikasi penginstalan dalam cluster standar Anda. Hal ini akan menyiapkan infrastruktur untuk perutean Layer 7 lanjutan.

Menginstal CRD Gateway API

Gateway API memerlukan Definisi Resource Kustom (CRD) yang 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

Verifikasi bahwa 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 dari Harbor dengan aman menggunakan secret yang disediakan (${IMAGE_PULL_SECRET_NAME}), yang berisi kredensial akun robot Harbor.

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

Membuat instance Gateway

Tentukan instance load balancer logis yang memproses permintaan di port 443. Kita akan mengonfigurasinya untuk mode Terminate, yang berarti Gateway akan melakukan penghentian TLS 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

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

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

Verifikasi bahwa load balancer L4 GDC terkelola telah di-deploy sebagai Layanan bersama Gateway

kk get services -n load-balancer

Pastikan layanan Nginx 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 yang diminta (SNI).

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}'

IP ini akan diperlukan saat memverifikasi akses ke aplikasi. IP 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 sudah 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 perutean, 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 Anda. Perhatikan bahwa kita meneruskan flag -k untuk mempercayai 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

Uji 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 bertindak sebagai penghentian TLS dan meneruskan traffic ke tujuan dengan lancar.

Opsional: Menggunakan sertifikat siap produksi

Bagian ini membahas cara memanfaatkan Layanan CA GDC dengan air gap untuk membuat root certificate authority pribadi, menerbitkan sertifikat yang ditandatangani untuk workload Anda, dan mengupdate cluster standar dan VM klien GDC dengan air gap Anda dengan aman.

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

Memberikan izin yang diperlukan dan mendapatkan kredensial

Untuk mengelola Layanan CA 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 CA root

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 sertifikat siap saat kondisi Siap adalah Benar:

km get certificaterequests -n ${PROJECT_ID}

Mengupdate cluster standar

Jika Anda mengikuti bagian sebelumnya dari panduan ini, Anda akan 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 diperbarui oleh load balancer.

Mengonfigurasi kepercayaan klien

Untuk memverifikasi penyiapan, Anda harus memberi tahu VM klien untuk mempercayai CA root 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, perbarui 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

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