🥇 گھٽ ۾ گھٽ قابل عمل ڪبرنيٽس

مضمون جو ترجمو ڪورس جي شروعات جي موقعي تي تيار ڪيو ويو "DevOps طريقا ۽ اوزار".

جيڪڏهن توهان هن کي پڙهي رهيا آهيو، توهان شايد ڪبرنيٽس بابت ڪجهه ٻڌو آهي (۽ جيڪڏهن نه، توهان هتي ڪيئن ختم ڪيو؟) پر اصل ۾ ڪبرنيٽس ڇا آهي؟ هي "صنعتي درجي جي ڪنٽينرز جي آرڪيسٽريشن"؟ يا "Cloud-Native آپريٽنگ سسٽم"؟ اهو به ڇا مطلب آهي؟

ايماندار ٿيڻ لاء، مان 100٪ يقين نه آهيان. پر مان سمجهان ٿو ته اهو دلچسپ آهي داخلي ۾ کڙو ڪرڻ ۽ ڏسو ته حقيقت ۾ ڪبرنيٽس ۾ ان جي ڪيترن ئي پرتن جي خلاصن جي تحت ڇا ٿي رهيو آهي. تنهنڪري صرف مذاق لاء، اچو ته هڪ نظر رکون ته هڪ گهٽ ۾ گهٽ "Kubernetes ڪلستر" اصل ۾ ڪيئن نظر اچي ٿو. (اهو گهڻو آسان ٿيندو ڪبرنيٽس جو سخت رستو.)

مان سمجهان ٿو ته توهان کي ڪبرنيٽس، لينڪس، ۽ ڪنٽينرز جي بنيادي ڄاڻ آهي. اسان هتي جيڪو ڪجهه ڳالهايون ٿا اهو صرف تحقيق / سکيا جي مقصدن لاءِ آهي، ان مان ڪنهن کي به پيداوار ۾ نه وجهي!

جو جائزو

Kubernetes ڪيترن ئي اجزاء تي مشتمل آهي. جي مطابق وڪيپيڊيا، فن تعمير هن طرح نظر اچي ٿو:

هتي گهٽ ۾ گهٽ اٺ جزا ڏيکاريا ويا آهن، پر اسان انهن مان اڪثر کي نظر انداز ڪنداسين. مان اهو چوڻ چاهيان ٿو ته گهٽ ۾ گهٽ شيء جيڪا معقول طور تي Kubernetes سڏيو وڃي ٿو ٽن مکيه حصن تي مشتمل آهي:

ڪوبلٽ
kube-apiserver (جنهن جو دارومدار etcd تي آهي - ان جو ڊيٽابيس)
ڪنٽينر رن ٽائم (هن صورت ۾ ڊڪر)

اچو ته ڏسو ته دستاويز انهن مان هر هڪ بابت ڇا چوندا آهن (rus., انگريزي.) آغاز ۾ ڪوبلٽ:

ڪلستر ۾ هر نوڊ تي هلندڙ هڪ ايجنٽ. اهو يقيني بڻائي ٿو ته ڪنٽينر پوڊ ۾ هلندا آهن.

ڪافي سادو آواز. ڇا جي باري ۾ ڪنٽينر رن ٽائمز (ڪنٽينر رن ٽائم)؟

هڪ ڪنٽينر رن ٽائم هڪ پروگرام آهي جيڪو ڪنٽينرز کي هلائڻ لاءِ ٺهيل آهي.

ڏاڍو معلوماتي. پر جيڪڏهن توهان Docker سان واقف آهيو، ته توهان کي عام خيال هجڻ گهرجي ته اهو ڇا ڪندو آهي. (ڪنٽينر رن ٽائم ۽ ڪوبيليٽ جي وچ ۾ ذميوارين جي علحدگيءَ جا تفصيل اصل ۾ ڪافي ذهين آهن ۽ مان هتي انهن ۾ نه ويندس.)

И API سرور?

API سرور Kubernetes ڪنٽرول پينل جزو آهي جيڪو ڪبرنيٽس API کي ظاهر ڪري ٿو. API سرور ڪلائنٽ طرف آھي Kubernetes ڪنٽرول پينل جو

ڪو به ماڻهو جيڪو ڪڏهن ڪبرنيٽس سان ڪجهه ڪيو آهي ان کي API سان سڌو سنئون يا ڪبيڪٽل ذريعي رابطو ڪرڻو پوندو. اها دل آهي جيڪا ڪبرنيٽس ڪبرنيٽس ٺاهي ٿي - اهو دماغ جيڪو YAML جي جبلن کي ڦيرائي ٿو اسان سڀ ڄاڻون ٿا ۽ پيار ڪريون ٿا (؟) ڪم ڪندڙ انفراسٽرڪچر ۾. اهو ظاهر ٿئي ٿو ته API اسان جي گهٽ ۾ گهٽ تشڪيل ۾ موجود هجڻ گهرجي.

شرطون

لينڪس ورچوئل يا فزيڪل مشين روٽ رسائي سان (مان يوبونٽ 18.04 استعمال ڪري رهيو آهيان ورچوئل مشين تي).
۽ اهو سڀ ڪجهه آهي!

بورنگ تنصيب

اسان کي مشين تي 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

واه، ڪيترائي اختيار! خوش قسمت، اسان کي صرف انهن مان ڪجهه جي ضرورت آهي. هتي انهن مان هڪ آهي جنهن ۾ اسان دلچسپي رکون ٿا:

--pod-manifest-path string

ڊاريڪٽري ڏانهن رستو جنهن ۾ جامد پوڊس لاءِ فائلون شامل آهن، يا جامد پوڊس کي بيان ڪرڻ واري فائل ڏانهن رستو. ڊٽس سان شروع ٿيندڙ فائلن کي نظرانداز ڪيو ويو آهي. (منسوخ ٿيل: هي اختيار لازمي طور تي مقرر ڪيو وڃي configuration فائل ۾ جيڪو ڪيبلٽ ڏانهن موڪليو ويو --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 ڪجهه ڊيڄاريندڙ لکڻ شروع ڪري ٿو ۽ اهو لڳي ٿو ته ڪجهه به نه ٿي رهيو آهي. پر اهو سچ ناهي! اچو ته ڏسو 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 مون پوڊ مينيفيسٽ پڙهيو ۽ ڊاڪر کي حڪم ڏنو ته اسان جي وضاحتن مطابق ڪجهه ڪنٽينر لانچ ڪري. (جيڪڏهن توهان "روڪ" ڪنٽينر بابت سوچي رهيا آهيو، اهو هڪ ڪبرنيٽس هيڪ آهي - ڏسو هي بلاگ.) 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 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 فائل کي 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>

اهو ڪافي دلچسپ آهي ته هن ماحول ۾ کڙو ڪريو ۽ ڏسو ته ڇا ڪم ڪري ٿو ۽ ڇا نٿو ڪري. مون ڏٺو ته ConfigMap ۽ ڳجهي ڪم جيئن توقع ڪئي وئي، پر خدمت ۽ تعیناتي نه.

ڪاميابي!

هي پوسٽ ڊگهي ٿي رهي آهي، تنهنڪري مان فتح جو اعلان ڪرڻ وارو آهيان ۽ چوان ٿو ته هي هڪ قابل عمل ترتيب آهي جنهن کي سڏيو وڃي ٿو "Kubernetes". اختصار ڪرڻ لاء: چار بائنري، پنج ڪمانڊ لائين پيٽرولر ۽ "صرف" YAML جون 45 لائينون (نه معيار جي لحاظ کان گهڻو ڪري Kubernetes) ۽ اسان وٽ ڪافي شيون ڪم ڪري رهيا آهن:

پوڊ منظم ڪيا ويندا آهن باقاعده ڪبرنيٽس API استعمال ڪندي (ڪجهه هيڪس سان)
توھان اپلوڊ ڪري سگھوٿا ۽ انتظام ڪري سگھوٿا عوامي ڪنٽينر تصويرون
پوڊز زنده رهن ٿا ۽ خودڪار طريقي سان ٻيهر شروع ڪريو
ساڳئي نوڊ اندر پوڊ جي وچ ۾ نيٽ ورڪنگ تمام سٺو ڪم ڪري ٿو
ConfigMap، رازداري ۽ سادو اسٽوريج لڳائڻ جو ڪم توقع جي مطابق

پر گهڻو ڪري ڪبرنيٽس کي واقعي مفيد بڻائي ٿو اڃا تائين غائب آهي، جهڙوڪ:

پوڊ شيڊولر
تصديق / اختيار
گهڻن نوڊس
خدمتن جي نيٽ ورڪ
ڪلستر ٿيل اندروني DNS
سروس اڪائونٽس لاءِ ڪنٽرولرز، ڊيپلائيمينٽ، ڪلائوڊ فراهم ڪندڙن سان انضمام ۽ ٻيون گهڻيون شيون جيڪي ڪبرنيٽس کڻي اچن ٿيون

پوءِ اسان کي اصل ۾ ڇا مليو؟ Kubernetes API، پنهنجو پاڻ تي هلندڙ، حقيقت ۾ صرف هڪ پليٽ فارم آهي ڪنٽينر خودڪار. اهو گهڻو ڪجهه نٿو ڪري - اهو API استعمال ڪندي مختلف ڪنٽرولرز ۽ آپريٽرن لاءِ هڪ نوڪري آهي - پر اهو آٽوميشن لاءِ مستقل ماحول فراهم ڪري ٿو.

مفت ويبينار ۾ ڪورس بابت وڌيڪ سکو.

وڌيڪ پڙهو:

جو ذريعو: www.habr.com

گھٽ ۾ گھٽ قابل عمل ڪبرنيٽس