Crie cargas de trabalho com estado

Esta página explica como criar e gerir cargas de trabalho com estado num cluster do Kubernetes isolado do ar do Google Distributed Cloud (GDC). As cargas de trabalho com estado permitem-lhe dimensionar a implementação da sua aplicação com armazenamento persistente. O armazenamento persistente fornece à sua aplicação identidades consistentes e nomes de anfitriões estáveis, independentemente de onde as respetivas cargas de trabalho estão agendadas.

Esta página destina-se a programadores no grupo de operadores de aplicações, que são responsáveis por criar cargas de trabalho de aplicações para a respetiva organização. Para mais informações, consulte a documentação sobre públicos-alvo para GDC com isolamento de ar.

Antes de começar

Para executar comandos num cluster do Kubernetes, certifique-se de que tem os seguintes recursos:

  1. Localize o nome do cluster do Kubernetes ou pergunte ao administrador da plataforma qual é o nome do cluster.

  2. Inicie sessão e gere o ficheiro kubeconfig para o cluster Kubernetes, se não tiver um.

  3. Use o caminho kubeconfig do cluster Kubernetes para substituir KUBERNETES_CLUSTER_KUBECONFIG nestas instruções.

Para receber as autorizações necessárias para criar cargas de trabalho com estado, peça ao administrador de IAM da organização que lhe conceda a função de administrador do espaço de nomes (namespace-admin) no espaço de nomes do projeto.

Crie um recurso StatefulSet

Crie um objeto StatefulSet escrevendo um manifesto StatefulSet e executando kubectl apply para criar o recurso. Para oferecer uma forma estável de os clientes enviarem pedidos para os pods do seu recurso StatefulSet, também tem de criar um objeto Service.

O comando kubectl apply usa ficheiros de manifesto para criar, atualizar e eliminar recursos no seu cluster do Kubernetes. Este é um método declarativo de configuração de objetos. Este método retém as gravações feitas em objetos ativos sem intercalar as alterações novamente nos ficheiros de configuração de objetos.

Para criar um recurso StatefulSet e Service, execute:

kubectl --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG -n NAMESPACE \
    apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  labels:
    app: APP_NAME
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: APP_NAME
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: STATEFULSET_NAME
spec:
  selector:
    matchLabels:
      app: APP_LABEL_NAME
  serviceName: "SERVICE_NAME"
  replicas: NUMBER_OF_REPLICAS
  template:
    metadata:
      labels:
        app: APP_LABEL_NAME
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: CONTAINER_STORAGE_VOLUME_PATH
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
EOF

Substitua o seguinte:

  • KUBERNETES_CLUSTER_KUBECONFIG: o ficheiro kubeconfig para o cluster no qual está a implementar cargas de trabalho de contentores.

  • NAMESPACE: o espaço de nomes do projeto no qual implementar as cargas de trabalho do contentor.

  • SERVICE_NAME: o nome do objeto Service. Certifique-se de que o objeto StatefulSet define o objeto Service no respetivo serviceName também.

  • APP_NAME: o nome da aplicação a executar na implementação.

  • APP_LABEL_NAME: o seletor de etiquetas que determina a que pods pertence o objeto StatefulSet.

  • STATEFULSET_NAME: o nome do objeto StatefulSet

  • NUMBER_OF_REPLICAS: o número de objetos Pod replicados que a implementação gere.

  • CONTAINER_NAME: o nome do contentor.

  • CONTAINER_IMAGE: o nome da imagem do contentor. Tem de incluir o caminho do registo de contentores e a versão da imagem, como REGISTRY_PATH/nginx:1.23. Para mais informações sobre como definir o caminho do registo de contentores, consulte a vista geral do serviço Harbor gerido.

  • CONTAINER_STORAGE_VOLUME_PATH: o caminho no contentor no qual um volume de armazenamento está montado.

Por exemplo, o objeto StatefulSet seguinte e o objeto Service correspondente criam cargas de trabalho de contentores com estado:

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: REGISTRY_PATH/nginx:1.23
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Neste exemplo:

  • É criado um objeto Service com o nome nginx, indicado pelo campo metadata: name. O objeto Service segmenta uma app denominada nginx, indicada por labels.app: nginx e selector.app: nginx. O objeto Service expõe a porta 80 e atribui-lhe o nome web. Este objeto Service controla o domínio de rede e encaminha o tráfego da Internet para a aplicação em contentor implementada pelo objeto StatefulSet.
  • É criado um StatefulSet denominado web com três objetos Pod replicados, conforme definido pelo campo replicas: 3.
  • O modelo Pod, definido pela secção .spec.template, indica que os respetivos objetos Pod estão etiquetados como app: nginx.
  • A especificação Pod, definida pela secção .template.spec, indica que os pods do StatefulSet executam um contentor, nginx, que executa a imagem nginx na versão 1.23.
  • A especificação Pod usa a porta Web aberta pelo objeto Service.
  • A secção .template.spec.volumeMounts especifica um campo mountPath, que tem o nome www. O mountPath é o caminho no contentor onde um volume de armazenamento está montado.
  • O StatefulSet aprovisiona três objetos PersistentVolumeClaim, denominados web-www-0, web-www-1 e web-www-2, com 1 GB de armazenamento aprovisionado cada.

Depois de criado, o StatefulSet garante que o número pretendido de objetos Pod está em execução e disponível em todos os momentos. O StatefulSet substitui automaticamente os objetos Pod que falham ou são removidos dos respetivos nós e associa novos objetos Pod aos recursos de armazenamento, aos pedidos de recursos e aos limites, e a outras configurações definidas na especificação Pod do objeto StatefulSet.

Peça armazenamento persistente num recurso StatefulSet

O armazenamento persistente pode ser aprovisionado dinamicamente para que os volumes subjacentes sejam criados a pedido. As aplicações podem pedir armazenamento persistente com um objeto PersistentVolumeClaim.

Normalmente, tem de criar PersistentVolumeClaim objetos, além de criar o objeto Pod. No entanto, os objetos StatefulSet incluem uma matriz volumeClaimTemplates que gera os objetos PersistentVolumeClaim. Cada réplica StatefulSet recebe o seu próprio objeto PersistentVolumeClaim.

Para mais informações, consulte o artigo Configure o armazenamento do contentor.