One place for hosting & domains

      Kubernetes

      Getting Started with Containers and Kubernetes: A DigitalOcean Meetup Kit


      Getting Started with Containers and Kubernetes Meetup Kit Materials

      This meetup kit is designed to help a technical audience become familiar with core Kubernetes concepts and practices.

      The aim is to provide a complete set of resources for a speaker to host an event and deliver an introductory talk on containers and Kubernetes. It includes:

      This tutorial is intended to supplement the talk demo with additional detail and elucidation. It also serves as a reference for readers seeking to get a minimal containerized Flask app up and running on DigitalOcean Kubernetes.

      Introduction

      In the past decade, containerized applications and container clusters have rapidly replaced the old paradigm of scaling applications using virtual machines. Containers offer the same process isolation, but are generally more lightweight, portable, and performant than full virtualization. Container clusters, which can be used to manage thousands of running containers across a set of physical machines, abstract away much of the work of rolling out new versions of applications, scaling them, and efficiently scheduling workloads. Out of these, Kubernetes has emerged as a mature, production-ready system. It provides a rich set of features like rolling deployments, health checking, self-monitoring, workload autoscaling, and much, much more.

      This tutorial, designed to accompany the Slides and speaker notes for the Getting Started with Kubernetes Meetup Kit, will show you how to harness these technologies and deploy the “Hello World” Flask app onto a DigitalOcean Kubernetes cluster.

      Prerequisites

      To follow this tutorial, you will need:

      • A Kubernetes 1.10+ cluster with role-based access control (RBAC) enabled. This setup will use a DigitalOcean Kubernetes cluster
      • The kubectl command-line tool installed on your local machine or development server and configured to connect to your cluster. You can read more about installing kubectl in the official documentation.
      • Docker installed on your local machine or development server. If you are working with Ubuntu 18.04, follow Steps 1 and 2 of How To Install and Use Docker on Ubuntu 18.04; otherwise, follow the official documentation for information about installing on other operating systems. Be sure to add your non-root user to the docker group, as described in Step 2 of the linked tutorial.
      • A Docker Hub account (optional). For an overview of how to set this up, refer to this introduction to Docker Hub. You’ll only need a Docker Hub account if you plan on modifying the Flask Docker image described in this tutorial.

      Step 1 — Cloning the App Repository and Building the Flask Image

      To begin, clone the demo Flask app repo onto your machine, navigate into the directory, and list the directory contents:

      • git clone https://github.com/do-community/k8s-intro-meetup-kit.git
      • cd k8s-intro-meetup-kit
      • ls

      Output

      LICENSE README.md app k8s

      The app directory contains the Flask demo app code, as well as the Dockerfile for building its container image. The k8s directory contains Kubernetes manifest files for a Pod, Deployment, and Service. To learn more about these Kubernetes objects, consult the slide deck or An Introduction to Kubernetes.

      Navigate into the app directory and print out the contents of the app.py file:

      Output

      from flask import Flask app = Flask(__name__) @app.route('/') def hello_world(): return 'Hello, World!' if __name__ == "__main__": app.run(debug=True, host='0.0.0.0')

      This code defines a single default route that will print “Hello World.” Additionally, the apps runs in debug mode to enable verbose output.

      In a similar fashion, cat out the contents of the app’s Dockerfile:

      Output

      FROM python:3-alpine WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . EXPOSE 5000 CMD ["python", "app.py"]

      This Dockerfile first sources a lightweight Alpine Linux Python parent image. It then copies in the Python requirements file, installs Flask, copies the app code into the container image, defines port 5000 as the container port, and finally sets the default command to python app.py.

      Next, build the app image:

      • cd app
      • docker build -t flask_demo:v0 .

      We give the image a name, flask_demo, and tag, v0 using the -t option.

      After Docker finishes the build, run the container using run:

      • docker run -p 5000:5000 flask:v0

      This command runs a container using the flask:v0 image, and forwards local port 5000 to container port 5000.

      If you’re running Docker on your local machine, navigate to http://localhost:5000 in your web browser. You should see “Hello World,” generated by the dockerized Flask app.

      If you’re running Docker on a dev server, navigate instead to http://dev_server_external_IP:5000. If you’re running a firewall like UFW, be sure to allow external access on port 5000. To learn more about doing this with UFW, consult UFW Essentials: Common Firewall Rules and Commands.

      At this point you can experiment with Docker commands like docker ps, docker top, and docker images to practice working with images and containers on your system.

      In the next step, we’ll deploy this demo app to your Kubernetes cluster. We’ll use a prebuilt image shared publicly on Docker Hub. If you’d like to customize the Flask app and use your own image, you should create a Docker Hub account and follow the steps in this introduction to push your image to a public repository. From there, Kubernetes will be able to pull and deploy the container image into your cluster.

      Step 2 — Deploying the Flask App on Kubernetes

      The app and Docker image described in the previous step have already been built and made publicly available in the flask-helloworld Docker Hub repository. You can optionally create your own repository for the app and substitute it for flask-helloworld throughout this step.

      We’ll first deploy this demo “Hello World” app into our cluster as a standalone Pod, then as a multi-pod Deployment, which we’ll finally expose as a LoadBalancer Service. At the end of this tutorial, the “Hello World” app will be publicly accessible from outside of the Kubernetes cluster.

      Before we launch any workloads into the cluster, we’ll create a Namespace in which the objects will run. Namespaces allow you to segment your cluster and limit scope for running workloads.

      Create a Namespace called flask:

      • kubectl create namespace flask

      Now, list all the Namespaces in your cluster:

      You should see your new Namespace as well as some default Namespaces like kube-system and default. In this tutorial, we are going to exclusively work within the flask Namespace.

      Navigate back out to the k8s directory in the demo repo:

      In this directory, you’ll see three Kubernetes manifest files:

      • flask-pod.yaml: The app Pod manifest
      • flask-deployment.yaml: The app Deployment manifest
      • flask-service.yaml: The app LoadBalancer Service manifest

      Let’s take a look at the Pod manifest:

      Output

      apiVersion: v1 kind: Pod metadata: name: flask-pod labels: app: flask-helloworld spec: containers: - name: flask image: hjdo/flask-helloworld:latest ports: - containerPort: 5000

      Here, we define a minimal Pod called flask-pod and label it with the app: flask-helloworld key-value pair.

      We then name the single container flask and set the image to flask-helloworld:latest from the hjdo/flask-helloworld Docker Hub repository. If you’re using an image stored in a different Docker Hub repo, you can reference it using the image field here. Finally, we open up port 5000 to accept incoming connections.

      Deploy this Pod into the flask Namespace using kubectl apply -f and the -n Namespace flag:

      • kubectl apply -f flask-pod.yaml -n flask

      After ten or so seconds, the Pod should be up and running in your cluster:

      Output

      NAME READY STATUS RESTARTS AGE flask-pod 1/1 Running 0 4s

      Since this Pod is running inside of the Kubernetes cluster, we need to forward a local port to the Pod’s containerPort to access the running app locally:

      • kubectl port-forward pods/flask-pod -n flask 5000:5000

      Here we use port-forward to forward local port 5000 to the Pod’s containerPort 5000.

      Navigate to http://localhost:5000, where you should once again see the “Hello World” text generated by the Flask app. If you’re running kubectl on a remote dev server, replace localhost with your dev server’s external IP address.

      Feel free to play around with kubectl commands like kubectl describe to explore the Pod resource. When you’re done, delete the Pod using delete:

      • kubectl delete pod flask-pod -n flask

      Next, we’ll roll out this Pod in a scalable fashion using the Deployment resource. Print out the contents of the flask-deployment.yaml manifest file:

      • cat flask-deployment.yaml

      Output

      apiVersion: apps/v1 kind: Deployment metadata: name: flask-dep labels: app: flask-helloworld spec: replicas: 2 selector: matchLabels: app: flask-helloworld template: metadata: labels: app: flask-helloworld spec: containers: - name: flask image: hjdo/flask-helloworld:latest ports: - containerPort: 5000

      Here, we define a Deployment called flask-dep with an app: flask-helloworld Label. Next, we request 2 replicas of a Pod template identical to the template we previously used to deploy the Flask app Pod. The selector field matches the app: flask-helloworld Pod template to the Deployment.

      Roll out the Deployment using kubectl apply -f:

      • kubectl apply -f flask-deployment.yaml -n flask

      After a brief moment, the Deployment should be up and running in your cluster:

      • kubectl get deploy -n flask

      Output

      NAME READY UP-TO-DATE AVAILABLE AGE flask-dep 2/2 2 2 5s

      You can also pull up the individual Pods that are managed by the Deployment controller:

      Output

      NAME READY STATUS RESTARTS AGE flask-dep-876bd7677-bl4lg 1/1 Running 0 76s flask-dep-876bd7677-jbfpb 1/1 Running 0 76s

      To access the app, we have to forward a port inside of the cluster:

      • kubectl port-forward deployment/flask-dep -n flask 5000:5000

      This will forward local port 5000 to containerPort 5000 on one of the running Pods.

      You should be able to access the app at http://localhost:5000. If you’re running kubectl on a remote dev server, replace localhost with your dev server’s external IP address.

      At this point you can play around with commands like kubectl rollout and kubectl scale to experiment with rolling back Deployments and scaling them. To learn more about these and other kubectl commands, consult a kubectl Cheat Sheet.

      In the final step, we’ll expose this app to outside users using the LoadBalancer Service type, which will automatically provision a DigitalOcean cloud Load Balancer for the Flask app Service.

      Step 3 — Creating the App Service

      A Kubernetes Deployment allows the operator to flexibly scale a Pod template up or down, as well as manage rollouts and template updates. To create a stable network endpoint for this set of running Pod replicas, you can create a Kubernetes Service, which we’ll do here.

      Begin by inspecting the Service manifest file:

      Output

      apiVersion: v1 kind: Service metadata: name: flask-svc labels: app: flask-helloworld spec: type: LoadBalancer ports: - port: 80 targetPort: 5000 protocol: TCP selector: app: flask-helloworld

      This manifest defines a Service called flask-svc. We set the type to LoadBalancer to provision a DigitalOcean cloud Load Balancer that will route traffic to the Deployment Pods. To select the already running Deployment, the selector field is set to the Deployment’s app: flask-helloworld Label. Finally, we open up port 80 on the Load Balancer and instruct it to route traffic to the Pods’ containerPort 5000.

      To create the Service, use kubectl apply -f:

      • kubectl apply -f flask-service.yaml -n flask

      It may take a bit of time for Kubernetes to provision the cloud Load Balancer. You can track progress using the -w watch flag:

      Once you see an external IP for the flask-svc Service, navigate to it using your web browser. You should see the “Hello World” Flask app page.

      Conclusion

      This brief tutorial demonstrates how to containerize a minimal Flask app and deploy it to a Kubernetes cluster. It accompanies the meetup kit’s slides and speaker notes and GitHub repository.



      Source link

      Como Escalar Automaticamente suas Cargas de Trabalho no Kubernetes da DigitalOcean


      Introdução

      Ao trabalhar com uma aplicação criada no Kubernetes, os desenvolvedores frequentemente precisam provisionar pods adicionais para lidar com períodos de pico de tráfego ou aumento da carga de processamento. Por padrão, provisionar esses pods adicionais é uma etapa manual; o desenvolvedor deve alterar o número de réplicas desejadas no objeto do deployment para contar com o aumento do tráfego e alterá-lo novamente quando os pods adicionais não forem mais necessários. Essa dependência da intervenção manual pode não ser o ideal em muitos cenários. Por exemplo, sua carga de trabalho pode atingir o horário de pico no meio da noite, quando ninguém está acordado para escalar os pods, ou seu site pode receber um aumento inesperado no tráfego quando uma resposta manual não seria rápida o suficiente para lidar com a carga. Nessas situações, a abordagem mais eficiente e menos sujeita a erros é automatizar o escalonamento dos seus clusters com o Horizontal Pod Autoscaler (HPA).

      Usando informações do Metrics Server, o HPA detectará aumento no uso de recursos e responderá escalando sua carga de trabalho para você. Isso é especialmente útil nas arquiteturas de microsserviço e dará ao cluster Kubernetes a capacidade de escalar seu deployment com base em métricas como a utilização da CPU. Quando combinado como o DigitalOcean Kubernetes (DOKS), uma oferta de Kubernetes gerenciada que fornece aos desenvolvedores uma plataforma para fazer o deploy de aplicações containerizadas, o uso do HPA pode criar uma infraestrutura automatizada que se ajusta rapidamente às mudanças no tráfego e na carga.

      Nota: Ao considerar a possibilidade de usar o autoscaling para sua carga de trabalho, lembre-se de que o autoscaling funciona melhor para aplicativos sem estado ou stateless, especialmente aqueles capazes de ter várias instâncias da aplicação em execução e aceitando tráfego em paralelo. Esse paralelismo é importante porque o principal objetivo do autoscaling é distribuir dinamicamente a carga de trabalho de uma aplicação por várias instâncias no cluster Kubernetes para garantir que sua aplicação tenha os recursos necessários para atender o tráfego de maneira ágil e estável, sem sobrecarregar nenhuma instância única.

      Um exemplo de carga de trabalho que não apresenta esse paralelismo é o autoscaling de banco de dados. A configuração do autoscaling para um banco de dados seria muito mais complexa, pois você precisaria considerar race conditions, problemas com a integridade dos dados, sincronização de dados e adições e remoções constantes de membros do cluster de banco de dados. Por razões como essas, não recomendamos o uso da estratégia de autoscaling deste tutorial para bancos de dados.

      Neste tutorial você vai configurar um deployment de exemplo do Nginx no DOKS que pode auto escalar horizontalmente para dar conta do aumento da carga de CPU. Você conseguirá isso ao fazer o deploy do Metrics Server em seu cluster para reunir métricas de pod para o HPA usar para determinar quando escalar.

      Pré-requisitos

      Antes de começar este guia, você precisará do seguinte:

      • Um cluster Kubernetes na DigitalOcean com sua conexão configurada como padrão kubectl. As instruções sobre como configurar o kubectl são mostradas no passo Connect to your Cluster quando você cria seu cluster. Para criar um cluster Kubernetes na DigitalOcean, consulte Kubernetes Quickstart.

      • O gerenciador de pacotes Helm instalado em sua máquina local e o Tiller instalado em seu cluster. Para fazer isso, execute os passos 1 e 2 do tutorial How To Install Software on Kubernetes Clusters with the Helm Package Manager

      Passo 1 — Criando um Deployment de Teste

      Para mostrar o efeito do HPA, você primeiro fará o deploy de uma aplicação que você utilizará para fazer autoscale. Este tutorial usa uma imagem Nginx Docker padrão como um deployment porque ela é totalmente capaz de operar em paralelo, é amplamente usada no Kubernetes com ferramentas como o Nginx Ingress Controller, e é leve para configurar. Esse deployment do Nginx servirá uma página estática Welcome to Nginx!, que vem por padrão na imagem base. Se você já possui um deployment que gostaria de escalar, sinta-se à vontade para usá-lo e pule este passo.

      Crie o deployment de exemplo usando a imagem base do Nginx executando o seguinte comando. Você pode substituir o nome web se desejar atribuir um nome diferente ao seu deployment:

      • kubectl create deployment web --image=nginx:latest

      A flag --image=nginx:latest criará o deployment a partir da versão mais recente da imagem base do Nginx.

      Após alguns segundos, seu pod web será lançado. Para ver este pod, execute o seguinte comando, que mostrará os pods em execução no namespace atual:

      Isso lhe dará uma saída semelhante à seguinte:

      Output

      NAME READY STATUS RESTARTS AGE web-84d7787df5-btf9h 1/1 Running 0 11s

      Observe que há apenas um pod deployado originalmente. Depois que o autoscaling é acionado, mais pods serão criados automaticamente.

      Agora você tem um deployment básico em funcionamento no cluster. Este é o deployment que você irá configurar para o autoscaling. Seu próximo passo é configurar esse deployment para definir suas solicitações de recursos e limites.

      Passo 2 — Definindo Limites e Solicitações de CPU em seu Deployment

      Neste passo, você irá definir solicitações e limites no uso da CPU para seu deployment. Limites ou Limits no Kubernetes são definidos no deployment para descrever a quantidade máxima de recursos (CPU ou Memória) que o pod pode usar. Solicitações ou Requests são definidas no deployment para descrever quanto desse recurso é necessário em um node para que esse node seja considerado como um node válido para escalonamento. Por exemplo, se seu servidor web tivesse uma solicitação de memória definida em 1 GB, apenas os nodes com pelo menos 1 GB de memória livre seriam considerados para escalonamento. Para o autoscaling, é necessário definir esses limites e solicitações, pois o HPA precisará ter essas informações ao tomar decisões de escalonamento e provisionamento.

      Para definir solicitações e limites, você precisará fazer alterações no deployment que você acabou de criar. Este tutorial usará o seguinte comando kubectl edit para modificar a configuração do objeto API armazenada no cluster. O comando kubectl edit abrirá o editor definido por suas variáveis de ambiente KUBE_EDITOR ou EDITOR, ou cairá de volta no vi para Linux ou notepad para Windows por padrão.

      Edite seu deployment:

      • kubectl edit deployment web

      Você verá a configuração para o deployment. Agora você pode definir limites de recursos e solicitações especificadas para o uso de CPU do seu deployment. Esses limites definem a linha de base de quanto de cada recurso um pod deste deployment pode usar individualmente. Definir isso dará ao HPA um quadro de referência para saber se um pod está sendo sobrecarregado. Por exemplo, se você espera que seu pod tenha um limit superior de 100 milicores de CPU e o pod esteja usando 95 milicores atualmente, a HPA saberá que está com 95% da capacidade. Sem fornecer esse limite de 100 milicores, o HPA não pode decifrar a capacidade total do pod.

      Podemos definir os limites e solicitações na seção resources:

      Deployment Configuration File

      . . .
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: web
          spec:
            containers:
            - image: nginx:latest
              imagePullPolicy: Always
              name: nginx
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
            dnsPolicy: ClusterFirst
            restartPolicy: Always
            schedulerName: default-scheduler
            securityContext: {}
            terminationGracePeriodSeconds: 30
      status:
        availableReplicas: 1
      . . .
      

      Para este tutorial, você definirá requests para CPU como 100m e memória para 250Mi. Esses valores são apenas para fins de demonstração; cada carga de trabalho é diferente, portanto, esses valores podem não fazer sentido para outras cargas de trabalho. Como regra geral, esses valores devem ser definidos no máximo que um pod dessa carga de trabalho deve usar. Recomenda-se o monitoramento da aplicação e a coleta de dados de uso de recursos sobre o desempenho em períodos de baixa e de pico para ajudar a determinar esses valores. Esses valores também podem ser ajustados e alterados a qualquer momento, assim você sempre pode voltar e otimizar seu deployment posteriormente.

      Vá em frente e insira as seguintes linhas destacadas na seção resources do seu container Nginx:

      Deployment Configuration File

      . . .
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: web
          spec:
            containers:
            - image: nginx:latest
              imagePullPolicy: Always
              name: nginx
              resources:
                limits:
                  cpu: 300m
                requests:
                  cpu: 100m
                  memory: 250Mi
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
            dnsPolicy: ClusterFirst
            restartPolicy: Always
            schedulerName: default-scheduler
            securityContext: {}
            terminationGracePeriodSeconds: 30
      status:
        availableReplicas: 1
      . . .
      

      Depois de inserir essas linhas, salve e saia do arquivo. Se houver um problema com a sintaxe, o kubectl irá reabrir o arquivo para você com um erro publicado para que você obtenha mais informações.

      Agora que você definiu seus limites e solicitações, você precisa garantir que suas métricas sejam reunidas para que o HPA possa monitorar e aderir corretamente a esses limites. Para fazer isso, você irá configurar um serviço para reunir as métricas de CPU. Para este tutorial, você usará o projeto Metrics Server para coletar essas métricas, que você instalará com um chart do Helm.

      Passo 3 — Instalando o Metrics Server

      Agora você instalará o Kubernetes Metric Server. Esse é o servidor que extrai as métricas do pod, que reunirá as métricas que o HPA usará para decidir se o autoscaling é necessário.

      Para instalar o Metrics Server usando o Helm, execute o seguinte comando:

      • helm install stable/metrics-server --name metrics-server

      Isso instalará a versão estável mais recente do Metrics Server. A flag --name nomeia este release como metrics-server.

      Depois de aguardar a inicialização deste pod, tente usar o comando kubectl top pod para exibir as métricas do seu pod:

      Este comando tem como objetivo fornecer uma visão em nível de pod do uso de recursos em seu cluster, mas devido à maneira como o DOKS lida com o DNS, esse comando retornará um erro neste momento:

      Output

      Error: Metrics not available for pod Error from server (ServiceUnavailable): the server is currently unable to handle the request (get pods.metrics.k8s.io)

      Esse erro ocorre porque os nodes DOKS não criam um registro DNS para eles mesmos e, como o Metrics Server entra em contato com os nodes por meio de seus nomes de host, os nomes de host não são resolvidos corretamente. Para corrigir esse problema, altere a maneira como o Metrics Server se comunica com os nodes adicionando flags de runtime ao container do Metrics Server usando o seguinte comando:

      • kubectl edit deployment metrics-server

      Você estará adicionando uma flag na seção command.

      metrics-server Configuration File

      . . .
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: metrics-server
              release: metrics-server
          spec:
            affinity: {}
            containers:
            - command:
              - /metrics-server
              - --cert-dir=/tmp
              - --logtostderr
              - --secure-port=8443
              image: gcr.io/google_containers/metrics-server-amd64:v0.3.4
              imagePullPolicy: IfNotPresent
              livenessProbe:
                failureThreshold: 3
                httpGet:
                  path: /healthz
      . . .
      

      A flag que você está adicionando é --kubelet-preferred-address-types=InternalIP. Essa flag informa ao metrics server para contatar os nodes usando seu internalIP em oposição ao nome do host. Você pode usar essa flag como uma solução alternativa para se comunicar com os nodes por meio de endereços IP internos.

      Adicione também a flag --metric-resolution para alterar a taxa padrão na qual o Metrics Server extrai as métricas. Para este tutorial, configuraremos o Metrics Server para realizar pontos de coletas de dados a cada 60s, mas se você quiser mais dados de métricas, poderá solicitar ao Metrics Server que extraia as métricas a cada 10s ou 20s. Isso lhe fornecerá mais pontos de dados de uso de recursos por período de tempo. Sinta-se livre para ajustar esta resolução para atender às suas necessidades.

      Adicione as seguintes linhas destacadas ao arquivo:

      metrics-server Configuration File

      . . .
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: metrics-server
              release: metrics-server
          spec:
            affinity: {}
            containers:
            - command:
              - /metrics-server
              - --cert-dir=/tmp
              - --logtostderr
              - --secure-port=8443
              - --metric-resolution=60s
              - --kubelet-preferred-address-types=InternalIP
              image: gcr.io/google_containers/metrics-server-amd64:v0.3.4
              imagePullPolicy: IfNotPresent
              livenessProbe:
                failureThreshold: 3
                httpGet:
                  path: /healthz
      . . .
      

      Após a adição da flag, salve e saia do seu editor.

      Para verificar se o Metrics Server está em execução, use o kubectl top pod após alguns minutos. Como antes, este comando nos fornecerá o uso de recursos em um nível de pod. Dessa vez, um Metrics Server funcionando permitirá que você veja as métricas em cada pod:

      Isso fornecerá a seguinte saída, com o seu pod do Metrics Server em execução:

      Output

      NAME CPU(cores) MEMORY(bytes) metrics-server-db745fcd5-v8gv6 3m 12Mi web-555db5bf6b-f7btr 0m 2Mi

      Agora você tem um Metrics Server funcional e pode visualizar e monitorar o uso de recursos de pods em seu cluster. Em seguida, você irá configurar o HPA para monitorar esses dados e reagir a períodos de alto uso da CPU.

      Passo 4 — Criando e Validando o Autoscaler Horizontal de Pod

      Por fim, é hora de criar o Horizontal Pod Autoscaler (HPA) para seu deployment. O HPA é o objeto real do Kubernetes que verifica rotineiramente os dados de uso de CPU coletados do Metrics Server e escala seu deployment com base nos limites que você definiu no Passo 2.

      Crie o HPA usando o comando kubectl autoscale:

      • kubectl autoscale deployment web --max=4 --cpu-percent=80

      Este comando cria o HPA para seu deployment web. Ele também usa a flag --max para definir o máximo de réplicas nas quais web pode ser escalado, o que, neste caso, você define como 4.

      A flag --cpu-percent informa ao HPA em qual porcentagem de uso do limite que você definiu no Passo 2 você deseja que o autoscale ocorra. Isso também usa os requests para ajudar a provisionar os pods escalados para um node que possa acomodar a alocação inicial de recursos. Neste exemplo, se o limite que você definiu para o seu deployment no Passo 1 fosse 100 milicores (100m), esse comando dispararia um autoscale assim que o pod atingisse 80m no uso médio da CPU. Isso permitiria que o deployment fosse escalado automaticamente antes de estourar seus recursos de CPU.

      Agora que seu deployment pode ser escalado automaticamente, é hora de testar isso.

      Para validar, você irá gerar uma carga que colocará seu cluster acima do seu limite e assistirá o autoscaler assumir o controle. Para começar, abra um segundo terminal para observar os pods provisionados no momento e atualizar a lista de pods a cada 2 segundos. Para fazer isso, use o comando watch neste segundo terminal:

      O comando watch emite o comando dado como argumento continuamente, exibindo a saída no seu terminal. A duração entre repetições pode ser configurada mais finamente com a flag -n. Para os fins deste tutorial, a configuração padrão de dois segundos será suficiente.

      O terminal agora exibirá a saída do kubectl top pods inicialmente e, a cada 2 segundos, atualizará a saída que esse comando gera, que será semelhante a esta:

      Output

      Every 2.0s: kubectl top pods NAME CPU(cores) MEMORY(bytes) metrics-server-6fd5457684-7kqtz 3m 15Mi web-7476bb659d-q5bjv 0m 2Mi

      Anote o número de pods atualmente deployados para o web.

      Volte ao seu terminal original. Agora você abrirá um terminal dentro do seu pod web atual usando kubectl exec e criará uma carga artificial. Você pode fazer isso entrando no pod e instalando o stress CLI tool.

      Digite seu pod usando kubectl exec, substituindo o nome do pod realçado pelo nome do seu pod web:

      • kubectl exec -it web-f765fd676-s9729 /bin/bash

      Este comando é muito semelhante em conceito ao de usar ssh para efetuar login em outra máquina. O /bin/bash estabelece um shell bash no seu pod.

      Em seguida, no shell bash dentro do seu pod, atualize os metadados do repositório e instale o pacote stress.

      • apt update; apt-get install -y stress

      Nota: Para containers baseados no CentOS, isso seria assim:

      Em seguida, gere alguma carga de CPU no seu pod usando o comando stress e deixe-o executar:

      Agora, volte ao seu comando watch no segundo terminal. Aguarde alguns minutos para o Metrics Server reunir dados de CPU acima do limite definido pelo HPA. Observe que as métricas por padrão são coletadas na taxa que você definir como --metric-resolution ao configurar o metrics server. Pode demorar um minuto para que as métricas de uso sejam atualizadas.

      Após cerca de dois minutos, você verá pods adicionais web subindo:

      Output

      Every 2.0s: kubectl top pods NAME CPU(cores) MEMORY(bytes) metrics-server-db745fcd5-v8gv6 6m 16Mi web-555db5bf6b-ck98q 0m 2Mi web-555db5bf6b-f7btr 494m 21Mi web-555db5bf6b-h5cbx 0m 1Mi web-555db5bf6b-pvh9f 0m 2Mi

      Agora você pode ver que o HPA provisionou novos pods com base na carga de CPU coletada pelo Metrics Server. Quando estiver satisfeito com esta validação, use CTRL+C para interromper o comando stress no seu primeiro terminal e então, saia do shell bash do seu pod.

      Conclusão

      Neste artigo, você criou um deployment que será escalado automaticamente com base na carga de CPU. Você adicionou limites de recursos e solicitações de CPU ao seu deployment, instalou e configurou o Metrics Server em seu cluster por meio do uso do Helm e criou um HPA para tomar decisões de escalabilidade.

      Esse foi um deployment de demonstração tanto do Metrics Server quanto do HPA. Agora você pode ajustar a configuração para se adequar aos seus casos de uso específicos. Certifique-se de verificar a documentação do Kubernetes HPA para ajuda e informação sobre requests e limits. Além disso, confira o Projeto Metrics Server para ver todas as configurações ajustáveis que podem ser aplicadas ao seu caso de uso.

      Se você gostaria de fazer mais com o Kubernetes, visite nossa Página da Comunidade Kubernetes ou explore nosso Serviço Gerenciado de Kubernetes.



      Source link

      Como criar um API Gateway Usando o Ambassador no Kubernetes da DigitalOcean


      O autor escolheu a Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Ambassador é um API Gateway para aplicações nativas em nuvem que roteia o tráfego entre serviços heterogêneos e mantém fluxos de trabalho descentralizados. Ele atua como um único ponto de entrada e suporta tarefas como descoberta de serviço, gerenciamento de configuração, regras de roteamento e limitação de taxas de acesso. Ele também oferece grande flexibilidade e facilidade de configuração para seus serviços.

      O Envoy é um proxy de serviço de código aberto projetado para aplicações nativas em nuvem. No Kubernetes, o Ambassador pode ser usado para instalar e gerenciar a configuração do Envoy. O Ambassador suporta alterações na configuração com tempo zero de inatividade e integração com outros recursos, como autenticação, descoberta de serviços e service meshes.

      Neste tutorial, você configurará um Ambassador API Gateway em um cluster Kubernetes usando o Helm e o configurará para rotear o tráfego de entrada para vários serviços com base nas regras de roteamento. Você configurará essas regras para rotear o tráfego com base no nome do host ou no caminho para os serviços relevantes.

      Pré-requisitos

      Antes de começar este guia, você precisará do seguinte:

      • Um cluster Kubernetes na DigitalOcean com o kubectl configurado. Para criar um cluster Kubernetes na DigitalOcean, veja nosso guia Kubernetes Quickstart.

      • O gerenciador de pacotes Helm instalado em sua máquina local e o Tiller instalado em seu cluster. Complete os passos 1 e 2 do tutorial How To Install Software on Kubernetes Clusters with the Helm Package Manager

      • Um nome de domíno totalmente qualificado com pelo menos dois registros A configurados. Ao longo deste tutorial iremos utilizar svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio. Você pode seguir o guia DNS Quickstart para configurar seus registros na DigitalOcean.

      Passo 1 — Instalando o Ambassador

      Nesta seção, você instalará o Ambassador no seu cluster Kubernetes. O Ambassador pode ser instalado usando um chart do Helm ou passando um arquivo de configuração YAML para o comando kubectl.

      Nota: O Kubernetes na DigitalOcean tem o RBAC ativado por padrão, portanto, ao usar um arquivo de configuração YAML para instalação, é necessário garantir que você use o RBAC ativado. Você pode encontrar mais detalhes sobre o deployment do Ambassador no Kubernetes via YAML na documentação do Ambassador

      Para os propósitos deste tutorial, você usará um chart do Helm para instalar o Ambassador no seu cluster. Após seguir os pré-requisitos, você terá o Helm instalado em seu cluster.

      Para começar, execute o seguinte comando para instalar o Ambassador via Helm:

      • helm upgrade --install --wait ambassador stable/ambassador

      Você verá uma saída semelhante à seguinte:

      Output

      Release "ambassador" does not exist. Installing it now. NAME: ambassador LAST DEPLOYED: Tue Jun 18 02:15:00 2019 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Deployment NAME READY UP-TO-DATE AVAILABLE AGE ambassador 3/3 3 3 2m39s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE ambassador-7d55c468cb-4gpq9 1/1 Running 0 2m38s ambassador-7d55c468cb-jr9zr 1/1 Running 0 2m38s ambassador-7d55c468cb-zhm7l 1/1 Running 0 2m38s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ambassador LoadBalancer 10.245.183.114 139.59.52.164 80:30001/TCP,443:31557/TCP 2m40s ambassador-admins ClusterIP 10.245.46.43 <none> 8877/TCP 2m41s ==> v1/ServiceAccount NAME SECRETS AGE ambassador 1 2m43s ==> v1beta1/ClusterRole NAME AGE ambassador 2m41s ==> v1beta1/ClusterRoleBinding NAME AGE ambassador 2m41s ==> v1beta1/CustomResourceDefinition NAME AGE authservices.getambassador.io 2m42s consulresolvers.getambassador.io 2m41s kubernetesendpointresolvers.getambassador.io 2m42s kubernetesserviceresolvers.getambassador.io 2m43s mappings.getambassador.io 2m41s modules.getambassador.io 2m41s ratelimitservices.getambassador.io 2m42s tcpmappings.getambassador.io 2m41s tlscontexts.getambassador.io 2m42s tracingservices.getambassador.io 2m43s . . .

      Isso criará um deployment do Ambassador, um serviço e um balanceador de carga do Ambassador com os seus nodes do cluster Kubernetes conectados. Você precisará do IP do balanceador de carga para mapeá-lo para os registros A do seu domínio

      Para obter o endereço IP do balanceador de carga do seu Ambassador, execute o seguinte:

      • kubectl get svc --namespace default ambassador

      Você verá uma saída semelhante a:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ambassador LoadBalancer IP-do-seu-cluster seu-endereço-IP 80:30001/TCP,443:31557/TCP 8m4s

      Observe o IP externo seu-endereço-IP neste passo e mapeie os domínios (através de seu provedor de domínio) svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio para apontar para este endereço IP.

      Você pode ativar o HTTPS com o seu balanceador de carga na DigitalOcean usando os passos fornecidos em Como configurar a terminação SSL. É recomendável configurar a terminação TLS por meio do balanceador de carga. Outra maneira de configurar a terminação TLS é usar o Suporte TLS do Ambassador

      Você instalou o Ambassador no seu cluster Kubernetes usando o Helm, que criou um deployment do Ambassador com três réplicas no namespace padrão. Isso também criou um balanceador de carga com um IP público para rotear todo o tráfego em direção ao API Gateway. Em seguida, você criará deployments do Kubernetes para três serviços diferentes que você usará para testar esse API Gateway.

      Passo 2 — Configurando Deployments de Servidor Web

      Nesta seção, você criará três deployments para executar três containers de servidor web diferentes. Você criará arquivos YAML com definições de deployments do Kubernetes para os três diferentes containers de servidores web e fará o deploy usando o kubectl.

      Abra seu editor de texto preferido para criar seu primeiro deployment para um servidor web Nginx:

      Digite a seguinte configuração yaml no seu arquivo:

      svc1-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc1
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: nginx
            name: svc1
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: nginx
              name: svc1
          spec:
            containers:
            - name: nginx
              image: nginx:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container nginx:latest a ser deployada com 1 réplica, chamada svc1. O Deployment é definido para expor o cluster na porta 80.

      Salve e feche o arquivo.

      Em seguida, execute o seguinte comando para aplicar esta configuração:

      • kubectl apply -f svc1-deploy.yaml

      Você verá a saída confirmando a criação:

      Output

      deployment.extensions/svc1 created

      Agora, crie um segundo deployment de servidor web. Abra um arquivo chamado svc2-deploy.yaml com:

      Digite a seguinte configuração YAML no arquivo:

      svc2-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc2
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: httpd
            name: svc2
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: httpd
              name: svc2
          spec:
            containers:
            - name: httpd
              image: httpd:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container httpd a ser deployada com 1 réplica, chamada svc2.

      Salve e feche o arquivo.

      Execute o seguinte comando para aplicar esta configuração:

      • kubectl apply -f svc2-deploy.yaml

      Você verá esta saída:

      Output

      deployment.extensions/svc2 created

      Finalmente, para o terceiro deployment, abra e crie o arquivo svc3-deploy.yaml:

      Adicione as seguintes linhas ao arquivo:

      svc3-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc3
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: httpbin
            name: svc3
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: httpbin
              name: svc3
          spec:
            containers:
            - name: httpbin
              image: kennethreitz/httpbin:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container httpbin a ser deployada com 1 réplica, chamada svc3.

      Salve e feche o arquivo.

      Por fim, execute o seguinte comando para aplicar:

      • kubectl apply -f svc3-deploy.yaml

      E você verá a seguinte saída:

      Output

      deployment.extensions/svc3 created

      Você fez o deploy de três containers de servidor web usando deployments do Kubernetes. No próximo passo, você irá expor esses deployments ao tráfego da Internet.

      Nesta seção, você irá expor suas aplicações web à Internet, criando os Serviços Kubernetes com Anotações do Ambassador para configurar regras para rotear o tráfego para eles. Annotations ou Anotações no Kubernetes são uma maneira de adicionar metadados aos objetos. O Ambassador usa esses valores de anotação dos serviços para configurar suas regras de roteamento.

      Como lembrete, você precisa ter seus domínios (por exemplo: svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio) mapeados para o IP público do balanceador de carga em seus registros DNS.

      Defina um serviço Kubernetes para o deployment do svc1 com anotações do Ambassador, criando e abrindo este arquivo:

      Nota: O nome do mapeamento deve ser exclusivo para cada bloco de anotação do Ambassador. O mapeamento atua como um identificador para cada bloco de anotação e, se repetido, ele irá sobrepor o bloco de anotação mais antigo.

      svc1-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc1
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc1-service_mapping
            host: svc1.seu-domínio
            prefix: /
            service: svc1:80
      spec:
        selector:
          app: nginx
          name: svc1
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Neste código YAML, você definiu um serviço Kubernetes svc1 usando anotações do Ambassador para mapear o nome do host svc1.seu-domínio para este serviço.

      Salve e saia do arquivo svc1-service.yaml e execute o seguinte para aplicar esta configuração:

      • kubectl apply -f svc1-service.yaml

      Você verá esta saída:

      Output

      service/svc1 created

      Crie seu segundo serviço Kubernetes para o deployment do svc2 com anotações do Ambassador. Este é outro exemplo de roteamento baseado em host com o Ambassador:

      Adicione a seguinte configuração ao arquivo:

      svc2-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc2
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc2-service_mapping
            host: svc2.seu-domínio
            prefix: /
            service: svc2:80
      spec:
        selector:
          app: httpd
          name: svc2
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Salve isso como svc2-service.yaml. Aqui, você definiu outro serviço Kubernetes usando anotações do Ambassador para rotear o tráfego para svc2 quando qualquer solicitação é recebida pelo Ambassador com o valor do cabeçalho host como svc2.seu-domínio. Portanto, esse roteamento baseado em host permitirá que você envie uma solicitação ao subdomínio svc2.seu-domínio, que encaminhará o tráfego para o serviço svc2 e servirá sua solicitação a partir do servidor web httpd.

      Para criar este serviço, execute o seguinte:

      • kubectl apply -f svc2-service.yaml

      Você verá a seguinte saída:

      Output

      service/svc2 created

      Crie um terceiro serviço Kubernetes para seu deployment svc3 e sirva-o através do caminho svc2.seu-domínio/bin. Isso configurará o roteamento baseado em caminho para o Ambassador:

      svc3-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc3
      spec:
        selector:
          app: httpbin
          name: svc3
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Salve isso como svc3-service.yaml e execute o seguinte para aplicar a configuração:

      • kubectl apply -f svc3-service.yaml

      Sua saída será:

      Output

      service/svc3 created

      Edite svc2-service.yaml para acrescentar o segundo bloco de anotação do Ambassador para rotear o /bin para o serviço svc3:

      svc2-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc2
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc2-service_mapping
            host: svc2.seu-domínio
            prefix: /
            service: svc2:80
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc3-service_mapping
            host: svc2.seu-domínio
            prefix: /bin
            service: svc3:80
      spec:
        selector:
          app: httpd
          name: svc2
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Você adicionou o segundo bloco de anotação do Ambassador para configurar os caminhos que começam com /bin para mapear para o seu serviço Kubernetes svc3. Para rotear solicitações de svc2.seu-domínio/bin para svc3, você adicionou o segundo bloco de anotação aqui com o valor do host svc2.seu-domínio, que é o mesmo para os dois blocos. Portanto, o roteamento baseado em caminho permitirá que você envie uma solicitação ao svc2.seu-domínio/bin, que será recebido pelo serviço svc3 e servido pela aplicação httpbin neste tutorial.

      Agora execute o seguinte para aplicar as alterações:

      • kubectl apply -f svc2-service.yaml

      Você verá esta saída:

      Output

      service/svc2 configured

      Você criou os Serviços Kubernetes para os três deployments e adicionou regras de roteamento com base no host e no caminho com as anotações do Ambassador. Em seguida, você adicionará configuração avançada a esses serviços para configurar o roteamento, o redirecionamento e cabeçalhos personalizados.

      Passo 4 — Configurações Avançadas do Ambassador para Roteamento

      Nesta seção, você irá configurar os serviços com mais anotações do Ambassador para modificar cabeçalhos e configurar redirecionamento.

      Faça um curl no domínio svc1.seu-domínio e verifique os cabeçalhos de resposta:

      • curl -I svc1.seu-domínio

      Sua saída será semelhante à seguinte:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 21:41:00 GMT content-type: text/html content-length: 612 last-modified: Tue, 21 May 2019 14:23:57 GMT etag: "5ce409fd-264" accept-ranges: bytes x-envoy-upstream-service-time: 0

      Esta saída mostra os cabeçalhos recebidos do serviço roteado usando o Ambassador. Você adicionará cabeçalhos personalizados à sua resposta de serviço usando as anotações do Ambassador e validará a saída para os novos cabeçalhos adicionados.

      Para adicionar cabeçalhos personalizados à sua resposta de serviço, remova o cabeçalho x-envoy-upstream-service-time da resposta e adicione um novo cabeçalho de resposta x-geo-location: Brazil para o svc1. (Você pode alterar este cabeçalho conforme seus requisitos.)

      Edite o arquivo svc1-service.yaml:

      Atualize a anotação com as seguintes linhas destacadas:

      svc1-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc1
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc1-service_mapping
            host: svc1.example.com
            prefix: /
            remove_response_headers:
            - x-envoy-upstream-service-time
            add_response_headers:
              x-geo-location: Brazil
            service: svc1:80
      spec:
        selector:
          app: nginx
          name: svc1
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Aqui você modificou o serviço svc1 para remover x-envoy-upstream-service-time e adicionou o cabeçalho x-geo-location: Brazil na resposta HTTP.

      Aplique as alterações que você fez:

      • kubectl apply -f svc1-service.yaml

      Você verá a seguinte saída:

      Output

      service/svc1 configured

      Agora execute curl para validar os cabeçalhos atualizados na resposta do serviço:

      • curl -I svc1.seu-domínio

      A saída será semelhante a esta:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 21:45:26 GMT content-type: text/html content-length: 612 last-modified: Tue, 21 May 2019 14:23:57 GMT etag: "5ce409fd-264" accept-ranges: bytes x-geo-location: Brazil

      Agora edite o svc3-service.yaml para redirecionar solicitações para o seu nome de host svc3.seu-domínio para o caminho svc2.seu-domínio/bin:

      Acrescente o bloco de anotação do Ambassador, conforme mostrado no YAML a seguir, e salve-o:

      svc3-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc3
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind:  Mapping
            name:  redirect_mapping
            host: svc3.seu-domínio
            prefix: /
            service: svc2.seu-domínio
            host_redirect: true
            path_redirect: /bin
      spec:
        selector:
          app: httpbin
          name: svc3
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Você adicionou host_redirect: true para configurar uma resposta de redirecionamento 301 de svc3 para svc2.seu-domínio/bin para o nome de host svc3.seu-domínio . O parâmetro host_redirect envia uma resposta de redirecionamento 301 para o cliente. Se não estiver definido, as requisições receberão respostas 200 HTTP em vez de respostas 301 HTTP.

      Agora execute o seguinte comando para aplicar essas alterações:

      • kubectl apply -f svc3-service.yaml

      Você verá uma saída semelhante a:

      Output

      service/svc3 configured

      Agora você pode verificar a resposta para svc3.seu-domínio usando curl:

      • curl -I svc3.seu-domínio

      Sua saída será semelhante à seguinte:

      Output

      HTTP/1.1 301 Moved Permanently location: http://svc2.seu-domínio/bin date: Mon, 17 Jun 2019 21:52:05 GMT server: envoy transfer-encoding: chunked

      A saída é um cabeçalho HTTP para a resposta da solicitação ao serviço svc3.seu-domínio mostrando que a configuração de host_redirect: true na anotação do serviço forneceu corretamente o código de status HTTP: 301 Moved Permanently.

      Você configurou o serviço com anotações do Ambassador para modificar cabeçalhos HTTP e configurar redirecionamentos. Em seguida, você adicionará a configuração global ao serviço Ambassador API Gateway.

      Passo 5 — Definindo Configurações Globais do Ambassador

      Nesta seção, você editará o serviço Ambassador para adicionar a configuração global de compactação GZIP. A compactação GZIP compactará o tamanho dos assets HTTP e reduzirá os requisitos de largura de banda da rede, levando a tempos de resposta mais rápidos para os clientes web. Essa configuração afeta todo o tráfego que está sendo roteado pelo Ambassador API Gateway. Da mesma forma, você pode configurar outros módulos globais com o Ambassador, que permitem ativar comportamentos especiais para o serviço em nível global. Essas configurações globais podem ser aplicadas usando anotações do serviço Ambassador. Você pode consultar a documentação da Configuração Global do Ambassador para obter mais informações.

      O seguinte comando kubectl edit abrirá o editor padrão, que é o vim. Para usar o nano, por exemplo, você pode definir a variável de ambiente KUBE_EDITOR como nano:

      • export KUBE_EDITOR="nano"

      Edite o serviço Ambassador:

      • kubectl edit service ambassador

      Agora adicione as linhas destacadas a um novo bloco de anotação para compactação GZIP:

      Editing Ambassador Service

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Module
            name: ambassador
            config:
              service_port: 8080
            ---
            apiVersion: ambassador/v0
            kind:  Module
            name:  ambassador
            config:
              gzip:
                memory_level: 5
                min_content_length: 256
                compression_level: BEST
                compression_strategy: DEFAULT
                content_type:
                - application/javascript
                - application/json
                - text/html
                - text/plain
                disable_on_etag_header: false
                remove_accept_encoding_header: false
        creationTimestamp: "2019-06-17T20:45:04Z"
        labels:
          app.kubernetes.io/instance: ambassador
          app.kubernetes.io/managed-by: Tiller
          app.kubernetes.io/name: ambassador
          helm.sh/chart: ambassador-2.8.2
        name: ambassador
        namespace: default
        resourceVersion: "2153"
        . . .
      

      Você adicionou o bloco de anotação do Ambassador ao seu serviço Ambassador e configurou o GZIP globalmente para o API Gateway. Aqui você incluiu a configuração para controlar a quantidade de memória interna usada com memory_level, que pode ser um valor de 1 a 9. O compression_level configurado como BEST garante uma taxa de compactação mais alta, com o custo de uma latência mais alta. Com o min_content_length, você configurou o comprimento mínimo de resposta para 256 bytes. Para o content_type, você incluiu especificamente um conjunto de tipos de mídia (anteriormente MIME-types) que produz compactação. Finalmente, você adicionou as duas configurações finais como false para permitir a compactação.

      Você pode ler mais sobre a compactação GZIP na página sobre GZIP do Envoy.

      Quaisquer alterações neste serviço se aplicam como configurações globais para o API Gateway.

      Depois de sair do editor, você verá uma saída semelhante à seguinte:

      Output

      service/ambassador edited

      Verifique o svc1.seu-domínio usando o curl para ver o cabeçalho content-encoding tendo o valor gzip:

      • curl --compressed -i http://svc1.example.com

      A saída será semelhante a esta:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 22:25:35 GMT content-type: text/html last-modified: Tue, 21 May 2019 14:23:57 GMT accept-ranges: bytes x-geo-location: Brazil vary: Accept-Encoding content-encoding: gzip transfer-encoding: chunked <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>

      Aqui você pode ver a página HTML padrão do Nginx com seu cabeçalho de resposta, mostrando que o content-encoding da resposta recebida é compactação gzip.

      Você adicionou a configuração global ao Ambassador para habilitar a configuração GZIP para respostas de tipos de conteúdo selecionados no API Gateway.

      Conclusão

      Você configurou com êxito um API Gateway para seu cluster Kubernetes usando o Ambassador. Agora você pode expor suas aplicações usando roteamento baseado em host e caminho, com cabeçalhos personalizados e a compactação GZIP global.

      Para obter mais informações sobre as anotações do Ambassador e parâmetros de configuração, leia a documentação oficial do Ambassador.



      Source link