Em clusters ACK Edge com Kubernetes anterior à versão 1,26, o edge-tunnel-server e o edge-tunnel-agent são implantados por padrão para crie um túnel criptografado de O&M entre a nuvem e a borda, permitindo que componentes na nuvem acessem nós de borda em redes privadas. Este tópico descreve os componentes do túnel e como estender o monitoramento de borda para portas não padrão. e o edge-tunnel-agent criam túneis criptografados para acesso de O&M a nós de borda em redes privadas.
Para clusters ACK Edge com Kubernetes 1,26 ou superior, o Raven substitui os componentes de túnel. Consulte Trabalhar com o componente de comunicação nuvem-borda Raven .
Como funciona
O edge-tunnel-server é executado como um Deployment nos nós da nuvem. O edge-tunnel-agent é executado como um DaemonSet em cada nó de borda.
Durante a criação do cluster, o ACK provisiona uma instância de Server Load Balancer (SLB) à frente do edge-tunnel-server. Cada edge-tunnel-agent se conecta externamente por meio da instância SLB para estabelecer um túnel criptografado pela Internet.
Após o estabelecimento dos túneis, o edge-tunnel-server encaminha automaticamente as requisições do kube-apiserver ou metrics-server para as portas 10250 ou 10255 nos nós de borda. Isso inclui operações de O&M, como kubectl logs e kubectl exec, direcionadas ao kubelet nessas portas. Nenhuma alteração de configuração é necessária.
Se a instância SLB for excluída ou interrompida, todos os túneis deixarão de funcionar. Os túneis também podem falhar caso a conexão de um nó de borda com a nuvem seja perdida ou esteja instável.
Pré-requisitos
Certifique-se de ter:
Um cluster ACK Edge execute Kubernetes anterior à versão 1,26
Pelo menos uma instância Elastic Compute Service (ECS) na nuvem para hospedar o edge-tunnel-server
Na versão 1.16.9-aliyunedge.1, implante o metrics-server no mesmo nó ECS que o edge-tunnel-server. Na versão 1.18.8-aliyunedge.1 ou superior, eles podem ser executados em nós separados.
Estender o monitoramento para portas não padrão
Por padrão, os túneis encaminham tráfego apenas nas portas 10250 e 10255. Para usar portas adicionais, configure o ConfigMap edge-tunnel-server-cfg no namespace kube-system.
Os campos de configuração e protocolos variam conforme a versão do cluster:
|
Versão do cluster |
Protocolos suportados |
Campo de configuração |
Formato do valor |
|
1.20.11-aliyunedge.1 |
HTTP |
|
|
|
1.20.11-aliyunedge.1 |
HTTPS |
|
|
|
1.20.11-aliyunedge.1 |
Endpoints localhost |
|
|
|
1.18.8-aliyunedge.1 |
Apenas HTTP |
|
|
Configure portas adicionais na versão 1.20.11-aliyunedge.1
Este exemplo habilita:
Porta 9051 via HTTP
Portas 9052 e 8080 via HTTPS
Acesso a endpoints localhost, incluindo
https://127.0.0.1:8080
Aplique o 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
EOFConfigure portas adicionais na versão 1.18.8-aliyunedge.1
Na versão 1.18.8-aliyunedge.1, apenas HTTP é suportado para portas não padrão. Utilize o campo dnat-ports-pair com o formato <target-port>=10264.
Este exemplo habilita o acesso da nuvem à porta 9051 nos nós de borda:
Aplique o 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