Bezpłatny fragment - Zaawansowany Kubernetes w moment

I. Wprowadzenie

A. Przypomnienie podstaw Kubernetes

1. Kubernetes w pigułce

Kubernetes, często nazywany K8s, jest platformą open-source służącą do automatyzacji wdrażania, skalowania i zarządzania aplikacjami kontenerowymi. Powstał z inicjatywy Google, a obecnie jest rozwijany przez Cloud Native Computing Foundation (CNCF). Kubernetes pozwala na efektywne zarządzanie zasobami w klastrze, umożliwiając jednoczesne uruchamianie setek, a nawet tysięcy kontenerów.

2. Kluczowe komponenty Kubernetes

• Pod: Najmniejsza jednostka w Kubernetes. Pod może zawierać jeden lub więcej kontenerów.

• ReplicaSet: Zapewnia określoną liczbę identycznych podów.

• Deployment: Zarządza wdrażaniem i skalowaniem podów oraz ReplicaSet.

• Service: Umożliwia komunikację między różnymi komponentami aplikacji oraz z użytkownikami zewnętrznymi.

• Namespace: Sposób na logiczne oddzielenie zasobów w klastrze.

• ConfigMap i Secret: Służą do zarządzania konfiguracjami i danymi wrażliwymi.

3. Architektura Kubernetes

Kubernetes składa się z dwóch głównych komponentów:

• Control Plane: Zarządza stanem klastra. Składa się z kilku komponentów, takich jak kube-apiserver, kube-controller-manager, kube-scheduler oraz etcd.

• Worker Nodes: Miejsca, gdzie uruchamiane są aplikacje. Każdy węzeł ma kubelet (agent odpowiedzialny za zarządzanie podami) oraz kube-proxy (obsługuje networking).

B. Cel książki i dla kogo jest przeznaczona

1. Cel książki

„Zaawansowany Kubernetes w moment” to kontynuacja wprowadzenia do Kubernetes. Naszym celem jest przejście od podstaw do zaawansowanych technik i strategii zarządzania klastrami Kubernetes. Czytelnik nauczy się, jak efektywnie wykorzystać Kubernetes w skomplikowanych środowiskach produkcyjnych, jak implementować najlepsze praktyki, i jak rozwiązywać typowe problemy.

2. Dla kogo jest ta książka?

Ta książka jest przeznaczona dla:

• DevOps Engineerów: którzy chcą pogłębić swoją wiedzę na temat zaawansowanego zarządzania klastrami Kubernetes.

• Administratorów Systemów: którzy zarządzają dużymi, produkcyjnymi wdrożeniami Kubernetes.

• Architektów IT: poszukujących wiedzy na temat projektowania skalowalnych, niezawodnych systemów opartych na Kubernetes.

• Deweloperów: którzy chcą zrozumieć, jak ich aplikacje działają w środowisku Kubernetes oraz jak najlepiej wykorzystać jego możliwości.

3. Struktura książki

Książka podzielona jest na 11 rozdziałów, z których każdy skupia się na innym aspekcie zaawansowanego użytkowania Kubernetes. Rozpoczniemy od zaawansowanego zarządzania zasobami, poprzez strategie skalowania, bezpieczeństwo, aż po zaawansowane techniki wdrażania i monitorowania. Każdy rozdział zawiera praktyczne przykłady oraz kod, który pomoże w zrozumieniu omawianych zagadnień.

4. Wymagania wstępne

Aby w pełni wykorzystać tę książkę, czytelnik powinien mieć podstawową wiedzę na temat Kubernetes, konteneryzacji (Docker), oraz być zaznajomiony z podstawowymi pojęciami z zakresu administracji systemów Linux. Znajomość narzędzi takich jak kubectl, Helm oraz podstawowych koncepcji sieciowych również będzie pomocna.

II. Zaawansowane zarządzanie zasobami

A. Planowanie zasobów na poziomie klastra

1. Wprowadzenie do planowania zasobów

Planowanie zasobów jest kluczowym elementem zarządzania klastrami Kubernetes. Dzięki efektywnemu planowaniu zasobów możemy zapewnić optymalne wykorzystanie zasobów w klastrze, unikając zarówno niedoborów, jak i nadmiaru. Planowanie obejmuje alokację zasobów CPU, pamięci, a także zasobów specyficznych dla aplikacji, takich jak zasoby GPU.

2. Rezerwacja i limity zasobów

W Kubernetes możemy definiować rezerwacje (requests) i limity (limits) zasobów dla kontenerów. Rezerwacje określają minimalną ilość zasobów, jaką kontener potrzebuje do działania, a limity definiują maksymalną ilość zasobów, jaką kontener może zużywać. Przykład konfiguracji rezerwacji i limitów zasobów w pliku YAML:

yaml

apiVersion: v1

kind: Pod

metadata:

name: mypod

spec:

containers:

— name: mycontainer

image: nginx

resources:

requests:

memory: „256Mi”

cpu: „250m”

limits:

memory: „512Mi”

cpu: „500m”

3. QoS (Quality of Service)

Kubernetes definiuje trzy klasy QoS, które determinują priorytety alokacji zasobów dla podów:

• Guaranteed: Kontenery, które mają zdefiniowane zarówno requests, jak i limits na poziomie zasobów.

• Burstable: Kontenery, które mają zdefiniowane requests i mogą, ale nie muszą mieć limits.

• Best-Effort: Kontenery, które nie mają zdefiniowanych żadnych requests ani limits.

QoS pozwala na efektywniejsze zarządzanie zasobami, szczególnie w środowiskach o zmiennym obciążeniu.

4. Overcommitment

Overcommitment to strategia polegająca na alokacji zasobów przekraczających rzeczywiste zasoby fizyczne. Pozwala to na bardziej efektywne wykorzystanie zasobów, jednak niesie ze sobą ryzyko przeciążenia systemu. Kubernetes wspiera overcommitment poprzez mechanizmy cgroups oraz polityki QoS.

B. Zarządzanie zasobami pamięci z wykorzystaniem Cgroups

1. Cgroups w Linux

Cgroups (control groups) są mechanizmem jądra Linux, który pozwala na ograniczanie, kontrolowanie i izolowanie zasobów dla grup procesów. Kubernetes wykorzystuje cgroups do zarządzania zasobami CPU i pamięci dla kontenerów, zapewniając izolację i kontrolę zasobów.

2. Konfiguracja limitów pamięci

Aby zapobiec sytuacjom, w których kontener zużywa zbyt dużo pamięci, możemy ustawić limity pamięci w pliku YAML manifestu Kubernetes:

yaml

apiVersion: v1

kind: Pod

metadata:

name: mypod

spec:

containers:

— name: mycontainer

image: nginx

resources:

limits:

memory: „512Mi” # Ustawienie limitu pamięci na 512 megabajtów

3. Zarządzanie żądaniami pamięci

Żądania pamięci informują Kubernetes o minimalnej ilości pamięci, jaką kontener potrzebuje do poprawnego działania. Poniżej znajduje się przykład ustawienia żądania pamięci:

yaml

apiVersion: v1

kind: Pod

metadata:

name: mypod

spec:

containers:

— name: mycontainer

image: nginx

resources:

requests:

memory: „256Mi” # Ustawienie żądania pamięci na 256 megabajtów

4. Monitorowanie zużycia pamięci

Monitorowanie zużycia pamięci jest kluczowe dla zapewnienia stabilności klastra. Narzędzia takie jak Prometheus i Grafana umożliwiają zbieranie i wizualizację metryk dotyczących zużycia pamięci przez kontenery. Przykładowa konfiguracja Prometheus do monitorowania pamięci:

yaml

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

name: kube-prometheus-service-monitor

labels:

team: frontend

spec:

selector:

matchLabels:

app: nginx

namespaceSelector:

matchNames:

— default

endpoints:

— port: web

interval: 30s

C. Zaawansowane mechanizmy alokacji i planowania zasobów

1. PodAffinity i PodAntiAffinity

PodAffinity i PodAntiAffinity umożliwiają kontrolowanie rozmieszczenia podów w klastrze, definiując zasady współistnienia lub wykluczania podów na węzłach. Przykład konfiguracji PodAffinity:

yaml

apiVersion: v1

kind: Pod

metadata:

name: with-affinity

spec:

affinity:

podAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

— labelSelector:

matchExpressions:

— key: security

operator: In

values:

— S1

topologyKey: "kubernetes.io/hostname”

containers:

— name: with-affinity

image: nginx

2. NodeAffinity

NodeAffinity pozwala na definiowanie zasad, które określają, na których węzłach mogą działać pody. Przykład konfiguracji NodeAffinity:

yaml

apiVersion: v1

kind: Pod

metadata:

name: with-node-affinity

spec:

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

— matchExpressions:

— key: disktype

operator: In

values:

— ssd

containers:

— name: with-node-affinity

image: nginx

3. Taints i Tolerations

Taints i Tolerations są mechanizmami, które pozwalają na kontrolowanie, które pody mogą być uruchamiane na konkretnych węzłach. Przykład konfiguracji taint i toleration:

Taint dodany do węzła:

bash

kubectl taint nodes node1 key=value: NoSchedule

Toleration dodana do podu:

yaml

apiVersion: v1

kind: Pod

metadata:

name: with-toleration

spec:

tolerations:

— key: „key”

operator: „Equal”

value: „value”

effect: „NoSchedule”

containers:

— name: with-toleration

image: nginx

D. Zrównoleglenie pracy aplikacji w klastrze

1. Podzielone aplikacje i mikroserwisy

Jedną z kluczowych korzyści Kubernetes jest możliwość uruchamiania aplikacji podzielonych na mikroserwisy. Każdy mikroserwis może działać niezależnie, skalować się według własnych potrzeb i być zarządzany oddzielnie. Poniżej znajduje się przykładowa konfiguracja aplikacji podzielonej na mikroserwisy:

yaml

apiVersion: v1

kind: Service

metadata:

name: frontend

spec:

selector:

app: frontend

ports:

— protocol: TCP

port: 80

targetPort: 8080

— —

apiVersion: v1

kind: Service

metadata:

name: backend

spec:

selector:

app: backend

ports:

— protocol: TCP

port: 80

targetPort: 8080

— —

apiVersion: apps/v1

kind: Deployment

metadata:

name: frontend

spec:

replicas: 3

selector:

matchLabels:

app: frontend

template:

metadata:

labels:

app: frontend

spec:

containers:

— name: frontend

image: my-frontend-image

ports:

— containerPort: 8080

— —

apiVersion: apps/v1

kind: Deployment

metadata:

name: backend

spec:

replicas: 3

selector:

matchLabels:

app: backend

template:

metadata:

labels:

app: backend

spec:

containers:

— name: backend

image: my-backend-image

ports:

— containerPort: 8080

2. Przetwarzanie równoległe i Batch Jobs

Kubernetes umożliwia również uruchamianie zadań przetwarzania wsadowego (Batch Jobs), które mogą być wykorzystywane do zrównoleglenia pracy aplikacji. Przykład konfiguracji Batch Job:

yaml

apiVersion: batch/v1

kind: Job

metadata:

name: myjob

spec:

template:

spec:

containers:

— name: myjob

image: my-batch-image

command: [„my-command”]

restartPolicy: OnFailure

backoffLimit: 4

Podsumowanie

Zaawansowane zarządzanie zasobami w Kubernetes wymaga zrozumienia i umiejętności korzystania z różnych mechanizmów alokacji zasobów, takich jak rezerwacje, limity, cgroups, affinity, taints i tolerations. Dzięki tym narzędziom i technikom możemy efektywnie zarządzać zasobami w klastrze, zapewniając wysoką wydajność, stabilność i elastyczność naszych aplikacji.

III. Zaawansowane strategie skalowania

A. Elastyczne skalowanie klastrów z użyciem auto-scaling

1. Wprowadzenie do skalowania

Skalowanie w Kubernetes jest kluczowym elementem zarządzania aplikacjami w chmurze, zapewniającym, że aplikacje mogą obsługiwać zmieniające się obciążenia w sposób elastyczny. Kubernetes oferuje różne mechanizmy skalowania, które można dostosować do potrzeb aplikacji, w tym automatyczne skalowanie podów, węzłów oraz całych klastrów.

2. Horizontal Pod Autoscaler (HPA)

Horizontal Pod Autoscaler (HPA) automatycznie skaluje liczbę podów w oparciu o metryki, takie jak zużycie CPU lub pamięci. HPA działa na poziomie Deploymentów, ReplicaSets oraz StatefulSets.

Konfiguracja HPA:

yaml

apiVersion: autoscaling/v2beta2

kind: HorizontalPodAutoscaler

metadata:

name: myapp-hpa

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

name: myapp

minReplicas: 1

maxReplicas: 10

metrics:

— type: Resource

resource:

name: cpu

target:

type: Utilization

averageUtilization: 80

W powyższym przykładzie HPA monitoruje zużycie CPU w aplikacji „myapp” i skalę liczbę podów od 1 do 10, utrzymując średnie zużycie CPU na poziomie 80%.

3. Vertical Pod Autoscaler (VPA)

Vertical Pod Autoscaler (VPA) dostosowuje zasoby (CPU i pamięć) przydzielane poszczególnym podom, na podstawie rzeczywistego zużycia. VPA jest przydatny, gdy aplikacje mają zmienne zapotrzebowanie na zasoby, które niekoniecznie są związane z liczbą podów.

Konfiguracja VPA:

yaml

apiVersion: autoscaling.k8s.io/v1

kind: VerticalPodAutoscaler

metadata:

name: myapp-vpa

spec:

targetRef:

apiVersion: apps/v1

kind: Deployment

name: myapp

updatePolicy:

updateMode: „Auto”

VPA automatycznie dostosowuje zasoby przydzielane podom, co pomaga w optymalizacji wykorzystania zasobów.

4. Cluster Autoscaler

Cluster Autoscaler automatycznie dostosowuje liczbę węzłów w klastrze Kubernetes w odpowiedzi na zmieniające się obciążenie. Cluster Autoscaler działa na podstawie obciążenia podów i dostępności zasobów na węzłach.

Konfiguracja Cluster Autoscaler:

Cluster Autoscaler jest zazwyczaj konfigurowany za pomocą flag w konfiguracji klastra lub przy użyciu narzędzi takich jak kubeadm, kubelet, lub platformy chmurowe (np. AWS, GCP, Azure).

Przykład użycia na AWS:

bash

— cluster-name=my-cluster \

— nodes=2:10:my-nodegroup \

— scale-down-utilization-threshold=0.5 \

— scale-up-from-zero

W powyższym przykładzie Cluster Autoscaler będzie skalować liczbę węzłów od 2 do 10 w grupie węzłów „my-nodegroup”, w zależności od wykorzystania zasobów.

B. Skalowanie aplikacji w oparciu o metryki niestandardowe

1. Wprowadzenie do metryk niestandardowych

Standardowe metryki, takie jak zużycie CPU i pamięci, są często niewystarczające dla bardziej złożonych aplikacji. Dlatego Kubernetes pozwala na skalowanie w oparciu o metryki niestandardowe, takie jak liczba zapytań HTTP, czas odpowiedzi aplikacji, czy obciążenie aplikacji.

2. Custom Metrics API

Custom Metrics API umożliwia skalowanie w oparciu o niestandardowe metryki, które mogą pochodzić z różnych źródeł, takich jak Prometheus, InfluxDB lub inne systemy monitorowania.

Przykład skalowania z użyciem Custom Metrics API:

1. Instalacja adaptera Custom Metrics:

bash

kubectl apply -f https://github.com/kubernetes-sigs/custom-metrics-apiserver/releases/download/v0.6.0/custom-metrics-apiserver-v0.6.0.yaml

2. Konfiguracja HPA z metryką niestandardową:

yaml

apiVersion: autoscaling/v2beta2

kind: HorizontalPodAutoscaler

metadata:

name: myapp-hpa

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

name: myapp

minReplicas: 1

maxReplicas: 10

metrics:

— type: Pods

pods:

metric:

name: request_count

target:

type: AverageValue

averageValue: „100”

W tym przykładzie HPA skaluje liczbę podów w oparciu o liczbę zapytań HTTP, z wartością docelową 100 zapytań na pod.

3. Integracja z Prometheus

Prometheus jest popularnym systemem monitorowania, który może być używany do zbierania niestandardowych metryk. Można go zintegrować z HPA za pomocą adaptera Prometheus Adapter.

Przykład konfiguracji Prometheus Adapter:

1. Instalacja Prometheus Adapter:

bash

kubectl apply -f https://github.com/kubernetes-sigs/prometheus-adapter/releases/download/v0.9.0/prometheus-adapter-v0.9.0.yaml

2. Konfiguracja metryk w Prometheus:

yaml

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

name: myapp-servicemonitor

spec:

selector:

matchLabels:

app: myapp

endpoints:

— port: web

interval: 30s

C. Dynamiczne zarządzanie podami w reakcji na obciążenie

1. Wprowadzenie do dynamicznego zarządzania

Dynamiczne zarządzanie podami polega na dostosowywaniu liczby uruchamianych podów w zależności od bieżącego obciążenia. Kubernetes automatycznie dostosowuje liczbę podów w odpowiedzi na zmieniające się warunki, co zapewnia optymalne wykorzystanie zasobów.

2. Skalowanie w odpowiedzi na obciążenie

1. Skalowanie w oparciu o metryki

Kubernetes może skalować aplikacje w oparciu o metryki, takie jak CPU, pamięć lub niestandardowe metryki, za pomocą HPA lub VPA.

2. Autoskalowanie z wykorzystaniem zapytań HTTP

W przypadku aplikacji webowych, skalowanie może być oparte na liczbie zapytań HTTP. Można to osiągnąć poprzez konfigurację HPA w oparciu o metryki HTTP.

3. Przykład dynamicznego zarządzania podami

Konfiguracja HPA z metrykami niestandardowymi:

yaml

apiVersion: autoscaling/v2beta2

kind: HorizontalPodAutoscaler

metadata:

name: dynamic-hpa

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

name: myapp

minReplicas: 1

maxReplicas: 20

metrics:

— type: Resource

resource:

name: cpu

target:

type: Utilization

averageUtilization: 75

— type: Pods

pods:

metric:

name: request_count

target:

type: AverageValue

averageValue: „50”

W powyższym przykładzie HPA skalować będzie aplikację w oparciu o zużycie CPU oraz liczbę zapytań HTTP.

D. Przewidywanie obciążenia i skalowanie proaktywne

1. Wprowadzenie do przewidywania obciążenia

Przewidywanie obciążenia to technika, która pozwala na proaktywne dostosowanie zasobów w klastrze w oparciu o prognozy obciążenia. Dzięki tej technice można z wyprzedzeniem dostosować liczbę podów lub węzłów, zanim rzeczywiste obciążenie wzrośnie.

2. Techniki przewidywania obciążenia

1. Analiza historycznych danych

Analiza historycznych danych obciążenia pozwala na przewidywanie przyszłych trendów. Można to osiągnąć za pomocą narzędzi do analizy danych, takich jak Prometheus i Grafana, które zbierają i analizują metryki z aplikacji.

2. Uczenie maszynowe

Uczenie maszynowe może być używane do przewidywania obciążenia na podstawie różnych danych wejściowych. Modele predykcyjne mogą analizować wzorce obciążenia i prognozować przyszłe wymagania zasobów.

3. Przykład przewidywania obciążenia

1. Integracja z narzędziami do analizy danych:

Można użyć narzędzi takich jak Prometheus i Grafana do analizy danych i przewidywania obciążenia.

2. Wykorzystanie modeli predykcyjnych:

Wykorzystanie modeli predykcyjnych w połączeniu z Kubernetes może wymagać specjalnych narzędzi i integracji, np. z MLflow lub TensorFlow.

E. Strategia blue-green i canary deployments w skalowaniu

1. Wprowadzenie do strategii wdrażania

Strategie wdrażania, takie jak blue-green i canary deployments, pozwalają na płynne wdrażanie nowych wersji aplikacji, minimalizując ryzyko i zapewniając lepsze zarządzanie obciążeniem.

2. Blue-Green Deployment

Blue-Green Deployment polega na utrzymywaniu dwóch identycznych środowisk (niebieskiego i zielonego). Nowa wersja aplikacji jest wdrażana w środowisku, które nie jest aktualnie używane, a po przetestowaniu, ruch jest przekierowywany na nowe środowisko.

Przykład konfiguracji blue-green deployment:

yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: blue

spec:

replicas: 3

selector:

matchLabels:

app: myapp

version: blue

template:

metadata:

labels:

app: myapp

version: blue

spec:

containers:

— name: myapp

image: myapp: blue

yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: green

spec:

replicas: 3

selector:

matchLabels:

app: myapp

version: green

template:

metadata:

labels:

app: myapp

version: green

spec:

containers:

— name: myapp

image: myapp: green

3. Canary Deployment

Canary Deployment polega na stopniowym wdrażaniu nowej wersji aplikacji do części użytkowników, co pozwala na monitorowanie działania nowej wersji przed pełnym wdrożeniem.

Przykład konfiguracji canary deployment:

yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: myapp-canary

spec:

replicas: 1

selector:

matchLabels:

app: myapp

version: canary

template:

metadata:

labels:

app: myapp

version: canary

spec:

containers:

— name: myapp

image: myapp: canary

4. Narzędzia wspierające strategie wdrażania

Narzędzia takie jak Argo Rollouts, Spinnaker, czy Jenkins X wspierają zaawansowane strategie wdrażania i mogą być używane do implementacji blue-green i canary deployments w Kubernetes.

Przykład konfiguracji Argo Rollouts:

yaml

apiVersion: argoproj.io/v1alpha1

kind: Rollout

metadata:

name: myapp-rollout

spec:

replicas: 3

selector:

matchLabels:

app: myapp

strategy:

canary:

steps:

— setWeight: 20

— pause: {duration: 10m}

— setWeight: 40

— pause: {duration: 10m}

— setWeight: 60

— pause: {duration: 10m}

— setWeight: 80

— pause: {duration: 10m}

— setWeight: 100

template:

metadata:

labels:

app: myapp

spec:

containers:

— name: myapp

image: myapp: latest

Podsumowanie

Zaawansowane strategie skalowania w Kubernetes obejmują różne mechanizmy i techniki, które umożliwiają dynamiczne i efektywne zarządzanie obciążeniem aplikacji. Od automatycznego skalowania podów, przez zaawansowane mechanizmy przewidywania obciążenia, aż po zaawansowane strategie wdrażania, takie jak blue-green i canary deployments — Kubernetes oferuje szeroki wachlarz narzędzi i możliwości dostosowania do potrzeb nowoczesnych aplikacji. Wykorzystanie tych strategii pozwala na optymalizację wydajności, minimalizowanie ryzyka i zapewnianie wysokiej dostępności aplikacji w dynamicznych środowiskach chmurowych.

IV. Bezpieczeństwo i zabezpieczenia

A. Wprowadzenie do bezpieczeństwa w Kubernetes

1. Znaczenie bezpieczeństwa w Kubernetes

Bezpieczeństwo w Kubernetes jest kluczowym aspektem zapewniającym integralność, poufność i dostępność aplikacji oraz danych w klastrze. Bezpieczeństwo obejmuje zarówno ochronę przed nieautoryzowanym dostępem, jak i zabezpieczenie przed nieprawidłowym działaniem lub atakami.

2. Główne obszary bezpieczeństwa

Bezpieczeństwo w Kubernetes można podzielić na kilka głównych obszarów:

• Bezpieczeństwo sieci: Ochrona komunikacji między podami, usługami i zewnętrznymi klientami.

• Bezpieczeństwo kontenerów: Ochrona obrazów kontenerów i zarządzanie ich bezpieczeństwem.

• Autoryzacja i uwierzytelnianie: Kontrola dostępu do zasobów klastra.

• Zarządzanie sekretami: Bezpieczne przechowywanie i zarządzanie poufnymi danymi.

• Monitorowanie i audyt: Zbieranie danych o działaniu klastra i identyfikowanie potencjalnych zagrożeń.

B. Bezpieczeństwo sieci w Kubernetes

1. Network Policies

Network Policies pozwalają na definiowanie reguł dotyczących komunikacji między podami. Można używać ich do ograniczenia dostępu do usług tylko dla wybranych podów lub aplikacji.

Przykład konfiguracji Network Policy:

yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: allow-specific-pods

spec:

podSelector:

matchLabels:

app: myapp

ingress:

— from:

— podSelector:

matchLabels:

role: frontend

ports:

— protocol: TCP

port: 80

W powyższym przykładzie Network Policy zezwala na komunikację na porcie 80 tylko z podów oznaczonych etykietą role: frontend.

2. CNI Plugins

Kubernetes korzysta z różnych pluginów CNI (Container Network Interface), takich jak Calico, Cilium, i Weave, które umożliwiają zaawansowane funkcje sieciowe i bezpieczeństwa. Pluginy te mogą implementować dodatkowe mechanizmy, takie jak izolacja sieciowa i kontrole dostępu.

Przykład instalacji Calico:

bash

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Calico dostarcza zaawansowane funkcje zarządzania siecią i bezpieczeństwem, w tym polityki sieciowe i funkcje monitorowania.

C. Bezpieczeństwo kontenerów

1. Pod Security Standards

Pod Security Standards to zbiór zasad bezpieczeństwa, które definiują, jakie konfiguracje są dozwolone dla podów. Można je wdrożyć w klastrze Kubernetes, aby zapewnić zgodność z najlepszymi praktykami bezpieczeństwa.

Przykład zasad bezpieczeństwa dla podów:

yaml

apiVersion: policy/v1beta1

kind: PodSecurityPolicy

metadata:

name: restricted

spec:

privileged: false

allowPrivilegeEscalation: false

seLinux: