Kuidas tagada pilve Kubernetes-klasteri ja füüsiliste…

Et tagamiseks, et tagada pilvepõhise Kubernetes-klasteri ja füüsiliste serverite ühine toimimine ning säilitada mõned podid füüsilistel masinatel, saab kasutada järgmisi lähenemisviise:

Mitmeklasteri konfiguratsioon:
- Eraldi Kubernetes-klaster pilves ja eraldi Kubernetes-klaster füüsilistel serveritel.
- Kasutada teenuse-meshi (näiteks Istio, Linkerd), et tagada läbipaistev suhtlus erinevate klasterite vahel.
- Mõlemas klasteris kasutatavate rakenduste haldamiseks saab kasutada mitmeklasterilisi juurutuslahendusi (näiteks Argo CD, Flux CD mitmeklasterilise toe abil).
- Eelised: hea isolatsioon, iga klasteri lihtne haldamine.
- Miinused: keerulisem suhtlus ja juurutus klasterite vahel.
Pilveklasteri laiendamine füüsilistele serveritele:
- Füüsiliste serverite lisamine Kubernetes-klasterisse:
  - Võib olla vajalik pilveteenuse pakkuja, kes toetab hübriidkonfiguratsioone (näiteks GCP Anthos, Azure Arc, AWS EKS Anywhere).
  - Veenduge, et võrguühendus pilve- ja füüsiliste sõlmede vahel oleks usaldusväärne ja madala latentsusega.
- Podide paigutamine füüsilistele sõlmedele kasutades:
  - Node Affinity: määrab eelistused või nõuded podide planeerimiseks teatud märgenditega sõlmedele.
```
// pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-location
            operator: In
            values:
            - physical-server
```
  - Taints ja Tolerations: märgistab füüsilisi sõlmeid "taints" ja võimaldab konkreetsetel podidel "tolerida" neid märke.
```
# Märgistada füüsiline sõlm
kubectl taint nodes physical-server-node node-location=physical:NoSchedule
```
```
// pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  tolerations:
  - key: "node-location"
    operator: "Equal"
    value: "physical"
    effect: "NoSchedule"
```
  - Topoloogiline hajutuskontroll: võib olla kasutusel podide jaotamiseks teatud topoloogilistes domeenides, sealhulgas füüsilistel serveritel.
- Eelised: ühtne haldus, lihtne suhtlus podide vahel.
- Miinused: keerulisem võrguühenduse seadistamine, viivituse probleemid sõlmede vahel.

DaemonSets kasutamine:

Kui podid peavad töötama iga füüsilise serveri või ainult ühe neist, võib DaemonSet olla kasulik. Kasutage Node Selector või Node Affinity, et sihtida ainult füüsilisi servereid.

// daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: physical-server-agent
spec:
  selector:
    matchLabels:
      app: physical-agent
  template:
    metadata:
      labels:
        app: physical-agent
    spec:
      containers:
      - name: agent-container
        image: my-agent-image
      nodeSelector:
        node-location: physical-server

Eelised: lihtne garantii, et pod töötab määratud sõlmel.

Valik sõltub konkreetsetest nõuetest, võrgu infrastruktuurist ja haldamise eelistustest.

Enamikel juhtudel on pilveklasteri laiendamine füüsilistele serveritele Node Affinity ja Taints/Tolerations kasutamisega paindlik ja tõhus lahendus.

Oluline on tagada stabiilne ja turvaline võrguliides pilve- ja kohalikku infrastruktuuri vahel.

Kuidas tagada pilve Kubernetes-klasteri ja füüsiliste serverite koostöö, et hoida mõned podid füüsilistel masinatel?