Objetos do Kubernetes

• 1: Nomes de objetos e IDs
• 2: Namespaces
• 3: Seletores de Campos

1 - Nomes de objetos e IDs

Cada objeto em seu cluster possui um Nome que é único para aquele tipo de recurso. Todo objeto do Kubernetes também possui um UID que é único para todo o cluster.

Por exemplo, você pode ter apenas um Pod chamado myapp-1234 dentro de um namespace, porém você pode ter um Pod e um Deployment ambos com o nome myapp-1234.

Para atributos não-únicos definidos pelo usuário, o Kubernetes fornece labels e annotations.

Nomes

Uma string fornecida pelo cliente que referencia um objeto em uma URL de recurso, como por exemplo /api/v1/pods/qualquer-nome.

Somente um objeto de um dado tipo pode ter um certo nome por vez. No entanto, se você remover o objeto, você poderá criar um novo objeto com o mesmo nome.

Abaixo estão descritos quatro tipos de restrições de nomes comumente utilizadas para recursos.

Nomes de subdomínio DNS

A maior parte dos recursos do Kubernetes requerem um nome que possa ser utilizado como um nome de subdomínio DNS, conforme definido na RFC 1123. Isso significa que o nome deve:

• conter no máximo 253 caracteres
• conter somente caracteres alfanuméricos em caixa baixa, traço ('-') ou ponto ('.').
• iniciar com um caractere alfanumérico
• terminar com um caractere alfanumérico

Nomes de rótulos da RFC 1123

Alguns tipos de recurso requerem que seus nomes sigam o padrão de rótulos DNS definido na RFC 1123. Isso significa que o nome deve:

• conter no máximo 63 caracteres
• conter somente caracteres alfanuméricos em caixa baixa ou traço ('-')
• iniciar com um caractere alfanumérico
• terminar com um caractere alfanumérico

Nomes de rótulo da RFC 1035

Alguns tipos de recurso requerem que seus nomes sigam o padrão de rótulos DNS definido na RFC 1035. Isso significa que o nome deve:

• conter no máximo 63 caracteres
• conter somente caracteres alfanuméricos em caixa baixa ou traço ('-')
• iniciar com um caractere alfanumérico
• terminar com um caractere alfanumérico

Nomes de segmentos de caminhos

Alguns tipos de recurso requerem que seus nomes possam ser seguramente codificados como um segmento de caminho, ou seja, o nome não pode ser "." ou ".." e não pode conter "/" ou "%".

Exemplo de um manifesto para um Pod chamado nginx-demo.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

UIDs

Uma string gerada pelos sistemas do Kubernetes para identificar objetos de forma única.

Cada objeto criado durante todo o ciclo de vida do cluster do Kubernetes possui um UID distinto. O objetivo deste identificador é distinguir ocorrências históricas de entidades semelhantes.

UIDs no Kubernetes são identificadores únicos universais (também conhecidos como UUIDs). UUIDs seguem os padrões ISO/IEC 9834-8 e ITU-T X.667.

Próximos passos

• Leia sobre labels no Kubernetes.
• Consulte o documento de design Identifiers and Names in Kubernetes.

2 - Namespaces

No Kubernetes, namespaces disponibilizam um mecanismo para isolar grupos de recursos dentro de um único cluster. Nomes de recursos precisam ser únicos dentro de um namespace, porém podem se repetir em diferentes namespaces. Escopos baseados em namespaces são aplicáveis apenas para objetos com namespace (como: Deployments, Services, etc) e não em objetos que abrangem todo o cluster (como: StorageClass, Nodes, PersistentVolumes, etc).

Quando Utilizar Múltiplos Namespaces

Namespaces devem ser utilizados em ambientes com múltiplos usuários espalhados por diversos times ou projetos. Para clusters com poucos ou até algumas dezenas de usuários, você não deveria precisar criar ou pensar a respeito de namespaces. Comece a utilizar namespaces quando você precisar das funcionalidades que eles oferecem.

Namespaces oferecem escopo para nomes. Nomes de recursos precisam ser únicos dentro de um namespace, porém não em diferentes namespaces. Namespaces não podem ser aninhados dentro de outros namespaces e cada recurso Kubernetes pode pertencer à apenas um namespace.

Namespaces nos permitem dividir os recursos do cluster entre diferentes usuários (via resource quota).

Não é necessário utilizar múltiplos namespaces para separar recursos levemente diferentes, como diferentes versões de um mesmo software: use labels para distinguir recursos dentro de um mesmo namespace.

Trabalhando com Namespaces

Criação e eliminação de namespaces estão descritas na documentação de namespaces do guia de administradores.

Visualizando namespaces

Você pode obter uma lista dos namespaces atuais dentro de um cluster com:

kubectl get namespace

NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

O Kubernetes é inicializado com quatro namespaces:

• default O namespace padrão para objetos sem namespace
• kube-system O namespace para objetos criados pelo sistema Kubernetes
• kube-public Este namespace é criado automaticamente e é legível por todos os usuários (incluindo usuários não autenticados). Este namespace é reservado principalmente para uso do cluster, no caso de alguns recursos que precisem ser visíveis e legíveis publicamente por todo o cluster. O aspecto público deste namespace é apenas uma convenção, não um requisito.
• kube-node-lease Este namespace contém os objetos de Lease associados com cada node. Node leases permitem que o kubelet envie heartbeats para que a camada de gerenciamento detecte falhas nos nodes.

Preparando o namespace para uma requisição

Para preparar o namespace para a requisição atual, utilize o parâmetro --namespace. Por exemplo:

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>

Configurando a preferência de namespaces

Você pode salvar permanentemente o namespace para todos os comandos kubectl subsequentes no mesmo contexto:

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validando
kubectl config view --minify | grep namespace:

Namespaces e DNS

Quando você cria um Serviço, ele cria uma entrada DNS correspondente. Esta entrada possui o formato: <service-name>.<namespace-name>.svc.cluster.local, de forma que se um contêiner utilizar apenas <service-name> ele será resolvido para um serviço que é local ao namespace. Isso é útil para utilizar a mesma configuração em vários namespaces, por exemplo em Desenvolvimento, Staging e Produção. Se você quiser acessar múltiplos namespaces, precisará utilizar um Fully Qualified Domain Name (FQDN).

Nem todos os objetos pertencem a algum Namespace

A maior parte dos recursos Kubernetes (como Pods, Services, controladores de replicação e outros) pertencem a algum namespace. Entretanto, recursos de namespaces não pertencem a nenhum namespace. Além deles, recursos de baixo nível, como nodes e persistentVolumes, também não pertencem a nenhum namespace.

Para visualizar quais recursos Kubernetes pertencem ou não a algum namespace, utilize:

# Em um namespace
kubectl api-resources --namespaced=true

# Sem namespace
kubectl api-resources --namespaced=false

Rotulamento Automático

A camada de gerenciamento Kubernetes configura um label imutável kubernetes.io/metadata.name em todos os namespaces se a feature gate NamespaceDefaultLabelName estiver habilitada. O valor do label é o nome do namespace.

Próximos passos

• Leia sobre a criação de um novo namespace.
• Leia sobre a eliminação de um namespace.

3 - Seletores de Campos

Os Seletores de Campos permitem que você selecione recursos do Kubernetes baseado no valor de um ou mais campos de um recurso. Seguem alguns exemplos de buscas utilizando seletores de campos:

• metadata.name=my-service
• metadata.namespace!=default
• status.phase=Pending

O comando kubectl, mostrado a seguir, seleciona todos os Pods nos quais o valor do campo status.phase é Running:

kubectl get pods --field-selector status.phase=Running

Campos suportados

Os campos de seleção suportados variam dependendo do tipo de recurso Kubernetes. Todos os tipos de recursos suportam os campos metadata.name e metadata.namespace. Utilizar campos não suportados produz um erro. Como por exemplo:

kubectl get ingress --field-selector foo.bar=baz

Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

Operadores suportados

Você pode utilizar os operadores =, == e != com seletores de campos (= e == significam a mesma coisa). Por exemplo, o comando kubectl a seguir seleciona todos os Kubernetes Services que não estão no namespace default:

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default

Seletores em cadeia

Assim como label e outros tipos de seletores, podem ser utilizados em cadeia através de uma lista separada por vírgula. O comando kubectl a seguir seleciona todos os Pods nos quais status.phase não é igual a Running e spec.restartPolicy é igual a Always

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

Múltiplos tipos de recursos

Você pode utilizar seletores de campos através de múltiplos tipos de recursos. Por exemplo, o comando kubectl a seguir seleciona todos Statefulsets e Services que não estão presentes no namespace default.

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default