Archives

Kubernetes

Kubernetes und Docker: Automatisierung als Schlüsselprinzip für agile Softwareentwicklung

Beitrag von Thomas Wirtz, Pre-sales Director Germany

CIOs stehen heute vor großen Herausforderungen: Einerseits sollen sie Kosten einsparen, andererseits aber auch immer mehr Services auf unterschiedlichen IT-Plattformen bereitstellen und betreuen. Nur mit automatisierten Abläufen wird es möglich, diese Herausforderung zu meistern – denn die IT-Umgebungen insbesondere großer Unternehmen wachsen beständig und die manuelle Verwaltung nimmt zu viel Zeit in Anspruch und verursacht gleichzeitig zu hohe Kosten. An dieser Stelle spielen immer häufiger Cluster Manager, wie beispielsweise Kubernetes, eine wichtige Rolle. Oftmals als Datacenter oder Cloud Betriebssystem bezeichnet, vereinheitlichen sie heterogene Infrastrukturen, darunter selbstverständlich auch Public Clouds. Doch davor steht die Entwicklung von neuer Software, die dann für unterschiedliche Betriebssysteme und in Abhängigkeit von Datenbanken und Systemen getestet werden muss. Container-Technologie und Docker vereinfachen Entwicklern diese Schritte enorm.

Wie arbeiten Entwickler?

Entwickler nutzen in erster Linie Docker-Umgebungen, um Software als Container zu starten und später zu verteilen. Dabei können Anwendungen und komplexe Stacks schnell und trotz unterschiedlicher Betriebssysteme ausgeführt werden, da Docker eine Abstraktionsebene über das Betriebssystem und den darunterliegenden Host legt. So wird es möglich, dass Entwickler beispielsweise eine Linux-Datenbank auf einem Mac- oder Windows-Rechner ausführen können. Konkret bedeutet das, dass ein Entwickler Source Code schreibt und diesen mithilfe einer Beschreibung („Dockerfile&#rsquo;) in ein Docker-Image packt und zentral ablegt („Docker Registry&#rsquo;). Anschließend wird lediglich der Name der Anwendung weitergegeben. Andere Entwickler können dann über Docker das Programm auf ihren jeweiligen Rechnern ausführen – unabhängig vom Betriebssystem. Ein weiterer Vorteil ist, dass alle Abhängigkeiten und die Zielumgebung in dem Docker-Image beschrieben sind, sodass im Betrieb ein vollständiges Paket vorhanden ist und nicht alle einzelnen Abhängigkeiten zusammengestellt werden müssen.

Die Anwendungsentwicklung findet typischerweise zunächst lokal statt – anschließend wird der neue Code getestet und ausgerollt. Aus Gründen der Ausfallsicherheit wird in der Produktion natürlich nicht nur ein Docker-Host, sondern gleich mehrere betrieben – und natürlich werden zeitgleich unüberschaubar viele Docker-Images verschickt und ausgeführt. Um all diese Hosts und Images zu verwalten, benötigen Unternehmen einen Container Cluster Manager. Aktuell gibt es drei prominente Cluster Manager mit flexiblen Deployments (eigenes RZ und/ oder Public Cloud): Docker Swarm, Kubernetes und Mesos. Bei VMware setzen wir aktuell vor allem auf Kubernetes, da hier von unserer Community aus die größte Nachfrage herrscht.

Was hat Vereinssport mit Kubernetes zu tun?

Ein Cluster Manager simuliert einen Verbund aus mehreren Docker-Hosts und sorgt für die richtige Verteilung der Aufgaben (beispielsweise Docker Images). Zu den wichtigsten Aufgaben des Container Cluster Managers gehören neben intelligenter Orchestrierung auch Scheduling (Zuweisen von Ressourcen, beispielsweise von Docker Images zu Cluster Nodes respektive Docker Hosts) und Skalierung (bei einem Ausfall eines Docker-Hosts wird ein neuer automatisch gestartet, bei steigender Last müssen automatisch neue Hosts gestartet werden). Das bedeutet, dass der Cluster Manager sich um die alltäglichen Betriebsaufgaben kümmert, die aktuell noch oftmals manuell von IT-Administratoren übernommen werden. Er gleicht einem Trainer, der seine Spieler anweist, koordiniert und auf Fehler hinweist. An dieser Stelle tut sich ein weiterer Knackpunkt auf: Einerseits schafft der Cluster Manager erstmal eine neue Rolle, da es sich um ein sehr komplexes System handelt, um das sich jemand kümmern muss. Andererseits jedoch fallen durch die Automatisierung auch Routineaufgaben und klassische Administratorenrollen weg.

Eine kleine Kubernetes-Geschichte

Die Blaupause von Kubernetes, genannt Borg, wurde ursprünglich von Google entwickelt. In vielen Fällen hat Google die Probleme, mit denen Unternehmen heute zu kämpfen haben, bereits vor Jahren gelöst. Google experimentierte bereits vor mehr als 10 Jahren mit Container-Technologien, da das Unternehmen damals vor der großen Herausforderung stand, dass Anwendungen für mehrere Millionen Server ausgerollt und effizient betrieben werden mussten – eine manuelle Herangehensweise hätte die Kapazitäten von Google deutlich überstiegen. 2015 veröffentlichte Google schließlich ein Paper, in dem Borg der Öffentlichkeit vorgestellt wurde.

Ein sehr gutes Beispiel für den erfolgreichen Einsatz von Automatisierung und Standardisierung mittels eines Cluster Managers ist Facebook: Dank dieses Ansatzes ist ein einzelner Administrator für die Betreuung von rund 20.000 Servern zuständig. Ein weiteres aktuelles Problem, vor dem CIOs stehen, ist die Auslastung der Server in ihrem Rechenzentrum. Netflix zählte beispielsweise zu den Early Adoptern von AWS. Doch schon bald stellte sich heraus, dass die virtuellen Maschinen lediglich zu 20 Prozent ausgelastet waren – je nach Umgebungsgröße ist das ein enormer Kostenfaktor! Durch einen Cluster Manager kann die Auslastung erhöht werden, sodass Server typischerweise einen Auslastungsgrad von 80 bis 90 Prozent erreichen und somit direkt Kosten gespart werden können.

Lutz Andre Barroso von Google hat die moderne Vorgehensweise kompakt zusammengefasst: &#rsquo;We must treat the datacenter itself as one massive warehouse-scale computer.&#rsquo; Und ganz genau darum geht es letztendlich: Das Rechenzentrum nicht als mehrere Tausend Server zu sehen, sondern als eine Einheit, die sich mittels Automatisierung und der richtigen Tools sehr viel einfacher verwalten lässt.

Sie haben Fragen zu agiler Softwareentwicklung und Cloud-native Apps? Auf Twitter können Sie gerne direkt mit mir in Kontakt treten und meine News rund um #CrossCloud verfolgen!

Read more..

NetScaler and Kubernetes: An Enabler for Digital and DevOps Teams

In 2016, we sowed the seeds of putting a Citrix NetScaler application delivery proxy in the hands of developers to roll out apps quickly with CPX Express, a NetScaler in a Docker container. At DockerCon 2017, we are completing the …


  

Related Stories

Continue reading..

Kubernetes and VMware NSX

Attending CloudNativeCon/KubeCon this week in Berlin (29th- 30th of March)? Please visit us at our booth #G1 andclick for more details about what’s happening at the show!


IT is undergoing a huge transformation.

Organizations are moving away from static infrastructure to full automation on every aspect of IT. This major shift is not happening overnight. It is an evolutionary process, and people decide to evolve their IT at different speeds based on organizational needs.

When I decided to join the VMware Networking & Security Business Unit four years ago, the key deciding factor for me was that I felt that networking is adopting automation far too slowly. Do not get me wrong – we always automated network configurations in some form. I still remember vividly my time as a networking consultant at a major German airport. Back at the beginning of the new millennium, I used a combination of Perl, Telnet and Expect to migrate the configuration of a huge core network from a single-tenant configuration to a multi-tenant MPLS/VPN. Nevertheless, at some point, network operators stopped evolving, and even today largely, we continue to automate by manually setting up new configuration into network devices using the individual boxes CLI syntax.

Then along came VMware NSX. NSX was, and still is, exactly what my definition of a system purpose-built for network and security automation. NSX abstracts away the &#rsquo;to be automated&#rdquo; parts of the network from the static physical infrastructure, and all of this is driven by APIs. NSX lets operators automate where it is good and safe to automate – in the overlay, as well as keep static configuration with the stability sought after in the physical network.

What does this all have to do with Kubernetes?

Let us first have a quick look at Kubernetes&#rsquo; mission statement:

&#rsquo;Kubernetes is an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure&#rdquo;

Container-centric infrastructure needs a network and this network must be dynamic. We cannot keep the good ol&#rsquo; model of predefining everything and having the containers only &#rsquo;consume&#rdquo; networking. The Container Network must share the life cycle of the applications deployed on Kubernetes – created dynamically, scaled on-demand when the app is scaled, and must be multi-tenant. Anything less will result in incomplete automation and limited agility.

Let me give you an example:

A business unit decides to move to the new Kubernetes deployment that was recently set up by the internal IT Cloud Infrastructure team. Unfortunately, the business unit user will need to wait for a couple of days for his environment to be usable, as the underlying network topology (VLANs, Router IP Interfaces, VRFs, Firewall Interfaces, etc.) has to be pre-configured to map to the business units newly created Kubernetes namespace.

This clearly does not work! The business unit user rightly expects a &#lsquo;public cloud experience&#rsquo;. After finalizing contractual details through a web-portal, the Namespace in Kubernetes should be created alongside all needed network and storage constructs. Even more extreme, the business unit should be able to order its own complete Kubernetes deployment – with all network and storage constructs – delivered to them in less than 10 minutes after pressing the &#rsquo;order&#rdquo; button.

Now you might rightly say, &#rsquo;Isn&#rsquo;t this a solved problem? Don&#rsquo;t we have overlay network technologies in Kubernetes that already abstract away the logical network in Kubernetes from the underlying IaaS network?&#rdquo; True! Those have all been invented exactly to solve the issues caused by non-programmable static infrastructure that sits underneath Kubernetes.

However, the current implementations with overlay network technologies have a number of challenges that I would like to walk you through:

  • Missing fine-grained traffic control and monitoring: In Kubernetes, operators do not deploy individual containers, they deploy Pods. A Pod is a collection of containers that share the same network interface, and run on the same Kubernetes node. Every Pod has a distinct network interface that gets patched into a Linux network namespace for isolation. It is very complex to troubleshoot and secure Pod-to-Pod connectivity with the current technologies, as they do not offer a central visibility of all Pod network interfaces. Having a central management of Pod network interfaces, with the ability to read counters, do traffic monitoring and enforce spoofguard policies is at the core of the NSX value proposition. NSX also offers a rich set of troubleshooting tools to analyze and solve connectivity issues between Pods.
  • Missing fine-grained security policy (firewall rules): In some of the current technologies, Pod-to-Pod traffic is not secured at all. This opens an opportunity for attackers to move laterally from Pod to Pod without being blocked by firewall rules and, even worse, without leaving any traces of this lateral movement in logs. Kubernetes addresses this with the network policy project driven by the Networking Special Interest Group (SIG)in Kubernetes. NSX implements Network Policy alongside with pre-created &#lsquo;admin-rules&#rsquo; to secure Pod-to-Pod traffic in Kubernetes
  • Automating the creation of network topology: Many of the current implementations take a simple approach to network topology mapping, which is not to have any topology mapping. IP Subnet allocation for Pods is mostly done per Kubernetes node. Tenancy constructs like namespaces are usually not reflected in anything else than abstract firewall rules. NSX implements a distinct network topology per Kubernetes namespace. NSX maps logical network elements like logical switches and distributed logical router to Kubernetes namespaces in a fully automated manner. Each of those network topologies can then be adapted per namespace, e.g. operators can decide if the subnets of the namespace should be directly routed, or privately addressed and behind NAT

1- NSX_Kubernetes Topology

 

  • Integration in enterprise networking: A paradigm of many existing technologies is that the operator needs to decide at the time of install whether the container networks should be privately addressed, and if they are hidden behind a NAT boundary or directly routed within the enterprise network. Existing overlay technologies make it difficult to expose Pods to networks outside of the Kubernetes cluster. Exposing the services involves using NAT/PAT on the Kubernetes nodes themselves, putting the burden on the operator to design how to map e.g. external physical load-balancers or DNS records to TCP/UDP ports on the Kubernetes nodes. Alternatively, or in addition, one can use the new Kubernetes Ingress load-balancers to get traffic into the container networks. In any case, there is NAT involved. With the NSX integration, we intend to allow operators to be able to decide on a per-namespace basis if they want to do direct routing, and even if they want to inject the routes dynamically into the core network using BGP. On the other hand, if operators wanted to save IP address space, they would be able to &#lsquo;hide&#rsquo; the namespace networks behind NAT using private IPs and Kubernetes Ingress Controllers (Load-Balancers) to get external traffic to the Pods.

How does the NSX integration look like? How did we design it?

To start, the integration uses NSX-T since this makes the solution applicable to any compute environment, and not just vSphere. E.g. NSX-T will allow us to support Kubernetes on a variety of compute platforms – such as Photon-Platform (which uses ESXi hosts with vCenter), Baremetal Linux servers, Public Clouds, and KVM based virtualization environments.

To integrate Kubernetes with NSX-T we intend to develop three major Components; 1) the NSX Container Plugin (NCP), 2) the NSX CNI Plugin and 3) NSX Kube-Proxy.

  1. The NSX Container Plugin (NCP) is a software component that we intendto deliver as a container image, running as an infrastructure Pod in the Kubernetes cluster. It would sit between the Kubernetes API Server, watching for changes on Kubernetes Objects (namespaces, network policies, services etc.), and the NSX-T API. It would create networking constructs based on the object addition and changes reported by the Kubernetes API.

    2 - NCP

  2. The NSX CNI Plugin is a small executable intended to be installed on all Kubernetes Nodes. CNI stands for Container Network Interfaceand is a standard that intends to allow the integration of network solutions like NSX into container orchestration platforms. The Kuberenetes node component called Kubelet will instantiate/call the CNI Plugin to handle the Pod network attachment.
  3. The NSX Kube-Proxy is a daemon running on the Kubernetes Nodes. Again, we intend to deliver NSX Kube-Proxy as a container image, so that it can be run as a Kubernetes Daemon-Set on the Nodes. NSX Kube-Proxy would replace the native distributed east-west load balancer in Kubernetes called Kube-Proxy, which uses IPTables, with our solution that uses OpenVSwitch (OVS) load-balancing features.

Each of the components deserves a closer look and far more explanation than what I can cover in this initial article. We will follow up with a detailed look at each component in future articles.

Before I wrap this up, there is one more thing you might ask, &#rsquo;How do we solve the two layers of overlay problem?&#rdquo; Well, when running overlay networks between Kubernetes Nodes running as VMs on an IaaS that itself uses an overlay network solution, you get into the situation where you have double encapsulation. E.g. VXLAN in VXLAN.

3 - Overlay in Overlay Problem

Would the NSX-T Kubernetes Integration suffer from the same problem?

The answer would be No. When running the Kubernetes nodes as VMs, the tunnel encapsulation would be handled only on the hypervisor vSwitch layer. In fact, the OpenVSwitch (OVS) in the Kubernetes Node VM would not even have a control plane connection to the NSX-T controllers and managers thereby creating an additional layer of isolation and security between the containers and the NSX-T control plane. The NSX CNI Plugin intends to program the OVS in the Kubernetes Node to tag traffic from Pods with a locally significant VLAN id (per vnic). This would allow us to &#rsquo;multiplex&#rdquo; all the traffic coming from the Pods onto one of the Kubernetes Node VMs vnics towards the Hypervisor vSwitch. The VLAN id would allow us to identify individual Pods on the Hypervisor vSwitch using a logical sub interfaces of the VMs vnic. All management and enforcement actions (counters, spoofguard, firewalling, …) on the per-Pod logical port would be done on the Hypervisor vSwitch. The VLAN id imposed by OVS in the Node VM would be stripped by the Hypervisor vSwitch before encapsulating it with the overlay header.

4 - Pod Multiplexing using VLANs

There are many more details to be discussed than what we can not fit into a single article. Stay tuned for more articles on how we integrate Kubernetes with NSX-T!

Meanwhile, if you attend CloudNativeCon / Kubecon this week in Berlin (29th + 30th of March), please visit us at our booth #G1. We would be delighted to chat with you in detail about NSX-T with Kubernetes.

We will also be at Dockercon in Austin, TX, April 17th to the 20th as a gold sponsor. We would love to meet you at our booth #G3 where we will showcase container-ready SDDC solutions that includeNSX.

To learn more about NSX Container Networking and Security, watch these VMworld 2016 sessions:

  • VMworld 2016: NET9989 – VMware NSX, Network Bridge to Multi-Cloud Future from Guido Appenzeller
  • VMworld 2016: NET 7935 – Container Orchestration and Network Virtualization – free VMworld login required

To learn more about VMware&#rsquo;s open source projects and products in the cloud-native space, you can follow the following links:

  • Cloud-Native Apps
  • Photon Platform
  • vSphere Integrated Container

The post Kubernetes and VMware NSX appeared first on The Network Virtualization Blog.

Read more..

Firma invitada: ¿Qué nos deparará el cloud en 2017?

La segunda entrega de nuestras predicciones para 2017, por Kit Colbert, director de tecnología del Departamento de Cloud de VMware, describe cinco tendencias clave en materia de aplicaciones nativas cloud que seguramente tendrán enorme éxito en este 2017, y que están vinculadas con las soluciones de seguridad en estructuras de contenedores y la plataforma de aplicaciones nativas de la nube de código abierto Pivotal Cloud Foundry (PCF).

VMware presentó su iniciativa de aplicaciones nativas cloud en 2015, con la introducción de vSphere Integrated Containers (VIC) y la Plataforma Photon. Desde entonces, ha habido un interés creciente en este nuevo modelo de desarrollo de aplicaciones.

Sin duda, el año 2016 ha sido el año de los contenedores. Con los nuevos proyectos de código abierto lanzados por los grandes desarrolladores (como VMware y su proyecto de código abierto vSphere Integrated Containers), es de esperar que la infraestructura nativa de la nube de contenedores reciba un gran impulso.

¿Qué se puede esperar para el año 2017? A continuación, enumeramos cinco tendencias clave:

  1. Kubernetes se alejará del grupo de programadores de contenedores

En 2016, se inició una carrera en la que participaban tres programadores de contenedores: Docker Swarm, Kubernetes y Mesos. Pensamos que Kubernetes se pondrá en cabeza en 2017. En VMware, hemos comenzado a observar un creciente interés en Kubernetes entre los usuarios, los proveedores y las comunidades de código abierto, y este año, en VMworld EMEA hemos presentado Kubernetes como servicio en la Plataforma Photon. Kubernetes continuará alejándose del pelotón, con más usuarios y despliegues en producción, y muchas características novedosas que lo harán cada vez más atractivo para un público que crece día a día.

  1. Los contenedores usarán cada vez más las tecnologías de virtualización

En la actualidad, los contenedores se basan en tecnologías integradas en el núcleo de Linux, incluidos los grupos de control y los nombres de espacios, para aislar entre sí los contenedores en el host. No obstante, varias compañías están experimentando con sistemas operativos ligeros y características de virtualización integradas en CPU modernas para poder iniciar de modo transparente una máquina virtual ligera para cada contenedor que se lanza. Este enfoque podría aumentar el aislamiento y la seguridad de los contenedores sin coste adicional. Pensamos que la idea dará mucho que hablar este año.

  1. Las tecnologías de persistencia de contenedores madurarán y se comenzará a ver en producción

La mayoría de los contenedores actuales están &#rsquo;sin estado&#rdquo; (stateless), es decir, los datos que se encuentran dentro del contenedor se destruyen cuando la instancia del contenedor se cierra, y cualquier estado de aplicación necesario debe almacenarse en una base de datos externa o en otra forma de servicio de almacenamiento. Esto se debe, en gran parte, a la inmadurez de las tecnologías de persistencia disponibles hoy en día en el mercado. Sin embargo, con la llegada de nuevas capacidades, tales como PetSets de Kubernetes, tecnologías emergentes como las de Portworx y nuestros propios desarrollos en materia de persistencia de contenedores, como el controlador de volumen Docker para vSphere, pronto veremos un nivel mayor de madurez en la persistencia de contenedores. Finalmente, comenzaremos a ver contenedores &#rsquo;con estado&#rdquo; (stateful) en producción.

  1. La cantidad de soluciones de seguridad de contenedores será enorme

La seguridad es la mayor preocupación de los usuarios de contenedores, dato que revelan todos los estudios. Y es normal, dado que existe un amplio espectro de problemas de seguridad relacionados con los contenedores. Los contenedores de Linux comparten un núcleo y por tanto dejan expuesto un límite de seguridad poroso. Y la seguridad de la red de contenedores está aún en pañales. Pero se divisa una luz al final del túnel, pues a medida que aumente el uso de contenedores en entornos de producción, habrá una mayor demanda de soluciones de seguridad por parte las empresas, para asegurar sus aplicaciones y datos críticos y no quedar demasiado expuestas. Muchas compañías, VMware con NSX entre ellas, están ocupándose de satisfacer esa demanda, y es muy probable que surjan nuevas soluciones en los próximos meses.

  1. Pivotal Cloud Foundry obtendrá el reconocimiento que merece

Las tecnologías de contenedores han sido las grandes protagonistas de los últimos años. Entretanto, la plataforma de aplicaciones nativas de la nube de código abierto Pivotal Cloud Foundry (PCF) ha ido acumulando una gran base de clientes, entre los que se encuentran leales desarrolladores y operadores de la nube. La tasa de proyección de la compañía ha superado la marca de los 200 millones de dólares anuales, prueba de su crecimiento sólido y continuo en una gran variedad de sectores. El framework Spring Boot de Pivotal ha crecido enormemente, prueba de ello son sus 2,5 millones de descargas mensuales. Esto aumenta el interés en PCF como aplicación en entornos de producción. Éste es el año para que finalmente PCF comience a brillar con luz propia.

Próximamente, estará disponible la tercera y última entrega de las predicciones para el año 2017 de Tom Corn, vicepresidente ejecutivo de Productos de Seguridad, donde se pregunta si en 2017 habrá que adoptar un nuevo enfoque de cara a la seguridad.

¿Cómo puede la infraestructura hiperconvergente ayudar a las compañías a transitar el camino de la transformación digital en 2017? En la primera publicación de la serie de predicciones para el año 2017 encontrarás la respuesta. Y para no perderte las últimas novedades, síguenos en Twitter: @VMware_ES.

Read more..

Go Que Newsroom

Categories