🥇குறைந்தபட்ச சாத்தியமான குபர்னெட்ஸ்

இக்கட்டுரையின் மொழியாக்கம் பாடநெறி தொடங்கும் தினத்தன்று தயாரிக்கப்பட்டது "DevOps நடைமுறைகள் மற்றும் கருவிகள்".

நீங்கள் இதைப் படிக்கிறீர்கள் என்றால், நீங்கள் குபெர்னெட்டஸைப் பற்றி ஏதாவது கேள்விப்பட்டிருக்கலாம் (இல்லையென்றால், நீங்கள் எப்படி இங்கு வந்தீர்கள்?) ஆனால் குபர்னெட்டஸ் என்றால் என்ன? இது "தொழில்துறை தர கொள்கலன்களின் ஆர்கெஸ்ட்ரேஷன்"? அல்லது "கிளவுட்-நேட்டிவ் ஆப்பரேட்டிங் சிஸ்டம்"? இதற்கு கூட என்ன அர்த்தம்?

உண்மையைச் சொல்வதானால், எனக்கு 100% உறுதியாகத் தெரியவில்லை. ஆனால் குபெர்னெட்டஸில் அதன் பல அடுக்குகளின் சுருக்கங்களின் கீழ் உண்மையில் என்ன நடக்கிறது என்பதைப் பார்ப்பது இன்டர்னல்களை ஆராய்வது சுவாரஸ்யமானது என்று நான் நினைக்கிறேன். எனவே வேடிக்கைக்காக, குறைந்தபட்ச "குபெர்னெட்ஸ் கிளஸ்டர்" உண்மையில் எப்படி இருக்கும் என்பதைப் பார்ப்போம். (இது மிகவும் எளிதாக இருக்கும் குபெர்னெட்ஸ் தி ஹார்ட் வே.)

குபெர்னெட்ஸ், லினக்ஸ் மற்றும் கொள்கலன்கள் பற்றிய அடிப்படை அறிவு உங்களுக்கு இருப்பதாக நான் கருதுகிறேன். இங்கு நாம் பேசுவது எல்லாம் ஆராய்ச்சி/கற்றல் நோக்கத்திற்காக மட்டுமே, அதில் எதையும் தயாரிப்பில் வைக்காதீர்கள்!

கண்ணோட்டம்

குபெர்னெட்டஸில் பல கூறுகள் உள்ளன. படி விக்கிபீடியா, கட்டிடக்கலை இது போல் தெரிகிறது:

குறைந்தது எட்டு கூறுகள் இங்கே காட்டப்பட்டுள்ளன, ஆனால் அவற்றில் பெரும்பாலானவற்றை நாங்கள் புறக்கணிப்போம். குபெர்னெட்ஸ் என்று நியாயமாக அழைக்கப்படும் குறைந்தபட்ச விஷயம் மூன்று முக்கிய கூறுகளைக் கொண்டுள்ளது என்பதை நான் கூற விரும்புகிறேன்:

கியூப்லெட்
kube-apiserver (இது etcd சார்ந்தது - அதன் தரவுத்தளம்)
கொள்கலன் இயக்க நேரம் (இந்த வழக்கில் டோக்கர்)

ஆவணங்கள் ஒவ்வொன்றையும் பற்றி என்ன சொல்கிறது என்று பார்ப்போம் (ரஸ்., ஆங்கிலம்.). முதலில் கியூப்லெட்:

கிளஸ்டரில் உள்ள ஒவ்வொரு முனையிலும் ஒரு முகவர் இயங்கும். தொட்டியில் கொள்கலன்கள் இயங்குவதை இது உறுதி செய்கிறது.

போதுமான எளிமையான ஒலிகள். என்ன பற்றி கொள்கலன் இயக்க நேரங்கள் (கன்டெய்னர் இயக்க நேரம்)?

கொள்கலன் இயக்க நேரம் என்பது கொள்கலன்களை இயக்க வடிவமைக்கப்பட்ட ஒரு நிரலாகும்.

மிகவும் தகவல். ஆனால் நீங்கள் டோக்கரைப் பற்றி நன்கு அறிந்திருந்தால், அது என்ன செய்கிறது என்பது பற்றிய பொதுவான யோசனை உங்களுக்கு இருக்க வேண்டும். (கன்டெய்னர் இயக்க நேரம் மற்றும் குபெலெட்டுக்கு இடையே உள்ள பொறுப்புகளை பிரிப்பது பற்றிய விவரங்கள் உண்மையில் மிகவும் நுட்பமானவை, அவற்றை நான் இங்கு பார்க்க மாட்டேன்.)

И API சேவையகம்?

ஏபிஐ சர்வர் என்பது குபெர்னெட்ஸ் ஏபிஐயை வெளிப்படுத்தும் குபெர்னெட்ஸ் கண்ட்ரோல் பேனல் கூறு ஆகும். API சேவையகம் குபெர்னெட்ஸ் கட்டுப்பாட்டுப் பலகத்தின் கிளையன்ட் பக்கமாகும்

குபெர்னெட்டஸுடன் எதையும் செய்த எவரும் நேரடியாகவோ அல்லது 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 விருப்பத்தின் மூலம் Kubelet க்கு அனுப்பப்பட்ட உள்ளமைவு கோப்பில் இந்த விருப்பம் அமைக்கப்பட வேண்டும். மேலும் தகவலுக்கு, பார்க்கவும் kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

இந்த விருப்பம் நம்மை இயக்க அனுமதிக்கிறது நிலையான காய்கள் — Kubernetes 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 நான் பாட் மேனிஃபெஸ்டைப் படித்து, எங்கள் விவரக்குறிப்புகளின்படி இரண்டு கொள்கலன்களைத் தொடங்க டோக்கருக்கு கட்டளை கொடுத்தேன். ("இடைநிறுத்தம்" கொள்கலனைப் பற்றி நீங்கள் ஆச்சரியப்படுகிறீர்கள் என்றால், அது ஒரு குபெர்னெட்ஸ் ஹேக் - பார்க்கவும் இந்த வலைப்பதிவு.) Kubelet எங்கள் கொள்கலன் தொடங்கும் busybox குறிப்பிட்ட கட்டளையுடன் மற்றும் நிலையான பாட் நீக்கப்படும் வரை காலவரையின்றி அதை மறுதொடக்கம் செய்யும்.

உங்களை வாழ்த்துங்கள். டெர்மினலுக்கு உரையை வெளியிடுவதற்கான மிகவும் குழப்பமான வழிகளில் ஒன்றை நாங்கள் கண்டுபிடித்துள்ளோம்!

முதலியவற்றை துவக்கவும்

குபெர்னெட்டஸ் 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

நீங்கள் எப்போதாவது Kubernetes உடன் பணிபுரிந்திருந்தால், இந்த YAML கோப்புகள் உங்களுக்கு நன்கு தெரிந்திருக்க வேண்டும். இங்கே கவனிக்க வேண்டிய இரண்டு புள்ளிகள் மட்டுமே உள்ளன:

ஹோஸ்ட் கோப்புறையை ஏற்றியுள்ளோம் /var/lib/etcd மறுதொடக்கத்திற்குப் பிறகு etcd தரவு பாதுகாக்கப்படும் வகையில் பாடில் (இதைச் செய்யாவிட்டால், ஒவ்வொரு முறையும் பாட் மறுதொடக்கம் செய்யப்படும் போது கிளஸ்டர் நிலை அழிக்கப்படும், இது குறைந்தபட்ச குபெர்னெட்டஸ் நிறுவலுக்கு கூட நன்றாக இருக்காது).

நிறுவியுள்ளோம் hostNetwork: true. இந்த அமைப்பு, ஆச்சரியப்படத்தக்க வகையில், பாட்டின் உள் நெட்வொர்க்கிற்குப் பதிலாக ஹோஸ்ட் நெட்வொர்க்கைப் பயன்படுத்த etcd ஐ உள்ளமைக்கிறது (இது etcd கிளஸ்டரைக் கண்டுபிடிப்பதை API சேவையகத்திற்கு எளிதாக்கும்).

ஒரு எளிய சரிபார்ப்பு, 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 ஐத் தொடங்கினோம், எனவே API சேவையகத்தைத் தொடர்புகொண்டு அதன் நிலையை எவ்வாறு அறிவிப்பது என்று kubelet க்கு தெரியாது. ஆவணங்களைப் படித்த பிறகு, தொடர்புடைய கொடியைக் காண்கிறோம்:

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

(அப்படியானால், kubelet இயங்காதபோது கர்ல் வழியாக API ஐ அணுக முயற்சித்தால், அது இன்னும் இயங்குவதை நீங்கள் காண்பீர்கள்! Kubelet அதன் டோக்கர் போன்ற காய்களின் "பெற்றோர்" அல்ல, இது ஒரு "கட்டுப்பாடு" போன்றது. டீமான்.” ஒரு குபெலட் மூலம் நிர்வகிக்கப்படும் கொள்கலன்கள் குபெலெட் அவற்றை நிறுத்தும் வரை தொடர்ந்து இயங்கும்.)

இன்னும் சிறிது நிமிடங்களில் 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

நாங்கள் சேவைக் கணக்கை கைமுறையாக உருவாக்கிய போதும், அங்கீகார டோக்கன் உருவாக்கப்படவில்லை. எங்கள் மிகச்சிறிய "கிளஸ்டரை" நாங்கள் தொடர்ந்து பரிசோதிக்கும்போது, பொதுவாக தானாகவே நிகழும் பெரும்பாலான பயனுள்ள விஷயங்கள் காணாமல் போவதைக் காண்போம். குபெர்னெட்ஸ் ஏபிஐ சேவையகம் மிகவும் சிறியது, அதிக எடை தூக்குதல் மற்றும் தானியங்கி உள்ளமைவுகள் பல்வேறு கட்டுப்படுத்திகள் மற்றும் பின்னணி வேலைகளில் இன்னும் இயங்கவில்லை.

விருப்பத்தை அமைப்பதன் மூலம் இந்த சிக்கலைச் சமாளிக்கலாம் 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 இல் ஒரு Pod ஐ உருவாக்கும்போது, அது அதைப் பதிவு செய்கிறது, ஆனால் அதை எந்த முனையில் இயக்க வேண்டும் என்பதைக் கண்டுபிடிக்க முயற்சிக்கவில்லை.

உண்மையில், ஒரு பாட் இயக்க திட்டமிடுபவர் தேவையில்லை. அளவுருவில் உள்ள மேனிஃபெஸ்டில் நீங்கள் கைமுறையாக ஒரு முனையைச் சேர்க்கலாம் 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>

இந்த சூழலில் தோண்டி என்ன வேலை செய்கிறது மற்றும் எது செய்யாது என்பதைப் பார்ப்பது மிகவும் சுவாரஸ்யமானது. ConfigMap மற்றும் Secret ஆகியவை எதிர்பார்த்தபடி செயல்படுவதைக் கண்டேன், ஆனால் சேவை மற்றும் வரிசைப்படுத்தல் செயல்படவில்லை.

வெற்றி!

இந்த இடுகை நீண்டு கொண்டே செல்கிறது, எனவே நான் வெற்றியை அறிவிக்கப் போகிறேன், இது "குபர்னெட்ஸ்" என்று அழைக்கப்படக்கூடிய ஒரு சாத்தியமான உள்ளமைவு என்று கூறுகிறேன். சுருக்கமாக: நான்கு பைனரிகள், ஐந்து கட்டளை வரி அளவுருக்கள் மற்றும் "மட்டும்" 45 YAML வரிகள் (இல்லை குபெர்னெட்ஸ் தரநிலைகளின்படி) மற்றும் எங்களிடம் சில விஷயங்கள் செயல்படுகின்றன:

வழக்கமான Kubernetes API ஐப் பயன்படுத்தி காய்கள் நிர்வகிக்கப்படுகின்றன (சில ஹேக்குகளுடன்)
பொது கொள்கலன் படங்களை நீங்கள் பதிவேற்றலாம் மற்றும் நிர்வகிக்கலாம்
காய்கள் உயிருடன் இருக்கும் மற்றும் தானாகவே மீண்டும் தொடங்கும்
ஒரே முனையில் உள்ள காய்களுக்கு இடையேயான நெட்வொர்க்கிங் நன்றாக வேலை செய்கிறது
ConfigMap, சீக்ரெட் மற்றும் எளிமையான சேமிப்பு மவுண்டிங் வேலை எதிர்பார்த்தபடி

ஆனால் குபெர்னெட்ஸை உண்மையிலேயே பயனுள்ளதாக மாற்றும் பல விஷயங்கள் இன்னும் காணவில்லை, அவை:

பாட் திட்டமிடுபவர்
அங்கீகாரம்/அங்கீகாரம்
பல முனைகள்
சேவைகளின் நெட்வொர்க்
கிளஸ்டர்டு உள் DNS
சேவைக் கணக்குகளுக்கான கன்ட்ரோலர்கள், வரிசைப்படுத்தல்கள், கிளவுட் வழங்குநர்களுடன் ஒருங்கிணைத்தல் மற்றும் குபெர்னெட்டஸ் கொண்டு வரும் பல இன்னபிற பொருட்கள்

எனவே நாம் உண்மையில் என்ன பெற்றோம்? Kubernetes API, சொந்தமாக இயங்குகிறது, இது உண்மையில் ஒரு தளமாகும் கொள்கலன் ஆட்டோமேஷன். இது அதிகம் செய்யாது - இது API ஐப் பயன்படுத்தும் பல்வேறு கட்டுப்படுத்திகள் மற்றும் ஆபரேட்டர்களுக்கு ஒரு வேலை - ஆனால் இது ஆட்டோமேஷனுக்கான நிலையான சூழலை வழங்குகிறது.

இலவச வெபினாரில் படிப்பைப் பற்றி மேலும் அறியவும்.

மேலும் படிக்க:

ஆதாரம்: www.habr.com

குறைந்தபட்ச சாத்தியமான குபெர்னெட்ஸ்