Kubecon Europe 2019 (Teil 3): Architekturpattern in Orchestrierungsumgebungen

(0 comments)

Teil 3: Architekturpattern in Orchestrierungsumgebungen

Ein nicht unerheblicher Teil der Vorträge und Diskussion auf der KubeCon 2019 wird über Designpattern geführt. Interessant ist es, dass es derzeit selbst in großen Organisationen oft noch keinerlei Begriff und Verständnis über derartige Pattern gibt:

  • Wie werden die Cluster aufgeteilt? 
  • Wo sind die Lokationen der Cluster?
  • Wie werden die Namespaces aufgeteilt, verteilt und wie werden die RBAC Policies darauf implementiert?
    • Es gibt viele Organisationen, die augenscheinlich noch nichts von RBAC auf Namespaces gehört haben!
    • Wo der Unterschied zwischen einem Namespace (Kubernetes) und einem Project (OpenShift / Rancher2) liegt ist nicht klar / schwer nachzuvollziehen
  • Wie groß sollen die Cluster werden?
  • Trennt man Cluster nach Funktion (Development / Test / QM / Production) oder nach Location ( Europe / Americas / Asia) , ...?
  • Wie setzt man Policies für Label und Selektoren auf?
  • Wie geht man mit Network Policies um?
    • Die meisten Network Policies kommen aus der "alten" Welt der Intra- / Extra- & Internet Philosophie und passen daher nicht sehr gut auf die modernen Anforderungen.
    • Wie spielt eine Cluster Network Policy mit der Physical Network Policy zusammen?
    • Was passiert, wenn man Cloud Provider und On Premise mischt?
  • Wie geht man mit Volumes um?
    • Auch auftrennen wie die Cluster  / Namespaces?
    • Self Service für PV's?
    • Storage Classes oder doch nicht?
  • Wie werden die CI / CD Policies implementiert? Löst jedes Branching ein Build aus? Wie wird gebrancht?

Vermutlich könnte man noch 3 Seiten mit Fragen füllen. Das zeigt aber deutlich, das es nicht reicht, eine Orchestrierung zu installieren oder installieren zu lassen. Man muss sich nicht nur mit neuen Applikationspattern sondern auch massiv mit Infrastrukturarchitekturen beschäftigen.

Der große Vorteil: Mit etwas Aufwand kann man viele Entscheidungen revidieren, ohne dass der Aufwand zu teuer oder exorbitant wird!

Currently unrated

Comments

There are currently no comments

New Comment

required

required (not published)

optional

required

Recent Posts

Categories

Authors

Archive

2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005

Feeds

RSS / Atom