Google Kubernetes Engine में .NET Core ऐप्लिकेशन डिप्लॉय और अपडेट करें

1. खास जानकारी

Microsoft .NET Core, .NET का एक ओपन-सोर्स और क्रॉस-प्लैटफ़ॉर्म वर्शन है. यह कंटेनर में नेटिव तौर पर चल सकता है. .NET Core, GitHub पर उपलब्ध है. इसे Microsoft और .NET कम्यूनिटी मैनेज करती है. इस लैब में, कंटेनर में मौजूद .NET Core ऐप्लिकेशन को Google Kubernetes Engine (GKE) में डिप्लॉय किया जाता है.

इस लैब में, डेवलपमेंट के सामान्य पैटर्न का पालन किया जाता है. इसमें ऐप्लिकेशन को डेवलपर के लोकल एनवायरमेंट में डेवलप किया जाता है. इसके बाद, उन्हें प्रोडक्शन में डिप्लॉय किया जाता है. लैब के पहले हिस्से में, .NET Core ऐप्लिकेशन के उदाहरण की पुष्टि की जाती है. इसके लिए, Cloud Shell में चल रहे कंटेनर का इस्तेमाल किया जाता है. पुष्टि हो जाने के बाद, ऐप्लिकेशन को GKE का इस्तेमाल करके Kubernetes पर डिप्लॉय किया जाता है. इस लैब में, GKE क्लस्टर बनाने का तरीका बताया गया है.

लैब के दूसरे हिस्से में, ऐप्लिकेशन में एक छोटा सा बदलाव किया जाता है. इससे उस कंटेनर का होस्टनेम दिखता है जो ऐप्लिकेशन के उस इंस्टेंस को चला रहा है. इसके बाद, अपडेट किए गए ऐप्लिकेशन की पुष्टि क्लाउड शेल में की जाती है. साथ ही, डिप्लॉयमेंट को नए वर्शन का इस्तेमाल करने के लिए अपडेट किया जाता है. इस इलस्ट्रेशन में, इस लैब में की जाने वाली गतिविधियों का क्रम दिखाया गया है:

डेमो सीक्वेंस डायग्राम

लागत

अगर इस लैब को ठीक उसी तरह से चलाया जाता है जैसा कि लिखा गया है, तो इन सेवाओं के लिए सामान्य शुल्क लागू होगा

2. सेटअप और ज़रूरी शर्तें

ज़रूरी शर्तें

इस लैब को पूरा करने के लिए, Google Cloud खाता और प्रोजेक्ट होना ज़रूरी है. नया प्रोजेक्ट बनाने के बारे में ज़्यादा जानकारी के लिए, यह कोडलैब देखें.

इस लैब में, Cloud Shell में चल रहे Docker का इस्तेमाल किया जाता है. यह Google Cloud Console के ज़रिए उपलब्ध होता है. इसमें gcloud और Docker जैसे कई काम के टूल पहले से कॉन्फ़िगर किए गए होते हैं. Cloud Shell को ऐक्सेस करने का तरीका यहां बताया गया है. सबसे ऊपर दाईं ओर मौजूद Cloud Shell आइकॉन पर क्लिक करें, ताकि यह कंसोल विंडो के सबसे नीचे वाले पैन में दिखे.

Cloud Shell

GKE क्लस्टर के लिए कॉन्फ़िगरेशन के अन्य विकल्प (ज़रूरी नहीं)

इस लैब के लिए, Kubernetes क्लस्टर की ज़रूरत होती है. अगले सेक्शन में, सामान्य कॉन्फ़िगरेशन वाला GKE क्लस्टर बनाया गया है. इस सेक्शन में, कुछ gcloud कमांड दिखाई गई हैं. ये कमांड, GKE का इस्तेमाल करके Kubernetes क्लस्टर बनाने के दौरान, कॉन्फ़िगरेशन के अन्य विकल्प उपलब्ध कराती हैं. उदाहरण के लिए, यहां दिए गए निर्देशों का इस्तेमाल करके अलग-अलग मशीन टाइप, ज़ोन, और जीपीयू (ऐक्सलरेटर) की पहचान की जा सकती है.

इस कमांड gcloud compute machine-types list की मदद से, मशीन टाइप की सूची बनाएं
इस निर्देश gcloud compute accelerator-types list का इस्तेमाल करके, जीपीयू की सूची बनाएं
इस निर्देश gcloud compute zones list की मदद से, कंप्यूट ज़ोन की सूची पाएं
किसी भी gcloud कमांड के बारे में मदद पाना gcloud container clusters --help
- उदाहरण के लिए, इससे Kubernetes क्लस्टर बनाने के बारे में जानकारी मिलती है gcloud container clusters create --help

GKE के लिए कॉन्फ़िगरेशन के सभी विकल्पों की पूरी सूची देखने के लिए, यह दस्तावेज़ देखें

Kubernetes क्लस्टर बनाने की तैयारी करना

Cloud Shell में, कुछ एनवायरमेंट वैरिएबल सेट करना और gcloud क्लाइंट को कॉन्फ़िगर करना ज़रूरी है. इसके लिए, यहां दी गई कमांड का इस्तेमाल करें.

export PROJECT_ID=YOUR_PROJECT_ID
export DEFAULT_ZONE=us-central1-c

gcloud config set project ${PROJECT_ID}
gcloud config set compute/zone ${DEFAULT_ZONE}

GKE क्लस्टर बनाना

यह लैब, .NET Core ऐप्लिकेशन को Kubernetes पर डिप्लॉय करता है. इसलिए, क्लस्टर बनाना ज़रूरी है. GKE का इस्तेमाल करके, Google Cloud में नया Kubernetes क्लस्टर बनाने के लिए, यहां दिया गया निर्देश इस्तेमाल करें.

gcloud container clusters create dotnet-cluster \
  --zone ${DEFAULT_ZONE} \
  --num-nodes=1 \
  --node-locations=${DEFAULT_ZONE},us-central1-b \
  --enable-stackdriver-kubernetes \
  --machine-type=n1-standard-1 \
  --workload-pool=${PROJECT_ID}.svc.id.goog \
  --enable-ip-alias

--num-nodes, हर ज़ोन में जोड़े जाने वाले नोड की संख्या है. इसे बाद में बढ़ाया जा सकता है
--node-locations, ज़ोन की कॉमा लगाकर अलग की गई सूची है. इस मामले में, ऊपर दिए गए एनवायरमेंट वैरिएबल और us-central1-b में पहचाने गए ज़ोन का इस्तेमाल किया जाता है
- ध्यान दें: इस सूची में डुप्लीकेट नाम नहीं हो सकते
--workload-pool वर्कलोड आइडेंटिटी सेट अप करता है, ताकि GKE वर्कलोड, Google Cloud की सेवाओं को ऐक्सेस कर सकें

क्लस्टर बनाते समय, यह मैसेज दिखता है

Creating cluster dotnet-cluster in us-central1-b... Cluster is being deployed...⠼

kubectl को कॉन्फ़िगर करना

kubectl CLI, Kubernetes क्लस्टर के साथ इंटरैक्ट करने का मुख्य तरीका है. अभी बनाए गए नए क्लस्टर के साथ इसका इस्तेमाल करने के लिए, इसे क्लस्टर के ख़िलाफ़ पुष्टि करने के लिए कॉन्फ़िगर करना होगा. इसके लिए, यह कमांड इस्तेमाल करें.

$ gcloud container clusters get-credentials dotnet-cluster --zone ${DEFAULT_ZONE}
Fetching cluster endpoint and auth data.
kubeconfig entry generated for dotnet-cluster.

अब क्लस्टर से इंटरैक्ट करने के लिए, kubectl का इस्तेमाल किया जा सकता है.

$ kubectl get nodes
NAME                                            STATUS   ROLES    AGE     VERSION
gke-dotnet-cluster-default-pool-02c9dcb9-fgxj   Ready    <none>   2m15s   v1.16.13-gke.401
gke-dotnet-cluster-default-pool-ed09d7b7-xdx9   Ready    <none>   2m24s   v1.16.13-gke.401

3. स्थानीय तौर पर जांच करें और पुष्टि करें कि सुविधा आपकी उम्मीद के मुताबिक काम कर रही है

यह लैब, Docker Hub पर मौजूद आधिकारिक .NET रिपॉज़िटरी से इन कंटेनर इमेज का इस्तेमाल करती है.

फ़ंक्शन की पुष्टि करने के लिए, कंटेनर को लोकल लेवल पर चलाएं

क्लाउड शेल में, पुष्टि करें कि Docker ठीक से काम कर रहा है. साथ ही, .NET कंटेनर उम्मीद के मुताबिक काम कर रहा है. इसके लिए, यहां दिया गया Docker कमांड चलाएं:

$ docker run --rm mcr.microsoft.com/dotnet/samples

      Hello from .NET!
      __________________
                        \
                        \
                            ....
                            ....'
                            ....
                          ..........
                      .............'..'..
                  ................'..'.....
                .......'..........'..'..'....
                ........'..........'..'..'.....
              .'....'..'..........'..'.......'.
              .'..................'...   ......
              .  ......'.........         .....
              .                           ......
              ..    .            ..        ......
            ....       .                 .......
            ......  .......          ............
              ................  ......................
              ........................'................
            ......................'..'......    .......
          .........................'..'.....       .......
      ........    ..'.............'..'....      ..........
    ..'..'...      ...............'.......      ..........
    ...'......     ...... ..........  ......         .......
  ...........   .......              ........        ......
  .......        '...'.'.              '.'.'.'         ....
  .......       .....'..               ..'.....
    ..       ..........               ..'........
            ............               ..............
          .............               '..............
          ...........'..              .'.'............
        ...............              .'.'.............
        .............'..               ..'..'...........
        ...............                 .'..............
        .........                        ..............
          .....
  
Environment:
.NET 5.0.1-servicing.20575.16
Linux 5.4.58-07649-ge120df5deade #1 SMP PREEMPT Wed Aug 26 04:56:33 PDT 2020

वेब ऐप्लिकेशन के काम करने की पुष्टि करना

क्लाउड शेल में, सैंपल वेब ऐप्लिकेशन की पुष्टि भी की जा सकती है. यहां दी गई Docker रन कमांड, एक नया कंटेनर बनाती है. यह 80 पोर्ट को दिखाता है और उसे localhost पोर्ट 8080 पर मैप करता है. ध्यान रखें कि इस मामले में localhost क्लाउड शेल में है.

$ docker run -it --rm -p 8080:80 --name aspnetcore_sample mcr.microsoft.com/dotnet/samples:aspnetapp
warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
      Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
      No XML encryptor configured. Key {64a3ed06-35f7-4d95-9554-8efd38f8b5d3} may be persisted to storage in unencrypted form.
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://[::]:80
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /app

यह एक वेब ऐप्लिकेशन है. इसलिए, इसे वेब ब्राउज़र में देखा और इसकी पुष्टि की जानी चाहिए. अगले सेक्शन में, Web Preview का इस्तेमाल करके क्लाउड शेल में ऐसा करने का तरीका बताया गया है.

4. "वेब प्रीव्यू" का इस्तेमाल करके, Cloud Shell से सेवाओं को ऐक्सेस करना

Cloud Shell में वेब प्रीव्यू की सुविधा मिलती है. इसकी मदद से, ब्राउज़र का इस्तेमाल करके Cloud Shell इंस्टेंस में चल रही प्रोसेस के साथ इंटरैक्ट किया जा सकता है.

Cloud Shell में ऐप्लिकेशन देखने के लिए, "वेब प्रीव्यू" का इस्तेमाल करना

Cloud Shell में, वेब प्रीव्यू बटन पर क्लिक करें. इसके बाद, "पोर्ट 8080 पर झलक देखें" (या वेब प्रीव्यू के लिए सेट किया गया कोई भी पोर्ट) चुनें.

Cloud Shell

इससे एक ब्राउज़र विंडो खुलेगी, जिसमें इस तरह का पता होगा:

https://8080-cs-754738286554-default.us-central1.cloudshell.dev/?authuser=0

वेब प्रीव्यू का इस्तेमाल करके, .NET के सैंपल ऐप्लिकेशन को देखना

पिछले चरण में शुरू किए गए सैंपल ऐप्लिकेशन को अब वेब प्रीव्यू शुरू करके और दिए गए यूआरएल को लोड करके देखा जा सकता है. यह कुछ ऐसी नज़र आनी चाहिए:

.NET ऐप्लिकेशन V1 का स्क्रीनशॉट

5. Kubernetes पर डिप्लॉय करें

YAML फ़ाइल बनाना और उसे लागू करना

अगले चरण में, आपको एक YAML फ़ाइल की ज़रूरत होगी. इसमें दो Kubernetes रिसॉर्स, डिप्लॉयमेंट, और सर्विस के बारे में जानकारी दी गई हो. Cloud Shell में dotnet-app.yaml नाम की फ़ाइल बनाएं और उसमें यह कॉन्टेंट जोड़ें.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dotnet-deployment
  labels:
    app: dotnetapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: dotnetapp
  template:
    metadata:
      labels:
        app: dotnetapp
    spec:
      containers:
      - name: dotnet
        image: mcr.microsoft.com/dotnet/samples:aspnetapp
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: dotnet-service
spec:
    selector:
      app: dotnetapp
    ports:
      - protocol: TCP
        port: 8080
        targetPort: 80

अब इस फ़ाइल को Kubernetes पर लागू करने के लिए, kubectl का इस्तेमाल करें.

$ kubectl apply -f dotnet-app.yaml
deployment.apps/dotnet-deployment created
service/dotnet-service created

उन मैसेज पर ध्यान दें जिनसे पता चलता है कि आपके हिसाब से संसाधन बना दिए गए हैं.

नतीजे के तौर पर मिले संसाधनों को एक्सप्लोर करना

ऊपर बनाए गए संसाधनों की जांच करने के लिए, हम kubectl CLI का इस्तेमाल कर सकते हैं. सबसे पहले, डिप्लॉयमेंट के संसाधनों को देखते हैं और पुष्टि करते हैं कि नया डिप्लॉयमेंट मौजूद है.

$ kubectl get deployment
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
dotnet-deployment   3/3     3            3           80s

इसके बाद, ReplicaSet देखें. ऊपर दिए गए डिप्लॉयमेंट से बनाया गया एक ReplicaSet होना चाहिए.

$ kubectl get replicaset
NAME                           DESIRED   CURRENT   READY   AGE
dotnet-deployment-5c9d4cc4b9   3         3         3       111s

आखिर में, पॉड देखें. डप्लॉयमेंट से पता चलता है कि तीन इंस्टेंस होने चाहिए. नीचे दिए गए कमांड से पता चलना चाहिए कि तीन इंस्टेंस मौजूद हैं. -o wide विकल्प जोड़ा गया है, ताकि उन नोड को दिखाया जा सके जहां ये इंस्टेंस चल रहे हैं.

$ kubectl get pod -o wide
NAME                                 READY   STATUS    RESTARTS   AGE     IP          NODE                                            NOMINATED NODE   READINESS GATES
dotnet-deployment-5c9d4cc4b9-cspqd   1/1     Running   0          2m25s   10.16.0.8   gke-dotnet-cluster-default-pool-ed09d7b7-xdx9   <none>           <none>
dotnet-deployment-5c9d4cc4b9-httw6   1/1     Running   0          2m25s   10.16.1.7   gke-dotnet-cluster-default-pool-02c9dcb9-fgxj   <none>           <none>
dotnet-deployment-5c9d4cc4b9-vvdln   1/1     Running   0          2m25s   10.16.0.7   gke-dotnet-cluster-default-pool-ed09d7b7-xdx9   <none>           <none>

सेवा संसाधन की समीक्षा करना

Kubernetes में Service रिसॉर्स, लोड बैलेंसर होता है. एंडपॉइंट, पॉड पर मौजूद लेबल के हिसाब से तय किए जाते हैं. इस तरह, ऊपर दी गई kubectl scale deployment कार्रवाई के ज़रिए डिप्लॉयमेंट में नए पॉड जोड़े जाने के तुरंत बाद, ये पॉड उस सेवा के ज़रिए हैंडल किए जा रहे अनुरोधों के लिए उपलब्ध हो जाते हैं.

नीचे दिए गए कमांड से, सेवा का संसाधन दिखना चाहिए.

$ kubectl get svc
NAME             TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
dotnet-service   ClusterIP   10.20.9.124   <none>        8080/TCP   2m50s
...

इस सेवा के बारे में ज़्यादा जानकारी देखने के लिए, यह कमांड इस्तेमाल करें.

$ kubectl describe svc dotnet-service
Name:              dotnet-service
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          app=dotnetapp
Type:              ClusterIP
IP:                10.20.9.124
Port:              <unset>  8080/TCP
TargetPort:        80/TCP
Endpoints:         10.16.0.7:80,10.16.0.8:80,10.16.1.7:80
Session Affinity:  None
Events:            <none>

ध्यान दें कि सेवा का टाइप ClusterIP है. इसका मतलब है कि क्लस्टर में मौजूद कोई भी पॉड, सर्विस के नाम dotnet-service को उसके आईपी पते में बदल सकता है. सेवा को भेजे गए अनुरोधों को सभी इंस्टेंस (पॉड) के बीच लोड बैलेंस किया जाएगा. ऊपर दी गई Endpoints वैल्यू से पता चलता है कि इस सेवा के लिए फ़िलहाल कौनसे पॉड उपलब्ध हैं. इनकी तुलना, ऊपर दिए गए पॉड के आईपी पतों से करें.

चल रहे ऐप्लिकेशन की पुष्टि करना

इस समय ऐप्लिकेशन लाइव हो जाता है और उपयोगकर्ता के अनुरोधों को पूरा करने के लिए तैयार हो जाता है. इसे ऐक्सेस करने के लिए, प्रॉक्सी का इस्तेमाल करें. नीचे दी गई कमांड, एक लोकल प्रॉक्सी बनाती है. यह प्रॉक्सी, पोर्ट 8080 पर अनुरोध स्वीकार करती है और उन्हें Kubernetes क्लस्टर को पास करती है.

$ kubectl proxy --port 8080
Starting to serve on 127.0.0.1:8080

अब वेब ऐप्लिकेशन को ऐक्सेस करने के लिए, Cloud Shell में वेब प्रीव्यू का इस्तेमाल करें.

वेब प्रीव्यू की सुविधा से जनरेट हुए यूआरएल में यह जोड़ें: /api/v1/namespaces/default/services/dotnet-service:8080/proxy/. इसके बाद, यह कुछ ऐसा दिखेगा:

https://8080-cs-473655782854-default.us-central1.cloudshell.dev/api/v1/namespaces/default/services/dotnet-service:8080/proxy/

Google Kubernetes Engine पर .NET Core ऐप्लिकेशन डिप्लॉय करने के लिए बधाई. इसके बाद, हम ऐप्लिकेशन में बदलाव करेंगे और उसे फिर से डिप्लॉय करेंगे.

6. ऐप्लिकेशन में बदलाव करना

इस सेक्शन में, ऐप्लिकेशन में बदलाव किया जाएगा, ताकि उस होस्ट को दिखाया जा सके जिस पर इंस्टेंस चल रहा है. इससे यह पुष्टि की जा सकेगी कि लोड बैलेंसिंग काम कर रही है और उपलब्ध पॉड उम्मीद के मुताबिक जवाब दे रहे हैं.

सोर्स कोड पाना

git clone https://github.com/dotnet/dotnet-docker.git
cd dotnet-docker/samples/aspnetapp/

होस्ट का नाम शामिल करने के लिए, ऐप्लिकेशन को अपडेट करें

vi aspnetapp/Pages/Index.cshtml

    <tr>
        <td>Host</td>
        <td>@Environment.MachineName</td>
    </tr>

नई कंटेनर इमेज बनाना और उसे स्थानीय तौर पर टेस्ट करना

अपडेट किए गए कोड की मदद से, नई कंटेनर इमेज बनाएं.

docker build --pull -t aspnetapp:alpine -f Dockerfile.alpine-x64 .

पहले की तरह, नए ऐप्लिकेशन को स्थानीय तौर पर टेस्ट करें

$ docker run --rm -it -p 8080:80 aspnetapp:alpine
warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
      Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
      No XML encryptor configured. Key {f71feb13-8eae-4552-b4f2-654435fff7f8} may be persisted to storage in unencrypted form.
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://[::]:80
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /app

पहले की तरह, ऐप्लिकेशन को वेब प्रीव्यू का इस्तेमाल करके ऐक्सेस किया जा सकता है. इस बार Host पैरामीटर दिखना चाहिए, जैसा कि यहां दिखाया गया है:

Cloud Shell

क्लाउड शेल में एक नया टैब खोलें और docker ps चलाकर देखें कि कंटेनर आईडी, ऊपर दिखाई गई होस्ट वैल्यू से मेल खाता है या नहीं.

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                  NAMES
ab85ce11aecd        aspnetapp:alpine    "./aspnetapp"       2 minutes ago       Up 2 minutes        0.0.0.0:8080->80/tcp   relaxed_northcutt

इमेज को टैग करें और पुश करें, ताकि यह Kubernetes के लिए उपलब्ध हो

Kubernetes को इमेज को पुल करने के लिए, उसे टैग और पुश करना होगा. सबसे पहले, कंटेनर इमेज की सूची बनाएं और अपनी पसंद की इमेज चुनें.

$ docker image list
REPOSITORY                                         TAG                 IMAGE ID            CREATED             SIZE
aspnetapp                                          alpine              95b4267bb6d0        6 days ago          110MB

इसके बाद, उस इमेज को टैग करें और उसे Google Container Registry पर पुश करें. ऊपर दिए गए IMAGE ID का इस्तेमाल करके, यह इस तरह दिखेगा

docker tag 95b4267bb6d0 gcr.io/${PROJECT_ID}/aspnetapp:alpine
docker push gcr.io/${PROJECT_ID}/aspnetapp:alpine

7. अपडेट किए गए ऐप्लिकेशन को फिर से डिप्लॉय करें

YAML फ़ाइल में बदलाव करना

उस डायरेक्ट्री पर वापस जाएं जहां फ़ाइल dotnet-app.yaml सेव की गई है. YAML फ़ाइल में यह लाइन ढूंढें

        image: mcr.microsoft.com/dotnet/core/samples:aspnetapp

इसे बदलकर, उस कंटेनर इमेज का रेफ़रंस देना होगा जिसे ऊपर gcr.io में बनाया और पुश किया गया था.

        image: gcr.io/PROJECT_ID/aspnetapp:alpine

PROJECT_ID का इस्तेमाल करने के लिए, इसमें बदलाव करना न भूलें. यह इस तरह दिखना चाहिए

        image: gcr.io/myproject/aspnetapp:alpine

अपडेट की गई YAML फ़ाइल लागू करना

$ kubectl apply -f dotnet-app.yaml
deployment.apps/dotnet-deployment configured
service/dotnet-service unchanged

ध्यान दें कि डिप्लॉयमेंट रिसॉर्स में अपडेट किया गया डेटा दिखता है, जबकि सर्विस रिसॉर्स में कोई बदलाव नहीं दिखता. अपडेट किए गए पॉड को पहले की तरह kubectl get pod कमांड से देखा जा सकता है. हालांकि, इस बार हम -w जोड़ेंगे. इससे, सभी बदलावों को रीयल टाइम में देखा जा सकेगा.

$ kubectl get pod -w
NAME                                 READY   STATUS              RESTARTS   AGE
dotnet-deployment-5c9d4cc4b9-cspqd   1/1     Running             0          34m
dotnet-deployment-5c9d4cc4b9-httw6   1/1     Running             0          34m
dotnet-deployment-5c9d4cc4b9-vvdln   1/1     Running             0          34m
dotnet-deployment-85f6446977-tmbdq   0/1     ContainerCreating   0          4s
dotnet-deployment-85f6446977-tmbdq   1/1     Running             0          5s
dotnet-deployment-5c9d4cc4b9-vvdln   1/1     Terminating         0          34m
dotnet-deployment-85f6446977-lcc58   0/1     Pending             0          0s
dotnet-deployment-85f6446977-lcc58   0/1     Pending             0          0s
dotnet-deployment-85f6446977-lcc58   0/1     ContainerCreating   0          0s
dotnet-deployment-5c9d4cc4b9-vvdln   0/1     Terminating         0          34m
dotnet-deployment-85f6446977-lcc58   1/1     Running             0          6s
dotnet-deployment-5c9d4cc4b9-cspqd   1/1     Terminating         0          34m
dotnet-deployment-85f6446977-hw24v   0/1     Pending             0          0s
dotnet-deployment-85f6446977-hw24v   0/1     Pending             0          0s
dotnet-deployment-5c9d4cc4b9-cspqd   0/1     Terminating         0          34m
dotnet-deployment-5c9d4cc4b9-vvdln   0/1     Terminating         0          34m
dotnet-deployment-5c9d4cc4b9-vvdln   0/1     Terminating         0          34m
dotnet-deployment-85f6446977-hw24v   0/1     Pending             0          2s
dotnet-deployment-85f6446977-hw24v   0/1     ContainerCreating   0          2s
dotnet-deployment-5c9d4cc4b9-cspqd   0/1     Terminating         0          34m
dotnet-deployment-5c9d4cc4b9-cspqd   0/1     Terminating         0          34m
dotnet-deployment-85f6446977-hw24v   1/1     Running             0          3s
dotnet-deployment-5c9d4cc4b9-httw6   1/1     Terminating         0          34m
dotnet-deployment-5c9d4cc4b9-httw6   0/1     Terminating         0          34m

ऊपर दिए गए आउटपुट में, रोलिंग अपडेट को होते हुए दिखाया गया है. सबसे पहले, नए कंटेनर शुरू किए जाते हैं. जब वे चालू हो जाते हैं, तब पुराने कंटेनर बंद कर दिए जाते हैं.

चल रहे ऐप्लिकेशन की पुष्टि करना

इस समय ऐप्लिकेशन अपडेट हो जाता है और उपयोगकर्ता के अनुरोधों को पूरा करने के लिए तैयार हो जाता है. पहले की तरह, इसे प्रॉक्सी का इस्तेमाल करके ऐक्सेस किया जा सकता है.

$ kubectl proxy --port 8080
Starting to serve on 127.0.0.1:8080

https://8080-cs-473655782854-default.us-central1.cloudshell.dev/api/v1/namespaces/default/services/dotnet-service:8080/proxy/

पुष्टि करें कि Kubernetes सेवा लोड डिस्ट्रिब्यूट कर रही है

इस यूआरएल को कई बार रीफ़्रेश करें. ध्यान दें कि जैसे-जैसे अनुरोधों को सेवा के ज़रिए अलग-अलग पॉड में लोड बैलेंस किया जाता है वैसे-वैसे होस्ट बदलती है. यह देखने के लिए कि सभी पॉड को ट्रैफ़िक मिल रहा है, होस्ट वैल्यू की तुलना ऊपर दी गई पॉड की सूची से करें.

इंस्टेंस को स्केल अप करना

Kubernetes में ऐप्लिकेशन को स्केल करना आसान है. इस निर्देश से, ऐप्लिकेशन के डिप्लॉयमेंट को छह इंस्टेंस तक बढ़ाया जा सकेगा.

$ kubectl scale deployment dotnet-deployment --replicas 6
deployment.apps/dotnet-deployment scaled

इस कमांड की मदद से, नए पॉड और उनकी मौजूदा स्थिति देखी जा सकती है

kubectl get pod -w

ध्यान दें कि उसी ब्राउज़र विंडो को रीफ़्रेश करने पर, यह दिखता है कि ट्रैफ़िक को अब सभी नए पॉड में बराबर बांटा जा रहा है.

8. बधाई हो!

इस लैब में, .NET Core के सैंपल वेब ऐप्लिकेशन की पुष्टि डेवलपर एनवायरमेंट में की गई. इसके बाद, इसे GKE का इस्तेमाल करके Kubernetes पर डिप्लॉय किया गया. इसके बाद, ऐप्लिकेशन में बदलाव किया गया, ताकि उस कंटेनर का होस्टनेम दिखाया जा सके जिसमें वह चल रहा था. इसके बाद, Kubernetes डिप्लॉयमेंट को नए वर्शन में अपडेट किया गया. साथ ही, ऐप्लिकेशन को स्केल अप किया गया, ताकि यह दिखाया जा सके कि लोड को अतिरिक्त इंस्टेंस में कैसे डिस्ट्रिब्यूट किया जाता है.

.NET और Kubernetes के बारे में ज़्यादा जानने के लिए, इन ट्यूटोरियल को देखें. ये लैब, इस लैब में सीखी गई बातों पर आधारित हैं. इनमें, बेहतर राउटिंग और रेज़िलियंस पैटर्न के लिए, Istio Service Mesh को पेश किया गया है.

9. व्यवस्थित करें

अनचाहे शुल्क से बचने के लिए, इस लैब में बनाए गए क्लस्टर और कंटेनर इमेज को मिटाने के लिए, इन कमांड का इस्तेमाल करें.

gcloud container clusters delete dotnet-cluster --zone ${DEFAULT_ZONE}
gcloud container images delete gcr.io/${PROJECT_ID}/aspnetapp:alpine