Kubernetes Prow Robot
@@ -157,7 +157,7 @@ Dans la plupart des cas, le contrôleur de noeud limite le taux d’expulsion à
|
||||
|
||||
Le comportement d'éviction de noeud change lorsqu'un noeud d'une zone de disponibilité donnée devient défaillant.
|
||||
Le contrôleur de nœud vérifie quel pourcentage de nœuds de la zone est défaillant (la condition NodeReady est ConditionUnknown ou ConditionFalse) en même temps.
|
||||
Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à ` --large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde.
|
||||
Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à `--large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde.
|
||||
|
||||
Ces stratégies sont implémentées par zone de disponibilité car une zone de disponibilité peut être partitionnée à partir du master, tandis que les autres restent connectées.
|
||||
Si votre cluster ne s'étend pas sur plusieurs zones de disponibilité de fournisseur de cloud, il n'existe qu'une seule zone de disponibilité (la totalité du cluster).
|
||||
|
||||
@@ -91,7 +91,7 @@ spec:
|
||||
number: 80
|
||||
```
|
||||
|
||||
Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a besoin des champs `apiVersion`,` kind` et `metadata`.
|
||||
Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a besoin des champs `apiVersion`, `kind` et `metadata`.
|
||||
Pour des informations générales sur l'utilisation des fichiers de configuration, voir [déployer des applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configurer des conteneurs](/docs/tasks/configure-pod-container/configure-pod-configmap/), [gestion des ressources](/docs/concepts/cluster-administration/manage-deployment/).
|
||||
Ingress utilise fréquemment des annotations pour configurer certaines options en fonction du contrôleur Ingress, dont un exemple
|
||||
est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
|
||||
@@ -223,7 +223,7 @@ Events:
|
||||
Normal ADD 22s loadbalancer-controller default/test
|
||||
```
|
||||
|
||||
Le contrôleur d’Ingress fournit une implémentation spécifique aux load-balancers qui satisfait l'Ingress, tant que les services (`s1`,` s2`) existent.
|
||||
Le contrôleur d’Ingress fournit une implémentation spécifique aux load-balancers qui satisfait l'Ingress, tant que les services (`s1`, `s2`) existent.
|
||||
Lorsque cela est fait, vous pouvez voir l’adresse du load-balancer sur le champ d'adresse.
|
||||
|
||||
{{< note >}}
|
||||
@@ -272,7 +272,7 @@ spec:
|
||||
number: 80
|
||||
```
|
||||
|
||||
Si vous créez une ressource Ingress sans aucun hôte défini dans les règles, tout trafic Web à destination de l'adresse IP de votre contrôleur d'Ingress peut être mis en correspondance sans qu'un hôte virtuel basé sur le nom ne soit requis. Par exemple, la ressource Ingress suivante acheminera le trafic demandé pour `first.bar.com` au `service1` `second.foo.com` au `service2`, et à tout trafic à l'adresse IP sans nom d'hôte défini dans la demande (c'est-à-dire sans en-tête de requête présenté) au `service3`.
|
||||
Si vous créez une ressource Ingress sans aucun hôte défini dans les règles, tout trafic Web à destination de l'adresse IP de votre contrôleur d'Ingress peut être mis en correspondance sans qu'un hôte virtuel basé sur le nom ne soit requis. Par exemple, la ressource Ingress suivante acheminera le trafic demandé pour `first.bar.com` au `service1`, `second.foo.com` au `service2`, et à tout trafic à l'adresse IP sans nom d'hôte défini dans la demande (c'est-à-dire sans en-tête de requête présenté) au `service3`.
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
|
||||
@@ -209,7 +209,7 @@ Cela signifie que vous évitez d'envoyer du trafic via kube-proxy vers un pod co
|
||||
|
||||
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
|
||||
|
||||
En mode `ipvs`, kube-proxy surveille les Services et Endpoints Kubernetes. kube-proxy appelle l'interface` netlink` pour créer les règles IPVS en conséquence et synchronise périodiquement les règles IPVS avec les Services et Endpoints Kubernetes.
|
||||
En mode `ipvs`, kube-proxy surveille les Services et Endpoints Kubernetes. kube-proxy appelle l'interface `netlink` pour créer les règles IPVS en conséquence et synchronise périodiquement les règles IPVS avec les Services et Endpoints Kubernetes.
|
||||
Cette boucle de contrôle garantit que l'état IPVS correspond à l'état souhaité.
|
||||
Lors de l'accès à un service, IPVS dirige le trafic vers l'un des pods backend.
|
||||
|
||||
@@ -364,11 +364,11 @@ Les valeurs de `Type` et leurs comportements sont:
|
||||
Le choix de cette valeur rend le service uniquement accessible à partir du cluster.
|
||||
Il s'agit du `ServiceType` par défaut.
|
||||
* [`NodePort`](#type-nodeport): Expose le service sur l'IP de chaque nœud sur un port statique (le `NodePort`).
|
||||
Un service `ClusterIP`, vers lequel le service` NodePort` est automatiquement créé.
|
||||
Un service `ClusterIP`, vers lequel le service `NodePort` est automatiquement créé.
|
||||
Vous pourrez contacter le service `NodePort`, depuis l'extérieur du cluster, en demandant `<NodeIP>: <NodePort>`.
|
||||
* [`LoadBalancer`](#loadbalancer): Expose le service en externe à l'aide de l'équilibreur de charge d'un fournisseur de cloud.
|
||||
Les services `NodePort` et `ClusterIP`, vers lesquels les itinéraires de l'équilibreur de charge externe, sont automatiquement créés.
|
||||
* [`ExternalName`](#externalname): Mappe le service au contenu du champ `externalName` (par exemple` foo.bar.example.com`), en renvoyant un enregistrement `CNAME` avec sa valeur.
|
||||
* [`ExternalName`](#externalname): Mappe le service au contenu du champ `externalName` (par exemple `foo.bar.example.com`), en renvoyant un enregistrement `CNAME` avec sa valeur.
|
||||
Aucun proxy d'aucune sorte n'est mis en place.
|
||||
{{< note >}}
|
||||
Vous avez besoin de CoreDNS version 1.7 ou supérieure pour utiliser le type `ExternalName`.
|
||||
|
||||
@@ -122,7 +122,7 @@ On branch master
|
||||
|
||||
### Valider votre fichier édité
|
||||
|
||||
Exécutez `git add` et ` git commit` pour valider les modifications que vous avez apportées jusqu'à présent.
|
||||
Exécutez `git add` et `git commit` pour valider les modifications que vous avez apportées jusqu'à présent.
|
||||
Dans l'étape suivante, vous ferez un deuxième commit.
|
||||
Il est important de séparer vos modifications en deux commits.
|
||||
|
||||
@@ -152,7 +152,7 @@ Voir le contenu de `api/openapi-spec/swagger.json` pour vous assurer que la faut
|
||||
Par exemple, vous pouvez exécuter `git diff -a api/openapi-spec/swagger.json`.
|
||||
Ceci est important, car `swagger.json` sera l’entrée de la seconde étape du processus de génération de doc.
|
||||
|
||||
Exécutez `git add` et ` git commit` pour valider vos modifications.
|
||||
Exécutez `git add` et `git commit` pour valider vos modifications.
|
||||
Vous avez maintenant deux validations: une avec le fichier `types.go` édité et une avec les spécifications OpenAPI générées et les fichiers associés.
|
||||
Gardez ces deux commits séparés.
|
||||
C'est-à-dire, ne faites pas un squash de vos commits.
|
||||
|
||||
@@ -132,7 +132,7 @@ mais aussi `dev.example.com` ou même `example.com`. kops fonctionne avec n'impo
|
||||
Supposons que vous utilisiez `dev.example.com` comme zone hébergée. Vous créeriez cette zone hébergée en utilisant la [méthode normal](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), ou avec une ligne de commande telle que `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
|
||||
|
||||
Vous devrez ensuite configurer vos enregistrements NS dans le domaine parent afin que vous puissiez résoudre dans ce domaine.
|
||||
Vous créeriez donc des enregistrements NS dans le domaine `example.com` pour` dev`.
|
||||
Vous créeriez donc des enregistrements NS dans le domaine `example.com` pour `dev`.
|
||||
S'il s'agit d'un nom de domaine racine, vous devrez configurer les enregistrements NS chez votre hébergeur de nom de domaine (là où vous avez acheté votre nom de domaine `example.com`).
|
||||
|
||||
Cette étape est délicate, soyez vigilants (c’est la première cause de problèmes !). Vous pouvez vérifier que
|
||||
@@ -195,7 +195,7 @@ Il applique les modifications que vous avez apportées à la configuration sur v
|
||||
|
||||
Par exemple, après un `kops edit ig nodes`, puis un `kops update cluster --yes` pour appliquer votre configuration, parfois, vous devrez également exécuter un `kops rolling-update cluster` pour déployer la configuration immédiatement.
|
||||
|
||||
Sans l'argument `--yes`,` kops update cluster` vous montrera un aperçu de ce qu’il va faire. C'est pratique
|
||||
Sans l'argument `--yes`, `kops update cluster` vous montrera un aperçu de ce qu’il va faire. C'est pratique
|
||||
pour les clusters de production !
|
||||
|
||||
### Explorer d'autres composants additionnels (add-ons)
|
||||
|
||||
+13
-13
@@ -243,7 +243,7 @@ Alternativement, si vous êtes `root`, vous pouvez exécuter:
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
Faites un enregistrement du retour de la commande `kubeadm join` que` kubeadm init` génère. Vous avez
|
||||
Faites un enregistrement du retour de la commande `kubeadm join` que `kubeadm init` génère. Vous avez
|
||||
besoin de cette commande pour [joindre des noeuds à votre cluster](#join-nodes).
|
||||
|
||||
Le jeton est utilisé pour l'authentification mutuelle entre le master et les nœuds qui veulent le rejoindre.
|
||||
@@ -284,7 +284,7 @@ car cela pourrait entraîner des problèmes.
|
||||
Si vous constatez une collision entre le réseau de pod de votre plug-in de réseau et certains
|
||||
de vos réseaux hôtes,
|
||||
vous devriez penser à un remplacement de CIDR approprié et l'utiliser lors de `kubeadm init` avec
|
||||
` --pod-network-cidr` et en remplacement du YAML de votre plugin réseau.
|
||||
`--pod-network-cidr` et en remplacement du YAML de votre plugin réseau.
|
||||
Vous pouvez installer un add-on réseau de pod avec la commande suivante:
|
||||
|
||||
```bash
|
||||
@@ -304,8 +304,8 @@ Pour plus d'informations sur l'utilisation de Calico, voir
|
||||
[Installation de Calico pour les netpols ( network policies ) et le réseau](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), ainsi que d'autres resources liées à ce sujet.
|
||||
|
||||
Pour que Calico fonctionne correctement, vous devez passer `--pod-network-cidr = 192.168.0.0 / 16`
|
||||
à` kubeadm init` ou mettre à jour le fichier `calico.yml` pour qu'il corresponde à votre réseau de Pod.
|
||||
Notez que Calico fonctionne uniquement sur `amd64`,` arm64`, `ppc64le` et` s390x`.
|
||||
à `kubeadm init` ou mettre à jour le fichier `calico.yml` pour qu'il corresponde à votre réseau de Pod.
|
||||
Notez que Calico fonctionne uniquement sur `amd64`, `arm64`, `ppc64le` et `s390x`.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
|
||||
@@ -317,7 +317,7 @@ Canal utilise Calico pour les netpols et Flannel pour la mise en réseau. Report
|
||||
documentation Calico pour obtenir le [guide de démarrage officiel](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/flannel).
|
||||
|
||||
Pour que Canal fonctionne correctement, `--pod-network-cidr = 10.244.0.0 / 16` doit être passé à
|
||||
` kubeadm init`. Notez que Canal ne fonctionne que sur `amd64`.
|
||||
`kubeadm init`. Notez que Canal ne fonctionne que sur `amd64`.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
|
||||
@@ -353,14 +353,14 @@ cilium-drxkl 1/1 Running 0 18m
|
||||
{{% /tab %}}
|
||||
{{% tab name="Flannel" %}}
|
||||
|
||||
Pour que `flannel` fonctionne correctement, vous devez passer` --pod-network-cidr = 10.244.0.0 / 16` à `kubeadm init`.
|
||||
Pour que `flannel` fonctionne correctement, vous devez passer `--pod-network-cidr = 10.244.0.0 / 16` à `kubeadm init`.
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant
|
||||
` sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
`sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
passez le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI
|
||||
fonctionnent, pour plus d'informations
|
||||
allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Notez que `flannel` fonctionne sur` amd64`, `arm`,` arm64`, `ppc64le` et` s390x` sous Linux.
|
||||
Notez que `flannel` fonctionne sur `amd64`, `arm`, `arm64`, `ppc64le` et `s390x` sous Linux.
|
||||
Windows (`amd64`) est annoncé comme supporté dans la v0.11.0 mais son utilisation n’est pas
|
||||
documentée.
|
||||
|
||||
@@ -378,7 +378,7 @@ Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'inf
|
||||
s'il vous plaît allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Kube-router s'appuie sur kube-controller-manager pour allouer le pod CIDR aux nœuds. Par conséquent,
|
||||
utilisez `kubeadm init` avec l'option` --pod-network-cidr`.
|
||||
utilisez `kubeadm init` avec l'option `--pod-network-cidr`.
|
||||
|
||||
Kube-router fournit un réseau de pod, une stratégie réseau et un proxy de service basé sur un
|
||||
IP Virtual Server (IPVS) / Linux Virtual Server (LVS) hautement performant.
|
||||
@@ -388,7 +388,7 @@ veuillez consulter le [guide d'installation](https://github.com/cloudnativelabs/
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Romana" %}}
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à` 1` en exécutant
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à `1` en exécutant
|
||||
`sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent,
|
||||
pour plus d'informations
|
||||
@@ -404,13 +404,13 @@ kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containe
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Weave Net" %}}
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant` sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant `sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'informations
|
||||
s'il vous plaît allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Le guide de configuration officiel de Weave Net est [ici](https://www.weave.works/docs/net/latest/kube-addon/).
|
||||
|
||||
Weave Net fonctionne sur `amd64`,` arm`, `arm64` et` ppc64le` sans aucune action supplémentaire requise.
|
||||
Weave Net fonctionne sur `amd64`, `arm`, `arm64` et `ppc64le` sans aucune action supplémentaire requise.
|
||||
Weave Net paramètre le mode hairpin par défaut. Cela permet aux pods de se connecter via leur adresse IP de service
|
||||
s'ils ne connaissent pas leur Pod IP.
|
||||
|
||||
@@ -597,7 +597,7 @@ Si vous souhaitez réinitialiser les tables IPVS, vous devez exécuter la comman
|
||||
ipvsadm -C
|
||||
```
|
||||
|
||||
Si vous souhaitez recommencer Il suffit de lancer `kubeadm init` ou` kubeadm join` avec les
|
||||
Si vous souhaitez recommencer Il suffit de lancer `kubeadm init` ou `kubeadm join` avec les
|
||||
arguments appropriés.
|
||||
Plus d'options et d'informations sur la
|
||||
[`commande de réinitialisation de kubeadm`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
|
||||
|
||||
@@ -27,7 +27,7 @@ Un cluster HA empilé est une [topologie réseau](https://fr.wikipedia.org/wiki/
|
||||
où le cluster de stockage de données distribuées est fourni par etcd et est superposé au
|
||||
cluster formé par les noeuds gérés par kubeadm qui exécute les composants du control plane.
|
||||
|
||||
Chaque nœud du control plane exécute une instance de `kube-apiserver`,` kube-scheduler` et
|
||||
Chaque nœud du control plane exécute une instance de `kube-apiserver`, `kube-scheduler` et
|
||||
`kube-controller-manager`.
|
||||
Le `kube-apiserver` est exposé aux nœuds à l'aide d'un loadbalancer.
|
||||
|
||||
@@ -47,7 +47,7 @@ Par conséquent, vous devez exécuter au moins trois nœuds de control plane emp
|
||||
en haute disponibilité.
|
||||
|
||||
C'est la topologie par défaut dans kubeadm. Un membre etcd local est créé automatiquement
|
||||
sur les noeuds du control plane en utilisant `kubeadm init` et` kubeadm join --experimental-control-plane`.
|
||||
sur les noeuds du control plane en utilisant `kubeadm init` et `kubeadm join --experimental-control-plane`.
|
||||
|
||||
Schéma de la [Topologie etcd empilée](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
|
||||
|
||||
@@ -59,7 +59,7 @@ distribuées fourni par etcd est externe au cluster formé par les nœuds qui ex
|
||||
du control plane.
|
||||
|
||||
Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute
|
||||
une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver`
|
||||
une instance de `kube-apiserver`, `kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver`
|
||||
est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur
|
||||
des hôtes distincts et chaque hôte etcd communique avec le `kube-apiserver` de chaque nœud du control plane.
|
||||
|
||||
|
||||
@@ -250,7 +250,7 @@ ARCH="amd64"
|
||||
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
|
||||
```
|
||||
|
||||
Installez `kubeadm`,` kubelet`, `kubectl` et ajoutez un service systemd` kubelet`:
|
||||
Installez `kubeadm`, `kubelet`, `kubectl` et ajoutez un service systemd `kubelet`:
|
||||
|
||||
RELEASE_VERSION="v0.6.0"
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ utilisant kubeadm, plutôt que de gérer manuellement la configuration des kubel
|
||||
### Propagation de la configuration niveau cluster à chaque kubelet {#propagating-cluster-level-configuration-to-each-kubelet}
|
||||
|
||||
Vous pouvez fournir à la kubelet les valeurs par défaut à utiliser par les commandes `kubeadm init` et
|
||||
` kubeadm join`. Des exemples intéressants incluent l’utilisation d’un runtime CRI différent ou la
|
||||
`kubeadm join`. Des exemples intéressants incluent l’utilisation d’un runtime CRI différent ou la
|
||||
définition du sous-réseau par défaut utilisé par les services.
|
||||
|
||||
Si vous souhaitez que vos services utilisent le sous-réseau `10.96.0.0 / 12` par défaut pour les
|
||||
|
||||
+11
-11
@@ -102,26 +102,26 @@ L'inspection des journaux de Docker peut également être utile:
|
||||
journalctl -ul docker
|
||||
```
|
||||
|
||||
## Pods dans l'état `RunContainerError`,` CrashLoopBackOff` ou `Error`
|
||||
## Pods dans l'état `RunContainerError`, `CrashLoopBackOff` ou `Error`
|
||||
|
||||
Juste après `kubeadm init`, il ne devrait pas y avoir de pods dans ces états.
|
||||
|
||||
- S'il existe des pods dans l'un de ces états _juste après_ `kubeadm init`, veuillez ouvrir un
|
||||
issue dans le dépôt de Kubeadm. `coredns` (ou` kube-dns`) devrait être dans l'état `Pending`
|
||||
jusqu'à ce que vous ayez déployé la solution réseau.
|
||||
- Si vous voyez des pods dans les états `RunContainerError`,` CrashLoopBackOff` ou `Error`
|
||||
- Si vous voyez des pods dans les états `RunContainerError`, `CrashLoopBackOff` ou `Error`
|
||||
après le déploiement de la solution réseau et que rien ne se passe pour `coredns` (ou` kube-dns`),
|
||||
il est très probable que la solution Pod Network que vous avez installée est en quelque sorte
|
||||
endommagée. Vous devrez peut-être lui accorder plus de privilèges RBAC ou utiliser une version
|
||||
plus récente. S'il vous plaît créez une issue dans le dépôt du fournisseur de réseau de Pod.
|
||||
- Si vous installez une version de Docker antérieure à 1.12.1, supprimez l'option `MountFlags = slave`
|
||||
lors du démarrage de `dockerd` avec` systemd` et redémarrez `docker`. Vous pouvez voir les options
|
||||
lors du démarrage de `dockerd` avec `systemd` et redémarrez `docker`. Vous pouvez voir les options
|
||||
de montage dans `/usr/lib/systemd/system/docker.service`.
|
||||
Les options de montage peuvent interférer avec les volumes montés par Kubernetes et mettre les
|
||||
pods dans l'état`CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers
|
||||
pods dans l'état `CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers
|
||||
`var/run/secrets/kubernetes.io/serviceaccount`.
|
||||
|
||||
## `coredns` (ou` kube-dns`) est bloqué dans l'état `Pending`
|
||||
## `coredns` (ou `kube-dns`) est bloqué dans l'état `Pending`
|
||||
|
||||
Ceci est **prévu** et fait partie du design. kubeadm est agnostique vis-à-vis du fournisseur
|
||||
de réseau, ainsi l'administrateur devrait [installer la solution réseau pod](/docs/concepts/cluster-administration/addons/)
|
||||
@@ -132,7 +132,7 @@ D'où l' état `Pending` avant la mise en place du réseau.
|
||||
|
||||
Les fonctionnalités `HostPort` et `HostIP` sont disponibles en fonction de votre fournisseur
|
||||
de réseau de pod. Veuillez contacter l’auteur de la solution de réseau de Pod pour savoir si
|
||||
Les fonctionnalités `HostPort` et` HostIP` sont disponibles.
|
||||
Les fonctionnalités `HostPort` et `HostIP` sont disponibles.
|
||||
|
||||
Les fournisseurs de CNI Calico, Canal, et Flannel supportent HostPort.
|
||||
|
||||
@@ -151,7 +151,7 @@ Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, v
|
||||
|
||||
- Si vous utilisez VirtualBox (directement ou via Vagrant), vous devrez vous assurez que
|
||||
`hostname -i` renvoie une adresse IP routable. Par défaut la première interface est connectée
|
||||
à un réseau d’`hôte uniquement` non routable. En contournement vous pouvez modifier`/etc/hosts`,
|
||||
à un réseau d’ `hôte uniquement` non routable. En contournement vous pouvez modifier `/etc/hosts`,
|
||||
jetez un œil à ce [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11) par exemple.
|
||||
|
||||
## Erreurs de certificats TLS
|
||||
@@ -198,7 +198,7 @@ pour que la deuxième interface soit choisie.
|
||||
|
||||
## IP non publique utilisée pour les conteneurs
|
||||
|
||||
Dans certaines situations, les commandes `kubectl logs` et` kubectl run` peuvent
|
||||
Dans certaines situations, les commandes `kubectl logs` et `kubectl run` peuvent
|
||||
renvoyer les erreurs suivantes dans un cluster par ailleurs fonctionnel:
|
||||
|
||||
```sh
|
||||
@@ -211,9 +211,9 @@ avec d’autres adresses IP même sous-réseau, éventuellement à cause d'une p
|
||||
par le fournisseur de la machine.
|
||||
- Digital Ocean attribue une adresse IP publique à `eth0` ainsi qu’une adresse privée à
|
||||
utiliser en interne comme IP d'ancrage pour leur fonction IP flottante, mais `kubelet` choisira cette
|
||||
dernière comme` InternalIP` du noeud au lieu du public.
|
||||
dernière comme `InternalIP` du noeud au lieu du public.
|
||||
|
||||
Utilisez `ip addr show` pour verifier ce scénario au lieu de` ifconfig` car `ifconfig` n'affichera pas
|
||||
Utilisez `ip addr show` pour verifier ce scénario au lieu de `ifconfig` car `ifconfig` n'affichera pas
|
||||
l'alias de l'adresse IP incriminée. Sinon, une API spécifique à Digital Ocean
|
||||
permet de rechercher l'adresse IP d'ancrage à partir du droplet:
|
||||
|
||||
@@ -253,7 +253,7 @@ Pod de CoreDNS déployé dans Kubernetes détecte une boucle. [Un certain nombre
|
||||
sont disponibles pour éviter que Kubernetes ne tente de redémarrer le pod CoreDNS chaque fois que CoreDNS détecte une boucle et s'arrête.
|
||||
|
||||
{{< warning >}}
|
||||
Désactiver SELinux ou paramètrer `allowPrivilegeEscalation` sur` true` peut compromettre
|
||||
Désactiver SELinux ou paramètrer `allowPrivilegeEscalation` sur `true` peut compromettre
|
||||
la sécurité de votre cluster.
|
||||
{{< /warning >}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user