מינימום קיימות Kubernetes

תרגום המאמר הוכן ערב תחילת הקורס "שיטות וכלים של DevOps".

אם אתם קוראים את זה, בטח שמעתם משהו על Kubernetes (ואם לא, איך הגעת לכאן?) אבל מה זה בעצם Kubernetes? זֶה "תזמור של מכולות תעשייתיות"? או "מערכת הפעלה ענן מקורית"? מה זה אומר בכלל?

למען האמת, אני לא בטוח ב-100%. אבל אני חושב שזה מעניין לחפור בפנים ולראות מה באמת קורה ב-Kubernetes מתחת לשכבות ההפשטות הרבות שלו. אז סתם בשביל הכיף, בואו נסתכל איך באמת נראה "אשכול Kubernetes" מינימלי. (זה יהיה הרבה יותר קל מאשר Kubernetes בדרך הקשה.)

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

סקירה

Kubernetes מכיל רכיבים רבים. לפי ויקיפדיה, הארכיטקטורה נראית כך:

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

• קובלט
• kube-apiserver (תלוי ב-etcd - מסד הנתונים שלו)
• זמן ריצה של מיכל (Docker במקרה זה)

בוא נראה מה אומר התיעוד על כל אחד מהם (רוס., אנגלית.). בתחילה קובלט:

סוכן הפועל בכל צומת באשכול. זה מוודא שמיכלים פועלים בתרמיל.

נשמע פשוט מספיק. מה לגבי זמני ריצה של מיכל (זמן ריצה של מיכל)?

זמן ריצה של קונטיינר היא תוכנית המיועדת להפעיל קונטיינרים.

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

И שרת API?

שרת API הוא רכיב לוח הבקרה של Kubernetes שחושף את ה-API של Kubernetes. שרת ה-API הוא צד הלקוח של לוח הבקרה של Kubernetes

כל מי שאי פעם עשה משהו עם Kubernetes נאלץ ליצור אינטראקציה עם ה-API ישירות או דרך kubectl. זה הלב של מה שהופך את Kubernetes Kubernetes - המוח שהופך את הרי YAML שכולנו מכירים ואוהבים (?) לתשתית פועלת. נראה ברור שה-API צריך להיות קיים בתצורה המינימלית שלנו.

תנאים מוקדמים

• מכונה וירטואלית או פיזית של לינוקס עם גישת שורש (אני משתמש באובונטו 18.04 במכונה וירטואלית).
• והכל!

התקנה משעממת

אנחנו צריכים להתקין את Docker על המחשב שבו נשתמש. (אני לא מתכוון להיכנס לפרטים לגבי אופן הפעולה של Docker ומכולות; אם אתה מעוניין, יש מאמרים נפלאים). בואו פשוט נתקין את זה עם apt:

$ sudo apt install docker.io
$ sudo systemctl start docker

לאחר מכן, עלינו לקבל את הקבצים הבינאריים של Kubernetes. למעשה, עבור ההשקה הראשונית של ה"אשכול" שלנו אנחנו צריכים רק kubelet, שכן כדי להפעיל רכיבי שרת אחרים אנחנו יכולים להשתמש kubelet. כדי ליצור אינטראקציה עם האשכול שלנו לאחר שהוא פועל, נשתמש גם kubectl.

$ curl -L https://dl.k8s.io/v1.18.5/kubernetes-server-linux-amd64.tar.gz > server.tar.gz
$ tar xzvf server.tar.gz
$ cp kubernetes/server/bin/kubelet .
$ cp kubernetes/server/bin/kubectl .
$ ./kubelet --version
Kubernetes v1.18.5

מה יקרה אם רק נרוץ kubelet?

$ ./kubelet
F0609 04:03:29.105194    4583 server.go:254] mkdir /var/lib/kubelet: permission denied

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

$ ./kubelet -h
<слишком много строк, чтобы разместить здесь>
$ ./kubelet -h | wc -l
284

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

--pod-manifest-path string

נתיב לספרייה המכילה קבצים עבור תרמילים סטטיים, או נתיב לקובץ המתאר תרמילים סטטיים. מתעלמים מקבצים שמתחילים בנקודות. (מבוטל: יש להגדיר אפשרות זו בקובץ התצורה המועבר ל-Kubelet דרך האפשרות --config. למידע נוסף, ראה kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

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

ראשית ניצור ספרייה עבור פודים סטטיים ונפעיל kubelet:

$ mkdir pods
$ sudo ./kubelet --pod-manifest-path=pods

לאחר מכן, בטרמינל/חלון tmux/whatever אחר, ניצור מניפסט פוד:

$ cat <<EOF > pods/hello.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
  - image: busybox
    name: hello
    command: ["echo", "hello world!"]
EOF

kubelet מתחיל לכתוב כמה אזהרות ונראה ששום דבר לא קורה. אבל זה לא נכון! בואו נסתכל על Docker:

$ sudo docker ps -a
CONTAINER ID        IMAGE                  COMMAND                 CREATED             STATUS                      PORTS               NAMES
8c8a35e26663        busybox                "echo 'hello world!'"   36 seconds ago      Exited (0) 36 seconds ago                       k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4
68f670c3c85f        k8s.gcr.io/pause:3.2   "/pause"                2 minutes ago       Up 2 minutes                                    k8s_POD_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_0
$ sudo docker logs k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4
hello world!

kubelet קראתי את המניפסט של הפוד ונתתי ל-Docker את הפקודה להשיק כמה מכולות לפי המפרט שלנו. (אם אתה תוהה לגבי מיכל ה"השהה", זה פריצת Kubernetes - ראה הבלוג הזה.) Kubelet תשיק את המכולה שלנו busybox עם הפקודה שצוינה ויפעיל אותו מחדש ללא הגבלת זמן עד שהפוד הסטטי יימחק.

ברך את עצמך. זה עתה מצאנו את אחת הדרכים המבלבלות ביותר להוציא טקסט למסוף!

הפעלה וכו'

המטרה הסופית שלנו היא להפעיל את ה-API של Kubernetes, אך לשם כך עלינו קודם כל להפעיל וכו '. בואו נתחיל אשכול etcd מינימלי על ידי הצבת ההגדרות שלו בספריית הפודים (לדוגמה, pods/etcd.yaml):

apiVersion: v1
kind: Pod
metadata:
  name: etcd
  namespace: kube-system
spec:
  containers:
  - name: etcd
    command:
    - etcd
    - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: etcd-data
  hostNetwork: true
  volumes:
  - hostPath:
      path: /var/lib/etcd
      type: DirectoryOrCreate
    name: etcd-data

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

הרכבנו את תיקיית המארח /var/lib/etcd בפוד כך שנתוני ה-etcd יישמרו לאחר הפעלה מחדש (אם זה לא נעשה, מצב האשכול יימחק בכל פעם שהפוד יופעל מחדש, מה שלא יהיה טוב אפילו להתקנת Kubernetes מינימלית).

התקנו hostNetwork: true. הגדרה זו, באופן לא מפתיע, מגדירה את etcd להשתמש ברשת המארח במקום ברשת הפנימית של הפוד (זה יקל על שרת ה-API למצוא את אשכול ה-etcd).

בדיקה פשוטה מראה ש-etcd אכן פועל על localhost ושומר נתונים בדיסק:

$ curl localhost:2379/version
{"etcdserver":"3.4.3","etcdcluster":"3.4.0"}
$ sudo tree /var/lib/etcd/
/var/lib/etcd/
└── member
    ├── snap
    │   └── db
    └── wal
        ├── 0.tmp
        └── 0000000000000000-0000000000000000.wal

הפעלת שרת ה-API

הפעלת שרת Kubernetes API היא אפילו קלה יותר. הפרמטר היחיד שצריך לעבור הוא --etcd-servers, עושה מה שאתה מצפה:

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    command:
    - kube-apiserver
    - --etcd-servers=http://127.0.0.1:2379
    image: k8s.gcr.io/kube-apiserver:v1.18.5
  hostNetwork: true

מקם את קובץ ה-YAML הזה בספרייה pods, ושרת ה-API יתחיל. בודק עם curl מראה שה-API של Kubernetes מאזין ביציאה 8080 עם גישה פתוחה לחלוטין - אין צורך באימות!

$ curl localhost:8080/healthz
ok
$ curl localhost:8080/api/v1/pods
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/pods",
    "resourceVersion": "59"
  },
  "items": []
}

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

והפתעה נעימה, kubectl עובד מחוץ לקופסה ללא הגדרות נוספות!

$ ./kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:39:24Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
$ ./kubectl get pod
No resources found in default namespace.

בעיה

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

$ ./kubectl get pod -n kube-system
No resources found in kube-system namespace.

התרמילים הסטטיים שיצרנו נעלמו! למעשה, צומת הקובלט שלנו לא מתגלה כלל:

$ ./kubectl get nodes
No resources found in default namespace.

מה הבעיה? אם אתם זוכרים לפני כמה פסקאות, התחלנו את kubelet עם סט פשוט ביותר של פרמטרים של שורת הפקודה, כך שה-kubelet לא יודע איך ליצור קשר עם שרת ה-API ולהודיע ​​לו על מצבו. לאחר לימוד התיעוד, אנו מוצאים את הדגל המתאים:

--kubeconfig string

הנתיב לקובץ kubeconfig, המפרט כיצד להתחבר לשרת ה-API. זמינות --kubeconfig מאפשר מצב שרת API, לא --kubeconfig מאפשר מצב לא מקוון.

כל הזמן הזה, מבלי שידענו זאת, הרצנו את הקובלט ב"מצב לא מקוון". (אם היינו פדנטיים, היינו יכולים לחשוב על קובלט עצמאי כעל "מינימום קייברנטס", אבל זה היה מאוד משעמם). כדי שהקונפיגורציה ה"אמיתית" תעבוד, אנחנו צריכים להעביר את קובץ kubeconfig ל-kubelet כדי שהוא יידע לדבר עם שרת ה-API. למרבה המזל זה די פשוט (מכיוון שאין לנו בעיות אימות או אישורים):

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: http://127.0.0.1:8080
  name: mink8s
contexts:
- context:
    cluster: mink8s
  name: mink8s
current-context: mink8s

שמור את זה בשם kubeconfig.yaml, להרוג את התהליך kubelet והפעל מחדש עם הפרמטרים הדרושים:

$ sudo ./kubelet --pod-manifest-path=pods --kubeconfig=kubeconfig.yaml

(אגב, אם תנסה לגשת ל-API באמצעות curl כשה-kubelet לא פועל, תגלה שהוא עדיין פועל! Kubelet הוא לא "הורה" של הפודים שלו כמו Docker, זה יותר כמו "שליטה" דמון." מיכלים המנוהלים על ידי קובלט ימשיכו לפעול עד שהקובלט יעצור אותם.)

בעוד כמה דקות kubectl צריך להראות לנו את התרמילים והצמתים כפי שאנו מצפים:

$ ./kubectl get pods -A
NAMESPACE     NAME                    READY   STATUS             RESTARTS   AGE
default       hello-mink8s            0/1     CrashLoopBackOff   261        21h
kube-system   etcd-mink8s             1/1     Running            0          21h
kube-system   kube-apiserver-mink8s   1/1     Running            0          21h
$ ./kubectl get nodes -owide
NAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
mink8s   Ready    <none>   21h   v1.18.5   10.70.10.228   <none>        Ubuntu 18.04.4 LTS   4.15.0-109-generic   docker://19.3.6

בואו באמת נברך את עצמנו הפעם (אני יודע שכבר בירכתי את עצמנו) - יש לנו "אשכול" מינימלי של Kubernetes שרץ עם API מתפקד במלואו!

אנחנו משיקים תחת

עכשיו בואו נראה למה ה-API מסוגל. נתחיל עם תרמיל nginx:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx

כאן אנו מקבלים שגיאה מעניינת למדי:

$ ./kubectl apply -f nginx.yaml
Error from server (Forbidden): error when creating "nginx.yaml": pods "nginx" is
forbidden: error looking up service account default/default: serviceaccount
"default" not found
$ ./kubectl get serviceaccounts
No resources found in default namespace.

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

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
EOS
serviceaccount/default created
$ ./kubectl apply -f nginx.yaml
Error from server (ServerTimeout): error when creating "nginx.yaml": No API
token found for service account "default", retry after the token is
automatically created and added to the service account

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

נוכל לעקוף בעיה זו על ידי הגדרת האפשרות automountServiceAccountToken עבור חשבון השירות (מכיוון שלא נצטרך להשתמש בו בכל מקרה):

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
automountServiceAccountToken: false
EOS
serviceaccount/default configured
$ ./kubectl apply -f nginx.yaml
pod/nginx created
$ ./kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   0/1     Pending   0          13m

סוף סוף, התרמיל הופיע! אבל למעשה זה לא יתחיל כי אין לנו מְתַכנֵן (לוח זמנים) הוא מרכיב חשוב נוסף של Kubernetes. שוב, אנו רואים שה-Kubernetes API הוא "טיפש" באופן מפתיע - כשאתה יוצר Pod ב-API, הוא רושם אותו, אבל לא מנסה להבין באיזה צומת להפעיל אותו.

למעשה, אתה לא צריך מתזמן כדי להפעיל פוד. אתה יכול להוסיף ידנית צומת למניפסט בפרמטר nodeName:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
  nodeName: mink8s

(החלף mink8s לשם הצומת.) לאחר המחיקה וההחלה, אנו רואים ש-nginx התחיל ומאזין לכתובת ה-IP הפנימית:

$ ./kubectl delete pod nginx
pod "nginx" deleted
$ ./kubectl apply -f nginx.yaml
pod/nginx created
$ ./kubectl get pods -owide
NAME    READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          30s   172.17.0.2   mink8s   <none>           <none>
$ curl -s 172.17.0.2 | head -4
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

כדי לוודא שהרשת בין התרמילים פועלת כהלכה, נוכל להריץ את ה-Curl מפוד אחר:

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
  - image: curlimages/curl
    name: curl
    command: ["curl", "172.17.0.2"]
  nodeName: mink8s
EOS
pod/curl created
$ ./kubectl logs curl | head -6
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

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

הַצלָחָה!

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

• הפוד מנוהל באמצעות ה-API הרגיל של Kubernetes (עם כמה פריצות)
• אתה יכול להעלות ולנהל תמונות מכילות ציבוריות
• התרמילים נשארים בחיים ומפעילים מחדש באופן אוטומטי
• רשת בין תרמילים בתוך אותו צומת עובד די טוב
• ConfigMap, הרכבת אחסון סודית ופשוטה פועלת כצפוי

אבל הרבה ממה שהופך את Kubernetes לשימושי באמת עדיין חסר, כגון:

• מתזמן תרמילים
• אימות/הרשאה
• מספר צמתים
• רשת שירותים
• DNS פנימי מקובץ
• בקרים לחשבונות שירות, פריסות, אינטגרציה עם ספקי ענן ורוב הדברים הטובים האחרים ש-Kubernetes מביאה

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

למד עוד על הקורס בסמינר המקוון החינמי.

קרא עוד:

• מדוע מנהלי מערכת, מפתחים ובודקים צריכים ללמוד שיטות DevOps?
• Thanos - פרומתאוס ניתן להרחבה
• כיצד צוות GitLab QA משתמש בכלי הביצועים של GitLab
• לוקי - איסוף יומנים בגישת פרומתאוס
• יום בחייו של DevOps

מקור: www.habr.com