🥇მინიმუმ სიცოცხლისუნარიანი Kubernetes

სტატიის თარგმანი მომზადდა კურსის დაწყების წინა დღეს "DevOps პრაქტიკა და ინსტრუმენტები".

თუ ამას კითხულობთ, ალბათ გსმენიათ რაღაც Kubernetes-ის შესახებ (და თუ არა, როგორ მოხვდით აქ?) მაგრამ კონკრეტულად რა არის Kubernetes? ეს "სამრეწველო კლასის კონტეინერების ორკესტრირება"? ან "Cloud-Native ოპერაციული სისტემა"? ეს საერთოდ რას ნიშნავს?

მართალი გითხრათ, 100%-ით არ ვარ დარწმუნებული. მაგრამ ვფიქრობ, საინტერესოა შინაგანში ჩაღრმავება და იმის დანახვა, თუ რა ხდება რეალურად კუბერნეტში მისი აბსტრაქციების მრავალი ფენის ქვეშ. ასე რომ, უბრალოდ გასართობად, მოდით შევხედოთ რეალურად როგორ გამოიყურება მინიმალური „კუბერნეტის კლასტერი“. (ეს ბევრად უფრო ადვილი იქნება, ვიდრე Kubernetes რთული გზა.)

ვფიქრობ, თქვენ გაქვთ Kubernetes, Linux და კონტეინერების საბაზისო ცოდნა. ყველაფერი, რაზეც აქ ვსაუბრობთ, მხოლოდ კვლევითი/სასწავლო მიზნებისთვისაა, ნუ გამოიტანთ მათ წარმოებაში!

განიხილოს

Kubernetes შეიცავს ბევრ კომპონენტს. Მიხედვით ვიკიპედიაარქიტექტურა ასე გამოიყურება:

აქ ნაჩვენებია მინიმუმ რვა კომპონენტი, მაგრამ ჩვენ უგულებელვყოფთ მათ უმეტესობას. მინდა განვაცხადო, რომ მინიმალური რამ, რასაც გონივრულად შეიძლება ვუწოდოთ Kubernetes, შედგება სამი ძირითადი კომპონენტისგან:

კუბელეტი
kube-apiserver (რომელიც დამოკიდებულია etcd-ზე - მისი მონაცემთა ბაზა)
კონტეინერის მუშაობის დრო (ამ შემთხვევაში Docker)

ვნახოთ, რას ამბობს დოკუმენტაცია თითოეულ მათგანზე (რუსი., ინგლისური.). Პირველად კუბელეტი:

აგენტი, რომელიც მუშაობს კლასტერის თითოეულ კვანძზე. ის დარწმუნდება, რომ კონტეინერები გაშვებულია პოდში.

საკმარისად მარტივად ჟღერს. რაც შეეხება კონტეინერის მუშაობის ვადები (კონტეინერის მუშაობის დრო)?

კონტეინერის გაშვების დრო არის პროგრამა, რომელიც შექმნილია კონტეინერების გასაშვებად.

ძალიან ინფორმატიული. მაგრამ თუ თქვენ იცნობთ Docker-ს, მაშინ უნდა გქონდეთ ზოგადი წარმოდგენა იმის შესახებ, თუ რას აკეთებს იგი. (კონტეინერის მუშაობის დროსა და კუბლეტს შორის პასუხისმგებლობების გამიჯვნის დეტალები, ფაქტობრივად, საკმაოდ დახვეწილია და მათ აქ არ შევალ.)

И 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 ბინარები. სინამდვილეში, ჩვენი "კლასტერის" საწყისი გაშვებისთვის ჩვენ მხოლოდ გვჭირდება 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

Wow, ამდენი ვარიანტი! საბედნიეროდ, ჩვენ მხოლოდ რამდენიმე მათგანი გვჭირდება. აქ არის ერთ-ერთი პარამეტრი, რომელიც გვაინტერესებს:

--pod-manifest-path string

გზა დირექტორიაში, რომელიც შეიცავს ფაილებს სტატიკური პოდებისთვის, ან გზა ფაილისაკენ, რომელიც აღწერს სტატიკური პოდებს. წერტილებით დაწყებული ფაილები იგნორირებულია. (მოძველებულია: ეს პარამეტრი უნდა იყოს დაყენებული კონფიგურაციის ფაილში, რომელიც გადაეცემა Kubelet-ს --config ოფციის მეშვეობით. დამატებითი ინფორმაციისთვის იხ. kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

ეს პარამეტრი გაშვების საშუალებას გვაძლევს სტატიკური ბუდეები - პოდები, რომლებიც არ იმართება Kubernetes API-ით. სტატიკური ბუდეები იშვიათად გამოიყენება, მაგრამ ისინი ძალიან მოსახერხებელია მტევნის სწრაფად ასამაღლებლად და ეს არის ზუსტად ის, რაც ჩვენ გვჭირდება. ჩვენ უგულებელვყოფთ ამ დიდ გაფრთხილებას (კიდევ ერთხელ, არ გაუშვათ ეს წარმოებაში!) და ვნახოთ, შევძლებთ თუ არა პოდის გაშვებას.

პირველ რიგში შევქმნით დირექტორიას სტატიკური პოდებისთვის და გავუშვით kubelet:

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

შემდეგ, სხვა ტერმინალში/tmux ფანჯარაში/რაც არ უნდა იყოს, ჩვენ შევქმნით pod manifest-ს:

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

kubelet იწყებს რაღაც გაფრთხილებების წერას და თითქოს არაფერი ხდება. მაგრამ ეს ასე არ არის! მოდით გადავხედოთ დოკერს:

$ 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 მე წავიკითხე პოდ მანიფესტი და დოკერს მივეცი ბრძანება გაუშვა რამდენიმე კონტეინერი ჩვენი სპეციფიკაციების მიხედვით. (თუ გაინტერესებთ "პაუზის" კონტეინერი, ეს არის Kubernetes-ის ჰაკი - იხ. ეს ბლოგი.) Kubelet გაუშვებს ჩვენს კონტეინერს busybox მითითებული ბრძანებით და გადაიტვირთება განუსაზღვრელი ვადით, სანამ სტატიკური პოდი არ წაიშლება.

მიულოცეთ საკუთარ თავს. ჩვენ ახლახან მოვიფიქრეთ ერთ-ერთი ყველაზე დამაბნეველი გზა ტერმინალში ტექსტის გამოსატანად!

გაშვება და ა.შ

ჩვენი საბოლოო მიზანია Kubernetes API-ის გაშვება, მაგრამ ამისათვის ჯერ უნდა გაუშვათ ა.შ.შ. დავიწყოთ მინიმალური 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 პოდში ისე, რომ etcd მონაცემები შენახული იყოს გადატვირთვის შემდეგ (თუ ეს არ გაკეთებულა, კლასტერის მდგომარეობა წაიშლება ყოველ ჯერზე, როდესაც pod გადაიტვირთება, რაც არ იქნება კარგი თუნდაც მინიმალური Kubernetes ინსტალაციისთვის).

ჩვენ დავაყენეთ hostNetwork: true. ეს პარამეტრი, გასაკვირი არ არის, აკონფიგურირებს etcd-ს, რათა გამოიყენოს მასპინძელი ქსელი pod-ის შიდა ქსელის ნაცვლად (ეს გაუადვილებს API სერვერს etcd კლასტერის პოვნას).

მარტივი შემოწმება აჩვენებს, რომ etcd ნამდვილად მუშაობს ლოკალურ ჰოსტზე და ინახავს მონაცემებს დისკზე:

$ 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.

ჩვენ მიერ შექმნილი სტატიკური ძაფები გაქრა! სინამდვილეში, ჩვენი კუბელეტის კვანძი საერთოდ არ არის აღმოჩენილი:

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

Რა მოხდა? თუ გახსოვთ რამდენიმე აბზაცის წინ, ჩვენ დავიწყეთ kubelet ბრძანების ხაზის პარამეტრების უკიდურესად მარტივი ნაკრებით, ასე რომ, kubelet-მა არ იცის როგორ დაუკავშირდეს API სერვერს და შეატყობინოს მას მისი მდგომარეობის შესახებ. დოკუმენტაციის შესწავლის შემდეგ ვპოულობთ შესაბამის დროშას:

--kubeconfig string

ფაილის გზა kubeconfig, რომელიც განსაზღვრავს API სერვერთან დაკავშირებას. ხელმისაწვდომობა --kubeconfig ჩართავს API სერვერის რეჟიმს, არა --kubeconfig ჩართავს ოფლაინ რეჟიმს.

მთელი ამ ხნის განმავლობაში, ამის ცოდნის გარეშე, ჩვენ ვმართავდით kubelet-ს „ოფლაინ რეჟიმში“. (პედანტურები რომ ვიყოთ, ჩვენ შეგვიძლია ვიფიქროთ დამოუკიდებელი კუბლეტის შესახებ, როგორც "მინიმალური სიცოცხლისუნარიანი კუბერნეტები", მაგრამ ეს ძალიან მოსაწყენი იქნებოდა). იმისათვის, რომ "რეალური" კონფიგურაცია იმუშაოს, ჩვენ უნდა გადავცეთ 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 არ არის მისი პოდების „მშობელი“, როგორც 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 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

მაშინაც კი, როდესაც ჩვენ შევქმენით სერვისის ანგარიში ხელით, ავთენტიფიკაციის ჟეტონი არ არის გენერირებული. როდესაც ჩვენ ვაგრძელებთ ექსპერიმენტებს ჩვენს მინიმალისტურ „კლასტერზე“, აღმოვაჩენთ, რომ უმეტესი სასარგებლო რამ, რაც ჩვეულებრივ ხდება ავტომატურად, აკლია. 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-ში, ის რეგისტრირებს მას, მაგრამ არ ცდილობს გაარკვიოს, რომელ კვანძზე გაუშვას იგი.

ფაქტობრივად, თქვენ არ გჭირდებათ დამგეგმავი პოდის გასაშვებად. თქვენ შეგიძლიათ ხელით დაამატოთ კვანძი მანიფესტში პარამეტრში 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". შეჯამებისთვის: ოთხი ბინარი, ხუთი ბრძანების ხაზი და "მხოლოდ" YAML-ის 45 ხაზი (არა ამდენი Kubernetes-ის სტანდარტებით) და ჩვენ საკმაოდ ბევრი რამ მუშაობს:

Pods იმართება ჩვეულებრივი Kubernetes API-ის გამოყენებით (რამდენიმე ჰაკით)
შეგიძლიათ ატვირთოთ და მართოთ საჯარო კონტეინერის სურათები
Pods რჩება ცოცხალი და ავტომატურად გადაიტვირთება
ერთსა და იმავე კვანძში პოდებს შორის ქსელი საკმაოდ კარგად მუშაობს
ConfigMap, საიდუმლო და მარტივი მეხსიერების მონტაჟი მუშაობს როგორც მოსალოდნელი იყო

მაგრამ ბევრი რამ, რაც Kubernetes-ს მართლაც სასარგებლო ხდის, ჯერ კიდევ აკლია, მაგალითად:

Pod Scheduler
ავთენტიფიკაცია/ავტორიზაცია
მრავალი კვანძი
სერვისების ქსელი
კლასტერირებული შიდა DNS
სერვისის ანგარიშების, განლაგების, ღრუბლოვან პროვაიდერებთან ინტეგრაციის კონტროლერები და კუბერნეტის მიერ მოტანილი სხვა სიკეთეების უმეტესობა

რა მივიღეთ სინამდვილეში? Kubernetes API, რომელიც მუშაობს თავისთავად, ნამდვილად მხოლოდ პლატფორმაა კონტეინერის ავტომატიზაცია. ეს ბევრს არ აკეთებს - ეს არის სამუშაო სხვადასხვა კონტროლერებისა და ოპერატორებისთვის, რომლებიც იყენებენ API - მაგრამ ის უზრუნველყოფს თანმიმდევრულ გარემოს ავტომატიზაციისთვის.

შეიტყვეთ მეტი კურსის შესახებ უფასო ვებინარზე.

დაწვრილებით:

წყარო: www.habr.com

მინიმალური სიცოცხლისუნარიანი Kubernetes

განიხილოს

წინაპირობები

მოსაწყენი ინსტალაცია

გაშვება და ა.შ

API სერვერის გაშვება

პრობლემა

ჩვენ ვიწყებთ ქვეშ

წარმატებები!

დაწვრილებით:

ახალი კომენტარის დამატება

მინიმალური სიცოცხლისუნარიანი Kubernetes

განიხილოს

წინაპირობები

მოსაწყენი ინსტალაცია

გაშვება და ა.შ

API სერვერის გაშვება

პრობლემა

ჩვენ ვიწყებთ ქვეშ

წარმატებები!

დაწვრილებით:

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება