Docker y Kubernetes - Evolución tecnológica

En este decí repasaremos como docker y Kubernetes nos ayudan a dar el paso siguiente en nuestra evolución de soluciones tecnologicas.

Transcript

1. IasCode Containers and Kubernetes Entender para poder extender ;)
2. Agenda • Estandarizar! • VM, Contenedor, Pod y VM (?). • Orquestar Pods, Kubernetes. • Desplegar Apps, Templates. • Redes en Kubernetes, SDN.
3. Estandarizar!
4. Historia del transporte Contenedor unimodal Malcom McLean* Antes Después • Transporte dedicado para un propósito • Transporte de diferentes se vuelve costoso • No estandarizado, desordenado Estandariza el proceso de transporte! • Autosustentable • Isolado • Estandarizado • El transporte se prepara para transportar contenedores esto permite que camiones, barcos o aviones pueden transportar lo mismo, un contenedor. *https://en.wikipedia.org/wiki/Malcom_McLean
5. Estandarizar Estructura IT Tradicional Dos o más equipos de trabajo separados Desarrolladores y Operaciones Desarrollo Trabajan en el software, lo desarrollan, aseguran que trabaje correctamente. Horas de trabajo sobre prueba-error, liberan una nueva versión del código. Hardware & Software. • Ubuntu Linux • PHP5 • Procesador i7 • 8 GB RAM • Disco SSD OK! Operaciones Responsable del nuevo release y la operación del código Realizará chequeos de la aplicación, su rendimiento y reportará los bugs. Hardware & Software. • Red Hat Enterprise Linux • PHP7 • Procesador Xeon • 16 GB RAM • Disco SAS Fail!
6. Estandarizar Estructura Moderna Estandarizar el hardware y framework para reducir errores en la corrida. Identicas caracteristicas Desarrollo Trabajan en el software, lo desarrollan, aseguran que trabaje correctamente. Horas de trabajo sobre prueba-error, liberan una nueva versión del código. Hardware & Software. • Ubuntu Linux • PHP5 • Procesador i7 • 8 GB RAM • Disco SSD OK! Operaciones Responsable del nuevo release y la operación del código Realizará chequeos de la aplicación, su rendimiento y reportará los bugs. Hardware & Software. • Ubuntu Linux • PHP5 • Procesador i7 • 8 GB RAM • Disco SSD OK!
7. VM, Contenedor, POD y VM(?)
8. Evolución Tecnológica Virtualización Hardware Físico OS Hardware Físico Hipervisor Hardware Virtual OS Hardware Virtual OS WEB DB WEB Hardware Físico o Virtual Hipervisor Hardware Virtual OS Container Runtime Hardware Virtual OS Container Runtime WEB DB Hardware Físico o Virtual Hipervisor Hardware Virtual OS Container Runtime Hardware Virtual OS Container Runtime Hardwar e Virtual OS WEB Hardwar e Virtual OS DB Aplicación sobre hardware físico POD APP PROX Y
9. Evolución Tecnológica Virtualización Hardware Físico OS Hardware Físico Hipervisor Hardware Virtual OS Hardware Virtual OS WEB DB WEB Hardware Físico o Virtual Hipervisor Hardware Virtual OS Container Runtime Hardware Virtual OS Container Runtime WEB DB Aplicación sobre hardware físico Aplicación sobre VM. VM corre sobre hypervisor. Hypervisor sobre hardware físico. Hardware Físico o Virtual Hipervisor Hardware Virtual OS Container Runtime Hardware Virtual OS Container Runtime Hardwar e Virtual OS WEB Hardwar e Virtual OS DB POD APP PROX Y
10. Evolución Tecnológica Virtualización Hardware Físico OS Hardware Físico Hipervisor Hardware Virtual OS Hardware Virtual OS WEB DB WEB Hardware Físico o Virtual Hipervisor Hardware Virtual OS Container Runtime Hardware Virtual OS Container Runtime WEB DB Aplicación sobre hardware físico Aplicación sobre VM. VM corre sobre hypervisor. Hypervisor sobre hardware físico. Aplicación en container. Container Runtime corre sobre VM. VM corre sobre hypervisor. Hypervisor sobre hardware físico. Hardware Físico o Virtual Hipervisor Hardware Virtual OS Container Runtime Hardware Virtual OS Container Runtime Hardwar e Virtual OS WEB Hardwar e Virtual OS DB POD APP PROX Y
11. Evolución Tecnológica Virtualización Hardware Físico OS Hardware Físico Hipervisor Hardware Virtual OS Hardware Virtual OS WEB DB WEB Hardware Físico o Virtual Hipervisor Hardware Virtual OS Container Runtime Hardware Virtual OS Container Runtime WEB DB Hardware Físico o Virtual Hipervisor Hardware Virtual OS Container Runtime Hardware Virtual OS Container Runtime Hardwar e Virtual OS WEB Hardwar e Virtual OS DB Aplicación sobre hardware físico Aplicación sobre VM. VM corre sobre hypervisor. Hypervisor sobre hardware físico. Aplicación en container. Container Runtime corre sobre VM. VM corre sobre hypervisor. Hypervisor sobre hardware físico. Aplicación en VM. VM en Container. Container Runtime corre sobre VM. VM corre sobre hypervisor. Hypervisor sobre hardware físico. https://kubevirt.io/ POD APP PROX Y
12. POD Evolución Tecnológica Virtualización Containers Mayor portabilidad más liviano que una VM Hardware Físico Hardware Físico o Virtual Hipervisor Hardware Virtual Container Engine Notebook Container Engine APP dev OS Container Engine DB APP-2 APP-1 OS Container Engine Hardware Virtual OS Container Engine APP-3 APP-4 Containers LIBs+APP Apps y solo las librerías necesarias Que separa un contenedor de otro?. 7 Niveles de aislación 1. IPC, Communicate over share memory. 2. Network, Network device, stacks, ports. 3. UTS, Hostname and NIS domain name. 4. Cgroups, Resource protection. 5. Mount - Mount points, mapeo de directorios 6. PID, Process IDs 7. User, User and groups IDs. APP PROXY Un pod pude contener uno o más contenedores, la particularidad es que comparten IPC, Network, UTS.
13. Evolución Tecnológica Network Containers Hardware OS - Server1 Docker Engine 1. Cada contenedor tiene su propia interfaz de red e ip. Un network namespace permite la comunicación entre pods. 2. Todos los contenedores se conectan de manera virtual a un linux bridge docker0. 3.El docker bridge posee una patch virtual a la interfaz de red física eth0 como un trunk. 4.Cada servidor se conecta a un switch físico. 5.Cada contenedor expone un puerto que es mapeado a un puerto de la placa física del servidor. Container ip:port -> Físico ip:port 172.0.0.2:80 -> 192.168.0.2:8080 172.0.0.3:80 -> 192.168.0.2:8080 → No es posible, no se pueden pisar puertos!!!. Bridge docker0 Ubuntu eth0 Ubuntu eth0 RHEL eth0 eth0 Networking Switch Hardware OS - Server2 Docker Engine Bridge docker0 Ubuntu eth0 eth0 172.0.0.2 172.0.0.3 172.0.0.4 172.0.0.2 192.168.0.2 192.168.0.3 172.0.0.1 172.0.0.1 $ docker network ls NETWORK ID NAME DRIVER SCOPE 695a2f989bd9 bridge bridge local b2540f45cbf1 host host local d2ea295d108c none null local $ docker network inspect 695a2f989bd9 [ { "Name": "bridge", "Id": "695a2f989bd9286f2ca649735e7c5fd3b34e4f90453f2db63 a00c87495f19a29", ... "Subnet": "172.17.0.0/16" ... "Containers": { "8502fe3ad22b78acf7bd74de82ed226535b3407575670a9f dfe65c5a5bddf297": { "MacAddress": "02:42:ac:11:00:02", "IPv4Address": "172.17.0.2/16",
14. Ordenar Pods, Kubernetes!
15. Kubernetes Container Orquestation Perspectiva Lógica Hardware OS Hardware OS Hardware OS Hardware OS Hardware OS Hardware OS • La orquestación de contenedores ha surgido para ayudar a simplificar y estandarizar como los containers se agrupan y consumen. • Proyecto interno de Google 2014, Borg. 1.0 Release 2015. • Estándar abierto gracias a Google y CNCF. • Kubernetes = k8s • Gran comunidad código abierto. • Auto-scaling, cloud agnostic e integrable con otras tecnologías. Container Engine Container Engine Container Engine Container Engine Container Engine Container Engine Container Orchestration Platform - Kubernetes APP2 APP1 APP3 APP2 APP1 APP3 APP2 APP1 APP3 APP2 APP1 APP3 APP2 APP1 APP3 APP2 APP1 APP3 DEV TEST PROD Datacenter laptop minikube Private Cloud Public Cloud
16. Arquitectura Kubernetes, componentes. Master Master Master APP2 APP1 APP3 APP2 APP1 APP3 APP2 APP1 APP3 APP2 APP1 APP3 APP2 APP1 APP3 APP2 APP1 APP3 DEV TEST PROD Masters son el control plane del cluster de kubernetes. Alojan la metadata del cluster en una base de datos clave valor (etcd). Poseen el servicio de api y scheduller del cluster. Worker Worker Worker Container Orchestration Platform - Kubernetes Workers [Apps e Ingress] Son los nodos que alojarán los pods aplicativos, hay algunos que poseen los pods de ingresos de tráfico de red, a esos se los llama Worker Ingress
17. Perspectiva Logica PODs POD • Elemento básico dentro de Kubernetes es el POD. • Un POD es una abstracción de uno o más containers. • Un POD tiene recursos asociados. -BuildConfig(bc) -DeploymentConfig(dc) -ImageStream(is) -Pod -Service(svc) -Route(ro) -Statefulsets -Ingress -ServiceAccount(sa) -HorizontalPodScale(hpa) -PersistenVolumeClaim(pvc) -Event(ev) Los contenedores comparten: 1. IPC, Communicate over share memory. 2. Network, Network device, stacks, ports. 3. UTS, Hostname and NIS domain name. Los contenedores NO comparten: 4. Cgroups, Resource protection. 5. Mount - Mount points, mapeo de directorios 6. PID, Process IDs 7. User, User and groups IDs.
18. Perspectiva Lógica Namespaces POD Web namespaces POD • Un namespaces es un espacio de trabajo donde el desarrollador puede agrupar sus PODs para poder crear aplicaciones. • Los namespaces pueden ser organizados por ambiente o rol funcional. • Elegir qué componentes forman parte de su aplicación. Ej, db=mysql; app=jboss, web=apache • Elegir qué componente exponer. Ej web=apache Web 172.0.0.3 POD APP 172.0.0.4 POD Web 172.0.0.5 route = http:/ /web-myproject.apps.ocp.domain.com SVC= APP/172.20.64.10 SVC= DB/172.20.74.10 http:/ /web-myproject.apps.ocp.domain.com URI Dinámica Algunos orquestadores de containers pueden brindar el servicio de generación dinámica de url. https:/ /web / SVC = Web/172.20.54.10 pod/web-1 172.0.0.2 svc/web 172.20.54.10 pod/web-2 172.0.0.3 pod/app 172.0.0.4 svc/app 172.20.64.10 pod/db 172.0.0.5 svc/db 172.20.74.10
19. semperti-cerebro-temp.yml semperti-kibana-temp.yml https:/ /github.com/gonzaloacosta/openshift-logging-eck semperti-elasticsearch-temp.yml kubernetes Perspectiva Lógica Templates de despliegues namespace POD kibana 172.0.0.3 POD elasticsearch 172.0.0.4 http:/kibana-semperti-loggin g-eck.apps.semperti.local svc= elasticsearch https:/ /kib ana/ route = kibana svc = kibana #Route - apiVersion: v1 kind: Route metadata: name: ${DEPLOYMENT_NAME}-es labels: app: ${DEPLOYMENT_NAME}-es tier: elasticsearch spec: port: targetPort: web tls: termination: edge to: kind: Service name: ${DEPLOYMENT_NAME}-es wildcardPolicy: None parameters: - name: DEPLOYMENT_NAME value: semperti - name: ES_IMAGE value: docker.io/elasticsearch:2.4.6 POD cerebro 172.0.0.4 svc = cerebro pvc-es apiVersion: v1 kind: Template metadata: name: "semperti-elasticsearch-2.4.6" ... #Deployment: - apiVersion: extensions/v1beta1 kind: Deployment metadata: name: ${DEPLOYMENT_NAME}-es spec: replicas: 1 template: metadata: labels: app: ${DEPLOYMENT_NAME}-es tier: elasticsearch project: ${DEPLOYMENT_NAME} spec: containers: - image: ${ES_IMAGE} imagePullPolicy: Always name: elasticsearch ports: - containerPort: 9200 name: http protocol: TCP #Servicio - apiVersion: v1 kind: Service metadata: name: ${DEPLOYMENT_NAME}-es labels: app: ${DEPLOYMENT_NAME}-es tier: elasticsearch spec: ports: - name: transport port: 9300 protocol: TCP targetPort: 9300 - name: web port: 9200 protocol: TCP targetPort: 9200 selector: app: ${DEPLOYMENT_NAME}-es tier: elasticsearch GitHub
20. Kubernetes DC1 Perspectiva Lógica Multiple namespaces namespace = desa POD kibana 172.0.0.3 POD elasticsearch 172.0.0.4 http:/kibana-semperti-loggin g-eck.apps.semperti.local svc= elasticsearch https:/ /kib ana/ route = kibana svc = kibana POD cerebro 172.0.0.4 svc = cerebro pvc-es https://github.com/../openshift-logging-eck namespace = prod-1 POD kibana 172.0.0.3 POD elasticsearch 172.0.0.4 svc= elasticsearch route = kibana svc = kibana POD cerebro 172.0.0.4 svc = cerebro pvc-es Kubernetes DC2 namespace = prod-1 POD kibana 172.0.0.3 POD elasticsearch 172.0.0.4 svc= elasticsearch route = kibana svc = kibana POD cerebro 172.0.0.4 svc = cerebro pvc-es Despliegue de mismo escenario en distintos clusters
21. Redes en Kubernetes, SDN
22. Kubernetes CNI Container Network Interfaces Link RH: https://docs.openshift.com/container-platform/4.2/networking/understanding-networking.html Kubernetes CNI Kubernetes Openshift Plugins SDN Flannel Plugin Nuage Plugin Essential (Calico) Plugin Contrail (OpenCont rail) Plugin Cisco Plugin Big Switch Plugin VMware NSX-T Plugin Open Daylight Plugin
23. SDN Overview Dispositivos de red • br0: Los pods son conectados a este ovs bridge. • tun0: Para acceso externo via NAT. Gateway de la subred de cluster. Configura netfilter y reglas de ruteo. • Vxlan0: Para acceso a otros nodos. OVS VxLAN device. ◦ Observa las actualizaciones de las subnet desde el master. ◦ Agrega reglas Openflow en br0 y rutea el tráfico hacia las otras subredes de cluster. • eth0 (pod): Cada pod posee una interfaz eth0 que se conecta al br0. Nodo k8s POD POD eth0 eth0 Open vSwitch Bridge Port 1 vxlan Port 2 tun0 Cluster Subnet gateway address
24. Real Network SDN Overview Traffic Flow Nodo1 k8s Cluster Subnet: 10.248.0.0/24 A C br0 Open vSwitch Bridge Port 1 vxlan Port 2 tun0 Nodo2 k8s Cluster Subnet: 10.248.4.0/24 B D br0 Open vSwitch Bridge Port 1 vxlan Port 2 tun0 VxLAN Overlay 10.248.0.2 10.248.4.2 10.248.0.1 10.248.4.1 10.248.0.3 https://docs.openshift.com/container-platform/4.2/networking/openshift-sdn/about-openshift-sdn.html 10.248.4.3 Interfaz física = 10.252.7.20 Interfaz física = 10.252.7.21 10.252.7.0/24 eth0(pod A in netns) -> vethA -[Br0] - vxlan0 - [Network] - vxlan0 - [br0] - vethB - eth0 (pod B in netns) eth0(pod A in netns) -> vethA -[Br0] -> vethB - eth0 (pod C in netns) eth0(pod D in netns) -> vethD -[br0]- tun0 - Real Network Red Real (ssh route): 10.252.7.0/24 Red de Pods (SDN noRoute): 10.248.0.0/14 Subred en Nodo1 (SDN noRoute): 10.248.0.0/24 Subred en Nodo2 (SDN noRoute): 10.248.4.0/24
25. SDN Overview Network Policy • Microsegmentacion - Permite la configuración de políticas a nivel de pod. - Aplica al trafico entrante (ingress) para pods y servicios. - Permite restringir el tráfico entre pods en un namespaces - Permite el tráfico específico desde otros namespaces Namespace Front Frontend Microservice POD PHP Namespace Services Email Microservic e POD MySQL POD Python Kind: NetworkPolicy apiVersion: extension/v1beta1 metadata: name: allow-3306 spec: podSelector: matchLabel: app: mysql ingress: - from: - podSelector: matchLabels: app: emailsvc ports: - protocol: TCP Port: 3306 app: emailsvc app: mysql app: php NetworkPolicy: allow-3306 Permit: TCP 8080 NetworkPolicy: default-deny NetworkPolicy: default-deny NetworkPolicy: allow-8080-front
26. Real Network Ingress Router (Openshift) Traffic Flow Nodo Ingress Nodo Apps https://docs.openshift.com/container-platform/4.2/networking/routes/route-configuration.html Nodo Apps POD POD POD POD myfront.apps.dominio.com Port 80/443 DNS POD Router VxLAN Overlay DNS Resolution Wildcard *.app.ocp-np.sis.ad.bia.itau FQDN: www.dominio.com Pod Router Wildcard: *.app.dominio.com FQDN: www.dominio.com Whitelist • Restringe el acceso a una ruta o ip determinada. • Permitir whitelist ip • Conexiones a otras ips son bloqueadas metada: annotations: haproxy.router.openshift.io/ip_whitelist: 192.168.2.10 192.168.1.12
27. MUCHAS GRACIAS Gonzalo Acosta E-mail Personal: gonzalo.acosta@semperti.com Twitter: @_gonzalo_acosta