For ACK Edge clusters running Kubernetes earlier than 1.26, edge-tunnel-server and edge-tunnel-agent are deployed by default to create an encrypted cloud-to-edge O&M tunnel so cloud components can reach edge nodes in private networks. This topic describes the tunnel components and how to extend edge monitoring to non-default ports. et edge-tunnel-agent créent des tunnels chiffrés pour l'accès de maintenance aux nœuds edge situés dans des réseaux privés.
Pour les clusters ACK Edge exécutant Kubernetes 1.26 ou une version ultérieure, Raven remplace les composants de tunnel. Consultez la rubrique Utilisation du composant de communication cloud-edge Raven .
Fonctionnement
edge-tunnel-server s'exécute en tant que Deployment sur les nœuds cloud. edge-tunnel-agent s'exécute en tant que DaemonSet sur chaque nœud edge.
Lors de la création du cluster, ACK provisionne une instance Server Load Balancer (SLB) devant edge-tunnel-server. Chaque edge-tunnel-agent établit une connexion sortante via l'instance SLB pour mettre en place un tunnel chiffré sur Internet.
Une fois les tunnels actifs, les requêtes envoyées par kube-apiserver ou metrics-server vers les ports 10250 ou 10255 des nœuds edge sont automatiquement transmises via edge-tunnel-server. Cela inclut les opérations de maintenance telles que kubectl logs et kubectl exec, qui ciblent kubelet sur ces ports. Aucune modification de configuration n'est nécessaire.
Si l'instance SLB est supprimée ou arrêtée, tous les tunnels cessent de fonctionner. Les tunnels peuvent également tomber en panne si la connexion d'un nœud edge au cloud est perdue ou instable.
Prérequis
Assurez-vous de disposer des éléments suivants :
Un cluster ACK Edge exécutant une version de Kubernetes antérieure à 1.26
Au moins une instance Elastic Compute Service (ECS) dans le cloud pour héberger edge-tunnel-server
Sur la version 1.16.9-aliyunedge.1, déployez metrics-server sur le même nœud ECS que edge-tunnel-server. À partir de la version 1.18.8-aliyunedge.1, ils peuvent s'exécuter sur des nœuds distincts.
Extension de la surveillance à des ports non standard
Par défaut, les tunnels transfèrent le trafic uniquement sur les ports 10250 et 10255. Pour utiliser des ports supplémentaires, configurez la ConfigMap edge-tunnel-server-cfg dans le namespace kube-system.
Les champs de configuration et les protocoles varient selon la version du cluster :
| Version du cluster | Protocoles pris en charge | Champ de configuration | Format de valeur |
|---|---|---|---|
| 1.20.11-aliyunedge.1 | HTTP | http-proxy-ports |
port1, port2 |
| 1.20.11-aliyunedge.1 | HTTPS | https-proxy-ports |
port1, port2 |
| 1.20.11-aliyunedge.1 | Endpoints localhost | localhost-proxy-ports |
port1, port2 (par défaut : 10250, 10255, 10266, 10267) |
| 1.18.8-aliyunedge.1 | HTTP uniquement | dnat-ports-pair |
port=10264 |
Configuration de ports supplémentaires sur la version 1.20.11-aliyunedge.1
Cet exemple active :
Le port 9051 via HTTP
Les ports 9052 et 8080 via HTTPS
L'accès aux endpoints localhost, y compris
https://127.0.0.1:8080
Appliquez la ConfigMap :
cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
http-proxy-ports: "9051"
https-proxy-ports: "9052, 8080"
localhost-proxy-ports: "10250, 10255, 10266, 10267, 8080"
kind: ConfigMap
metadata:
name: edge-tunnel-server-cfg
namespace: kube-system
EOFConfiguration de ports supplémentaires sur la version 1.18.8-aliyunedge.1
Sur la version 1.18.8-aliyunedge.1, seul le protocole HTTP est pris en charge pour les ports non standard. Utilisez le champ dnat-ports-pair avec le format <target-port>=10264.
Cet exemple permet l'accès cloud au port 9051 sur les nœuds edge :
Appliquez la ConfigMap :
cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
dnat-ports-pair: '9051=10264'
kind: ConfigMap
metadata:
name: edge-tunnel-server-cfg
namespace: kube-system
EOF