🥇 ন্যূনতম কার্যকর কুবারনেটস

নিবন্ধটির অনুবাদ কোর্স শুরুর প্রাক্কালে প্রস্তুত করা হয়েছিল "DevOps অনুশীলন এবং সরঞ্জাম".

আপনি যদি এটি পড়ছেন, আপনি সম্ভবত কুবারনেটস সম্পর্কে কিছু শুনেছেন (এবং যদি না হয় তবে আপনি এখানে কীভাবে শেষ করলেন?) কিন্তু কুবারনেটস আসলে কী? এই "শিল্প-গ্রেড পাত্রে অর্কেস্ট্রেশন"? বা "ক্লাউড-নেটিভ অপারেটিং সিস্টেম"? এই এমনকি মানে কি?

সত্যি বলতে, আমি 100% নিশ্চিত নই। কিন্তু আমি মনে করি অভ্যন্তরীণ অংশে খনন করা এবং কুবারনেটসের বিমূর্ততার অনেক স্তরের অধীনে আসলে কী ঘটছে তা দেখতে আকর্ষণীয়। তাই শুধু মজা করার জন্য, আসুন দেখে নেওয়া যাক একটি ন্যূনতম "কুবারনেটস ক্লাস্টার" আসলে কেমন দেখায়। (এটি এর চেয়ে অনেক সহজ হবে কুবারনেটস দ্য হার্ড ওয়ে.)

আমি ধরে নিচ্ছি আপনার কুবারনেটস, লিনাক্স এবং কন্টেইনার সম্পর্কে প্রাথমিক জ্ঞান আছে। আমরা এখানে যা কিছু কথা বলি তা শুধুমাত্র গবেষণা/শিক্ষার উদ্দেশ্যে, এর কোনোটি উৎপাদনে রাখবেন না!

ওভারভিউ

কুবারনেটে অনেক উপাদান রয়েছে। অনুসারে উইকিপিডিয়া, স্থাপত্য এই মত দেখায়:

এখানে অন্তত আটটি উপাদান দেখানো হয়েছে, কিন্তু আমরা তাদের বেশিরভাগকে উপেক্ষা করব। আমি বলতে চাই যে ন্যূনতম জিনিসটিকে যুক্তিসঙ্গতভাবে কুবারনেটস বলা যেতে পারে তিনটি প্রধান উপাদান নিয়ে গঠিত:

কুবলেট
kube-apiserver (যা etcd-এর উপর নির্ভর করে - এর ডাটাবেস)
কন্টেইনার রানটাইম (এই ক্ষেত্রে ডকার)

আসুন দেখি তাদের প্রতিটি সম্পর্কে ডকুমেন্টেশন কি বলে (rus., ইংরেজি.) প্রথমে কুবলেট:

ক্লাস্টারের প্রতিটি নোডে চলমান একটি এজেন্ট। এটি নিশ্চিত করে যে কন্টেইনারগুলি পডে চলছে।

যথেষ্ট সহজ শোনাচ্ছে. কি সম্পর্কে ধারক রানটাইম (ধারক রানটাইম)?

একটি কন্টেইনার রানটাইম হল একটি প্রোগ্রাম যা কন্টেইনার চালানোর জন্য ডিজাইন করা হয়েছে।

খুবই তথ্যবহুল. তবে আপনি যদি ডকারের সাথে পরিচিত হন তবে এটি কী করে সে সম্পর্কে আপনার একটি সাধারণ ধারণা থাকা উচিত। (কন্টেইনার রানটাইম এবং কুবেলেটের মধ্যে দায়িত্বের বিচ্ছেদের বিবরণ আসলে বেশ সূক্ষ্ম এবং আমি এখানে সেগুলিতে যাব না।)

И API সার্ভার?

API সার্ভার হল Kubernetes কন্ট্রোল প্যানেল উপাদান যা Kubernetes API প্রকাশ করে। API সার্ভার হল Kubernetes কন্ট্রোল প্যানেলের ক্লায়েন্ট সাইড

যে কেউ Kubernetes এর সাথে কিছু করেছে তাকে সরাসরি বা kubectl এর মাধ্যমে API এর সাথে যোগাযোগ করতে হয়েছে। কুবারনেটেস কুবারনেটেস - এই মস্তিষ্ক যা আমরা সকলেই জানি এবং ভালোবাসি (?) ওয়ার্কিং ইনফ্রাস্ট্রাকচারে পরিণত করে। এটা স্পষ্ট মনে হচ্ছে যে 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 .)

এই বিকল্পটি আমাদের চালানোর অনুমতি দেয় স্ট্যাটিক শুঁটি — কুবারনেটস এপিআই-এর মাধ্যমে পরিচালিত নয় এমন পড। স্ট্যাটিক পড খুব কমই ব্যবহার করা হয়, কিন্তু তারা একটি ক্লাস্টার দ্রুত উত্থাপন করার জন্য খুব সুবিধাজনক, এবং এটি ঠিক আমাদের প্রয়োজন। আমরা এই বড় সতর্কবাণী উপেক্ষা করব (আবার, এটিকে উৎপাদনে চালাবেন না!) এবং দেখুন আমরা পড চালু করতে পারি কিনা।

প্রথমে আমরা স্ট্যাটিক পডের জন্য একটি ডিরেক্টরি তৈরি করব এবং রান করব 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 দেখায় যে 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.

কি ব্যাপার? আপনি যদি কিছু অনুচ্ছেদ আগে মনে রাখেন, আমরা কমান্ড লাইন প্যারামিটারের একটি অত্যন্ত সাধারণ সেট দিয়ে কুবেলেট শুরু করেছি, তাই কুবেলেট জানে না কিভাবে API সার্ভারের সাথে যোগাযোগ করতে হয় এবং এটিকে তার অবস্থা সম্পর্কে অবহিত করতে হয়। ডকুমেন্টেশন অধ্যয়ন করার পরে, আমরা সংশ্লিষ্ট পতাকা খুঁজে পাই:

--kubeconfig string

ফাইলের পথ kubeconfig, যা নির্দিষ্ট করে কিভাবে API সার্ভারের সাথে সংযোগ করতে হয়। উপস্থিতি --kubeconfig API সার্ভার মোড সক্ষম করে, না --kubeconfig অফলাইন মোড সক্ষম করে।

এই সমস্ত সময়, এটি না জেনে, আমরা "অফলাইন মোডে" কুবেলেট চালাচ্ছিলাম। (যদি আমরা পেডেন্টিক হতাম, আমরা একটি স্বতন্ত্র কুবেলেটকে "ন্যূনতম কার্যকর কুবারনেটস" হিসাবে ভাবতে পারি, তবে এটি খুব বিরক্তিকর হবে)। "বাস্তব" কনফিগারেশন কাজ করার জন্য, আমাদের kubeconfig ফাইলটি কুবেলেটে পাস করতে হবে যাতে এটি 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

(যাইহোক, কুবেলেট না চলাকালীন আপনি যদি কার্ল এর মাধ্যমে এপিআই অ্যাক্সেস করার চেষ্টা করেন তবে আপনি দেখতে পাবেন যে এটি এখনও চলছে! কুবেলেট ডকারের মতো এর পডগুলির একটি "অভিভাবক" নয়, এটি একটি "নিয়ন্ত্রণের মতো" ডেমন।" কুবেলেট দ্বারা পরিচালিত পাত্রগুলি চলতে থাকবে যতক্ষণ না কুবেলেট তাদের থামায়।)

কয়েক মিনিটের মধ্যে 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.

এখানে আমরা দেখতে পাই যে আমাদের কুবারনেটস পরিবেশ কতটা অসম্পূর্ণ - পরিষেবাগুলির জন্য আমাদের কোনও অ্যাকাউন্ট নেই। ম্যানুয়ালি একটি পরিষেবা অ্যাকাউন্ট তৈরি করে আবার চেষ্টা করুন এবং দেখুন কী হয়:

$ 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 শুরু হয়েছে এবং অভ্যন্তরীণ আইপি ঠিকানা শুনছে:

$ ./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 লাইন (না কুবারনেটসের মান অনুসারে) এবং আমাদের কাছে বেশ কয়েকটি জিনিস কাজ করছে:

নিয়মিত Kubernetes API ব্যবহার করে পডগুলি পরিচালনা করা হয় (কিছু হ্যাক সহ)
আপনি পাবলিক ধারক ছবি আপলোড এবং পরিচালনা করতে পারেন
শুঁটি জীবিত থাকে এবং স্বয়ংক্রিয়ভাবে পুনরায় চালু হয়
একই নোডের মধ্যে পডগুলির মধ্যে নেটওয়ার্কিং বেশ ভাল কাজ করে
কনফিগম্যাপ, সিক্রেট এবং সহজ স্টোরেজ মাউন্টিং কাজ প্রত্যাশিত হিসাবে

কিন্তু কুবারনেটসকে যা সত্যিই দরকারী করে তোলে তার অনেক কিছুই এখনও অনুপস্থিত, যেমন:

পড শিডিউলার
প্রমাণীকরণ/অনুমোদন
একাধিক নোড
পরিষেবার নেটওয়ার্ক
ক্লাস্টার অভ্যন্তরীণ DNS
পরিষেবা অ্যাকাউন্ট, স্থাপনা, ক্লাউড প্রদানকারীদের সাথে একীকরণ এবং কুবারনেটস যে অন্যান্য জিনিসগুলি নিয়ে আসে তার জন্য নিয়ন্ত্রক

তাহলে আমরা আসলে কি পেয়েছি? Kubernetes API, নিজে থেকে চলছে, সত্যিই এর জন্য একটি প্ল্যাটফর্ম ধারক অটোমেশন. এটি অনেক কিছু করে না - এটি API ব্যবহার করে বিভিন্ন কন্ট্রোলার এবং অপারেটরদের জন্য একটি কাজ - তবে এটি অটোমেশনের জন্য একটি সামঞ্জস্যপূর্ণ পরিবেশ প্রদান করে।

বিনামূল্যের ওয়েবিনারে কোর্সটি সম্পর্কে আরও জানুন।

ন্যূনতম কার্যকর কুবারনেটস