Merge steps 2 & 3
This commit is contained in:
parent
8abec325d5
commit
44c01be37d
@ -29,9 +29,8 @@ cd config
|
|||||||
# A lancer avec l'utilisateur root !
|
# A lancer avec l'utilisateur root !
|
||||||
sudo ./scripts/0.start_dls.sh # Démarrage du serveur DLS
|
sudo ./scripts/0.start_dls.sh # Démarrage du serveur DLS
|
||||||
sudo ./scripts/1.qemu.sh # Démarrage de la ou des VMs et du cluster
|
sudo ./scripts/1.qemu.sh # Démarrage de la ou des VMs et du cluster
|
||||||
# A lancer avec votre utilisateur local
|
# A lancer avec votre utilisateur local de préférence
|
||||||
./scripts/2.start_k8s.sh # Création du control plane
|
./scripts/2.first_start_k8s.sh # Création du control plane et installation des additions
|
||||||
./scripts/3.install_addons.sh # Installation des additions
|
|
||||||
|
|
||||||
mkdir -p ~/.kube
|
mkdir -p ~/.kube
|
||||||
cp secrets/kubeconfig ~/.kube/config
|
cp secrets/kubeconfig ~/.kube/config
|
||||||
@ -100,7 +99,7 @@ Dans tous les cas, il n'est nécessaire de faire cette opération qu'une seule f
|
|||||||
{{< tabs >}}
|
{{< tabs >}}
|
||||||
{{% tab name="Automatisée" %}}
|
{{% tab name="Automatisée" %}}
|
||||||
```bash
|
```bash
|
||||||
./scripts/2.start_k8s.sh
|
./scripts/2.first_start_k8s.sh
|
||||||
```
|
```
|
||||||
{{% /tab %}}
|
{{% /tab %}}
|
||||||
{{% tab name="Manuel" %}}
|
{{% tab name="Manuel" %}}
|
||||||
@ -113,16 +112,9 @@ mv /etc/kubernetes/manifests.static/* /var/lib/kubernetes/manifests/
|
|||||||
{{% /tab %}}
|
{{% /tab %}}
|
||||||
{{< /tabs >}}
|
{{< /tabs >}}
|
||||||
|
|
||||||
|
Cette étape sert également à la mise en place des addons. Dans les addons devant être installés dans le cluster, nous pouvons citer un fournisseur d'overlay réseau, kube-proxy, un contrôleur ingress, un dashboard, un coredns local, etc...
|
||||||
|
|
||||||
## Configuration des additions
|
Enfin, un cluster kubernetes sécurisé et fonctionnel nécessite des certificats TLS pour toute communication intra-cluster. Ce rôle de les générer est à majorité celui du DLS, à l'exception de deux certificats, tous deux utilisés par le processus Kubelet de la machine nouvellement installés (voir [TLS Bootstraping](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)). Ceux-là sont générés automatiquement au sein de Kubernetes mais nécessitent une approbation manuelle, ce qui est géré par ce script par facilité.
|
||||||
|
|
||||||
{{< highlight bash >}}
|
|
||||||
./scripts/3.install_addons.sh
|
|
||||||
{{< /highlight >}}
|
|
||||||
|
|
||||||
Dans les addons devant être installés dans le cluster, nous pouvons citer un fournisseur d'overlay réseau, kube-proxy, un contrôleur ingress, un dashboard, un coredns local, etc...
|
|
||||||
|
|
||||||
Un cluster kubernetes sécurisé et fonctionnel nécessite des certificats TLS pour toute communication intra-cluster. Ce rôle de les générer est à majorité celui du DLS, à l'exception de deux certificats, tous deux utilisés par le processus Kubelet de la machine nouvellement installés (voir [TLS Bootstraping](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)). Ceux-là sont générés automatiquement au sein de Kubernetes mais nécessitent une approbation manuelle, ce qui est géré par ce script par facilité.
|
|
||||||
|
|
||||||
## Utilisation du cluster
|
## Utilisation du cluster
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user