zh-trans: add missing trans from 1.12 branch (#15189)

2019-06-29 11:47:23 +08:00
parent 66e25732bf
commit b715a8a40f
3 changed files with 1611 additions and 0 deletions
@@ -0,0 +1,259 @@
 ---
 title: 推荐使用的标签
 content_template: templates/concept
 ---
 <!--
 ---
 title: Recommended Labels
 content_template: templates/concept
 ---
 -->
 {{% capture overview %}}
 <!--
 You can visualize and manage Kubernetes objects with more tools than kubectl and
 the dashboard. A common set of labels allows tools to work interoperably, describing
 objects in a common manner that all tools can understand.
 -->
 除了 kubectl 和 dashboard 之外，您可以其他工具来可视化和管理 Kubernetes 对象。
 一组通用的标签可以让多个工具之间互操作，用所有工具都能理解的通用方式描述对象。
 <!--
 In addition to supporting tooling, the recommended labels describe applications
 in a way that can be queried.
 -->
 除了支持工具外，推荐的标签还以一种可以查询的方式描述了应用程序。
 {{% /capture %}}
 {{% capture body %}}
 <!--
 The metadata is organized around the concept of an _application_. Kubernetes is not
 a platform as a service (PaaS) and doesn't have or enforce a formal notion of an application.
 Instead, applications are informal and described with metadata. The definition of
 what an application contains is loose.
 -->
 元数据围绕 _应用（application）_ 的概念进行组织。Kubernetes 不是
 平台即服务（PaaS），没有或强制执行正式的应用程序概念。
 相反，应用程序是非正式的，并使用元数据进行描述。应用程序包含的定义是松散的。
 {{< note >}}
 <!--
 These are recommended labels. They make it easier to manage applications
 but aren't required for any core tooling.
 -->
 这些是推荐的标签。它们使管理应用程序变得更容易但不是任何核心工具所必需的。
 {{< /note >}}
 <!--
 Shared labels and annotations share a common prefix: `app.kubernetes.io`. Labels
 without a prefix are private to users. The shared prefix ensures that shared labels
 do not interfere with custom user labels.
 -->
 共享标签和注解都使用同一个前缀：`app.kubernetes.io`。没有前缀的标签是用户私有的。共享前缀可以确保共享标签不会干扰用户自定义的标签。
 <!--
 ## Labels
 In order to take full advantage of using these labels, they should be applied
 on every resource object.
 -->
 ## 标签
 为了充分利用这些标签，应该在每个资源对象上都使用它们。
 <!--
 | Key                                 | Description           | Example  | Type |
 | ----------------------------------- | --------------------- | -------- | ---- |
 | `app.kubernetes.io/name`            | The name of the application | `mysql` | string |
 | `app.kubernetes.io/instance`        | A unique name identifying the instance of an application | `wordpress-abcxzy` | string |
 | `app.kubernetes.io/version`         | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
 | `app.kubernetes.io/component`       | The component within the architecture | `database` | string |
 | `app.kubernetes.io/part-of`         | The name of a higher level application this one is part of | `wordpress` | string |
 | `app.kubernetes.io/managed-by`  | The tool being used to manage the operation of an application | `helm` | string |
 -->
 | 键                                 | 描述           | 示例  | 类型 |
 | ----------------------------------- | --------------------- | -------- | ---- |
 | `app.kubernetes.io/name`            | 应用程序的名称 | `mysql` | 字符串 |
 | `app.kubernetes.io/instance`        | 用于唯一确定应用实例的名称 | `wordpress-abcxzy` | 字符串 |
 | `app.kubernetes.io/version`         | 应用程序的当前版本（例如，语义版本，修订版哈希等） | `5.7.21` | 字符串 |
 | `app.kubernetes.io/component`       | 架构中的组件 | `database` | 字符串 |
 | `app.kubernetes.io/part-of`         | 此级别的更高级别应用程序的名称 | `wordpress` | 字符串 |
 | `app.kubernetes.io/managed-by`  | 用于管理应用程序的工具 | `helm` | 字符串 |
 <!--
 To illustrate these labels in action, consider the following StatefulSet object:
 -->
 为说明这些标签的实际使用情况，请看下面的 StatefulSet 对象：
 ```yaml
 apiVersion: apps/v1
 kind: StatefulSet
 metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm
 ```
 <!--
 ## Applications And Instances Of Applications
 An application can be installed one or more times into a Kubernetes cluster and,
 in some cases, the same namespace. For example, wordpress can be installed more
 than once where different websites are different installations of wordpress.
 The name of an application and the instance name are recorded separately. For
 example, WordPress has a `app.kubernetes.io/name` of `wordpress` while it has
 an instance name, represented as `app.kubernetes.io/instance` with a value of
 `wordpress-abcxzy`. This enables the application and instance of the application
 to be identifiable. Every instance of an application must have a unique name.
 -->
 ## 应用和应用实例
 应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。例如，可以不止一次地为不同的站点安装不同的 wordpress。
 应用的名称和实例的名称是分别记录的。例如，某 WordPress 实例的 `app.kubernetes.io/name` 为 `wordpress`，而其实例名称表现为 `app.kubernetes.io/instance` 的属性值 `wordpress-abcxzy`。这使应用程序和应用程序的实例成为可能是可识别的。应用程序的每个实例都必须具有唯一的名称。
 <!--
 ## Examples
 -->
 ## 示例
 <!--
 To illustrate different ways to use these labels the following examples have varying complexity.
 -->
 为了说明使用这些标签的不同方式，以下示例具有不同的复杂性。
 <!--
 ### A Simple Stateless Service
 -->
 ### 一个简单的无状态服务
 <!--
 Consider the case for a simple stateless service deployed using `Deployment` and `Service` objects. The following two snippets represent how the labels could be used in their simplest form.
 -->
 考虑使用 `Deployment` 和 `Service` 对象部署的简单无状态服务的情况。以下两个代码段表示如何以最简单的形式使用标签。
 <!--
 The `Deployment` is used to oversee the pods running the application itself.
 -->
 下面的 `Deployment` 用于监督运行应用本身的 pods。
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
 metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
 ...
 ```
 <!--
 The `Service` is used to expose the application.
 -->
 下面的 `Service` 用于暴露应用。
 ```yaml
 apiVersion: v1
 kind: Service
 metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
 ...
 ```
 <!--
 ### Web Application With A Database
 -->
 ### 带有一个数据库的 Web 应用程序
 <!--
 Consider a slightly more complicated application: a web application (WordPress)
 using a database (MySQL), installed using Helm. The following snippets illustrate
 the start of objects used to deploy this application.
 The start to the following `Deployment` is used for WordPress:
 -->
 考虑一个稍微复杂的应用：一个使用 Helm 安装的 Web 应用（WordPress），其中
 使用了数据库（MySQL）。以下代码片段说明用于部署此应用程序的对象的开始。
 以下 `Deployment` 的开头用于 WordPress：
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
 metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
 ...
 ```
 <!--
 The `Service` is used to expose WordPress:
 -->
 这个 `Service` 用于暴露 WordPress：
 ```yaml
 apiVersion: v1
 kind: Service
 metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
 ...
 ```
 <!--
 MySQL is exposed as a `StatefulSet` with metadata for both it and the larger application it belongs to:
 -->
 MySQL 作为一个 `StatefulSet` 暴露，包含它和它所属的较大应用程序的元数据：
 ```yaml
 apiVersion: apps/v1
 kind: StatefulSet
 metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/version: "5.7.21"
 ...
 ```
 <!--
 The `Service` is used to expose MySQL as part of WordPress:
 -->
 `Service` 用于将 MySQL 作为 WordPress 的一部分暴露：
 ```yaml
 apiVersion: v1
 kind: Service
 metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/version: "5.7.21"
 ...
 ```
 <!--
 With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and Wordpress, the broader application, are included.
 -->
 使用 MySQL `StatefulSet` 和 `Service`，您会注意到有关 MySQL 和 Wordpress 的信息，包括更广泛的应用程序。
 {{% /capture %}}
@@ -0,0 +1,663 @@
 ---
 title: kubectl Cheat Sheet
 reviewers:
 - bgrant0607
 - erictune
 - krousey
 - clove
 content_template: templates/concept
 ---
 {{% capture overview %}}
 <!--
 See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath).
 -->
 也可以看下：[Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。
 <!--
 This page is an overview of the `kubectl` command.
 -->
 本页面是 `kubectl` 命令的概述。
 {{% /capture %}}
 {{% capture body %}}
 # kubectl - Cheat Sheet
 <!--
 ## Kubectl Autocomplete
 -->
 ## Kubectl 自动补全
 ### BASH
 <!--
 ```bash
 source <(kubectl completion bash) # setup autocomplete in bash into the current shell, bash-completion package should be installed first.
 echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.
 ```
 -->
 ```bash
 source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全，要先安装 bash-completion 包。
 echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全
 ```
 ### ZSH
 <!--
 ```bash
 source <(kubectl completion zsh)  # setup autocomplete in zsh into the current shell
 echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # add autocomplete permanently to your zsh shell
 ```
 -->
 ```bash
 source <(kubectl completion zsh)  # 在 zsh 中设置当前 shell 的自动补全
 echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全
 ```
 <!--
 ## Kubectl Context and Configuration
 Set which Kubernetes cluster `kubectl` communicates with and modifies configuration
 information. See [Authenticating Across Clusters with kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation for
 detailed config file information.
 -->
 ##  Kubectl 上下文和配置
 设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 [使用 kubeconfig 跨集群授权访问
 ](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取详情配置文件信息。
 <!--
 ```bash
 kubectl config view # Show Merged kubeconfig settings.
 # use multiple kubeconfig files at the same time and view merged config
 KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view
 # Get the password for the e2e user
 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
 kubectl config current-context              # Display the current-context
 kubectl config use-context my-cluster-name  # set the default context to my-cluster-name
 # add a new cluster to your kubeconf that supports basic auth
 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
 # set a context utilizing a specific username and namespace.
 kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce
 ```
 -->
 ```bash
 kubectl config view # 显示合并的 kubeconfig 配置。
 # 同时使用多个 kubeconfig 文件并查看合并的配置
 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
 # 添加新的集群配置到 kubeconf 中，使用 basic auth 进行鉴权
 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
 # 使用特定的用户名和命名空间设置上下文。
 kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce
 ```
 <!--
 ## Creating Objects
 Kubernetes manifests can be defined in json or yaml. The file extension `.yaml`,
 `.yml`, and `.json` can be used.
 -->
 ## 创建对象
 Kubernetes 配置可以用 json 或 yaml 定义。可以使用的文件扩展名有 `.yaml`，
 `.yml` 和 `.json` 。
 <!--
 ```bash
 kubectl create -f ./my-manifest.yaml           # create resource(s)
 kubectl create -f ./my1.yaml -f ./my2.yaml     # create from multiple files
 kubectl create -f ./dir                        # create resource(s) in all manifest files in dir
 kubectl create -f https://git.io/vPieo         # create resource(s) from url
 kubectl run nginx --image=nginx                # start a single instance of nginx
 kubectl explain pods,svc                       # get the documentation for pod and svc manifests
 # Create multiple YAML objects from stdin
 cat <<EOF | kubectl create -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-sleep
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
 ---
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-sleep-less
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000"
 EOF
 # Create a secret with several keys
 cat <<EOF | kubectl create -f -
 apiVersion: v1
 kind: Secret
 metadata:
  name: mysecret
 type: Opaque
 data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
 EOF
 ```
 -->
 ```bash
 kubectl create -f ./my-manifest.yaml           # 创建资源
 kubectl create -f ./my1.yaml -f ./my2.yaml     # 使用多个文件创建
 kubectl create -f ./dir                        # 从目录下的全部配置文件创建资源
 kubectl create -f https://git.io/vPieo         # 从 url 中创建资源
 kubectl run nginx --image=nginx                # 启动单实例 nginx
 kubectl explain pods,svc                       # 获取 pod，svc 配置的文档说明
 # 从标准输入中的多个 YAML 对象中创建
 cat <<EOF | kubectl create -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-sleep
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
 ---
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-sleep-less
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000"
 EOF
 # 创建有多个 key 的 Secret
 cat <<EOF | kubectl create -f -
 apiVersion: v1
 kind: Secret
 metadata:
  name: mysecret
 type: Opaque
 data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
 EOF
 ```
 <!--
 ## Viewing, Finding Resources
 -->
 ## 获取和查找资源
 <!--
 ```bash
 # Get commands with basic output
 kubectl get services                          # List all services in the namespace
 kubectl get pods --all-namespaces             # List all pods in all namespaces
 kubectl get pods -o wide                      # List all pods in the namespace, with more details
 kubectl get deployment my-dep                 # List a particular deployment
 kubectl get pods --include-uninitialized      # List all pods in the namespace, including uninitialized ones
 # Describe commands with verbose output
 kubectl describe nodes my-node
 kubectl describe pods my-pod
 kubectl get services --sort-by=.metadata.name # List Services Sorted by Name
 # List pods Sorted by Restart Count
 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
 # Get the version label of all pods with label app=cassandra
 kubectl get pods --selector=app=cassandra rc -o \
  jsonpath='{.items[*].metadata.labels.version}'
 # Get all running pods in the namespace
 kubectl get pods --field-selector=status.phase=Running
 # Get ExternalIPs of all nodes
 kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
 # List Names of Pods that belong to Particular RC
 # "jq" command useful for transformations that are too complex for jsonpath, it can be found at 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})
 # Check which nodes are ready
 JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
 # List all Secrets currently in use by a pod
 kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
 # List Events sorted by timestamp
 kubectl get events --sort-by=.metadata.creationTimestamp
 ```
 -->
 ```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，包含未初始化的
 # 使用 describe 命令获取详细输出
 kubectl describe nodes my-node
 kubectl describe pods my-pod
 kubectl get services --sort-by=.metadata.name # 列出当前命名空间下所有 services，按照名称排序
 # 列出 pods 按照重启次数进行排序
 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
 # 获取包含 app=cassandra 标签全部 pods 的 version 标签
 kubectl get pods --selector=app=cassandra rc -o \
  jsonpath='{.items[*].metadata.labels.version}'
 # 获取当前命名空间中正在运行的 pods
 kubectl get pods --field-selector=status.phase=Running
 # 获取全部 node 的 ExternalIP 地址
 kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
 # 列出属于某个特定 RC 的 pods 的名称
 # "jq" 命令对于 jsonpath 过于复杂的转换非常有用，可以在 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})
 # 检查哪些节点处于 ready
 JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
 # 列出被一个 pod 使用的全部 secret
 kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
 # 列出 events，按照创建时间排序
 kubectl get events --sort-by=.metadata.creationTimestamp
 ```
 <!--
 ## Updating Resources
 As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)), use `rollout` instead.
 -->
 ## 更新资源
 从版本 1.11 开始，`rolling-update` 已被弃用（参见[CHANGELOG-1.11.md]（https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md）），请使用 `rollout` 代替。
 <!--
 ```bash
 kubectl set image deployment/frontend www=image:v2               # Rolling update "www" containers of "frontend" deployment, updating the image
 kubectl rollout undo deployment/frontend                         # Rollback to the previous deployment
 kubectl rollout status -w deployment/frontend                    # Watch rolling update status of "frontend" deployment until completion
 # deprecated starting version 1.11
 kubectl rolling-update frontend-v1 -f frontend-v2.json           # (deprecated) Rolling update pods of frontend-v1
 kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (deprecated) Change the name of the resource and update the image
 kubectl rolling-update frontend --image=image:v2                 # (deprecated) Update the pods image of frontend
 kubectl rolling-update frontend-v1 frontend-v2 --rollback        # (deprecated) Abort existing rollout in progress
 cat pod.json | kubectl replace -f -                              # Replace a pod based on the JSON passed into std
 # Force replace, delete and then re-create the resource. Will cause a service outage.
 kubectl replace --force -f ./pod.json
 # Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000
 kubectl expose rc nginx --port=80 --target-port=8000
 # Update a single-container pod's image version (tag) to v4
 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
 kubectl label pods my-pod new-label=awesome                      # Add a Label
 kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # Add an annotation
 kubectl autoscale deployment foo --min=2 --max=10                # Auto scale a deployment "foo"
 ```
 -->
 ```bash
 kubectl set image deployment/frontend www=image:v2               # 滚动更新 "frontend" deployment 的 "www" 容器镜像
 kubectl rollout undo deployment/frontend                         # 回滚到上次部署
 kubectl rollout status -w deployment/frontend                    # Watch "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
 # 强制进行替换，会删除然后再创建资源，会导致服务不可用。
 kubectl replace --force -f ./pod.json
 # 为多副本的 nginx 创建服务，使用 80 端口提供服务，连接到容器的 8000 端口。
 kubectl expose rc nginx --port=80 --target-port=8000
 # 更新单容器 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 自动伸缩容
 ```
 <!--
 ## Patching Resources
 -->
 ## 局部更新资源
 <!--
 ```bash
 kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # Partially update a node
 # Update a container's image; spec.containers[*].name is required because it's a merge key
 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
 # Update a container's image using a json patch with positional arrays
 kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
 # Disable a deployment livenessProbe using a json patch with positional arrays
 kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
 # Add a new element to a positional array 
 kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
 ```
 -->
 ```bash
 kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新 node 
 # 更新容器的镜像；spec.containers[*].name 是必须的因为它是一个合并 key。
 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
 # 使用带位置数组的 json patch 更新容器的镜像
 kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
 # 使用带位置数组的 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" } }]'
 ```
 <!--
 ## Editing Resources
 The edit any API resource in an editor.
 ```bash
 kubectl edit svc/docker-registry                      # Edit the service named docker-registry
 KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # Use an alternative editor
 ```
 -->
 ## 编辑资源
 在编辑器中编辑任何 API 资源
 ```bash
 kubectl edit svc/docker-registry                      # 编辑名为 docker-registry 的 service
 KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # 使用其他编辑器
 ```
 <!--
 ## Scaling Resources
 ```bash
 kubectl scale --replicas=3 rs/foo                                 # Scale a replicaset named 'foo' to 3
 kubectl scale --replicas=3 -f foo.yaml                            # Scale a resource specified in "foo.yaml" to 3
 kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # If the deployment named mysql's current size is 2, scale mysql to 3
 kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Scale multiple replication controllers
 ```
 -->
 ## 对资源进行伸缩
 ```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
 ```
 <!--
 ## Deleting Resources
 ```bash
 kubectl delete -f ./pod.json                                              # Delete a pod using the type and name specified in pod.json
 kubectl delete pod,service baz foo                                        # Delete pods and services with same names "baz" and "foo"
 kubectl delete pods,services -l name=myLabel                              # Delete pods and services with label name=myLabel
 kubectl delete pods,services -l name=myLabel --include-uninitialized      # Delete pods and services, including uninitialized ones, with label name=myLabel
 kubectl -n my-ns delete po,svc --all                                      # Delete all pods and services, including uninitialized ones, in namespace my-ns,
 ```
 -->
 ## 删除资源
 ```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 ，包括未初始化的
 ```
 <!--
 ## Interacting with running Pods
 ```bash
 kubectl logs my-pod                                 # dump pod logs (stdout)
 kubectl logs my-pod --previous                      # dump pod logs (stdout) for a previous instantiation of a container
 kubectl logs my-pod -c my-container                 # dump pod container logs (stdout, multi-container case)
 kubectl logs my-pod -c my-container --previous      # dump pod container logs (stdout, multi-container case) for a previous instantiation of a container
 kubectl logs -f my-pod                              # stream pod logs (stdout)
 kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case)
 kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell
 kubectl attach my-pod -i                            # Attach to Running Container
 kubectl port-forward my-pod 5000:6000               # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
 kubectl exec my-pod -- ls /                         # Run command in existing pod (1 container case)
 kubectl exec my-pod -c my-container -- ls /         # Run command in existing pod (multi-container case)
 kubectl top pod POD_NAME --containers               # Show metrics for a given pod and its containers
 ```
 -->
 ## 与运行中的 Pods 进行交互
 ```bash
 kubectl logs my-pod                                 # 获取 pod 日志(标准输出)
 kubectl logs my-pod --previous                      # 获取上个容器实例的 pod 日志(标准输出)
 kubectl logs my-pod -c my-container                 # 获取 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 run -i --tty busybox --image=busybox -- sh  # 以交互式 shell 运行 Pod
 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 和容器的监控数据
 ```
 <!--
 ## Interacting with Nodes and Cluster
 ```bash
 kubectl cordon my-node                                                # Mark my-node as unschedulable
 kubectl drain my-node                                                 # Drain my-node in preparation for maintenance
 kubectl uncordon my-node                                              # Mark my-node as schedulable
 kubectl top node my-node                                              # Show metrics for a given node
 kubectl cluster-info                                                  # Display addresses of the master and services
 kubectl cluster-info dump                                             # Dump current cluster state to stdout
 kubectl cluster-info dump --output-directory=/path/to/cluster-state   # Dump current cluster state to /path/to/cluster-state
 # If a taint with that key and effect already exists, its value is replaced as specified.
 kubectl taint nodes foo dedicated=special-user:NoSchedule
 ```
 -->
 ## 与节点和集群进行交互
 ```bash
 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                                                  # 限制 master 和 services 的地址
 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
 ```
 <!--
 ### Resource types
 List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
 ```bash
 kubectl api-resources
 ```
 Other operations for exploring API resources:
 ```bash
 kubectl api-resources --namespaced=true      # All namespaced resources
 kubectl api-resources --namespaced=false     # All non-namespaced resources
 kubectl api-resources -o name                # All resources with simple output (just the resource name)
 kubectl api-resources -o wide                # All resources with expanded (aka "wide") output
 kubectl api-resources --verbs=list,get       # All resources that support the "list" and "get" request verbs
 kubectl api-resources --api-group=extensions # All resources in the "extensions" API group
 ```
 -->
 ### 资源类型
 列出全部支持的资源类型和它们的简称, [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):
 ```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 --verbs=list,get       # 支持"list"和"get"请求动词的所有资源
 kubectl api-resources --api-group=extensions # "extensions" API组中的所有资源
 ```
 <!--
 ### Formatting output
 To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command.
 Output format | Description
 --------------| -----------
 `-o=custom-columns=<spec>` | Print a table using a comma separated list of custom columns
 `-o=custom-columns-file=<filename>` | Print a table using the custom columns template in the `<filename>` file
 `-o=json`     | Output a JSON formatted API object
 `-o=jsonpath=<template>` | Print the fields defined in a [jsonpath](/docs/reference/kubectl/jsonpath) expression
 `-o=jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/docs/reference/kubectl/jsonpath) expression in the `<filename>` file
 `-o=name`     | Print only the resource name and nothing else
 `-o=wide`     | Output in the plain-text format with any additional information, and for pods, the node name is included
 `-o=yaml`     | Output a YAML formatted API object
 -->
 ### 格式化输出
 要以特定格式将详细信息输出到终端窗口，可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令.
 输出格式 | 描述
 --------------| -----------
 `-o=custom-columns=<spec>` | 使用逗号分隔的自定义列列表打印表格
 `-o=custom-columns-file=<filename>` | 使用 `<filename>` 文件中的自定义列模板打印表格
 `-o=json`     | 输出 JSON 格式的 API 对象
 `-o=jsonpath=<template>` | 打印 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式中定义的字段
 `-o=jsonpath-file=<filename>` | 打印 `<filename>` 文件中 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式定义的字段
 `-o=name`     | 仅打印资源名称而不打印任何其他内容
 `-o=wide`     | 使用任何其他信息以纯文本格式输出，对于 pod 来说，包含了节点名称
 `-o=yaml`     | 输出 YAML 格式的 API 对象
 <!--
 ### Kubectl output verbosity and debugging
 Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md).
 Verbosity | Description
 --------------| -----------
 `--v=0` | Generally useful for this to ALWAYS be visible to an operator.
 `--v=1` | A reasonable default log level if you don't want verbosity.
 `--v=2` | Useful steady state information about the service and important log messages that may correlate to significant changes in the system. This is the recommended default log level for most systems.
 `--v=3` | Extended information about changes.
 `--v=4` | Debug level verbosity.
 `--v=6` | Display requested resources.
 `--v=7` | Display HTTP request headers.
 `--v=8` | Display HTTP request contents.
 `--v=9` | Display HTTP request contents without truncation of contents.
 -->
 ### Kubectl 日志输出详细程度和调试
 Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的，参数后跟了一个数字表示日志的级别。Kubernetes 通用的日志习惯和相关的日志级别在 [这里](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md) 有相应的描述。
 详细程度 | 描述
 --------------| -----------
 `--v=0` | 通常对此有用，始终对运维人员可见。
 `--v=1` | 如果您不想要详细程度，则为合理的默认日志级别。
 `--v=2` | 有关服务的有用稳定状态信息以及可能与系统中的重大更改相关的重要日志消息。这是大多数系统的建议默认日志级别。
 `--v=3` | 有关更改的扩展信息。
 `--v=4` | Debug 级别。
 `--v=6` | 显示请求的资源。
 `--v=7` | 显示 HTTP 请求头。
 `--v=8` | 显示 HTTP 请求内容。
 `--v=9` | 显示 HTTP 请求内容而不截断内容。
 {{% /capture %}}
 {{% capture whatsnext %}}
 <!--
 * Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
 * See [kubectl](/docs/reference/kubectl/kubectl/) options.
 * Also [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use it in reusable scripts.
 * See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
 -->
 * 学习更多关于 [kubectl 概述](/docs/reference/kubectl/overview/)。
 * 查看 [kubectl](/docs/reference/kubectl/kubectl/) 的参数。
 * 也可以查看 [kubectl 使用约定](/docs/reference/kubectl/conventions/) 来理解如果在可以复用的脚本中使用它。
 * 查看更多社区的 [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。
 {{% /capture %}}
@@ -0,0 +1,689 @@
 ---
 reviewers:
 - dlorenc
 - balopat
 - aaron-prindle
 title: 使用 Minikube 在本地运行 Kubernetes
 content_template: templates/concept
 ---
 <!--
 ---
 reviewers:
 - dlorenc
 - balopat
 - aaron-prindle
 title: Running Kubernetes Locally via Minikube
 content_template: templates/concept
 ---
 -->
 {{% capture overview %}}
 <!--
 Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
 -->
 Minikube 是一个可以在本地轻松运行 Kubernetes 的工具。Minikube 在笔记本电脑的虚拟机中运行单节点 Kubernetes 集群，供那些希望尝试 Kubernetes 或对 Kubernetes 进行日常开发的用户使用。
 {{% /capture %}}
 {{% capture body %}}
 <!--
 ## Minikube Features
 -->
 ## Minikube 的特性
 <!--
 * Minikube supports Kubernetes features such as:
  * DNS
  * NodePorts
  * ConfigMaps and Secrets
  * Dashboards
  * Container Runtime: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) and [containerd](https://github.com/containerd/containerd)
  * Enabling CNI (Container Network Interface)
  * Ingress
 -->
 * Minikube 支持的 Kubernetes 特性如下：
  * DNS
  * NodePorts
  * ConfigMaps 和 Secrets
  * Dashboards
  * 容器运行时: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) 和 [containerd](https://github.com/containerd/containerd)
  * 启用 CNI (Container Network Interface)
  * Ingress
 <!--
 ## Installation
 See [Installing Minikube](/docs/tasks/tools/install-minikube/).
 -->
 ## 安装
 查看 [安装 Minikube](/docs/tasks/tools/install-minikube/)。
 <!--
 ## Quickstart
 Here's a brief demo of Minikube usage.
 If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube supports
 the following drivers:
 -->
 ## 快速入门
 下面是 Minikube 用法的简单示例。
 如果您想要更改 VM 驱动，可以添加合适的 `--vm-driver=xxx` 到 `minikube start` 命令。Minikube 支持下面的驱动：
 * virtualbox
 * vmwarefusion
 * kvm2 ([安装驱动](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
 * kvm ([安装驱动](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver))
 * hyperkit ([安装驱动](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
 * xhyve ([安装驱动](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (deprecated)
 <!--
 Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`.
 -->
 注意下面的 IP 是动态的、可能不同的。它可以通过 `minikube ip` 获取。
 ```shell
 $ minikube start
 Starting local Kubernetes cluster...
 Running pre-create checks...
 Creating machine...
 Starting local Kubernetes cluster...
 $ kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
 deployment.apps/hello-minikube created
 $ kubectl expose deployment hello-minikube --type=NodePort
 service/hello-minikube exposed
 # 现在我们启动了一个 echoserver pod，但是必须等待这个 pod 启动成功后才可以通过暴露的服务对它进行访问。
 # 要检查这个 pod 是否启动并运行，我们可以使用下面的命令：
 $ kubectl get pod
 NAME                              READY     STATUS              RESTARTS   AGE
 hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
 # 我们可以从 ContainerCreating 的状态得知，这个 pod 仍然处于创建中。
 $ kubectl get pod
 NAME                              READY     STATUS    RESTARTS   AGE
 hello-minikube-3383150820-vctvh   1/1       Running   0          13s
 # 我们可以看到这个 pod 现在处于 Running 状态，我们可以对它执行 curl:
 $ curl $(minikube service hello-minikube --url)
 Hostname: hello-minikube-7c77b68cff-8wdzq
 Pod Information:
 	-no pod information available-
 Server values:
 	server_version=nginx: 1.13.3 - lua: 10008
 Request Information:
 	client_address=172.17.0.1
 	method=GET
 	real path=/
 	query=
 	request_version=1.1
 	request_scheme=http
 	request_uri=http://192.168.99.100:8080/
 Request Headers:
 	accept=*/*
 	host=192.168.99.100:30674
 	user-agent=curl/7.47.0
 Request Body:
 	-no body in request-
 $ kubectl delete services hello-minikube
 service "hello-minikube" deleted
 $ kubectl delete deployment hello-minikube
 deployment.extensions "hello-minikube" deleted
 $ minikube stop
 Stopping local Kubernetes cluster...
 Stopping "minikube"...
 ```
 <!--
 ### Alternative Container Runtimes
 -->
 ### 其他容器运行时
 #### containerd
 <!--
 To use [containerd](https://github.com/containerd/containerd) as the container runtime, run:
 -->
 要使用 [containerd](https://github.com/containerd/containerd) 作为容器运行时，运行：
 ```bash
 $ minikube start \
    --network-plugin=cni \
    --container-runtime=containerd \
    --bootstrapper=kubeadm
 ```
 <!--
 Or you can use the extended version:
 -->
 或者您可以使用命令的扩展版本：
 ```bash
 $ minikube start \
    --network-plugin=cni \
    --extra-config=kubelet.container-runtime=remote \
    --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
    --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
    --bootstrapper=kubeadm
 ```
 #### CRI-O
 <!--
 To use [CRI-O](https://github.com/kubernetes-incubator/cri-o) as the container runtime, run:
 -->
 要使用 [CRI-O](https://github.com/kubernetes-incubator/cri-o) 作为容器运行时，运行：
 ```bash
 $ minikube start \
    --network-plugin=cni \
    --container-runtime=cri-o \
    --bootstrapper=kubeadm
 ```
 <!--
 Or you can use the extended version:
 -->
 或者您可以使用命令的扩展版本：
 ```bash
 $ minikube start \
    --network-plugin=cni \
    --extra-config=kubelet.container-runtime=remote \
    --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
    --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
    --bootstrapper=kubeadm
 ```
 #### rkt container engine
 <!--
 To use [rkt](https://github.com/rkt/rkt) as the container runtime run:
 -->
 要使用 [rkt](https://github.com/rkt/rkt) 作为容器的运行时，运行：
 ```shell
 $ minikube start \
    --network-plugin=cni \
    --container-runtime=rkt
 ```
 <!--
 This will use an alternative minikube ISO image containing both rkt, and Docker, and enable CNI networking.
 -->
 这将使用包含 rkt 和 Docker 的替代 minikube ISO 映像，并启用 CNI 网络。
 <!--
 ### Driver plugins
 -->
 ### 驱动插件
 <!--
 See [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) for details on supported drivers and how to install
 plugins, if required.
 -->
 如有需要，可以查看 [驱动](https://git.k8s.io/minikube/docs/drivers.md) 查阅支持的驱动的细节和如何安装插件。
 <!--
 ### Use local images by re-using the Docker daemon
 -->
 ### 通过重用 Docker daemon 来使用本地镜像
 <!--
 When using a single VM of Kubernetes, it's really handy to reuse the Minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet.
 -->
 当使用只有单个 VM 的 Kubernetes 集群时，重用 Minikube 的内置 Docker daemon 非常方便; 因为这意味着您不必在宿主机上构建 docker regitstry 并将镜像 push 进去 - 您可以在与 minikube 相同的 docker daemon 内部构建，从而加速本地实验。只需确保使用 'latest' 之外的其他标签标记 Docker 镜像，并在拉取镜像时使用该标签。否则，如果你没有指定镜像的版本，它将被假定为`：latest`，相应的拉取镜像策略为 `Always`，最终可能导致 `ErrImagePull`，因为您可能在默认的 docker registry（通常是 DockerHub ）中还没有任何版本的镜像。
 <!--
 To be able to work with the docker daemon on your mac/linux host use the `docker-env command` in your shell:
 -->
 为了能够在 mac/linux 主机上使用 docker daemon，请在 shell 中使用 `docker-env command`：
 ```shell
 eval $(minikube docker-env)
 ```
 <!--
 You should now be able to use docker on the command line on your host mac/linux machine talking to the docker daemon inside the minikube VM:
 -->
 现在您应该可以在您的 mac/linux 主机上使用 docker 命令与 minikube VM 中的 docker daemon 进行通信了：
 ```shell
 docker ps
 ```
 <!--
 On Centos 7, docker may report the following error:
 -->
 在 Centos 7 操作系统上，docker 可能报出下面的错误：
 ```shell
 Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
 ```
 <!--
 The fix is to update /etc/sysconfig/docker to ensure that Minikube's environment changes are respected:
 -->
 修复办法是更新 /etc/sysconfig/docker，确保 Minikube 的环境变量的变化和预期一致：
 ```shell
 < DOCKER_CERT_PATH=/etc/docker
 ---
 > if [ -z "${DOCKER_CERT_PATH}" ]; then
 >   DOCKER_CERT_PATH=/etc/docker
 > fi
 ```
 <!--
 Remember to turn off the imagePullPolicy:Always, otherwise Kubernetes won't use images you built locally.
 -->
 记得关闭 imagePullPolicy:Always，否则 Kubernetes 不会使用您在本地构建的镜像。
 <!--
 ## Managing your Cluster
 ### Starting a Cluster
 -->
 ## 管理您的集群
 ### 启动一个集群
 <!--
 The `minikube start` command can be used to start your cluster.
 This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
 This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster.
 If you are behind a web proxy, you will need to pass this information to the `minikube start` command:
 -->
 `minikube start` 命令可以用来启动您的集群。
 这个命令会创建和配置一个虚拟机，里面运行了一个单节点的 Kubernetes 集群。
 这个命令也会安装 [kubectl](/docs/user-guide/kubectl-overview/) 用于和集群进行通信。
 ```shell
 https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
 ```
 <!--
 Unfortunately just setting the environment variables will not work.
 Minikube will also create a "minikube" context, and set it to default in kubectl.
 To switch back to this context later, run this command: `kubectl config use-context minikube`.
 -->
 不幸的是，仅仅设置环境变量是不够的。
 Minikube 也会创建 "minikube" context，并且在 kubectl 把它设置为默认值。
 运行这个命令 `kubectl config use-context minikube` 可以再切换到这个 context。
 <!--
 #### Specifying the Kubernetes version
 -->
 #### 指定 Kubernetes 版本
 <!--
 You can specify the specific version of Kubernetes for Minikube to use by
 adding the `--kubernetes-version` string to the `minikube start` command. For
 example, to run version `v1.7.3`, you would run the following:
 -->
 您可以使用 `minikube start` 命令时，添加 `--kubernetes-version` 参数来指定 Minikube 的 Kubernetes 版本。例如，如果要运行 `v1.7.3` 版本，可以运行下面的命令：
 ```
 minikube start --kubernetes-version v1.7.3
 ```
 <!--
 ### Configuring Kubernetes
 -->
 ### 配置 Kubernetes
 <!--
 Minikube has a "configurator" feature that allows users to configure the Kubernetes components with arbitrary values.
 To use this feature, you can use the `--extra-config` flag on the `minikube start` command.
 This flag is repeated, so you can pass it several times with several different values to set multiple options.
 This flag takes a string of the form `component.key=value`, where `component` is one of the strings from the below list, `key` is a value on the
 configuration struct and `value` is the value to set.
 Valid keys can be found by examining the documentation for the Kubernetes `componentconfigs` for each component.
 Here is the documentation for each supported configuration:
 -->
 Minikube 有一个 "配置器" 特性，允许用户为 Kubernetes 组件配置任意值。要使用这个特性，您可以在使用 `minikube start` 时加上 `--extra-config` 参数。
 这个参数是可以重复的，所以您可以多次使用不同的值设置不同的选项。
 这个参数采用 `component.key=value` 形式的字符串，其中 `component` 是下面列表中的字符串，`key` 是配置结构的值，`value` 是配置项要设置的值。
 通过检查每个组件的 Kubernetes `componentconfigs` 文档，可以找到有效的键值。
 以下是每个支持配置的文档：
 * [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
 * [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions)
 * [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration)
 * [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration)
 * [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig)
 * [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration)
 <!--
 #### Examples
 To change the `MaxPods` setting to 5 on the Kubelet, pass this flag: `--extra-config=kubelet.MaxPods=5`.
 This feature also supports nested structs. To change the `LeaderElection.LeaderElect` setting to `true` on the scheduler, pass this flag: `--extra-config=scheduler.LeaderElection.LeaderElect=true`.
 To set the `AuthorizationMode` on the `apiserver` to `RBAC`, you can use: `--extra-config=apiserver.authorization-mode=RBAC`.
 -->
 #### 示例
 要在 Kubelet 上将 `MaxPods` 设置更改为 5，请传递此参数：`--extra-config=kubelet.MaxPods=5`。
 这个特性也支持嵌套结构。要把调度器的 `LeaderElection.LeaderElect` 设置为 `true`，传递这个参数 `--extra-config=scheduler.LeaderElection.LeaderElect=true`。
 <!--
 ### Stopping a Cluster
 The `minikube stop` command can be used to stop your cluster.
 This command shuts down the Minikube Virtual Machine, but preserves all cluster state and data.
 Starting the cluster again will restore it to it's previous state.
 -->
 ### 停止集群
 可以使用 `minikube stop` 命令来停止您的集群。这个命令会停止 Minikube 虚拟机，但是保留了集群里的所有状态和数据。重新启动这个集群会恢复到之前的状态。
 <!--
 ### Deleting a Cluster
 The `minikube delete` command can be used to delete your cluster.
 This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved.
 -->
 ### 删除集群
 可以使用 `minikube delete` 命令来删除您的集群。
 这个命令会停止和删除 Minikube 虚拟机。不会保留任何数据和状态。
 <!--
 ## Interacting with Your Cluster
 ### Kubectl
 The `minikube start` command creates a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) called "minikube".
 This context contains the configuration to communicate with your Minikube cluster.
 Minikube sets this context to default automatically, but if you need to switch back to it in the future, run:
 `kubectl config use-context minikube`,
 Or pass the context on each command like this: `kubectl get pods --context=minikube`.
 -->
 ## 和您的集群进行交互
 ### Kubectl
 `minikube start` 命令会创建一个叫做 "minikube"的 [kubectl 上下文](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-)。这个上下文包含了与您的 Minikube 集群进行通信的配置信息。
 Minikube 会自动将这个上下文设为默认值，如果您将来需要将它切回，运行：
 `kubectl config use-context minikube`，
 或者像这样在每个命令中传递这个上下文：`kubectl get pods --context=minikube`。
 <!--
 ### Dashboard
 To access the [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), run this command in a shell after starting Minikube to get the address:
 ```shell
 minikube dashboard
 ```
 -->
 ### Dashboard
 要访问 [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/)，在启动 Minikube 后在 shell 中执行此命令来获取访问地址：
 ```shell
 minikube dashboard
 ```
 <!--
 ### Services
 To access a service exposed via a node port, run this command in a shell after starting Minikube to get the address:
 ```shell
 minikube service [-n NAMESPACE] [--url] NAME
 ```
 -->
 ### Services
 要访问通过 node port 暴露的 service，在启动 Minikube 后在 shell 中执行此命令来获取访问地址：
 ```shell
 minikube service [-n NAMESPACE] [--url] NAME
 ```
 <!--
 ## Networking
 The Minikube VM is exposed to the host system via a host-only IP address, that can be obtained with the `minikube ip` command.
 Any services of type `NodePort` can be accessed over that IP address, on the NodePort.
 To determine the NodePort for your service, you can use a `kubectl` command like this:
 `kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
 -->
 ## 网络
 Minikube VM 通过一个 host-only IP 地址暴露给宿主机，这个 IP 可以通过 `minikube ip` 命令获取。任何的 `NodePort` 类型的 service 可以通过这个 IP 在 NodePort 上来访问。
 要确定服务的 NodePort，您可以使用这样的 `kubectl` 命令：
 `kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
 <!--
 ## Persistent Volumes
 Minikube supports [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) of type `hostPath`.
 These PersistentVolumes are mapped to a directory inside the Minikube VM.
 The Minikube VM boots into a tmpfs, so most directories will not be persisted across reboots (`minikube stop`).
 However, Minikube is configured to persist files stored under the following host directories:
 -->
 ## Persistent Volumes
 Minikube 支持 `hostPath` 类型的 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。
 这些 PersistentVolumes 被映射到 Minikube VM 里的目录中。
 * `/data`
 * `/var/lib/minikube`
 * `/var/lib/docker`
 <!--
 Here is an example PersistentVolume config to persist data in the `/data` directory:
 -->
 下面是一个将数据永久存储在 `/data` 的 PersistentVolume 配置示例：
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
 metadata:
  name: pv0001
 spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 5Gi
  hostPath:
    path: /data/pv0001/
 ```
 <!--
 ## Mounted Host Folders
 Some drivers will mount a host folder within the VM so that you can easily share files between the VM and host.  These are not configurable at the moment and different for the driver and OS you are using.
 {{< note >}}
 Host folder sharing is not implemented in the KVM driver yet.
 {{< /note >}}
 | Driver | OS | HostFolder | VM |
 | --- | --- | --- | --- |
 | VirtualBox | Linux | /home | /hosthome |
 | VirtualBox | macOS | /Users | /Users |
 | VirtualBox | Windows | C://Users | /c/Users |
 | VMware Fusion | macOS | /Users | /Users |
 | Xhyve | macOS | /Users | /Users |
 -->
 ## 挂载宿主机的目录
 一些驱动会在 VM 内挂载宿主机的目录，以便可以在 VM 和宿主机方便的共享文件。目前这些是不可配置的，而且根据您使用的 OS 和驱动而有所不同。
 {{< note >}}
 <!--
 Host folder sharing is not implemented in the KVM driver yet.
 -->
 目前 KVM 驱动尚未实现宿主机目录共享。
 {{< /note >}}
 | Driver | OS | HostFolder | VM |
 | --- | --- | --- | --- |
 | VirtualBox | Linux | /home | /hosthome |
 | VirtualBox | macOS | /Users | /Users |
 | VirtualBox | Windows | C://Users | /c/Users |
 | VMware Fusion | macOS | /Users | /Users |
 | Xhyve | macOS | /Users | /Users |
 <!--
 ## Private Container Registries
 To access a private container registry, follow the steps on [this page](/docs/concepts/containers/images/).
 We recommend you use `ImagePullSecrets`, but if you would like to configure access on the Minikube VM you can place the `.dockercfg` in the `/home/docker` directory or the `config.json` in the `/home/docker/.docker` directory.
 -->
 ## 私有镜像仓库
 要访问私有镜像仓库，请按照 [这个页面](/docs/concepts/containers/images/) 的步骤进行操作。
 我们推荐您使用 `ImagePullSecrets`，但是如果您想要配置在 Minikube VM 上能够访问，您可以把 `.dockercfg` 放在 `/home/docker` 目录或者把 `config.json` 放在 `/home/docker/.docker` 目录下。
 <!--
 ## Add-ons
 In order to have Minikube properly start or restart custom addons,
 place the addons you wish to be launched with Minikube in the `~/.minikube/addons`
 directory. Addons in this folder will be moved to the Minikube VM and
 launched each time Minikube is started or restarted.
 -->
 ## 插件
 为了能让 Minikube 能够正常地启动或者重启自定义插件，请把您要在 Minikube 里启动的插件放在 `~/.minikube/addons` 目录。在这个目录中的插件会被移动到 Minikube VM 中，并且在 Minikube 每次启动或者重启时启动。
 <!--
 ## Using Minikube with an HTTP Proxy
 Minikube creates a Virtual Machine that includes Kubernetes and a Docker daemon.
 When Kubernetes attempts to schedule containers using Docker, the Docker daemon may require external network access to pull containers.
 If you are behind an HTTP proxy, you may need to supply Docker with the proxy settings.
 To do this, pass the required environment variables as flags during `minikube start`.
 For example:
 ```shell
 $ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
                 --docker-env https_proxy=https://$YOURPROXY:PORT
 ```
 If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent `kubectl` from directly reaching it.
 To by-pass proxy configuration for this IP address, you should modify your no_proxy settings. You can do so with:
 ```shell
 $ export no_proxy=$no_proxy,$(minikube ip)
 ```
 -->
 ## 在 Minikube 中使用 HTTP 代理
 Minikube 创建了一个包含了 Kubernetes 和 Docker daemon 的虚拟机。当 Kubernetes 尝试使用 Docker 调度容器时，Docker daemon 可能需要访问外部网络来拉取容器。
 如果您通过 HTTP 代理访问，您可能要设置 Docker 的代理配置。
 通过在运行 `minikube start` 时传入需要的环境变量来实现这个配置。
 例如：
 ```shell
 $ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
                 --docker-env https_proxy=https://$YOURPROXY:PORT
 ```
 如果您的虚拟机地址是 192.168.99.100，那么您的代理设置可能会阻止 `kubectl` 直接访问它。
 要绕过此 IP 地址的代理配置，您应该修改 no_proxy 设置。您可以这样做：
 ```shell
 $ export no_proxy=$no_proxy,$(minikube ip)
 ```
 <!--
 ## Known Issues
 * Features that require a Cloud Provider will not work in Minikube. These include:
  * LoadBalancers
 * Features that require multiple nodes. These include:
  * Advanced scheduling policies
 -->
 ## 已知问题
 * 需要 Cloud Provider 的特性在 Minikube 不能工作。这些特性包括：
  * LoadBalancer
 * 需要多个节点的特性 Minikube 也不支持。包括：
  * 高级调度策略
 <!--
 ## Design
 Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [kubeadm](https://github.com/kubernetes/kubeadm) to provision a Kubernetes cluster.
 For more information about Minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
 -->
 ## 设计
 Minikube 使用 [libmachine](https://github.com/docker/machine/tree/master/libmachine) 来提供虚拟机，使用 [kubeadm](https://github.com/kubernetes/kubeadm) 来提供 Kubernetes 集群。
 想要了解更多 Minikube 的信息，查看 [提议](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md)。
 <!--
 ## Additional Links
 * **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
 * **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests.
 * **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md).
 * **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md).
 * **Adding a New Addon**: For instruction on how to add a new addon for Minikube see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md).
 * **Updating Kubernetes**: For instructions on how to update Kubernetes see the [updating Kubernetes guide](https://git.k8s.io/minikube/docs/contributors/updating_kubernetes.md).
 -->
 ## 其他链接
 * **目标和非目标**: 对于 Minikube 项目的目标和非目标, 请查看我们的 [路线图](https://git.k8s.io/minikube/docs/contributors/roadmap.md)。
 * **开发指南**: 查看 [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) 来了解如果发起 pull requests。
 * **编译 Minikube**: 有关如何从源代码构建/测试 Minikube 的说明，请查看 [编译指南](https://git.k8s.io/minikube/docs/contributors/build_guide.md)。
 * **添加新的依赖**: 有关如何向 Minikube 添加新依赖项的说明，查看 [添加依赖指南](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)。
 * **添加新的组件**: 有关如何为 Minikube 添加新插件的说明，查看 [添加插件指南](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)。
 * **更新 Kubernetes**: 有关如何更新 Kubernetes 的说明，查看 [更新 Kubernetes 指南](https://git.k8s.io/minikube/docs/contributors/updating_kubernetes.md)。
 <!--
 ## Community
 Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
 -->
 ## 社区
 我们欢迎和鼓励所有的贡献、问题和评论！Minikube 开发者在 [Slack]（https://kubernetes.slack.com）上 #minikube 频道闲逛（获得邀请[这里](http://slack.kubernetes.io/)）。我们还有[kubernetes-dev Google Groups邮件列表]（https://groups.google.com/forum/#!forum/kubernetes-dev）。如果您要发布到列表中，请在主题前加上"minikube："
 {{% /capture %}}