🥇Ελάχιστο βιώσιμο Kubernetes

Η μετάφραση του άρθρου ετοιμάστηκε την παραμονή της έναρξης του μαθήματος "Πρακτικές και εργαλεία DevOps".

Αν διαβάζετε αυτό, πιθανότατα έχετε ακούσει κάτι για το Kubernetes (και αν όχι, πώς καταλήξατε εδώ;) Αλλά τι ακριβώς είναι το Kubernetes; Αυτό «Ενορχήστρωση εμπορευματοκιβωτίων βιομηχανικής ποιότητας»; Ή "Cloud-Native Operating System"? Τι σημαίνει ακόμη αυτό;

Για να είμαι ειλικρινής, δεν είμαι 100% σίγουρος. Αλλά νομίζω ότι είναι ενδιαφέρον να σκάβουμε στα εσωτερικά και να δούμε τι πραγματικά συμβαίνει στο Kubernetes κάτω από τα πολλά στρώματα των αφαιρέσεών του. Για πλάκα λοιπόν, ας ρίξουμε μια ματιά στο πώς μοιάζει στην πραγματικότητα ένα μινιμαλιστικό "cluster Kubernetes". (Αυτό θα είναι πολύ πιο εύκολο από Kubernetes Ο σκληρός τρόπος.)

Υποθέτω ότι έχετε βασικές γνώσεις Kubernetes, Linux και κοντέινερ. Όλα όσα μιλάμε εδώ είναι μόνο για ερευνητικούς/μαθησιακούς σκοπούς, μην τα βάζετε στην παραγωγή!

Αναθεώρηση

Το Kubernetes περιέχει πολλά συστατικά. Σύμφωνα με Βικιπαίδεια, η αρχιτεκτονική μοιάζει με αυτό:

Υπάρχουν τουλάχιστον οκτώ στοιχεία που εμφανίζονται εδώ, αλλά θα αγνοήσουμε τα περισσότερα από αυτά. Θέλω να δηλώσω ότι το ελάχιστο πράγμα που μπορεί εύλογα να ονομαστεί Kubernetes αποτελείται από τρία κύρια συστατικά:

kubelet
kube-apiserver (που εξαρτάται από etcd - τη βάση δεδομένων του)
Χρόνος εκτέλεσης κοντέινερ (Docker σε αυτήν την περίπτωση)

Ας δούμε τι λέει η τεκμηρίωση για καθένα από αυτά (ρωσικός., Αγγλικά.). Αρχικά kubelet:

Ένας πράκτορας που τρέχει σε κάθε κόμβο στο σύμπλεγμα. Διασφαλίζει ότι τα δοχεία τρέχουν στο λοβό.

Ακούγεται αρκετά απλό. Τι θα έλεγες χρόνους λειτουργίας κοντέινερ (χρόνος εκτέλεσης κοντέινερ);

Ένας χρόνος εκτέλεσης κοντέινερ είναι ένα πρόγραμμα που έχει σχεδιαστεί για την εκτέλεση κοντέινερ.

Πολύ κατατοπιστικό. Αλλά αν είστε εξοικειωμένοι με το Docker, τότε θα πρέπει να έχετε μια γενική ιδέα για το τι κάνει. (Οι λεπτομέρειες του διαχωρισμού των ευθυνών μεταξύ του χρόνου εκτέλεσης του κοντέινερ και του kubelet είναι στην πραγματικότητα αρκετά λεπτές και δεν θα αναφερθώ σε αυτές εδώ.)

И Διακομιστής API?

Ο διακομιστής API είναι το στοιχείο του πίνακα ελέγχου Kubernetes που εκθέτει το Kubernetes API. Ο διακομιστής API είναι η πλευρά πελάτη του πίνακα ελέγχου Kubernetes

Όποιος έχει κάνει κάτι με το Kubernetes έπρεπε να αλληλεπιδράσει με το API είτε απευθείας είτε μέσω του kubectl. Αυτή είναι η καρδιά αυτού που κάνει το Kubernetes Kubernetes - τον εγκέφαλο που μετατρέπει τα βουνά του YAML που όλοι γνωρίζουμε και αγαπάμε (;) σε υποδομή εργασίας. Φαίνεται προφανές ότι το API θα πρέπει να υπάρχει στην ελάχιστη διαμόρφωση μας.

Προϋποθέσεις

Εικονική ή φυσική μηχανή Linux με πρόσβαση root (χρησιμοποιώ το Ubuntu 18.04 σε εικονική μηχανή).
Και είναι όλο!

Βαρετή εγκατάσταση

Πρέπει να εγκαταστήσουμε το Docker στο μηχάνημα που θα χρησιμοποιήσουμε. (Δεν πρόκειται να υπεισέλθω σε λεπτομέρειες σχετικά με το πώς λειτουργούν το Docker και τα κοντέινερ. Αν σας ενδιαφέρει, υπάρχει υπέροχα άρθρα). Ας το εγκαταστήσουμε με apt:

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

Μετά από αυτό, πρέπει να πάρουμε τα δυαδικά αρχεία Kubernetes. Στην πραγματικότητα, για την αρχική εκτόξευση του «cluster» μας χρειαζόμαστε μόνο 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 πρέπει να τρέχει ως root. Πολύ λογικό, αφού πρέπει να διαχειριστεί ολόκληρο τον κόμβο. Ας δούμε τις παραμέτρους του:

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

Ουάου, τόσες πολλές επιλογές! Ευτυχώς, χρειαζόμαστε μόνο μερικά από αυτά. Εδώ είναι μια από τις παραμέτρους που μας ενδιαφέρουν:

--pod-manifest-path string

Διαδρομή προς τον κατάλογο που περιέχει αρχεία για στατικά pods ή διαδρομή προς ένα αρχείο που περιγράφει στατικά pods. Τα αρχεία που ξεκινούν με τελείες αγνοούνται. (ΚΑΤΑΡΓΗΘΗΚΕ: Αυτή η επιλογή πρέπει να οριστεί στο αρχείο διαμόρφωσης που μεταβιβάστηκε στο Kubelet μέσω της επιλογής --config. Για περισσότερες πληροφορίες, βλ. kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

Αυτή η επιλογή μας επιτρέπει να τρέξουμε στατικοί λοβοί — pods που δεν διαχειρίζονται μέσω του Kubernetes API. Οι στατικές λοβοί χρησιμοποιούνται σπάνια, αλλά είναι πολύ βολικοί για τη γρήγορη ανύψωση ενός συμπλέγματος, και αυτό ακριβώς χρειαζόμαστε. Θα αγνοήσουμε αυτήν τη μεγάλη προειδοποίηση (και πάλι, μην το εκτελέσετε στην παραγωγή!) και θα δούμε αν μπορούμε να ξεκινήσουμε το pod.

Πρώτα θα δημιουργήσουμε έναν κατάλογο για στατικά pods και θα τρέξουμε kubelet:

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

Στη συνέχεια, σε ένα άλλο παράθυρο terminal/tmux/whatever, θα δημιουργήσουμε μια δήλωση pod:

$ 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 Διάβασα το pod manifest και έδωσα στον Docker την εντολή να εκτοξεύσει μερικά κοντέινερ σύμφωνα με τις προδιαγραφές μας. (Αν αναρωτιέστε για το κοντέινερ "pause", πρόκειται για hack της Kubernetes - βλ. αυτό το blog.) Η Kubelet θα ξεκινήσει το κοντέινερ μας busybox με την καθορισμένη εντολή και θα την επανεκκινήσει επ' αόριστον μέχρι να διαγραφεί το στατικό pod.

Συγχαρητήρια στον εαυτό σου. Μόλις καταλήξαμε σε έναν από τους πιο συγκεχυμένους τρόπους για την έξοδο κειμένου στο τερματικό!

Εκκίνηση κ.λπ

Ο απώτερος στόχος μας είναι να τρέξουμε το Kubernetes API, αλλά για να το κάνουμε αυτό πρέπει πρώτα να τρέξουμε κλπ. Ας ξεκινήσουμε ένα σύμπλεγμα minimal etcd τοποθετώντας τις ρυθμίσεις του στον κατάλογο pods (για παράδειγμα, 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 στο pod έτσι ώστε τα δεδομένα etcd να διατηρούνται μετά από επανεκκίνηση (εάν αυτό δεν γίνει, η κατάσταση του συμπλέγματος θα διαγράφεται κάθε φορά που γίνεται επανεκκίνηση του pod, κάτι που δεν θα είναι καλό ακόμη και για μια ελάχιστη εγκατάσταση Kubernetes).

Έχουμε εγκαταστήσει hostNetwork: true. Αυτή η ρύθμιση, χωρίς έκπληξη, διαμορφώνει το etcd ώστε να χρησιμοποιεί το κεντρικό δίκτυο αντί για το εσωτερικό δίκτυο του pod (αυτό θα διευκολύνει τον διακομιστή 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 δείχνει ότι το Kubernetes API ακούει στη θύρα 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.

Τα στατικά pods που δημιουργήσαμε έχουν φύγει! Στην πραγματικότητα, ο κόμβος μας kubelet δεν ανακαλύπτεται καθόλου:

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

Τι συμβαίνει? Αν θυμάστε μερικές παραγράφους πριν, ξεκινήσαμε το kubelet με ένα εξαιρετικά απλό σύνολο παραμέτρων γραμμής εντολών, έτσι ώστε το kubelet να μην ξέρει πώς να επικοινωνήσει με τον διακομιστή API και να τον ειδοποιήσει για την κατάστασή του. Αφού μελετήσουμε την τεκμηρίωση, βρίσκουμε την αντίστοιχη σημαία:

--kubeconfig string

Η διαδρομή προς το αρχείο kubeconfig, το οποίο καθορίζει τον τρόπο σύνδεσης στον διακομιστή API. Διαθεσιμότητα --kubeconfig ενεργοποιεί τη λειτουργία διακομιστή API, όχι --kubeconfig ενεργοποιεί τη λειτουργία εκτός σύνδεσης.

Όλο αυτό το διάστημα, χωρίς να το γνωρίζουμε, τρέχαμε το kubelet σε "λειτουργία εκτός σύνδεσης". (Αν ήμασταν σχολαστικοί, θα μπορούσαμε να σκεφτούμε ένα αυτόνομο kubelet ως "ελάχιστα βιώσιμα Kubernetes", αλλά αυτό θα ήταν πολύ βαρετό). Για να λειτουργήσει η "πραγματική" διαμόρφωση, πρέπει να περάσουμε το αρχείο 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 δεν είναι «γονέας» των pod του όπως το Docker, είναι περισσότερο σαν ένα «έλεγχος Τα εμπορευματοκιβώτια που διαχειρίζεται ένα kubelet θα συνεχίσουν να λειτουργούν μέχρι να τα σταματήσει το kubelet.)

Σε λίγα λεπτά 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

Ας συγχαρούμε πραγματικά τους εαυτούς μας αυτή τη φορά (ξέρω ότι έχω ήδη δώσει συγχαρητήρια) - έχουμε ένα ελάχιστο "cluster" Kubernetes που τρέχει με ένα πλήρως λειτουργικό API!

Ξεκινάμε κάτω

Τώρα ας δούμε τι είναι ικανό το API. Ας ξεκινήσουμε με το nginx pod:

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

Ακόμη και όταν δημιουργήσαμε τον λογαριασμό υπηρεσίας με μη αυτόματο τρόπο, το διακριτικό ελέγχου ταυτότητας δεν δημιουργείται. Καθώς συνεχίζουμε να πειραματιζόμαστε με το μινιμαλιστικό μας "cluster", θα διαπιστώσουμε ότι τα περισσότερα από τα χρήσιμα πράγματα που συνήθως συμβαίνουν αυτόματα θα λείπουν. Ο διακομιστής Kubernetes API είναι αρκετά μινιμαλιστικός, με το μεγαλύτερο μέρος της ανύψωσης και αυτόματης διαμόρφωσης να συμβαίνει σε διάφορους ελεγκτές και εργασίες παρασκηνίου που δεν εκτελούνται ακόμη.

Μπορούμε να επιλύσουμε αυτό το πρόβλημα ορίζοντας την επιλογή 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, το καταχωρεί, αλλά δεν προσπαθεί να καταλάβει σε ποιον κόμβο να το εκτελέσει.

Στην πραγματικότητα, δεν χρειάζεστε προγραμματιστή για να εκτελέσετε ένα pod. Μπορείτε να προσθέσετε μη αυτόματα έναν κόμβο στο μανιφέστο της παραμέτρου 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>

Για να βεβαιωθούμε ότι το δίκτυο μεταξύ των pod λειτουργεί σωστά, μπορούμε να εκτελέσουμε το curl από άλλο pod:

$ 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 λειτουργούν όπως αναμενόταν, αλλά το Service και το Deployment όχι.

Επιτυχία!

Αυτή η ανάρτηση γίνεται μεγάλη, οπότε θα δηλώσω τη νίκη και θα πω ότι αυτή είναι μια βιώσιμη διαμόρφωση που μπορεί να ονομαστεί "Kubernetes". Για να συνοψίσουμε: τέσσερα δυαδικά αρχεία, πέντε παράμετροι γραμμής εντολών και "μόνο" 45 γραμμές YAML (όχι τόσο κατά τα πρότυπα Kubernetes) και έχουμε αρκετά πράγματα που λειτουργούν:

Η διαχείριση των pods γίνεται χρησιμοποιώντας το κανονικό Kubernetes API (με μερικά hacks)
Μπορείτε να ανεβάσετε και να διαχειριστείτε δημόσια εικόνες κοντέινερ
Τα Pods παραμένουν ζωντανά και επανεκκινούνται αυτόματα
Η δικτύωση μεταξύ pods στον ίδιο κόμβο λειτουργεί αρκετά καλά
Το ConfigMap, το Secret και η απλή τοποθέτηση αποθήκευσης λειτουργούν όπως αναμένεται

Αλλά πολλά από αυτά που κάνουν το Kubernetes πραγματικά χρήσιμο εξακολουθούν να λείπουν, όπως:

Προγραμματιστής Pod
Έλεγχος ταυτότητας/εξουσιοδότηση
Πολλαπλοί κόμβοι
Δίκτυο υπηρεσιών
Συγκεντρωμένο εσωτερικό DNS
Ελεγκτές για λογαριασμούς υπηρεσιών, αναπτύξεις, ενοποίηση με παρόχους cloud και τα περισσότερα από τα άλλα καλούδια που φέρνει η Kubernetes

Τι πήραμε λοιπόν; Το Kubernetes API, που εκτελείται από μόνο του, είναι στην πραγματικότητα απλώς μια πλατφόρμα αυτοματισμός κοντέινερ. Δεν κάνει πολλά - είναι δουλειά για διάφορους ελεγκτές και χειριστές που χρησιμοποιούν το API - αλλά παρέχει ένα συνεπές περιβάλλον για αυτοματισμό.

Μάθετε περισσότερα για το μάθημα στο δωρεάν διαδικτυακό σεμινάριο.

Διαβάστε περισσότερα:

Πηγή: www.habr.com

Ελάχιστο βιώσιμο Kubernetes