O Kubernetes sem dúvida se tornou a plataforma dominante para implantação de contêineres. Ele fornece a capacidade de controlar quase tudo usando suas APIs e controladores personalizados que estendem suas APIs com recursos personalizados.
No entanto, o usuário ainda deve tomar decisões detalhadas sobre exatamente como implantar, configurar, gerenciar e dimensionar aplicativos. As questões de escalonamento de aplicativos, proteção e fluxo de tráfego permanecem a critério do usuário. Isso diferencia o Kubernetes das plataformas convencionais como serviço (PaaS), como Cloud Foundry e Heroku.
As plataformas possuem uma interface de usuário simplificada e destinam-se a desenvolvedores de aplicativos que estão mais frequentemente envolvidos na configuração de aplicativos individuais. O roteamento, a implantação e as métricas são gerenciados de forma transparente para o usuário pelo sistema PaaS subjacente.
O fluxo de trabalho da origem ao envio é gerenciado pelo PaaS criando uma imagem de contêiner personalizada, implantando-a e configurando uma nova rota e um subdomínio DNS para o tráfego de entrada. Tudo isso é lançado sob comando git push
.
O Kubernetes (intencionalmente) fornece apenas os blocos de construção básicos para tais plataformas, deixando a comunidade livre para fazer o trabalho por conta própria. Como
Kubernetes é uma plataforma para construção de plataformas. A melhor posição para começar, mas não para terminar.
Como resultado, vemos vários builds de Kubernetes, bem como empresas de hospedagem que estão tentando criar PaaS para Kubernetes, como OpenShift e Rancher. Em meio ao crescente mercado de Kube-PaaS, a Knative, fundada em julho de 2018 pelo Google e pela Pivotal, está entrando no ringue.
Knative foi uma colaboração entre Google e Pivotal, com uma pequena ajuda de outras empresas como IBM, RedHat e Solo.im. Ele oferece recursos PaaS semelhantes ao Kubernetes com suporte de alto nível para aplicativos baseados em computação sem servidor. Ao contrário das compilações do Kubernetes, o Knative é instalado como um complemento em qualquer cluster Kubernetes compatível e configurado por meio de recursos do usuário.
O que é Knativo?
Knative é descrito como “Uma plataforma baseada em Kubernetes para entregar e gerenciar cargas de trabalho usando computação moderna sem servidor”. O Knative, embora se autodenomina uma plataforma desse tipo, dimensiona automaticamente os contêineres em proporção às solicitações HTTP simultâneas. Os serviços não utilizados eventualmente são reduzidos a zero, fornecendo escalonamento sob demanda no estilo serverless.
Knative consiste em um conjunto de controladores que são instalados em qualquer cluster Kubernetes e fornecem os seguintes recursos:
- construir aplicativos em contêineres a partir do código-fonte (fornecido pelo componente Construa),
- fornecendo acesso ao tráfego de entrada para aplicativos (fornecido pelo componente De servir),
- entrega e escalonamento automático de aplicativos sob demanda (também fornecido pelo componente De servir),
- identificar as fontes de eventos que levam ao lançamento de aplicativos (fornecidos pelo componente Eventing).
Um componente importante é o Serving, que fornece provisionamento, escalonamento automático e gerenciamento de tráfego para aplicativos gerenciados. Após instalar o Knative, você ainda terá acesso total à API Kubernetes, permitindo aos usuários gerenciar aplicativos o habitual forma, e também serve para depurar serviços Knative, trabalhando com as mesmas primitivas de API que esses serviços utilizam (módulos, serviços, etc.).
Com a ajuda do Serving, o roteamento de tráfego azul-verde também é automatizado, garantindo a separação do tráfego entre versões novas e antigas do aplicativo quando o usuário entrega uma versão atualizada do aplicativo.
O próprio Knative depende da instalação de um controlador de ingresso compatível. No momento em que este artigo foi escrito, este artigo era suportado
O Istio Service Mesh pode ser 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 porta de entrada para o Knative, fornecendo um conjunto de recursos semelhante ao Istio (com a finalidade de usar apenas o Knative), ao mesmo tempo que utiliza significativamente menos recursos e tem custos operacionais mais baixos.
Vamos testar o Knative em ação no estande. Usarei um cluster recém-instalado em execução no GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21h
Vamos começar a instalar o Knative e o 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
# ...
Verificamos se todos os pods estão no status “Running”:
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 44s
Gloo está pronto para roteamento, vamos criar um serviço Knative de escalonamento automático (vamos chamá-lo de kservice) e rotear o tráfego para ele.
Os serviços Knative fornecem um caminho mais fácil para entregar aplicativos ao Kubernetes do que o modelo convencional de Implantação+Serviço+Ingress. Trabalharemos com este 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 user
Copiei isso para um arquivo e apliquei-o ao meu cluster Kubernetes desta forma:
kubectl apply -f ksvc.yaml -n default
Podemos visualizar os recursos criados pelo Knative no cluster após entregar nosso ‘helloworld-go’ kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68s
O 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 vice-versa, se o número de solicitações simultâneas exceder um determinado limite configurável, o número de pods aumentará.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go True
O Knative configura sua entrada usando um recurso especial de 'entrada' na API interna do Knative. Gloo usa essa API como configuração para fornecer recursos semelhantes a PaaS, incluindo um modelo de implantação azul esverdeado, aplicação automática de TLS, tempos limite e outros recursos avançados de roteamento.
Depois de algum tempo, vemos que nossos pods desapareceram (porque 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 9m46s
Finalmente tentaremos alcançá-los. Você pode obter facilmente o URL do Knative Proxy usando glooctl
:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80
Sem instalado glooctl
você pode ver o endereço e a porta no serviço kube:
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 77m
Vamos executar alguns dados usando cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!
Knative fornece um quase PaaS para desenvolvedores além do Kubernetes pronto para uso, usando o gateway de API full-stack de alto desempenho do Gloo. Esta postagem apenas arranhou a superfície das extensas opções de personalização e recursos adicionais do Knative. O mesmo com Gloo!
Apesar de o Knative ainda ser um projeto jovem, sua equipe lança novas versões a cada seis semanas, e já foi iniciada a implementação de recursos avançados, como implantação automática de TLS, escalonamento automático do painel de controle. Há uma boa chance de que, como resultado da colaboração entre várias empresas de nuvem e como base da nova oferta Cloud Run do Google, o Knative possa se tornar a principal opção para computação sem servidor e PaaS no Kubernetes. Acompanhe as novidades!
Dos editores da SouthBridge
A opinião dos leitores é importante para nós, por isso pedimos que você participe de uma breve pesquisa relacionada a artigos futuros sobre Knative, Kubernetes, computação sem servidor:
Apenas usuários registrados podem participar da pesquisa.
Devo continuar escrevendo artigos e guias sobre computação Knative e sem servidor?
-
Sim por favor
-
Obrigado, não.
28 usuários votaram. 4 usuários se abstiveram.
Fonte: habr.com