Passer au contenu principal

Fondamentaux (Kubernetes)

Namespaces, Labels et Selectors

Namespaces, labels et selectors sont les mécanismes d'organisation et de ciblage dans Kubernetes. Les namespaces partitionnent le cluster. Les labels annotent les objets. Les selectors les ciblent. Ces trois éléments travaillent ensemble pour structurer un cluster multi-équipes ou multi-applications.

Namespaces

Les namespaces offrent une isolation logique (pas physique) du cluster. Les quotas, RBAC et NetworkPolicies s'appliquent au niveau namespace. Quatre namespaces existent par défaut :

  • default : namespace par défaut si aucun n'est spécifié
  • kube-system : composants Kubernetes (CoreDNS, kube-proxy, metrics-server...)
  • kube-public : données lisibles par tous les utilisateurs non authentifiés
  • kube-node-lease : objets Lease pour les heartbeats des noeuds
# Créer un namespace
kubectl create namespace staging

# Travailler dans un namespace
kubectl get pods -n staging
kubectl apply -f deployment.yaml -n staging

# Changer le namespace par défaut du contexte courant
kubectl config set-context --current --namespace=staging

ResourceQuota

Limite les ressources consommables dans un namespace :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: staging
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"
    services: "10"

LimitRange

Définit des valeurs par défaut et des limites min/max pour les conteneurs qui n'en spécifient pas :

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: staging
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "256Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "2"
      memory: "2Gi"

Labels

Les labels sont des paires clé-valeur attachées à n'importe quel objet Kubernetes. Ils n'ont pas de sémantique imposée par Kubernetes (sauf quelques labels réservés). La convention recommandée par Kubernetes utilise des labels préfixés :

metadata:
  labels:
    app.kubernetes.io/name: myapp
    app.kubernetes.io/version: "1.2.3"
    app.kubernetes.io/component: frontend
    app.kubernetes.io/part-of: myplatform
    app.kubernetes.io/managed-by: helm
    environment: production
    team: platform
# Filtrer par label
kubectl get pods -l app=web
kubectl get pods -l app=web,environment=production
kubectl get pods -l 'environment in (prod,staging)'
kubectl get pods -l '!debug'   # Pods sans le label debug

Annotations

Les annotations sont aussi des paires clé-valeur, mais pour des métadonnées non-identifiantes (non utilisables dans les selectors). Usages : informations de build, liens vers des dashboards, configurations de controllers (ingress, cert-manager...).

metadata:
  annotations:
    kubernetes.io/change-cause: "Deploy v1.2.3 - Fix memory leak"
    prometheus.io/scrape: "true"
    prometheus.io/port: "9090"

Selectors

Les selectors utilisent les labels pour cibler des objets. Deux types :

  • Equality-based : app=web, version!=beta
  • Set-based : env in (prod,staging), tier notin (frontend), !debug

Les Services, Deployments, ReplicaSets et NetworkPolicies utilisent des selectors pour cibler leurs pods. La cohérence des labels entre un Deployment et son Service est critique : un mismatch provoque un Service sans endpoints (trafic perdu en silence).

Sources