diff --git a/.github/ISSUE_TEMPLATE/support.md b/.github/ISSUE_TEMPLATE/support.md
index 0363c0837d..fd223c8991 100644
--- a/.github/ISSUE_TEMPLATE/support.md
+++ b/.github/ISSUE_TEMPLATE/support.md
@@ -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**
diff --git a/Dockerfile b/Dockerfile
index 3e3335076c..4ceae22959 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -29,4 +29,6 @@ RUN mkdir -p /usr/local/src && \
WORKDIR /src
+USER hugo:hugo
+
EXPOSE 1313
diff --git a/Makefile b/Makefile
index 56ec8410f4..523775cd17 100644
--- a/Makefile
+++ b/Makefile
@@ -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
diff --git a/README-id.md b/README-id.md
index 5685e72ab9..992adf7ed5 100644
--- a/README-id.md
+++ b/README-id.md
@@ -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/)
diff --git a/README-it.md b/README-it.md
index 7002aef9ee..dea728cba5 100644
--- a/README-it.md
+++ b/README-it.md
@@ -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/)
diff --git a/README.md b/README.md
index dce4cb91a6..52a1b20b87 100644
--- a/README.md
+++ b/README.md
@@ -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
diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss
index f511e05e3b..d236327b39 100644
--- a/assets/scss/_custom.scss
+++ b/assets/scss/_custom.scss
@@ -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;
+}
diff --git a/assets/scss/_variables_project.scss b/assets/scss/_variables_project.scss
index 9030d61dc9..fd1dddd607 100644
--- a/assets/scss/_variables_project.scss
+++ b/assets/scss/_variables_project.scss
@@ -12,4 +12,16 @@ Add styles or override variables from the theme here. */
@import "tablet";
@import "desktop";
-$primary: #3371e3;
\ No newline at end of file
+$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;
diff --git a/config.toml b/config.toml
index 719a1180ba..943363c9f1 100644
--- a/config.toml
+++ b/config.toml
@@ -155,8 +155,7 @@ offlineSearch = false
[params.pushAssets]
css = [
"callouts",
- "styles",
- "custom-jekyll/tags"
+ "styles"
]
js = [
"script"
diff --git a/content/en/_common-resources/images/kub_video_banner_homepage.jpg b/content/en/_common-resources/images/kub_video_banner_homepage.jpg
index 57582e4938..e40d92a503 100644
Binary files a/content/en/_common-resources/images/kub_video_banner_homepage.jpg and b/content/en/_common-resources/images/kub_video_banner_homepage.jpg differ
diff --git a/content/en/_index.html b/content/en/_index.html
index 110141c900..452c7ea325 100644
--- a/content/en/_index.html
+++ b/content/en/_index.html
@@ -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 %}}
diff --git a/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md b/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md
index 49519cef15..3561203548 100644
--- a/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md
+++ b/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md
@@ -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**
diff --git a/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/index.md b/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/index.md
new file mode 100644
index 0000000000..5c2940c1a7
--- /dev/null
+++ b/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/index.md
@@ -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." — 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.
diff --git a/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/jorge-castro-code-of-conduct.jpg b/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/jorge-castro-code-of-conduct.jpg
new file mode 100644
index 0000000000..aeea042a7a
Binary files /dev/null and b/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/jorge-castro-code-of-conduct.jpg differ
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index e314a2c9d7..6057c60d46 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -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.
diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md
index 8f685e35f3..c96bd7aba5 100644
--- a/content/en/docs/concepts/containers/runtime-class.md
+++ b/content/en/docs/concepts/containers/runtime-class.md
@@ -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)
diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md
index 3b375f7421..917f3412e3 100644
--- a/content/en/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/en/docs/concepts/services-networking/ingress-controllers.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
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index 795a3546b5..7743ae656a 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -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" >}}
diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md
index 6e67a9e0ca..5c92f07423 100644
--- a/content/en/docs/concepts/workloads/pods/init-containers.md
+++ b/content/en/docs/concepts/workloads/pods/init-containers.md
@@ -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
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index 9dc37c357c..9c74012e8c 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -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}
diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md
index 82a05bdb86..5c781ec53f 100644
--- a/content/en/docs/contribute/review/for-approvers.md
+++ b/content/en/docs/contribute/review/for-approvers.md
@@ -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).
diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
index 0ed039f40e..fc574c685f 100644
--- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
+++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
@@ -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
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index 6dea2e0d31..138403e37c 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -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.
diff --git a/content/en/docs/reference/glossary/kubelet.md b/content/en/docs/reference/glossary/kubelet.md
index 92073a5347..e442fe29f0 100755
--- a/content/en/docs/reference/glossary/kubelet.md
+++ b/content/en/docs/reference/glossary/kubelet.md
@@ -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" >}}.
diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md
index e198b3d2d9..e0afae8aa8 100644
--- a/content/en/docs/reference/using-api/health-checks.md
+++ b/content/en/docs/reference/using-api/health-checks.md
@@ -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.
diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index 812d86faf7..ee1638bbb3 100644
--- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -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
diff --git a/content/en/docs/tasks/administer-cluster/out-of-resource.md b/content/en/docs/tasks/administer-cluster/out-of-resource.md
index b989ceac62..973eda947e 100644
--- a/content/en/docs/tasks/administer-cluster/out-of-resource.md
+++ b/content/en/docs/tasks/administer-cluster/out-of-resource.md
@@ -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
diff --git a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
index 216145a744..4f77db20cc 100644
--- a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
@@ -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`.
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
index f914480905..c79059d335 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -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:
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
index 95213176bf..d558a271ad 100644
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
@@ -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:
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 2d9c8f1adb..b6b3ad35e9 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -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
diff --git a/content/en/docs/tasks/administer-cluster/memory-available.sh b/content/en/examples/admin/resource/memory-available.sh
similarity index 100%
rename from content/en/docs/tasks/administer-cluster/memory-available.sh
rename to content/en/examples/admin/resource/memory-available.sh
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
index f760dec10d..fbc9d14c0c 100644
--- a/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
@@ -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.
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/fr/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 06b2c0a735..88d2ea5da0 100644
--- a/content/fr/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -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 >}}
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
index b2127b9733..c8966b56fa 100644
--- a/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
@@ -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
diff --git a/content/id/docs/concepts/scheduling/scheduling-framework.md b/content/id/docs/concepts/scheduling/scheduling-framework.md
index f08f9f40c7..b3580eb7ac 100644
--- a/content/id/docs/concepts/scheduling/scheduling-framework.md
+++ b/content/id/docs/concepts/scheduling/scheduling-framework.md
@@ -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
diff --git a/content/id/docs/reference/glossary/annotation.md b/content/id/docs/reference/glossary/annotation.md
new file mode 100644
index 0000000000..2ae2c729a0
--- /dev/null
+++ b/content/id/docs/reference/glossary/annotation.md
@@ -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.
+
+
+
+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.
diff --git a/content/id/docs/reference/glossary/api-group.md b/content/id/docs/reference/glossary/api-group.md
new file mode 100644
index 0000000000..4701d13c60
--- /dev/null
+++ b/content/id/docs/reference/glossary/api-group.md
@@ -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.
+
+
+
+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.
diff --git a/content/id/docs/reference/glossary/applications.md b/content/id/docs/reference/glossary/applications.md
new file mode 100644
index 0000000000..643b3c9b27
--- /dev/null
+++ b/content/id/docs/reference/glossary/applications.md
@@ -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.
diff --git a/content/id/docs/reference/glossary/cgroup.md b/content/id/docs/reference/glossary/cgroup.md
new file mode 100644
index 0000000000..ef418f00b3
--- /dev/null
+++ b/content/id/docs/reference/glossary/cgroup.md
@@ -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.
+
+
+
+cgroup merupakan fitur kernel Linux yang membatasi, menghitung, dan mengisolasi penggunaan sumber daya (CPU, memori, I/O diska, jaringan) untuk sekumpulan proses.
diff --git a/content/id/docs/reference/glossary/cluster-operator.md b/content/id/docs/reference/glossary/cluster-operator.md
index e1d09dbc7d..893aaeae5e 100644
--- a/content/id/docs/reference/glossary/cluster-operator.md
+++ b/content/id/docs/reference/glossary/cluster-operator.md
@@ -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.
-
+
-
-Tanggung jawab utama mereka adalah menjaga dan menjalankan cluster, yang mungkin melibatkan kegiatan pemeliharaan berkala atau peningkatan.
+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 >}}
-
diff --git a/content/id/docs/reference/glossary/cluster.md b/content/id/docs/reference/glossary/cluster.md
new file mode 100644
index 0000000000..a6722eef1e
--- /dev/null
+++ b/content/id/docs/reference/glossary/cluster.md
@@ -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.
+
+
+
+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_).
diff --git a/content/id/docs/reference/glossary/configmap.md b/content/id/docs/reference/glossary/configmap.md
index aaf96d5ad1..a5efb02328 100644
--- a/content/id/docs/reference/glossary/configmap.md
+++ b/content/id/docs/reference/glossary/configmap.md
@@ -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" >}}.
diff --git a/content/id/docs/reference/glossary/container-env-variables.md b/content/id/docs/reference/glossary/container-env-variables.md
index 996475cc2f..cbc39d1e57 100644
--- a/content/id/docs/reference/glossary/container-env-variables.md
+++ b/content/id/docs/reference/glossary/container-env-variables.md
@@ -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.
-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.
diff --git a/content/id/docs/reference/glossary/container-runtime.md b/content/id/docs/reference/glossary/container-runtime.md
new file mode 100644
index 0000000000..64416edd86
--- /dev/null
+++ b/content/id/docs/reference/glossary/container-runtime.md
@@ -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.
+
+
+
+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).
diff --git a/content/id/docs/reference/glossary/container.md b/content/id/docs/reference/glossary/container.md
index df94eca126..93a85b567e 100644
--- a/content/id/docs/reference/glossary/container.md
+++ b/content/id/docs/reference/glossary/container.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.
-
-Kontainer memisahkan aplikasi dan segala infrastruktur yang digunakan untuk membuat sebuah deployment menjadi lebih mudah pada berbagai environment *cloud provider* yang ada.
\ No newline at end of file
+
+
+Container memisahkan aplikasi dari infrastruktur hos yang digunakan untuk mempermudah penggelaran pada berbagai lingkungan _cloud_ atau OS, dan juga untuk mempermudah penyekalaan.
diff --git a/content/id/docs/reference/glossary/control-plane.md b/content/id/docs/reference/glossary/control-plane.md
new file mode 100644
index 0000000000..a309e4fcc0
--- /dev/null
+++ b/content/id/docs/reference/glossary/control-plane.md
@@ -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.
+
+
+
+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" >}}.
diff --git a/content/id/docs/reference/glossary/controller.md b/content/id/docs/reference/glossary/controller.md
index c88dfccb14..bad87c4a6b 100755
--- a/content/id/docs/reference/glossary/controller.md
+++ b/content/id/docs/reference/glossary/controller.md
@@ -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.
-_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" >}}.
diff --git a/content/id/docs/reference/glossary/cri.md b/content/id/docs/reference/glossary/cri.md
new file mode 100644
index 0000000000..8226ee6f93
--- /dev/null
+++ b/content/id/docs/reference/glossary/cri.md
@@ -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.
+
+
+
+Untuk informasi lebih lanjut, lihat API dan spesifikasi [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
diff --git a/content/id/docs/reference/glossary/customresourcedefinition.md b/content/id/docs/reference/glossary/customresourcedefinition.md
new file mode 100644
index 0000000000..4e2676c5ff
--- /dev/null
+++ b/content/id/docs/reference/glossary/customresourcedefinition.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.
+
+
+
+CRD memungkinkanmu untuk memperluas API Kubernetes untuk lingkunganmu jika sumber daya API yang didukung secara publik tidak dapat memenuhi kebutuhanmu.
diff --git a/content/id/docs/reference/glossary/daemonset.md b/content/id/docs/reference/glossary/daemonset.md
new file mode 100644
index 0000000000..7f8fdd5f61
--- /dev/null
+++ b/content/id/docs/reference/glossary/daemonset.md
@@ -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" >}}.
+
+
+
+Digunakan untuk menggelar _daemon_ sistem sebagai kolektor log dan memonitor agen yang biasanya harus dijalankan di setiap {{< glossary_tooltip term_id="node" >}}.
diff --git a/content/id/docs/reference/glossary/data-plane.md b/content/id/docs/reference/glossary/data-plane.md
new file mode 100644
index 0000000000..bdfcd6758d
--- /dev/null
+++ b/content/id/docs/reference/glossary/data-plane.md
@@ -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.
diff --git a/content/id/docs/setup/_index.md b/content/id/docs/setup/_index.md
index 80677a97e4..2dfa4da74f 100644
--- a/content/id/docs/setup/_index.md
+++ b/content/id/docs/setup/_index.md
@@ -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
---
-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 baremetal.
-Kamu juga bisa menyiapkan klaster yang diatur sepenuhnya (fully-managed), dengan hanya menjalankan satu perintah, ataupun membuat klaster dengan solusi custom kamu sendiri pada server baremetal.
-
+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_.
-## 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 resource 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 (Hosted Solution)
-
-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 (Site Reliability Engineering) yang mendedikasikan waktunya untukmu, tapi ingin HA (High Availability)
-* Tidak punya resource 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 turnkey, jika kamu:
-
-* Ingin punya kontrol yang lebih daripada yang ditawarkan oleh solusi tersediakan (hosted solution)
-* 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 (private cloud network)
-* Punya tim SRE yang mendedikasikan waktunya
-* Punya resource untuk menjalankan dan memonitor klaster
-
-Pilih [solusi cloud on-prem turnkey](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions).
-
-## Solusi Custom
-
-Solusi custom 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 custom](/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).
diff --git a/content/id/docs/setup/learning-environment/_index.md b/content/id/docs/setup/learning-environment/_index.md
new file mode 100644
index 0000000000..4c116a9bc0
--- /dev/null
+++ b/content/id/docs/setup/learning-environment/_index.md
@@ -0,0 +1,4 @@
+---
+title: Lingkungan Pembelajaran
+weight: 20
+---
diff --git a/content/id/docs/setup/learning-environment/minikube.md b/content/id/docs/setup/learning-environment/minikube.md
new file mode 100644
index 0000000000..8729968738
--- /dev/null
+++ b/content/id/docs/setup/learning-environment/minikube.md
@@ -0,0 +1,514 @@
+---
+title: Instalasi Kubernetes dengan Minikube
+weight: 30
+content_type: concept
+---
+
+
+
+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.
+
+
+
+
+## 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= minikube start --docker-env http_proxy= --docker-env https_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 {{}}, kamu akan menjalankan perintah berikut:
+
+```
+minikube start --kubernetes-version {{< param "fullversion" >}}
+```
+#### Menentukan _driver_ VM
+
+Kamu bisa mengubah _driver_ VM dengan menambahkan tanda `--driver=` pada `minikube start`.
+Sebagai contoh:
+```shell
+minikube start --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 {{}}.)
+
+{{< 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: ".
diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md
index 2e76e101be..6ceffc9ef4 100644
--- a/content/ko/docs/contribute/review/for-approvers.md
+++ b/content/ko/docs/contribute/review/for-approvers.md
@@ -190,7 +190,7 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의
문서에 대한 일부 이슈는 실제로 기본 코드와 관련된 이슈이거나, 튜토리얼과
같은 무언가가 작동하지 않을 때 도움을 요청하는 것이다.
-문서와 관련이 없는 이슈의 경우, `triage/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을
+문서와 관련이 없는 이슈의 경우, `kind/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을
알려주며 이슈를 닫고, 기능 관련 버그에 대한 이슈인 경우,
관련 리포지터리를 코멘트로 남긴다(`kubernetes/kubernetes` 는
시작하기 좋은 곳이다).
diff --git a/content/ru/docs/contribute/intermediate.md b/content/ru/docs/contribute/intermediate.md
index d43d415314..ba3b06511f 100644
--- a/content/ru/docs/contribute/intermediate.md
+++ b/content/ru/docs/contribute/intermediate.md
@@ -493,7 +493,7 @@ PR объединяется, когда у него есть комментар
#### Заявки с помощью или отчёты об ошибке в коде
-Некоторые открытые заявки — это проблемы с основным кодом или просьбы с помощью, когда что-то (например, учебное руководство) не работает. Для заявок, не имеющих отношение к документации, закройте её, проставив метку `triage/support` и добавив комментарий с ресурсами, где можно найти помощь (Slack, Stack Overflow) и при необходимости укажите, где нужно открыть заявку, чтобы сообщить об ошибке в функциональности (вероятно, репозиторий kubernetes/kubernetes отлично подойдет для этого).
+Некоторые открытые заявки — это проблемы с основным кодом или просьбы с помощью, когда что-то (например, учебное руководство) не работает. Для заявок, не имеющих отношение к документации, закройте её, проставив метку `kind/support` и добавив комментарий с ресурсами, где можно найти помощь (Slack, Stack Overflow) и при необходимости укажите, где нужно открыть заявку, чтобы сообщить об ошибке в функциональности (вероятно, репозиторий kubernetes/kubernetes отлично подойдет для этого).
Пример ответа на запрос о помощи:
diff --git a/content/zh/docs/concepts/cluster-administration/controller-metrics.md b/content/zh/docs/concepts/cluster-administration/controller-metrics.md
deleted file mode 100644
index c865ce7e5b..0000000000
--- a/content/zh/docs/concepts/cluster-administration/controller-metrics.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: 控制器管理器指标
-content_type: concept
-weight: 100
----
-
-
-
-
-
-
-
-控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。
-
-
-
-
-
-
-
-## 什么是控制器管理器度量
-
-控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。
-这些度量包括常见的 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"}
-```
-
-
-
-## 配置
-
-在集群中，控制器管理器指标可从它所在的主机上的 `http://localhost:10252/metrics` 中获得。
-
-这些指标是以 [prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/) 发出的，是人类可读的。
-
-在生产环境中，您可能想配置 prometheus 或其他一些指标收集工具，以定期收集这些指标数据，并将它们应用到某种时间序列数据库中。
-
-
diff --git a/content/zh/docs/concepts/cluster-administration/monitoring.md b/content/zh/docs/concepts/cluster-administration/monitoring.md
deleted file mode 100644
index a7e8e5c3c8..0000000000
--- a/content/zh/docs/concepts/cluster-administration/monitoring.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-title: Kubernetes 控制面的指标
-content_type: concept
-weight: 60
-aliases:
-- controller-metrics.md
----
-
-
-
-
-系统组件的指标可以让我们更好的看清系统内部究竟发生了什么，尤其对于构建仪表盘和告警都非常有用。
-
-Kubernetes 控制面板中的指标是以
-[prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/)
-格式发出的，而且是易于阅读的。
-
-
-
-
-## Kubernetes 的指标
-
-在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用。
-对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。
-
-
-举例下面这些组件：
-
-* {{< 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" >}}
-
-
-在生产环境中，你可能需要配置 [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
-```
-
-
-## 指标的生命周期
-
-内测版指标 → 稳定版指标 → 弃用指标 → 隐藏指标 → 删除
-
-内测版指标没有任何稳定性保证，因此可能随时被修改或删除。
-
-稳定版指标可以保证不会改变，具体的说，稳定就意味着：
-
-
-
-* 这个指标自身不会被删除或者重命名。
-* 这个指标类型不会被更改
-
-
-弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释，
-注释中包括该指标从哪个 kubernetes 版本被弃用。
-
-指标弃用前：
-
-```
-# HELP some_counter this counts things
-# TYPE some_counter counter
-some_counter 0
-```
-
-
-指标弃用后：
-
-```
-# HELP some_counter (Deprecated since 1.15.0) this counts things
-# TYPE some_counter counter
-some_counter 0
-```
-
-
-一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。
-如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。
-
-一个指标一旦被删除，那这个指标就不会被发布，您也不可以通过覆盖配置来进行更改。
-
-
-## 显示隐藏指标
-
-综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。
-当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。
-
-`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。
-这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的，
-尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。
-
-这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值，
-那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。
-
-以指标 `A` 为例，这里假设 `A` 指标在 1.n 版本中被弃用，根据指标弃用策略，我们可以得出以下结论：
-
-
-
-* 在 `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`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。
-
-
-## 组件指标
-
-### 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" %}}
-
-
-
-* 了解有关 [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 )
-
-
diff --git a/content/zh/docs/concepts/configuration/manage-resources-containers.md b/content/zh/docs/concepts/configuration/manage-resources-containers.md
index b2d3844012..f3a1d11311 100644
--- a/content/zh/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/zh/docs/concepts/configuration/manage-resources-containers.md
@@ -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.
diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md
index 941cdaccb2..8e30177cee 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/labels.md
@@ -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` 也是类似的。
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
```
+
+
+
+
+在阅读这篇文档之前，强烈建议你先熟悉一下 [Kubernetes 日志概况](/zh/docs/concepts/cluster-administration/logging)
+
+
+
+{{< note >}}
+默认情况下，Stackdriver 日志机制仅收集容器的标准输出和标准错误流。
+如果要收集你的应用程序写入一个文件（例如）的任何日志，请参见 Kubernetes 日志概述中的 [sidecar 方式](/zh/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
+{{< /note >}}
+
+
+
+
+
+## 部署 {#deploying}
+
+
+为了接收日志，你必须将 Stackdriver 日志代理部署到集群中的每个节点。
+此代理是一个已配置的 `fluentd`，其配置存在一个 `ConfigMap` 中，且实例使用 Kubernetes 的 `DaemonSet` 进行管理。
+`ConfigMap` 和 `DaemonSet` 的实际部署，取决你的集群设置。
+
+
+
+### 部署到一个新的集群
+
+#### Google Kubernetes Engine
+
+
+对于部署在 Google Kubernetes Engine 上的集群，Stackdriver 是默认的日志解决方案。
+Stackdriver 日志机制会默认部署到你的新集群上，除非你明确地不选择。
+
+
+
+#### 其他平台
+
+
+为了将 Stackdriver 日志机制部署到你正在使用 `kube-up.sh` 创建的*新*集群上，执行如下操作：
+
+
+1. 设置环境变量 `KUBE_LOGGING_DESTINATION` 为 `gcp`。
+1. **如果不是跑在 GCE 上**，在 `KUBE_NODE_LABELS` 变量中包含 `beta.kubernetes.io/fluentd-ds-ready=true`。
+
+
+
+集群启动后，每个节点都应该运行 Stackdriver 日志代理。
+`DaemonSet` 和 `ConfigMap` 作为附加组件进行配置。
+如果你不是使用 `kube-up.sh`，可以考虑不使用预先配置的日志方案启动集群，然后部署 Stackdriver 日志代理到正在运行的集群。
+
+
+
+{{< warning >}}
+除了 Google Kubernetes Engine，Stackdriver 日志守护进程在其他的平台有已知的问题。
+请自行承担风险。
+{{< /warning >}}
+
+
+### 部署到一个已知集群
+
+
+1. 在每个节点上打标签（如果尚未存在）
+
+
+ Stackdriver 日志代理部署使用节点标签来确定应该将其分配到给哪些节点。
+ 引入这些标签是为了区分 Kubernetes 1.6 或更高版本的节点。
+ 如果集群是在配置了 Stackdriver 日志机制的情况下创建的，并且节点的版本为 1.5.X 或更低版本，则它将使用 fluentd 用作静态容器。
+ 节点最多只能有一个 fluentd 实例，因此只能将标签打在未分配过 fluentd pod 的节点上。
+ 你可以通过运行 `kubectl describe` 来确保你的节点被正确标记，如下所示：
+
+ ```
+ kubectl describe node $NODE_NAME
+ ```
+
+ 输出应类似于如下内容：
+
+ ```
+ Name: NODE_NAME
+ Role:
+ Labels: beta.kubernetes.io/fluentd-ds-ready=true
+ ...
+ ```
+
+ 确保输出内容包含 `beta.kubernetes.io/fluentd-ds-ready=true` 标签。
+ 如果不存在，则可以使用 `kubectl label` 命令添加，如下所示：
+
+ ```
+ kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
+ ```
+
+
+ {{< note >}}
+ 如果节点发生故障并且必须重新创建，则必须将标签重新打在重新创建了的节点。
+ 为了让此操作更便捷，你可以在节点启动脚本中使用 Kubelet 的命令行参数给节点添加标签。
+ {{< /note >}}
+
+
+2. 通过运行以下命令，部署一个带有日志代理配置的 `ConfigMap`：
+
+ ```
+ kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
+ ```
+
+ 该命令在 `default` 命名空间中创建 `ConfigMap`。你可以在创建 `ConfigMap` 对象之前手动下载文件并进行更改。
+
+
+3. 通过运行以下命令，部署日志代理的 `DaemonSet`：
+
+ ```
+ kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
+ ```
+
+ 你也可以在使用前下载和编辑此文件。
+
+
+## 验证日志代理部署
+
+
+部署 Stackdriver `DaemonSet` 之后，你可以通过运行以下命令来查看日志代理的部署状态：
+
+```shell
+kubectl get ds --all-namespaces
+```
+
+
+如果你的集群中有 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
+...
+```
+
+
+要了解使用 Stackdriver 进行日志记录的工作方式，请考虑以下具有日志生成的 pod 定义 [counter-pod.yaml](/examples/debug/counter-pod.yaml)：
+
+{{< codenew file="debug/counter-pod.yaml" >}}
+
+
+这个 pod 定义里有一个容器，该容器运行一个 bash 脚本，脚本每秒写一次计数器的值和日期时间，并无限期地运行。
+让我们在默认命名空间中创建此 pod。
+
+```shell
+kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+
+
+你可以观察到正在运行的 pod：
+
+```shell
+kubectl get pods
+```
+```
+NAME READY STATUS RESTARTS AGE
+counter 1/1 Running 0 5m
+```
+
+
+在短时间内，你可以观察到 "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
+...
+```
+
+
+正如日志概览所述，此命令从容器日志文件中获取日志项。
+如果该容器被 Kubernetes 杀死然后重新启动，你仍然可以访问前一个容器的日志。
+但是，如果将 Pod 从节点中驱逐，则日志文件会丢失。让我们通过删除当前运行的 counter 容器来演示这一点：
+
+```shell
+kubectl delete pod counter
+```
+```
+pod "counter" deleted
+```
+
+
+然后重建它：
+
+```shell
+kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+```
+pod/counter created
+```
+
+
+一段时间后，你可以再次从 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
+...
+```
+
+
+如预期的那样，日志中仅出现最近的日志记录。
+但是，对于实际应用程序，你可能希望能够访问所有容器的日志，特别是出于调试的目的。
+这就是先前启用的 Stackdriver 日志机制可以提供帮助的地方。
+
+
+## 查看日志
+
+
+Stackdriver 日志代理为每个日志项关联元数据，供你在后续的查询中只选择感兴趣的消息：
+例如，来自某个特定 Pod 的消息。
+
+
+元数据最重要的部分是资源类型和日志名称。
+容器日志的资源类型为 `container`，在用户界面中名为 `GKE Containers`（即使 Kubernetes 集群不在 Google Kubernetes Engine 上）。
+日志名称是容器的名称，因此，如果你有一个包含两个容器的 pod，在 spec 中名称定义为 `container_1` 和 `container_2`，则它们的日志的名称分别为 `container_1` 和 `container_2`。
+
+
+系统组件的资源类型为 `compute`，在接口中名为 `GCE VM Instance`。
+系统组件的日志名称是固定的。
+对于 Google Kubernetes Engine 节点，系统组件中的每个日志项都具有以下日志名称之一：
+
+* docker
+* kubelet
+* kube-proxy
+
+
+你可以在[专用 Stackdriver 页面](https://cloud.google.com/logging/docs/view/overview)上了解有关查看日志的更多信息。
+
+
+查看日志的一种可能方法是使用 [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"
+```
+
+
+如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter 容器第一次和第二次运行时输出的消息。
+
+
+### 导出日志
+
+
+你可以将日志导出到 [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)上获得更多信息。
+
+
+## 配置 Stackdriver 日志代理
+
+
+有时默认的 Stackdriver 日志机制安装可能无法满足你的需求，例如：
+
+
+* 你可能需要添加更多资源，因为默认的行为表现无法满足你的需求。
+* 你可能需要引入额外的解析机制以便从日志消息中提取更多元数据，例如严重性或源代码引用。
+* 你可能想要将日志不仅仅发送到 Stackdriver 或仅将部分日志发送到 Stackdriver。
+
+
+在这种情况下，你需要更改 `DaemonSet` 和 `ConfigMap` 的参数。
+
+
+### 先决条件
+
+
+如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置，因为它是由 GKE 管理和支持的。
+但是，你可以禁用默认集成的日志机制并部署自己的。
+
+
+
+{{< note >}}
+你将需要自己支持和维护新部署的配置了：更新映像和配置、调整资源等等。
+{{< /note >}}
+
+
+若要禁用默认的日志记录集成，请使用以下命令：
+
+```
+gcloud beta container clusters update --logging-service=none CLUSTER
+```
+
+
+你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到正在运行的集群中的说明。
+
+
+### 更改 `DaemonSet` 参数 {#changing-daemonset-parameters}
+
+
+当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的 `template` 字段，daemonset 控制器将为你更新 pod。
+例如，假设你按照上面的描述已经安装了 Stackdriver 日志机制。
+现在，你想更改内存限制，来给 fluentd 提供的更多内存，从而安全地处理更多日志。
+
+
+获取集群中运行的 `DaemonSet` 的 spec：
+
+```shell
+kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml
+```
+
+
+然后在 spec 文件中编辑资源需求，并使用以下命令更新 apiserver 中的 `DaemonSet` 对象：
+
+```shell
+kubectl replace -f fluentd-gcp-ds.yaml
+```
+
+
+一段时间后，Stackdriver 日志代理的 pod 将使用新配置重新启动。
+
+
+### 更改 fluentd 参数
+
+
+Fluentd 的配置存在 `ConfigMap` 对象中。
+它实际上是一组合并在一起的配置文件。
+你可以在[官方网站](https://docs.fluentd.org)上了解 fluentd 的配置。
+
+
+假设你要向配置添加新的解析逻辑，以便 fluentd 可以理解默认的 Python 日志记录格式。
+一个合适的 fluentd 过滤器类似如下：
+
+```
+
+ type parser
+ format /^(?\w):(?\w):(?.*)/
+ reserve_data true
+ suppress_parse_error_log true
+ key_name log
+
+```
+
+
+现在，你需要将其放入配置中，并使 Stackdriver 日志代理感知它。
+通过运行以下命令，获取集群中当前版本的 Stackdriver 日志机制的 `ConfigMap`：
+
+```shell
+kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml
+```
+
+
+然后在 `containers.input.conf` 键的值中，在 `source` 部分之后插入一个新的过滤器。
+
+
+
+{{< note >}}
+顺序很重要。
+{{< /note >}}
+
+
+在 apiserver 中更新 `ConfigMap` 比更新 `DaemonSet` 更复杂。
+最好考虑 `ConfigMap` 是不可变的。
+如果是这样，要更新配置，你应该使用新名称创建 `ConfigMap`，然后使用
+[上面的指南](#changing-daemonset-parameters)将 `DaemonSet` 更改为指向它。
+
+
+### 添加 fluentd 插件
+
+
+Fluentd 用 Ruby 编写，并允许使用 [plugins](https://www.fluentd.org/plugins) 扩展其功能。
+如果要使用默认的 Stackdriver 日志机制容器镜像中未包含的插件，则必须构建自定义镜像。
+假设你要为来自特定容器添加 Kafka 信息接收器，以进行其他处理。
+你可以复用默认的[容器镜像源](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)，并仅添加少量更改：
+
+
+* 将 Makefile 更改为指向你的容器仓库，例如 `PREFIX=gcr.io/`。
+* 将你的依赖项添加到 Gemfile 中，例如 `gem 'fluent-plugin-kafka'`。
+
+
+然后在该目录运行 `make build push`。在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。
diff --git a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
index 2a81040a1a..4b5acb47ea 100644
--- a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
@@ -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 库的细节。
这里是一些用户调用你的插件的时候提供额外标志和参数的场景。
这些场景时基于上述案例中的 `kubectl-foo-bar-baz` 插件的。
diff --git a/content/zh/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/zh/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
new file mode 100644
index 0000000000..12c5032b49
--- /dev/null
+++ b/content/zh/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
@@ -0,0 +1,115 @@
+---
+title: 定义相互依赖的环境变量
+content_type: task
+weight: 20
+---
+
+
+
+
+
+本页展示了如何为 Kubernetes Pod 中的容器定义相互依赖的环境变量。
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+
+
+
+
+## 为容器定义相互依赖的环境变量 {#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. 依据清单创建 Pod：
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
+ ```
+ ```
+ pod/dependent-envars-demo created
+ ```
+
+2. 列出运行的 Pod：
+
+ ```shell
+ kubectl get pods dependent-envars-demo
+ ```
+ ```
+ NAME READY STATUS RESTARTS AGE
+ dependent-envars-demo 1/1 Running 0 9s
+ ```
+
+
+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
+ ```
+
+
+如上所示，你已经定义了 `SERVICE_ADDRESS` 的正确依赖引用，
+`UNCHANGED_REFERENCE` 的错误依赖引用，
+并跳过了 `ESCAPED_REFERENCE` 的依赖引用。
+
+如果环境变量被引用时已事先定义，则引用可以正确解析，
+比如 `SERVICE_ADDRESS` 的例子。
+
+
+当环境变量未定义或仅包含部分变量时，未定义的变量会被当做普通字符串对待，
+比如 `UNCHANGED_REFERENCE` 的例子。
+注意，解析不正确的环境变量通常不会阻止容器启动。
+
+`$(VAR_NAME)` 这样的语法可以用两个 `$` 转义，既：`$$(VAR_NAME)`。
+无论引用的变量是否定义，转义的引用永远不会展开。
+这一点可以从上面 `ESCAPED_REFERENCE` 的例子得到印证。
+
+## {{% heading "whatsnext" %}}
+
+
+
+* 进一步了解[环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
+* 参阅 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
+
diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/zh/docs/tasks/manage-kubernetes-objects/declarative-config.md
new file mode 100644
index 0000000000..75bc47770e
--- /dev/null
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/declarative-config.md
@@ -0,0 +1,1553 @@
+---
+title: 使用配置文件对 Kubernetes 对象进行声明式管理
+content_type: task
+weight: 10
+---
+
+
+
+
+你可以通过在一个目录中存储多个对象配置文件、并使用 `kubectl apply`
+来递归地创建和更新对象来创建、更新和删除 Kubernetes 对象。
+这种方法会保留对现有对象已作出的修改，而不会将这些更改写回到对象配置文件中。
+`kubectl diff` 也会给你呈现 `apply` 将作出的变更的预览。
+
+## {{% heading "prerequisites" %}}
+
+
+安装 [`kubectl`](/zh/docs/tasks/tools/install-kubectl/)。
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+## 权衡取舍 {#trade-offs}
+
+`kubectl` 工具能够支持三种对象管理方式：
+
+* 指令式命令
+* 指令式对象配置
+* 声明式对象配置
+
+关于每种对象管理的优缺点的讨论，可参见
+[Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。
+
+
+## 概览 {#overview}
+
+声明式对象管理需要用户对 Kubernetes 对象定义和配置有比较深刻的理解。
+如果你还没有这方面的知识储备，请先阅读下面的文档：
+
+* [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [使用配置文件对 Kubernetes 对象进行指令式管理](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
+
+
+以下是本文档中使用的术语的定义：
+
+- *对象配置文件/配置文件*：一个定义 Kubernetes 对象的配置的文件。
+ 本主题展示如何将配置文件传递给 `kubectl apply`。
+ 配置文件通常存储于类似 Git 这种源码控制系统中。
+- *现时对象配置/现时配置*：由 Kubernetes 集群所观测到的对象的现时配置值。
+ 这些配置保存在 Kubernetes 集群存储（通常是 etcd）中。
+- *声明式配置写者/声明式写者*：负责更新现时对象的人或者软件组件。
+ 本主题中的声明式写者负责改变对象配置文件并执行 `kubectl apply` 命令
+ 以写入变更。
+
+
+## 如何创建对象 {#how-to-create-objects}
+
+使用 `kubectl apply` 来创建指定目录中配置文件所定义的所有对象，除非对应对象已经存在：
+
+```shell
+kubectl apply -f <目录>/
+```
+
+此操作会在每个对象上设置 `kubectl.kubernetes.io/last-applied-configuration: '{...}'`
+注解。注解值中包含了用来创建对象的配置文件的内容。
+
+
+{{< note >}}
+添加 `-R` 标志可以递归地处理目录。
+{{< /note >}}
+
+
+下面是一个对象配置文件示例：
+
+{{< codenew file="application/simple_deployment.yaml" >}}
+
+
+执行 `kubectl diff` 可以打印出将被创建的对象：
+
+```shell
+kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
+```
+
+
+{{< note >}}
+`diff` 使用[服务器端试运行（Server-side Dry-run）](/zh/docs/reference/using-api/api-concepts/#dry-run)
+功能特性；而该功能特性需要在 `kube-apiserver` 上启用。
+
+由于 `diff` 操作会使用试运行模式执行服务器端 apply 请求，因此需要为
+用户配置 `PATCH`、`CREATE` 和 `UPDATE` 操作权限。
+参阅[试运行授权](/zh/docs/reference/using-api/api-concepts#dry-run-authorization)
+了解详情。
+{{< /note >}}
+
+
+使用 `kubectl apply` 来创建对象：
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
+```
+
+
+使用 `kubectl get` 打印其现时配置：
+
+```shell
+kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
+```
+
+
+输出显示注解 `kubectl.kubernetes.io/last-applied-configuration` 被写入到
+现时配置中，并且其内容与配置文件相同：
+
+```yaml
+kind: Deployment
+metadata:
+ annotations:
+ # ...
+ # This is the json representation of simple_deployment.yaml
+ # It was written by kubectl apply when the object was created
+ kubectl.kubernetes.io/last-applied-configuration: |
+ {"apiVersion":"apps/v1","kind":"Deployment",
+ "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+ "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+ "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+ "ports":[{"containerPort":80}]}]}}}}
+ # ...
+spec:
+ # ...
+ minReadySeconds: 5
+ selector:
+ matchLabels:
+ # ...
+ app: nginx
+ template:
+ metadata:
+ # ...
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx:1.14.2
+ # ...
+ name: nginx
+ ports:
+ - containerPort: 80
+ # ...
+ # ...
+ # ...
+ # ...
+```
+
+
+## 如何更新对象 {#how-to-update-objects}
+
+你也可以使用 `kubectl apply` 来更新某个目录中定义的所有对象，即使那些对象已经存在。
+这一操作会隐含以下行为：
+
+1. 在现时配置中设置配置文件中出现的字段；
+2. 在现时配置中清除配置文件中已删除的字段。
+
+```shell
+kubectl diff -f <目录>/
+kubectl apply -f <目录>/
+```
+
+
+{{< note >}}
+使用 `-R` 标志递归处理目录。
+{{< /note >}}
+
+
+下面是一个配置文件示例：
+
+{{< codenew file="application/simple_deployment.yaml" >}}
+
+
+使用 `kubectl apply` 来创建对象：
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
+```
+
+
+{{< note >}}
+出于演示的目的，上面的命令引用的是单个文件而不是整个目录。
+{{< /note >}}
+
+
+使用 `kubectl get` 打印现时配置：
+
+```shell
+kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
+```
+
+
+输出显示，注解 `kubectl.kubernetes.io/last-applied-configuration` 被写入到
+现时配置中，并且其取值与配置文件内容相同。
+
+```yaml
+kind: Deployment
+metadata:
+ annotations:
+ # ...
+ # 此为 simple_deployment.yaml 的 JSON 表示
+ # 在对象创建时由 kubectl apply 命令写入
+ kubectl.kubernetes.io/last-applied-configuration: |
+ {"apiVersion":"apps/v1","kind":"Deployment",
+ "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+ "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+ "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+ "ports":[{"containerPort":80}]}]}}}}
+ # ...
+spec:
+ # ...
+ minReadySeconds: 5
+ selector:
+ matchLabels:
+ # ...
+ app: nginx
+ template:
+ metadata:
+ # ...
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx:1.14.2
+ # ...
+ name: nginx
+ ports:
+ - containerPort: 80
+ # ...
+ # ...
+ # ...
+ # ...
+```
+
+
+通过 `kubeclt scale` 命令直接更新现时配置中的 `replicas` 字段。
+这一命令没有使用 `kubectl apply`：
+
+```shell
+kubectl scale deployment/nginx-deployment --replicas=2
+```
+
+
+使用 `kubectl get` 来打印现时配置：
+
+```shell
+kubectl get deployment nginx-deployment -o yaml
+```
+
+
+输出显示，`replicas` 字段已经被设置为 2，而 `last-applied-configuration` 注解中
+并不包含 `replicas` 字段。
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ annotations:
+ # ...
+ # 注意注解中并不包含 replicas
+ # 这是因为更新并不是通过 kubectl apply 来执行的
+ kubectl.kubernetes.io/last-applied-configuration: |
+ {"apiVersion":"apps/v1","kind":"Deployment",
+ "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+ "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+ "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+ "ports":[{"containerPort":80}]}]}}}}
+ # ...
+spec:
+ replicas: 2 # written by scale
+ # ...
+ minReadySeconds: 5
+ selector:
+ matchLabels:
+ # ...
+ app: nginx
+ template:
+ metadata:
+ # ...
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx:1.14.2
+ # ...
+ name: nginx
+ ports:
+ - containerPort: 80
+ # ...
+```
+
+
+现在更新 `simple_deployment.yaml` 配置文件，将镜像文件从
+`nginx:1.14.2` 更改为 `nginx:1.16.1`，同时删除`minReadySeconds` 字段：
+
+{{< codenew file="application/update_deployment.yaml" >}}
+
+
+应用对配置文件所作更改：
+
+```shell
+kubectl diff -f https://k8s.io/examples/application/update_deployment.yaml
+kubectl apply -f https://k8s.io/examples/application/update_deployment.yaml
+```
+
+
+使用 `kubectl get` 打印现时配置：
+
+```shell
+kubectl get -f https://k8s.io/examples/application/update_deployment.yaml -o yaml
+```
+
+
+输出显示现时配置中发生了以下更改：
+
+* 字段 `replicas` 保留了 `kubectl scale` 命令所设置的值：2；
+ 之所以该字段被保留是因为配置文件中并没有设置 `replicas`。
+* 字段 `image` 的内容已经从 `nginx:1.14.2` 更改为 `nginx:1.16.1`。
+* 注解 `last-applied-configuration` 内容被更改为新的镜像名称。
+* 字段 `minReadySeconds` 被移除。
+* 注解 `last-applied-configuration` 中不再包含 `minReadySeconds` 字段。
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ annotations:
+ # ...
+ # 注解中包含更新后的镜像 nginx 1.16.1
+ # 但是其中并不包含更改后的 replicas 值 2
+ kubectl.kubernetes.io/last-applied-configuration: |
+ {"apiVersion":"apps/v1","kind":"Deployment",
+ "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+ "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+ "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
+ "ports":[{"containerPort":80}]}]}}}}
+ # ...
+spec:
+ replicas: 2 # 由 `kubectl scale` 设置，被 `kubectl apply` 命令忽略
+ # minReadySeconds 被 `kubectl apply` 清除
+ # ...
+ selector:
+ matchLabels:
+ # ...
+ app: nginx
+ template:
+ metadata:
+ # ...
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx:1.16.1 # 由 `kubectl apply` 设置
+ # ...
+ name: nginx
+ ports:
+ - containerPort: 80
+ # ...
+ # ...
+ # ...
+ # ...
+```
+
+
+{{< warning >}}
+将 `kubectl apply` 与指令式对象配置命令 `kubectl create` 或 `kubectl replace`
+混合使用是不受支持的。这是因为 `create` 和 `replace` 命令都不会保留
+`kubectl apply` 用来计算更新内容所使用的
+ `kubectl.kubernetes.io/last-applied-configuration` 注解值。
+{{< /warning >}}
+
+
+## 如何删除对象 {#how-to-delete-objects}
+
+有两种方法来删除 `kubectl apply` 管理的对象。
+
+### 建议操作：`kubectl delete -f <文件名>`
+
+使用指令式命令来手动删除对象是建议的方法，因为这种方法更为明确地给出了
+要删除的内容是什么，且不容易造成用户不小心删除了其他对象的情况。
+
+```shell
+kubectl delete -f <文件名>
+```
+
+
+### 替代方式：`kubectl apply -f <目录名称/> --prune -l your=label`
+
+只有在充分理解此命令背后含义的情况下才建议这样操作。
+
+
+{{< warning >}}
+`kubectl apply --prune` 命令本身仍处于 Alpha 状态，在后续发布版本中可能会
+引入一些向后不兼容的变化。
+{{< /warning >}}
+
+{{< warning >}}
+在使用此命令时必须小心，这样才不会无意中删除不想删除的对象。
+{{< /warning >}}
+
+
+作为 `kubectl delete` 操作的替代方式，你可以在目录中对象配置文件被删除之后，
+使用 `kubectl apply` 来辩识要删除的对象。
+带 `--prune` 标志的 `apply` 命令会首先查询 API 服务器，获得与某组标签相匹配
+的对象列表，之后将返回的现时对象配置与目录中的对象配置文件相比较。
+如果某对象在查询中被匹配到，但在目录中没有文件与其相对应，并且其中还包含
+`last-applied-configuration` 注解，则该对象会被删除。
+
+```shell
+kubectl apply -f --prune -l
+```
+
+
+{{< warning >}}
+带剪裁（prune）行为的 `apply` 操作应在包含对象配置文件的目录的根目录运行。
+如果在其子目录中运行，可能导致对象被不小心删除。
+因为某些对象可能与 `-l <标签>` 的标签选择算符匹配，但其配置文件不在当前
+子目录下。
+{{< /warning >}}
+
+
+## 如何查看对象 {#how-to-view-an-object}
+
+你可以使用 `kubectl get` 并指定 `-o yaml` 选项来查看现时对象的配置：
+
+```shell
+kubectl get -f <文件名 | URL> -o yaml
+```
+
+
+## apply 操作是如何计算配置差异并合并变更的？
+
+{{< caution >}}
+*patch* 是一种更新操作，其作用域为对象的一些特定字段而不是整个对象。
+这使得你可以更新对象的特定字段集合而不必先要读回对象。
+{{< /caution >}}
+
+
+`kubectl apply` 更新对象的现时配置，它是通过向 API 服务器发送一个 patch 请求
+来执行更新动作的。
+所提交的补丁中定义了对现时对象配置中特定字段的更新。
+`kubectl apply` 命令会使用当前的配置文件、现时配置以及现时配置中保存的
+`last-applied-configuration` 注解内容来计算补丁更新内容。
+
+
+### 合并补丁计算 {#merge-patch-calculation}
+
+`kubectl apply` 命令将配置文件的内容写入到
+`kubectl.kubernetes.io/last-applied-configuration` 注解中。
+这些内容用来识别配置文件中已经移除的、因而也需要从现时配置中删除的字段。
+用来计算要删除或设置哪些字段的步骤如下：
+
+
+1. 计算要删除的字段，即在 `last-applied-configuration` 中存在但在
+ 配置文件中不再存在的字段。
+2. 计算要添加或设置的字段，即在配置文件中存在但其取值与现时配置不同的字段。
+
+下面是一个例子。假定此文件是某 Deployment 对象的配置文件：
+
+{{< codenew file="application/update_deployment.yaml" >}}
+
+
+同时假定同一 Deployment 对象的现时配置如下：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ annotations:
+ # ...
+ kubectl.kubernetes.io/last-applied-configuration: |
+ {"apiVersion":"apps/v1","kind":"Deployment",
+ "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+ "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+ "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+ "ports":[{"containerPort":80}]}]}}}}
+ # ...
+spec:
+ replicas: 2
+ # ...
+ minReadySeconds: 5
+ selector:
+ matchLabels:
+ # ...
+ app: nginx
+ template:
+ metadata:
+ # ...
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx:1.14.2
+ # ...
+ name: nginx
+ ports:
+ - containerPort: 80
+ # ...
+```
+
+
+下面是 `kubectl apply` 将执行的合并计算：
+
+1. 通过读取 `last-applied-configuration` 并将其与配置文件中的值相比较，
+ 计算要删除的字段。
+ 对于本地对象配置文件中显式设置为空的字段，清除其在现时配置中的设置，
+ 无论这些字段是否出现在 `last-applied-configuration` 中。
+ 在此例中，`minReadySeconds` 出现在 `last-applied-configuration` 注解中，但
+ 并不存在于配置文件中。
+ **动作：** 从现时配置中删除 `minReadySeconds` 字段。
+2. 通过读取配置文件中的值并将其与现时配置相比较，计算要设置的字段。
+ 在这个例子中，配置文件中的 `image` 值与现时配置中的 `image` 不匹配。
+ **动作**：设置现时配置中的 `image` 值。
+3. 设置 `last-applied-configuration` 注解的内容，使之与配置文件匹配。
+4. 将第 1、2、3 步骤得出的结果合并，构成向 API 服务器发送的补丁请求内容。
+
+下面是此合并操作之后形成的现时配置：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ annotations:
+ # ...
+ # 注解中包含更新后的 image，nginx 1.11.9,
+ # 但不包含更新后的 replicas
+ kubectl.kubernetes.io/last-applied-configuration: |
+ {"apiVersion":"apps/v1","kind":"Deployment",
+ "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+ "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+ "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
+ "ports":[{"containerPort":80}]}]}}}}
+ # ...
+spec:
+ selector:
+ matchLabels:
+ # ...
+ app: nginx
+ replicas: 2
+ # minReadySeconds 此字段被清除
+ # ...
+ template:
+ metadata:
+ # ...
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx:1.16.1
+ # ...
+ name: nginx
+ ports:
+ - containerPort: 80
+ # ...
+ # ...
+ # ...
+ # ...
+```
+
+
+### 不同类型字段的合并方式
+
+配置文件中的特定字段与现时配置合并时，合并方式取决于字段类型。
+字段类型有几种：
+
+
+- *基本类型*：字段类型为 `string`、`integer` 或 `boolean` 之一。
+ 例如：`image` 和 `replicas` 字段都是基本类型字段。
+
+ **动作：** 替换。
+
+- *map*：也称作 *object*。类型为 `map` 或包含子域的复杂结构。例如，`labels`、
+ `annotations`、`spec` 和 `metadata` 都是 map。
+
+ **动作：** 合并元素或子字段。
+
+- *list*：包含元素列表的字段，其中每个元素可以是基本类型或 map。
+ 例如，`containers`、`ports` 和 `args` 都是 list。
+
+ **动作：** 不一定。
+
+
+当 `kubectl apply` 更新某个 map 或 list 字段时，它通常不会替换整个字段，而是会
+更新其中的各个子元素。例如，当合并 Deployment 的 `spec` 时，`kubectl` 并不会
+将其整个替换掉。相反，实际操作会是对 `replicas` 这类 `spec`
+的子字段来执行比较和更新。
+
+
+### 合并对基本类型字段的更新
+
+基本类型字段会被替换或清除。
+
+
+{{< note >}}
+`-` 表示的是“不适用”，因为指定数值未被使用。
+{{< /note >}}
+
+| 字段在对象配置文件中 | 字段在现时对象配置中 | 字段在 `last-applied-configuration` 中 | 动作 |
+|-----------------------|----------------------|----------------------------------------|------|
+| 是 | 是 | - | 将配置文件中值设置到现时配置上。 |
+| 是 | 否 | - | 将配置文件中值设置到现时配置上。 |
+| 否 | - | 是 | 从现时配置中移除。 |
+| 否 | - | 否 | 什么也不做。保持现时值。 |
+
+
+### 合并对 map 字段的变更
+
+用来表示映射的字段在合并时会逐个子字段或元素地比较：
+
+
+{{< note >}}
+`-` 表示的是“不适用”，因为指定数值未被使用。
+{{< /note >}}
+
+| 键存在于对象配置文件中 | 键存在于现时对象配置中 | 键存在于 `last-applied-configuration` 中 | 动作 |
+|------------------------|------------------------|------------------------------------------|------|
+| 是 | 是 | - | 比较子域取值。 |
+| 是 | 否 | - | 将现时配置设置为本地配置值。 |
+| 否 | - | 是 | 从现时配置中删除键。 |
+| 否 | - | 否 | 什么也不做，保留现时值。 |
+
+
+### 合并 list 类型字段的变更
+
+对 list 类型字段的变更合并会使用以下三种策略之一：
+
+* 如果 list 所有元素都是基本类型则替换整个 list。
+* 如果 list 中元素是复合结构则逐个元素执行合并操作。
+* 合并基本类型元素构成的 list。
+
+策略的选择是基于各个字段做出的。
+
+
+#### 如果 list 中元素都是基本类型则替换整个 list
+
+将整个 list 视为一个基本类型字段。或者整个替换或者整个删除。
+此操作会保持 list 中元素顺序不变
+
+
+**示例：** 使用 `kubectl apply` 来更新 Pod 中 Container 的 `args` 字段。此操作会
+将现时配置中的 `args` 值设为配置文件中的值。
+所有之前添加到现时配置中的 `args` 元素都会丢失。
+配置文件中的 `args` 元素的顺序在被添加到现时配置中时保持不变。
+
+
+```yaml
+# last-applied-configuration 值
+ args: ["a", "b"]
+
+# 配置文件值
+ args: ["a", "c"]
+
+# 现时配置
+ args: ["a", "b", "d"]
+
+# 合并结果
+ args: ["a", "c"]
+```
+
+
+**解释：** 合并操作将配置文件中的值当做新的 list 值。
+
+
+#### 如果 list 中元素为复合类型则逐个执行合并
+
+此操作将 list 视为 map，并将每个元素中的特定字段当做其主键。
+逐个元素地执行添加、删除或更新操作。结果顺序无法得到保证。
+
+
+此合并策略会使用每个字段上的一个名为 `patchMergeKey` 的特殊标签。
+Kubernetes 源代码中为每个字段定义了 `patchMergeKey`：
+[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2747)
+当合并由 map 组成的 list 时，给定元素中被设置为 `patchMergeKey` 的字段会被
+当做该元素的 map 键值来使用。
+
+**例如：** 使用 `kubectl apply` 来更新 Pod 规约中的 `containers` 字段。
+此操作会将 `containers` 列表视作一个映射来执行合并，每个元素的主键为 `name`。
+
+
+```yaml
+# last-applied-configuration 值
+ containers:
+ - name: nginx
+ image: nginx:1.16
+ - name: nginx-helper-a # 键 nginx-helper-a 会被删除
+ image: helper:1.3
+ - name: nginx-helper-b # 键 nginx-helper-b 会被保留
+ image: helper:1.3
+
+# 配置文件值
+ containers:
+ - name: nginx
+ image: nginx:1.16
+ - name: nginx-helper-b
+ image: helper:1.3
+ - name: nginx-helper-c # 键 nginx-helper-c 会被添加
+ image: helper:1.3
+
+# 现时配置
+ containers:
+ - name: nginx
+ image: nginx:1.16
+ - name: nginx-helper-a
+ image: helper:1.3
+ - name: nginx-helper-b
+ image: helper:1.3
+ args: ["run"] # 字段会被保留
+ - name: nginx-helper-d # 键 nginx-helper-d 会被保留
+ image: helper:1.3
+
+# result after merge
+ containers:
+ - name: nginx
+ image: nginx:1.16
+ # 元素 nginx-helper-a 被删除
+ - name: nginx-helper-b
+ image: helper:1.3
+ args: ["run"] # 字段被保留
+ - name: nginx-helper-c # 新增元素
+ image: helper:1.3
+ - name: nginx-helper-d # 此元素被忽略（保留）
+ image: helper:1.3
+```
+
+
+**解释：**
+
+- 名为 "nginx-helper-a" 的容器被删除，因为配置文件中不存在同名的容器。
+- 名为 "nginx-helper-b" 的容器的现时配置中的 `args` 被保留。
+ `kubectl apply` 能够辩识出现时配置中的容器 "nginx-helper-b" 与配置文件
+ 中的容器 "nginx-helper-b" 相同，即使它们的字段值有些不同（配置文件中未给定
+ `args` 值）。这是因为 `patchMergeKey` 字段（name）的值在两个版本中都一样。
+- 名为 "nginx-helper-c" 的容器是新增的，因为在配置文件中的这个容器尚不存在
+ 于现时配置中。
+- 名为 "nginx-helper-d" 的容器被保留下来，因为在 last-applied-configuration
+ 中没有与之同名的元素。
+
+
+#### 合并基本类型元素 list
+
+在 Kubernetes 1.5 中，尚不支持对由基本类型元素构成的 list 进行合并。
+
+
+{{< note >}}
+选择上述哪种策略是由源码中给定字段的 `patchStrategy` 标记来控制的：
+[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2748)
+如果 list 类型字段未设置 `patchStrategy`，则整个 list 会被替换掉。
+{{< /note >}}
+
+{{< comment >}}
+TODO(pwittrock): Uncomment this for 1.6
+
+- Treat the list as a set of primitives. Replace or delete individual
+ elements. Does not preserve ordering. Does not preserve duplicates.
+
+**Example:** Using apply to update the `finalizers` field of ObjectMeta
+keeps elements added to the live configuration. Ordering of finalizers
+is lost.
+{{< /comment >}}
+
+
+## 默认字段值 {#default-field-values}
+
+API 服务器会在对象创建时其中某些字段未设置的情况下在现时配置中为其设置默认值。
+
+下面是一个 Deployment 的配置文件。文件未设置 `strategy`：
+
+{{< codenew file="application/simple_deployment.yaml" >}}
+
+
+使用 `kubectl apply` 创建对象：
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
+```
+
+
+使用 `kubectl get` 打印现时配置：
+
+```shell
+kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
+```
+
+
+输出显示 API 在现时配置中为某些字段设置了默认值。
+这些字段在配置文件中并未设置。
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+# ...
+spec:
+ selector:
+ matchLabels:
+ app: nginx
+ minReadySeconds: 5
+ replicas: 1 # API 服务器所设默认值
+ strategy:
+ rollingUpdate: # API 服务器基于 strategy.type 所设默认值
+ maxSurge: 1
+ maxUnavailable: 1
+ type: RollingUpdate # API 服务器所设默认值
+ template:
+ metadata:
+ creationTimestamp: null
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx:1.14.2
+ imagePullPolicy: IfNotPresent # API 服务器所设默认值
+ name: nginx
+ ports:
+ - containerPort: 80
+ protocol: TCP # API 服务器所设默认值
+ resources: {} # API 服务器所设默认值
+ terminationMessagePath: /dev/termination-log # API 服务器所设默认值
+ dnsPolicy: ClusterFirst # API 服务器所设默认值
+ restartPolicy: Always # API 服务器所设默认值
+ securityContext: {} # API 服务器所设默认值
+ terminationGracePeriodSeconds: 30 # API 服务器所设默认值
+# ...
+```
+
+
+在补丁请求中，已经设置了默认值的字段不会被重新设回其默认值，除非
+在补丁请求中显式地要求清除。对于默认值取决于其他字段的某些字段而言，
+这可能会引发一些意想不到的行为。当所依赖的其他字段后来发生改变时，
+基于它们所设置的默认值只能在显式执行清除操作时才会被更新。
+
+
+为此，建议在配置文件中为服务器设置默认值的字段显式提供定义，即使所
+给的定义与服务器端默认值设定相同。这样可以使得辩识无法被服务器重新
+基于默认值来设置的冲突字段变得容易。
+
+**示例：**
+
+```yaml
+# last-applied-configuration
+spec:
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+
+# 配置文件
+spec:
+ strategy:
+ type: Recreate # 更新的值
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+
+# 现时配置
+spec:
+ strategy:
+ type: RollingUpdate # 默认设置的值
+ rollingUpdate: # 基于 type 设置的默认值
+ maxSurge : 1
+ maxUnavailable: 1
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+
+# 合并后的结果 - 出错！
+spec:
+ strategy:
+ type: Recreate # 更新的值：与 rollingUpdate 不兼容
+ rollingUpdate: # 默认设置的值：与 "type: Recreate" 冲突
+ maxSurge : 1
+ maxUnavailable: 1
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+```
+
+
+**解释：**
+
+1. 用户创建 Deployment，未设置 `strategy.type`。
+2. 服务器为 `strategy.type` 设置默认值 `RollingUpdate`，并为 `strategy.rollingUpdate`
+ 设置默认值。
+3. 用户改变 `strategy.type` 为 `Recreate`。字段 `strategy.rollingUpdate` 仍会取其
+ 默认设置值，尽管服务器期望该字段被清除。
+ 如果 `strategy.rollingUpdate` 值最初于配置文件中定义，则它们需要被清除
+ 这一点就更明确一些。
+4. `apply` 操作失败，因为 `strategy.rollingUpdate` 未被清除。
+ `strategy.rollingupdate` 在 `strategy.type` 为 `Recreate` 不可被设定。
+
+
+建议：以下字段应该在对象配置文件中显式定义：
+
+- 如 Deployment、StatefulSet、Job、DaemonSet、ReplicaSet 和 ReplicationController
+ 这类负载的选择算符和 `PodTemplate` 标签
+- Deployment 的上线策略
+
+
+### 如何清除服务器端按默认值设置的字段或者被其他写者设置的字段
+
+没有出现在配置文件中的字段可以通过将其值设置为 `null` 并应用配置文件来清除。
+对于由服务器按默认值设置的字段，清除操作会触发重新为字段设置新的默认值。
+
+
+## 如何将字段的属主在配置文件和直接指令式写者之间切换
+
+更改某个对象字段时，应该采用下面的方法：
+
+- 使用 `kubectl apply`.
+- 直接写入到现时配置，但不更改配置文件本身，例如使用 `kubectl scale`。
+
+
+### 将属主从直接指令式写者更改为配置文件
+
+将字段添加到配置文件。针对该字段，不再直接执行对现时配置的修改。
+修改均通过 `kubectl apply` 来执行。
+
+
+### 将属主从配置文件改为直接指令式写者
+
+在 Kubernetes 1.5 中，将字段的属主从配置文件切换到某指令式写者需要手动
+执行以下步骤：
+
+- 从配置文件中删除该字段；
+- 将字段从现时对象的 `kubectl.kubernetes.io/last-applied-configuration` 注解
+ 中删除。
+
+
+## 更改管理方法 {#changing-management-methods}
+
+Kubernetes 对象在同一时刻应该只用一种方法来管理。
+从一种方法切换到另一种方法是可能的，但这一切换是一个手动过程。
+
+
+{{< note >}}
+在声明式管理方法中使用指令式命令来删除对象是可以的。
+{{< /note >}}
+
+
+### 从指令式命令管理切换到声明式对象配置
+
+从指令式命令管理切换到声明式对象配置管理的切换包含以下几个手动步骤：
+
+1. 将现时对象导出到本地配置文件：
+
+ ```shell
+ kubectl get / -o yaml > _.yaml
+ ```
+
+1. 手动移除配置文件中的 `status` 字段。
+
+
+ {{< note >}}
+ 这一步骤是可选的，因为 `kubectl apply` 并不会更新 status 字段，即便
+ 配置文件中包含 status 字段。
+ {{< /note >}}
+
+1. 设置对象上的 `kubectl.kubernetes.io/last-applied-configuration` 注解：
+
+ ```shell
+ kubectl replace --save-config -f _.yaml
+ ```
+
+
+### 从指令式对象配置切换到声明式对象配置
+
+1. 在对象上设置 `kubectl.kubernetes.io/last-applied-configuration` 注解：
+
+ ```shell
+ kubectl replace -save-config -f _.yaml
+ ```
+
+1. 自此排他性地使用 `kubectl apply` 来管理对象。
+
+
+## 定义控制器选择算符和 PodTemplate 标签
+
+
+{{< warning >}}
+强烈不建议更改控制器上的选择算符。
+{{< /warning >}}
+
+
+建议的方法是定义一个不可变更的 PodTemplate 标签，仅用于控制器选择算符且
+不包含其他语义性的含义。
+
+**示例：**
+
+```yaml
+selector:
+ matchLabels:
+ controller-selector: "apps/v1/deployment/nginx"
+template:
+ metadata:
+ labels:
+ controller-selector: "apps/v1/deployment/nginx"
+```
+
+## {{% heading "whatsnext" %}}
+
+
+* [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [使用配置文件对 Kubernetes 对象执行指令式管理](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
+* [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+
diff --git a/content/zh/docs/tutorials/_index.md b/content/zh/docs/tutorials/_index.md
index 0125b0e9ca..b4151e7e22 100644
--- a/content/zh/docs/tutorials/_index.md
+++ b/content/zh/docs/tutorials/_index.md
@@ -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)
-
-
-
* [介绍 Kubernetes (edx)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
- {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/user-guide/kubectl-overview/)。{{< /note >}}
+ {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/reference/kubectl/overview/)。{{< /note >}}
-
-
-
-
-以下是提供 Kubernetes 在线培训的一些网站:
-
-
-
-
-
-
-* [AIOps Essentials (使用 Prometheus 度量标准自动缩放 Kubernetes) 和动手实验室 (Linux 学院)]
- (https://linuxacademy.com/devops/training/course/name/using-machine-learning-to-scale-kubernetes-clusters)
-
-
-* [带有动手实验室的 Amazon EKS 深入研究(Linux 学院)] (https://linuxacademy.com/amazon-web-services/training/course/name/amazon-eks-deep-dive)
-
-
-* [具有动手实验和实践考试的 Cloud Native 认证 Kubernetes 管理员 (CKA)(Linux 学院)]
-(https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)
-
-
-* [带有实践测试的认证 Kubernetes 管理员准备课程 (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
-
-
-* [经过实践实验室和实践考试认证的 Kubernetes 应用程序开发人员(CKAD) (Linux 学院)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)
-
-
-* [经过认证的带有实践测试的 Kubernetes 应用程序开发人员准备课程 (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
-
-
-* [Google Kubernetes 引擎入门(Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
-
-
-* [Kubernetes 入门 (Pluralsight)]
-(https://www.pluralsight.com/courses/getting-started-kubernetes)
-
-
-* [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 引擎深度学习 (Linux 学院)]
-(https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive)
-
-
-* [通过动手实验室进行深度学习(Linux 学院)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1)
-
-
-* [Kubernetes 的动手入门 (Instruqt)]
-(https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
-
-
-* [IBM Cloud: 使用 Kubernetes 部署微服务 (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
-
-
-* [Kubernetes (edX) 简介](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
-
-
-* [带动手实验室的 Kubernetes Essentials (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
-
-
-* [通过动手实验室为绝对初学者提供 Kubernetes (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
-
-
-* [Kubernetes 基础 (LFS258) (Linux 基金会)](https://training.linuxfoundation.org/training/kubernetes-fundamentals/)
-
-
-* [Kubernetes 动手实验室快速入门 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
-
-
-* [Kubernetes 通过动手实验室解决难题 (Linux 学院)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
-
-
-* [通过动手实验室实现 Kubernetes 安全性(Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-security)
-
-
-* [通过动手实验室启动您的第一个 OpenShift 操作 (Linux 学院)] (https://linuxacademy.com/containers/training/course/name/red-hat-open-shift)
-
-
-* [边干边学 Kubernetes - 100% 动手体验 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing)
-
-
-* [使用交互式动手场景学习 Kubernetes (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
-
-
-* [Kubernetes中的微服务应用程序 - 100% 动手体验 (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing)
-
-
-* [通过动手实验室使用 Prometheus 监控 Kubernetes (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
-
-
-* [带动手实验室的 Istio 服务网络 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1)
-
-
-* [使用 Kubernetes 的可扩展微服务(Udacity)]
-(https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
-
-
-* [自定进度的 Kubernetes 在线课程 (Learnk8s 学院)]
-(https://learnk8s.io/academy)
-
-
diff --git a/content/zh/examples/pods/inject/dependent-envars.yaml b/content/zh/examples/pods/inject/dependent-envars.yaml
new file mode 100644
index 0000000000..2509c6f47b
--- /dev/null
+++ b/content/zh/examples/pods/inject/dependent-envars.yaml
@@ -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)"
diff --git a/i18n/vi.toml b/i18n/vi.toml
index e2e2c5ee04..d65c07a720 100644
--- a/i18n/vi.toml
+++ b/i18n/vi.toml
@@ -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"
diff --git a/layouts/blog/baseof.html b/layouts/blog/baseof.html
index f208811236..d801da9d8a 100644
--- a/layouts/blog/baseof.html
+++ b/layouts/blog/baseof.html
@@ -4,6 +4,9 @@
{{ partial "head.html" . }}
{{ if .IsHome }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{ . }} | {{ end }}{{ .Site.Title }}{{ end }}
+ {{ with .Params.canonicalUrl }}
+
+ {{ end }}
diff --git a/layouts/partials/css.html b/layouts/partials/css.html
index a55529844b..cb2cef6eb6 100644
--- a/layouts/partials/css.html
+++ b/layouts/partials/css.html
@@ -14,7 +14,7 @@
{{- end }}
-
+
{{- if .Site.Params.announcement }}
{{- end }}
diff --git a/layouts/shortcodes/glossary_tooltip.html b/layouts/shortcodes/glossary_tooltip.html
index a0bed81597..400bcf7c84 100644
--- a/layouts/shortcodes/glossary_tooltip.html
+++ b/layouts/shortcodes/glossary_tooltip.html
@@ -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)(.*?).*" "$1" | plainify -}}
+
+{{- $tooltip := $tooltip | replaceRE "(?s)(.*?).*" "$1" | plainify -}}
{{- $tooltip := trim $tooltip " \n" -}}
-
- {{- $text -}}
-
- {{- $tooltip | safeHTML -}}
-
+
+{{- $text -}}
{{- end -}}
{{- end -}}
diff --git a/scripts/lsync.sh b/scripts/lsync.sh
new file mode 100755
index 0000000000..740b390be1
--- /dev/null
+++ b/scripts/lsync.sh
@@ -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 \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
diff --git a/static/css/custom-jekyll/tags.css b/static/css/custom-jekyll/tags.css
deleted file mode 100644
index 1ff6d12e85..0000000000
--- a/static/css/custom-jekyll/tags.css
+++ /dev/null
@@ -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;
-}
-