ഏറ്റവും കുറഞ്ഞ പ്രവർത്തനക്ഷമമായ കുബർനെറ്റുകൾ

കോഴ്‌സ് തുടങ്ങുന്നതിന്റെ തലേന്ന് തയ്യാറാക്കിയതാണ് ലേഖനത്തിന്റെ പരിഭാഷ "DevOps പ്രാക്ടീസുകളും ടൂളുകളും".

നിങ്ങൾ ഇത് വായിക്കുകയാണെങ്കിൽ, നിങ്ങൾ കുബർനെറ്റസിനെ കുറിച്ച് എന്തെങ്കിലും കേട്ടിരിക്കാം (ഇല്ലെങ്കിൽ, നിങ്ങൾ എങ്ങനെ ഇവിടെ എത്തി?) എന്നാൽ യഥാർത്ഥത്തിൽ എന്താണ് കുബർനെറ്റസ്? ഈ "വ്യാവസായിക നിലവാരമുള്ള കണ്ടെയ്നറുകളുടെ ഓർക്കസ്ട്രേഷൻ"? അഥവാ "ക്ലൗഡ്-നേറ്റീവ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം"? ഇത് പോലും എന്താണ് അർത്ഥമാക്കുന്നത്?

സത്യം പറഞ്ഞാൽ, എനിക്ക് 100% ഉറപ്പില്ല. എന്നാൽ ആന്തരികതകളിലേക്ക് കുഴിച്ചിടുന്നത് രസകരമാണെന്ന് ഞാൻ കരുതുന്നു, അതിന്റെ അമൂർത്തതകളുടെ പല പാളികൾക്ക് കീഴിൽ കുബർനെറ്റസിൽ യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന്. അതിനാൽ വിനോദത്തിനായി, ഏറ്റവും കുറഞ്ഞ “കുബർനെറ്റസ് ക്ലസ്റ്റർ” യഥാർത്ഥത്തിൽ എങ്ങനെയുണ്ടെന്ന് നോക്കാം. (ഇത് വളരെ എളുപ്പമായിരിക്കും കുബെർനെറ്റസ് ദി ഹാർഡ് വേ.)

കുബർനെറ്റസ്, ലിനക്സ്, കണ്ടെയ്‌നറുകൾ എന്നിവയെക്കുറിച്ച് നിങ്ങൾക്ക് അടിസ്ഥാന അറിവുണ്ടെന്ന് ഞാൻ കരുതുന്നു. ഞങ്ങൾ ഇവിടെ സംസാരിക്കുന്നതെല്ലാം ഗവേഷണ/പഠന ആവശ്യങ്ങൾക്ക് മാത്രമുള്ളതാണ്, അവയൊന്നും നിർമ്മാണത്തിൽ ഉൾപ്പെടുത്തരുത്!

പൊതു അവലോകനം

കുബർനെറ്റസിൽ നിരവധി ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു. ഇതനുസരിച്ച് വിക്കിപീഡിയ, വാസ്തുവിദ്യ ഇതുപോലെ കാണപ്പെടുന്നു:

കുറഞ്ഞത് എട്ട് ഘടകങ്ങളെങ്കിലും ഇവിടെ കാണിച്ചിട്ടുണ്ട്, എന്നാൽ അവയിൽ മിക്കതും ഞങ്ങൾ അവഗണിക്കും. കുബർനെറ്റസ് എന്ന് ന്യായമായും വിളിക്കാവുന്ന ഏറ്റവും കുറഞ്ഞ കാര്യം മൂന്ന് പ്രധാന ഘടകങ്ങൾ ഉൾക്കൊള്ളുന്നുവെന്ന് ഞാൻ പ്രസ്താവിക്കാൻ ആഗ്രഹിക്കുന്നു:

• കുബെലെറ്റ്
• kube-apiserver (ഇത് etcd-യെ ആശ്രയിച്ചിരിക്കുന്നു - അതിന്റെ ഡാറ്റാബേസ്)
• കണ്ടെയ്നർ റൺടൈം (ഈ സാഹചര്യത്തിൽ ഡോക്കർ)

ഓരോന്നിനെയും കുറിച്ച് ഡോക്യുമെന്റേഷൻ എന്താണ് പറയുന്നതെന്ന് നമുക്ക് നോക്കാം (റസ്., ഇംഗ്ലീഷ്.). ആദ്യം കുബെലെറ്റ്:

ക്ലസ്റ്ററിലെ ഓരോ നോഡിലും പ്രവർത്തിക്കുന്ന ഒരു ഏജന്റ്. പോഡിൽ കണ്ടെയ്‌നറുകൾ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഇത് ഉറപ്പാക്കുന്നു.

വേണ്ടത്ര ലളിതമായി തോന്നുന്നു. എന്തുപറ്റി കണ്ടെയ്നർ റൺടൈമുകൾ (കണ്ടെയ്നർ റൺടൈം)?

കണ്ടെയ്‌നറുകൾ പ്രവർത്തിപ്പിക്കുന്നതിനായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഒരു പ്രോഗ്രാമാണ് കണ്ടെയ്‌നർ റൺടൈം.

വളരെ വിജ്ഞാനപ്രദം. എന്നാൽ നിങ്ങൾക്ക് ഡോക്കറിനെ പരിചയമുണ്ടെങ്കിൽ, അത് എന്താണ് ചെയ്യുന്നതെന്ന് നിങ്ങൾക്ക് പൊതുവായ ഒരു ധാരണ ഉണ്ടായിരിക്കണം. (കണ്ടെയ്‌നർ റൺടൈമും കുബെലെറ്റും തമ്മിലുള്ള ഉത്തരവാദിത്തങ്ങൾ വേർതിരിക്കുന്നതിന്റെ വിശദാംശങ്ങൾ യഥാർത്ഥത്തിൽ വളരെ സൂക്ഷ്മമാണ്, ഞാൻ അവയിലേക്ക് ഇവിടെ കടക്കില്ല.)

И API സെർവർ?

Kubernetes API തുറന്നുകാട്ടുന്ന Kubernetes കൺട്രോൾ പാനൽ ഘടകമാണ് API സെർവർ. കുബർനെറ്റസ് നിയന്ത്രണ പാനലിന്റെ ക്ലയന്റ് വശമാണ് API സെർവർ

Kubernetes-മായി എന്തെങ്കിലും ചെയ്‌തിട്ടുള്ള ആർക്കും API-യുമായി നേരിട്ടോ kubectl വഴിയോ സംവദിക്കേണ്ടതുണ്ട്. ഇതാണ് കുബർനെറ്റസ് കുബർനെറ്റസ് ആക്കുന്നതിന്റെ ഹൃദയം - നമുക്കെല്ലാവർക്കും അറിയാവുന്നതും ഇഷ്ടപ്പെടുന്നതുമായ (?) YAML മലകളെ പ്രവർത്തന അടിസ്ഥാന സൗകര്യങ്ങളാക്കി മാറ്റുന്ന തലച്ചോറ്. ഞങ്ങളുടെ ഏറ്റവും കുറഞ്ഞ കോൺഫിഗറേഷനിൽ API ഉണ്ടായിരിക്കണമെന്ന് വ്യക്തമാണ്.

മുൻവ്യവസ്ഥകൾ

• റൂട്ട് ആക്‌സസ് ഉള്ള Linux വെർച്വൽ അല്ലെങ്കിൽ ഫിസിക്കൽ മെഷീൻ (ഞാൻ ഒരു വെർച്വൽ മെഷീനിൽ ഉബുണ്ടു 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 ഞാൻ പോഡ് മാനിഫെസ്റ്റ് വായിക്കുകയും ഞങ്ങളുടെ സ്പെസിഫിക്കേഷനുകൾക്കനുസരിച്ച് രണ്ട് കണ്ടെയ്നറുകൾ ലോഞ്ച് ചെയ്യാൻ ഡോക്കറിന് കമാൻഡ് നൽകുകയും ചെയ്തു. ("താൽക്കാലികമായി നിർത്തുക" കണ്ടെയ്‌നറിനെ കുറിച്ച് നിങ്ങൾ ആശ്ചര്യപ്പെടുകയാണെങ്കിൽ, ഇത് ഒരു കുബർനെറ്റസ് ഹാക്ക് ആണ് - കാണുക ഈ ബ്ലോഗ്.) കുബെലെറ്റ് ഞങ്ങളുടെ കണ്ടെയ്നർ വിക്ഷേപിക്കും 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

നിങ്ങൾ എപ്പോഴെങ്കിലും Kubernetes-ൽ പ്രവർത്തിച്ചിട്ടുണ്ടെങ്കിൽ, ഈ YAML ഫയലുകൾ നിങ്ങൾക്ക് പരിചിതമായിരിക്കണം. ഇവിടെ ശ്രദ്ധിക്കേണ്ട രണ്ട് പോയിന്റുകൾ മാത്രമേയുള്ളൂ:

ഞങ്ങൾ ഹോസ്റ്റ് ഫോൾഡർ മൌണ്ട് ചെയ്തു /var/lib/etcd പുനരാരംഭിച്ചതിന് ശേഷം etcd ഡാറ്റ സംരക്ഷിക്കപ്പെടുന്ന തരത്തിൽ പോഡിൽ (ഇത് ചെയ്തില്ലെങ്കിൽ, പോഡ് പുനരാരംഭിക്കുമ്പോഴെല്ലാം ക്ലസ്റ്റർ അവസ്ഥ മായ്‌ക്കപ്പെടും, ഇത് ചുരുങ്ങിയ കുബർനെറ്റസ് ഇൻസ്റ്റാളേഷനുപോലും നല്ലതല്ല).

ഞങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്തു hostNetwork: true. ഈ ക്രമീകരണം, പോഡിന്റെ ആന്തരിക നെറ്റ്‌വർക്കിന് പകരം ഹോസ്റ്റ് നെറ്റ്‌വർക്ക് ഉപയോഗിക്കുന്നതിന് etcd കോൺഫിഗർ ചെയ്യുന്നു (ഇത് എപിഐ സെർവറിന് 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 പൂർണ്ണമായും തുറന്ന ആക്‌സസ് ഉള്ള പോർട്ട് 8080-ൽ Kubernetes API ശ്രവിക്കുന്നുണ്ടെന്ന് കാണിക്കുന്നു - ആധികാരികത ആവശ്യമില്ല!

$ 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-ലേക്ക് curl വഴി ആക്സസ് ചെയ്യാൻ ശ്രമിച്ചാൽ, അത് ഇപ്പോഴും പ്രവർത്തിക്കുന്നതായി നിങ്ങൾ കണ്ടെത്തും! 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

ഞങ്ങൾ സേവന അക്കൗണ്ട് സ്വമേധയാ സൃഷ്‌ടിച്ചപ്പോഴും, പ്രാമാണീകരണ ടോക്കൺ ജനറേറ്റുചെയ്യുന്നില്ല. ഞങ്ങളുടെ മിനിമലിസ്റ്റിക് "ക്ലസ്റ്റർ" ഉപയോഗിച്ച് ഞങ്ങൾ പരീക്ഷണം തുടരുമ്പോൾ, സാധാരണയായി യാന്ത്രികമായി സംഭവിക്കുന്ന ഉപയോഗപ്രദമായ മിക്ക കാര്യങ്ങളും നഷ്‌ടമാകുമെന്ന് ഞങ്ങൾ കണ്ടെത്തും. 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>

പോഡുകൾക്കിടയിലുള്ള നെറ്റ്‌വർക്ക് ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ, നമുക്ക് മറ്റൊരു പോഡിൽ നിന്ന് 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>

ഈ പരിതസ്ഥിതിയിൽ കുഴിച്ചെടുത്ത് എന്താണ് പ്രവർത്തിക്കുന്നതെന്നും എന്താണ് പ്രവർത്തിക്കാത്തതെന്നും കാണുന്നത് വളരെ രസകരമാണ്. കോൺഫിഗ്മാപ്പും രഹസ്യവും പ്രതീക്ഷിച്ചതുപോലെ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഞാൻ കണ്ടെത്തി, എന്നാൽ സേവനവും വിന്യാസവും ചെയ്യുന്നില്ല.

വിജയം!

ഈ പോസ്റ്റ് ദൈർഘ്യമേറിയതാണ്, അതിനാൽ ഞാൻ വിജയം പ്രഖ്യാപിക്കാൻ പോകുന്നു, ഇത് "കുബർനെറ്റസ്" എന്ന് വിളിക്കാവുന്ന ഒരു പ്രായോഗിക കോൺഫിഗറേഷനാണെന്ന് പറയാൻ പോകുന്നു. ചുരുക്കത്തിൽ: നാല് ബൈനറികളും അഞ്ച് കമാൻഡ് ലൈൻ പാരാമീറ്ററുകളും YAML-ന്റെ "മാത്രം" 45 വരികളും (അല്ല കുബെർനെറ്റസ് മാനദണ്ഡമനുസരിച്ച്) ഞങ്ങൾക്ക് കുറച്ച് കാര്യങ്ങൾ പ്രവർത്തിക്കുന്നുണ്ട്:

• സാധാരണ കുബർനെറ്റസ് API ഉപയോഗിച്ചാണ് പോഡുകൾ നിയന്ത്രിക്കുന്നത് (കുറച്ച് ഹാക്കുകളോടെ)
• നിങ്ങൾക്ക് പൊതു കണ്ടെയ്‌നർ ചിത്രങ്ങൾ അപ്‌ലോഡ് ചെയ്യാനും നിയന്ത്രിക്കാനും കഴിയും
• പോഡുകൾ സജീവമായി തുടരുകയും സ്വയമേവ പുനരാരംഭിക്കുകയും ചെയ്യുന്നു
• ഒരേ നോഡിനുള്ളിലെ പോഡുകൾ തമ്മിലുള്ള നെറ്റ്‌വർക്കിംഗ് നന്നായി പ്രവർത്തിക്കുന്നു
• കോൺഫിഗ്‌മാപ്പ്, രഹസ്യവും ലളിതവുമായ സ്റ്റോറേജ് മൗണ്ടിംഗ് ജോലികൾ പ്രതീക്ഷിച്ചതുപോലെ

എന്നാൽ കുബർനെറ്റസിനെ ശരിക്കും ഉപയോഗപ്രദമാക്കുന്ന പലതും ഇപ്പോഴും കാണുന്നില്ല, ഇനിപ്പറയുന്നവ:

• പോഡ് ഷെഡ്യൂളർ
• പ്രാമാണീകരണം/അംഗീകാരം
• ഒന്നിലധികം നോഡുകൾ
• സേവന ശൃംഖല
• ക്ലസ്റ്റേർഡ് ഇന്റേണൽ DNS
• സേവന അക്കൗണ്ടുകൾക്കായുള്ള കൺട്രോളറുകൾ, വിന്യാസങ്ങൾ, ക്ലൗഡ് ദാതാക്കളുമായുള്ള സംയോജനം, കുബെർനെറ്റസ് കൊണ്ടുവരുന്ന മറ്റ് മിക്ക ഗുണങ്ങളും

അപ്പോൾ നമുക്ക് യഥാർത്ഥത്തിൽ എന്താണ് ലഭിച്ചത്? സ്വന്തമായി പ്രവർത്തിക്കുന്ന കുബർനെറ്റസ് API ശരിക്കും ഒരു പ്ലാറ്റ്ഫോം മാത്രമാണ് കണ്ടെയ്നർ ഓട്ടോമേഷൻ. ഇത് കൂടുതൽ ഒന്നും ചെയ്യുന്നില്ല - ഇത് API ഉപയോഗിക്കുന്ന വിവിധ കൺട്രോളർമാർക്കും ഓപ്പറേറ്റർമാർക്കും വേണ്ടിയുള്ള ഒരു ജോലിയാണ് - എന്നാൽ ഇത് ഓട്ടോമേഷനായി സ്ഥിരതയുള്ള അന്തരീക്ഷം നൽകുന്നു.

സൗജന്യ വെബിനാറിൽ കോഴ്സിനെക്കുറിച്ച് കൂടുതലറിയുക.

കൂടുതല് വായിക്കുക:

• എന്തുകൊണ്ടാണ് സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാരും ഡവലപ്പർമാരും ടെസ്റ്റർമാരും DevOps രീതികൾ പഠിക്കേണ്ടത്?
• താനോസ് - സ്കേലബിൾ പ്രൊമിത്യൂസ്
• GitLab QA ടീം എങ്ങനെയാണ് GitLab പെർഫോമൻസ് ടൂൾ ഉപയോഗിക്കുന്നത്
• ലോക്കി - പ്രോമിത്യൂസ് സമീപനം ഉപയോഗിച്ചുള്ള ലോഗ് ശേഖരണം
• DevOps-ന്റെ ജീവിതത്തിലെ ഒരു ദിവസം

അവലംബം: www.habr.com