Split discover to avoid link to virli.nemunai.re
This commit is contained in:
parent
96cf5dd08a
commit
f5b7f2d7a7
5 changed files with 71 additions and 70 deletions
|
|
@ -1,6 +1,6 @@
|
||||||
include ../pandoc-opts.mk
|
include ../pandoc-opts.mk
|
||||||
|
|
||||||
SOURCES_TUTO = tutorial-el.md setup.md intro-srs.md intro.md overview.md discover.md run.md run-cmd-virli.md run2.md scaling.md rendu.md
|
SOURCES_TUTO = tutorial-el.md setup.md intro-srs.md intro.md overview.md discover.md discover-cmd-virli.md discover2.md run.md run-cmd-virli.md run2.md scaling.md rendu.md
|
||||||
|
|
||||||
|
|
||||||
all: tutorial.pdf
|
all: tutorial.pdf
|
||||||
|
|
|
||||||
3
tutorial/k8s/discover-cmd-alpo.md
Normal file
3
tutorial/k8s/discover-cmd-alpo.md
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
```bash
|
||||||
|
kubectl create -f https://supplements.alpo.tf/493960009/insecure-dashboard.yaml
|
||||||
|
```
|
||||||
3
tutorial/k8s/discover-cmd-virli.md
Normal file
3
tutorial/k8s/discover-cmd-virli.md
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
```bash
|
||||||
|
kubectl create -f https://virli.nemunai.re/insecure-dashboard.yaml
|
||||||
|
```
|
||||||
|
|
@ -317,72 +317,3 @@ une interface web.
|
||||||
Ils mettent à disposition un fichier décrivant l'état d'un cluster ayant une
|
Ils mettent à disposition un fichier décrivant l'état d'un cluster ayant une
|
||||||
telle application. Nous pouvons demander à ce que notre cluster converge vers
|
telle application. Nous pouvons demander à ce que notre cluster converge vers
|
||||||
la configuration nécessaire :
|
la configuration nécessaire :
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl create -f https://virli.nemunai.re/insecure-dashboard.yaml
|
|
||||||
```
|
|
||||||
|
|
||||||
::::: {.warning}
|
|
||||||
|
|
||||||
Notez que le dashboard, avec cette configuration, va s'exécuter sans les
|
|
||||||
prérequis minimum de sécurité : pas de certificat TLS, ni
|
|
||||||
d'authentification. Ceci est juste pour jouer avec l'interface, en production,
|
|
||||||
on n'utilisera pas cette recette.
|
|
||||||
|
|
||||||
:::::
|
|
||||||
|
|
||||||
Regardons où nous pouvons contacter notre dashboard :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
$ kubectl get svc
|
|
||||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
|
||||||
dashboard NodePort 10.96.78.69 <none> 80:31505/TCP 3m10s
|
|
||||||
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6m51s
|
|
||||||
```
|
|
||||||
|
|
||||||
Regardons si cela répond :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
$ docker exec -it kind-control-plane curl 10.96.78.69:80
|
|
||||||
<p class="browsehappy">You are using an <strong>outdated</strong> browser.
|
|
||||||
```
|
|
||||||
|
|
||||||
Pas très sympa... il faudrait que l'on puisse le voir dans un navigateur plus
|
|
||||||
... moderne alors.
|
|
||||||
|
|
||||||
Étant donné que notre cluster ne se trouve pas directement sur notre machine,
|
|
||||||
mais dans différents conteneurs Docker, nous ne pouvons pas accéder à
|
|
||||||
`127.0.0.1`. Heureusement, au moment de la création de notre cluster avec
|
|
||||||
`kind`, nous avons renseigné plusieurs ports redirigés au sein de notre
|
|
||||||
configuration. Il va donc falloir indiquer à Kubernetes que l'on désire
|
|
||||||
utiliser un port spécifique pour exposer le tableau de bord.
|
|
||||||
|
|
||||||
Pour ce faire, éditons le fichier `insecure-dashboard.yaml`, pour ajouter, dans
|
|
||||||
la partie `Service` un *node port* plus spécifique :
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
- port: 80
|
|
||||||
protocol: TCP
|
|
||||||
targetPort: 80
|
|
||||||
nodePort: 30002
|
|
||||||
```
|
|
||||||
|
|
||||||
Maintenant, nous n'allons pas recréer un nouveau dashboard : nous allons
|
|
||||||
simplement « appliquer » la nouvelle configuration :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
kubectl apply -f my-insecure-dashboard.yaml
|
|
||||||
```
|
|
||||||
|
|
||||||
En voyant la divergence entre la réalité et la configuration demandée,
|
|
||||||
Kubernetes va tout mettre en œuvre pour se conformer à nos directives. En
|
|
||||||
l'occurrence, il s'agit de changer le port qui expose le service au sein du
|
|
||||||
cluster.
|
|
||||||
|
|
||||||
En fait, on pourra faire exactement la même chose lors d'un changement de
|
|
||||||
version. Kubernetes verra la différence et appliquera une politique de
|
|
||||||
migration déterminée.
|
|
||||||
|
|
||||||
Une fois que c'est fait, nous pouvons fièrement utiliser notre navigateur pour
|
|
||||||
aller sur <http://localhost:30002/> (vous pouvez *Skip* l'authentification,
|
|
||||||
dans cette configuration d'exemple, elle n'est pas nécessaire).
|
|
||||||
|
|
|
||||||
64
tutorial/k8s/discover2.md
Normal file
64
tutorial/k8s/discover2.md
Normal file
|
|
@ -0,0 +1,64 @@
|
||||||
|
::::: {.warning}
|
||||||
|
|
||||||
|
Notez que le dashboard, avec cette configuration, va s'exécuter sans les
|
||||||
|
prérequis minimum de sécurité : pas de certificat TLS, ni
|
||||||
|
d'authentification. Ceci est juste pour jouer avec l'interface, en production,
|
||||||
|
on n'utilisera pas cette recette.
|
||||||
|
|
||||||
|
:::::
|
||||||
|
|
||||||
|
Regardons où nous pouvons contacter notre dashboard :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ kubectl get svc
|
||||||
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||||
|
dashboard NodePort 10.96.78.69 <none> 80:31505/TCP 3m10s
|
||||||
|
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6m51s
|
||||||
|
```
|
||||||
|
|
||||||
|
Regardons si cela répond :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ docker exec -it kind-control-plane curl 10.96.78.69:80
|
||||||
|
<p class="browsehappy">You are using an <strong>outdated</strong> browser.
|
||||||
|
```
|
||||||
|
|
||||||
|
Pas très sympa... il faudrait que l'on puisse le voir dans un navigateur plus
|
||||||
|
... moderne alors.
|
||||||
|
|
||||||
|
Étant donné que notre cluster ne se trouve pas directement sur notre machine,
|
||||||
|
mais dans différents conteneurs Docker, nous ne pouvons pas accéder à
|
||||||
|
`127.0.0.1`. Heureusement, au moment de la création de notre cluster avec
|
||||||
|
`kind`, nous avons renseigné plusieurs ports redirigés au sein de notre
|
||||||
|
configuration. Il va donc falloir indiquer à Kubernetes que l'on désire
|
||||||
|
utiliser un port spécifique pour exposer le tableau de bord.
|
||||||
|
|
||||||
|
Pour ce faire, éditons le fichier `insecure-dashboard.yaml`, pour ajouter, dans
|
||||||
|
la partie `Service` un *node port* plus spécifique :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
- port: 80
|
||||||
|
protocol: TCP
|
||||||
|
targetPort: 80
|
||||||
|
nodePort: 30002
|
||||||
|
```
|
||||||
|
|
||||||
|
Maintenant, nous n'allons pas recréer un nouveau dashboard : nous allons
|
||||||
|
simplement « appliquer » la nouvelle configuration :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
kubectl apply -f my-insecure-dashboard.yaml
|
||||||
|
```
|
||||||
|
|
||||||
|
En voyant la divergence entre la réalité et la configuration demandée,
|
||||||
|
Kubernetes va tout mettre en œuvre pour se conformer à nos directives. En
|
||||||
|
l'occurrence, il s'agit de changer le port qui expose le service au sein du
|
||||||
|
cluster.
|
||||||
|
|
||||||
|
En fait, on pourra faire exactement la même chose lors d'un changement de
|
||||||
|
version. Kubernetes verra la différence et appliquera une politique de
|
||||||
|
migration déterminée.
|
||||||
|
|
||||||
|
Une fois que c'est fait, nous pouvons fièrement utiliser notre navigateur pour
|
||||||
|
aller sur <http://localhost:30002/> (vous pouvez *Skip* l'authentification,
|
||||||
|
dans cette configuration d'exemple, elle n'est pas nécessaire).
|
||||||
Loading…
Add table
Add a link
Reference in a new issue