نشر تطبيق .NET Core وتحديثه في Google Kubernetes Engine

1. نظرة عامة

‫‎.NET Core من Microsoft هو إصدار مفتوح المصدر ومتوافق مع أنظمة التشغيل المختلفة من ‎ .NET، ويمكن تشغيله في الحاويات. يتوفّر .NET Core على GitHub وتتولّى Microsoft ومنتدى .NET صيانته. ينشر هذا المختبر تطبيق .NET Core محفوظًا في حاوية إلى Google Kubernetes Engine (GKE).

يتّبع هذا الدرس التطبيقي نمط تطوير نموذجيًا يتم فيه تطوير التطبيقات في بيئة محلية للمطوّرين ثم يتم نشرها في مرحلة الإنتاج. في الجزء الأول من الدرس التطبيقي، يتم التحقّق من صحة مثال على تطبيق .NET Core باستخدام حاوية تعمل في Cloud Shell. وبعد التحقّق من صحة التطبيق، يتم نشره على Kubernetes باستخدام GKE. يتضمّن المختبر خطوات إنشاء مجموعة GKE.

في الجزء الثاني من المختبر، يتم إجراء تغيير بسيط على التطبيق الذي يعرض اسم مضيف الحاوية التي يتم تشغيل مثيل التطبيق هذا فيها. بعد ذلك، يتم التحقّق من صحة التطبيق المعدَّل في Cloud Shell ويتم تعديل عملية النشر لاستخدام الإصدار الجديد. يوضّح الرسم التوضيحي التالي تسلسل الأنشطة في هذا المختبر:

مخطط التسلسل للعرض التوضيحي

التكاليف

إذا نفّذت هذا المختبر كما هو مكتوب تمامًا، سيتم تطبيق التكاليف العادية للخدمات التالية

2. الإعداد والمتطلبات

المتطلبات الأساسية

لإكمال هذا الدرس التطبيقي، يجب أن يكون لديك حساب ومشروع على Google Cloud. للحصول على تعليمات أكثر تفصيلاً حول كيفية إنشاء مشروع جديد، يُرجى الرجوع إلى هذا الدرس التطبيقي حول الترميز.

يستخدم هذا المختبر Docker الذي يعمل في Cloud Shell، وهو متاح من خلال Google Cloud Console ويأتي مضبوطًا مسبقًا باستخدام العديد من الأدوات المفيدة، مثل gcloud وDocker. في ما يلي كيفية الوصول إلى Cloud Shell. انقر على رمز Cloud Shell في أعلى اليسار لعرضه في اللوحة السفلية من نافذة وحدة التحكّم.

Cloud Shell

خيارات الضبط البديلة لمجموعة GKE (اختيارية)

يتطلّب هذا المختبر مجموعة Kubernetes. في القسم التالي، سيتم إنشاء مجموعة GKE بإعداد بسيط. يعرض هذا القسم بعض أوامر gcloud التي توفّر خيارات إعداد بديلة يمكن استخدامها عند إنشاء مجموعة Kubernetes باستخدام GKE. على سبيل المثال، باستخدام الأوامر أدناه، يمكن تحديد أنواع الأجهزة والمناطق وحتى وحدات معالجة الرسومات (المسرّعات) المختلفة.

يمكنك إدراج أنواع الأجهزة باستخدام الأمر 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، من الضروري إنشاء مجموعة. استخدِم الأمر التالي لإنشاء مجموعة Kubernetes جديدة في Google Cloud باستخدام GKE.

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 واجهة سطر الأوامر هي الطريقة الأساسية للتفاعل مع مجموعة 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- الاختبار محليًا والتأكّد من الوظائف المطلوبة

تستخدم هذه الميزة التجريبية صور الحاويات التالية من مستودع ‎ .NET الرسمي على Docker hub.

تشغيل الحاوية محليًا للتحقّق من الوظائف

في 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 run أدناه حاوية جديدة تعرض المنفذ 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 (أو أي منفذ تم ضبط "معاينة الويب" على استخدامه).

Cloud Shell

سيؤدي ذلك إلى فتح نافذة متصفّح تحتوي على عنوان على النحو التالي:

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

عرض نموذج تطبيق ‎ .NET باستخدام "معاينة الويب"

يمكن الآن عرض نموذج التطبيق الذي تم تشغيله في الخطوة الأخيرة من خلال بدء "معاينة الويب" وتحميل عنوان URL المقدَّم. من المفترض أن تظهر بشكلٍ مشابه لما يلي:

لقطة شاشة للإصدار الأول من تطبيق ‎ .NET

5- النشر على Kubernetes

إنشاء ملف YAML وتطبيقه

تتطلّب الخطوة التالية ملف YAML يصف موردَين من موارد Kubernetes، وهما Deployment وService. أنشئ ملفًا باسم dotnet-app.yaml في Cloud Shell وأضِف إليه المحتوى التالي.

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

الآن، استخدِم kubectl لتطبيق هذا الملف على Kubernetes.

$ 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 يعمل كموازنة تحميل. يتم تحديد نقاط النهاية من خلال التصنيفات على Pods. بهذه الطريقة، بمجرد إضافة وحدات Pod جديدة إلى عملية النشر من خلال عملية kubectl scale deployment أعلاه، تصبح وحدات Pod الناتجة متاحة على الفور للطلبات التي تعالجها تلك الخدمة.

من المفترض أن يعرض الأمر التالي مورد الخدمة.

$ 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. وهذا يعني أنّه يمكن لأي Pod داخل المجموعة مطابقة اسم الخدمة، dotnet-service مع عنوان IP الخاص بها. سيتم توزيع الطلبات المُرسَلة إلى الخدمة بالتساوي على جميع المثيلات (Pods). تعرض قيمة Endpoints أعلاه عناوين IP الخاصة بحاويات Pods المتاحة حاليًا لهذه الخدمة. قارِن هذه العناوين بعناوين IP الخاصة بالحاويات التي تم عرضها أعلاه.

التحقّق من التطبيق الذي يتم تشغيله

في هذه المرحلة، يكون التطبيق متاحًا وجاهزًا لتلقّي طلبات المستخدمين. للوصول إلى هذه الخدمة، استخدِم خادمًا وكيلاً. ينشئ الأمر التالي خادم وكيل محليًا يقبل الطلبات على المنفذ 8080 ويمررها إلى مجموعة Kubernetes.

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

يمكنك الآن استخدام "معاينة الويب" في Cloud Shell للوصول إلى تطبيق الويب.

أضِف ما يلي إلى عنوان URL الذي تم إنشاؤه بواسطة "معاينة الويب": /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/

تهانينا على نشر تطبيق ‎ .NET Core على Google Kubernetes Engine. بعد ذلك، سنجري تغييرًا على التطبيق ونعيد نشره.

6. تعديل التطبيق

في هذا القسم، سيتم تعديل التطبيق لعرض المضيف الذي يتم تشغيل الجهاز الافتراضي عليه. سيؤدي ذلك إلى إمكانية التأكّد من أنّ موازنة التحميل تعمل وأنّ وحدات Pod المتاحة تستجيب على النحو المتوقّع.

الحصول على رمز المصدر

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

افتح علامة تبويب جديدة في 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

لاحظ أنّ مورد النشر يعرض حالة "تم التعديل"، بينما يعرض مورد الخدمة حالة "لم يتم التعديل". يمكن الاطّلاع على حِزم Pods المعدَّلة كما كان من قبل باستخدام الأمر 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 للوصول إلى تطبيق الويب.

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

تأكَّد من أنّ خدمة Kubernetes توزع الحمل

أعِد تحميل عنوان URL هذا عدة مرات ولاحظ أنّ المضيف يتغير مع موازنة تحميل الطلبات على مستوى وحدات Pod مختلفة من خلال الخدمة. قارِن قيم المضيف بقائمة الحاويات من الأعلى للتأكّد من أنّ جميع الحاويات تتلقّى عدد زيارات.

توسيع نطاق الأجهزة الافتراضية

يمكنك توسيع نطاق التطبيقات في Kubernetes بسهولة. سيؤدي الأمر التالي إلى توسيع نطاق عملية النشر لتشمل ما يصل إلى 6 مثيلات من التطبيق.

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

يمكن عرض حزم Pods الجديدة وحالتها الحالية باستخدام هذا الأمر

kubectl get pod -w

لاحظ أنّ إعادة تحميل نافذة المتصفّح نفسها توضّح أنّه يتم الآن موازنة عدد الزيارات على جميع وحدات Pod الجديدة.

8. تهانينا!

في هذا التمرين العملي، تم التحقّق من صحة نموذج لتطبيق ويب .NET Core في بيئة مطوّرين، ثم تم نشره على Kubernetes باستخدام GKE. تم تعديل التطبيق بعد ذلك لعرض اسم المضيف للحاوية التي كان يعمل فيها. تم بعد ذلك تعديل عملية نشر 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

نشر تطبيق .NET Core وتحديثه في Google Kubernetes Engine تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

1. نظرة عامة

التكاليف

2. الإعداد والمتطلبات

المتطلبات الأساسية

خيارات الضبط البديلة لمجموعة GKE (اختيارية)

الاستعداد لإنشاء مجموعة Kubernetes

إنشاء مجموعة GKE

ضبط kubectl

3- الاختبار محليًا والتأكّد من الوظائف المطلوبة

تشغيل الحاوية محليًا للتحقّق من الوظائف

تأكيد وظائف تطبيق الويب

4. الوصول إلى الخدمات من Cloud Shell باستخدام "معاينة الويب"

استخدام "معاينة الويب" لعرض التطبيقات في Cloud Shell

عرض نموذج تطبيق ‎ .NET باستخدام "معاينة الويب"

5- النشر على Kubernetes

إنشاء ملف YAML وتطبيقه

استكشاف المراجع الناتجة

مراجعة مورد الخدمة

التحقّق من التطبيق الذي يتم تشغيله

6. تعديل التطبيق

الحصول على رمز المصدر

تعديل التطبيق ليشمل اسم المضيف

إنشاء صورة حاوية جديدة واختبارها محليًا

وضع علامة على الصورة ونقلها لتصبح متاحة لـ Kubernetes

7. إعادة نشر التطبيق المعدَّل

تعديل ملف YAML

تطبيق ملف YAML المعدَّل

التحقّق من التطبيق الذي يتم تشغيله

تأكَّد من أنّ خدمة Kubernetes توزع الحمل

توسيع نطاق الأجهزة الافتراضية

8. تهانينا!

9- تَنظيم

نشر تطبيق .NET Core وتحديثه في Google Kubernetes Engine