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 tem vários exemplos, incluindo formato não estruturado e formato hierárquico, modo de vários repositórios e modo sem vários repositórios ,repositório raiz e repositórios de namespace.

    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 ao kubectl (em inglês). 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