🥇I-Kubernetes Esebenzayo Encane

Ukuhunyushwa kwesihloko kwalungiselelwa ngobusuku bangaphambi kokuqala kwesifundo "Imikhuba namathuluzi we-DevOps".

Uma ufunda lokhu, cishe uzwile okuthile nge-Kubernetes (futhi uma kungenjalo, ufinyelele kanjani lapha?) Kodwa yini ngempela i-Kubernetes? Lokhu "I-Orchestration yeziqukathi ezisezingeni lezimboni"? Noma "I-Cloud-Native Operating System"? Ngabe kusho ukuthini lokhu?

Uma ngikhuluma iqiniso, angiqiniseki ngo-100%. Kodwa ngicabanga ukuthi kuyathakazelisa ukumba kwabangaphakathi futhi ubone ukuthi kwenzekani ngempela e-Kubernetes ngaphansi kwezingqimba zayo eziningi zokungafinyeleli. Ngakho-ke ukuze sizijabulise, ake sibheke ukuthi i-“Kubernetes cluster” encane ibukeka kanjani ngempela. (Lokhu kuzoba lula kakhulu kunalokho Kubernetes The Hard Way.)

Ngicabanga ukuthi unolwazi oluyisisekelo lwe-Kubernetes, Linux, neziqukathi. Konke esikhuluma ngakho lapha kungokwezinjongo zocwaningo/zokufunda kuphela, ungafaki okunye kwakho ekukhiqizeni!

Uhlolojikelele

I-Kubernetes iqukethe izingxenye eziningi. Ngokuvumelana ne I-Wikipedia, i-architecture ibukeka kanje:

Okungenani kunezingxenye eziyisishiyagalombili eziboniswe lapha, kodwa sizoziba eziningi zazo. Ngifuna ukusho ukuthi into encane engabizwa ngokunengqondo ngokuthi i-Kubernetes iqukethe izingxenye ezintathu ezibalulekile:

kubelet
kube-apiserver (okuncike etcd - database yayo)
isikhathi sokusebenza sesiqukathi (i-Docker kuleli cala)

Ake sibone ukuthi imibhalo ithini ngomunye wabo (gijima., IsiNgisi.). Ekuqaleni kubelet:

I-ejenti egijima endaweni ngayinye ku-cluster. Iqinisekisa ukuthi iziqukathi ziyasebenza kuphod.

Kuzwakala kulula ngokwanele. Mayelana nani izikhathi zokusebenza zesitsha (isikhathi sokusebenza kwesitsha)?

Isikhathi sokusebenza sesiqukathi wuhlelo oluklanyelwe ukusebenzisa iziqukathi.

Inolwazi kakhulu. Kepha uma ujwayelene ne-Docker, kufanele ube nombono ojwayelekile walokho ekwenzayo. (Imininingwane yokwehlukaniswa kwezibopho phakathi kwesikhathi sokusebenza esitsheni kanye ne-kubelet empeleni icashile futhi ngeke ngingene kuyo lapha.)

И Iseva ye-API?

Iseva ye-API ingxenye yephaneli yokulawula ye-Kubernetes edalula i-Kubernetes API. Iseva ye-API iwuhlangothi lweklayenti lephaneli yokulawula ye-Kubernetes

Noma ubani oke wenza noma yini nge-Kubernetes kudingeke ukuthi axhumane ne-API ngokuqondile noma nge-kubectl. Lena inhliziyo yalokho okwenza u-Kubernetes Kubernetes - ubuchopho obuguqula izintaba ze-YAML sonke esizaziyo nesibathandayo (?) zibe ingqalasizinda esebenzayo. Kubonakala kusobala ukuthi i-API kufanele ibe khona ekucushweni kwethu okuncane.

Preconditions

Umshini obonakalayo we-Linux noma ophathekayo onokufinyelela kwezimpande (ngisebenzisa Ubuntu 18.04 emshinini obonakalayo).
Futhi konke!

Ukufakwa okuyisicefe

Sidinga ukufaka i-Docker emshinini esizowusebenzisa. (Ngeke ngingene ngemininingwane yokuthi i-Docker neziqukathi zisebenza kanjani; uma unentshisekelo, kukhona izihloko ezimangalisayo). Asivele siyifake nayo apt:

$ sudo apt install docker.io
$ sudo systemctl start docker

Ngemuva kwalokho, sidinga ukuthola amabhanari we-Kubernetes. Eqinisweni, ekuqalisweni kokuqala "kweqoqo" lethu sidinga kuphela kubelet, kusukela ukuze siqalise ezinye izingxenye zeseva esingazisebenzisa kubelet. Ukuze sihlanganyele neqoqo lethu ngemva kokuba seliqalile, sizolisebenzisa futhi 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

Kwenzekani uma sigijima nje kubelet?

$ ./kubelet
F0609 04:03:29.105194    4583 server.go:254] mkdir /var/lib/kubelet: permission denied

kubelet kumele isebenze njengempande. Inengqondo impela, ngoba idinga ukuphatha yonke i-node. Ake sibheke amapharamitha ayo:

$ ./kubelet -h
<слишком много строк, чтобы разместить здесь>
$ ./kubelet -h | wc -l
284

Hawu, izinketho eziningi! Ngenhlanhla, sidinga ezimbalwa zazo kuphela. Nansi enye yamapharamitha esinentshisekelo kuwo:

--pod-manifest-path string

Indlela eya kuhla lwemibhalo oluqukethe amafayela ama-pod amile, noma indlela eya efayeleni elichaza ama-pod amile. Amafayela aqala ngamachashazi azitshwa. (AKUKHISHIWE: Le nketho kufanele isethwe kufayela lokumisa elidluliselwe ku-Kubelet ngenketho --config. Ukuze uthole ulwazi olwengeziwe, bona kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

Le nketho isivumela ukuthi sisebenze ama-static pods - ama-pods angaphethwe nge-Kubernetes API. Ama-pod amile awavamile ukusetshenziswa, kodwa alungele ukukhulisa ngokushesha iqoqo, futhi yilokhu kanye esikudingayo. Ngeke sisizibe lesi sixwayiso esikhulu (futhi, ungakusebenzisi lokhu ekukhiqizeni!) futhi sibone ukuthi singakwazi yini ukwenza i-pod isebenze.

Okokuqala sizokwakha umkhombandlela wama-pod amile futhi sisebenze kubelet:

$ mkdir pods
$ sudo ./kubelet --pod-manifest-path=pods

Bese, kwenye i-terminal/tmux window/noma yini, sizodala i-pod manifest:

$ cat <<EOF > pods/hello.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
  - image: busybox
    name: hello
    command: ["echo", "hello world!"]
EOF

kubelet iqala ukubhala izexwayiso futhi kubonakala sengathi akwenzeki lutho. Kodwa lokho akulona iqiniso! Ake sibheke i-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 Ngifunde i-pod manifest futhi nganikeza i-Docker umyalo wokwethula iziqukathi ezimbalwa ngokuya ngemininingwane yethu. (Uma uzibuza ngesiqukathi "sokuphumula", kungukugebenga kwe-Kubernetes - bheka le bhulogi.) UKubelet uzokwethula ikhonteyina yethu busybox ngomyalo oshiwo futhi izowuqala kabusha unomphela kuze kube yilapho i-pod emile isusiwe.

Zibongele. Sisanda kuqhamuka nenye yezindlela ezidida kakhulu zokukhipha umbhalo kutheminali!

Yethula njll

Inhloso yethu enkulu ukusebenzisa i-Kubernetes API, kodwa ukwenza lokho sidinga ukuqala njll. Ake siqale iqoqo elincane le- etcd ngokubeka izilungiselelo zalo kumkhombandlela we-pods (isibonelo, 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

Uma uke wasebenza ne-Kubernetes, lawa mafayela e-YAML kufanele uwajwayele. Kunamaphuzu amabili kuphela okufanele uwaqaphele lapha:

Sikhweze ifolda yosokhaya /var/lib/etcd ku-pod ukuze idatha njll igcinwe ngemva kokuqala kabusha (uma lokhu kungenziwanga, isimo seqoqo sizosulwa njalo lapho i-pod iqalwa kabusha, okungeke kube kuhle ngisho nasekufakweni okuncane kwe-Kubernetes).

Sifakile hostNetwork: true. Lesi silungiselelo, ngokumangalisayo, silungiselela njlld ukusebenzisa inethiwekhi yomsingathi esikhundleni senethiwekhi yangaphakathi ye-pod (lokhu kuzokwenza kube lula kuseva ye-API ukuthola iqoqo njlld).

Ukuhlola okulula kukhombisa ukuthi njlld isebenza ngempela ku-localhost futhi igcina idatha kudiski:

$ 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

Iqalisa iseva ye-API

Ukusebenzisa iseva ye-Kubernetes API kulula nakakhulu. Ukuphela kwepharamitha okudingeka idluliswe --etcd-servers, yenza lokho okulindele:

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

Beka leli fayela le-YAML ohlwini lwemibhalo pods, futhi iseva ye-API izoqala. Ihlola nge curl ibonisa ukuthi i-Kubernetes API ilalele ku-port 8080 enokufinyelela okuvuleke ngokuphelele - abukho ubuqiniso obudingekayo!

$ curl localhost:8080/healthz
ok
$ curl localhost:8080/api/v1/pods
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/pods",
    "resourceVersion": "59"
  },
  "items": []
}

(Futhi, ungakuqalisi lokhu ekukhiqizeni! Ngimangele kancane ukuthi ukulungiselelwa okuzenzakalelayo akuvikelekile. Kodwa ngicabanga ukuthi lokhu okokwenza ukuthuthukiswa nokuhlola kube lula.)

Futhi, isimangaliso esijabulisayo, i-kubectl isebenza ngaphandle kwebhokisi ngaphandle kwezilungiselelo ezengeziwe!

$ ./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.

Inkinga

Kodwa uma umba ujule kancane, kubonakala sengathi kukhona okungahambi kahle:

$ ./kubectl get pod -n kube-system
No resources found in kube-system namespace.

Amaphodi amile esiwadalile awasekho! Eqinisweni, i-kubelet node yethu ayitholakali nhlobo:

$ ./kubectl get nodes
No resources found in default namespace.

Kwenzenjani? Uma ukhumbula izigaba ezimbalwa ezedlule, siqale i-kubelet ngesethi elula kakhulu yamapharamitha womugqa womyalo, ngakho-ke i-kubelet ayikwazi ukuthintana kanjani neseva ye-API futhi yazise ngesimo sayo. Ngemva kokutadisha imibhalo, sithola ifulege elihambisanayo:

--kubeconfig string

Indlela eya kufayela kubeconfig, ecacisa indlela yokuxhuma kuseva ye-API. Ukutholakala --kubeconfig inika amandla imodi yeseva ye-API, cha --kubeconfig inika amandla imodi yokungaxhunyiwe ku-inthanethi.

Sonke lesi sikhathi, singazi, besisebenzisa i-kubelet “ngemodi engaxhunyiwe ku-inthanethi.” (Ukube besihamba ngezinyawo, besingacabanga nge-kubelet ezimele njengokuthi "i-Kubernetes esebenzayo encane", kodwa lokho bekungaba yisicefe kakhulu). Ukwenza ukumisa "kwangempela" kusebenze, sidinga ukudlulisa ifayela le-kubeconfig ku-kubelet ukuze yazi ukuthi ikhuluma kanjani neseva ye-API. Ngenhlanhla ilula impela (njengoba singenazo izinkinga zokuqinisekisa noma zesitifiketi):

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: http://127.0.0.1:8080
  name: mink8s
contexts:
- context:
    cluster: mink8s
  name: mink8s
current-context: mink8s

Londoloza lokhu njenge kubeconfig.yaml, bulala inqubo kubelet bese uqala kabusha ngamapharamitha adingekayo:

$ sudo ./kubelet --pod-manifest-path=pods --kubeconfig=kubeconfig.yaml

(Ngaphandle kwalokho, uma uzama ukufinyelela i-API nge-curl lapho i-kubelet ingasebenzi, uzothola ukuthi isasebenza! I-Kubelet ayiyena "umzali" wezigxobo zayo ezifana ne-Docker, ifana "nokulawula daemon.” Iziqukathi eziphethwe i-kubelet zizoqhubeka nokusebenza kuze kube yilapho i-kubelet iwamisa.)

Emizuzwini embalwa kubectl kufanele asibonise ama-pods namanodi njengoba silindele:

$ ./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

Asizibongele ngempela kulokhu (Ngiyazi ukuthi sengizibongele kakade) - sine-"cluster" encane ye-Kubernetes esebenza nge-API esebenza ngokugcwele!

Sethula ngaphansi

Manje ake sibone ukuthi i-API ikwazi ukwenzani. Ake siqale nge-nginx pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx

Lapha sithola iphutha elithakazelisa kakhulu:

$ ./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.

Lapha sibona ukuthi indawo yethu ye-Kubernetes ayiphelele ngokudabukisayo - asinawo ama-akhawunti ezinsiza. Ake sizame futhi ngokwenza i-akhawunti yesevisi mathupha futhi sibone ukuthi kwenzekani:

$ 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

Ngisho nalapho sidala i-akhawunti yesevisi mathupha, ithokheni yokuqinisekisa ayikhiqizwa. Njengoba siqhubeka nokuhlola "iqoqo" lethu elincane, sizothola ukuthi izinto eziningi eziwusizo ezivame ukwenzeka ngokuzenzakalelayo zizobe zingekho. Iseva ye-Kubernetes API i-minimalistic impela, ngokuphakamisa okuningi nokulungisa okuzenzakalelayo okwenzeka kuzilawuli ezihlukahlukene nemisebenzi yangemuva engakasebenzi.

Singalungisa le nkinga ngokusetha inketho automountServiceAccountToken nge-akhawunti yesevisi (njengoba ngeke kudingeke siyisebenzise noma kunjalo):

$ 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

Ekugcineni, i-pod isivele! Kodwa empeleni ngeke kuqale ngoba asinakho umhleli (umhleli) ungenye ingxenye ebalulekile ye-Kubernetes. Futhi, siyabona ukuthi i-Kubernetes API "iyisimungulu" ngokumangalisayo - uma udala iPod ku-API, iyabhalisa, kodwa ayizami ukuthola ukuthi iyiphi i-node yokuyisebenzisa.

Eqinisweni, awudingi isihleli ukuze usebenzise i-pod. Ungakwazi ukwengeza mathupha inodi ku-manifest kupharamitha nodeName:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
  nodeName: mink8s

(Faka esikhundleni mink8s egameni lenodi.) Ngemva kokususa nokusebenzisa, siyabona ukuthi i-nginx isiqalile futhi ilalele ikheli le-IP langaphakathi:

$ ./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>

Ukuqinisekisa ukuthi inethiwekhi phakathi kwama-pods isebenza kahle, singasebenzisa i-curl isuka kwenye i-pod:

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

Kuyathakazelisa impela ukumba kule ndawo futhi ubone ukuthi yini esebenzayo nengasebenzi. Ngithole ukuthi i-ConfigMap ne-Secret zisebenza njengoba bekulindelekile, kodwa Isevisi Nokuthunyelwa akwenzi.

Impumelelo!

Lokhu okuthunyelwe kuba kude, ngakho-ke ngizomemezela ukunqoba futhi ngithi lokhu ukucushwa okusebenzayo okungabizwa ngokuthi "Kubernetes". Ukufingqa: amabhanari amane, amapharamitha emigqa yomyalo emihlanu kanye "kuphela" nemigqa engu-45 ye-YAML (hhayi lokho kakhulu ngokwezindinganiso Kubernetes) futhi sinezinto ezimbalwa ezisebenzayo:

Amaphodi aphethwe kusetshenziswa i-Kubernetes API ejwayelekile (enama-hacks ambalwa)
Ungalayisha futhi uphathe izithombe zeziqukathi zomphakathi
Amaphodi ahlala ephila futhi aqale kabusha ngokuzenzakalelayo
Ukuxhumana phakathi kwama-pod ngaphakathi kwe-node efanayo kusebenza kahle kakhulu
I-ConfigMap, Imfihlo nomsebenzi wokukhweza wesitoreji olula njengoba kulindelekile

Kepha okuningi kwalokho okwenza uKubernetes abe usizo ngempela kusashoda, njengokuthi:

I-Pod Scheduler
Ukuqinisekisa/ukugunyazwa
Amanodi amaningi
Inethiwekhi yamasevisi
I-DNS yangaphakathi ehlanganisiwe
Izilawuli zama-akhawunti wesevisi, ukusetshenziswa, ukuhlanganiswa nabahlinzeki bamafu nokunye okuningi okulethwa u-Kubernetes

Pho sitholeni ngempela? I-Kubernetes API, esebenza yodwa, iyinkundla nje yayo isitsha esizenzakalelayo. Awenzi okuningi - kuwumsebenzi wabalawuli abahlukahlukene nabaqhubi abasebenzisa i-API - kodwa inikeza indawo engaguquki yokuzenzakalela.

Funda kabanzi mayelana nesifundo kuwebhu yamahhala.

Funda kabanzi:

Source: www.habr.com

I-Kubernetes Esebenzayo Encane