המדריך הזה יעזור לכם להעביר את עומסי העבודה שלכם כדי שיפעלו ב-Knative בקוד פתוח עם Google Kubernetes Engine. באופן כללי, כדי להעביר את עומסי העבודה, צריך להתקין את הרכיב Knative Serving באשכול GKE חדש, ואז לפרוס מחדש כל אחד מהשירותים באשכול Knative הזה.
השימוש ב-Knative קוד פתוח, הניהול שלו והתמיכה בו הם באחריותכם, אבל המעבר ל-Knative מאפשר לכם להמשיך להריץ את עומסי העבודה בפלטפורמת Google Kubernetes Engine.
ההבדלים הבולטים:
- התמיכה מוגבלת ל-Google Kubernetes Engine. אפשר לפנות אל קהילת Knative לקבלת תמיכה ב-Knative.
- Google Cloud CLI (
gcloud) נתמך רק על ידי Google Kubernetes Engine. Knative תומך בפקודותkubectlו-kn. איך מתקינים אתkn
לפני שמתחילים
- צריכה להיות לכם גישה לאשכול GKE חדש.
- אפשר ליצור את האשכול החדש באותו פרויקט או בפרויקט חדש. Google Cloud
- האשכול חייב לעמוד בדרישות של Knative.
- איך יוצרים אשכול:
- צריך להעביר ידנית את כל הגדרות האשכול לאשכול Knative החדש, כולל, בין היתר:
- צריך ליצור ולהגדיר אמצעי בקרה חדשים של IAM ו-RBAC לגישה:
התקנת Knative ב-Google Kubernetes Engine
Knative מספקת כמה אפשרויות התקנה ושכבות רשת שניתן לבחור מתוכן. בשלבי ההתקנה הבאים של Knative נעשה שימוש בשיטת Knative Operator ובשכבת הרשת של Istio.
מתקינים את Knative Operator:
פורסים את האופרטור באשכול:
kubectl apply -f https://github.com/knative/operator/releases/download/knative-vVERSION/operator.yamlמחליפים את VERSION בגרסה של Knative Operator.
דוגמה:
kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.3.1/operator.yamlמגדירים את
kubectlCLI לשימוש במרחב השמותdefault:kubectl config set-context --current --namespace=defaultמוודאים שהמפעיל נוצר בהצלחה:
kubectl get deployment knative-operatorתוצאה:
NAME READY UP-TO-DATE AVAILABLE AGE knative-operator 1/1 1 1 6m43s
מתקינים את הרכיב Knative Serving:
יוצרים קובץ YAML עם ההגדרות הבאות, לדוגמה SERVING_FILENAME.yaml:
apiVersion: v1 kind: Namespace metadata: name: knative-serving --- apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving namespace: knative-servingפורסים את קובץ ה-YAML באשכול:
kubectl apply -f SERVING_FILENAME.yamlמחליפים את SERVING_FILENAME בקובץ ה-YAML שיצרתם.
מתקינים את Istio עם הזרקת sidecar כשכבת הרשת:
יש לכם אפשרות לבצע ולהגדיר התקנת Istio חלופית. אפשר לעיין בכל אפשרויות ההתקנה של Istio באתר Knative. הערה: ההתקנה הזו עשויה להימשך 30 דקות או יותר.
כדי להתקין את Istio, מריצים את הפקודה הבאה עם הדגל
--set hub=gcr.io/istio-releaseכדי להימנע מהגבלת קצב של יצירת בקשות של Docker:istioctl install --set hub=gcr.io/istio-releaseמריצים את הפקודה הבאה כדי להפעיל הוספה של קונטיינר sidecar:
kubectl label namespace default istio-injection=enabledאופציונלי: כברירת מחדל, Istio מותקן במרחב השמות
istio-system. אם רוצים להגדיר מרחב שמות אחר, אפשר לבצע את השלבים הבאים:כדי להגדיר מרחב שמות בהתאמה אישית ל-Istio, מוסיפים את המאפיינים
spec.config.istioלקובץ התצורה SERVING_FILENAME.yaml. לדוגמה:apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: # ... config: istio: local-gateway.LOCAL_GATEWAY_NAMESPACE.knative-local-gateway: "knative-local-gateway.ISTIO_NAMESPACE.svc.cluster.local"מחליפים את:
- LOCAL_GATEWAY_NAMESPACE הוא מרחב השמות שבו התקנתם את Knative Serving. ברירת מחדל:
knative-serving - ISTIO_NAMESPACE הוא מרחב השמות שבו מותקן Istio. ברירת מחדל:
istio-system
- LOCAL_GATEWAY_NAMESPACE הוא מרחב השמות שבו התקנתם את Knative Serving. ברירת מחדל:
פורסים את שירות SERVING_FILENAME.yaml המעודכן באשכול Knative:
kubectl apply -f SERVING_FILENAME.yamlכדי לאמת את ההתקנה של Istio, מאשרים ש-
istio-ingressgatewayנמצא במרחב השמות שצוין:kubectl get svc istio-ingressgateway -n ISTIO_NAMESPACEמחליפים את ISTIO_NAMESPACE במרחב השמות שבו התקנתם את Istio. ברירת מחדל:
istio-systemתוצאה:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.232.10.190 34.123.5.116 15021:30337/TCP,80:32549/TCP,443:31210/TCP 119m
העברת שירות
כדי להעביר שירות, פורסים את קובץ התצורה של השירות בפורמט YAML לאשכול Knative.
מריצים את הפקודה הבאה כדי לייצא את שירות Knative serving לקובץ YAML מקומי:
gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yamlמחליפים את:
SERVICEבשם של שירות Knative serving.-
NAMESPACEמחליפים במרחב השמות שבו השירות שלכם פועל. -
CLUSTERמחליפים בשם של האשכול שבו השירות פועל. -
FILENAMEבשם קובץ ייחודי לפי בחירתכם.
משנים את קובץ
FILENAME.yamlשיוצא כדי להסיר הגדרות לא רצויות של Knative serving. לשם כך, מוחקים את המאפיינים הבאים ואת הערכים שלהם:metadata.annotations.kubectl.kubernetes.io/last-applied-configurationmetadata.managedFieldsspec.template.spec.containers.readinessProbesspec.template.spec.enableServiceLinksלדוגמה, יכול להיות שתצטרכו להסיר את ההגדרה הבאה מהמאפיינים
spec:>template:>spec:>containers::... readinessProbe: successThreshold: 1 tcpSocket: {} ...
מבצעים פריסה של קובץ
.yamlששוּנה לאשכול Knative:kubectl apply -f SERVICE.yamlמחליפים את SERVICE בשם של קובץ התצורה של השירות.
אפשר לגשת לשירות שפרסתם באמצעות דומיין בדיקה או פקודות
cURL. אתם יכולים להשתמש בשירות DNS עם תווים כלליים כדי לבדוק גישה חיצונית לשירות שלכם. אפשרויות נוספות מפורטות בקטע הגדרת DNS במסמכי Knative.כדי להשתמש ב-Magic DNS (sslip.io), מריצים את הפקודה הבאה.
שימו לב שאפשר גם להשתמש ישירות ב-sslip.io.
kubectl apply -f https://github.com/knative/serving/releases/download/knative-vVERSION/serving-default-domain.yamlמחליפים את VERSION בגרסה של Knative Serving.
דוגמה:
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.3.0/serving-default-domain.yaml
העברת תנועה לשירות שלכם
אחרי שבודקים את השירותים החדשים שנפרסו ומוכנים להעביר את כל תעבורת הייצור, אפשר להגדיר את הדומיין המותאם אישית ולעדכן את רשומות ה-DNS אצל הרשם. פועלים לפי ההוראות במאמר הגדרת דומיינים בהתאמה אישית.