From a3f977aaec05b09b5fe20c749703c7ece1e8546c Mon Sep 17 00:00:00 2001 From: Cheikhrouhou ines Date: Thu, 12 Sep 2019 21:58:31 +0200 Subject: [PATCH 01/25] translate service account fr --- .../configure-service-account.md | 288 ++++++++++++++++++ .../pods/pod-projected-svc-token.yaml | 20 ++ 2 files changed, 308 insertions(+) create mode 100644 content/fr/docs/tasks/configure-pod-container/configure-service-account.md create mode 100644 content/fr/examples/pods/pod-projected-svc-token.yaml diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..c90a7de585 --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,288 @@ +--- +title: Configurer les comptes de service pour les pods +content_template: templates/task +weight: 90 +--- + +{{% capture overview %}} +Un compte de service fournit une identité pour les processus qui s'exécutent dans un Pod. + +*Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi +[Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).* + +{{< note >}} +Ce document décrit le comportement des comptes de service dans un cluster mis en place conformément aux recommandations du projet Kubernetes. L'administrateur de votre cluster a peut-être personnalisé le comportement dans votre cluster, dans ce cas cette documentation pourrait être non applicable. +{{< /note >}} + +Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes +authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit +généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster).Les processus dans les conteneurs dans les pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Utiliser le compte de service par défaut pour accéder au API server. + +Si vous obtenez le raw json ou yaml pour un pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). + +Vous pouvez accéder à l'API depuis l'intérieur d'un pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage. + +Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken : false` sur le compte de service : + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + +Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un pod particulier : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + +La spéc de pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. + +## Utiliser plusieurs comptes de services. + +Chaque namespace possède une ressource de compte de service par défaut appelée `default`. +Vous pouvez lister cette ressource et toutes les autres ressources de serviceAccount dans le namespace avec cette commande : + +```shell +kubectl get serviceAccounts +``` +La sortie est comme la suivante : + +``` +NAME SECRETS AGE +default 1 1d +``` + +Vous pouvez créer des objets ServiceAccount supplémentaires comme ceci : + +```shell +kubectl apply -f - < +Annotations: kubernetes.io/service-account.name=build-robot + kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1338 bytes +namespace: 7 bytes +token: ... +``` + +{{< note >}} +Le contenu de `token` est éludé ici. +{{< /note >}} + +## Ajouter ImagePullSecrets à un compte de service + +Tout d'abord, créez un imagePullSecret, comme décrit [ici](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +Puis, vérifiez qu'il a été créé. Par exemple : + +```shell +kubectl get secrets myregistrykey +``` + +La sortie est comme la suivante : + +``` +NAME TYPE DATA AGE +myregistrykey   kubernetes.io/.dockerconfigjson   1       1d +``` + +Ensuite, modifiez le compte de service par défaut du namespace pour utiliser ce secret comme un imagePullSecret. + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + +La version interactive nécessite un traitement manuel : + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml +``` + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +``` + +En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajouter les lignes avec `imagePullSecrets:` et sauvegarder. + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey +``` + +Enfin, remplacez le compte de service par le nouveau fichier `sa.yaml` mis à jour. + +```shell +kubectl replace serviceaccount default -f ./sa.yaml +``` + +Maintenant, tous les nouveaux pods créés dans le namespace courant auront ceci ajouté à leurs spécifications : + +```yaml +spec: + imagePullSecrets: + - name: myregistrykey +``` + + + +## Projection du volume des tokens de compte de service + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} +Ce ServiceAccountTokenVolumeProjection est __beta__ en 1.12 et +activé en passant tous les paramètres suivants au serveur API : + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +Le kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. +Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé + +Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé +[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un +pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : + +{{< codenew file="pods/pod-projected-svc-token.yaml" >}} + +Créez le pod + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml +``` + +Le kubelet demandera et stockera le token a la place du pod, rendra le token disponible pour le pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. + +L'application est responsable du rechargement du token lorsqu'il tourne. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. + +{{% /capture %}} diff --git a/content/fr/examples/pods/pod-projected-svc-token.yaml b/content/fr/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/fr/examples/pods/pod-projected-svc-token.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + serviceAccountName: build-robot + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault From 496fad77bbf9a1362c332fdfca26f7c876532c02 Mon Sep 17 00:00:00 2001 From: Cheikhrouhou ines Date: Fri, 20 Dec 2019 16:52:34 +0100 Subject: [PATCH 02/25] renaming and fix for service account fr --- .../configure-service-account.md | 44 +++++++++---------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md index c90a7de585..872256503b 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -5,7 +5,7 @@ weight: 90 --- {{% capture overview %}} -Un compte de service fournit une identité pour les processus qui s'exécutent dans un Pod. +Un ServiceAccount (compte de service) fournit une identité pour les processus qui s'exécutent dans un Pod. *Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi [Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).* @@ -16,7 +16,7 @@ Ce document décrit le comportement des comptes de service dans un cluster mis e Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit -généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster).Les processus dans les conteneurs dans les pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). +généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster). Les processus dans les conteneurs dans les Pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). {{% /capture %}} @@ -31,12 +31,12 @@ généralement de l'utilisateur `admin`, à moins que votre administrateur de cl ## Utiliser le compte de service par défaut pour accéder au API server. -Si vous obtenez le raw json ou yaml pour un pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). +Si vous obtenez le raw json ou yaml pour un Pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). -Vous pouvez accéder à l'API depuis l'intérieur d'un pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Vous pouvez accéder à l'API depuis l'intérieur d'un Pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage. -Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken : false` sur le compte de service : +Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken: false` sur le compte de service : ```yaml apiVersion: v1 @@ -47,7 +47,7 @@ automountServiceAccountToken: false ... ``` -Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un pod particulier : +Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un Pod particulier : ```yaml apiVersion: v1 @@ -60,12 +60,12 @@ spec: ... ``` -La spéc de pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. +La spéc de Pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. ## Utiliser plusieurs comptes de services. -Chaque namespace possède une ressource de compte de service par défaut appelée `default`. -Vous pouvez lister cette ressource et toutes les autres ressources de serviceAccount dans le namespace avec cette commande : +Chaque Namespace possède une ressource ServiceAccount par défaut appelée `default`. +Vous pouvez lister cette ressource et toutes les autres ressources de ServiceAccount dans le Namespace avec cette commande : ```shell kubectl get serviceAccounts @@ -111,13 +111,13 @@ secrets: vous verrez alors qu'un token a été automatiquement créé et est référencé par le compte de service. -Vous pouvez utiliser des plugins d'autorisation pour[définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions). +Vous pouvez utiliser des plugins d'autorisation pour [définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions). -Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un pod au nom du compte de service que vous souhaitez utiliser. +Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un Pod au nom du compte de service que vous souhaitez utiliser. -Le compte de service doit exister au moment de la création du pod, sinon il sera rejeté. +Le compte de service doit exister au moment de la création du Pod, sinon il sera rejeté. -Vous ne pouvez pas mettre à jour le compte de service d'un pod déjà créé. +Vous ne pouvez pas mettre à jour le compte de service d'un Pod déjà créé. Vous pouvez supprimer le compte de service de cet exemple comme ceci : @@ -127,7 +127,7 @@ kubectl delete serviceaccount/build-robot ## Créez manuellement un API token de compte de service. -Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau secret manuellement. +Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau Secret manuellement. ```shell kubectl apply -f - <}} -Le kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. +Kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un -pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : +Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : {{< codenew file="pods/pod-projected-svc-token.yaml" >}} -Créez le pod +Créez le Pod ```shell kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml ``` -Le kubelet demandera et stockera le token a la place du pod, rendra le token disponible pour le pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. +Kubelet demandera et stockera le token a la place du Pod, rendra le token disponible pour le Pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. -L'application est responsable du rechargement du token lorsqu'il tourne. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. +L'application est responsable du rechargement du token lorsque celui ci est renouvelé. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. {{% /capture %}} From 40496c2b7d8e2dc9f47f2da21c1ede2db6b93420 Mon Sep 17 00:00:00 2001 From: icheikhrouhou Date: Mon, 13 Apr 2020 10:18:36 +0200 Subject: [PATCH 03/25] fix translate configure service account --- .../configure-pod-container/configure-service-account.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md index 872256503b..5d8df1af62 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -214,7 +214,7 @@ secrets: - name: default-token-uudge ``` -En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajouter les lignes avec `imagePullSecrets:` et sauvegarder. +En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajoutez les lignes avec `imagePullSecrets:` et sauvegardez. La sortie du fichier `sa.yaml` est similaire à celle-ci : @@ -247,11 +247,6 @@ spec: - name: myregistrykey ``` - - ## Projection du volume des tokens de compte de service {{< feature-state for_k8s_version="v1.12" state="beta" >}} From bdc18d99f053aa0c1a7db2d127cc8a59cc73c032 Mon Sep 17 00:00:00 2001 From: lou-lan Date: Tue, 28 Apr 2020 00:51:31 +0800 Subject: [PATCH 04/25] Fix minikube image 'project:hello-minikube-zero-install' has been suspended. --- content/fr/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md index 71f9d0f1ee..b2acb150a1 100644 --- a/content/fr/docs/tutorials/hello-minikube.md +++ b/content/fr/docs/tutorials/hello-minikube.md @@ -76,7 +76,7 @@ Les déploiements sont le moyen recommandé pour gérer la création et la mise Pod utilise un conteneur basé sur l'image Docker fournie. ```shell - kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node + kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4 ``` 2. Affichez le déploiement : From d757b2da39dd8bd0652c1fb669680d81aa305d50 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 20 Jun 2020 12:45:55 +0800 Subject: [PATCH 05/25] Move DNS debugging page back to cluster administration DNS resolution is a task in the control plane rather than application layer. --- .../dns-debugging-resolution.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/en/docs/tasks/{debug-application-cluster => administer-cluster}/dns-debugging-resolution.md (100%) diff --git a/content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md similarity index 100% rename from content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md rename to content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md From a4919b4e5023269eaa5fa3e23d82a10645d55916 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 24 Jun 2020 15:21:48 +0800 Subject: [PATCH 06/25] [zh] Sync kubectl cheatsheet This PR resync the Chinese translation of the kubectl cheatsheet. I realized that it is is out of sync because it still contains deprecated kubectl options such as `--export`. --- .../zh/docs/reference/kubectl/cheatsheet.md | 541 +++++++++++------- 1 file changed, 323 insertions(+), 218 deletions(-) diff --git a/content/zh/docs/reference/kubectl/cheatsheet.md b/content/zh/docs/reference/kubectl/cheatsheet.md index 4ef61cac63..b157fefd71 100644 --- a/content/zh/docs/reference/kubectl/cheatsheet.md +++ b/content/zh/docs/reference/kubectl/cheatsheet.md @@ -1,9 +1,5 @@ --- title: kubectl 备忘单 -reviewers: -- erictune -- krousey -- clove content_type: concept card: name: reference @@ -23,34 +19,42 @@ card: - -也可以看下: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 + +另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 - 本页面是 `kubectl` 命令的概述。 - - -## kubectl - 备忘单 + +# kubectl - 备忘单 - ## Kubectl 自动补全 ### BASH - +``` + +You can also use a shorthand alias for `kubectl` that also works with completion: +--> ```bash source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全，要先安装 bash-completion 包。 echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全 ``` - 您还可以为 `kubectl` 使用一个速记别名，该别名也可以与 completion 一起使用： ```bash @@ -60,25 +64,32 @@ complete -F __start_kubectl k ### ZSH - +``` +--> ```bash source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全 echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全 ``` - +detailed config file information. +--> ## Kubectl 上下文和配置 -设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 [使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取详情配置文件信息。 +设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 +[使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +文档获取配置文件详细信息。 - +``` +--> ```bash kubectl config view # 显示合并的 kubeconfig 配置。 @@ -115,36 +128,54 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view # 获取 e2e 用户的密码 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' -kubectl config current-context # 展示当前所处的上下文 -kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name +kubectl config view -o jsonpath='{.users[].name}' # 显示第一个用户 +kubectl config view -o jsonpath='{.users[*].name}' # 获取用户列表 +kubectl config get-contexts # 显示上下文列表 +kubectl config current-context # 展示当前所处的上下文 +kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name -# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行鉴权 +# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行身份认证 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword -# 使用特定的用户名和命名空间设置上下文。 +# 在指定上下文中持久性地保存名字空间，供所有后续 kubectl 命令使用 +kubectl config set-context --current --namespace=ggckad-s2 + +# 使用特定的用户名和名字空间设置上下文 kubectl config set-context gce --user=cluster-admin --namespace=foo \ && kubectl config use-context gce + +kubectl config unset users.foo # 删除用户 foo ``` - + +## Apply +`apply` 通过定义 Kubernetes 资源的文件来管理应用。它通过运行 +`kubectl apply` 在集群中创建和更新资源。 +这是在生产中管理 Kubernetes 应用的推荐方法。 +参见 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。 - -## 创建对象 + -Kubernetes 配置可以用 json 或 yaml 定义。可以使用的文件扩展名有 `.yaml`，`.yml` 和 `.json`。 +Kubernetes manifests can be defined in YAML or JSON. The file extension `.yaml`, +`.yml`, and `.json` can be used. +--> +## 创建对象 {#creating-objects} - +``` +--> ```bash kubectl apply -f ./my-manifest.yaml # 创建资源 kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建 -kubectl apply -f ./dir # 从目录下的全部配置文件创建资源 -kubectl apply -f https://git.io/vPieo # 从 url 中创建资源 -kubectl create deployment nginx --image=nginx # 启动单实例 nginx -kubectl explain pods,svc # 获取 pod，svc 配置的文档说明 +kubectl apply -f ./dir # 基于目录下的所有清单文件创建资源 +kubectl apply -f https://git.io/vPieo # 从 URL 中创建资源 +kubectl create deployment nginx --image=nginx # 启动单实例 nginx +kubectl explain pods,svc # 获取 pod 清单的文档说明 -# 从标准输入中的多个 YAML 对象中创建 +# 从标准输入创建多个 YAML 对象 cat < -## 获取和查找资源 + +## 查看和查找资源 - -```bash -# 使用 get 命令获取基本输出 -kubectl get services # 列出当前命名空间下的所有 services -kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 pods -kubectl get pods -o wide # 列出当前命名空间下的全部 pods，有更多的详细信息 -kubectl get deployment my-dep # 列出某个特定的 deployment -kubectl get pods --include-uninitialized # 列出当前命名空间下的全部 pods，包含未初始化的 -kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML -kubectl get pod my-pod -o yaml --export # 获取一个没有集群特定信息的 YAML -# 使用 describe 命令获取详细输出 +# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied. +kubectl diff -f ./my-manifest.yaml +``` +--> +```bash +# get 命令的基本输出 +kubectl get services # 列出当前命名空间下的所有 services +kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 Pods +kubectl get pods -o wide # 列出当前命名空间下的全部 Pods，并显示更详细的信息 +kubectl get deployment my-dep # 列出某个特定的 Deployment +kubectl get pods # 列出当前命名空间下的全部 Pods +kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML + +# describe 命令的详细输出 kubectl describe nodes my-node kubectl describe pods my-pod -kubectl get services --sort-by=.metadata.name # 列出当前命名空间下所有 services，按照名称排序 +# 列出当前名字空间下所有 Services，按名称排序 +kubectl get services --sort-by=.metadata.name -# 列出 pods 按照重启次数进行排序 +# 列出 Pods，按重启次数排序 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# 列出测试命名空间中的 Pod，按容量排序 -kubectl get pods -n test --sort-by=.spec.capacity.storage +# 列举所有 PV 持久卷，按容量排序 +kubectl get pv --sort-by=.spec.capacity.storage -# 获取包含 app=cassandra 标签全部 pods 的 version 标签 +# 获取包含 app=cassandra 标签的所有 Pods 的 version 标签 kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' -# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果) +# 获取所有工作节点（使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果） kubectl get node --selector='!node-role.kubernetes.io/master' -# 获取当前命名空间中正在运行的 pods +# 获取当前命名空间中正在运行的 Pods kubectl get pods --field-selector=status.phase=Running -# 获取全部 node 的 ExternalIP 地址 +# 获取全部节点的 ExternalIP 地址 kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' -# 列出属于某个特定 RC 的 pods 的名称 -# "jq" 命令对于 jsonpath 过于复杂的转换非常有用，可以在 https://stedolan.github.io/jq/ 找到它。 +# 列出属于某个特定 RC 的 Pods 的名称 +# 在转换对于 jsonpath 过于复杂的场合，"jq" 命令很有用；可以在 https://stedolan.github.io/jq/ 找到它。 sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?} echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) -# 显示所有 Pod 的标签(或任何其他支持标签的 Kubernetes 对象) -# 也可以使用 "jq" -for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done - -# 或也可以使用此命令来获取与容器关联的所有标签 +# 显示所有 Pods 的标签（或任何其他支持标签的 Kubernetes 对象） kubectl get pods --show-labels -# 检查哪些节点处于 ready +# 检查哪些节点处于就绪状态 JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" -# 列出被一个 pod 使用的全部 secret +# 列出被一个 Pod 使用的全部 Secret kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq -# 列出 events，按照创建时间排序 +# 列举所有 Pods 中初始化容器的容器 ID（containerID） +# Helpful when cleaning up stopped containers, while avoiding removal of initContainers. +kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3 + +# 列出事件（Events），按时间戳排序 kubectl get events --sort-by=.metadata.creationTimestamp + +# 比较当前的集群状态和假定某清单被应用之后的集群状态 +kubectl diff -f ./my-manifest.yaml ``` - + ## 更新资源 - -从版本 1.11 开始，`rolling-update` 已被弃用（参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))，请使用 `rollout` 代替。 - - +``` +--> ```bash -kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" deployment 的 "www" 容器镜像 -kubectl rollout history deployment/frontend # 检查部署的历史记录，包括版本 +kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像 +kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录，包括版本 kubectl rollout undo deployment/frontend # 回滚到上次部署版本 kubectl rollout undo deployment/frontend --to-revision=2 # 回滚到特定部署版本 -kubectl rollout status -w deployment/frontend # Watch "frontend" deployment 的滚动升级状态直到完成 +kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成 +kubectl rollout restart deployment/frontend # 轮替重启 "frontend" Deployment -# 从 1.11 版本开始弃用 -kubectl rolling-update frontend-v1 -f frontend-v2.json # (弃用) 滚动升级 frontend-v1 的 pods -kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (弃用) 修改资源的名称并更新镜像 -kubectl rolling-update frontend --image=image:v2 # (弃用) 更新 frontend 的 pods 的镜像 -kubectl rolling-update frontend-v1 frontend-v2 --rollback # (弃用) 终止已经进行中的 rollout +cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 Pod -cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 pod - -# 强制进行替换，会删除然后再创建资源，会导致服务不可用。 +# 强制替换，删除后重建资源。会导致服务不可用。 kubectl replace --force -f ./pod.json # 为多副本的 nginx 创建服务，使用 80 端口提供服务，连接到容器的 8000 端口。 kubectl expose rc nginx --port=80 --target-port=8000 -# 更新单容器 pod 的镜像标签到 v4 +# 将某单容器 Pod 的镜像版本（标签）更新到 v4 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - kubectl label pods my-pod new-label=awesome # 添加标签 kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解 -kubectl autoscale deployment foo --min=2 --max=10 # 使 "foo" deployment 自动伸缩容 +kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容 ``` -## 局部更新资源 +## 部分更新资源 - +``` +--> ```bash -kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新 node +# 部分更新某节点 +kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' -#更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并 key。 +# 更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并性质的主键。 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' -# 使用带位置数组的 json patch 更新容器的镜像 +# 使用带位置数组的 JSON patch 更新容器的镜像 kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' -# 使用带位置数组的 json patch 禁用 deployment 的 livenessProbe +# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]' # 在带位置数组中添加元素 kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' ``` - -## 编辑资源 - -在编辑器中编辑任何 API 资源 + +## 编辑资源 + +使用你偏爱的编辑器编辑 API 资源。 + + +``` +--> ```bash -kubectl edit svc/docker-registry # 编辑名为 docker-registry 的 service +kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务 KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器 ``` - + ## 对资源进行伸缩 +``` +--> ```bash kubectl scale --replicas=3 rs/foo # 将名为 'foo' 的副本集伸缩到 3 副本 kubectl scale --replicas=3 -f foo.yaml # 将在 "foo.yaml" 中的特定资源伸缩到 3 个副本 -kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 deployment 的副本当前是 2，那么将它伸缩到 3 -kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个 replication controllers +kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 Deployment 的副本当前是 2，那么将它伸缩到 3 +kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个副本控制器 ``` - + ## 删除资源 +``` +--> ```bash -kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 pod -kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 pod 和 service -kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和 services -kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 pods 和 services，包括未初始化的 -kubectl -n my-ns delete po,svc --all # 删除在 my-ns 命名空间中全部的 pods 和 services ，包括未初始化的 -# 删除所有与 pattern1 或 pattern2 匹配的 pod +kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod +kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务 +kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和服务 +kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 Pods 和服务 +kubectl -n my-ns delete po,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务 +# 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` - + ## 与运行中的 Pods 进行交互 - +``` +--> ```bash -kubectl logs my-pod # 获取 pod 日志(标准输出) -kubectl logs -l name=myLabel # 获取 pod label name=myLabel 日志(标准输出) -kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出) -kubectl logs my-pod -c my-container # 获取 pod 的容器日志 (标准输出, 多容器的场景) -kubectl logs -l name=myLabel -c my-container # 获取 label name=myLabel pod 的容器日志 (标准输出, 多容器的场景) -kubectl logs my-pod -c my-container --previous # 获取 pod 的上个容器实例日志 (标准输出, 多容器的场景) -kubectl logs -f my-pod # 流式输出 pod 的日志 (标准输出) -kubectl logs -f my-pod -c my-container # 流式输出 pod 容器的日志 (标准输出, 多容器的场景) -kubectl logs -f -l name=myLabel --all-containers # 流式输出 label name=myLabel pod 的日志 (标准输出) -kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 shell 运行 pod -kubectl attach my-pod -i # 进入到一个运行中的容器中 +kubectl logs my-pod # 获取 pod 日志（标准输出） +kubectl logs -l name=myLabel # 获取含 name=myLabel 标签的 Pods 的日志（标准输出） +kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志（标准输出） +kubectl logs my-pod -c my-container # 获取 Pod 容器的日志（标准输出, 多容器场景） +kubectl logs -l name=myLabel -c my-container # 获取含 name=myLabel 标签的 Pod 容器日志（标准输出, 多容器场景） +kubectl logs my-pod -c my-container --previous # 获取 Pod 中某容器的上个实例的日志（标准输出, 多容器场景） +kubectl logs -f my-pod # 流式输出 Pod 的日志（标准输出） +kubectl logs -f my-pod -c my-container # 流式输出 Pod 容器的日志（标准输出, 多容器场景） +kubectl logs -f -l name=myLabel --all-containers # 流式输出含 name=myLabel 标签的 Pod 的所有日志（标准输出） +kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 Shell 运行 Pod +kubectl run nginx --image=nginx -n mynamespace # 在指定名字空间中运行 nginx Pod +kubectl run nginx --image=nginx # 运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件 + --dry-run=client -o yaml > pod.yaml + +kubectl attach my-pod -i # 挂接到一个运行的容器中 kubectl port-forward my-pod 5000:6000 # 在本地计算机上侦听端口 5000 并转发到 my-pod 上的端口 6000 -kubectl exec my-pod -- ls / # 在已有的 pod 中运行命令(单容器的场景) -kubectl exec my-pod -c my-container -- ls / # 在已有的 pod 中运行命令(多容器的场景) -kubectl top pod POD_NAME --containers # 显示给定 pod 和容器的监控数据 +kubectl exec my-pod -- ls / # 在已有的 Pod 中运行命令（单容器场景） +kubectl exec my-pod -c my-container -- ls / # 在已有的 Pod 中运行命令（多容器场景） +kubectl top pod POD_NAME --containers # 显示给定 Pod 和其中容器的监控数据 ``` - + ## 与节点和集群进行交互 - +``` +--> ```bash -kubectl cordon my-node # 设置 my-node 节点为不可调度 -kubectl drain my-node # 对 my-node 节点进行驱逐操作，为节点维护做准备 -kubectl uncordon my-node # 设置 my-node 节点为可以调度 -kubectl top node my-node # 显示给定 node 的指标 -kubectl cluster-info # 显示 master 和 services 的地址 -kubectl cluster-info dump # 将当前集群状态输出到标准输出 +kubectl cordon my-node # 标记 my-node 节点为不可调度 +kubectl drain my-node # 对 my-node 节点进行清空操作，为节点维护做准备 +kubectl uncordon my-node # 标记 my-node 节点为可以调度 +kubectl top node my-node # 显示给定节点的度量值 +kubectl cluster-info # 显示主控节点和服务的地址 +kubectl cluster-info dump # 将当前集群状态转储到标准输出 kubectl cluster-info dump --output-directory=/path/to/cluster-state # 将当前集群状态输出到 /path/to/cluster-state -# 如果已存在具有该键和效果的污点，则其值将按指定替换 +# 如果已存在具有指定键和效果的污点，则替换其值为指定值 kubectl taint nodes foo dedicated=special-user:NoSchedule ``` - + ### 资源类型 - -列出全部支持的资源类型和它们的简称, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), 无论它们是否是 [namespaced](/docs/concepts/overview/working-with-objects/namespaces), [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 + +列出所支持的全部资源类型和它们的简称、[API 组](/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 ```bash kubectl api-resources ``` - + 用于探索 API 资源的其他操作： - +``` +--> ```bash -kubectl api-resources --namespaced=true # 所有在命名空间中的资源 -kubectl api-resources --namespaced=false # 所有不在命名空间中的资源 -kubectl api-resources -o name # 输出简单的所有资源（只是资源名称） -kubectl api-resources -o wide # 具有扩展（又称 "wide"）输出的所有资源 +kubectl api-resources --namespaced=true # 所有命名空间作用域的资源 +kubectl api-resources --namespaced=false # 所有非命名空间作用域的资源 +kubectl api-resources -o name # 用简单格式列举所有资源（仅显示资源名称） +kubectl api-resources -o wide # 用扩展格式列举所有资源（又称 "wide" 格式） kubectl api-resources --verbs=list,get # 支持 "list" 和 "get" 请求动词的所有资源 kubectl api-resources --api-group=extensions # "extensions" API 组中的所有资源 ``` - + ### 格式化输出 - 要以特定格式将详细信息输出到终端窗口，可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令。 - -输出格式 | 描述 +`-o=yaml` | Output a YAML formatted API object +--> +输出格式 | 描述 --------------| ----------- -`-o=custom-columns=` | 使用逗号分隔的自定义列列表打印表格 +`-o=custom-columns=` | 使用逗号分隔的自定义列来打印表格 `-o=custom-columns-file=` | 使用 `` 文件中的自定义列模板打印表格 `-o=json` | 输出 JSON 格式的 API 对象 `-o=jsonpath=