<\/p>\n
Na pocz\u0105tku warto przypomnie\u0107 sobie architektur\u0119 Kubernetes z lotu ptaka<\/p>\n
<\/p>\n
![\"Kubernetes](\"https:\/\/dwmkerr.com\/tips-for-cka\/images\/k8s-architecture.png\")
<\/p>\n
Po lewej stronie mamy wyszczeg\u00f3lnione komponenty control-plane<\/strong> (dawniej master) . Etcd, kube-controller-manager i kube-api-server i kube-scheduler<\/strong> s\u0105 dostarczane w postaci kontener\u00f3w. Po prawej stronie mamy komponenty, kt\u00f3re s\u0105 sk\u0142adow\u0105 w\u0119z\u0142\u00f3w typu worker<\/strong>.\u00a0 Wszelkie komponenty control-plane<\/strong>, opr\u00f3cz kubelet<\/strong>, kt\u00f3ry jest plikiem binarnym odpowiedzialnym za tworzenie i kontrol\u0119 kontener\u00f3w na danym w\u0119\u017ale, s\u0105 w tym rozwi\u0105zaniu dostarczane w postaci skonteneryzowanej.<\/p>\n Patrz\u0105c literalnie na powy\u017cszy obraz mo\u017cna doj\u015b\u0107 do wniosku ze control-plane<\/strong> nie zawiera kubelet<\/strong> i kube-prox<\/strong>y. Nic bardziej b\u0142\u0119dnego. W\u0119ze\u0142 kontrolny mo\u017ce pe\u0142ni\u0107 rol\u0119 w\u0119z\u0142a typu worker<\/strong>. Tak dzia\u0142a np. popularny minikube<\/strong>. Ale taka konfiguracja nie jest stosowana produkcyjnie, gdzie raczej separujemy cz\u0119\u015bci systemowe od aplikacji biznesowych.<\/p>\n <\/p>\n Klaster Kubernetes komunikuje si\u0119 ze \u015bwiatem zewn\u0119trznym przez komponent API-Server<\/strong>.<\/p>\n <\/p>\n Przyk\u0142ad wdro\u017cenia nowego obiektu pod na klastrze, pochodzi on z bloga heptio<\/a> i doskonale pokazuje interakcj\u0119 mi\u0119dzy komponentami klastra.<\/p>\n <\/p>\n <\/p>\n Scheduler w Kubernetes jest niezale\u017cnym komponentem, co wi\u0119cej mo\u017ce by\u0107 ich wi\u0119cej ni\u017c jeden w danym klastrze. W manife\u015bcie obiektu mo\u017cna poda\u0107 nazw\u0119 schedulera, kt\u00f3ry ma przeprowadzi\u0107 ca\u0142y proces wyznaczenia w\u0142a\u015bciwego w\u0119z\u0142a.<\/p>\n Opiszmy jak dzia\u0142a po kolei w bardzo uproszczony spos\u00f3b:<\/p>\n Kiedy tworzymy nowy obiekt typu pod jego manifest jest wysy\u0142any do API-server<\/strong> i zapisany przez niego w bazie etcd<\/strong><\/p>\n Scheduler<\/strong> odpytuje cyklicznie API-Server<\/strong>, czy istniej\u0105 obiekty pod, dla kt\u00f3rych nie okre\u015blono nazwy w\u0119z\u0142a. Obiekty takie trafiaj\u0105 do kolejki.<\/p>\n Scheduler<\/strong> pobiera definicj\u0119 takiego poda i rozpoczyna proces wyznaczenia w\u0119z\u0142a, na kt\u00f3ry ma on trafi\u0107.<\/p>\n Proces taki sk\u0142ada si\u0119 z dw\u00f3ch g\u0142\u00f3wnych krok\u00f3w<\/p>\n a) filtrowania (filter<\/strong>). W tym miejscu wywo\u0142ywana jest grupa funkcji przyjmuj\u0105cych jako argumenty identyfikator obiektu pod i identyfikator w\u0119z\u0142a. Funkcje takie zwracaj\u0105 dla danej pary tylko warto\u015bci prawdy lub fa\u0142szu.<\/p>\n b) punktacja (scoring<\/strong>) W tym miejscu wywo\u0142ywana jest grupa funkcji przyjmuj\u0105cych jako argumenty identyfikator obiektu pod i identyfikator w\u0119z\u0142a. Funkcje takie zwracaj\u0105 ranking dla danej pary w postaci liczby.<\/p>\n Na ko\u0144cu wybierany jest w\u0119ze\u0142, dla kt\u00f3rego uda\u0142o si\u0119 ustali\u0107 dopasowanie z najwi\u0119ksz\u0105 punktacj\u0105.<\/p>\n Wys\u0142any jest komunikat do API-Server<\/strong>,kt\u00f3ry to jest w\u0119ze\u0142. API-Server<\/strong> zleca ustawienie w etcd<\/strong> Kubelet<\/strong> danego w\u0119z\u0142a zabiera si\u0119 do pracy, tworzy i kontroluje mikrous\u0142ug\u0119 i raportuje zwrotnie do API-Server<\/strong> o statusie swojej pracy.<\/p>\n Api-Server<\/strong> zleca zapis konfiguracji do bazy etcd<\/strong>.<\/p>\n <\/p>\n To co nale\u017cy zapami\u0119ta\u0107.<\/p>\n Ten ostatni jest odpowiedzialny za komunikacj\u0119 z silnikiem konteneryzacji, kt\u00f3rym nie musi by\u0107 docker<\/strong>, ale np containerd<\/strong> lub cri-o<\/strong>.\u00a0 Kubelet kontroluje stan mikrous\u0142ug, kt\u00f3re utworzy\u0142, weryfikuje na bie\u017c\u0105co wykorzystanie zasob\u00f3w i w razie potrzeby restartuje je.<\/p>\n <\/p>\n https:\/\/www.tutorialworks.com\/difference-docker-containerd-runc-crio-oci<\/a>\/<\/p>\n <\/p>\n Nie wszystkie obiekty wdra\u017cane na klastrze Kubernetes korzystaj\u0105 z kube-scheduler. Pom\u00f3wmy o dw\u00f3ch przypadkach<\/p>\n <\/p>\n Obiekt daemonset stara si\u0119 wdro\u017cy\u0107 na klastrze stan, w kt\u00f3rym na ka\u017cdym w\u0119\u017ale pojawi si\u0119 dok\u0142adnie jedna instancja obiektu pod.<\/p>\n Je\u017celi chcemy wdro\u017cy\u0107 te obiekty r\u00f3wnie\u017c na w\u0119z\u0142ach control-plane, to nale\u017cy doda\u0107 w manife\u015bcie tolerancj\u0119<\/p>\n <\/p>\n Om\u00f3wimy to dok\u0142adniej w cz\u0119\u015bci praktycznej<\/p>\n <\/p>\n Zobaczmy stan us\u0142ugi kubelet<\/strong> na dowolnym w\u0119\u017ale (control-plane czy worker). Podczas egzaminu mamy do czynienia z dystrybucj\u0105 Ubuntu i klastrami Kubernetes zainstalowanymi za pomoc\u0105 narz\u0119dzie kubeadm<\/strong>. Takie klastry maj\u0105 zainstalowane komponenty systemowe w postaci static pods.<\/p>\n <\/p>\n Przyk\u0142adowy rezultat<\/p>\n Je\u015bli stan nie jest active<\/strong> to mamy problem i taki w\u0119ze\u0142 jest traktowany przez klaster jako notReady. To tyle tytu\u0142em wst\u0119pu do troubleshooting.<\/p>\n Je\u015bli chcemy si\u0119 wi\u0119cej dowiedzie\u0107 o problemach z kubelet, mo\u017cemy skorzysta\u0107 journactl<\/strong>.<\/p>\n <\/p>\n Przyk\u0142adowe logi<\/p>\n <\/p>\n Gdzie kubelet<\/strong> trzyma konfiguracj\u0119 ?<\/p>\n <\/p>\n Sp\u00f3jrzmy na definicje pliku \/etc\/systemd\/system\/kubelet.service.d\/10-kubeadm.conf<\/strong><\/p>\n <\/p>\n To co nas interesuje, to plik konfiguracyjny \/var\/lib\/kubelet\/config.yaml<\/strong><\/p>\n Zobaczmy jego zawarto\u015b\u0107<\/p>\n Jak wida\u0107 konfiguracja jest w postaci pliku YAML<\/p>\n W kontek\u015bcie obiekt\u00f3w static pod nale\u017cy zwr\u00f3ci\u0107 uwag\u0119 na zmienn\u0105 staticPodPath<\/strong><\/p>\n Oczywi\u015bcie mo\u017cemy zapami\u0119ta\u0107 ten\u00a0 adres, z tym, \u017ce mo\u017cna czasem trafi\u0107 na zadanie, gdzie albo nie ma jej skonfigurowanej, albo wskazuje na inny i nieoczywisty katalog.<\/p>\n <\/p>\n Jak w tym schemacie\u00a0 mamy\u00a0 rozumie\u0107, czym w\u0142a\u015bciwie s\u0105 obiekty static pod.<\/p>\n <\/p>\n <\/p>\n Wyobra\u017amy sobie sytuacj\u0119, gdy jeden z w\u0119z\u0142\u00f3w ulega awarii lub chcemy go podda\u0107 konserwacji (instalacja nowych wersji pakiet\u00f3w, niwelacja luk bezpiecze\u0144stwa. itp…).<\/p>\n Symulacj\u0119 takiej awarii mo\u017cna przeprowadzi\u0107 za pomoc\u0105 polecenia kubectl drain node-name<\/strong>.<\/p>\n Obiekty pod, kt\u00f3re zosta\u0142y pouk\u0142adane na w\u0119\u017ale przez scheduler zostan\u0105 z takiego w\u0119z\u0142a eksmitowane (evicted) , ale nie dotyczy to static pods i nie dotyczy obiekt\u00f3w kontrolowanych przez DaemonSet. Je\u015bli na danym w\u0119\u017ale mamy obiekty pod w takiej konfiguracji to jawnie musimy poda\u0107, \u017ce nale\u017cy je zignorowa\u0107<\/p>\n <\/p>\n <\/p>\n O tym postaram si\u0119 dok\u0142adniej napisa\u0107 podczas \u0107wicze\u0144 dotycz\u0105cych instalacji i upgrade klastra za pomoc\u0105 narz\u0119dzie kubeadm.<\/p>\n <\/p>\n Zobaczmy jak wygl\u0105da plik manifestu kube-scheduler.yaml<\/strong><\/p>\n <\/p>\n <\/p>\n To na co nale\u017cy zwr\u00f3ci\u0107 uwag\u0119 to nazwa obiektu w obszarze metadata. name: kube-scheduler, <\/strong>obiekt jest wdro\u017cony w przestrzeni nazw kube-system <\/strong>i nie ma wype\u0142nionego znacznika nodeName<\/strong>. Jest wykorzystana sie\u0107 hosta hostNetwork: true<\/strong>.<\/p>\n <\/p>\n To co widzimy z poziomu API-Server w przestrzeni nazw kube-scheduler<\/strong><\/p>\n Przyk\u0142adowa lista obiekt\u00f3w: Pod kube-scheduler<\/strong> ma zmienion\u0105 nazw\u0119 i jest tak zwany mirror pod o nazwie kube-scheduler_node_name<\/strong><\/p>\n Jak wygl\u0105da jego manifest, po usuni\u0119ciu cz\u0119\u015bci danych kt\u00f3re s\u0105\u00a0 wstrzykni\u0119te przez klaster ?<\/p>\n <\/p>\n I tutaj widzimy dodane nodeName: controlplane<\/strong> i zmieniona nazw\u0119 name: kube-scheduler-controlplane<\/strong>. To co nale\u017cy zapami\u0119ta\u0107, to brak mo\u017cliwo\u015bci tworzenia, usuwania i modyfikacji takich obiekt\u00f3w z poziomu kubectl<\/strong>, czyli przez API-Server<\/strong>. Takie obiekty s\u0105 zmieniane jedynie przez wrzucenie nowego pliku, jego modyfikacj\u0119 lub usuni\u0119cie z katalogu, w kt\u00f3rym kubelet<\/strong> danego w\u0119z\u0142a kontroluje zawarto\u015b\u0107 zgodnie ze \u015bcie\u017ck\u0105 staticPodPath<\/strong>.<\/p>\n <\/p>\n Jak w praktyce odr\u00f3\u017cni\u0107 static pod bez logowania si\u0119 na ka\u017cdy w\u0119ze\u0142 i ogl\u0105dania konfiguracji kubelet<\/strong>?<\/p>\n <\/p>\n Zacznijmy od listy w\u0119z\u0142\u00f3w<\/p>\n <\/p>\n Potem obejrzyjmy list\u0119 obiekt\u00f3w pod<\/strong> w przestrzeni nazw kube-system<\/strong><\/p>\n <\/p>\n Lista obiekt\u00f3w pod w przestrzeni nazw kube-system<\/p>\n Naj\u0142atwiej jest zauwa\u017cy\u0107, \u017ce sufiksem nazwy obiektu jest nazwa w\u0119z\u0142a (w naszym przypadku jest to controlplane<\/strong>).<\/p>\n Ale je\u015bli mamy klaster, kt\u00f3ry ma wiele w\u0119z\u0142\u00f3w, ten spos\u00f3b mo\u017ce si\u0119 okaza\u0107 ma\u0142o efektywny.<\/p>\n <\/p>\n Innym sposobem jest weryfikacja obiektu kontroluj\u0105cego dany obiekt pod i mo\u017cna wykorzysta\u0107 pole, kt\u00f3re wskazuje jaki obiekt nadrz\u0119dny jest tym kt\u00f3ry kontroluje jego stan.<\/p>\n Przyk\u0142adowy rezultat<\/p>\n \u0141atwo zauwa\u017cy\u0107, \u017ce mamy obiekty kontrolowane przez DaemonSet,ReplicaSet (i w konsekwencji przez obiekt Deployment), ale pojawiaj\u0105 si\u0119 te\u017c obiekty kontrolowane przez Node\/nazwa-w\u0119z\u0142a)<\/p>\n <\/p>\n Dane takie mo\u017cna te\u017c wy\u015bwietli\u0107 w bardziej eleganckiej formie wykorzystuj\u0105c, kubectl get (…) -o custom-columns<\/strong>.<\/p>\n Wykorzystaniu dok\u0142adniej custom-columns<\/strong> i jsonpath<\/strong> b\u0119dzie dedykowany inny odcinek, tu mamy tylko ma\u0142y przedsmak wykorzystania<\/p>\n <\/p>\n https:\/\/stackoverflow.com\/questions\/43225591\/kubernetes-custom-columns-select-element-from-array<\/a><\/p>\n https:\/\/kubernetes.io\/docs\/reference\/kubectl\/jsonpath\/<\/a><\/p>\n <\/p>\n <\/p>\n <\/p>\n I dodatkowo mo\u017cna odfiltrowa\u0107 zwracany wynik, tylko dla obiekt\u00f3w static pod.<\/p>\n <\/p>\n <\/p>\n Dosy\u0107 teorii, zabierzmy si\u0119 za cz\u0119\u015b\u0107 praktyczn\u0105<\/p>\n <\/p>\n <\/p>\n <\/p>\n Utw\u00f3rz obiekt typu pod o nazwie\u00a0 static-nginx-node01<\/strong> zawieraj\u0105cy obraz nginx<\/strong> pracuj\u0105cy na porcie 80<\/strong>. Umie\u015b\u0107 go w przestrzeni nazw gamma<\/strong> i na w\u0119\u017ale o nazwie node01<\/strong>. Obiekt powinien by\u0107 kontrolowany przez API-Server. Je\u017celi przestrze\u0144 nazw nie istnieje nale\u017cy j\u0105 utworzy\u0107.<\/p>\n <\/p>\n Zawarto\u015b\u0107 naszego manifestu<\/p>\n <\/p>\n <\/p>\n W jaki spos\u00f3b umie\u015bci\u0107 pod na w\u0119\u017ale node01<\/strong> ?<\/p>\n <\/p>\n Zacznijmy od najprostszego rozwi\u0105\u017cania, nie mo\u017ce by\u0107 to static pod, gdy\u017c ma by\u0107 kontrolowany przez API-Server, ale mo\u017cemy wyr\u0119czy\u0107 kube-scheduler<\/strong> przez podanie jawnie nazwy w\u0119z\u0142a nodeName: node01<\/strong>.<\/p>\n Po dodaniu odpowiedniej przestrzeni nazw (tutaj gamma) nasz manifest powinien wygl\u0105da\u0107 tak:<\/p>\n <\/p>\n Wdra\u017camy nasz obiekt na klaster<\/p>\n <\/p>\n Zobaczmy, czy zosta\u0142 umieszczony na odpowiednim w\u0119\u017ale, w tym celu mo\u017cemy wykorzysta\u0107 jako parametr polecenia kubectl get pod -o wide<\/strong><\/p>\n <\/p>\n Wszystko wygl\u0105da poprawie, ale czy jest to jedyne rozwi\u0105zanie ?<\/p>\n Co je\u015bli nie wype\u0142nimy nodeName ? Czy obiekt zostanie wdro\u017cony na inny w\u0119ze\u0142 ni\u017c node01<\/strong> ? W naszym przypadku mamy do czynienia z ma\u0142ym dwuw\u0119z\u0142owym klastrem.<\/p>\n Bez podania nazwy wez\u0142a do akcji wkroczy kube-scheduler<\/strong>.<\/p>\n <\/p>\n Uwa\u017cna osoba zapyta si\u0119 dlaczego kaza\u0142em nazwa\u0107 obiekt z prefiksem static, a w zasadzie to nie jest to static pod. No wla\u015bnie dlatego, aby by\u0142o to mniej oczywiste i podnios\u0142o poziom \u0107wiczenia.<\/p>\n <\/p>\n <\/p>\n Utw\u00f3rz obiekt typu pod o nazwie\u00a0 static-nginx-controlplane<\/strong> zawieraj\u0105cy obraz nginx<\/strong> pracuj\u0105cy na porcie 80<\/strong> . Umie\u015b\u0107 go w przestrzeni nazw gamma<\/strong> i na w\u0119\u017ale o nazwie controlplane<\/strong>. Obiekt\u00a0 powinien by\u0107 kontrolowany przez API-Server. Je\u017celi przestrze\u0144 nazw nie istnieje nale\u017cy j\u0105 utworzy\u0107. Kube-scheduler<\/strong> nie powinien bra\u0107 udzia\u0142u w ustaleniu docelowego w\u0119z\u0142a.<\/p>\n <\/p>\n To zadanie jest praktycznie tym samym co zadanie pierwsze, ale warto przetestowa\u0107 jak dzia\u0142a nodeName dla\u00a0 w\u0119z\u0142a controlplane<\/p>\n <\/p>\n <\/p>\n Po dodaniu odpowiedniej przestrzeni nazw nasz manifest powinien wygl\u0105da\u0107 tak<\/p>\n <\/p>\n Wdra\u017camy nasz obiekt na klaster<\/p>\n <\/p>\n Zobaczmy, czy zosta\u0142 umieszczony na odpowiednim w\u0119\u017ale, w tym celu mo\u017cemy wykorzysta\u0107 jako parametr polecenia kubectl -o wide<\/p>\n <\/p>\n <\/p>\n Jak wida\u0107 z powy\u017cszych przyk\u0142ad\u00f3w nodeName<\/strong> jest opcj\u0105 atomow\u0105, z tym \u017ce ma jedn\u0105 wad\u0119. Musimy zna\u0107 nazwy w\u0119z\u0142\u00f3w, a z tym bywa r\u00f3\u017cnie w zale\u017cno\u015bci od konfiguracji klastra.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Utw\u00f3rz obiekt typu pod o nazwie\u00a0 static-nginx<\/strong> zawieraj\u0105cy obraz nginx<\/strong> pracuj\u0105cy na porcie 80<\/strong> . Umie\u015b\u0107 go w przestrzeni nazw gamma<\/strong> i na w\u0119\u017ale o nazwie controlplane<\/strong>. Obiekt\u00a0 powinien by\u0107 kontrolowany przez API-Server<\/strong>. Je\u017celi przestrze\u0144 nazw nie istnieje nale\u017cy j\u0105 utworzy\u0107. Kube-scheduler<\/strong> powinien bra\u0107 udzia\u0142 w ustaleniu docelowego w\u0119z\u0142a. Nale\u017cy wykorzysta\u0107 mechanizm taints<\/strong> and tolerations<\/strong>.<\/p>\n <\/p>\n Zacznijmy od mechanizmu taints<\/strong> and tolerations<\/strong><\/p>\n <\/p>\n <\/p>\n Standardowo, w\u0119z\u0142y kontroluj\u0105ce klaster maja ustawiony zapach (taint<\/strong>), kt\u00f3ry uniemo\u017cliwia utworzenia na nich obiekt\u00f3w typu pod. Istnieje taka mo\u017cliwo\u015b\u0107, ale wtedy nale\u017cy w definicji obiektu uwzgl\u0119dni\u0107 tolerancj\u0119 (toleration<\/strong>) na zapach danego w\u0119z\u0142a.<\/p>\n <\/p>\n W jaki spos\u00f3b mo\u017cna doda\u0107 zapach dla danego w\u0119z\u0142a ?<\/p>\n <\/p>\n <\/p>\n W jaki spos\u00f3b doda\u0107 toleracj\u0119 do obiektu pod?<\/p>\n <\/p>\n na poziomie spec.tolerations<\/p>\n Gotowy manifest z dokumentacji Kubernetes wygl\u0105da tak<\/p>\n <\/p>\n <\/p>\n![\"\"](\"https:\/\/i.imgur.com\/MaONXzt.png\")
<\/p>\npod.Spec.NodeName<\/code><\/p>\n\n
\n
spec:\r\n template:\r\n spec:\r\n tolerations:\r\n # this toleration is to have the daemonset runnable on master nodes\r\n # remove it if your masters can't run pods\r\n - key: node-role.kubernetes.io\/master\r\n operator: Exists\r\n effect: NoSchedule<\/pre>\n
Kubelet<\/h3>\n
systemctl status kubelet<\/pre>\n
\u25cf kubelet.service - kubelet: The Kubernetes Node Agent\r\nLoaded: loaded (\/lib\/systemd\/system\/kubelet.service; enabled; vendor preset: enabled)\r\nDrop-In: \/etc\/systemd\/system\/kubelet.service.d\r\n\u2514\u250010-kubeadm.conf\r\nActive: active (running) since Fri 2021-06-04 10:52:09 UTC; 1min 25s ago\r\nDocs: https:\/\/kubernetes.io\/docs\/home\/\r\nMain PID: 6842 (kubelet)\r\nTasks: 15 (limit: 2336)<\/pre>\n
journalctl -u kubelet\r\n<\/pre>\n
-- Logs begin at Fri 2021-06-04 10:50:32 UTC, end at Fri 2021-06-04 10:54:42 UTC. --\r\nJun 04 10:50:32 controlplane systemd[1]: Started kubelet: The Kubernetes Node Agent.\r\nJun 04 10:50:33 controlplane kubelet[396]: F0604 10:50:33.828046 396 server.go:199] failed to load Kubelet c\r\nJun 04 10:50:33 controlplane systemd[1]: kubelet.service: Main process exited, code=exited, status=255\/n\/a\r\nJun 04 10:50:33 controlplane systemd[1]: kubelet.service: Failed with result 'exit-code'.\r\nJun 04 10:50:35 controlplane systemd[1]: Stopped kubelet: The Kubernetes Node Agent.\r\nJun 04 10:50:38 controlplane systemd[1]: Started kubelet: The Kubernetes Node Agent.<\/pre>\n
[Service]\r\nEnvironment=\"KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=\/etc\/kubernetes\/bootstrap-kubelet.conf --kubeconfig=\/etc\/kubernetes\/kubelet.conf\"\r\nEnvironment=\"KUBELET_CONFIG_ARGS=--config=\/var\/lib\/kubelet\/config.yaml\"\r\n# This is a file that \"kubeadm init\" and \"kubeadm join\" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically\r\nEnvironmentFile=-\/var\/lib\/kubelet\/kubeadm-flags.env\r\n# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use\r\n# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.\r\nEnvironmentFile=-\/etc\/default\/kubelet\r\nExecStart=\r\nExecStart=\/usr\/bin\/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS<\/pre>\n
apiVersion: kubelet.config.k8s.io\/v1beta1\r\nauthentication:\r\n anonymous:\r\n enabled: false\r\n webhook:\r\n cacheTTL: 0s\r\n enabled: true\r\n x509:\r\n clientCAFile: \/etc\/kubernetes\/pki\/ca.crt\r\nauthorization:\r\n mode: Webhook\r\n webhook:\r\n cacheAuthorizedTTL: 0s\r\n cacheUnauthorizedTTL: 0s\r\nclusterDNS:\r\n- 10.96.0.10\r\nclusterDomain: cluster.local\r\ncpuManagerReconcilePeriod: 0s\r\nevictionPressureTransitionPeriod: 0s\r\nfileCheckFrequency: 0s\r\nhealthzBindAddress: 127.0.0.1\r\nhealthzPort: 10248\r\nhttpCheckFrequency: 0s\r\nimageMinimumGCAge: 0s\r\nkind: KubeletConfiguration\r\nnodeStatusReportFrequency: 0s\r\nnodeStatusUpdateFrequency: 0s\r\nrotateCertificates: true\r\nruntimeRequestTimeout: 0s\r\nstaticPodPath: \/etc\/kubernetes\/manifests\r\nstreamingConnectionIdleTimeout: 0s\r\nsyncFrequency: 0s\r\nvolumeStatsAggPeriod: 0s<\/pre>\n
staticPodPath: \/etc\/kubernetes\/manifests<\/pre>\n
Konserwacja<\/h3>\n
kubectl drain node-name --ignore-daemonsets<\/pre>\n
cat \/etc\/kubernetes\/manifests\/kube-scheduler.yaml\r\n\r\n<\/pre>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n creationTimestamp: null\r\n labels:\r\n component: kube-scheduler\r\n tier: control-plane\r\n name: kube-scheduler\r\n namespace: kube-system\r\nspec:\r\n containers:\r\n - command:\r\n - kube-scheduler\r\n - --authentication-kubeconfig=\/etc\/kubernetes\/scheduler.conf\r\n - --authorization-kubeconfig=\/etc\/kubernetes\/scheduler.conf\r\n - --bind-address=127.0.0.1\r\n - --kubeconfig=\/etc\/kubernetes\/scheduler.conf\r\n - --leader-elect=true\r\n image: k8s.gcr.io\/kube-scheduler:v1.18.0\r\n imagePullPolicy: IfNotPresent\r\n livenessProbe:\r\n failureThreshold: 8\r\n httpGet:\r\n host: 127.0.0.1\r\n path: \/healthz\r\n port: 10259\r\n scheme: HTTPS\r\n initialDelaySeconds: 15\r\n timeoutSeconds: 15\r\n name: kube-scheduler\r\n resources:\r\n requests:\r\n cpu: 100m\r\n volumeMounts:\r\n - mountPath: \/etc\/kubernetes\/scheduler.conf\r\n name: kubeconfig\r\n readOnly: true\r\n hostNetwork: true\r\n priorityClassName: system-cluster-critical\r\n volumes:\r\n - hostPath:\r\n path: \/etc\/kubernetes\/scheduler.conf\r\n type: FileOrCreate\r\n name: kubeconfig\r\nstatus: {}<\/pre>\nkubectl get pod\u00a0 -n kube-system<\/pre>\n
\n<\/strong><\/p>\nNAME READY STATUS RESTARTS AGE\r\ncoredns-66bff467f8-bmwfk 1\/1 Running 0 15m\r\ncoredns-66bff467f8-vq78s 1\/1 Running 0 15m\r\netcd-controlplane 1\/1 Running 0 14m\r\nkube-apiserver-controlplane 1\/1 Running 0 14m\r\nkube-controller-manager-controlplane 1\/1 Running 0 14m\r\nkube-flannel-ds-amd64-55njh 1\/1 Running 0 15m\r\nkube-flannel-ds-amd64-t5shx 1\/1 Running 0 15m\r\nkube-keepalived-vip-fplqp 1\/1 Running 0 14m\r\nkube-proxy-886tw 1\/1 Running 0 15m\r\nkube-proxy-pjxzf 1\/1 Running 0 15m\r\nkube-scheduler-controlplane 1\/1 Running 0 15m\r\nmetrics-server-85f8dd85fd-msnhf 1\/1 Running 0 15m<\/pre>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n annotations:\r\n kubernetes.io\/config.hash: 74e2b561ea40b4f834f9854608d559d4\r\n kubernetes.io\/config.mirror: 74e2b561ea40b4f834f9854608d559d4\r\n kubernetes.io\/config.seen: \"2021-06-04T11:01:30.654339598Z\"\r\n kubernetes.io\/config.source: file\r\n labels:\r\n component: kube-scheduler\r\n tier: control-plane\r\n name: kube-scheduler-controlplane\r\n namespace: kube-system\r\nspec:\r\n containers:\r\n - command:\r\n - kube-scheduler\r\n - --authentication-kubeconfig=\/etc\/kubernetes\/scheduler.conf\r\n - --authorization-kubeconfig=\/etc\/kubernetes\/scheduler.conf\r\n - --bind-address=127.0.0.1\r\n - --kubeconfig=\/etc\/kubernetes\/scheduler.conf\r\n - --leader-elect=true\r\n image: k8s.gcr.io\/kube-scheduler:v1.18.0\r\n livenessProbe:\r\n failureThreshold: 8\r\n httpGet:\r\n host: 127.0.0.1\r\n path: \/healthz\r\n port: 10259\r\n scheme: HTTPS\r\n initialDelaySeconds: 15\r\n timeoutSeconds: 15\r\n name: kube-scheduler\r\n resources:\r\n requests:\r\n cpu: 100m\r\n volumeMounts:\r\n - mountPath: \/etc\/kubernetes\/scheduler.conf\r\n name: kubeconfig\r\n readOnly: true\r\n hostNetwork: true\r\n nodeName: controlplane\r\n priority: 2000000000\r\n priorityClassName: system-cluster-critical\r\n tolerations:\r\n - effect: NoExecute\r\n operator: Exists\r\n volumes:\r\n - hostPath:\r\n path: \/etc\/kubernetes\/scheduler.conf\r\n type: FileOrCreate\r\n name: kubeconfig<\/pre>\n
kubectl get nodes<\/pre>\n
NAME STATUS ROLES AGE VERSION\r\ncontrolplane Ready master 21m v1.19.0\r\nnode01 Ready <none> 20m v1.19.0<\/pre>\n
kubectl get pod -n kube-system<\/pre>\n
NAME READY STATUS RESTARTS AGE\r\ncoredns-66bff467f8-bmwfk 1\/1 Running 0 39m\r\ncoredns-66bff467f8-vq78s 1\/1 Running 0 39m\r\netcd-controlplane 1\/1 Running 0 38m\r\nkube-apiserver-controlplane 1\/1 Running 0 38m\r\nkube-controller-manager-controlplane 1\/1 Running 0 38m\r\nkube-flannel-ds-amd64-55njh 1\/1 Running 0 39m\r\nkube-flannel-ds-amd64-t5shx 1\/1 Running 0 39m\r\nkube-keepalived-vip-fplqp 1\/1 Running 0 38m\r\nkube-proxy-886tw 1\/1 Running 0 39m\r\nkube-proxy-pjxzf 1\/1 Running 0 39m\r\nkube-scheduler-controlplane 1\/1 Running 0 29m\r\nmetrics-server-85f8dd85fd-msnhf 1\/1 Running 0 39m<\/pre>\n
kubectl describe pod -n kube-system | grep \"Controlled By:\"<\/pre>\n
Controlled By: ReplicaSet\/coredns-66bff467f8\r\nControlled By: ReplicaSet\/coredns-66bff467f8\r\nControlled By: Node\/controlplane\r\nControlled By: ReplicaSet\/katacoda-cloud-provider-6bc7d5d9ff\r\nControlled By: Node\/controlplane\r\nControlled By: Node\/controlplane\r\nControlled By: DaemonSet\/kube-flannel-ds-amd64\r\nControlled By: DaemonSet\/kube-flannel-ds-amd64\r\nControlled By: DaemonSet\/kube-keepalived-vip\r\nControlled By: DaemonSet\/kube-proxy\r\nControlled By: DaemonSet\/kube-proxy\r\nControlled By: Node\/controlplane\r\nControlled By: ReplicaSet\/metrics-server-85f8dd85fd\r\n<\/pre>\n
kubectl get pods -n kube-system -o custom-columns=NAME:.metadata.name,CONTROLLER:.metadata.ownerReferences[].kind,NAMESPACE:.metadata.namespace\r\n<\/pre>\n
NAME CONTROLLER NAMESPACE\r\ncoredns-66bff467f8-bmwfk ReplicaSet kube-system\r\ncoredns-66bff467f8-vq78s ReplicaSet kube-system\r\netcd-controlplane Node kube-system\r\nkatacoda-cloud-provider-6bc7d5d9ff-t4zr2 ReplicaSet kube-system\r\nkube-apiserver-controlplane Node kube-system\r\nkube-controller-manager-controlplane Node kube-system\r\nkube-flannel-ds-amd64-55njh DaemonSet kube-system\r\nkube-flannel-ds-amd64-t5shx DaemonSet kube-system\r\nkube-keepalived-vip-fplqp DaemonSet kube-system\r\nkube-proxy-886tw DaemonSet kube-system\r\nkube-proxy-pjxzf DaemonSet kube-system\r\nkube-scheduler-controlplane Node kube-system\r\nmetrics-server-85f8dd85fd-msnhf ReplicaSet kube-system\r\n<\/pre>\n
kubectl get pods --all-namespaces -o custom-columns=NAME:.metadata.name,CONTROLLER:.metadata.ownerReferences[].kind,NAMESPACE:.metadata.namespace |grep Node\r\n<\/pre>\n
etcd-controlplane Node kube-system\r\nkube-apiserver-controlplane Node kube-system\r\nkube-controller-manager-controlplane Node kube-system\r\nkube-scheduler-controlplane Node kube-system<\/pre>\n
\u0106wiczenia<\/h3>\n
Zadanie pierwsze<\/h4>\n
kubectl run static-nginx-node01 --image=nginx --port=80 -o yaml --dry-run=client > 01.pod.static-nginx-node01.yaml<\/pre>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n creationTimestamp: null\r\n labels:\r\n run: static-nginx-node01\r\n name: static-nginx-node01\r\nspec:\r\n containers:\r\n - image: nginx\r\n name: static-nginx-node01\r\n ports:\r\n - containerPort: 80\r\n resources: {}\r\n dnsPolicy: ClusterFirst\r\n restartPolicy: Always\r\nstatus: {}<\/pre>\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n creationTimestamp: null\r\n labels:\r\n run: static-nginx-node01\r\n name: static-nginx-node01\r\n namespace: gamma\r\nspec:\r\n containers:\r\n - image: nginx\r\n name: static-nginx-node01\r\n ports:\r\n - containerPort: 80\r\n resources: {}\r\n dnsPolicy: ClusterFirst\r\n restartPolicy: Always\r\n nodeName: node01\r\nstatus: {}<\/pre>\nkubectl apply -f 01.pod.static-nginx-node01.yaml<\/pre>\n
pod\/static-nginx-node01 created<\/pre>\n
kubectl get pod static-nginx-node01 -n gamma -o wide<\/pre>\n
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES\r\nstatic-nginx-node01 1\/1 Running 0 3m4s 10.244.2.13 node01 <none> <none><\/pre>\n
Zadanie drugie<\/h4>\n
kubectl run static-nginx-controlplane --image=nginx --port=80 -o yaml --dry-run=client > 02.pod.static-nginx-controlplane.yaml<\/pre>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n creationTimestamp: null\r\n labels:\r\n run: static-nginx-controlplane\r\n name: static-nginx-controlplane\r\n namespace: gamma\r\nspec:\r\n containers:\r\n - image: nginx\r\n name: static-nginx-controlplane\r\n ports:\r\n - containerPort: 80\r\n resources: {}\r\n dnsPolicy: ClusterFirst\r\n restartPolicy: Always\r\n nodeName: controlplane\r\nstatus: {}<\/pre>\nkubectl apply -f 02.pod.static-nginx-controlplane.yaml<\/pre>\n
pod\/static-nginx-controlplane created<\/pre>\n
kubectl get pod static-nginx-controlplane -n gamma -o wide<\/pre>\n
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES\r\nstatic-nginx-controlplane 1\/1 Running 0 3m4s 10.244.2.13 controlplane <none> <none><\/pre>\n
Zadanie trzecie<\/h4>\n
kubectl describe nodes | egrep \"Name:|Taints:\"\r\n<\/pre>\n
Name: controlplane\r\nTaints: node-role.kubernetes.io\/master:NoSchedule\r\nName: node01\r\nTaints: <none><\/pre>\n
kubectl taint nodes controlplane key1=value1:NoSchedule<\/pre>\n
tolerations:\r\n- key: \"key1\"\r\n operator: \"Equal\"\r\n value: \"value1\"\r\n effect: \"NoSchedule\"<\/pre>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: nginx\r\n labels:\r\n env: test\r\nspec:\r\n containers:\r\n - name: nginx\r\n image: nginx\r\n imagePullPolicy: IfNotPresent\r\n tolerations:\r\n - key: \"example-key\"\r\n operator: \"Exists\"\r\n effect: \"NoSchedule\"<\/pre>\n
![\"\"](\"https:\/\/cdn.thenewstack.io\/media\/2020\/01\/6f288b5f-np-aff-1024x447.png\")
<\/p>\n