Como garantir a colaboração entre um cluster…

Para garantir a interoperabilidade entre um cluster Kubernetes na nuvem e servidores físicos, mantendo alguns pods em máquinas físicas, podem ser utilizados os seguintes métodos:

Configuração multi-cluster:
- Um cluster Kubernetes na nuvem e outro em servidores físicos.
- Utilizar um service mesh (por exemplo, Istio, Linkerd) para garantir comunicação transparente entre pods em diferentes clusters.
- Para gerir implementações em ambos os clusters, usar soluções de implantação multi-cluster (por exemplo, Argo CD, Flux CD com suporte multi-cluster).
- Vantagens: boa isolamento, facilidade de gestão de cada cluster separadamente.
- Desvantagens: maior complexidade na gestão de comunicação e implantações entre clusters.
Extensão do cluster na nuvem para servidores físicos:
- Adicionar servidores físicos como nós no cluster Kubernetes.
  - Pode requerer um provedor de nuvem que suporte configurações híbridas (por exemplo, GCP Anthos, Azure Arc, AWS EKS Anywhere).
  - Garantir que a conectividade de rede entre os nós na nuvem e físicos seja confiável e de baixa latência.
- Implantação de pods em nós físicos usando:
  - Node Affinity: Indica preferências ou requisitos para agendar pods em nós com etiquetas específicas.
```
// 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 e Tolerations: Marcam os nós físicos com "taints" e permitem que pods específicos "tolere" essas etiquetas. Isto impede que pods sejam executados em nós físicos a menos que seja explicitamente permitido.
```
# Marcar nó físico
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"
```
  - Restrições de distribuição de topologia: Pode ser usado para distribuir pods por domínios topológicos específicos, incluindo servidores físicos.
- Vantagens: gestão unificada do cluster, comunicação simplificada entre pods.
- Desvantagens: complexidade na configuração e manutenção da conectividade de rede, potenciais problemas de latência entre os nós.

Uso de DaemonSets:

Se os pods devem funcionar em cada ou um dos servidores físicos, um DaemonSet pode ser útil. Pode usar Node Selector ou Node Affinity com DaemonSet para direcionar apenas para servidores físicos.

// 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

Vantagens: garantia simples de que o pod funciona em nós específicos.

A escolha do método depende dos requisitos específicos, infraestrutura de rede e preferências de gestão. Na maioria dos casos, ampliar o cluster na nuvem para servidores físicos usando Node Affinity e Taints/Tolerations é uma solução flexível e eficiente. É importante garantir uma conexão de rede estável e segura entre a infraestrutura na nuvem e a local.

Como garantir a colaboração entre um cluster Kubernetes na nuvem e servidores físicos para manter alguns pods em máquinas físicas?