Konfiguracje Kubernetes, które warto znać w 2024 roku

Kubernetes wciąż jest liderem w orkiestracji kontenerów. Opanowanie jego mechanizmów i możliwości, jakie oferuje, staje się niezbędne nie tylko dla profesjonalistów DevOps, ale także dla zwykłych programistów, ponieważ spotykamy się z nim w każdym projekcie na rynku. Ponadto, we wszystkich ofertach pracy można zauważyć, że znajomość tej technologii jest mile widziana.

W 2024 roku niektóre konfiguracje Kubernetes wyróżniają się na tle innych ze względu na swoją funkcjonalność w zakresie automatyzacji i bezpieczeństwa, a także poprawy wydajności w środowiskach natywnych w chmurze. Artykuł bada kluczowe konfiguracje Kubernetes wraz ze scenariuszami zastosowania, korzyściami i przykładami kodu, oferując dogłębne spojrzenie na każdą z nich.

Żądania i ograniczenia zasobów

W Kubernetes zrozumienie i poprawna konfiguracja żądanych zasobów oraz ograniczeń zasobów są kluczowe. Żądania i ograniczenia zapewniają, że aplikacje otrzymują niezbędne zasoby do działania, jednocześnie zapobiegając monopolizacji wszystkich zasobów klastra przez jedną aplikację.

apiVersion: v1 
kind: Pod 
metadata: 
name: sample-app 
spec: 
containers: 
- name: app-container 
 image: nginx 
 resources: 
 requests: 
 memory: "64Mi" 
 cpu: "250m" 
 limits:
 memory: "128Mi" 
 cpu: "500m" 

• Cele: Zwiększenie stabilności i wydajności poszczególnych aplikacji oraz całego klastra. Zapobieganie konkurencji o zasoby i zapewnienie, że aplikacje nie zostaną niespodziewanie zakończone z powodu braku zasobów.
• Kiedy stosować: Konfiguracja żądań i ograniczeń jest konieczna dla wszystkich aplikacji działających w klastrze (obciążenia). Prawidłowa konfiguracja zapewnia przewidywalną wydajność i zapobiega nadmiernemu zużywaniu dużej ilości zasobów przez jedną aplikację, co wpływa na stabilność całego klastra.
• Dokumentacja: Resource Management for Modules  and Containers.

Liveness and readiness probe

Konfiguracja prób liveness i readiness jest niezwykle ważna dla zarządzania cyklem życia aplikacji w Kubernetes. Pomaga podejmować decyzje o tym, kiedy należy zrestartować kontener na podstawie konfiguracji liveness oraz kiedy kontener jest gotowy do obsługi ruchu na podstawie konfiguracji readiness.

livenessProbe: 
httpGet: 
 path: /health 
 port: 8080 
initialDelaySeconds: 3 
periodSeconds: 3 
readinessProbe: 
httpGet: 
 path: /ready 
 port: 8080 
initialDelaySeconds: 5 
periodSeconds: 5 

• Cele: Zwiększenie odporności na błędy i dostępności aplikacji poprzez zapewnienie, że Kubernetes może automatycznie zarządzać stanem kontenerów na podstawie rzeczywistego statusu operacyjnego aplikacji, zamiast polegać na stanie czasu działania kontenera.
• Kiedy stosować: Konfiguracja prób liveness jest konieczna dla aplikacji, w których maksymalna dostępność i minimalny czas przestoju są kluczowe. Konfiguracja prób readiness jest wymagana dla aplikacji, które powinny otrzymywać ruch dopiero po całkowitej inicjalizacji i potwierdzeniu gotowości do obsługi żądań.
• Dokumentacja: Configure Liveness, Readiness i Startup Probes.

Mapy konfiguracyjne i sekrety

Mapy konfiguracyjne i sekrety są niezbędne do przechowywania parametrów konfiguracyjnych oraz danych poufnych poza kodem aplikacji. Umożliwiają przechowywanie otwartych danych w formacie klucz-wartość, podczas gdy sekrety służą do przechowywania informacji poufnych.

apiVersion: v1 
kind: ConfigMap 
metadata: 
name: app-config 
data: 
config.json: | 
 { 
 "database": "sql", 
 "timeout": "30s", 
 "featureFlag": "true" 
 } 
--- 
apiVersion: v1 
kind: Secret 
metadata: 
name: app-secret 
type: Opaque 
data: 
password: cGFzc3dvcmQ=

• Cele: Oddzielenie parametrów konfiguracyjnych i sekretów od logiki aplikacji, co upraszcza wdrażanie i zarządzanie aplikacjami w różnych środowiskach, a także zwiększa poziom bezpieczeństwa.
• Kiedy stosować: Mapy konfiguracyjne są używane do definiowania parametrów aplikacji, które zmieniają się w zależności od środowiska (dev, cert, produkcja). Sekrety są używane do przechowywania poświadczeń, tokenów i innych informacji wrażliwych.
• Dokumentacja: ConfigMaps, Secrets.

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) automatycznie dostosowuje liczbę replik podów w Deployment, ReplicaSet lub StatefulSet na podstawie wykorzystania CPU lub metryk niestandardowych.

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
name: sample-app-hpa 
spec: 
scaleTargetRef: 
 apiVersion: apps/v1 
 kind: Deployment 
 name: sample-app 
minReplicas: 1 
maxReplicas: 10 
targetCPUUtilizationPercentage: 80 

• Cele: Zapewnienie gwarantowanego poziomego skalowania na podstawie bieżącego obciążenia, optymalne wykorzystanie zasobów oraz utrzymanie wydajności.
• Kiedy stosować: Konfiguracja poziomego autoskalowania jest idealna dla aplikacji o zmiennym ruchu. Umożliwia dynamiczną alokację zasobów w zależności od zapotrzebowania bez interwencji ręcznej.
• Dokumentacja: Horizontal Pod Autoscaling.

Polityki sieciowe

Polityki sieciowe to zasoby Kubernetes, które kontrolują przepływ ruchu między podami a punktami końcowymi sieci, umożliwiając mikrosegmentację i zwiększając bezpieczeństwo aplikacji w Kubernetes.

apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: default-deny-all 
spec: 
podSelector: {} 
policyTypes: 
- Ingress 
- Egress 

• Cele: Zapewnienie bezpieczeństwa wymiany danych między podami w obrębie klastra Kubernetes – zezwalanie tylko na autoryzowany ruch między modułami lub usługami zewnętrznymi.
• Kiedy stosować: Konfiguracja polityk sieciowych jest szczególnie przydatna w środowiskach wielodostępnych lub aplikacjach o wysokich wymaganiach bezpieczeństwa, aby zapobiegać nieautoryzowanemu dostępowi i ograniczać potencjalne wektory ataków.
• Dokumentacja: Network Policies.

Konta serwisowe

Konta serwisowe w Kubernetes służą do identyfikacji podów podczas interakcji z API Kubernetes i innymi usługami (zasobami) w obrębie klastra. Są kluczowe dla zarządzania dostępem i zapewnienia bezpiecznej komunikacji między usługami.

apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: my-service-account
namespace: default 

Użycie konta serwisowego w podzie:

apiVersion: v1 
kind: Pod 
metadata: 
name: my-pod 
spec: 
containers: 
- name: my-container 
 image: my-image 
serviceAccountName: my-service-account 

• Cele: Przypisanie kont serwisowych do podów umożliwia szczegółową kontrolę dostępu i audyt. Konta serwisowe są również niezbędne do przyznawania dostępu do API Kubernetes i innych zasobów klastra.
• Kiedy stosować: Konta serwisowe są używane podczas wdrażania aplikacji, które muszą integrować z API Kubernetes lub autoryzować się w innych usługach w obrębie klastra. Mogą to być zadania automatyzacyjne lub mikroserwisy wymagające określonych uprawnień.
• Dokumentacja: Configure Service Accounts for Pods.

Ingress i kontrolery Ingress

Zasoby Ingress i kontrolery Ingress zarządzają dostępem zewnętrznym do usług w klastrze, korzystając zazwyczaj z protokołu HTTP. Umożliwiają definiowanie reguł routingu ruchu dla różnych usług.

apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
name: example-ingress 
spec: 
rules: 
- host: www.example.com 
 http: 
 paths: 
 - path: / 
 pathType: Prefix 
 backend: 
 service: 
 name: example-service 
 port: 
 number: 80 

• Cele: Zapewnienie scentralizowanej, skalowalnej i bezpiecznej metody zarządzania dostępem do usług Kubernetes z zewnątrz klastra.
• Kiedy stosować: Kontrolery Ingress i zasoby Ingress są niezbędne dla każdej aplikacji, która wymaga kontrolowanego dostępu zewnętrznego do klastra Kubernetes. Są szczególnie istotne przy zarządzaniu wieloma usługami lub wdrażaniu routingu opartego na URL.
• Dokumentacja: Ingress, Ingress Controllers.

Persistent Volumes

Persistent Volumes (PV) oraz Persistent Volume Claims (PVC) są wygodnymi narzędziami w Kubernetes do zarządzania pamięcią, abstrahując szczegóły dotyczące przechowywania i manipulacji danymi.

apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: example-pv 
spec: 
capacity: 
 storage: 10Gi 
accessModes: 
 - ReadWriteOnce 
nfs: 
 path: /path/to/data 
 server: nfs-server.example.com 
--- 
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
name: example-pvc 
spec: 
accessModes: 
 - ReadWriteOnce 
resources: 
 requests: 
 storage: 10Gi 

• Cele: Zapewnienie trwałej pamięci dla aplikacji stanowych, która wykracza poza cykl życia poda.
• Kiedy stosować: PV i PVC są używane, gdy aplikacja wymaga trwałej pamięci niezależnej od cyklu życia poda, co zapewnia trwałość i dostępność danych.
• Dokumentacja: Persistent Volumes.

Kontrola dostępu oparta na rolach (RBAC)

Kontrola dostępu oparta na rolach (RBAC) umożliwia zastosowanie szczegółowych polityk kontroli dostępu do zasobów Kubernetes za pomocą ról i powiązań ról, ograniczając uprawnienia w obrębie klastra.

apiVersion: rbac.authorization.k8s.io/v1 
kind: Role 
metadata: 
namespace: default 
name: pod-reader 
rules: 
- apiGroups: [""] 
resources: ["pods"] 
verbs: ["get", "watch", "list"] 
--- 
apiVersion: rbac.authorization.k8s.io/v1 
kind: RoleBinding 
metadata: 
name: read-pods 
namespace: default 
subjects: 
- kind: User 
name: "jane" 
apiGroup: rbac.authorization.k8s.io 
roleRef: 
kind: Role 
name: pod-reader 
apiGroup: rbac.authorization.k8s.io 

• Cele: Wdrożenie zasady najmniejszych uprawnień w całym klastrze Kubernetes. Zasada ta zapewnia, że użytkownicy i aplikacje mają tylko te uprawnienia, które są niezbędne do ich konkretnych wymagań.
• Kiedy stosować: RBAC stosuje się, gdy konieczny jest bezpieczny dostęp do zasobów Kubernetes, szczególnie w środowiskach z wieloma użytkownikami lub zespołami.
• Dokumentacja: Using RBAC Authorization.

Taints and Tolerations

Taints and Tolerations działają razem, aby zapewnić, że pody nie będą uruchamiane na nieodpowiednich węzłach w obrębie klastra.

apiVersion: v1
kind: Node 
metadata: 
name: node1 
spec: 
taints: 
- key: "key1" 
 value: "value1" 
 effect: NoSchedule 

• Cele: Zarządzanie umiejscowieniem podów na węzłach, uwzględniając cechy sprzętowe i programowe, a także inne wymagania zdefiniowane przez użytkownika.
• Kiedy stosować: Zanieczyszczenia i tolerancje są używane do zapobiegania wykonywaniu określonych zadań na konkretnych węzłach, co pozwala na przypisanie tych węzłów do konkretnych obciążeń.
• Dokumentacja: Taints and Tolerations.

Affinity and anti-affinity

Ustawienia Affinity and anti-affinity pozwalają kontrolować, gdzie pody powinny (lub nie powinny) być umieszczane w odniesieniu do innych podów.

apiVersion: apps/v1 
kind: Deployment 
metadata: 
name: with-pod-affinity 
spec: 
selector: 
 matchLabels: 
 app: with-pod-affinity 
template: 
 metadata: 
 labels: 
 app: with-pod-affinity 
 spec: 
 affinity: 
 podAffinity: 
 requiredDuringSchedulingIgnoredDuringExecution:  - labelSelector: 
 matchExpressions:
 - key: security 
 operator: In 
 values: 
 - S1 
 topologyKey: "kubernetes.io/hostname" 
 podAntiAffinity: 
 preferredDuringSchedulingIgnoredDuringExecution:  - weight: 100 
 podAffinityTerm: 
 labelSelector: 
 matchExpressions: 
 - key: security 
 operator: In 
 values: 
 - S2 
 topologyKey: "kubernetes.io/hostname" 

• Cele: Zarządzanie rozkładem podów w obrębie klastra w celu zwiększenia odporności na błędy, dostępności lub spełnienia innych wymagań operacyjnych.
• Kiedy stosować: Ustawienia affinity i anti-affinity zapewniają wysoką dostępność oraz rozkład obciążenia zgodnie z wymaganiami bezpieczeństwa lub innymi warunkami.
• Dokumentacja: Assigning Pods to Nodes.

Zadania (Jobs) i zadania cykliczne (CronJobs)

Funkcja Zadania zarządza zadaniami, które muszą być uruchomione raz, podczas gdy opcja Zadania cykliczne zarządza zadaniami, które muszą być uruchamiane w określonych interwałach czasowych.

apiVersion: batch/v1 
kind: Job 
metadata: 
name: example-job 
spec: 
template: 
 spec: 
 containers: 
 - name: hello 
 image: busybox
 command: ["sh", "-c", "echo Hello Kubernetes! && sleep 30"]  restartPolicy: Never 
--- 
apiVersion: batch/v1beta1 
kind: CronJob 
metadata: 
name: example-cronjob 
spec: 
schedule: "*/5 * * * *" 
jobTemplate: 
 spec: 
 template: 
 spec: 
 containers: 
 - name: hello 
 image: busybox 
 command: ["sh", "-c", "echo Hello Kubernetes! && sleep 30"]  restartPolicy: OnFailure 

• Cele: Automatyzacja zadań w Kubernetes, takich jak tworzenie kopii zapasowych, konserwacja, usuwanie pamięci podręcznej itp.
• Kiedy stosować: Zadania i zadania cykliczne są używane do uruchamiania zadań jednorazowo lub w określonych interwałach czasowych.
• Dokumentacja: Jobs, CronJob.

Podsumowanie

Podane konfiguracje Kubernetes stanowią podstawę do tworzenia niezawodnych, wydajnych i bezpiecznych aplikacji chmurowych.

Zrozumienie i praktyczne zastosowanie tych ustawień umożliwi Wam odkrycie wszystkich możliwości Kubernetes, wdrażanie zadań specjalnych oraz przestrzeganie optymalnych standardów operacyjnych.

***

Jeśli dla odmiany chcesz dowiedzieć się więcej na temat Dockera, zajrzyj koniecznie do innych artykułów naszych autorów.