Cloud Service Mesh es una herramienta potente para administrar y supervisar aplicaciones. Para aprovechar al máximo Cloud Service Mesh, es útil comprender sus abstracciones subyacentes, incluidos los contenedores y Kubernetes. En este instructivo, se explica cómo preparar una aplicación para Cloud Service Mesh del código fuente a un contenedor que se ejecuta en GKE, hasta el punto antes de instalar Cloud Service Mesh.
Si ya conoces Kubernetes y los conceptos de malla de servicios, omita este instructivo y vaya directamente a Malla de servicios en la nube guía de instalación.
Objetivos
- Explorarás una aplicación “Hello World” simple de varios servicios.
- Ejecutarás la aplicación desde la fuente.
- Organizarás la aplicación en contenedores.
- Crearás un clúster de Kubernetes.
- Implementarás los contenedores en el clúster.
Antes de comenzar
Sigue estos pasos para habilitar la API de Cloud Service Mesh:- Consulta la página Kubernetes Engine en la consola de Google Cloud.
- Crea o selecciona un proyecto.
- Espera a que la API y los servicios relacionados se habiliten. Esto puede tomar varios minutos.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
En este instructivo, se usa Cloud Shell, que aprovisiona un Máquina virtual g1-small de Compute Engine (VM) que ejecuta un sistema operativo Linux basado en Debian.
Prepara Cloud Shell
Las ventajas de usar Cloud Shell son las siguientes:
- Los entornos de desarrollo de Python 2 y Python 3 (incluido
virtualenv
) están configurados. - Las herramientas de línea de comandos de
gcloud
,docker
,git
ykubectl
que se usan en este instructivo ya están instaladas. Puedes elegir entre los editores de texto:
El editor de código, al que puedes acceder desde en la parte superior de la ventana de Cloud Shell
Emacs, Vim o Nano, a los que puedes acceder desde la línea de comandos en Cloud Shell.
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Descarga el código de muestra
Descarga el código fuente de
helloserver
:git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
Cambia al directorio del código de muestra:
cd anthos-service-mesh-samples/docs/helloserver
Explora la aplicación de varios servicios
La aplicación de muestra está escrita en Python y tiene dos componentes que se comunican mediante REST:
server
: Es un servidor simple con un extremoGET
,/
, que imprime “Hello World” en la consola.loadgen
: Es una secuencia de comandos que envía tráfico alserver
, con una cantidad configurable de solicitudes por segundo (RPS).
Ejecuta la aplicación desde la fuente
Para familiarizarte con la aplicación de ejemplo, ejecútala en Cloud Shell.
Desde el directorio
sample-apps/helloserver
, ejecuta elserver
:python3 server/server.py
En el inicio, el
server
muestra lo siguiente:INFO:root:Starting server...
Abre otra ventana de la terminal para poder enviar solicitudes al
server
. Haz clic en para abrir otra sesión.Envía una solicitud al
server
:curl http://localhost:8080
Esta es la respuesta del
server
:Hello World!
Desde el directorio en el que descargaste el código de muestra, cambia al directorio que contiene
loadgen
:cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/loadgen
Crea las siguientes variables de entorno:
export SERVER_ADDR=http://localhost:8080 export REQUESTS_PER_SECOND=5
Inicia
virtualenv
:virtualenv --python python3 env
Activa el entorno virtual:
source env/bin/activate
Instala los requisitos de
loadgen
:pip3 install -r requirements.txt
Ejecuta
loadgen
:python3 loadgen.py
En el inicio,
loadgen
genera un mensaje similar al siguiente:Starting loadgen: 2019-05-20 10:44:12.448415 5 request(s) complete to http://localhost:8080
En la otra ventana de la terminal, el
server
escribe mensajes similares al siguiente en la consola:127.0.0.1 - - [21/Jun/2019 14:22:01] "GET / HTTP/1.1" 200 - INFO:root:GET request, Path: / Headers: Host: localhost:8080 User-Agent: python-requests/2.22.0 Accept-Encoding: gzip, deflate Accept: */*
Desde el punto de vista de las herramientas de redes, toda la aplicación ahora se ejecuta en el mismo host. Por este motivo, puedes usar
localhost
para enviar solicitudes a laserver
Para detener
loadgen
y elserver
, ingresaCtrl-c
en cada ventana de la terminal.En la ventana de la terminal de
loadgen
, desactiva el entorno virtual:deactivate
Organiza la aplicación en contenedores
Para ejecutar la aplicación en GKE, debes empaquetar la aplicación de muestra, el server
y loadgen
, en contenedores. Un contenedor es una forma de empaquetar una aplicación de modo que esté aislada del entorno subyacente.
Para organizar la aplicación en contenedores, necesitas un Dockerfile
. Un Dockerfile
es un archivo de texto que define los comandos necesarios para juntar el código fuente de la aplicación y sus dependencias en una imagen de Docker. Después de compilar la imagen, debes subirla a un registro de contenedores, como Docker Hub o Container Registry.
La muestra incluye un Dockerfile
para el server
y loadgen
con todos los comandos necesarios a fin de compilar las imágenes. A continuación, se incluye el Dockerfile
para el server
:
- Con el comando
FROM python:3-slim as base
, se le indica a Docker que use la imagen de Python 3 más reciente como imagen base. - Con el comando
COPY . .
, se copian los archivos fuente del directorio de trabajo actual (en este caso, soloserver.py
) en el sistema de archivos del contenedor. - El
ENTRYPOINT
define el comando que se usa para ejecutar el contenedor. En este caso, el comando es casi el mismo que usaste para ejecutarserver.py
desde el código fuente. - Con el comando
EXPOSE
, e especifica que elserver
escucha en el puerto8080
. Este comando no expone ningún puerto, pero sirve como documentación que necesitas para abrir el puerto8080
cuando ejecutas el contenedor.
Prepárate para organizar la aplicación en contenedores
Configura las siguientes variables de entorno: Reemplazar
PROJECT_ID
por el ID de tu proyecto de Google Cloud.export PROJECT_ID="PROJECT_ID"
export GCR_REPO="asm-ready"
Usa el valor de
PROJECT_ID
yGCR_REPO
para etiquetar la imagen de Docker durante la compilación y envía la imagen a tu Container Registry privado.Configura el proyecto predeterminado de Google Cloud para Google Cloud CLI.
gcloud config set project $PROJECT_ID
Establece la zona predeterminada para la CLI de Google Cloud.
gcloud config set compute/zone us-central1-b
Asegúrate de que el servicio de Container Registry esté habilitado en tu proyecto de Google Cloud.
gcloud services enable containerregistry.googleapis.com
Crea contenedores para el server
Cambia al directorio en el que se encuentra el
server
de muestra:cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/
Compila la imagen mediante el
Dockerfile
y las variables de entorno que definiste antes:docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1 .
La marca
-t
representa la etiqueta de Docker. Este es el nombre de la imagen que debes usar en la implementación del contenedor.Envía la imagen a Container Registry:
docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1
Crea contenedores para loadgen
Cambia al directorio en el que se encuentra la muestra de
loadgen
:cd ../loadgen
Compila la imagen:
docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1 .
Envía la imagen a Container Registry:
docker push gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1
Obtén una lista de las imágenes
Obtén una lista de las imágenes en el repositorio para confirmar que se enviaron:
gcloud container images list --repository gcr.io/$PROJECT_ID/asm-ready
El comando responde con los nombres de las imágenes que acabas de enviar:
NAME gcr.io/PROJECT_ID/asm-ready/helloserver gcr.io/PROJECT_ID/asm-ready/loadgen
Cree un clúster de GKE
Puedes ejecutar estos contenedores en la VM de Cloud Shell con el
Comando docker run
. Pero en producción, debes organizar los contenedores en un
de una forma más unificada. Por ejemplo, necesitas un sistema que garantice que el
los contenedores están siempre en ejecución, y necesitas una forma de escalar verticalmente y
instancias adicionales de un contenedor para manejar los aumentos de tráfico.
Puedes usar GKE para ejecutar aplicaciones en contenedores. GKE es una plataforma de organización de contenedores que funciona mediante la conexión de VM a un clúster. Cada VM se conoce como un nodo. Los clústeres de GKE funcionan con el sistema de administración de clústeres de código abierto de Kubernetes. Kubernetes proporciona los mecanismos que usas para interactuar con el clúster.
Creación de un clúster de GKE:
Crea el clúster:
gcloud container clusters create asm-ready \ --cluster-version latest \ --machine-type=n1-standard-4 \ --num-nodes 4
El comando
gcloud
crea un clúster en el el proyecto y la zona de Google Cloud que configuraste anteriormente. Para ejecutar Cloud Service Mesh, recomendamos al menos 4 nodos y la n1-standard-4 el tipo de máquina de la instancia.El comando para crear el clúster toma unos minutos en completarse. Cuando el clúster está listo, el comando genera un mensaje similar al siguiente:
NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS asm-ready us-central1-b 1.13.5-gke.10 203.0.113.1 n1-standard-2 1.13.5-gke.10 4 RUNNING
Proporciona credenciales a la herramienta de línea de comandos de
kubectl
para que puedas usarla a fin de administrar el clúster:gcloud container clusters get-credentials asm-ready
Ahora puedes usar
kubectl
para comunicarte con Kubernetes. Por ejemplo, puedes ejecutar el siguiente comando para obtener el estado de los nodos:kubectl get nodes
El comando da como resultado una lista de los nodos, similar a la siguiente:
NAME STATUS ROLES AGE VERSION gke-asm-ready-default-pool-dbeb23dc-1vg0 Ready <none> 99s v1.13.6-gke.13 gke-asm-ready-default-pool-dbeb23dc-36z5 Ready <none> 100s v1.13.6-gke.13 gke-asm-ready-default-pool-dbeb23dc-fj7s Ready <none> 99s v1.13.6-gke.13 gke-asm-ready-default-pool-dbeb23dc-wbjw Ready <none> 99s v1.13.6-gke.13
Comprende los conceptos clave de Kubernetes
En el siguiente diagrama, se muestra la aplicación que se ejecuta en GKE:
Antes de implementar los contenedores en GKE, te recomendamos revisar algunos conceptos clave de Kubernetes. Al final de este instructivo, se proporcionan vínculos para que puedas obtener más información sobre cada concepto.
Nodos y clústeres: en GKE, un nodo es una VM. En otras plataformas de Kubernetes, un nodo puede ser una máquina física o virtual. Un clúster es un conjunto de nodos que se pueden tratar en conjunto como una sola máquina y en el que implementas una aplicación en contenedores.
Pods: en Kubernetes, los contenedores se ejecutan dentro de un Pod. Un Pod es la unidad atómica en Kubernetes. Un Pod contiene uno o más contenedores. Debes implementar los contenedores de
server
yloadgen
, cada uno en su propio Pod. Cuando un Pod ejecuta varios contenedores (por ejemplo, un servidor de aplicaciones y un servidor proxy), los contenedores se administran como una sola entidad y comparten los recursos del Pod.Deployments: Un Deployment es un objeto de Kubernetes que representa un conjunto de Pods idénticos. Un Deployment ejecuta varias réplicas de los Pods distribuidos entre los nodos de un clúster. Un Deployment reemplaza de forma automática cualquier Pod que falla o deja de responder.
Service de Kubernetes: la ejecución del código de la aplicación en GKE cambia las herramientas de redes entre
loadgen
yserver
. Cuando ejecutaste el servicios en una VM de Cloud Shell, puedes enviar solicitudes aserver
con la direcciónlocalhost:8080
. Después de la implementación en GKE, los Pods están programados para ejecutarse en los nodos disponibles. De forma predeterminada, no puedes controlan en qué nodo se ejecuta el Pod, Los Pods no tienen con direcciones IP estables.A fin de obtener una dirección IP para el
server
, debes definir una abstracción de herramientas de redes además de los Pods, lo que se denomina Service de Kubernetes. Un Service de Kubernetes proporciona un extremo de herramientas de redes estable para un conjunto de Pods. Existen varios tipos de objetos Service. Elserver
usa unLoadBalancer
, que expone una dirección IP externa para que puedas llegar alserver
desde fuera del clúster.Kubernetes también tiene un sistema DNS integrado, que asigna nombres de DNS (por ejemplo,
helloserver.default.cluster.local
) a los objetos Service. Esto permite que los Pods del clúster lleguen a otros Pods dentro del clúster con una dirección estable. No puedes usar este nombre de DNS fuera del clúster, por ejemplo, desde Cloud Shell.
Manifiestos de Kubernetes
Cuando ejecutaste la aplicación desde el código fuente, usaste un comando imperativo: python3 server.py
“Imperativo” significa basado en un verbo: “haz esto”.
Por el contrario, Kubernetes opera en función de un modelo declarativo. Esto significa que, en lugar de indicarle a Kubernetes qué hacer con exactitud, le proporcionas a Kubernetes el estado deseado. Por ejemplo, Kubernetes inicia y finaliza los Pods según sea necesario para que el estado real del sistema coincida con el estado deseado.
Debes especificar el estado deseado en un conjunto de manifiestos o archivos YAML. Un archivo YAML contiene la especificación de uno o más objetos de Kubernetes.
La muestra contiene un archivo YAML para server
y loadgen
. Cada archivo YAML especifica el estado deseado para los objetos Deployment y Service de Kubernetes.
Servidor
kind
indica el tipo de objeto.metadata.name
especifica el nombre del objeto Deployment.- El primer campo
spec
contiene una descripción del estado deseado. spec.replicas
especifica la cantidad de Pods deseados.- La sección
spec.template
define una plantilla de Pod. En la especificación para los Pods, se incluye el campoimage
, que es el nombre de la imagen que se extraerá de Container Registry.
El Service se define de la siguiente manera:
LoadBalancer
: Los clientes envían solicitudes a la dirección IP de un balanceador de cargas de redes, que tiene una dirección IP estable y a la que se puede acceder desde fuera del clúster.targetPort
: Recuerda que el comandoEXPOSE 8080
en elDockerfile
no expone ningún puerto. Debes exponer el puerto8080
para poder acceder al contenedor deserver
fuera del clúster. En este caso,hellosvc.default.cluster.local:80
(nombre corto:hellosvc
) se asigna al puerto8080
de la IP del Podhelloserver
.port
: Este es el número de puerto que usan otros servicios en el clúster cuando envían solicitudes.
Generador de cargas
El objeto Deployment en loadgen.yaml
es similar a server.yaml
. Una diferencia notable es que el objeto Deployment contiene una sección llamada env
. En esta sección, se definen las variables de entorno que requiere loadgen
, que configuraste antes cuando ejecutaste la aplicación desde la fuente.
Debido a que loadgen
no acepta solicitudes entrantes, el campo type
se establece en ClusterIP
. Este tipo proporciona una dirección IP estable que los servicios en el clúster pueden usar, pero la dirección IP no está expuesta a clientes externos.
Implementa los contenedores en GKE
Cambia al directorio en el que se encuentra el
server
de muestra:cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/
Abre
server.yaml
en un editor de texto.Reemplaza el nombre en el campo
image
por el nombre de tu imagen de Docker.image: gcr.io/PROJECT_ID/asm-ready/helloserver:v0.0.1
Reemplaza
PROJECT_ID
por el ID del proyecto de Google Cloud.Guarda y cierra
server.yaml
.Implementa el archivo YAML en Kubernetes:
kubectl apply -f server.yaml
Si se ejecuta de forma correcta, el comando responde con lo siguiente:
deployment.apps/helloserver created service/hellosvc created
Cambia al directorio en el que se encuentra
loadgen
.cd ../loadgen
Abre
loadgen.yaml
en un editor de texto.Reemplaza el nombre en el campo
image
por el nombre de tu imagen de Docker.image: gcr.io/PROJECT_ID/asm-ready/loadgen:v0.0.1
Reemplaza
PROJECT_ID
por el ID del proyecto de Google Cloud.Guarda y cierra
loadgen.yaml
, y cierra el editor de texto.Implementa el archivo YAML en Kubernetes:
kubectl apply -f loadgen.yaml
Si se ejecuta de forma correcta, el comando responde con lo siguiente:
deployment.apps/loadgenerator created service/loadgensvc created
Verifica el estado de los Pods:
kubectl get pods
El comando responde con un estado similar al siguiente:
NAME READY STATUS RESTARTS AGE helloserver-69b9576d96-mwtcj 1/1 Running 0 58s loadgenerator-774dbc46fb-gpbrz 1/1 Running 0 57s
Obtén los registros de la aplicación desde el Pod
loadgen
. ReemplazaPOD_ID
por el identificador del resultado anterior.kubectl logs loadgenerator-POD_ID
Obtén las direcciones IP externas de
hellosvc
:kubectl get service
La respuesta del comando es similar a la siguiente:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hellosvc LoadBalancer 10.81.15.158 192.0.2.1 80:31127/TCP 33m kubernetes ClusterIP 10.81.0.1 <none> 443/TCP 93m loadgensvc ClusterIP 10.81.15.155 <none> 80/TCP 4m52s
Envía una solicitud a
hellosvc
. ReemplazaEXTERNAL_IP
por la dirección IP externa de tuhellosvc
.curl http://EXTERNAL_IP
Listo para la malla de servicios en la nube
Ahora tienes la aplicación implementada en GKE. Es posible que loadgen
use el DNS de Kubernetes (hellosvc:80
) para enviar solicitudes al server
, y tú puedes enviar solicitudes al server
con una dirección IP externa. Aunque Kubernetes te brinda muchas funciones, falta información sobre los servicios:
- ¿Cómo interactúan los servicios? ¿Cuál es la relación entre los servicios? ¿Cómo fluye el tráfico entre los servicios? Sabes que
loadgen
envía solicitudes alserver
, pero imagínate que no estás familiarizado con la aplicación. No puedes responder estas preguntas si consultas la lista de Pods en ejecución en GKE. - Métricas: ¿Cuánto tarda el
server
en responder a las solicitudes entrantes? ¿Cuántas solicitudes por segundo (RPS) recibe elserver
? ¿Hay alguna respuesta de error? - Información de seguridad: Es el tráfico entre
loadgen
y elserver
sin formato. ¿HTTP
o mTLS?
La malla de servicios de Cloud puede brindar respuestas a estas preguntas. Cloud Service Mesh es una versión administrada por Google Cloud del proyecto Istio de código abierto. Cloud Service Mesh funciona colocando un
Proxy de sidecar Envoy en cada Pod. El proxy Envoy intercepta todo el tráfico de entrada y de salida de los contenedores de la aplicación. Esto significa que el server
y loadgen
obtienen un proxy de sidecar Envoy cada uno, y todo el tráfico de loadgen
al server
está mediado por los proxies Envoy. Las conexiones entre estos proxies Envoy forman la malla de servicios. Esta arquitectura de la malla de servicios proporciona una capa de control sobre Kubernetes.
Debido a que los proxies de Envoy se ejecutan en sus propios contenedores, puedes instalar Cloud Service Mesh en superior de un clúster de GKE sin cambios sustanciales en tu el código de la aplicación. Sin embargo, hay algunas formas clave en las que preparaste app que se instrumentará con la malla de servicios de Cloud:
- Servicios para todos los contenedores: los objetos Deployment de
server
yloadgen
tienen un servicio de Kubernetes adjunto. Incluso elloadgen
, que no recibe solicitudes entrantes, tiene un servicio. - Los puertos en los servicios deben tener un nombre: aunque GKE te permite
definir puertos de servicio sin nombre, Cloud Service Mesh requiere que proporciones un
nombre para un puerto
que coincida con el protocolo del puerto. En el archivo YAML, el puerto del
server
se llamahttp
porque elserver
usa el protocolo de comunicaciónHTTP
. Si elservice
usaragRPC
, le asignarías el nombregrpc
al puerto. - Las implementaciones están etiquetadas, lo que te permite usar la administración del tráfico de Cloud Service Mesh como la división del tráfico entre versiones del mismo servicio.
Instala Cloud Service Mesh
Visita la guía de instalación de Cloud Service Mesh y sigue las instrucciones de instalación. Cloud Service Mesh en tu clúster.
Limpia
Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.
Para descartar recursos, borra el clúster de GKE. Cuando borras el clúster, se borran todos los recursos que conforman el clúster de contenedor, como las instancias de procesamiento, los discos y los recursos de red.
gcloud container clusters delete asm-ready
Próximos pasos
Obtén más información sobre las tecnologías que se usan en este instructivo:
Obtén más información sobre las herramientas:
- CLI de gcloud
- Referencia de
gcloud
kubectl
docker
Obtén más información sobre los conceptos de Kubernetes: