A plataforma dominante para a implantação de contêineres, sem dúvida, tem sido o Kubernetes. Ele oferece a capacidade de gerenciar quase tudo usando suas APIs e controladores personalizados, que expandem sua API por meio de recursos personalizados.
No entanto, o usuário ainda precisa tomar decisões detalhadas sobre como exatamente implementar, configurar, gerenciar e escalar aplicativos. As questões de escalabilidade de aplicativos, segurança e passagem de tráfego permanecem à discrição do usuário. Isso diferencia o Kubernetes das tradicionais "plataformas como serviço" (PaaS), como Cloud Foundry e Heroku.
As plataformas possuem uma interface de usuário simplificada, orientadas para desenvolvedores de aplicativos, que frequentemente lidam com a configuração de aplicativos individuais. O gerenciamento de roteamento, implantação e métricas é transparência gerido pela base do sistema PaaS.
O fluxo de trabalho "código fonte – entrega" é tratado pelo PaaS por meio da criação de uma imagem de contêiner personalizada, sua implantação, configuração de uma nova rota e subdomínio DNS para tráfego de entrada. Tudo isso é acionado por comando git push.
No Kubernetes (de forma intencional) são fornecidos apenas os blocos básicos para tais plataformas, permitindo à comunidade fazer esse trabalho por conta própria. Como :
Kubernetes é uma plataforma para construir plataformas. Um ótimo ponto de partida, mas não um final.
Como resultado, vemos uma série de distribuições do Kubernetes, além de provedores de hospedagem que tentam criar PaaS para Kubernetes, como OpenShift e Rancher. Em um mercado crescente de Kube-PaaS, surge o Knative, criado em julho de 2018 pelas empresas Google e Pivotal.
O Knative surgiu da colaboração entre Google e Pivotal, com alguma ajuda de outras empresas, como IBM, RedHat e Solo.im. Ele oferece funcionalidades semelhantes ao PaaS para Kubernetes com suporte de primeira linha a aplicativos baseados em computação sem servidor. Ao contrário das distribuições do Kubernetes, o Knative é instalado como um complemento em qualquer cluster Kubernetes compatível, sendo configurado através de recursos personalizados.
O que é Knative?
Knative é descrito como "Uma plataforma baseada em Kubernetes para implementar e gerenciar cargas de trabalho usando computação sem servidor moderna". Ao se declarar como tal, o Knative escala automaticamente contêineres proporcionalmente às solicitações HTTP simultâneas. Os serviços não utilizados, em última análise, escalam até zero, fornecendo escalabilidade sob demanda no estilo da computação sem servidor.
Knative consiste em um conjunto de controladores que podem ser instalados em qualquer cluster Kubernetes e oferecem as seguintes funcionalidades:
- compilação de aplicativos empacotados em contêineres a partir do código-fonte (fornecido pelo componente Build),
- fornecimento de acesso ao tráfego de entrada para os aplicativos (fornecido pelo componente Serving),
- fornecimento e escalabilidade automática de aplicativos sob demanda (também fornecido pelo componente Serving),
- definição de fontes de eventos que disparam a execução de aplicativos (fornecido pelo componente Eventing).
O componente principal é o Serving, que fornece entrega, escalabilidade automática e gerenciamento do tráfego para aplicativos gerenciados. Após a instalação do Knative, o acesso completo à API do Kubernetes ainda está disponível, permitindo que os usuários gerenciem aplicativos da maneira habitual, além de servir para depurar serviços Knative, trabalhando com os mesmos primitivos da API que esses serviços utilizam (módulos, serviços, etc.).
Com o Serving, também é automatizada a roteação blue-green, garantindo a divisão do tráfego entre novas e antigas versões do aplicativo ao entregar uma versão atualizada do aplicativo pelo usuário.
O Knative depende da instalação de um controlador de ingress compatível. No momento da redação deste artigo, são suportados e . Ele configurará o ingress disponível para rotear o tráfego para os aplicativos gerenciados pelo Knative.
O Istio Service Mesh pode se tornar uma grande dependência para usuários do Knative que desejam experimentá-lo sem instalar o painel de controle do Istio, já que o Knative depende apenas do gateway.
Por esse motivo, a maioria dos usuários prefere o Gloo como gateway para o Knative, que oferece um conjunto semelhante de funcionalidades ao Istio (no que diz respeito ao uso do Knative), além de utilizar significativamente menos recursos e ter menores custos operacionais.
Vamos verificar o Knative em ação em um ambiente de teste. Vou usar um cluster recém-instalado, executado no GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hVamos começar a instalação do Knative e do Gloo. Isso pode ser feito em qualquer ordem:
# ставим Knative-Serving
kubectl apply -f
https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f
https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...Verificando se todos os Pods estão com o status ‘Em Execução’:
kubectl get pod -n knative-serving
NAME READY STATUS RESTARTS AGE
activator-5dd55958cc-fkp7r 1/1 Running 0 7m32s
autoscaler-fd66459b7-7d5s2 1/1 Running 0 7m31s
autoscaler-hpa-85b5667df4-mdjch 1/1 Running 0 7m32s
controller-85c8bb7ffd-nj9cs 1/1 Running 0 7m29s
webhook-5bd79b5c8b-7czrm 1/1 Running 0 7m29s
kubectl get pod -n gloo-system
NAME READY STATUS RESTARTS AGE
discovery-69548c8475-fvh7q 1/1 Running 0 44s
gloo-5b6954d7c7-7rfk9 1/1 Running 0 45s
ingress-6c46cdf6f6-jwj7m 1/1 Running 0 44s
knative-external-proxy-7dd7665869-x9xkg 1/1 Running 0 44s
knative-internal-proxy-7775476875-9xvdg 1/1 Running 0 44sO Gloo está pronto para rotear, vamos criar um serviço Knative escalável automaticamente (vamos chamá-lo de kservice) e direcionar o tráfego a ele.
Os serviços Knative oferecem um caminho mais leve para a entrega de aplicações no Kubernetes — em comparação com o modelo tradicional de Deployment+Service+Ingress. Vamos trabalhar com o seguinte exemplo:
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
template:
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go
env:
- name: TARGET
Value: Knative userCopiei isso para um arquivo, e depois apliquei ao meu cluster Kubernetes assim:
kubectl apply -f ksvc.yaml -n defaultPodemos visualizar os recursos criados pelo Knative no cluster após a entrega do nosso ‘helloworld-go’ kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68sO Pod com nossa imagem ‘helloworld-go’ é iniciado quando o kservice é implantado. Se não houver tráfego, o número de pods será reduzido a zero. E, inversamente, se o número de requisições simultâneas ultrapassar um certo valor limite configurável, o número de pods aumentará.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative configura seu ingress utilizando um recurso especial de ‘ingress’ na API interna do Knative. O Gloo usa essa API como sua configuração para oferecer propriedades inerentes ao PaaS, incluindo o modelo de implantação blue-green, aplicação automática de TLS, timeouts e outras características avançadas de roteamento.
Após algum tempo, percebemos que nossos pods desapareceram (já que não havia tráfego de entrada):
kubectl get pod -n default
No resources found.
kubectl get deployment -n default
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
helloworld-go-fjp75-deployment 0 0 0 0 9m46sFinalmente, tentaremos alcançá-los. Obter a URL para o Knative Proxy é fácil e descomplicado usando glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Sem estar instalado glooctl pode-se espiar o endereço e a porta no kube service:
kubectl get svc -n gloo-system knative-external-proxy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
knative-external-proxy LoadBalancer 10.16.11.157 35.190.151.188 80:32168/TCP,443:30729/TCP 77mVamos rodar alguns dados usando cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!Knative oferece uma experiência quase-PaaS para desenvolvedores em cima do Kubernetes ‘de caixa’, utilizando um gateway de API Gloo altamente funcional e de alto desempenho. Esta nota apenas arranha a superfície de uma vasta gama de opções de configuração do Knative, bem como de funcionalidades adicionais. O mesmo se aplica ao Gloo!
Embora o Knative ainda seja um projeto jovem, sua equipe lança novas versões a cada seis semanas, e a implementação de recursos avançados, como a implantação automática de TLS e o escalonamento automático do painel de controle, já foi iniciada. Há uma alta probabilidade de que, como resultado da colaboração de várias empresas de nuvem, além de servir como base para a nova oferta Cloud Run da Google, o Knative possa se tornar a opção principal para a realização de computação sem servidor e PaaS no Kubernetes. Fique atento às novidades!
Da redação da SouthBridge
É importante para nós a opinião dos leitores, por isso pedimos que você participe de uma rápida pesquisa relacionada a futuros artigos sobre Knative, Kubernetes e computação sem servidor:
Apenas usuários registrados podem participar da pesquisa. , por favor.
Você gostaria de continuar traduzindo e escrevendo artigos e guias sobre Knative e computação sem servidor?
Sim, por favor.
Obrigado, não preciso.
28 usuários votaram. 4 usuários se abstiveram.
Fonte: habr.com
