1. खास जानकारी
Microsoft .NET Core, .NET का एक ओपन-सोर्स और क्रॉस-प्लैटफ़ॉर्म वर्शन है. इसे कंटेनर में नेटिव तौर पर चलाया जा सकता है. .NET Core, GitHub पर उपलब्ध है. इसे Microsoft और .NET कम्यूनिटी मैनेज करती है. इस लैब में, कंटेनर में बदले गए .NET Core ऐप्लिकेशन को Google Kubernetes Engine (GKE) में डिप्लॉय किया जाता है.
यह लैब, डेवलपमेंट के सामान्य पैटर्न का इस्तेमाल करती है. इसमें ऐप्लिकेशन को डेवलपर के लोकल एनवायरमेंट में डेवलप किया जाता है और फिर प्रोडक्शन में डिप्लॉय किया जाता है. लैब के पहले हिस्से में, Cloud Shell में चल रहे कंटेनर का इस्तेमाल करके, .NET कोर ऐप्लिकेशन के उदाहरण की पुष्टि की जाती है. पुष्टि होने के बाद, ऐप्लिकेशन को GKE का इस्तेमाल करके Kubernetes पर डिप्लॉय किया जाता है. इस लैब में, GKE क्लस्टर बनाने का तरीका बताया गया है.
लैब के दूसरे हिस्से में, ऐप्लिकेशन में एक छोटा सा बदलाव किया जाता है. इससे उस कंटेनर का होस्टनेम दिखता है जिसमें ऐप्लिकेशन का इंस्टेंस चल रहा है. इसके बाद, अपडेट किए गए ऐप्लिकेशन की पुष्टि Cloud Shell में की जाती है. साथ ही, नए वर्शन का इस्तेमाल करने के लिए डिप्लॉयमेंट को अपडेट किया जाता है. यहां दिए गए इलस्ट्रेशन में, इस लैब में की जाने वाली गतिविधियों का क्रम दिखाया गया है:
लागत
अगर इस लैब को ठीक वैसे ही चलाया जाता है जैसा कि लिखा गया है, तो इन सेवाओं के लिए सामान्य शुल्क लागू होंगे
2. सेटअप और ज़रूरी शर्तें
ज़रूरी शर्तें
इस लैब को पूरा करने के लिए, आपके पास Google Cloud खाता और प्रोजेक्ट होना चाहिए. नया प्रोजेक्ट बनाने के तरीके के बारे में ज़्यादा जानकारी के लिए, यह कोडलैब देखें.
इस लैब में, Cloud Shell में चल रहे Docker का इस्तेमाल किया जाता है. यह Google Cloud Console के ज़रिए उपलब्ध होता है. साथ ही, इसमें gcloud और Docker जैसे कई काम के टूल पहले से कॉन्फ़िगर किए होते हैं. 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
- उदाहरण के लिए, इसमें Kubernetes क्लस्टर बनाने के बारे में जानकारी दी गई है
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, Workload Identity को सेट अप करता है, ताकि GKE वर्कलोड, Google Cloud की सेवाओं को ऐक्सेस कर सकें
क्लस्टर बनने के दौरान, यह जानकारी दिखती है
Creating cluster dotnet-cluster in us-central1-b... Cluster is being deployed...⠼
kubectl को कॉन्फ़िगर करना
kubectl सीएलआई, 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 रिपॉज़िटरी से, इन कंटेनर इमेज का इस्तेमाल करती है.
फ़ंक्शन की पुष्टि करने के लिए, कंटेनर को लोकल लेवल पर चलाना
Cloud Shell में, पुष्टि करें कि 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
वेब ऐप्लिकेशन की मुख्य सुविधाओं और उनके काम करने के तरीके की पुष्टि करना
Cloud Shell में, सैंपल के तौर पर बनाए गए वेब ऐप्लिकेशन की पुष्टि भी की जा सकती है. नीचे दिया गया Docker रन कमांड, एक नया कंटेनर बनाता है. यह कंटेनर, पोर्ट 80 को एक्सपोज़ करता है और उसे localhost पोर्ट 8080 पर मैप करता है. ध्यान रखें कि इस मामले में, localhost Cloud Shell में है.
$ 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
यह एक वेब ऐप्लिकेशन है. इसलिए, इसे वेब ब्राउज़र में देखना और इसकी पुष्टि करना ज़रूरी है. अगले सेक्शन में, वेब की झलक का इस्तेमाल करके, Cloud Shell में ऐसा करने का तरीका बताया गया है.
4. "वेब की झलक" का इस्तेमाल करके, Cloud Shell से सेवाओं को ऐक्सेस करना
Cloud Shell में वेब की झलक देखने की सुविधा मिलती है. इसकी मदद से, Cloud Shell इंस्टेंस में चल रही प्रोसेस के साथ इंटरैक्ट करने के लिए, ब्राउज़र का इस्तेमाल किया जा सकता है.
Cloud Shell में ऐप्लिकेशन देखने के लिए, "वेब की झलक" का इस्तेमाल करना
Cloud Shell में, वेब की झलक वाले बटन पर क्लिक करें और "पोर्ट 8080 पर झलक देखें" चुनें. इसके अलावा, वह पोर्ट चुनें जिस पर वेब की झलक देखने की सुविधा सेट की गई है.
इससे एक ब्राउज़र विंडो खुलेगी, जिसमें इस तरह का पता होगा:
https://8080-cs-754738286554-default.us-central1.cloudshell.dev/
वेब की झलक का इस्तेमाल करके, .NET सैंपल ऐप्लिकेशन देखना
पिछले चरण में शुरू किए गए सैंपल के तौर पर मिले ऐप्लिकेशन को अब वेब की झलक शुरू करके और दिए गए यूआरएल को लोड करके देखा जा सकता है. यह कुछ ऐसी नज़र आनी चाहिए:
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 सीएलआई का इस्तेमाल कर सकते हैं. सबसे पहले, डिप्लॉयमेंट के संसाधनों को देखें और पुष्टि करें कि नया डिप्लॉयमेंट वहां मौजूद है.
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
dotnet-deployment 3/3 3 3 80s
इसके बाद, ReplicaSets पर नज़र डालें. ऊपर दिए गए डिप्लॉयमेंट से एक 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 में सेवा संसाधन, एक लोड बैलेंसर होता है. एंडपॉइंट, पॉड पर मौजूद लेबल से तय होते हैं. इस तरह, ऊपर दिए गए 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
पहले की तरह ही, ऐप्लिकेशन को वेब की झलक का इस्तेमाल करके ऐक्सेस किया जा सकता है. इस बार होस्ट पैरामीटर दिखना चाहिए, जैसा कि यहां दिखाया गया है:
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 में पुश करें. ऊपर दिए गए इमेज आईडी का इस्तेमाल करने पर, यह कुछ ऐसा दिखेगा
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
वेब ऐप्लिकेशन को ऐक्सेस करने के लिए, अब 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/
पुष्टि करना कि 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 सर्विस मेश को पेश किया गया है. इससे, ज़्यादा बेहतर रूटिंग और रिज़िलियंस पैटर्न मिलते हैं.
9. व्यवस्थित करें
इस लैब में बनाए गए क्लस्टर और कंटेनर इमेज को मिटाने के लिए, इन निर्देशों का इस्तेमाल करें. इससे आपको अनचाहे शुल्क नहीं देने पड़ेंगे.
gcloud container clusters delete dotnet-cluster --zone ${DEFAULT_ZONE}
gcloud container images delete gcr.io/${PROJECT_ID}/aspnetapp:alpine