פריסת אפליקציה ב-Windows Server

Standard

בדף הזה מוסבר איך לפרוס אפליקציית Windows Server ללא שמירת מצב באשכול Google Kubernetes Engine ‏ (GKE). אפשר גם ללמוד איך לפרוס אפליקציית Windows עם שמירת מצב.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

• מפעילים את ממשקי ה-API של Artifact Registry ושל Google Kubernetes Engine.
הפעלת ממשקי API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, צריך להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

פריסת אפליקציית Windows Server באשכול עם צמתים ציבוריים

כדי לפרוס אפליקציית Windows Server באשכול GKE עם צמתים ציבוריים בלבד, צריך לבצע את המשימות הבאות:

1. יוצרים אשכול עם צמתים ציבוריים.
2. יוצרים קובץ מניפסט של פריסה.
3. יצירה וחשיפה של הפריסה.
4. מוודאים שה-Pod פועל.

יצירת אשכול עם צמתים ציבוריים

אם כבר יש לכם אשכול GKE שמשתמש במאגרי צמתים של Windows Server, המשיכו לשלב הבא. אחרת, יוצרים אשכול באמצעות מאגרי צמתים של Windows Server. כדי להקצות צמתים עם כתובות IP חיצוניות (צמתים ציבוריים), משתמשים בדגל --no-enable-private-nodes כשיוצרים את האשכול.

יצירת קובץ מניפסט של פריסה

צמתי Windows Server הם tainted עם צמד המפתח/ערך הבא: node.kubernetes.io/os=windows:NoSchedule.

ההכתמה הזו עוזרת לוודא שתזמן העבודות של GKE לא ינסה להפעיל קונטיינרים של Linux בצמתים של Windows Server. כדי לתזמן קונטיינרים של Windows Server בצמתים של Windows Server, קובץ המניפסט צריך לכלול את בורר הצמתים הזה:

nodeSelector:
 kubernetes.io/os: windows

ווּבהוק (webhook) של הרשאה שפועל באשכול בודק אם יש בעומסי עבודה חדשים את בורר הצמתים של Windows. אם הוא מוצא אותו, הוא מחיל את הטולרנטיות הבאה על עומס העבודה, וכך מאפשר לו לפעול בצמתים של שרת Windows שסומנו כבעייתיים:

tolerations:
- effect: NoSchedule
  key: node.kubernetes.io/os
  operator: Equal
  value: windows

במקרים מסוימים, יכול להיות שתצטרכו לכלול את ההגדרה הזו באופן מפורש בקובץ המניפסט. לדוגמה, אם אתם פורסים DaemonSet עם קובץ אימג' של קונטיינר multi-arch להפעלה בכל הצמתים של Linux ו-Windows Server באשכול, קובץ המניפסט לא יכלול את בורר הצמתים של Windows. צריך לכלול באופן מפורש את הטולרנטיות לדחייה (taint) של Windows.

קובץ מניפסט לדוגמה

קובץ הפריסה לדוגמה (iis.yaml) הבא פורס את תמונת ה-IIS של מיקרוסופט לפוד יחיד:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80

הקובץ הזה מיועד לאשכול שבו כל עומסי העבודה משתמשים באותו סוג וגרסה של תמונת צומת של Windows Server. פרטים על עבודה עם תמונות של צמתים מעורבים מופיעים בקטע שימוש בתמונות של צמתים מעורבים.

יצירה וחשיפה של הפריסה

יוצרים את קובץ הפריסה שיצרתם בשלב הקודם וחושפים אותו כשירות Kubernetes עם פריסה של מאזן עומסים חיצוני.

1. כדי ליצור את משאב הפריסה, מריצים את הפקודה הבאה:

   kubectl apply -f iis.yaml
   

2. כדי לחשוף את הפריסה כמאזן עומסים חיצוני, מריצים את הפקודה הבאה:

   kubectl expose deployment iis \
       --type=LoadBalancer \
       --name=iis
   

אימות שה-Pod פועל

כדי לוודא שה-Pod פועל, צריך לאמת אותו.

1. בודקים את הסטטוס של ה-Pod באמצעות kubectl:

   kubectl get pods
   

2. מחכים עד שהפלט שמוחזר יראה שהסטטוס של ה-Pod הוא Running:

   NAME                   READY     STATUS    RESTARTS   AGE
   iis-5c997657fb-w95dl   1/1       Running   0          28s
   

3. מקבלים את הסטטוס של השירות וממתינים עד שהשדה EXTERNAL-IP יאוכלס:

   kubectl get service iis
   

   הפלט הבא אמור להתקבל:

   NAME   TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
   iis    LoadBalancer   10.44.2.112   external-ip    80:32233/TCP   17s
   

עכשיו אפשר להשתמש בדפדפן כדי לפתוח את http://EXTERNAL_IP ולראות את דף האינטרנט של IIS.

פריסת אפליקציית Windows Server באשכול עם צמתים פרטיים

בקטע הזה נסביר איך פורסים אפליקציית קונטיינר של Windows Server לאשכול GKE שמופעלים בו רק צמתים פרטיים.

לקובצי אימג' של קונטיינרים ב-Windows Server יש כמה שכבות, והשכבות הבסיסיות מסופקות על ידי מיקרוסופט. שכבות הבסיס מאוחסנות כשכבה חיצונית במקום להיות מוטמעות בתמונה כמו שכבות של תמונת Linux Docker. כשמושכים קובץ אימג' של קונטיינר של Windows Server בפעם הראשונה, בדרך כלל צריך להוריד את שכבות הבסיס מהשרתים של מיקרוסופט. מכיוון שלצמתים פרטיים אין קישוריות לאינטרנט, אי אפשר לשלוף את שכבות מאגר הבסיס של Windows Server ישירות משרתי מיקרוסופט.

כדי להשתמש באשכולות עם צמתים פרטיים מופעלים, אפשר להגדיר את שד ה-Docker כדי לאפשר דחיפה של שכבות שאי אפשר להפיץ למאגרי רישום פרטיים. מידע נוסף זמין במאמר Allow push of non-distributable artifacts בדף GitHub של Docker.

כדי לפרוס את אפליקציית Windows Server באשכול שמופעלים בו צמתים פרטיים:

1. יוצרים אשכול עם צמתים של Windows Server ומפעילים צמתים פרטיים.
2. יוצרים קובץ אימג' של Docker לאפליקציית Windows Server.
3. פורסים את האפליקציה באשכול שמופעלים בו צמתים פרטיים.
4. מוודאים שה-Pod פועל.

יצירת אשכול עם צמתים פרטיים

פועלים לפי ההוראות במאמר יצירת אשכול עם צמתי Windows Server. כדי להקצות צמתים עם כתובות IP פנימיות בלבד (צמתים פרטיים), משתמשים בדגל --enable-private-nodes כשיוצרים את האשכול.

יצירת קובץ אימג' של Docker לאפליקציית Windows Server

1. כדי ליצור את קובץ האימג' של Docker, מפעילים מכונה של Compute Engine עם גרסת Windows Server שרוצים להריץ עליה את קונטיינרים של האפליקציה, כמו Windows Server 2019 או Windows Server גרסה 20H2. בנוסף, צריך לוודא שיש חיבור לאינטרנט.

2. במכונה של Compute Engine, עוברים להגדרות של Docker daemon:

   cat C:\ProgramData\docker\config\daemon.json
   

3. כדי לאפשר דחיפה של שכבות חיצוניות למאגר הפרטי, מוסיפים את השורות הבאות לקובץ Docker daemon.json:

   {
     "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
   }
   

   בדוגמה הזו, REGISTRY_REGION-docker.pkg.dev מתייחס ל-Artifact Registry, שבו יתארח האימג'.

4. מפעילים מחדש את Docker daemon:

   Restart-Service docker
   

5. יוצרים מאגר Docker ב-Artifact Registry.

6. יוצרים את קובץ האימג' של Docker לאפליקציה ומוסיפים לו תג:

   cd C:\my-app
   

   docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2 .
   

   הפקודה הזו מורה ל-Docker ליצור את קובץ האימג' באמצעות קובץ Dockerfile בספרייה הנוכחית ולתייג אותו בשם, כמו us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2.

7. מעבירים בדחיפה את קובץ האימג' של Docker של האפליקציה למאגר Artifact Registry בפרויקט. הגדרת התצורה allow-nondistributable-artifacts גורמת לשכבות הבסיס של Windows להידחף למאגר הפרטי שלכם.

   docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
   

יצירת קובץ מניפסט של פריסה

בהמשך מופיע קובץ מניפסט לדוגמה של פריסה בשם my-app.yaml. התמונה בדוגמה הזו היא התמונה שדחפתם בשלב הקודם (REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: my-server
        image: REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2

1. משתמשים בפקודה get-credentials כדי להפעיל את kubectl לעבודה עם האשכול שיצרתם:

   gcloud container clusters get-credentials CLUSTER_NAME
   

   מחליפים את CLUSTER_NAME בשם האשכול שיצרתם.

2. פורסים את האפליקציה שצוינה בקובץ my-app.yaml באשכול:

   kubectl apply -f my-app.yaml
   

אימות שה-Pod פועל

מציגים את כל ה-Pods כדי לוודא שהאפליקציה פועלת בצורה תקינה:

kubectl get pods

ה-Pod אמור להופיע עם הסטטוס Running, כמו בדוגמה הבאה:

NAME                     READY   STATUS    RESTARTS   AGE
my-app-c95fc5596-c9zcb   1/1     Running   0          5m

שימוש בתמונות של צמתים מעורבים

האשכולות יכולים לכלול מאגרי צמתים עם כמה גרסאות של Windows Server. הם יכולים גם לשלב בין עומסי עבודה של Windows Server ו-Linux. בקטעים הבאים מוסבר איך להגדיר את עומסי העבודה כך שישתמשו בסוגי האשכולות האלה.

שימוש בעומסי עבודה עם גרסאות שונות של מערכת ההפעלה Windows Server LTSC

צמתים של Windows Server תומכים בתמונות של מערכות הפעלה LTSC2022 ו-LTSC2019. אפשר לציין את גרסת מערכת ההפעלה Windows לשימוש (LTSC2022) באמצעות זוג הערכים הבא במאפיין nodeSelector: ‏ cloud.google.com/gke-windows-os-version=2022.

תווית הצומת הזו עוזרת להבטיח שתזמן GKE יבחר את הצמתים הנכונים של Windows Server להרצת עומסי עבודה של LTSC2022 או LTSC2019. הצמתים של Windows Server שייכים לסוג התמונה windows_ltsc_containerd. הערך של תווית הצומת יכול להיות 2022 או 2019. אם לא מציינים את התווית של הצומת, אפשר להשתמש בצמתים LTSC2019 או LTSC2022 כדי לתזמן קונטיינרים. כדי לתזמן קונטיינרים של Windows Server רק בצמתים של Windows Server LTSC2022, קובץ המניפסט צריך לכלול את בורר הצמתים הזה:

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc
   cloud.google.com/gke-windows-os-version: 2022

שימוש בעומסי עבודה עם גרסאות שונות של Windows Server

אם אתם צריכים להריץ מאגרי צמתים של Windows Server עם כמה גרסאות LTSC שונות, מומלץ ליצור את תמונות הקונטיינרים כתמונות מרובות ארכיטקטורות שיכולות לפעול בכל הגרסאות של Windows Server שנמצאות בשימוש באשכול. התווית של הצומת gke-os-distribution לא מספיקה כדי למנוע את האפשרות שעומסי העבודה שלכם יתוזמנו לצמתים לא תואמים.

שימוש בעומסי עבודה של Linux ו-Windows Server באשכול

כדי לוודא שעומסי העבודה של Linux תמיד מתוזמנים לצמתים של Linux, מוסיפים את בורר הצמתים הבא לעומסי העבודה של Linux:

nodeSelector:
   kubernetes.io/os: linux

ההגדרה הזו מספקת הגנה נוספת כדי למנוע תזמון של עומסי עבודה של Linux בצמתי Windows Server במקרה שNoSchedule taint יוסר בטעות מצמתי Windows Server.

הערה: אם משתמשים ב-DaemonSets שפועלים רק ב-Linux, חובה להשתמש ב-nodeSelector הזה.