Apprendre les bases de Kubernetes

Tâches

Kubernetes v1.16 documentation non maintenue. Vous consultez une version statique. Pour une documentation à jour, veuillez consulter: dernière version.

Edit This Page

Kubernetes cloud-controller-manager

FEATURE STATE: Kubernetes v1.16 beta
Cette fonctionnalité est actuellement dans un état beta, c’est-à-dire :

  • Les noms de version contiennent: beta (par ex. v2beta3).
  • Le code est bien testé. L’activation de cette fonctionnalité est considérée comme sûre. Elle est activée par défaut.
  • La prise en charge de l’ensemble de la fonctionnalité ne sera pas supprimée, bien que des détails puissent changer.
  • Le schéma et/ou la sémantique des objets peuvent changer de manière incompatible dans une version bêta ou stable ultérieure. Lorsque cela se produira, nous vous fournirons des instructions pour migrer vers la prochaine version. Cela peut nécessiter la suppression, l’édition et la recréation d’objets API. Le processus de changement de version peut nécessiter une certaine réflexion. Cela peut aussi nécessiter une interruption de service pour les applications qui s’appuient sur cette fonctionnalité.
  • Recommandé uniquement pour les utilisations non critiques en raison du risque de changements incompatibles dans les versions ultérieures. Si vous avez plusieurs clusters qui peuvent être mis à niveau indépendamment, vous pouvez assouplir cette restriction.
  • Donnez votre avis sur cette fonctionnalité bêta ! Une fois qu’elle aura quitté la version bêta, ce sera probablement moins évident pour nous d’apporter d’autres changements.

Kubernetes v1.6 a introduit un nouveau binaire appelé cloud-controller-manager. cloud-controller-manager est un démon qui intègre des boucles de contrôle spécifiques au cloud. Ces boucles de contrôle spécifiques au cloud étaient à l’origine dans le binaire kube-controller-manager. Étant donné que les fournisseurs de cloud développent et publient à un rythme différent de celui du projet Kubernetes, fournir une abstraction du code du cloud-controller-manager permet aux fournisseurs de cloud d’évoluer indépendamment du code Kubernetes principal.

Le cloud-controller-manager peut être lié à tout fournisseur de cloud satisfaisant l’interface cloudprovider.Interface. Pour des raisons de retro-compatibilité, le cloud-controller-manager fourni dans le projet de base Kubernetes utilise les mêmes bibliothèques ​​que kube-controller-manager. Les fournisseurs de cloud déjà pris en charge nativement par Kubernetes devraient utiliser le cloud-controller-manager ​disponible ​dans le code de Kubernetes pour effectuer une transition visant à faire sortir cette prise en charge du code de Kubernetes. Dans les futures versions de Kubernetes, tous les cloud-controller-manager seront développés en dehors du projet de base de Kubernetes géré par des sig leads ou des fournisseurs de cloud.

Administration

Pré-requis

Chaque cloud a ses propres exigences pour l’exécution de sa propre intégration, ces exigences sont similaires à celles requises pour l’exécution de kube-controller-manager. En règle générale, vous aurez besoin de:

  • cloud authentification/autorisation: votre cloud peut nécessiter un jeton ou des règles IAM pour permettre l’accès à leurs API
  • kubernetes authentification/autorisation: cloud-controller-manager peut avoir besoin de règles RBAC définies pour parler à l’apiserver kubernetes
  • la haute disponibilité: Comme pour kube-controller-manager, vous pouvez souhaiter une configuration hautement disponible pour le cloud controller mananger en utilisant l’élection de leader (activée par défaut).

Lancer cloud-controller-manager

L’exécution réussie de cloud-controller-manager nécessite certaines modifications de la configuration de votre cluster.

  • kube-apiserver et kube-controller-manager NE DOIVENT PAS spécifier l’option --cloud-provider. Cela garantit qu’il n’exécutera aucune boucle spécifique au cloud qui serait exécutée par le cloud-controller-manager. À l’avenir, cet indicateur sera rendu obsolète et supprimé.
  • kubelet doit s’exécuter avec --cloud-provider=external. C’est pour nous assurer que le kubelet est conscient qu’il doit être initialisé par le cloud-controller-manager avant qu’il ne commence à travailler.

N’oubliez pas que la configuration de votre cluster pour utiliser le cloud-controller-manager changera le comportement de votre cluster de plusieurs façons:

  • Les kubelets lancés avec --cloud-provider=external auront un marquage node.cloudprovider.kubernetes.io/uninitialized avec un effet NoSchedule pendant l’initialisation. Cela indique que le nœud nécessite une seconde initialisation à partir d’un contrôleur externe avant de pouvoir planifier un travail. Notez que si le cloud-controller-manager n’est pas disponible, les nouveaux nœuds du cluster ne seront pas valides. Le marquage est important car le planificateur peut nécessiter des informations spécifiques au cloud à propos des nœuds, telles que leur région ou leur type (CPU performant, gpu, mémoire importante, instance ponctuelle, etc.).
  • Les informations relatives aux nœuds s’exécutant dans le cloud ne seront plus récupérées à l’aide de métadonnées locales, mais tous les appels d’API pour récupérer les informations de ces nœuds passeront par le cloud-controller-manager. Cela peut signifier que vous pouvez restreindre l’accès à votre API de cloud sur les kubelets pour une sécurité accrue. Pour les clusters de plus grande taille, vous voudrez peut-être déterminer si le cloud-controller-manager atteindra les limites de requêtes sur les API de votre fournisseur de cloud puisqu’il est désormais responsable de la quasi-totalité des appels d’API vers votre cloud depuis le cluster.

À partir de la version 1.8, le cloud-controller-manager peut implémenter:

  • contrôleur de nœud - responsable de la mise à jour des nœud kubernetes à l’aide des API de cloud et de la suppression des nœud kubernetes supprimés sur votre cloud.
  • contrôleur de service - responsable des loadbalancers sur votre cloud vers des services de type LoadBalancer.
  • contrôleur de route - responsable de la configuration des routes réseau sur votre cloud
  • toute autre fonctionnalité que vous voudriez implémenter si vous exécutez en dehors de l’arborescence de Kubernetes.

Exemples

Si vous utilisez un cloud actuellement pris en charge nativement dans Kubernetes et souhaitez adopter le cloud-controller-manager, reportez-vous à la section cloud-controller-manager dans kubernetes core.

Pour les cloud-controller-manager ne faisant pas partie de Kubernetes, vous pouvez trouver les projets respectifs dans des dépôts maintenus par des fournisseurs de cloud ou des sig leads.

Pour les fournisseurs qui se trouvent déjà dans Kubernetes, vous pouvez exécuter le cloud-controller-manager dans l’arborescence en tant que Daemonset dans votre cluster. Utilisez ce qui suit comme guide:

admin/cloud/ccm-example.yaml 
# Voici un exemple de configuration de cloud-controller-manager en tant que Daemonset dans votre cluster.
# Il suppose que vos masters peuvent executer des pods et ont le role node-role.kubernetes.io/master
# Notez que ce Daemonset ne fonctionnera pas directement pour votre cloud, c’est juste un exemple.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cloud-controller-manager
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:cloud-controller-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: cloud-controller-manager
  namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    k8s-app: cloud-controller-manager
  name: cloud-controller-manager
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: cloud-controller-manager
  template:
    metadata:
      labels:
        k8s-app: cloud-controller-manager
    spec:
      serviceAccountName: cloud-controller-manager
      containers:
      - name: cloud-controller-manager
        # pour les fournisseurs in-tree, nous utilisons k8s.gcr.io/cloud-controller-manager
        # cela peut être remplacé par n'importe quelle autre image pour les fournisseurs out-of-tree
        image: k8s.gcr.io/cloud-controller-manager:v1.8.0
        command:
        - /usr/local/bin/cloud-controller-manager
        - --cloud-provider=<YOUR_CLOUD_PROVIDER>   # Ajoutez votre propre fournisseur de cloud ici!
        - --leader-elect=true
        - --use-service-account-credentials
        # ces drapeaux varient pour chaque fournisseur de cloud
        - --allocate-node-cidrs=true
        - --configure-cloud-routes=true
        - --cluster-cidr=172.17.0.0/16
      tolerations:
      # cela est nécessaire pour que CCM puisse s'initialiser
      - key: node.cloudprovider.kubernetes.io/uninitialized
        value: "true"
        effect: NoSchedule
      # le daemonset doit pouvoir être exécuté sur les nœuds master. Le marquage peut varier en fonction de la configuration de votre cluster.
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      # ceci limite le fonctionnement du CCM sur des nœuds master
      # le sélecteur de nœud peut varier en fonction de la configuration de votre cluster
      nodeSelector:
        node-role.kubernetes.io/master: ""

Limitations

L’exécution du cloud-controller-manager est soumise à quelques limitations. Bien que ces limitations soient levées dans les prochaines versions, il est important que vous connaissiez ces limitations pour les charges de travail de production.

Prise en charge des volumes

Le cloud-controller-manager n’implémente aucun des contrôleurs de volume trouvés dans kube-controller-manager car les intégrations de volume nécessitent également une coordination avec les kubelets. Au fur et à mesure de l’évolution de CSI (interface de stockage de conteneur) et de la prise en charge renforcée des plug-ins de volume flexible, le cloud-controller-manager prendra en charge le support nécessaire afin que les clouds puissent pleinement s’intégrer aux volumes. Pour en savoir plus sur les plug-ins de volume CSI en dehors des sources de Kubernetes consultez ceci.

Charge sur les APIs cloud

Dans l’architecture précédente pour les fournisseurs de cloud, nous utilisions des kubelets utilisant un service de métadonnées local pour extraire des informations sur les nœuds. Avec cette nouvelle architecture, nous comptons désormais entièrement sur les cloud-controller-manager pour extraire les informations de tous les nœuds. Pour les très grand clusters, vous devez envisager les goulots d’étranglement tels que les besoins en ressources et la limitation de la vitesse des APIs de votre fournisseur cloud.

Problème de l’oeuf et de la poule

L’objectif du projet des cloud-controller-manager est de dissocier le développement des fonctionnalités de cloud computing du projet de base Kubernetes. Malheureusement, de nombreux aspects du projet Kubernetes supposent que les fonctionnalités de fournisseur de cloud soient étroitement intégrées au projet. Par conséquent, l’adoption de cette nouvelle architecture peut créer plusieurs situations dans lesquelles une demande d’informations auprès d’un fournisseur de cloud est demandée, mais le cloud-controller-manager peut ne pas être en mesure de renvoyer ces informations sans que la demande d’origine soit complète.

La fonctionnalité d’amorçage TLS dans Kubelet en est un bon exemple. Actuellement, l’amorçage TLS suppose que Kubelet aie la possibilité de demander au fournisseur de cloud (ou à un service de métadonnées local) tous ses types d’adresses (privé, public, etc.), mais le cloud-controller-manager ne peut pas définir les types d’adresse d’un nœud sans être initialisé dans le système. Ce qui nécessite que le kubelet possède des certificats TLS pour communiquer avec l’apiserver.

À mesure que cette initiative évoluera, des modifications seront apportées pour résoudre ces problèmes dans les prochaines versions.

Développer votre propre cloud-controller-manager

Pour créer et développer votre propre cloud-controller-manager, lisez la documentation Développer un cloud-controller-manager.

Feedback