martes, 31 de octubre de 2017

Usando Ingress en Google Container Engine


Viene de Medium power by Christopher Grant

En este artículo, se cubren una variedad de desafíos a la que se enfrenta  y que soluciones que descubrió al implementar una aplicación real en un clúster Global utilizando el controlador de Ingress GCE. 

Ha cubierto cómo configurar Global Kubernetes en 3 pasos en un artículo separado. Este artículo se centrará en cómo usarlo una vez que esté configurado. En la parte 1, se discutiren los conceptos, y en la parte se realizara una implementación de extremo a extremo con código real.

Contenido:
- Ejemplo simple
- Variaciones
- IP global
- Anotaciones
- Chequeo Health
- Tipo de puerto de nodo y puerto
- Contextos de ruta
- Clúster Equilibrado


Tener varios servicios desplegados que responden bajo un nombre de dominio es una práctica común en aplicaciones más grandes. Con Kubernetes puede exponer Implementaciones como Servicios independientes, utilizando ClusterIPs, NodePort y LoadBalancers. También puede exponer múltiples servicios como una sola entidad virtual utilizando recursos de Ingress.

En teoría, los recursos de Ingress son sencillos y fáciles de usar, pero en la práctica puede haber una curva de aprendizaje más empinada. En este artículo, repasaremos los conceptos básicos de la creación de recursos de Ingress y algunas peculiaridades que se encontraran en la vida real.


Ejemplo simple

Hay tres recursos principales involucrados en este proceso: el despliegue, su servicio y el Ingress en sí. Veamos una simple entrada de Hello World.

De la documentación de Kubernetes para el recurso Ingress, podemos ver muchos de los elementos clave

Ejemplo de  Ingress en formato Yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80

Solo cubriendo lo que está aquí, cualquier solicitud para alojar foo.bar.com será procesada por las reglas contenidas en ese bloque, foo.bar.com/foo enrutará al servicio s1 en el puerto 80, solicitudes a foo.bar.com/bar dirigirá al servicio s2 en el puerto 80.


Variaciones no enumeradas explícitamente en los documentos

Para todos los host

Si no desea tratar con el nombre de host, puede eliminar el valor de host y solo se evaluarán las reglas de ruta para todos los hosts / IP.

Ejemplo de uso

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80

Backend predeterminado

Los documentos muestran una opción de Ingress de Servicio Único y sin reglas. Puede combinar esto con las reglas de ruta para definir su propio back-end predeterminado con reglas adicionales.

Vamos al ejemplo.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  backend:
    serviceName: testsvc
    servicePort: 80
  rules:
  - http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80


Aquí cualquier solicitud a este Ingress con / foo con ir al servicio s1, cualquier solicitud para / bar se enrutará a s2, y todos los demás se enviarán a testsvc

Es importante tener en cuenta que si no define un back-end predeterminado, Kubernetes creará uno detrás de la escena. Además, el backend creado para usted solo existe en un clúster. Lo verá cuando consulte los desarrollos de carga del backend en GCP más adelante.


IP Global

Este es otro punto importante para el Ingress global. Necesitarás crear y usar explícitamente una IP global de Google. Las IP efímeras predeterminadas creadas son solo regionales y no podrán admitir servicios de back-end de diferentes regiones.

Pasé mucho tiempo con esto, NO TE DESPISTES

Desde la línea de comando crea una IP global

gcloud compute addresses create ingress-ip --global

Luego, en tu ficherio ingress.yaml.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    kubernetes.io/ingress.global-static-ip-name: ingress-ip      
    ingress.kubernetes.io/rewrite-target: /
spec:
  backend:
    serviceName: testsvc
    servicePort: 80
  rules:
  - http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80


Anotaciones en el Ingress

En la sección de metadatos de la definición de Ingress se pueden proporcionar varias anotaciones para ayudar a  kubernetes a comprender mejor sus intenciones.

Controlador de Ingress

Dependiendo de dónde y cómo despliegues kubernetes, puedes elegir qué ejecutará realmente en la definición de ingress yaml que proporciones. Muchos de los documentos se refieren a nginx como el controlador de ingreso, pero para este ejemplo mostraré cómo usar GCE nativo.

Aunque no es obligatorio, es una buena práctica agregar una anotación que indique qué controlador está intentando usar. Esto es útil si hay múltiples opciones dentro de un entorno dado como ejemplo

Como quiero usar GCE para este controlador de Ingress, lo especificaré explícitamente usando la anotación kubernetes.io/ingress.class: “gce” 
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
     kubernetes.io/ingress.class: "gce"
    ingress.kubernetes.io/rewrite-target: /
spec:
  backend:
    serviceName: testsvc
    servicePort: 80
  rules:
  - http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80


Chequeos health

De manera predeterminada, el Ingrees configurará las comprobaciones de estado de loadblancer al hacer ping en la raíz de su servicio. Es importante saber esto en caso de que elija no enrutar "/" en su servicio. Para garantizar que su aplicación registre su estado de health correctamente, proporcione una ruta "/" o configure las sondas Liveness and Readiness para sus necesidades.

Terminé simplemente dejando el contexto root en la aplicación por simplicidad

NodePort

Aquí hay otro elemento que tiene sentido después de trabajarlo. En primer lugar, utilizar el controlador de Ingress GCE requiere un servicio expuesto con NodePort, no puede ser solo ClusterIP. 
En segundo lugar, cuando se despliega en un clúster federado, los puertos de nodo para su contenedor deben ser los mismos en todos los clústeres, por lo que debemos definirlo explícitamente. De forma predeterminada, cada contenedor proporcionaría un puerto aleatorio para el tipo NodePort, pero en un modelo federado, necesitamos que sean iguales para que la verificación de estado sea precisa. Una vez en funcionamiento, verá el chequeo de health consultando el mismo puerto en todos los nodos de su aplicación.

Para definir esto, en la definición del servicio para nuestra implementación, especificaremos los valores exactos que queremos. Aquí hay un ejemplo


apiVersion: v1
kind: Service
metadata:
  name: s1
  labels:
    app: app1
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30041
  selector:
    app: app1


Tendrá que definir un puerto de nodo diferente para cada servicio para que no haya colisiones


Contextos de ruta

Este fue probablemente el problema más complicado al que me enfrenté y solo lo cree con una aplicación real. Hasta ahora, todas las aplicaciones demos y hello world han funcionado bien. / foo rutas a svc1, y / bar a svc2. Cuando desplegué una aplicación real, sin embargo, las cosas no fueron tan claras. 
Me gustaría obtener la página principal para mis servicios, pero todo lo demás volvería al equilibrador de carga predeterminado. Vamos a descubrir que hay una [peculiaridad con ingress] 

(https://github.com/kubernetes/contrib/issues/885) porque los controladores de ingress Nginx y GCE no funcionan igual.

Básicamente en Nginx / foo está buscando cualquier cosa con un prefijo de / foo donde el controlador gce lo vea como un mapeo explícito. Para solucionar esto, necesitamos agregar * mapeos a nuestras rutas de reglas en el ingress.yaml de la siguiente manera:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
     kubernetes.io/ingress.class: "gce"
    ## ingress.kubernetes.io/rewrite-target: /
spec:
  backend:
    serviceName: testsvc
    servicePort: 80
  rules:
  - http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /foo/*
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80
      - path: /bar/*
        backend:
          serviceName: s2
          servicePort: 80


Al agregar las asignaciones adicionales, cualquier solicitud para /foo o /foo/baz/bar se enrutará correctamente al servicio s1 y las solicitudes para /bar o /bar/baz /foo se enrutarán al servicio s2


Cluster Balancing

En la mayoría de los casos, kubernetes intentará equilibrar los clústeres para que las aplicaciones se distribuyan uniformemente entre los clusters, pero puedes reflejar sus intenciones usando 
federation.kubernetes.io/deployment-preferences:: usando de la siguiente manera

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app1
spec:
  replicas: 4
  template:
    metadata:
      annotations:
        federation.kubernetes.io/deployment-preferences: |
          {
            "rebalance": true,
            "clusters": {
              "east-cluster": {
                  "minReplicas": 1
              },
              "west-cluster": {
                  "minReplicas": 1
              }
            }
          }
      labels:
        app: app1
    spec:
      containers:
        - name: app1
          image: myrepo/appi:v7
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 100Mi



Las anotaciones anteriores le piden a los kubernetes que reequilibren y mantengan un mínimo de una réplica en el este y un mínimo de una réplica en el oeste.

Conclusión

Los controladores de ingreso de Kubernetes son una herramienta poderosa. Con poco conocimiento adicional, se convierten en un recurso simple para administrar también. La utilización del tipo de controlador GCE le permite implementar la entrada rápida y fácilmente en Google Container Engine sin necesidad de recursos adicionales.
Espero que esto haya sido útil y asegúrese de consultar la guía de instalación y la demostración de principio a fin.


lunes, 30 de octubre de 2017

GCP productos de Google Cloud en 4 palabras o menos



Viene de medium Greg Wilson

Google Sheet | PDF | High-res image | GCP Products Page | Tweet
Machine Learning
Cloud Machine Learning Engine -- Gestion ML (TensorFlow)
Cloud Job Discovery -- ML Job Búsquedas y Descubrimiento
Cloud Natural Language -- Parsea y analiza texto
Cloud Speech -- convierte la voz en texto
Cloud Translation -- Deteción y traducción del lenguaje
Cloud Vision -- Reconocimiento y clasificación de imagenes
Cloud Video Intelligence -- Niven de escena y anotaciones de video
  
 
Internet of Things 
Cloud IoT Core -- Data Gestion de Ingestion/Device 
  
 
Big Data  
BigQuery -- Guarda y analiza Datos
Cloud Dataflow -- Dato Streaming Stream/batch 
Cloud Dataproc -- Gestión Spark and Hadoop
Cloud Datalab -- Visualiza y Esplora datos
Cloud Dataprep -- Tranforma/limpia datos en crudo
Cloud Pub/Sub -- Mensajes en tiempo real Globales
Genomics -- Plataforma de Genomica
Data Studio -- Pizarras colaborativas
  
Databases  
Cloud SQL -- Gestiona MySQL and PostgreSQL
Cloud Bigtable -- HBase base no relacional
Cloud Datastore -- Escala base no relacionales
Cloud Spanner -- Escala horizontal de datos
  
Storage  
Cloud Storage -- Guarda y sirve objetos
Nearline -- Almacen de Archivos
Coldline -- Almacen frio de Archivos
Persistent Disk -- Discos para pinchar en VM
  
Data Transfer
Google Transfer Appliance -- Hard para mirgracion
Cloud Storage Transfer Service -- Trafiere de cloud a cloud
BigQuery Data Transfer Service -- Analitica de datos
  
Compute  
Compute Engine -- çMaquinas virtuales, red y disco
App Engine -- Plataforma de gestion de aplicaciones
Container Engine -- Gestion Kubernetes/Contenedores
Cloud Functions -- Aplicaciones sin servidor
  
Networking  
Virtual Private Cloud -- Define la red con sotfware
Cloud Load Balancing -- Distrivucion de red internacional
Cloud CDN -- Content Delivery Network
Cloud DNS -- Servicios de DNS
Dedicated Interconnect -- Red privada dedicada
IPsec VPN -- Conexion privada de VPN
Direct Peering -- Peer with GCP
Carrier Peering -- Peer with a carrier
  
 
Identity and Security
Cloud IAM -- Control de acceso a recursos
Cloud Identity-Aware Proxy -- Identifica y firma los datos
Cloud Data Loss Prevention API -- Clasifica Datos
Cloud Key Management Service -- Servicio de gestion de claves
Cloud Resource Manager -- Gestiona el Cloud
Cloud Security Scanner -- Scaner de seguridad de app engine
Security Key Enforcement -- Verificacion en dos pasos
  
 
Management Tools 
Stackdriver Monitoring -- Monitorizacion de infraestructura y dasot
Stackdriver Logging -- Login centralizado
Stackdriver Error Reporting -- Reportes de errores de App
Stackdriver Trace -- App Performance Insights
Stackdriver Debugger -- Live Production Debugging
Cloud Deployment Manager -- Gestion de plantillas
Cloud Console -- WConsola de gestion web
Cloud Shell --  Terminal/CLI en navegador
Cloud Mobile App -- apliacion de gestion desde iOS/Android
Cloud Billing API -- Gestion de uso y pagos
Cloud APIs -- Servicio de APIs de cloud
  
 
Developer Tools   
Cloud SDK -- CLI for GCP
Container Registry -- Registra/guarda repositorio privado containers
Container Builder -- Construye y packetiza containers
Cloud Source Repositories -- Repositorios de GIT
Cloud Tools for Android Studio --Herramietas Android Studio GCP
Cloud Tools for IntelliJ -- Herramientas IntelliJ GCP
Cloud Tools for PowerShell -- Herramientas PowerShell GCP
Cloud Tools for Visual Studio --Herramintas Visual Studio GCP
Cloud Tools for Eclipse -- Herramintas Eclipse GCP
Gradle App Engine Plugin -- Gradle App Engine Plugin
Maven App Engine Plugin -- Maven App Engine Plugin
  
 
API Platform and Ecosystems 
Apigee API Platform -- Desarrolla, seguriza y monitoriza APIs
Apigee Sense -- Protege y seguriza tus API
API Monetization -- Monetiza APIs
API Analytics -- Metricas API
Cloud Endpoints -- Cloud API Gateway
  
 
Mobile (Firebase) 
Realtime Database -- Sincroniza datos en tiempo real
Cloud Firestore -- Guarda y sincroniza ficheros
Cloud Storage -- Guarda y publica Ficheros
Hosting -- Web Hosting con CDN/SSL
Authentication -- Gestiona Authenticacion
Cloud Functions -- Gestiona eventos sin servidores
Test Lab for Android -- Testea dispositivos moviles
Performance Monitoring -- App Performance Monitoring
Crashlytics -- Reporta y analiza Crash
Cloud Messaging -- Manda mensajes a dispositivos
See all Firebase products

miércoles, 25 de octubre de 2017

VPN Google Cloud <-> Mikrotik router



Cada vez disponemos de mejores routers y mas ancho de banda, es lógico que optemos por una conexión mas segura y potente con nuestro Google Cloud.

Es muy recomendable de hecho para mi se obligatorio pensar en establecer una conexión directa con esa nube.  Un fantastico Router ademas de no ser muy caro es n Microtick en donde podemos configurar para la conexión con Google cloud VPN.

Para conectar google cloud a través de VPN a un router microtik:
La formula para verificar que todo funciona pasa por crear una instancia en cualquier región que desees e inicia esto (f1-micro sobra, solo para hacer ping y ssh para confirmar que todo está funcionando)

Cree una VPN en la misma región, ingrese su IP externa conectada al router  microtik

La red remota es su subred ipv4 local en la página microtik del vpn y selecciona las subredes en la nube como rangos de IP local.

Luego, vamos a la nube de la red> al entorno de la nube de google y hacemos clic en crear
El nombre, la descripción, la región (similar a su instancia) que completamos, la red es probablemente la predeterminada y la dirección IP en la que hacemos clic en crear. Google emite una IP publica desde su pool, por ejemplo: 4.3.2.1

En el túnel, la IP remota de su router externo puede tener la ip que le entrega su operador por ejemplo : 1.2.3.4  ademas hay que creat un secreto para compartir. 

También tenemos que usar las ips locales  por ejemplo  utilizamos 192.168.1.0/24 como ejemplo y usted elige una red local donde a configurado su VM que puede ser una subred local como  10.132.0.0/20.

En el microtik:


/ip ipsec proposal
add name=google auth-algorithms=sha1 enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc lifetime=3h pfs-group=modp1024
/ip ipsec peer
add address=4.3.2.1 enc-algorithm=aes-256,aes-192,aes-128,3des exchange-mode=ike2 hash-algorithm=sha512 secret=CONTRASENA_SUPERSECRETA
/ip ipsec policy
add dst-address=10.132.0.0/20 sa-dst-address=4.3.2.1 sa-src-address=1.2.3.4 src-address=192.168.1.0/24 tunnel=yes proposal=google
/ip firewall nat
add chain=srcnat action=accept place-before=0 src-address=192.168.1.0/24 dst-address=10.132.0.0/20

Si te gusta mejor la descripción conceptos. la formula es: (debes poner la ip correspondiente en cada tipo)

//ip ipsec proposal
add name=google auth-algorithms=sha1 enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc lifetime=3h pfs-group=modp1024
/ip ipsec peer
add address=$Google-public-ip enc-algorithm=aes-256,aes-192,aes-128,3des exchange-mode=ike2 hash-algorithm=sha512 secret=$CONTRASENA_SUPERSECRETA
/ip ipsec policy
add dst-address=$Google-local-subnet-in-cidr sa-dst-address=$Google-public-ip sa-src-address=$Mikrotik-public-ip src-address=$Mikrotik-public-ipv4-in-cide tunnel=yes proposal=google
/ip firewall nat
add chain=srcnat action=accept place-before=0 src-address=$Mikrotik-public-ipv4-in-cide dst-address=$Google-local-subnet-in-cidr

Esto debería permitir que tu Mikrotik se conecte a Google Cloud. para probarlo haces un  ping a su instancia y de tambien puede hacer inicio de sesión utilizando ssh para confirmar usan las ip locales.

martes, 24 de octubre de 2017

Google Cloud Launcher [Soluciones de código Abierto]


Soluciones de open source en Google Cloud Launcher.


La implementación de soluciones de open source en el cloud generalmente implica mucho trabajo para mantenerse al día con las revisiones de seguridad y las actualizaciones de las versiones.

En la Consola de de Google Cloud están implementado la opción de Cloud Launcher  que brinda soluciones de nivel de producción que puede iniciar y administrar con solo unos pocos clics, y las soluciones de "Click To Deploy" reducen aún más los costos operacionales con los productos de código abierto que mantiene Google.


Las soluciones de Click To Deploy son instalaciones idénticas a las que usted mismo instala. Cuando se detecta una vulnerabilidad crítica, se configura y monta y ofrecemos una solución actualizada lo antes posible.
Los clientes existentes también reciben una notificación para actualizar su imagen. Los clientes de Google Cloud dicen que les encanta la facilidad y simplicidad de las soluciones de Click To Deploy, y han se puede   confiar en nuestra puntualidad de los partches para ayudar a mantenerse seguros.

Hoy Google ha lanzado 21 nuevas soluciones de VM para algunos de los productos de código abierto más populares:


  • Apache Solr
  • Comunidad Alfresco
  • Pila Django
  • Dokuwiki
  • Drupal
  • Fantasma
  • Jenkins
  • Joomla!
  • Kafka
  • PostgreSQL
  • Magento
  • Moodle
  • MySQL
  • Nginx
  • Node.js
  • Piwik
  • PrestaShop
  • Redmine
  • Ruby Stack
  • Gato
  • WordPress Multisite


No hay costo adicional para usar Click to Deploy soluciones más allá del costo de la infraestructura. Consulte el catálogo completo de las soluciones de Click To Deploy para Cloud Launcher, y si es nuevo en Google Cloud Platform (GCP), comience con un crédito de $ 300 por 12 meses.

jueves, 19 de octubre de 2017

Estaremos en el primer CloudFest.



El Viernes 3 de Noviembre estaremos en el primer #CloudFest que celebra el GDG Cloud Madrid, así que no faltes y nos vemos en el evento.

Si estas por Madrid y te gusta o usas el mundo Cloud no puedes faltar a este evento que hacemos en nuestro grupo gdg cloud, que se realiza en "Campus Madrid" y no puedes faltar.

Mejora el soporte de google cloud para español


Google esta mejorando el soporte que ofrece en su web oficial  en español y para muestra os pasamos el link por donde podeis acceder a los recursos en español de su web. 
Esta claro que google tiene en mente a la comunidad hispana y esta prestando atención a que la barrera de idioma no sea un problema. Todavía falta mucho para encontramos todo el material en Español pero estamos seguros del esfuerzo para ampliar cada día mas el soporte en idiomas de la plataforma.

Explora a fondo la programación mediante estos ejemplos donde se muestra cómo utilizar algunos de los productos y funciones de GCP más eficaces y populares.
Tutoriales breves que te servirán de introducción a los productos, servicios y APIs de Cloud Platform

En estos tutorial aprenderás los conceptos básicos de cuatro servicios de Google Cloud Platform que se usan frecuentemente. El coste de los recursos del tutorial es de aproximadamente 15 centavos, que se facturarán en tu cuenta o se descontarán del crédito de 300 $ de tu versión de prueba gratuita. La consola de Google Cloud Platform se ejecuta en todos los dispositivos.

Tutoriales breves que te servirán de introducción a los productos, servicios y APIs de Cloud Platform.

miércoles, 18 de octubre de 2017

Kubernetes monitoring with Prometheus in 15 minutes


Si no ha oído hablar de Kubernetes (o su nombre comúnmente conocido K8s), es hora de salir de su cueva. K8s es una plataforma de auto-gestión de código abierto para desplegar, escalar y operar contenedores. Originalmente diseñado por Google (inspirado por Borg) y luego donado a la CNCF.

Comprender todos los componentes de k8s no es trivial, lleva tiempo tener un control total en una plataforma tan sofisticada y poderosa. También es importante darse cuenta de que los nodos, aplicaciones o redes pueden fallar en un momento particular, como todo en TI. Por lo tanto, tener alertas, registros, métricas y paneles de supervisión es fundamental para evitar interrupciones y otros problemas.

Durante mi último proyecto, pasando del baremetal a la nube, tuve tiempo de investigar el monitoreo proactivo con k8s. Después de algunos puntos de referencia y golpeando mi cabeza contra la pared, finalmente encontré a Prometheus. El proyecto k8s ya ha adoptado esta asombrosa herramienta, exponiendo las métricas de Prometeo en casi todos los componentes.

La supervisión de su clúster k8s ayudará a su equipo a:
  • Monitoreo proactivo
  • Visibilidad del clúster y planificación de capacidad
  • Activar alertas y notificaciones
  • Tableros de métricas


Durante el tiempo que estaba investigando sobre cómo Prometheus se integra con k8s, Coreos lanzó Prometheus-Operator; Se ajusta perfectamente a mis necesidades, facilitando la configuración de toda la instalación.

Operador Kubernetes

"Llamamos a esta nueva clase de Operadores de software. Un operador es un controlador específico de la aplicación que extiende la API de Kubernetes para crear, configurar y administrar instancias de aplicaciones complejas con estado en nombre de un usuario de Kubernetes. Se basa en los conceptos básicos de recursos y controladores de Kubernetes, pero incluye el dominio o el conocimiento específico de la aplicación para automatizar tareas comunes ".
Brandon Philips, de Coreos

Los operadores de Kubernetes fueron introducidos por Coreos en 2016, y tiene el poder de resumir implementaciones y configuración de aplicaciones. En una nota personal, he estado usando una gran cantidad de operador elasticsearch-operador y prometheus. No es el objetivo de este artículo extenderse en los operadores de k8, pero si estás interesado puedes ver a otros operadores de k8 aquí.


Prometeo


Prometheus es un tookit de herramientas de código abierto para monitorear y alertar, inspirado en Google Borg Monitor. Fue previamente desarrollado por SoundCloud y luego donado a la CNCF.

Prometheus tiene soporte para la aplicación de instrumentos en muchos idiomas. También brinda a los exportadores la conexión de aplicaciones (Postgresql, Mysql, AWS Cloudwatch, ETCD y K8), al tiempo que sigue siendo una excelente solución para monitorear la infraestructura y las aplicaciones.

Operador de Prometheus

La misión del Prometheus Operator es hacer que ejecutar Prometheus encima de Kubernetes sea lo más fácil posible, a la vez que preserva la configurabilidad y hace que la configuración sea nativa de Kubernetes. https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html

El Operator Prometheus proporciona una supervisión sencilla para los servicios y las implementaciones de k8 además de la configuración de Prometheus, Alertmanager y Grafana.


¿Como funciona?


Cuando implementa una nueva versión de su aplicación, k8s crea un nuevo pod (contenedor) y después de que el pod está listo, k8s destruye el anterior. Prometheus está en una vigilancia constante, mirando el k8s api y cuando detecta un cambio crea una nueva configuración de Prometheus, basada en los cambios de los servicios (pods).

ServiceMonitor

Operator-prometheus utiliza una Definición de recursos personalizados (CRD), denominada ServiceMonitor, para abstraer la configuración al destino. Como ejemplo a continuación, veamos cómo monitorear un pod NGINX con ServiceMonitor. El ServiceMonitor seleccionará el pod NGINX, usando el selector matchLabels. El operator-prometheus buscará los pods en función del selector de etiquetas y creará un objetivo prometheus, por lo que prometheus raspará el punto final de métricas.



apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
namespaceSelector:
matchNames:
- default
endpoints:
- port: web
interval: 30s


Inténtalo tú mismo

Este tutorial se puede ejecutar en menos de 15 minutos, como registro que ya tiene:
  • Kubernetes en cluster y corriendo
  • Helm está instalado y funcionando
  • helm list

Instalación


1.Cree un nuevo espacio de nombres, clone el repositorio git prometheus-operator
kubectl create ns monitoring
git clone git@github.com:coreos/prometheus-operator.git
cd prometheus-operator

2. Instalar y delpliege prometheus-operator
helm install --name prometheus-operator --set rbacEnable=true --namespace=monitoring helm/prometheus-operator

3. Instale las especificaciones de Prometheus y Alertmanager y la implementación de grafana.
helm install --name prometheus --set serviceMonitorsSelector.app=prometheus --set ruleSelector.app=prometheus --namespace=monitoring helm/prometheus
helm install --name alertmanager --namespace=monitoring helm/alertmanager
helm install --name grafana --namespace=monitoring helm/grafana

4. Instale kube-prometheus para cargar exportadores y serviceMonitors predefinidos de k8s.
helm install --name kube-prometheus --namespace=monitoring helm/kube-prometheus

Suponiendo que todo esté bien, puede ejecutar el siguiente comando para enumerar las aplicaciones que veremos más a fondo en la próxima sesión.
$ kubectl get pods -n monitoring
NAME                                                      READY     STATUS    RESTARTS   AGE
alertmanager-alertmanager-0                               2/2       Running   0          3m
grafana-grafana-3066287131-brj8n                          2/2       Running   0          4m
kube-prometheus-exporter-kube-state-2696859725-s8m56      2/2       Running   0          3m
kube-prometheus-exporter-node-029w0                       1/1       Running   0          3m
kube-prometheus-exporter-node-n3txz                       1/1       Running   0          3m
kube-prometheus-exporter-node-q2rk3                       1/1       Running   0          3m
prometheus-operator-prometheus-operator-514889780-qm3fp   1/1       Running   0          4m
prometheus-prometheus-0                                   2/2       Running   0          3m

Prometeo

Reenvíe el servidor Prometheus a su máquina para que pueda ver mejor el dashboard abriendo http: // localhost: 9090
kubectl port-forward -n monitoring prometheus-prometheus-0 9090




En el panel Prometheus, puede: consultar las métricas, ver todas las alertas predefinidas y los destinos Prometheus.

Nota: Si algunos objetivos están cayendo con un error inalcanzable, verifique las reglas del grupo de seguridad o firewall. Si no tiene los mismos objetivos que la imagen de arriba, consulte las etiquetas de sus pods de k8s, a veces la herramienta que utilizó para implementar el cluster no sigue los patrones de etiquetas de k8s.

Nota 2: El proyecto prometheus-operator está trabajando para proporcionar alertas predeterminadas para k8s empaquetadas en un gráfico de helm. Por ahora, ejecute los siguientes comandos para cargar las reglas de alerta. En el futuro, este comando no será exigido.

sed -ie 's/role: prometheus-rulefiles/app: prometheus/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/prometheus: k8s/prometheus: prometheus/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/job=\"kube-controller-manager/job=\"kube-prometheus-exporter-kube-controller-manager/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/job=\"apiserver/job=\"kube-prometheus-exporter-kube-api/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/job=\"kube-scheduler/job=\"kube-prometheus-exporter-kube-scheduler/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
sed -ie 's/job=\"node-exporter/job=\"kube-prometheus-exporter-node/g' contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml
kubectl apply -n monitoring -f contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml

Grafana


Prometheus tiene un navegador de expresiones para el propósito de depuración. Para tener un tablero atractivo, use Grafana, tiene una fuente de datos lista para consultar en Prometheus.

Nota: El proyecto prometheus-operator está funcionando para proporcionar un despliegue fácil para Grafana, probablemente usando un nuevo CRD. Por ahora, ejecute los siguientes comandos para configurar y cargar los paneles. En el futuro, este comando no será necesario.

sed -ie 's/grafana-dashboards-0/grafana-grafana/g' contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml
sed -ie 's/prometheus-k8s.monitoring/prometheus-prometheus.monitoring/g' contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml
kubectl apply -n monitoring -f contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml
kubectl port-forward -n monitoring $(kubectl get pods --selector=app=grafana-grafana -n monitoring --output=jsonpath={.items..metadata.name})  3000

Espere unos segundos hasta que grafana cargue los paneles, abra su navegador en http: // localhost: 3000 para ver su impresionante dashboard nuevo !!!

Grafana - Tableros Kubernetes

Grafana - Tablero de planificación de capacidad de Kubernetes

Alertmanager

Alertmanager maneja alertas enviadas por aplicaciones cliente como el servidor Prometheus. Se ocupa de desduplicar, agrupar y enrutarlos a la integración correcta del receptor, como correo electrónico, PagerDuty u OpsGenie. También se ocupa del silenciamiento y la inhibición de alertas.

Ya instalamos Alertmanager, ahora el comando a continuación, para reenviar el puerto a su máquina y abrir la URL http: // localhost: 9093 en su navegador
kubectl port-forward -n monitoring alertmanager-alertmanager-0 9093