Version imprimable multipages. Cliquer ici pour imprimer.

Retour à la version par défaut.

Administration d'un cluster

1 - Administration avec kubeadm

2 - Gestion de la mémoire du CPU et des ressources d'API

3 - Installation d'un fournisseur de politiques de réseau

4 - Déclarer une politique réseau (NetworkPolicy)

Ce document vous aide à utiliser l'API NetworkPolicy de Kubernetes pour déclarer des politiques réseau qui gouvernent la communication entre les pods.

Pré-requis

Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant Minikube, ou vous pouvez utiliser l'un de ces environnements Kubernetes:

Votre serveur Kubernetes doit être au moins à la version v1.8. Pour consulter la version, entrez kubectl version.

Assurez-vous d'avoir configuré un fournisseur de réseau qui supporte les politiques réseau. De nombreux fournisseurs de réseau prennent en charge les NetworkPolicy, notamment :

Créer un Deployment nginx et l'exposer via un Service

Pour comprendre comment fonctionne les politiques réseau dans Kubernetes, commencez par créer un déploiement nginx.

kubectl create deployment nginx --image=nginx

deployment.apps/nginx created

Exposez le déploiement via un service appelé nginx.

kubectl expose deployment nginx --port=80

service/nginx exposed

Les commandes ci-dessus créent un déploiement avec un Pod nginx et exposent le déploiement via un service nommé nginx. Le Pod et le Deployment nginx se trouvent dans le namespace default.

kubectl get svc,pod

NAME                        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service/kubernetes          10.100.0.1    <none>        443/TCP    46m
service/nginx               10.100.0.16   <none>        80/TCP     33s

NAME                        READY         STATUS        RESTARTS   AGE
pod/nginx-701339712-e0qfq   1/1           Running       0          35s

Tester le Service en y accédant depuis un autre Pod

Vous devriez pouvoir accéder au nouveau service nginx depuis d'autres pods. Pour accéder au service nginx depuis un autre pod dans le namespace default, démarrez un conteneur busybox :

kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh

Dans votre shell, exécutez la commande suivante :

wget --spider --timeout=1 nginx

Connecting to nginx (10.100.0.16:80)
remote file exists

Limiter l'accès au Service nginx

Pour limiter l'accès au service nginx afin que seuls les pods avec le label access: true puissent le consulter, créez un objet NetworkPolicy comme suit :

service/networking/nginx-policy.yaml 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"

Le nom d'un objet NetworkPolicy doit être un nom de sous-domaine DNS valide.

Affecter la politique au Service

Utilisez kubectl pour créer une NetworkPolicy à partir du fichier nginx-policy.yaml ci-dessus :

kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml

networkpolicy.networking.k8s.io/access-nginx created

Tester l'accès au Service lorsque le label d'accès n'est pas défini

Lorsque vous tentez d'accéder au service nginx depuis un pod sans les bons labels, la requête échoue :

kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh

Dans votre shell, exécutez la commande :

wget --spider --timeout=1 nginx

Connecting to nginx (10.100.0.16:80)
wget: download timed out

Définir le label d'accès et tester à nouveau

Vous pouvez créer un pod avec le bon label pour voir que la requête est autorisée :

kubectl run busybox --rm -ti --labels="access=true" --image=busybox:1.28 -- /bin/sh

Dans votre shell, exécutez la commande :

wget --spider --timeout=1 nginx

Connecting to nginx (10.100.0.16:80)
remote file exists

5 - Développer un Cloud Controller Manager

FEATURE STATE: Kubernetes v1.11 [beta]
Dans les prochaines versions, Cloud Controller Manager sera le moyen privilégié d’intégrer Kubernetes à n’importe quel cloud. Cela garantira que les fournisseurs de cloud peuvent développer leurs fonctionnalités indépendamment des cycles de publication de Kubernetes.

FEATURE STATE: Kubernetes 1.8 [alpha]

Avant d’expliquer comment créer votre propre gestionnaire de contrôleur de cloud, il est utile d’avoir quelques informations sur son fonctionnement interne. Le cloud controller manager est un code de kube-controller-manager utilisant des interfaces Go pour permettre la mise en œuvre d'implémentations depuis n'importe quel cloud. La plupart des implémentations de contrôleurs génériques seront au cœur du projet, mais elles seront toujours exécutées sur les interfaces de cloud fournies, à condition que l'interface du fournisseur de cloud soit satisfaite.

Pour approfondir un peu les détails de la mise en œuvre, tous les gestionnaires de contrôleurs de nuage vont importer des packages à partir de Kubernetes core, la seule différence étant que chaque projet enregistre son propre fournisseur de nuage en appelant cloudprovider.RegisterCloudProvider où une variable globale des fournisseurs de cloud disponibles est mise à jour.

Développement

Out of Tree

Pour construire un out-of-tree cloud-controller-manager pour votre cloud, suivez ces étapes:

  1. Créez un package Go avec une implémentation satisfaisantcloudprovider.Interface.
  2. Utilisez main.go dans cloud-controller-manager de Kubernetes core en tant que modèle pour votre main.go. Comme mentionné ci-dessus, la seule différence devrait être le package cloud qui sera importé.
  3. Importez votre paquet cloud dans main.go, assurez-vous que votre paquet a un bloc init à exécuter cloudprovider.RegisterCloudProvider.

Utiliser des exemples de fournisseurs de cloud out-of-tree peut être utile. Vous pouvez trouver la liste ici.

In Tree

Pour les cloud in-tree, vous pouvez exécuter le in-tree cloud controller manager comme un Daemonset dans votre cluster. Voir la documentation sur l'exécution d'un cloud controller manager pour plus de détails.

6 - Kubernetes cloud-controller-manager

FEATURE STATE: Kubernetes v1.30 [beta]

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 registry.k8s.io/cloud-controller-manager
        # cela peut être remplacé par n'importe quelle autre image pour les fournisseurs out-of-tree
        image: registry.k8s.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.