במאמר הזה מוסבר איך ליצור ולנהל עומסי עבודה חסרי מצב באשכול Kubernetes עם בידוד פיזי ב-Google Distributed Cloud (GDC). עומסי עבודה בלי שמירת מצב מאפשרים לכם להתאים את פריסת האפליקציה לעומס העבודה, בלי שתצטרכו לנהל אחסון מתמיד באשכול Kubernetes כדי לאחסן נתונים או את ערך דינמי של האפליקציה. המאמר הזה יעזור לכם להתחיל כדי שתוכלו לבצע אופטימיזציה יעילה של זמינות האפליקציה ולהתאים אותה.
המסמך הזה מיועד למפתחים בקבוצת מפעילים של אפליקציות, שאחראים ליצירת עומסי עבודה של אפליקציות בארגון שלהם. מידע נוסף זמין במאמר בנושא קהלים ב-GDC עם air gap.
לפני שמתחילים
כדי להשלים את המשימות שמתוארות במאמר הזה, צריך לבקש את ההרשאות הנדרשות.
שליחת בקשה לתפקידי IAM
כדי לקבל את ההרשאות שדרושות ליצירת עומסי עבודה חסרי סטטוס, צריך להיות לכם תפקידים ספציפיים. התפקידים שאתם צריכים תלויים בסוג האשכול שבו אתם עובדים: אשכול שיתופי בהיקף הארגון או אשכול רגיל בהיקף הפרויקט. למידע נוסף, קראו את המאמר הגדרות של אשכול Kubernetes.
תפקידים משותפים באשכול
כדי ליצור, למחוק, לערוך או להציג עומסי עבודה חסרי סטטוס באשכול משותף, צריך לבקש מאדמין ה-IAM בפרויקט להעניק לכם את התפקיד אדמין של מרחב שמות (namespace-admin). התפקיד הזה משויך למרחב השמות של הפרויקט.
תפקידים רגילים באשכול
כדי ליצור, למחוק, לערוך או להציג עומסי עבודה ללא מצב (stateless) באשכול רגיל, צריך לבקש מאדמין IAM בפרויקט להעניק לכם את התפקיד מפתח אשכול (cluster-developer). התפקיד הזה משויך למרחב השמות של הפרויקט.
הכנת הסביבה
כדי להריץ פקודות מול אשכול Kubernetes באמצעות ה-API, צריך לוודא שיש לכם את המשאבים הבאים:
מאתרים את שם אשכול Kubernetes או שואלים חבר בקבוצת האדמינים של הפלטפורמה מה שם האשכול.
נכנסים לחשבון ויוצרים את קובץ ה-kubeconfig לאשכול Kubernetes.
משתמשים בנתיב kubeconfig של אשכול Kubernetes כדי להחליף את
KUBERNETES_CLUSTER_KUBECONFIGבהוראות האלה.
יצירת פריסה
כדי ליצור פריסה, כותבים Deployment מניפסט ומריצים את הפקודה
kubectl apply כדי ליצור את המשאב. בשיטה הזו, המערכת גם שומרת על העדכונים שבוצעו במשאבים של שידורים חיים בלי למזג את השינויים בחזרה לקובצי המניפסט.
כדי ליצור Deployment מקובץ המניפסט שלו, מריצים את הפקודה:
kubectl --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG -n NAMESPACE \
apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: DEPLOYMENT_NAME
spec:
replicas: NUMBER_OF_REPLICAS
selector:
matchLabels:
run: APP_NAME
template:
metadata:
labels: # The labels given to each pod in the deployment, which are used
# to manage all pods in the deployment.
run: APP_NAME
spec: # The pod specification, which defines how each pod runs in the deployment.
containers:
- name: CONTAINER_NAME
image: CONTAINER_IMAGE
EOF
מחליפים את מה שכתוב בשדות הבאים:
KUBERNETES_CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של אשכול Kubernetes שבו אתם פורסים עומסי עבודה של קונטיינרים.
NAMESPACE: מרחב השמות שבו יופעלו עומסי העבודה של הקונטיינרים. במקרה של אשכולות משותפים, צריך להשתמש במרחב שמות של פרויקט. במקרים של אשכולות רגילים, אפשר להשתמש בכל מרחב שמות.
DEPLOYMENT_NAME: השם של אובייקטDeployment.
APP_NAME: השם של האפליקציה שרוצים להפעיל בפריסה.
NUMBER_OF_REPLICAS: מספר האובייקטים המשוכפליםPodשהפריסה מנהלת.
CONTAINER_NAME: השם של הקונטיינר.
CONTAINER_IMAGE: השם של קובץ האימג' בקונטיינר. חובה לכלול את הנתיב של מאגר הקונטיינרים ואת הגרסה של התמונה, כמוREGISTRY_PATH/hello-app:1.0. מידע נוסף על הגדרת הנתיב של מאגר התמונות זמין במאמר סקירה כללית על שירות Harbor המנוהל.
לדוגמה:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
run: my-app
template:
metadata:
labels:
run: my-app
spec:
containers:
- name: hello-app
image: REGISTRY_PATH/hello-app:1.0
אם אתם פורסים עומסי עבודה של GPU במאגרי התמונות שלכם, תוכלו לקרוא מידע נוסף במאמר בנושא ניהול עומסי עבודה של GPU במאגרי תמונות.