ProHoster > Օրագիր > Վարչակազմը > Նվազագույն կենսունակ Kubernetes

Նվազագույն կենսունակ Kubernetes

Հոդվածի թարգմանությունը պատրաստվել է դասընթացի մեկնարկի նախօրեին «DevOps պրակտիկա և գործիքներ».

Նվազագույն կենսունակ Kubernetes

Եթե ​​դուք կարդում եք սա, հավանաբար ինչ-որ բան եք լսել Kubernetes-ի մասին (և եթե ոչ, ինչպե՞ս եք հայտնվել այստեղ): Բայց իրականում ի՞նչ է Kubernetes-ը: Սա «Արդյունաբերական կարգի բեռնարկղերի կազմակերպում»? Կամ «Cloud-Native օպերացիոն համակարգ»? Ի՞նչ է սա նույնիսկ նշանակում:

Ճիշտն ասած, ես 100%-ով վստահ չեմ: Բայց ես կարծում եմ, որ հետաքրքիր է փորփրել ներքինը և տեսնել, թե իրականում ինչ է կատարվում Kubernetes-ում նրա աբստրակցիայի բազմաթիվ շերտերի ներքո: Այսպիսով, պարզապես զվարճանալու համար, եկեք տեսնենք, թե իրականում ինչ տեսք ունի նվազագույն «Kubernetes կլաստերը»: (Սա շատ ավելի հեշտ կլինի, քան Kubernetes The Hard Way.)

Ենթադրում եմ, որ դուք ունեք հիմնական գիտելիքներ Kubernetes-ի, Linux-ի և կոնտեյներների մասին: Այն ամենը, ինչի մասին մենք խոսում ենք այստեղ, նախատեսված է միայն հետազոտական/ուսուցման նպատակների համար, դրանցից ոչ մեկը արտադրության մեջ մի դրեք:

Վերանայել

Kubernetes-ը պարունակում է բազմաթիվ բաղադրիչներ։ Համաձայն Վիքիպեդիա, ճարտարապետությունն ունի հետևյալ տեսքը.

Նվազագույն կենսունակ Kubernetes

Այստեղ ներկայացված են առնվազն ութ բաղադրիչ, բայց մենք անտեսելու ենք դրանցից շատերը: Ես ուզում եմ նշել, որ նվազագույն բանը, որը կարելի է ողջամտորեն անվանել Kubernetes, բաղկացած է երեք հիմնական բաղադրիչներից.

  • կուբելետ
  • kube-apiserver (որը կախված է etcd-ից՝ դրա տվյալների բազայից)
  • կոնտեյների գործարկման ժամանակ (այս դեպքում Docker)

Տեսնենք, թե ինչ է ասում փաստաթղթերը նրանցից յուրաքանչյուրի մասին (ռուս., Անգլերեն.). Սկզբում կուբելետ:

Կլաստերի յուրաքանչյուր հանգույցի վրա աշխատող գործակալ: Այն ապահովում է, որ բեռնարկղերը աշխատում են պատիճում:

Բավականին պարզ է հնչում: Ինչ մասին բեռնարկղերի աշխատաժամանակներ (կոնտեյների գործարկման ժամանակը):

Կոնտեյների գործարկման ժամանակը ծրագիր է, որը նախատեսված է կոնտեյներներ գործարկելու համար:

Շատ տեղեկատվական: Բայց եթե դուք ծանոթ եք Docker-ին, ապա պետք է ընդհանուր պատկերացում ունենաք այն մասին, թե ինչ է դա անում: (Պատասխանատվությունների տարանջատման մանրամասները կոնտեյների գործարկման ժամանակի և կուբելետի միջև իրականում բավականին նուրբ են, և ես դրանց մեջ չեմ անդրադառնա այստեղ):

И API սերվեր?

API սերվերը Kubernetes կառավարման վահանակի բաղադրիչն է, որը բացահայտում է Kubernetes API-ն: API սերվերը Kubernetes կառավարման վահանակի հաճախորդի կողմն է

Յուրաքանչյուր ոք, ով երբևէ որևէ բան է արել Kubernetes-ի հետ, ստիպված է եղել շփվել API-ի հետ կամ ուղղակիորեն կամ kubectl-ի միջոցով: Սա այն սիրտն է, որը դարձնում է Kubernetes Kubernetes-ը՝ ուղեղը, որը բոլորիս ծանոթ և սիրված YAML լեռները վերածում է աշխատանքային ենթակառուցվածքի: Ակնհայտ է, որ API-ն պետք է ներկա լինի մեր նվազագույն կազմաձևում:

Նախապայմաններ

  • Linux վիրտուալ կամ ֆիզիկական մեքենա՝ արմատային հասանելիությամբ (ես օգտագործում եմ 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 պետք է գործի որպես արմատ: Միանգամայն տրամաբանական է, քանի որ նա պետք է կառավարի ամբողջ հանգույցը: Դիտարկենք դրա պարամետրերը.

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

Wow, այնքան շատ տարբերակներ! Բարեբախտաբար, մեզ միայն մի երկուսն են պետք: Ահա մեզ հետաքրքրող պարամետրերից մեկը.

--pod-manifest-path string

Ճանապարհ դեպի գրացուցակ, որը պարունակում է ստատիկ պատիճների համար նախատեսված ֆայլեր կամ ուղի դեպի ստատիկ պատիճներ նկարագրող ֆայլ: Կետերով սկսվող ֆայլերը անտեսվում են: (ՀԺԱՄԿԵՏ Է. Այս տարբերակը պետք է տեղադրվի Kubelet-ին փոխանցված կազմաձևման ֆայլում --config տարբերակի միջոցով: Լրացուցիչ տեղեկությունների համար տե՛ս. kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

Այս տարբերակը թույլ է տալիս մեզ գործարկել ստատիկ պատիճներ — pods, որոնք չեն կառավարվում 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 սկսում է գրել որոշ նախազգուշացումներ, և թվում է, թե ոչինչ չի կատարվում: Բայց դա ճիշտ չէ։ Եկեք նայենք 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 մանիֆեստը և Docker-ին հրաման տվեցի գործարկել մի քանի կոնտեյներ՝ ըստ մեր բնութագրերի: (Եթե ձեզ հետաքրքրում է «դադար» կոնտեյների մասին, ապա դա 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 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.

Մեր ստեղծած ստատիկ պատյաններն անհետացել են: Փաստորեն, մեր kubelet հանգույցը ընդհանրապես չի հայտնաբերվել.

$ ./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-ը չի աշխատում, կտեսնեք, որ այն դեռ աշխատում է: Kubelet-ը Docker-ի նման իր pod-ների «ծնողը» չէ, այն ավելի շատ նման է «վերահսկիչի»: Դեյմոն»: Կուբելետի կողմից կառավարվող բեռնարկղերը կշարունակեն աշխատել այնքան ժամանակ, մինչև կուբելեթը դադարեցնի դրանք:)

Մի քանի րոպեում 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»: Ամփոփելու համար. չորս երկուական, հինգ հրամանի տողի պարամետր և «ընդամենը» 45 տող YAML (ոչ այդքանը Kubernetes-ի չափանիշներով) և մենք ունենք մի քանի բան, որն աշխատում է.

  • Պոդները կառավարվում են սովորական Kubernetes API-ի միջոցով (մի քանի հաքերով)
  • Դուք կարող եք վերբեռնել և կառավարել հանրային կոնտեյների պատկերները
  • Pods-ը մնում է կենդանի և ավտոմատ կերպով վերսկսվում է
  • Նույն հանգույցի շրջանակների միջև ցանցը բավականին լավ է աշխատում
  • ConfigMap-ը, Գաղտնի և պարզ պահեստային մոնտաժն աշխատում են ինչպես և սպասվում էր

Բայց շատ բան, ինչը Kubernetes-ին իսկապես օգտակար է դարձնում, դեռևս բացակայում է, օրինակ՝

  • Pod Scheduler
  • Նույնականացում/լիազորում
  • Բազմաթիվ հանգույցներ
  • Ծառայությունների ցանց
  • Կլաստերային ներքին DNS
  • Կարգավորիչներ ծառայության հաշիվների, տեղակայումների, ամպային մատակարարների հետ ինտեգրման և Kubernetes-ի կողմից բերված այլ բարիքների մեծ մասի համար

Այսպիսով, ի՞նչ ենք մենք իրականում ստացել: Kubernetes API-ն, որն աշխատում է ինքնուրույն, իրականում պարզապես հարթակ է բեռնարկղերի ավտոմատացում. Այն շատ բան չի անում, դա աշխատանք է տարբեր կարգավորիչների և օպերատորների համար, որոնք օգտագործում են API-ն, բայց այն ապահովում է ավտոմատացման հետևողական միջավայր:

Իմացեք ավելին դասընթացի մասին անվճար վեբինարից:

Ավելին կարդացեք

Source: www.habr.com

Добавить комментарий