"Container hängen mit VMs zusammen und bauen auf diesen auf"

[Doubleslash]

Aber doch nur, weil VMs einfach schon da sind. Nochmal zum mitmeißeln: Container brauchen VMs nicht. Container haben keine Awareness ueber einen VM Layer und auch keine Abhaengigkeiten dazu.
Der Grund, warum Kubernetes Cluster on Premise haeufig auf VMware laufen, ist dass die meisten Umgebungen einfach VMware-basiert sind und es mittlerweile recht schwierig ist, eine Bare-Metal Umgebung zu bekommen. Genau das ist aber gerade wieder im Kommen bei vielen Kunden.
Der Grund warum Cloud Provider Kubernetes in VMs laufen lassen ist, dass sie Kubernetes-Cluster als Service anbieten.

Container brauchen keine VMs. Das Gegenteil ist der Fall: wenn die IT-Landschaft einmal auf Container umgezogen ist, braucht man kein VMware mehr.

[Gamma Ray Burst]

Doubleslash schrieb:
--------------------------------------------------------------------------------



> Container brauchen keine VMs.

Ja

... aber ...


> Das Gegenteil ist der Fall: wenn die
> IT-Landschaft einmal auf Container umgezogen ist, braucht man kein VMware
> mehr.

Das hängt davon ab, Docker-Machine installiert zB Virtual box.

Ja das ist kein Kubernetes, aber am Ende läuft es darauf hinaus das man das ganze Data Center virtualisiert.

Wenn man es braucht ... hängt vom Anwendungsfall ab.

[logged_in]

Container stellen Umgebungen für Programme dar, VM's für Betriebssysteme. Das sind ganz andere Ebenen und beide benötigen ihre eigene Art verwaltet, gewartet und gepflegt zu werden.

Auf VMs zu verzichten wäre ein riesen Fehler. Die ermöglichen so viel Flexibilität, die man bei Bare Metal gar nicht hat. Die werden niemals verdrängt werden, nicht im geringsten. Hardware kündigt an, den Geist aufzugeben? VM schnell mal einfrieren und auf eine andere Maschine verschieben, dann fortsetzten, die Container bekommen davon im günstigsten Fall gar nichts mit.

[Doubleslash]

Diese Meinung vertritt man hauptsaechlich als IT-Ops / Administrator. In diesen Abteilungen existiert ein starker Fokus auf Work Input (Tooling, Infrastruktur, Prozesse) und weniger auf Work Output (tatsaechlichen Mehrwert durch Applikationen mit Business-Logik). Wenn du heute die User von Kubernetes fragst, wird dir keiner sagen: wir brauchen VMs. Und das sind die Leute, die heute das Gehoer vom CIO haben.
Wenn du eine VM einfrieren musst um deine SLA zu halten, setzt ihr Container falsch ein.

[Hawk321]

Doubleslash schrieb:
--------------------------------------------------------------------------------
> Diese Meinung vertritt man hauptsaechlich als IT-Ops / Administrator. In
> diesen Abteilungen existiert ein starker Fokus auf Work Input (Tooling,
> Infrastruktur, Prozesse) und weniger auf Work Output (tatsaechlichen
> Mehrwert durch Applikationen mit Business-Logik).
Falsch ! IT-Ops sind in der Regel die VM's, Container und all die verschiedenen LoadBalancing und HA Techniken verstehen. Entwickler und "Entscheider" sind das nicht. Es heißt ja nicht umsonst "Schuster bleib bei Deinen Leisten"

> Wenn du heute die User
> von Kubernetes fragst, wird dir keiner sagen: wir brauchen VMs. Und das
> sind die Leute, die heute das Gehoer vom CIO haben.
Heute ? Kubernetes ist gerade mal 3 Jahre alt und vielleicht mal 1.5 Jahre davon kein Beta mehr...gehör haben diese Leute nicht mehr lange, da IT-Infrastruktur in die Hände von Profis gehört und nicht "Usern". Also den CIO will ich geifern hören, wenn bekannt wird das ein Server mit 2 und mehr CPU's nur für Container genutzt wird. Container laufen innerhalb von VM's....VM's sind die logische Unterteilung von Hardware-Ressourcen in der dann ein seriöses Betriebssystem läuft, das wiederum auch einen Dienst hortet. Dieser Dienst ist z.b. Docker. Einen physischen und leistungsstarken Computer nur für Docker und Kubernetes zu nutzen ist schlicht Verschwendung und unsicher.

Kubernetes ersetzt keinen Server-Failover, Kubernetes ist ein Anwendungs-Failover. Gespickt mit ein paar neumodischen Begriffen, die allesamt unter anderen Namen ur-alt sind.

Ein Server muss erst mal aufgesetzt werden...was zumeist stets ein individueller Prozess ist, da jeder Server unterschiedliche Scripte, Überwachungsmechanism usw. hat. Wenn hier etwas kaputt geht, hilft auch ein Kubernetes nur bedingt, da eine Leistung nun von jemand anderen doppelt erbracht werden muss....zu Lasten des Netzwerkdurchsatzes. Dieser Gap kann mittels VM Migration schneller bewerkstelligt werden.

Stell dir vor, ein Server geht wirklich kaputt, soll ersetzt werden oder so was...da ist eine VM das Mittel der Wahl um das OS schnell auf etwas neuem zu migrieren oder willst du aus der Entfernung Platten verschicken ??? Nicht zu vergessen, VM's haben virtuelle Hardware die dafür sorgen, das ein Umzug zu jeder Maschine mit gleichen Hypervisor möglich macht.

Auch hier nützt dir Kubernetes gar nichts. Kubernetes hat hauptsächlich ganz andere Einsatzzwecke. Doch um generell diese Thematik zu verstehen, braucht es richtige Admins die sich für alles begeistern können. Reine Entwickler, "User" und Entscheider fehlt es an Detailwissen.

Operator arbeiten Hand in Hand mit Entwicklern (human load balancing wenn man so will), da sind zu einseitige Sichtweisen völlig konträr zum agilen DevOps Gedanken.

Pauschal kann man sagen, Kubernetes ist eine weitere Möglichkeit eine Struktur ausfallsicherer zu machen und zu so was gehört auch eine VM (sowie so einiges mehr). Es wird immer physische Server geben, VM's und Container.

So einige Nutzen bewusst kleine VM's für die Kubernetes Master, weil der nicht viel braucht...ein separater Hardware Server ist da finanziell unsinnig.
> Wenn du eine VM einfrieren musst um deine SLA zu halten, setzt ihr
> Container falsch ein.
Ich vermute, Du hast ein grundsätzliches Defizit an der Technik und dem Einsatzzweck von VM's oder Du siehst die Container Technik zu schwarz/weiss. Das hat nichts mit SLA zu tun, sondern schlicht wie schnell ein Host wieder verfügbar ist und Kubernetes wieder sauber balancen kann.
Ein Container MUSS ein Betriebssystem unten drunter haben. Mal davon abgesehen das ein dicker Server mit VM's und Containern während einer normalen Abschreibungsperiode günstiger kommt als einzelne Server ohne VM's. Sicher ist auch hier das USE-CASE Szenario individuell zu betrachten.



1 mal bearbeitet, zuletzt am 06.11.18 21:13 durch Hawk321.

[GodsBoss]

> Container stellen Umgebungen für Programme dar, VM's für Betriebssysteme.
> Das sind ganz andere Ebenen und beide benötigen ihre eigene Art verwaltet,
> gewartet und gepflegt zu werden.
>
> Auf VMs zu verzichten wäre ein riesen Fehler. Die ermöglichen so viel
> Flexibilität, die man bei Bare Metal gar nicht hat. Die werden niemals
> verdrängt werden, nicht im geringsten. Hardware kündigt an, den Geist
> aufzugeben? VM schnell mal einfrieren und auf eine andere Maschine
> verschieben, dann fortsetzten, die Container bekommen davon im günstigsten
> Fall gar nichts mit.

Und wenn sie unangekündigt den Geist aufgibt? Hat man dafür einen Plan? Vermutlich ja, nämlich Instanzen auf anderen Maschinen starten (automatisch, nicht der Admin nachts um zwei). Aber wenn ich das sowieso brauche und habe, muss ich auch keine VMs einfrieren.

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[Doubleslash]

Hawk321 schrieb:
--------------------------------------------------------------------------------

> Falsch ! IT-Ops sind in der Regel die VM's, Container und all die
> verschiedenen LoadBalancing und HA Techniken verstehen. Entwickler und
> "Entscheider" sind das nicht. Es heißt ja nicht umsonst "Schuster bleib bei
> Deinen Leisten"

Das war vielleicht vor 10 Jahren so. In Zeiten von Service Mesh sind all die genannten Punkte durchaus in Griffweite fuer einen Developer. Der ohne jegliche "IT-Ops" wie du sie beschreibst diese Ressourcen und Services provisionieren und konfigurieren kann - deklarativ und ganz so, wie es seine Apps eben brauchen.

>
> > Wenn du heute die User
> > von Kubernetes fragst, wird dir keiner sagen: wir brauchen VMs. Und das
> > sind die Leute, die heute das Gehoer vom CIO haben.
> Heute ? Kubernetes ist gerade mal 3 Jahre alt und vielleicht mal 1.5 Jahre
> davon kein Beta mehr...gehör haben diese Leute nicht mehr lange, da
> IT-Infrastruktur in die Hände von Profis gehört und nicht "Usern".

Dumm nur, dass die "User" scheinbar immer weniger vertrauen in die "Profis" haben, die aktuell die IT-Infrastruktur in der Hand haben. Liegt wohl daran, dass die sich nur fuer Infrastruktur fuer Systeme interessieren und nicht fuer Infrastruktur fuer Applikationen. Anders ist es nicht zu erklaeren, dass in so gut wie jedem groesseren IT-Shop mittlerweile eine neue Art von Shadow-IT Einzug haelt, bei der die Entwickler die Schnauze voll haben von ihrer In-House IT und mit der Kreditkarte sich ihre k8s Cluster einfach bei GKE & Co. holen. Inklusive der ganzen restlichen Infrastruktur fuer moderne Applikationen (Message Queues, FaaS-Provider, CI&CD Tooling, Build Services, Registries etc).
So bekommt man neuen Projekte auch sehr schnell stabil und produktiv waehrend die eigene IT nach 6 Monaten immer noch ueberlegt, wie sie die Infrastruktur aufbauen. Und jetzt ueberleg mal, fuer den sich dann der CIO mehr interessiert.

Kubernetes ist uebrigens 4 Jahre alt, und das ist in 2018 schon eine Ewigkeit fuer eine Platform.

> Also den
> CIO will ich geifern hören, wenn bekannt wird das ein Server mit 2 und mehr
> CPU's nur für Container genutzt wird.

Thanks for having the best server utilization. Said no CIO ever.

> Container laufen innerhalb von
> VM's....VM's sind die logische Unterteilung von Hardware-Ressourcen in der
> dann ein seriöses Betriebssystem läuft, das wiederum auch einen Dienst
> hortet.

Container sind ebenfalls eine logische Unterteilung von Hardware-Ressourcen. Nur eben nicht auf ebene virtualisierter Hardware sondern von Kernel Namespaces und cgroups. Erfuellt letztlich den selben Zweck, nur mit einem Bruchteil des Overheads.

> Dieser Dienst ist z.b. Docker. Einen physischen und
> leistungsstarken Computer nur für Docker und Kubernetes zu nutzen ist
> schlicht Verschwendung und unsicher.

Oh, dann muss Google in den letzten 15 Jahren wohl einiges falsch gemacht haben. Borg hat naemlich genau das gemacht.


> Kubernetes ersetzt keinen Server-Failover, Kubernetes ist ein
> Anwendungs-Failover. Gespickt mit ein paar neumodischen Begriffen, die
> allesamt unter anderen Namen ur-alt sind.

Da hast du dich aber geoutet. Nunja, du ignorierst, dass sich die Anwendungsarchitektur in den letzten 5 Jahren massiv geaendert hat. Stichwort 12-Factor, Reactive und Microservices. Kurzum: keine Anwendung, die heute neu geschrieben wird, benoetigt einen Server-Failover. Nur genug Compute Ressourcen zur Laufzeit und Load Balancer. Das alles andere als uralt. Was uralt ist, ist deine Vorstellung, dass auf Platformen wie Kubernetes immer noch Monolithen laufen, die auf Hardware-Verfuegbarkeit angewiesen sind.

>
> Ein Server muss erst mal aufgesetzt werden...was zumeist stets ein
> individueller Prozess ist, da jeder Server unterschiedliche Scripte,
> Überwachungsmechanism usw. hat. Wenn hier etwas kaputt geht, hilft auch ein
> Kubernetes nur bedingt, da eine Leistung nun von jemand anderen doppelt
> erbracht werden muss....zu Lasten des Netzwerkdurchsatzes. Dieser Gap kann
> mittels VM Migration schneller bewerkstelligt werden.

Du beschreibst wunderbar die IT der 200er Jahre. Ein Server muss erstmal aufgesetzt werden. Weil er unterschiedliche Scripte und Ueberwachungsmechanismen hat. Du meinst in 2018, in Zeiten von DevOps und SRE, sollte das noch ein Mensch machen? Oder ein Mensch mittels VM-Migration intervenieren, falls etwas "kaputt geht"?
Schauen wir uns an wie das wirklich funktioniert: k8s hat eine Anzahl von Worker Nodes, die allesamt stateless sind. Nichtmal eine Cluster-Groesse ist fest definiert - die Knoten melden sich nach dem Boot bei der Control Plane an bzw. selbige wirft sie wieder heraus, wenn nach einiger Zeit kein Hearbeat mehr da ist. Ressourcenprobleme auf einzelnen Knoten werden durch Health-Checks und Auto-Scaling Mechanismen ausgeglichen, die einfach Pods, die auf anderen Knoten starten falls gewisse Antwortzeiten ueber- oder Durchsaetze unterschritten werden. Fallen Knoten ganz aus, passiert das gleiche. Alle cloud-basierten k8s Cluster werden heute auch mit Auto-Scaling betrieben.
Deine VM Migration hat nur wirklich dann einen Vorteil wenn es um planned Downtime geht.

> Stell dir vor, ein Server geht wirklich kaputt, soll ersetzt werden oder so
> was...da ist eine VM das Mittel der Wahl um das OS schnell auf etwas neuem
> zu migrieren oder willst du aus der Entfernung Platten verschicken ???

Mir scheint du hast die Funktionalitaet von k8s nicht wirklich verstanden. OS, VMs, Server... das sind Commoditybegriffe die k8s wegabstrahiert. Solange nur genug davon da ist, wird da gar nix verschoben sondern die Workloads werden einfach woanders neugestartet. Ob das nachher der selbe Server, OS oder VM ist, die vorher runtergegangen ist, ist k8s herzlich egal und aus User-Sicht auch ueberhaupt nicht ersichtlich.

> Nicht zu vergessen, VM's haben virtuelle Hardware die dafür sorgen, das ein
> Umzug zu jeder Maschine mit gleichen Hypervisor möglich macht.

So what. Nochmal: k8s Workloads haengen nicht von der Hardware oder dem OS ab. Es wird durch die Container wegabstrahiert. Daher gibt es auch keinen Grund spezielle Massnahmen zu ergreifen, damit genau die selbe Hardware oder Betriebssystemumgebungen nachher wieder zur Verfuegung stehen. Solange nur genuegend Cores, RAM, Network-Storage und L3-Konnektivitaet da ist, wird k8s sich darum kuemmern, wo deine Workloads laufen.

> Auch hier nützt dir Kubernetes gar nichts. Kubernetes hat hauptsächlich
> ganz andere Einsatzzwecke. Doch um generell diese Thematik zu verstehen,
> braucht es richtige Admins die sich für alles begeistern können. Reine
> Entwickler, "User" und Entscheider fehlt es an Detailwissen.

Ich glaube dir fehlt es an Detailwissen wie eine Container-Platform funktioniert und wie Workloads darauf orchestriert werden. Du doktorst hier an den untersten 5% des Stacks herum.


> Pauschal kann man sagen, Kubernetes ist eine weitere Möglichkeit eine
> Struktur ausfallsicherer zu machen und zu so was gehört auch eine VM (sowie
> so einiges mehr). Es wird immer physische Server geben, VM's und
> Container.

Eine typische Ansicht von Admins. Kubernetes ist Applikations-Infrastruktur, die es enorm vereinfach verteilte Systeme zu kreieren. Da geht es nicht nur um Ausfallsicherheit sondern auch um Aufteilung in verschiedene Services, die damit unabhaengig voneinander skalierbar, wartbar und erweiterbar werden.
Die Ausfallsicherheit kommt durch eine redundante Control Plane (3+ Master) und mehrere Worker Nodes zu Stande. Ob die virtuell oder physisch sind, spielt ueberhaupt keine Rolle.

>
> So einige Nutzen bewusst kleine VM's für die Kubernetes Master, weil der
> nicht viel braucht...ein separater Hardware Server ist da finanziell
> unsinnig.

Du wuerdest dich wundern, was in einem etcd/kube-api Server bei mehreren Tausend Pods abgeht.

> Ich vermute, Du hast ein grundsätzliches Defizit an der Technik und dem
> Einsatzzweck von VM's oder Du siehst die Container Technik zu
> schwarz/weiss.

Das wird es sein.

> Das hat nichts mit SLA zu tun, sondern schlicht wie schnell
> ein Host wieder verfügbar ist und Kubernetes wieder sauber balancen kann.

Genau wie bei Virtualisierung auch, laesst man natuerlich Spare Capacity im Cluster verfuegbar - zu der jeder Knoten beitraegt. Ein ausgefallener Server muss damit nicht sofort wieder verfuegbar sein, weil k8s die Pods einfach auf den verbleibenden System wieder verteilt. Ist doch bei Virtualisierung auch nicht anders?

> Ein Container MUSS ein Betriebssystem unten drunter haben.

Haargenau! Er MUSS aber KEINE VM unter dem OS haben. Nein, er wuesste es nicht mal. Du willst hier Virtualisierung fuer Features positionieren, die mit Kubernetes einfach auf der Ebene nicht mehr gebraucht werden.

> Mal davon
> abgesehen das ein dicker Server mit VM's und Containern während einer
> normalen Abschreibungsperiode günstiger kommt als einzelne Server ohne
> VM's. Sicher ist auch hier das USE-CASE Szenario individuell zu betrachten.

Wenige "dicke" Server vs. viele "kleine" - macht aus k8s keinen Unterschied. Nur dann, wenn du eine massive Anzahl von unabhaenigen k8s Clustern brauchst. In diesem Fall wuerde mich interessieren, wo dieser Anforderung herkommt.

[scroogie]

Schöner Beitrag. Etwas aufgearbeitet könnte da auch ein interessanter Artikel draus werden. Ich würde es aber nicht ganz so polarisierend sehen. Woher kommt diese Einstellung Dev GEGEN Ops? Schlechte Erfahrungen? Es sollte doch Dev MIT Ops sein. Und der Trend geht meiner Meinung nach in die Richtung. Entwickler befassen sich aufgrund der Trends wie Microarchitektur, Asynchronität, Parallelität, Entkopplung mit Message Queues usw. mehr denn je mit Ops Aspekten, und Ops befassen sich mehr mit Architektur- und Entwicklungsfragen.

[Hawk321]

Doubleslash schrieb:
--------------------------------------------------------------------------------

> Dumm nur, dass die "User" scheinbar immer weniger vertrauen in die "Profis"
> haben, die aktuell die IT-Infrastruktur in der Hand haben. Liegt wohl
> daran, dass die sich nur fuer Infrastruktur fuer Systeme interessieren und
> nicht fuer Infrastruktur fuer Applikationen.
Schwachsinn...ein richtiger Admin ist 80% SysOps und 20% Dev. Den ein Operator muss durchaus Scripte schreiben und Acceptance Tests
mit in die CI Pipeline schieben mit Bezug SECURITY, welches ein typisches Gebiet für gute Operator ist. Nicht zu vergessen die Container Tests selbst fernab der eigentlich Applikation. Wie bereits oben geschrieben, das geht Hand in Hand
> Anders ist es nicht zu
> erklaeren, dass in so gut wie jedem groesseren IT-Shop mittlerweile eine
> neue Art von Shadow-IT Einzug haelt, bei der die Entwickler die Schnauze
> voll haben von ihrer In-House IT und mit der Kreditkarte sich ihre k8s
> Cluster einfach bei GKE & Co. holen. Inklusive der ganzen restlichen
> Infrastruktur fuer moderne Applikationen (Message Queues, FaaS-Provider,
> CI&CD Tooling, Build Services, Registries etc).
> So bekommt man neuen Projekte auch sehr schnell stabil und produktiv
> waehrend die eigene IT nach 6 Monaten immer noch ueberlegt, wie sie die
> Infrastruktur aufbauen. Und jetzt ueberleg mal, fuer den sich dann der CIO
> mehr interessiert.
Und wer hat die Kontrolle über die Cloud Struktur und Kubernetes ??? Der Provider ? Der will Geld verdienen und ein Kunde will einen Vertrag mit Leuten haben die Kompetent UND Zuverlässig sind...deine Äusserung nach stirbt die Branche, alle sind nur noch bei AWS und Azure. Linux, Storage, Netzwerk etc...alles tot wegen dem Magic Kubernetes...BULLSHIT.
Hartz4 für alle ???
>
> Kubernetes ist uebrigens 4 Jahre alt, und das ist in 2018 schon eine
> Ewigkeit fuer eine Platform.
wrong....
> > Also den
> > CIO will ich geifern hören, wenn bekannt wird das ein Server mit 2 und
> mehr
> > CPU's nur für Container genutzt wird.
>
> Thanks for having the best server utilization. Said no CIO ever.
Nee ist klar...
> > Container laufen innerhalb von
> > VM's....VM's sind die logische Unterteilung von Hardware-Ressourcen in
> der
> > dann ein seriöses Betriebssystem läuft, das wiederum auch einen Dienst
> > hortet.
>
> Container sind ebenfalls eine logische Unterteilung von
> Hardware-Ressourcen. Nur eben nicht auf ebene virtualisierter Hardware
> sondern von Kernel Namespaces und cgroups. Erfuellt letztlich den selben
> Zweck, nur mit einem Bruchteil des Overheads.
Nicht mal nahe dran...den ganzen seperaten IP Stack vergisst du ??? Gängige Fachliteratur warnt genau vor der Falschannahme,
das alles zuckersüß und wenig Overhead hat....so ist das nicht, jeden falls nicht pauschal.
> > Dieser Dienst ist z.b. Docker. Einen physischen und
> > leistungsstarken Computer nur für Docker und Kubernetes zu nutzen ist
> > schlicht Verschwendung und unsicher.
>
> Oh, dann muss Google in den letzten 15 Jahren wohl einiges falsch gemacht
> haben. Borg hat naemlich genau das gemacht.
Ein Äpfel mit Birnen Vergleich...Google hatte speziell Server für diese Rolle. Firmen, haben eine gewisse Anzahl an Servern die mit anderen
Rollen geteilt werden (der Sinn von VM's). Firmen können nicht mal eben sagen heute 5 Instanzen morgen 100 (unabhängig vom Scale Out Möglichkeiten). Es scheint du haust hier mächtig verschiedene Use Cases durcheinander
>
> > Kubernetes ersetzt keinen Server-Failover, Kubernetes ist ein
> > Anwendungs-Failover. Gespickt mit ein paar neumodischen Begriffen, die
> > allesamt unter anderen Namen ur-alt sind.
>
> Da hast du dich aber geoutet. Nunja, du ignorierst, dass sich die
> Anwendungsarchitektur in den letzten 5 Jahren massiv geaendert hat.
> Stichwort 12-Factor, Reactive und Microservices. Kurzum: keine Anwendung,
> die heute neu geschrieben wird, benoetigt einen Server-Failover.
Nochmals, vergleiche nicht Äpfel mit Birnen. Ein Server braucht einen Failover...ALLES läuft auf einem Server.
> Nur genug
> Compute Ressourcen zur Laufzeit und Load Balancer. Das alles andere als
> uralt. Was uralt ist, ist deine Vorstellung, dass auf Platformen wie
> Kubernetes immer noch Monolithen laufen, die auf Hardware-Verfuegbarkeit
> angewiesen sind.
Wo läuft den Kubernetes den drauf ??? Zuckerwatte ??? Ist der Server weg...so ist der weg. Jemand anderes springt ein...doppelte Arbeit.
Nicht jedes Unternehmen hat mal eben zig Nodes frei...diese Kapazitäten sind eine auch eine Kostenfrage.
>
> >
> > Ein Server muss erst mal aufgesetzt werden...was zumeist stets ein
> > individueller Prozess ist, da jeder Server unterschiedliche Scripte,
> > Überwachungsmechanism usw. hat. Wenn hier etwas kaputt geht, hilft auch
> ein
> > Kubernetes nur bedingt, da eine Leistung nun von jemand anderen doppelt
> > erbracht werden muss....zu Lasten des Netzwerkdurchsatzes. Dieser Gap
> kann
> > mittels VM Migration schneller bewerkstelligt werden.
>
> Du beschreibst wunderbar die IT der 200er Jahre. Ein Server muss erstmal
> aufgesetzt werden. Weil er unterschiedliche Scripte und
> Ueberwachungsmechanismen hat. Du meinst in 2018, in Zeiten von DevOps und
> SRE, sollte das noch ein Mensch machen? Oder ein Mensch mittels
> VM-Migration intervenieren, falls etwas "kaputt geht"?
Stimmt hast Recht...der Java 08/15 Entwickler ist nun der Hecht, Linux Torvalds arbeitslos, alle Unis lehren dummes Zeugs. Vagrant und Ansible ist alles Mist und VMWare, KVM etc. alles nur Schund. Sorry, anscheinend hast du von IT absolut 0 Ahnung. Stattdessen outest Du dich hier als ein Buzzwort getriebener mit einem ganz gefährlichen Halbwissen.

> Schauen wir uns an wie das wirklich funktioniert: k8s hat eine Anzahl von
> Worker Nodes, die allesamt stateless sind. Nichtmal eine Cluster-Groesse
> ist fest definiert - die Knoten melden sich nach dem Boot bei der Control
> Plane an bzw. selbige wirft sie wieder heraus, wenn nach einiger Zeit kein
> Hearbeat mehr da ist. Ressourcenprobleme auf einzelnen Knoten werden durch
> Health-Checks und Auto-Scaling Mechanismen ausgeglichen, die einfach Pods,
> die auf anderen Knoten starten falls gewisse Antwortzeiten ueber- oder
> Durchsaetze unterschritten werden. Fallen Knoten ganz aus, passiert das
> gleiche. Alle cloud-basierten k8s Cluster werden heute auch mit
> Auto-Scaling betrieben.
> Deine VM Migration hat nur wirklich dann einen Vorteil wenn es um planned
> Downtime geht.
Cool, in wenigen Zeilen hast Du bewiesen was ich vermutet habe. Halbwissen.
> > Stell dir vor, ein Server geht wirklich kaputt, soll ersetzt werden oder
> so
> > was...da ist eine VM das Mittel der Wahl um das OS schnell auf etwas
> neuem
> > zu migrieren oder willst du aus der Entfernung Platten verschicken ???
>
> Mir scheint du hast die Funktionalitaet von k8s nicht wirklich verstanden.
> OS, VMs, Server... das sind Commoditybegriffe die k8s wegabstrahiert.
> Solange nur genug davon da ist, wird da gar nix verschoben sondern die
> Workloads werden einfach woanders neugestartet. Ob das nachher der selbe
> Server, OS oder VM ist, die vorher runtergegangen ist, ist k8s herzlich
> egal und aus User-Sicht auch ueberhaupt nicht ersichtlich.
Der Node muss aber da sein...Netzwerktechnisch....Systemtechnisch und leistungstechnisch
> > Nicht zu vergessen, VM's haben virtuelle Hardware die dafür sorgen, das
> ein
> > Umzug zu jeder Maschine mit gleichen Hypervisor möglich macht.
>
> So what. Nochmal: k8s Workloads haengen nicht von der Hardware oder dem OS
> ab. Es wird durch die Container wegabstrahiert. Daher gibt es auch keinen
> Grund spezielle Massnahmen zu ergreifen, damit genau die selbe Hardware
> oder Betriebssystemumgebungen nachher wieder zur Verfuegung stehen. Solange
> nur genuegend Cores, RAM, Network-Storage und L3-Konnektivitaet da ist,
> wird k8s sich darum kuemmern, wo deine Workloads laufen.
Und wieder...du hast offenbar den Zweck von VM's nicht verstanden
> > Auch hier nützt dir Kubernetes gar nichts. Kubernetes hat hauptsächlich
> > ganz andere Einsatzzwecke. Doch um generell diese Thematik zu verstehen,
> > braucht es richtige Admins die sich für alles begeistern können. Reine
> > Entwickler, "User" und Entscheider fehlt es an Detailwissen.
>
> Ich glaube dir fehlt es an Detailwissen wie eine Container-Platform
> funktioniert und wie Workloads darauf orchestriert werden. Du doktorst hier
> an den untersten 5% des Stacks herum.
>
> > Pauschal kann man sagen, Kubernetes ist eine weitere Möglichkeit eine
> > Struktur ausfallsicherer zu machen und zu so was gehört auch eine VM
> (sowie
> > so einiges mehr). Es wird immer physische Server geben, VM's und
> > Container.
>
> Eine typische Ansicht von Admins. Kubernetes ist
> Applikations-Infrastruktur, die es enorm vereinfach verteilte Systeme zu
> kreieren. Da geht es nicht nur um Ausfallsicherheit sondern auch um
> Aufteilung in verschiedene Services, die damit unabhaengig voneinander
> skalierbar, wartbar und erweiterbar werden.
> Die Ausfallsicherheit kommt durch eine redundante Control Plane (3+ Master)
> und mehrere Worker Nodes zu Stande. Ob die virtuell oder physisch sind,
> spielt ueberhaupt keine Rolle.
Ob physisch oder virtuell, das ist egal. Für viele Firmen ist eine VM kostentechnisch das bessere Modell und sehr leicht zu migrieren.

> >
> > So einige Nutzen bewusst kleine VM's für die Kubernetes Master, weil der
> > nicht viel braucht...ein separater Hardware Server ist da finanziell
> > unsinnig.
>
> Du wuerdest dich wundern, was in einem etcd/kube-api Server bei mehreren
> Tausend Pods abgeht.
Nicht jeder braucht tausende PODS....wieder schmeißt du unterschiedliche Szenarien durcheinander.

Ich sehe hier einfach nur jemanden der völlig frustriert nach einem Strohhalm sucht um sich unabhängig von Admins zu machen.
Oft genug gesehen und immer das gleiche...es geht in die Hose. Wenn ein "Entwickler" meint Admin zu spielen, kann nichts gutes bei raus kommen da hinter deinen deklarativen yaml,json Files eine Menge tief greifendes Know-How benötigt wird.

Andersrum, wird kein Admin ein reinrassiger Entwickler werden....aber egal.



1 mal bearbeitet, zuletzt am 07.11.18 19:43 durch Hawk321.

[elgooG]

Gamma Ray Burst schrieb:
--------------------------------------------------------------------------------
> Das hängt davon ab, Docker-Machine installiert zB Virtual box.
>
> Ja das ist kein Kubernetes, aber am Ende läuft es darauf hinaus das man das
> ganze Data Center virtualisiert.
>
> Wenn man es braucht ... hängt vom Anwendungsfall ab.

Das was du meinst ist die alte Toolbox für Entwickler, weil Windows auch im Jahre 2018 noch keine native Unterstützung hat. Container können in einem Linux Server direkt auf der Hardware laufen. Um genau zu sein gibt es Container sogar nur darum ohne Overhead multipler VMs einerseits Anwendungen besser voneinander isolieren zu können und gleichzeitig insgesamt den Overhead von virtuellen Maschinen loszuwerden. Selbst der Hypervisor von VMware kann Container direkt ohne VM ausführen.

Der OP hat damit schon recht, der einzige sinnvolle Grund für Container in VMS sind irgendwelche Serviceangebote.