Merge master into dev-1.20 to keep in sync

2020-10-07 15:36:49 -07:00
parent 5e7cb3f9ca 3d23e421d2
commit 59cf7a42b4
82 changed files with 3337 additions and 779 deletions
@@ -2,7 +2,7 @@
 name: Support Request
 about: Support request or question relating to Kubernetes Website project
 labels:
- triage/support
+- kind/support
 ---
 **This is Support**

@@ -29,4 +29,6 @@ RUN mkdir -p /usr/local/src && \

 WORKDIR /src

+USER hugo:hugo
+
 EXPOSE 1313
@@ -68,7 +68,7 @@ container-build: module-check
 	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --minify

 container-serve: module-check
-	$(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0
+	$(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0

 test-examples:
 	scripts/test_examples.sh install
@@ -15,7 +15,7 @@ Untuk informasi lebih lanjut mengenai tata cara melakukan kontribusi, kamu dapat

 * [Petunjuk Melakukan Kontribusi](https://kubernetes.io/docs/contribute/start/)
 * [Melakukan Tahap Staging pada Konten Dokumentasi yang telah Kamu Sediakan](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [Petunjuk Menggunakan Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Petunjuk Menggunakan Page Templates](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Petunjuk untuk Documentation Style](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Petunjuk untuk Melakukan Lokalisasi Dokumentasi Kubernetes](https://kubernetes.io/docs/contribute/localization/)

@@ -15,7 +15,7 @@ Per maggiori informazioni su come contribuire alla documentazione Kubernetes, ve

 * [Cominciare a contribuire](https://kubernetes.io/docs/contribute/start/)
 * [Vedere le modifiche localmente](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [Utilizzare i template delle pagine](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Utilizzare i template delle pagine](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Guida Stilistica per la documentazione di Kubernetes](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Tradurre la documentazione di Kubernetes](https://kubernetes.io/docs/contribute/localization/)

@@ -71,7 +71,7 @@ Try checking the current limit for open files:

 `launchctl limit maxfiles`

-Then run the following commands:
+Then run the following commands (adapted from https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c):

 ```
 #!/bin/sh
@@ -43,6 +43,14 @@ section {
  padding: 0 !important;
 }

+
+/* Emphasize first paragraph of running text on site front page */
+body.td-home main[role="main"] > section:first-of-type .content p:first-child {
+  line-height: 1.3em;
+  font-size: 1.4em;
+  margin-bottom: 1.5em;
+}
+
 #desktopShowVideoButton {
  border: none
 }
@@ -552,3 +560,10 @@ body.td-documentation {
  }
 }

+/* glossary tooltip */
+.glossary-tooltip {
+  display: inline-block;
+  border-bottom: 1px dotted black; /* If you want dots under the hoverable text */
+  color: black;
+  text-decoration: none !important;
+}
@@ -12,4 +12,16 @@ Add styles or override variables from the theme here. */
@import "tablet";
@import "desktop";

-$primary: #3371e3;
+$primary: #3371e3;
+
+// tooltip
+$tooltip-bg: #555;
+$tooltip-arrow-color: $tooltip-bg !default;
+$tooltip-arrow-width: 10px !default;
+$tooltip-opacity: 1 !default;
+$tooltip-color: #fff !default;
+$tooltip-max-width: 300px !default;
+$tooltip-font-size: 1rem;
+$tooltip-padding: 5px 8px;
+$tooltip-border-radius: 6px;
+$tooltip-font-weight: 400;
@@ -155,8 +155,7 @@ offlineSearch = false
 [params.pushAssets]
 css = [
  "callouts",
-  "styles",
-  "custom-jekyll/tags"
+  "styles"
 ]
 js = [
  "script"
@@ -6,7 +6,7 @@ cid: home

 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
-### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) is an open-source system for automating deployment, scaling, and management of containerized applications.
+[Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) is an open-source system for automating deployment, scaling, and management of containerized applications.

 It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444), combined with best-of-breed ideas and practices from the community.
 {{% /blocks/feature %}}
@@ -89,7 +89,7 @@ Volume cloning enables users to specify another PVC as a "DataSource" when provi
 - ExecutionHook API [designed to trigger hook commands](https://github.com/kubernetes/enhancements/issues/962) in the containers for different use cases is now Alpha.
 - Continued deprecation of extensions/v1beta1, apps/v1beta1, and apps/v1beta2 APIs; these extensions will be retired in 1.16!

-Check the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#kubernetes-v115-release-notes) for a complete list of notable features and fixes.
+Check the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md#kubernetes-v115-release-notes) for a complete list of notable features and fixes.

 **Availability**

@@ -0,0 +1,107 @@
+---
+title: "Contributing to the Development Guide"
+linkTitle: "Contributing to the Development Guide"
+Author: Erik L. Arneson
+Description: "A new contributor describes the experience of writing and submitting changes to the Kubernetes Development Guide."
+date: 2020-10-01
+canonicalUrl: https://www.kubernetes.dev/blog/2020/09/28/contributing-to-the-development-guide/
+resources:
+- src: "jorge-castro-code-of-conduct.jpg"
+  title: "Jorge Castro announcing the Kubernetes Code of Conduct during a weekly SIG ContribEx meeting."
+---
+
+When most people think of contributing to an open source project, I suspect they probably think of
+contributing code changes, new features, and bug fixes. As a software engineer and a long-time open
+source user and contributor, that's certainly what I thought. Although I have written a good quantity
+of documentation in different workflows, the massive size of the Kubernetes community was a new kind 
+of "client." I just didn't know what to expect when Google asked my compatriots and me at
+[Lion's Way](https://lionswaycontent.com/) to make much-needed updates to the Kubernetes Development Guide.
+
+*This article originally appeared on the [Kubernetes Contributor Community blog](https://www.kubernetes.dev/blog/2020/09/28/contributing-to-the-development-guide/).*
+
+## The Delights of Working With a Community
+
+As professional writers, we are used to being hired to write very specific pieces. We specialize in
+marketing, training, and documentation for technical services and products, which can range anywhere from relatively fluffy marketing emails to deeply technical white papers targeted at IT and developers. With 
+this kind of professional service, every deliverable tends to have a measurable return on investment. 
+I knew this metric wouldn't be present when working on open source documentation, but I couldn't
+predict how it would change my relationship with the project.
+
+One of the primary traits of the relationship between our writing and our traditional clients is that we
+always have one or two primary points of contact inside a company. These contacts are responsible
+for reviewing our writing and making sure it matches the voice of the company and targets the
+audience they're looking for. It can be stressful -- which is why I'm so glad that my writing
+partner, eagle-eyed reviewer, and bloodthirsty editor [Joel](https://twitter.com/JoelByronBarker)
+handles most of the client contact.
+
+I was surprised and delighted that all of the stress of client contact went out the window when
+working with the Kubernetes community.
+
+"How delicate do I have to be? What if I screw up? What if I make a developer angry? What if I make
+enemies?" These were all questions that raced through my mind and made me feel like I was
+approaching a field of eggshells when I first joined the `#sig-contribex` channel on the Kubernetes
+Slack and announced that I would be working on the
+[Development Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md).
+
+{{< imgproc jorge-castro-code-of-conduct Fit "800x450" >}}
+"The Kubernetes Code of Conduct is in effect, so please be excellent to each other." &mdash; Jorge
+Castro, SIG ContribEx co-chair
+{{< /imgproc >}}
+
+My fears were unfounded. Immediately, I felt welcome. I like to think this isn't just because I was
+working on a much needed task, but rather because the Kubernetes community is filled
+with friendly, welcoming people. During the weekly SIG ContribEx meetings, our reports on progress
+with the Development Guide were included immediately. In addition, the leader of the meeting would
+always stress that the [Kubernetes Code of Conduct](https://www.kubernetes.dev/resources/code-of-conduct/) was in
+effect, and that we should, like Bill and Ted, be excellent to each other.
+
+## This Doesn't Mean It's All Easy
+
+The Development Guide needed a pretty serious overhaul. When we got our hands on it, it was already
+packed with information and lots of steps for new developers to go through, but it was getting dusty
+with age and neglect. Documentation can really require a global look, not just point fixes.
+As a result, I ended up submitting a gargantuan pull request to the
+[Community repo](https://github.com/kubernetes/community): 267 additions and 88 deletions.
+
+The life cycle of a pull request requires a certain number of Kubernetes organization members to review and approve changes
+before they can be merged. This is a great practice, as it keeps both documentation and code in
+pretty good shape, but it can be tough to cajole the right people into taking the time for such a hefty
+review. As a result, that massive PR took 26 days from my first submission to final merge. But in
+the end, [it was successful](https://github.com/kubernetes/community/pull/5003).
+
+Since Kubernetes is a pretty fast-moving project, and since developers typically aren't really
+excited about writing documentation, I also ran into the problem that sometimes, the secret jewels
+that describe the workings of a Kubernetes subsystem are buried deep within the [labyrinthine mind of
+a brilliant engineer](https://github.com/amwat), and not in plain English in a Markdown file. I ran headlong into this issue
+when it came time to update the getting started documentation for end-to-end (e2e) testing. 
+
+This portion of my journey took me out of documentation-writing territory and into the role of a
+brand new user of some unfinished software. I ended up working with one of the developers of the new
+[`kubetest2` framework](https://github.com/kubernetes-sigs/kubetest2) to document the latest process of
+getting up-and-running for e2e testing, but it required a lot of head scratching on my part. You can
+judge the results for yourself by checking out my
+[completed pull request](https://github.com/kubernetes/community/pull/5045).
+
+## Nobody Is the Boss, and Everybody Gives Feedback
+
+But while I secretly expected chaos, the process of contributing to the Kubernetes Development Guide
+and interacting with the amazing Kubernetes community went incredibly smoothly. There was no
+contention. I made no enemies. Everybody was incredibly friendly and welcoming. It was *enjoyable*.
+
+With an open source project, there is no one boss. The Kubernetes project, which approaches being
+gargantuan, is split into many different special interest groups (SIGs), working groups, and
+communities. Each has its own regularly scheduled meetings, assigned duties, and elected
+chairpersons. My work intersected with the efforts of both SIG ContribEx (who watch over and seek to
+improve the contributor experience) and SIG Testing (who are in charge of testing). Both of these
+SIGs proved easy to work with, eager for contributions, and populated with incredibly friendly and
+welcoming people.
+
+In an active, living project like Kubernetes, documentation continues to need maintenance, revision,
+and testing alongside the code base. The Development Guide will continue to be crucial to onboarding
+new contributors to the Kubernetes code base, and as our efforts have shown, it is important that
+this guide keeps pace with the evolution of the Kubernetes project.
+
+Joel and I really enjoy interacting with the Kubernetes community and contributing to
+the Development Guide. I really look forward to continuing to not only contributing more, but to
+continuing to build the new friendships I've made in this vast open source community over the past
+few months.
@@ -438,7 +438,7 @@ If you want to use project quotas, you should:
  [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
  in the kubelet configuration.

-* Ensure that the the root filesystem (or optional runtime filesystem)
+* Ensure that the root filesystem (or optional runtime filesystem)
  has project quotas enabled. All XFS filesystems support project quotas.
  For ext4 filesystems, you need to enable the project quota tracking feature
  while the filesystem is not mounted.
@@ -181,8 +181,8 @@ are accounted for in Kubernetes.
 ## {{% heading "whatsnext" %}}


- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
+- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
+- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
 - Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept
 - [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)

@@ -44,9 +44,9 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
 * [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
  [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
-* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
+* [Traefik](https://github.com/traefik/traefik) is a fully featured ingress controller
  ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
-  support by [Containous](https://containo.us/services).
+  support by [Traefik Labs](https://traefik.io).

 ## Using multiple Ingress controllers

@@ -411,7 +411,7 @@ type: kubernetes.io/tls
 Referencing this secret in an Ingress tells the Ingress controller to
 secure the channel from the client to the load balancer using TLS. You need to make
 sure the TLS secret you created came from a certificate that contains a Common
-Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `sslexample.foo.com`.
+Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `https-example.foo.com`.

 {{< codenew file="service/networking/tls-example-ingress.yaml" >}}

@@ -28,8 +28,8 @@ Init containers are exactly like regular containers, except:
 * Init containers always run to completion.
 * Each init container must complete successfully before the next one starts.

-If a Pod's init container fails, Kubernetes repeatedly restarts the Pod until the init container
-succeeds. However, if the Pod has a `restartPolicy` of Never, Kubernetes does not restart the Pod.
+If a Pod's init container fails, the kubelet repeatedly restarts that init container until it succeeds. 
+However, if the Pod has a `restartPolicy` of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed.

 To specify an init container for a Pod, add the `initContainers` field into
 the Pod specification, as an array of objects of type
@@ -342,7 +342,9 @@ place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts gr
 shutdown.

 Typically, the container runtime sends a TERM signal to the main process in each
-container. Once the grace period has expired, the KILL signal is sent to any remaining
+container. Many container runtimes respect the `STOPSIGNAL` value defined in the container
+image and send this instead of TERM.
+Once the grace period has expired, the KILL signal is sent to any remaining
 processes, and the Pod is then deleted from the
 {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
 container runtime's management service is restarted while waiting for processes to terminate, the
@@ -353,9 +355,9 @@ An example flow:
 1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period
   (30 seconds).
 1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead"
-   along with the grace period.  
+   along with the grace period.
   If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as
-   "Terminating".  
+   "Terminating".
   On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked
   as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
   shutdown process.
@@ -386,7 +388,7 @@ An example flow:
   `SIGKILL` to any processes still running in any container in the Pod.
   The kubelet also cleans up a hidden `pause` container if that container runtime uses one.
 1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period
-   to 0 (immediate deletion).  
+   to 0 (immediate deletion).
 1. The API server deletes the Pod's API object, which is then no longer visible from any client.

 ### Forced Pod termination {#pod-termination-forced}
@@ -190,7 +190,7 @@ close the issue without fixing.

 Some docs issues are actually issues with the underlying code, or requests for
 assistance when something, for example a tutorial, doesn't work.
-For issues unrelated to docs, close the issue with the `triage/support` label and a comment
+For issues unrelated to docs, close the issue with the `kind/support` label and a comment
 directing the requester to support venues (Slack, Stack Overflow) and, if
 relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes`
 is a great place to start).
@@ -31,6 +31,7 @@ be issued, based on a signing request.
 The CertificateSigningRequest object includes a PEM-encoded PKCS#10 signing request in
 the `spec.request` field. The CertificateSigningRequest denotes the _signer_ (the
 recipient that the request is being made to) using the `spec.signerName` field.
+Note that `spec.signerName` is a required key after api version `certificates.k8s.io/v1`.

 Once created, a CertificateSigningRequest must be approved before it can be signed.
 Depending on the signer selected, a CertificateSigningRequest may be automatically approved
@@ -106,8 +107,9 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
    1. Expiration/certificate lifetime - minimum of CSR signer or request.
    1. CA bit allowed/disallowed - not allowed.

-1. `kubernetes.io/legacy-unknown`:  has no guarantees for trust at all. Some distributions may honor these as client
-  certs, but that behavior is not standard Kubernetes behavior.
+1. `kubernetes.io/legacy-unknown`:  has no guarantees for trust at all. Some third-party distributions of Kubernetes
+  may honor client certificates signed by it. The stable CertificateSigningRequest API (version `certificates.k8s.io/v1` and later)
+  does not allow to set the `signerName` as `kubernetes.io/legacy-unknown`.
  Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
    1. Trust distribution: None.  There is no standard trust or distribution for this signer in a Kubernetes cluster.
    1. Permitted subjects - any
@@ -227,7 +229,7 @@ rules:

 ## Normal User

-There are a few steps are required in order to get normal user to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl.
+A few steps are required in order to get normal user to be able to authenticate and invoke an API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate to the API call as the Certificate Header or through the kubectl.

 ### Create Private Key

@@ -1096,37 +1096,37 @@ In order from most secure to least secure, the approaches are:

 2. Grant a role to the "default" service account in a namespace

-If an application does not specify a `serviceAccountName`, it uses the "default" service account.
+    If an application does not specify a `serviceAccountName`, it uses the "default" service account.

-{{< note >}}
-Permissions given to the "default" service account are available to any pod
-in the namespace that does not specify a `serviceAccountName`.
-{{< /note >}}
+    {{< note >}}
+    Permissions given to the "default" service account are available to any pod
+    in the namespace that does not specify a `serviceAccountName`.
+    {{< /note >}}

-For example, grant read-only permission within "my-namespace" to the "default" service account:
+    For example, grant read-only permission within "my-namespace" to the "default" service account:

-```shell
-kubectl create rolebinding default-view \
-  --clusterrole=view \
-  --serviceaccount=my-namespace:default \
-  --namespace=my-namespace
-```
+    ```shell
+    kubectl create rolebinding default-view \
+      --clusterrole=view \
+      --serviceaccount=my-namespace:default \
+      --namespace=my-namespace
+    ```

-Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
-"default" service account in the `kube-system` namespace.
-To allow those add-ons to run with super-user access, grant cluster-admin
-permissions to the "default" service account in the `kube-system` namespace.
+    Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
+    "default" service account in the `kube-system` namespace.
+    To allow those add-ons to run with super-user access, grant cluster-admin
+    permissions to the "default" service account in the `kube-system` namespace.

-{{< caution >}}
-Enabling this means the `kube-system` namespace contains Secrets
-that grant super-user access to your cluster's API.
-{{< /caution >}}
+    {{< caution >}}
+    Enabling this means the `kube-system` namespace contains Secrets
+    that grant super-user access to your cluster's API.
+    {{< /caution >}}

-```shell
-kubectl create clusterrolebinding add-on-cluster-admin \
-  --clusterrole=cluster-admin \
-  --serviceaccount=kube-system:default
-```
+    ```shell
+    kubectl create clusterrolebinding add-on-cluster-admin \
+      --clusterrole=cluster-admin \
+      --serviceaccount=kube-system:default
+    ```

 3. Grant a role to all service accounts in a namespace

@@ -1193,7 +1193,7 @@ the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-fo
 ```

 To explain that first command line option in detail: if earlier authorizers, such as Node,
-deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC
+deny a request, then the RBAC authorizer attempts to authorize the API request. If RBAC
 also denies that API request, the ABAC authorizer is then run. This means that any request
 allowed by *either* the RBAC or ABAC policies is allowed.

@@ -9,7 +9,6 @@ short_description: >
 aka:
 tags:
 - fundamental
- core-object
 ---
 An agent that runs on each {{< glossary_tooltip text="node" term_id="node" >}} in the cluster. It makes sure that {{< glossary_tooltip text="containers" term_id="container" >}} are running in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.

@@ -19,7 +19,7 @@ The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should us
 The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration.
 For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
 Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code.
-A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
+A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
 The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server.

 The following examples will show how you can interact with the health API endpoints.
@@ -573,7 +573,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
    Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
    ```

-    Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
+    Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.

 1. My Pods are stuck at "Container Creating" or restarting over and over

@@ -41,7 +41,7 @@ like `free -m`. This is important because `free -m` does not work in a
 container, and if users use the [node
 allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
 are made local to the end user Pod part of the cgroup hierarchy as well as the
-root node. This [script](/docs/tasks/administer-cluster/memory-available.sh)
+root node. This [script](/examples/admin/resource/memory-available.sh)
 reproduces the same set of steps that the `kubelet` performs to calculate
 `memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
 file-backed memory on inactive LRU list) from its calculation as it assumes that
@@ -153,7 +153,7 @@ An older kubectl plugin mechanism provided environment variables such as `KUBECT
 kubectl plugins must parse and validate all of the arguments passed to them.
 See [using the command line runtime package](#using-the-command-line-runtime-package) for details of a Go library aimed at plugin authors.

-Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the the `kubectl-foo-bar-baz` plugin from the scenario above.
+Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the `kubectl-foo-bar-baz` plugin from the scenario above.

 If you run `kubectl foo bar baz arg1 --flag=value arg2`, kubectl's plugin mechanism will first try to find the plugin with the longest possible name, which in this case
 would be `kubectl-foo-bar-baz-arg1`. Upon not finding that plugin, kubectl then treats the last dash-separated value as an argument (`arg1` in this case), and attempts to find the next longest possible name, `kubectl-foo-bar-baz`.
@@ -405,8 +405,8 @@ behavior:
      periodSeconds: 60
 ```

-To allow a final drop of 5 pods, another policy can be added and a selection
-strategy of minimum:
+To allow a final drop of 5 pods, another policy can be added with a selection
+strategy of maximum:

 ```yaml
 behavior:
@@ -39,7 +39,7 @@ helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
 Check to make sure that it installed successfully by executing the following command:

 ```shell
-helm search service-catalog
+helm search repo service-catalog
 ```

 If the installation was successful, the command should output the following:
@@ -65,7 +65,7 @@ Using the latest version of kubectl helps avoid unforeseen issues.

 {{< tabs name="kubectl_install" >}}
 {{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
+sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
 echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
 sudo apt-get update
@@ -55,7 +55,7 @@ Schéma de la [Topologie etcd empilée](/images/kubeadm/kubeadm-ha-topology-stac

 Un cluster haute disponibilité avec un etcd externe est une
 [topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau) où le cluster de stockage de données
-distribué fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants
+distribuées fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants
 du control plane.

 Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute
@@ -63,7 +63,7 @@ une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`.
 est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur
 des hôtes distincts et chaque hôte etcd communique avec le `kube-apiserver` de chaque nœud du control plane.

-Cette topologie dissocie le control plane et le membre etcd. Il fournit donc une configuration HA où
+Cette topologie dissocie le control plane et le membre etcd. Elle fournit donc une configuration HA où
 perdre une instance de control plane ou un membre etcd a moins d'impact et n'affecte pas la redondance du
 cluster autant que la topologie HA empilée.

@@ -31,7 +31,7 @@ Voir aussi [La documentation de mise à niveau HA](/docs/tasks/administer-cluste

 {{< caution >}}
 Cette page ne traite pas de l'exécution de votre cluster sur un fournisseur de cloud. Dans un
-environnement Cloud, les approches documentées ici ne fonctionne ni avec des objets de type
+environnement Cloud, les approches documentées ici ne fonctionnent ni avec des objets de type
 load balancer, ni avec des volumes persistants dynamiques.
 {{< /caution >}}

@@ -78,7 +78,7 @@ certains comme Weave n'en ont pas besoin. Voir la
 ### Créez un load balancer pour kube-apiserver

 {{< note >}}
-Il existe de nombreuses configurations pour les équilibreurs de charge (load balancer).
+Il existe de nombreuses configurations pour les équilibreurs de charge (load balancers).
 L'exemple suivant n'est qu'un exemple. Vos exigences pour votre cluster peuvent nécessiter une configuration différente.
 {{< /note >}}

@@ -118,7 +118,7 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc
    - `/etc/kubernetes/pki/etcd/ca.crt`
    - `/etc/kubernetes/pki/etcd/ca.key`

-1. Créer des certificats pour chaque membres
+1. Créer des certificats pour chaque membre

    ```sh
    kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
@@ -76,6 +76,14 @@ mereka dikonfigurasi. Jika ada _plugin_ Filter menandai Node menjadi _infeasible
 maka _plugin_ yang lainnya tidak akan dipanggil untuk Node itu. Node-Node dapat dievaluasi 
 secara bersamaan.

+### PostFilter {#post-filter}
+
+Plugin ini disebut setelah fase Filter, tetapi hanya ketika tidak ada node yang layak
+ditemukan untuk pod. Plugin dipanggil dalam urutan yang dikonfigurasi. Jika
+plugin postFilter menandai node sebagai 'Schedulable', plugin yang tersisa
+tidak akan dipanggil. Implementasi PostFilter yang khas adalah preemption, yang
+mencoba membuat pod dapat di menjadwalkan dengan mendahului Pod lain.
+
 ### PreScore {#pre-score}

 _Plugin_ ini digunakan untuk melakukan pekerjaan "pra-penilaian", yang 
@@ -0,0 +1,16 @@
+---
+title: Anotasi
+id: annotation
+date: 2018-04-12
+full_link: /id/docs/concepts/overview/working-with-objects/annotations
+short_description: >
+  Suatu pasangan kunci-nilai (_key-value_) yang digunakan untuk melampirkan metadata nonidentifikasi arbitrer ke objek.
+aka:
+tags:
+- fundamental
+---
+Suatu pasangan kunci-nilai (_key-value_) yang digunakan untuk melampirkan metadata nonidentifikasi arbitrer ke objek.
+
+<!--more-->
+
+Metadata dalam anotasi bisa berukuran kecil atau besar, terstruktur atau tidak terstruktur, dan dapat menyertakan karakter yang tidak dibolehkan pada {{< glossary_tooltip text="label" term_id="label" >}}. Klien seperti utilitas dan pustaka dapat mengambil metadata ini.
@@ -0,0 +1,19 @@
+---
+title: Grup API
+id: api-group
+date: 2019-09-02
+full_link: /id/docs/concepts/overview/kubernetes-api/#api-groups
+short_description: >
+  Sekumpulan _path_ terkait pada API Kubernetes.
+aka:
+tags:
+- fundamental
+- architecture
+---
+Sekumpulan _path_ terkait pada API Kubernetes.
+
+<!--more-->
+
+Kamu dapat mengaktifkan atau menonaktifkan setiap grup API dengan mengubah konfigurasi server API-mu. Kamu juga dapat menonaktifkan atau mengaktifkan _path_ untuk sumber daya tertentu. Grup API memudahkan penambahan ekstensi dari API Kubernetes. Grup API ditentukan di dalam _path_ REST dan _field_ `apiVersion` dari objek terserialisasi.
+
+* Baca [Grup API](/id/docs/concepts/overview/kubernetes-api/#api-groups) untuk informasi lebih lanjut.
@@ -0,0 +1,12 @@
+---
+title: Aplikasi
+id: applications
+date: 2019-05-12
+full_link:
+short_description: >
+  Lapisan (_layer_) tempat menjalankan berbagai aplikasi dalam Container.
+aka:
+tags:
+- fundamental
+---
+Lapisan (_layer_) tempat menjalankan berbagai aplikasi dalam Container.
@@ -0,0 +1,17 @@
+---
+title: cgroup (control group)
+id: cgroup
+date: 2019-06-25
+full_link:
+short_description: >
+  Suatu grup proses Linux dengan isolasi, penghitungan, dan pembatasan sumber daya opsional.
+aka:
+- grup kontrol
+tags:
+- fundamental
+---
+Suatu grup proses Linux dengan isolasi, penghitungan, dan pembatasan sumber daya opsional.
+
+<!--more--> 
+
+cgroup merupakan fitur kernel Linux yang membatasi, menghitung, dan mengisolasi penggunaan sumber daya (CPU, memori, I/O diska, jaringan) untuk sekumpulan proses.
@@ -1,23 +1,21 @@
 ---
-title: Cluster Operator
+title: Operator Klaster
 id: cluster-operator
 date: 2018-04-12
 full_link: 
 short_description: >
-  Seseorang yang mengkonfigurasi, mengontrol, dan memonitor cluster.
+  Seseorang yang mengonfigurasi, mengontrol, dan memonitor klaster.

-aka: 
+aka:
 tags:
 - user-type
 ---
-  Seseorang yang mengkonfigurasi, mengontrol, dan memonitor cluster.
+Seseorang yang mengonfigurasi, mengontrol, dan memonitor klaster.

-<!--more--> 
+<!--more-->

-
-Tanggung jawab utama mereka adalah menjaga dan menjalankan cluster, yang mungkin melibatkan kegiatan pemeliharaan berkala atau peningkatan. <br>
+Tanggung jawab utama operator klaster adalah menjaga dan menjalankan klaster, yang mungkin melibatkan kegiatan pemeliharaan berkala atau peningkatan.

 {{< note >}}
-Operator cluster berbeda dari [Pola operator] (https://coreos.com/operators) yang memperluas API Kubernetes.
+Operator klaster berbeda dari [pola Operator](https://coreos.com/operators) yang memperluas API Kubernetes.
 {{< /note >}}
-
@@ -0,0 +1,17 @@
+---
+title: Klaster
+id: cluster
+date: 2019-06-15
+full_link: 
+short_description: >
+  Sekumpulan mesin pekerja, yang dikenal sebagai Node, yang menjalankan aplikasi dalam Container. Setiap klaster setidaknya mempunyai satu Node pekerja.
+aka:
+tags:
+- fundamental
+- operation
+---
+Sekumpulan mesin pekerja, yang dikenal sebagai {{< glossary_tooltip term_id="node" >}}, yang menjalankan aplikasi dalam Container. Setiap klaster setidaknya mempunyai satu Node pekerja.
+
+<!--more-->
+
+Node pekerja menjalankan {{< glossary_tooltip term_id="pod" >}} yang merupakan komponen dari beban kerja aplikasi. {{< glossary_tooltip term_id="control-plane" >}} mengelola Node pekerja dan Pod di dalam klaster. Pada lingkungan produksi, _control plane_ biasanya berjalan di beberapa komputer dan suatu klaster pada umumnya menjalankan beberapa Node, hal ini akan memberikan toleransi kesalahan (_fault-tolerance_) dan ketersediaan tinggi (_high availability_).
@@ -10,7 +10,7 @@ aka:
 tags:
 - core-object
 ---
-Sebuah objek API yang digunakan untuk menyimpan data nonkonfidensial sebagai pasangan kunci-nilai (_key-value_). {{< glossary_tooltip text="Pod" term_id="pod" >}} dapat menggunakan ConfigMap sebagai variabel lingkungan, argumen baris perintah (_command-line_), atau berkas konfigurasi dalam sebuah {{< glossary_tooltip text="volume" term_id="volume" >}}.
+Sebuah objek API yang digunakan untuk menyimpan data nonkonfidensial sebagai pasangan kunci-nilai (_key-value_). {{< glossary_tooltip term_id="pod" >}} dapat menggunakan ConfigMap sebagai variabel lingkungan, argumen baris perintah (_command-line_), atau berkas konfigurasi dalam sebuah {{< glossary_tooltip text="volume" term_id="volume" >}}.

 <!--more-->

@@ -1,17 +1,18 @@
 ---
-title: Container Environment Variables
+title: Variabel Lingkungan Container
 id: container-env-variables
 date: 2019-06-24
 full_link: /docs/concepts/containers/container-environment-variables/
 short_description: >
-  Variabel environment kontainer merupakan pasangan name=value yang dapat digunakan untuk menyediakan informasi penting bagi kontainer yang dijalankan pada pod.
+  Variabel lingkungan Container merupakan pasangan nama=nilai yang dapat digunakan untuk menyediakan informasi penting bagi Container yang dijalankan pada Pod.

-aka: 
+aka:
+- Container Environment Variables
 tags:
 - fundamental
 ---
- Container environment variables are name=value pairs that provide useful information into containers running in a Pod.
+Variabel lingkungan Container merupakan pasangan nama=nilai yang dapat digunakan untuk menyediakan informasi penting bagi Container yang dijalankan pada Pod.

 <!--more-->

-Variabel environment kontainer merupakan pasangan name=value yang dapat digunakan untuk menyediakan informasi penting bagi {{< glossary_tooltip text="kontainer" term_id="container" >}} yang dijalankan pada pod. Contohnya, detail mengenai file systems, informasi mengenai kontainer itu sendiri, dan komponen kluster lainnya seperti endpoint kluster.
+Variabel lingkungan Container menyediakan informasi yang dibutuhkan oleh aplikasi yang berjalan di dalam Container bersama dengan informasi mengenai sumber daya penting yang dibutuhkan oleh {{< glossary_tooltip term_id="container" >}}. Sebagai contoh, detail sistem berkas (_file system_), informasi mengenai Container itu sendiri, dan sumber daya klaster lainnya seperti _endpoint_ Service.
@@ -0,0 +1,17 @@
+---
+title: Runtime Container
+id: container-runtime
+date: 2019-06-05
+full_link: /id/docs/setup/production-environment/container-runtimes
+short_description: >
+ _Runtime_ Container adalah perangkat lunak yang bertanggung jawab untuk menjalankan Container.
+aka:
+tags:
+- fundamental
+- workload
+---
+_Runtime_ Container adalah perangkat lunak yang bertanggung jawab untuk menjalankan Container.
+
+<!--more-->
+
+Kubernetes mendukung beberapa _runtime_ Container: {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}, dan implementasi apapun dari [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
@@ -2,16 +2,17 @@
 title: Container
 id: container
 date: 2019-06-24
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /id/docs/concepts/overview/what-is-kubernetes/#mengapa-kontainer
 short_description: >
-  Sebuah image yang ringan dan *executable* yang mengandung perangkat lunak and segala *dependency* yang dibutuhkan.
+  Sebuah _image_ yang ringan dan dapat dijalankan yang mengandung perangkat lunak and segala dependensi yang dibutuhkan.

-aka: 
+aka:
 tags:
 - fundamental
 - workload
 ---
-Sebuah image yang ringan dan *executable* yang mengandung perangkat lunak and segala *dependency* yang dibutuhkan.
+Sebuah _image_ yang ringan dan dapat dijalankan yang mengandung perangkat lunak and segala dependensi yang dibutuhkan.

-<!--more--> 
-Kontainer memisahkan aplikasi dan segala infrastruktur yang digunakan untuk membuat sebuah deployment menjadi lebih mudah pada berbagai environment *cloud provider* yang ada. 
+<!--more-->
+
+Container memisahkan aplikasi dari infrastruktur hos yang digunakan untuk mempermudah penggelaran pada berbagai lingkungan _cloud_ atau OS, dan juga untuk mempermudah penyekalaan.
@@ -0,0 +1,25 @@
+---
+title: Control Plane
+id: control-plane
+date: 2019-05-12
+full_link:
+short_description: >
+  Merupakan lapisan orkestrasi Container yang mengekspos API dan antarmuka untuk mendefinisikan, menggelar, dan mengelola siklus hidup suatu Container.
+
+aka:
+tags:
+- fundamental
+---
+Merupakan lapisan orkestrasi Container yang mengekspos API dan antarmuka untuk mendefinisikan, menggelar, dan mengelola siklus hidup suatu Container.
+
+<!--more--> 
+
+Lapisan ini terdiri dari beragam komponen, seperti (tapi tidak terbatas pada):
+
+* {{< glossary_tooltip text="etcd" term_id="etcd" >}}
+* {{< glossary_tooltip text="Server API" term_id="kube-apiserver" >}}
+* {{< glossary_tooltip text="Penjadwal" term_id="kube-scheduler" >}}
+* {{< glossary_tooltip text="Manajer Pengontrol" term_id="kube-controller-manager" >}}
+* {{< glossary_tooltip text="Manajer Pengontrol Cloud" term_id="cloud-controller-manager" >}}
+
+Komponen-komponen tersebut dapat dijalankan sebagai layanan sistem operasi tradisional (_daemon_) atau sebagai Container. Hos yang menjalankan komponen-komponen tersebut secara historis dikenal sebagai {{< glossary_tooltip text="master" term_id="master" >}}.
@@ -1,30 +1,21 @@
 ---
-title: Controller
+title: Pengontrol
 id: controller
 date: 2018-04-12
-full_link: /docs/concepts/architecture/controller/
+full_link: /id/docs/concepts/architecture/controller/
 short_description: >
  Kontrol tertutup yang mengawasi kondisi bersama dari klaster melalui apiserver dan membuat perubahan yang mencoba untuk membawa kondisi saat ini ke kondisi yang diinginkan.

-aka: 
+aka:
+- Controller
 tags:
 - architecture
 - fundamental
 ---
-Di Kubernetes, _controller_ adalah kontrol tertutup yang mengawasi kondisi
-{{< glossary_tooltip term_id="cluster" text="klaster">}} anda, lalu membuat atau 
-meminta perubahan jika diperlukan.
-Setiap _controller_ mencoba untuk memindahkan status klaster saat ini lebih 
-dekat ke kondisi yang diinginkan.
+Di Kubernetes, pengontrol adalah kontrol tertutup yang mengawasi kondisi {{< glossary_tooltip term_id="cluster" text="klaster">}}, lalu membuat atau meminta perubahan jika diperlukan. Setiap pengontrol mencoba untuk memindahkan status klaster saat ini lebih dekat ke kondisi yang diinginkan.

 <!--more-->

-_Controller_ mengawasi keadaan bersama dari klaster kamu melalui
-{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (bagian dari
-{{< glossary_tooltip term_id="control-plane" >}}).
+Pengontrol mengawasi keadaan bersama (_shared state_) dari klastermu melalui {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (bagian dari {{< glossary_tooltip term_id="control-plane" >}}).

-Beberapa _controller_ juga berjalan di dalam _control plane_, menyediakan 
-kontrol tertutup yang merupakan inti dari operasi Kubernetes. Sebagai contoh: 
-_controller Deployment_, _controller daemonset_, _controller namespace_, dan 
-_controller volume persisten_ (dan lainnya) semua berjalan di dalam
-{{< glossary_tooltip term_id="kube-controller-manager" >}}.
+Beberapa pengontrol juga berjalan di dalam _control plane_, menyediakan kontrol tertutup yang merupakan inti dari operasi Kubernetes. Sebagai contoh: pengontrol Deployment, pengontrol DaemonSet, pengontrol Namespace, dan pengontrol PersistentVolume (dan lainnya) semuanya berjalan di dalam {{< glossary_tooltip term_id="kube-controller-manager" >}}.
@@ -0,0 +1,18 @@
+---
+title: Antarmuka Runtime Container
+id: cri
+date: 2019-03-07
+full_link: /id/docs/concepts/overview/components/#container-runtime
+short_description: >
+  Sebuah API untuk mengintegrasikan _runtime_ Container dengan kubelet.
+
+aka:
+- Container Runtime Interface (CRI)
+tags:
+- fundamental
+---
+Sebuah API untuk mengintegrasikan _runtime_ Container dengan kubelet.
+
+<!--more-->
+
+Untuk informasi lebih lanjut, lihat API dan spesifikasi [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
@@ -0,0 +1,19 @@
+---
+title: CustomResourceDefinition (CRD)
+id: CustomResourceDefinition
+date: 2018-04-12
+full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
+short_description: >
+  Kode khusus yang mendefinisikan sebuah sumber daya untuk ditambahkan ke server API Kubernetes-mu tanpa membangun server khusus tersendiri.
+
+aka:
+tags:
+- fundamental
+- operation
+- extension
+---
+Kode khusus yang mendefinisikan sebuah sumber daya untuk ditambahkan ke server API Kubernetes-mu tanpa membangun server khusus tersendiri.
+
+<!--more-->
+
+CRD memungkinkanmu untuk memperluas API Kubernetes untuk lingkunganmu jika sumber daya API yang didukung secara publik tidak dapat memenuhi kebutuhanmu.
@@ -0,0 +1,19 @@
+---
+title: DaemonSet
+id: daemonset
+date: 2018-04-12
+full_link: /id/docs/concepts/workloads/controllers/daemonset
+short_description: >
+  Memastikan salinan Pod dijalankan pada sekumpulan Node dalam satu klaster.
+
+aka:
+tags:
+- fundamental
+- core-object
+- workload
+---
+Memastikan salinan {{< glossary_tooltip term_id="pod" >}} dijalankan pada sekumpulan Node dalam satu {{< glossary_tooltip text="klaster" term_id="cluster" >}}.
+
+<!--more-->
+
+Digunakan untuk menggelar _daemon_ sistem sebagai kolektor log dan memonitor agen yang biasanya harus dijalankan di setiap {{< glossary_tooltip term_id="node" >}}.
@@ -0,0 +1,13 @@
+---
+title: Data Plane
+id: data-plane
+date: 2019-05-12
+full_link:
+short_description: >
+  Lapisan yang menyediakan kapasitas seperti CPU, memori, jaringan, dan penyimpanan sehingga Container dapat dijalankan dan terhubung ke suatu jaringan.
+
+aka:
+tags:
+- fundamental
+---
+Lapisan yang menyediakan kapasitas seperti CPU, memori, jaringan, dan penyimpanan sehingga Container dapat dijalankan dan terhubung ke suatu jaringan.
@@ -4,79 +4,31 @@ title: Persiapan
 main_menu: true
 weight: 30
 content_type: concept
+card:
+  name: persiapan
+  weight: 20
+  anchors:
+  - anchor: "#learning-environment"
+    title: Lingkungan Pembelajaran
+  - anchor: "#production-environment"
+    title: Lingkungan Produksi 
 ---

 <!-- overview -->

-Gunakan halaman ini untuk mencari solusi yang paling sesuai dengan kebutuhan kamu.
-
-Menentukan dimana sebaiknya Kubernetes dijalankan sangat tergantung pada kapasitas yang kamu punya dan seberapa fleksibel klaster yang kamu inginkan.
-Kamu dapat menjalankan Kubernetes hampir dimana saja, mulai dari laptop, VM di penyedia cloud, sampai pada rak-rak berisi server <i>baremetal</i>.
-Kamu juga bisa menyiapkan klaster yang diatur sepenuhnya (<i>fully-managed</i>), dengan hanya menjalankan satu perintah, ataupun membuat klaster dengan solusi <i>custom</i> kamu sendiri pada server <i>baremetal</i>.
-
+Bagian ini mencantumkan berbagai cara untuk menyiapkan dan menjalankan Kubernetes. Ketika kamu menginstal Kubernetes, pilih tipe instalasi berdasarkan: kemudahan perawatan, keamanan, sumber daya yang tersedia, dan keahlian yang dibutuhkan untuk mengoperasikan dan mengelola klaster.

+Kamu dapat menggelar klaster Kubernetes di mesin lokal, cloud, _datacenter_ di tempat, atau pilih klaster Kubernetes yang dikelola. Ada juga solusi khusus di berbagai penyedia cloud, atau lingkungan _baremetal_.

 <!-- body -->

-## Solusi pada Mesin Lokal
+## Lingkungan Pembelajaran

-Memulai Kubernetes bisa dilakukan dengan mudah melalui solusi pada mesin lokal.
-Kamu bisa membuat dan mengevaluasi klaster Kubernetes tanpa perlu takut menghabiskan <i>resource</i> dan kuota penyedia cloud.
+Jika kamu sedang belajar Kubernetes, gunakan alat yang didukung oleh komunitas Kubernetes, atau alat di ekosistem untuk menyiapkan klaster Kubernetes di mesin lokal.

-Sebaiknya kamu memilih solusi lokal jika kamu ingin:
+## Lingkungan Produksi

-* Mulai belajar atau mencoba Kubernetes
-* Mengembangkan dan melakukan evaluasi klaster secara lokal
+Pada saat mengevaluasi sebuah solusi untuk lingkungan produksi, pertimbangkan aspek dari pengoperasian klaster Kubernetes (atau _abstractions_) yang ingin kamu kelola atau membiarkan penyedia.

-Pilih [solusi lokal](/docs/setup/pick-right-solution/#local-machine-solutions).
-
-## Solusi Tersediakan (<i>Hosted Solution</i>)
-
-Solusi tersediakan adalah cara yang nyaman untuk membuat dan memelihara klaster Kubernetes. Kamu tidak perlu repot, karena para penyedia solusi mengatur dan mengoperasikan klaster milikmu.
-
-Sebaiknya kamu memilih solusi tersediakan ini jika kamu:
-
-* Ingin punya solusi yang diatur sepenuhnya
-* Fokus pada pengembangan aplikasi atau servis saja
-* Tidak mau punya tim SRE (<i>Site Reliability Engineering</i>) yang mendedikasikan waktunya untukmu, tapi ingin HA (<i>High Availability</i>)
-* Tidak punya <i>resource</i> untuk menjalankan dan memonitor klaster.
-
-Pilih [solusi tersediakan](/docs/setup/pick-right-solution/#hosted-solutions).
-
-## Turnkey – Solusi Cloud
-
-Solusi-solusi ini memudahkan kamu untuk mempunyai klaster Kubernetes hanya dengan beberapa perintah. Lalu, solusi-solusi ini juga masih terus berkembang dan memiliki pendukung komunitas yang aktif.
-Mereka juga bisa berjalan pada berbagai macam penyedia Cloud IaaS, tapi mereka menawarkan kebebasan dan fleksibilitas sebagai pengganti dari usaha.
-
-Sebaiknya kamu memilih solusi cloud <i>turnkey</i>, jika kamu:
-
-* Ingin punya kontrol yang lebih daripada yang ditawarkan oleh solusi tersediakan (<i>hosted solution</i>)
-* Ingin memiliki porsi dalam mengoperasikan klaster
-
-Pilih [solusi cloud turnkey](/docs/setup/pick-right-solution/#turnkey-cloud-solutions)
-
-## Turnkey – Solusi On-Premise
-
-Solusi-solusi ini menyediakan cara untuk membuat klaster Kubernetes di dalam jaringan cloud internal kamu yang aman, hanya dengan beberapa perintah.
-
-Sebaiknya kamu memilih solusi cloud on-premise turnkey, jika kamu:
-
-* Ingin membuat klaster di jaringan cloud yang privat (<i>private cloud network</i>)
-* Punya tim SRE yang mendedikasikan waktunya
-* Punya <i>resource</i> untuk menjalankan dan memonitor klaster
-
-Pilih [solusi cloud on-prem turnkey](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions).
-
-## Solusi <i>Custom</i>
-
-Solusi <i>custom</i> adalah solusi yang paling memberikan kebebasan dalam menjalankan klaster kamu, tapi perlu keahlian.
-Solusi-solusi ini cukup beragam, mulai dari bare-metal sampai ke penyedia cloud, berjalan pada sistem operasi yang berbeda-beda.
-
-Pilih [solusi <i>custom</i>](/docs/setup/pick-right-solution/#custom-solutions).
-
-
-
-## {{% heading "whatsnext" %}}
-
-Lihat [Memilih Solusi Terbaik](/docs/setup/pick-right-solution/) untuk daftar solusi yang lengkap.
+[Kubernetes Partners](https://kubernetes.io/partners/#conformance) termasuk dari daftar dari penyedia [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes).

@@ -0,0 +1,4 @@
+---
+title: Lingkungan Pembelajaran
+weight: 20
+---
@@ -0,0 +1,514 @@
+---
+title: Instalasi Kubernetes dengan Minikube
+weight: 30
+content_type: concept
+---
+
+<!-- overview -->
+
+Minikube adalah alat yang memudahkan untuk menjalankan Kubernetes pada komputer lokal. Minikube menjalankan satu Node klaster Kubernetes di dalam _Virtual Machine_ (VM) pada laptop kamu untuk pengguna yang ingin mencoba Kubernetes atau mengembangkannya.
+
+
+<!-- body -->
+
+## Fitur Minikube
+
+Minikube mendukung fitur Kubernetes berikut:
+
+* DNS
+* NodePort
+* {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} dan {< glossary_tooltip text="Secret" term_id="secret" >}}
+* _Dashboard_
+* _Container runtime_: [Docker](https://www.docker.com/), [CRI-O](https://cri-o.io/), dan [containerd](https://github.com/containerd/containerd)
+* {{< glossary_tooltip text="CNI" term_id="cni" >}}
+* Ingress
+
+## Instalasi
+
+Lihat [Instalasi Minikube](/id/docs/tasks/tools/install-minikube/).
+
+## Memulai Cepat
+
+Demonstrasi singkat ini memandu kamu tentang bagaimana memulai, menggunakan dan menghapus Minikube secara lokal. Ikuti langkah berikut untuk memulai dan menjelajahi Minikube.
+
+1. Mulailah Minikube dan buatlah sebuah klaster:
+
+   ```shell
+    minikube start
+   ```
+
+   Keluaran menyerupai:
+
+   ```
+   Starting local Kubernetes cluster...
+   Running pre-create checks...
+   Creating machine...
+   Starting local Kubernetes cluster...
+   ```
+   Untuk informasi lebih lanjut mengenai bagaimana memulai klaster pada versi Kubernetes tertentu, VM atau Container _runtime_, lihatlah [Memulai klaster](#memulai-klaster).
+
+2. Kini kamu bisa berinteraksi dengan klaster kamu dengan kubectl. Untuk informasi lebih lanjut, lihatlah [Interaksi dengan klaster kamu](#interaksi-dengan-klaster-kamu).
+
+   Mari kita buat Kubernetes Deployment menggunakan _image_ bernama `echoserver`, yaitu sebuah server HTTP sederhana dan buka layanan pada porta 8080 dengan menggunakan opsi `--port`.
+
+   ```shell
+   kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
+   ```
+
+   Keluaran menyerupai:
+
+   ```
+   deployment.apps/hello-minikube created
+   ```
+3. Untuk mengakses Deployment `hello-minikube`, bukalah dia sebagai sebuah Service: 
+
+   ```shell
+   kubectl expose deployment hello-minikube --type=NodePort --port=8080
+   ```
+
+   Opsi `--type=NodePort` menentukan tipe Service.
+
+   Keluarannya menyerupai:
+
+   ```
+   service/hello-minikube exposed
+   ```
+
+4. Pod `hello-minikube` saat ini telah dibuat namun kamu harus menunggu hingga Pod selesai dijalankan sebelum dapat mengaksesnya melalui Service yang telah dibuka.
+
+   Cek apakah Pod sudah berjalan dan beroperasi:
+
+   ```shell
+   kubectl get pod
+   ```
+
+   Jika keluaran menampilkan `STATUS` sebagai `ContainerCreating`, maka Pod sedang dalam proses pembuatan:
+
+   ```
+   NAME                              READY     STATUS              RESTARTS   AGE
+   hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
+   ```
+
+   Jika keluaran menampilkan `STATUS` sebagai `Running`, maka Pod sudah berjalan dan beroperasi:
+
+   ```
+   NAME                              READY     STATUS    RESTARTS   AGE
+   hello-minikube-3383150820-vctvh   1/1       Running   0          13s
+   ```
+
+5. Ambil URL Service yang telah dibuka untuk melihat Service secara detail:
+
+   ```shell
+   minikube service hello-minikube --url
+   ```
+
+6. Untuk melihat detail dari klaster lokal kamu, salin dan tempel URL yang kamu dapatkan dari keluaran pada peramban kamu.
+
+   Keluarannya menyerupai:
+
+   ```
+   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-
+   ```
+
+   Jika kamu tidak lagi membutuhkan Service dan klaster, maka kamu bisa menghapusnya.
+
+7. Hapuslah Service `hello-minikube`:
+
+   ```shell
+   kubectl delete services hello-minikube
+   ```
+
+   Keluarannya menyerupai:
+
+   ```
+   service "hello-minikube" deleted
+   ```
+
+8. Hapuslah Deployment `hello-minikube`:
+
+   ```shell
+   kubectl delete deployment hello-minikube
+   ```
+
+   Keluarannya menyerupai:
+
+   ```
+   deployment.extensions "hello-minikube" deleted
+   ```
+
+9. Hentikanlah klaster Minikube lokal:
+
+   ```shell
+   minikube stop
+   ```
+
+   Keluarannya menyerupai:
+
+   ```
+   Stopping "minikube"...
+   "minikube" stopped.
+   ```
+
+   Untuk informasi lebih lanjut, lihatlah [Menghentikan Klaster](#menghentikan-klaster).
+
+10. Hapuslah klaster Minikube lokal
+
+    ```shell
+    minikube delete
+    ```
+    Keluarannya menyerupai:
+    ```
+    Deleting "minikube" ...
+    The "minikube" cluster has been deleted.
+    ```
+	Untuk informasi lebih lanjut, lihat [Menghapus Klaster](#menghapus-klaster).
+
+## Mengelola Klaster
+
+### Memulai Klaster
+
+Perintah `minikube start` bisa digunakan untuk memulai klaster kamu.
+Perintah ini membuat dan mengonfigurasi sebuah mesin virtual yang menjalankan klaster Kubernetes dengan satu Node.
+Perintah ini juga mengonfigurasi instalasi [kubectl](/id/docs/user-guide/kubectl-overview/) untuk berkomunikasi dengan klaster ini.
+
+{{< note >}}
+Jika kamu menggunakan proksi web, maka kamu harus meneruskan informasi berikut ini ke perintah `minikube start`:
+
+```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
+```
+Sayangnya, pengaturan dengan _environment variable_ saja tidak berguna.
+
+Minikube juga membuat konteks "minikube", dan menetapkannya sebagai bawaan di kubectl.
+Untuk kembali menggunakan konteks ini, jalankan perintah: `kubectl config use-context minikube`.
+{{< /note >}}
+
+#### Menentukan Versi Kubernetes
+
+Kamu bisa menentukan versi Kubernetes yang digunakan oleh Minikube dengan
+menambahkan `--kubernetes-version` ke perintah `minikube start`. Sebagai 
+contoh, untuk menjalankan versi {{<param "fullversion">}}, kamu akan menjalankan perintah berikut:
+
+```
+minikube start --kubernetes-version {{< param "fullversion" >}}
+```
+#### Menentukan _driver_ VM
+
+Kamu bisa mengubah _driver_ VM dengan menambahkan tanda `--driver=<masukan_nama_driver>` pada `minikube start`.
+Sebagai contoh:
+```shell
+minikube start --driver=<nama_driver>
+```
+
+Minikube mendukung _driver_ berikut ini:
+{{< note >}}
+Lihat [_DRIVER_](https://minikube.sigs.k8s.io/docs/reference/drivers/) untuk detail tentang _driver_ yang didukung dan proses instalasi _plugin_.
+{{< /note >}}
+
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/docker/)) docker
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/)) virtualbox 
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/podman/)) podman (TAHAP EXPERIMEN)
+* vmwarefusion
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) kvm2
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) hyperkit
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) hyperv
+Perlu diingat bahwa IP dibawah adalah dinamik dan bisa berubah. IP ini bisa diambil dengan `minikube ip`.
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) vmware (_driver_ VMware terpadu)
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) parallels
+* none (menjalankan komponen Kubernetes pada hos dan bukan pada mesin virtual. Kamu harus menjalankan Linux dan harus menginstal {{<glossary_tooltip term_id = "docker">}}.)
+
+{{< caution >}}
+Jika kamu menggunakan _driver_ `none`, beberapa komponen Kubernetes dijalankan sebagai Container istimewa yang memiliki efek samping di luar lingkungan Minikube. Efek samping tersebut berarti bahwa _driver_ `none` tidak direkomendasikan untuk komputer pribadi.
+{{< /caution >}}
+
+#### Memulai klaster pada _runtime_ kontainer alternatif
+Kamu bisa memulai Minikube pada _runtime_ kontainer berikut.
+{{< tabs name="container_runtimes" >}}
+{{% tab name="containerd" %}}
+Untuk menggunakan [containerd](https://github.com/containerd/containerd) sebagai _runtime_ kontainer, jalankan:
+```bash
+minikube start \
+    --network-plugin=cni \
+    --enable-default-cni \
+    --container-runtime=containerd \
+    --bootstrapper=kubeadm
+```
+
+Atau kamu bisa menggunakan versi yang diperpanjang:
+
+```bash
+minikube start \
+    --network-plugin=cni \
+    --enable-default-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
+```
+{{% /tab %}}
+{{% tab name="CRI-O" %}}
+Untuk menggunakan [CRI-O](https://cri-o.io/) sebagain _runtime_ kontainer, jalankan:
+```bash
+minikube start \
+    --network-plugin=cni \
+    --enable-default-cni \
+    --container-runtime=cri-o \
+    --bootstrapper=kubeadm
+```
+Atau kamu bisa menggunakan versi yang diperpanjang:
+
+```bash
+minikube start \
+    --network-plugin=cni \
+    --enable-default-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
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+#### Menggunakan _image_ lokal degan menggunakan kembali _daemon_ Docker
+
+Saat menggunakan sebuah VM untuk Kubernetes, akan lebih baik jika _daemon_ Docker bawaan Minikube digunakan kembali. Menggunakan kembali _daemon_ bawaan membuat kamu tidak perlu membangun registri Docker pada mesin hos kamu dan mengunggah _image_ ke dalamnya. Namun, kamu dapat membangun di dalam _daemon_ Docker yang sama dengan Minikube, yang tentunya dapat mempercepat percobaan lokal.
+
+{{< note >}}
+Pastikan untuk memberi _tag_ pada Docker _image_ kamu dengan sesuatu selain `latest` dan gunakan _tag_ tersebut untuk menarik _image_. Karena `:latest` adalah bawaan, dengan kebijakan penarikan _image_ bawaan, yaitu `Always`, kesalahan penarikan _image_ (`ErrImagePull`) akhirnya dapat terjadi jika kamu tidak memiliki _image_ Docker di register Docker bawaan (biasanya DockerHub).
+{{< /note >}}
+
+Untuk bekerja dengan _daemon_ Docker pada mesin Mac/Linux, jalankan baris terakhir dari `minikube docker-env`.
+
+Kamu sekarang dapat menggunakan Docker di terminal mesin Mac/Linux kamu untuk berkomunikasi dengan _daemon_ Docker di dalam VM Minikube:
+
+```shell
+docker ps
+```
+
+{{< note >}}
+Pada Centos 7, Docker bisa memberikan kesalahan berikut:
+
+```
+Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
+```
+
+Kamu bisa memperbaikinya dengan memperbaharui /etc/sysconfig/docker untuk memastikan bahwa lingkungan Minikube dikenali:
+
+```shell
+< DOCKER_CERT_PATH=/etc/docker
+---
+> if [ -z "${DOCKER_CERT_PATH}" ]; then
+>   DOCKER_CERT_PATH=/etc/docker
+> fi
+```
+{{< /note >}}
+
+### Mengonfigurasi Kubernetes
+
+Minikube memiliki sebuah fitur "pengonfigurasi" yang memperbolehkan pengguna untuk mengkonfigurasi komponen Kubernetes dengan sembarang nilai.
+Untuk menggunakan fitur ini, kamu bisa menggunakan _flag_ `--extra-config` pada perintah `minikube start`.
+
+_Flag_ ini berulang, jadi kamu bisa menggunakannya beberapa kali dengan beberapa nilai yang berbeda untuk mengatur beberapa opsi.
+
+_Flag_ ini menerima sebuah _string_ dalam format `component.key=value`, di mana `component` adalah salah satu _string_ dari list di bawah, `key` adalah nilai dari _struct_ configurasi dan `value` adalah nilai yang digunakan.
+
+Kunci yang valid bisa ditemukan dengan memeriksa dokumentasi `componentconfigs` Kubernetes untuk setiap komponen.
+Berikut adalah dokumentasi untuk setiap konfigurasi yang didukung:
+
+* [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)
+
+#### Contoh
+
+Untuk mengubah pengaturan `MaxPods` menjadi 5 pada Kubelet, gunakan _flag_ ini: `--extra-config=kubelet.MaxPods=5`.
+
+Fitur ini juga mendukung _struct_ yang berulang. Untuk mengubah pengaturan `LeaderElection.LeaderElect` menjadi `true` pada penjadwal, gunakan _flag_: `--extra-config=scheduler.LeaderElection.LeaderElect=true`.
+
+Untuk mengatur `AuthorizationMode` pada `apiserver` menjadi `RBAC`, kamu bisa menggunakan: `--extra-config=apiserver.authorization-mode=RBAC`.
+
+### Menghentikan klaster
+Perintah `minikube stop` bisa digunakan untuk menghentikan klaster kamu.
+Perintah ini menghentikan mesin virtual Minikube, tapi mempertahankan semua status dan data klaster.
+Memulai klaster lagi akan mengembalikannya ke keadaan sebelumnya.
+
+### Menghapus klaster
+Perintah `minikube delete` bisa digunakan untuk menghapus klaster kamu.
+Perintah ini menghentikan dan menghapus mesin virtual Minikube. Tidak ada data atau _state_ yang dipertahankan.
+
+### Memperbaharui Minikube
+Jika kamu menggunakan MacOS dan [Brew Package Manager](https://brew.sh/) sudah terpasang, jalankan:
+
+```shell
+brew update
+brew upgrade minikube
+```
+
+## Interaksi dengan Klaster Kamu
+
+### Kubectl
+
+Perintah `minikube start` membuat sebuah [konteks kubectl](/id/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) yang disebut "minikube".
+Konteks ini menyimpan pengaturan untuk berkomunikasi dengan klaster Minikube kamu.
+
+Minikube menetapkan konteks ini sebagai bawaan secara otomatis, tetapi jika kamu ingin mengubah kembali ke konteks tersebut di kemudian hari, gunakan:
+
+`kubectl config use-context minikube`
+
+Atau berikan konteks untuk setiap perintah seperti ini:
+
+`kubectl get pods --context=minikube`
+
+### Dashboard
+
+Untuk mengakses [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), gunakan perintah ini pada terminal setelah memulai Minikube untuk mendapatkan alamatnya:
+
+```shell
+minikube dashboard
+```
+
+### Service
+
+Untuk mengakses Service yang dibuka via NodePort, jalankan perintah ini pada terminal setelah memulai Minikube untuk mendapatkan alamat:
+
+```shell
+minikube service [-n NAMESPACE] [--url] NAME
+```
+
+## Jaringan
+
+Mesin virtual Minikube dibuka ke sistem hos melalui alamat IP _host-only_ , yang bisa didapatkan dengan perintah `minikube ip`.
+Seluruh Service dengan jenis `NodePort` bisa diakses melalui alamat IP pada NodePort.
+
+Untuk mementukan NodePort pada Service kamu, kamu bisa menggunakan perintah `kubectl` sebagai berikut:
+
+`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
+
+## PersistentVolume
+
+Minikube mendukung [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) dengan jenis `hostPath`.
+PersistenVolume ini dipetakan ke direktori di dalam mesin virtual Minikube.
+
+Mesin virtual Minikube melakukan _booting_ ke tmpfs, sehingga sebagian besar direktori tidak akan bertahan setelah di _reboot_ (`minikube stop`).
+
+Namun, Minikube diatur untuk mempertahankan berkas yang tersimpan didalam direktori hos berikut:
+
+* `/data`
+* `/var/lib/minikube`
+* `/var/lib/docker`
+
+Ini adalah contoh pengaturan PersistentVolume untuk mempertahankan data di dalam direktori `/data`:
+
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: pv0001
+spec:
+  accessModes:
+    - ReadWriteOnce
+  capacity:
+    storage: 5Gi
+  hostPath:
+    path: /data/pv0001/
+```
+
+## Folder hos yang di _mount_
+Beberapa _driver_ akan memasang folder _hos_ dalam VM sehingga kamu dapat dengan mudah berbagi berkas antara VM dan hos. Saat ini, hal tersebut tidak dapat dikonfigurasi dan berbeda untuk setiap _driver_ dan sistem operasi yang kamu gunakan.
+
+{{< note >}}
+Berbagi folder hos belum diimplementasikan pada _driver_ KVM.
+{{< /note >}}
+
+| Driver | OS | HostFolder | VM |
+| --- | --- | --- | --- |
+| VirtualBox | Linux | /home | /hosthome |
+| VirtualBox | macOS | /Users | /Users |
+| VirtualBox | Windows | C://Users | /c/Users |
+| VMware Fusion | macOS | /Users | /mnt/hgfs/Users |
+| Xhyve | macOS | /Users | /Users |
+
+## Registri Container Pribadi
+
+Untuk mengakses registri Container pribadi, ikuti langkah berikut pada [halaman ini](/id/docs/concepts/containers/images/).
+
+Kami merekomendasi penggunaan `ImagePullSecrets`, tetapi jika kamu ingin mengonfigurasi akses pada virtual mesin Minikube, kamu bisa menempatkan `.dockercfg` pada direktori `/home/docker` atau `config.json` dalam direktori `/home/docker/.docker`.
+
+## Tambahan (_Add-on_)
+
+Supaya Minikube memulai atau memulai kembali kustom tambahan dengan benar, 
+tempatkan tambahan yang ingin kamu jalankan di dalam direktori `~/.minikube/addons`.
+Tambahan dalam folder akan dipindahkan ke virtual mesin Minikube dan dijalankan setiap kali Minikube
+dimulai atau dimulai ulang.
+
+## Menggunakan Minikube dengan Proksi HTTP
+
+Minikube membuat sebuah mesin virtual yang memasukkan Kubernetes dan _daemon_ Docker.
+Ketika Kubernetes berusaha untuk menjadwalkan Container dengan Docker, _daemon_ Docker mungkin membutuhkan
+akses jaringan eksternal untuk menarik Container.
+
+Jika kamu berada di belakang _proxy_ HTTP, kamu mungkin perlu menyediakan Docker dengan pengaturan proksi. 
+Untuk melakukan ini, berikan _environment variable_ yang dibutuhkan sebagai _flag_ pada saat `minikube start`.
+
+Contoh:
+
+```shell
+minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
+                 --docker-env https_proxy=https://$YOURPROXY:PORT
+```
+
+Jika alamat mesin virtual kamu adalah 192.168.99.100, maka ada kemungkinan pengaturan proksi kamu akan mencegah `kubectl` untuk mencapainya. 
+Untuk melewatkan konfigurasi _proxy_ untuk alamat IP ini, kamu harus memodifikasi pengaturan _no_proxy` kamu. Kamu bisa melakukannya dengan:
+
+```shell
+export no_proxy=$no_proxy,$(minikube ip)
+```
+
+## Masalah yang Diketahui
+
+Fitur yang memerlukan banyak Node tidak akan berfungsi dalam Minikube.
+
+## Desain
+
+Minikube menggunakan [libmachine](https://github.com/docker/machine/tree/master/libmachine) untuk menyediakan mesin virtual, dan [kubeadm](https://github.com/kubernetes/kubeadm) untuk menyediakan klaster Kubernetes.
+
+Untuk info lebih lanjut tentang Minikube, lihat [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
+
+## Tautan Tambahan
+
+* **Tujuan and Non-Tujuan**: Untuk tujuan dan non-tujuan dari projek Minikube, lihat [roadmap](https://minikube.sigs.k8s.io/docs/contrib/roadmap/).
+* **Petunjuk Pengembangan**: Lihat [Berkontribusi](https://minikube.sigs.k8s.io/docs/contrib/) untuk ikhtisar bagaimana cara mengirimkan _pull request_.
+* **Membangun Minikube**: Untuk instruksi bagaimana membangun atau mengetes Minikube dari sumber kode, lihat [petunjuk membangun](https://minikube.sigs.k8s.io/docs/contrib/building/).
+* **Menambahkan Dependensi Baru**: Untuk instruksi bagaimana menambahkan dependensi baru ke Minikube, lihat [petunjuk penambahan dependensi](https://minikube.sigs.k8s.io/docs/contrib/drivers/).
+* **Menambahkan Addon Baru**: Untuk instruksi bagaimana menambahkan tambahan baru untuk Minikube, lihat [petunjuk menambahkan addon baru](https://minikube.sigs.k8s.io/docs/contrib/addons/).
+* **MicroK8s**: Pengguna Linux yang ingin menghindari penggunaan mesin virtual, bisa mempertimbangkan [MicroK8s](https://microk8s.io/) sebagai alternatif.
+
+## Komunitas
+
+Kontribusi, pertanyaan, dan komentar sangat diharapkan! Pengembang Minikube berkumpul dalam [Slack](https://kubernetes.slack.com) di _channel_ #minikube (dapatkan undangan [di sini](http://slack.kubernetes.io/)). Kami juga memiliki [milis kubernetes-dev Google Groups](https://groups.google.com/forum/#!forum/kubernetes-dev). Jika kamu memposting sesuatu, awali subjek kamu dengan "minikube: ".
@@ -190,7 +190,7 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의

 문서에 대한 일부 이슈는 실제로 기본 코드와 관련된 이슈이거나, 튜토리얼과
 같은 무언가가 작동하지 않을 때 도움을 요청하는 것이다.
-문서와 관련이 없는 이슈의 경우, `triage/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을
+문서와 관련이 없는 이슈의 경우, `kind/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을
 알려주며 이슈를 닫고, 기능 관련 버그에 대한 이슈인 경우,
 관련 리포지터리를 코멘트로 남긴다(`kubernetes/kubernetes` 는
 시작하기 좋은 곳이다).
@@ -493,7 +493,7 @@ PR объединяется, когда у него есть комментар

 #### Заявки с помощью или отчёты об ошибке в коде

-Некоторые открытые заявки — это проблемы с основным кодом или просьбы с помощью, когда что-то (например, учебное руководство) не работает. Для заявок, не имеющих отношение к документации, закройте её, проставив метку `triage/support` и добавив комментарий с ресурсами, где можно найти помощь (Slack, Stack Overflow) и при необходимости укажите, где нужно открыть заявку, чтобы сообщить об ошибке в функциональности (вероятно, репозиторий kubernetes/kubernetes отлично подойдет для этого).
+Некоторые открытые заявки — это проблемы с основным кодом или просьбы с помощью, когда что-то (например, учебное руководство) не работает. Для заявок, не имеющих отношение к документации, закройте её, проставив метку `kind/support` и добавив комментарий с ресурсами, где можно найти помощь (Slack, Stack Overflow) и при необходимости укажите, где нужно открыть заявку, чтобы сообщить об ошибке в функциональности (вероятно, репозиторий kubernetes/kubernetes отлично подойдет для этого).

 Пример ответа на запрос о помощи:

@@ -1,82 +0,0 @@
---
-title: 控制器管理器指标
-content_type: concept
-weight: 100
---
-
-<!--
---
-title: Controller manager metrics
-content_type: concept
-weight: 100
---
-->
-
-<!-- overview -->
-
-<!--
-Controller manager metrics provide important insight into the performance and health of
-the controller manager.
-->
-
-控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。
-
-
-
-<!-- body -->
-
-<!--
-## What are controller manager metrics
-
-Controller manager metrics provide important insight into the performance and health of the controller manager.
-These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
-etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
-to gauge the health of a cluster.
-
-Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
-These metrics can be used to monitor health of persistent volume operations.
-
-For example, for GCE these metrics are called:
-->
-
-## 什么是控制器管理器度量
-
-控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。
-这些度量包括常见的 Go 语言运行时度量，比如 go_routine 计数，以及控制器特定的度量，比如 etcd 请求延迟或 云提供商（AWS、GCE、OpenStack）的 API 延迟，这些参数可以用来测量集群的健康状况。
-
-从 Kubernetes 1.7 版本开始，详细的云提供商指标可用于 GCE、AWS、Vsphere 和 OpenStack 的存储操作。
-这些度量可用于监视持久卷操作的健康状况。
-
-例如，在 GCE 中这些指标叫做：
-
-```
-cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
-cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
-```
-
-<!--
-## Configuration
-
-
-In a cluster, controller-manager metrics are available from `http://localhost:10252/metrics`
-from the host where the controller-manager is running.
-
-The metrics are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
-
-In a production environment you may want to configure prometheus or some other metrics scraper
-to periodically gather these metrics and make them available in some kind of time series database.
-->
-
-## 配置
-
-在集群中，控制器管理器指标可从它所在的主机上的 `http://localhost:10252/metrics` 中获得。
-
-这些指标是以 [prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/) 发出的，是人类可读的。
-
-在生产环境中，您可能想配置 prometheus 或其他一些指标收集工具，以定期收集这些指标数据，并将它们应用到某种时间序列数据库中。
-
-
@@ -1,224 +0,0 @@
---
-title: Kubernetes 控制面的指标
-content_type: concept
-weight: 60
-aliases:
- controller-metrics.md
---
-
-<!-- overview -->
-
-<!--
-System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
-
-Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
-->
-系统组件的指标可以让我们更好的看清系统内部究竟发生了什么，尤其对于构建仪表盘和告警都非常有用。
-
-Kubernetes 控制面板中的指标是以
-[prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/)
-格式发出的，而且是易于阅读的。
-
-<!-- body -->
-
-<!--
-## Metrics in Kubernetes
-In most cases metrics are available on `/metrics` endpoint of the HTTP server. For components that doesn't expose endpoint by default it can be enabled using `--bind-address` flag.
-->
-## Kubernetes 的指标
-
-在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用。
-对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。
-
-<!--
-Examples of those components:
-->
-举例下面这些组件：
-
-* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
-* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
-* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
-* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
-* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
-
-<!--
-In a production environment you may want to configure [Prometheus Server](https://prometheus.io/) or some other metrics scraper
-to periodically gather these metrics and make them available in some kind of time series database.
-
-Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes metrics in `/metrics/cadvisor`, `/metrics/resource` and `/metrics/probes` endpoints. Those metrics do not have same lifecycle.
-
-If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`.
-For example:
-->
-在生产环境中，你可能需要配置 [Prometheus 服务器](https://prometheus.io/) 
-或其他指标收集器来定期收集这些指标，并使它们在某种时间序列数据库中可用。
-
-请注意 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 同样在
-`/metrics/cadvisor`、`/metrics/resource` 和 `/metrics/probes`  等端点提供性能指标。
-这些指标的生命周期并不相同。
-
-如果你的集群还使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}，
-那读取指标数据的时候，还需要通过具有 ClusterRole 的用户、组或者 ServiceAccount 来进行授权，
-才有权限访问 `/metrics` 。
-
-举例：
-
-```
-apiVersion: rbac.authorization.k8s.io/v1	
-kind: ClusterRole	
-metadata:	
-  name: prometheus	
-rules:	
-  - nonResourceURLs:	
-      - "/metrics"	
-    verbs:	
-      - get
-```
-
-<!--
-## Metric lifecycle
-Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deletion
-
-Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time.
-
-Stable metrics can be guaranteed to not change; Specifically, stability means:
-->
-## 指标的生命周期
-
-内测版指标 → 稳定版指标 → 弃用指标 → 隐藏指标 → 删除
-
-内测版指标没有任何稳定性保证，因此可能随时被修改或删除。
-
-稳定版指标可以保证不会改变，具体的说，稳定就意味着：
-
-<!--
-* the metric itself will not be deleted (or renamed)
-* the type of metric will not be modified
-->
-
-* 这个指标自身不会被删除或者重命名。
-* 这个指标类型不会被更改
-
-<!--
-Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated.
-
-Before deprecation:
-->
-弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释，
-注释中包括该指标从哪个 kubernetes 版本被弃用。
-
-指标弃用前：
-
-```
-# HELP some_counter this counts things
-# TYPE some_counter counter
-some_counter 0
-```
-
-<!-- After deprecation: -->
-指标弃用后：
-
-```
-# HELP some_counter (Deprecated since 1.15.0) this counts things
-# TYPE some_counter counter
-some_counter 0
-```
-
-<!--
-Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component.
-
-Once a metric is deleted, the metric is not published. You cannot change this using an override.
-->
-一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。
-如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。
-
-一个指标一旦被删除，那这个指标就不会被发布，您也不可以通过覆盖配置来进行更改。
-
-<!--
-## Show Hidden Metrics
-
-As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.
-
-The flag `show-hidden-metrics-for-version` takes a version for which you want to show metrics deprecated in that release. The version is expressed as x.y, where x is the major version, y is the minor version. The patch version is not needed even though a metrics can be deprecated in a patch release, the reason for that is the metrics deprecation policy runs against the minor release.
-
-The flag can only take the previous minor version as it's value. All metrics hidden in previous will be emitted if admins set the previous version to `show-hidden-metrics-for-version`. The too old version is not allowed because this violates the metrics deprecated policy.
-
-Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. According to metrics deprecated policy, we can reach the following conclusion:
-->
-## 显示隐藏指标
-
-综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。
-当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。
-
-`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。
-这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的，
-尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。
-
-这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值，
-那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。
-
-以指标 `A` 为例，这里假设 `A` 指标在 1.n 版本中被弃用，根据指标弃用策略，我们可以得出以下结论：
-
-<!--
-* In release `1.n`, the metric is deprecated, and it can be emitted by default.
-* In release `1.n+1`, the metric is hidden by default and it can be emitted by command line `show-hidden-metrics-for-version=1.n`.
-* In release `1.n+2`, the metric should be removed from the codebase. No escape hatch anymore.
-
-If you're upgrading from release `1.12` to `1.13`, but still depend on a metric `A` deprecated in `1.12`, you should set hidden metrics via command line: `--show-hidden-metrics=1.12` and remember to remove this metric dependency before upgrading to `1.14`
-->
-
-* 在 `1.n` 版本中，这个指标被弃用，并且默认情况下，这个指标还是可以发出.
-* 在 `1.n+1` 版本中，这个指标默认被隐藏，你可以通过设置参数 `show-hidden-metrics-for-version=1.n` 来使它可以被发出.
-* 在 `1.n+2` 版本中，这个指标就被从代码库中删除，也不会再有后门了.
-
-如果你想要从 `1.12` 版本升级到 `1.13` ，但仍然需要依赖指标 `A` ，
-你可以通过命令行设置隐藏指标 `--show-hidden-metrics=1.12`，
-但是在升级到 `1.14`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。
-
-<!--
-## Component metrics
-
-### kube-controller-manager metrics
-
-Controller manager metrics provide important insight into the performance and health of the controller manager.
-These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
-etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
-to gauge the health of a cluster.
-
-Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
-These metrics can be used to monitor health of persistent volume operations.
-
-For example, for GCE these metrics are called:
-->
-## 组件指标
-
-### kube-controller-manager 指标
-
-控制器管理器指标提供了有关控制器管理器性能和运行状况的重要见解。这些指标包括常见的一些 Go 语言运行时的重要指标（比如 go_routine 的数量）和一些控制器的特定指标（比如 etcd 的请求时延），还有一些云供应商（比如 AWS、GCE、OpenStack）的 API 请求延迟，用来评估集群的整体运行状况。
-
-从 Kubernetes 1.7 开始，详细的云供应商指标便可用于 GCE、 AWS、Vsphere 和 OpenStack 的存储操作，这些指标可用于监控持久卷运行时的健康状况。
-
-举例，GCE 的这些指标是这些：
-
-```
-cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
-cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
-```
-
-## {{% heading "whatsnext" %}}
-
-<!--
-* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
-* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
-* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
-->
-
-* 了解有关 [Prometheus 指标相关的文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
-* 查看 [Kubernetes 稳定版指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)列表
-* 了解有关 [Kubernetes 指标弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
-
-
@@ -815,7 +815,7 @@ If you want to use project quotas, you should:
  [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
  in the kubelet configuration.

-* Ensure that the the root filesystem (or optional runtime filesystem)
+* Ensure that the root filesystem (or optional runtime filesystem)
  has project quotas enabled. All XFS filesystems support project quotas.
  For ext4 filesystems, you need to enable the project quota tracking feature
  while the filesystem is not mounted.
@@ -239,7 +239,7 @@ Similarly the comma separator acts as an _AND_ operator. So filtering resources
 The _set-based_ label selector is a general form of equality since `environment=production` is equivalent to `environment in (production)`; similarly for `!=` and `notin`.
 -->
 _基于集合_ 的标签选择算符是相等标签选择算符的一般形式，因为 `environment=production`
-等同于 `environment in（production`；`!=` 和 `notin` 也是类似的。
+等同于 `environment in（production）`；`!=` 和 `notin` 也是类似的。

 <!--
 _Set-based_ requirements can be mixed with _equality-based_ requirements. For example: `partition in (customerA, customerB),environment!=qa`.
@@ -385,7 +385,7 @@ Issue，不必修复。

 Some docs issues are actually issues with the underlying code, or requests for
 assistance when something, for example a tutorial, doesn't work.
-For issues unrelated to docs, close the issue with the `triage/support` label and a comment
+For issues unrelated to docs, close the issue with the `kind/support` label and a comment
 directing the requester to support venues (Slack, Stack Overflow) and, if
 relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes`
 is a great place to start).
@@ -396,7 +396,7 @@ Sample response to a request for support:

 某些文档 Issues 实际上是关于底层代码的 Issue 或者在某方面请求协助的问题，
 例如某个教程无法正常工作。
-对于与文档无关的 Issues，关闭它并打上标签 `triage/support`，可以通过评论
+对于与文档无关的 Issues，关闭它并打上标签 `kind/support`，可以通过评论
 告知请求者其他支持渠道（Slack、Stack Overflow）。
 如果有相关的其他仓库，可以告诉请求者应该在哪个仓库登记与功能特性相关的 Issues
 （通常会是 `kubernetes/kubernetes`）。
@@ -30,18 +30,14 @@ Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
 kubectl [flags]
 ```

-
-
 ## {{% heading "options" %}}

-
-<table style="width: 100%; table-layout: fixed;">
-  <colgroup>
-    <col span="1" style="width: 10px;" />
-    <col span="1" />
-  </colgroup>
-  <tbody>
-
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
    <tr>
      <td colspan="2">--add-dir-header</td>
    </tr>
@@ -53,7 +49,6 @@ kubectl [flags]
      设置为 true 表示添加文件目录到 header 中
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--alsologtostderr</td>
    </tr>
@@ -65,7 +60,6 @@ kubectl [flags]
      表示将日志输出到文件的同时输出到 stderr
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--as string</td>
    </tr>
@@ -77,7 +71,6 @@ kubectl [flags]
      以指定用户的身份执行操作
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--as-group stringArray</td>
    </tr>
@@ -89,7 +82,6 @@ kubectl [flags]
      模拟指定的组来执行操作，可以使用这个标志来指定多个组。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--azure-container-registry-config string</td>
    </tr>
@@ -101,7 +93,6 @@ kubectl [flags]
      包含 Azure 容器仓库配置信息的文件的路径。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--cache-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "~/.kube/http-cache"</td>
    </tr>
@@ -113,7 +104,6 @@ kubectl [flags]
      默认 HTTP 缓存目录
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--certificate-authority string</td>
    </tr>
@@ -125,7 +115,6 @@ kubectl [flags]
      指向证书机构的 cert 文件路径
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--client-certificate string</td>
    </tr>
@@ -137,7 +126,6 @@ kubectl [flags]
      TLS 使用的客户端证书路径
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--client-key string</td>
    </tr>
@@ -149,7 +137,6 @@ kubectl [flags]
      TLS 使用的客户端密钥文件路径
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--cloud-provider-gce-lb-src-cidrs cidrs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16</td>
    </tr>
@@ -161,7 +148,6 @@ kubectl [flags]
      在 GCE 防火墙中打开 CIDR，以进行 LB 流量代理和运行状况检查。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--cluster string</td>
    </tr>
@@ -173,7 +159,6 @@ kubectl [flags]
      要使用的 kubeconfig 集群的名称
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--context string</td>
    </tr>
@@ -185,7 +170,6 @@ kubectl [flags]
      要使用的 kubeconfig 上下文的名称
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--default-not-ready-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 300</td>
    </tr>
@@ -197,7 +181,6 @@ kubectl [flags]
      表示 `notReady` 状态的容忍度秒数：默认情况下，`NoExecute` 被添加到尚未具有此容忍度的每个 Pod 中。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--default-unreachable-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 300</td>
    </tr>
@@ -209,7 +192,6 @@ kubectl [flags]
      表示 `unreachable` 状态的容忍度秒数：默认情况下，`NoExecute` 被添加到尚未具有此容忍度的每个 Pod 中。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">-h, --help</td>
    </tr>
@@ -221,7 +203,6 @@ kubectl [flags]
      kubectl 操作的帮助命令
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--insecure-skip-tls-verify</td>
    </tr>
@@ -233,7 +214,6 @@ kubectl [flags]
      设置为 true，则表示不会检查服务器证书的有效性。这样会导致您的 HTTPS 连接不安全。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--kubeconfig string</td>
    </tr>
@@ -245,7 +225,6 @@ kubectl [flags]
      CLI 请求使用的 kubeconfig 配置文件的路径。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--log-backtrace-at traceLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 0</td>
    </tr>
@@ -257,7 +236,6 @@ kubectl [flags]
      当日志机制运行到指定文件的指定行（file:N）时，打印调用堆栈信息
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--log-dir string</td>
    </tr>
@@ -269,7 +247,6 @@ kubectl [flags]
      如果不为空，则将日志文件写入此目录
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--log-file string</td>
    </tr>
@@ -281,7 +258,6 @@ kubectl [flags]
      如果不为空，则将使用此日志文件
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--log-file-max-size uint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 1800</td>
    </tr>
@@ -293,7 +269,6 @@ kubectl [flags]
      定义日志文件的最大尺寸。单位为兆字节。如果值设置为 0，则表示日志文件大小不受限制。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 5s</td>
    </tr>
@@ -305,7 +280,6 @@ kubectl [flags]
      两次日志刷新操作之间的最长时间（秒）
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--logtostderr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: true</td>
    </tr>
@@ -317,7 +291,6 @@ kubectl [flags]
      日志输出到 stderr 而不是文件中
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--match-server-version</td>
    </tr>
@@ -329,7 +302,6 @@ kubectl [flags]
      要求客户端版本和服务端版本相匹配
      </td>
    </tr>
-
    <tr>
      <td colspan="2">-n, --namespace string</td>
    </tr>
@@ -341,7 +313,6 @@ kubectl [flags]
      如果存在，CLI 请求将使用此命名空间
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--password string</td>
    </tr>
@@ -353,7 +324,6 @@ kubectl [flags]
      API 服务器进行基本身份验证的密码
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--profile string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "none"</td>
    </tr>
@@ -365,7 +335,6 @@ kubectl [flags]
      要记录的性能指标的名称。可取 (none|cpu|heap|goroutine|threadcreate|block|mutex) 其中之一。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--profile-output string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "profile.pprof"</td>
    </tr>
@@ -377,7 +346,6 @@ kubectl [flags]
      用于转储所记录的性能信息的文件名
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--request-timeout string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "0"</td>
    </tr>
@@ -389,7 +357,6 @@ kubectl [flags]
      放弃单个服务器请求之前的等待时间，非零值需要包含相应时间单位（例如：1s、2m、3h）。零值则表示不做超时要求。
      </td>
    </tr>
-
    <tr>
      <td colspan="2">-s, --server string</td>
    </tr>
@@ -401,7 +368,6 @@ kubectl [flags]
      Kubernetes API 服务器的地址和端口
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--skip-headers</td>
    </tr>
@@ -413,7 +379,6 @@ kubectl [flags]
      设置为 true 则表示跳过在日志消息中出现 header 前缀信息
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--skip-log-headers</td>
    </tr>
@@ -425,7 +390,6 @@ kubectl [flags]
      设置为 true 则表示在打开日志文件时跳过 header 信息
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--stderrthreshold severity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 2</td>
    </tr>
@@ -437,7 +401,6 @@ kubectl [flags]
      等于或高于此阈值的日志将输出到标准错误输出（stderr）
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--token string</td>
    </tr>
@@ -449,7 +412,6 @@ kubectl [flags]
      用于对 API 服务器进行身份认证的持有者令牌
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--user string</td>
    </tr>
@@ -461,7 +423,6 @@ kubectl [flags]
      指定使用 kubeconfig 配置文件中的用户名
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--username string</td>
    </tr>
@@ -473,7 +434,6 @@ kubectl [flags]
      用于 API 服务器的基本身份验证的用户名
      </td>
    </tr>
-
    <tr>
      <td colspan="2">-v, --v Level</td>
    </tr>
@@ -485,7 +445,6 @@ kubectl [flags]
      指定输出日志的日志详细级别
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--version version[=true]</td>
    </tr>
@@ -497,7 +456,6 @@ kubectl [flags]
      打印 kubectl 版本信息并退出
      </td>
    </tr>
-
    <tr>
      <td colspan="2">--vmodule moduleSpec</td>
    </tr>
@@ -509,7 +467,6 @@ kubectl [flags]
      以逗号分隔的 pattern=N 设置列表，用于过滤文件的日志记录
      </td>
    </tr>
-
  </tbody>
 </table>

@@ -206,7 +206,7 @@ To create a new secret perform the following steps:
 {{< caution >}}
 你的配置文件包含可以解密 etcd 内容的密钥，因此你必须正确限制主控节点的访问权限，
 以便只有能运行 kube-apiserver 的用户才能读取它。
-{{< caution >}}
+{{< /caution >}}

 <!--
 ## Verifying that data is encrypted
@@ -232,9 +232,8 @@ program to retrieve the contents of your secret.
 2. Using the etcdctl commandline, read that secret out of etcd:
 -->
 2. 使用 etcdctl 命令行，从 etcd 中读取 secret：
-
   ```shell
-   ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
+   ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
   ```

   <!--
@@ -0,0 +1,619 @@
+---
+title: 使用 Stackdriver 生成日志
+content_type: concept
+---
+
+<!--
+reviewers:
+- piosz
+- x13n
+title: Logging Using Stackdriver
+content_type: concept
+-->
+
+<!-- overview -->
+
+<!--
+Before reading this page, it's highly recommended to familiarize yourself
+with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
+-->
+在阅读这篇文档之前，强烈建议你先熟悉一下 [Kubernetes 日志概况](/zh/docs/concepts/cluster-administration/logging)
+
+<!--
+By default, Stackdriver logging collects only your container's standard output and
+standard error streams. To collect any logs your application writes to a file (for example),
+see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
+in the Kubernetes logging overview.
+-->
+
+{{< note >}}
+默认情况下，Stackdriver 日志机制仅收集容器的标准输出和标准错误流。
+如果要收集你的应用程序写入一个文件（例如）的任何日志，请参见 Kubernetes 日志概述中的 [sidecar 方式](/zh/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
+{{< /note >}}
+
+<!-- body -->
+
+<!--
+## Deploying
+-->
+
+## 部署  {#deploying}
+
+<!--
+To ingest logs, you must deploy the Stackdriver Logging agent to each node in your cluster.
+The agent is a configured `fluentd` instance, where the configuration is stored in a `ConfigMap`
+and the instances are managed using a Kubernetes `DaemonSet`. The actual deployment of the
+`ConfigMap` and `DaemonSet` for your cluster depends on your individual cluster setup.
+-->
+为了接收日志，你必须将 Stackdriver 日志代理部署到集群中的每个节点。
+此代理是一个已配置的 `fluentd`，其配置存在一个 `ConfigMap` 中，且实例使用 Kubernetes 的 `DaemonSet` 进行管理。
+`ConfigMap` 和 `DaemonSet` 的实际部署，取决你的集群设置。
+
+<!--
+### Deploying to a new cluster
+-->
+
+### 部署到一个新的集群
+
+#### Google Kubernetes Engine
+
+<!--
+Stackdriver is the default logging solution for clusters deployed on Google Kubernetes Engine.
+Stackdriver Logging is deployed to a new cluster by default unless you explicitly opt-out.
+-->
+对于部署在 Google Kubernetes Engine 上的集群，Stackdriver 是默认的日志解决方案。
+Stackdriver 日志机制会默认部署到你的新集群上，除非你明确地不选择。
+
+<!--
+#### Other platforms
+-->
+
+#### 其他平台
+
+<!--
+To deploy Stackdriver Logging on a *new* cluster that you're
+creating using `kube-up.sh`, do the following:
+-->
+为了将 Stackdriver 日志机制部署到你正在使用 `kube-up.sh` 创建的*新*集群上，执行如下操作：
+
+<!--
+1. Set the `KUBE_LOGGING_DESTINATION` environment variable to `gcp`.
+1. **If not running on GCE**, include the `beta.kubernetes.io/fluentd-ds-ready=true`
+in the `KUBE_NODE_LABELS` variable.
+-->
+1. 设置环境变量 `KUBE_LOGGING_DESTINATION` 为 `gcp`。
+1. **如果不是跑在 GCE 上**，在 `KUBE_NODE_LABELS` 变量中包含 `beta.kubernetes.io/fluentd-ds-ready=true`。
+
+<!--
+Once your cluster has started, each node should be running the Stackdriver Logging agent.
+The `DaemonSet` and `ConfigMap` are configured as addons. If you're not using `kube-up.sh`,
+consider starting a cluster without a pre-configured logging solution and then deploying
+Stackdriver Logging agents to the running cluster.
+-->
+
+集群启动后，每个节点都应该运行 Stackdriver 日志代理。
+`DaemonSet` 和 `ConfigMap` 作为附加组件进行配置。
+如果你不是使用 `kube-up.sh`，可以考虑不使用预先配置的日志方案启动集群，然后部署 Stackdriver 日志代理到正在运行的集群。
+
+<!--
+The Stackdriver logging daemon has known issues on platforms other
+than Google Kubernetes Engine. Proceed at your own risk.
+-->
+
+{{< warning >}}
+除了 Google Kubernetes Engine，Stackdriver 日志守护进程在其他的平台有已知的问题。
+请自行承担风险。
+{{< /warning >}}
+
+<!--
+### Deploying to an existing cluster
+-->
+### 部署到一个已知集群
+
+<!--
+1. Apply a label on each node, if not already present.
+-->
+1. 在每个节点上打标签（如果尚未存在）
+   <!--
+   The Stackdriver Logging agent deployment uses node labels to determine to which nodes
+   it should be allocated. These labels were introduced to distinguish nodes with the
+   Kubernetes version 1.6 or higher. If the cluster was created with Stackdriver Logging
+   configured and node has version 1.5.X or lower, it will have fluentd as static pod. Node
+   cannot have more than one instance of fluentd, therefore only apply labels to the nodes
+   that don't have fluentd pod allocated already. You can ensure that your node is labelled
+   properly by running `kubectl describe` as follows:
+   -->
+
+   Stackdriver 日志代理部署使用节点标签来确定应该将其分配到给哪些节点。
+   引入这些标签是为了区分 Kubernetes 1.6 或更高版本的节点。
+   如果集群是在配置了 Stackdriver 日志机制的情况下创建的，并且节点的版本为 1.5.X 或更低版本，则它将使用 fluentd 用作静态容器。
+   节点最多只能有一个 fluentd 实例，因此只能将标签打在未分配过 fluentd pod 的节点上。
+   你可以通过运行 `kubectl describe` 来确保你的节点被正确标记，如下所示：
+
+   ```
+   kubectl describe node $NODE_NAME
+   ```
+   <!--
+   The output should be similar to this:
+   -->
+   输出应类似于如下内容：
+
+   ```
+   Name:           NODE_NAME
+   Role:
+   Labels:         beta.kubernetes.io/fluentd-ds-ready=true
+   ...
+   ```
+   <!--
+   Ensure that the output contains the label `beta.kubernetes.io/fluentd-ds-ready=true`. If it
+   is not present, you can add it using the `kubectl label` command as follows:
+   -->
+   确保输出内容包含 `beta.kubernetes.io/fluentd-ds-ready=true` 标签。
+   如果不存在，则可以使用 `kubectl label` 命令添加，如下所示：
+
+   ```
+   kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
+   ```
+   <!--
+   If a node fails and has to be recreated, you must re-apply the label to
+   the recreated node. To make this easier, you can use Kubelet's command-line parameter
+   for applying node labels in your node startup script.
+   -->
+
+   {{< note >}}
+   如果节点发生故障并且必须重新创建，则必须将标签重新打在重新创建了的节点。
+   为了让此操作更便捷，你可以在节点启动脚本中使用 Kubelet 的命令行参数给节点添加标签。
+   {{< /note >}}
+
+<!--
+1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
+-->
+2. 通过运行以下命令，部署一个带有日志代理配置的 `ConfigMap`：
+
+   ```
+   kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
+   ```
+   <!--
+   The command creates the `ConfigMap` in the `default` namespace. You can download the file
+   manually and change it before creating the `ConfigMap` object.
+   -->
+   该命令在 `default` 命名空间中创建 `ConfigMap`。你可以在创建 `ConfigMap` 对象之前手动下载文件并进行更改。
+
+<!--
+1. Deploy the logging agent `DaemonSet` by running the following command:
+-->
+3. 通过运行以下命令，部署日志代理的 `DaemonSet`：
+
+   ```
+   kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
+   ```
+   <!--
+   You can download and edit this file before using it as well.
+   -->
+   你也可以在使用前下载和编辑此文件。
+
+<!--
+## Verifying your Logging Agent Deployment
+-->
+## 验证日志代理部署
+
+<!--
+After Stackdriver `DaemonSet` is deployed, you can discover logging agent deployment status
+by running the following command:
+-->
+部署 Stackdriver `DaemonSet` 之后，你可以通过运行以下命令来查看日志代理的部署状态：
+
+```shell
+kubectl get ds --all-namespaces
+```
+
+<!--
+If you have 3 nodes in the cluster, the output should looks similar to this:
+-->
+如果你的集群中有 3 个节点，则输出应类似于如下：
+
+```
+NAMESPACE     NAME               DESIRED   CURRENT   READY     NODE-SELECTOR                              AGE
+...
+default       fluentd-gcp-v2.0   3         3         3         beta.kubernetes.io/fluentd-ds-ready=true   5m
+...
+```
+
+<!--
+To understand how logging with Stackdriver works, consider the following
+synthetic log generator pod specification [counter-pod.yaml](/examples/debug/counter-pod.yaml):
+-->
+要了解使用 Stackdriver 进行日志记录的工作方式，请考虑以下具有日志生成的 pod 定义 [counter-pod.yaml](/examples/debug/counter-pod.yaml)：
+
+{{< codenew file="debug/counter-pod.yaml" >}}
+
+<!--
+This pod specification has one container that runs a bash script
+that writes out the value of a counter and the datetime once per
+second, and runs indefinitely. Let's create this pod in the default namespace.
+-->
+这个 pod 定义里有一个容器，该容器运行一个 bash 脚本，脚本每秒写一次计数器的值和日期时间，并无限期地运行。
+让我们在默认命名空间中创建此 pod。
+
+```shell
+kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+
+<!--
+You can observe the running pod:
+-->
+你可以观察到正在运行的 pod：
+
+```shell
+kubectl get pods
+```
+```
+NAME                                           READY     STATUS    RESTARTS   AGE
+counter                                        1/1       Running   0          5m
+```
+
+<!--
+For a short period of time you can observe the 'Pending' pod status, because the kubelet
+has to download the container image first. When the pod status changes to `Running`
+you can use the `kubectl logs` command to view the output of this counter pod.
+-->
+在短时间内，你可以观察到 "pending" 的 pod 的状态，因为 kubelet 必须先下载容器镜像。
+当 pod 状态变为 `Running` 时，你可以使用 `kubectl logs` 命令查看此 counter pod 的输出。
+
+```shell
+kubectl logs counter
+```
+```
+0: Mon Jan  1 00:00:00 UTC 2001
+1: Mon Jan  1 00:00:01 UTC 2001
+2: Mon Jan  1 00:00:02 UTC 2001
+...
+```
+
+<!--
+As described in the logging overview, this command fetches log entries
+from the container log file. If the container is killed and then restarted by
+Kubernetes, you can still access logs from the previous container. However,
+if the pod is evicted from the node, log files are lost. Let's demonstrate this
+by deleting the currently running counter container:
+-->
+正如日志概览所述，此命令从容器日志文件中获取日志项。
+如果该容器被 Kubernetes 杀死然后重新启动，你仍然可以访问前一个容器的日志。
+但是，如果将 Pod 从节点中驱逐，则日志文件会丢失。让我们通过删除当前运行的 counter 容器来演示这一点：
+
+```shell
+kubectl delete pod counter
+```
+```
+pod "counter" deleted
+```
+
+<!--
+and then recreating it:
+-->
+然后重建它：
+
+```shell
+kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+```
+pod/counter created
+```
+
+<!--
+After some time, you can access logs from the counter pod again:
+-->
+一段时间后，你可以再次从 counter pod 访问日志：
+
+```shell
+kubectl logs counter
+```
+```
+0: Mon Jan  1 00:01:00 UTC 2001
+1: Mon Jan  1 00:01:01 UTC 2001
+2: Mon Jan  1 00:01:02 UTC 2001
+...
+```
+
+<!--
+As expected, only recent log lines are present. However, for a real-world
+application you will likely want to be able to access logs from all containers,
+especially for the debug purposes. This is exactly when the previously enabled
+Stackdriver Logging can help.
+-->
+如预期的那样，日志中仅出现最近的日志记录。
+但是，对于实际应用程序，你可能希望能够访问所有容器的日志，特别是出于调试的目的。
+这就是先前启用的 Stackdriver 日志机制可以提供帮助的地方。
+
+<!--
+## Viewing logs
+-->
+## 查看日志
+
+<!--
+Stackdriver Logging agent attaches metadata to each log entry, for you to use later
+in queries to select only the messages you're interested in: for example,
+the messages from a particular pod.
+-->
+Stackdriver 日志代理为每个日志项关联元数据，供你在后续的查询中只选择感兴趣的消息：
+例如，来自某个特定 Pod 的消息。
+
+<!--
+The most important pieces of metadata are the resource type and log name.
+The resource type of a container log is `container`, which is named
+`GKE Containers` in the UI (even if the Kubernetes cluster is not on Google Kubernetes Engine).
+The log name is the name of the container, so that if you have a pod with
+two containers, named `container_1` and `container_2` in the spec, their logs
+will have log names `container_1` and `container_2` respectively.
+-->
+元数据最重要的部分是资源类型和日志名称。
+容器日志的资源类型为 `container`，在用户界面中名为 `GKE Containers`（即使 Kubernetes 集群不在 Google Kubernetes Engine 上）。
+日志名称是容器的名称，因此，如果你有一个包含两个容器的 pod，在 spec 中名称定义为 `container_1` 和 `container_2`，则它们的日志的名称分别为 `container_1` 和 `container_2`。
+
+<!--
+System components have resource type `compute`, which is named
+`GCE VM Instance` in the interface. Log names for system components are fixed.
+For a Google Kubernetes Engine node, every log entry from a system component has one of the following
+log names:
+-->
+系统组件的资源类型为 `compute`，在接口中名为 `GCE VM Instance`。
+系统组件的日志名称是固定的。
+对于 Google Kubernetes Engine 节点，系统组件中的每个日志项都具有以下日志名称之一：
+
+* docker
+* kubelet
+* kube-proxy
+
+<!--
+You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
+-->
+你可以在[专用 Stackdriver 页面](https://cloud.google.com/logging/docs/view/overview)上了解有关查看日志的更多信息。
+
+<!--
+One of the possible ways to view logs is using the
+[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging)
+command line interface from the [Google Cloud SDK].
+It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
+to query specific logs. For example, you can run the following command:
+-->
+查看日志的一种可能方法是使用 [Google Cloud SDK]((https://cloud.google.com/sdk/)) 中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging) 命令行接口。
+它使用 Stackdriver 日志机制的[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。
+例如，你可以运行以下命令：
+
+```none
+gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
+```
+```
+...
+"2: Mon Jan  1 00:01:02 UTC 2001\n"
+"1: Mon Jan  1 00:01:01 UTC 2001\n"
+"0: Mon Jan  1 00:01:00 UTC 2001\n"
+...
+"2: Mon Jan  1 00:00:02 UTC 2001\n"
+"1: Mon Jan  1 00:00:01 UTC 2001\n"
+"0: Mon Jan  1 00:00:00 UTC 2001\n"
+```
+
+<!--
+As you can see, it outputs messages for the count container from both
+the first and second runs, despite the fact that the kubelet already deleted
+the logs for the first container.
+-->
+如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter 容器第一次和第二次运行时输出的消息。
+
+<!--
+### Exporting logs
+-->
+### 导出日志
+
+<!--
+You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/)
+or to [BigQuery](https://cloud.google.com/bigquery/) to run further
+analysis. Stackdriver Logging offers the concept of sinks, where you can
+specify the destination of log entries. More information is available on
+the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2).
+-->
+你可以将日志导出到 [Google Cloud Storage](https://cloud.google.com/storage/) 或
+[BigQuery](https://cloud.google.com/bigquery/) 进行进一步的分析。
+Stackdriver 日志机制提供了接收器（Sink）的概念，你可以在其中指定日志项的存放地。
+可在 Stackdriver [导出日志页面](https://cloud.google.com/logging/docs/export/configure_export_v2)上获得更多信息。
+
+<!--
+## Configuring Stackdriver Logging Agents
+-->
+## 配置 Stackdriver 日志代理
+
+<!--
+Sometimes the default installation of Stackdriver Logging may not suit your needs, for example:
+-->
+有时默认的 Stackdriver 日志机制安装可能无法满足你的需求，例如：
+
+<!--
+* You may want to add more resources because default performance doesn't suit your needs.
+* You may want to introduce additional parsing to extract more metadata from your log messages,
+like severity or source code reference.
+* You may want to send logs not only to Stackdriver or send it to Stackdriver only partially.
+-->
+* 你可能需要添加更多资源，因为默认的行为表现无法满足你的需求。
+* 你可能需要引入额外的解析机制以便从日志消息中提取更多元数据，例如严重性或源代码引用。
+* 你可能想要将日志不仅仅发送到 Stackdriver 或仅将部分日志发送到 Stackdriver。
+
+<!--
+In this case you need to be able to change the parameters of `DaemonSet` and `ConfigMap`.
+-->
+在这种情况下，你需要更改 `DaemonSet` 和 `ConfigMap` 的参数。
+
+<!--
+### Prerequisites
+-->
+### 先决条件
+
+<!--
+If you're using GKE and Stackdriver Logging is enabled in your cluster, you
+cannot change its configuration, because it's managed and supported by GKE.
+However, you can disable the default integration and deploy your own.
+-->
+如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置，因为它是由 GKE 管理和支持的。
+但是，你可以禁用默认集成的日志机制并部署自己的。
+
+<!--
+You will have to support and maintain a newly deployed configuration
+yourself: update the image and configuration, adjust the resources and so on.
+-->
+
+{{< note >}}
+你将需要自己支持和维护新部署的配置了：更新映像和配置、调整资源等等。
+{{< /note >}}
+
+<!--
+To disable the default logging integration, use the following command:
+-->
+若要禁用默认的日志记录集成，请使用以下命令：
+
+```
+gcloud beta container clusters update --logging-service=none CLUSTER
+```
+
+<!--
+You can find notes on how to then install Stackdriver Logging agents into
+a running cluster in the [Deploying section](#deploying).
+-->
+你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到正在运行的集群中的说明。
+
+<!--
+### Changing `DaemonSet` parameters
+-->
+### 更改 `DaemonSet` 参数    {#changing-daemonset-parameters}
+
+<!--
+When you have the Stackdriver Logging `DaemonSet` in your cluster, you can just modify the
+`template` field in its spec, daemonset controller will update the pods for you. For example,
+let's assume you've just installed the Stackdriver Logging as described above. Now you want to
+change the memory limit to give fluentd more memory to safely process more logs.
+-->
+当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的 `template` 字段，daemonset 控制器将为你更新 pod。
+例如，假设你按照上面的描述已经安装了 Stackdriver 日志机制。
+现在，你想更改内存限制，来给 fluentd 提供的更多内存，从而安全地处理更多日志。
+
+<!--
+Get the spec of `DaemonSet` running in your cluster:
+-->
+获取集群中运行的 `DaemonSet` 的 spec：
+
+```shell
+kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml
+```
+
+<!--
+Then edit resource requirements in the spec file and update the `DaemonSet` object
+in the apiserver using the following command:
+-->
+然后在 spec 文件中编辑资源需求，并使用以下命令更新 apiserver 中的 `DaemonSet` 对象：
+
+```shell
+kubectl replace -f fluentd-gcp-ds.yaml
+```
+
+<!--
+After some time, Stackdriver Logging agent pods will be restarted with the new configuration.
+-->
+一段时间后，Stackdriver 日志代理的 pod 将使用新配置重新启动。
+
+<!--
+### Changing fluentd parameters
+-->
+### 更改 fluentd 参数
+
+<!--
+Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration
+files that are merged together. You can learn about fluentd configuration on the
+[official site](https://docs.fluentd.org).
+-->
+Fluentd 的配置存在 `ConfigMap` 对象中。
+它实际上是一组合并在一起的配置文件。
+你可以在[官方网站](https://docs.fluentd.org)上了解 fluentd 的配置。
+
+<!--
+Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand
+default Python logging format. An appropriate fluentd filter looks similar to this:
+-->
+假设你要向配置添加新的解析逻辑，以便 fluentd 可以理解默认的 Python 日志记录格式。
+一个合适的 fluentd 过滤器类似如下：
+
+```
+<filter reform.**>
+  type parser
+  format /^(?<severity>\w):(?<logger_name>\w):(?<log>.*)/
+  reserve_data true
+  suppress_parse_error_log true
+  key_name log
+</filter>
+```
+
+<!--
+Now you have to put it in the configuration and make Stackdriver Logging agents pick it up.
+Get the current version of the Stackdriver Logging `ConfigMap` in your cluster
+by running the following command:
+-->
+现在，你需要将其放入配置中，并使 Stackdriver 日志代理感知它。
+通过运行以下命令，获取集群中当前版本的 Stackdriver 日志机制的 `ConfigMap`：
+
+```shell
+kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml
+```
+
+<!--
+Then in the value of the key `containers.input.conf` insert a new filter right after
+the `source` section.
+-->
+然后在 `containers.input.conf` 键的值中，在 `source` 部分之后插入一个新的过滤器。
+
+<!--
+Order is important.
+-->
+
+{{< note >}}
+顺序很重要。
+{{< /note >}}
+
+<!--
+Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
+to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should
+create `ConfigMap` with a new name and then change `DaemonSet` to point to it
+using [guide above](#changing-daemonset-parameters).
+-->
+在 apiserver 中更新 `ConfigMap` 比更新 `DaemonSet` 更复杂。
+最好考虑 `ConfigMap` 是不可变的。
+如果是这样，要更新配置，你应该使用新名称创建 `ConfigMap`，然后使用
+[上面的指南](#changing-daemonset-parameters)将 `DaemonSet` 更改为指向它。
+
+<!--
+### Adding fluentd plugins
+-->
+### 添加 fluentd 插件
+
+<!--
+Fluentd is written in Ruby and allows to extend its capabilities using
+[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included
+in the default Stackdriver Logging container image, you have to build a custom image. Imagine
+you want to add Kafka sink for messages from a particular container for additional processing.
+You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
+with minor changes:
+-->
+Fluentd 用 Ruby 编写，并允许使用 [plugins](https://www.fluentd.org/plugins) 扩展其功能。
+如果要使用默认的 Stackdriver 日志机制容器镜像中未包含的插件，则必须构建自定义镜像。
+假设你要为来自特定容器添加 Kafka 信息接收器，以进行其他处理。
+你可以复用默认的[容器镜像源](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)，并仅添加少量更改：
+
+<!--
+* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/<your-project-id>`.
+* Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`.
+-->
+* 将 Makefile 更改为指向你的容器仓库，例如 `PREFIX=gcr.io/<your-project-id>`。
+* 将你的依赖项添加到 Gemfile 中，例如 `gem 'fluent-plugin-kafka'`。
+
+<!--
+Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
+new image, you can use the plugin you installed in the fluentd configuration.
+-->
+然后在该目录运行 `make build push`。在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。
@@ -243,14 +243,14 @@ An older kubectl plugin mechanism provided environment variables such as `KUBECT
 kubectl plugins must parse and validate all of the arguments passed to them.
 See [using the command line runtime package](#using-the-command-line-runtime-package) for details of a Go library aimed at plugin authors.

-Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the the `kubectl-foo-bar-baz` plugin from the scenario above.
+Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the `kubectl-foo-bar-baz` plugin from the scenario above.
 -->
 kubeclt 插件必须解析并检查传递给它们的所有参数。
 参阅[使用命令行运行时包](#using-the-command-line-runtime-package)了解针对
 插件开发人员的 Go 库的细节。

 <!--
-Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the the `kubectl-foo-bar-baz` plugin from the scenario above.
+Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the `kubectl-foo-bar-baz` plugin from the scenario above.
 -->
 这里是一些用户调用你的插件的时候提供额外标志和参数的场景。
 这些场景时基于上述案例中的 `kubectl-foo-bar-baz` 插件的。
@@ -0,0 +1,115 @@
+---
+title: 定义相互依赖的环境变量
+content_type: task
+weight: 20
+---
+<!-- 
+title: Define Dependent Environment Variables
+-->
+
+<!-- overview -->
+
+<!-- 
+This page shows how to define dependent environment variables for a container
+in a Kubernetes Pod.
+-->
+本页展示了如何为 Kubernetes Pod 中的容器定义相互依赖的环境变量。
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+
+<!-- steps -->
+
+<!-- 
+## Define an environment dependent variable for a container
+
+When you create a Pod, you can set dependent environment variables for the containers that run in the Pod. To set dependent environment variables, you can use $(VAR_NAME) in the `value` of `env` in the configuration file.
+
+In this exercise, you create a Pod that runs one container. The configuration
+file for the Pod defines an dependent environment variable with common usage defined. Here is the configuration manifest for the
+Pod:
+-->
+## 为容器定义相互依赖的环境变量   {#define-an-environment-dependent-variable-for-a-container}
+
+当创建一个 Pod 时，你可以为运行在 Pod 中的容器设置相互依赖的环境变量。 
+设置相互依赖的环境变量，你就可以在配置清单文件的 `env` 的 `value` 中使用 $(VAR_NAME)。
+
+在本练习中，你会创建一个单容器的 Pod。
+此 Pod 的配置文件定义了一个已定义常用用法的相互依赖的环境变量。
+下面是 Pod 的配置清单：
+
+{{< codenew file="pods/inject/dependent-envars.yaml" >}}
+
+<!-- 1. Create a Pod based on that manifest: -->
+1. 依据清单创建 Pod：
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
+    ```
+    ```
+    pod/dependent-envars-demo created
+    ```
+    <!-- 2. List the running Pods: -->
+2. 列出运行的 Pod：
+
+    ```shell
+    kubectl get pods dependent-envars-demo
+    ```
+    ```
+    NAME                      READY     STATUS    RESTARTS   AGE
+    dependent-envars-demo     1/1       Running   0          9s
+    ```
+
+    <!-- 3. Check the logs for the container running in your Pod: -->
+3. 检查 Pod 中运行容器的日志：
+
+    ```shell
+    kubectl logs pod/dependent-envars-demo
+    ```
+    ```
+
+    UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+    SERVICE_ADDRESS=https://172.17.0.1:80
+    ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+    ```
+
+<!-- 
+As shown above, you have defined the correct dependency reference of `SERVICE_ADDRESS`, bad dependency reference of `UNCHANGED_REFERENCE` and skip dependent references of `ESCAPED_REFERENCE`.
+
+When an environment variable is already defined when being referenced,
+the reference can be correctly resolved, such as in the `SERVICE_ADDRESS` case.
+-->
+如上所示，你已经定义了 `SERVICE_ADDRESS` 的正确依赖引用，
+`UNCHANGED_REFERENCE` 的错误依赖引用，
+并跳过了 `ESCAPED_REFERENCE` 的依赖引用。
+
+如果环境变量被引用时已事先定义，则引用可以正确解析，
+比如 `SERVICE_ADDRESS` 的例子。
+
+<!-- 
+When the environment variable is undefined or only includes some variables, the undefined environment variable is treated as a normal string, such as `UNCHANGED_REFERENCE`. Note that incorrectly parsed environment variables, in general, will not block the container from starting.
+
+The `$(VAR_NAME)` syntax can be escaped with a double `$`, ie: `$$(VAR_NAME)`.
+Escaped references are never expanded, regardless of whether the referenced variable
+is defined or not. This can be seen from the `ESCAPED_REFERENCE` case above.
+-->
+当环境变量未定义或仅包含部分变量时，未定义的变量会被当做普通字符串对待，
+比如 `UNCHANGED_REFERENCE` 的例子。
+注意，解析不正确的环境变量通常不会阻止容器启动。
+
+`$(VAR_NAME)` 这样的语法可以用两个 `$` 转义，既：`$$(VAR_NAME)`。
+无论引用的变量是否定义，转义的引用永远不会展开。
+这一点可以从上面 `ESCAPED_REFERENCE` 的例子得到印证。
+
+## {{% heading "whatsnext" %}}
+
+
+<!--
+* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
+* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
+-->
+* 进一步了解[环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
+* 参阅 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
+
@@ -45,12 +45,6 @@ Before walking through each tutorial, you may want to bookmark the
 * [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.
 -->

-* [使用 Kubernetes (Udacity) 的可伸缩微服务](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
-
-<!--
-* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
-->
-
 * [介绍 Kubernetes (edx)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)

 <!--
@@ -207,7 +207,7 @@ Pod runs a Container based on the provided Docker image.
 <!--
    {{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
 -->
-   {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/user-guide/kubectl-overview/)。{{< /note >}}
+   {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/reference/kubectl/overview/)。{{< /note >}}

 <!--
 ## Create a Service
@@ -1,4 +0,0 @@
---
-title: "在线培训课程"
-weight: 20
---
@@ -1,170 +0,0 @@
---
-title: Kubernetes 在线培训概述
-content_type: concept
---
-<!--
---
-title: Overview of Kubernetes Online Training
-content_type: concept
---
-->
-
-<!-- overview -->
-
-<!--
-Here are some of the sites that offer online training for Kubernetes:
-->
-以下是提供 Kubernetes 在线培训的一些网站:
-
-
-
-<!-- body -->
-
-<!--
-* [AIOps Essentials (Autoscaling Kubernetes with Prometheus Metrics) with Hands-On Labs (Linux Academy)](https://linuxacademy.com/devops/training/course/name/using-machine-learning-to-scale-kubernetes-clusters)
-->
-* [AIOps Essentials (使用 Prometheus 度量标准自动缩放 Kubernetes) 和动手实验室 (Linux 学院)]
- (https://linuxacademy.com/devops/training/course/name/using-machine-learning-to-scale-kubernetes-clusters)
-
-<!--
-* [Amazon EKS Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/amazon-web-services/training/course/name/amazon-eks-deep-dive)
-->
-* [带有动手实验室的 Amazon EKS 深入研究(Linux 学院)] (https://linuxacademy.com/amazon-web-services/training/course/name/amazon-eks-deep-dive)
-
-<!--
-* [Cloud Native Certified Kubernetes Administrator (CKA) with Hands-On Labs & Practice Exams (Linux Academy)](https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)
-->
-* [具有动手实验和实践考试的 Cloud Native 认证 Kubernetes 管理员 (CKA)(Linux 学院)]
-(https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)
-
-<!--
-* [Certified Kubernetes Administrator Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
-->
-* [带有实践测试的认证 Kubernetes 管理员准备课程 (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
-
-<!--
-* [Certified Kubernetes Application Developer (CKAD) with Hands-On Labs & Practice Exams (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)
-->
-* [经过实践实验室和实践考试认证的 Kubernetes 应用程序开发人员(CKAD) (Linux 学院)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)
-
-<!--
-* [Certified Kubernetes Application Developer Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
-->
-* [经过认证的带有实践测试的 Kubernetes 应用程序开发人员准备课程 (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
-
-<!--
-*[Getting Started with Google Kubernetes Engine (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
-->
-* [Google Kubernetes 引擎入门(Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
-
-<!--
-* [Getting Started with Kubernetes (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes)
-->
-* [Kubernetes 入门 (Pluralsight)]
-(https://www.pluralsight.com/courses/getting-started-kubernetes)
-
-<!--
-* [Getting Started with Kubernetes Clusters on OCI Oracle Kubernetes Engine (OKE) (Learning Library)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)
-->
-* [OCI Oracle Kubernetes 引擎(OKE)上的 Kubernetes集群入门 (学习库)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)
-
-<!--
-* [Google Kubernetes Engine Deep Dive (Linux Academy)] (https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive)
-->
-* [Google Kubernetes 引擎深度学习 (Linux 学院)]
-(https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive)
-
-<!--
-* [Helm Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1)
-->
-* [通过动手实验室进行深度学习(Linux 学院)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1)
-
-<!--
-* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
-->
-* [Kubernetes 的动手入门 (Instruqt)]
-(https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
-
-<!--
-* [IBM Cloud: Deploying Microservices with Kubernetes (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
-->
-* [IBM Cloud: 使用 Kubernetes 部署微服务 (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
-
-<!--
-* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
-->
-* [Kubernetes (edX) 简介](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
-
-<!--
-* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
-->
-* [带动手实验室的 Kubernetes Essentials (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
-
-<!--
-* [Kubernetes for the Absolute Beginners with Hands-on Labs (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
-->
-* [通过动手实验室为绝对初学者提供 Kubernetes (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
-
-<!--
-* [Kubernetes Fundamentals (LFS258) (The Linux Foundation)](https://training.linuxfoundation.org/training/kubernetes-fundamentals/)
-->
-* [Kubernetes 基础 (LFS258) (Linux 基金会)](https://training.linuxfoundation.org/training/kubernetes-fundamentals/)
-
-<!--
-* [Kubernetes Quick Start with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
-->
-* [Kubernetes 动手实验室快速入门 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
-
-<!--
-* [Kubernetes the Hard Way with Hands-On Labs (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
-->
-* [Kubernetes 通过动手实验室解决难题 (Linux 学院)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
-
-<!--
-* [Kubernetes Security with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-security)
-->
-* [通过动手实验室实现 Kubernetes 安全性(Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-security)
-
-<!--
-* [Launch Your First OpenShift Operator with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/red-hat-open-shift)
-->
-* [通过动手实验室启动您的第一个 OpenShift 操作 (Linux 学院)] (https://linuxacademy.com/containers/training/course/name/red-hat-open-shift)
-
-<!--
-* [Learn Kubernetes by Doing - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing)
-->
-* [边干边学 Kubernetes  - 100% 动手体验 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing)
-
-<!--
-* [Learn Kubernetes using Interactive Hands-on Scenarios (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
-->
-* [使用交互式动手场景学习 Kubernetes (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
-
-<!--
-* [Microservice Applications in Kubernetes - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing)
-->
-* [Kubernetes中的微服务应用程序 - 100% 动手体验 (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing)
-
-<!--
-* [Monitoring Kubernetes With Prometheus with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
-->
-* [通过动手实验室使用 Prometheus 监控 Kubernetes (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
-
-<!--
-* [Service Mesh with Istio with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1)
-->
-* [带动手实验室的 Istio 服务网络 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1)
-
-<!--
-* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
-->
-* [使用 Kubernetes 的可扩展微服务(Udacity)]
-(https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
-
-<!--
-* [Self-paced Kubernetes online course (Learnk8s Academy)](https://learnk8s.io/academy)
-->
-* [自定进度的 Kubernetes 在线课程 (Learnk8s 学院)]
-(https://learnk8s.io/academy)
-
-
@@ -0,0 +1,26 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dependent-envars-demo
+spec:
+  containers:
+    - name: dependent-envars-demo
+      args:
+        - while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done;
+      command:
+        - sh
+        - -c
+      image: busybox
+      env:
+        - name: SERVICE_PORT
+          value: "80"
+        - name: SERVICE_IP
+          value: "172.17.0.1"
+        - name: UNCHANGED_REFERENCE
+          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
+        - name: PROTOCOL
+          value: "https"
+        - name: SERVICE_ADDRESS
+          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
+        - name: ESCAPED_REFERENCE
+          value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
@@ -174,6 +174,9 @@ other = "Mục tiêu"
 [prerequisites_heading]
 other = "Trước khi bắt đầu"

+[subscribe_button]
+other = "Đăng ký"
+
 [ui_search_placeholder]
 other = "Tìm kiếm"

@@ -4,6 +4,9 @@
    {{ partial "head.html" . }}
    <title>{{ if .IsHome }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{ . }} | {{ end }}{{ .Site.Title }}{{ end }}</title>
    <script defer src="https://use.fontawesome.com/releases/v5.0.6/js/all.js"></script>
+    {{ with .Params.canonicalUrl }}
+    <link rel="canonical" href="{{ . }}">
+    {{ end }}
  </head>
  <body class="td-{{ .Kind }} td-blog">
    <header>
@@ -14,7 +14,7 @@
 {{- end }}

 <link rel="stylesheet" href="{{ "css/feature-states.css" | relURL }}">
-<link rel="stylesheet" href="{{ "css/custom-jekyll/tags.css" | relURL }}">
+
 {{- if .Site.Params.announcement }}
 <link rel="stylesheet" href="{{ "css/announcement.css" | relURL }}">
 {{- end }}
@@ -14,13 +14,11 @@
 {{- $glossary_home := "docs/reference/glossary/?all=true" | relLangURL -}}
 {{- $external_link := $term_info.Params.full_link | default (printf "%s#term-%s" $glossary_home $id | safeURL  ) -}}
 {{- $tooltip :=  $term_info.Params.short_description | markdownify -}}
-{{- $tooltip := $tooltip | replaceRE "(?s)<a class='glossary-tooltip'.*?>(.*?)<span class='tooltip-text'>.*</a>" "$1" | plainify -}}
+
+{{- $tooltip := $tooltip | replaceRE "(?s)<a class='glossary-tooltip'.*?>(.*?).*</a>" "$1" | plainify -}}
 {{- $tooltip := trim $tooltip " \n" -}}
-<a class='glossary-tooltip' href='{{ $external_link }}' target='_blank'>
-	{{- $text -}}
-	<span class='tooltip-text'>
-  {{- $tooltip | safeHTML -}}
-	</span>
+<a class='glossary-tooltip' title='{{- $tooltip | safeHTML -}}' data-toggle='tooltip' data-placement='top' href='{{ $external_link }}' target='_blank' aria-label='{{ $text }}'>
+{{- $text -}}
 </a>
 {{- end -}}
 {{- end -}}
@@ -0,0 +1,31 @@
+#!/bin/bash
+#
+# This script checks if the English version of a page has changed since a localized
+# page has been committed.
+
+if [ "$#" -ne 1 ] || ! [ -f "$1" ]; then
+  echo -e "\nThis script checks if the English version of a page has changed since a "
+  echo -e "localized page has been committed.\n"
+  echo -e "Usage:\n\t$0 <PATH>\n" >&2
+  echo -e "Example:\n\t$0 content/zh/docs/concepts/_index.md\n" >&2
+  exit 1
+fi
+
+LOCALIZED="$1"
+
+# Try get the English version
+EN_VERSION=`echo $LOCALIZED | sed "s/content\/..\//content\/en\//g"`
+if ! [ -f $EN_VERSION ]; then
+  echo "$EN_VERSION has been removed."
+  exit 2
+fi
+
+# Last commit for the localized file
+LASTCOMMIT=`git log -n 1 --pretty=format:%h -- $LOCALIZED`
+
+git diff $LASTCOMMIT...HEAD $EN_VERSION
+
+if [ "$?" -eq 0 ]; then
+  echo "$LOCALIZED is still in sync"
+  exit 3
+fi
@@ -1,59 +0,0 @@
-.no-underline {
-  text-decoration: none !important;
-}
-
-.hide {
-  display: none !important;
-}
-
-/* Tooltip container */
-.glossary-tooltip {
-    position: relative;
-    display: inline-block;
-    border-bottom: 1px dotted black; /* If you want dots under the hoverable text */
-    color: black;
-    text-decoration: none !important;
-}
-
-/* Tooltip text */
-.glossary-tooltip .tooltip-text {
-    visibility: hidden;
-    width: 300px;
-    background-color: #555;
-    color: #fff;
-    text-align: center;
-    padding: 5px 8px;
-    border-radius: 6px;
-
-    /* Position the tooltip text */
-    position: absolute;
-    z-index: 10;
-    bottom: 125%;
-    left: 50%;
-    margin-left: -150px;
-
-    /* Fade in tooltip */
-    opacity: 0;
-    transition: opacity 0.3s;
-}
-
-/* Tooltip arrow */
-.glossary-tooltip .tooltip-text::after {
-    content: "";
-    position: absolute;
-    top: 100%;
-    left: 50%;
-    margin-left: -5px;
-    border-width: 5px;
-    border-style: solid;
-    border-color: #555 transparent transparent transparent;
-}
-
-/* Show the tooltip text when you mouse over the tooltip container */
-.glossary-tooltip:hover .tooltip-text {
-    visibility: visible;
-    opacity: 1;
-    font-size: 1rem;
-    font-weight: 400;
-}
-