De Ikoula wiki - Benutzerbeiträge [de]

Einsatz eines Gitea-Stacks

2021-07-30T09:39:50Z

Ikbot: Die Seite wurde neu angelegt: „:fr:Déployer une stack Gitea…“

[[:fr:Déployer une stack Gitea]][[fr:Déployer une stack Gitea]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Gitea-stack implementeren]][[nl:Een Gitea-stack implementeren]]
[[:it:Distribuire uno stack Gitea]][[it:Distribuire uno stack Gitea]]
[[:pt:Implantação de uma pilha de Gitea]][[pt:Implantação de uma pilha de Gitea]]
[[:es:Despliegue de una pila Gitea]][[es:Despliegue de una pila Gitea]]
[[:en:Deploy a Gitea stack]][[en:Deploy a Gitea stack]]
[[:fr:Déployer une stack Gitea]][[fr:Déployer une stack Gitea]]

{{#seo:
|title=Einsatz eines Gitea-Stacks
|titlemode=replace
|keywords=Gitea
|description=Um einen Gitea-Stack einzusetzen, können Sie der offiziellen Projektdokumentation folgen
|og:type=article
|og:image=https://fr-wiki.ikoula.com/resources/assets/logo_ikwiki.png

}}

== Voraussetzungen ==

Um einen Gitea ''Stack'' einzusetzen, können Sie der offiziellen Projektdokumentation folgen:

[https://docs.gitea.io/en-us/install-with-docker/ Gitea-Dokumentation]

Hierfür sollten Sie über :

ein funktionierendes GNU/Linux-System, auf das Sie über SSH zugreifen können
eine funktionierende Installation von Docker und Docker Compose
 
 
Sie können Gitea von einer physischen Maschine, einer virtuellen Maschine oder von einer Ikoula One Cloud-Instanz aus installieren.

== Einsatz von Gitea ==

Einsatz des "Stack '''Gitea''' Der Stack wird mit Hilfe einer Kompositionsdatei bereitgestellt, die Sie zuvor erstellt oder in einem Ordner abgelegt haben, auf den der Benutzer Zugriff hat.

In unserem Beispiel werden wir Postgres als DBMS einsetzen (Sie können es durch ein Login/Passwort-Paar Ihrer Wahl ersetzen):

<syntaxhighlight lang=bash>
Gitea version: "2"

networks:
gitea:
external: false

services:
server:
image: gitea/gitea:latest
environment:
- USER_UID=1000
- USER_GID=1000
restart: always
networks:
- gitea
volumes:
- /var/lib/persistent/gitea:/data
ports:
- "80:3000"
- "222:22"
depends_on:
- db

db:
image: postgres:9.6
restart: always
environment:
- POSTGRES_USER=gitea
- POSTGRES_PASSWORD=gitea
- POSTGRES_DB=gitea
networks:
- gitea
volumes:
- /var/lib/persistent/postgres:/var/lib/postgresql/data
</syntaxhighlight>

Stellen Sie sicher, dass Sie die Ports 3000 und 222 in TCP auf dem Host geöffnet haben.

So führen Sie Ihre compose.yml-Datei im Hintergrund aus dem Ordner aus, in dem die Datei gespeichert ist:

<syntaxhighlight lang=bash># docker-compose up -d</syntaxhighlight>

Sie müssen nur noch das Formular ausfüllen, um die Installation abzuschließen und Zugang zu Ihrem Gitea-Stack zu erhalten.

<syntaxhighlight lang=bash>http://VOTRE_IP</syntaxhighlight>

Sie sollten nun in der Lage sein, sich mit Ihrem Gitea-Stack über Web und SSH von den auf Ihrer Firewall autorisierten IPs aus zu verbinden.
Es ist möglich, Ihren Gitea-Stack mit anderen Diensten hinter einem Reverse-Proxy zusammenzuarbeiten. In diesem Fall können Sie den lauschenden Port des WEB-Dienstes nach Belieben ändern.

[[File:Gitea-deploy3.png|alt=Gitea]]

[[Category:Docker]]
[[Catégorie :Cloudstack]]
[[Catégorie :Cloud public]]
[[Category:Dedizierter Server]]
[[Category:Linux]]
[[Category:FLEX]]
[[Catégorie :Cloud]]
[[Category:VPS-Server]]

Duplizieren einer Instanz in einer anderen Zone

2021-07-29T15:36:22Z

Ikbot:

[[:ro:Duplicarea unei instanțe în altă zonă]][[ro:Duplicarea unei instanțe în altă zonă]]
[[:ru:Дублирование экземпляра в другой зоне]][[ru:Дублирование экземпляра в другой зоне]]
[[:pl:Duplikuj instancję w innej strefie]][[pl:Duplikuj instancję w innej strefie]]
[[:ja:インスタンスを別のゾーンに複製する]][[ja:インスタンスを別のゾーンに複製する]]
[[:zh:在另一区复制一个实例]][[zh:在另一区复制一个实例]]
[[:fr:Dupliquer une instance dans une autre zone]][[fr:Dupliquer une instance dans une autre zone]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Dupliquer une instance dans une autre zone|hier]] ansehen. 
[[:nl:Een instantie in een andere zone dupliceren]][[nl:Een instantie in een andere zone dupliceren]]
[[:it:Duplicare un'istanza in un'altra zona]][[it:Duplicare un'istanza in un'altra zona]]
[[:pt:Duplicar uma instância noutra zona]][[pt:Duplicar uma instância noutra zona]]
[[:es:Duplicar una instancia en otra zona]][[es:Duplicar una instancia en otra zona]]
[[:en:Duplicate an instance in another zone]][[en:Duplicate an instance in another zone]]
==Anwendungsfälle==
Ich habe eine Instanz in einer BASIC-Zone erstellt. Ich möchte meine Instanz in eine ADVANCE-Zone verschieben, um von den Funktionen dieser Zone zu profitieren.
Ich möchte meine Infrastruktur identisch in einer anderen Zone einsetzen, um eine Testinfrastruktur zu haben.

==Voraussetzungen==
Ich möchte meine Infrastruktur in einer anderen Zone einrichten, um eine Testinfrastruktur zu haben * Ich benötige keine Datenfestplatte

==Abwickeln==
Erstellen Sie ein Modell meiner cf-Instanz: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]
# Kopiere meine Vorlage in eine andere Zone cf: [[Copier_mon_modele_dans_une_autre_zone]]
# Meine Vorlage bereitstellen cf: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]

[[Category:Cloud_public]]
[[Catégorie :Cloud]]

Duplizieren einer Instanz in einer anderen Zone

2021-07-29T15:35:26Z

Ikbot:

[[:ru:Дублирование экземпляра в другой зоне]][[ru:Дублирование экземпляра в другой зоне]]
[[:pl:Duplikuj instancję w innej strefie]][[pl:Duplikuj instancję w innej strefie]]
[[:ja:インスタンスを別のゾーンに複製する]][[ja:インスタンスを別のゾーンに複製する]]
[[:zh:在另一区复制一个实例]][[zh:在另一区复制一个实例]]
[[:fr:Dupliquer une instance dans une autre zone]][[fr:Dupliquer une instance dans une autre zone]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Dupliquer une instance dans une autre zone|hier]] ansehen. 
[[:nl:Een instantie in een andere zone dupliceren]][[nl:Een instantie in een andere zone dupliceren]]
[[:it:Duplicare un'istanza in un'altra zona]][[it:Duplicare un'istanza in un'altra zona]]
[[:pt:Duplicar uma instância noutra zona]][[pt:Duplicar uma instância noutra zona]]
[[:es:Duplicar una instancia en otra zona]][[es:Duplicar una instancia en otra zona]]
[[:en:Duplicate an instance in another zone]][[en:Duplicate an instance in another zone]]
==Anwendungsfälle==
Ich habe eine Instanz in einer BASIC-Zone erstellt. Ich möchte meine Instanz in eine ADVANCE-Zone verschieben, um von den Funktionen dieser Zone zu profitieren.
Ich möchte meine Infrastruktur identisch in einer anderen Zone einsetzen, um eine Testinfrastruktur zu haben.

==Voraussetzungen==
Ich möchte meine Infrastruktur in einer anderen Zone einrichten, um eine Testinfrastruktur zu haben * Ich benötige keine Datenfestplatte

==Abwickeln==
Erstellen Sie ein Modell meiner cf-Instanz: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]
# Kopiere meine Vorlage in eine andere Zone cf: [[Copier_mon_modele_dans_une_autre_zone]]
# Meine Vorlage bereitstellen cf: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]

[[Category:Cloud_public]]
[[Catégorie :Cloud]]

Duplizieren einer Instanz in einer anderen Zone

2021-07-29T15:34:44Z

Ikbot:

[[:pl:Duplikuj instancję w innej strefie]][[pl:Duplikuj instancję w innej strefie]]
[[:ja:インスタンスを別のゾーンに複製する]][[ja:インスタンスを別のゾーンに複製する]]
[[:zh:在另一区复制一个实例]][[zh:在另一区复制一个实例]]
[[:fr:Dupliquer une instance dans une autre zone]][[fr:Dupliquer une instance dans une autre zone]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Dupliquer une instance dans une autre zone|hier]] ansehen. 
[[:nl:Een instantie in een andere zone dupliceren]][[nl:Een instantie in een andere zone dupliceren]]
[[:it:Duplicare un'istanza in un'altra zona]][[it:Duplicare un'istanza in un'altra zona]]
[[:pt:Duplicar uma instância noutra zona]][[pt:Duplicar uma instância noutra zona]]
[[:es:Duplicar una instancia en otra zona]][[es:Duplicar una instancia en otra zona]]
[[:en:Duplicate an instance in another zone]][[en:Duplicate an instance in another zone]]
==Anwendungsfälle==
Ich habe eine Instanz in einer BASIC-Zone erstellt. Ich möchte meine Instanz in eine ADVANCE-Zone verschieben, um von den Funktionen dieser Zone zu profitieren.
Ich möchte meine Infrastruktur identisch in einer anderen Zone einsetzen, um eine Testinfrastruktur zu haben.

==Voraussetzungen==
Ich möchte meine Infrastruktur in einer anderen Zone einrichten, um eine Testinfrastruktur zu haben * Ich benötige keine Datenfestplatte

==Abwickeln==
Erstellen Sie ein Modell meiner cf-Instanz: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]
# Kopiere meine Vorlage in eine andere Zone cf: [[Copier_mon_modele_dans_une_autre_zone]]
# Meine Vorlage bereitstellen cf: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]

[[Category:Cloud_public]]
[[Catégorie :Cloud]]

Duplizieren einer Instanz in einer anderen Zone

2021-07-29T15:34:02Z

Ikbot:

[[:ja:インスタンスを別のゾーンに複製する]][[ja:インスタンスを別のゾーンに複製する]]
[[:zh:在另一区复制一个实例]][[zh:在另一区复制一个实例]]
[[:fr:Dupliquer une instance dans une autre zone]][[fr:Dupliquer une instance dans une autre zone]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Dupliquer une instance dans une autre zone|hier]] ansehen. 
[[:nl:Een instantie in een andere zone dupliceren]][[nl:Een instantie in een andere zone dupliceren]]
[[:it:Duplicare un'istanza in un'altra zona]][[it:Duplicare un'istanza in un'altra zona]]
[[:pt:Duplicar uma instância noutra zona]][[pt:Duplicar uma instância noutra zona]]
[[:es:Duplicar una instancia en otra zona]][[es:Duplicar una instancia en otra zona]]
[[:en:Duplicate an instance in another zone]][[en:Duplicate an instance in another zone]]
==Anwendungsfälle==
Ich habe eine Instanz in einer BASIC-Zone erstellt. Ich möchte meine Instanz in eine ADVANCE-Zone verschieben, um von den Funktionen dieser Zone zu profitieren.
Ich möchte meine Infrastruktur identisch in einer anderen Zone einsetzen, um eine Testinfrastruktur zu haben.

==Voraussetzungen==
Ich möchte meine Infrastruktur in einer anderen Zone einrichten, um eine Testinfrastruktur zu haben * Ich benötige keine Datenfestplatte

==Abwickeln==
Erstellen Sie ein Modell meiner cf-Instanz: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]
# Kopiere meine Vorlage in eine andere Zone cf: [[Copier_mon_modele_dans_une_autre_zone]]
# Meine Vorlage bereitstellen cf: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]

[[Category:Cloud_public]]
[[Catégorie :Cloud]]

Duplizieren einer Instanz in einer anderen Zone

2021-07-29T15:33:16Z

Ikbot:

[[:zh:在另一区复制一个实例]][[zh:在另一区复制一个实例]]
[[:fr:Dupliquer une instance dans une autre zone]][[fr:Dupliquer une instance dans une autre zone]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Dupliquer une instance dans une autre zone|hier]] ansehen. 
[[:nl:Een instantie in een andere zone dupliceren]][[nl:Een instantie in een andere zone dupliceren]]
[[:it:Duplicare un'istanza in un'altra zona]][[it:Duplicare un'istanza in un'altra zona]]
[[:pt:Duplicar uma instância noutra zona]][[pt:Duplicar uma instância noutra zona]]
[[:es:Duplicar una instancia en otra zona]][[es:Duplicar una instancia en otra zona]]
[[:en:Duplicate an instance in another zone]][[en:Duplicate an instance in another zone]]
==Anwendungsfälle==
Ich habe eine Instanz in einer BASIC-Zone erstellt. Ich möchte meine Instanz in eine ADVANCE-Zone verschieben, um von den Funktionen dieser Zone zu profitieren.
Ich möchte meine Infrastruktur identisch in einer anderen Zone einsetzen, um eine Testinfrastruktur zu haben.

==Voraussetzungen==
Ich möchte meine Infrastruktur in einer anderen Zone einrichten, um eine Testinfrastruktur zu haben * Ich benötige keine Datenfestplatte

==Abwickeln==
Erstellen Sie ein Modell meiner cf-Instanz: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]
# Kopiere meine Vorlage in eine andere Zone cf: [[Copier_mon_modele_dans_une_autre_zone]]
# Meine Vorlage bereitstellen cf: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]

[[Category:Cloud_public]]
[[Catégorie :Cloud]]

Duplizieren einer Instanz in einer anderen Zone

2021-07-29T15:32:40Z

Ikbot: Die Seite wurde neu angelegt: „</span…“

[[:fr:Dupliquer une instance dans une autre zone]][[fr:Dupliquer une instance dans une autre zone]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Dupliquer une instance dans une autre zone|hier]] ansehen. 
[[:nl:Een instantie in een andere zone dupliceren]][[nl:Een instantie in een andere zone dupliceren]]
[[:it:Duplicare un'istanza in un'altra zona]][[it:Duplicare un'istanza in un'altra zona]]
[[:pt:Duplicar uma instância noutra zona]][[pt:Duplicar uma instância noutra zona]]
[[:es:Duplicar una instancia en otra zona]][[es:Duplicar una instancia en otra zona]]
[[:en:Duplicate an instance in another zone]][[en:Duplicate an instance in another zone]]
==Anwendungsfälle==
Ich habe eine Instanz in einer BASIC-Zone erstellt. Ich möchte meine Instanz in eine ADVANCE-Zone verschieben, um von den Funktionen dieser Zone zu profitieren.
Ich möchte meine Infrastruktur identisch in einer anderen Zone einsetzen, um eine Testinfrastruktur zu haben.

==Voraussetzungen==
Ich möchte meine Infrastruktur in einer anderen Zone einrichten, um eine Testinfrastruktur zu haben * Ich benötige keine Datenfestplatte

==Abwickeln==
Erstellen Sie ein Modell meiner cf-Instanz: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]
# Kopiere meine Vorlage in eine andere Zone cf: [[Copier_mon_modele_dans_une_autre_zone]]
# Meine Vorlage bereitstellen cf: [[Cr%C3%A9er_un_mod%C3%A8le_%C3%A0_partir_de_ma_VM]]

[[Category:Cloud_public]]
[[Catégorie :Cloud]]

Docker-Debugging eines Containers, der sofort anhält

2021-07-29T15:27:50Z

Ikbot:

[[:ro:Docker depanarea unui container care se oprește imediat]][[ro:Docker depanarea unui container care se oprește imediat]]
[[:ru:Docker отлаживает контейнер, который немедленно останавливается]][[ru:Docker отлаживает контейнер, который немедленно останавливается]]
[[:pl:Docker debuguje kontener, który natychmiast się zatrzymuje]][[pl:Docker debuguje kontener, który natychmiast się zatrzymuje]]
[[:ja:すぐに停止するコンテナをDockerでデバッグする]][[ja:すぐに停止するコンテナをDockerでデバッグする]]
[[:zh:Docker调试一个立即停止的容器]][[zh:Docker调试一个立即停止的容器]]
[[:fr:Docker déboguer un conteneur qui se stop immédiatement]][[fr:Docker déboguer un conteneur qui se stop immédiatement]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Docker déboguer un conteneur qui se stop immédiatement|hier]] ansehen. 
[[:nl:Docker debuggen van een container die onmiddellijk stopt]][[nl:Docker debuggen van een container die onmiddellijk stopt]]
[[:it:Docker esegue il debug di un contenitore che si ferma immediatamente]][[it:Docker esegue il debug di un contenitore che si ferma immediatamente]]
[[:pt:Depuração de um contentor que pára imediatamente]][[pt:Depuração de um contentor que pára imediatamente]]
[[:es:Docker depurando un contenedor que se detiene inmediatamente]][[es:Docker depurando un contenedor que se detiene inmediatamente]]
[[:en:Docker debugging a container that stops immediately]][[en:Docker debugging a container that stops immediately]]


==Einführung== 
Wenn Sie Ihr '''Docker-Lauf''' der Container sofort anhält, ist es möglich, dass Ihr ''PID 1'' nicht gestartet wurde, Sie aber in den Protokollen nichts sehen und in Ihrem Container nichts überprüfen können. 
Wir werden sehen, wie man einen ''Docker'' Container debuggt, der sofort anhält, indem man ihm einen Befehl unter ''PID 1'' aufzwingt.

==Kurs== 
Starten Sie Ihr '''Docker-Lauf''' mit dem unten stehenden Befehl:
<pre>
$ docker run -d --name NOM_DE_VOTRE_CONTENEUR NOM_DE_VOTRE_IMAGE /bin/sh -c "while true; do sleep 2; df -h; done"
</pre>

Dadurch wird Ihr '''PID 1''' läuft noch, so dass Sie in Ihrem Container überprüfen können, ob Ihre Dienste laufen und sie debuggen können.



 
Cet article vous a semblé utile ? <vote />




<comments />


[[Category:Linux]]
[[Category:Docker]]

Docker-Debugging eines Containers, der sofort anhält

2021-07-29T15:25:45Z

Ikbot:

[[:ru:Docker отлаживает контейнер, который немедленно останавливается]][[ru:Docker отлаживает контейнер, который немедленно останавливается]]
[[:pl:Docker debuguje kontener, który natychmiast się zatrzymuje]][[pl:Docker debuguje kontener, który natychmiast się zatrzymuje]]
[[:ja:すぐに停止するコンテナをDockerでデバッグする]][[ja:すぐに停止するコンテナをDockerでデバッグする]]
[[:zh:Docker调试一个立即停止的容器]][[zh:Docker调试一个立即停止的容器]]
[[:fr:Docker déboguer un conteneur qui se stop immédiatement]][[fr:Docker déboguer un conteneur qui se stop immédiatement]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Docker déboguer un conteneur qui se stop immédiatement|hier]] ansehen. 
[[:nl:Docker debuggen van een container die onmiddellijk stopt]][[nl:Docker debuggen van een container die onmiddellijk stopt]]
[[:it:Docker esegue il debug di un contenitore che si ferma immediatamente]][[it:Docker esegue il debug di un contenitore che si ferma immediatamente]]
[[:pt:Depuração de um contentor que pára imediatamente]][[pt:Depuração de um contentor que pára imediatamente]]
[[:es:Docker depurando un contenedor que se detiene inmediatamente]][[es:Docker depurando un contenedor que se detiene inmediatamente]]
[[:en:Docker debugging a container that stops immediately]][[en:Docker debugging a container that stops immediately]]


==Einführung== 
Wenn Sie Ihr '''Docker-Lauf''' der Container sofort anhält, ist es möglich, dass Ihr ''PID 1'' nicht gestartet wurde, Sie aber in den Protokollen nichts sehen und in Ihrem Container nichts überprüfen können. 
Wir werden sehen, wie man einen ''Docker'' Container debuggt, der sofort anhält, indem man ihm einen Befehl unter ''PID 1'' aufzwingt.

==Kurs== 
Starten Sie Ihr '''Docker-Lauf''' mit dem unten stehenden Befehl:
<pre>
$ docker run -d --name NOM_DE_VOTRE_CONTENEUR NOM_DE_VOTRE_IMAGE /bin/sh -c "while true; do sleep 2; df -h; done"
</pre>

Dadurch wird Ihr '''PID 1''' läuft noch, so dass Sie in Ihrem Container überprüfen können, ob Ihre Dienste laufen und sie debuggen können.



 
Cet article vous a semblé utile ? <vote />




<comments />


[[Category:Linux]]
[[Category:Docker]]

Docker-Debugging eines Containers, der sofort anhält

2021-07-29T15:23:09Z

Ikbot:

[[:pl:Docker debuguje kontener, który natychmiast się zatrzymuje]][[pl:Docker debuguje kontener, który natychmiast się zatrzymuje]]
[[:ja:すぐに停止するコンテナをDockerでデバッグする]][[ja:すぐに停止するコンテナをDockerでデバッグする]]
[[:zh:Docker调试一个立即停止的容器]][[zh:Docker调试一个立即停止的容器]]
[[:fr:Docker déboguer un conteneur qui se stop immédiatement]][[fr:Docker déboguer un conteneur qui se stop immédiatement]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Docker déboguer un conteneur qui se stop immédiatement|hier]] ansehen. 
[[:nl:Docker debuggen van een container die onmiddellijk stopt]][[nl:Docker debuggen van een container die onmiddellijk stopt]]
[[:it:Docker esegue il debug di un contenitore che si ferma immediatamente]][[it:Docker esegue il debug di un contenitore che si ferma immediatamente]]
[[:pt:Depuração de um contentor que pára imediatamente]][[pt:Depuração de um contentor que pára imediatamente]]
[[:es:Docker depurando un contenedor que se detiene inmediatamente]][[es:Docker depurando un contenedor que se detiene inmediatamente]]
[[:en:Docker debugging a container that stops immediately]][[en:Docker debugging a container that stops immediately]]


==Einführung== 
Wenn Sie Ihr '''Docker-Lauf''' der Container sofort anhält, ist es möglich, dass Ihr ''PID 1'' nicht gestartet wurde, Sie aber in den Protokollen nichts sehen und in Ihrem Container nichts überprüfen können. 
Wir werden sehen, wie man einen ''Docker'' Container debuggt, der sofort anhält, indem man ihm einen Befehl unter ''PID 1'' aufzwingt.

==Kurs== 
Starten Sie Ihr '''Docker-Lauf''' mit dem unten stehenden Befehl:
<pre>
$ docker run -d --name NOM_DE_VOTRE_CONTENEUR NOM_DE_VOTRE_IMAGE /bin/sh -c "while true; do sleep 2; df -h; done"
</pre>

Dadurch wird Ihr '''PID 1''' läuft noch, so dass Sie in Ihrem Container überprüfen können, ob Ihre Dienste laufen und sie debuggen können.



 
Cet article vous a semblé utile ? <vote />




<comments />


[[Category:Linux]]
[[Category:Docker]]

Docker-Debugging eines Containers, der sofort anhält

2021-07-29T15:22:16Z

Ikbot:

[[:ja:すぐに停止するコンテナをDockerでデバッグする]][[ja:すぐに停止するコンテナをDockerでデバッグする]]
[[:zh:Docker调试一个立即停止的容器]][[zh:Docker调试一个立即停止的容器]]
[[:fr:Docker déboguer un conteneur qui se stop immédiatement]][[fr:Docker déboguer un conteneur qui se stop immédiatement]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Docker déboguer un conteneur qui se stop immédiatement|hier]] ansehen. 
[[:nl:Docker debuggen van een container die onmiddellijk stopt]][[nl:Docker debuggen van een container die onmiddellijk stopt]]
[[:it:Docker esegue il debug di un contenitore che si ferma immediatamente]][[it:Docker esegue il debug di un contenitore che si ferma immediatamente]]
[[:pt:Depuração de um contentor que pára imediatamente]][[pt:Depuração de um contentor que pára imediatamente]]
[[:es:Docker depurando un contenedor que se detiene inmediatamente]][[es:Docker depurando un contenedor que se detiene inmediatamente]]
[[:en:Docker debugging a container that stops immediately]][[en:Docker debugging a container that stops immediately]]


==Einführung== 
Wenn Sie Ihr '''Docker-Lauf''' der Container sofort anhält, ist es möglich, dass Ihr ''PID 1'' nicht gestartet wurde, Sie aber in den Protokollen nichts sehen und in Ihrem Container nichts überprüfen können. 
Wir werden sehen, wie man einen ''Docker'' Container debuggt, der sofort anhält, indem man ihm einen Befehl unter ''PID 1'' aufzwingt.

==Kurs== 
Starten Sie Ihr '''Docker-Lauf''' mit dem unten stehenden Befehl:
<pre>
$ docker run -d --name NOM_DE_VOTRE_CONTENEUR NOM_DE_VOTRE_IMAGE /bin/sh -c "while true; do sleep 2; df -h; done"
</pre>

Dadurch wird Ihr '''PID 1''' läuft noch, so dass Sie in Ihrem Container überprüfen können, ob Ihre Dienste laufen und sie debuggen können.



 
Cet article vous a semblé utile ? <vote />




<comments />


[[Category:Linux]]
[[Category:Docker]]

Docker-Debugging eines Containers, der sofort anhält

2021-07-29T15:21:28Z

Ikbot:

[[:zh:Docker调试一个立即停止的容器]][[zh:Docker调试一个立即停止的容器]]
[[:fr:Docker déboguer un conteneur qui se stop immédiatement]][[fr:Docker déboguer un conteneur qui se stop immédiatement]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Docker déboguer un conteneur qui se stop immédiatement|hier]] ansehen. 
[[:nl:Docker debuggen van een container die onmiddellijk stopt]][[nl:Docker debuggen van een container die onmiddellijk stopt]]
[[:it:Docker esegue il debug di un contenitore che si ferma immediatamente]][[it:Docker esegue il debug di un contenitore che si ferma immediatamente]]
[[:pt:Depuração de um contentor que pára imediatamente]][[pt:Depuração de um contentor que pára imediatamente]]
[[:es:Docker depurando un contenedor que se detiene inmediatamente]][[es:Docker depurando un contenedor que se detiene inmediatamente]]
[[:en:Docker debugging a container that stops immediately]][[en:Docker debugging a container that stops immediately]]


==Einführung== 
Wenn Sie Ihr '''Docker-Lauf''' der Container sofort anhält, ist es möglich, dass Ihr ''PID 1'' nicht gestartet wurde, Sie aber in den Protokollen nichts sehen und in Ihrem Container nichts überprüfen können. 
Wir werden sehen, wie man einen ''Docker'' Container debuggt, der sofort anhält, indem man ihm einen Befehl unter ''PID 1'' aufzwingt.

==Kurs== 
Starten Sie Ihr '''Docker-Lauf''' mit dem unten stehenden Befehl:
<pre>
$ docker run -d --name NOM_DE_VOTRE_CONTENEUR NOM_DE_VOTRE_IMAGE /bin/sh -c "while true; do sleep 2; df -h; done"
</pre>

Dadurch wird Ihr '''PID 1''' läuft noch, so dass Sie in Ihrem Container überprüfen können, ob Ihre Dienste laufen und sie debuggen können.



 
Cet article vous a semblé utile ? <vote />




<comments />


[[Category:Linux]]
[[Category:Docker]]

Docker-Debugging eines Containers, der sofort anhält

2021-07-29T15:20:48Z

Ikbot: Die Seite wurde neu angelegt: „<span data-link_translate_fr_title="Docker déboguer un conteneur qui se stop immédiatement" data-link_translate_fr_url="Docker déboguer un conteneur qui se…“

[[:fr:Docker déboguer un conteneur qui se stop immédiatement]][[fr:Docker déboguer un conteneur qui se stop immédiatement]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Docker déboguer un conteneur qui se stop immédiatement|hier]] ansehen. 
[[:nl:Docker debuggen van een container die onmiddellijk stopt]][[nl:Docker debuggen van een container die onmiddellijk stopt]]
[[:it:Docker esegue il debug di un contenitore che si ferma immediatamente]][[it:Docker esegue il debug di un contenitore che si ferma immediatamente]]
[[:pt:Depuração de um contentor que pára imediatamente]][[pt:Depuração de um contentor que pára imediatamente]]
[[:es:Docker depurando un contenedor que se detiene inmediatamente]][[es:Docker depurando un contenedor que se detiene inmediatamente]]
[[:en:Docker debugging a container that stops immediately]][[en:Docker debugging a container that stops immediately]]


==Einführung== 
Wenn Sie Ihr '''Docker-Lauf''' der Container sofort anhält, ist es möglich, dass Ihr ''PID 1'' nicht gestartet wurde, Sie aber in den Protokollen nichts sehen und in Ihrem Container nichts überprüfen können. 
Wir werden sehen, wie man einen ''Docker'' Container debuggt, der sofort anhält, indem man ihm einen Befehl unter ''PID 1'' aufzwingt.

==Kurs== 
Starten Sie Ihr '''Docker-Lauf''' mit dem unten stehenden Befehl:
<pre>
$ docker run -d --name NOM_DE_VOTRE_CONTENEUR NOM_DE_VOTRE_IMAGE /bin/sh -c "while true; do sleep 2; df -h; done"
</pre>

Dadurch wird Ihr '''PID 1''' läuft noch, so dass Sie in Ihrem Container überprüfen können, ob Ihre Dienste laufen und sie debuggen können.



 
Cet article vous a semblé utile ? <vote />




<comments />


[[Category:Linux]]
[[Category:Docker]]

Diagnose einer defekten Linux-Festplatte

2021-07-29T15:10:31Z

Ikbot:

[[:ro:Diagnosticarea unui disc Linux defect]][[ro:Diagnosticarea unui disc Linux defect]]
[[:ru:Диагностика неисправного диска Linux]][[ru:Диагностика неисправного диска Linux]]
[[:pl:Diagnozowanie uszkodzonego dysku w systemie Linux]][[pl:Diagnozowanie uszkodzonego dysku w systemie Linux]]
[[:ja:故障したLinuxディスクの診断]][[ja:故障したLinuxディスクの診断]]
[[:zh:诊断一个有问题的Linux磁盘]][[zh:诊断一个有问题的Linux磁盘]]
[[:fr:Diagnostic d'un disque défectueux Linux]][[fr:Diagnostic d'un disque défectueux Linux]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Diagnostic d'un disque défectueux Linux|hier]] ansehen. 
[[:nl:Diagnose van een defecte Linux-schijf]][[nl:Diagnose van een defecte Linux-schijf]]
[[:it:Diagnosticare un disco Linux difettoso]][[it:Diagnosticare un disco Linux difettoso]]
[[:pt:Diagnosticar um disco Linux defeituoso]][[pt:Diagnosticar um disco Linux defeituoso]]
[[:es:Diagnóstico de un disco Linux defectuoso]][[es:Diagnóstico de un disco Linux defectuoso]]
[[:en:Diagnosing a faulty Linux disk]][[en:Diagnosing a faulty Linux disk]]
== Einführung ==

Dieser Artikel zielt darauf ab, eine defekte Festplatte auf einem Linux-Server zu diagnostizieren und zu identifizieren.

Die folgenden Aktionen können von einem Linux-Terminal oder einem Netboot aus durchgeführt werden.

== Die Aufträge ==

==Wenn Ihr Betriebssystem über RAID verfügt == =

Als ersten Schritt können Sie die folgenden Befehle ausführen:

<code> cat /proc/mdstat </code>

Sie erhalten dann ein ähnliches Ergebnis wie das folgende:

<pre>
[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
read_ahead 1024 sectors
md2 : active raid1 sda3[1] sdb3[0]
262016 blocks [2/2] [UU]

md1 : active raid1 sda2[1] sdb2[0]
119684160 blocks [2/2] [UU]

md0 : active raid1 sda1[1] sdb1[0]
102208 blocks [2/2] [UU]

unused devices: <none>

</pre>

Hier können Sie [UU] am Ende jedes logischen Laufwerks sehen. Ein U bedeutet, dass ein Laufwerk korrekt in den RAID-Verbund integriert ist.
Sobald Sie also eine Sequenz wie [_U] sehen, können wir davon ausgehen, dass ein Laufwerk defekt ist.

Sie können auch ein Ergebnis wie dieses erhalten:

<pre>

[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
md3 : active raid1 sda3[0] sdb3[2](F)
439553856 blocks super 1.0 [2/1] [U_]
bitmap: 1/4 pages [4KB], 65536KB chunk

md1 : active raid1 sdb1[2](F) sda1[0]
19529600 blocks super 1.0 [2/1] [U_]

unused devices: <none>

</pre>

In diesem Fall sagt uns das (F), dass die Trennwand defekt ist. In unserem Beispiel sind die Partitionen sdb3 und sdb1 fehlerhaft.

=== Diagnose == =

Um festzustellen, welche Festplatte defekt ist, verwenden wir SMART.

Zu diesem Zweck müssen Sie es installieren:
Abhängig von Ihrer Linux-Distribution kann sich der Befehl ändern:

Für Centos :

<code>
yum install smartmontools
</code>

Für Ubuntu / Debian :

<code>
apt-get install smartmontools
</code>

Sie können dann den folgenden Befehl ausführen, der die vorhandenen Festplatten auflistet:

<code>
smartctl --scan
</code>

Um weitere Informationen über eine Festplatte zu erhalten, verwenden Sie den folgenden Befehl:

<code>
smartctl -iHAl error [NOM DU DISQUE]
</code>

Anschließend wird ein Bericht über den Datenträger erstellt, in dem alle Anomalien aufgeführt sind.
Dieser Bericht besteht aus vier Teilen. Der erste Teil ist die Information über die Festplatte, ihre Seriennummer, das Modell, die Kapazität, ...
Der zweite Teil ist die Rückgabe des SMART-Tests. Wenn das Ergebnis nicht PASSED ist, muss die Festplatte ausgetauscht werden.
Der dritte Teil enthält alle Werte, die durch den Test in Bezug auf die Festplatte erzeugt wurden.
Der letzte Teil sind die Festplattenfehlerprotokolle.

[[Category:Linux]]
[[Category:Dedizierter Server]]

Diagnose einer defekten Linux-Festplatte

2021-07-29T15:09:22Z

Ikbot:

[[:ru:Диагностика неисправного диска Linux]][[ru:Диагностика неисправного диска Linux]]
[[:pl:Diagnozowanie uszkodzonego dysku w systemie Linux]][[pl:Diagnozowanie uszkodzonego dysku w systemie Linux]]
[[:ja:故障したLinuxディスクの診断]][[ja:故障したLinuxディスクの診断]]
[[:zh:诊断一个有问题的Linux磁盘]][[zh:诊断一个有问题的Linux磁盘]]
[[:fr:Diagnostic d'un disque défectueux Linux]][[fr:Diagnostic d'un disque défectueux Linux]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Diagnostic d'un disque défectueux Linux|hier]] ansehen. 
[[:nl:Diagnose van een defecte Linux-schijf]][[nl:Diagnose van een defecte Linux-schijf]]
[[:it:Diagnosticare un disco Linux difettoso]][[it:Diagnosticare un disco Linux difettoso]]
[[:pt:Diagnosticar um disco Linux defeituoso]][[pt:Diagnosticar um disco Linux defeituoso]]
[[:es:Diagnóstico de un disco Linux defectuoso]][[es:Diagnóstico de un disco Linux defectuoso]]
[[:en:Diagnosing a faulty Linux disk]][[en:Diagnosing a faulty Linux disk]]
== Einführung ==

Dieser Artikel zielt darauf ab, eine defekte Festplatte auf einem Linux-Server zu diagnostizieren und zu identifizieren.

Die folgenden Aktionen können von einem Linux-Terminal oder einem Netboot aus durchgeführt werden.

== Die Aufträge ==

==Wenn Ihr Betriebssystem über RAID verfügt == =

Als ersten Schritt können Sie die folgenden Befehle ausführen:

<code> cat /proc/mdstat </code>

Sie erhalten dann ein ähnliches Ergebnis wie das folgende:

<pre>
[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
read_ahead 1024 sectors
md2 : active raid1 sda3[1] sdb3[0]
262016 blocks [2/2] [UU]

md1 : active raid1 sda2[1] sdb2[0]
119684160 blocks [2/2] [UU]

md0 : active raid1 sda1[1] sdb1[0]
102208 blocks [2/2] [UU]

unused devices: <none>

</pre>

Hier können Sie [UU] am Ende jedes logischen Laufwerks sehen. Ein U bedeutet, dass ein Laufwerk korrekt in den RAID-Verbund integriert ist.
Sobald Sie also eine Sequenz wie [_U] sehen, können wir davon ausgehen, dass ein Laufwerk defekt ist.

Sie können auch ein Ergebnis wie dieses erhalten:

<pre>

[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
md3 : active raid1 sda3[0] sdb3[2](F)
439553856 blocks super 1.0 [2/1] [U_]
bitmap: 1/4 pages [4KB], 65536KB chunk

md1 : active raid1 sdb1[2](F) sda1[0]
19529600 blocks super 1.0 [2/1] [U_]

unused devices: <none>

</pre>

In diesem Fall sagt uns das (F), dass die Trennwand defekt ist. In unserem Beispiel sind die Partitionen sdb3 und sdb1 fehlerhaft.

=== Diagnose == =

Um festzustellen, welche Festplatte defekt ist, verwenden wir SMART.

Zu diesem Zweck müssen Sie es installieren:
Abhängig von Ihrer Linux-Distribution kann sich der Befehl ändern:

Für Centos :

<code>
yum install smartmontools
</code>

Für Ubuntu / Debian :

<code>
apt-get install smartmontools
</code>

Sie können dann den folgenden Befehl ausführen, der die vorhandenen Festplatten auflistet:

<code>
smartctl --scan
</code>

Um weitere Informationen über eine Festplatte zu erhalten, verwenden Sie den folgenden Befehl:

<code>
smartctl -iHAl error [NOM DU DISQUE]
</code>

Anschließend wird ein Bericht über den Datenträger erstellt, in dem alle Anomalien aufgeführt sind.
Dieser Bericht besteht aus vier Teilen. Der erste Teil ist die Information über die Festplatte, ihre Seriennummer, das Modell, die Kapazität, ...
Der zweite Teil ist die Rückgabe des SMART-Tests. Wenn das Ergebnis nicht PASSED ist, muss die Festplatte ausgetauscht werden.
Der dritte Teil enthält alle Werte, die durch den Test in Bezug auf die Festplatte erzeugt wurden.
Der letzte Teil sind die Festplattenfehlerprotokolle.

[[Category:Linux]]
[[Category:Dedizierter Server]]

Diagnose einer defekten Linux-Festplatte

2021-07-29T15:08:21Z

Ikbot:

[[:pl:Diagnozowanie uszkodzonego dysku w systemie Linux]][[pl:Diagnozowanie uszkodzonego dysku w systemie Linux]]
[[:ja:故障したLinuxディスクの診断]][[ja:故障したLinuxディスクの診断]]
[[:zh:诊断一个有问题的Linux磁盘]][[zh:诊断一个有问题的Linux磁盘]]
[[:fr:Diagnostic d'un disque défectueux Linux]][[fr:Diagnostic d'un disque défectueux Linux]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Diagnostic d'un disque défectueux Linux|hier]] ansehen. 
[[:nl:Diagnose van een defecte Linux-schijf]][[nl:Diagnose van een defecte Linux-schijf]]
[[:it:Diagnosticare un disco Linux difettoso]][[it:Diagnosticare un disco Linux difettoso]]
[[:pt:Diagnosticar um disco Linux defeituoso]][[pt:Diagnosticar um disco Linux defeituoso]]
[[:es:Diagnóstico de un disco Linux defectuoso]][[es:Diagnóstico de un disco Linux defectuoso]]
[[:en:Diagnosing a faulty Linux disk]][[en:Diagnosing a faulty Linux disk]]
== Einführung ==

Dieser Artikel zielt darauf ab, eine defekte Festplatte auf einem Linux-Server zu diagnostizieren und zu identifizieren.

Die folgenden Aktionen können von einem Linux-Terminal oder einem Netboot aus durchgeführt werden.

== Die Aufträge ==

==Wenn Ihr Betriebssystem über RAID verfügt == =

Als ersten Schritt können Sie die folgenden Befehle ausführen:

<code> cat /proc/mdstat </code>

Sie erhalten dann ein ähnliches Ergebnis wie das folgende:

<pre>
[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
read_ahead 1024 sectors
md2 : active raid1 sda3[1] sdb3[0]
262016 blocks [2/2] [UU]

md1 : active raid1 sda2[1] sdb2[0]
119684160 blocks [2/2] [UU]

md0 : active raid1 sda1[1] sdb1[0]
102208 blocks [2/2] [UU]

unused devices: <none>

</pre>

Hier können Sie [UU] am Ende jedes logischen Laufwerks sehen. Ein U bedeutet, dass ein Laufwerk korrekt in den RAID-Verbund integriert ist.
Sobald Sie also eine Sequenz wie [_U] sehen, können wir davon ausgehen, dass ein Laufwerk defekt ist.

Sie können auch ein Ergebnis wie dieses erhalten:

<pre>

[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
md3 : active raid1 sda3[0] sdb3[2](F)
439553856 blocks super 1.0 [2/1] [U_]
bitmap: 1/4 pages [4KB], 65536KB chunk

md1 : active raid1 sdb1[2](F) sda1[0]
19529600 blocks super 1.0 [2/1] [U_]

unused devices: <none>

</pre>

In diesem Fall sagt uns das (F), dass die Trennwand defekt ist. In unserem Beispiel sind die Partitionen sdb3 und sdb1 fehlerhaft.

=== Diagnose == =

Um festzustellen, welche Festplatte defekt ist, verwenden wir SMART.

Zu diesem Zweck müssen Sie es installieren:
Abhängig von Ihrer Linux-Distribution kann sich der Befehl ändern:

Für Centos :

<code>
yum install smartmontools
</code>

Für Ubuntu / Debian :

<code>
apt-get install smartmontools
</code>

Sie können dann den folgenden Befehl ausführen, der die vorhandenen Festplatten auflistet:

<code>
smartctl --scan
</code>

Um weitere Informationen über eine Festplatte zu erhalten, verwenden Sie den folgenden Befehl:

<code>
smartctl -iHAl error [NOM DU DISQUE]
</code>

Anschließend wird ein Bericht über den Datenträger erstellt, in dem alle Anomalien aufgeführt sind.
Dieser Bericht besteht aus vier Teilen. Der erste Teil ist die Information über die Festplatte, ihre Seriennummer, das Modell, die Kapazität, ...
Der zweite Teil ist die Rückgabe des SMART-Tests. Wenn das Ergebnis nicht PASSED ist, muss die Festplatte ausgetauscht werden.
Der dritte Teil enthält alle Werte, die durch den Test in Bezug auf die Festplatte erzeugt wurden.
Der letzte Teil sind die Festplattenfehlerprotokolle.

[[Category:Linux]]
[[Category:Dedizierter Server]]

Diagnose einer defekten Linux-Festplatte

2021-07-29T15:07:22Z

Ikbot:

[[:ja:故障したLinuxディスクの診断]][[ja:故障したLinuxディスクの診断]]
[[:zh:诊断一个有问题的Linux磁盘]][[zh:诊断一个有问题的Linux磁盘]]
[[:fr:Diagnostic d'un disque défectueux Linux]][[fr:Diagnostic d'un disque défectueux Linux]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Diagnostic d'un disque défectueux Linux|hier]] ansehen. 
[[:nl:Diagnose van een defecte Linux-schijf]][[nl:Diagnose van een defecte Linux-schijf]]
[[:it:Diagnosticare un disco Linux difettoso]][[it:Diagnosticare un disco Linux difettoso]]
[[:pt:Diagnosticar um disco Linux defeituoso]][[pt:Diagnosticar um disco Linux defeituoso]]
[[:es:Diagnóstico de un disco Linux defectuoso]][[es:Diagnóstico de un disco Linux defectuoso]]
[[:en:Diagnosing a faulty Linux disk]][[en:Diagnosing a faulty Linux disk]]
== Einführung ==

Dieser Artikel zielt darauf ab, eine defekte Festplatte auf einem Linux-Server zu diagnostizieren und zu identifizieren.

Die folgenden Aktionen können von einem Linux-Terminal oder einem Netboot aus durchgeführt werden.

== Die Aufträge ==

==Wenn Ihr Betriebssystem über RAID verfügt == =

Als ersten Schritt können Sie die folgenden Befehle ausführen:

<code> cat /proc/mdstat </code>

Sie erhalten dann ein ähnliches Ergebnis wie das folgende:

<pre>
[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
read_ahead 1024 sectors
md2 : active raid1 sda3[1] sdb3[0]
262016 blocks [2/2] [UU]

md1 : active raid1 sda2[1] sdb2[0]
119684160 blocks [2/2] [UU]

md0 : active raid1 sda1[1] sdb1[0]
102208 blocks [2/2] [UU]

unused devices: <none>

</pre>

Hier können Sie [UU] am Ende jedes logischen Laufwerks sehen. Ein U bedeutet, dass ein Laufwerk korrekt in den RAID-Verbund integriert ist.
Sobald Sie also eine Sequenz wie [_U] sehen, können wir davon ausgehen, dass ein Laufwerk defekt ist.

Sie können auch ein Ergebnis wie dieses erhalten:

<pre>

[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
md3 : active raid1 sda3[0] sdb3[2](F)
439553856 blocks super 1.0 [2/1] [U_]
bitmap: 1/4 pages [4KB], 65536KB chunk

md1 : active raid1 sdb1[2](F) sda1[0]
19529600 blocks super 1.0 [2/1] [U_]

unused devices: <none>

</pre>

In diesem Fall sagt uns das (F), dass die Trennwand defekt ist. In unserem Beispiel sind die Partitionen sdb3 und sdb1 fehlerhaft.

=== Diagnose == =

Um festzustellen, welche Festplatte defekt ist, verwenden wir SMART.

Zu diesem Zweck müssen Sie es installieren:
Abhängig von Ihrer Linux-Distribution kann sich der Befehl ändern:

Für Centos :

<code>
yum install smartmontools
</code>

Für Ubuntu / Debian :

<code>
apt-get install smartmontools
</code>

Sie können dann den folgenden Befehl ausführen, der die vorhandenen Festplatten auflistet:

<code>
smartctl --scan
</code>

Um weitere Informationen über eine Festplatte zu erhalten, verwenden Sie den folgenden Befehl:

<code>
smartctl -iHAl error [NOM DU DISQUE]
</code>

Anschließend wird ein Bericht über den Datenträger erstellt, in dem alle Anomalien aufgeführt sind.
Dieser Bericht besteht aus vier Teilen. Der erste Teil ist die Information über die Festplatte, ihre Seriennummer, das Modell, die Kapazität, ...
Der zweite Teil ist die Rückgabe des SMART-Tests. Wenn das Ergebnis nicht PASSED ist, muss die Festplatte ausgetauscht werden.
Der dritte Teil enthält alle Werte, die durch den Test in Bezug auf die Festplatte erzeugt wurden.
Der letzte Teil sind die Festplattenfehlerprotokolle.

[[Category:Linux]]
[[Category:Dedizierter Server]]

Diagnose einer defekten Linux-Festplatte

2021-07-29T15:06:21Z

Ikbot:

[[:zh:诊断一个有问题的Linux磁盘]][[zh:诊断一个有问题的Linux磁盘]]
[[:fr:Diagnostic d'un disque défectueux Linux]][[fr:Diagnostic d'un disque défectueux Linux]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Diagnostic d'un disque défectueux Linux|hier]] ansehen. 
[[:nl:Diagnose van een defecte Linux-schijf]][[nl:Diagnose van een defecte Linux-schijf]]
[[:it:Diagnosticare un disco Linux difettoso]][[it:Diagnosticare un disco Linux difettoso]]
[[:pt:Diagnosticar um disco Linux defeituoso]][[pt:Diagnosticar um disco Linux defeituoso]]
[[:es:Diagnóstico de un disco Linux defectuoso]][[es:Diagnóstico de un disco Linux defectuoso]]
[[:en:Diagnosing a faulty Linux disk]][[en:Diagnosing a faulty Linux disk]]
== Einführung ==

Dieser Artikel zielt darauf ab, eine defekte Festplatte auf einem Linux-Server zu diagnostizieren und zu identifizieren.

Die folgenden Aktionen können von einem Linux-Terminal oder einem Netboot aus durchgeführt werden.

== Die Aufträge ==

==Wenn Ihr Betriebssystem über RAID verfügt == =

Als ersten Schritt können Sie die folgenden Befehle ausführen:

<code> cat /proc/mdstat </code>

Sie erhalten dann ein ähnliches Ergebnis wie das folgende:

<pre>
[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
read_ahead 1024 sectors
md2 : active raid1 sda3[1] sdb3[0]
262016 blocks [2/2] [UU]

md1 : active raid1 sda2[1] sdb2[0]
119684160 blocks [2/2] [UU]

md0 : active raid1 sda1[1] sdb1[0]
102208 blocks [2/2] [UU]

unused devices: <none>

</pre>

Hier können Sie [UU] am Ende jedes logischen Laufwerks sehen. Ein U bedeutet, dass ein Laufwerk korrekt in den RAID-Verbund integriert ist.
Sobald Sie also eine Sequenz wie [_U] sehen, können wir davon ausgehen, dass ein Laufwerk defekt ist.

Sie können auch ein Ergebnis wie dieses erhalten:

<pre>

[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
md3 : active raid1 sda3[0] sdb3[2](F)
439553856 blocks super 1.0 [2/1] [U_]
bitmap: 1/4 pages [4KB], 65536KB chunk

md1 : active raid1 sdb1[2](F) sda1[0]
19529600 blocks super 1.0 [2/1] [U_]

unused devices: <none>

</pre>

In diesem Fall sagt uns das (F), dass die Trennwand defekt ist. In unserem Beispiel sind die Partitionen sdb3 und sdb1 fehlerhaft.

=== Diagnose == =

Um festzustellen, welche Festplatte defekt ist, verwenden wir SMART.

Zu diesem Zweck müssen Sie es installieren:
Abhängig von Ihrer Linux-Distribution kann sich der Befehl ändern:

Für Centos :

<code>
yum install smartmontools
</code>

Für Ubuntu / Debian :

<code>
apt-get install smartmontools
</code>

Sie können dann den folgenden Befehl ausführen, der die vorhandenen Festplatten auflistet:

<code>
smartctl --scan
</code>

Um weitere Informationen über eine Festplatte zu erhalten, verwenden Sie den folgenden Befehl:

<code>
smartctl -iHAl error [NOM DU DISQUE]
</code>

Anschließend wird ein Bericht über den Datenträger erstellt, in dem alle Anomalien aufgeführt sind.
Dieser Bericht besteht aus vier Teilen. Der erste Teil ist die Information über die Festplatte, ihre Seriennummer, das Modell, die Kapazität, ...
Der zweite Teil ist die Rückgabe des SMART-Tests. Wenn das Ergebnis nicht PASSED ist, muss die Festplatte ausgetauscht werden.
Der dritte Teil enthält alle Werte, die durch den Test in Bezug auf die Festplatte erzeugt wurden.
Der letzte Teil sind die Festplattenfehlerprotokolle.

[[Category:Linux]]
[[Category:Dedizierter Server]]

Diagnose einer defekten Linux-Festplatte

2021-07-29T15:05:36Z

Ikbot: Die Seite wurde neu angelegt: „:…“

[[:fr:Diagnostic d'un disque défectueux Linux]][[fr:Diagnostic d'un disque défectueux Linux]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Diagnostic d'un disque défectueux Linux|hier]] ansehen. 
[[:nl:Diagnose van een defecte Linux-schijf]][[nl:Diagnose van een defecte Linux-schijf]]
[[:it:Diagnosticare un disco Linux difettoso]][[it:Diagnosticare un disco Linux difettoso]]
[[:pt:Diagnosticar um disco Linux defeituoso]][[pt:Diagnosticar um disco Linux defeituoso]]
[[:es:Diagnóstico de un disco Linux defectuoso]][[es:Diagnóstico de un disco Linux defectuoso]]
[[:en:Diagnosing a faulty Linux disk]][[en:Diagnosing a faulty Linux disk]]
== Einführung ==

Dieser Artikel zielt darauf ab, eine defekte Festplatte auf einem Linux-Server zu diagnostizieren und zu identifizieren.

Die folgenden Aktionen können von einem Linux-Terminal oder einem Netboot aus durchgeführt werden.

== Die Aufträge ==

==Wenn Ihr Betriebssystem über RAID verfügt == =

Als ersten Schritt können Sie die folgenden Befehle ausführen:

<code> cat /proc/mdstat </code>

Sie erhalten dann ein ähnliches Ergebnis wie das folgende:

<pre>
[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
read_ahead 1024 sectors
md2 : active raid1 sda3[1] sdb3[0]
262016 blocks [2/2] [UU]

md1 : active raid1 sda2[1] sdb2[0]
119684160 blocks [2/2] [UU]

md0 : active raid1 sda1[1] sdb1[0]
102208 blocks [2/2] [UU]

unused devices: <none>

</pre>

Hier können Sie [UU] am Ende jedes logischen Laufwerks sehen. Ein U bedeutet, dass ein Laufwerk korrekt in den RAID-Verbund integriert ist.
Sobald Sie also eine Sequenz wie [_U] sehen, können wir davon ausgehen, dass ein Laufwerk defekt ist.

Sie können auch ein Ergebnis wie dieses erhalten:

<pre>

[root@localhost ~]# cat /proc/mdstat

Personalities : [raid1]
md3 : active raid1 sda3[0] sdb3[2](F)
439553856 blocks super 1.0 [2/1] [U_]
bitmap: 1/4 pages [4KB], 65536KB chunk

md1 : active raid1 sdb1[2](F) sda1[0]
19529600 blocks super 1.0 [2/1] [U_]

unused devices: <none>

</pre>

In diesem Fall sagt uns das (F), dass die Trennwand defekt ist. In unserem Beispiel sind die Partitionen sdb3 und sdb1 fehlerhaft.

=== Diagnose == =

Um festzustellen, welche Festplatte defekt ist, verwenden wir SMART.

Zu diesem Zweck müssen Sie es installieren:
Abhängig von Ihrer Linux-Distribution kann sich der Befehl ändern:

Für Centos :

<code>
yum install smartmontools
</code>

Für Ubuntu / Debian :

<code>
apt-get install smartmontools
</code>

Sie können dann den folgenden Befehl ausführen, der die vorhandenen Festplatten auflistet:

<code>
smartctl --scan
</code>

Um weitere Informationen über eine Festplatte zu erhalten, verwenden Sie den folgenden Befehl:

<code>
smartctl -iHAl error [NOM DU DISQUE]
</code>

Anschließend wird ein Bericht über den Datenträger erstellt, in dem alle Anomalien aufgeführt sind.
Dieser Bericht besteht aus vier Teilen. Der erste Teil ist die Information über die Festplatte, ihre Seriennummer, das Modell, die Kapazität, ...
Der zweite Teil ist die Rückgabe des SMART-Tests. Wenn das Ergebnis nicht PASSED ist, muss die Festplatte ausgetauscht werden.
Der dritte Teil enthält alle Werte, die durch den Test in Bezug auf die Festplatte erzeugt wurden.
Der letzte Teil sind die Festplattenfehlerprotokolle.

[[Category:Linux]]
[[Category:Dedizierter Server]]

Deaktivieren der kernelbasierten Modus-Einstellung für das neue Modul

2021-07-29T15:00:36Z

Ikbot:

[[:ro:Dezactivarea setării modului bazat pe kernel pentru noul modul]][[ro:Dezactivarea setării modului bazat pe kernel pentru noul modul]]
[[:ru:Отключите установку режима на основе ядра для нового модуля]][[ru:Отключите установку режима на основе ядра для нового модуля]]
[[:pl:Wyłączenie ustawiania trybów dla nowego modułu w oparciu o jądro]][[pl:Wyłączenie ustawiania trybów dla nowego modułu w oparciu o jądro]]
[[:ja:新モジュールのカーネルベースのモード設定を無効にする]][[ja:新モジュールのカーネルベースのモード設定を無効にする]]
[[:zh:禁用新模块的基于内核的模式设置]][[zh:禁用新模块的基于内核的模式设置]]
[[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau]][[fr:Desactiver le Kernel-based mode-setting pour le module nouveau]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau|hier]] ansehen. 
<span data-link_translate_nl_title="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit" data-link_translate_nl_url="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit">[[:nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]][[nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]]
<span data-link_translate_it_title="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo" data-link_translate_it_url="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo">[[:it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]][[it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]]
[[:pt:Desactivar o mode-setting baseado no kernel para o novo módulo]][[pt:Desactivar o mode-setting baseado no kernel para o novo módulo]]
<span data-link_translate_es_title="Desactivar la configuración del modo basado en el kernel para el nuevo módulo" data-link_translate_es_url="Desactivar la configuración del modo basado en el kernel para el nuevo módulo">[[:es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]][[es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]]
[[:en:Disable kernel-based mode-setting for the new module]][[en:Disable kernel-based mode-setting for the new module]]
Die Kernel-basierte Modus-Einstellung (KMS) ermöglicht eine Verbesserung der Anzeige eines Linux-Servers. Im Falle eines dezentralen dedizierten Servers lassen sich diese Vorteile nur schwer ausnutzen. Wir empfehlen, diese Funktion zu deaktivieren, die beim "neuen" Treiber standardmäßig aktiviert ist.

==Wie man herausfindet, ob das KMS aktiviert ist== =
Mit diesem Befehl, wenn das Ergebnis nicht '0' ist:
<pre>
cat /sys/module/nouveau/parameters/modeset
-1
</pre>

==So deaktivieren Sie das KMS== =
* Setzen Sie modeset in den Standardeinstellungen von grub auf 0 '''/etc/default/grub''' (hinzuzufügen unter '''GRUB_CMDLINE_LINUX'''):
<pre>
nouveau.modeset=0
</pre>
Generieren Sie die Grub-Konfigurationsdateien neu, um die Standardeinstellungen wiederherzustellen:
<pre>
grub-mkconfig -o /boot/grub/grub.cfg
</pre>

Überprüfen Sie, ob die Option richtig eingestellt ist:
<pre>
grep -ri nouveau /boot/grub/
</pre>

Um dies zu berücksichtigen, ist ein Neustart erforderlich. Si les commandes précédentes ont générées des erreurs, il est indispensable de vérifier avant de procéder au redémarrage.

[[Category:Linux]]
[[Category:VPS-Server]]
[[Category:Dedizierter Server]]

Deaktivieren der kernelbasierten Modus-Einstellung für das neue Modul

2021-07-29T14:59:26Z

Ikbot:

[[:ru:Отключите установку режима на основе ядра для нового модуля]][[ru:Отключите установку режима на основе ядра для нового модуля]]
[[:pl:Wyłączenie ustawiania trybów dla nowego modułu w oparciu o jądro]][[pl:Wyłączenie ustawiania trybów dla nowego modułu w oparciu o jądro]]
[[:ja:新モジュールのカーネルベースのモード設定を無効にする]][[ja:新モジュールのカーネルベースのモード設定を無効にする]]
[[:zh:禁用新模块的基于内核的模式设置]][[zh:禁用新模块的基于内核的模式设置]]
[[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau]][[fr:Desactiver le Kernel-based mode-setting pour le module nouveau]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau|hier]] ansehen. 
<span data-link_translate_nl_title="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit" data-link_translate_nl_url="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit">[[:nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]][[nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]]
<span data-link_translate_it_title="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo" data-link_translate_it_url="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo">[[:it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]][[it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]]
[[:pt:Desactivar o mode-setting baseado no kernel para o novo módulo]][[pt:Desactivar o mode-setting baseado no kernel para o novo módulo]]
<span data-link_translate_es_title="Desactivar la configuración del modo basado en el kernel para el nuevo módulo" data-link_translate_es_url="Desactivar la configuración del modo basado en el kernel para el nuevo módulo">[[:es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]][[es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]]
[[:en:Disable kernel-based mode-setting for the new module]][[en:Disable kernel-based mode-setting for the new module]]
Die Kernel-basierte Modus-Einstellung (KMS) ermöglicht eine Verbesserung der Anzeige eines Linux-Servers. Im Falle eines dezentralen dedizierten Servers lassen sich diese Vorteile nur schwer ausnutzen. Wir empfehlen, diese Funktion zu deaktivieren, die beim "neuen" Treiber standardmäßig aktiviert ist.

==Wie man herausfindet, ob das KMS aktiviert ist== =
Mit diesem Befehl, wenn das Ergebnis nicht '0' ist:
<pre>
cat /sys/module/nouveau/parameters/modeset
-1
</pre>

==So deaktivieren Sie das KMS== =
* Setzen Sie modeset in den Standardeinstellungen von grub auf 0 '''/etc/default/grub''' (hinzuzufügen unter '''GRUB_CMDLINE_LINUX'''):
<pre>
nouveau.modeset=0
</pre>
Generieren Sie die Grub-Konfigurationsdateien neu, um die Standardeinstellungen wiederherzustellen:
<pre>
grub-mkconfig -o /boot/grub/grub.cfg
</pre>

Überprüfen Sie, ob die Option richtig eingestellt ist:
<pre>
grep -ri nouveau /boot/grub/
</pre>

Um dies zu berücksichtigen, ist ein Neustart erforderlich. Si les commandes précédentes ont générées des erreurs, il est indispensable de vérifier avant de procéder au redémarrage.

[[Category:Linux]]
[[Category:VPS-Server]]
[[Category:Dedizierter Server]]

Deaktivieren der kernelbasierten Modus-Einstellung für das neue Modul

2021-07-29T14:58:35Z

Ikbot:

[[:pl:Wyłączenie ustawiania trybów dla nowego modułu w oparciu o jądro]][[pl:Wyłączenie ustawiania trybów dla nowego modułu w oparciu o jądro]]
[[:ja:新モジュールのカーネルベースのモード設定を無効にする]][[ja:新モジュールのカーネルベースのモード設定を無効にする]]
[[:zh:禁用新模块的基于内核的模式设置]][[zh:禁用新模块的基于内核的模式设置]]
[[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau]][[fr:Desactiver le Kernel-based mode-setting pour le module nouveau]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau|hier]] ansehen. 
<span data-link_translate_nl_title="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit" data-link_translate_nl_url="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit">[[:nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]][[nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]]
<span data-link_translate_it_title="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo" data-link_translate_it_url="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo">[[:it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]][[it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]]
[[:pt:Desactivar o mode-setting baseado no kernel para o novo módulo]][[pt:Desactivar o mode-setting baseado no kernel para o novo módulo]]
<span data-link_translate_es_title="Desactivar la configuración del modo basado en el kernel para el nuevo módulo" data-link_translate_es_url="Desactivar la configuración del modo basado en el kernel para el nuevo módulo">[[:es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]][[es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]]
[[:en:Disable kernel-based mode-setting for the new module]][[en:Disable kernel-based mode-setting for the new module]]
Die Kernel-basierte Modus-Einstellung (KMS) ermöglicht eine Verbesserung der Anzeige eines Linux-Servers. Im Falle eines dezentralen dedizierten Servers lassen sich diese Vorteile nur schwer ausnutzen. Wir empfehlen, diese Funktion zu deaktivieren, die beim "neuen" Treiber standardmäßig aktiviert ist.

==Wie man herausfindet, ob das KMS aktiviert ist== =
Mit diesem Befehl, wenn das Ergebnis nicht '0' ist:
<pre>
cat /sys/module/nouveau/parameters/modeset
-1
</pre>

==So deaktivieren Sie das KMS== =
* Setzen Sie modeset in den Standardeinstellungen von grub auf 0 '''/etc/default/grub''' (hinzuzufügen unter '''GRUB_CMDLINE_LINUX'''):
<pre>
nouveau.modeset=0
</pre>
Generieren Sie die Grub-Konfigurationsdateien neu, um die Standardeinstellungen wiederherzustellen:
<pre>
grub-mkconfig -o /boot/grub/grub.cfg
</pre>

Überprüfen Sie, ob die Option richtig eingestellt ist:
<pre>
grep -ri nouveau /boot/grub/
</pre>

Um dies zu berücksichtigen, ist ein Neustart erforderlich. Si les commandes précédentes ont générées des erreurs, il est indispensable de vérifier avant de procéder au redémarrage.

[[Category:Linux]]
[[Category:VPS-Server]]
[[Category:Dedizierter Server]]

Deaktivieren der kernelbasierten Modus-Einstellung für das neue Modul

2021-07-29T14:55:51Z

Ikbot:

[[:ja:新モジュールのカーネルベースのモード設定を無効にする]][[ja:新モジュールのカーネルベースのモード設定を無効にする]]
[[:zh:禁用新模块的基于内核的模式设置]][[zh:禁用新模块的基于内核的模式设置]]
[[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau]][[fr:Desactiver le Kernel-based mode-setting pour le module nouveau]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau|hier]] ansehen. 
<span data-link_translate_nl_title="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit" data-link_translate_nl_url="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit">[[:nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]][[nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]]
<span data-link_translate_it_title="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo" data-link_translate_it_url="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo">[[:it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]][[it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]]
[[:pt:Desactivar o mode-setting baseado no kernel para o novo módulo]][[pt:Desactivar o mode-setting baseado no kernel para o novo módulo]]
<span data-link_translate_es_title="Desactivar la configuración del modo basado en el kernel para el nuevo módulo" data-link_translate_es_url="Desactivar la configuración del modo basado en el kernel para el nuevo módulo">[[:es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]][[es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]]
[[:en:Disable kernel-based mode-setting for the new module]][[en:Disable kernel-based mode-setting for the new module]]
Die Kernel-basierte Modus-Einstellung (KMS) ermöglicht eine Verbesserung der Anzeige eines Linux-Servers. Im Falle eines dezentralen dedizierten Servers lassen sich diese Vorteile nur schwer ausnutzen. Wir empfehlen, diese Funktion zu deaktivieren, die beim "neuen" Treiber standardmäßig aktiviert ist.

==Wie man herausfindet, ob das KMS aktiviert ist== =
Mit diesem Befehl, wenn das Ergebnis nicht '0' ist:
<pre>
cat /sys/module/nouveau/parameters/modeset
-1
</pre>

==So deaktivieren Sie das KMS== =
* Setzen Sie modeset in den Standardeinstellungen von grub auf 0 '''/etc/default/grub''' (hinzuzufügen unter '''GRUB_CMDLINE_LINUX'''):
<pre>
nouveau.modeset=0
</pre>
Generieren Sie die Grub-Konfigurationsdateien neu, um die Standardeinstellungen wiederherzustellen:
<pre>
grub-mkconfig -o /boot/grub/grub.cfg
</pre>

Überprüfen Sie, ob die Option richtig eingestellt ist:
<pre>
grep -ri nouveau /boot/grub/
</pre>

Um dies zu berücksichtigen, ist ein Neustart erforderlich. Si les commandes précédentes ont générées des erreurs, il est indispensable de vérifier avant de procéder au redémarrage.

[[Category:Linux]]
[[Category:VPS-Server]]
[[Category:Dedizierter Server]]

Deaktivieren der kernelbasierten Modus-Einstellung für das neue Modul

2021-07-29T14:54:50Z

Ikbot:

[[:zh:禁用新模块的基于内核的模式设置]][[zh:禁用新模块的基于内核的模式设置]]
[[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau]][[fr:Desactiver le Kernel-based mode-setting pour le module nouveau]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau|hier]] ansehen. 
<span data-link_translate_nl_title="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit" data-link_translate_nl_url="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit">[[:nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]][[nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]]
<span data-link_translate_it_title="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo" data-link_translate_it_url="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo">[[:it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]][[it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]]
[[:pt:Desactivar o mode-setting baseado no kernel para o novo módulo]][[pt:Desactivar o mode-setting baseado no kernel para o novo módulo]]
<span data-link_translate_es_title="Desactivar la configuración del modo basado en el kernel para el nuevo módulo" data-link_translate_es_url="Desactivar la configuración del modo basado en el kernel para el nuevo módulo">[[:es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]][[es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]]
[[:en:Disable kernel-based mode-setting for the new module]][[en:Disable kernel-based mode-setting for the new module]]
Die Kernel-basierte Modus-Einstellung (KMS) ermöglicht eine Verbesserung der Anzeige eines Linux-Servers. Im Falle eines dezentralen dedizierten Servers lassen sich diese Vorteile nur schwer ausnutzen. Wir empfehlen, diese Funktion zu deaktivieren, die beim "neuen" Treiber standardmäßig aktiviert ist.

==Wie man herausfindet, ob das KMS aktiviert ist== =
Mit diesem Befehl, wenn das Ergebnis nicht '0' ist:
<pre>
cat /sys/module/nouveau/parameters/modeset
-1
</pre>

==So deaktivieren Sie das KMS== =
* Setzen Sie modeset in den Standardeinstellungen von grub auf 0 '''/etc/default/grub''' (hinzuzufügen unter '''GRUB_CMDLINE_LINUX'''):
<pre>
nouveau.modeset=0
</pre>
Generieren Sie die Grub-Konfigurationsdateien neu, um die Standardeinstellungen wiederherzustellen:
<pre>
grub-mkconfig -o /boot/grub/grub.cfg
</pre>

Überprüfen Sie, ob die Option richtig eingestellt ist:
<pre>
grep -ri nouveau /boot/grub/
</pre>

Um dies zu berücksichtigen, ist ein Neustart erforderlich. Si les commandes précédentes ont générées des erreurs, il est indispensable de vérifier avant de procéder au redémarrage.

[[Category:Linux]]
[[Category:VPS-Server]]
[[Category:Dedizierter Server]]

Deaktivieren der kernelbasierten Modus-Einstellung für das neue Modul

2021-07-29T14:54:08Z

Ikbot: Die Seite wurde neu angelegt: „<span data-link_translate_fr_title="Desactiver le Kernel-based mode-setting pour le module nouveau" data-link_translate_fr_url="Desactiver le Kernel-based mod…“

[[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau]][[fr:Desactiver le Kernel-based mode-setting pour le module nouveau]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Desactiver le Kernel-based mode-setting pour le module nouveau|hier]] ansehen. 
<span data-link_translate_nl_title="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit" data-link_translate_nl_url="Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit">[[:nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]][[nl:Schakel de kernel-gebaseerde modus-instelling voor de nieuwe module uit]]
<span data-link_translate_it_title="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo" data-link_translate_it_url="Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo">[[:it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]][[it:Disabilita l'impostazione della modalità basata sul kernel per il nuovo modulo]]
[[:pt:Desactivar o mode-setting baseado no kernel para o novo módulo]][[pt:Desactivar o mode-setting baseado no kernel para o novo módulo]]
<span data-link_translate_es_title="Desactivar la configuración del modo basado en el kernel para el nuevo módulo" data-link_translate_es_url="Desactivar la configuración del modo basado en el kernel para el nuevo módulo">[[:es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]][[es:Desactivar la configuración del modo basado en el kernel para el nuevo módulo]]
[[:en:Disable kernel-based mode-setting for the new module]][[en:Disable kernel-based mode-setting for the new module]]
Die Kernel-basierte Modus-Einstellung (KMS) ermöglicht eine Verbesserung der Anzeige eines Linux-Servers. Im Falle eines dezentralen dedizierten Servers lassen sich diese Vorteile nur schwer ausnutzen. Wir empfehlen, diese Funktion zu deaktivieren, die beim "neuen" Treiber standardmäßig aktiviert ist.

==Wie man herausfindet, ob das KMS aktiviert ist== =
Mit diesem Befehl, wenn das Ergebnis nicht '0' ist:
<pre>
cat /sys/module/nouveau/parameters/modeset
-1
</pre>

==So deaktivieren Sie das KMS== =
* Setzen Sie modeset in den Standardeinstellungen von grub auf 0 '''/etc/default/grub''' (hinzuzufügen unter '''GRUB_CMDLINE_LINUX'''):
<pre>
nouveau.modeset=0
</pre>
Generieren Sie die Grub-Konfigurationsdateien neu, um die Standardeinstellungen wiederherzustellen:
<pre>
grub-mkconfig -o /boot/grub/grub.cfg
</pre>

Überprüfen Sie, ob die Option richtig eingestellt ist:
<pre>
grep -ri nouveau /boot/grub/
</pre>

Um dies zu berücksichtigen, ist ein Neustart erforderlich. Si les commandes précédentes ont générées des erreurs, il est indispensable de vérifier avant de procéder au redémarrage.

[[Category:Linux]]
[[Category:VPS-Server]]
[[Category:Dedizierter Server]]

Bereitstellen Ihrer Instanzen mit Terraform

2021-07-29T14:48:27Z

Ikbot:

[[:ro:Implementarea instanțelor dvs. cu Terraform]][[ro:Implementarea instanțelor dvs. cu Terraform]]
[[:ru:Развертывание ваших экземпляров с помощью Terraform]][[ru:Развертывание ваших экземпляров с помощью Terraform]]
[[:pl:Wdrażanie instancji za pomocą Terraform]][[pl:Wdrażanie instancji za pomocą Terraform]]
[[:ja:Terraformによるインスタンスのデプロイ]][[ja:Terraformによるインスタンスのデプロイ]]
[[:zh:用Terraform部署你的实例]][[zh:用Terraform部署你的实例]]
[[:fr:Deployer vos instances avec Terraform]][[fr:Deployer vos instances avec Terraform]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Terraform|hier]] ansehen. 
[[:nl:Je instances uitrollen met Terraform]][[nl:Je instances uitrollen met Terraform]]
[[:it:Distribuire le istanze con Terraform]][[it:Distribuire le istanze con Terraform]]
[[:pt:Implementar as suas instâncias com a Terraform]][[pt:Implementar as suas instâncias com a Terraform]]
[[:es:Despliegue de sus instancias con Terraform]][[es:Despliegue de sus instancias con Terraform]]
[[:en:Deploying your instances with Terraform]][[en:Deploying your instances with Terraform]]
== Beschreibung ==

Wir werden sehen, wie man schnell eine oder mehrere IKOULA One Cloud-Instanzen über das Infrastruktur-als-Code-Tool "Terraform" bereitstellen kann.

Als Erstes müssen Sie Terraform installieren, falls Sie dies noch nicht getan haben, und ein IKOULA One Cloud-Konto besitzen.
Terraform ist für die meisten Betriebssysteme unter dem folgenden Link verfügbar: https://www.terraform.io/downloads.html

Terraform unterstützt Dutzende von Anbietern, eine Liste davon ist auf der Terraform-Website verfügbar (https://www.terraform.io/docs/providers/).
Wir werden den Anbieter "Cloudstack" für die Bereitstellung auf Cloud Ikoula One verwenden.

== Bereitstellen einer einzelnen Instanz ==

Wir werden unsere erste Terraform-Konfigurationsdatei schreiben, die die Bereitstellung einer einzelnen IKOULA-Cloud-Instanz ermöglicht:

Dies ist eine Textdatei mit der Erweiterung ".tf" (achten Sie darauf, dass Sie nicht mehrere ".tf"-Dateien in Ihrem Arbeitsverzeichnis erstellen, da Terraform sonst alle lädt). Wir werden das klassische Terraform-Format verwenden, aber es ist auch möglich, eine JSON-Syntax zu verwenden.

Hier ist der Inhalt unserer Terraform-Datei, die Sie mit Ihren eigenen Parametern anpassen können:

'''Für die Bereitstellung einer Instanz in der Basiszone''':

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource >" {
zone = "< Nom de la zone basic Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
security_group_ids = ["< ID de votre groupe de sécurité Cloud Ikoula One à utiliser >",]
}
</pre>

* '''Pour le déploiement d'une instance en zone avancée''' (avec création d'une règle de redirection de port, pour ssh dans cet exemple) :

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource d'instance >" {
zone = "< Nom de la zone avancée/adv Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
network_id = ["< ID de votre réseau d'invités Cloud Ikoula One à utiliser >",]
}

# Redirection de port (ici SSH)

resource "cloudstack_port_forward" "SshTerraformVM1" {
ip_address_id = "< ID de l'adresse ip NAT Source de votre réseau d'invités >"
forward {
protocol = "tcp"
private_port = "22"
public_port = "< port ssh publique de votre choix>"
virtual_machine_id = "${cloudstack_instance.< Nom que vous avez choisis au-dessus pour votre ressource d'instance >.id}"
}
}
</pre>

Note : la ligne 'expunge = "true"' nous permettra de supprimer notre instance lors de l'appel "terraform destroy".

Une fois votre fichier de configuration enregistré, nous allons initialiser Terraform puis l'appliquer :

<pre>
$ terraform init

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.cloudstack: version = "~> 0.1"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
</pre>

Avant de lancer notre déploiement (ici en zone basic), nous pouvons vérifier ce qui sera exécuté sans rien appliquer via la commande :
#terraform plan

<pre>
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
</pre>

Si c'est bien ce que nous voulons faire alors nous pouvons appliquer via la commande "terraform apply" et saisir "yes" pour confirmer quand cela nous est demandé :

<pre>
$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

cloudstack_instance.TerraformVM1: Creating...
display_name: "" => "<computed>"
expunge: "" => "true"
group: "" => "<computed>"
ip_address: "" => "<computed>"
keypair: "" => "MY_SSH_KEYPAIR"
name: "" => "TerraformVM1"
network_id: "" => "<computed>"
project: "" => "<computed>"
root_disk_size: "" => "<computed>"
security_group_ids.#: "" => "1"
security_group_ids.3260590242: "" => "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "" => "t1.pico"
tags.%: "" => "<computed>"
template: "" => "Debian 9 - Minimal - 64bits"
zone: "" => "US-FL-MIAMI02-Z2-BASIC"
cloudstack_instance.TerraformVM1: Still creating... (10s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (20s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (30s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (40s elapsed)
cloudstack_instance.TerraformVM1: Creation complete after 46s (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
</pre>

Ici nous venons de déployer en quelques secondes, une instance nommée "TerraformVM1" avec le modèle "Debian 9 - Minimal - 64bits" dans la zone basic "US-FL-MIAMI02-Z2-BASIC" avec l'offre de calcul "t1.pico".

Nous pouvons voir celle-ci depuis notre interface Cloud Ikoula One :

[[File:wiki_terraform_1.png]]

Nous pouvons nous connecter sur notre instance fraichement déployée.
Note : Pour que cela fonctionne il faut que le [https://fr-wiki.ikoula.com/fr/Deploiement_d%27une_instance_en_zone_basic_(cliquez_pour_lire_la_suite)#Introduction_aux_groupes_de_s.C3.A9curit.C3.A9 Sicherheitsgruppe] dans lequel nous avons déployé le permette, sinon il faudra y rajouter une règle autorisant la connexion.

<pre>
$ ssh -i MY_SSH_KEYPAIR root@38.93.X.X
The authenticity of host '38.93.X.X (38.93.X.X)' can't be established.
ECDSA key fingerprint is SHA256:4D7s+xxxXXXXxxxxXXXXXXXXXxxxxXXXXXxxXXXXxxXXXxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '38.93.X.X' (ECDSA) to the list of known hosts.
Linux TerraformVM1 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@TerraformVM1:~#
</pre>

Pour supprimer notre instance, il nous suffira d'exécuter la commande "terraform destroy" et valider en saisissant "yes" quand cela nous est demandé :

<pre>
$ terraform destroy
cloudstack_instance.TerraformVM1: Refreshing state... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
- destroy

Terraform will perform the following actions:

- cloudstack_instance.TerraformVM1

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.

Enter a value: yes

cloudstack_instance.TerraformVM1: Destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)
cloudstack_instance.TerraformVM1: Still destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba, 10s elapsed)
cloudstack_instance.TerraformVM1: Destruction complete after 15s

Destroy complete! Resources: 1 destroyed.
</pre>

[[Catégorie :Cloudstack]]
[[Catégorie :Cloud public]]
[[Catégorie :Cloud]]

Bereitstellen Ihrer Instanzen mit Terraform

2021-07-29T14:46:37Z

Ikbot:

[[:ru:Развертывание ваших экземпляров с помощью Terraform]][[ru:Развертывание ваших экземпляров с помощью Terraform]]
[[:pl:Wdrażanie instancji za pomocą Terraform]][[pl:Wdrażanie instancji za pomocą Terraform]]
[[:ja:Terraformによるインスタンスのデプロイ]][[ja:Terraformによるインスタンスのデプロイ]]
[[:zh:用Terraform部署你的实例]][[zh:用Terraform部署你的实例]]
[[:fr:Deployer vos instances avec Terraform]][[fr:Deployer vos instances avec Terraform]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Terraform|hier]] ansehen. 
[[:nl:Je instances uitrollen met Terraform]][[nl:Je instances uitrollen met Terraform]]
[[:it:Distribuire le istanze con Terraform]][[it:Distribuire le istanze con Terraform]]
[[:pt:Implementar as suas instâncias com a Terraform]][[pt:Implementar as suas instâncias com a Terraform]]
[[:es:Despliegue de sus instancias con Terraform]][[es:Despliegue de sus instancias con Terraform]]
[[:en:Deploying your instances with Terraform]][[en:Deploying your instances with Terraform]]
== Beschreibung ==

Wir werden sehen, wie man schnell eine oder mehrere IKOULA One Cloud-Instanzen über das Infrastruktur-als-Code-Tool "Terraform" bereitstellen kann.

Als Erstes müssen Sie Terraform installieren, falls Sie dies noch nicht getan haben, und ein IKOULA One Cloud-Konto besitzen.
Terraform ist für die meisten Betriebssysteme unter dem folgenden Link verfügbar: https://www.terraform.io/downloads.html

Terraform unterstützt Dutzende von Anbietern, eine Liste davon ist auf der Terraform-Website verfügbar (https://www.terraform.io/docs/providers/).
Wir werden den Anbieter "Cloudstack" für die Bereitstellung auf Cloud Ikoula One verwenden.

== Bereitstellen einer einzelnen Instanz ==

Wir werden unsere erste Terraform-Konfigurationsdatei schreiben, die die Bereitstellung einer einzelnen IKOULA-Cloud-Instanz ermöglicht:

Dies ist eine Textdatei mit der Erweiterung ".tf" (achten Sie darauf, dass Sie nicht mehrere ".tf"-Dateien in Ihrem Arbeitsverzeichnis erstellen, da Terraform sonst alle lädt). Wir werden das klassische Terraform-Format verwenden, aber es ist auch möglich, eine JSON-Syntax zu verwenden.

Hier ist der Inhalt unserer Terraform-Datei, die Sie mit Ihren eigenen Parametern anpassen können:

'''Für die Bereitstellung einer Instanz in der Basiszone''':

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource >" {
zone = "< Nom de la zone basic Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
security_group_ids = ["< ID de votre groupe de sécurité Cloud Ikoula One à utiliser >",]
}
</pre>

* '''Pour le déploiement d'une instance en zone avancée''' (avec création d'une règle de redirection de port, pour ssh dans cet exemple) :

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource d'instance >" {
zone = "< Nom de la zone avancée/adv Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
network_id = ["< ID de votre réseau d'invités Cloud Ikoula One à utiliser >",]
}

# Redirection de port (ici SSH)

resource "cloudstack_port_forward" "SshTerraformVM1" {
ip_address_id = "< ID de l'adresse ip NAT Source de votre réseau d'invités >"
forward {
protocol = "tcp"
private_port = "22"
public_port = "< port ssh publique de votre choix>"
virtual_machine_id = "${cloudstack_instance.< Nom que vous avez choisis au-dessus pour votre ressource d'instance >.id}"
}
}
</pre>

Note : la ligne 'expunge = "true"' nous permettra de supprimer notre instance lors de l'appel "terraform destroy".

Une fois votre fichier de configuration enregistré, nous allons initialiser Terraform puis l'appliquer :

<pre>
$ terraform init

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.cloudstack: version = "~> 0.1"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
</pre>

Avant de lancer notre déploiement (ici en zone basic), nous pouvons vérifier ce qui sera exécuté sans rien appliquer via la commande :
#terraform plan

<pre>
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
</pre>

Si c'est bien ce que nous voulons faire alors nous pouvons appliquer via la commande "terraform apply" et saisir "yes" pour confirmer quand cela nous est demandé :

<pre>
$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

cloudstack_instance.TerraformVM1: Creating...
display_name: "" => "<computed>"
expunge: "" => "true"
group: "" => "<computed>"
ip_address: "" => "<computed>"
keypair: "" => "MY_SSH_KEYPAIR"
name: "" => "TerraformVM1"
network_id: "" => "<computed>"
project: "" => "<computed>"
root_disk_size: "" => "<computed>"
security_group_ids.#: "" => "1"
security_group_ids.3260590242: "" => "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "" => "t1.pico"
tags.%: "" => "<computed>"
template: "" => "Debian 9 - Minimal - 64bits"
zone: "" => "US-FL-MIAMI02-Z2-BASIC"
cloudstack_instance.TerraformVM1: Still creating... (10s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (20s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (30s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (40s elapsed)
cloudstack_instance.TerraformVM1: Creation complete after 46s (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
</pre>

Ici nous venons de déployer en quelques secondes, une instance nommée "TerraformVM1" avec le modèle "Debian 9 - Minimal - 64bits" dans la zone basic "US-FL-MIAMI02-Z2-BASIC" avec l'offre de calcul "t1.pico".

Nous pouvons voir celle-ci depuis notre interface Cloud Ikoula One :

[[File:wiki_terraform_1.png]]

Nous pouvons nous connecter sur notre instance fraichement déployée.
Note : Pour que cela fonctionne il faut que le [https://fr-wiki.ikoula.com/fr/Deploiement_d%27une_instance_en_zone_basic_(cliquez_pour_lire_la_suite)#Introduction_aux_groupes_de_s.C3.A9curit.C3.A9 Sicherheitsgruppe] dans lequel nous avons déployé le permette, sinon il faudra y rajouter une règle autorisant la connexion.

<pre>
$ ssh -i MY_SSH_KEYPAIR root@38.93.X.X
The authenticity of host '38.93.X.X (38.93.X.X)' can't be established.
ECDSA key fingerprint is SHA256:4D7s+xxxXXXXxxxxXXXXXXXXXxxxxXXXXXxxXXXXxxXXXxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '38.93.X.X' (ECDSA) to the list of known hosts.
Linux TerraformVM1 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@TerraformVM1:~#
</pre>

Pour supprimer notre instance, il nous suffira d'exécuter la commande "terraform destroy" et valider en saisissant "yes" quand cela nous est demandé :

<pre>
$ terraform destroy
cloudstack_instance.TerraformVM1: Refreshing state... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
- destroy

Terraform will perform the following actions:

- cloudstack_instance.TerraformVM1

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.

Enter a value: yes

cloudstack_instance.TerraformVM1: Destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)
cloudstack_instance.TerraformVM1: Still destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba, 10s elapsed)
cloudstack_instance.TerraformVM1: Destruction complete after 15s

Destroy complete! Resources: 1 destroyed.
</pre>

[[Catégorie :Cloudstack]]
[[Catégorie :Cloud public]]
[[Catégorie :Cloud]]

Bereitstellen Ihrer Instanzen mit Terraform

2021-07-29T14:45:41Z

Ikbot:

[[:pl:Wdrażanie instancji za pomocą Terraform]][[pl:Wdrażanie instancji za pomocą Terraform]]
[[:ja:Terraformによるインスタンスのデプロイ]][[ja:Terraformによるインスタンスのデプロイ]]
[[:zh:用Terraform部署你的实例]][[zh:用Terraform部署你的实例]]
[[:fr:Deployer vos instances avec Terraform]][[fr:Deployer vos instances avec Terraform]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Terraform|hier]] ansehen. 
[[:nl:Je instances uitrollen met Terraform]][[nl:Je instances uitrollen met Terraform]]
[[:it:Distribuire le istanze con Terraform]][[it:Distribuire le istanze con Terraform]]
[[:pt:Implementar as suas instâncias com a Terraform]][[pt:Implementar as suas instâncias com a Terraform]]
[[:es:Despliegue de sus instancias con Terraform]][[es:Despliegue de sus instancias con Terraform]]
[[:en:Deploying your instances with Terraform]][[en:Deploying your instances with Terraform]]
== Beschreibung ==

Wir werden sehen, wie man schnell eine oder mehrere IKOULA One Cloud-Instanzen über das Infrastruktur-als-Code-Tool "Terraform" bereitstellen kann.

Als Erstes müssen Sie Terraform installieren, falls Sie dies noch nicht getan haben, und ein IKOULA One Cloud-Konto besitzen.
Terraform ist für die meisten Betriebssysteme unter dem folgenden Link verfügbar: https://www.terraform.io/downloads.html

Terraform unterstützt Dutzende von Anbietern, eine Liste davon ist auf der Terraform-Website verfügbar (https://www.terraform.io/docs/providers/).
Wir werden den Anbieter "Cloudstack" für die Bereitstellung auf Cloud Ikoula One verwenden.

== Bereitstellen einer einzelnen Instanz ==

Wir werden unsere erste Terraform-Konfigurationsdatei schreiben, die die Bereitstellung einer einzelnen IKOULA-Cloud-Instanz ermöglicht:

Dies ist eine Textdatei mit der Erweiterung ".tf" (achten Sie darauf, dass Sie nicht mehrere ".tf"-Dateien in Ihrem Arbeitsverzeichnis erstellen, da Terraform sonst alle lädt). Wir werden das klassische Terraform-Format verwenden, aber es ist auch möglich, eine JSON-Syntax zu verwenden.

Hier ist der Inhalt unserer Terraform-Datei, die Sie mit Ihren eigenen Parametern anpassen können:

'''Für die Bereitstellung einer Instanz in der Basiszone''':

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource >" {
zone = "< Nom de la zone basic Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
security_group_ids = ["< ID de votre groupe de sécurité Cloud Ikoula One à utiliser >",]
}
</pre>

* '''Pour le déploiement d'une instance en zone avancée''' (avec création d'une règle de redirection de port, pour ssh dans cet exemple) :

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource d'instance >" {
zone = "< Nom de la zone avancée/adv Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
network_id = ["< ID de votre réseau d'invités Cloud Ikoula One à utiliser >",]
}

# Redirection de port (ici SSH)

resource "cloudstack_port_forward" "SshTerraformVM1" {
ip_address_id = "< ID de l'adresse ip NAT Source de votre réseau d'invités >"
forward {
protocol = "tcp"
private_port = "22"
public_port = "< port ssh publique de votre choix>"
virtual_machine_id = "${cloudstack_instance.< Nom que vous avez choisis au-dessus pour votre ressource d'instance >.id}"
}
}
</pre>

Note : la ligne 'expunge = "true"' nous permettra de supprimer notre instance lors de l'appel "terraform destroy".

Une fois votre fichier de configuration enregistré, nous allons initialiser Terraform puis l'appliquer :

<pre>
$ terraform init

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.cloudstack: version = "~> 0.1"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
</pre>

Avant de lancer notre déploiement (ici en zone basic), nous pouvons vérifier ce qui sera exécuté sans rien appliquer via la commande :
#terraform plan

<pre>
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
</pre>

Si c'est bien ce que nous voulons faire alors nous pouvons appliquer via la commande "terraform apply" et saisir "yes" pour confirmer quand cela nous est demandé :

<pre>
$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

cloudstack_instance.TerraformVM1: Creating...
display_name: "" => "<computed>"
expunge: "" => "true"
group: "" => "<computed>"
ip_address: "" => "<computed>"
keypair: "" => "MY_SSH_KEYPAIR"
name: "" => "TerraformVM1"
network_id: "" => "<computed>"
project: "" => "<computed>"
root_disk_size: "" => "<computed>"
security_group_ids.#: "" => "1"
security_group_ids.3260590242: "" => "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "" => "t1.pico"
tags.%: "" => "<computed>"
template: "" => "Debian 9 - Minimal - 64bits"
zone: "" => "US-FL-MIAMI02-Z2-BASIC"
cloudstack_instance.TerraformVM1: Still creating... (10s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (20s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (30s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (40s elapsed)
cloudstack_instance.TerraformVM1: Creation complete after 46s (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
</pre>

Ici nous venons de déployer en quelques secondes, une instance nommée "TerraformVM1" avec le modèle "Debian 9 - Minimal - 64bits" dans la zone basic "US-FL-MIAMI02-Z2-BASIC" avec l'offre de calcul "t1.pico".

Nous pouvons voir celle-ci depuis notre interface Cloud Ikoula One :

[[File:wiki_terraform_1.png]]

Nous pouvons nous connecter sur notre instance fraichement déployée.
Note : Pour que cela fonctionne il faut que le [https://fr-wiki.ikoula.com/fr/Deploiement_d%27une_instance_en_zone_basic_(cliquez_pour_lire_la_suite)#Introduction_aux_groupes_de_s.C3.A9curit.C3.A9 Sicherheitsgruppe] dans lequel nous avons déployé le permette, sinon il faudra y rajouter une règle autorisant la connexion.

<pre>
$ ssh -i MY_SSH_KEYPAIR root@38.93.X.X
The authenticity of host '38.93.X.X (38.93.X.X)' can't be established.
ECDSA key fingerprint is SHA256:4D7s+xxxXXXXxxxxXXXXXXXXXxxxxXXXXXxxXXXXxxXXXxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '38.93.X.X' (ECDSA) to the list of known hosts.
Linux TerraformVM1 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@TerraformVM1:~#
</pre>

Pour supprimer notre instance, il nous suffira d'exécuter la commande "terraform destroy" et valider en saisissant "yes" quand cela nous est demandé :

<pre>
$ terraform destroy
cloudstack_instance.TerraformVM1: Refreshing state... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
- destroy

Terraform will perform the following actions:

- cloudstack_instance.TerraformVM1

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.

Enter a value: yes

cloudstack_instance.TerraformVM1: Destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)
cloudstack_instance.TerraformVM1: Still destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba, 10s elapsed)
cloudstack_instance.TerraformVM1: Destruction complete after 15s

Destroy complete! Resources: 1 destroyed.
</pre>

[[Catégorie :Cloudstack]]
[[Catégorie :Cloud public]]
[[Catégorie :Cloud]]

Bereitstellen Ihrer Instanzen mit Terraform

2021-07-29T14:44:28Z

Ikbot:

[[:ja:Terraformによるインスタンスのデプロイ]][[ja:Terraformによるインスタンスのデプロイ]]
[[:zh:用Terraform部署你的实例]][[zh:用Terraform部署你的实例]]
[[:fr:Deployer vos instances avec Terraform]][[fr:Deployer vos instances avec Terraform]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Terraform|hier]] ansehen. 
[[:nl:Je instances uitrollen met Terraform]][[nl:Je instances uitrollen met Terraform]]
[[:it:Distribuire le istanze con Terraform]][[it:Distribuire le istanze con Terraform]]
[[:pt:Implementar as suas instâncias com a Terraform]][[pt:Implementar as suas instâncias com a Terraform]]
[[:es:Despliegue de sus instancias con Terraform]][[es:Despliegue de sus instancias con Terraform]]
[[:en:Deploying your instances with Terraform]][[en:Deploying your instances with Terraform]]
== Beschreibung ==

Wir werden sehen, wie man schnell eine oder mehrere IKOULA One Cloud-Instanzen über das Infrastruktur-als-Code-Tool "Terraform" bereitstellen kann.

Als Erstes müssen Sie Terraform installieren, falls Sie dies noch nicht getan haben, und ein IKOULA One Cloud-Konto besitzen.
Terraform ist für die meisten Betriebssysteme unter dem folgenden Link verfügbar: https://www.terraform.io/downloads.html

Terraform unterstützt Dutzende von Anbietern, eine Liste davon ist auf der Terraform-Website verfügbar (https://www.terraform.io/docs/providers/).
Wir werden den Anbieter "Cloudstack" für die Bereitstellung auf Cloud Ikoula One verwenden.

== Bereitstellen einer einzelnen Instanz ==

Wir werden unsere erste Terraform-Konfigurationsdatei schreiben, die die Bereitstellung einer einzelnen IKOULA-Cloud-Instanz ermöglicht:

Dies ist eine Textdatei mit der Erweiterung ".tf" (achten Sie darauf, dass Sie nicht mehrere ".tf"-Dateien in Ihrem Arbeitsverzeichnis erstellen, da Terraform sonst alle lädt). Wir werden das klassische Terraform-Format verwenden, aber es ist auch möglich, eine JSON-Syntax zu verwenden.

Hier ist der Inhalt unserer Terraform-Datei, die Sie mit Ihren eigenen Parametern anpassen können:

'''Für die Bereitstellung einer Instanz in der Basiszone''':

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource >" {
zone = "< Nom de la zone basic Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
security_group_ids = ["< ID de votre groupe de sécurité Cloud Ikoula One à utiliser >",]
}
</pre>

* '''Pour le déploiement d'une instance en zone avancée''' (avec création d'une règle de redirection de port, pour ssh dans cet exemple) :

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource d'instance >" {
zone = "< Nom de la zone avancée/adv Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
network_id = ["< ID de votre réseau d'invités Cloud Ikoula One à utiliser >",]
}

# Redirection de port (ici SSH)

resource "cloudstack_port_forward" "SshTerraformVM1" {
ip_address_id = "< ID de l'adresse ip NAT Source de votre réseau d'invités >"
forward {
protocol = "tcp"
private_port = "22"
public_port = "< port ssh publique de votre choix>"
virtual_machine_id = "${cloudstack_instance.< Nom que vous avez choisis au-dessus pour votre ressource d'instance >.id}"
}
}
</pre>

Note : la ligne 'expunge = "true"' nous permettra de supprimer notre instance lors de l'appel "terraform destroy".

Une fois votre fichier de configuration enregistré, nous allons initialiser Terraform puis l'appliquer :

<pre>
$ terraform init

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.cloudstack: version = "~> 0.1"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
</pre>

Avant de lancer notre déploiement (ici en zone basic), nous pouvons vérifier ce qui sera exécuté sans rien appliquer via la commande :
#terraform plan

<pre>
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
</pre>

Si c'est bien ce que nous voulons faire alors nous pouvons appliquer via la commande "terraform apply" et saisir "yes" pour confirmer quand cela nous est demandé :

<pre>
$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

cloudstack_instance.TerraformVM1: Creating...
display_name: "" => "<computed>"
expunge: "" => "true"
group: "" => "<computed>"
ip_address: "" => "<computed>"
keypair: "" => "MY_SSH_KEYPAIR"
name: "" => "TerraformVM1"
network_id: "" => "<computed>"
project: "" => "<computed>"
root_disk_size: "" => "<computed>"
security_group_ids.#: "" => "1"
security_group_ids.3260590242: "" => "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "" => "t1.pico"
tags.%: "" => "<computed>"
template: "" => "Debian 9 - Minimal - 64bits"
zone: "" => "US-FL-MIAMI02-Z2-BASIC"
cloudstack_instance.TerraformVM1: Still creating... (10s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (20s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (30s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (40s elapsed)
cloudstack_instance.TerraformVM1: Creation complete after 46s (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
</pre>

Ici nous venons de déployer en quelques secondes, une instance nommée "TerraformVM1" avec le modèle "Debian 9 - Minimal - 64bits" dans la zone basic "US-FL-MIAMI02-Z2-BASIC" avec l'offre de calcul "t1.pico".

Nous pouvons voir celle-ci depuis notre interface Cloud Ikoula One :

[[File:wiki_terraform_1.png]]

Nous pouvons nous connecter sur notre instance fraichement déployée.
Note : Pour que cela fonctionne il faut que le [https://fr-wiki.ikoula.com/fr/Deploiement_d%27une_instance_en_zone_basic_(cliquez_pour_lire_la_suite)#Introduction_aux_groupes_de_s.C3.A9curit.C3.A9 Sicherheitsgruppe] dans lequel nous avons déployé le permette, sinon il faudra y rajouter une règle autorisant la connexion.

<pre>
$ ssh -i MY_SSH_KEYPAIR root@38.93.X.X
The authenticity of host '38.93.X.X (38.93.X.X)' can't be established.
ECDSA key fingerprint is SHA256:4D7s+xxxXXXXxxxxXXXXXXXXXxxxxXXXXXxxXXXXxxXXXxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '38.93.X.X' (ECDSA) to the list of known hosts.
Linux TerraformVM1 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@TerraformVM1:~#
</pre>

Pour supprimer notre instance, il nous suffira d'exécuter la commande "terraform destroy" et valider en saisissant "yes" quand cela nous est demandé :

<pre>
$ terraform destroy
cloudstack_instance.TerraformVM1: Refreshing state... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
- destroy

Terraform will perform the following actions:

- cloudstack_instance.TerraformVM1

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.

Enter a value: yes

cloudstack_instance.TerraformVM1: Destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)
cloudstack_instance.TerraformVM1: Still destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba, 10s elapsed)
cloudstack_instance.TerraformVM1: Destruction complete after 15s

Destroy complete! Resources: 1 destroyed.
</pre>

[[Catégorie :Cloudstack]]
[[Catégorie :Cloud public]]
[[Catégorie :Cloud]]

Bereitstellen Ihrer Instanzen mit Terraform

2021-07-29T14:43:36Z

Ikbot:

[[:zh:用Terraform部署你的实例]][[zh:用Terraform部署你的实例]]
[[:fr:Deployer vos instances avec Terraform]][[fr:Deployer vos instances avec Terraform]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Terraform|hier]] ansehen. 
[[:nl:Je instances uitrollen met Terraform]][[nl:Je instances uitrollen met Terraform]]
[[:it:Distribuire le istanze con Terraform]][[it:Distribuire le istanze con Terraform]]
[[:pt:Implementar as suas instâncias com a Terraform]][[pt:Implementar as suas instâncias com a Terraform]]
[[:es:Despliegue de sus instancias con Terraform]][[es:Despliegue de sus instancias con Terraform]]
[[:en:Deploying your instances with Terraform]][[en:Deploying your instances with Terraform]]
== Beschreibung ==

Wir werden sehen, wie man schnell eine oder mehrere IKOULA One Cloud-Instanzen über das Infrastruktur-als-Code-Tool "Terraform" bereitstellen kann.

Als Erstes müssen Sie Terraform installieren, falls Sie dies noch nicht getan haben, und ein IKOULA One Cloud-Konto besitzen.
Terraform ist für die meisten Betriebssysteme unter dem folgenden Link verfügbar: https://www.terraform.io/downloads.html

Terraform unterstützt Dutzende von Anbietern, eine Liste davon ist auf der Terraform-Website verfügbar (https://www.terraform.io/docs/providers/).
Wir werden den Anbieter "Cloudstack" für die Bereitstellung auf Cloud Ikoula One verwenden.

== Bereitstellen einer einzelnen Instanz ==

Wir werden unsere erste Terraform-Konfigurationsdatei schreiben, die die Bereitstellung einer einzelnen IKOULA-Cloud-Instanz ermöglicht:

Dies ist eine Textdatei mit der Erweiterung ".tf" (achten Sie darauf, dass Sie nicht mehrere ".tf"-Dateien in Ihrem Arbeitsverzeichnis erstellen, da Terraform sonst alle lädt). Wir werden das klassische Terraform-Format verwenden, aber es ist auch möglich, eine JSON-Syntax zu verwenden.

Hier ist der Inhalt unserer Terraform-Datei, die Sie mit Ihren eigenen Parametern anpassen können:

'''Für die Bereitstellung einer Instanz in der Basiszone''':

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource >" {
zone = "< Nom de la zone basic Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
security_group_ids = ["< ID de votre groupe de sécurité Cloud Ikoula One à utiliser >",]
}
</pre>

* '''Pour le déploiement d'une instance en zone avancée''' (avec création d'une règle de redirection de port, pour ssh dans cet exemple) :

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource d'instance >" {
zone = "< Nom de la zone avancée/adv Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
network_id = ["< ID de votre réseau d'invités Cloud Ikoula One à utiliser >",]
}

# Redirection de port (ici SSH)

resource "cloudstack_port_forward" "SshTerraformVM1" {
ip_address_id = "< ID de l'adresse ip NAT Source de votre réseau d'invités >"
forward {
protocol = "tcp"
private_port = "22"
public_port = "< port ssh publique de votre choix>"
virtual_machine_id = "${cloudstack_instance.< Nom que vous avez choisis au-dessus pour votre ressource d'instance >.id}"
}
}
</pre>

Note : la ligne 'expunge = "true"' nous permettra de supprimer notre instance lors de l'appel "terraform destroy".

Une fois votre fichier de configuration enregistré, nous allons initialiser Terraform puis l'appliquer :

<pre>
$ terraform init

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.cloudstack: version = "~> 0.1"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
</pre>

Avant de lancer notre déploiement (ici en zone basic), nous pouvons vérifier ce qui sera exécuté sans rien appliquer via la commande :
#terraform plan

<pre>
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
</pre>

Si c'est bien ce que nous voulons faire alors nous pouvons appliquer via la commande "terraform apply" et saisir "yes" pour confirmer quand cela nous est demandé :

<pre>
$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

cloudstack_instance.TerraformVM1: Creating...
display_name: "" => "<computed>"
expunge: "" => "true"
group: "" => "<computed>"
ip_address: "" => "<computed>"
keypair: "" => "MY_SSH_KEYPAIR"
name: "" => "TerraformVM1"
network_id: "" => "<computed>"
project: "" => "<computed>"
root_disk_size: "" => "<computed>"
security_group_ids.#: "" => "1"
security_group_ids.3260590242: "" => "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "" => "t1.pico"
tags.%: "" => "<computed>"
template: "" => "Debian 9 - Minimal - 64bits"
zone: "" => "US-FL-MIAMI02-Z2-BASIC"
cloudstack_instance.TerraformVM1: Still creating... (10s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (20s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (30s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (40s elapsed)
cloudstack_instance.TerraformVM1: Creation complete after 46s (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
</pre>

Ici nous venons de déployer en quelques secondes, une instance nommée "TerraformVM1" avec le modèle "Debian 9 - Minimal - 64bits" dans la zone basic "US-FL-MIAMI02-Z2-BASIC" avec l'offre de calcul "t1.pico".

Nous pouvons voir celle-ci depuis notre interface Cloud Ikoula One :

[[File:wiki_terraform_1.png]]

Nous pouvons nous connecter sur notre instance fraichement déployée.
Note : Pour que cela fonctionne il faut que le [https://fr-wiki.ikoula.com/fr/Deploiement_d%27une_instance_en_zone_basic_(cliquez_pour_lire_la_suite)#Introduction_aux_groupes_de_s.C3.A9curit.C3.A9 Sicherheitsgruppe] dans lequel nous avons déployé le permette, sinon il faudra y rajouter une règle autorisant la connexion.

<pre>
$ ssh -i MY_SSH_KEYPAIR root@38.93.X.X
The authenticity of host '38.93.X.X (38.93.X.X)' can't be established.
ECDSA key fingerprint is SHA256:4D7s+xxxXXXXxxxxXXXXXXXXXxxxxXXXXXxxXXXXxxXXXxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '38.93.X.X' (ECDSA) to the list of known hosts.
Linux TerraformVM1 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@TerraformVM1:~#
</pre>

Pour supprimer notre instance, il nous suffira d'exécuter la commande "terraform destroy" et valider en saisissant "yes" quand cela nous est demandé :

<pre>
$ terraform destroy
cloudstack_instance.TerraformVM1: Refreshing state... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
- destroy

Terraform will perform the following actions:

- cloudstack_instance.TerraformVM1

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.

Enter a value: yes

cloudstack_instance.TerraformVM1: Destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)
cloudstack_instance.TerraformVM1: Still destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba, 10s elapsed)
cloudstack_instance.TerraformVM1: Destruction complete after 15s

Destroy complete! Resources: 1 destroyed.
</pre>

[[Catégorie :Cloudstack]]
[[Catégorie :Cloud public]]
[[Catégorie :Cloud]]

Bereitstellen Ihrer Instanzen mit Terraform

2021-07-29T14:41:38Z

Ikbot: Die Seite wurde neu angelegt: „:fr:Dep…“

[[:fr:Deployer vos instances avec Terraform]][[fr:Deployer vos instances avec Terraform]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Terraform|hier]] ansehen. 
[[:nl:Je instances uitrollen met Terraform]][[nl:Je instances uitrollen met Terraform]]
[[:it:Distribuire le istanze con Terraform]][[it:Distribuire le istanze con Terraform]]
[[:pt:Implementar as suas instâncias com a Terraform]][[pt:Implementar as suas instâncias com a Terraform]]
[[:es:Despliegue de sus instancias con Terraform]][[es:Despliegue de sus instancias con Terraform]]
[[:en:Deploying your instances with Terraform]][[en:Deploying your instances with Terraform]]
== Beschreibung ==

Wir werden sehen, wie man schnell eine oder mehrere IKOULA One Cloud-Instanzen über das Infrastruktur-als-Code-Tool "Terraform" bereitstellen kann.

Als Erstes müssen Sie Terraform installieren, falls Sie dies noch nicht getan haben, und ein IKOULA One Cloud-Konto besitzen.
Terraform ist für die meisten Betriebssysteme unter dem folgenden Link verfügbar: https://www.terraform.io/downloads.html

Terraform unterstützt Dutzende von Anbietern, eine Liste davon ist auf der Terraform-Website verfügbar (https://www.terraform.io/docs/providers/).
Wir werden den Anbieter "Cloudstack" für die Bereitstellung auf Cloud Ikoula One verwenden.

== Bereitstellen einer einzelnen Instanz ==

Wir werden unsere erste Terraform-Konfigurationsdatei schreiben, die die Bereitstellung einer einzelnen IKOULA-Cloud-Instanz ermöglicht:

Dies ist eine Textdatei mit der Erweiterung ".tf" (achten Sie darauf, dass Sie nicht mehrere ".tf"-Dateien in Ihrem Arbeitsverzeichnis erstellen, da Terraform sonst alle lädt). Wir werden das klassische Terraform-Format verwenden, aber es ist auch möglich, eine JSON-Syntax zu verwenden.

Hier ist der Inhalt unserer Terraform-Datei, die Sie mit Ihren eigenen Parametern anpassen können:

'''Für die Bereitstellung einer Instanz in der Basiszone''':

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource >" {
zone = "< Nom de la zone basic Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
security_group_ids = ["< ID de votre groupe de sécurité Cloud Ikoula One à utiliser >",]
}
</pre>

* '''Pour le déploiement d'une instance en zone avancée''' (avec création d'une règle de redirection de port, pour ssh dans cet exemple) :

<pre>
provider "cloudstack" {
api_url = "https://cloudstack.ikoula.com/client/api"
api_key = "< Votre clé API de votre compte/utilisateur Cloud Ikoula One >"
secret_key = "< Votre clé secrète de votre compte/utilisateur Cloud Ikoula One>"
}

resource "cloudstack_instance" "< Nom de votre choix pour votre ressource d'instance >" {
zone = "< Nom de la zone avancée/adv Cloud Ikoula One de votre choix >"
service_offering = "< Nom de l'offre de calcul Cloud Ikoula One de votre choix > "
template = "< Nom du modèle Cloud Ikoula One de votre choix"
name = "< Nom de votre choix pour votre instance Cloud Ikoula One"
keypair = "< Nom de votre paire de clé SSH Cloud Ikoula One>"
expunge = "true"
network_id = ["< ID de votre réseau d'invités Cloud Ikoula One à utiliser >",]
}

# Redirection de port (ici SSH)

resource "cloudstack_port_forward" "SshTerraformVM1" {
ip_address_id = "< ID de l'adresse ip NAT Source de votre réseau d'invités >"
forward {
protocol = "tcp"
private_port = "22"
public_port = "< port ssh publique de votre choix>"
virtual_machine_id = "${cloudstack_instance.< Nom que vous avez choisis au-dessus pour votre ressource d'instance >.id}"
}
}
</pre>

Note : la ligne 'expunge = "true"' nous permettra de supprimer notre instance lors de l'appel "terraform destroy".

Une fois votre fichier de configuration enregistré, nous allons initialiser Terraform puis l'appliquer :

<pre>
$ terraform init

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.cloudstack: version = "~> 0.1"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
</pre>

Avant de lancer notre déploiement (ici en zone basic), nous pouvons vérifier ce qui sera exécuté sans rien appliquer via la commande :
#terraform plan

<pre>
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
</pre>

Si c'est bien ce que nous voulons faire alors nous pouvons appliquer via la commande "terraform apply" et saisir "yes" pour confirmer quand cela nous est demandé :

<pre>
$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

+ cloudstack_instance.TerraformVM1
id: <computed>
display_name: <computed>
expunge: "true"
group: <computed>
ip_address: <computed>
keypair: "MY_SSH_KEYPAIR"
name: "TerraformVM1"
network_id: <computed>
project: <computed>
root_disk_size: <computed>
security_group_ids.#: "1"
security_group_ids.3260590242: "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "t1.pico"
tags.%: <computed>
template: "Debian 9 - Minimal - 64bits"
zone: "US-FL-MIAMI02-Z2-BASIC"

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

cloudstack_instance.TerraformVM1: Creating...
display_name: "" => "<computed>"
expunge: "" => "true"
group: "" => "<computed>"
ip_address: "" => "<computed>"
keypair: "" => "MY_SSH_KEYPAIR"
name: "" => "TerraformVM1"
network_id: "" => "<computed>"
project: "" => "<computed>"
root_disk_size: "" => "<computed>"
security_group_ids.#: "" => "1"
security_group_ids.3260590242: "" => "84be7eef7-4pne-51c6-9abf6f3f9-c4zoek90887"
service_offering: "" => "t1.pico"
tags.%: "" => "<computed>"
template: "" => "Debian 9 - Minimal - 64bits"
zone: "" => "US-FL-MIAMI02-Z2-BASIC"
cloudstack_instance.TerraformVM1: Still creating... (10s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (20s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (30s elapsed)
cloudstack_instance.TerraformVM1: Still creating... (40s elapsed)
cloudstack_instance.TerraformVM1: Creation complete after 46s (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
</pre>

Ici nous venons de déployer en quelques secondes, une instance nommée "TerraformVM1" avec le modèle "Debian 9 - Minimal - 64bits" dans la zone basic "US-FL-MIAMI02-Z2-BASIC" avec l'offre de calcul "t1.pico".

Nous pouvons voir celle-ci depuis notre interface Cloud Ikoula One :

[[File:wiki_terraform_1.png]]

Nous pouvons nous connecter sur notre instance fraichement déployée.
Note : Pour que cela fonctionne il faut que le [https://fr-wiki.ikoula.com/fr/Deploiement_d%27une_instance_en_zone_basic_(cliquez_pour_lire_la_suite)#Introduction_aux_groupes_de_s.C3.A9curit.C3.A9 Sicherheitsgruppe] dans lequel nous avons déployé le permette, sinon il faudra y rajouter une règle autorisant la connexion.

<pre>
$ ssh -i MY_SSH_KEYPAIR root@38.93.X.X
The authenticity of host '38.93.X.X (38.93.X.X)' can't be established.
ECDSA key fingerprint is SHA256:4D7s+xxxXXXXxxxxXXXXXXXXXxxxxXXXXXxxXXXXxxXXXxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '38.93.X.X' (ECDSA) to the list of known hosts.
Linux TerraformVM1 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@TerraformVM1:~#
</pre>

Pour supprimer notre instance, il nous suffira d'exécuter la commande "terraform destroy" et valider en saisissant "yes" quand cela nous est demandé :

<pre>
$ terraform destroy
cloudstack_instance.TerraformVM1: Refreshing state... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
- destroy

Terraform will perform the following actions:

- cloudstack_instance.TerraformVM1

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.

Enter a value: yes

cloudstack_instance.TerraformVM1: Destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba)
cloudstack_instance.TerraformVM1: Still destroying... (ID: ba1220fc-b777-48e2-b63a-5d21ccc930ba, 10s elapsed)
cloudstack_instance.TerraformVM1: Destruction complete after 15s

Destroy complete! Resources: 1 destroyed.
</pre>

[[Catégorie :Cloudstack]]
[[Catégorie :Cloud public]]
[[Catégorie :Cloud]]

Stellen Sie Ihre Instanzen mit Ansible bereit

2021-07-29T14:37:51Z

Ikbot:

[[:ro:Implementarea instanțelor cu Ansible]][[ro:Implementarea instanțelor cu Ansible]]
[[:ru:Развертывание ваших экземпляров с помощью Ansible]][[ru:Развертывание ваших экземпляров с помощью Ansible]]
[[:pl:Wdrażaj instancje za pomocą Ansible]][[pl:Wdrażaj instancje za pomocą Ansible]]
[[:ja:Ansibleによるインスタンスのデプロイ]][[ja:Ansibleによるインスタンスのデプロイ]]
[[:zh:用Ansible部署你的实例]][[zh:用Ansible部署你的实例]]
[[:fr:Deployer vos instances avec Ansible]][[fr:Deployer vos instances avec Ansible]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Ansible|hier]] ansehen. 
[[:nl:Implementeer uw instanties met Ansible]][[nl:Implementeer uw instanties met Ansible]]
[[:it:Distribuire le tue istanze con Ansible]][[it:Distribuire le tue istanze con Ansible]]
[[:pt:Implante as suas instâncias com Ansible]][[pt:Implante as suas instâncias com Ansible]]
[[:es:Despliegue de sus instancias con Ansible]][[es:Despliegue de sus instancias con Ansible]]
[[:en:Deploy your instances with Ansible]][[en:Deploy your instances with Ansible]]
== Beschreibung ==

Wir werden sehen, wie man IKOULA One Cloud-Instanzen schnell über das Ansible-Tool bereitstellt

Zunächst müssen Sie Ansible installieren (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) dann das Modul "cs_instance" (kann über "pip install cs" installiert werden). https://docs.ansible.com/ansible/2.6/modules/cs_instance_module.html) die es Ihnen ermöglicht, die Cloud Ikoula One API zu nutzen, wenn Sie dies noch nicht getan haben und ein Cloud IKOULA One-Konto besitzen.

Ansible ist für die meisten GNU/Linux-Distributionen und MacOS verfügbar, kann aber auch über Cygwin z.B. unter Microsoft Windows verwendet werden.

Bereitstellung einer Instanz mit einem einzigen Befehl mit ''Ansible''

Sie müssen zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von '''Ansible''' erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur noch diesen Befehl ausführen und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (z. B. ob Sie ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) entsprechend anpassen:

<pre>
ansible -i "localhost," -c local all -m cs_instance -a "name=<Nom de la VM> display_name=<Nom de la VM> state=present template=< Nom entre simples quotes ou ID du template voulu> api_region=CloudIkoulaOne zone=<Nom de la zone voulu> service_offering=< Nom de l’offre de calcul voulu > networks=<Nom du réseau existant voulu> ssh_key=<Nom de la paire de clés ssh CIO existante>"
</pre>

wobei "<Nom de l’offre de calcul voulu >" die Wahl von ist:

<pre>
"t1.pico" (1/2 Core CPU with 512MB RAM and 100Mbps NIC)
"t1.micro" (1 Core CPU with 1GB RAM and 100Mbps NIC)
"m1.small" (1 Core CPU with 1.7GB RAM and 100Mbps NIC)
"m1.medium" (2 Cores CPU with 3.8GB RAM and 100Mbps NIC)
"m1.large" (4 Cores CPU with 7.6GB RAM and 100Mbps NIC)
"m1.extralarge" (8 Cores CPU with 15.3GB RAM and 100Mbps NIC)
</pre>

Hier ist ein Beispiel und das Ergebnis der Ausführung:

<pre>
$ ansible -i "localhost," -c local all -m cs_instance -a "name=Debian9advz1 display_name=Debian9adv1 state=present template='Debian 9 - Minimal - 64bits' api_region=CloudIkoulaOne zone=EU-FR-IKDC1-Z1-ADV service_offering=t1.micro networks=My-Network-Z1 ssh_key=MY_SSHKEY"
localhost | SUCCESS => {
"account": "ikoula",
"affinity_groups": [],
"changed": true,
"created": "2018-09-12T10:05:00+0200",
"default_ip": "10.1.1.176",
"display_name": "Debian9adv1",
"domain": "ROOT",
"hypervisor": "XenServer",
"id": "3c60acc9-1480-48bc-ab78-934f0e607d6c",
"instance_name": "i-1079-67026-VM",
"name": "Debian9advz1",
"password": "KYqrT3h28qOs",
"password_enabled": true,
"security_groups": [],
"service_offering": "t1.micro",
"ssh_key": "MY_SSHKEY",
"state": "Running",
"tags": [],
"template": "Debian 9 - Minimal - 64bits",
"user_data": "",
"zone": "EU-FR-IKDC1-Z1-ADV"
}
</pre>

In diesem Beispiel stellen wir eine Debian 9-Instanz in der erweiterten Zone (EU-FR-IKDC1-Z1-ADV) bereit und verwenden das Rechenangebot "t1.micro" in unserem Netzwerk mit dem Namen "My-Network-Z1" und unserem SSH-Schlüsselpaar mit dem Namen "MY_SSHKEY".

Um alle verwendbaren Parameter und andere Beispiele zu sehen, können Sie die ansible-doc des Moduls "cs_instance" verwenden:

<pre>
$ ansible-doc cs_instance
> CS_INSTANCE (/usr/lib/python2.7/site-packages/ansible/modules/cloud/cloudstack/cs_instance.py)

Deploy, start, update, scale, restart, restore, stop and destroy instances.

Options (= is mandatory):

- account
Account the instance is related to.
[Default: None]
- affinity_groups
Affinity groups names to be applied to the new instance.
[Default: []]
- api_http_method
HTTP method used.
(Choices: get, post)[Default: get]
- api_key
API key of the CloudStack API.
[Default: None]
- api_region
Name of the ini section in the `cloustack.ini' file.
[Default: cloudstack]
- api_secret
Secret key of the CloudStack API.
[Default: None]
- api_timeout
HTTP timeout.
[Default: 10]
- api_url
URL of the CloudStack API e.g. https://cloud.example.com/client/api.
[Default: None]
- cpu
The number of CPUs to allocate to the instance, used with custom service offerings
[Default: None]
- cpu_speed
The clock speed/shares allocated to the instance, used with custom service offerings
[Default: None]
- disk_offering
Name of the disk offering to be used.
[Default: None]
- disk_size
Disk size in GByte required if deploying instance from ISO.
[Default: None]
...
</pre>

Hinweis: Die Ausgabe des Befehls ist aufgrund seiner Länge absichtlich gekürzt.

== Bereitstellung einer Instanz mit einem Ansible-Playbook ==

Auf die gleiche Weise wie oben müssen Sie zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von Ansible erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur eine Playbook-Datei (yml-Erweiterung / YAML-Format) erstellen, wie unten beschrieben, und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (ob Sie z. B. ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) anpassen:

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer erweiterten Zone:

<pre>
$ cat deploy_instance_adv.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
networks: "<Nom du réseau existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"
...
</pre>

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer Basiszone (hier wird einfach der Netzwerkparameter durch den Sicherheitsgruppenparameter ersetzt und die Rückgabe der öffentlichen IP-Adresse, die der VM zugewiesen wurde, nach der Bereitstellung hinzugefügt):

<pre>
$ cat deploy_instance_basic.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
security_groups: "<Nom du groupe de sécurité existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"

- name: "VM ip address:"
debug:
var: vminfo.default_ip
...
</pre>

Nachdem die Parameter und ihre Werte angepasst wurden, folgt ein Beispiel für die Ausführung des Playbooks (passen Sie den Namen Ihrer Playbook-Datei gegebenenfalls an):

<pre>
$ ansible-playbook -i "localhost," -c local deploy_instance_adv.yml

PLAY [all] ********************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [Create Debian instance in Cloud IKOULA One with Ansible Playbook] ********************************************************************************************************************************************************************************************************************************
changed: [localhost]

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0
</pre>

[[Catégorie :Cloud public]]
[[Catégorie:API]]
[[Catégorie :Cloud]]</Nom>

Stellen Sie Ihre Instanzen mit Ansible bereit

2021-07-29T14:36:28Z

Ikbot:

[[:ru:Развертывание ваших экземпляров с помощью Ansible]][[ru:Развертывание ваших экземпляров с помощью Ansible]]
[[:pl:Wdrażaj instancje za pomocą Ansible]][[pl:Wdrażaj instancje za pomocą Ansible]]
[[:ja:Ansibleによるインスタンスのデプロイ]][[ja:Ansibleによるインスタンスのデプロイ]]
[[:zh:用Ansible部署你的实例]][[zh:用Ansible部署你的实例]]
[[:fr:Deployer vos instances avec Ansible]][[fr:Deployer vos instances avec Ansible]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Ansible|hier]] ansehen. 
[[:nl:Implementeer uw instanties met Ansible]][[nl:Implementeer uw instanties met Ansible]]
[[:it:Distribuire le tue istanze con Ansible]][[it:Distribuire le tue istanze con Ansible]]
[[:pt:Implante as suas instâncias com Ansible]][[pt:Implante as suas instâncias com Ansible]]
[[:es:Despliegue de sus instancias con Ansible]][[es:Despliegue de sus instancias con Ansible]]
[[:en:Deploy your instances with Ansible]][[en:Deploy your instances with Ansible]]
== Beschreibung ==

Wir werden sehen, wie man IKOULA One Cloud-Instanzen schnell über das Ansible-Tool bereitstellt

Zunächst müssen Sie Ansible installieren (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) dann das Modul "cs_instance" (kann über "pip install cs" installiert werden). https://docs.ansible.com/ansible/2.6/modules/cs_instance_module.html) die es Ihnen ermöglicht, die Cloud Ikoula One API zu nutzen, wenn Sie dies noch nicht getan haben und ein Cloud IKOULA One-Konto besitzen.

Ansible ist für die meisten GNU/Linux-Distributionen und MacOS verfügbar, kann aber auch über Cygwin z.B. unter Microsoft Windows verwendet werden.

Bereitstellung einer Instanz mit einem einzigen Befehl mit ''Ansible''

Sie müssen zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von '''Ansible''' erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur noch diesen Befehl ausführen und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (z. B. ob Sie ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) entsprechend anpassen:

<pre>
ansible -i "localhost," -c local all -m cs_instance -a "name=<Nom de la VM> display_name=<Nom de la VM> state=present template=< Nom entre simples quotes ou ID du template voulu> api_region=CloudIkoulaOne zone=<Nom de la zone voulu> service_offering=< Nom de l’offre de calcul voulu > networks=<Nom du réseau existant voulu> ssh_key=<Nom de la paire de clés ssh CIO existante>"
</pre>

wobei "<Nom de l’offre de calcul voulu >" die Wahl von ist:

<pre>
"t1.pico" (1/2 Core CPU with 512MB RAM and 100Mbps NIC)
"t1.micro" (1 Core CPU with 1GB RAM and 100Mbps NIC)
"m1.small" (1 Core CPU with 1.7GB RAM and 100Mbps NIC)
"m1.medium" (2 Cores CPU with 3.8GB RAM and 100Mbps NIC)
"m1.large" (4 Cores CPU with 7.6GB RAM and 100Mbps NIC)
"m1.extralarge" (8 Cores CPU with 15.3GB RAM and 100Mbps NIC)
</pre>

Hier ist ein Beispiel und das Ergebnis der Ausführung:

<pre>
$ ansible -i "localhost," -c local all -m cs_instance -a "name=Debian9advz1 display_name=Debian9adv1 state=present template='Debian 9 - Minimal - 64bits' api_region=CloudIkoulaOne zone=EU-FR-IKDC1-Z1-ADV service_offering=t1.micro networks=My-Network-Z1 ssh_key=MY_SSHKEY"
localhost | SUCCESS => {
"account": "ikoula",
"affinity_groups": [],
"changed": true,
"created": "2018-09-12T10:05:00+0200",
"default_ip": "10.1.1.176",
"display_name": "Debian9adv1",
"domain": "ROOT",
"hypervisor": "XenServer",
"id": "3c60acc9-1480-48bc-ab78-934f0e607d6c",
"instance_name": "i-1079-67026-VM",
"name": "Debian9advz1",
"password": "KYqrT3h28qOs",
"password_enabled": true,
"security_groups": [],
"service_offering": "t1.micro",
"ssh_key": "MY_SSHKEY",
"state": "Running",
"tags": [],
"template": "Debian 9 - Minimal - 64bits",
"user_data": "",
"zone": "EU-FR-IKDC1-Z1-ADV"
}
</pre>

In diesem Beispiel stellen wir eine Debian 9-Instanz in der erweiterten Zone (EU-FR-IKDC1-Z1-ADV) bereit und verwenden das Rechenangebot "t1.micro" in unserem Netzwerk mit dem Namen "My-Network-Z1" und unserem SSH-Schlüsselpaar mit dem Namen "MY_SSHKEY".

Um alle verwendbaren Parameter und andere Beispiele zu sehen, können Sie die ansible-doc des Moduls "cs_instance" verwenden:

<pre>
$ ansible-doc cs_instance
> CS_INSTANCE (/usr/lib/python2.7/site-packages/ansible/modules/cloud/cloudstack/cs_instance.py)

Deploy, start, update, scale, restart, restore, stop and destroy instances.

Options (= is mandatory):

- account
Account the instance is related to.
[Default: None]
- affinity_groups
Affinity groups names to be applied to the new instance.
[Default: []]
- api_http_method
HTTP method used.
(Choices: get, post)[Default: get]
- api_key
API key of the CloudStack API.
[Default: None]
- api_region
Name of the ini section in the `cloustack.ini' file.
[Default: cloudstack]
- api_secret
Secret key of the CloudStack API.
[Default: None]
- api_timeout
HTTP timeout.
[Default: 10]
- api_url
URL of the CloudStack API e.g. https://cloud.example.com/client/api.
[Default: None]
- cpu
The number of CPUs to allocate to the instance, used with custom service offerings
[Default: None]
- cpu_speed
The clock speed/shares allocated to the instance, used with custom service offerings
[Default: None]
- disk_offering
Name of the disk offering to be used.
[Default: None]
- disk_size
Disk size in GByte required if deploying instance from ISO.
[Default: None]
...
</pre>

Hinweis: Die Ausgabe des Befehls ist aufgrund seiner Länge absichtlich gekürzt.

== Bereitstellung einer Instanz mit einem Ansible-Playbook ==

Auf die gleiche Weise wie oben müssen Sie zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von Ansible erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur eine Playbook-Datei (yml-Erweiterung / YAML-Format) erstellen, wie unten beschrieben, und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (ob Sie z. B. ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) anpassen:

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer erweiterten Zone:

<pre>
$ cat deploy_instance_adv.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
networks: "<Nom du réseau existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"
...
</pre>

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer Basiszone (hier wird einfach der Netzwerkparameter durch den Sicherheitsgruppenparameter ersetzt und die Rückgabe der öffentlichen IP-Adresse, die der VM zugewiesen wurde, nach der Bereitstellung hinzugefügt):

<pre>
$ cat deploy_instance_basic.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
security_groups: "<Nom du groupe de sécurité existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"

- name: "VM ip address:"
debug:
var: vminfo.default_ip
...
</pre>

Nachdem die Parameter und ihre Werte angepasst wurden, folgt ein Beispiel für die Ausführung des Playbooks (passen Sie den Namen Ihrer Playbook-Datei gegebenenfalls an):

<pre>
$ ansible-playbook -i "localhost," -c local deploy_instance_adv.yml

PLAY [all] ********************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [Create Debian instance in Cloud IKOULA One with Ansible Playbook] ********************************************************************************************************************************************************************************************************************************
changed: [localhost]

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0
</pre>

[[Catégorie :Cloud public]]
[[Catégorie:API]]
[[Catégorie :Cloud]]</Nom>

Stellen Sie Ihre Instanzen mit Ansible bereit

2021-07-29T14:35:30Z

Ikbot:

[[:pl:Wdrażaj instancje za pomocą Ansible]][[pl:Wdrażaj instancje za pomocą Ansible]]
[[:ja:Ansibleによるインスタンスのデプロイ]][[ja:Ansibleによるインスタンスのデプロイ]]
[[:zh:用Ansible部署你的实例]][[zh:用Ansible部署你的实例]]
[[:fr:Deployer vos instances avec Ansible]][[fr:Deployer vos instances avec Ansible]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Ansible|hier]] ansehen. 
[[:nl:Implementeer uw instanties met Ansible]][[nl:Implementeer uw instanties met Ansible]]
[[:it:Distribuire le tue istanze con Ansible]][[it:Distribuire le tue istanze con Ansible]]
[[:pt:Implante as suas instâncias com Ansible]][[pt:Implante as suas instâncias com Ansible]]
[[:es:Despliegue de sus instancias con Ansible]][[es:Despliegue de sus instancias con Ansible]]
[[:en:Deploy your instances with Ansible]][[en:Deploy your instances with Ansible]]
== Beschreibung ==

Wir werden sehen, wie man IKOULA One Cloud-Instanzen schnell über das Ansible-Tool bereitstellt

Zunächst müssen Sie Ansible installieren (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) dann das Modul "cs_instance" (kann über "pip install cs" installiert werden). https://docs.ansible.com/ansible/2.6/modules/cs_instance_module.html) die es Ihnen ermöglicht, die Cloud Ikoula One API zu nutzen, wenn Sie dies noch nicht getan haben und ein Cloud IKOULA One-Konto besitzen.

Ansible ist für die meisten GNU/Linux-Distributionen und MacOS verfügbar, kann aber auch über Cygwin z.B. unter Microsoft Windows verwendet werden.

Bereitstellung einer Instanz mit einem einzigen Befehl mit ''Ansible''

Sie müssen zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von '''Ansible''' erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur noch diesen Befehl ausführen und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (z. B. ob Sie ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) entsprechend anpassen:

<pre>
ansible -i "localhost," -c local all -m cs_instance -a "name=<Nom de la VM> display_name=<Nom de la VM> state=present template=< Nom entre simples quotes ou ID du template voulu> api_region=CloudIkoulaOne zone=<Nom de la zone voulu> service_offering=< Nom de l’offre de calcul voulu > networks=<Nom du réseau existant voulu> ssh_key=<Nom de la paire de clés ssh CIO existante>"
</pre>

wobei "<Nom de l’offre de calcul voulu >" die Wahl von ist:

<pre>
"t1.pico" (1/2 Core CPU with 512MB RAM and 100Mbps NIC)
"t1.micro" (1 Core CPU with 1GB RAM and 100Mbps NIC)
"m1.small" (1 Core CPU with 1.7GB RAM and 100Mbps NIC)
"m1.medium" (2 Cores CPU with 3.8GB RAM and 100Mbps NIC)
"m1.large" (4 Cores CPU with 7.6GB RAM and 100Mbps NIC)
"m1.extralarge" (8 Cores CPU with 15.3GB RAM and 100Mbps NIC)
</pre>

Hier ist ein Beispiel und das Ergebnis der Ausführung:

<pre>
$ ansible -i "localhost," -c local all -m cs_instance -a "name=Debian9advz1 display_name=Debian9adv1 state=present template='Debian 9 - Minimal - 64bits' api_region=CloudIkoulaOne zone=EU-FR-IKDC1-Z1-ADV service_offering=t1.micro networks=My-Network-Z1 ssh_key=MY_SSHKEY"
localhost | SUCCESS => {
"account": "ikoula",
"affinity_groups": [],
"changed": true,
"created": "2018-09-12T10:05:00+0200",
"default_ip": "10.1.1.176",
"display_name": "Debian9adv1",
"domain": "ROOT",
"hypervisor": "XenServer",
"id": "3c60acc9-1480-48bc-ab78-934f0e607d6c",
"instance_name": "i-1079-67026-VM",
"name": "Debian9advz1",
"password": "KYqrT3h28qOs",
"password_enabled": true,
"security_groups": [],
"service_offering": "t1.micro",
"ssh_key": "MY_SSHKEY",
"state": "Running",
"tags": [],
"template": "Debian 9 - Minimal - 64bits",
"user_data": "",
"zone": "EU-FR-IKDC1-Z1-ADV"
}
</pre>

In diesem Beispiel stellen wir eine Debian 9-Instanz in der erweiterten Zone (EU-FR-IKDC1-Z1-ADV) bereit und verwenden das Rechenangebot "t1.micro" in unserem Netzwerk mit dem Namen "My-Network-Z1" und unserem SSH-Schlüsselpaar mit dem Namen "MY_SSHKEY".

Um alle verwendbaren Parameter und andere Beispiele zu sehen, können Sie die ansible-doc des Moduls "cs_instance" verwenden:

<pre>
$ ansible-doc cs_instance
> CS_INSTANCE (/usr/lib/python2.7/site-packages/ansible/modules/cloud/cloudstack/cs_instance.py)

Deploy, start, update, scale, restart, restore, stop and destroy instances.

Options (= is mandatory):

- account
Account the instance is related to.
[Default: None]
- affinity_groups
Affinity groups names to be applied to the new instance.
[Default: []]
- api_http_method
HTTP method used.
(Choices: get, post)[Default: get]
- api_key
API key of the CloudStack API.
[Default: None]
- api_region
Name of the ini section in the `cloustack.ini' file.
[Default: cloudstack]
- api_secret
Secret key of the CloudStack API.
[Default: None]
- api_timeout
HTTP timeout.
[Default: 10]
- api_url
URL of the CloudStack API e.g. https://cloud.example.com/client/api.
[Default: None]
- cpu
The number of CPUs to allocate to the instance, used with custom service offerings
[Default: None]
- cpu_speed
The clock speed/shares allocated to the instance, used with custom service offerings
[Default: None]
- disk_offering
Name of the disk offering to be used.
[Default: None]
- disk_size
Disk size in GByte required if deploying instance from ISO.
[Default: None]
...
</pre>

Hinweis: Die Ausgabe des Befehls ist aufgrund seiner Länge absichtlich gekürzt.

== Bereitstellung einer Instanz mit einem Ansible-Playbook ==

Auf die gleiche Weise wie oben müssen Sie zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von Ansible erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur eine Playbook-Datei (yml-Erweiterung / YAML-Format) erstellen, wie unten beschrieben, und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (ob Sie z. B. ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) anpassen:

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer erweiterten Zone:

<pre>
$ cat deploy_instance_adv.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
networks: "<Nom du réseau existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"
...
</pre>

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer Basiszone (hier wird einfach der Netzwerkparameter durch den Sicherheitsgruppenparameter ersetzt und die Rückgabe der öffentlichen IP-Adresse, die der VM zugewiesen wurde, nach der Bereitstellung hinzugefügt):

<pre>
$ cat deploy_instance_basic.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
security_groups: "<Nom du groupe de sécurité existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"

- name: "VM ip address:"
debug:
var: vminfo.default_ip
...
</pre>

Nachdem die Parameter und ihre Werte angepasst wurden, folgt ein Beispiel für die Ausführung des Playbooks (passen Sie den Namen Ihrer Playbook-Datei gegebenenfalls an):

<pre>
$ ansible-playbook -i "localhost," -c local deploy_instance_adv.yml

PLAY [all] ********************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [Create Debian instance in Cloud IKOULA One with Ansible Playbook] ********************************************************************************************************************************************************************************************************************************
changed: [localhost]

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0
</pre>

[[Catégorie :Cloud public]]
[[Catégorie:API]]
[[Catégorie :Cloud]]</Nom>

Stellen Sie Ihre Instanzen mit Ansible bereit

2021-07-29T14:34:40Z

Ikbot:

[[:ja:Ansibleによるインスタンスのデプロイ]][[ja:Ansibleによるインスタンスのデプロイ]]
[[:zh:用Ansible部署你的实例]][[zh:用Ansible部署你的实例]]
[[:fr:Deployer vos instances avec Ansible]][[fr:Deployer vos instances avec Ansible]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Ansible|hier]] ansehen. 
[[:nl:Implementeer uw instanties met Ansible]][[nl:Implementeer uw instanties met Ansible]]
[[:it:Distribuire le tue istanze con Ansible]][[it:Distribuire le tue istanze con Ansible]]
[[:pt:Implante as suas instâncias com Ansible]][[pt:Implante as suas instâncias com Ansible]]
[[:es:Despliegue de sus instancias con Ansible]][[es:Despliegue de sus instancias con Ansible]]
[[:en:Deploy your instances with Ansible]][[en:Deploy your instances with Ansible]]
== Beschreibung ==

Wir werden sehen, wie man IKOULA One Cloud-Instanzen schnell über das Ansible-Tool bereitstellt

Zunächst müssen Sie Ansible installieren (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) dann das Modul "cs_instance" (kann über "pip install cs" installiert werden). https://docs.ansible.com/ansible/2.6/modules/cs_instance_module.html) die es Ihnen ermöglicht, die Cloud Ikoula One API zu nutzen, wenn Sie dies noch nicht getan haben und ein Cloud IKOULA One-Konto besitzen.

Ansible ist für die meisten GNU/Linux-Distributionen und MacOS verfügbar, kann aber auch über Cygwin z.B. unter Microsoft Windows verwendet werden.

Bereitstellung einer Instanz mit einem einzigen Befehl mit ''Ansible''

Sie müssen zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von '''Ansible''' erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur noch diesen Befehl ausführen und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (z. B. ob Sie ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) entsprechend anpassen:

<pre>
ansible -i "localhost," -c local all -m cs_instance -a "name=<Nom de la VM> display_name=<Nom de la VM> state=present template=< Nom entre simples quotes ou ID du template voulu> api_region=CloudIkoulaOne zone=<Nom de la zone voulu> service_offering=< Nom de l’offre de calcul voulu > networks=<Nom du réseau existant voulu> ssh_key=<Nom de la paire de clés ssh CIO existante>"
</pre>

wobei "<Nom de l’offre de calcul voulu >" die Wahl von ist:

<pre>
"t1.pico" (1/2 Core CPU with 512MB RAM and 100Mbps NIC)
"t1.micro" (1 Core CPU with 1GB RAM and 100Mbps NIC)
"m1.small" (1 Core CPU with 1.7GB RAM and 100Mbps NIC)
"m1.medium" (2 Cores CPU with 3.8GB RAM and 100Mbps NIC)
"m1.large" (4 Cores CPU with 7.6GB RAM and 100Mbps NIC)
"m1.extralarge" (8 Cores CPU with 15.3GB RAM and 100Mbps NIC)
</pre>

Hier ist ein Beispiel und das Ergebnis der Ausführung:

<pre>
$ ansible -i "localhost," -c local all -m cs_instance -a "name=Debian9advz1 display_name=Debian9adv1 state=present template='Debian 9 - Minimal - 64bits' api_region=CloudIkoulaOne zone=EU-FR-IKDC1-Z1-ADV service_offering=t1.micro networks=My-Network-Z1 ssh_key=MY_SSHKEY"
localhost | SUCCESS => {
"account": "ikoula",
"affinity_groups": [],
"changed": true,
"created": "2018-09-12T10:05:00+0200",
"default_ip": "10.1.1.176",
"display_name": "Debian9adv1",
"domain": "ROOT",
"hypervisor": "XenServer",
"id": "3c60acc9-1480-48bc-ab78-934f0e607d6c",
"instance_name": "i-1079-67026-VM",
"name": "Debian9advz1",
"password": "KYqrT3h28qOs",
"password_enabled": true,
"security_groups": [],
"service_offering": "t1.micro",
"ssh_key": "MY_SSHKEY",
"state": "Running",
"tags": [],
"template": "Debian 9 - Minimal - 64bits",
"user_data": "",
"zone": "EU-FR-IKDC1-Z1-ADV"
}
</pre>

In diesem Beispiel stellen wir eine Debian 9-Instanz in der erweiterten Zone (EU-FR-IKDC1-Z1-ADV) bereit und verwenden das Rechenangebot "t1.micro" in unserem Netzwerk mit dem Namen "My-Network-Z1" und unserem SSH-Schlüsselpaar mit dem Namen "MY_SSHKEY".

Um alle verwendbaren Parameter und andere Beispiele zu sehen, können Sie die ansible-doc des Moduls "cs_instance" verwenden:

<pre>
$ ansible-doc cs_instance
> CS_INSTANCE (/usr/lib/python2.7/site-packages/ansible/modules/cloud/cloudstack/cs_instance.py)

Deploy, start, update, scale, restart, restore, stop and destroy instances.

Options (= is mandatory):

- account
Account the instance is related to.
[Default: None]
- affinity_groups
Affinity groups names to be applied to the new instance.
[Default: []]
- api_http_method
HTTP method used.
(Choices: get, post)[Default: get]
- api_key
API key of the CloudStack API.
[Default: None]
- api_region
Name of the ini section in the `cloustack.ini' file.
[Default: cloudstack]
- api_secret
Secret key of the CloudStack API.
[Default: None]
- api_timeout
HTTP timeout.
[Default: 10]
- api_url
URL of the CloudStack API e.g. https://cloud.example.com/client/api.
[Default: None]
- cpu
The number of CPUs to allocate to the instance, used with custom service offerings
[Default: None]
- cpu_speed
The clock speed/shares allocated to the instance, used with custom service offerings
[Default: None]
- disk_offering
Name of the disk offering to be used.
[Default: None]
- disk_size
Disk size in GByte required if deploying instance from ISO.
[Default: None]
...
</pre>

Hinweis: Die Ausgabe des Befehls ist aufgrund seiner Länge absichtlich gekürzt.

== Bereitstellung einer Instanz mit einem Ansible-Playbook ==

Auf die gleiche Weise wie oben müssen Sie zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von Ansible erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur eine Playbook-Datei (yml-Erweiterung / YAML-Format) erstellen, wie unten beschrieben, und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (ob Sie z. B. ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) anpassen:

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer erweiterten Zone:

<pre>
$ cat deploy_instance_adv.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
networks: "<Nom du réseau existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"
...
</pre>

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer Basiszone (hier wird einfach der Netzwerkparameter durch den Sicherheitsgruppenparameter ersetzt und die Rückgabe der öffentlichen IP-Adresse, die der VM zugewiesen wurde, nach der Bereitstellung hinzugefügt):

<pre>
$ cat deploy_instance_basic.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
security_groups: "<Nom du groupe de sécurité existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"

- name: "VM ip address:"
debug:
var: vminfo.default_ip
...
</pre>

Nachdem die Parameter und ihre Werte angepasst wurden, folgt ein Beispiel für die Ausführung des Playbooks (passen Sie den Namen Ihrer Playbook-Datei gegebenenfalls an):

<pre>
$ ansible-playbook -i "localhost," -c local deploy_instance_adv.yml

PLAY [all] ********************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [Create Debian instance in Cloud IKOULA One with Ansible Playbook] ********************************************************************************************************************************************************************************************************************************
changed: [localhost]

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0
</pre>

[[Catégorie :Cloud public]]
[[Catégorie:API]]
[[Catégorie :Cloud]]</Nom>

Stellen Sie Ihre Instanzen mit Ansible bereit

2021-07-29T14:33:54Z

Ikbot:

[[:zh:用Ansible部署你的实例]][[zh:用Ansible部署你的实例]]
[[:fr:Deployer vos instances avec Ansible]][[fr:Deployer vos instances avec Ansible]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Ansible|hier]] ansehen. 
[[:nl:Implementeer uw instanties met Ansible]][[nl:Implementeer uw instanties met Ansible]]
[[:it:Distribuire le tue istanze con Ansible]][[it:Distribuire le tue istanze con Ansible]]
[[:pt:Implante as suas instâncias com Ansible]][[pt:Implante as suas instâncias com Ansible]]
[[:es:Despliegue de sus instancias con Ansible]][[es:Despliegue de sus instancias con Ansible]]
[[:en:Deploy your instances with Ansible]][[en:Deploy your instances with Ansible]]
== Beschreibung ==

Wir werden sehen, wie man IKOULA One Cloud-Instanzen schnell über das Ansible-Tool bereitstellt

Zunächst müssen Sie Ansible installieren (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) dann das Modul "cs_instance" (kann über "pip install cs" installiert werden). https://docs.ansible.com/ansible/2.6/modules/cs_instance_module.html) die es Ihnen ermöglicht, die Cloud Ikoula One API zu nutzen, wenn Sie dies noch nicht getan haben und ein Cloud IKOULA One-Konto besitzen.

Ansible ist für die meisten GNU/Linux-Distributionen und MacOS verfügbar, kann aber auch über Cygwin z.B. unter Microsoft Windows verwendet werden.

Bereitstellung einer Instanz mit einem einzigen Befehl mit ''Ansible''

Sie müssen zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von '''Ansible''' erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur noch diesen Befehl ausführen und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (z. B. ob Sie ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) entsprechend anpassen:

<pre>
ansible -i "localhost," -c local all -m cs_instance -a "name=<Nom de la VM> display_name=<Nom de la VM> state=present template=< Nom entre simples quotes ou ID du template voulu> api_region=CloudIkoulaOne zone=<Nom de la zone voulu> service_offering=< Nom de l’offre de calcul voulu > networks=<Nom du réseau existant voulu> ssh_key=<Nom de la paire de clés ssh CIO existante>"
</pre>

wobei "<Nom de l’offre de calcul voulu >" die Wahl von ist:

<pre>
"t1.pico" (1/2 Core CPU with 512MB RAM and 100Mbps NIC)
"t1.micro" (1 Core CPU with 1GB RAM and 100Mbps NIC)
"m1.small" (1 Core CPU with 1.7GB RAM and 100Mbps NIC)
"m1.medium" (2 Cores CPU with 3.8GB RAM and 100Mbps NIC)
"m1.large" (4 Cores CPU with 7.6GB RAM and 100Mbps NIC)
"m1.extralarge" (8 Cores CPU with 15.3GB RAM and 100Mbps NIC)
</pre>

Hier ist ein Beispiel und das Ergebnis der Ausführung:

<pre>
$ ansible -i "localhost," -c local all -m cs_instance -a "name=Debian9advz1 display_name=Debian9adv1 state=present template='Debian 9 - Minimal - 64bits' api_region=CloudIkoulaOne zone=EU-FR-IKDC1-Z1-ADV service_offering=t1.micro networks=My-Network-Z1 ssh_key=MY_SSHKEY"
localhost | SUCCESS => {
"account": "ikoula",
"affinity_groups": [],
"changed": true,
"created": "2018-09-12T10:05:00+0200",
"default_ip": "10.1.1.176",
"display_name": "Debian9adv1",
"domain": "ROOT",
"hypervisor": "XenServer",
"id": "3c60acc9-1480-48bc-ab78-934f0e607d6c",
"instance_name": "i-1079-67026-VM",
"name": "Debian9advz1",
"password": "KYqrT3h28qOs",
"password_enabled": true,
"security_groups": [],
"service_offering": "t1.micro",
"ssh_key": "MY_SSHKEY",
"state": "Running",
"tags": [],
"template": "Debian 9 - Minimal - 64bits",
"user_data": "",
"zone": "EU-FR-IKDC1-Z1-ADV"
}
</pre>

In diesem Beispiel stellen wir eine Debian 9-Instanz in der erweiterten Zone (EU-FR-IKDC1-Z1-ADV) bereit und verwenden das Rechenangebot "t1.micro" in unserem Netzwerk mit dem Namen "My-Network-Z1" und unserem SSH-Schlüsselpaar mit dem Namen "MY_SSHKEY".

Um alle verwendbaren Parameter und andere Beispiele zu sehen, können Sie die ansible-doc des Moduls "cs_instance" verwenden:

<pre>
$ ansible-doc cs_instance
> CS_INSTANCE (/usr/lib/python2.7/site-packages/ansible/modules/cloud/cloudstack/cs_instance.py)

Deploy, start, update, scale, restart, restore, stop and destroy instances.

Options (= is mandatory):

- account
Account the instance is related to.
[Default: None]
- affinity_groups
Affinity groups names to be applied to the new instance.
[Default: []]
- api_http_method
HTTP method used.
(Choices: get, post)[Default: get]
- api_key
API key of the CloudStack API.
[Default: None]
- api_region
Name of the ini section in the `cloustack.ini' file.
[Default: cloudstack]
- api_secret
Secret key of the CloudStack API.
[Default: None]
- api_timeout
HTTP timeout.
[Default: 10]
- api_url
URL of the CloudStack API e.g. https://cloud.example.com/client/api.
[Default: None]
- cpu
The number of CPUs to allocate to the instance, used with custom service offerings
[Default: None]
- cpu_speed
The clock speed/shares allocated to the instance, used with custom service offerings
[Default: None]
- disk_offering
Name of the disk offering to be used.
[Default: None]
- disk_size
Disk size in GByte required if deploying instance from ISO.
[Default: None]
...
</pre>

Hinweis: Die Ausgabe des Befehls ist aufgrund seiner Länge absichtlich gekürzt.

== Bereitstellung einer Instanz mit einem Ansible-Playbook ==

Auf die gleiche Weise wie oben müssen Sie zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von Ansible erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur eine Playbook-Datei (yml-Erweiterung / YAML-Format) erstellen, wie unten beschrieben, und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (ob Sie z. B. ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) anpassen:

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer erweiterten Zone:

<pre>
$ cat deploy_instance_adv.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
networks: "<Nom du réseau existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"
...
</pre>

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer Basiszone (hier wird einfach der Netzwerkparameter durch den Sicherheitsgruppenparameter ersetzt und die Rückgabe der öffentlichen IP-Adresse, die der VM zugewiesen wurde, nach der Bereitstellung hinzugefügt):

<pre>
$ cat deploy_instance_basic.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
security_groups: "<Nom du groupe de sécurité existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"

- name: "VM ip address:"
debug:
var: vminfo.default_ip
...
</pre>

Nachdem die Parameter und ihre Werte angepasst wurden, folgt ein Beispiel für die Ausführung des Playbooks (passen Sie den Namen Ihrer Playbook-Datei gegebenenfalls an):

<pre>
$ ansible-playbook -i "localhost," -c local deploy_instance_adv.yml

PLAY [all] ********************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [Create Debian instance in Cloud IKOULA One with Ansible Playbook] ********************************************************************************************************************************************************************************************************************************
changed: [localhost]

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0
</pre>

[[Catégorie :Cloud public]]
[[Catégorie:API]]
[[Catégorie :Cloud]]</Nom>

Stellen Sie Ihre Instanzen mit Ansible bereit

2021-07-29T14:32:44Z

Ikbot: Die Seite wurde neu angelegt: „:fr:Deploye…“

[[:fr:Deployer vos instances avec Ansible]][[fr:Deployer vos instances avec Ansible]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deployer vos instances avec Ansible|hier]] ansehen. 
[[:nl:Implementeer uw instanties met Ansible]][[nl:Implementeer uw instanties met Ansible]]
[[:it:Distribuire le tue istanze con Ansible]][[it:Distribuire le tue istanze con Ansible]]
[[:pt:Implante as suas instâncias com Ansible]][[pt:Implante as suas instâncias com Ansible]]
[[:es:Despliegue de sus instancias con Ansible]][[es:Despliegue de sus instancias con Ansible]]
[[:en:Deploy your instances with Ansible]][[en:Deploy your instances with Ansible]]
== Beschreibung ==

Wir werden sehen, wie man IKOULA One Cloud-Instanzen schnell über das Ansible-Tool bereitstellt

Zunächst müssen Sie Ansible installieren (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) dann das Modul "cs_instance" (kann über "pip install cs" installiert werden). https://docs.ansible.com/ansible/2.6/modules/cs_instance_module.html) die es Ihnen ermöglicht, die Cloud Ikoula One API zu nutzen, wenn Sie dies noch nicht getan haben und ein Cloud IKOULA One-Konto besitzen.

Ansible ist für die meisten GNU/Linux-Distributionen und MacOS verfügbar, kann aber auch über Cygwin z.B. unter Microsoft Windows verwendet werden.

Bereitstellung einer Instanz mit einem einzigen Befehl mit ''Ansible''

Sie müssen zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von '''Ansible''' erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur noch diesen Befehl ausführen und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (z. B. ob Sie ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) entsprechend anpassen:

<pre>
ansible -i "localhost," -c local all -m cs_instance -a "name=<Nom de la VM> display_name=<Nom de la VM> state=present template=< Nom entre simples quotes ou ID du template voulu> api_region=CloudIkoulaOne zone=<Nom de la zone voulu> service_offering=< Nom de l’offre de calcul voulu > networks=<Nom du réseau existant voulu> ssh_key=<Nom de la paire de clés ssh CIO existante>"
</pre>

wobei "<Nom de l’offre de calcul voulu >" die Wahl von ist:

<pre>
"t1.pico" (1/2 Core CPU with 512MB RAM and 100Mbps NIC)
"t1.micro" (1 Core CPU with 1GB RAM and 100Mbps NIC)
"m1.small" (1 Core CPU with 1.7GB RAM and 100Mbps NIC)
"m1.medium" (2 Cores CPU with 3.8GB RAM and 100Mbps NIC)
"m1.large" (4 Cores CPU with 7.6GB RAM and 100Mbps NIC)
"m1.extralarge" (8 Cores CPU with 15.3GB RAM and 100Mbps NIC)
</pre>

Hier ist ein Beispiel und das Ergebnis der Ausführung:

<pre>
$ ansible -i "localhost," -c local all -m cs_instance -a "name=Debian9advz1 display_name=Debian9adv1 state=present template='Debian 9 - Minimal - 64bits' api_region=CloudIkoulaOne zone=EU-FR-IKDC1-Z1-ADV service_offering=t1.micro networks=My-Network-Z1 ssh_key=MY_SSHKEY"
localhost | SUCCESS => {
"account": "ikoula",
"affinity_groups": [],
"changed": true,
"created": "2018-09-12T10:05:00+0200",
"default_ip": "10.1.1.176",
"display_name": "Debian9adv1",
"domain": "ROOT",
"hypervisor": "XenServer",
"id": "3c60acc9-1480-48bc-ab78-934f0e607d6c",
"instance_name": "i-1079-67026-VM",
"name": "Debian9advz1",
"password": "KYqrT3h28qOs",
"password_enabled": true,
"security_groups": [],
"service_offering": "t1.micro",
"ssh_key": "MY_SSHKEY",
"state": "Running",
"tags": [],
"template": "Debian 9 - Minimal - 64bits",
"user_data": "",
"zone": "EU-FR-IKDC1-Z1-ADV"
}
</pre>

In diesem Beispiel stellen wir eine Debian 9-Instanz in der erweiterten Zone (EU-FR-IKDC1-Z1-ADV) bereit und verwenden das Rechenangebot "t1.micro" in unserem Netzwerk mit dem Namen "My-Network-Z1" und unserem SSH-Schlüsselpaar mit dem Namen "MY_SSHKEY".

Um alle verwendbaren Parameter und andere Beispiele zu sehen, können Sie die ansible-doc des Moduls "cs_instance" verwenden:

<pre>
$ ansible-doc cs_instance
> CS_INSTANCE (/usr/lib/python2.7/site-packages/ansible/modules/cloud/cloudstack/cs_instance.py)

Deploy, start, update, scale, restart, restore, stop and destroy instances.

Options (= is mandatory):

- account
Account the instance is related to.
[Default: None]
- affinity_groups
Affinity groups names to be applied to the new instance.
[Default: []]
- api_http_method
HTTP method used.
(Choices: get, post)[Default: get]
- api_key
API key of the CloudStack API.
[Default: None]
- api_region
Name of the ini section in the `cloustack.ini' file.
[Default: cloudstack]
- api_secret
Secret key of the CloudStack API.
[Default: None]
- api_timeout
HTTP timeout.
[Default: 10]
- api_url
URL of the CloudStack API e.g. https://cloud.example.com/client/api.
[Default: None]
- cpu
The number of CPUs to allocate to the instance, used with custom service offerings
[Default: None]
- cpu_speed
The clock speed/shares allocated to the instance, used with custom service offerings
[Default: None]
- disk_offering
Name of the disk offering to be used.
[Default: None]
- disk_size
Disk size in GByte required if deploying instance from ISO.
[Default: None]
...
</pre>

Hinweis: Die Ausgabe des Befehls ist aufgrund seiner Länge absichtlich gekürzt.

== Bereitstellung einer Instanz mit einem Ansible-Playbook ==

Auf die gleiche Weise wie oben müssen Sie zunächst die Konfigurationsdatei ".cloudstack.ini" des Moduls "cs_instance" von Ansible erstellen und ausfüllen/anpassen:

<pre>
[CloudIkoulaOne]
endpoint = https://cloudstack.ikoula.com/client/api
key = <clé API de votre utilisateur/compte Cloud IKOULA One>
secret = <clé privée de votre utilisateur/compte Cloud IKOULA One>
timeout = 30
</pre>

Dann müssen Sie nur eine Playbook-Datei (yml-Erweiterung / YAML-Format) erstellen, wie unten beschrieben, und die Werte der Parameter (Name Ihrer Instanz, Name des Netzwerks usw.) und die Parameter selbst (ob Sie z. B. ein SSH-Schlüsselpaar verwenden müssen/wollen oder nicht) anpassen:

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer erweiterten Zone:

<pre>
$ cat deploy_instance_adv.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
networks: "<Nom du réseau existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"
...
</pre>

Beispiel für ein Playbook für die Bereitstellung einer Instanz in einer Basiszone (hier wird einfach der Netzwerkparameter durch den Sicherheitsgruppenparameter ersetzt und die Rückgabe der öffentlichen IP-Adresse, die der VM zugewiesen wurde, nach der Bereitstellung hinzugefügt):

<pre>
$ cat deploy_instance_basic.yml
---

- hosts: all
connection: local
user: root

tasks:

- name: 'Create Debian instance in Cloud IKOULA One with Ansible Playbook'
cs_instance:
name: "<Nom de la VM>"
state: present
display_name: "<Nom de la VM>"
template: "<Nom entre simples quotes ou ID du template CIO voulu>"
api_region: "CloudIkoulaOne"
zone: "<Nom de la zone voulu>"
service_offering: "<Nom de l’offre de calcul voulu >"
security_groups: "<Nom du groupe de sécurité existant voulu>"
ssh_key: "<Nom de la paire de clés ssh CIO existante>"

- name: "VM ip address:"
debug:
var: vminfo.default_ip
...
</pre>

Nachdem die Parameter und ihre Werte angepasst wurden, folgt ein Beispiel für die Ausführung des Playbooks (passen Sie den Namen Ihrer Playbook-Datei gegebenenfalls an):

<pre>
$ ansible-playbook -i "localhost," -c local deploy_instance_adv.yml

PLAY [all] ********************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [Create Debian instance in Cloud IKOULA One with Ansible Playbook] ********************************************************************************************************************************************************************************************************************************
changed: [localhost]

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0
</pre>

[[Catégorie :Cloud public]]
[[Catégorie:API]]
[[Catégorie :Cloud]]</Nom>

Bereitstellen eines Kubernetes-Clusters mit microk8s

2021-07-29T14:23:59Z

Ikbot:

[[:ro:Implementarea unui cluster Kubernetes cu microk8s]][[ro:Implementarea unui cluster Kubernetes cu microk8s]]
[[:ru:Развертывание кластера Kubernetes с помощью microk8s]][[ru:Развертывание кластера Kubernetes с помощью microk8s]]
[[:pl:Wdrażanie klastra Kubernetes za pomocą microk8s]][[pl:Wdrażanie klastra Kubernetes za pomocą microk8s]]
[[:ja:microk8sを使ったKubernetesクラスタのデプロイメント]][[ja:microk8sを使ったKubernetesクラスタのデプロイメント]]
[[:zh:用microk8s部署一个Kubernetes集群]][[zh:用microk8s部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes avec microk8s]][[fr:Deployer un cluster Kubernetes avec microk8s]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren met microk8s]][[nl:Een Kubernetes cluster implementeren met microk8s]]
[[:it:Distribuire un cluster Kubernetes con microk8s]][[it:Distribuire un cluster Kubernetes con microk8s]]
[[:pt:Implementação de um aglomerado Kubernetes com microk8s]][[pt:Implementação de um aglomerado Kubernetes com microk8s]]
[[:es:Despliegue de un clúster Kubernetes con microk8s]][[es:Despliegue de un clúster Kubernetes con microk8s]]
[[:en:Deploying a Kubernetes cluster with microk8s]][[en:Deploying a Kubernetes cluster with microk8s]]


{{#seo:
|title=Bereitstellen eines Kubernetes-Clusters mit microk8s
|title_mode=append
|keywords=das,sind,Ihre,Schlüsselwörter
|description=In diesem Artikel erfahren Sie, wie Sie einen Kubernetes-Cluster mit microk8s bereitstellen
|image=Uploaded_file.png
|image_alt=Wiki Logo
}}

==Einführung== 
In dieser Dokumentation erfahren Sie, wie Sie einen Kubernetes-Cluster mit der microk8s-Lösung einrichten und verwalten. 
Letzteres hat den Vorteil, dass es sich um eine All-in-One-Lösung handelt, die die Installation und Verwaltung der Lösung erheblich erleichtert. 

Wenn Sie kubernetes "direkt" ohne diese Lösung installieren möchten, können Sie unsere FAQ einsehen [[Deployer_un_cluster_Kubernetes|suivante]].

Für die Einrichtung eines solchen Clusters sind mindestens drei Knoten erforderlich, in unserem auf dieser Seite beschriebenen Beispiel sind es vier, die wir hier benennen werden:
* microk8test01
* microk8test02
* microk8test03

==Art der Ausrüstung für diese Art der Konfiguration== 
Diese Art der Konfiguration ist bei allen Lösungen von Ikoula möglich, unabhängig davon, ob es sich um:
* Die [https://www.ikoula.com/fr/serveur-dedie spezielle Lösungen],
* Die [https://www.ikoula.com/fr/serveur-virtuel Virtuelle Flex-Lösungen],
Wenn Sie Microservices oder einen Cluster mit einer großen Anzahl von Knoten betreiben möchten, ist die [https://www.ikoula.com/fr/raspberry-pi-4-micro-serveur Lösung Micro Server Raspberry PI] ist ebenfalls möglich.

==Verfahren== 
Das gesamte Verfahren wird auf einem Ubuntu 20.04-System durchgeführt.

===Installation== = 
Die Installation von microk8s ist sehr einfach und wird wie folgt durchgeführt (fügen Sie sudo su hinzu, der Befehl wird nicht als root ausgeführt):
<pre>
snap install microk8s --classic
</pre>

Die Installation und Konfiguration wird dann automatisch durchgeführt (ca. 2-3 Minuten) und gibt dann die folgende Ausgabe: 
[[File:Microk8s01.JPG]]

===Einrichtung des Clusters== = 
Auch die Einrichtung des Clusters ist denkbar einfach:
Führen Sie den folgenden Befehl auf einem der Knoten (hier 01) aus:
<pre>
microk8s add-node
</pre>

[[File:Microk8s02.JPG]]

Kopieren Sie dann den angegebenen Befehl (wenn Sie mehrere IPs/Netzwerke haben, wählen Sie dasjenige aus, über das Ihre Server miteinander kommunizieren können). 
Führen Sie dann diesen Befehl auf Ihrem zweiten Server aus: 
[[File:Microk8s03.JPG]]

Sobald der Vorgang für den zweiten Server abgeschlossen ist, müssen Sie den gleichen Vorgang für den dritten Server durchführen (von Anfang an, um einen neuen Befehl über den add-node zu erzeugen).

===Überprüfung des Zustands des Clusters== = 
Es ist möglich, den Status des microk8s-Clusters über den Befehl zu überprüfen:
<pre>
microk8s status --wait-ready
</pre>

Wenn alles in Ordnung ist, sollten Sie das folgende Ergebnis erhalten: 
[[File:Microk8s04.JPG]]

===Entfernen eines Knotens aus dem Cluster == = 
Das Entfernen eines Knotens aus dem Cluster erfolgt über den Befehl:
<pre>
microk8s leave
</pre>

[[File:Microk8s05.JPG]]

===Aktivierung der in microk8s integrierten Addons == = 
Die microk8s-Basisversion enthält die folgenden Zusatzmodule:

[[File:Microk8s06.JPG]]

Sie können ein Addon einfach über den Befehl installieren/aktivieren:
<pre>
microk8s enable NOM_DE_LADDON
</pre>



 
Cet article vous a semblé utile ? <vote />




<comments />



[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters mit microk8s

2021-07-29T14:22:27Z

Ikbot:

[[:ru:Развертывание кластера Kubernetes с помощью microk8s]][[ru:Развертывание кластера Kubernetes с помощью microk8s]]
[[:pl:Wdrażanie klastra Kubernetes za pomocą microk8s]][[pl:Wdrażanie klastra Kubernetes za pomocą microk8s]]
[[:ja:microk8sを使ったKubernetesクラスタのデプロイメント]][[ja:microk8sを使ったKubernetesクラスタのデプロイメント]]
[[:zh:用microk8s部署一个Kubernetes集群]][[zh:用microk8s部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes avec microk8s]][[fr:Deployer un cluster Kubernetes avec microk8s]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren met microk8s]][[nl:Een Kubernetes cluster implementeren met microk8s]]
[[:it:Distribuire un cluster Kubernetes con microk8s]][[it:Distribuire un cluster Kubernetes con microk8s]]
[[:pt:Implementação de um aglomerado Kubernetes com microk8s]][[pt:Implementação de um aglomerado Kubernetes com microk8s]]
[[:es:Despliegue de un clúster Kubernetes con microk8s]][[es:Despliegue de un clúster Kubernetes con microk8s]]
[[:en:Deploying a Kubernetes cluster with microk8s]][[en:Deploying a Kubernetes cluster with microk8s]]


{{#seo:
|title=Bereitstellen eines Kubernetes-Clusters mit microk8s
|title_mode=append
|keywords=das,sind,Ihre,Schlüsselwörter
|description=In diesem Artikel erfahren Sie, wie Sie einen Kubernetes-Cluster mit microk8s bereitstellen
|image=Uploaded_file.png
|image_alt=Wiki Logo
}}

==Einführung== 
In dieser Dokumentation erfahren Sie, wie Sie einen Kubernetes-Cluster mit der microk8s-Lösung einrichten und verwalten. 
Letzteres hat den Vorteil, dass es sich um eine All-in-One-Lösung handelt, die die Installation und Verwaltung der Lösung erheblich erleichtert. 

Wenn Sie kubernetes "direkt" ohne diese Lösung installieren möchten, können Sie unsere FAQ einsehen [[Deployer_un_cluster_Kubernetes|suivante]].

Für die Einrichtung eines solchen Clusters sind mindestens drei Knoten erforderlich, in unserem auf dieser Seite beschriebenen Beispiel sind es vier, die wir hier benennen werden:
* microk8test01
* microk8test02
* microk8test03

==Art der Ausrüstung für diese Art der Konfiguration== 
Diese Art der Konfiguration ist bei allen Lösungen von Ikoula möglich, unabhängig davon, ob es sich um:
* Die [https://www.ikoula.com/fr/serveur-dedie spezielle Lösungen],
* Die [https://www.ikoula.com/fr/serveur-virtuel Virtuelle Flex-Lösungen],
Wenn Sie Microservices oder einen Cluster mit einer großen Anzahl von Knoten betreiben möchten, ist die [https://www.ikoula.com/fr/raspberry-pi-4-micro-serveur Lösung Micro Server Raspberry PI] ist ebenfalls möglich.

==Verfahren== 
Das gesamte Verfahren wird auf einem Ubuntu 20.04-System durchgeführt.

===Installation== = 
Die Installation von microk8s ist sehr einfach und wird wie folgt durchgeführt (fügen Sie sudo su hinzu, der Befehl wird nicht als root ausgeführt):
<pre>
snap install microk8s --classic
</pre>

Die Installation und Konfiguration wird dann automatisch durchgeführt (ca. 2-3 Minuten) und gibt dann die folgende Ausgabe: 
[[File:Microk8s01.JPG]]

===Einrichtung des Clusters== = 
Auch die Einrichtung des Clusters ist denkbar einfach:
Führen Sie den folgenden Befehl auf einem der Knoten (hier 01) aus:
<pre>
microk8s add-node
</pre>

[[File:Microk8s02.JPG]]

Kopieren Sie dann den angegebenen Befehl (wenn Sie mehrere IPs/Netzwerke haben, wählen Sie dasjenige aus, über das Ihre Server miteinander kommunizieren können). 
Führen Sie dann diesen Befehl auf Ihrem zweiten Server aus: 
[[File:Microk8s03.JPG]]

Sobald der Vorgang für den zweiten Server abgeschlossen ist, müssen Sie den gleichen Vorgang für den dritten Server durchführen (von Anfang an, um einen neuen Befehl über den add-node zu erzeugen).

===Überprüfung des Zustands des Clusters== = 
Es ist möglich, den Status des microk8s-Clusters über den Befehl zu überprüfen:
<pre>
microk8s status --wait-ready
</pre>

Wenn alles in Ordnung ist, sollten Sie das folgende Ergebnis erhalten: 
[[File:Microk8s04.JPG]]

===Entfernen eines Knotens aus dem Cluster == = 
Das Entfernen eines Knotens aus dem Cluster erfolgt über den Befehl:
<pre>
microk8s leave
</pre>

[[File:Microk8s05.JPG]]

===Aktivierung der in microk8s integrierten Addons == = 
Die microk8s-Basisversion enthält die folgenden Zusatzmodule:

[[File:Microk8s06.JPG]]

Sie können ein Addon einfach über den Befehl installieren/aktivieren:
<pre>
microk8s enable NOM_DE_LADDON
</pre>



 
Cet article vous a semblé utile ? <vote />




<comments />



[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters mit microk8s

2021-07-29T14:20:49Z

Ikbot:

[[:pl:Wdrażanie klastra Kubernetes za pomocą microk8s]][[pl:Wdrażanie klastra Kubernetes za pomocą microk8s]]
[[:ja:microk8sを使ったKubernetesクラスタのデプロイメント]][[ja:microk8sを使ったKubernetesクラスタのデプロイメント]]
[[:zh:用microk8s部署一个Kubernetes集群]][[zh:用microk8s部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes avec microk8s]][[fr:Deployer un cluster Kubernetes avec microk8s]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren met microk8s]][[nl:Een Kubernetes cluster implementeren met microk8s]]
[[:it:Distribuire un cluster Kubernetes con microk8s]][[it:Distribuire un cluster Kubernetes con microk8s]]
[[:pt:Implementação de um aglomerado Kubernetes com microk8s]][[pt:Implementação de um aglomerado Kubernetes com microk8s]]
[[:es:Despliegue de un clúster Kubernetes con microk8s]][[es:Despliegue de un clúster Kubernetes con microk8s]]
[[:en:Deploying a Kubernetes cluster with microk8s]][[en:Deploying a Kubernetes cluster with microk8s]]


{{#seo:
|title=Bereitstellen eines Kubernetes-Clusters mit microk8s
|title_mode=append
|keywords=das,sind,Ihre,Schlüsselwörter
|description=In diesem Artikel erfahren Sie, wie Sie einen Kubernetes-Cluster mit microk8s bereitstellen
|image=Uploaded_file.png
|image_alt=Wiki Logo
}}

==Einführung== 
In dieser Dokumentation erfahren Sie, wie Sie einen Kubernetes-Cluster mit der microk8s-Lösung einrichten und verwalten. 
Letzteres hat den Vorteil, dass es sich um eine All-in-One-Lösung handelt, die die Installation und Verwaltung der Lösung erheblich erleichtert. 

Wenn Sie kubernetes "direkt" ohne diese Lösung installieren möchten, können Sie unsere FAQ einsehen [[Deployer_un_cluster_Kubernetes|suivante]].

Für die Einrichtung eines solchen Clusters sind mindestens drei Knoten erforderlich, in unserem auf dieser Seite beschriebenen Beispiel sind es vier, die wir hier benennen werden:
* microk8test01
* microk8test02
* microk8test03

==Art der Ausrüstung für diese Art der Konfiguration== 
Diese Art der Konfiguration ist bei allen Lösungen von Ikoula möglich, unabhängig davon, ob es sich um:
* Die [https://www.ikoula.com/fr/serveur-dedie spezielle Lösungen],
* Die [https://www.ikoula.com/fr/serveur-virtuel Virtuelle Flex-Lösungen],
Wenn Sie Microservices oder einen Cluster mit einer großen Anzahl von Knoten betreiben möchten, ist die [https://www.ikoula.com/fr/raspberry-pi-4-micro-serveur Lösung Micro Server Raspberry PI] ist ebenfalls möglich.

==Verfahren== 
Das gesamte Verfahren wird auf einem Ubuntu 20.04-System durchgeführt.

===Installation== = 
Die Installation von microk8s ist sehr einfach und wird wie folgt durchgeführt (fügen Sie sudo su hinzu, der Befehl wird nicht als root ausgeführt):
<pre>
snap install microk8s --classic
</pre>

Die Installation und Konfiguration wird dann automatisch durchgeführt (ca. 2-3 Minuten) und gibt dann die folgende Ausgabe: 
[[File:Microk8s01.JPG]]

===Einrichtung des Clusters== = 
Auch die Einrichtung des Clusters ist denkbar einfach:
Führen Sie den folgenden Befehl auf einem der Knoten (hier 01) aus:
<pre>
microk8s add-node
</pre>

[[File:Microk8s02.JPG]]

Kopieren Sie dann den angegebenen Befehl (wenn Sie mehrere IPs/Netzwerke haben, wählen Sie dasjenige aus, über das Ihre Server miteinander kommunizieren können). 
Führen Sie dann diesen Befehl auf Ihrem zweiten Server aus: 
[[File:Microk8s03.JPG]]

Sobald der Vorgang für den zweiten Server abgeschlossen ist, müssen Sie den gleichen Vorgang für den dritten Server durchführen (von Anfang an, um einen neuen Befehl über den add-node zu erzeugen).

===Überprüfung des Zustands des Clusters== = 
Es ist möglich, den Status des microk8s-Clusters über den Befehl zu überprüfen:
<pre>
microk8s status --wait-ready
</pre>

Wenn alles in Ordnung ist, sollten Sie das folgende Ergebnis erhalten: 
[[File:Microk8s04.JPG]]

===Entfernen eines Knotens aus dem Cluster == = 
Das Entfernen eines Knotens aus dem Cluster erfolgt über den Befehl:
<pre>
microk8s leave
</pre>

[[File:Microk8s05.JPG]]

===Aktivierung der in microk8s integrierten Addons == = 
Die microk8s-Basisversion enthält die folgenden Zusatzmodule:

[[File:Microk8s06.JPG]]

Sie können ein Addon einfach über den Befehl installieren/aktivieren:
<pre>
microk8s enable NOM_DE_LADDON
</pre>



 
Cet article vous a semblé utile ? <vote />




<comments />



[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters mit microk8s

2021-07-29T14:19:07Z

Ikbot:

[[:ja:microk8sを使ったKubernetesクラスタのデプロイメント]][[ja:microk8sを使ったKubernetesクラスタのデプロイメント]]
[[:zh:用microk8s部署一个Kubernetes集群]][[zh:用microk8s部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes avec microk8s]][[fr:Deployer un cluster Kubernetes avec microk8s]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren met microk8s]][[nl:Een Kubernetes cluster implementeren met microk8s]]
[[:it:Distribuire un cluster Kubernetes con microk8s]][[it:Distribuire un cluster Kubernetes con microk8s]]
[[:pt:Implementação de um aglomerado Kubernetes com microk8s]][[pt:Implementação de um aglomerado Kubernetes com microk8s]]
[[:es:Despliegue de un clúster Kubernetes con microk8s]][[es:Despliegue de un clúster Kubernetes con microk8s]]
[[:en:Deploying a Kubernetes cluster with microk8s]][[en:Deploying a Kubernetes cluster with microk8s]]


{{#seo:
|title=Bereitstellen eines Kubernetes-Clusters mit microk8s
|title_mode=append
|keywords=das,sind,Ihre,Schlüsselwörter
|description=In diesem Artikel erfahren Sie, wie Sie einen Kubernetes-Cluster mit microk8s bereitstellen
|image=Uploaded_file.png
|image_alt=Wiki Logo
}}

==Einführung== 
In dieser Dokumentation erfahren Sie, wie Sie einen Kubernetes-Cluster mit der microk8s-Lösung einrichten und verwalten. 
Letzteres hat den Vorteil, dass es sich um eine All-in-One-Lösung handelt, die die Installation und Verwaltung der Lösung erheblich erleichtert. 

Wenn Sie kubernetes "direkt" ohne diese Lösung installieren möchten, können Sie unsere FAQ einsehen [[Deployer_un_cluster_Kubernetes|suivante]].

Für die Einrichtung eines solchen Clusters sind mindestens drei Knoten erforderlich, in unserem auf dieser Seite beschriebenen Beispiel sind es vier, die wir hier benennen werden:
* microk8test01
* microk8test02
* microk8test03

==Art der Ausrüstung für diese Art der Konfiguration== 
Diese Art der Konfiguration ist bei allen Lösungen von Ikoula möglich, unabhängig davon, ob es sich um:
* Die [https://www.ikoula.com/fr/serveur-dedie spezielle Lösungen],
* Die [https://www.ikoula.com/fr/serveur-virtuel Virtuelle Flex-Lösungen],
Wenn Sie Microservices oder einen Cluster mit einer großen Anzahl von Knoten betreiben möchten, ist die [https://www.ikoula.com/fr/raspberry-pi-4-micro-serveur Lösung Micro Server Raspberry PI] ist ebenfalls möglich.

==Verfahren== 
Das gesamte Verfahren wird auf einem Ubuntu 20.04-System durchgeführt.

===Installation== = 
Die Installation von microk8s ist sehr einfach und wird wie folgt durchgeführt (fügen Sie sudo su hinzu, der Befehl wird nicht als root ausgeführt):
<pre>
snap install microk8s --classic
</pre>

Die Installation und Konfiguration wird dann automatisch durchgeführt (ca. 2-3 Minuten) und gibt dann die folgende Ausgabe: 
[[File:Microk8s01.JPG]]

===Einrichtung des Clusters== = 
Auch die Einrichtung des Clusters ist denkbar einfach:
Führen Sie den folgenden Befehl auf einem der Knoten (hier 01) aus:
<pre>
microk8s add-node
</pre>

[[File:Microk8s02.JPG]]

Kopieren Sie dann den angegebenen Befehl (wenn Sie mehrere IPs/Netzwerke haben, wählen Sie dasjenige aus, über das Ihre Server miteinander kommunizieren können). 
Führen Sie dann diesen Befehl auf Ihrem zweiten Server aus: 
[[File:Microk8s03.JPG]]

Sobald der Vorgang für den zweiten Server abgeschlossen ist, müssen Sie den gleichen Vorgang für den dritten Server durchführen (von Anfang an, um einen neuen Befehl über den add-node zu erzeugen).

===Überprüfung des Zustands des Clusters== = 
Es ist möglich, den Status des microk8s-Clusters über den Befehl zu überprüfen:
<pre>
microk8s status --wait-ready
</pre>

Wenn alles in Ordnung ist, sollten Sie das folgende Ergebnis erhalten: 
[[File:Microk8s04.JPG]]

===Entfernen eines Knotens aus dem Cluster == = 
Das Entfernen eines Knotens aus dem Cluster erfolgt über den Befehl:
<pre>
microk8s leave
</pre>

[[File:Microk8s05.JPG]]

===Aktivierung der in microk8s integrierten Addons == = 
Die microk8s-Basisversion enthält die folgenden Zusatzmodule:

[[File:Microk8s06.JPG]]

Sie können ein Addon einfach über den Befehl installieren/aktivieren:
<pre>
microk8s enable NOM_DE_LADDON
</pre>



 
Cet article vous a semblé utile ? <vote />




<comments />



[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters mit microk8s

2021-07-29T14:17:36Z

Ikbot:

[[:zh:用microk8s部署一个Kubernetes集群]][[zh:用microk8s部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes avec microk8s]][[fr:Deployer un cluster Kubernetes avec microk8s]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren met microk8s]][[nl:Een Kubernetes cluster implementeren met microk8s]]
[[:it:Distribuire un cluster Kubernetes con microk8s]][[it:Distribuire un cluster Kubernetes con microk8s]]
[[:pt:Implementação de um aglomerado Kubernetes com microk8s]][[pt:Implementação de um aglomerado Kubernetes com microk8s]]
[[:es:Despliegue de un clúster Kubernetes con microk8s]][[es:Despliegue de un clúster Kubernetes con microk8s]]
[[:en:Deploying a Kubernetes cluster with microk8s]][[en:Deploying a Kubernetes cluster with microk8s]]


{{#seo:
|title=Bereitstellen eines Kubernetes-Clusters mit microk8s
|title_mode=append
|keywords=das,sind,Ihre,Schlüsselwörter
|description=In diesem Artikel erfahren Sie, wie Sie einen Kubernetes-Cluster mit microk8s bereitstellen
|image=Uploaded_file.png
|image_alt=Wiki Logo
}}

==Einführung== 
In dieser Dokumentation erfahren Sie, wie Sie einen Kubernetes-Cluster mit der microk8s-Lösung einrichten und verwalten. 
Letzteres hat den Vorteil, dass es sich um eine All-in-One-Lösung handelt, die die Installation und Verwaltung der Lösung erheblich erleichtert. 

Wenn Sie kubernetes "direkt" ohne diese Lösung installieren möchten, können Sie unsere FAQ einsehen [[Deployer_un_cluster_Kubernetes|suivante]].

Für die Einrichtung eines solchen Clusters sind mindestens drei Knoten erforderlich, in unserem auf dieser Seite beschriebenen Beispiel sind es vier, die wir hier benennen werden:
* microk8test01
* microk8test02
* microk8test03

==Art der Ausrüstung für diese Art der Konfiguration== 
Diese Art der Konfiguration ist bei allen Lösungen von Ikoula möglich, unabhängig davon, ob es sich um:
* Die [https://www.ikoula.com/fr/serveur-dedie spezielle Lösungen],
* Die [https://www.ikoula.com/fr/serveur-virtuel Virtuelle Flex-Lösungen],
Wenn Sie Microservices oder einen Cluster mit einer großen Anzahl von Knoten betreiben möchten, ist die [https://www.ikoula.com/fr/raspberry-pi-4-micro-serveur Lösung Micro Server Raspberry PI] ist ebenfalls möglich.

==Verfahren== 
Das gesamte Verfahren wird auf einem Ubuntu 20.04-System durchgeführt.

===Installation== = 
Die Installation von microk8s ist sehr einfach und wird wie folgt durchgeführt (fügen Sie sudo su hinzu, der Befehl wird nicht als root ausgeführt):
<pre>
snap install microk8s --classic
</pre>

Die Installation und Konfiguration wird dann automatisch durchgeführt (ca. 2-3 Minuten) und gibt dann die folgende Ausgabe: 
[[File:Microk8s01.JPG]]

===Einrichtung des Clusters== = 
Auch die Einrichtung des Clusters ist denkbar einfach:
Führen Sie den folgenden Befehl auf einem der Knoten (hier 01) aus:
<pre>
microk8s add-node
</pre>

[[File:Microk8s02.JPG]]

Kopieren Sie dann den angegebenen Befehl (wenn Sie mehrere IPs/Netzwerke haben, wählen Sie dasjenige aus, über das Ihre Server miteinander kommunizieren können). 
Führen Sie dann diesen Befehl auf Ihrem zweiten Server aus: 
[[File:Microk8s03.JPG]]

Sobald der Vorgang für den zweiten Server abgeschlossen ist, müssen Sie den gleichen Vorgang für den dritten Server durchführen (von Anfang an, um einen neuen Befehl über den add-node zu erzeugen).

===Überprüfung des Zustands des Clusters== = 
Es ist möglich, den Status des microk8s-Clusters über den Befehl zu überprüfen:
<pre>
microk8s status --wait-ready
</pre>

Wenn alles in Ordnung ist, sollten Sie das folgende Ergebnis erhalten: 
[[File:Microk8s04.JPG]]

===Entfernen eines Knotens aus dem Cluster == = 
Das Entfernen eines Knotens aus dem Cluster erfolgt über den Befehl:
<pre>
microk8s leave
</pre>

[[File:Microk8s05.JPG]]

===Aktivierung der in microk8s integrierten Addons == = 
Die microk8s-Basisversion enthält die folgenden Zusatzmodule:

[[File:Microk8s06.JPG]]

Sie können ein Addon einfach über den Befehl installieren/aktivieren:
<pre>
microk8s enable NOM_DE_LADDON
</pre>



 
Cet article vous a semblé utile ? <vote />




<comments />



[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters mit microk8s

2021-07-29T14:16:03Z

Ikbot: Die Seite wurde neu angelegt: „</…“

[[:fr:Deployer un cluster Kubernetes avec microk8s]][[fr:Deployer un cluster Kubernetes avec microk8s]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren met microk8s]][[nl:Een Kubernetes cluster implementeren met microk8s]]
[[:it:Distribuire un cluster Kubernetes con microk8s]][[it:Distribuire un cluster Kubernetes con microk8s]]
[[:pt:Implementação de um aglomerado Kubernetes com microk8s]][[pt:Implementação de um aglomerado Kubernetes com microk8s]]
[[:es:Despliegue de un clúster Kubernetes con microk8s]][[es:Despliegue de un clúster Kubernetes con microk8s]]
[[:en:Deploying a Kubernetes cluster with microk8s]][[en:Deploying a Kubernetes cluster with microk8s]]


{{#seo:
|title=Bereitstellen eines Kubernetes-Clusters mit microk8s
|title_mode=append
|keywords=das,sind,Ihre,Schlüsselwörter
|description=In diesem Artikel erfahren Sie, wie Sie einen Kubernetes-Cluster mit microk8s bereitstellen
|image=Uploaded_file.png
|image_alt=Wiki Logo
}}

==Einführung== 
In dieser Dokumentation erfahren Sie, wie Sie einen Kubernetes-Cluster mit der microk8s-Lösung einrichten und verwalten. 
Letzteres hat den Vorteil, dass es sich um eine All-in-One-Lösung handelt, die die Installation und Verwaltung der Lösung erheblich erleichtert. 

Wenn Sie kubernetes "direkt" ohne diese Lösung installieren möchten, können Sie unsere FAQ einsehen [[Deployer_un_cluster_Kubernetes|suivante]].

Für die Einrichtung eines solchen Clusters sind mindestens drei Knoten erforderlich, in unserem auf dieser Seite beschriebenen Beispiel sind es vier, die wir hier benennen werden:
* microk8test01
* microk8test02
* microk8test03

==Art der Ausrüstung für diese Art der Konfiguration== 
Diese Art der Konfiguration ist bei allen Lösungen von Ikoula möglich, unabhängig davon, ob es sich um:
* Die [https://www.ikoula.com/fr/serveur-dedie spezielle Lösungen],
* Die [https://www.ikoula.com/fr/serveur-virtuel Virtuelle Flex-Lösungen],
Wenn Sie Microservices oder einen Cluster mit einer großen Anzahl von Knoten betreiben möchten, ist die [https://www.ikoula.com/fr/raspberry-pi-4-micro-serveur Lösung Micro Server Raspberry PI] ist ebenfalls möglich.

==Verfahren== 
Das gesamte Verfahren wird auf einem Ubuntu 20.04-System durchgeführt.

===Installation== = 
Die Installation von microk8s ist sehr einfach und wird wie folgt durchgeführt (fügen Sie sudo su hinzu, der Befehl wird nicht als root ausgeführt):
<pre>
snap install microk8s --classic
</pre>

Die Installation und Konfiguration wird dann automatisch durchgeführt (ca. 2-3 Minuten) und gibt dann die folgende Ausgabe: 
[[File:Microk8s01.JPG]]

===Einrichtung des Clusters== = 
Auch die Einrichtung des Clusters ist denkbar einfach:
Führen Sie den folgenden Befehl auf einem der Knoten (hier 01) aus:
<pre>
microk8s add-node
</pre>

[[File:Microk8s02.JPG]]

Kopieren Sie dann den angegebenen Befehl (wenn Sie mehrere IPs/Netzwerke haben, wählen Sie dasjenige aus, über das Ihre Server miteinander kommunizieren können). 
Führen Sie dann diesen Befehl auf Ihrem zweiten Server aus: 
[[File:Microk8s03.JPG]]

Sobald der Vorgang für den zweiten Server abgeschlossen ist, müssen Sie den gleichen Vorgang für den dritten Server durchführen (von Anfang an, um einen neuen Befehl über den add-node zu erzeugen).

===Überprüfung des Zustands des Clusters== = 
Es ist möglich, den Status des microk8s-Clusters über den Befehl zu überprüfen:
<pre>
microk8s status --wait-ready
</pre>

Wenn alles in Ordnung ist, sollten Sie das folgende Ergebnis erhalten: 
[[File:Microk8s04.JPG]]

===Entfernen eines Knotens aus dem Cluster == = 
Das Entfernen eines Knotens aus dem Cluster erfolgt über den Befehl:
<pre>
microk8s leave
</pre>

[[File:Microk8s05.JPG]]

===Aktivierung der in microk8s integrierten Addons == = 
Die microk8s-Basisversion enthält die folgenden Zusatzmodule:

[[File:Microk8s06.JPG]]

Sie können ein Addon einfach über den Befehl installieren/aktivieren:
<pre>
microk8s enable NOM_DE_LADDON
</pre>



 
Cet article vous a semblé utile ? <vote />




<comments />



[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters

2021-07-29T14:02:11Z

Ikbot:

[[:ro:Implementarea unui cluster Kubernetes]][[ro:Implementarea unui cluster Kubernetes]]
[[:ru:Развертывание кластера Kubernetes]][[ru:Развертывание кластера Kubernetes]]
[[:pl:Wdrażanie klastra Kubernetes]][[pl:Wdrażanie klastra Kubernetes]]
[[:ja:Kubernetesクラスタのデプロイ]][[ja:Kubernetesクラスタのデプロイ]]
[[:zh:部署一个Kubernetes集群]][[zh:部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren]][[nl:Een Kubernetes cluster implementeren]]
[[:pt:Implantação de um aglomerado Kubernetes]][[pt:Implantação de um aglomerado Kubernetes]]
[[:es:Despliegue de un clúster Kubernetes]][[es:Despliegue de un clúster Kubernetes]]
[[:en:Deploying a Kubernetes cluster]][[en:Deploying a Kubernetes cluster]]
[[:it:Configurare un cluster Kubernetes]][[it:Configurare un cluster Kubernetes]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]

{{#seo:
|title=kubernetes Installation
|titlemode=replace
|keywords=ikoula wiki, ikoula wiki, ikoula Wissensbasis, kubernetes ist was, kubernetes installation, kubernetes tutorial
|description=Kubernetes kann als eine Container-Plattform, eine Microservices-Plattform, eine portable Cloud-Plattform und vieles mehr betrachtet werden... Finden Sie heraus, wie man es installiert.
|og:type=article
|og:image=https://fr-wiki.ikoula.com/resources/assets/logo_ikwiki.png
}}

==Was ist Kubernetes?==

'''Kubernetes''' ist eine Open-Source-Plattform für die Verwaltung von containerisierten Arbeitslasten und Diensten.
Es unterstützt die deklarative Konfigurationserstellung, aber auch die Automatisierung. ''Kubernetes'' ist ein großes und schnell wachsendes Ökosystem.

Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster einrichten [https://www.ikoula.com/fr/cloud-public/oneclick Kubernetes (k8s)] Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster aus drei CentOS 7-Instanzen einrichten, die innerhalb desselben Netzwerks in einer Forward Zone installiert sind.

Eine dieser drei Instanzen wird unser Masterknoten sein, die anderen beiden werden unsere Arbeitsknoten sein. Zusammenfassend lässt sich sagen, dass der Master-Knoten der Knoten ist, von dem aus wir den Kubernetes-Cluster (Container-Orchestrator) über seine API verwalten, und die Worker-Knoten die Knoten sind, auf denen die Pods oder Container (in unserem Fall Docker) ausgeführt werden.

Wir gehen davon aus, dass Ihre 3 CentOS 7-Instanzen bereits eingerichtet sind und dass Sie per ssh Zugriff auf sie haben, um die folgenden Befehle auszuführen.

Hier ist die Konfiguration, die wir in unserem Beispiel haben und die in diesem Verfahren als Beispiel verwendet wird:

Knotenmaster: "k8s-master" / 10.1.1.16 
Erster Arbeitsknoten: "k8s-worker01" / 10.1.1.169 
Zweiter Arbeitsknoten: "k8s-worker02" / 10.1.1.87 

== Tutorial zur Systemvorbereitung und Kubernetes-Installation ==

Die folgenden Aktionen müssen auf allen Instanzen (Master und Worker) als root (oder mit den erforderlichen sudo-Rechten) durchgeführt werden.

Beginnen Sie damit, die Datei /etc/hosts auf jeder Ihrer Instanzen aufzufüllen, so dass sie ihren jeweiligen Hostnamen auflösen können (normalerweise ist dies in einem erweiterten Zonennetzwerk, in dem der virtuelle Router ein DNS-Auflöser ist, bereits der Fall).

In unserem Beispiel ergibt dies die folgende /etc/hosts Datei auf unseren drei Instanzen (passen Sie sie mit dem Namen und der IP Ihrer Instanzen an):

<syntaxhighlight lang="bash">
cat /etc/hosts
127.0.0.1 localhost
::1 localhost

10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02
</syntaxhighlight>

Aktivieren Sie das Bridge-Modul und die iptables-Regeln für dieses Modul mit den folgenden drei Befehlen:

<syntaxhighlight lang="bash">
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
</syntaxhighlight>

Fügen Sie das YUM-Docker-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF
</syntaxhighlight>

Fügen Sie das YUM-Kubernetes-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
</syntaxhighlight>

Docker installieren :

<syntaxhighlight lang="bash">
yum install -y docker-ce
</syntaxhighlight>

Installieren Sie dann die erforderlichen Kubernetes-Pakete:

<syntaxhighlight lang="bash">
yum install -y kubeadm kubelet kubectl
</syntaxhighlight>

Bearbeiten Sie die Konfigurationsdatei des systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) Konfigurationsdatei die folgende Zeile in den Abschnitt "[Service]" ein:

<pre>
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
</pre>

derart, dass :

<pre>
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
*Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"*
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
</pre>

Laden Sie die Konfiguration neu, aktivieren Sie die Docker- und Kubelet-Dienste und starten Sie sie dann mit den folgenden drei Befehlen:

systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>

Deaktivieren Sie den System-Swap (kubelet unterstützt keinen Swap-Speicher, Sie erhalten eine Fehlermeldung während der Pre-Flight Checks bei der Initialisierung Ihres Clusters über kubeadms, wenn Sie ihn nicht deaktivieren):

<syntaxhighlight lang="bash">
swapoff -a
</syntaxhighlight>

Bitte denken Sie daran, auch die Swap-Zeile in der /etc/fstab Datei jeder Ihrer Instanzen zu kommentieren/entfernen, wie z.B. :

<pre>
#/dev/mapper/vg01-swap swap swap defaults 0 0
</pre>

== Initialisierung des Kubernetes-Clusters ==

Die folgenden Aktionen dürfen nur auf der Node-Master-Instanz durchgeführt werden

Starten Sie die Initialisierung Ihres Kubernetes-Clusters mit dem unten stehenden Befehl. Achten Sie darauf, den Wert des Parameters "--apiserver-advertise-address=" durch die IP-Adresse Ihrer Master-Instanz zu ändern.

<syntaxhighlight lang="bash">
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
</syntaxhighlight>

Hinweis: Bitte ändern Sie die im Parameter "--pod-network-cidr=" angegebene Netzwerk-IP "10.244.0.0/16" nicht, da dieser Parameter angibt, dass wir das CNI Flannel-Plugin zur Verwaltung des Netzwerkteils unserer Pods verwenden werden.

So sollte die Rückgabe dieses Befehls aussehen, wenn der Cluster erfolgreich initialisiert wurde:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
</syntaxhighlight>

Wir führen die geforderten Operationen durch, um die Initialisierung unseres Clusters abzuschließen:

Wir erstellen ein Verzeichnis und eine Konfigurationsdatei in dem Verzeichnis unseres Benutzers (in unserem Fall root):

<syntaxhighlight lang="bash">
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
</syntaxhighlight>

Wir stellen unser Pod-Flannel-Netzwerk für unseren Cluster bereit:

<syntaxhighlight lang="bash">
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
</syntaxhighlight>

Hinweis: Wir werden den letzten Befehl, der durch die Rückgabe des Seiteninitialisierungsbefehls ("kubeadm join...") bereitgestellt wird, behalten, um ihn später auf unseren Worker-Instanzen auszuführen, um sie in unseren Cluster einzubinden.

Wir können nun die ersten Prüfungen unseres Clusters von unserer Master-Instanz aus durchführen:

Geben Sie den Befehl "kubectl get nodes" ein, um die derzeit in Ihrem Cluster vorhandenen Knoten zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 41m v1.12.2
</syntaxhighlight>

Hinweis: Derzeit gibt es nur Ihren Masterknoten, was normal ist, da wir die anderen Knoten noch nicht zum Cluster hinzugefügt haben.

Geben Sie den Befehl "kubectl get pods --all-namespaces" ein, um die derzeit in Ihrem Cluster vorhandenen Pods/Container zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 41m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 41m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 84s
kube-system kube-proxy-h94bs 1/1 Running 0 41m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 40m
</syntaxhighlight>

Hinweis: Es gibt nur Pods, die den Kubernetes-Komponenten entsprechen, die für unseren Master-Knoten benötigt werden (kube-apiserver, etcd, kube-scheduler, etc.).

Wir können den Status dieser Komponenten mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
</syntaxhighlight>

== Hinzufügen von Arbeitsknoten zum Cluster ==

Aktionen, die nur auf Arbeitsinstanzen/Knoten ausgeführt werden

Führen Sie auf jeder Ihrer Worker-Instanzen (nicht auf Ihrer Master-Instanz) den Befehl "kubeadm join ..." aus, der am Ende der obigen Cluster-Initialisierung angegeben ist:

<syntaxhighlight lang="bash">
[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

<syntaxhighlight lang="bash">
[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

== Überprüfung des Status des Clusters ==

Von der Master-Instanz/dem Master-Knoten auszuführende Aktionen

Überprüfen Sie, ob Ihre Arbeitsknoten Ihrem Cluster hinzugefügt wurden, indem Sie den Befehl "kubectl get nodes" erneut ausführen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 46m v1.12.2
k8s-worker01.cs437cloud.internal Ready <none> 103s v1.12.2
k8s-worker02.cs437cloud.internal Ready <none> 48s v1.12.2
</syntaxhighlight>

Bemerkung: Wir können unsere beiden Arbeiterknoten (k8s-worker01 und k8s-worker02) sehen, sie wurden also zu unserem Cluster hinzugefügt.

Führen wir nun erneut den Befehl "kubectl get pods --all-namespaces" aus:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 46m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 46m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 2m6s
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 6m31s
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 70s
kube-system kube-proxy-8r7wg 1/1 Running 0 2m6s
kube-system kube-proxy-h94bs 1/1 Running 0 46m
kube-system kube-proxy-m2f5r 1/1 Running 0 70s
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 46m
</syntaxhighlight>

Hinweis: Wie Sie sehen, gibt es so viele "kube-flannel"- und "kube-proxy"-Pods/Container, wie wir Knoten in unserem Cluster haben.

== Einsatz eines ersten Pods ==

Wir werden unsere erste [https://kubernetes.io/docs/concepts/workloads/pods/pod/ pod] in unserem Kubernetes-Cluster.

Der Einfachheit halber entscheiden wir uns für die Bereitstellung eines Pods (ohne Replikate) mit dem Namen "nginx" und dem Image "nginx":

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
</syntaxhighlight>

Wenn wir nachsehen, erscheint dieser auch bei der Rückkehr des Befehls, der die Pods unseres Clusters auflistet:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-55bd7c9fd-5bghl 1/1 Running 0 104s
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 57m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 57m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 13m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 17m
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 12m
kube-system kube-proxy-8r7wg 1/1 Running 0 13m
kube-system kube-proxy-h94bs 1/1 Running 0 57m
kube-system kube-proxy-m2f5r 1/1 Running 0 12m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 57m
</syntaxhighlight>

Es erscheint am Anfang der Liste in einem anderen Namensraum als "kube-system", da es sich nicht um eine für den Betrieb von Kubernetes spezifische Komponente handelt.

Es ist auch möglich, die Anzeige von Pods, die für den kube-system-Namensraum spezifisch sind, zu vermeiden, indem man denselben Befehl ohne den Parameter "--all-namespace" ausführt:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 3d2h
</syntaxhighlight>

So zeigen Sie die Beschriftungen an:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-55bd7c9fd-ckltn 1/1 Running 0 8m2s app=nginx,pod-template-hash=55bd7c9fd
</syntaxhighlight>

Wir können unsere Bereitstellungen auch mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 93m
</syntaxhighlight>

Wir haben also einen Nginx-Pod eingerichtet und gestartet, aber er ist noch nicht von außen zugänglich. Um ihn von außen zugänglich zu machen, müssen wir den Port unseres Pods offenlegen, indem wir den Dienst (vom Typ NodePort) mit dem folgenden Befehl erstellen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
</syntaxhighlight>

So entsteht unser Service:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 147m
nginx NodePort 10.108.251.178 <none> 80:30566/TCP 20s
</syntaxhighlight>

Hinweis: Er lauscht auf Port 80/tcp und ist von außen über Port 30566/tcp erreichbar/offenbar.

Wir können die Flannel-IP unseres Pods und den Namen des Knotens, auf dem er gerade läuft, mit dem folgenden Befehl abrufen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 174m 10.244.2.2 k8s-worker02.cs437cloud.internal <none>
</syntaxhighlight>

Hier hat unser nginx-Pod die IP 10.244.2.2 und läuft auf unserem Knoten k8s-worker02.

Sie können auch einfach einen Befehl ausführen oder eine Shell auf unserem nginx-Pod über den folgenden Befehl öffnen (sehr ähnlich wie der Docker-Befehl):

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
</syntaxhighlight>

Alles, was Sie tun müssen, ist Ihre Lastausgleichsregel in Ihrem Ikoula One Cloud-Netzwerk zu erstellen, um auf Ihren Webserver (nginx pod) zuzugreifen bzw. ihn zu veröffentlichen:

- Verbinden Sie mit dem [https://cloudstack.ikoula.com/client Wolke Ikoula Eins]

- Gehen Sie auf "Netzwerk" im linken vertikalen Menü

- Klicken Sie auf Ihr Netzwerk, in dem Sie Ihre Kubernetes-Instanzen eingerichtet haben, dann auf "IP-Adressen anzeigen" und auf Ihre NAT-Quell-IP und gehen Sie auf die Registerkarte "Konfiguration".

- klicken Sie auf "Load Balancing" und erstellen Sie Ihre Regel, indem Sie einen Namen angeben, den öffentlichen Port "80" in unserem Fall, den privaten Port "30566" in unserem Fall (siehe oben), indem Sie einen LB-Algorithmus wählen (z.B. Round-Robin) wie :

[[File:faq_k8s_regle_lb-01.png|Kubernetes-Instanz]]

- alle Ihre Arbeitsinstanzen ankreuzen:

[[File:faq_k8s_regle_lb-02.png|Überprüfen Sie Ihre Kubernetes-Arbeitsinstanzen]]

Testen Sie den Zugriff auf Ihren Webserver/Nginx-Pod von Ihrem Browser aus (über die öffentliche IP Ihres Netzwerks, in dem Sie die LB-Regel erstellt haben):

[[File:faq_k8s_browser_nginx.png|Zugang zu Ihrem Webserver]]

Die Tatsache, dass Ihr nginx-Pod von jedem Ihrer Knoten aus zugänglich ist, wird durch die Komponente "kube-proxy" ermöglicht, die für die Weiterleitung von Verbindungen zu dem/den Knoten verantwortlich ist, auf dem/denen sie läuft (im Falle von Replikaten).

Sie haben also gerade einen einfachen Kubernetes-Cluster mit 3 Knoten, einem Master und zwei Workern eingerichtet.

== Weiter gehen ==

Sie können noch weiter gehen, indem Sie das Kubernetes-Dashboard einsetzen oder persistente Volumes für Ihre Pods erstellen, die Anzahl Ihrer Worker-Nodes erhöhen oder sogar die Master-Rolle redundant zuweisen, um eine hohe Verfügbarkeit zu gewährleisten, oder indem Sie Nodes für bestimmte Komponenten wie z. B. Etcd reservieren.

Hier sind einige nützliche Links:

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Docker]]
[[Category:CoreOS]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters

2021-07-29T14:00:22Z

Ikbot:

[[:ru:Развертывание кластера Kubernetes]][[ru:Развертывание кластера Kubernetes]]
[[:pl:Wdrażanie klastra Kubernetes]][[pl:Wdrażanie klastra Kubernetes]]
[[:ja:Kubernetesクラスタのデプロイ]][[ja:Kubernetesクラスタのデプロイ]]
[[:zh:部署一个Kubernetes集群]][[zh:部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren]][[nl:Een Kubernetes cluster implementeren]]
[[:pt:Implantação de um aglomerado Kubernetes]][[pt:Implantação de um aglomerado Kubernetes]]
[[:es:Despliegue de un clúster Kubernetes]][[es:Despliegue de un clúster Kubernetes]]
[[:en:Deploying a Kubernetes cluster]][[en:Deploying a Kubernetes cluster]]
[[:it:Configurare un cluster Kubernetes]][[it:Configurare un cluster Kubernetes]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]

{{#seo:
|title=kubernetes Installation
|titlemode=replace
|keywords=ikoula wiki, ikoula wiki, ikoula Wissensbasis, kubernetes ist was, kubernetes installation, kubernetes tutorial
|description=Kubernetes kann als eine Container-Plattform, eine Microservices-Plattform, eine portable Cloud-Plattform und vieles mehr betrachtet werden... Finden Sie heraus, wie man es installiert.
|og:type=article
|og:image=https://fr-wiki.ikoula.com/resources/assets/logo_ikwiki.png
}}

==Was ist Kubernetes?==

'''Kubernetes''' ist eine Open-Source-Plattform für die Verwaltung von containerisierten Arbeitslasten und Diensten.
Es unterstützt die deklarative Konfigurationserstellung, aber auch die Automatisierung. ''Kubernetes'' ist ein großes und schnell wachsendes Ökosystem.

Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster einrichten [https://www.ikoula.com/fr/cloud-public/oneclick Kubernetes (k8s)] Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster aus drei CentOS 7-Instanzen einrichten, die innerhalb desselben Netzwerks in einer Forward Zone installiert sind.

Eine dieser drei Instanzen wird unser Masterknoten sein, die anderen beiden werden unsere Arbeitsknoten sein. Zusammenfassend lässt sich sagen, dass der Master-Knoten der Knoten ist, von dem aus wir den Kubernetes-Cluster (Container-Orchestrator) über seine API verwalten, und die Worker-Knoten die Knoten sind, auf denen die Pods oder Container (in unserem Fall Docker) ausgeführt werden.

Wir gehen davon aus, dass Ihre 3 CentOS 7-Instanzen bereits eingerichtet sind und dass Sie per ssh Zugriff auf sie haben, um die folgenden Befehle auszuführen.

Hier ist die Konfiguration, die wir in unserem Beispiel haben und die in diesem Verfahren als Beispiel verwendet wird:

Knotenmaster: "k8s-master" / 10.1.1.16 
Erster Arbeitsknoten: "k8s-worker01" / 10.1.1.169 
Zweiter Arbeitsknoten: "k8s-worker02" / 10.1.1.87 

== Tutorial zur Systemvorbereitung und Kubernetes-Installation ==

Die folgenden Aktionen müssen auf allen Instanzen (Master und Worker) als root (oder mit den erforderlichen sudo-Rechten) durchgeführt werden.

Beginnen Sie damit, die Datei /etc/hosts auf jeder Ihrer Instanzen aufzufüllen, so dass sie ihren jeweiligen Hostnamen auflösen können (normalerweise ist dies in einem erweiterten Zonennetzwerk, in dem der virtuelle Router ein DNS-Auflöser ist, bereits der Fall).

In unserem Beispiel ergibt dies die folgende /etc/hosts Datei auf unseren drei Instanzen (passen Sie sie mit dem Namen und der IP Ihrer Instanzen an):

<syntaxhighlight lang="bash">
cat /etc/hosts
127.0.0.1 localhost
::1 localhost

10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02
</syntaxhighlight>

Aktivieren Sie das Bridge-Modul und die iptables-Regeln für dieses Modul mit den folgenden drei Befehlen:

<syntaxhighlight lang="bash">
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
</syntaxhighlight>

Fügen Sie das YUM-Docker-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF
</syntaxhighlight>

Fügen Sie das YUM-Kubernetes-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
</syntaxhighlight>

Docker installieren :

<syntaxhighlight lang="bash">
yum install -y docker-ce
</syntaxhighlight>

Installieren Sie dann die erforderlichen Kubernetes-Pakete:

<syntaxhighlight lang="bash">
yum install -y kubeadm kubelet kubectl
</syntaxhighlight>

Bearbeiten Sie die Konfigurationsdatei des systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) Konfigurationsdatei die folgende Zeile in den Abschnitt "[Service]" ein:

<pre>
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
</pre>

derart, dass :

<pre>
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
*Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"*
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
</pre>

Laden Sie die Konfiguration neu, aktivieren Sie die Docker- und Kubelet-Dienste und starten Sie sie dann mit den folgenden drei Befehlen:

systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>

Deaktivieren Sie den System-Swap (kubelet unterstützt keinen Swap-Speicher, Sie erhalten eine Fehlermeldung während der Pre-Flight Checks bei der Initialisierung Ihres Clusters über kubeadms, wenn Sie ihn nicht deaktivieren):

<syntaxhighlight lang="bash">
swapoff -a
</syntaxhighlight>

Bitte denken Sie daran, auch die Swap-Zeile in der /etc/fstab Datei jeder Ihrer Instanzen zu kommentieren/entfernen, wie z.B. :

<pre>
#/dev/mapper/vg01-swap swap swap defaults 0 0
</pre>

== Initialisierung des Kubernetes-Clusters ==

Die folgenden Aktionen dürfen nur auf der Node-Master-Instanz durchgeführt werden

Starten Sie die Initialisierung Ihres Kubernetes-Clusters mit dem unten stehenden Befehl. Achten Sie darauf, den Wert des Parameters "--apiserver-advertise-address=" durch die IP-Adresse Ihrer Master-Instanz zu ändern.

<syntaxhighlight lang="bash">
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
</syntaxhighlight>

Hinweis: Bitte ändern Sie die im Parameter "--pod-network-cidr=" angegebene Netzwerk-IP "10.244.0.0/16" nicht, da dieser Parameter angibt, dass wir das CNI Flannel-Plugin zur Verwaltung des Netzwerkteils unserer Pods verwenden werden.

So sollte die Rückgabe dieses Befehls aussehen, wenn der Cluster erfolgreich initialisiert wurde:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
</syntaxhighlight>

Wir führen die geforderten Operationen durch, um die Initialisierung unseres Clusters abzuschließen:

Wir erstellen ein Verzeichnis und eine Konfigurationsdatei in dem Verzeichnis unseres Benutzers (in unserem Fall root):

<syntaxhighlight lang="bash">
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
</syntaxhighlight>

Wir stellen unser Pod-Flannel-Netzwerk für unseren Cluster bereit:

<syntaxhighlight lang="bash">
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
</syntaxhighlight>

Hinweis: Wir werden den letzten Befehl, der durch die Rückgabe des Seiteninitialisierungsbefehls ("kubeadm join...") bereitgestellt wird, behalten, um ihn später auf unseren Worker-Instanzen auszuführen, um sie in unseren Cluster einzubinden.

Wir können nun die ersten Prüfungen unseres Clusters von unserer Master-Instanz aus durchführen:

Geben Sie den Befehl "kubectl get nodes" ein, um die derzeit in Ihrem Cluster vorhandenen Knoten zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 41m v1.12.2
</syntaxhighlight>

Hinweis: Derzeit gibt es nur Ihren Masterknoten, was normal ist, da wir die anderen Knoten noch nicht zum Cluster hinzugefügt haben.

Geben Sie den Befehl "kubectl get pods --all-namespaces" ein, um die derzeit in Ihrem Cluster vorhandenen Pods/Container zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 41m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 41m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 84s
kube-system kube-proxy-h94bs 1/1 Running 0 41m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 40m
</syntaxhighlight>

Hinweis: Es gibt nur Pods, die den Kubernetes-Komponenten entsprechen, die für unseren Master-Knoten benötigt werden (kube-apiserver, etcd, kube-scheduler, etc.).

Wir können den Status dieser Komponenten mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
</syntaxhighlight>

== Hinzufügen von Arbeitsknoten zum Cluster ==

Aktionen, die nur auf Arbeitsinstanzen/Knoten ausgeführt werden

Führen Sie auf jeder Ihrer Worker-Instanzen (nicht auf Ihrer Master-Instanz) den Befehl "kubeadm join ..." aus, der am Ende der obigen Cluster-Initialisierung angegeben ist:

<syntaxhighlight lang="bash">
[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

<syntaxhighlight lang="bash">
[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

== Überprüfung des Status des Clusters ==

Von der Master-Instanz/dem Master-Knoten auszuführende Aktionen

Überprüfen Sie, ob Ihre Arbeitsknoten Ihrem Cluster hinzugefügt wurden, indem Sie den Befehl "kubectl get nodes" erneut ausführen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 46m v1.12.2
k8s-worker01.cs437cloud.internal Ready <none> 103s v1.12.2
k8s-worker02.cs437cloud.internal Ready <none> 48s v1.12.2
</syntaxhighlight>

Bemerkung: Wir können unsere beiden Arbeiterknoten (k8s-worker01 und k8s-worker02) sehen, sie wurden also zu unserem Cluster hinzugefügt.

Führen wir nun erneut den Befehl "kubectl get pods --all-namespaces" aus:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 46m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 46m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 2m6s
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 6m31s
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 70s
kube-system kube-proxy-8r7wg 1/1 Running 0 2m6s
kube-system kube-proxy-h94bs 1/1 Running 0 46m
kube-system kube-proxy-m2f5r 1/1 Running 0 70s
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 46m
</syntaxhighlight>

Hinweis: Wie Sie sehen, gibt es so viele "kube-flannel"- und "kube-proxy"-Pods/Container, wie wir Knoten in unserem Cluster haben.

== Einsatz eines ersten Pods ==

Wir werden unsere erste [https://kubernetes.io/docs/concepts/workloads/pods/pod/ pod] in unserem Kubernetes-Cluster.

Der Einfachheit halber entscheiden wir uns für die Bereitstellung eines Pods (ohne Replikate) mit dem Namen "nginx" und dem Image "nginx":

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
</syntaxhighlight>

Wenn wir nachsehen, erscheint dieser auch bei der Rückkehr des Befehls, der die Pods unseres Clusters auflistet:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-55bd7c9fd-5bghl 1/1 Running 0 104s
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 57m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 57m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 13m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 17m
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 12m
kube-system kube-proxy-8r7wg 1/1 Running 0 13m
kube-system kube-proxy-h94bs 1/1 Running 0 57m
kube-system kube-proxy-m2f5r 1/1 Running 0 12m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 57m
</syntaxhighlight>

Es erscheint am Anfang der Liste in einem anderen Namensraum als "kube-system", da es sich nicht um eine für den Betrieb von Kubernetes spezifische Komponente handelt.

Es ist auch möglich, die Anzeige von Pods, die für den kube-system-Namensraum spezifisch sind, zu vermeiden, indem man denselben Befehl ohne den Parameter "--all-namespace" ausführt:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 3d2h
</syntaxhighlight>

So zeigen Sie die Beschriftungen an:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-55bd7c9fd-ckltn 1/1 Running 0 8m2s app=nginx,pod-template-hash=55bd7c9fd
</syntaxhighlight>

Wir können unsere Bereitstellungen auch mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 93m
</syntaxhighlight>

Wir haben also einen Nginx-Pod eingerichtet und gestartet, aber er ist noch nicht von außen zugänglich. Um ihn von außen zugänglich zu machen, müssen wir den Port unseres Pods offenlegen, indem wir den Dienst (vom Typ NodePort) mit dem folgenden Befehl erstellen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
</syntaxhighlight>

So entsteht unser Service:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 147m
nginx NodePort 10.108.251.178 <none> 80:30566/TCP 20s
</syntaxhighlight>

Hinweis: Er lauscht auf Port 80/tcp und ist von außen über Port 30566/tcp erreichbar/offenbar.

Wir können die Flannel-IP unseres Pods und den Namen des Knotens, auf dem er gerade läuft, mit dem folgenden Befehl abrufen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 174m 10.244.2.2 k8s-worker02.cs437cloud.internal <none>
</syntaxhighlight>

Hier hat unser nginx-Pod die IP 10.244.2.2 und läuft auf unserem Knoten k8s-worker02.

Sie können auch einfach einen Befehl ausführen oder eine Shell auf unserem nginx-Pod über den folgenden Befehl öffnen (sehr ähnlich wie der Docker-Befehl):

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
</syntaxhighlight>

Alles, was Sie tun müssen, ist Ihre Lastausgleichsregel in Ihrem Ikoula One Cloud-Netzwerk zu erstellen, um auf Ihren Webserver (nginx pod) zuzugreifen bzw. ihn zu veröffentlichen:

- Verbinden Sie mit dem [https://cloudstack.ikoula.com/client Wolke Ikoula Eins]

- Gehen Sie auf "Netzwerk" im linken vertikalen Menü

- Klicken Sie auf Ihr Netzwerk, in dem Sie Ihre Kubernetes-Instanzen eingerichtet haben, dann auf "IP-Adressen anzeigen" und auf Ihre NAT-Quell-IP und gehen Sie auf die Registerkarte "Konfiguration".

- klicken Sie auf "Load Balancing" und erstellen Sie Ihre Regel, indem Sie einen Namen angeben, den öffentlichen Port "80" in unserem Fall, den privaten Port "30566" in unserem Fall (siehe oben), indem Sie einen LB-Algorithmus wählen (z.B. Round-Robin) wie :

[[File:faq_k8s_regle_lb-01.png|Kubernetes-Instanz]]

- alle Ihre Arbeitsinstanzen ankreuzen:

[[File:faq_k8s_regle_lb-02.png|Überprüfen Sie Ihre Kubernetes-Arbeitsinstanzen]]

Testen Sie den Zugriff auf Ihren Webserver/Nginx-Pod von Ihrem Browser aus (über die öffentliche IP Ihres Netzwerks, in dem Sie die LB-Regel erstellt haben):

[[File:faq_k8s_browser_nginx.png|Zugang zu Ihrem Webserver]]

Die Tatsache, dass Ihr nginx-Pod von jedem Ihrer Knoten aus zugänglich ist, wird durch die Komponente "kube-proxy" ermöglicht, die für die Weiterleitung von Verbindungen zu dem/den Knoten verantwortlich ist, auf dem/denen sie läuft (im Falle von Replikaten).

Sie haben also gerade einen einfachen Kubernetes-Cluster mit 3 Knoten, einem Master und zwei Workern eingerichtet.

== Weiter gehen ==

Sie können noch weiter gehen, indem Sie das Kubernetes-Dashboard einsetzen oder persistente Volumes für Ihre Pods erstellen, die Anzahl Ihrer Worker-Nodes erhöhen oder sogar die Master-Rolle redundant zuweisen, um eine hohe Verfügbarkeit zu gewährleisten, oder indem Sie Nodes für bestimmte Komponenten wie z. B. Etcd reservieren.

Hier sind einige nützliche Links:

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Docker]]
[[Category:CoreOS]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters

2021-07-29T13:59:05Z

Ikbot:

[[:pl:Wdrażanie klastra Kubernetes]][[pl:Wdrażanie klastra Kubernetes]]
[[:ja:Kubernetesクラスタのデプロイ]][[ja:Kubernetesクラスタのデプロイ]]
[[:zh:部署一个Kubernetes集群]][[zh:部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren]][[nl:Een Kubernetes cluster implementeren]]
[[:pt:Implantação de um aglomerado Kubernetes]][[pt:Implantação de um aglomerado Kubernetes]]
[[:es:Despliegue de un clúster Kubernetes]][[es:Despliegue de un clúster Kubernetes]]
[[:en:Deploying a Kubernetes cluster]][[en:Deploying a Kubernetes cluster]]
[[:it:Configurare un cluster Kubernetes]][[it:Configurare un cluster Kubernetes]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]

{{#seo:
|title=kubernetes Installation
|titlemode=replace
|keywords=ikoula wiki, ikoula wiki, ikoula Wissensbasis, kubernetes ist was, kubernetes installation, kubernetes tutorial
|description=Kubernetes kann als eine Container-Plattform, eine Microservices-Plattform, eine portable Cloud-Plattform und vieles mehr betrachtet werden... Finden Sie heraus, wie man es installiert.
|og:type=article
|og:image=https://fr-wiki.ikoula.com/resources/assets/logo_ikwiki.png
}}

==Was ist Kubernetes?==

'''Kubernetes''' ist eine Open-Source-Plattform für die Verwaltung von containerisierten Arbeitslasten und Diensten.
Es unterstützt die deklarative Konfigurationserstellung, aber auch die Automatisierung. ''Kubernetes'' ist ein großes und schnell wachsendes Ökosystem.

Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster einrichten [https://www.ikoula.com/fr/cloud-public/oneclick Kubernetes (k8s)] Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster aus drei CentOS 7-Instanzen einrichten, die innerhalb desselben Netzwerks in einer Forward Zone installiert sind.

Eine dieser drei Instanzen wird unser Masterknoten sein, die anderen beiden werden unsere Arbeitsknoten sein. Zusammenfassend lässt sich sagen, dass der Master-Knoten der Knoten ist, von dem aus wir den Kubernetes-Cluster (Container-Orchestrator) über seine API verwalten, und die Worker-Knoten die Knoten sind, auf denen die Pods oder Container (in unserem Fall Docker) ausgeführt werden.

Wir gehen davon aus, dass Ihre 3 CentOS 7-Instanzen bereits eingerichtet sind und dass Sie per ssh Zugriff auf sie haben, um die folgenden Befehle auszuführen.

Hier ist die Konfiguration, die wir in unserem Beispiel haben und die in diesem Verfahren als Beispiel verwendet wird:

Knotenmaster: "k8s-master" / 10.1.1.16 
Erster Arbeitsknoten: "k8s-worker01" / 10.1.1.169 
Zweiter Arbeitsknoten: "k8s-worker02" / 10.1.1.87 

== Tutorial zur Systemvorbereitung und Kubernetes-Installation ==

Die folgenden Aktionen müssen auf allen Instanzen (Master und Worker) als root (oder mit den erforderlichen sudo-Rechten) durchgeführt werden.

Beginnen Sie damit, die Datei /etc/hosts auf jeder Ihrer Instanzen aufzufüllen, so dass sie ihren jeweiligen Hostnamen auflösen können (normalerweise ist dies in einem erweiterten Zonennetzwerk, in dem der virtuelle Router ein DNS-Auflöser ist, bereits der Fall).

In unserem Beispiel ergibt dies die folgende /etc/hosts Datei auf unseren drei Instanzen (passen Sie sie mit dem Namen und der IP Ihrer Instanzen an):

<syntaxhighlight lang="bash">
cat /etc/hosts
127.0.0.1 localhost
::1 localhost

10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02
</syntaxhighlight>

Aktivieren Sie das Bridge-Modul und die iptables-Regeln für dieses Modul mit den folgenden drei Befehlen:

<syntaxhighlight lang="bash">
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
</syntaxhighlight>

Fügen Sie das YUM-Docker-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF
</syntaxhighlight>

Fügen Sie das YUM-Kubernetes-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
</syntaxhighlight>

Docker installieren :

<syntaxhighlight lang="bash">
yum install -y docker-ce
</syntaxhighlight>

Installieren Sie dann die erforderlichen Kubernetes-Pakete:

<syntaxhighlight lang="bash">
yum install -y kubeadm kubelet kubectl
</syntaxhighlight>

Bearbeiten Sie die Konfigurationsdatei des systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) Konfigurationsdatei die folgende Zeile in den Abschnitt "[Service]" ein:

<pre>
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
</pre>

derart, dass :

<pre>
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
*Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"*
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
</pre>

Laden Sie die Konfiguration neu, aktivieren Sie die Docker- und Kubelet-Dienste und starten Sie sie dann mit den folgenden drei Befehlen:

systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>

Deaktivieren Sie den System-Swap (kubelet unterstützt keinen Swap-Speicher, Sie erhalten eine Fehlermeldung während der Pre-Flight Checks bei der Initialisierung Ihres Clusters über kubeadms, wenn Sie ihn nicht deaktivieren):

<syntaxhighlight lang="bash">
swapoff -a
</syntaxhighlight>

Bitte denken Sie daran, auch die Swap-Zeile in der /etc/fstab Datei jeder Ihrer Instanzen zu kommentieren/entfernen, wie z.B. :

<pre>
#/dev/mapper/vg01-swap swap swap defaults 0 0
</pre>

== Initialisierung des Kubernetes-Clusters ==

Die folgenden Aktionen dürfen nur auf der Node-Master-Instanz durchgeführt werden

Starten Sie die Initialisierung Ihres Kubernetes-Clusters mit dem unten stehenden Befehl. Achten Sie darauf, den Wert des Parameters "--apiserver-advertise-address=" durch die IP-Adresse Ihrer Master-Instanz zu ändern.

<syntaxhighlight lang="bash">
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
</syntaxhighlight>

Hinweis: Bitte ändern Sie die im Parameter "--pod-network-cidr=" angegebene Netzwerk-IP "10.244.0.0/16" nicht, da dieser Parameter angibt, dass wir das CNI Flannel-Plugin zur Verwaltung des Netzwerkteils unserer Pods verwenden werden.

So sollte die Rückgabe dieses Befehls aussehen, wenn der Cluster erfolgreich initialisiert wurde:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
</syntaxhighlight>

Wir führen die geforderten Operationen durch, um die Initialisierung unseres Clusters abzuschließen:

Wir erstellen ein Verzeichnis und eine Konfigurationsdatei in dem Verzeichnis unseres Benutzers (in unserem Fall root):

<syntaxhighlight lang="bash">
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
</syntaxhighlight>

Wir stellen unser Pod-Flannel-Netzwerk für unseren Cluster bereit:

<syntaxhighlight lang="bash">
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
</syntaxhighlight>

Hinweis: Wir werden den letzten Befehl, der durch die Rückgabe des Seiteninitialisierungsbefehls ("kubeadm join...") bereitgestellt wird, behalten, um ihn später auf unseren Worker-Instanzen auszuführen, um sie in unseren Cluster einzubinden.

Wir können nun die ersten Prüfungen unseres Clusters von unserer Master-Instanz aus durchführen:

Geben Sie den Befehl "kubectl get nodes" ein, um die derzeit in Ihrem Cluster vorhandenen Knoten zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 41m v1.12.2
</syntaxhighlight>

Hinweis: Derzeit gibt es nur Ihren Masterknoten, was normal ist, da wir die anderen Knoten noch nicht zum Cluster hinzugefügt haben.

Geben Sie den Befehl "kubectl get pods --all-namespaces" ein, um die derzeit in Ihrem Cluster vorhandenen Pods/Container zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 41m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 41m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 84s
kube-system kube-proxy-h94bs 1/1 Running 0 41m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 40m
</syntaxhighlight>

Hinweis: Es gibt nur Pods, die den Kubernetes-Komponenten entsprechen, die für unseren Master-Knoten benötigt werden (kube-apiserver, etcd, kube-scheduler, etc.).

Wir können den Status dieser Komponenten mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
</syntaxhighlight>

== Hinzufügen von Arbeitsknoten zum Cluster ==

Aktionen, die nur auf Arbeitsinstanzen/Knoten ausgeführt werden

Führen Sie auf jeder Ihrer Worker-Instanzen (nicht auf Ihrer Master-Instanz) den Befehl "kubeadm join ..." aus, der am Ende der obigen Cluster-Initialisierung angegeben ist:

<syntaxhighlight lang="bash">
[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

<syntaxhighlight lang="bash">
[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

== Überprüfung des Status des Clusters ==

Von der Master-Instanz/dem Master-Knoten auszuführende Aktionen

Überprüfen Sie, ob Ihre Arbeitsknoten Ihrem Cluster hinzugefügt wurden, indem Sie den Befehl "kubectl get nodes" erneut ausführen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 46m v1.12.2
k8s-worker01.cs437cloud.internal Ready <none> 103s v1.12.2
k8s-worker02.cs437cloud.internal Ready <none> 48s v1.12.2
</syntaxhighlight>

Bemerkung: Wir können unsere beiden Arbeiterknoten (k8s-worker01 und k8s-worker02) sehen, sie wurden also zu unserem Cluster hinzugefügt.

Führen wir nun erneut den Befehl "kubectl get pods --all-namespaces" aus:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 46m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 46m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 2m6s
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 6m31s
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 70s
kube-system kube-proxy-8r7wg 1/1 Running 0 2m6s
kube-system kube-proxy-h94bs 1/1 Running 0 46m
kube-system kube-proxy-m2f5r 1/1 Running 0 70s
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 46m
</syntaxhighlight>

Hinweis: Wie Sie sehen, gibt es so viele "kube-flannel"- und "kube-proxy"-Pods/Container, wie wir Knoten in unserem Cluster haben.

== Einsatz eines ersten Pods ==

Wir werden unsere erste [https://kubernetes.io/docs/concepts/workloads/pods/pod/ pod] in unserem Kubernetes-Cluster.

Der Einfachheit halber entscheiden wir uns für die Bereitstellung eines Pods (ohne Replikate) mit dem Namen "nginx" und dem Image "nginx":

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
</syntaxhighlight>

Wenn wir nachsehen, erscheint dieser auch bei der Rückkehr des Befehls, der die Pods unseres Clusters auflistet:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-55bd7c9fd-5bghl 1/1 Running 0 104s
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 57m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 57m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 13m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 17m
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 12m
kube-system kube-proxy-8r7wg 1/1 Running 0 13m
kube-system kube-proxy-h94bs 1/1 Running 0 57m
kube-system kube-proxy-m2f5r 1/1 Running 0 12m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 57m
</syntaxhighlight>

Es erscheint am Anfang der Liste in einem anderen Namensraum als "kube-system", da es sich nicht um eine für den Betrieb von Kubernetes spezifische Komponente handelt.

Es ist auch möglich, die Anzeige von Pods, die für den kube-system-Namensraum spezifisch sind, zu vermeiden, indem man denselben Befehl ohne den Parameter "--all-namespace" ausführt:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 3d2h
</syntaxhighlight>

So zeigen Sie die Beschriftungen an:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-55bd7c9fd-ckltn 1/1 Running 0 8m2s app=nginx,pod-template-hash=55bd7c9fd
</syntaxhighlight>

Wir können unsere Bereitstellungen auch mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 93m
</syntaxhighlight>

Wir haben also einen Nginx-Pod eingerichtet und gestartet, aber er ist noch nicht von außen zugänglich. Um ihn von außen zugänglich zu machen, müssen wir den Port unseres Pods offenlegen, indem wir den Dienst (vom Typ NodePort) mit dem folgenden Befehl erstellen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
</syntaxhighlight>

So entsteht unser Service:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 147m
nginx NodePort 10.108.251.178 <none> 80:30566/TCP 20s
</syntaxhighlight>

Hinweis: Er lauscht auf Port 80/tcp und ist von außen über Port 30566/tcp erreichbar/offenbar.

Wir können die Flannel-IP unseres Pods und den Namen des Knotens, auf dem er gerade läuft, mit dem folgenden Befehl abrufen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 174m 10.244.2.2 k8s-worker02.cs437cloud.internal <none>
</syntaxhighlight>

Hier hat unser nginx-Pod die IP 10.244.2.2 und läuft auf unserem Knoten k8s-worker02.

Sie können auch einfach einen Befehl ausführen oder eine Shell auf unserem nginx-Pod über den folgenden Befehl öffnen (sehr ähnlich wie der Docker-Befehl):

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
</syntaxhighlight>

Alles, was Sie tun müssen, ist Ihre Lastausgleichsregel in Ihrem Ikoula One Cloud-Netzwerk zu erstellen, um auf Ihren Webserver (nginx pod) zuzugreifen bzw. ihn zu veröffentlichen:

- Verbinden Sie mit dem [https://cloudstack.ikoula.com/client Wolke Ikoula Eins]

- Gehen Sie auf "Netzwerk" im linken vertikalen Menü

- Klicken Sie auf Ihr Netzwerk, in dem Sie Ihre Kubernetes-Instanzen eingerichtet haben, dann auf "IP-Adressen anzeigen" und auf Ihre NAT-Quell-IP und gehen Sie auf die Registerkarte "Konfiguration".

- klicken Sie auf "Load Balancing" und erstellen Sie Ihre Regel, indem Sie einen Namen angeben, den öffentlichen Port "80" in unserem Fall, den privaten Port "30566" in unserem Fall (siehe oben), indem Sie einen LB-Algorithmus wählen (z.B. Round-Robin) wie :

[[File:faq_k8s_regle_lb-01.png|Kubernetes-Instanz]]

- alle Ihre Arbeitsinstanzen ankreuzen:

[[File:faq_k8s_regle_lb-02.png|Überprüfen Sie Ihre Kubernetes-Arbeitsinstanzen]]

Testen Sie den Zugriff auf Ihren Webserver/Nginx-Pod von Ihrem Browser aus (über die öffentliche IP Ihres Netzwerks, in dem Sie die LB-Regel erstellt haben):

[[File:faq_k8s_browser_nginx.png|Zugang zu Ihrem Webserver]]

Die Tatsache, dass Ihr nginx-Pod von jedem Ihrer Knoten aus zugänglich ist, wird durch die Komponente "kube-proxy" ermöglicht, die für die Weiterleitung von Verbindungen zu dem/den Knoten verantwortlich ist, auf dem/denen sie läuft (im Falle von Replikaten).

Sie haben also gerade einen einfachen Kubernetes-Cluster mit 3 Knoten, einem Master und zwei Workern eingerichtet.

== Weiter gehen ==

Sie können noch weiter gehen, indem Sie das Kubernetes-Dashboard einsetzen oder persistente Volumes für Ihre Pods erstellen, die Anzahl Ihrer Worker-Nodes erhöhen oder sogar die Master-Rolle redundant zuweisen, um eine hohe Verfügbarkeit zu gewährleisten, oder indem Sie Nodes für bestimmte Komponenten wie z. B. Etcd reservieren.

Hier sind einige nützliche Links:

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Docker]]
[[Category:CoreOS]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters

2021-07-29T13:57:35Z

Ikbot:

[[:ja:Kubernetesクラスタのデプロイ]][[ja:Kubernetesクラスタのデプロイ]]
[[:zh:部署一个Kubernetes集群]][[zh:部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren]][[nl:Een Kubernetes cluster implementeren]]
[[:pt:Implantação de um aglomerado Kubernetes]][[pt:Implantação de um aglomerado Kubernetes]]
[[:es:Despliegue de un clúster Kubernetes]][[es:Despliegue de un clúster Kubernetes]]
[[:en:Deploying a Kubernetes cluster]][[en:Deploying a Kubernetes cluster]]
[[:it:Configurare un cluster Kubernetes]][[it:Configurare un cluster Kubernetes]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]

{{#seo:
|title=kubernetes Installation
|titlemode=replace
|keywords=ikoula wiki, ikoula wiki, ikoula Wissensbasis, kubernetes ist was, kubernetes installation, kubernetes tutorial
|description=Kubernetes kann als eine Container-Plattform, eine Microservices-Plattform, eine portable Cloud-Plattform und vieles mehr betrachtet werden... Finden Sie heraus, wie man es installiert.
|og:type=article
|og:image=https://fr-wiki.ikoula.com/resources/assets/logo_ikwiki.png
}}

==Was ist Kubernetes?==

'''Kubernetes''' ist eine Open-Source-Plattform für die Verwaltung von containerisierten Arbeitslasten und Diensten.
Es unterstützt die deklarative Konfigurationserstellung, aber auch die Automatisierung. ''Kubernetes'' ist ein großes und schnell wachsendes Ökosystem.

Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster einrichten [https://www.ikoula.com/fr/cloud-public/oneclick Kubernetes (k8s)] Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster aus drei CentOS 7-Instanzen einrichten, die innerhalb desselben Netzwerks in einer Forward Zone installiert sind.

Eine dieser drei Instanzen wird unser Masterknoten sein, die anderen beiden werden unsere Arbeitsknoten sein. Zusammenfassend lässt sich sagen, dass der Master-Knoten der Knoten ist, von dem aus wir den Kubernetes-Cluster (Container-Orchestrator) über seine API verwalten, und die Worker-Knoten die Knoten sind, auf denen die Pods oder Container (in unserem Fall Docker) ausgeführt werden.

Wir gehen davon aus, dass Ihre 3 CentOS 7-Instanzen bereits eingerichtet sind und dass Sie per ssh Zugriff auf sie haben, um die folgenden Befehle auszuführen.

Hier ist die Konfiguration, die wir in unserem Beispiel haben und die in diesem Verfahren als Beispiel verwendet wird:

Knotenmaster: "k8s-master" / 10.1.1.16 
Erster Arbeitsknoten: "k8s-worker01" / 10.1.1.169 
Zweiter Arbeitsknoten: "k8s-worker02" / 10.1.1.87 

== Tutorial zur Systemvorbereitung und Kubernetes-Installation ==

Die folgenden Aktionen müssen auf allen Instanzen (Master und Worker) als root (oder mit den erforderlichen sudo-Rechten) durchgeführt werden.

Beginnen Sie damit, die Datei /etc/hosts auf jeder Ihrer Instanzen aufzufüllen, so dass sie ihren jeweiligen Hostnamen auflösen können (normalerweise ist dies in einem erweiterten Zonennetzwerk, in dem der virtuelle Router ein DNS-Auflöser ist, bereits der Fall).

In unserem Beispiel ergibt dies die folgende /etc/hosts Datei auf unseren drei Instanzen (passen Sie sie mit dem Namen und der IP Ihrer Instanzen an):

<syntaxhighlight lang="bash">
cat /etc/hosts
127.0.0.1 localhost
::1 localhost

10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02
</syntaxhighlight>

Aktivieren Sie das Bridge-Modul und die iptables-Regeln für dieses Modul mit den folgenden drei Befehlen:

<syntaxhighlight lang="bash">
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
</syntaxhighlight>

Fügen Sie das YUM-Docker-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF
</syntaxhighlight>

Fügen Sie das YUM-Kubernetes-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
</syntaxhighlight>

Docker installieren :

<syntaxhighlight lang="bash">
yum install -y docker-ce
</syntaxhighlight>

Installieren Sie dann die erforderlichen Kubernetes-Pakete:

<syntaxhighlight lang="bash">
yum install -y kubeadm kubelet kubectl
</syntaxhighlight>

Bearbeiten Sie die Konfigurationsdatei des systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) Konfigurationsdatei die folgende Zeile in den Abschnitt "[Service]" ein:

<pre>
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
</pre>

derart, dass :

<pre>
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
*Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"*
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
</pre>

Laden Sie die Konfiguration neu, aktivieren Sie die Docker- und Kubelet-Dienste und starten Sie sie dann mit den folgenden drei Befehlen:

systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>

Deaktivieren Sie den System-Swap (kubelet unterstützt keinen Swap-Speicher, Sie erhalten eine Fehlermeldung während der Pre-Flight Checks bei der Initialisierung Ihres Clusters über kubeadms, wenn Sie ihn nicht deaktivieren):

<syntaxhighlight lang="bash">
swapoff -a
</syntaxhighlight>

Bitte denken Sie daran, auch die Swap-Zeile in der /etc/fstab Datei jeder Ihrer Instanzen zu kommentieren/entfernen, wie z.B. :

<pre>
#/dev/mapper/vg01-swap swap swap defaults 0 0
</pre>

== Initialisierung des Kubernetes-Clusters ==

Die folgenden Aktionen dürfen nur auf der Node-Master-Instanz durchgeführt werden

Starten Sie die Initialisierung Ihres Kubernetes-Clusters mit dem unten stehenden Befehl. Achten Sie darauf, den Wert des Parameters "--apiserver-advertise-address=" durch die IP-Adresse Ihrer Master-Instanz zu ändern.

<syntaxhighlight lang="bash">
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
</syntaxhighlight>

Hinweis: Bitte ändern Sie die im Parameter "--pod-network-cidr=" angegebene Netzwerk-IP "10.244.0.0/16" nicht, da dieser Parameter angibt, dass wir das CNI Flannel-Plugin zur Verwaltung des Netzwerkteils unserer Pods verwenden werden.

So sollte die Rückgabe dieses Befehls aussehen, wenn der Cluster erfolgreich initialisiert wurde:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
</syntaxhighlight>

Wir führen die geforderten Operationen durch, um die Initialisierung unseres Clusters abzuschließen:

Wir erstellen ein Verzeichnis und eine Konfigurationsdatei in dem Verzeichnis unseres Benutzers (in unserem Fall root):

<syntaxhighlight lang="bash">
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
</syntaxhighlight>

Wir stellen unser Pod-Flannel-Netzwerk für unseren Cluster bereit:

<syntaxhighlight lang="bash">
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
</syntaxhighlight>

Hinweis: Wir werden den letzten Befehl, der durch die Rückgabe des Seiteninitialisierungsbefehls ("kubeadm join...") bereitgestellt wird, behalten, um ihn später auf unseren Worker-Instanzen auszuführen, um sie in unseren Cluster einzubinden.

Wir können nun die ersten Prüfungen unseres Clusters von unserer Master-Instanz aus durchführen:

Geben Sie den Befehl "kubectl get nodes" ein, um die derzeit in Ihrem Cluster vorhandenen Knoten zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 41m v1.12.2
</syntaxhighlight>

Hinweis: Derzeit gibt es nur Ihren Masterknoten, was normal ist, da wir die anderen Knoten noch nicht zum Cluster hinzugefügt haben.

Geben Sie den Befehl "kubectl get pods --all-namespaces" ein, um die derzeit in Ihrem Cluster vorhandenen Pods/Container zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 41m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 41m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 84s
kube-system kube-proxy-h94bs 1/1 Running 0 41m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 40m
</syntaxhighlight>

Hinweis: Es gibt nur Pods, die den Kubernetes-Komponenten entsprechen, die für unseren Master-Knoten benötigt werden (kube-apiserver, etcd, kube-scheduler, etc.).

Wir können den Status dieser Komponenten mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
</syntaxhighlight>

== Hinzufügen von Arbeitsknoten zum Cluster ==

Aktionen, die nur auf Arbeitsinstanzen/Knoten ausgeführt werden

Führen Sie auf jeder Ihrer Worker-Instanzen (nicht auf Ihrer Master-Instanz) den Befehl "kubeadm join ..." aus, der am Ende der obigen Cluster-Initialisierung angegeben ist:

<syntaxhighlight lang="bash">
[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

<syntaxhighlight lang="bash">
[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

== Überprüfung des Status des Clusters ==

Von der Master-Instanz/dem Master-Knoten auszuführende Aktionen

Überprüfen Sie, ob Ihre Arbeitsknoten Ihrem Cluster hinzugefügt wurden, indem Sie den Befehl "kubectl get nodes" erneut ausführen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 46m v1.12.2
k8s-worker01.cs437cloud.internal Ready <none> 103s v1.12.2
k8s-worker02.cs437cloud.internal Ready <none> 48s v1.12.2
</syntaxhighlight>

Bemerkung: Wir können unsere beiden Arbeiterknoten (k8s-worker01 und k8s-worker02) sehen, sie wurden also zu unserem Cluster hinzugefügt.

Führen wir nun erneut den Befehl "kubectl get pods --all-namespaces" aus:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 46m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 46m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 2m6s
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 6m31s
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 70s
kube-system kube-proxy-8r7wg 1/1 Running 0 2m6s
kube-system kube-proxy-h94bs 1/1 Running 0 46m
kube-system kube-proxy-m2f5r 1/1 Running 0 70s
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 46m
</syntaxhighlight>

Hinweis: Wie Sie sehen, gibt es so viele "kube-flannel"- und "kube-proxy"-Pods/Container, wie wir Knoten in unserem Cluster haben.

== Einsatz eines ersten Pods ==

Wir werden unsere erste [https://kubernetes.io/docs/concepts/workloads/pods/pod/ pod] in unserem Kubernetes-Cluster.

Der Einfachheit halber entscheiden wir uns für die Bereitstellung eines Pods (ohne Replikate) mit dem Namen "nginx" und dem Image "nginx":

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
</syntaxhighlight>

Wenn wir nachsehen, erscheint dieser auch bei der Rückkehr des Befehls, der die Pods unseres Clusters auflistet:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-55bd7c9fd-5bghl 1/1 Running 0 104s
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 57m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 57m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 13m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 17m
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 12m
kube-system kube-proxy-8r7wg 1/1 Running 0 13m
kube-system kube-proxy-h94bs 1/1 Running 0 57m
kube-system kube-proxy-m2f5r 1/1 Running 0 12m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 57m
</syntaxhighlight>

Es erscheint am Anfang der Liste in einem anderen Namensraum als "kube-system", da es sich nicht um eine für den Betrieb von Kubernetes spezifische Komponente handelt.

Es ist auch möglich, die Anzeige von Pods, die für den kube-system-Namensraum spezifisch sind, zu vermeiden, indem man denselben Befehl ohne den Parameter "--all-namespace" ausführt:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 3d2h
</syntaxhighlight>

So zeigen Sie die Beschriftungen an:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-55bd7c9fd-ckltn 1/1 Running 0 8m2s app=nginx,pod-template-hash=55bd7c9fd
</syntaxhighlight>

Wir können unsere Bereitstellungen auch mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 93m
</syntaxhighlight>

Wir haben also einen Nginx-Pod eingerichtet und gestartet, aber er ist noch nicht von außen zugänglich. Um ihn von außen zugänglich zu machen, müssen wir den Port unseres Pods offenlegen, indem wir den Dienst (vom Typ NodePort) mit dem folgenden Befehl erstellen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
</syntaxhighlight>

So entsteht unser Service:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 147m
nginx NodePort 10.108.251.178 <none> 80:30566/TCP 20s
</syntaxhighlight>

Hinweis: Er lauscht auf Port 80/tcp und ist von außen über Port 30566/tcp erreichbar/offenbar.

Wir können die Flannel-IP unseres Pods und den Namen des Knotens, auf dem er gerade läuft, mit dem folgenden Befehl abrufen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 174m 10.244.2.2 k8s-worker02.cs437cloud.internal <none>
</syntaxhighlight>

Hier hat unser nginx-Pod die IP 10.244.2.2 und läuft auf unserem Knoten k8s-worker02.

Sie können auch einfach einen Befehl ausführen oder eine Shell auf unserem nginx-Pod über den folgenden Befehl öffnen (sehr ähnlich wie der Docker-Befehl):

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
</syntaxhighlight>

Alles, was Sie tun müssen, ist Ihre Lastausgleichsregel in Ihrem Ikoula One Cloud-Netzwerk zu erstellen, um auf Ihren Webserver (nginx pod) zuzugreifen bzw. ihn zu veröffentlichen:

- Verbinden Sie mit dem [https://cloudstack.ikoula.com/client Wolke Ikoula Eins]

- Gehen Sie auf "Netzwerk" im linken vertikalen Menü

- Klicken Sie auf Ihr Netzwerk, in dem Sie Ihre Kubernetes-Instanzen eingerichtet haben, dann auf "IP-Adressen anzeigen" und auf Ihre NAT-Quell-IP und gehen Sie auf die Registerkarte "Konfiguration".

- klicken Sie auf "Load Balancing" und erstellen Sie Ihre Regel, indem Sie einen Namen angeben, den öffentlichen Port "80" in unserem Fall, den privaten Port "30566" in unserem Fall (siehe oben), indem Sie einen LB-Algorithmus wählen (z.B. Round-Robin) wie :

[[File:faq_k8s_regle_lb-01.png|Kubernetes-Instanz]]

- alle Ihre Arbeitsinstanzen ankreuzen:

[[File:faq_k8s_regle_lb-02.png|Überprüfen Sie Ihre Kubernetes-Arbeitsinstanzen]]

Testen Sie den Zugriff auf Ihren Webserver/Nginx-Pod von Ihrem Browser aus (über die öffentliche IP Ihres Netzwerks, in dem Sie die LB-Regel erstellt haben):

[[File:faq_k8s_browser_nginx.png|Zugang zu Ihrem Webserver]]

Die Tatsache, dass Ihr nginx-Pod von jedem Ihrer Knoten aus zugänglich ist, wird durch die Komponente "kube-proxy" ermöglicht, die für die Weiterleitung von Verbindungen zu dem/den Knoten verantwortlich ist, auf dem/denen sie läuft (im Falle von Replikaten).

Sie haben also gerade einen einfachen Kubernetes-Cluster mit 3 Knoten, einem Master und zwei Workern eingerichtet.

== Weiter gehen ==

Sie können noch weiter gehen, indem Sie das Kubernetes-Dashboard einsetzen oder persistente Volumes für Ihre Pods erstellen, die Anzahl Ihrer Worker-Nodes erhöhen oder sogar die Master-Rolle redundant zuweisen, um eine hohe Verfügbarkeit zu gewährleisten, oder indem Sie Nodes für bestimmte Komponenten wie z. B. Etcd reservieren.

Hier sind einige nützliche Links:

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Docker]]
[[Category:CoreOS]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters

2021-07-29T13:55:55Z

Ikbot:

[[:zh:部署一个Kubernetes集群]][[zh:部署一个Kubernetes集群]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren]][[nl:Een Kubernetes cluster implementeren]]
[[:pt:Implantação de um aglomerado Kubernetes]][[pt:Implantação de um aglomerado Kubernetes]]
[[:es:Despliegue de un clúster Kubernetes]][[es:Despliegue de un clúster Kubernetes]]
[[:en:Deploying a Kubernetes cluster]][[en:Deploying a Kubernetes cluster]]
[[:it:Configurare un cluster Kubernetes]][[it:Configurare un cluster Kubernetes]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]

{{#seo:
|title=kubernetes Installation
|titlemode=replace
|keywords=ikoula wiki, ikoula wiki, ikoula Wissensbasis, kubernetes ist was, kubernetes installation, kubernetes tutorial
|description=Kubernetes kann als eine Container-Plattform, eine Microservices-Plattform, eine portable Cloud-Plattform und vieles mehr betrachtet werden... Finden Sie heraus, wie man es installiert.
|og:type=article
|og:image=https://fr-wiki.ikoula.com/resources/assets/logo_ikwiki.png
}}

==Was ist Kubernetes?==

'''Kubernetes''' ist eine Open-Source-Plattform für die Verwaltung von containerisierten Arbeitslasten und Diensten.
Es unterstützt die deklarative Konfigurationserstellung, aber auch die Automatisierung. ''Kubernetes'' ist ein großes und schnell wachsendes Ökosystem.

Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster einrichten [https://www.ikoula.com/fr/cloud-public/oneclick Kubernetes (k8s)] Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster aus drei CentOS 7-Instanzen einrichten, die innerhalb desselben Netzwerks in einer Forward Zone installiert sind.

Eine dieser drei Instanzen wird unser Masterknoten sein, die anderen beiden werden unsere Arbeitsknoten sein. Zusammenfassend lässt sich sagen, dass der Master-Knoten der Knoten ist, von dem aus wir den Kubernetes-Cluster (Container-Orchestrator) über seine API verwalten, und die Worker-Knoten die Knoten sind, auf denen die Pods oder Container (in unserem Fall Docker) ausgeführt werden.

Wir gehen davon aus, dass Ihre 3 CentOS 7-Instanzen bereits eingerichtet sind und dass Sie per ssh Zugriff auf sie haben, um die folgenden Befehle auszuführen.

Hier ist die Konfiguration, die wir in unserem Beispiel haben und die in diesem Verfahren als Beispiel verwendet wird:

Knotenmaster: "k8s-master" / 10.1.1.16 
Erster Arbeitsknoten: "k8s-worker01" / 10.1.1.169 
Zweiter Arbeitsknoten: "k8s-worker02" / 10.1.1.87 

== Tutorial zur Systemvorbereitung und Kubernetes-Installation ==

Die folgenden Aktionen müssen auf allen Instanzen (Master und Worker) als root (oder mit den erforderlichen sudo-Rechten) durchgeführt werden.

Beginnen Sie damit, die Datei /etc/hosts auf jeder Ihrer Instanzen aufzufüllen, so dass sie ihren jeweiligen Hostnamen auflösen können (normalerweise ist dies in einem erweiterten Zonennetzwerk, in dem der virtuelle Router ein DNS-Auflöser ist, bereits der Fall).

In unserem Beispiel ergibt dies die folgende /etc/hosts Datei auf unseren drei Instanzen (passen Sie sie mit dem Namen und der IP Ihrer Instanzen an):

<syntaxhighlight lang="bash">
cat /etc/hosts
127.0.0.1 localhost
::1 localhost

10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02
</syntaxhighlight>

Aktivieren Sie das Bridge-Modul und die iptables-Regeln für dieses Modul mit den folgenden drei Befehlen:

<syntaxhighlight lang="bash">
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
</syntaxhighlight>

Fügen Sie das YUM-Docker-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF
</syntaxhighlight>

Fügen Sie das YUM-Kubernetes-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
</syntaxhighlight>

Docker installieren :

<syntaxhighlight lang="bash">
yum install -y docker-ce
</syntaxhighlight>

Installieren Sie dann die erforderlichen Kubernetes-Pakete:

<syntaxhighlight lang="bash">
yum install -y kubeadm kubelet kubectl
</syntaxhighlight>

Bearbeiten Sie die Konfigurationsdatei des systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) Konfigurationsdatei die folgende Zeile in den Abschnitt "[Service]" ein:

<pre>
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
</pre>

derart, dass :

<pre>
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
*Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"*
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
</pre>

Laden Sie die Konfiguration neu, aktivieren Sie die Docker- und Kubelet-Dienste und starten Sie sie dann mit den folgenden drei Befehlen:

systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>

Deaktivieren Sie den System-Swap (kubelet unterstützt keinen Swap-Speicher, Sie erhalten eine Fehlermeldung während der Pre-Flight Checks bei der Initialisierung Ihres Clusters über kubeadms, wenn Sie ihn nicht deaktivieren):

<syntaxhighlight lang="bash">
swapoff -a
</syntaxhighlight>

Bitte denken Sie daran, auch die Swap-Zeile in der /etc/fstab Datei jeder Ihrer Instanzen zu kommentieren/entfernen, wie z.B. :

<pre>
#/dev/mapper/vg01-swap swap swap defaults 0 0
</pre>

== Initialisierung des Kubernetes-Clusters ==

Die folgenden Aktionen dürfen nur auf der Node-Master-Instanz durchgeführt werden

Starten Sie die Initialisierung Ihres Kubernetes-Clusters mit dem unten stehenden Befehl. Achten Sie darauf, den Wert des Parameters "--apiserver-advertise-address=" durch die IP-Adresse Ihrer Master-Instanz zu ändern.

<syntaxhighlight lang="bash">
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
</syntaxhighlight>

Hinweis: Bitte ändern Sie die im Parameter "--pod-network-cidr=" angegebene Netzwerk-IP "10.244.0.0/16" nicht, da dieser Parameter angibt, dass wir das CNI Flannel-Plugin zur Verwaltung des Netzwerkteils unserer Pods verwenden werden.

So sollte die Rückgabe dieses Befehls aussehen, wenn der Cluster erfolgreich initialisiert wurde:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
</syntaxhighlight>

Wir führen die geforderten Operationen durch, um die Initialisierung unseres Clusters abzuschließen:

Wir erstellen ein Verzeichnis und eine Konfigurationsdatei in dem Verzeichnis unseres Benutzers (in unserem Fall root):

<syntaxhighlight lang="bash">
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
</syntaxhighlight>

Wir stellen unser Pod-Flannel-Netzwerk für unseren Cluster bereit:

<syntaxhighlight lang="bash">
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
</syntaxhighlight>

Hinweis: Wir werden den letzten Befehl, der durch die Rückgabe des Seiteninitialisierungsbefehls ("kubeadm join...") bereitgestellt wird, behalten, um ihn später auf unseren Worker-Instanzen auszuführen, um sie in unseren Cluster einzubinden.

Wir können nun die ersten Prüfungen unseres Clusters von unserer Master-Instanz aus durchführen:

Geben Sie den Befehl "kubectl get nodes" ein, um die derzeit in Ihrem Cluster vorhandenen Knoten zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 41m v1.12.2
</syntaxhighlight>

Hinweis: Derzeit gibt es nur Ihren Masterknoten, was normal ist, da wir die anderen Knoten noch nicht zum Cluster hinzugefügt haben.

Geben Sie den Befehl "kubectl get pods --all-namespaces" ein, um die derzeit in Ihrem Cluster vorhandenen Pods/Container zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 41m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 41m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 84s
kube-system kube-proxy-h94bs 1/1 Running 0 41m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 40m
</syntaxhighlight>

Hinweis: Es gibt nur Pods, die den Kubernetes-Komponenten entsprechen, die für unseren Master-Knoten benötigt werden (kube-apiserver, etcd, kube-scheduler, etc.).

Wir können den Status dieser Komponenten mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
</syntaxhighlight>

== Hinzufügen von Arbeitsknoten zum Cluster ==

Aktionen, die nur auf Arbeitsinstanzen/Knoten ausgeführt werden

Führen Sie auf jeder Ihrer Worker-Instanzen (nicht auf Ihrer Master-Instanz) den Befehl "kubeadm join ..." aus, der am Ende der obigen Cluster-Initialisierung angegeben ist:

<syntaxhighlight lang="bash">
[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

<syntaxhighlight lang="bash">
[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

== Überprüfung des Status des Clusters ==

Von der Master-Instanz/dem Master-Knoten auszuführende Aktionen

Überprüfen Sie, ob Ihre Arbeitsknoten Ihrem Cluster hinzugefügt wurden, indem Sie den Befehl "kubectl get nodes" erneut ausführen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 46m v1.12.2
k8s-worker01.cs437cloud.internal Ready <none> 103s v1.12.2
k8s-worker02.cs437cloud.internal Ready <none> 48s v1.12.2
</syntaxhighlight>

Bemerkung: Wir können unsere beiden Arbeiterknoten (k8s-worker01 und k8s-worker02) sehen, sie wurden also zu unserem Cluster hinzugefügt.

Führen wir nun erneut den Befehl "kubectl get pods --all-namespaces" aus:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 46m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 46m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 2m6s
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 6m31s
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 70s
kube-system kube-proxy-8r7wg 1/1 Running 0 2m6s
kube-system kube-proxy-h94bs 1/1 Running 0 46m
kube-system kube-proxy-m2f5r 1/1 Running 0 70s
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 46m
</syntaxhighlight>

Hinweis: Wie Sie sehen, gibt es so viele "kube-flannel"- und "kube-proxy"-Pods/Container, wie wir Knoten in unserem Cluster haben.

== Einsatz eines ersten Pods ==

Wir werden unsere erste [https://kubernetes.io/docs/concepts/workloads/pods/pod/ pod] in unserem Kubernetes-Cluster.

Der Einfachheit halber entscheiden wir uns für die Bereitstellung eines Pods (ohne Replikate) mit dem Namen "nginx" und dem Image "nginx":

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
</syntaxhighlight>

Wenn wir nachsehen, erscheint dieser auch bei der Rückkehr des Befehls, der die Pods unseres Clusters auflistet:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-55bd7c9fd-5bghl 1/1 Running 0 104s
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 57m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 57m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 13m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 17m
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 12m
kube-system kube-proxy-8r7wg 1/1 Running 0 13m
kube-system kube-proxy-h94bs 1/1 Running 0 57m
kube-system kube-proxy-m2f5r 1/1 Running 0 12m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 57m
</syntaxhighlight>

Es erscheint am Anfang der Liste in einem anderen Namensraum als "kube-system", da es sich nicht um eine für den Betrieb von Kubernetes spezifische Komponente handelt.

Es ist auch möglich, die Anzeige von Pods, die für den kube-system-Namensraum spezifisch sind, zu vermeiden, indem man denselben Befehl ohne den Parameter "--all-namespace" ausführt:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 3d2h
</syntaxhighlight>

So zeigen Sie die Beschriftungen an:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-55bd7c9fd-ckltn 1/1 Running 0 8m2s app=nginx,pod-template-hash=55bd7c9fd
</syntaxhighlight>

Wir können unsere Bereitstellungen auch mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 93m
</syntaxhighlight>

Wir haben also einen Nginx-Pod eingerichtet und gestartet, aber er ist noch nicht von außen zugänglich. Um ihn von außen zugänglich zu machen, müssen wir den Port unseres Pods offenlegen, indem wir den Dienst (vom Typ NodePort) mit dem folgenden Befehl erstellen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
</syntaxhighlight>

So entsteht unser Service:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 147m
nginx NodePort 10.108.251.178 <none> 80:30566/TCP 20s
</syntaxhighlight>

Hinweis: Er lauscht auf Port 80/tcp und ist von außen über Port 30566/tcp erreichbar/offenbar.

Wir können die Flannel-IP unseres Pods und den Namen des Knotens, auf dem er gerade läuft, mit dem folgenden Befehl abrufen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 174m 10.244.2.2 k8s-worker02.cs437cloud.internal <none>
</syntaxhighlight>

Hier hat unser nginx-Pod die IP 10.244.2.2 und läuft auf unserem Knoten k8s-worker02.

Sie können auch einfach einen Befehl ausführen oder eine Shell auf unserem nginx-Pod über den folgenden Befehl öffnen (sehr ähnlich wie der Docker-Befehl):

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
</syntaxhighlight>

Alles, was Sie tun müssen, ist Ihre Lastausgleichsregel in Ihrem Ikoula One Cloud-Netzwerk zu erstellen, um auf Ihren Webserver (nginx pod) zuzugreifen bzw. ihn zu veröffentlichen:

- Verbinden Sie mit dem [https://cloudstack.ikoula.com/client Wolke Ikoula Eins]

- Gehen Sie auf "Netzwerk" im linken vertikalen Menü

- Klicken Sie auf Ihr Netzwerk, in dem Sie Ihre Kubernetes-Instanzen eingerichtet haben, dann auf "IP-Adressen anzeigen" und auf Ihre NAT-Quell-IP und gehen Sie auf die Registerkarte "Konfiguration".

- klicken Sie auf "Load Balancing" und erstellen Sie Ihre Regel, indem Sie einen Namen angeben, den öffentlichen Port "80" in unserem Fall, den privaten Port "30566" in unserem Fall (siehe oben), indem Sie einen LB-Algorithmus wählen (z.B. Round-Robin) wie :

[[File:faq_k8s_regle_lb-01.png|Kubernetes-Instanz]]

- alle Ihre Arbeitsinstanzen ankreuzen:

[[File:faq_k8s_regle_lb-02.png|Überprüfen Sie Ihre Kubernetes-Arbeitsinstanzen]]

Testen Sie den Zugriff auf Ihren Webserver/Nginx-Pod von Ihrem Browser aus (über die öffentliche IP Ihres Netzwerks, in dem Sie die LB-Regel erstellt haben):

[[File:faq_k8s_browser_nginx.png|Zugang zu Ihrem Webserver]]

Die Tatsache, dass Ihr nginx-Pod von jedem Ihrer Knoten aus zugänglich ist, wird durch die Komponente "kube-proxy" ermöglicht, die für die Weiterleitung von Verbindungen zu dem/den Knoten verantwortlich ist, auf dem/denen sie läuft (im Falle von Replikaten).

Sie haben also gerade einen einfachen Kubernetes-Cluster mit 3 Knoten, einem Master und zwei Workern eingerichtet.

== Weiter gehen ==

Sie können noch weiter gehen, indem Sie das Kubernetes-Dashboard einsetzen oder persistente Volumes für Ihre Pods erstellen, die Anzahl Ihrer Worker-Nodes erhöhen oder sogar die Master-Rolle redundant zuweisen, um eine hohe Verfügbarkeit zu gewährleisten, oder indem Sie Nodes für bestimmte Komponenten wie z. B. Etcd reservieren.

Hier sind einige nützliche Links:

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Docker]]
[[Category:CoreOS]]
[[Category:Wolke]]

Bereitstellen eines Kubernetes-Clusters

2021-07-29T13:54:34Z

Ikbot: Die Seite wurde neu angelegt: „:fr:Deployer un clust…“

[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Array|hier]] ansehen. 
[[:nl:Een Kubernetes cluster implementeren]][[nl:Een Kubernetes cluster implementeren]]
[[:pt:Implantação de um aglomerado Kubernetes]][[pt:Implantação de um aglomerado Kubernetes]]
[[:es:Despliegue de un clúster Kubernetes]][[es:Despliegue de un clúster Kubernetes]]
[[:en:Deploying a Kubernetes cluster]][[en:Deploying a Kubernetes cluster]]
[[:it:Configurare un cluster Kubernetes]][[it:Configurare un cluster Kubernetes]]
[[:fr:Deployer un cluster Kubernetes]][[fr:Deployer un cluster Kubernetes]]

{{#seo:
|title=kubernetes Installation
|titlemode=replace
|keywords=ikoula wiki, ikoula wiki, ikoula Wissensbasis, kubernetes ist was, kubernetes installation, kubernetes tutorial
|description=Kubernetes kann als eine Container-Plattform, eine Microservices-Plattform, eine portable Cloud-Plattform und vieles mehr betrachtet werden... Finden Sie heraus, wie man es installiert.
|og:type=article
|og:image=https://fr-wiki.ikoula.com/resources/assets/logo_ikwiki.png
}}

==Was ist Kubernetes?==

'''Kubernetes''' ist eine Open-Source-Plattform für die Verwaltung von containerisierten Arbeitslasten und Diensten.
Es unterstützt die deklarative Konfigurationserstellung, aber auch die Automatisierung. ''Kubernetes'' ist ein großes und schnell wachsendes Ökosystem.

Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster einrichten [https://www.ikoula.com/fr/cloud-public/oneclick Kubernetes (k8s)] Mit diesem Verfahren können Sie schnell und einfach einen Drei-Knoten-Cluster aus drei CentOS 7-Instanzen einrichten, die innerhalb desselben Netzwerks in einer Forward Zone installiert sind.

Eine dieser drei Instanzen wird unser Masterknoten sein, die anderen beiden werden unsere Arbeitsknoten sein. Zusammenfassend lässt sich sagen, dass der Master-Knoten der Knoten ist, von dem aus wir den Kubernetes-Cluster (Container-Orchestrator) über seine API verwalten, und die Worker-Knoten die Knoten sind, auf denen die Pods oder Container (in unserem Fall Docker) ausgeführt werden.

Wir gehen davon aus, dass Ihre 3 CentOS 7-Instanzen bereits eingerichtet sind und dass Sie per ssh Zugriff auf sie haben, um die folgenden Befehle auszuführen.

Hier ist die Konfiguration, die wir in unserem Beispiel haben und die in diesem Verfahren als Beispiel verwendet wird:

Knotenmaster: "k8s-master" / 10.1.1.16 
Erster Arbeitsknoten: "k8s-worker01" / 10.1.1.169 
Zweiter Arbeitsknoten: "k8s-worker02" / 10.1.1.87 

== Tutorial zur Systemvorbereitung und Kubernetes-Installation ==

Die folgenden Aktionen müssen auf allen Instanzen (Master und Worker) als root (oder mit den erforderlichen sudo-Rechten) durchgeführt werden.

Beginnen Sie damit, die Datei /etc/hosts auf jeder Ihrer Instanzen aufzufüllen, so dass sie ihren jeweiligen Hostnamen auflösen können (normalerweise ist dies in einem erweiterten Zonennetzwerk, in dem der virtuelle Router ein DNS-Auflöser ist, bereits der Fall).

In unserem Beispiel ergibt dies die folgende /etc/hosts Datei auf unseren drei Instanzen (passen Sie sie mit dem Namen und der IP Ihrer Instanzen an):

<syntaxhighlight lang="bash">
cat /etc/hosts
127.0.0.1 localhost
::1 localhost

10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02
</syntaxhighlight>

Aktivieren Sie das Bridge-Modul und die iptables-Regeln für dieses Modul mit den folgenden drei Befehlen:

<syntaxhighlight lang="bash">
modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
</syntaxhighlight>

Fügen Sie das YUM-Docker-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF
</syntaxhighlight>

Fügen Sie das YUM-Kubernetes-Repository hinzu:

<syntaxhighlight lang="bash">
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
</syntaxhighlight>

Docker installieren :

<syntaxhighlight lang="bash">
yum install -y docker-ce
</syntaxhighlight>

Installieren Sie dann die erforderlichen Kubernetes-Pakete:

<syntaxhighlight lang="bash">
yum install -y kubeadm kubelet kubectl
</syntaxhighlight>

Bearbeiten Sie die Konfigurationsdatei des systemd kubelet (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) Konfigurationsdatei die folgende Zeile in den Abschnitt "[Service]" ein:

<pre>
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"
</pre>

derart, dass :

<pre>
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
*Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"*
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
</pre>

Laden Sie die Konfiguration neu, aktivieren Sie die Docker- und Kubelet-Dienste und starten Sie sie dann mit den folgenden drei Befehlen:

systemctl daemon-reload
systemctl enable docker kubelet
systemctl start docker kubelet
</syntaxhighlight>

Deaktivieren Sie den System-Swap (kubelet unterstützt keinen Swap-Speicher, Sie erhalten eine Fehlermeldung während der Pre-Flight Checks bei der Initialisierung Ihres Clusters über kubeadms, wenn Sie ihn nicht deaktivieren):

<syntaxhighlight lang="bash">
swapoff -a
</syntaxhighlight>

Bitte denken Sie daran, auch die Swap-Zeile in der /etc/fstab Datei jeder Ihrer Instanzen zu kommentieren/entfernen, wie z.B. :

<pre>
#/dev/mapper/vg01-swap swap swap defaults 0 0
</pre>

== Initialisierung des Kubernetes-Clusters ==

Die folgenden Aktionen dürfen nur auf der Node-Master-Instanz durchgeführt werden

Starten Sie die Initialisierung Ihres Kubernetes-Clusters mit dem unten stehenden Befehl. Achten Sie darauf, den Wert des Parameters "--apiserver-advertise-address=" durch die IP-Adresse Ihrer Master-Instanz zu ändern.

<syntaxhighlight lang="bash">
kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16
</syntaxhighlight>

Hinweis: Bitte ändern Sie die im Parameter "--pod-network-cidr=" angegebene Netzwerk-IP "10.244.0.0/16" nicht, da dieser Parameter angibt, dass wir das CNI Flannel-Plugin zur Verwaltung des Netzwerkteils unserer Pods verwenden werden.

So sollte die Rückgabe dieses Befehls aussehen, wenn der Cluster erfolgreich initialisiert wurde:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
</syntaxhighlight>

Wir führen die geforderten Operationen durch, um die Initialisierung unseres Clusters abzuschließen:

Wir erstellen ein Verzeichnis und eine Konfigurationsdatei in dem Verzeichnis unseres Benutzers (in unserem Fall root):

<syntaxhighlight lang="bash">
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
</syntaxhighlight>

Wir stellen unser Pod-Flannel-Netzwerk für unseren Cluster bereit:

<syntaxhighlight lang="bash">
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
</syntaxhighlight>

Hinweis: Wir werden den letzten Befehl, der durch die Rückgabe des Seiteninitialisierungsbefehls ("kubeadm join...") bereitgestellt wird, behalten, um ihn später auf unseren Worker-Instanzen auszuführen, um sie in unseren Cluster einzubinden.

Wir können nun die ersten Prüfungen unseres Clusters von unserer Master-Instanz aus durchführen:

Geben Sie den Befehl "kubectl get nodes" ein, um die derzeit in Ihrem Cluster vorhandenen Knoten zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 41m v1.12.2
</syntaxhighlight>

Hinweis: Derzeit gibt es nur Ihren Masterknoten, was normal ist, da wir die anderen Knoten noch nicht zum Cluster hinzugefügt haben.

Geben Sie den Befehl "kubectl get pods --all-namespaces" ein, um die derzeit in Ihrem Cluster vorhandenen Pods/Container zu überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 41m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 41m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 41m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 84s
kube-system kube-proxy-h94bs 1/1 Running 0 41m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 40m
</syntaxhighlight>

Hinweis: Es gibt nur Pods, die den Kubernetes-Komponenten entsprechen, die für unseren Master-Knoten benötigt werden (kube-apiserver, etcd, kube-scheduler, etc.).

Wir können den Status dieser Komponenten mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
</syntaxhighlight>

== Hinzufügen von Arbeitsknoten zum Cluster ==

Aktionen, die nur auf Arbeitsinstanzen/Knoten ausgeführt werden

Führen Sie auf jeder Ihrer Worker-Instanzen (nicht auf Ihrer Master-Instanz) den Befehl "kubeadm join ..." aus, der am Ende der obigen Cluster-Initialisierung angegeben ist:

<syntaxhighlight lang="bash">
[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

<syntaxhighlight lang="bash">
[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
[WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.
</syntaxhighlight>

== Überprüfung des Status des Clusters ==

Von der Master-Instanz/dem Master-Knoten auszuführende Aktionen

Überprüfen Sie, ob Ihre Arbeitsknoten Ihrem Cluster hinzugefügt wurden, indem Sie den Befehl "kubectl get nodes" erneut ausführen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master.cs437cloud.internal Ready master 46m v1.12.2
k8s-worker01.cs437cloud.internal Ready <none> 103s v1.12.2
k8s-worker02.cs437cloud.internal Ready <none> 48s v1.12.2
</syntaxhighlight>

Bemerkung: Wir können unsere beiden Arbeiterknoten (k8s-worker01 und k8s-worker02) sehen, sie wurden also zu unserem Cluster hinzugefügt.

Führen wir nun erneut den Befehl "kubectl get pods --all-namespaces" aus:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 46m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 46m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 46m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 2m6s
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 6m31s
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 70s
kube-system kube-proxy-8r7wg 1/1 Running 0 2m6s
kube-system kube-proxy-h94bs 1/1 Running 0 46m
kube-system kube-proxy-m2f5r 1/1 Running 0 70s
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 46m
</syntaxhighlight>

Hinweis: Wie Sie sehen, gibt es so viele "kube-flannel"- und "kube-proxy"-Pods/Container, wie wir Knoten in unserem Cluster haben.

== Einsatz eines ersten Pods ==

Wir werden unsere erste [https://kubernetes.io/docs/concepts/workloads/pods/pod/ pod] in unserem Kubernetes-Cluster.

Der Einfachheit halber entscheiden wir uns für die Bereitstellung eines Pods (ohne Replikate) mit dem Namen "nginx" und dem Image "nginx":

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
</syntaxhighlight>

Wenn wir nachsehen, erscheint dieser auch bei der Rückkehr des Befehls, der die Pods unseres Clusters auflistet:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-55bd7c9fd-5bghl 1/1 Running 0 104s
kube-system coredns-576cbf47c7-fwxj9 1/1 Running 0 57m
kube-system coredns-576cbf47c7-t86s9 1/1 Running 0 57m
kube-system etcd-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-apiserver-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-controller-manager-k8s-master.cs437cloud.internal 1/1 Running 0 57m
kube-system kube-flannel-ds-amd64-724nl 1/1 Running 0 13m
kube-system kube-flannel-ds-amd64-wcm7v 1/1 Running 0 17m
kube-system kube-flannel-ds-amd64-z7mwg 1/1 Running 3 12m
kube-system kube-proxy-8r7wg 1/1 Running 0 13m
kube-system kube-proxy-h94bs 1/1 Running 0 57m
kube-system kube-proxy-m2f5r 1/1 Running 0 12m
kube-system kube-scheduler-k8s-master.cs437cloud.internal 1/1 Running 0 57m
</syntaxhighlight>

Es erscheint am Anfang der Liste in einem anderen Namensraum als "kube-system", da es sich nicht um eine für den Betrieb von Kubernetes spezifische Komponente handelt.

Es ist auch möglich, die Anzeige von Pods, die für den kube-system-Namensraum spezifisch sind, zu vermeiden, indem man denselben Befehl ohne den Parameter "--all-namespace" ausführt:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 3d2h
</syntaxhighlight>

So zeigen Sie die Beschriftungen an:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-55bd7c9fd-ckltn 1/1 Running 0 8m2s app=nginx,pod-template-hash=55bd7c9fd
</syntaxhighlight>

Wir können unsere Bereitstellungen auch mit dem folgenden Befehl überprüfen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 1 1 1 1 93m
</syntaxhighlight>

Wir haben also einen Nginx-Pod eingerichtet und gestartet, aber er ist noch nicht von außen zugänglich. Um ihn von außen zugänglich zu machen, müssen wir den Port unseres Pods offenlegen, indem wir den Dienst (vom Typ NodePort) mit dem folgenden Befehl erstellen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created
</syntaxhighlight>

So entsteht unser Service:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 147m
nginx NodePort 10.108.251.178 <none> 80:30566/TCP 20s
</syntaxhighlight>

Hinweis: Er lauscht auf Port 80/tcp und ist von außen über Port 30566/tcp erreichbar/offenbar.

Wir können die Flannel-IP unseres Pods und den Namen des Knotens, auf dem er gerade läuft, mit dem folgenden Befehl abrufen:

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-55bd7c9fd-vs4fq 1/1 Running 0 174m 10.244.2.2 k8s-worker02.cs437cloud.internal <none>
</syntaxhighlight>

Hier hat unser nginx-Pod die IP 10.244.2.2 und läuft auf unserem Knoten k8s-worker02.

Sie können auch einfach einen Befehl ausführen oder eine Shell auf unserem nginx-Pod über den folgenden Befehl öffnen (sehr ähnlich wie der Docker-Befehl):

<syntaxhighlight lang="bash">
[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#
</syntaxhighlight>

Alles, was Sie tun müssen, ist Ihre Lastausgleichsregel in Ihrem Ikoula One Cloud-Netzwerk zu erstellen, um auf Ihren Webserver (nginx pod) zuzugreifen bzw. ihn zu veröffentlichen:

- Verbinden Sie mit dem [https://cloudstack.ikoula.com/client Wolke Ikoula Eins]

- Gehen Sie auf "Netzwerk" im linken vertikalen Menü

- Klicken Sie auf Ihr Netzwerk, in dem Sie Ihre Kubernetes-Instanzen eingerichtet haben, dann auf "IP-Adressen anzeigen" und auf Ihre NAT-Quell-IP und gehen Sie auf die Registerkarte "Konfiguration".

- klicken Sie auf "Load Balancing" und erstellen Sie Ihre Regel, indem Sie einen Namen angeben, den öffentlichen Port "80" in unserem Fall, den privaten Port "30566" in unserem Fall (siehe oben), indem Sie einen LB-Algorithmus wählen (z.B. Round-Robin) wie :

[[File:faq_k8s_regle_lb-01.png|Kubernetes-Instanz]]

- alle Ihre Arbeitsinstanzen ankreuzen:

[[File:faq_k8s_regle_lb-02.png|Überprüfen Sie Ihre Kubernetes-Arbeitsinstanzen]]

Testen Sie den Zugriff auf Ihren Webserver/Nginx-Pod von Ihrem Browser aus (über die öffentliche IP Ihres Netzwerks, in dem Sie die LB-Regel erstellt haben):

[[File:faq_k8s_browser_nginx.png|Zugang zu Ihrem Webserver]]

Die Tatsache, dass Ihr nginx-Pod von jedem Ihrer Knoten aus zugänglich ist, wird durch die Komponente "kube-proxy" ermöglicht, die für die Weiterleitung von Verbindungen zu dem/den Knoten verantwortlich ist, auf dem/denen sie läuft (im Falle von Replikaten).

Sie haben also gerade einen einfachen Kubernetes-Cluster mit 3 Knoten, einem Master und zwei Workern eingerichtet.

== Weiter gehen ==

Sie können noch weiter gehen, indem Sie das Kubernetes-Dashboard einsetzen oder persistente Volumes für Ihre Pods erstellen, die Anzahl Ihrer Worker-Nodes erhöhen oder sogar die Master-Rolle redundant zuweisen, um eine hohe Verfügbarkeit zu gewährleisten, oder indem Sie Nodes für bestimmte Komponenten wie z. B. Etcd reservieren.

Hier sind einige nützliche Links:

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

[[Category:Wolkenstapel]]
[[Category:öffentliche Wolke]]
[[Category:private Cloud]]
[[Category:Docker]]
[[Category:CoreOS]]
[[Category:Wolke]]

Bereitstellen einer Instanz in einer Zone mit direkter Weiterleitung

2021-07-29T13:32:32Z

Ikbot:

[[:ro:Implementarea unei instanțe într-o zonă de rutare directă]][[ro:Implementarea unei instanțe într-o zonă de rutare directă]]
[[:ru:Развертывание экземпляра в зоне прямой маршрутизации]][[ru:Развертывание экземпляра в зоне прямой маршрутизации]]
[[:pl:Wdrażanie instancji w strefie bezpośredniego routingu]][[pl:Wdrażanie instancji w strefie bezpośredniego routingu]]
[[:ja:ダイレクトルーティング・ゾーンにインスタンスを配置する]][[ja:ダイレクトルーティング・ゾーンにインスタンスを配置する]]
[[:zh:在直接路由区部署一个实例]][[zh:在直接路由区部署一个实例]]
[[:fr:Deploiement d'une instance en zone direct-routing]][[fr:Deploiement d'une instance en zone direct-routing]]
 Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle [[:fr:Deploiement d'une instance en zone direct-routing|hier]] ansehen. 
[[:nl:Een instantie implementeren in een direct-routing zone]][[nl:Een instantie implementeren in een direct-routing zone]]
[[:it:Distribuire un'istanza in una zona a instradamento diretto]][[it:Distribuire un'istanza in una zona a instradamento diretto]]
[[:pt:Implantação de uma instância numa zona de encaminhamento directo]][[pt:Implantação de uma instância numa zona de encaminhamento directo]]
[[:es:Despliegue de una instancia en una zona de enrutamiento directo]][[es:Despliegue de una instancia en una zona de enrutamiento directo]]
[[:en:Deploying an instance in a direct-routing zone]][[en:Deploying an instance in a direct-routing zone]]
#REDIRECTION [[Deploiement d'une instance en zone basic (cliquez pour lire la suite)]]