🥇किमान व्यवहार्य कुबर्नेट्स

लेखाचा अनुवाद अभ्यासक्रम सुरू होण्याच्या आदल्या दिवशी तयार केला होता "DevOps सराव आणि साधने".

जर तुम्ही हे वाचत असाल, तर तुम्ही कदाचित कुबर्नेट्सबद्दल काहीतरी ऐकले असेल (आणि नसल्यास, तुम्ही इथे कसे पोहोचलात?) पण कुबर्नेट्स म्हणजे नक्की काय? या "औद्योगिक दर्जाच्या कंटेनरचे ऑर्केस्ट्रेशन"? किंवा "क्लाउड-नेटिव्ह ऑपरेटिंग सिस्टम"? याचा अर्थ काय?

खरे सांगायचे तर, मला 100% खात्री नाही. परंतु मला वाटते की इंटर्नल्समध्ये खोदणे आणि कुबर्नेट्समध्ये अमूर्ततेच्या अनेक स्तरांखाली खरोखर काय चालले आहे ते पाहणे मनोरंजक आहे. तर फक्त मनोरंजनासाठी, एक किमान “कुबर्नेट्स क्लस्टर” प्रत्यक्षात कसा दिसतो ते पाहू. (हे पेक्षा खूप सोपे होईल कुबर्नेट्स द हार्ड वे.)

मी असे गृहीत धरतो की तुम्हाला कुबर्नेट्स, लिनक्स आणि कंटेनरचे मूलभूत ज्ञान आहे. आम्ही येथे जे काही बोलतो ते फक्त संशोधन/शिकण्याच्या उद्देशाने आहे, त्यातील काहीही उत्पादनात टाकू नका!

विहंगावलोकन

कुबर्नेट्समध्ये अनेक घटक असतात. त्यानुसार विकिपीडिया, आर्किटेक्चर असे दिसते:

येथे किमान आठ घटक दाखवले आहेत, परंतु आम्ही त्यापैकी बहुतेकांकडे दुर्लक्ष करू. मला हे सांगायचे आहे की कुबर्नेट्स म्हणता येईल अशा किमान गोष्टीमध्ये तीन मुख्य घटक असतात:

कुबेलेट
kube-apiserver (जे etcd वर अवलंबून असते - त्याचा डेटाबेस)
कंटेनर रनटाइम (या प्रकरणात डॉकर)

त्या प्रत्येकाबद्दल दस्तऐवजीकरण काय म्हणते ते पाहूया (rus., इंग्रजी.). सुरुवातीला कुबेलेट:

क्लस्टरमधील प्रत्येक नोडवर एक एजंट कार्यरत आहे. पॉडमध्ये कंटेनर चालू आहेत याची खात्री करते.

पुरेसे सोपे वाटते. त्याबद्दल काय कंटेनर रनटाइम्स (कंटेनर रनटाइम)?

कंटेनर रनटाइम हा कंटेनर चालविण्यासाठी डिझाइन केलेला प्रोग्राम आहे.

अतिशय माहितीपूर्ण. परंतु जर तुम्ही डॉकरशी परिचित असाल, तर तुम्हाला ते काय करते याची सामान्य कल्पना असावी. (कंटेनर रनटाइम आणि कुबेलेटमधील जबाबदाऱ्यांच्या पृथक्करणाचे तपशील प्रत्यक्षात खूपच सूक्ष्म आहेत आणि मी येथे त्यामध्ये जाणार नाही.)

И API सर्व्हर?

API सर्व्हर हा Kubernetes नियंत्रण पॅनेल घटक आहे जो Kubernetes API उघड करतो. API सर्व्हर ही Kubernetes नियंत्रण पॅनेलची क्लायंट बाजू आहे

कुबर्नेट्ससोबत ज्याने कधीही काहीही केले असेल त्याला थेट किंवा कुबेक्टलद्वारे API शी संवाद साधावा लागतो. कुबर्नेट्स कुबर्नेट्स बनवणारे हे हृदय आहे - हा मेंदू जो YAML च्या पर्वतांना आपल्या सर्वांना माहित आहे आणि (?) कार्यरत पायाभूत सुविधांमध्ये बदलतो. हे स्पष्ट दिसते की API आमच्या किमान कॉन्फिगरेशनमध्ये उपस्थित असावे.

पूर्व शर्त

रूट ऍक्सेससह लिनक्स व्हर्च्युअल किंवा फिजिकल मशीन (मी व्हर्च्युअल मशीनवर उबंटू 18.04 वापरत आहे).
आणि हे सर्व आहे!

कंटाळवाणे स्थापना

आम्ही वापरत असलेल्या मशीनवर डॉकर स्थापित करणे आवश्यक आहे. (डॉकर आणि कंटेनर कसे कार्य करतात याबद्दल मी तपशीलवार विचार करणार नाही; तुम्हाला स्वारस्य असल्यास, तेथे आहे अप्रतिम लेख). चला फक्त ते स्थापित करूया apt:

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

त्यानंतर, आपल्याला कुबर्नेट्स बायनरी मिळणे आवश्यक आहे. खरं तर, आमच्या "क्लस्टर" च्या प्रारंभिक प्रक्षेपणासाठी आम्हाला फक्त आवश्यक आहे 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

स्टॅटिक पॉड्ससाठी फाइल्स असलेल्या डिरेक्टरीचा मार्ग किंवा स्टॅटिक पॉड्सचे वर्णन करणाऱ्या फाइलचा मार्ग. डॉट्सपासून सुरू होणाऱ्या फाइल्सकडे दुर्लक्ष केले जाते. (नापसंत: हा पर्याय कुबेलेटला --config पर्यायाद्वारे पास केलेल्या कॉन्फिगरेशन फाइलमध्ये सेट करणे आवश्यक आहे. अधिक माहितीसाठी, पहा kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

हा पर्याय आम्हाला चालवण्याची परवानगी देतो स्थिर शेंगा — कुबर्नेट्स API द्वारे व्यवस्थापित न केलेल्या पॉड्स. स्टॅटिक पॉड्स क्वचितच वापरल्या जातात, परंतु क्लस्टर त्वरीत वाढवण्यासाठी ते खूप सोयीस्कर आहेत आणि आपल्याला हेच हवे आहे. आम्ही या मोठ्या चेतावणीकडे दुर्लक्ष करू (पुन्हा, हे उत्पादनात चालवू नका!) आणि आम्ही पॉड चालू करू शकतो का ते पाहू.

प्रथम आपण स्टॅटिक पॉड्ससाठी डिरेक्टरी तयार करू आणि रन करू kubelet:

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

त्यानंतर, दुसर्‍या टर्मिनल/tmux विंडोमध्ये/काहीही, आम्ही पॉड मॅनिफेस्ट तयार करू:

$ 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 मी पॉड मॅनिफेस्ट वाचला आणि डॉकरला आमच्या वैशिष्ट्यांनुसार दोन कंटेनर लॉन्च करण्याची आज्ञा दिली. (तुम्ही "पॉज" कंटेनरबद्दल विचार करत असाल तर, हे कुबर्नेट्स हॅक आहे - पहा हा ब्लॉग.) कुबेलेट आमचा कंटेनर लाँच करेल busybox निर्दिष्ट आदेशासह आणि स्टॅटिक पॉड हटवले जाईपर्यंत ते अनिश्चित काळासाठी रीस्टार्ट करेल.

स्वतःचे अभिनंदन करा. आम्ही आत्ताच टर्मिनलवर मजकूर आउटपुट करण्याचा सर्वात गोंधळात टाकणारा मार्ग शोधून काढला!

लाँच इ

Kubernetes API चालवणे हे आमचे अंतिम ध्येय आहे, परंतु ते करण्यासाठी आम्हाला प्रथम चालवणे आवश्यक आहे इ. पॉड्स डिरेक्टरीमध्ये सेटिंग्ज ठेवून किमान 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

तुम्ही कधी कुबर्नेट्ससोबत काम केले असल्यास, या YAML फाइल्स तुम्हाला परिचित असाव्यात. येथे फक्त दोन मुद्दे लक्षात घेण्यासारखे आहेत:

आम्ही होस्ट फोल्डर माउंट केले आहे /var/lib/etcd पॉडमध्ये जेणेकरुन रीस्टार्ट केल्यानंतर etcd डेटा जतन केला जाईल (जर हे केले नाही, तर प्रत्येक वेळी पॉड रीस्टार्ट केल्यावर क्लस्टर स्थिती मिटवली जाईल, जे कुबेरनेट्सच्या किमान स्थापनेसाठी देखील चांगले होणार नाही).

आम्ही स्थापित केले आहे hostNetwork: true. हे सेटिंग, आश्चर्यकारकपणे, पॉडच्या अंतर्गत नेटवर्कऐवजी होस्ट नेटवर्क वापरण्यासाठी etcd कॉन्फिगर करते (यामुळे 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 कुबर्नेट्स 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 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.

काय झला? तुम्हाला काही परिच्छेद पूर्वी आठवत असल्यास, आम्ही कमांड लाइन पॅरामीटर्सच्या अत्यंत सोप्या सेटसह कुबेलेट सुरू केले, त्यामुळे एपीआय सर्व्हरशी संपर्क कसा साधावा आणि त्याची स्थिती कशी सूचित करावी हे कुबेलेटला कळत नाही. कागदपत्रांचा अभ्यास केल्यानंतर, आम्हाला संबंधित ध्वज सापडतो:

--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 मध्ये प्रवेश करण्याचा प्रयत्न केल्यास, ते अजूनही चालू असल्याचे तुम्हाला आढळेल! कुबेलेट हे डॉकर सारख्या त्याच्या पॉड्सचे "पालक" नाही, ते "नियंत्रण" सारखे आहे. डिमन." कुबेलेटद्वारे व्यवस्थापित केलेले कंटेनर कुबेलेट थांबेपर्यंत चालत राहतील.)

काही मिनिटांत 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

चला या वेळी स्वतःचे अभिनंदन करूया (मला माहित आहे की मी आधीच स्वतःचे अभिनंदन केले आहे) - आमच्याकडे पूर्णतः कार्यशील 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.

येथे आपण पाहतो की आपले कुबर्नेट्स वातावरण किती अपूर्ण आहे - आमच्याकडे सेवांसाठी कोणतेही खाते नाहीत. चला मॅन्युअली सेवा खाते तयार करून पुन्हा प्रयत्न करू आणि काय होते ते पाहू:

$ 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 API आश्चर्यकारकपणे "मूक" आहे - जेव्हा तुम्ही 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>

पॉड्समधील नेटवर्क योग्यरित्या कार्य करत आहे याची खात्री करण्यासाठी, आम्ही दुसर्या पॉडमधून कर्ल चालवू शकतो:

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

या वातावरणात खोदणे आणि काय कार्य करते आणि काय नाही हे पाहणे खूप मनोरंजक आहे. मला आढळले की कॉन्फिगमॅप आणि सिक्रेट अपेक्षेप्रमाणे कार्य करतात, परंतु सेवा आणि उपयोजन करत नाहीत.

यश!

ही पोस्ट लांबत चालली आहे, म्हणून मी विजय घोषित करणार आहे आणि म्हणेन की हे एक व्यवहार्य कॉन्फिगरेशन आहे ज्याला "कुबरनेटेस" म्हटले जाऊ शकते. थोडक्यात: चार बायनरी, पाच कमांड लाइन पॅरामीटर्स आणि YAML च्या "फक्त" 45 ओळी (नाही कुबर्नेट्सच्या मानकांनुसार) आणि आमच्याकडे बर्‍याच गोष्टी कार्यरत आहेत:

शेंगा नियमित कुबर्नेट्स API वापरून व्यवस्थापित केल्या जातात (काही हॅकसह)
तुम्ही सार्वजनिक कंटेनर प्रतिमा अपलोड आणि व्यवस्थापित करू शकता
शेंगा जिवंत राहतात आणि आपोआप रीस्टार्ट होतात
एकाच नोडमधील पॉड्समधील नेटवर्किंग चांगले कार्य करते
अपेक्षेप्रमाणे कॉन्फिगमॅप, गुप्त आणि साधे स्टोरेज माउंटिंग कार्य

परंतु कुबर्नेट्स खरोखर उपयुक्त बनवणारे बरेच काही अद्याप गहाळ आहे, जसे की:

पॉड शेड्यूलर
प्रमाणीकरण/अधिकृतीकरण
एकाधिक नोड्स
सेवांचे नेटवर्क
क्लस्टर केलेले अंतर्गत DNS
सेवा खाती, उपयोजन, क्लाउड प्रदात्यांसह एकीकरण आणि कुबरनेटेस आणलेल्या इतर बहुतेक वस्तूंसाठी नियंत्रक

मग आम्हाला प्रत्यक्षात काय मिळाले? Kubernetes API, स्वतः चालत आहे, हे खरोखर फक्त एक व्यासपीठ आहे कंटेनर ऑटोमेशन. हे फार काही करत नाही - हे API वापरणारे विविध नियंत्रक आणि ऑपरेटरसाठी काम आहे - परंतु ते ऑटोमेशनसाठी सुसंगत वातावरण प्रदान करते.

विनामूल्य वेबिनारमध्ये कोर्सबद्दल अधिक जाणून घ्या.

पुढे वाचा:

स्त्रोत: www.habr.com

किमान व्यवहार्य Kubernetes