Home Artigos técnicos Implementando o Edgio Delivery CDN como um provedor de entrada no cluster do Kubernetes
Applications

Implementando o Edgio Delivery CDN como um provedor de entrada no cluster do Kubernetes

About The Author

Outline

Prefácio

A seguir, um exemplo de integração do Kubernetes com o serviço Edgio Delivery CDN para profissionais experientes do Kubernetes. Ele assume um nível de conhecimento em Kubernetes e conhecimento de protocolos padrão de internet, como TCP, DNS e HTTP/HTTPS. O objetivo final é demonstrar uma maneira de fazer com que o serviço Edgio Delivery CDN apareça como entrada padrão. O usuário do Kubernetes pode manter a configuração de entrada em sistemas familiares, como Portainer ou terraform .

Kubernetes

O Kubernetes.io define o Kubernetes como “um sistema de código aberto para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos em contentor”. Existem várias maneiras de criar um cluster. A maneira mais rápida e fácil é aproveitar um dos muitos provedores de nuvem que permitem implantações de “um clique”.

Os clusters do Kubernetes contêm muitas partes. Na demonstração, vamos nos concentrar em um subconjunto do total.

Peças do Kubernetes

  • Nó: Máquina ou VM que hospeda as cargas de trabalho e serviços.
  • Carga de trabalho: Aplicação simples ou complexa
  • Pod: Recipientes nos quais o software de aplicação está a ser executado. Um ou mais pods compõem uma carga de trabalho.
  • Serviço: Um mecanismo que expõe uma carga de trabalho a outras cargas de trabalho ou cargas de trabalho
  • Ingresso: Um mecanismo para expor serviços ao mundo exterior

Edgio

O Edgio torna a vida conetada mais rápida, segura e simples de gerenciar, fornecendo velocidade, segurança e simplicidade incomparáveis na borda com nossas soluções de entrega, aplicativos e streaming perfeitamente integradas. Nossa tecnologia de escala global e serviços especializados alimentam as principais marcas do mundo com a capacidade de oferecer a educação, entretenimento, eventos e eventos mais rápidos, dinâmicos e sem atritos. aplicações para todos os utilizadores. Dedicada a fornecer atendimento inigualável ao cliente e aumentar o valor a cada passo do caminho, Edgio é um parceiro de escolha, impulsionando o tráfego mundial da Internet para apoiar os programas mais populares, filmes, esportes, jogos e música, e sites de carregamento instantâneo.

Arquitetura

Edgio Delivery CDN

Para esta demonstração, usamos o SDK do Edgio python no GitHub – llnw/llnw-SDK-python: Limelight Networks Python SDK. A configuração básica será mantida simples.

Configurando o CDN, os seguintes dados (além da autenticação) são necessários.

  • Shortname: Um identificador exclusivo dentro do Edgio Delivery CDN que contém regras CDN.
  • Nome do host publicado: O nome do host que está voltado para a Internet a partir da CDN. No caso desta demonstração, o hostname cstradtman.s.llnwi.net foi previamente configurado.
  • Caminho de URL publicado: O caminho mapeado na regra específica em questão.
  • Nome do host de origem: O nome do host da origem. Neste caso, um registro round-robin aponta para o cluster do Kubernetes.
  • Caminho do URL de origem: O caminho de destino associado ao nome do host. Neste caso, ele estará em branco, pois descrevemos mais adiante neste documento. Nesta demonstração, as cargas de trabalho serão diferenciadas por número de porta e não por caminho.

DNS

A demonstração usa a API de DNS Vultr. Configurar o CDN usando endereços IP como origens não é uma prática recomendada. A demonstração usa uma API para criar ou modificar um round-Robin Um registro apontando para os nós do cluster.

Cluster

A demonstração está no Vultr em um cluster de três nós.

Namespaces

A demonstração existirá sob o namespace padrão, uma vez que é a única coisa em execução neste cluster

Nós

  • Cluster VKE – 3 nós cada com
    • 4G ram
    • Disco de 80 g.
    • 2 vCPU
    • Rede 1 G.

Cargas de trabalho

A carga de trabalho é um programa Python simples que retorna informações básicas sobre a conexão HTTP. Nós implantamos esta demonstração em linha, que não é um método de implantação típico. No entanto, ele permite que a demonstração seja totalmente independente, em vez de ter dependências externas para construir os contentores e armazená-los. O código-fonte está no Apêndice 1. O código Python real é itálico, e o código YAML descrevendo a implantação não é. A carga de trabalho utiliza a porta TCP 8000.

Serviços

Existem vários tipos de serviço disponíveis. Estamos usando o tipo de serviço “NodePort”. Ele expõe o serviço nos endereços IP externos do cluster em um número de porta alto selecionado aleatoriamente. O Kubernetes cuida da conexão com um nó onde a carga de trabalho é executada.

Entrada

O Kubernetes Ingress é um objeto de software que descreve o comportamento de uma coleção de recursos que tornam um serviço Kubernetes disponível fora do cluster.

Um controlador de entrada combina software e/ou hardware que instancia o objeto de software de entrada.

Uma CDN é um proxy reverso distribuído rico em recursos, além da função de proxy reverso, os CDNs geralmente têm algoritmos de cache flexíveis, diversidade geográfica, recursos de segurança (ACLs (GEO, método, regex), firewalls de aplicativos da Web, watermarking, e outros recursos mais avançados não encontrados em proxies reversos simples.

As APIs para o monitoramento de objetos do Kubernetes são bem definidas, e vários proxies reversos HTTP e balanceadores de carga foram estendidos para funcionar como controladores de entrada. Por exemplo, NGINX e HAProxy são proxies da velha escola que foram estendidos para funcionar como controladores de entrada e aqueles como Traefik e Itsio foram desenvolvidos em paralelo ao Kubernetes . Uma CDN é uma próxima progressão natural de proxies reversos simples. No caso desta demonstração, criaremos um controlador de entrada personalizado que controla o Edgio Delivery CDN. Os dados normalmente necessários para descrever uma entrada são

  • Nome de host público: O nome de host no qual o serviço Kubernetes estará disponível
  • Caminho público: O caminho associado ao nome de host público no qual os serviços do Kubernetes estarão disponíveis
  • Nome do serviço de back-end: Nome do serviço definido por uma estrofe de serviços do Kubernetes
  • Porta Backend: Um nome que corresponde à descrição da porta na descrição do serviço

Mapeamentos de ativos CDN de Entrega Edgio:

Kubernetes

Edgio Delivery CDN

Nome de anfitrião público

Nome do anfitrião publicado

Caminho Público

Caminho de URL publicado

Nome do serviço de back-end

Exclusivo dentro do cluster do Kubernetes

Não conhecido/disponível para o mundo exterior

Nome do anfitrião de origem

Nome de domínio totalmente qualificado

Na verdade, não um para um

A lógica por trás disso é:

  • Ouça o evento de entrada de namespace do cluster
  • Se o tipo de evento for “adicionado”.
    • Obtenha o endereço IP dos nós no cluster
    • Criar registro DNS no vultr
    • Crie regras CDN no Edgio CDN apontando para os registros DNS criados e a porta alocada pelo serviço NodePort.
  • Se o tipo de evento for “modificado”.
    • Encontre regras de CDN no Edgio CDN que correspondem à entrada existente
    • Modifique regras no Edgio CDN para refletir novos dados no evento
  • Se o tipo de evento for “excluído”.
    • Encontre regras de CDN no Edgio CDN que correspondem à entrada removida
    • Remova os registros DNS no Vultr associados a essa entrada
    • Remova as regras CDN no Edgio que correspondem à entrada removida

Configuração

Objetos

Os objetos do Kubernetes são descritos em arquivos YAML . No Kubernetes, cada configuração é um objeto. Você pode colocar todas as configurações de implantação em um único arquivo. É prática comum dividi-los com base em qual parte da implantação eles descrevem.

Implementação

No Apêndice 1, há um grande arquivo YAML que é uma combinação de código Python e YAML. Tudo depois de “spec.template.spec.containers.command” é o código Python que é transformado em um contentor durante a implantação. Do ponto de vista do objeto Kubernetes, as linhas que são importantes para nós para a demonstração são:

  • Tipo: Implantação – descreve o objeto como uma implantação
  • Metadata.name: O nome é usado pelo objeto de serviço para criar o link entre os dois.
  • Spec.selector.matchlabels.app: informa a que pods a implantação será aplicada.
  • Spec.template.spec.containers.image: Aponta para a imagem oficial do hub docker python 3
  • Spec.template.spec.containers.ports.name: Um rótulo para a porta a ser referenciada em outros objetos de serviço neste caso
  • Spec.template.spec.containers.ports.containerport: Lista a porta TCP exposta do contentor em execução

Serviço

  • Tipo: Implantação – descreve o objeto como uma implantação
  • Metadata.name: O nome é usado pelo objeto de entrada para criar o link entre os dois.
  • Spec.selector.app: aponta para o nome da implantação – pywai-inline-service como nomeado no objeto deployment.
  • Spec.selector.type: Nodeport Isso define esse serviço como o tipo Nodeport, conforme descrito acima
  • Spec.ports.name: A etiqueta para a porta a ser referenciada por outros objetos (entrada neste caso)
  • Spec.ports.protocol: define o protocolo IP em uso – TCP
  • Spec.ports.port: Define a porta exposta por este serviço
  • Spec.ports.targetPort: Aponta para a porta exposta pela implantação – pywai-inline-deployment neste caso

Entrada

No Apêndice 3, você verá o arquivo YAML descrevendo o objeto Kubernetes para o controlador Edgio Ingress. Os objetos a serem preocupados são:

  • Tipo: Entrada – Isso diz ao Kubernetes que é um objeto de entrada
  • Medatdata.name – Tudo no Kubernetes deve ter um nome
  • Metadata.labels.cdn – Esta tag é usada para sinalizar ao controlador de entrada que esse objeto é para o controlador de entrada edgio
  • Spec.rules.host – hostname público para expor o serviço.
  • Spec.rules.http.paths.path – caminho associado ao serviço.
  • Spec.rules.http.paths.backend.service.name – Etiqueta do serviço a expor
  • Spec.rules.http.paths.backend.service.port.name – etiqueta da porta do serviço a expor

Config Mapas

Segredos

O Kubernetes tem um conceito interno de segredos para o armazenamento de dados confidenciais. Esta demonstração aproveita isso para os nomes de usuário e chaves compartilhadas para o Edgio SDK e a API de DNS Vultr

Exemplos de código

O código para esta demonstração incluído no git repos

Futuras adições e melhorias ao design atual

Em um post futuro, vamos mostrar como aproveitar outras soluções Edgio, por exemplo, aplicativos. Poderíamos usar o cluster do Kubernetes como uma forma de aproveitar e sincronizar configurações entre várias ofertas do Edgio CDN para diferentes fluxos de trabalho.

Apêndice 1 – pywai-inline-deployment.yaml

ApiVersion: Apps/v1

Tipo: Implantação

metadados:

nome: pywai-inline-deployment

especificação:

seletor:

MatchLabels:

app: pywai-inline-deployment

réplicas: 1

modelo:

metadados:

etiquetas:

app: pywai-inline-deployment

especificação:

recipientes:

– nome: python

imagem: python:3

comando:

– /bin/sh

– “-c”

– |

cat > /test.py <<EOF

#!/usr/bin/env python3

“”

Servidor HTTP muito simples em python para solicitações de log

Uso::

./server.py<[>porta ]

“”

A partir de http.server, importe BaseHTTPRequestHandler, HTTPServer

importar registo

importar pprint

Classe S (BaseHTTPRequestHandler):

def _set_response(self):

self.send_response(200)

self.send_header(‘Content-type’, ‘texto/html’)

auto.end_headers()

def do_get(self):

logging.info(“GET Request, Caminho: %S Cabeçalhos: N%s, str(self.path), str(pprint.pformat(self.headers)))

auto._set_response()

pprint.pformat(self.headers.items())

pprint.pformat(self.client_address)

pprint.pformat(auto.requestline)

pprint.pformat(self.request_version)

auto.wfile.write(“<> pre /pre <>”.format(headerinfo).encode(‘utf-8’))

auto.wfile.write(“<> pre /pre <>”.format(clientinfo).encode(‘utf-8’))

auto.wfile.write(“<> pre /pre <>”.format(lineinfo).encode(‘utf-8’))

auto.wfile.write(“<> pre /pre <>”.format(versioninfo).encode(‘utf-8’))

def run (server_class) HTTPServer, handler_class, port-8080):

Logging.basicConfig (nível de log.INFO)

endereço_do_servidor (“, porta)

servidor_class(server_address, handler_class)

logging.info(‘Starting httpd (em inglês)

tente:

httpd.serve_forever()

Exceto KeyboardInterrupt:

passe

httpd.server_close()

logging.info(‘Stopping httpd (em inglês)

se __name___:

a partir do sistema de importação argv

se len(argv): 2:

run (port) int (argv[1])

mais:

executar()

EOF

exec python /test.py 8000

portas:

– nome: http

ContainerPort: 8000

Apêndice 2 – pywai-inline-service.yaml

ApiVersion: v1

Tipo: Serviço

metadados:

nome: pywai-inline-service

especificação:

seletor:

app: pywai-inline-deployment

Tipo: NodePort

portas:

– nome: http

Protocolo: TCP

porto: 80

TargetPort: 8000

Apêndice 3 – pywai-edgio-Ingress.yaml

ApiVersion: Networking.k8s.io/v1

Tipo: Entrada

metadados:

nome: external-pywai-inline-ingress

anotações:

kubernetes.io/ingress.class: edgio

etiquetas:

cdn: edgio

especificação:

regras:

– HOST <: Insira o nome curto exclusivo>.s.llnwi.net

http:

caminhos:

– path: /fred

PathType: Exato

back-end:

serviço:

nome: external-pywai-inline-service

porta:

nome: pywai-port