על הפופולריות הגוברת של Kubernetes

היי הבר!

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

תהנה קריאה!

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

קונטיינרים החלו כעיצוב מיוחד לבידוד תהליכים בלינוקס; מכולות נכללות מאז 2007 קבוצות, ומאז 2002 – מרחבי שמות. מכולות תוכננו אפילו טוב יותר עד שנת 2008, כשהיא הפכה לזמינה LXC, וגוגל פיתחה מנגנון פנימי ארגוני משלה שנקרא בורג, שבו "כל העבודה נעשית במכולות". מכאן אנחנו מהר קדימה לשנת 2013, אז התרחשה ההשקה הראשונה של Docker, והמכולות הפכו סוף סוף לפתרון המוני פופולרי. באותה תקופה, הכלי העיקרי לתזמור מכולה היה מסוס, למרות שהוא לא היה פופולרי במיוחד. Kubernetes יצא לראשונה בשנת 2015, ולאחר מכן הכלי הזה הפך לסטנדרט דה פקטו בתחום תזמור המכולה.

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

תשתית כמו YAML

בעולם שעבר מ-Puppet and Chef ל-Kubernetes, אחד השינויים הגדולים ביותר היה המעבר מ"תשתית כקוד" ל"תשתית כנתונים" - ספציפית, כמו YAML. ניתן לתאר בקלות את כל המשאבים ב-Kubernetes, הכוללים פודים, תצורות, מופעים פרוסים, אמצעי אחסון וכו' בקובץ YAML. לדוגמה:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

תצוגה זו מקלה על אנשי מקצוע DevOps או SRE לבטא את עומסי העבודה שלהם במלואם מבלי לכתוב קוד בשפות כמו Python או Javascript.

יתרונות נוספים של ארגון תשתית כנתונים כוללים:

• GitOps או Git Operations Control Version Control. גישה זו מאפשרת לך לשמור את כל קבצי Kubernetes YAML במאגרי git, כך שתוכל לעקוב בדיוק מתי בוצע שינוי, מי ביצע אותו ומה בדיוק השתנה. זה מגביר את השקיפות של הפעולות בכל הארגון ומשפר את היעילות התפעולית על ידי ביטול אי בהירות, במיוחד במקום שבו העובדים צריכים לחפש את המשאבים שהם צריכים. יחד עם זאת, קל יותר לבצע שינויים אוטומטית במשאבי Kubernetes על ידי מיזוג בקשת משיכה.
• מדרגיות. כאשר משאבים מוגדרים כ-YAML, זה הופך להיות קל מאוד עבור אופרטורים של אשכולות לשנות מספר אחד או שניים במשאב Kubernetes, ובכך לשנות את אופן קנה המידה שלו. Kubernetes מספקת מנגנון לשינוי קנה מידה אוטומטי אופקי של פודים, שניתן להשתמש בו כדי לקבוע בנוחות מה המספר המינימלי והמקסימלי של פודים הנדרשים בתצורת פריסה מסוימת כדי להתמודד עם רמות נמוכות וגבוהות של תעבורה. לדוגמה, אם פרסתם תצורה הדורשת קיבולת נוספת עקב עלייה פתאומית בתעבורה, ניתן לשנות את maxReplicas מ-10 ל-20:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• אבטחה וניהול. YAML מצוין להערכת אופן פריסת הדברים ב-Kubernetes. לדוגמה, דאגת אבטחה גדולה נוגעת לשאלה האם עומסי העבודה שלך פועלים כמשתמש שאינו מנהל. במקרה זה, ייתכן שנצטרך כלים כגון תחרות, אימות YAML/JSON, פלוס פתח את סוכן המדיניות, מאמת מדיניות כדי להבטיח שההקשר אבטחה הקשר עומסי העבודה שלך אינם מאפשרים למכולה לפעול עם הרשאות מנהל. אם זה נדרש, משתמשים יכולים להחיל מדיניות פשוטה רגו, ככה:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• אפשרויות אינטגרציה עם ספק ענן. אחת המגמות הבולטות ביותר בטכנולוגיה העילית של ימינו היא להפעיל עומסי עבודה על ספקי ענן ציבוריים. שימוש ברכיב ספק ענן Kubernetes מאפשרת לכל אשכול להשתלב עם ספק הענן עליו הוא פועל. לדוגמה, אם משתמש מריץ אפליקציה ב-Kubernetes ב-AWS ורוצה לחשוף את האפליקציה דרך שירות, ספק הענן עוזר ליצור את השירות באופן אוטומטי LoadBalancerאשר יספק אוטומטית את מאזן העומס מאזן עומסים אלסטי של אמזוןכדי להפנות תעבורה לתרמילים של יישומים.

יכולת הרחבה

Kubernetes מאוד ניתנת להרחבה ומפתחים אוהבים את זה. יש קבוצה של משאבים זמינים כגון תרמילים, פריסות, StatefulSets, סודות, ConfigMaps, וכו. נכון, משתמשים ומפתחים יכולים להוסיף משאבים אחרים בטופס הגדרות משאבים מותאמות אישית.

למשל, אם נרצה להגדיר משאב CronTab, אז אתה יכול לעשות משהו כזה:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

מאוחר יותר נוכל ליצור משאב CronTab משהו כזה:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

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

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

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

זה יוצר את כל קוד ה-boilerplate עבור המפעיל שלך, כולל קבצי YAML וקוד Golang:

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

לאחר מכן תוכל להוסיף את ממשקי ה-API והבקר הנדרשים, כך:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

לאחר מכן, לבסוף, הרכיב את המפעיל ושלח אותו לרישום של המכולה שלך:

$ operator-sdk build your.container.registry/youruser/myapp-operator

אם המפתח רוצה אפילו יותר שליטה, ניתן לשנות את קוד ה-boilerplate בקבצי Go. לדוגמה, כדי לשנות את הפרטים של הבקר, אתה יכול לבצע שינויים בקובץ controller.go.

עוד פרויקט בכל מקום, מאפשר לך ליצור הצהרות באמצעות קבצי YAML הצהרתיים בלבד. לדוגמה, מפעיל עבור Apache Kafka יוגדר בערך כך. עם זה, אתה יכול להתקין אשכול קפקא על גבי Kubernetes עם רק כמה פקודות:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

ואז להגדיר את זה עם פקודה אחרת:

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

חידושים

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

יכולות חדשות מאפשרות לך לאסוף פעולות בצורה גמישה יותר על פני עומסי עבודה מגוונים. בנוסף, מתכנתים נהנים משליטה רבה יותר בעת פריסת יישומים ישירות לייצור.

קהל

היבט מרכזי נוסף בפופולריות של Kubernetes הוא החוזק של הקהילה שלה. בשנת 2015, עם הגיעה לגרסה 1.0, Kubernetes זכה בחסות קרן מחשוב מקומית לענן.

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

קרן Cloud Native מארחת גם את CloudNativeCon/KubeCon, שהוא, בזמן כתיבת שורות אלו, כנס הקוד הפתוח הגדול בעולם. הוא מתקיים בדרך כלל שלוש פעמים בשנה, ומפגיש אלפי אנשי מקצוע שרוצים לשפר את Kubernetes ואת המערכת האקולוגית שלה, כמו גם ללמוד תכונות חדשות המופיעות כל שלושה חודשים.

יתר על כן, ל-Cloud Native Foundation יש ועדת פיקוח טכני, אשר, יחד עם SIGs, סוקר חדש וקיימים פרויקטים קרנות המתמקדות במערכת האקולוגית של הענן. רוב הפרויקטים הללו עוזרים לשפר את החוזקות של Kubernetes.

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

העתיד

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

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

מקור: www.habr.com