Container Service for Kubernetes:[Discontinued] Release notes for ACK Edge of Kubernetes 1.18

Canal d'opérations cloud-edge et supervision

tunnel-server intercepte et gère désormais le trafic des opérations et de la supervision edge en se basant sur les résolutions DNS (Domain Name System) du cluster, plutôt que sur les règles iptables des nœuds individuels. Cette modification apporte trois améliorations :

• Prometheus et metrics-server n'ont plus besoin de s'exécuter sur le même nœud que tunnel-server.

• tunnel-server prend en charge le déploiement de plusieurs réplicas de pods, avec équilibrage de charge sur tous les nœuds.

• Un nouveau module meta server a été ajouté à tunnel-server pour gérer les Prometheus metrics et debug/pprof. L'endpoint de tunnel-server est http://127.0.0.1:10265 et celui de edge-tunnel-agent est http://127.0.0.1:10266. Pour modifier le port par défaut, définissez le paramètre de démarrage --meta-port sur l'un ou l'autre composant.

Autonomie des nœuds edge

edge-hub améliore la mise en cache edge, les contrôles d'intégrité, les endpoints de service et l'analyse du trafic afin de renforcer l'autonomie du trafic edge et l'accès in-cluster à kube-apiserver. Voici les modifications spécifiques :

• La topologie du trafic des services au niveau de l'edge est désormais prise en charge nativement par edge-hub, sans dépendre des feature gates de Kubernetes.

• edge-hub met automatiquement à jour l'endpoint d'un service au niveau de l'edge vers l'endpoint public de kube-apiserver du cluster, permettant aux applications edge d'accéder au cluster en mode in-cluster.

• edge-hub peut mettre en cache les CustomResourceDefinitions (CRD). Par exemple, le CRD nodenetworkconfigurations, qui stocke les informations réseau pour Flannel, peut désormais être mis en cache.

• Les contrôles d'intégrité sont améliorés : edge-hub envoie désormais des battements de cœur Lease au lieu de requêtes healthz.

• edge-hub écoute sur le port 10261 pour la transmission des requêtes et sur le port 10267 pour les requêtes locales telles que les sondes de vivacité, les métriques et pprof de yurthub.

• La métrique node_edge_hub_proxy_traffic_collector est désormais disponible. Elle affiche le trafic généré lorsque les composants de nœud tels que kubelet et kube-proxy accèdent aux ressources Kubernetes, y compris les pods et les Deployments.

Gestion basée sur les cellules au niveau de l'edge

Le contrôleur UnitedDeployment prend désormais en charge un champ Patch dans la gestion basée sur les cellules. Utilisez ce champ pour personnaliser les configurations par pool de nœuds. Par exemple, pour déployer des nœuds dans différents pools de nœuds en utilisant différents dépôts d'images locaux, spécifiez une adresse d'image distincte pour chaque pool de nœuds dans le champ Patch.

Nœuds edge

Les nœuds exécutant Ubuntu 20.04 peuvent désormais être ajoutés aux clusters Kubernetes edge.

Réseau edge

Le réseau cloud-edge Flannel est optimisé. Les opérations List et Watch s'effectuent désormais sur les CRD associés plutôt que directement sur les nœuds, ce qui réduit le trafic généré par ces opérations.

Les annotations de gestion du trafic sont également mises à jour. Pour plus de détails, consultez la section Annotations relatives à la gestion du trafic au niveau de l'edge.

Annotations relatives à la gestion du trafic au niveau de l'edge

Le tableau suivant décrit les clés d'annotation prises en charge dans Kubernetes 1.16 :

Dans Kubernetes 1.18, les values valides de openyurt.io/topologyKeys sont mises à jour. Les valeurs valides sont désormais kubernetes.io/zone et openyurt.io/nodepool. Ces deux valeurs indiquent que le service est accessible uniquement par les nœuds du même pool de nœuds. Utilisez openyurt.io/nodepool comme valeur.