Upgrade to Pro — share decks privately, control downloads, hide ads and more …

All Eyes on DCOS

All Eyes on DCOS

Einordnung und Demo von DC/OS von Mesosphere

Stefan Siprell

November 15, 2016
Tweet

More Decks by Stefan Siprell

Other Decks in Programming

Transcript

  1. PROLOG STEFAN SIPRELL ▸ Arbeite für codecentric Karlsruhe ▸ Partnermanager

    ▸ Sales ▸ Themenentwicklung ▸ Schwerpunkt derzeit IoT mit SMACK / Cloud PaaS ▸ Verteiler: ▸ Beschwerden: [email protected] ▸ Lob: @stefansiprell ▸ Bewerbungen: [email protected]
  2. PROLOG AGENDA ▸ Kapitel 1: Container Orchestration ▸ Kapitel 2:

    Scheduling ▸ Kapitel 3: Container Plattform ▸ Kapitel 4: Distributed OS ▸ Demo
  3. CONTINUOUS AUTOMATED SCHEDULING, COORDINATION AND MANAGEMENT OF COMPLEX SYSTEMS OF

    CONTAINERIZED COMPONENTS AND THE RESOURCES THEY CONSUME. Karl Isenburg CONTAINER ORCHESTRATION
  4. CONTAINER ORCHESTRATION DIE WELT VOR CONTAINER APP SERVICE APP SERVICE

    APP SERVICE APP SERVICE APP SERVICE APP SERVICE OS OS OS MASCHINE MASCHINE MASCHINE INFRASTRUKTUR ▸ Auf echten/virtuellen Maschinen laufen Betriebssysteme ▸ Auf den Maschinen laufen Anwendungen und Services
  5. CONTAINER ORCHESTRATION RESOURCE MANAGEMENT APP SERVICE APP SERVICE APP SERVICE

    APP SERVICE APP SERVICE APP SERVICE OS OS OS MASCHINE MASCHINE MASCHINE INFRASTRUKTUR CONTAINER RUNTIME CONTAINER RUNTIME CONTAINER RUNTIME RESOURCE MANAGEMENT SCHEDULING SERVICE MANAGEMENT ‣ MEMORY ‣ CPU ‣ GPU ‣ VOLUMES ‣ PORTS ‣ IPS
  6. CONTAINER ORCHESTRATION SCHEDULING APP SERVICE APP SERVICE APP SERVICE APP

    SERVICE APP SERVICE APP SERVICE OS OS OS MASCHINE MASCHINE MASCHINE INFRASTRUKTUR CONTAINER RUNTIME CONTAINER RUNTIME CONTAINER RUNTIME RESOURCE MANAGEMENT SCHEDULING SERVICE MANAGEMENT ‣ PLACEMENT ‣ REPLICATION / SCALING ‣ RESURRECTION ‣ RESCHEDULING ‣ ROLLING DEPLOYMENT ‣ UPGRADES ‣ DOWNGRADES ‣ COLLOCATION
  7. CONTAINER ORCHESTRATION SERVICE MANAGEMENT APP SERVICE APP SERVICE APP SERVICE

    APP SERVICE APP SERVICE APP SERVICE OS OS OS MASCHINE MASCHINE MASCHINE INFRASTRUKTUR CONTAINER RUNTIME CONTAINER RUNTIME CONTAINER RUNTIME RESOURCE MANAGEMENT SCHEDULING SERVICE MANAGEMENT ‣ LABELS ‣ GROUPS / NAMESPACES ‣ DEPENDENCIES ‣ LOAD BALANCING ‣ READINESS CHECKING
  8. 4 TASK 3 SCHEDULING ABLAUF IN MESOS 1. SLAVE meldet

    verfügbare Ressourcen an MASTER 2. MASTER bietet Ressourcen den Frameworks an 3. Framework scheduled TASKS für die SLAVES 4. MASTER verteilt TASKS an die SLAVES MESOS MASTER MESOS SLAVE TASK 1 FRAMEWORKS 2
  9. SCHEDULING SCHEDULING METHODEN ▸ Monolithic ▸ Nur ein einziger Algorithmus

    für das Verteilen von Aufgaben erschwert die optimale Nutzung für verschiedene Workloads. ▸ Beispiel: YARN ▸ Two-Level ▸ Langsamer in der Nutzung von Ressourcen aber stabiler. ▸ Beispiel: Mesos ▸ Shared State ▸ Nutzt auch zwei-stufige Verteilung, aber die einzelnen Scheduler verteilen die Aufgaben autark. ▸ Beispiel: Nomad
  10. SCHEDULING SERVICES ▸ Mesos delegiert das Scheduling an Frameworks ▸

    Marathon ist ein Beispiel für einen long-running Service Framework ▸ Startet für jede Task eine Sandbox ▸ Tasks laufen in eigenen Namespaces ▸ Marathon kann Docker/APPC Images als Deployment Format nutzen ▸ entweder über die Universal Container Runtime (ohne Docker Daemon) oder ▸ über die Docker Runtime
  11. SCHEDULING KRISE DER MONOLITHISCHEN DEPLOYMENTS ▸ Scale UP ▸ Verteilte

    Datenservices brauchen management um „breit zu skalieren“. ▸ Recovery ▸ Verteilte Datenservices sind keine Freunde des Shuffles durch erzwungene Partitionsausfälle - graceful ist trumpf ▸ Client Code ▸ Moderne Datenservices kennen und nutzen Mesos zum Management der Cluster und deren Resourcen WHAT HAPPENED? I JUST STARTED ON THIS MINION. WHY? WHO ELSE IS RUNNING? DO THEY KNOW THAT I JOINED? MY HOSTED CODE WANTS MORE NODES. WHAT SHOULD I DO?
  12. SCHEDULING ALTERNATIVEN ZU MARATHON ▸ Alternativ zu Marathon gibt es

    weitere Mesos Scheduler bei DC/OS ▸ Kafka ▸ Hadoop HDFS ▸ Hadoop YARN (Alpha…) ▸ Spark ▸ Cassandra ▸ Elasticsearch ▸ Da diese Scheduler direkt auf der Mesos API aufsetzen, haben sie vielmehr Möglichkeiten als der monolithische Docker Orchestrator.
  13. A DISTRIBUTED SYSTEM ON WHICH USERS DEVELOP, RUN, AND MANAGE

    CONTAINERIZED APPLICATIONS AND SERVICES. Karl Isenburg CONTAINER PLATTFORM
  14. CONTAINER PLATTFORM POST DEV-OPS OPS ▸ Debugging ▸ Logging &

    Metriken ▸ Konsolenzugang ▸ Wartung ▸ Paketverwaltung ▸ Upgrades ▸ Cluster Resizing ▸ Application Autoscaling ▸ Software Defined Netze
  15. CONTAINER PLATTFORM SYSTEM SPACE APP SERVICE APP SERVICE APP SERVICE

    APP SERVICE APP SERVICE APP SERVICE OS OS OS MASCHINE MASCHINE MASCHINE INFRASTRUKTUR CONTAINER RUNTIME CONTAINER RUNTIME CONTAINER RUNTIME RESOURCE MANAGEMENT SCHEDULING SERVICE MANAGEMENT ‣ LOAD BALANCER ‣ SECURITY ‣ NETWORKING ‣ LOGGING & METRICS ‣ PACKAGE MANAGER ‣ STORAGE USER SPACE SYSTEM SPACE
  16. CONTAINER PLATTFORM USER SPACE APP SERVICE APP SERVICE APP SERVICE

    APP SERVICE APP SERVICE APP SERVICE OS OS OS MASCHINE MASCHINE MASCHINE INFRASTRUKTUR CONTAINER RUNTIME CONTAINER RUNTIME CONTAINER RUNTIME RESOURCE MANAGEMENT SCHEDULING SERVICE MANAGEMENT ‣ SOURCE CONTROL ‣ CONTINUOUS INTEGRATION ‣ ARTIFACT REPOSITORY USER SPACE SYSTEM SPACE
  17. DISTRIBUTED OS DISTRIBUTED OPERATING SYSTEM EIGENTLICH IST DAS DOCH EIN

    VERTEILTES OS… APP SERVICE APP SERVICE APP SERVICE APP SERVICE APP SERVICE APP SERVICE OS OS OS MASCHINE MASCHINE MASCHINE INFRASTRUKTUR CONTAINER RUNTIME CONTAINER RUNTIME CONTAINER RUNTIME RESOURCE MANAGEMENT SCHEDULING SERVICE MANAGEMENT USER SPACE SYSTEM SPACE
  18. DC/OS DISTRIBUTED OPERATING SYSTEM NOCHMAL EINE ANDERE SICHT MACHINE MANAGEMENT

    AWS, AZURE, GVE, OPENSTACK, VSPHERE, VIRTUAL BOX, FUSION PROVISIONING PUPPET, CHEF, ANSIBLE, SALT, VAGRANT, OTTO RESOURCE MANAGEMENT MESOS CONTAINERIZATION DOCKER, RKT, GARDEN, MESOS JOB SCHEDULING CHRONOS, KUBERNETES CONTAINER ORCHESTRATION KUBERNETES, MARATHON, SWARM, FLEET, LATTICE, ECS APPLICATION ORCHESTRATION CLOUD FOUNDRY, HEROKU, OPENSHIFT, DEIS Der Full-Stack ist erschreckend tief und die Toolpalette riesig. DC/OS deckt große Teile mit einer Plattform ab. Kubernetes ist zum Beispiel deutlich weniger komplex, da es weniger Bereiche abdeckt. DC/OS kann auch um Kubernetes erweitert werden, falls zusätzliche Scheduling Funktionen (Collocation, Resurrection, etc.) erforderlich sind. ES GIBT WIE IMMER KEINE ONE-SIZE-FITS- ALL LÖSUNG.