Knative - פלטפורמה כשירות מבוססת k8s עם תמיכה ללא שרת

Kubernetes הפכה ללא ספק לפלטפורמה הדומיננטית לפריסת מכולות. הוא מספק את היכולת לשלוט כמעט בכל דבר באמצעות ממשקי ה-API שלו והבקרים המותאמים אישית שמרחיבים את ממשקי ה-API שלו עם משאבים מותאמים אישית.

עם זאת, המשתמש עדיין חייב לקבל החלטות מפורטות לגבי איך בדיוק לפרוס, להגדיר, לנהל ולהתאים יישומים. בעיות של קנה מידה, הגנה וזרימת תנועה נשארות לשיקולו של המשתמש. זה מבדיל את Kubernetes מפלטפורמות קונבנציונליות כשירות (PaaS), כמו Cloud Foundry ו-Heroku.

לפלטפורמות ממשק משתמש פשוט ומכוונות למפתחי אפליקציות העוסקים לרוב בהקמת אפליקציות בודדות. ניתוב, פריסה ומדדים מנוהלים בשקיפות למשתמש על ידי מערכת ה-PaaS הבסיסית.

זרימת העבודה של מקור לספינה מטופלת על ידי PaaS על ידי יצירת תמונת מיכל מותאמת אישית, פריסתה, הגדרת נתיב חדש ותת-דומיין DNS לתעבורה נכנסת. כל זה מופעל בפקודה git push.

Kubernetes (בכוונה) מספקת רק את אבני הבניין המרכזיות לפלטפורמות כאלה, ומשאירה את הקהילה חופשית לעשות את העבודה בעצמה. אֵיך אמרה קלסי הייטאוור:

Kubernetes היא פלטפורמה לבניית פלטפורמות. המיקום הטוב ביותר להתחלה, אבל לא לסיים.

כתוצאה מכך, אנו רואים חבורה של בניית Kubernetes, כמו גם חברות אירוח שמנסות ליצור PaaS עבור Kubernetes, כגון OpenShift ו-Rancher. בתוך שוק ה-Kube-PaaS הצומח, Knative, שהוקמה ביולי 2018 על ידי גוגל ו-Pivotal, נכנסת לזירה.

Knative היה שיתוף פעולה בין גוגל ו-Pivotal, עם מעט עזרה מחברות אחרות כמו IBM, RedHat ו-Solo.im. הוא מציע דברים דומים של PaaS ל-Kubernetes עם תמיכה מהשורה הראשונה עבור יישומים מבוססי מחשוב ללא שרת. שלא כמו בניית Kubernetes, Knative מותקן כתוסף בכל אשכול Kubernetes תואם ומוגדר באמצעות משאבי משתמש.

מה זה קניטיב?

Knative מתואר כ"פלטפורמה מבוססת Kubernetes לאספקה ​​וניהול עומסי עבודה באמצעות מחשוב מודרני ללא שרתים." Knative, בזמן שהוא מחייב את עצמו כפלטפורמה כזו, משנה באופן פעיל קונטיינרים באופן אוטומטי ביחס לבקשות HTTP במקביל. שירותים שאינם בשימוש מצטמצמים בסופו של דבר לאפס, ומספקים קנה מידה ללא שרת בסגנון לפי דרישה.

Knative מורכבת מקבוצה של בקרים המתקינים בכל אשכול Kubernetes ומספקים את היכולות הבאות:

• בניית אפליקציות מכולות מקוד המקור (המסופק על ידי הרכיב לִבנוֹת),
• מתן גישה לתעבורה נכנסת ליישומים (המסופקים על ידי הרכיב הגשה),
• משלוח ושינוי קנה מידה אוטומטי של יישומים לפי דרישה (ניתן גם כן על ידי הרכיב הגשה),
• זיהוי מקורות האירועים המובילים להשקת אפליקציות (המסופקים על ידי הרכיב אירוע).

מרכיב מרכזי הוא Serving, המספק אספקה, קנה מידה אוטומטי וניהול תעבורה עבור יישומים מנוהלים. לאחר התקנת Knative, עדיין תהיה לך גישה מלאה לממשק ה-API של Kubernetes, המאפשר למשתמשים לנהל יישומים את הרגיל דרך, ומשמשת גם לניפוי באגים בשירותי Knative, תוך עבודה עם אותם פרימיטיבים של API ששירותים אלה משתמשים בהם (מודולים, שירותים וכו').

בעזרת Serving, גם ניתוב תעבורה כחול-ירוק אוטומטי, מה שמבטיח הפרדת תנועה בין גרסאות חדשות לישנות של האפליקציה כאשר המשתמש מספק גרסה מעודכנת של האפליקציה.

Knative עצמה תלויה בהתקנת בקר כניסה תואם. בזמן כתיבת מאמר זה נתמך Gloo API Gateway и Istio Service Mesh. זה יגדיר כניסה זמינה לניתוב תעבורה ליישומים המנוהלים על ידי Knative.

Istio Service Mesh יכולה להיות תלות גדולה עבור משתמשי Knative שרוצים לנסות אותה מבלי להתקין את לוח הבקרה של Istio, מכיוון ש-Knative תלוי רק בשער.

מסיבה זו, רוב המשתמשים מעדיפים את Gloo כשער ל-Knative, המספק מערך דומה של יכולות ל-Istio (לצורך שימוש רק ב-Knative), תוך שימוש בפחות משאבים באופן משמעותי ועלויות תפעול נמוכות יותר.

בואו נבחן את Knative בפעולה על הדוכן. אני אשתמש באשכול שהותקן לאחרונה הפועל ב-GKE:

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

בואו נתחיל להתקין את Knative and Gloo. ניתן לעשות זאת בכל סדר:

# ставим Knative-Serving
kubectl apply -f 
 https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f 
  https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...

אנו בודקים שכל הפודים נמצאים בסטטוס "פועל":

kubectl get pod -n knative-serving
NAME                              READY   STATUS    RESTARTS   AGE
activator-5dd55958cc-fkp7r        1/1     Running   0          7m32s
autoscaler-fd66459b7-7d5s2        1/1     Running   0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Running   0          7m32s
controller-85c8bb7ffd-nj9cs       1/1     Running   0          7m29s
webhook-5bd79b5c8b-7czrm          1/1     Running   0          7m29s
kubectl get pod -n gloo-system
NAME                                      READY   STATUS    RESTARTS   AGE
discovery-69548c8475-fvh7q                1/1     Running   0          44s
gloo-5b6954d7c7-7rfk9                     1/1     Running   0          45s
ingress-6c46cdf6f6-jwj7m                  1/1     Running   0          44s
knative-external-proxy-7dd7665869-x9xkg   1/1     Running   0          44s
knative-internal-proxy-7775476875-9xvdg   1/1     Running   0          44s

Gloo מוכן לניתוב, בואו ניצור שירות Knative בקנה מידה אוטומטי (בואו נקרא לזה kservice) ונתיב אליו את התנועה.

שירותי Knative מספקים נתיב קל יותר לאספקת יישומים ל-Kubernetes מאשר מודל Deployment+Service+Ingress הרגיל. נעבוד עם הדוגמה הזו:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: gcr.io/knative-samples/helloworld-go
         env:
           - name: TARGET
             Value: Knative user

העתקתי את זה לקובץ, ואז החלתי אותו על אשכול Kubernetes שלי בדרך זו:

kubectl apply -f ksvc.yaml -n default

אנו יכולים לראות את המשאבים שנוצרו על ידי Knative באשכול לאחר העברת ה-"helloworld-go" שלנו kservice:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

הפוד עם תמונת 'helloworld-go' שלנו מושק כאשר ה-kservice נפרס. אם אין תנועה, מספר הפודים יקטן לאפס. ולהיפך, אם מספר הבקשות בו-זמנית חורג מסף מסוים שניתן להגדרה, מספר הפודים יגדל.

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

Knative מגדיר את הכניסה שלו באמצעות משאב 'כניסה' מיוחד ב-Knative API הפנימי. Gloo משתמש ב-API זה כתצורה שלו כדי לספק תכונות דמויות PaaS, כולל מודל פריסה כחול-ירוק, אכיפה אוטומטית של TLS, פסקי זמן ותכונות ניתוב מתקדמות אחרות.

לאחר זמן מה, אנו רואים שהתרמילים שלנו נעלמו (מכיוון שלא הייתה תנועה נכנסת):

kubectl get pod -n default

No resources found.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

לבסוף ננסה להגיע אליהם. אתה יכול בקלות ובקלות לקבל את כתובת האתר עבור Knative Proxy באמצעות glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

בלי מותקן glooctl אתה יכול לראות את הכתובת והיציאה בשירות kube:

kubectl get svc -n gloo-system knative-external-proxy
NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

בואו נריץ כמה נתונים באמצעות cURL:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

Knative מספקת כמעט PaaS למפתחים על גבי Kubernetes היוצאות מהקופסה באמצעות שער ה-API בעל הביצועים הגבוהים של Gloo. הפוסט הזה רק שרט את פני השטח של אפשרויות ההתאמה האישית הנרחבות של Knative ותכונות נוספות. אותו דבר עם Gloo!

למרות העובדה ש-Knative הוא עדיין פרויקט צעיר, הצוות שלה משחרר גרסאות חדשות כל שישה שבועות, והחלה הטמעת תכונות מתקדמות, כמו פריסת TLS אוטומטית, קנה מידה אוטומטי של לוח הבקרה. יש סיכוי גבוה שכתוצאה משיתוף פעולה בין מספר חברות ענן, וכבסיס להצעת Cloud Run החדשה של גוגל, Knative יכולה להפוך לאופציה העיקרית עבור מחשוב ללא שרת ו-PaaS ב-Kubernetes. עקבו אחר החדשות!

מעורכי SouthBridge
דעות הקוראים חשובות לנו, לכן אנו מבקשים מכם לקחת חלק בסקר קצר הקשור למאמרים עתידיים על Knative, Kubernetes, מחשוב ללא שרתים:

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם עלי להמשיך לכתוב מאמרים ומדריכים על מחשוב Knative וחסר שרתים?

• כן בבקשה.

• לא תודה.

28 משתמשים הצביעו. 4 משתמשים נמנעו.

מקור: www.habr.com