Merge pull request #42010 from k0rventen/fr-tasks-access-application-cluster
[fr] translate tasks from section "access-application-cluster"pull/42040/head
Kubernetes Prow Robot
GitHub
commit
e41fc6e829
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Selector
|
||||
id: selector
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/working-with-objects/labels/
|
||||
short_description: >
|
||||
Permet aux utilisateurs de filtrer une liste de ressources en fonction de labels.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Permet aux utilisateurs de filtrer une liste de ressources en fonction de {{< glossary_tooltip text="labels" term_id="label" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Les sélecteurs sont appliqués lors de la requête de listes de ressources pour les filtrer par labels.
|
||||
|
|
@ -0,0 +1,215 @@
|
|||
---
|
||||
title: Connecter un Frontend à un Backend en utilisant les Services
|
||||
content_type: tutorial
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
Cette tâche montre comment créer un microservice _frontend_ et un microservice _backend_.
|
||||
Le backend renvoie un message de salutations à chaque requête.
|
||||
Le frontend expose le backend en utilisant Nginx et un {{< glossary_tooltip term_id="service" >}} Kubernetes.
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* Créer et exécuter un microservice backend `hello` en utilisant un {{< glossary_tooltip term_id="deployment" >}}.
|
||||
* Utiliser un Service pour envoyer du trafic vers les multiples réplicas du microservice backend.
|
||||
* Créer et exécuter un microservice frontend `nginx`, en utilisant également un Deployment.
|
||||
* Configurer le microservice frontend pour envoyer du trafic vers le microservice backend.
|
||||
* Utiliser un Service de type `LoadBalancer` pour exposer le microservice frontend en dehors du cluster.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
Cette tâche utilise les [Services avec des équilibreurs de charge externes](/docs/tasks/access-application-cluster/create-external-load-balancer/),
|
||||
qui nécessitent un environnement spécifique.
|
||||
Si votre environnement ne prend pas en charge cette fonction, vous pouvez utiliser un Service de type
|
||||
[NodePort](/docs/concepts/services-networking/service/#type-nodeport) à la place.
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## Création du backend à l'aide d'un Deployment
|
||||
|
||||
Le backend est un simple microservice de salutations.
|
||||
Voici le fichier de configuration pour le Deployment backend :
|
||||
|
||||
{{< codenew file="service/access/backend-deployment.yaml" >}}
|
||||
|
||||
Créez le Deployment backend :
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml
|
||||
```
|
||||
|
||||
Affichez les informations du Deployment:
|
||||
|
||||
```shell
|
||||
kubectl describe deployment backend
|
||||
```
|
||||
|
||||
Le retour sera similaire à celui-ci:
|
||||
|
||||
```
|
||||
Name: backend
|
||||
Namespace: default
|
||||
CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
|
||||
Labels: app=hello
|
||||
tier=backend
|
||||
track=stable
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=hello,tier=backend,track=stable
|
||||
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 1 max unavailable, 1 max surge
|
||||
Pod Template:
|
||||
Labels: app=hello
|
||||
tier=backend
|
||||
track=stable
|
||||
Containers:
|
||||
hello:
|
||||
Image: "gcr.io/google-samples/hello-go-gke:1.0"
|
||||
Port: 80/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: hello-3621623197 (3/3 replicas created)
|
||||
Events:
|
||||
...
|
||||
```
|
||||
## Création du Service `hello`
|
||||
|
||||
La solution pour envoyer des requêtes d'un frontend vers un backend est le Service `backend`.
|
||||
Un Service crée une adresse IP persistante et un enregistrement DNS afin que le microservice backend puisse toujours être joignable.
|
||||
Un Service utilise des {{< glossary_tooltip text="sélecteurs" term_id="selector" >}} pour trouver les Pods vers lesquels acheminer le trafic.
|
||||
|
||||
Tout d'abord, explorez le fichier de configuration du Service :
|
||||
|
||||
{{< codenew file="service/access/backend-service.yaml" >}}
|
||||
|
||||
Dans le fichier de configuration, vous pouvez voir que le Service,
|
||||
nommé `hello`, achemine le trafic vers les Pods ayant les labels `app: hello` et `tier: backend`.
|
||||
|
||||
Créez le Service backend :
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml
|
||||
```
|
||||
|
||||
À ce stade, vous avez un Deployment `backend` exécutant trois réplicas de votre application `hello`,
|
||||
et un Service capable d'acheminer le trafic vers celles-ci.
|
||||
Cependant, ce service n'est ni disponible, ni résolvable en dehors du cluster.
|
||||
|
||||
## Création du frontend
|
||||
|
||||
Maintenant que votre backend est opérationnel,
|
||||
vous pouvez créer un frontend accessible en dehors du cluster,
|
||||
qui se connecte au backend en acheminant les requêtes vers celui-ci.
|
||||
|
||||
Le frontend envoie des requêtes aux Pods du backend en utilisant le nom DNS attribué au Service backend.
|
||||
Le nom DNS est `hello`, qui est la valeur du champ `name`
|
||||
dans le fichier de configuration `examples/service/access/backend-service.yaml`.
|
||||
|
||||
Les Pods du frontend Deployment exécutent une image nginx
|
||||
configurée pour acheminer les requêtes vers le Service backend `hello`.
|
||||
Voici le fichier de configuration nginx :
|
||||
|
||||
{{< codenew file="service/access/frontend-nginx.conf" >}}
|
||||
|
||||
Comme pour le backend, le frontend dispose d'un Deployment et d'un Service.
|
||||
Une différence importante à noter entre les services backend et frontend est que
|
||||
le Service frontend est configuré avec un `type: LoadBalancer`, ce qui signifie que le Service utilise
|
||||
un équilibreur de charge provisionné par votre fournisseur de cloud et sera accessible depuis l'extérieur du cluster.
|
||||
|
||||
{{< codenew file="service/access/frontend-service.yaml" >}}
|
||||
|
||||
{{< codenew file="service/access/frontend-deployment.yaml" >}}
|
||||
|
||||
Créez le Deployment et le Service frontend :
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml
|
||||
```
|
||||
|
||||
Le retour valide la création des deux ressources:
|
||||
|
||||
```
|
||||
deployment.apps/frontend created
|
||||
service/frontend created
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
La configuration de nginx est présente dans
|
||||
[l'image du container](/examples/service/access/Dockerfile). Une meilleure approche serait
|
||||
d'utiliser une [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
|
||||
afin de pouvoir changer la configuration plus facilement.
|
||||
{{< /note >}}
|
||||
|
||||
## Interagir avec le Service frontend
|
||||
|
||||
Une fois que vous avez créé un Service de type LoadBalancer, vous pouvez utiliser cette commande pour trouver l'IP externe :
|
||||
|
||||
```shell
|
||||
kubectl get service frontend --watch
|
||||
```
|
||||
|
||||
Cela affiche la configuration du Service `frontend` et surveille les changements.
|
||||
Initialement, l'IP externe est indiquée comme `<pending>` :
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend LoadBalancer 10.51.252.116 <pending> 80/TCP 10s
|
||||
```
|
||||
|
||||
Dès qu'une IP externe est attribuée, cependant,
|
||||
la configuration est mise à jour pour inclure la nouvelle IP sous l'en-tête `EXTERNAL-IP` :
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend LoadBalancer 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m
|
||||
```
|
||||
|
||||
Cette IP peut maintenant être utilisée pour interagir avec le service `frontend` depuis l'extérieur du cluster.
|
||||
|
||||
## Envoyer du trafic via le frontend
|
||||
|
||||
Le frontend et le backend sont maintenant connectés.
|
||||
Vous pouvez accéder à l'endpoint en utilisant la commande curl sur l'IP externe de votre Service frontend.
|
||||
|
||||
```shell
|
||||
curl http://${EXTERNAL_IP} # à remplacer par l'ip externe affichée précédemment
|
||||
```
|
||||
|
||||
Le résultat affiche le message généré par le backend :
|
||||
|
||||
```json
|
||||
{"message":"Hello"}
|
||||
```
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
Pour supprimer les Services, saisissez cette commande :
|
||||
|
||||
```shell
|
||||
kubectl delete services frontend backend
|
||||
```
|
||||
|
||||
Pour supprimer les Deployments, les ReplicaSets et les Pods qui exécutent les applications backend et frontend,
|
||||
saisissez cette commande :
|
||||
|
||||
```shell
|
||||
kubectl delete deployment frontend backend
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* En savoir plus sur les [Services](/docs/concepts/services-networking/service/)
|
||||
* En savoir plus sur les [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
* En savoir plus sur le [DNS pour les Services et les Pods](/docs/concepts/services-networking/dns-pod-service/)
|
||||
|
|
@ -0,0 +1,209 @@
|
|||
---
|
||||
title: Utiliser le Port Forwarding pour accéder à des applications dans un cluster
|
||||
content_type: task
|
||||
weight: 40
|
||||
min-kubernetes-server-version: v1.10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Cette page montre comment utiliser `kubectl port-forward`
|
||||
pour se connecter à un serveur MongoDB s'exécutant dans un cluster Kubernetes.
|
||||
Ce type de connexion peut être utile pour le debug d'une base de données.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* Installez [MongoDB Shell](https://www.mongodb.com/try/download/shell).
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Création du déploiement et du service MongoDB
|
||||
|
||||
1. Créez un déploiement qui exécute MongoDB :
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
|
||||
```
|
||||
|
||||
Le résultat d'une commande réussie doit valider que le déploiement a bien été créé :
|
||||
|
||||
```
|
||||
deployment.apps/mongo créé
|
||||
```
|
||||
|
||||
Affichez l'état du pod pour vérifier qu'il est prêt :
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
Le résultat doit lister le pod créé :
|
||||
|
||||
```
|
||||
NOM PRÊT STATUT REDÉMARRAGES ÂGE
|
||||
mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s
|
||||
```
|
||||
|
||||
Affichez l'état du déploiement :
|
||||
|
||||
```shell
|
||||
kubectl get deployment
|
||||
```
|
||||
|
||||
Le résultat affiche que le déploiement a bien été créé :
|
||||
|
||||
```
|
||||
NOM PRÊT ACTUALISÉ DISPONIBLE ÂGE
|
||||
mongo 1/1 1 1 2m21s
|
||||
```
|
||||
|
||||
Le déploiement gère automatiquement un ReplicaSet. Affichez l'état du ReplicaSet à l'aide de la commande :
|
||||
|
||||
```shell
|
||||
kubectl get replicaset
|
||||
```
|
||||
|
||||
Le résultat affiche que le ReplicaSet a bien été créé :
|
||||
|
||||
```
|
||||
NOM DÉSIRÉ ACTUEL PRÊT ÂGE
|
||||
mongo-75f59d57f4 1 1 1 3m12s
|
||||
```
|
||||
|
||||
2. Créez un service pour exposer MongoDB sur le réseau :
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
|
||||
```
|
||||
|
||||
Le résultat d'une commande réussie vérifie que le service a été créé :
|
||||
|
||||
```
|
||||
service/mongo créé
|
||||
```
|
||||
|
||||
Vérifiez que le service a été créé :
|
||||
|
||||
```shell
|
||||
kubectl get service mongo
|
||||
```
|
||||
|
||||
Le résultat affiche le service qui vient d'être créé :
|
||||
|
||||
```
|
||||
NOM TYPE CLUSTER-IP EXTERNAL-IP PORT(S) ÂGE
|
||||
mongo ClusterIP 10.96.41.183 <none> 27017/TCP 11s
|
||||
```
|
||||
|
||||
3. Vérifiez que le serveur MongoDB s'exécute dans le pod et écoute sur le port 27017 :
|
||||
|
||||
```shell
|
||||
# Changez mongo-75f59d57f4-4nd6q par le nom du pod
|
||||
kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
||||
```
|
||||
|
||||
Le résultat affiche le port pour MongoDB dans ce pod :
|
||||
|
||||
```
|
||||
27017
|
||||
```
|
||||
|
||||
27017 est le port TCP attribué à MongoDB sur Internet.
|
||||
|
||||
## Rediriger un port local vers un port du pod
|
||||
|
||||
1. `kubectl port-forward` permet d'utiliser un nom de ressource, tel qu'un nom de pod, pour sélectionner un pod correspondant vers lequel rediriger le port.
|
||||
|
||||
```shell
|
||||
# Changez mongo-75f59d57f4-4nd6q par le nom du pod
|
||||
kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
|
||||
```
|
||||
|
||||
qui est identique à
|
||||
|
||||
```shell
|
||||
kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
|
||||
```
|
||||
|
||||
ou
|
||||
|
||||
```shell
|
||||
kubectl port-forward deployment/mongo 28015:27017
|
||||
```
|
||||
|
||||
ou
|
||||
|
||||
```shell
|
||||
kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
|
||||
```
|
||||
|
||||
ou
|
||||
|
||||
```shell
|
||||
kubectl port-forward service/mongo 28015:27017
|
||||
```
|
||||
|
||||
N'importe laquelle des commandes ci-dessus fonctionne. Le résultat sera similaire à ceci :
|
||||
|
||||
```
|
||||
Forwarding from 127.0.0.1:28015 -> 27017
|
||||
Forwarding from [::1]:28015 -> 27017
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl port-forward` ne se termine pas une fois le port-forward lancé. Pour continuer avec les exercices, vous devrez ouvrir un autre terminal.
|
||||
{{< /note >}}
|
||||
|
||||
2. Démarrez l'interface de ligne de commande MongoDB :
|
||||
|
||||
```shell
|
||||
mongosh --port 28015
|
||||
```
|
||||
|
||||
3. Depuis la ligne de commande de MongoDB, entrez la commande `ping` :
|
||||
|
||||
```
|
||||
db.runCommand( { ping: 1 } )
|
||||
```
|
||||
|
||||
Une demande de ping réussie renvoie :
|
||||
|
||||
```
|
||||
{ ok: 1 }
|
||||
```
|
||||
|
||||
### Laisser _kubectl_ choisir le port local {#let-kubectl-choose-local-port}
|
||||
|
||||
Si vous n'avez pas besoin d'un port local précis,
|
||||
vous pouvez laisser `kubectl` choisir et attribuer le port local,
|
||||
vous évitant ainsi de gérer les conflits de ports locaux, avec cette syntaxe légèrement plus simple :
|
||||
|
||||
```shell
|
||||
kubectl port-forward deployment/mongo :27017
|
||||
```
|
||||
|
||||
`kubectl` trouvera un numéro de port local qui n'est pas utilisé
|
||||
(en évitant les numéros de ports bas, car ils pourraient être utilisés par d'autres applications).
|
||||
Le résultat sera similaire à :
|
||||
|
||||
```
|
||||
Forwarding from 127.0.0.1:63753 -> 27017
|
||||
Forwarding from [::1]:63753 -> 27017
|
||||
```
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Discussion
|
||||
|
||||
Les connexions établies sur le port local 28015 sont redirigées vers le port 27017 du pod qui exécute le serveur MongoDB.
|
||||
Avec cette connexion en place, vous pouvez utiliser votre poste de travail local
|
||||
pour debug la base de données MongoDB qui s'exécute dans le pod.
|
||||
|
||||
{{< note >}}
|
||||
`kubectl port-forward` est implémenté pour les ports TCP uniquement. La prise en charge du protocole UDP est suivie dans [l'issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
|
||||
{{< /note >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
En savoir plus sur [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward).
|
||||
|
|
@ -0,0 +1,155 @@
|
|||
---
|
||||
title: Utiliser un Service pour accéder à une application dans un cluster
|
||||
content_type: tutorial
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Cette page montre comment créer un Service Kubernetes que des clients externes peuvent utiliser
|
||||
pour accéder à une application s'exécutant dans un cluster.
|
||||
Le Service fournit une répartition de charge pour une application
|
||||
ayant deux instances en cours d'exécution.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
- Exécuter deux instances d'une application Hello World.
|
||||
- Créer un Service qui expose un port du nœud.
|
||||
- Utiliser le Service pour accéder à l'application en cours d'exécution.
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## Création d'un service pour une application s'exécutant dans deux pods
|
||||
|
||||
Voici le fichier de configuration pour le déploiement de l'application :
|
||||
|
||||
{{< codenew file="service/access/hello-application.yaml" >}}
|
||||
|
||||
1. Exécutez une application Hello World dans votre cluster :
|
||||
Créez le déploiement de l'application en utilisant le fichier ci-dessus :
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
|
||||
```
|
||||
|
||||
La commande précédente crée un
|
||||
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}
|
||||
et un
|
||||
{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}} associé.
|
||||
Le ReplicaSet possède deux
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}},
|
||||
chacun exécutant l'application Hello World.
|
||||
|
||||
1. Affichez les informations du déploiement :
|
||||
|
||||
```shell
|
||||
kubectl get deployments hello-world
|
||||
kubectl describe deployments hello-world
|
||||
```
|
||||
|
||||
1. Affichez les informations des ReplicaSet :
|
||||
|
||||
```shell
|
||||
kubectl get replicasets
|
||||
kubectl describe replicasets
|
||||
```
|
||||
|
||||
1. Créez un Service qui expose le déploiement :
|
||||
|
||||
```shell
|
||||
kubectl expose deployment hello-world --type=NodePort --name=example-service
|
||||
```
|
||||
|
||||
1. Affichez les informations sur le Service :
|
||||
|
||||
```shell
|
||||
kubectl describe services example-service
|
||||
```
|
||||
|
||||
Le résultat sera similaire à ceci :
|
||||
|
||||
```none
|
||||
Name: example-service
|
||||
Namespace: default
|
||||
Labels: run=load-balancer-example
|
||||
Annotations: <none>
|
||||
Selector: run=load-balancer-example
|
||||
Type: NodePort
|
||||
IP: 10.32.0.16
|
||||
Port: <unset> 8080/TCP
|
||||
TargetPort: 8080/TCP
|
||||
NodePort: <unset> 31496/TCP
|
||||
Endpoints: 10.200.1.4:8080,10.200.2.5:8080
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
Notez la valeur de NodePort pour le service. Par exemple,
|
||||
dans le résultat précédent, la valeur de NodePort est 31496.
|
||||
|
||||
1. Répertoriez les pods qui exécutent l'application Hello World :
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector="run=load-balancer-example" --output=wide
|
||||
```
|
||||
|
||||
Le résultat est similaire à ceci :
|
||||
|
||||
```none
|
||||
NAME READY STATUS ... IP NODE
|
||||
hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1
|
||||
hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2
|
||||
```
|
||||
|
||||
1. Obtenez l'adresse IP publique de l'un de vos nœuds qui exécute
|
||||
un pod Hello World. L'obtention de cette adresse dépend de la manière dont vous avez configuré votre cluster.
|
||||
Par exemple, si vous utilisez Minikube, vous pouvez
|
||||
voir l'adresse du nœud en exécutant `kubectl cluster-info`. Si vous utilisez
|
||||
des instances Google Compute Engine, vous pouvez utiliser la commande
|
||||
`gcloud compute instances list` pour voir les adresses publiques de vos
|
||||
nœuds.
|
||||
|
||||
1. Sur le nœud choisi, créez une règle de pare-feu autorisant le trafic TCP
|
||||
sur votre port. Par exemple, si votre Service a une valeur NodePort de
|
||||
31568, créez une règle de pare-feu autorisant le trafic TCP vers le port 31568. Différents
|
||||
fournisseurs cloud offrent différentes façons de configurer des règles de pare-feu.
|
||||
|
||||
1. Utilisez l'adresse du nœud et le port de nœud pour accéder à l'application Hello World :
|
||||
|
||||
```shell
|
||||
curl http://<adresse-ip-publique>:<port>
|
||||
```
|
||||
|
||||
où `<adresse-ip-publique>` est l'adresse IP publique de votre nœud,
|
||||
et `<port>` est la valeur de NodePort pour votre service. La
|
||||
réponse à une requête réussie est un message de bienvenue :
|
||||
|
||||
```none
|
||||
Hello Kubernetes!
|
||||
```
|
||||
|
||||
## Utilisation d'un fichier de configuration de service
|
||||
|
||||
Au lieu d'utiliser `kubectl expose`, vous pouvez utiliser un
|
||||
[fichier de configuration de service](/docs/concepts/services-networking/service/)
|
||||
pour créer un Service.
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
Pour supprimer le Service, saisissez cette commande :
|
||||
|
||||
kubectl delete services example-service
|
||||
|
||||
Pour supprimer le Déploiement, le ReplicaSet et les Pods qui exécutent
|
||||
l'application Hello World, saisissez cette commande :
|
||||
|
||||
kubectl delete deployment hello-world
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Suivez le tutoriel
|
||||
[Connecter des applications avec les Services](/docs/tutorials/services/connect-applications-service/).
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: backend
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hello
|
||||
tier: backend
|
||||
track: stable
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello
|
||||
tier: backend
|
||||
track: stable
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: "gcr.io/google-samples/hello-go-gke:1.0"
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 80
|
||||
...
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
selector:
|
||||
app: hello
|
||||
tier: backend
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: http
|
||||
...
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hello
|
||||
tier: frontend
|
||||
track: stable
|
||||
replicas: 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello
|
||||
tier: frontend
|
||||
track: stable
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: "gcr.io/google-samples/hello-frontend:1.0"
|
||||
lifecycle:
|
||||
preStop:
|
||||
exec:
|
||||
command: ["/usr/sbin/nginx","-s","quit"]
|
||||
...
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
# The identifier Backend is internal to nginx, and used to name this specific upstream
|
||||
upstream Backend {
|
||||
# hello is the internal DNS name used by the backend Service inside Kubernetes
|
||||
server hello;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
|
||||
location / {
|
||||
# The following statement will proxy traffic to the upstream named Backend
|
||||
proxy_pass http://Backend;
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
selector:
|
||||
app: hello
|
||||
tier: frontend
|
||||
ports:
|
||||
- protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 80
|
||||
type: LoadBalancer
|
||||
...
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: load-balancer-example
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: load-balancer-example
|
||||
spec:
|
||||
containers:
|
||||
- name: hello-world
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
ports:
|
||||
- containerPort: 8080
|
||||
protocol: TCP
|
||||
Loading…
Reference in New Issue