Como configurar objetos do Kubernetes

Neste tópico, você vê como criar configurações. Eles são os arquivos que o Config Sync lê do Git e aplica aos clusters automaticamente.

Antes de começar

  • Você precisa entender o básico da sintaxe YAML ou JSON, porque as configurações são gravadas em um desses dois formatos. O YAML é usado em todos os exemplos desta documentação porque a leitura dele é mais fácil.

  • Tipos diferentes de objetos do Kubernetes têm opções configuráveis distintas. É útil entender como você consegue a configuração desejada manualmente antes de gravar um config para esse tipo de objeto.

  • Se você optar por usar um repo hierárquico, compreenda a estrutura do repo hierárquico. A localização de uma configuração dentro do repositório afeta os clusters e os namespaces em que ela é aplicada. Isso é especialmente importante para o diretório namespaces/, porque os subdiretórios de namespaces/ podem herdar configurações dos diretórios de namespaces abstratos.

  • Um repositório de exemplo (em inglês) canônico foi criado para ilustrar como o Config Sync de configuração funciona. Ele inclui exemplos para os seguintes tipos de repositórios:

    Os exemplos neste tópico foram retirados desse repo, então pode ser útil manter o repo aberto em um navegador ou cloná-lo em seu sistema local.

Criação de config

Ao criar um config, decida a melhor localização no repo e os campos a serem incluídos.

Localização no repositório

  • Para repositórios não estruturados, organize as configurações arbitrariamente e crie subpastas de recursos.

  • Para repositórios hierárquicos, o local de um config no repo é um dos fatores que determina a quais clusters ele se aplica:

    • As configurações de objetos com escopo de cluster, exceto os namespaces, são armazenadas no diretório cluster/ do repositório.
    • As configurações de namespaces e objetos com escopo de namespace são armazenadas no diretório namespaces/ do repositório.
    • As configurações dos componentes do Config Sync são armazenadas no diretório system/ do repositório.
    • O config do Config Management Operator não é armazenado diretamente no repositório e não é sincronizado.

Conteúdo do config

Os configs usam uma abordagem aditiva, semelhante a kubectl. Ao criar novos objetos, você precisa incluir todos os campos obrigatórios. No entanto, ao atualizar objetos atuais, você só precisa fornecer os campos que precisa modificar.

O config, quando aplicado, precisa resultar em um objeto válido do Kubernetes.

Configs de exemplo

Os configs de exemplo a seguir são todos tirados do repo de exemplo. Com base neles, você conseguirá gravar seus próprios configs. Esta lista não está completa. É possível configurar qualquer tipo de objeto do Kubernetes usando o Config Sync.

Config Namespace

Esta configuração cria um namespace chamado gamestore.

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore

Ao criar uma configuração de namespace, também é possível adicionar rótulos ou anotações ao namespace. Os rótulos são necessários ao usar um NamespaceSelector.

O exemplo de configuração a seguir cria um namespace chamado gamestore quando ele não existe ou não é gerenciado. O namespace tem o rótulo app: gamestore e a anotação retail: true. Se os metadados do objeto forem modificados manualmente, o Config Sync os redefinirá rapidamente como o valor na configuração.

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore
  labels:
    app: gamestore
  annotations:
    retail: "true"

Para mais informações sobre como trabalhar com namespaces, consulte Como configurar namespaces e objetos com escopo de namespace.

Config ClusterRole

Essa configuração cria um ClusterRole chamado namespace-reader, que fornece a capacidade de ler (acessar, monitorar e listar) todos os objetos namespace no cluster. Um config ClusterRole costuma ser usado com um config ClusterRoleBinding.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-reader
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]

Config ClusterRoleBinding

Esta configuração cria um ClusterRoleBinding chamado namespace-readers. Ele concede ao usuário cheryl@example.com o ClusterRole namespace-reader.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-readers
subjects:
- kind: User
  name: cheryl@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBindings têm escopo de cluster e não podem ser colocadas em diretórios de namespace ou namespaces abstratos.

Config PodSecurityPolicy

Neste exemplo, você cria um PodSecurityPolicy chamado psp. Ele proíbe a execução de contêineres privilegiados e permite que contêineres sejam executados como qualquer usuário válido no nó.

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

PodSecurityPolicies têm escopo de cluster e não podem ser colocadas em diretórios de namespace ou namespaces abstratos.

Config NetworkPolicy

Neste exemplo, você cria um NetworkPolicy chamado default-deny-all-traffic.

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

NetworkPolicies têm escopo de namespace e só podem ser colocadas em diretórios de namespace ou namespaces abstratos.

Quando você aplica a NetworkPolicy acima a um único namespace, ela isola todos os pods desse namespace do tráfego de entrada e saída.

Quando você aplica a mesma NetworkPolicy a vários namespaces, colocando-a em um namespace abstrato com os namespaces descendentes, cada um desses namespaces herda a NetworkPolicy. No repositório de exemplo de herança de namespace, o diretório namespaces contém dois namespaces abstratos, eng e rnd, e cada namespace abstrato contém Dois namespaces reais, analytics e gamestore, incubator-1 e incubator-2, respectivamente. Se você adicionar a default-deny-all-traffic NetworkPolicy acima aos namespaces abstratos, os quatro namespaces reais herdarão a NetworkPolicy, para que cada um dos pods seja protegido do tráfego de entrada e saída.

É possível usar a herança de namespace para impor uma abordagem de privilégio mínimo à segurança. Por exemplo, se o exemplo anterior for aplicado a namespaces abstratos e o NetworkPolicy a seguir for adicionado ao namespace abstrato eng, o tráfego de entrada será permitido apenas para os pods nos namespaces descendentes com O rótulo app:gamestore. Os namespaces analytics, incubator-1 e incubator-2 não são impactados por essa NetworkPolicy.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-gamestore-ingress
spec:
  podSelector:
    matchLabels:
      app: gamestore
  ingress:
  - {}

Config ResourceQuota

Neste exemplo, você cria uma configuração ResourceQuota (em inglês) chamada quota. Ela define um limite absoluto de um pod, 100 mili-CPUs e 100 mebibytes (MiB) de memória.

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
spec:
  hard:
    pods: "1"
    cpu: "100m"
    memory: "100Mi"

Se a criação de um novo objeto de um determinado tipo violar um ResourceQuota atual, o Kubernetes não poderá criar esse objeto até que isso não viole mais o ResourceQuota.

Config RepoSync

Este exemplo cria um objeto RepoSync no repositório raiz, que é sincronizado a partir de um repositório de namespaces. Para mais informações sobre como configurar o objeto RepoSync, consulte Como configurar a sincronização a partir de repositórios de namespace.

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: repo-sync
  namespace: gamestore
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: main
    dir: quickstart/multirepo/namespaces/gamestore
    auth: none

O Config Sync cria um reconciliador de namespace para sincronizar a partir do repositório de namespaces.

A seguir