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

רגילה

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

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

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

• מפעילים את ממשקי ה-API של Artifact Registry ושל Google Kubernetes Engine.
הפעלת ממשקי API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-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 הם מוכתמים בצמד המפתח/ערך הבא: node.kubernetes.io/os=windows:NoSchedule.

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

nodeSelector:
 kubernetes.io/os: windows

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

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 יש כמה שכבות, והשכבות הבסיסיות מסופקות על ידי מיקרוסופט. שכבות הבסיס מאוחסנות כשכבה חיצונית במקום להיות מוטמעות בתמונה כמו שכבות של תמונת Docker של Linux. כשמושכים קובץ אימג' של קונטיינר של 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. הם יכולים גם לשלב בין עומסי עבודה (workloads) של 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:

nodeSelector:
   kubernetes.io/os: linux

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

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