ન્યૂનતમ સધ્ધર કુબરનેટ્સ

લેખનો અનુવાદ કોર્સની શરૂઆતની પૂર્વસંધ્યાએ તૈયાર કરવામાં આવ્યો હતો "DevOps પ્રેક્ટિસ અને ટૂલ્સ".

જો તમે આ વાંચી રહ્યાં છો, તો તમે કદાચ કુબરનેટ્સ વિશે કંઈક સાંભળ્યું હશે (અને જો નહીં, તો તમે અહીં કેવી રીતે પહોંચ્યા?) પરંતુ કુબરનેટ્સ બરાબર શું છે? આ "ઔદ્યોગિક-ગ્રેડ કન્ટેનરનું ઓર્કેસ્ટ્રેશન"? અથવા "ક્લાઉડ-નેટિવ ઓપરેટિંગ સિસ્ટમ"? આનો પણ અર્થ શું છે?

સાચું કહું તો, મને 100% ખાતરી નથી. પરંતુ મને લાગે છે કે આંતરિકમાં ખોદવું અને એબ્સ્ટ્રેક્શનના ઘણા સ્તરો હેઠળ કુબરનેટ્સમાં ખરેખર શું ચાલી રહ્યું છે તે જોવાનું રસપ્રદ છે. તો માત્ર મનોરંજન માટે, ચાલો જોઈએ કે ન્યૂનતમ “કુબરનેટ્સ ક્લસ્ટર” ખરેખર કેવું દેખાય છે. (આ કરતાં ઘણું સરળ હશે કુબરનેટ્સ ધ હાર્ડ વે.)

હું ધારું છું કે તમારી પાસે કુબરનેટ્સ, લિનક્સ અને કન્ટેનરનું મૂળભૂત જ્ઞાન છે. અમે અહીં જે પણ વાત કરીએ છીએ તે ફક્ત સંશોધન/શિક્ષણ હેતુઓ માટે છે, તેમાંથી કોઈ પણ ઉત્પાદનમાં મૂકશો નહીં!

ઝાંખી

કુબરનેટ્સમાં ઘણા ઘટકો છે. અનુસાર વિકિપીડિયા, આર્કિટેક્ચર આના જેવું દેખાય છે:

અહીં ઓછામાં ઓછા આઠ ઘટકો દર્શાવવામાં આવ્યા છે, પરંતુ અમે તેમાંના મોટાભાગનાને અવગણીશું. હું જણાવવા માંગુ છું કે ન્યૂનતમ વસ્તુ જેને વ્યાજબી રીતે કુબરનેટ્સ કહી શકાય તે ત્રણ મુખ્ય ઘટકો ધરાવે છે:

• કુબેલેટ
• kube-apiserver (જે etcd પર આધાર રાખે છે - તેનો ડેટાબેઝ)
• કન્ટેનર રનટાઇમ (આ કિસ્સામાં ડોકર)

ચાલો જોઈએ કે તે દરેક વિશે દસ્તાવેજીકરણ શું કહે છે (rus., અંગ્રેજી.). સૌ પ્રથમ કુબેલેટ:

ક્લસ્ટરમાં દરેક નોડ પર એક એજન્ટ ચાલી રહ્યો છે. તે ખાતરી કરે છે કે પોડમાં કન્ટેનર ચાલી રહ્યું છે.

પર્યાપ્ત સરળ લાગે છે. તે વિષે કન્ટેનર રનટાઇમ્સ (કન્ટેનર રનટાઇમ)?

કન્ટેનર રનટાઈમ એ કન્ટેનર ચલાવવા માટે રચાયેલ પ્રોગ્રામ છે.

ખૂબ જ માહિતીપ્રદ. પરંતુ જો તમે ડોકરથી પરિચિત છો, તો તમારે તે શું કરે છે તેનો સામાન્ય ખ્યાલ હોવો જોઈએ. (કન્ટેનર રનટાઈમ અને કુબેલેટ વચ્ચેની જવાબદારીઓના વિભાજનની વિગતો વાસ્તવમાં ખૂબ જ સૂક્ષ્મ છે અને હું અહીં તેમાં જઈશ નહીં.)

И API સર્વર?

API સર્વર એ Kubernetes નિયંત્રણ પેનલ ઘટક છે જે Kubernetes API ને ખુલ્લું પાડે છે. API સર્વર એ Kubernetes નિયંત્રણ પેનલની ક્લાયન્ટ બાજુ છે

કોઈપણ જેણે ક્યારેય કુબરનેટ્સ સાથે કંઈપણ કર્યું છે તેણે સીધા અથવા ક્યુબેક્ટલ દ્વારા API સાથે સંપર્ક કરવો પડ્યો છે. આ તે હૃદય છે જે કુબરનેટ્સ કુબરનેટ્સ બનાવે છે - મગજ જે 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 વિકલ્પ દ્વારા કુબેલેટને પસાર કરાયેલી રૂપરેખાંકન ફાઈલમાં સેટ કરવો આવશ્યક છે. વધુ માહિતી માટે, જુઓ 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 ઉલ્લેખિત આદેશ સાથે અને સ્થિર પોડ કાઢી નાખવામાં આવે ત્યાં સુધી તેને અનિશ્ચિત સમય માટે પુનઃપ્રારંભ કરશે.

તમારી જાતને અભિનંદન આપો. અમે હમણાં જ ટર્મિનલ પર ટેક્સ્ટને આઉટપુટ કરવાની સૌથી ગૂંચવણભરી રીતોમાંથી એક સાથે આવ્યા છીએ!

લોન્ચ વગેરે

અમારું અંતિમ ધ્યેય કુબરનેટ્સ 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.

શું બાબત છે? જો તમને થોડા ફકરા પહેલા યાદ હોય, તો અમે કમાન્ડ લાઇન પેરામીટર્સના અત્યંત સરળ સેટ સાથે કુબેલેટની શરૂઆત કરી, જેથી ક્યૂબેલેટ એપીઆઈ સર્વરનો સંપર્ક કેવી રીતે કરવો અને તેને તેની સ્થિતિ વિશે જાણ કરવી તે જાણતું નથી. દસ્તાવેજોનો અભ્યાસ કર્યા પછી, અમને અનુરૂપ ધ્વજ મળે છે:

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

છેલ્લે, પોડ દેખાયો છે! પરંતુ હકીકતમાં તે શરૂ થશે નહીં કારણ કે અમારી પાસે નથી આયોજક (શેડ્યુલર) કુબરનેટ્સનું બીજું મહત્વનું ઘટક છે. ફરીથી, આપણે જોઈએ છીએ કે કુબરનેટ્સ 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 અને સિક્રેટ અપેક્ષા મુજબ કામ કરે છે, પરંતુ સર્વિસ અને ડિપ્લોયમેન્ટ નથી કરતા.

સફળતા!

આ પોસ્ટ લાંબી થઈ રહી છે, તેથી હું વિજય જાહેર કરવા જઈ રહ્યો છું અને કહું છું કે આ એક સક્ષમ રૂપરેખાંકન છે જેને "કુબરનેટ્સ" કહી શકાય. સારાંશ માટે: ચાર દ્વિસંગી, પાંચ આદેશ વાક્ય પરિમાણો અને YAML ની ​​"માત્ર" 45 રેખાઓ (નથી કુબરનેટ્સના ધોરણો મુજબ) અને અમારી પાસે થોડીક વસ્તુઓ કામ કરી રહી છે:

• નિયમિત કુબરનેટ્સ API (થોડા હેક્સ સાથે) નો ઉપયોગ કરીને શીંગોનું સંચાલન કરવામાં આવે છે.
• તમે સાર્વજનિક કન્ટેનર છબીઓ અપલોડ અને સંચાલિત કરી શકો છો
• શીંગો જીવંત રહે છે અને આપમેળે પુનઃપ્રારંભ થાય છે
• સમાન નોડની અંદર પોડ્સ વચ્ચે નેટવર્કિંગ ખૂબ સારી રીતે કાર્ય કરે છે
• ConfigMap, સિક્રેટ અને સરળ સ્ટોરેજ માઉન્ટ કરવાનું કામ અપેક્ષા મુજબ

પરંતુ કુબરનેટ્સને ખરેખર ઉપયોગી બનાવે છે તેમાંથી ઘણું બધું હજી ખૂટે છે, જેમ કે:

• પોડ શેડ્યૂલર
• પ્રમાણીકરણ/અધિકૃતતા
• બહુવિધ ગાંઠો
• સેવાઓનું નેટવર્ક
• ક્લસ્ટર્ડ આંતરિક DNS
• સર્વિસ એકાઉન્ટ્સ, ડિપ્લોયમેન્ટ્સ, ક્લાઉડ પ્રદાતાઓ સાથે એકીકરણ અને અન્ય મોટાભાગની ગુડીઝ માટે કંટ્રોલર્સ જે કુબરનેટ્સ લાવે છે

તો આપણે ખરેખર શું મેળવ્યું? Kubernetes API, તેના પોતાના પર ચાલે છે, તે ખરેખર માટે માત્ર એક પ્લેટફોર્મ છે કન્ટેનર ઓટોમેશન. તે ઘણું કામ કરતું નથી - તે API નો ઉપયોગ કરીને વિવિધ નિયંત્રકો અને ઓપરેટરો માટેનું કામ છે - પરંતુ તે ઓટોમેશન માટે સુસંગત વાતાવરણ પૂરું પાડે છે.

મફત વેબિનારમાં કોર્સ વિશે વધુ જાણો.

વધુ વાંચો:

• સિસ્ટમ એડમિનિસ્ટ્રેટર્સ, ડેવલપર્સ અને ટેસ્ટર્સે શા માટે DevOps પ્રેક્ટિસ શીખવી જોઈએ?
• થેનોસ - સ્કેલેબલ પ્રોમિથિયસ
• GitLab QA ટીમ GitLab પરફોર્મન્સ ટૂલનો ઉપયોગ કેવી રીતે કરે છે
• લોકી - પ્રોમિથિયસ અભિગમનો ઉપયોગ કરીને લોગ સંગ્રહ
• DevOps ના જીવનનો એક દિવસ

સોર્સ: www.habr.com