Docker und Kubernetes Basics

Christoph Stoettner

München, 13-01-2020

Christoph Stoettner

  • Senior Consultant bei panagenda

    • Linux seit 1995

    • IBM Domino seit 1999

    • IBM Connections seit 2009

  • Schwerpunkt

    • Migrationen, Installationen

    • Performance Analysen, Infrastruktur

    • Monitoring, Security

    • Kubernetes, Container

  • Mehr und mehr

    • DevOps, Automatisierung

Geschichte der Container

  • Kernelerweiterungen

  • Entwicklung geht weiter (podman, containerd)

docker history

Docker: Technik vs. Firma

  • Docker (Software)

    • Open Source Software zur Isolierung von Anwendungen

    • Basiert auf Cgroups und Namespaces

    • Verwendete erst LXC als Kernel-Schnittstelle (heute: libcontainer)

    • seit 2014 Bestandteil in Red Hat Enterprise Linux 7.0 (und OpenSUSE)

  • Docker Inc.

    • März 2013 dotCloud veröffentlicht die Software Docker auf Github

    • dotCloud benennt sich in Docker Inc. um (Oktober 2013)

Red Hat Enterprise Linux 8, das 2019 erschienen ist, enthält Docker nicht mehr, da Redhat und andere Distributoren wie z. B. Suse sich wegen Problemen mit Docker Inc entschieden haben Docker durch podman zu ersetzen

Standardisierung

  • Open Container Initiative (OCI)

  • Cloud Native Computing Foundation (CNCF)

  • Docker Inc.

    • veröffentlichte libcontainer als Open Source (2013)

    • spendet runc und Container Image Spezifikation an OCI (2015)

    • spendet containerd an CNCF (2017)

Die Technik gehört also nicht mehr Docker Inc.

Vorteile von Containern (Transport)

  • Analogie zum Transport Container passend

  • Standard Container (20 x 8,5 x 8 Fuß³ | 6,09 x 2,59 x 2,44 m³)

  • Standardisierung der Schnittstellen

container ecosystem

Vorteile von Containern

  • Unabhängig vom Betriebssystem

  • Container laufen auf allen gängigen

    • Betriebssystemen

    • Cloud Plattformen

Build Ship Run

Container und virtuelle Maschinen

  • Container

    • nativ Linux (teilt sich den Kernel)

    • geringer Ressourcenbedarf

    • keine OS Lizenz notwendig

    • einfachere Updates

  • VM

    • Virtueller Computer

    • Emuliert Hardware (als Software)

    • komplettes Betriebssystem notwendig

    • Jede VM seperat zu aktualisieren

vm container

Update von Anwendungen

  • Aufwändig (Applikationen werden immer größer)

  • Lang laufende Projekte

  • Schwer zu testen

  • Neuinstallierte Server vs. Updates

    • 8.5.5.0 ▸ 8.5.5.8 ▸ 8.5.5.10 ▸ 8.5.5.15   ≠   8.5.5.0 ▸ 8.5.5.15

    • Test und Produktion sollten möglichst identisch sein

  • Bsp. Connections

Infrastructure as Code

Infrastructure as Code

  • Schnell auf Änderungen in Systemumgebung reagieren

  • Systemadministration mit ähnlichem Vorgehen wie Entwickler

    • Skripte für administrative Aufgaben

    • Konfiguration von Servern in Dateien

    • Ablage in zentralen Versionsverwaltungssystemen

  • (Automatisches) Testen von Änderungen

  • Monitoring

  • Installationen wiederholbar

Immer gleiche Server, egal ob in Test, QA oder Produktion

Virtualisierung minimiert Risiken

  • Werkzeuge wie Vagrant und Docker können das Risiko von Updates reduzieren

    • keine Abweichungen von Test und Produktion

  • Terraform um Vmware oder Cloud Server zu verwalten

    • Unveränderliche (Immutable) Images

    • Änderungen erzeugen neue Systeme

  • Ansible, Puppet oder Chef

    • Konfiguration

    • Installation

  • Idempotenz

    • Ausführen von Skripten führt immer zu gleichen Ergebnissen

Warum brauchen wir dann Container?

  • Große Applikationen bei Änderungen schwer zu testen

  • Aufteilen einer Applikation in Microservices

    • Container haben geringen Ressourcen Overhead

  • Container bzw. Microservices haben definierte Schnittstellen

    • Leicht zu testen

    • Kleine Änderungen häufig installieren

  • Entwickler bekommen schnell Rückmeldungen über ihren Code

    • kein tage- oder wochenlanger Abstand zum Entwickeln

    • Kleine aber ständige Verbesserungen

    • Häufiger commit veringert Probleme beim merge

Automatisierung

  • Testumgebung analog Produktion

    • Keine Überraschungen bei Installation und Update

  • Build

  • Installation

  • Änderung

    • Zero Downtime Updates

    • Updates für Teilmenge der Anwender

    • Updates auch ausserhalb Wartungsfenstern

  • Rollback

Continous Delivery

  • Automatisierung von Installation und Update

  • CI Server wie Jenkins ermöglichen

    • "Nightly", "Test" oder "Release"-Versionen

  • Schnelle, zuverlässige und wiederholbare Deployments

  • Rollback Optionen

Netflix says it launches up to a half million containers and 200,000 clusters per day

Images und Container

  • Ein Container wird durch Ausführen eines Images gestartet.

  • Ein Image ist ein ausführbares Paket

    • enthält alles, was zum Ausführen einer Anwendung benötigt wird

    • Code, eine Laufzeit, Bibliotheken, Umgebungsvariablen und Konfigurationsdateien

    • Besteht aus Layern

    • Layer unveränderbar (immutable)

    • Änderungen erzeugen neue Layer

  • Container ist eine Laufzeitinstanz eines Images

Trennung von Applikation und Daten

Docker Registry

Private Registry (ohne Security)
docker run -d -p 5000:5000 --restart=always --name registry registry:2
Per Helm
$ helm install stable/docker-registry

Kubernetes

  • Ursprünglich von Google entwickelt

  • Borg System (2003/2004)

    • Trennung von User und Batch Prozessen

    • Basiert auf cgroups

  • 2014 von Google als Open Source Software an CNCF übergeben

    • Bereits nach 6 Wochen schlossen sich MS, IBM, Red Hat und Docker an

  • Läuft in RZ, Clouds, Raspberry Pi …​

Run reliable applications on unreliable hardware.

Kubernetes Architektur

Kubernetes Architektur

Kommandozeile

Pods

  • Pods sind die kleinste Einheit in Kubernetes

    • enthält 1-n Container

    • läuft auf einer Node

  • Kurze Lebenszeit

  • Erstellt und zerstört

  • Keine Reparatur!

    • System heilt sich selbst

      • Durch neue Pods

      • Zerstören von nicht funktionierenden Pods

  • System ist langlebig

  • Pods nicht

Skalieren, Updaten und Zurückrollen

Netzwerk Modell

  • alle Pods können ohne NAT miteinander kommunizieren

  • alle Nodes können ohne NAT miteinander kommunizieren

  • die IP innerhalb und ausserhalb eines Pods ist gleich

  • freigegebene Ports sind von allen Pods erreichbar

Erweiterte Security mit Istio Service Mesh. * SSL erzwingen * Steuerung welche Pods miteinander kommunizieren dürfen

Kubernetes Deployments

  • On premises (Beispiele)

    • kubeadmin

    • Rancher

    • Ubuntu

    • IBM Cloud Private

    • Red Hat OpenShift

  • Cloud

    • Azure

    • AKS (Amazon Kubernetes Service)

    • GKC (Google Kubernetes Cloud)

    • Digital Ocean

  • Hybrid

Component Pack Installation

helm install \
--name=bootstrap <path>/helmbuilds/bootstrap-0.1.0-20191119-185020.tgz \ (1)
bootstrap <path>/hybridcloud/helmbuilds/bootstrap-0.1.0-20191119-185020.tgz \ (2)
--set image.repository=Docker_registry/connections,\
env.set_ic_admin_user=ic_admin_username,\
env.set_ic_admin_password=ic_admin_password,\
env.set_ic_internal=ic_internal,env.set_master_ip=master_ip,\
env.set_elasticsearch_ca_password=es_ca_password,\
env.set_elasticsearch_key_password=es_key_password,\
env.set_redis_secret=redis_secret_password,\
env.set_search_secret=search_secret_password,\
env.set_solr_secret=solr_secret_password,\
env.set_starter_stack_list=starter_stack_list,env.skip_configure_redis=true/false
1Helm 2
2Helm 3

NodePort oder Ingress

Storage

  • Trennung von Applikation

  • Herausforderung: Hochverfügbarkeit

  • z.B.

    • NFS

    • Ceph

    • S3 / Minio

Sizing

  • Documentation: 9 + n Server für hochverfügbare Kubernetes Umgebung

  • D.h. bei Test und Prod → min. 18 Server

  • Kubernetes unterstützt mehrere tausend Nodes

  • Man könnte einen großen K8s Cluster für alle Umgebungen bauen

    • Abgrenzung Apps über Namespaces

    • Durch den Einsatz von Nodeports nur mit Handarbeit

Links und Artikel

Buchempfehlungen

  • The Phoenix Project
    Gene Kim

  • The Unicorn Project
    Gene Kim

  • Infrastructure as Code
    Kief Morris

  • Continous Delivery Handbook
    Stephen Fleming

unicorn

 

thanks