Accès au cluster et interconnexion

Pour joindre l'API Kubernetes et vos ressources, France Nuage vous fournit un accès géré, prêt à l'emploi : l'accès Kubernetes (kube-access). Si votre besoin va plus loin, l'interconnexion est possible.

Ce que fournit l'accès Kubernetes géré

L'accès Kubernetes est inclus : un réseau privé Headscale dédié à votre organisation, opéré entièrement par France Nuage.

• L'accès à l'API par Capsule Proxy : ce réseau vous relie à Capsule Proxy, le point d'entrée multi-tenant de l'API Kubernetes. Votre kubeconfig le vise sur kube.france-nuage.fr:31443 (ou kube-dc05.france-nuage.fr:31443), joignable une fois votre poste connecté avec le client Tailscale standard.
• Une vue limitée à vos namespaces hosted-* : par Capsule Proxy, vous ne voyez que vos namespaces hosted-* et ce qu'ils contiennent, jamais le reste du cluster ni les autres clients. Vous y consultez vos ressources (journaux, exec, port-forward vers vos bases et vos services) dans les limites des droits de votre compte.
• L'exploitation : serveur Headscale, routeurs, règles d'accès, mises à jour, supervision et sauvegardes sont à notre charge.

Ses limites sont voulues : ses règles d'accès sont fixées par France Nuage, et il ne publie que l'API. Il ne relie pas vos propres machines et ne transporte pas d'autres réseaux.

Quand votre besoin va plus loin

Les briques à votre disposition :

• Un headscale dédié : votre propre réseau privé, dont vous éditez les règles d'accès dans Headplane. Sur demande, France Nuage y publie l'accès à un service managé, une base par exemple.
• Un routeur à vous dans un namespace hosted-* : un pod subnet-routeur qui publie sur votre réseau ce que vos namespaces peuvent joindre, dont l'API Kubernetes. L'exemple en fin de page le détaille.

Qui fait quoi

Élément	France Nuage	Vous
Accès Kubernetes géré	Fournit, opère, fixe les règles d'accès	L'utilisez
Serveur headscale dédié	Opère, met à jour, sauvegarde	Enrôlez vos machines
Règles d'accès du headscale dédié	Fournit l'éditeur (Headplane), pose les règles des routes que nous publions	Rédigez et maintenez le reste
Routeur dans un namespace hosted-*	—	Déployez, surveillez, mettez à jour
Flux sortants de vos namespaces	Ouvre l'API Kubernetes (ports 31443), ouvre les autres flux sur demande	Demandez ce dont vous avez besoin
Droits sur le cluster	Les définit, rien ne les contourne	—

Exemple : publier l'API Kubernetes sur votre headscale dédié

1. Créer l'utilisateur et sa clé

Dans Headplane :

1. Users : créez un utilisateur kube-router.
2. Settings, Pre-Auth Keys : créez une clé pour kube-router, Reusable et Ephemeral cochés, avec une expiration longue. Copiez-la : elle ne se réaffiche pas.

2. Autoriser et approuver les routes

L'API répond sur les trois nœuds de son plan de contrôle : dig +short kube.france-nuage.fr en donne les adresses, aujourd'hui 10.0.1.11, 10.1.1.11 et 10.2.1.11. Dans Headplane, menu Access Control, onglet Edit file, ajoutez cette règle et ces lignes autoApprovers en gardant vos règles existantes :

{
  "acls": [
    { "action": "accept", "src": ["*"], "dst": ["10.0.1.11:31443", "10.1.1.11:31443", "10.2.1.11:31443"] }
  ],
  "autoApprovers": {
    "routes": {
      "10.0.1.11/32": ["kube-router@"],
      "10.1.1.11/32": ["kube-router@"],
      "10.2.1.11/32": ["kube-router@"]
    }
  }
}

Une règle autorise un flux, elle ne crée pas de chemin : il faut aussi le routeur.

3. Stocker la clé dans votre namespace

De préférence dans un namespace hosted-* dédié au routeur :

kubectl -n <NAMESPACE> create secret generic kube-router-authkey \
  --from-literal=TS_AUTHKEY='<la clé créée à l étape 1>'

4. Déployer le routeur

Remplacez <NAMESPACE> et l'adresse de votre headscale dans TS_EXTRA_ARGS, puis kubectl apply -f kube-router.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-router
  namespace: <NAMESPACE>
spec:
  replicas: 2
  selector:
    matchLabels:
      app: kube-router
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: kube-router
    spec:
      automountServiceAccountToken: false
      enableServiceLinks: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app: kube-router
                topologyKey: topology.kubernetes.io/zone
      containers:
        - name: tailscale
          image: tailscale/tailscale:v1.104.1
          env:
            - name: TS_AUTHKEY
              valueFrom:
                secretKeyRef:
                  name: kube-router-authkey
                  key: TS_AUTHKEY
            - name: TS_EXTRA_ARGS
              value: --login-server=https://managed-votreslug-headscale-votreprojet.apps.france-nuage.fr
            - name: TS_ROUTES
              value: 10.0.1.11/32,10.1.1.11/32,10.2.1.11/32
            - name: TS_USERSPACE
              value: "true"
            - name: TS_KUBE_SECRET
              value: ""
            - name: TS_ACCEPT_DNS
              value: "false"
            - name: HOME
              value: /tmp
          livenessProbe:
            exec:
              command: ["sh", "-c", "tailscale --socket=/tmp/tailscaled.sock status --peers=false --json | grep -qE '\"Online\":[[:space:]]*true'"]
            initialDelaySeconds: 60
            periodSeconds: 30
            timeoutSeconds: 10
            failureThreshold: 6
          readinessProbe:
            exec:
              command: ["sh", "-c", "tailscale --socket=/tmp/tailscaled.sock status --peers=false --json | grep -qE '\"Online\":[[:space:]]*true'"]
            initialDelaySeconds: 10
            periodSeconds: 15
            timeoutSeconds: 10
            failureThreshold: 4
          resources:
            requests: { cpu: 50m, memory: 64Mi, ephemeral-storage: 16Mi }
            limits: { cpu: 200m, memory: 256Mi, ephemeral-storage: 64Mi }
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 64Mi

Les deux pods se répartissent sur deux zones : l'un sert les routes, l'autre prend le relais.

5. Vérifier

Dans Headplane, menu Machines, deux machines kube-router-* apparaissent en ligne, avec leurs trois routes approuvées. Sur votre poste, enrôlé sur votre headscale dédié avec --accept-routes, votre kubeconfig habituel fonctionne tel quel :

kubectl -n <un de vos namespaces> get pods

Si ça ne marche pas

• dial tcp 10.x.x.x:31443: i/o timeout : aucune route n'atteint votre poste. Vérifiez qu'il est enrôlé sur votre headscale dédié avec --accept-routes, que les routes des kube-router-* sont approuvées, et que la règle vise le port 31443.
• Route disponible mais pas approuvée : le nom dans autoApprovers ne correspond pas à l'utilisateur de la clé (kube-router@ attend l'utilisateur kube-router).
• Pods qui ne démarrent pas : kubectl -n <NAMESPACE> describe pod -l app=kube-router. Un quota dépassé, un secret absent ou une clé expirée sont les causes habituelles.

Références

• VPN Zero Trust Headscale / WireGuard pour votre headscale dédié
• Mettre à jour le certificat de votre kubeconfig
• Subnet routers dans la documentation Tailscale