Merge branch 'master' into kubeadm_inst

Author: RA489

OWNERS_ALIASES

@@ -98,6 +98,7 @@ aliases:
     - irvifa
   sig-docs-id-reviews: # PR reviews for Indonesian content
     - girikuncoro
+    - habibrosyad
     - irvifa
     - wahyuoi
     - phanama

README-zh.md

@@ -228,8 +228,8 @@ For more information about contributing to the Kubernetes documentation, see:
 有关为 Kubernetes 文档做出贡献的更多信息，请参阅：
 
 * [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/)
-* [页面内容类型](http://kubernetes.io/docs/contribute/style/page-content-types/)
-* [文档风格指南](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [页面内容类型](https://kubernetes.io/docs/contribute/style/page-content-types/)
+* [文档风格指南](https://kubernetes.io/docs/contribute/style/style-guide/)
 * [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/)
 
 # 中文本地化

README.md

@@ -76,7 +76,7 @@ Try checking the current limit for open files:
 
 Then run the following commands (adapted from https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c):
 
-```
+```shell
 #!/bin/sh
 
 # These are the original gist links, linking to my gists now.

config.toml

@@ -138,10 +138,10 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.19"
+latest = "v1.20"
 
-fullversion = "v1.19.0"
-version = "v1.19"
+fullversion = "v1.20.0"
+version = "v1.20"
 githubbranch = "master"
 docsbranch = "master"
 deprecated = false
@@ -183,40 +183,40 @@ js = [
 ]
 
 [[params.versions]]
-fullversion = "v1.19.0"
-version = "v1.19"
-githubbranch = "v1.19.0"
+fullversion = "v1.20.0"
+version = "v1.20"
+githubbranch = "v1.20.0"
 docsbranch = "master"
 url = "https://kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.18.8"
+fullversion = "v1.19.4"
+version = "v1.19"
+githubbranch = "v1.19.4"
+docsbranch = "release-1.19"
+url = "https://v1-19.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.18.12"
 version = "v1.18"
-githubbranch = "v1.18.8"
+githubbranch = "v1.18.12"
 docsbranch = "release-1.18"
 url = "https://v1-18.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.17.11"
+fullversion = "v1.17.14"
 version = "v1.17"
-githubbranch = "v1.17.11"
+githubbranch = "v1.17.14"
 docsbranch = "release-1.17"
 url = "https://v1-17.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.16.14"
+fullversion = "v1.16.15"
 version = "v1.16"
-githubbranch = "v1.16.14"
+githubbranch = "v1.16.15"
 docsbranch = "release-1.16"
 url = "https://v1-16.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.15.12"
-version = "v1.15"
-githubbranch = "v1.15.12"
-docsbranch = "release-1.15"
-url = "https://v1-15.docs.kubernetes.io"
-
 
 # User interface configuration
 [params.ui]

content/de/community/_index.html

@@ -8,7 +8,7 @@
     <main>
         <div class="content">
             <h3>Die Gewissheit, dass Kubernetes überall und für alle gut funktioniert.</h3>
-            <p>Verbinden Sie sich mit der Kubernetes-Community in unserem <a href="http://slack.k8s.io/">Slack Kanal</a>, <a href="https://discuss.kubernetes.io/">Diskussionsforum</a>, oder beteiligen Sie sich an der <a href="https://groups.google.com/forum/#!forum/kubernetes-dev"> Kubernetes-dev-Google-Gruppe</a>. Eine wöchentliches Community-Meeting findet per Videokonferenz statt, um den Stand der Dinge zu diskutieren, folgen Sie
+            <p>Verbinden Sie sich mit der Kubernetes-Community in unserem <a href="http://slack.k8s.io/">Slack Kanal</a>, <a href="https://discuss.kubernetes.io/">Diskussionsforum</a>, oder beteiligen Sie sich an der <a href="https://groups.google.com/g/kubernetes-dev"> Kubernetes-dev-Google-Gruppe</a>. Eine wöchentliches Community-Meeting findet per Videokonferenz statt, um den Stand der Dinge zu diskutieren, folgen Sie
 		<a href="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">diesen Anweisungen</a> für Informationen wie Sie teilnehmen können.</p>
             <p>Sie können Kubernetes auch auf der ganzen Welt über unsere
                 <a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup Community</a> und der

content/en/blog/_posts/2016-01-00-Why-Kubernetes-Doesnt-Use-Libnetwork.md

@@ -26,14 +26,14 @@ On the other hand, CNI is more philosophically aligned with Kubernetes. It's far
 
 Additionally, it's trivial to wrap a CNI plugin and produce a more customized CNI plugin — it can be done with a simple shell script. CNM is much more complex in this regard. This makes CNI an attractive option for rapid development and iteration. Early prototypes have proven that it's possible to eject almost 100% of the currently hard-coded network logic in kubelet into a plugin.  
 
-We investigated [writing a "bridge" CNM driver](https://groups.google.com/forum/#!topic/kubernetes-sig-network/5MWRPxsURUw) for Docker that ran CNI drivers. This turned out to be very complicated. First, the CNM and CNI models are very different, so none of the "methods" lined up. We still have the global vs. local and key-value issues discussed above. Assuming this driver would declare itself local, we have to get info about logical networks from Kubernetes.  
+We investigated [writing a "bridge" CNM driver](https://groups.google.com/g/kubernetes-sig-network/c/5MWRPxsURUw) for Docker that ran CNI drivers. This turned out to be very complicated. First, the CNM and CNI models are very different, so none of the "methods" lined up. We still have the global vs. local and key-value issues discussed above. Assuming this driver would declare itself local, we have to get info about logical networks from Kubernetes.  
 
 Unfortunately, Docker drivers are hard to map to other control planes like Kubernetes. Specifically, drivers are not told the name of the network to which a container is being attached — just an ID that Docker allocates internally. This makes it hard for a driver to map back to any concept of network that exists in another system.  
 
 This and other issues have been brought up to Docker developers by network vendors, and are usually closed as "working as intended" ([libnetwork #139](https://github.com/docker/libnetwork/issues/139), [libnetwork #486](https://github.com/docker/libnetwork/issues/486), [libnetwork #514](https://github.com/docker/libnetwork/pull/514), [libnetwork #865](https://github.com/docker/libnetwork/issues/865), [docker #18864](https://github.com/docker/docker/issues/18864)), even though they make non-Docker third-party systems more difficult to integrate with. Throughout this investigation Docker has made it clear that they’re not very open to ideas that deviate from their current course or that delegate control. This is very worrisome to us, since Kubernetes complements Docker and adds so much functionality, but exists outside of Docker itself.  
 
 For all of these reasons we have chosen to invest in CNI as the Kubernetes plugin model. There will be some unfortunate side-effects of this. Most of them are relatively minor (for example, `docker inspect` will not show an IP address), but some are significant. In particular, containers started by `docker run` might not be able to communicate with containers started by Kubernetes, and network integrators will have to provide CNI drivers if they want to fully integrate with Kubernetes. On the other hand, Kubernetes will get simpler and more flexible, and a lot of the ugliness of early bootstrapping (such as configuring Docker to use our bridge) will go away.  
 
-As we proceed down this path, we’ll certainly keep our eyes and ears open for better ways to integrate and simplify. If you have thoughts on how we can do that, we really would like to hear them — find us on [slack](http://slack.k8s.io/) or on our [network SIG mailing-list](https://groups.google.com/forum/#!forum/kubernetes-sig-network).  
+As we proceed down this path, we’ll certainly keep our eyes and ears open for better ways to integrate and simplify. If you have thoughts on how we can do that, we really would like to hear them — find us on [slack](http://slack.k8s.io/) or on our [network SIG mailing-list](https://groups.google.com/g/kubernetes-sig-network).  
 
 Tim Hockin, Software Engineer, Google

content/en/blog/_posts/2019-12-09-volume-snapshot-beta.md

@@ -44,7 +44,7 @@ As mentioned above, with the promotion of Volume Snapshot to beta, the feature i
 
 In order to use the Kubernetes Volume Snapshot feature, you must ensure the following components have been deployed on your Kubernetes cluster:
 
-- [Kubernetes Volume Snapshot CRDs](https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)
+- [Kubernetes Volume Snapshot CRDs](https://github.com/kubernetes-csi/external-snapshotter/tree/53469c21962339229dd150cbba50c34359acec73/config/crd)
 - [Volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller)
 - CSI Driver supporting Kubernetes volume snapshot beta
 
@@ -180,7 +180,7 @@ If your cluster does not come pre-installed with the correct components, you may
 #### Install Snapshot Beta CRDs
 
 - `kubectl create -f config/crd`
-- [https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd](https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)
+- [https://github.com/kubernetes-csi/external-snapshotter/tree/53469c21962339229dd150cbba50c34359acec73/config/crd](https://github.com/kubernetes-csi/external-snapshotter/tree/53469c21962339229dd150cbba50c34359acec73/config/crd)
 - Do this once per cluster
 
 

content/en/blog/_posts/2020-12-02-dockershim-faq.md

@@ -140,14 +140,15 @@ runtime where possible.
 
 Another thing to look out for is anything expecting to run for system maintenance
 or nested inside a container when building images will no longer work. For the
-former, you can use the [`crictl`][cr] tool as a drop-in replacement and for the
-latter you can use newer container build options like [img], [buildah], or
-[kaniko] that don’t require Docker.
+former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the
+latter you can use newer container build options like [img], [buildah],
+[kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker.
 
 [cr]: https://github.com/kubernetes-sigs/cri-tools
 [img]: https://github.com/genuinetools/img
 [buildah]: https://github.com/containers/buildah
 [kaniko]: https://github.com/GoogleContainerTools/kaniko
+[buildkit-cli-for-kubectl]: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl
 
 For containerd, you can start with their [documentation] to see what configuration
 options are available as you migrate things over.