{"id":1367,"date":"2021-06-20T23:33:13","date_gmt":"2021-06-20T21:33:13","guid":{"rendered":"https:\/\/wchmurze.cloud\/?p=1367"},"modified":"2021-06-22T22:27:38","modified_gmt":"2021-06-22T20:27:38","slug":"certified-kubernetes-administrator-cka-krok-po-kroku-czesc-5","status":"publish","type":"post","link":"https:\/\/wchmurze.cloud\/index.php\/2021\/06\/20\/certified-kubernetes-administrator-cka-krok-po-kroku-czesc-5\/","title":{"rendered":"Certified Kubernetes Administrator (CKA) krok po kroku – cz\u0119\u015b\u0107 5"},"content":{"rendered":"

W jaki spos\u00f3b mo\u017cna w \u015brodowisku skonteneryzowanym utrzymywa\u0107 dane i stan ?<\/h3>\n

 <\/p>\n

Jak wiadomo ka\u017cdy kontener ma sw\u00f3j system plik\u00f3w dost\u0119pny tylko dla niego. Ten system jest ulotny (efemeryczny). Oznacza to, ze wszelki dane jakie zapiszemy w kontenerze podczas jego pracy po ponownym uruchomienia b\u0119d\u0105 utracone.Je\u017celi mamy do czynienia z aplikacja, kt\u00f3ra dzia\u0142a samodzielnie i nie musi zapisywa\u0107 swojego stanu nie mamy problemu, ale co zrobi\u0107 w sytuacji, gdy aplikacja sk\u0142ada si\u0119 z wielu kontener\u00f3w i musi wymienia\u0107 sw\u00f3j stan i utrzymywa\u0107 go mi\u0119dzy restartami?<\/p>\n

 <\/p>\n

O tym jest dzisiejsza opowie\u015b\u0107:<\/p>\n

 <\/p>\n

Wolumeny danych<\/h3>\n

 <\/p>\n

Na pocz\u0105tku pracy z Kubernetes pewn\u0105 trudno\u015b\u0107 sprawia\u0142a mi budowa manifest\u00f3w, kt\u00f3re wykorzystuj\u0105 wolumeny. Nie uczmy si\u0119 na pami\u0119\u0107, wykorzystajmy zar\u00f3wno system pomocy jak i wbudowane narz\u0119dzia, niekoniecznie zgodnie z intencj\u0105 ich tw\u00f3rc\u00f3w.\u00a0 Jak mo\u017cna\u00a0 sprawnie budowa\u0107 takie manifesty?<\/p>\n

Na pocz\u0105tku zacznijmy od prostego \u0107wiczenia<\/p>\n

Czym r\u00f3\u017cni\u0105 si\u0119 dwa tryby kubectl –dry-run<\/strong> ? (client<\/strong>, server<\/strong>)<\/p>\n

W przypadku opcji client<\/strong> polecenie kubectl wy\u015bwietli tylko obiekt ( dla opcji -o yaml) , jaki zostanie wys\u0142any do klastra, a w przypadku opcji server<\/strong> obiekt zostanie wys\u0142any na klaster, zostan\u0105 dopisane r\u00f3\u017cne domy\u015blne warto\u015bci, ale bez ko\u0144cowego zapisu obiektu.<\/p>\n

Przyk\u0142adowe polecenie generuj\u0105ce manifest obiektu pod.<\/p>\n

kubectl run test --image=nginx.alpine -o yaml --dry-run=client<\/pre>\n
Zwrotny manifest wygl\u0105da w taki spos\u00f3b<\/p>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n  creationTimestamp: null\r\n  labels:\r\n    run: test\r\n  name: test\r\nspec:\r\n  containers:\r\n  - image: nginx.alpine\r\n    name: test\r\n    resources: {}\r\n  dnsPolicy: ClusterFirst\r\n  restartPolicy: Always\r\nstatus: {}<\/pre>\n
 <\/p>\n
W\u00a0 wersji “serwerowej” wygl\u0105da to nieco inaczej.<\/p>\n
kubectl run test --image=nginx:alpine -o yaml --dry-run=server \r\n<\/pre>\n
Manifest zawiera w sobie o wiele wi\u0119cej danych. Zwr\u00f3\u0107my uwag\u0119 na jeden aspekt jakim jest pod\u0142\u0105czenie za pomoc\u0105 obiektu secret tokena pochodz\u0105cego od konta serwisowego (serviceaccount<\/strong>) o nazwie default. Ka\u017cda przestrze\u0144 nazw ma utworzon\u0105 par\u0119 obiekt\u00f3w konto serwisowe\u00a0 (serviceaccount) o nazwie default<\/strong> i skojarzony z tym kontem token zawarty w obiekcie secret default-token-HASH<\/strong>.<\/p>\n
 <\/p>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n  creationTimestamp: \"2021-06-17T20:03:21Z\"\r\n  labels:\r\n    run: test\r\n # managedfields ommited (...)\r\n  name: test\r\n  namespace: default\r\n  selfLink: \/api\/v1\/namespaces\/default\/pods\/test\r\n  uid: 2049eb41-0974-4017-b5b6-1eddc29fbd9a\r\nspec:\r\n  containers:\r\n  - image: nginx:alpine\r\n    imagePullPolicy: IfNotPresent\r\n    name: test\r\n    resources: {}\r\n    terminationMessagePath: \/dev\/termination-log\r\n    terminationMessagePolicy: File\r\n    volumeMounts:\r\n    - mountPath: \/var\/run\/secrets\/kubernetes.io\/serviceaccount\r\n      name: default-token-hzgn6\r\n      readOnly: true\r\n  dnsPolicy: ClusterFirst\r\n  enableServiceLinks: true\r\n  preemptionPolicy: PreemptLowerPriority\r\n  priority: 0\r\n  restartPolicy: Always\r\n  schedulerName: default-scheduler\r\n  securityContext: {}\r\n  serviceAccount: default\r\n  serviceAccountName: default\r\n  terminationGracePeriodSeconds: 30\r\n  tolerations:\r\n  - effect: NoExecute\r\n    key: node.kubernetes.io\/not-ready\r\n    operator: Exists\r\n    tolerationSeconds: 300\r\n  - effect: NoExecute\r\n    key: node.kubernetes.io\/unreachable\r\n    operator: Exists\r\n    tolerationSeconds: 300\r\n  volumes:\r\n  - name: default-token-hzgn6\r\n    secret:\r\n      defaultMode: 420\r\n      secretName: default-token-hzgn6\r\nstatus:\r\n  phase: Pending\r\n  qosClass: BestEffort<\/pre>\n
 <\/p>\n
Zobaczmy jak to wygl\u0105da w naszym przypadku. Wylistujmy wszystkie obiekty kont serwisowych i obiekty secret w przestrzeni nazw default<\/p>\n
kubectl get sa,secret -n default\r\n<\/pre>\n
NAME SECRETS AGE\r\nserviceaccount\/default 1 8m17s\r\n\r\nNAME TYPE DATA AGE\r\nsecret\/default-token-hzgn6 kubernetes.io\/service-account-token 3 8m17s<\/pre>\n
kubectl get sa default -o yaml -n default\r\n<\/pre>\n
apiVersion: v1\r\nkind: ServiceAccount\r\nmetadata:\r\n  creationTimestamp: \"2021-06-17T19:57:18Z\"\r\n  name: default\r\n  namespace: default\r\n  resourceVersion: \"380\"\r\n  selfLink: \/api\/v1\/namespaces\/default\/serviceaccounts\/default\r\n  uid: 9e41fc13-3d63-4b10-ac6c-f1cd32d2a643\r\nsecrets:\r\n- name: default-token-hzgn6<\/pre>\n
 <\/p>\n
Nazwa obiektu secret dla konta serwisowego jest zawarta w mapie secrets<\/strong>.<\/p>\n
 <\/p>\n
Wracaj\u0105c do tematu pod\u0142\u0105czania do kontenera wolumenu, to warto zauwa\u017cy\u0107, \u017ce lista volumen\u00f3w jest na poziomie spec.<\/strong> ca\u0142ego obiektu pod, natomiast pod\u0142\u0105czenie tego wolumenu jest ju\u017c na poziomie kontenera w obiekcie pod, czyli spec.containers[*]<\/strong>.<\/p>\n
Przypominam, i\u017c pod jest obiektem grupuj\u0105cym wiele<\/strong> kontener\u00f3w i te kontenery umieszczone s\u0105 w tym samej linuksowej przestrzeni nazw, komunikuj\u0105 si\u0119 przez localhost i mog\u0105 dzieli\u0107 ten sam wolumen. Wolumeny maj\u0105 w ramach obiektu pod unikalne nazwy.<\/p>\n
Poni\u017cej umie\u015bci\u0142em cz\u0119\u015b\u0107 manifestu na poziomie listy wolumen\u00f3w<\/p>\n
spec:\r\n# (...)\r\n  volumes:\r\n  - name: default-token-hzgn6\r\n    secret:\r\n      defaultMode: 420\r\n      secretName: default-token-hzgn6\r\n<\/pre>\n
Mamy tu do czynienia z jednym elementem listy\u00a0 na poziomie pod.spec.volumes<\/strong>, gdzie unikaln\u0105 warto\u015bci\u0105 jest name. Dodatkowo widzimy informacj\u0119, o tym, \u017ce \u017ar\u00f3d\u0142em wolumenu jest obiekt secret. Lista takich \u017ar\u00f3de\u0142 jest dosy\u0107 d\u0142uga i zale\u017cy od dostawcy us\u0142ugi magazynowej (storage).<\/p>\n
Patrz\u0105c na cz\u0119\u015b\u0107 manifestu na poziomie miejsca pod\u0142\u0105czenia (volumeMounts<\/strong>)<\/p>\n
spec:\r\n  containers:\r\n# (...)\r\n    volumeMounts:\r\n    - mountPath: \/var\/run\/secrets\/kubernetes.io\/serviceaccount\r\n      name: default-token-hzgn6\r\n      readOnly: true\r\n<\/pre>\n
W tym przypadku na poziomie pod.spec.containers[*].volumeMounts<\/strong> widzimy t\u0119 sam\u0105 warto\u015b\u0107 name<\/strong> co wcze\u015bniej i mamy dodany punkt pod\u0142\u0105czenia (mountPath<\/strong>) w kontenerze. W naszym przypadku jest to katalog wewn\u0105trz kontenera o \u015bcie\u017cce \/var\/run\/secrets\/kubernetes.io\/serviceaccount<\/strong> z ustawionym dodatkowo znacznikiem trybu tylko do odczytu (readOnly: true<\/strong>).<\/p>\n
 <\/p>\n
Cz\u0119\u015b\u0107 manifestu obrazuj\u0105cego oba poziomy dotycz\u0105ce wolumen\u00f3w.<\/p>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n  labels:\r\n    run: pod\r\n  #  managedfields ommited (...)\r\n  name: pod\r\nspec:\r\n  containers:\r\n# (...)\r\n    volumeMounts:\r\n    - mountPath: \/var\/run\/secrets\/kubernetes.io\/serviceaccount\r\n      name: default-token-hzgn6\r\n      readOnly: true\r\n#  (...)\r\n  volumes:\r\n  - name: default-token-hzgn6\r\n    secret:\r\n      defaultMode: 420\r\n      secretName: default-token-hzgn6\r\n<\/pre>\n
 <\/p>\n
Jak wygl\u0105da nasz obiekt secret default-token-hzgn6<\/strong> ?<\/p>\n
 <\/p>\n
kubectl get secret default-token-hzgn6<\/pre>\n
NAME                  TYPE                                  DATA   AGE\r\ndefault-token-hzgn6   kubernetes.io\/service-account-token   3      12m<\/pre>\n
 <\/p>\n
Jak wida\u0107 obiekt secret zawiera trzy pary klucz:warto\u015b\u0107<\/p>\n
 <\/p>\n
kubectl get secret default-token-hzgn6 -o yaml<\/pre>\n
Obrobiony manifest wygl\u0105da tak:<\/p>\n
 <\/p>\n
apiVersion: v1\r\ndata:\r\n  ca.crt: REDACTED\r\n  namespace: ZGVmYXVsdA==\r\n  token: REDACTED\r\n  annotations:\r\n    kubernetes.io\/service-account.name: default\r\n    kubernetes.io\/service-account.uid: 9e41fc13-3d63-4b10-ac6c-f1cd32d2a643\r\n  creationTimestamp: \"2021-06-17T19:57:18Z\"\r\n  # managedFields ommitted \r\n    manager: kube-controller-manager\r\n    operation: Update\r\n    time: \"2021-06-17T19:57:18Z\"\r\n  name: default-token-hzgn6\r\n  namespace: default\r\n  resourceVersion: \"379\"\r\n  selfLink: \/api\/v1\/namespaces\/default\/secrets\/default-token-hzgn6\r\n  uid: 8ed2d192-b058-4147-b811-6e43a7bc2824\r\ntype: kubernetes.io\/service-account-token<\/pre>\n
 <\/p>\n
Dane , kt\u00f3re\u00a0 mo\u017cna przekaza\u0107 do kontenera s\u0105 na poziomie data.<\/strong><\/p>\n
data: \r\n  ca.crt: REDACTED\r\n  namespace: ZGVmYXVsdA==\r\n  token: REDACTED<\/pre>\n
 <\/p>\n
Wdr\u00f3\u017cmy nasz obiekt na klaster<\/p>\n
kubectl run test --image=nginx:alpine<\/pre>\n
pod\/test created<\/pre>\n
 <\/p>\n
Spr\u00f3bujmy wej\u015b\u0107 do \u015brodka kontenera w obiekcie o nazwie test. Wykorzystamy do tego polecenie kubectl exec<\/strong><\/p>\n
kubectl exec test -it -- sh<\/pre>\n
To co widzimy w \u015brodku naszego kontenera<\/p>\n
# zmieniamy katalog\r\n\r\n\/ cd \/var\/run\/secrets\/kubernetes.io\r\n\r\n# listujemy pliki ktore w nim s\u0105\r\n\r\n\/run\/secrets\/kubernetes.io # ls -la\r\ntotal 8\r\ndrwxr-xr-x 3 root root 4096 Jun 17 20:13 .\r\ndrwxr-xr-x 3 root root 4096 Jun 17 20:13 ..\r\ndrwxrwxrwt 3 root root 140 Jun 17 20:12 serviceaccount\r\n\r\n# wyswietlamy zawartosc podkatalogu serviceaccount\r\n\/run\/secrets\/kubernetes.io # ls -la serviceaccount\/\r\ntotal 4\r\ndrwxrwxrwt 3 root root 140 Jun 17 20:12 .\r\ndrwxr-xr-x 3 root root 4096 Jun 17 20:13 ..\r\ndrwxr-xr-x 2 root root 100 Jun 17 20:12 ..2021_06_17_20_12_55.229534384\r\nlrwxrwxrwx 1 root root 31 Jun 17 20:12 ..data -> ..2021_06_17_20_12_55.229534384\r\nlrwxrwxrwx 1 root root 13 Jun 17 20:12 ca.crt -> ..data\/ca.crt\r\nlrwxrwxrwx 1 root root 16 Jun 17 20:12 namespace -> ..data\/namespace\r\nlrwxrwxrwx 1 root root 12 Jun 17 20:12 token -> ..data\/token\r\n\r\n# wyswietlamy zawarto\u015b\u0107 pliku namespace\r\n\r\n\/run\/secrets\/kubernetes.io # cat serviceaccount\/namespace \r\n\r\ndefault<\/pre>\n
Mamy plik manifestu w obiekcie typu secret zawieraj\u0105cy trzy pary klucz:warto\u015b\u0107. W prosty spos\u00f3b mo\u017cemy pod\u0142\u0105czy\u0107 te dane jako trzy osobne pliki. Takie pliki traktowane s\u0105 przez system plikowy kontenera w trybie do odczytu. Co wi\u0119cej zmiana obiektu secret powoduje automatyczn\u0105 zmian\u0119 pod\u0142\u0105czonego pliku (dla danej pary klucz: warto\u015b\u0107) bez restartu obiektu pod.<\/p>\n
Uwa\u017cna osoba zada na pewno pytanie, po co montujemy niejako w tle takie rzeczy. Ot\u00f3\u017c obiekt pod uruchomiony na klastrze Kubernetes ma dost\u0119p do Kubernetes API. Uprawnienia z jakimi ma do tego API dost\u0119p wynikaj\u0105 z uprawnie\u0144 jakie ma\u00a0 konto serwisowe (w naszym przypadku o nazwie default)\u00a0 w zadanej przestrzeni nazw.\u00a0 Nie jest to zagadnienie zakresu egzaminacyjnego, ale warto wiedzie\u0107, \u017ce je\u015bli nie potrzebujemy dost\u0119pu do API Kubernetes, to mo\u017cemy zablokowa\u0107 pod\u0142\u0105czenie danych zwi\u0105zanych z obiektem secret stowarzyszonym z danym kontem serwisowym (serviceaccount<\/strong>). Warto dok\u0142adniej poczyta\u0107 o RBAC<\/strong>.<\/p>\n
https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/rbac\/<\/a><\/p>\n
 <\/p>\n
Mamy do dyspozycji dwie metody, kt\u00f3re zablokuj\u0105 dost\u0119p do API Kubernetes:<\/p>\n
 <\/p>\n
Mo\u017cna\u00a0 wy\u0142\u0105czy\u0107 dla danego konta mo\u017cliwo\u015b\u0107 korzystania z API Kubernetes dodaj\u0105c do manifestu\u00a0 automountServiceAccountToken: false<\/strong><\/p>\n
 <\/p>\n
apiVersion: v1\r\nkind: ServiceAccount\r\nmetadata:\r\n  name: no-token-please\r\n  namespace: default\r\nautomountServiceAccountToken: false<\/pre>\n
 <\/p>\n
Mo\u017cna te\u017c w definicji np. obiektu typu pod przy definicji konta serwisowego poprosi\u0107 o niepod\u0142\u0105czanie do API dodaj\u0105c automountServiceAccountToken: false<\/strong><\/p>\n
 <\/p>\n
apiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n  name: my-pod\r\nspec:\r\n  serviceAccountName: yes-token-please\r\n  automountServiceAccountToken: false<\/pre>\n
 <\/p>\n
 <\/p>\n
Zniecierpliwiona osoba, zacznie si\u0119 pyta\u0107, po co tyle opowie\u015bci o korzystaniu z API i pod\u0142\u0105czaniu plik\u00f3w do kontenera. Niniejszy wpis nie jest cz\u0119\u015bci\u0105 jakiego\u015b kursu Kubernetes, kt\u00f3rych jest ju\u017c du\u017co i w kt\u00f3rych mo\u017cna znale\u017a\u0107 wi\u0119cej informacji. Jest to pr\u00f3ba pomocy dla os\u00f3b, kt\u00f3re przygotowuj\u0105 si\u0119 do certyfikacji CKA, ale jednocze\u015bnie nie chcia\u0142bym, aby by\u0142 to jedynie spis gotowych rozwi\u0105za\u0144, kt\u00f3re co prawda pozwol\u0105 wyrobi\u0107 sobie manualn\u0105 sprawno\u015b\u0107, ale niewiele wi\u0119cej.<\/em><\/p>\n
 <\/p>\n
W jaki spos\u00f3b Kubernetes jest w stanie zapewni\u0107 nam przechowanie danych pomimo restartu kontenera ?<\/p>\n
Dotarli\u015bmy do pocz\u0105tku naszej opowie\u015bci.\u00a0 Przypomn\u0119 obrazek z jednej z poprzednich cz\u0119\u015bci<\/p>\n
 <\/p>\n
\"\"<\/p>\n
Tym razem zajmiemy si\u0119 cz\u0119\u015bci\u0105 praw\u0105 (zielon\u0105) zar\u00f3wno dla obiektu configmap<\/strong> jak i dla obiektu secret, <\/strong>z tym, \u017ce dla obiektu secret<\/strong> zamiast mapy configMap<\/strong> b\u0119dzie mapa secret. <\/strong><\/p>\n
<\/div>\n
Kubernetes obs\u0142uguje ponad 20 typ\u00f3w wolumen\u00f3w, nie ma sensu uczy\u0107 si\u0119 ich na pami\u0119\u0107.<\/div>\n
<\/div>\n
\n
Kubernetes Volume Types<\/a><\/p>\n
 <\/p>\n<\/div>\n
<\/h4>\n
Wolumeny ulotne<\/h4>\n
 <\/p>\n
\n
EmptyDir<\/h5>\n
Wolumen typu emptyDir<\/strong> jest tworzony w momencie, gdy na danym w\u0119\u017ale pojawia si\u0119 obiekt pod po raz pierwszy. Wolumen ten istnieje tak d\u0142ugo jak obiekt pod na danym w\u0119\u017ale. Zgodnie z nazw\u0105 pocz\u0105tkowy stan jest pusty. Wszystkie kontenery w danym obiekcie pod mog\u0105 czyta\u0107 i pisa\u0107 do tego samego wolumenu. Kiedy pod jest zrestartowany lub usuni\u0119ty dane w tego typu wolumenie s\u0105 tracone.<\/p>\n
Jakie\u00a0 jest g\u0142\u00f3wne zastosowanie?<\/p>\n<\/div>\n