Leia a estrutura e o princípio do contêiner de borda SuperEdge em um artigo

Prefácio

Superedge é uma estrutura de gerenciamento de computação de ponta nativa do Kubernetes lançada pela Tencent. Comparado com openyurt e kubeedge , o superedge não só tem os recursos de intrusão zero do Kubernetes e autonomia de borda, mas também oferece suporte a recursos avançados, como verificações de integridade distribuídas exclusivas e controle de acesso de serviço de borda, o que reduz muito o impacto da instabilidade da rede de borda da nuvem nos serviços. Também facilita muito o lançamento e governança de serviços de cluster de ponta

característica

• Kubernetes-nativo : o Superedge é expandido com base no Kubernetes nativo, adicionando certos componentes de computação de borda, que é completamente não invasivo ao Kubernetes; além disso, simplesmente implantando os componentes principais do superedge, o cluster nativo do Kubernetes pode ativar a função de computação de borda; além disso, nenhuma intrusão Possibilitar a implantação de qualquer carga de trabalho nativa do Kubernetes (implantação, statefulset, daemonset etc.) no cluster de borda
• Autonomia de borda : Superedge fornece autonomia de borda de nível L3. Quando o nó de borda está instável ou desconectado da rede em nuvem, o nó de borda ainda pode operar normalmente sem afetar os serviços de borda que foram implantados
• Verificação de integridade distribuída : o Superedge fornece recursos de verificação de integridade distribuída lateral. Cada nó de borda implantará a integridade de borda. Os nós de borda no mesmo cluster de borda realizarão verificações de saúde entre si e votarão no status dos nós. Desta forma, mesmo se houver um problema com a rede de borda da nuvem, desde que a conexão entre os nós de borda seja normal, o nó não será despejado; além disso, a verificação de integridade distribuída também suporta agrupamento, dividindo os nós do cluster em vários grupos (nós na mesma sala de computador). Os nós em cada grupo verificam-se uns aos outros. A vantagem disso é evitar a interação de dados entre os nós após o aumento do cluster, e é difícil chegar a um acordo; também se adapta aos nós de extremidade da rede A topologia é agrupada naturalmente. Todo o design evita um grande número de migrações e reconstruções de pods causadas pela instabilidade da rede do lado da nuvem e garante a estabilidade do serviço
• Controle de acesso de serviço : ServiceGroup auto-desenvolvido Superedge para implementar controle de acesso de serviço baseado em computação de ponta. Com base neste recurso, apenas dois recursos personalizados, DeploymentGrid e ServiceGrid, podem ser construídos, e um conjunto de serviços pode ser implantado em diferentes salas de computador ou regiões que compartilham o mesmo cluster convenientemente, e as solicitações entre cada serviço podem ser na sala de computador local ou no domínio local. Pode ser completado (circuito fechado), evitando o acesso inter-regional dos serviços. O uso desse recurso pode facilitar muito o lançamento e a governança de serviços de cluster de borda
• Cloud Edge Tunnel : Superedge oferece suporte a túneis auto-construídos (atualmente suporta TCP, HTTP e HTTPS) para resolver problemas de conexão cloud edge em diferentes ambientes de rede. Realize a operação e manutenção unificadas de nós de extremidade de IP sem rede pública

Estrutura geral

As funções dos componentes são resumidas da seguinte forma:

Componente nuvem

Além dos componentes principais nativos do Kubernetes (cloud-kube-apiserver, cloud-kube-controller e cloud-kube-scheduler) implantados no cluster de borda, os principais componentes de controle da nuvem incluem:

• túnel-nuvem : responsável por mantero túnel da redecom o nó de extremidade tunnel-edge , atualmente suporta protocolos TCP / HTTP / HTTPS
• controlador de grade de aplicativos : o controlador Kubernetes correspondente ao controle de acesso de serviço ServiceGroup é responsável por gerenciar CRDs de DeploymentGrids e ServiceGrids, e a implantação e serviço Kubernetes correspondentes são gerados por esses dois CRs. Ao mesmo tempo, a realização autodesenvolvida de reconhecimento de topologia de serviço permite o acesso de serviço de loop fechado
• edge-admission : Determine se o nó está íntegro por meio do relatório de status da verificação de integridade distribuída do nó de extremidade e ajude o cloud-kube-controller a executar ações de processamento relacionadas (contaminação)

Componente de borda

Além do kubelet e do kube-proxy que precisam ser implantados no nó de trabalho nativo do Kubernetes, o lado da borda também adiciona os seguintes componentes de computação de borda:

• lite-apiserver : o principal componente da autonomia de borda é o serviço de proxy de cloud-kube-apiserver, que armazena em cache certas solicitações de componentes de nó de borda para apiserver. Quando essas solicitações forem encontradas e houver problemas com a rede cloud-kube-apiserver, Devolva diretamente ao cliente
• edge-health : serviço de verificação de integridade distribuída de ponta-ponta, responsável por realizar operações específicas de monitoramento e detecção e votação para determinar se o nó está íntegro
• Tunnel-edge : Responsável por estabelecerum túnel de redecom o cluster de borda da nuvem tunnel-cloud , aceitando solicitações de API e encaminhando-as para o componente de nó de borda (kubelet)
• Wrapper de grade de aplicativo : combinado com o controlador de grade de aplicativo para completar o acesso de serviço de loop fechado em ServiceGrid (reconhecimento de topologia de serviço)

Visão Geral Funcional

Implantação de aplicativos e controle de acesso a serviços

O Superedge pode dar suporte à implantação de aplicativos de todas as cargas de trabalho de Kubernetes nativos, incluindo:

• desdobramento, desenvolvimento
• statefulset
• daemonset
• trabalho
• trabalho cron

Para aplicativos de computação de ponta, tem os seguintes pontos exclusivos:

• Em cenários de computação de ponta, vários sites de ponta são frequentemente gerenciados no mesmo cluster, e cada site de ponta tem um ou mais nós de computação
• Ao mesmo tempo, espero executar um conjunto de serviços com lógica de negócios em cada site. Os serviços em cada site são um conjunto completo de funções que podem fornecer serviços aos usuários
• Devido a restrições de rede, o acesso entre sites entre serviços que têm conexões comerciais é indesejável ou impossível

A fim de resolver os problemas acima, a superedge construiu de forma inovadora o conceito de ServiceGroup, que é conveniente para os usuários implantarem convenientemente um conjunto de serviços em diferentes salas de computador ou áreas que compartilham o mesmo cluster e fazer as solicitações entre cada serviço na sala de computador local ou domínio local. Pode ser concluído (circuito fechado), evitando o acesso ao serviço interregional

Vários conceitos-chave estão envolvidos no ServiceGroup:

NodeUnit

• NodeUnit é geralmente uma ou mais instâncias de recursos de computação localizadas no mesmo site de presença, e é necessário garantir que a intranet dos nós no mesmo NodeUnit esteja conectada
• Os serviços no grupo ServiceGroup são executados em um NodeUnit
• ServiceGroup permite que os usuários definam o número de pods (pertence à implantação) que o serviço executa em um NodeUnit
• ServiceGroup pode restringir chamadas entre serviços para este NodeUnit

NodeGroup

• NodeGroup contém um ou mais NodeUnit
• Certifique-se de que os serviços no ServiceGroup sejam implantados em cada NodeUnit na coleção
• Quando um NodeUnit é adicionado ao cluster, os serviços no ServiceGroup serão implantados automaticamente no novo NodeUnit

ServiceGroup

• ServiceGroup contém um ou mais serviços comerciais
• Cena aplicável:
  • Os negócios precisam ser empacotados e implantados;
  • Precisa ser executado em cada NodeUnit e garantir o número de pods
  • As chamadas entre os serviços precisam ser controladas no mesmo NodeUnit, e o tráfego não pode ser encaminhado para outros NodeUnits
• Nota: ServiceGroup é um conceito de recurso abstrato, vários ServiceGroups podem ser criados em um cluster

Aqui está um exemplo específico para ilustrar a função ServiceGroup:

# step1: labels edge nodes
$ kubectl  get nodes
NAME    STATUS   ROLES    AGE   VERSION
node0   Ready    <none>   16d   v1.16.7
node1   Ready    <none>   16d   v1.16.7
node2   Ready    <none>   16d   v1.16.7
# nodeunit1(nodegroup and servicegroup zone1)
$ kubectl --kubeconfig config label nodes node0 zone1=nodeunit1  
# nodeunit2(nodegroup and servicegroup zone1)
$ kubectl --kubeconfig config label nodes node1 zone1=nodeunit2
$ kubectl --kubeconfig config label nodes node2 zone1=nodeunit2

# step2: deploy echo DeploymentGrid
$ cat <<EOF | kubectl --kubeconfig config apply -f -
apiVersion: superedge.io/v1
kind: DeploymentGrid
metadata:
  name: deploymentgrid-demo
  namespace: default
spec:
  gridUniqKey: zone1
  template:
    replicas: 2
    selector:
      matchLabels:
        appGrid: echo
    strategy: {}
    template:
      metadata:
        creationTimestamp: null
        labels:
          appGrid: echo
      spec:
        containers:
        - image: gcr.io/kubernetes-e2e-test-images/echoserver:2.2
          name: echo
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          resources: {}
EOF
deploymentgrid.superedge.io/deploymentgrid-demo created
# note that there are two deployments generated and deployed into both nodeunit1 and nodeunit2
$ kubectl  get deploy
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deploymentgrid-demo-nodeunit1   2/2     2            2           5m50s
deploymentgrid-demo-nodeunit2   2/2     2            2           5m50s
$ kubectl  get pods -o wide
NAME                                             READY   STATUS    RESTARTS   AGE     IP            NODE    NOMINATED NODE   READINESS GATES
deploymentgrid-demo-nodeunit1-65bbb7c6bb-6lcmt   1/1     Running   0          5m34s   172.16.0.16   node0   <none>           <none>
deploymentgrid-demo-nodeunit1-65bbb7c6bb-hvmlg   1/1     Running   0          6m10s   172.16.0.15   node0   <none>           <none>
deploymentgrid-demo-nodeunit2-56dd647d7-fh2bm    1/1     Running   0          5m34s   172.16.1.12   node1   <none>           <none>
deploymentgrid-demo-nodeunit2-56dd647d7-gb2j8    1/1     Running   0          6m10s   172.16.2.9    node2   <none>           <none>

# step3: deploy echo ServiceGrid
$ cat <<EOF | kubectl --kubeconfig config apply -f -
apiVersion: superedge.io/v1
kind: ServiceGrid
metadata:
  name: servicegrid-demo
  namespace: default
spec:
  gridUniqKey: zone1
  template:
    selector:
      appGrid: echo
    ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
EOF
servicegrid.superedge.io/servicegrid-demo created
# note that there is only one relevant service generated
$ kubectl  get svc
NAME                   TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
kubernetes             ClusterIP   192.168.0.1       <none>        443/TCP   16d
servicegrid-demo-svc   ClusterIP   192.168.6.139     <none>        80/TCP    10m

# step4: access servicegrid-demo-svc(service topology and closed-looped)
# execute on onde0
$ curl 192.168.6.139|grep "node name"
        node name:      node0
# execute on node1 and node2
$ curl 192.168.6.139|grep "node name"
        node name:      node2
$ curl 192.168.6.139|grep "node name"
        node name:      node1

O exemplo acima resume o ServiceGroup da seguinte maneira:

• NodeUnit, NodeGroup e ServiceGroup são todos um conceito. Especificamente, a relação correspondente em uso real é a seguinte:
  • NodeUnit é um grupo de nós de extremidade com a mesma chave e valor de rótulo
  • NodeGroup é um grupo de NodeUnits (valores diferentes) com a mesma chave de rótulo
  • ServiceGroup é especificamente composto por dois CRDs: DepolymentGrid e ServiceGrid, com a mesma gridUniqKey
  • O valor gridUniqKey corresponde à chave do rótulo do NodeGroup, ou seja, o ServiceGroup corresponde ao NodeGroup um-para-um, e o NodeGroup corresponde a vários NodeUnits. Ao mesmo tempo, cada NodeUnit no NodeGroup implantará a implantação correspondente do ServiceGroup. Essas implantações (denominado de deploymentgridName-Node). Harmony corrige em um NodeUnit e restringe o acesso dentro do NodeUnit por meio do reconhecimento de topologia de serviço

Verificação de saúde distribuída

No cenário de computação de borda, o ambiente de rede entre o nó de borda e a nuvem é muito complexo e a conexão não é confiável. No cluster nativo do Kubernetes, a conexão entre o apiserver e o nó será interrompida, o status do nó será anormal e o pod será expulso e o endpoint estará ausente. Causa interrupção e flutuação do serviço, especificamente o processamento nativo do Kubernetes é o seguinte:

• O nó desconectado é definido para o estado ConditionUnknown, e manchas NoSchedule e NoExecute são adicionadas
• O pod no nó perdido é expulso e reconstruído em outros nós
• O pod no nó perdido é removido da lista de endpoints do serviço

Portanto, o cenário de computação de borda depende apenas da conexão entre a borda e o apiserver não é suficiente para determinar se o nó é anormal, e isso causará erro de julgamento devido à falta de confiabilidade da rede e afetará os serviços normais. Em comparação com a conexão entre a nuvem e a borda, é óbvio que a conexão entre os nós da borda é mais estável e tem um certo valor de referência, portanto, a superedge propõe um mecanismo de verificação de integridade distribuída pela borda. Além dos fatores de apiserver, o julgamento de status do nó neste mecanismo também introduz fatores de avaliação de nó para fazer um julgamento de status mais abrangente do nó. Por meio dessa função, um grande número de migrações e reconstruções de pods causadas pela rede não confiável do lado da nuvem pode ser evitado e a estabilidade do serviço pode ser garantida

Especificamente, a precisão do julgamento do status do nó é aprimorada principalmente por meio dos três níveis a seguir:

• Cada nó detecta periodicamente o status de saúde de outros nós
• Todos os nós do cluster votam regularmente para determinar o status de cada nó
• A nuvem e o nó de extremidade determinam conjuntamente o estado do nó

O processamento do julgamento final da verificação de saúde distribuída é o seguinte:

O estado final do nó	Nuvem considerada normal	Julgamento de nuvem anormal
O julgamento interno do nó é normal	normal	Chega de programar novos pods para este nó (mancha NoSchedule)
Julgamento interno do nó anormal	normal	Expulsar o pod de estoque; remover o pod da lista de endpoints; não programar mais novos pods para o nó

Autonomia marginal

Para usuários de computação de ponta, além de desfrutar da conveniência de gerenciamento, operação e manutenção oferecida pelo próprio Kubernetes, eles também desejam ter tolerância a desastres em um ambiente de rede fraco. Especificamente, são os seguintes:

• Mesmo se o nó perder a conexão com o mestre, o negócio no nó pode continuar a funcionar
• Certifique-se de que se o contêiner de negócios sair de forma anormal ou travar, o kubelet pode continuar a puxar
• Além disso, certifique-se de que, após a reinicialização do nó , o negócio possa continuar a ser retomado
• Os usuários implantados na planta é um micro-serviços , precisa garantir que o nó após o reinício, com um serviço de micro-planta pode acessar

Para o Kubernetes padrão, se o nó for desconectado da rede e reiniciar de forma anormal, os sintomas são os seguintes:

• O estado do nó perdido é definido como o estado ConditionUnknown
• Depois que o processo de negócios no nó perdido sai de forma anormal, o contêiner pode ser puxado
• O Pod IP no nó perdido é removido da lista de endpoints
• Depois que o nó ausente for reiniciado, todos os contêineres desaparecerão sem serem puxados

A autonomia de borda auto-desenvolvida do superedge é para resolver os problemas acima. Especificamente, a autonomia de borda pode alcançar os seguintes efeitos:

• O nó será colocado no estado ConditionUnknown, mas o serviço ainda estará disponível (o pod não será despejado e removido da lista de endpoints)
• No caso de desconexão de rede de vários nós, o negócio do Pod funciona normalmente e os recursos de microsserviço são fornecidos normalmente
• Depois que vários nós forem desconectados da rede e reiniciados, o pod será ativado novamente e executado normalmente
• Depois que vários nós são desconectados da rede e reiniciados, todos os microsserviços podem ser acessados ​​normalmente

Entre eles, os dois primeiros pontos podem ser alcançados por meio do mecanismo de verificação de integridade distribuída apresentado acima, e os dois pontos a seguir podem ser alcançados por meio de soluções lite-apiserver, instantâneo de rede e DNS, como segue:

mecanismo lite-apiserver

Superedge adiciona uma camada de espelhamento do componente lite-apiserver na borda, de modo que todas as solicitações dos nós da borda para nuvem kube-apiserver apontarão para o componente lite-apiserver:

O lite-apiserver é, na verdade, um proxy, que armazena em cache algumas solicitações do kube-apiserver e retorna diretamente ao cliente quando essas solicitações são encontradas e não podem se comunicar com o apiserver:

Em geral: para componentes de nós de borda, a função fornecida por lite-apiserver é kube-apiserver, mas por um lado lite-apiserver só é eficaz para este nó e, por outro lado, ocupa muito poucos recursos. Quando a rede está desobstruída, o componente lite-apiserver é transparente para o componente do nó; e quando a rede está anormal, o componente lite-apiserver retornará os dados exigidos pelo nó para o componente no nó para garantir que o componente do nó não seja afetado pela rede. Impacto de condições anormais

Instantâneo da rede

Por meio do lite-apiserver, o pod pode ser retirado normalmente após a reinicialização quando o nó de extremidade é desconectado da rede, mas de acordo com o princípio do Kubernetes nativo, o ip do pod após ser retirado mudará, o que não é permitido em alguns casos. Por este motivo Superedge projetou um mecanismo de instantâneo de rede para garantir que o nó de borda seja reiniciado e o IP seja mantido inalterado após o pod ser puxado. Especificamente, ele tira instantâneos periódicos das informações de rede dos componentes no nó e as restaura depois que o nó é reiniciado

Solução DNS local

Por meio do lite-apiserver e do mecanismo de instantâneo da rede, pode-se garantir que, depois que o nó de extremidade for reiniciado quando a rede for desconectada, o Pod será ativado e executado normalmente, e os microsserviços também estarão funcionando normalmente. O acesso mútuo entre serviços envolve um problema de resolução de nome de domínio: de modo geral, usamos coredns para fazer a resolução de nome de domínio dentro do cluster, e geralmente é implantado na forma de implantação, mas no caso da computação de borda, os nós podem não ser os mesmos É provável que a rede local cruze a zona de disponibilidade. No momento, o serviço coredns pode não estar acessível. A fim de garantir que o acesso dns seja sempre normal, a superedge projetou uma solução dns local especial, como segue:

O dns local usa DaemonSet para implantar coredns para garantir que cada nó tenha coredns disponíveis. Ao mesmo tempo, modifique os parâmetros de inicialização do kubelet em cada nó --cluster-dnspara apontá-lo para o IP privado local (o mesmo para cada nó). Isso garante que a resolução do nome de domínio possa ser executada mesmo quando a rede estiver desconectada.

Em geral, o superedge é baseado no mecanismo lite-apiserver, combinado com um mecanismo de verificação de integridade distribuída, instantâneos de rede e coredns locais para garantir a confiabilidade da rede do cluster de contêiner de borda em um ambiente de rede fraco. Além disso, quanto maior o nível de autonomia da borda, mais e mais componentes serão necessários

Túnel do lado da nuvem

Por fim, apresentarei o túnel de borda da nuvem de superedge. O túnel de borda da nuvem é usado principalmente para: enviar como proxy a solicitação da nuvem para acessar os componentes do nó de borda e resolver o problema de que a nuvem não pode acessar diretamente o nó de borda (o nó de borda não está exposto à rede pública)

O diagrama da arquitetura é o seguinte:

O princípio de realização é:

• A extremidade do túnel no nó de extremidade se conecta ativamente ao serviço de nuvem de túnel e o serviço de nuvem de túnel transfere a solicitação para o pod específico da nuvem de túnel de acordo com a política de balanceamento de carga
• Depois que a borda do túnel e a nuvem do túnel estabelecem uma conexão grpc, a nuvem do túnel escreverá o mapeamento de seu podIp e nodeName do nó onde a borda do túnel está localizada no DNS (DNS do túnel). Depois que a conexão grpc for desconectada, a nuvem de túnel excluirá o mapeamento entre o podIp relevante e o nome do nó

O processo de encaminhamento de proxy de toda a solicitação é o seguinte:

• Quando apiserver ou outros aplicativos em nuvem acessam kubelet ou outros aplicativos em nós de extremidade, o tunnel-dns encaminha a solicitação para o pod de túnel-nuvem por meio de sequestro de DNS (resolvendo o nome do nó no host para podIp de túnel-nuvem)
• tunnel-cloud encaminha as informações do pedido para a conexão grpc estabelecida com a borda do túnel correspondente ao nome do nó de acordo com o nome do nó
• A borda do túnel solicita o aplicativo no nó de borda de acordo com as informações de solicitação recebidas

Resumindo

Este artigo, por sua vez, apresenta os recursos, a arquitetura geral, as principais funções e os princípios da estrutura de computação de ponta de software livre SuperEdge. Entre eles, a verificação de integridade distribuída e o controle de acesso ao serviço de cluster de borda ServiceGroup são recursos exclusivos do SuperEdge. A verificação de integridade distribuída evita amplamente a migração e reconstrução de um grande número de pods causados ​​pela rede não confiável do lado da nuvem e garante a estabilidade do serviço; enquanto o ServiceGroup facilita muito os usuários em diferentes salas de computador ou regiões que pertencem ao mesmo cluster. Implantar um conjunto de serviços, e fazer com que as solicitações entre cada serviço sejam concluídas na sala de informática local ou no domínio local (circuito fechado), evitando o acesso inter-regional de serviços. Além disso, existem funções como autonomia de borda e túneis do lado da nuvem.

Em geral, o SuperEdge adota uma maneira não intrusiva de criar clusters de borda. Com base nos componentes originais do Kubernetes permanecem inalterados, alguns novos componentes são adicionados para completar as funções de computação de borda. Ele não apenas mantém o poderoso sistema de orquestração do Kubernetes, mas também tem uma vantagem completa. Calcule a habilidade.