diff --git a/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md b/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md
index 35918b5dbe..1e2b4ce3a5 100644
--- a/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md
+++ b/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md
@@ -19,34 +19,20 @@ The entries in the catalog include not just the ability to [start a Kubernetes c
--
-Apache web server
--
-Nginx web server
--
-Crate - The Distributed Database for Docker
--
-GlassFish - Java EE 7 Application Server
--
-Tomcat - An open-source web server and servlet container
--
-InfluxDB - An open-source, distributed, time series database
--
-Grafana - Metrics dashboard for InfluxDB
--
-Jenkins - An extensible open source continuous integration server
--
-MariaDB database
--
-MySql database
--
-Redis - Key-value cache and store
--
-PostgreSQL database
--
-MongoDB NoSQL database
--
-Zend Server - The Complete PHP Application Platform
+- Apache web server
+- Nginx web server
+- Crate - The Distributed Database for Docker
+- GlassFish - Java EE 7 Application Server
+- Tomcat - An open-source web server and servlet container
+- InfluxDB - An open-source, distributed, time series database
+- Grafana - Metrics dashboard for InfluxDB
+- Jenkins - An extensible open source continuous integration server
+- MariaDB database
+- MySql database
+- Redis - Key-value cache and store
+- PostgreSQL database
+- MongoDB NoSQL database
+- Zend Server - The Complete PHP Application Platform
diff --git a/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md b/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md
index d8c3c59a08..f5a050bd19 100644
--- a/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md
+++ b/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md
@@ -12,14 +12,10 @@ In many ways the switch from VMs to containers is like the switch from monolithi
The benefits of thinking in terms of modular containers are enormous, in particular, modular containers provide the following:
--
-Speed application development, since containers can be re-used between teams and even larger communities
--
-Codify expert knowledge, since everyone collaborates on a single containerized implementation that reflects best-practices rather than a myriad of different home-grown containers with roughly the same functionality
--
-Enable agile teams, since the container boundary is a natural boundary and contract for team responsibilities
--
-Provide separation of concerns and focus on specific functionality that reduces spaghetti dependencies and un-testable components
+- Speed application development, since containers can be re-used between teams and even larger communities
+- Codify expert knowledge, since everyone collaborates on a single containerized implementation that reflects best-practices rather than a myriad of different home-grown containers with roughly the same functionality
+- Enable agile teams, since the container boundary is a natural boundary and contract for team responsibilities
+- Provide separation of concerns and focus on specific functionality that reduces spaghetti dependencies and un-testable components
Building an application from modular containers means thinking about symbiotic groups of containers that cooperate to provide a service, not one container per service. In Kubernetes, the embodiment of this modular container service is a Pod. A Pod is a group of containers that share resources like file systems, kernel namespaces and an IP address. The Pod is the atomic unit of scheduling in a Kubernetes cluster, precisely because the symbiotic nature of the containers in the Pod require that they be co-scheduled onto the same machine, and the only way to reliably achieve this is by making container groups atomic scheduling units.
diff --git a/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md b/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md
index 753e2250be..9703dd6141 100644
--- a/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md
+++ b/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md
@@ -14,121 +14,71 @@ Here are the notes from today's meeting:
--
-Eric Paris: replacing salt with ansible (if we want)
+- Eric Paris: replacing salt with ansible (if we want)
- -
-In contrib, there is a provisioning tool written in ansible
- -
-The goal in the rewrite was to eliminate as much of the cloud provider stuff as possible
- -
-The salt setup does a bunch of setup in scripts and then the environment is setup with salt
+ - In contrib, there is a provisioning tool written in ansible
+ - The goal in the rewrite was to eliminate as much of the cloud provider stuff as possible
+ - The salt setup does a bunch of setup in scripts and then the environment is setup with salt
- -
-This means that things like generating certs is done differently on GCE/AWS/Vagrant
- -
-For ansible, everything must be done within ansible
- -
-Background on ansible
+ - This means that things like generating certs is done differently on GCE/AWS/Vagrant
+ - For ansible, everything must be done within ansible
+ - Background on ansible
- -
-Does not have clients
- -
-Provisioner ssh into the machine and runs scripts on the machine
- -
-You define what you want your cluster to look like, run the script, and it sets up everything at once
- -
-If you make one change in a config file, ansible re-runs everything (which isn’t always desirable)
- -
-Uses a jinja2 template
- -
-Create machines with minimal software, then use ansible to get that machine into a runnable state
+ - Does not have clients
+ - Provisioner ssh into the machine and runs scripts on the machine
+ - You define what you want your cluster to look like, run the script, and it sets up everything at once
+ - If you make one change in a config file, ansible re-runs everything (which isn’t always desirable)
+ - Uses a jinja2 template
+ - Create machines with minimal software, then use ansible to get that machine into a runnable state
- -
-Sets up all of the add-ons
- -
-Eliminates the provisioner shell scripts
- -
-Full cluster setup currently takes about 6 minutes
+ - Sets up all of the add-ons
+ - Eliminates the provisioner shell scripts
+ - Full cluster setup currently takes about 6 minutes
- -
-CentOS with some packages
- -
-Redeploy to the cluster takes 25 seconds
- -
-Questions for Eric
+ - CentOS with some packages
+ - Redeploy to the cluster takes 25 seconds
+ - Questions for Eric
- -
-Where does the provider-specific configuration go?
+ - Where does the provider-specific configuration go?
- -
-The only network setup that the ansible config does is flannel; you can turn it off
- -
-What about init vs. systemd?
+ - The only network setup that the ansible config does is flannel; you can turn it off
+ - What about init vs. systemd?
- -
-Should be able to support in the code w/o any trouble (not yet implemented)
- -
-Discussion
+ - Should be able to support in the code w/o any trouble (not yet implemented)
+ - Discussion
- -
-Why not push the setup work into containers or kubernetes config?
+ - Why not push the setup work into containers or kubernetes config?
- -
-To bootstrap a cluster drop a kubelet and a manifest
- -
-Running a kubelet and configuring the network should be the only things required. We can cut a machine image that is preconfigured minus the data package (certs, etc)
+ - To bootstrap a cluster drop a kubelet and a manifest
+ - Running a kubelet and configuring the network should be the only things required. We can cut a machine image that is preconfigured minus the data package (certs, etc)
- -
-The ansible scripts install kubelet & docker if they aren’t already installed
- -
-Each OS (RedHat, Debian, Ubuntu) could have a different image. We could view this as part of the build process instead of the install process.
- -
-There needs to be solution for bare metal as well.
- -
-In favor of the overall goal -- reducing the special configuration in the salt configuration
- -
-Everything except the kubelet should run inside a container (eventually the kubelet should as well)
+ - The ansible scripts install kubelet & docker if they aren’t already installed
+ - Each OS (RedHat, Debian, Ubuntu) could have a different image. We could view this as part of the build process instead of the install process.
+ - There needs to be solution for bare metal as well.
+ - In favor of the overall goal -- reducing the special configuration in the salt configuration
+ - Everything except the kubelet should run inside a container (eventually the kubelet should as well)
- -
-Running in a container doesn’t cut down on the complexity that we currently have
- -
-But it does more clearly define the interface about what the code expects
- -
-These tools (Chef, Puppet, Ansible) conflate binary distribution with configuration
+ - Running in a container doesn’t cut down on the complexity that we currently have
+ - But it does more clearly define the interface about what the code expects
+ - These tools (Chef, Puppet, Ansible) conflate binary distribution with configuration
- -
-Containers more clearly separate these problems
- -
-The mesos deployment is not completely automated yet, but the mesos deployment is completely different: kubelets get put on top on an existing mesos cluster
+ - Containers more clearly separate these problems
+ - The mesos deployment is not completely automated yet, but the mesos deployment is completely different: kubelets get put on top on an existing mesos cluster
- -
-The bash scripts allow the mesos devs to see what each cloud provider is doing and re-use the relevant bits
- -
-There was a large reverse engineering curve, but the bash is at least readable as opposed to the salt
- -
-Openstack uses a different deployment as well
- -
-We need a well documented list of steps (e.g. create certs) that are necessary to stand up a cluster
+ - The bash scripts allow the mesos devs to see what each cloud provider is doing and re-use the relevant bits
+ - There was a large reverse engineering curve, but the bash is at least readable as opposed to the salt
+ - Openstack uses a different deployment as well
+ - We need a well documented list of steps (e.g. create certs) that are necessary to stand up a cluster
- -
-This would allow us to compare across cloud providers
- -
-We should reduce the number of steps as much as possible
- -
-Ansible has 241 steps to launch a cluster
--
-1.0 Code freeze
+ - This would allow us to compare across cloud providers
+ - We should reduce the number of steps as much as possible
+ - Ansible has 241 steps to launch a cluster
+- 1.0 Code freeze
- -
-How are we getting out of code freeze?
- -
-This is a topic for next week, but the preview is that we will move slowly rather than totally opening the firehose
+ - How are we getting out of code freeze?
+ - This is a topic for next week, but the preview is that we will move slowly rather than totally opening the firehose
- -
-We want to clear the backlog as fast as possible while maintaining stability both on HEAD and on the 1.0 branch
- -
-The backlog of almost 300 PRs but there are also various parallel feature branches that have been developed during the freeze
- -
-Cutting a cherry pick release today (1.0.1) that fixes a few issues
+ - We want to clear the backlog as fast as possible while maintaining stability both on HEAD and on the 1.0 branch
+ - The backlog of almost 300 PRs but there are also various parallel feature branches that have been developed during the freeze
+ - Cutting a cherry pick release today (1.0.1) that fixes a few issues
- Next week we will discuss the cadence for patch releases
diff --git a/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md b/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md
index 1a67c9334e..e1df83d3e2 100644
--- a/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md
+++ b/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md
@@ -16,17 +16,10 @@ Fundamentally, ElasticKube delivers a web console for which compliments Kubernet
ElasticKube enables organizations to accelerate adoption by developers, application operations and traditional IT operations teams and shares a mutual goal of increasing developer productivity, driving efficiency in container management and promoting the use of microservices as a modern application delivery methodology. When leveraging ElasticKube in your environment, users need to ensure the following technologies are configured appropriately to guarantee everything runs correctly:
--
-Configure Google Container Engine (GKE) for cluster installation and management
-
--
-Use Kubernetes to provision the infrastructure and clusters for containers
-
--
-Use your existing tools of choice to actually build your containers
--
-
-Use ElasticKube to run, deploy and manage your containers and services
+- Configure Google Container Engine (GKE) for cluster installation and management
+- Use Kubernetes to provision the infrastructure and clusters for containers
+- Use your existing tools of choice to actually build your containers
+- Use ElasticKube to run, deploy and manage your containers and services
[](http://cl.ly/0i3M2L3Q030z/Image%202016-03-11%20at%209.49.12%20AM.png)
@@ -39,14 +32,10 @@ Getting Started with Kubernetes and ElasticKube
(this is a 3min walk through video with the following topics)
-1.
-Deploy ElasticKube to a Kubernetes cluster
-2.
-Configuration
-3.
-Admin: Setup and invite a user
-4.
-Deploy an instance
+1. Deploy ElasticKube to a Kubernetes cluster
+2. Configuration
+3. Admin: Setup and invite a user
+4. Deploy an instance
diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md b/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md
index 3bfa309fd1..b02f089cac 100644
--- a/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md
+++ b/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md
@@ -13,24 +13,18 @@ Today, we want to take you on a short tour explaining the background of our offe
In mid 2014 we looked at the challenges enterprises are facing in the context of digitization, where traditional enterprises experience that more and more competitors from the IT sector are pushing into the core of their markets. A big part of Fujitsu’s customers are such traditional businesses, so we considered how we could help them and came up with three basic principles:
--
-Decouple applications from infrastructure - Focus on where the value for the customer is: the application.
--
-Decompose applications - Build applications from smaller, loosely coupled parts. Enable reconfiguration of those parts depending on the needs of the business. Also encourage innovation by low-cost experiments.
--
-Automate everything - Fight the increasing complexity of the first two points by introducing a high degree of automation.
+- Decouple applications from infrastructure - Focus on where the value for the customer is: the application.
+- Decompose applications - Build applications from smaller, loosely coupled parts. Enable reconfiguration of those parts depending on the needs of the business. Also encourage innovation by low-cost experiments.
+- Automate everything - Fight the increasing complexity of the first two points by introducing a high degree of automation.
We found that Linux containers themselves cover the first point and touch the second. But at this time there was little support for creating distributed applications and running them managed automatically. We found Kubernetes as the missing piece.
**Not a free lunch**
The general approach of Kubernetes in managing containerized workload is convincing, but as we looked at it with the eyes of customers, we realized that it’s not a free lunch. Many customers are medium-sized companies whose core business is often bound to strict data protection regulations. The top three requirements we identified are:
--
-On-premise deployments (with the option for hybrid scenarios)
--
-Efficient operations as part of a (much) bigger IT infrastructure
--
-Enterprise-grade support, potentially on global scale
+- On-premise deployments (with the option for hybrid scenarios)
+- Efficient operations as part of a (much) bigger IT infrastructure
+- Enterprise-grade support, potentially on global scale
We created Cloud Load Control with these requirements in mind. It is basically a distribution of Kubernetes targeted for on-premise use, primarily focusing on operational aspects of container infrastructure. We are committed to work with the community, and contribute all relevant changes and extensions upstream to the Kubernetes project.
**On-premise deployments**
@@ -39,12 +33,9 @@ As Kubernetes core developer Tim Hockin often puts it in his[talks](https://spea
Cloud Load Control addresses these issues. It enables customers to reliably and readily provision a production grade Kubernetes clusters on their own infrastructure, with the following benefits:
--
-Proven setup process, lowers risk of problems while setting up the cluster
--
-Reduction of provisioning time to minutes
--
-Repeatable process, relevant especially for large, multi-tenant environments
+- Proven setup process, lowers risk of problems while setting up the cluster
+- Reduction of provisioning time to minutes
+- Repeatable process, relevant especially for large, multi-tenant environments
Cloud Load Control delivers these benefits for a range of platforms, starting from selected OpenStack distributions in the first versions of Cloud Load Control, and successively adding more platforms depending on customer demand. We are especially excited about the option to remove the virtualization layer and support Kubernetes bare-metal on Fujitsu servers in the long run. By removing a layer of complexity, the total cost to run the system would be decreased and the missing hypervisor would increase performance.
@@ -53,10 +44,8 @@ Right now we are in the process of contributing a generic provider to set up Kub
Reducing operation costs is the target of any organization providing IT infrastructure. This can be achieved by increasing the efficiency of operations and helping operators to get their job done. Considering large-scale container infrastructures, we found it is important to differentiate between two types of operations:
--
-Platform-oriented, relates to the overall infrastructure, often including various systems, one of which might be Kubernetes.
--
-Application-oriented, focusses rather on a single, or a small set of applications deployed on Kubernetes.
+- Platform-oriented, relates to the overall infrastructure, often including various systems, one of which might be Kubernetes.
+- Application-oriented, focusses rather on a single, or a small set of applications deployed on Kubernetes.
Kubernetes is already great for the application-oriented part. Cloud Load Control was created to help platform-oriented operators to efficiently manage Kubernetes as part of the overall infrastructure and make it easy to execute Kubernetes tasks relevant to them.
diff --git a/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md b/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md
index 27f84d3e7b..025c311606 100644
--- a/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md
+++ b/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md
@@ -11,15 +11,12 @@ Hello, and welcome to the second installment of the Kubernetes state of the cont
In January, 71% of respondents were currently using containers, in February, 89% of respondents were currently using containers. The percentage of users not even considering containers also shrank from 4% in January to a surprising 0% in February. Will see if that holds consistent in March.Likewise, the usage of containers continued to march across the dev/canary/prod lifecycle. In all parts of the lifecycle, container usage increased:
--
-Development: 80% -\> 88%
--
-Test: 67% -\> 72%
--
-Pre production: 41% -\> 55%
--
-Production: 50% -\> 62%
-What is striking in this is that pre-production growth continued, even as workloads were clearly transitioned into true production. Likewise the share of people considering containers for production rose from 78% in January to 82% in February. Again we’ll see if the trend continues into March.
+- Development: 80% -\> 88%
+- Test: 67% -\> 72%
+- Pre production: 41% -\> 55%
+- Production: 50% -\> 62%
+
+What is striking in this is that pre-production growth continued, even as workloads were clearly transitioned into true production. Likewise the share of people considering containers for production rose from 78% in January to 82% in February. Again we’ll see if the trend continues into March.
## Container and cluster sizes
diff --git a/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md
index 061a39c196..721b217c47 100644
--- a/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md
+++ b/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md
@@ -215,14 +215,10 @@ CRI is being actively developed and maintained by the Kubernetes [SIG-Node](http
--
-Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes)
--
-Join the #sig-node channel on [Slack](https://kubernetes.slack.com/)
--
-Subscribe to the [SIG-Node mailing list](mailto:kubernetes-sig-node@googlegroups.com)
--
-Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+- Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes)
+- Join the #sig-node channel on [Slack](https://kubernetes.slack.com/)
+- Subscribe to the [SIG-Node mailing list](mailto:kubernetes-sig-node@googlegroups.com)
+- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
diff --git a/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md b/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md
index 14eae43fc6..fa30aba5f7 100644
--- a/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md
+++ b/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md
@@ -21,13 +21,8 @@ This progress is our commitment in continuing to make Kubernetes best way to man
Connect
--
-[Download](http://get.k8s.io/) Kubernetes
--
-Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
--
-Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
--
-Connect with the community on [Slack](http://slack.k8s.io/)
--
-Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+- [Download](http://get.k8s.io/) Kubernetes
+- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
+- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+- Connect with the community on [Slack](http://slack.k8s.io/)
+- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
diff --git a/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md
index 7f58071940..ba87948d3c 100644
--- a/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md
+++ b/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md
@@ -36,12 +36,11 @@ Most of the Kubernetes constructs, such as Pods, Services, Labels, etc. work wit
|
What doesn’t work yet?
|
--
-Pod abstraction is not same due to networking namespaces. Net result is that Windows containers in a single POD cannot communicate over localhost. Linux containers can share networking stack by placing them in the same network namespace.
--
-DNS capabilities are not fully implemented
--
-UDP is not supported inside a container
+
+- Pod abstraction is not same due to networking namespaces. Net result is that Windows containers in a single POD cannot communicate over localhost. Linux containers can share networking stack by placing them in the same network namespace.
+- DNS capabilities are not fully implemented
+- UDP is not supported inside a container
+
|
|
When will it be ready for all production workloads (general availability)?
diff --git a/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md b/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md
index 87a26f14b4..c5f1147072 100644
--- a/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md
+++ b/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md
@@ -78,11 +78,7 @@ _--Jean-Mathieu Saponaro, Research & Analytics Engineer, Datadog_
--
-Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
--
-Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
--
-Connect with the community on [Slack](http://slack.k8s.io/)
--
-Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
+- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+- Connect with the community on [Slack](http://slack.k8s.io/)
+- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
diff --git a/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md b/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md
index 8c63574864..c6e4007d9a 100644
--- a/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md
+++ b/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md
@@ -113,11 +113,7 @@ _-- Rob Hirschfeld, co-founder of RackN and co-chair of the Cluster Ops SIG_
--
-Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
--
-Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
--
-Connect with the community on [Slack](http://slack.k8s.io/)
--
-Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
+- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+- Connect with the community on [Slack](http://slack.k8s.io/)
+- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
diff --git a/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md b/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md
index 774bbffad7..7f3c6ebee9 100644
--- a/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md
+++ b/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md
@@ -26,87 +26,69 @@ Kubernetes has also earned the trust of many [Fortune 500 companies](https://kub
July 2016
--
-Kubernauts celebrated its [first anniversary](https://kubernetes.io/blog/2016/07/happy-k8sbday-1) of the Kubernetes 1.0 launch with 20 [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties hosted worldwide
--
-Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/)
+- Kubernauts celebrated its [first anniversary](https://kubernetes.io/blog/2016/07/happy-k8sbday-1) of the Kubernetes 1.0 launch with 20 [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties hosted worldwide
+- Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/)
September 2016
--
-Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/)
--
-Launch of [kubeadm](https://kubernetes.io/blog/2016/09/how-we-made-kubernetes-easy-to-install), a tool that makes Kubernetes dramatically easier to install
--
-[Pokemon Go](https://www.sdxcentral.com/articles/news/google-dealt-pokemon-go-traffic-50-times-beyond-expectations/2016/09/) - one of the largest installs of Kubernetes ever
+- Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/)
+- Launch of [kubeadm](https://kubernetes.io/blog/2016/09/how-we-made-kubernetes-easy-to-install), a tool that makes Kubernetes dramatically easier to install
+- [Pokemon Go](https://www.sdxcentral.com/articles/news/google-dealt-pokemon-go-traffic-50-times-beyond-expectations/2016/09/) - one of the largest installs of Kubernetes ever
October 2016
--
-Introduced [Kubernetes service partners program](https://kubernetes.io/blog/2016/10/kubernetes-service-technology-partners-program) and a redesigned [partners page](https://kubernetes.io/partners/)
+- Introduced [Kubernetes service partners program](https://kubernetes.io/blog/2016/10/kubernetes-service-technology-partners-program) and a redesigned [partners page](https://kubernetes.io/partners/)
November 2016
--
-CloudNativeCon/KubeCon [Seattle](https://www.cncf.io/blog/2016/11/17/cloudnativeconkubecon-2016-wrap/)
--
-Cloud Native Computing Foundation partners with The Linux Foundation to launch a [new Kubernetes certification, training and managed service provider program](https://www.cncf.io/blog/2016/11/08/cncf-partners-linux-foundation-launch-new-kubernetes-certification-training-managed-service-provider-program/)
+- CloudNativeCon/KubeCon [Seattle](https://www.cncf.io/blog/2016/11/17/cloudnativeconkubecon-2016-wrap/)
+- Cloud Native Computing Foundation partners with The Linux Foundation to launch a [new Kubernetes certification, training and managed service provider program](https://www.cncf.io/blog/2016/11/08/cncf-partners-linux-foundation-launch-new-kubernetes-certification-training-managed-service-provider-program/)
December 2016
--
-Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/)
+- Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/)
January 2017
--
-[Survey](https://www.cncf.io/blog/2017/01/17/container-management-trends-kubernetes-moves-testing-production/) from CloudNativeCon + KubeCon Seattle showcases the maturation of Kubernetes deployment
+- [Survey](https://www.cncf.io/blog/2017/01/17/container-management-trends-kubernetes-moves-testing-production/) from CloudNativeCon + KubeCon Seattle showcases the maturation of Kubernetes deployment
March 2017
--
-CloudNativeCon/KubeCon [Europe](https://www.cncf.io/blog/2017/04/17/highlights-cloudnativecon-kubecon-europe-2017/)
--
-Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale)
+- CloudNativeCon/KubeCon [Europe](https://www.cncf.io/blog/2017/04/17/highlights-cloudnativecon-kubecon-europe-2017/)
+- Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale)
April 2017
--
-The [Battery Open Source Software (BOSS) Index](https://www.battery.com/powered/boss-index-tracking-explosive-growth-open-source-software/) lists Kubernetes as #33 in the top 100 popular open-source software projects
+- The [Battery Open Source Software (BOSS) Index](https://www.battery.com/powered/boss-index-tracking-explosive-growth-open-source-software/) lists Kubernetes as #33 in the top 100 popular open-source software projects
May 2017
--
-[Four Kubernetes projects](https://www.cncf.io/blog/2017/05/04/cncf-brings-kubernetes-coredns-opentracing-prometheus-google-summer-code-2017/) accepted to The [Google Summer of Code](https://developers.google.com/open-source/gsoc/) (GSOC) 2017 program
--
-Stutterstock and Kubernetes appear in [The Wall Street Journal](https://blogs.wsj.com/cio/2017/05/26/shutterstock-ceo-says-new-business-plan-hinged-upon-total-overhaul-of-it/): “On average we [Shutterstock] deploy 45 different releases into production a day using that framework. We use Docker, Kubernetes and Jenkins [to build and run containers and automate development,” said CTO Marty Brodbeck on the company’s IT overhaul and adoption of containerization.
+- [Four Kubernetes projects](https://www.cncf.io/blog/2017/05/04/cncf-brings-kubernetes-coredns-opentracing-prometheus-google-summer-code-2017/) accepted to The [Google Summer of Code](https://developers.google.com/open-source/gsoc/) (GSOC) 2017 program
+- Stutterstock and Kubernetes appear in [The Wall Street Journal](https://blogs.wsj.com/cio/2017/05/26/shutterstock-ceo-says-new-business-plan-hinged-upon-total-overhaul-of-it/): “On average we [Shutterstock] deploy 45 different releases into production a day using that framework. We use Docker, Kubernetes and Jenkins [to build and run containers and automate development,” said CTO Marty Brodbeck on the company’s IT overhaul and adoption of containerization.
June 2017
--
-Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates)
--
-[Survey](https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/) from CloudNativeCon + KubeCon Europe shows Kubernetes leading as the orchestration platform of choice
--
-Kubernetes ranked [#4](https://github.com/cncf/velocity) in the [30 highest velocity open source projects](https://www.cncf.io/blog/2017/06/05/30-highest-velocity-open-source-projects/)
+- Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates)
+- [Survey](https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/) from CloudNativeCon + KubeCon Europe shows Kubernetes leading as the orchestration platform of choice
+- Kubernetes ranked [#4](https://github.com/cncf/velocity) in the [30 highest velocity open source projects](https://www.cncf.io/blog/2017/06/05/30-highest-velocity-open-source-projects/)
@@ -116,8 +98,7 @@ Figure 2: The 30 highest velocity open source projects. Source: [https://github.
July 2017
--
-Kubernauts celebrate the second anniversary of the Kubernetes 1.0 launch with [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties worldwide!
+- Kubernauts celebrate the second anniversary of the Kubernetes 1.0 launch with [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties worldwide!
diff --git a/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md b/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md
index de516c17a8..b931ec336a 100644
--- a/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md
+++ b/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md
@@ -92,14 +92,10 @@ Usage of UCD in the Process Flow:
UCD is used for deployment and the end-to end deployment process is automated here. UCD component process involves the following steps:
--
-Download the required artifacts for deployment from the Gitlab.
--
-Login to Bluemix and set the KUBECONFIG based on the Kubernetes cluster used for creating the pods.
--
-Create the application pod in the cluster using kubectl create command.
--
-If needed, run a rolling update to update the existing pod.
+- Download the required artifacts for deployment from the Gitlab.
+- Login to Bluemix and set the KUBECONFIG based on the Kubernetes cluster used for creating the pods.
+- Create the application pod in the cluster using kubectl create command.
+- If needed, run a rolling update to update the existing pod.
@@ -150,13 +146,8 @@ To expose our services to outside the cluster, we used Ingress. In IBM Cloud Kub
--
-Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
--
-Join the community portal for advocates on [K8sPort](http://k8sport.org/)
--
-Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
--
-Connect with the community on [Slack](http://slack.k8s.io/)
--
-Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
+- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+- Join the community portal for advocates on [K8sPort](http://k8sport.org/)
+- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+- Connect with the community on [Slack](http://slack.k8s.io/)
+- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
diff --git a/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md b/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md
index b266497707..b94ac8b693 100644
--- a/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md
+++ b/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md
@@ -129,14 +129,10 @@ With our graduation, comes the release of Kompose 1.0.0, here’s what’s new:
--
-Docker Compose Version 3: Kompose now supports Docker Compose Version 3. New keys such as ‘deploy’ now convert to their Kubernetes equivalent.
--
-Docker Push and Build Support: When you supply a ‘build’ key within your `docker-compose.yaml` file, Kompose will automatically build and push the image to the respective Docker repository for Kubernetes to consume.
--
-New Keys: With the addition of version 3 support, new keys such as pid and deploy are supported. For full details on what Kompose supports, view our [conversion document](http://kompose.io/conversion/).
--
-Bug Fixes: In every release we fix any bugs related to edge-cases when converting. This release fixes issues relating to converting volumes with ‘./’ in the target name.
+- Docker Compose Version 3: Kompose now supports Docker Compose Version 3. New keys such as ‘deploy’ now convert to their Kubernetes equivalent.
+- Docker Push and Build Support: When you supply a ‘build’ key within your `docker-compose.yaml` file, Kompose will automatically build and push the image to the respective Docker repository for Kubernetes to consume.
+- New Keys: With the addition of version 3 support, new keys such as pid and deploy are supported. For full details on what Kompose supports, view our [conversion document](http://kompose.io/conversion/).
+- Bug Fixes: In every release we fix any bugs related to edge-cases when converting. This release fixes issues relating to converting volumes with ‘./’ in the target name.
@@ -145,28 +141,18 @@ What’s ahead?
As we continue development, we will strive to convert as many Docker Compose keys as possible for all future and current Docker Compose releases, converting each one to their Kubernetes equivalent. All future releases will be backwards-compatible.
--
-[Install Kompose](https://github.com/kubernetes/kompose/blob/master/docs/installation.md)
--
-[Kompose Quick Start Guide](https://github.com/kubernetes/kompose/blob/master/docs/installation.md)
--
-[Kompose Web Site](http://kompose.io/)
--
-[Kompose Documentation](https://github.com/kubernetes/kompose/tree/master/docs)
+- [Install Kompose](https://github.com/kubernetes/kompose/blob/master/docs/installation.md)
+- [Kompose Quick Start Guide](https://github.com/kubernetes/kompose/blob/master/docs/installation.md)
+- [Kompose Web Site](http://kompose.io/)
+- [Kompose Documentation](https://github.com/kubernetes/kompose/tree/master/docs)
--Charlie Drage, Software Engineer, Red Hat
--
-Post questions (or answer questions) on[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
--
-Join the community portal for advocates on[K8sPort](http://k8sport.org/)
--
-Follow us on Twitter[@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
--
-Connect with the community on[Slack](http://slack.k8s.io/)
--
-Get involved with the Kubernetes project on[GitHub](https://github.com/kubernetes/kubernetes)
--
+- Post questions (or answer questions) on[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+- Join the community portal for advocates on[K8sPort](http://k8sport.org/)
+- Follow us on Twitter[@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+- Connect with the community on[Slack](http://slack.k8s.io/)
+- Get involved with the Kubernetes project on[GitHub](https://github.com/kubernetes/kubernetes)
diff --git a/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md b/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md
index fe156e00df..67f3e084cc 100644
--- a/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md
+++ b/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md
@@ -987,13 +987,8 @@ Rolling updates and roll backs close an important feature gap for DaemonSets and
--
-Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
--
-Join the community portal for advocates on [K8sPort](http://k8sport.org/)
--
-Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
--
-Connect with the community on [Slack](http://slack.k8s.io/)
--
-Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
+- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+- Join the community portal for advocates on [K8sPort](http://k8sport.org/)
+- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+- Connect with the community on [Slack](http://slack.k8s.io/)
+- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
diff --git a/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md b/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md
index c33b805b4d..ebbf591772 100644
--- a/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md
+++ b/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md
@@ -18,7 +18,7 @@ This is post #1 in a series about the local deployment options on Linux, and it
[Minikube](https://github.com/kubernetes/minikube) is a cross-platform, community-driven [Kubernetes](https://kubernetes.io/) distribution, which is targeted to be used primarily in local environments. It deploys a single-node cluster, which is an excellent option for having a simple Kubernetes cluster up and running on localhost.
-Minikube is designed to be used as a virtual machine (VM), and the default VM runtime is [VirtualBox](https://www.virtualbox.org/). At the same time, extensibility is one of the critical benefits of Minikube, so it's possible to use it with [drivers](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md) outside of VirtualBox.
+Minikube is designed to be used as a virtual machine (VM), and the default VM runtime is [VirtualBox](https://www.virtualbox.org/). At the same time, extensibility is one of the critical benefits of Minikube, so it's possible to use it with [drivers](https://minikube.sigs.k8s.io/docs/drivers/) outside of VirtualBox.
By default, Minikube uses Virtualbox as a runtime for running the virtual machine. Virtualbox is a cross-platform solution, which can be used on a variety of operating systems, including GNU/Linux, Windows, and macOS.
diff --git a/content/en/blog/_posts/2020-06-29-working-with-terraform-and-kubernetes.md b/content/en/blog/_posts/2020-06-29-working-with-terraform-and-kubernetes.md
new file mode 100644
index 0000000000..1b15ae28d2
--- /dev/null
+++ b/content/en/blog/_posts/2020-06-29-working-with-terraform-and-kubernetes.md
@@ -0,0 +1,59 @@
+---
+layout: blog
+title: "Working with Terraform and Kubernetes"
+date: 2020-06-29
+slug: working-with-terraform-and-kubernetes
+url: /blog/2020/06/working-with-terraform-and-kubernetes
+---
+
+**Author:** [Philipp Strube](https://twitter.com/pst418), Kubestack
+
+Maintaining Kubestack, an open-source [Terraform GitOps Framework](https://www.kubestack.com/lp/terraform-gitops-framework) for Kubernetes, I unsurprisingly spend a lot of time working with Terraform and Kubernetes. Kubestack provisions managed Kubernetes services like AKS, EKS and GKE using Terraform but also integrates cluster services from Kustomize bases into the GitOps workflow. Think of cluster services as everything that's required on your Kubernetes cluster, before you can deploy application workloads.
+
+Hashicorp recently announced [better integration between Terraform and Kubernetes](https://www.hashicorp.com/blog/deploy-any-resource-with-the-new-kubernetes-provider-for-hashicorp-terraform/). I took this as an opportunity to give an overview of how Terraform can be used with Kubernetes today and what to be aware of.
+
+In this post I will however focus only on using Terraform to provision Kubernetes API resources, not Kubernetes clusters.
+
+[Terraform](https://www.terraform.io/intro/index.html) is a popular infrastructure as code solution, so I will only introduce it very briefly here. In a nutshell, Terraform allows declaring a desired state for resources as code, and will determine and execute a plan to take the infrastructure from its current state, to the desired state.
+
+To be able to support different resources, Terraform requires providers that integrate the respective API. So, to create Kubernetes resources we need a Kubernetes provider. Here are our options:
+
+## Terraform `kubernetes` provider (official)
+
+First, the [official Kubernetes provider](https://github.com/hashicorp/terraform-provider-kubernetes). This provider is undoubtedly the most mature of the three. However, it comes with a big caveat that's probably the main reason why using Terraform to maintain Kubernetes resources is not a popular choice.
+
+Terraform requires a schema for each resource and this means the maintainers have to translate the schema of each Kubernetes resource into a Terraform schema. This is a lot of effort and was the reason why for a long time the supported resources where pretty limited. While this has improved over time, still not everything is supported. And especially [custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are not possible to support this way.
+
+This schema translation also results in some edge cases to be aware of. For example, `metadata` in the Terraform schema is a list of maps. Which means you have to refer to the `metadata.name` of a Kubernetes resource like this in Terraform: `kubernetes_secret.example.metadata.0.name`.
+
+On the plus side however, having a Terraform schema means full integration between Kubernetes and other Terraform resources. Like for [example](https://github.com/kbst/terraform-kubestack/blob/e5caa6d20926d546a045144ebe79c7cc8c0b4c8a/aws/_modules/eks/ingress.tf#L37), using Terraform to create a Kubernetes service of type `LoadBalancer` and then use the returned ELB hostname in a Route53 record to configure DNS.
+
+The biggest benefit when using Terraform to maintain Kubernetes resources is integration into the Terraform plan/apply life-cycle. So you can review planned changes before applying them. Also, using `kubectl`, purging of resources from the cluster is not trivial without manual intervention. Terraform does this reliably.
+
+## Terraform `kubernetes-alpha` provider
+
+Second, the new [alpha Kubernetes provider](https://github.com/hashicorp/terraform-provider-kubernetes-alpha). As a response to the limitations of the current Kubernetes provider the Hashicorp team recently released an alpha version of a new provider.
+
+This provider uses dynamic resource types and server-side-apply to support all Kubernetes resources. I personally think this provider has the potential to be a game changer - even if [managing Kubernetes resources in HCL](https://github.com/hashicorp/terraform-provider-kubernetes-alpha#moving-from-yaml-to-hcl) may still not be for everyone. Maybe the Kustomize provider below will help with that.
+
+The only downside really is, that it's explicitly discouraged to use it for anything but testing. But the more people test it, the sooner it should be ready for prime time. So I encourage everyone to give it a try.
+
+## Terraform `kustomize` provider
+
+Last, we have the [`kustomize` provider](https://github.com/kbst/terraform-provider-kustomize). Kustomize provides a way to do customizations of Kubernetes resources using inheritance instead of templating. It is designed to output the result to `stdout`, from where you can apply the changes using `kubectl`. This approach means that `kubectl` edge cases like no purging or changes to immutable attributes still make full automation difficult.
+
+Kustomize is a popular way to handle customizations. But I was looking for a more reliable way to automate applying changes. Since this is exactly what Terraform is great at the Kustomize provider was born.
+
+Not going into too much detail here, but from Terraform's perspective, this provider treats every Kubernetes resource as a JSON string. This way it can handle any Kubernetes resource resulting from the Kustomize build. But it has the big disadvantage that Kubernetes resources can not easily be integrated with other Terraform resources. Remember the load balancer example from above.
+
+Under the hood, similarly to the new Kubernetes alpha provider, the Kustomize provider also uses the dynamic Kubernetes client and server-side-apply. Going forward, I plan to deprecate this part of the Kustomize provider that overlaps with the new Kubernetes provider and only keep the Kustomize integration.
+
+## Conclusion
+
+For teams that are already invested into Terraform, or teams that are looking for ways to replace `kubectl` in automation, Terraform's plan/apply life-cycle has always been a promising option to automate changes to Kubernetes resources. However, the limitations of the official Kubernetes provider resulted in this not seeing significant adoption.
+
+The new alpha provider removes the limitations and has the potential to make Terraform a prime option to automate changes to Kubernetes resources.
+
+Teams that have already adopted Kustomize, may find integrating Kustomize and Terraform using the Kustomize provider beneficial over `kubectl` because it avoids common edge cases. Even if in this set up, Terraform can only easily be used to plan and apply the changes, not to adapt the Kubernetes resources. In the future, this issue may be resolved by combining the Kustomize provider with the new Kubernetes provider.
+
+If you have any questions regarding these three options, feel free to reach out to me on the Kubernetes Slack in either the [#kubestack](https://app.slack.com/client/T09NY5SBT/CMBCT7XRQ) or the [#kustomize](https://app.slack.com/client/T09NY5SBT/C9A5ALABG) channel. If you happen to give any of the providers a try and encounter a problem, please file a GitHub issue to help the maintainers fix it.
diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/KubernetesComputer_transparent.png b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/KubernetesComputer_transparent.png
new file mode 100644
index 0000000000..86e4bdff5f
Binary files /dev/null and b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/KubernetesComputer_transparent.png differ
diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/PeopleDoodle_transparent.png b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/PeopleDoodle_transparent.png
new file mode 100644
index 0000000000..6657c31ec4
Binary files /dev/null and b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/PeopleDoodle_transparent.png differ
diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/cgroupsNamespacesComboPic.png b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/cgroupsNamespacesComboPic.png
new file mode 100644
index 0000000000..4aae049d00
Binary files /dev/null and b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/cgroupsNamespacesComboPic.png differ
diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/index.md b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/index.md
new file mode 100644
index 0000000000..df5834764e
--- /dev/null
+++ b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/index.md
@@ -0,0 +1,104 @@
+---
+layout: blog
+title: "SIG-Windows Spotlight"
+date: 2020-06-30
+slug: sig-windows-spotlight-2020
+---
+
+# SIG-Windows Spotlight
+_This post tells the story of how Kubernetes contributors work together to provide a container orchestrator that works for both Linux and Windows._
+
+
+
+Most people who are familiar with Kubernetes are probably used to associating it with Linux. The connection makes sense, since Kubernetes ran on Linux from its very beginning. However, many teams and organizations working on adopting Kubernetes need the ability to orchestrate containers on Windows. Since the release of Docker and rise to popularity of containers, there have been efforts both from the community and from Microsoft itself to make container technology as accessible in Windows systems as it is in Linux systems.
+
+Within the Kubernetes community, those who are passionate about making Kubernetes accessible to the Windows community can find a home in the Windows Special Interest Group. To learn more about SIG-Windows and the future of Kubernetes on Windows, I spoke to co-chairs [Mark Rossetti](https://github.com/marosset) and [Michael Michael](https://github.com/michmike) about the SIG's goals and how others can contribute.
+
+## Intro to Windows Containers & Kubernetes
+
+Kubernetes is the most popular tool for orchestrating container workloads, so to understand the Windows Special Interest Group (SIG) within the Kubernetes project, it's important to first understand what we mean when we talk about running containers on Windows.
+
+***
+_"When looking at Windows support in Kubernetes," says SIG (Special Interest Group) Co-chairs Mark Rossetti and Michael Michael, "many start drawing comparisons to Linux containers. Although some of the comparisons that highlight limitations are fair, it is important to distinguish between operational limitations and differences between the Windows and Linux operating systems. Windows containers run the Windows operating system and Linux containers run Linux."_
+***
+
+In essence, any "container" is simply a process being run on its host operating system, with some key tooling in place to isolate that process and its dependencies from the rest of the environment. The goal is to make that running process safely isolated, while taking up minimal resources from the system to perform that isolation. On Linux, the tooling used to isolate processes to create "containers" commonly boils down to cgroups and namespaces (among a few others), which are themselves tools built in to the Linux Kernel.
+
+
+
+#### _If dogs were processes: containerization would be like giving each dog their own resources like toys and food using cgroups, and isolating troublesome dogs using namespaces._
+
+
+Native Windows processes are processes that are or must be run on a Windows operating system. This makes them fundamentally different from a process running on a Linux operating system. Since Linux containers are Linux processes being isolated by the Linux kernel tools known as cgroups and namespaces, containerizing native Windows processes meant implementing similar isolation tools within the Windows kernel itself. Thus, "Windows Containers" and "Linux Containers" are fundamentally different technologies, even though they have the same goals (isolating processes) and in some ways work similarly (using kernel level containerization).
+
+So when it comes to running containers on Windows, there are actually two very important concepts to consider:
+
+* Native Windows processes running as native Windows Server style containers,
+* and traditional Linux containers running on a Linux Kernel, generally hosted on a lightweight Hyper-V Virtual Machine.
+
+You can learn more about Linux and Windows containers in this [tutorial](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers) from Microsoft.
+
+
+
+### Kubernetes on Windows
+
+Kubernetes was initially designed with Linux containers in mind and was itself designed to run on Linux systems. Because of that, much of the functionality of Kubernetes involves unique Linux functionality. The Linux-specific work is intentional--we all want Kubernetes to run optimally on Linux--but there is a growing demand for similar optimization for Windows servers. For cases where users need container orchestration on Windows, the Kubernetes contributor community of SIG-Windows has incorporated functionality for Windows-specific use cases.
+
+***
+_"A common question we get is, will I be able to have a Windows-only cluster. The answer is NO. Kubernetes control plane components will continue to be based on Linux, while SIG-Windows is concentrating on the experience of having Windows worker nodes in a Kubernetes cluster."_
+***
+
+Rather than separating out the concepts of "Windows Kubernetes," and "Linux Kubernetes," the community of SIG-Windows works toward adding functionality to the main Kubernetes project which allows it to handle use cases for Windows. These Windows capabilities mirror, and in some cases add unique functionality to, the Linux use cases Kubernetes has served since its release in 2014 (want to learn more history? Scroll through this [original design document](https://github.com/kubernetes/kubernetes/blob/e2b948dbfbba62b8cb681189377157deee93bb43/DESIGN.md).
+
+
+## What Does SIG-Windows Do?
+
+***
+_"SIG-Windows is really the center for all things Windows in Kubernetes,"_ SIG chairs Mark and Michael said, _"We mainly focus on the compute side of things, but really anything related to running Kubernetes on Windows is in scope for SIG-Windows."_
+***
+
+In order to best serve users, SIG-Windows works to make the Kubernetes user experience as consistent as possible for users of Windows and Linux. However some use cases simply only apply to one Operating System, and as such, the SIG-Windows group also works to create functionality that is unique to Windows-only workloads.
+
+Many SIGs, or "Special Interest Groups" within Kubernetes have a narrow focus, allowing members to dive deep on a certain facet of the technology. While specific expertise is welcome, those interested in SIG-Windows will find it to be a great community to build broad understanding across many focus areas of Kubernetes. "Members from our SIG interface with storage, network, testing, cluster-lifecycle and others groups in Kubernetes."
+
+### Who are SIG-Windows' Users?
+The best way to understand the technology a group makes, is often to understand who their customers or users are.
+
+
+
+#### "A majority of the users we've interacted with have business-critical infrastructure running on Windows developed over many years and can't move those workloads to Linux for various reasons (cost, time, compliance, etc)," the SIG chairs shared. "By transporting those workloads into Windows containers and running them in Kubernetes they are able to quickly modernize their infrastructure and help migrate it to the cloud."
+
+As anyone in the Kubernetes space can attest, companies around the world, in many different industries, see Kubernetes as their path to modernizing their infrastructure. Often this involves re-architecting or event totally re-inventing many of the ways they've been doing business. With the goal being to make their systems more scalable, more robust, and more ready for anything the future may bring. But not every application or workload can or should change the core operating system it runs on, so many teams need the ability to run containers at scale on Windows, or Linux, or both.
+
+"Sometimes the driver to Windows containers is a modernization effort and sometimes it’s because of expiring hardware warranties or end-of-support cycles for the current operating system. Our efforts in SIG-Windows enable Windows developers to take advantage of cloud native tools and Kubernetes to build and deploy distributed applications faster. That’s exciting! In essence, users can retain the benefits of application availability while decreasing costs."
+
+## Who are SIG-Windows?
+
+Who are these contributors working on enabling Windows workloads for Kubernetes? It could be you!
+
+Like with other Kubernetes SIGs, contributors to SIG-Windows can be anyone from independent hobbyists to professionals who work at many different companies. They come from many different parts of the world and bring to the table many different skill sets.
+
+
+
+_"Like most other Kubernetes SIGs, we are a very welcome and open community," explained the SIG co-chairs Michael Michael and Mark Rosetti._
+
+
+### Becoming a contributor
+
+For anyone interested in getting started, the co-chairs added, "New contributors can view old community meetings on GitHub (we record every single meeting going back three years), read our documentation, attend new community meetings, ask questions in person or on Slack, and file some issues on Github. We also attend all KubeCon conferences and host 1-2 sessions, a contributor session, and meet-the-maintainer office hours."
+
+The co-chairs also shared a glimpse into what the path looks like to becoming a member of the SIG-Windows community:
+
+"We encourage new contributors to initially just join our community and listen, then start asking some questions and get educated on Windows in Kubernetes. As they feel comfortable, they could graduate to improving our documentation, file some bugs/issues, and eventually they can be a code contributor by fixing some bugs. If they have long-term and sustained substantial contributions to Windows, they could become a technical lead or a chair of SIG-Windows. You won't know if you love this area unless you get started :) To get started, [visit this getting-started page](https://github.com/kubernetes/community/tree/master/sig-windows). It's a one stop shop with links to everything related to SIG-Windows in Kubernetes."
+
+When asked if there were any useful skills for new contributors, the co-chairs said,
+
+"We are always looking for expertise in Go and Networking and Storage, along with a passion for Windows. Those are huge skills to have. However, we don’t require such skills, and we welcome any and all contributors, with varying skill sets. If you don’t know something, we will help you acquire it."
+
+You can get in touch with the folks at SIG-Windows in their [Slack channel](https://kubernetes.slack.com/archives/C0SJ4AFB7) or attend one of their regular meetings - currently 30min long on Tuesdays at 12:30PM EST! You can find links to their regular meetings as well as past meeting notes and recordings from the [SIG-Windows README](https://github.com/kubernetes/community/tree/master/sig-windows#readme) on GitHub.
+
+As a closing message from SIG-Windows:
+
+***
+#### _"We welcome you to get involved and join our community to share feedback and deployment stories, and contribute to code, docs, and improvements of any kind."_
+***
diff --git a/content/en/case-studies/OWNERS b/content/en/case-studies/OWNERS
deleted file mode 100644
index e4131d339e..0000000000
--- a/content/en/case-studies/OWNERS
+++ /dev/null
@@ -1,10 +0,0 @@
-# See the OWNERS docs at https://go.k8s.io/owners
-
-# Owned by Kubernetes Blog reviewers.
-options:
- no_parent_owners: false
-reviewers:
- - alexcontini
-approvers:
- - alexcontini
- - sarahkconway
diff --git a/content/en/case-studies/adform/index.html b/content/en/case-studies/adform/index.html
index e9a8acc7a2..be35a2d837 100644
--- a/content/en/case-studies/adform/index.html
+++ b/content/en/case-studies/adform/index.html
@@ -12,7 +12,7 @@ quote: >
Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier.
---
-
+
CASE STUDY:
Improving Performance and Morale with Cloud Native
@@ -66,7 +66,7 @@ The company has a large infrastructure: Ope
-
+
"The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."
— Edgaras Apšega, IT Systems Engineer, Adform
@@ -83,7 +83,7 @@ The first production cluster was launched in the spring of 2018, and is now up t
-
+
"Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore."
Staying True to Its Culture, adidas Got 40% of Its Most Impactful Systems Running on Kubernetes in a Year
@@ -33,7 +33,7 @@ featured: false
-
+
"For me, Kubernetes is a platform made by engineers for engineers. It’s relieving the development team from tasks that they don’t want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it."
- FERNANDO CORNAGO, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS
@@ -74,7 +74,7 @@ featured: false
-
+
“There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster. Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly.”
- DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS
Ant Financial’s Hypergrowth Strategy Using Kubernetes
@@ -50,7 +50,7 @@ featured: false
To address those challenges and provide reliable and consistent services to its customers, Ant Financial embraced Docker containerization in 2014. But they soon realized that they needed an orchestration solution for some tens-of-thousands-of-node clusters in the company’s data centers.
-
+
"On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress." - RANGER YU, GLOBAL TECHNOLOGY PARTNERSHIP & DEVELOPMENT, ANT FINANCIAL
@@ -65,7 +65,7 @@ featured: false
All core financial systems were containerized by November 2017, and the migration to Kubernetes is ongoing. Ant’s platform also leverages a number of other CNCF projects, including Prometheus, OpenTracing, etcd and CoreDNS. “On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress,” says Ranger Yu, Global Technology Partnership & Development.
-
+
"We’re very grateful for CNCF and this amazing technology, which we need as we continue to scale globally. We’re definitely embracing the community and open source more in the future." - HAOJIE HANG, PRODUCT MANAGEMENT, ANT FINANCIAL
diff --git a/content/en/case-studies/appdirect/index.html b/content/en/case-studies/appdirect/index.html
index 16d93cce5c..ca6b0b8fe9 100644
--- a/content/en/case-studies/appdirect/index.html
+++ b/content/en/case-studies/appdirect/index.html
@@ -12,7 +12,7 @@ quote: >
We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem.
---
-
+
CASE STUDY:
AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetess
@@ -53,7 +53,7 @@ quote: >
-
+
"We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team." - Alexandre Gervais, Staff Software Developer, AppDirect
@@ -69,7 +69,7 @@ quote: >
Lacerte’s strategy ultimately worked because of the very real impact the Kubernetes platform has had to deployment time. Due to less dependency on custom-made, brittle shell scripts with SCP commands, time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn’t require Jira tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before.
-
+
"I think our velocity would have slowed down a lot if we didn’t have this new infrastructure." - Pierre-Alexandre Lacerte, Director of Software Development, AppDirect
How Cloud Native Is Enabling Babylon’s Medical AI Innovations
@@ -36,7 +36,7 @@ quote: >
Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.
-
+
“Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.”
- JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON
@@ -84,7 +84,7 @@ quote: >
-
+
“Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.”
- JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON
After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own
@@ -40,7 +40,7 @@ quote: >
-
+
“As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It’s a super healthy dynamic.”
- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM
@@ -91,7 +91,7 @@ quote: >
-
+
“We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time. The time to gain access to resources is decreased enormously.”
- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM
How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes
@@ -38,7 +38,7 @@ quote: >
-
+
"When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes."
- JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON
@@ -75,7 +75,7 @@ quote: >
-
+
"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event"
- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON
diff --git a/content/en/case-studies/bose/index.html b/content/en/case-studies/bose/index.html
index d22de2187a..c77f416c13 100644
--- a/content/en/case-studies/bose/index.html
+++ b/content/en/case-studies/bose/index.html
@@ -11,7 +11,7 @@ quote: >
The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles.
---
-
+
CASE STUDY:
Bose: Supporting Rapid Development for Millions of IoT Products With Kubernetes
@@ -56,7 +56,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
-
+
"Everybody on the team thinks in terms of automation, leaning out the processes, getting things done as quickly as possible. When you step back and look at what it means for a 50-plus-year-old speaker company to have that sort of culture, it really is quite incredible, and I think the tools that we use and the foundation that we’ve built with them is a huge piece of that." - Dylan O’Mahony, Cloud Architecture Manager, Bose
@@ -70,7 +70,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
-
+
"The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles." - Josh West, Lead Cloud Engineer, Bose
"We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."
@@ -69,7 +69,7 @@ css: /css/style_case_studies.css
-
+
With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
CERN: Processing Petabytes of Data More Efficiently with Kubernetes
@@ -52,7 +52,7 @@ logo: cern_featured_logo.png
-
+
"Before, the tendency was always: ‘I need this, I get a couple of developers, and I implement it.’ Right now it’s ‘I need this, I’m sure other people also need this, so I’ll go and ask around.’ The CNCF is a good source because there’s a very large catalog of applications available. It’s very hard right now to justify developing a new product in-house. There is really no real reason to keep doing that. It’s much easier for us to try it out, and if we see it’s a good solution, we try to reach out to the community and start working with that community." - Ricardo Rocha, Software Engineer, CERN
@@ -66,7 +66,7 @@ logo: cern_featured_logo.png
-
+
"With Kubernetes, there’s a well-established technology and a big community that we can contribute to. It allows us to do our physics analysis without having to focus so much on the lower level software. This is just exciting. We are looking forward to keep contributing to the community and collaborating with everyone." - Ricardo Rocha, Software Engineer, CERN
China Unicom: How China Unicom Leveraged Kubernetes to Boost Efficiency and Lower IT Costs
@@ -51,7 +51,7 @@ featured: false
-
+
"We could never imagine we can achieve this scalability in such a short time." - Chengyu Zhang, Group Leader of Platform Technology R&D, China Unicom
@@ -65,7 +65,7 @@ featured: false
-
+
"This technology is relatively complicated, but as long as developers get used to it, they can enjoy all the benefits." - Jie Jia, Member of Platform Technology R&D, China Unicom
City of Montréal - How the City of Montréal Is Modernizing Its 30-Year-Old, Siloed Architecture with Kubernetes
@@ -50,7 +50,7 @@ featured: false
The first step to modernize the architecture was containerization. “We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things,” says Solutions Architect Marc Khouzam. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins for deployment.
-
+
"Getting a project running in Kubernetes is entirely dependent on how long you need to program the actual software. It’s no longer dependent on deployment. Deployment is so fast that it’s negligible." - MARC KHOUZAM, SOLUTIONS ARCHITECT, CITY OF MONTRÉAL
@@ -65,7 +65,7 @@ featured: false
Another important factor in the decision was vendor neutrality. “As a government entity, it is essential for us to be neutral in our selection of products and providers,” says Thibault. “The independence of the Cloud Native Computing Foundation from any company provides this.”
-
+
"Kubernetes has been great. It’s been stable, and it provides us with elasticity, resilience, and robustness. While re-architecting for Kubernetes, we also benefited from the monitoring and logging aspects, with centralized logging, Prometheus logging, and Grafana dashboards. We have enhanced visibility of what’s being deployed." - MORGAN MARTINET, ENTERPRISE ARCHITECT, CITY OF MONTRÉAL
How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes
@@ -36,7 +36,7 @@ quote: >
Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi.
-
+
"Another disruptive innovation is coming, so to survive in this situation, we need to change our culture."
- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO
@@ -79,7 +79,7 @@ quote: >
-
+
"By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation."
- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO
Building an Image Trust Service on Kubernetes with Notary and TUF
@@ -58,7 +58,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
-
+
"Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"
- Michael Hough, a software developer with the IBM Cloud Container Registry team
@@ -75,7 +75,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
-
+
"With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."
- Michael Hough, a software developer with the IBM Cloud Container Registry team
"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes."
"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex."
— Onno Van der Voort, Infrastructure Architect, ING
JD.com: How JD.com Pioneered Kubernetes for E-Commerce at Hyperscale
@@ -51,7 +51,7 @@ featured: false
-
+
"We customized Kubernetes and built a modern system on top of it. This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time." - HAIFENG LIU, CHIEF ARCHITECT, JD.com
@@ -67,7 +67,7 @@ featured: false
-
+
"My advice is first you need to combine this technology with your own businesses, and the second is you need clear goals. You cannot just use the technology because others are using it. You need to consider your own objectives." - HAIFENG LIU, CHIEF ARCHITECT, JD.com
A Culture and Technology Transition Enabled by Kubernetes
@@ -59,7 +59,7 @@ In addition, NAIC is onboarding teams to the new platform, and those teams have
-
+
"In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community." - Dan Barker, Chief Enterprise Architect, NAIC
@@ -77,7 +77,7 @@ As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes
-
+
"We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."
How A Startup Reduced Its Infrastructure Costs by 50% With Kubernetes
@@ -52,7 +52,7 @@ featured: false
-
+
"The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way." - Travis Jeppson, Director of Engineering, Nav
@@ -65,7 +65,7 @@ featured: false
Jeppson’s four-person Engineering Services team got Kubernetes up and running in six months (they decided to use Kubespray to spin up clusters), and the full migration of Nav’s 25 microservices and one primary monolith was completed in another six months. “We couldn’t rewrite everything; we couldn’t stop,” he says. “We had to stay up, we had to stay available, and we had to have minimal amount of downtime. So we got really comfortable around our building pipeline, our metrics and logging, and then around Kubernetes itself: how to launch it, how to upgrade it, how to service it. And we moved little by little.”
-
+
“Kubernetes has brought so much value to Nav by allowing all of these new freedoms that we had just never had before.” - Travis Jeppson, Director of Engineering, Nav
Nerdalize: Providing Affordable and Sustainable Cloud Hosting with Kubernetes
@@ -47,7 +47,7 @@ featured: false
After trying to develop its own scheduling system using another open source tool, Nerdalize found Kubernetes. “Kubernetes provided us with more functionality out of the gate,” says van der Veer.
-
+
“We always try to get a working version online first, like minimal viable products, and then move to stabilize that,” says van der Veer. “And I think that these kinds of day-two problems are now immediately solved. The rapid prototyping we saw internally is a very valuable aspect of Kubernetes.” — AD VAN DER VEER, PRODUCT ENGINEER, NERDALIZE
@@ -62,7 +62,7 @@ featured: false
Not to mention the 40% cost savings. “Every euro that we have to invest for licensing of software that’s not open source comes from that 40%,” says van der Veer. If Nerdalize had used a non-open source orchestration platform instead of Kubernetes, “that would reduce our cost savings proposition to like 30%. Kubernetes directly allows us to have this business model and this strategic advantage.”
-
+
“One of our customers used to spend up to a day setting up the virtual machines, network and software every time they wanted to run a project in the cloud. On our platform, with Docker and Kubernetes, customers can have their projects running in a couple of minutes.”
- MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE
diff --git a/content/en/case-studies/netease/index.html b/content/en/case-studies/netease/index.html
index a62ade486f..6cba5579ab 100644
--- a/content/en/case-studies/netease/index.html
+++ b/content/en/case-studies/netease/index.html
@@ -9,7 +9,7 @@ featured: false
---
-
+
CASE STUDY:
How NetEase Leverages Kubernetes to Support Internet Business Worldwide
@@ -47,7 +47,7 @@ featured: false
After considering building its own orchestration solution, NetEase decided to base its private cloud platform on Kubernetes. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng.
-
+
"We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."
- Feng Changjian, Architect for NetEase Cloud and Container Service, NetEase
@@ -60,7 +60,7 @@ featured: false
And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment.
-
+
"As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."
"We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"
"Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
diff --git a/content/en/case-studies/nokia/index.html b/content/en/case-studies/nokia/index.html
index d8aaafc7f5..f824685327 100644
--- a/content/en/case-studies/nokia/index.html
+++ b/content/en/case-studies/nokia/index.html
@@ -8,7 +8,7 @@ logo: nokia_featured_logo.png
---
-
+
CASE STUDY:
Nokia: Enabling 5G and DevOps at a Telecom Company with Kubernetes
@@ -51,7 +51,7 @@ logo: nokia_featured_logo.png
-
+
"Having the community and CNCF around Kubernetes is not only important for having a connection to other companies who are using Kubernetes and a forum where you can ask or discuss features of Kubernetes. But as a company who would like to contribute to Kubernetes, it was very important to have a CLA (Contributors License Agreement) which is connected to the CNCF and not to a particular company. That was a critical step for us to start contributing to Kubernetes and Helm." - Gergely Csatari, Senior Open Source Engineer, Nokia
@@ -65,7 +65,7 @@ logo: nokia_featured_logo.png
-
+
"Kubernetes opened the window to all of these open source projects instead of implementing everything in house. Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business." - Gergely Csatari, Senior Open Source Engineer, Nokia
Finding Millions in Potential Savings in a Tough Retail Climate
@@ -60,7 +60,7 @@ css: /css/style_case_studies.css
-
+
"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
@@ -77,7 +77,7 @@ The benefits were immediate for the teams that came on board. "Teams running on
-
+
"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
- In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.
+ In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.
Solution
The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they’re building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced Kanali, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC.
@@ -53,7 +53,7 @@ In order to give the company’s 4.5 million clients the digital experience they
-
+
"Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."
@@ -63,12 +63,12 @@ In order to give the company’s 4.5 million clients the digital experience they
Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."
As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company’s 1,500 engineers are using it and more are eager to get on board.
-The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.
+The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.
-
+
"Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it."
diff --git a/content/en/case-studies/ocado/index.html b/content/en/case-studies/ocado/index.html
index 6a930f945c..79ac9bf3a8 100644
--- a/content/en/case-studies/ocado/index.html
+++ b/content/en/case-studies/ocado/index.html
@@ -11,7 +11,7 @@ weight: 4
quote: >
People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing.
---
-
+
CASE STUDY:
Ocado: Running Grocery Warehouses with a Cloud Native Platform
@@ -32,7 +32,7 @@ quote: >
-
+
Impact
With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses Prometheus and Grafana to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments."
@@ -54,7 +54,7 @@ Bryant had already been using Kubernetes with
+
"A cloud native infrastructure will not only save you money and allow you to be more in control of the infrastructure resources you consume, but also empower new product innovation, new experience for your users, and new business possibilities. It’s both a cost reducer and a money maker." - KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP
Pinning Its Past, Present, and Future on Cloud Native
@@ -60,7 +60,7 @@ The first phase involved moving to Docker. "Pinterest has been heavily running o
-
+
"Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing."
— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST
@@ -75,7 +75,7 @@ At the beginning of 2018, the team began onboarding its first use case into the
-
+
"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."
— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST
Prowise: How Kubernetes is Enabling the Edtech Solution’s Global Expansion
@@ -50,7 +50,7 @@ featured: false
The company’s existing infrastructure on Microsoft Azure Cloud was all on virtual machines, “a pretty traditional setup,” van den Bosch says. “We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn’t really want the hassle of trying to keep those servers in a particular state.”
-
+
"You don’t have to go all-in immediately. You can just take a few projects, a service, run it alongside your more traditional stack, and build it up from there. Kubernetes scales, so as you add applications and services to it, it will scale with you. You don’t have to do it all at once, and that’s really a secret to everything, but especially true to Kubernetes." — VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE
@@ -67,7 +67,7 @@ featured: false
With its first web-based applications now running in beta on Prowise’s Kubernetes platform, the team is seeing the benefits of rapid and smooth deployments. “The old way of deploying took half an hour of preparations and half an hour deploying it. With Kubernetes, it’s a couple of seconds,” says Senior Developer Bart Haalstra. As a result, adds van den Bosch, “We’ve gone from quarterly releases to a release every month in production. We’re pretty much deploying every hour or just when we find that a feature is ready for production. Before, our releases were mostly done on off-hours, where it couldn’t impact our customers, as our confidence the process itself was relatively low. With Kubernetes, we dare to deploy in the middle of a busy day with high confidence the deployment will succeed.”
-
+
"Kubernetes allows us to really consider the best tools for a problem. Want to have a full-fledged analytics application developed by a third party that is just right for your use case? Run it. Dabbling in machine learning and AI algorithms but getting tired of waiting days for training to complete? It takes only seconds to scale it. Got a stubborn developer that wants to use a programming language no one has heard of? Let him, if it runs in a container, of course. And all of that while your operations team/DevOps get to sleep at night." - VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE
ricardo.ch: How Kubernetes Improved Velocity and DevOps Harmony
@@ -48,7 +48,7 @@ featured: false
To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.
-
+
"Being in the End User Community demonstrates that we stand behind these technologies. In Switzerland, if all the companies see that ricardo.ch’s using it, I think that will help adoption. I also like that we’re connected to the other end users, so if there is a really heavy problem, I could go to the Slack channel, and say, ‘Hey, you guys…’ Like Reddit, Github and New York Times or whoever can give a recommendation on what to use here or how to solve that. So that’s kind of a superpower." — CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH
@@ -64,7 +64,7 @@ featured: false
Meury estimates that half of the application has been migrated to Kubernetes. And the plan is to move everything to the Google Cloud Platform by the end of 2018. "We are still running some servers in our own data centers, but all of the containerization efforts and describing our services as Kubernetes manifests will allow us to quite easily make that shift," says Meury.
-
+
"One of the core moments was when a front-end developer asked me how to do a port forward from his laptop to a front-end application to debug, and I told him the command. And he was like, ‘Wow, that’s all I need to do?’ He was super excited and happy about it. That showed me that this power in the right hands can just accelerate development."
- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH
diff --git a/content/en/case-studies/slamtec/index.html b/content/en/case-studies/slamtec/index.html
index 4a99d28fb3..86ebe15f91 100644
--- a/content/en/case-studies/slamtec/index.html
+++ b/content/en/case-studies/slamtec/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
featured: false
---
-
+
CASE STUDY:
@@ -47,7 +47,7 @@ featured: false
After an evaluation of existing technologies, Ji’s team chose Kubernetes for orchestration. "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes," says Ji. Plus, "avoiding binding to an infrastructure technology or provider can help us ensure that our business is deployed and migrated in cross-regional environments, and can serve users all over the world."
-
+
"CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes." - BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION
@@ -60,7 +60,7 @@ featured: false
The company uses Harbor as a container image repository. "Harbor’s replication function helps us implement CI/CD on both private and public clouds," says Ji. "In addition, multi-project support, certification and policy configuration, and integration with Kubernetes are also excellent functions." Helm is also being used as a package manager, and the team is evaluating the Istio framework. "We’re very pleased that Kubernetes and these frameworks can be seamlessly integrated," Ji adds.
-
+
"Cloud native is suitable for microservice architecture, it’s suitable for fast iteration and agile development, and it has a relatively perfect ecosystem and active community." - BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION
Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale
@@ -62,7 +62,7 @@ Led by the belief that “the cloud native architectures and patterns really giv
-
+
“We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.”
— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
@@ -75,7 +75,7 @@ With the emphasis on common tooling, “We are getting to the place where we can
-
+
“We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers."
— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
SOS International: Using Kubernetes to Provide Emergency Assistance in a Connected World
@@ -56,7 +56,7 @@ logo: sos_featured_logo.png
-
+
"We have to deliver new digital services, but we also have to migrate the old stuff, and we have to transform our core systems into new systems built on top of this platform. One of the reasons why we chose this technology is that we could build new digital services while changing the old one." - Martin Ahrentsen, Head of Enterprise Architecture, SOS International
@@ -70,7 +70,7 @@ logo: sos_featured_logo.png
-
+
"During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies." - Martin Ahrentsen, Head of Enterprise Architecture, SOS International
Spotify: An Early Adopter of Containers, Spotify Is Migrating from Homegrown Orchestration to Kubernetes
@@ -52,7 +52,7 @@ featured: false
-
+
"The community has been extremely helpful in getting us to work through all the technology much faster and much easier. And it’s helped us validate all the things we’re doing." - Dave Zolotusky, Software Engineer, Infrastructure and Operations, Spotify
@@ -67,7 +67,7 @@ featured: false
-
+
"We were able to use a lot of the Kubernetes APIs and extensibility features to support and interface with our legacy infrastructure, so the integration was straightforward and easy." - James Wen, Site Reliability Engineer, Spotify
Squarespace: Gaining Productivity and Resilience with Kubernetes
@@ -51,7 +51,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
+
After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had."
@@ -68,7 +68,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
+
"We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
@@ -49,7 +49,7 @@ featured: false
"We wanted to make sure that our engineers could embrace the DevOps mindset as they built software," Homer says. "It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."
-
+
"Kubernetes enabled auto scaling in a seamless and easily manageable way on days like Black Friday. We no longer have to sit there adding instances, monitoring the traffic, doing a lot of manual work." - CHRIS HOMER, COFOUNDER/CTO, THREDUP
@@ -62,7 +62,7 @@ featured: false
According to the infrastructure team, the key improvement was the consistent experience Kubernetes enabled for developers. "It lets developers work in the same environment that their application will be running in production," says Infrastructure Engineer Oleksandr Snagovskyi. Plus, "It became easier to test, easier to refine, and easier to deploy, because everything’s done automatically," says Infrastructure Engineer Oleksii Asiutin. "One of the main goals of our team is to make developers’ lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast."
-
+
"One of the main goals of our team is to make developers’ lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast." - OLEKSII ASIUTIN, INFRASTRUCTURE ENGINEER, THREDUP
VSCO: How a Mobile App Saved 70% on Its EC2 Bill with Cloud Native
@@ -48,7 +48,7 @@ featured: false
-
+
"Kubernetes seemed to have the strongest open source community around it, plus, we had started to standardize on a lot of the Google stack, with Go as a language, and gRPC for almost all communication between our own services inside the data center. So it seemed pretty natural for us to choose Kubernetes." - MELINDA LU, ENGINEERING MANAGER FOR VSCO'S MACHINE LEARNING TEAM
@@ -64,7 +64,7 @@ featured: false
-
+
"I've been really impressed seeing how our engineers have come up with really creative solutions to things by just combining a lot of Kubernetes primitives, exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it." - MELINDA LU, ENGINEERING MANAGER FOR VSCO’S MACHINE LEARNING TEAM
Woorank: How Kubernetes Helped a Startup Manage 50 Microservices with 12 Engineers—At 30% Less Cost
@@ -50,7 +50,7 @@ featured: false
-
+
"Cloud native technologies have brought to us a transparency on everything going on in our system, from the code to the server. It has brought huge cost savings and a better way of dealing with those costs and keeping them under control. And performance-wise, it has helped our team understand how we can make our code work better on the cloud native infrastructure." — NILS DE MOOR, CTO/COFOUNDER, WOORANK
@@ -66,7 +66,7 @@ featured: false
The company’s number one concern was immediately erased: Maintaining Kubernetes is the responsibility of just one person on staff, and it’s not his fulltime job. Updating the old infrastructure “was always a pain,” says De Moor: It used to take two active working days, “and it was always a bit scary when we did that.” With Kubernetes, it’s just a matter of “a few hours of passively following the process.”
-
+
"When things fail and errors pop up, the system tries to heal itself, and that’s really, for us, the key reason to work with Kubernetes. It allowed us to set up certain testing frameworks to just be alerted when things go wrong, instead of having to look at whether everything went right. It’s made people’s lives much easier. It’s quite a big mindset change." - NILS DE MOOR, CTO/COFOUNDER, WOORANK
diff --git a/content/en/case-studies/workiva/index.html b/content/en/case-studies/workiva/index.html
index 95f323d5ae..1c09503bfb 100644
--- a/content/en/case-studies/workiva/index.html
+++ b/content/en/case-studies/workiva/index.html
@@ -11,7 +11,7 @@ quote: >
With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code.
---
-
+
CASE STUDY:
Using OpenTracing to Help Pinpoint the Bottlenecks
@@ -30,12 +30,12 @@ quote: >
Workiva offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company’s first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva’s existing system, Broad’s team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn’t impact overall speed.
-
+
Solution
- Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.
+ Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.
Impact
Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
@@ -61,14 +61,14 @@ The challenges faced by Broad’s team may sound familiar to other companies tha
-
+
"A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on." — MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
-
+
Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."
With Workiva’s back-end code running on Google Compute Engine as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."
Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"
@@ -78,7 +78,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an
-
+
"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use." — MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
@@ -90,7 +90,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an
Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
Most of Workiva’s major products are now traced using OpenTracing, with data pushed into Google StackDriver. Even the products that aren’t fully traced have some components and libraries that are.
Broad points out that because some of the engineers were working on App Engine and already had experience with the platform’s Appstats library for profiling performance, it didn’t take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they’re working on. Questions about passing the context around and how that’s done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they’d used other systems that didn’t require that."
-But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing."
+But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing."
In fact, Broad believes that tracing naturally fits in with Workiva’s existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it’s being created and when it’s being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing."
@@ -98,7 +98,7 @@ In fact, Broad believes that tracing naturally fits in with Workiva’s existing
- "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." — Michael Davis, Software Engineer, Workiva
+ "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." — Michael Davis, Software Engineer, Workiva
diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html
index 498dc0ec73..c07443249a 100644
--- a/content/en/case-studies/ygrene/index.html
+++ b/content/en/case-studies/ygrene/index.html
@@ -12,7 +12,7 @@ quote: >
We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company.
---
-
+
CASE STUDY:
Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry
@@ -61,7 +61,7 @@ By 2017, deployments and scalability had become pain points. The company was uti
-
+
"CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."
— Austin Adams, Development Manager, Ygrene Energy Fund
@@ -78,7 +78,7 @@ Notary, in particular, "has been a godsend," says Adams. "We need to know that o
-
+
"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."
diff --git a/content/en/docs/concepts/_index.md b/content/en/docs/concepts/_index.md
index 1a61e3b28f..8165a3a1f4 100644
--- a/content/en/docs/concepts/_index.md
+++ b/content/en/docs/concepts/_index.md
@@ -12,61 +12,3 @@ The Concepts section helps you learn about the parts of the Kubernetes system an
-
-## Overview
-
-To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
-
-Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
-
-* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
-* Each individual non-master node in your cluster runs two processes:
- * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
- * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
-
-## Kubernetes objects
-
-Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) for more details.
-
-The basic Kubernetes objects include:
-
-* [Pod](/docs/concepts/workloads/pods/pod-overview/)
-* [Service](/docs/concepts/services-networking/service/)
-* [Volume](/docs/concepts/storage/volumes/)
-* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
-
-Kubernetes also contains higher-level abstractions that rely on [controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
-
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-* [Job](/docs/concepts/workloads/controllers/job/)
-
-## Kubernetes Control Plane
-
-The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.
-
-For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
-
-### Kubernetes Master
-
-The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
-
-> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
-
-### Kubernetes Nodes
-
-The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
-
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-If you would like to write a concept page, see
-[Page Content Types](/docs/home/contribute/style/page-content-types/#concept)
-for information about the concept page types.
-
-
diff --git a/content/en/docs/concepts/architecture/_index.md b/content/en/docs/concepts/architecture/_index.md
index 3a17d1b08e..61fb48e714 100755
--- a/content/en/docs/concepts/architecture/_index.md
+++ b/content/en/docs/concepts/architecture/_index.md
@@ -1,5 +1,7 @@
---
title: "Cluster Architecture"
weight: 30
+description: >
+ The architectural concepts behind Kubernetes.
---
diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md
old mode 100755
new mode 100644
index 72af40feec..c3b51f3acf
--- a/content/en/docs/concepts/cluster-administration/_index.md
+++ b/content/en/docs/concepts/cluster-administration/_index.md
@@ -1,5 +1,75 @@
---
-title: "Cluster Administration"
+title: Cluster Administration
+reviewers:
+- davidopp
+- lavalamp
weight: 100
+content_type: concept
+description: >
+ Lower-level detail relevant to creating or administering a Kubernetes cluster.
+no_list: true
---
+
+The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
+It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
+
+
+
+## Planning a cluster
+
+See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
+
+ {{< note >}}
+ Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
+ {{< /note >}}
+
+Before choosing a guide, here are some considerations:
+
+ - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
+ - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
+ - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
+ - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
+ - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
+ - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
+ latter, choose an actively-developed distro. Some distros only use binary releases, but
+ offer a greater variety of choices.
+ - Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
+
+
+## Managing a cluster
+
+* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
+
+* Learn how to [manage nodes](/docs/concepts/nodes/node/).
+
+* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
+
+## Securing a cluster
+
+* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
+
+* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
+
+* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
+
+* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
+
+* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
+
+* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
+
+* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
+
+* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
+
+### Securing the kubelet
+ * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
+ * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+ * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
+
+## Optional Cluster Services
+
+* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
+
+* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md
index 4f49e7bc42..8526ac830e 100644
--- a/content/en/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md
@@ -99,7 +99,7 @@ Different settings can be applied to a load balancer service in AWS using _annot
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing.
-* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB.
+* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Security groups defined here should not be shared between services.
* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created
* `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB.
* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends.
@@ -433,4 +433,4 @@ Alibaba Cloud does not require the format of node name, but the kubelet needs to
### Load Balancers
-You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
\ No newline at end of file
+You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
diff --git a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md
deleted file mode 100644
index fc2f55fbcd..0000000000
--- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-reviewers:
-- davidopp
-- lavalamp
-title: Cluster Administration Overview
-content_type: concept
-weight: 10
----
-
-
-The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
-It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
-
-
-
-## Planning a cluster
-
-See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
-
-Before choosing a guide, here are some considerations:
-
- - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
- - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
- latter, choose an actively-developed distro. Some distros only use binary releases, but
- offer a greater variety of choices.
- - Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
-
-Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
-
-## Managing a cluster
-
-* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
-
-* Learn how to [manage nodes](/docs/concepts/nodes/node/).
-
-* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
-
-## Securing a cluster
-
-* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
-
-* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
-
-* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
-
-* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
-
-* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
-
-* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
-
-* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
-
-* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
-
-### Securing the kubelet
- * [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
- * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
- * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
-
-## Optional Cluster Services
-
-* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
-
-* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
-
-
-
-
diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md
index 26fc1194df..5cdd070e0f 100644
--- a/content/en/docs/concepts/cluster-administration/flow-control.md
+++ b/content/en/docs/concepts/cluster-administration/flow-control.md
@@ -303,6 +303,9 @@ to get a mapping of UIDs to names for both FlowSchemas and
PriorityLevelConfigurations.
## Observability
+
+### Metrics
+
When you enable the API Priority and Fairness feature, the kube-apiserver
exports additional metrics. Monitoring these can help you determine whether your
configuration is inappropriately throttling important traffic, or find
@@ -365,9 +368,65 @@ poorly-behaved workloads that may be harming system health.
long requests took to actually execute, grouped by the FlowSchema that matched the
request and the PriorityLevel to which it was assigned.
+### Debug endpoints
+When you enable the API Priority and Fairness feature, the kube-apiserver serves the following additional paths at its HTTP[S] ports.
+- `/debug/api_priority_and_fairness/dump_priority_levels` - a listing of all the priority levels and the current state of each. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests,
+ workload-low, 0, true, false, 0, 0,
+ global-default, 0, true, false, 0, 0,
+ exempt, , , , , ,
+ catch-all, 0, true, false, 0, 0,
+ system, 0, true, false, 0, 0,
+ leader-election, 0, true, false, 0, 0,
+ workload-high, 0, true, false, 0, 0,
+ ```
+- `/debug/api_priority_and_fairness/dump_queues` - a listing of all the queues and their current state. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_queues
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, Index, PendingRequests, ExecutingRequests, VirtualStart,
+ workload-high, 0, 0, 0, 0.0000,
+ workload-high, 1, 0, 0, 0.0000,
+ workload-high, 2, 0, 0, 0.0000,
+ ...
+ leader-election, 14, 0, 0, 0.0000,
+ leader-election, 15, 0, 0, 0.0000,
+ ```
+
+- `/debug/api_priority_and_fairness/dump_requests` - a listing of all the requests that are currently waiting in a queue. You can fetch like this:
+ ```shell
+ kubectl get --raw /debug/api_priority_and_fairness/dump_requests
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime,
+ exempt, , , , , ,
+ system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z,
+ ```
+
+ In addition to the queued requests, the output includeas one phantom line for each priority level that is exempt from limitation.
+
+ You can get a more detailed listing with a command like this:
+ ```shell
+ kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1'
+ ```
+ The output is similar to this:
+ ```
+ PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource,
+ system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+ system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+ ```
+
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md
index 399f8f16cc..0c2299e35c 100644
--- a/content/en/docs/concepts/cluster-administration/logging.md
+++ b/content/en/docs/concepts/cluster-administration/logging.md
@@ -82,7 +82,8 @@ and the former approach is used in any other environment. In both cases, by
default rotation is configured to take place when log file exceeds 10MB.
As an example, you can find detailed information about how `kube-up.sh` sets
-up logging for COS image on GCP in the corresponding [script][cosConfigureHelper].
+up logging for COS image on GCP in the corresponding
+[script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
the basic logging example, the kubelet on the node handles the request and
@@ -96,8 +97,6 @@ the rotation and there are two files, one 10MB in size and one empty,
`kubectl logs` will return an empty response.
{{< /note >}}
-[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
-
### System component logs
There are two types of system components: those that run in a container and those
@@ -109,7 +108,7 @@ that do not run in a container. For example:
On machines with systemd, the kubelet and container runtime write to journald. If
systemd is not present, they write to `.log` files in the `/var/log` directory.
System components inside containers always write to the `/var/log` directory,
-bypassing the default logging mechanism. They use the [klog][klog]
+bypassing the default logging mechanism. They use the [klog](https://github.com/kubernetes/klog)
logging library. You can find the conventions for logging severity for those
components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
@@ -118,8 +117,6 @@ directory should be rotated. In Kubernetes clusters brought up by
the `kube-up.sh` script, those logs are configured to be rotated by
the `logrotate` tool daily or once the size exceeds 100MB.
-[klog]: https://github.com/kubernetes/klog
-
## Cluster-level logging architectures
While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options:
diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md
index b052dd3a15..d0485a4342 100644
--- a/content/en/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md
@@ -323,7 +323,7 @@ When load on your application grows or shrinks, it's easy to scale with `kubectl
kubectl scale deployment/my-nginx --replicas=1
```
```shell
-deployment.extensions/my-nginx scaled
+deployment.apps/my-nginx scaled
```
Now you only have one pod managed by the deployment.
diff --git a/content/en/docs/concepts/cluster-administration/monitoring.md b/content/en/docs/concepts/cluster-administration/monitoring.md
index fbea5e69c1..cd6069d229 100644
--- a/content/en/docs/concepts/cluster-administration/monitoring.md
+++ b/content/en/docs/concepts/cluster-administration/monitoring.md
@@ -40,14 +40,14 @@ Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes
If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`.
For example:
```
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: prometheus
-rules:
- - nonResourceURLs:
- - "/metrics"
- verbs:
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: prometheus
+rules:
+ - nonResourceURLs:
+ - "/metrics"
+ verbs:
- get
```
@@ -130,5 +130,4 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
-* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
-
+* Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index 29044be250..6779ee984a 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -12,7 +12,7 @@ understand exactly how it is expected to work. There are 4 distinct networking
problems to address:
1. Highly-coupled container-to-container communications: this is solved by
- [pods](/docs/concepts/workloads/pods/pod/) and `localhost` communications.
+ {{< glossary_tooltip text="Pods" term_id="pod" >}} and `localhost` communications.
2. Pod-to-Pod communications: this is the primary focus of this document.
3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
diff --git a/content/en/docs/concepts/configuration/_index.md b/content/en/docs/concepts/configuration/_index.md
index 1635c2a5bf..2ed10d601d 100755
--- a/content/en/docs/concepts/configuration/_index.md
+++ b/content/en/docs/concepts/configuration/_index.md
@@ -1,5 +1,7 @@
---
title: "Configuration"
weight: 80
+description: >
+ Resources that Kubernetes provides for configuring Pods.
---
diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
index 23d2a9dbed..d7d2feb9d5 100644
--- a/content/en/docs/concepts/configuration/configmap.md
+++ b/content/en/docs/concepts/configuration/configmap.md
@@ -60,7 +60,7 @@ metadata:
name: game-demo
data:
# property-like keys; each key maps to a simple value
- player_initial_lives: 3
+ player_initial_lives: "3"
ui_properties_file_name: "user-interface.properties"
#
# file-like keys
@@ -126,25 +126,32 @@ spec:
configMap:
# Provide the name of the ConfigMap you want to mount.
name: game-demo
+ # An array of keys from the ConfigMap to create as files
+ items:
+ - key: "game.properties"
+ path: "game.properties"
+ - key: "user-interface.properties"
+ path: "user-interface.properties"
```
A ConfigMap doesn't differentiate between single line property values and
multi-line file-like values.
What matters is how Pods and other objects consume those values.
+
For this example, defining a volume and mounting it inside the `demo`
-container as `/config` creates four files:
+container as `/config` creates two files,
+`/config/game.properties` and `/config/user-interface.properties`,
+even though there are four keys in the ConfigMap. This is because the Pod
+definition specifies an `items` array in the `volumes` section.
+If you omit the `items` array entirely, every key in the ConfigMap becomes
+a file with the same name as the key, and you get 4 files.
-- `/config/player_initial_lives`
-- `/config/ui_properties_file_name`
-- `/config/game.properties`
-- `/config/user-interface.properties`
+## Using ConfigMaps
-If you want to make sure that `/config` only contains files with a
-`.properties` extension, use two different ConfigMaps, and refer to both
-ConfigMaps in the `spec` for a Pod. The first ConfigMap defines
-`player_initial_lives` and `ui_properties_file_name`. The second
-ConfigMap defines the files that the kubelet places into `/config`.
+ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
+parts of the system, without being directly exposed to the Pod. For example,
+ConfigMaps can hold data that other parts of the system should use for configuration.
{{< note >}}
The most common way to use ConfigMaps is to configure settings for
@@ -157,12 +164,6 @@ or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
adjust their behavior based on a ConfigMap.
{{< /note >}}
-## Using ConfigMaps
-
-ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
-parts of the system, without being directly exposed to the Pod. For example,
-ConfigMaps can hold data that other parts of the system should use for configuration.
-
### Using ConfigMaps as files from a Pod
To consume a ConfigMap in a volume in a Pod:
@@ -223,7 +224,7 @@ data has the following advantages:
- improves performance of your cluster by significantly reducing load on kube-apiserver, by
closing watches for config maps marked as immutable.
-To use this feature, enable the `ImmutableEmphemeralVolumes`
+To use this feature, enable the `ImmutableEphemeralVolumes`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
your Secret or ConfigMap `immutable` field to `true`. For example:
```yaml
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index f8989c4a5d..275b70866a 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -132,11 +132,9 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
+ - name: app
+ image: super.mycompany.com/app:v4
env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
resources:
requests:
memory: "64Mi"
@@ -144,8 +142,8 @@ spec:
limits:
memory: "128Mi"
cpu: "500m"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: super.mycompany.com/log-aggregator:v6
resources:
requests:
memory: "64Mi"
@@ -227,7 +225,7 @@ locally-attached writeable devices or, sometimes, by RAM.
Pods use ephemeral local storage for scratch space, caching, and for logs.
The kubelet can provide scratch space to Pods using local ephemeral storage to
-mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir)
+mount [`emptyDir`](/docs/concepts/storage/volumes/#emptydir)
{{< glossary_tooltip term_id="volume" text="volumes" >}} into containers.
The kubelet also uses this kind of storage to hold
@@ -330,18 +328,15 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
- env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
+ - name: app
+ image: super.mycompany.com/app:v4
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: super.mycompany.com/log-aggregator:v6
resources:
requests:
ephemeral-storage: "2Gi"
@@ -657,7 +652,7 @@ Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
- 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)
+ 680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
```
In the preceding output, you can see that if a Pod requests more than 1120m
@@ -758,5 +753,3 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
* Read the [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API reference
* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
-
-
diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md
index 332bdebe28..744034f8ea 100644
--- a/content/en/docs/concepts/configuration/overview.md
+++ b/content/en/docs/concepts/configuration/overview.md
@@ -103,7 +103,7 @@ The caching semantics of the underlying image provider make even `imagePullPolic
- Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
-- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
+- Use `kubectl create deployment` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
diff --git a/content/en/docs/concepts/configuration/pod-overhead.md b/content/en/docs/concepts/configuration/pod-overhead.md
index 7057383dac..5eced7954f 100644
--- a/content/en/docs/concepts/configuration/pod-overhead.md
+++ b/content/en/docs/concepts/configuration/pod-overhead.md
@@ -87,7 +87,7 @@ spec:
memory: 100Mi
```
-At admission time the RuntimeClass [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
+At admission time the RuntimeClass [admission controller](/docs/reference/access-authn-authz/admission-controllers/)
updates the workload's PodSpec to include the `overhead` as described in the RuntimeClass. If the PodSpec already has this field defined,
the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
to include an `overhead`.
@@ -195,5 +195,3 @@ from source in the meantime.
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
-
-
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
index 9bfc514257..295a029d90 100644
--- a/content/en/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -255,7 +255,7 @@ makes Pod P eligible to preempt Pods on another Node.
#### Graceful termination of preemption victims
When Pods are preempted, the victims get their
-[graceful termination period](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
They have that much time to finish their work and exit. If they don't, they are
killed. This graceful termination period creates a time gap between the point
that the scheduler preempts Pods and the time when the pending Pod (P) can be
@@ -268,7 +268,7 @@ priority Pods to zero or a small number.
#### PodDisruptionBudget is supported, but not guaranteed
-A [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/)
+A [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)
allows application owners to limit the number of Pods of a replicated application
that are down simultaneously from voluntary disruptions. Kubernetes supports
PDB when preempting Pods, but respecting PDB is best effort. The scheduler tries
diff --git a/content/en/docs/concepts/containers/_index.md b/content/en/docs/concepts/containers/_index.md
old mode 100755
new mode 100644
index ad442f3ab3..edee4eccc4
--- a/content/en/docs/concepts/containers/_index.md
+++ b/content/en/docs/concepts/containers/_index.md
@@ -1,5 +1,45 @@
---
-title: "Containers"
+title: Containers
weight: 40
+description: Technology for packaging an application along with its runtime dependencies.
+reviewers:
+- erictune
+- thockin
+content_type: concept
+no_list: true
---
+
+
+Each container that you run is repeatable; the standardization from having
+dependencies included means that you get the same behavior wherever you
+run it.
+
+Containers decouple applications from underlying host infrastructure.
+This makes deployment easier in different cloud or OS environments.
+
+
+
+
+
+
+## Container images
+A [container image](/docs/concepts/containers/images/) is a ready-to-run
+software package, containing everything needed to run an application:
+the code and any runtime it requires, application and system libraries,
+and default values for any essential settings.
+
+By design, a container is immutable: you cannot change the code of a
+container that is already running. If you have a containerized application
+and want to make changes, you need to build a new container that includes
+the change, then recreate the container to start from the updated image.
+
+## Container runtimes
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## {{% heading "whatsnext" %}}
+
+* Read about [container images](/docs/concepts/containers/images/)
+* Read about [Pods](/docs/concepts/workloads/pods/)
+
diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
index 386e4d00bb..c8e93e93db 100644
--- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
@@ -42,7 +42,7 @@ so it must complete before the call to delete the container can be sent.
No parameters are passed to the handler.
A more detailed description of the termination behavior can be found in
-[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
### Hook handler implementations
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index b271c36d02..415d920b40 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -10,7 +10,7 @@ weight: 10
A container image represents binary data that encapsulates an application and all its
-software depencies. Container images are executable software bundles that can run
+software dependencies. Container images are executable software bundles that can run
standalone and that make very well defined assumptions about their runtime environment.
You typically create a container image of your application and push it to a registry
@@ -61,9 +61,11 @@ you can do one of the following:
- omit the `imagePullPolicy` and the tag for the image to use.
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
+When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
+
## Multi-architecture Images with Manifests
-As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
+As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
@@ -89,7 +91,7 @@ These options are explaind in more detail below.
### Configuring Nodes to authenticate to a Private Registry
If you run Docker on your nodes, you can configure the Docker container
-runtuime to authenticate to a private container registry.
+runtime to authenticate to a private container registry.
This approach is suitable if you can control node configuration.
@@ -127,7 +129,7 @@ example, run these on your desktop/laptop:
- for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
{{< note >}}
-For production clusers, use a configuration management tool so that you can apply this
+For production clusters, use a configuration management tool so that you can apply this
setting to all the nodes where you need it.
{{< /note >}}
diff --git a/content/en/docs/concepts/containers/overview.md b/content/en/docs/concepts/containers/overview.md
deleted file mode 100644
index 1d996b8b93..0000000000
--- a/content/en/docs/concepts/containers/overview.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-reviewers:
-- erictune
-- thockin
-title: Containers overview
-content_type: concept
-weight: 1
----
-
-
-
-Containers are a technology for packaging the (compiled) code for an
-application along with the dependencies it needs at run time. Each
-container that you run is repeatable; the standardization from having
-dependencies included means that you get the same behavior wherever you
-run it.
-
-Containers decouple applications from underlying host infrastructure.
-This makes deployment easier in different cloud or OS environments.
-
-
-
-
-
-
-## Container images
-A [container image](/docs/concepts/containers/images/) is a ready-to-run
-software package, containing everything needed to run an application:
-the code and any runtime it requires, application and system libraries,
-and default values for any essential settings.
-
-By design, a container is immutable: you cannot change the code of a
-container that is already running. If you have a containerized application
-and want to make changes, you need to build a new container that includes
-the change, then recreate the container to start from the updated image.
-
-## Container runtimes
-
-{{< glossary_definition term_id="container-runtime" length="all" >}}
-
-
-## {{% heading "whatsnext" %}}
-
-* Read about [container images](/docs/concepts/containers/images/)
-* Read about [Pods](/docs/concepts/workloads/pods/)
-
diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md
index d1857f3807..8f685e35f3 100644
--- a/content/en/docs/concepts/containers/runtime-class.md
+++ b/content/en/docs/concepts/containers/runtime-class.md
@@ -138,9 +138,7 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim
runtime_path = "${PATH_TO_BINARY}"
```
-See CRI-O's [config documentation][100] for more details.
-
-[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
+See CRI-O's [config documentation](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) for more details.
## Scheduling
@@ -149,7 +147,8 @@ See CRI-O's [config documentation][100] for more details.
As of Kubernetes v1.16, RuntimeClass includes support for heterogenous clusters through its
`scheduling` fields. Through the use of these fields, you can ensure that pods running with this
RuntimeClass are scheduled to nodes that support it. To use the scheduling support, you must have
-the [RuntimeClass admission controller][] enabled (the default, as of 1.16).
+the [RuntimeClass admission controller](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)
+enabled (the default, as of 1.16).
To ensure pods land on nodes supporting a specific RuntimeClass, that set of nodes should have a
common label which is then selected by the `runtimeclass.scheduling.nodeSelector` field. The
@@ -165,8 +164,6 @@ by each.
To learn more about configuring the node selector and tolerations, see [Assigning Pods to
Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/).
-[RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass
-
### Pod Overhead
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
diff --git a/content/en/docs/concepts/example-concept-template.md b/content/en/docs/concepts/example-concept-template.md
deleted file mode 100644
index adf3741f90..0000000000
--- a/content/en/docs/concepts/example-concept-template.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Example Concept Template
-reviewers:
-- chenopis
-content_type: concept
-toc_hide: true
----
-
-
-
-{{< note >}}
-Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
-{{< /note >}}
-
-This page explains ...
-
-
-
-
-
-## Understanding ...
-
-Kubernetes provides ...
-
-## Using ...
-
-To use ...
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-**[Optional Section]**
-
-* Learn more about [Writing a New Topic](/docs/home/contribute/style/write-new-topic/).
-* See [Page Content Types - Concept](/docs/home/contribute/style/page-concept-types/#concept).
-
-
-
-
diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md
index 93d955441d..6468ffa410 100644
--- a/content/en/docs/concepts/extend-kubernetes/_index.md
+++ b/content/en/docs/concepts/extend-kubernetes/_index.md
@@ -1,4 +1,213 @@
---
title: Extending Kubernetes
weight: 110
+description: Different ways to change the behavior of your Kubernetes cluster.
+reviewers:
+- erictune
+- lavalamp
+- cheftako
+- chenopis
+content_type: concept
+no_list: true
---
+
+
+
+Kubernetes is highly configurable and extensible. As a result,
+there is rarely a need to fork or submit patches to the Kubernetes
+project code.
+
+This guide describes the options for customizing a Kubernetes
+cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to
+understand how to adapt their Kubernetes cluster to the needs of
+their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it
+useful as an introduction to what extension points and patterns
+exist, and their trade-offs and limitations.
+
+
+
+
+
+
+## Overview
+
+Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions.
+
+## Configuration
+
+*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
+
+* [kubelet](/docs/admin/kubelet/)
+* [kube-apiserver](/docs/admin/kube-apiserver/)
+* [kube-controller-manager](/docs/admin/kube-controller-manager/)
+* [kube-scheduler](/docs/admin/kube-scheduler/).
+
+Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
+
+*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
+
+## Extensions
+
+Extensions are software components that extend and deeply integrate with Kubernetes.
+They adapt it to support new types and new kinds of hardware.
+
+Most cluster administrators will use a hosted or distribution
+instance of Kubernetes. As a result, most Kubernetes users will not need to
+install extensions and fewer will need to author new ones.
+
+## Extension Patterns
+
+Kubernetes is designed to be automated by writing client programs. Any
+program that reads and/or writes to the Kubernetes API can provide useful
+automation. *Automation* can run on the cluster or off it. By following
+the guidance in this doc you can write highly available and robust automation.
+Automation generally works with any Kubernetes cluster, including hosted
+clusters and managed installations.
+
+There is a specific pattern for writing client programs that work well with
+Kubernetes called the *Controller* pattern. Controllers typically read an
+object's `.spec`, possibly do things, and then update the object's `.status`.
+
+A controller is a client of Kubernetes. When Kubernetes is the client and
+calls out to a remote service, it is called a *Webhook*. The remote service
+is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of
+failure.
+
+In the webhook model, Kubernetes makes a network request to a remote service.
+In the *Binary Plugin* model, Kubernetes executes a binary (program).
+Binary plugins are used by the kubelet (e.g. [Flex Volume
+Plugins](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
+and [Network
+Plugins](/docs/concepts/cluster-administration/network-plugins/))
+and by kubectl.
+
+Below is a diagram showing how the extension points interact with the
+Kubernetes control plane.
+
+
+
+
+
+
+## Extension Points
+
+This diagram shows the extension points in a Kubernetes system.
+
+
+
+
+
+1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
+2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
+3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
+4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
+5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
+6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
+7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
+
+If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
+
+
+
+
+
+
+## API Extensions
+### User-Defined Types
+
+Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
+
+Do not use a Custom Resource as data storage for application, user, or monitoring data.
+
+For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/).
+
+
+### Combining New APIs with Automation
+
+The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies.
+
+### Changing Built-in Resources
+
+When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups.
+Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do.
+
+
+### API Access Extensions
+
+When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
+
+Each of these steps offers extension points.
+
+Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
+
+### Authentication
+
+[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
+
+Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
+
+
+### Authorization
+
+[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
+
+
+### Dynamic Admission Control
+
+After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
+
+* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
+* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
+
+## Infrastructure Extensions
+
+
+### Storage Plugins
+
+[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
+) allow users to mount volume types without built-in support by having the
+Kubelet call a Binary Plugin to mount the volume.
+
+
+### Device Plugins
+
+Device plugins allow a node to discover new Node resources (in addition to the
+builtin ones like cpu and memory) via a [Device
+Plugin](/docs/concepts/cluster-administration/device-plugins/).
+
+
+### Network Plugins
+
+Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/).
+
+### Scheduler Extensions
+
+The scheduler is a special type of controller that watches pods, and assigns
+pods to nodes. The default scheduler can be replaced entirely, while
+continuing to use other Kubernetes components, or [multiple
+schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
+can run at the same time.
+
+This is a significant undertaking, and almost all Kubernetes users find they
+do not need to modify the scheduler.
+
+The scheduler also supports a
+[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
+that permits a webhook backend (scheduler extension) to filter and prioritize
+the nodes chosen for a pod.
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
+* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+* Learn more about Infrastructure extensions
+ * [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)
+ * [Device Plugins](/docs/concepts/cluster-administration/device-plugins/)
+* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
+* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
+
+
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index f2ca2e2435..bd7d27305e 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -178,7 +178,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
| Feature | Description | CRDs | Aggregated API |
| ------- | ----------- | ---- | -------------- |
-| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
+| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes |
| Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes |
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index d27dddd384..7e6a648669 100644
--- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -223,7 +223,7 @@ Here are some examples of device plugin implementations:
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
-* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
+* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices
## {{% heading "whatsnext" %}}
@@ -232,6 +232,6 @@ Here are some examples of device plugin implementations:
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
-* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
+* Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/)
diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
index 7914b1cab5..bc06bd4ab0 100644
--- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -50,7 +50,7 @@ Extensions are software components that extend and deeply integrate with Kuberne
They adapt it to support new types and new kinds of hardware.
Most cluster administrators will use a hosted or distribution
-instance of Kubernetes. As a result, most Kubernetes users will need to
+instance of Kubernetes. As a result, most Kubernetes users will not need to
install extensions and fewer will need to author new ones.
## Extension Patterns
diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
deleted file mode 100644
index 7f81439c41..0000000000
--- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Poseidon-Firmament Scheduler
-content_type: concept
-weight: 80
----
-
-
-
-{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
-
-The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler.
-
-
-
-
-
-
-## Introduction
-
-Poseidon is a service that acts as the integration glue between the [Firmament scheduler](https://github.com/Huawei-PaaS/firmament) and Kubernetes. Poseidon-Firmament augments the current Kubernetes scheduling capabilities. It incorporates novel flow network graph based scheduling capabilities alongside the default Kubernetes scheduler. The Firmament scheduler models workloads and clusters as flow networks and runs min-cost flow optimizations over these networks to make scheduling decisions.
-
-Firmament models the scheduling problem as a constraint-based optimization over a flow network graph. This is achieved by reducing scheduling to a min-cost max-flow optimization problem. The Poseidon-Firmament scheduler dynamically refines the workload placements.
-
-Poseidon-Firmament scheduler runs alongside the default Kubernetes scheduler as an alternate scheduler. You can simultaneously run multiple, different schedulers.
-
-Flow graph scheduling with the Poseidon-Firmament scheduler provides the following advantages:
-
-- Workloads (Pods) are bulk scheduled to enable scheduling at massive scale.
- The Poseidon-Firmament scheduler outperforms the Kubernetes default scheduler by a wide margin when it comes to throughput performance for scenarios where compute resource requirements are somewhat uniform across your workload (Deployments, ReplicaSets, Jobs).
-- The Poseidon-Firmament's scheduler's end-to-end throughput performance and bind time improves as the number of nodes in a cluster increases. As you scale out, Poseidon-Firmament scheduler is able to amortize more and more work across workloads.
-- Scheduling in Poseidon-Firmament is dynamic; it keeps cluster resources in a global optimal state during every scheduling run.
-- The Poseidon-Firmament scheduler supports scheduling complex rule constraints.
-
-## How the Poseidon-Firmament scheduler works
-
-Kubernetes supports [using multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/). You can specify, for a particular Pod, that it is scheduled by a custom scheduler (“poseidon” for this case), by setting the `schedulerName` field in the PodSpec at the time of pod creation. The default scheduler will ignore that Pod and allow Poseidon-Firmament scheduler to schedule the Pod on a relevant node.
-
-For example:
-
-```yaml
-apiVersion: v1
-kind: Pod
-...
-spec:
- schedulerName: poseidon
-...
-```
-
-## Batch scheduling
-
-As mentioned earlier, Poseidon-Firmament scheduler enables an extremely high throughput scheduling environment at scale due to its bulk scheduling approach versus Kubernetes pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods are uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs.
-
-Although, Poseidon-Firmament scheduler is capable of scheduling various types of workloads, such as service, batch, etc., the following are a few use cases where it excels the most:
-
-1. For “Big Data/AI” jobs consisting of large number of tasks, throughput benefits are tremendous.
-2. Service or batch jobs where workload resource requirements are uniform across jobs (Replicasets/Deployments/Jobs).
-
-## Feature state
-
-Poseidon-Firmament is designed to work with Kubernetes release 1.6 and all subsequent releases.
-
-{{< caution >}}
-Poseidon-Firmament scheduler does not provide support for high availability; its implementation assumes that the scheduler cannot fail.
-{{< /caution >}}
-
-## Feature comparison {#feature-comparison-matrix}
-
-{{< table caption="Feature comparison of Kubernetes and Poseidon-Firmament schedulers." >}}
-|Feature|Kubernetes Default Scheduler|Poseidon-Firmament Scheduler|Notes|
-|--- |--- |--- |--- |
-|Node Affinity/Anti-Affinity|Y|Y||
-|Pod Affinity/Anti-Affinity - including support for pod anti-affinity symmetry|Y|Y|The default scheduler outperforms the Poseidon-Firmament scheduler pod affinity/anti-affinity functionality.|
-|Taints & Tolerations|Y|Y||
-|Baseline Scheduling capability in accordance to available compute resources (CPU & Memory) on a node|Y|Y†|**†** Not all Predicates & Priorities are supported with Poseidon-Firmament.|
-|Extreme Throughput at scale|Y†|Y|**†** Bulk scheduling approach scales or increases workload placement. Firmament scheduler offers high throughput when resource requirements (CPU/Memory) for incoming Pods are uniform across ReplicaSets/Deployments/Jobs.|
-|Colocation Interference Avoidance|N|N||
-|Priority Preemption|Y|N†|**†** Partially exists in Poseidon-Firmament versus extensive support in Kubernetes default scheduler.|
-|Inherent Rescheduling|N|Y†|**†** Poseidon-Firmament scheduler supports workload re-scheduling. In each scheduling run, Poseidon-Firmament considers all Pods, including running Pods, and as a result can migrate or evict Pods – a globally optimal scheduling environment.|
-|Gang Scheduling|N|Y||
-|Support for Pre-bound Persistence Volume Scheduling|Y|Y||
-|Support for Local Volume & Dynamic Persistence Volume Binding Scheduling|Y|N||
-|High Availability|Y|N||
-|Real-time metrics based scheduling|N|Y†|**†** Partially supported in Poseidon-Firmament using Heapster (now deprecated) for placing Pods using actual cluster utilization statistics rather than reservations.|
-|Support for Max-Pod per node|Y|Y|Poseidon-Firmament scheduler seamlessly co-exists with Kubernetes default scheduler.|
-|Support for Ephemeral Storage, in addition to CPU/Memory|Y|Y||
-{{< /table >}}
-
-## Installation
-
-The [Poseidon-Firmament installation guide](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md#Installation) explains how to deploy Poseidon-Firmament to your cluster.
-
-## Performance comparison
-
-{{< note >}}
- Please refer to the [latest benchmark results](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md) for detailed throughput performance comparison test results between Poseidon-Firmament scheduler and the Kubernetes default scheduler.
-{{< /note >}}
-
-Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in small batches (typically one at a time). These schedulers have the following crucial drawbacks:
-
-1. The scheduler commits to a pod placement early and restricts the choices for other pods that wait to be placed.
-2. There is limited opportunities for amortizing work across pods because they are considered for placement individually.
-
-These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput.
-
-
-## {{% heading "whatsnext" %}}
-
-* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information.
-* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon.
-* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design.
-* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md).
-
diff --git a/content/en/docs/concepts/overview/_index.md b/content/en/docs/concepts/overview/_index.md
index ec86980c4b..a52c470446 100755
--- a/content/en/docs/concepts/overview/_index.md
+++ b/content/en/docs/concepts/overview/_index.md
@@ -1,4 +1,5 @@
---
title: "Overview"
weight: 20
----
\ No newline at end of file
+description: Get a high-level outline of Kubernetes and the components it is built from.
+---
diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md
index f83f00683e..53e6b84c16 100644
--- a/content/en/docs/concepts/overview/components.md
+++ b/content/en/docs/concepts/overview/components.md
@@ -3,6 +3,9 @@ reviewers:
- lavalamp
title: Kubernetes Components
content_type: concept
+description: >
+ A Kubernetes cluster consists of the components that represent the control plane
+ and a set of machines called nodes.
weight: 20
card:
name: concepts
diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md
index dd69fb6ccb..42d12425b7 100644
--- a/content/en/docs/concepts/overview/kubernetes-api.md
+++ b/content/en/docs/concepts/overview/kubernetes-api.md
@@ -4,6 +4,9 @@ reviewers:
title: The Kubernetes API
content_type: concept
weight: 30
+description: >
+ The Kubernetes API lets you query and manipulate the state of objects in Kubernetes.
+ The core of Kubernetes' control plane is the API server and the HTTP API that it exposes. Users, the different parts of your cluster, and external components all communicate with one another through the API server.
card:
name: concepts
weight: 30
@@ -22,8 +25,6 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
-
-
## API changes
@@ -84,7 +85,7 @@ Kubernetes implements an alternative Protobuf based serialization format for the
To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path, such as `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
Versioning is done at the API level rather than at the resource or field level to ensure that the
API presents a clear, consistent view of system resources and behavior, and to enable controlling
@@ -154,14 +155,6 @@ The flag accepts comma separated set of key=value pairs describing runtime confi
{{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the
kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
-
## Persistence
Kubernetes stores its serialized state in terms of the API resources by writing them into
diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md
index 5b30c8e66e..5060b6f287 100644
--- a/content/en/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/en/docs/concepts/overview/what-is-kubernetes.md
@@ -74,7 +74,7 @@ Kubernetes lets you store and manage sensitive information, such as passwords, O
## What Kubernetes is not
-Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
+Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, and lets users integrate their logging, monitoring, and alerting solutions. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
Kubernetes:
diff --git a/content/en/docs/concepts/overview/working-with-objects/_index.md b/content/en/docs/concepts/overview/working-with-objects/_index.md
index 8661349a3f..f872c20697 100755
--- a/content/en/docs/concepts/overview/working-with-objects/_index.md
+++ b/content/en/docs/concepts/overview/working-with-objects/_index.md
@@ -1,5 +1,7 @@
---
title: "Working with Kubernetes Objects"
weight: 40
+description: >
+ Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster.
+ Learn about the Kubernetes object model and how to work with these objects.
---
-
diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
index 11e8944c8a..a0a68c6dff 100644
--- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
@@ -35,7 +35,7 @@ on every resource object.
| Key | Description | Example | Type |
| ----------------------------------- | --------------------- | -------- | ---- |
| `app.kubernetes.io/name` | The name of the application | `mysql` | string |
-| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `wordpress-abcxzy` | string |
+| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `mysql-abcxzy` | string |
| `app.kubernetes.io/version` | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
| `app.kubernetes.io/component` | The component within the architecture | `database` | string |
| `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string |
@@ -49,7 +49,7 @@ kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
- app.kubernetes.io/instance: wordpress-abcxzy
+ app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 1f4f4e7509..ab447cdcd6 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -92,7 +92,7 @@ and the `spec` format for a Deployment can be found in
## {{% heading "whatsnext" %}}
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
-* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
+* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
index 5e3acc5123..59b1763450 100644
--- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
@@ -26,7 +26,7 @@ need to create or think about namespaces at all. Start using namespaces when yo
need the features they provide.
Namespaces provide a scope for names. Names of resources need to be unique within a namespace,
-but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes
+but not across namespaces. Namespaces cannot be nested inside one another and each Kubernetes
resource can only be in one namespace.
Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
@@ -43,6 +43,10 @@ resources within the same namespace.
Creation and deletion of namespaces are described in the [Admin Guide documentation
for namespaces](/docs/admin/namespaces).
+{{< note >}}
+ Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
+{{< /note >}}
+
### Viewing namespaces
You can list the current namespaces in a cluster using:
diff --git a/content/en/docs/concepts/overview/working-with-objects/object-management.md b/content/en/docs/concepts/overview/working-with-objects/object-management.md
index 97f57ff275..7cb65b5497 100644
--- a/content/en/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/en/docs/concepts/overview/working-with-objects/object-management.md
@@ -40,12 +40,6 @@ objects, it provides no history of previous configurations.
Run an instance of the nginx container by creating a Deployment object:
-```sh
-kubectl run nginx --image nginx
-```
-
-Do the same thing using a different syntax:
-
```sh
kubectl create deployment nginx --image nginx
```
diff --git a/content/en/docs/concepts/policy/_index.md b/content/en/docs/concepts/policy/_index.md
index 41d91de546..d2b42bc4cd 100755
--- a/content/en/docs/concepts/policy/_index.md
+++ b/content/en/docs/concepts/policy/_index.md
@@ -1,5 +1,6 @@
---
title: "Policies"
weight: 90
+description: >
+ Policies you can configure that apply to groups of resources.
---
-
diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md
index 5a5241c42e..835bbc8475 100644
--- a/content/en/docs/concepts/policy/pod-security-policy.md
+++ b/content/en/docs/concepts/policy/pod-security-policy.md
@@ -302,7 +302,7 @@ kubectl-user delete pod pause
Let's try that again, slightly differently:
```shell
-kubectl-user run pause --image=k8s.gcr.io/pause
+kubectl-user create deployment pause --image=k8s.gcr.io/pause
deployment "pause" created
kubectl-user get pods
diff --git a/content/en/docs/concepts/scheduling-eviction/_index.md b/content/en/docs/concepts/scheduling-eviction/_index.md
index a30a80a451..3a2bf9359f 100644
--- a/content/en/docs/concepts/scheduling-eviction/_index.md
+++ b/content/en/docs/concepts/scheduling-eviction/_index.md
@@ -1,5 +1,8 @@
---
title: "Scheduling and Eviction"
weight: 90
+description: >
+ In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them.
+ Eviction is the process of proactively failing one or more Pods on resource-starved Nodes.
---
diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
index 406c3f974b..d469661849 100644
--- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -28,7 +28,7 @@ page will help you learn about scheduling.
## kube-scheduler
-[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
+[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
is the default scheduler for Kubernetes and runs as part of the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
kube-scheduler is designed so that, if you want and need to, you can
@@ -95,4 +95,3 @@ of the scheduler:
* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
-
diff --git a/content/en/docs/concepts/security/_index.md b/content/en/docs/concepts/security/_index.md
index aecc16eee7..3dfb62fe48 100644
--- a/content/en/docs/concepts/security/_index.md
+++ b/content/en/docs/concepts/security/_index.md
@@ -1,4 +1,6 @@
---
title: "Security"
weight: 81
+description: >
+ Concepts for keeping your cloud-native workload secure.
---
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index 2afd6c7335..20574c8f91 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -236,11 +236,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
spec.securityContext.supplementalGroups[*]
spec.securityContext.fsGroup
spec.containers[*].securityContext.runAsGroup
- spec.containers[*].securityContext.supplementalGroups[*]
- spec.containers[*].securityContext.fsGroup
spec.initContainers[*].securityContext.runAsGroup
- spec.initContainers[*].securityContext.supplementalGroups[*]
- spec.initContainers[*].securityContext.fsGroup
Allowed Values:
non-zero
undefined / nil (except for `*.runAsGroup`)
diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md
index eea2c65b33..2e7d91427e 100755
--- a/content/en/docs/concepts/services-networking/_index.md
+++ b/content/en/docs/concepts/services-networking/_index.md
@@ -1,5 +1,12 @@
---
title: "Services, Load Balancing, and Networking"
weight: 60
+description: >
+ Concepts and resources behind networking in Kubernetes.
---
+Kubernetes networking addresses four concerns:
+- Containers within a Pod use networking to communicate via loopback.
+- Cluster networking provides communication between different Pods.
+- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster.
+- You can also use Services to publish services only for consumption inside your cluster.
diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
index d4218f38f6..8eee03bf9b 100644
--- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+++ b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
@@ -23,7 +23,7 @@ Modification not using HostAliases is not suggested because the file is managed
Start an Nginx Pod which is assigned a Pod IP:
```shell
-kubectl run nginx --image nginx --generator=run-pod/v1
+kubectl run nginx --image nginx
```
```
@@ -64,14 +64,14 @@ By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like
## Adding additional entries with hostAliases
In addition to the default boilerplate, you can add additional entries to the
-`hosts` file.
+`hosts` file.
For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
`bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under
`.spec.hostAliases`:
{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
-Yoyu can start a Pod with that configuration by running:
+You can start a Pod with that configuration by running:
```shell
kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml
diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md
index 2c363ce7dc..33875e3637 100644
--- a/content/en/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/en/docs/concepts/services-networking/ingress-controllers.md
@@ -32,7 +32,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
provided and supported by VMware.
* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
- for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
+ for the [F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/).
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).
* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy.
* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index 430ee3c72d..fc069a593c 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -91,7 +91,7 @@ Different [Ingress controller](/docs/concepts/services-networking/ingress-contro
The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
has all the information needed to configure a load balancer or proxy server. Most importantly, it
contains a list of rules matched against all incoming requests. Ingress resource only supports rules
-for directing HTTP traffic.
+for directing HTTP(S) traffic.
### Ingress rules
@@ -192,7 +192,7 @@ IngressClass resource will ensure that new Ingresses without an
If you have more than one IngressClass marked as the default for your cluster,
the admission controller prevents creating new Ingress objects that don't have
an `ingressClassName` specified. You can resolve this by ensuring that at most 1
-IngressClasess are marked as default in your cluster.
+IngressClasses are marked as default in your cluster.
{{< /caution >}}
## Types of Ingress
diff --git a/content/en/docs/concepts/storage/_index.md b/content/en/docs/concepts/storage/_index.md
index 7e0dd19b12..a6aeac7734 100755
--- a/content/en/docs/concepts/storage/_index.md
+++ b/content/en/docs/concepts/storage/_index.md
@@ -1,5 +1,7 @@
---
title: "Storage"
weight: 70
+description: >
+ Ways to provide both long-term and temporary storage to Pods in your cluster.
---
diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md
index 2c3140de83..f60b90cb30 100644
--- a/content/en/docs/concepts/storage/persistent-volumes.md
+++ b/content/en/docs/concepts/storage/persistent-volumes.md
@@ -30,7 +30,7 @@ Managing storage is a distinct problem from managing compute instances. The Pers
A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
-A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).
+A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany, see [AccessModes](#access-modes)).
While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource.
diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md
index d6b3a9e332..1f12303eb7 100644
--- a/content/en/docs/concepts/storage/storage-classes.md
+++ b/content/en/docs/concepts/storage/storage-classes.md
@@ -41,7 +41,7 @@ be updated once they are created.
Administrators can specify a default StorageClass just for PVCs that don't
request any particular class to bind to: see the
-[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1)
+[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
for details.
```yaml
@@ -686,7 +686,7 @@ provisioner: kubernetes.io/portworx-volume
parameters:
repl: "1"
snap_interval: "70"
- io_priority: "high"
+ priority_io: "high"
```
@@ -695,7 +695,7 @@ parameters:
* `repl`: number of synchronous replicas to be provided in the form of
replication factor `1..3` (default: `1`) A string is expected here i.e.
`"1"` and not `1`.
-* `io_priority`: determines whether the volume will be created from higher
+* `priority_io`: determines whether the volume will be created from higher
performance or a lower priority storage `high/medium/low` (default: `low`).
* `snap_interval`: clock/time interval in minutes for when to trigger snapshots.
Snapshots are incremental based on difference with the prior snapshot, 0
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index c3f43f0fa5..acb48349ae 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@@ -1323,7 +1323,7 @@ persistent volume:
of a volume. This map must correspond to the map returned in the
`volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as
defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume).
- The map is passed to the CSI driver via the `volume_attributes` field in the
+ The map is passed to the CSI driver via the `volume_context` field in the
`ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and
`NodePublishVolumeRequest`.
- `controllerPublishSecretRef`: A reference to the secret object containing
diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md
index ca394ebd00..1aac095cb5 100644
--- a/content/en/docs/concepts/workloads/_index.md
+++ b/content/en/docs/concepts/workloads/_index.md
@@ -1,5 +1,7 @@
---
title: "Workloads"
weight: 50
+description: >
+ Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.
---
diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md
index 7f1b5c4630..c3d8cf36d8 100644
--- a/content/en/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/en/docs/concepts/workloads/controllers/daemonset.md
@@ -60,7 +60,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev
The `.spec.template` is one of the required fields in `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate
labels (see [pod selector](#pod-selector)).
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index 6287c0d98e..2c2fd8c7c2 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -13,8 +13,8 @@ weight: 30
-A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
-[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
+A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}}
+{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}.
You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
@@ -23,8 +23,6 @@ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in th
{{< /note >}}
-
-
## Use Case
@@ -861,7 +859,12 @@ The output is similar to this:
```
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment.apps/nginx-deployment successfully rolled out
-$ echo $?
+```
+and the exit status from `kubectl rollout` is 0 (success):
+```shell
+echo $?
+```
+```
0
```
@@ -1003,7 +1006,12 @@ The output is similar to this:
```
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
-$ echo $?
+```
+and the exit status from `kubectl rollout` is 1 (indicating an error):
+```shell
+echo $?
+```
+```
1
```
@@ -1043,8 +1051,7 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib
The `.spec.template` and `.spec.selector` are the only required field of the `.spec`.
-The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an
-`apiVersion` or `kind`.
+The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)).
@@ -1058,7 +1065,7 @@ allowed, which is the default if not specified.
### Selector
-`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
+`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
for the Pods targeted by this Deployment.
`.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
@@ -1145,10 +1152,6 @@ created Pod should be ready without any of its containers crashing, for it to be
This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
-### Rollback To
-
-Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used.
-
### Revision History Limit
A Deployment's revision history is stored in the ReplicaSets it controls.
diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
index a20951a35e..79cc905f58 100644
--- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
@@ -111,12 +111,6 @@ To control the cascading deletion policy, set the `propagationPolicy`
field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan",
"Foreground", or "Background".
-Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`.
-This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and
-Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you
-specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1`
-group version, dependent objects are deleted by default.
-
Here's an example that deletes dependents in background:
```shell
diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md
index 45fa66bd3d..81c1280943 100644
--- a/content/en/docs/concepts/workloads/controllers/job.md
+++ b/content/en/docs/concepts/workloads/controllers/job.md
@@ -122,7 +122,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d
The `.spec.template` is the only required field of the `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a pod template in a Job must specify appropriate
labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
@@ -215,12 +215,9 @@ To do so, set `.spec.backoffLimit` to specify the number of retries before
considering a Job as failed. The back-off limit is set by default to 6. Failed
Pods associated with the Job are recreated by the Job controller with an
exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The
-back-off count is reset if no new failed Pods appear before the Job's next
-status check.
+back-off count is reset when a Job's Pod is deleted or successful without any
+other Pods for the Job failing around that time.
-{{< note >}}
-Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
-{{< /note >}}
{{< note >}}
If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting
@@ -477,4 +474,3 @@ object, but maintains complete control over what Pods are created and how work i
## Cron Jobs {#cron-jobs}
You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
-
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index 2cc8284940..d59c09fc6b 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -126,7 +126,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun
The `.spec.template` is the only required field of the `.spec`.
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector).
diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md
index 4f8429d668..aff9e7b9f9 100644
--- a/content/en/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/en/docs/concepts/workloads/controllers/statefulset.md
@@ -141,6 +141,18 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form:
`$(podname).$(governing service domain)`, where the governing service is defined
by the `serviceName` field on the StatefulSet.
+Depending on how DNS is configured in your cluster, you may not be able to look up the DNS
+name for a newly-run Pod immediately. This behavior can occur when other clients in the
+cluster have already sent queries for the hostname of the Pod before it was created.
+Negative caching (normal in DNS) means that the results of previous failed lookups are
+remembered and reused, even after the Pod is running, for at least a few seconds.
+
+If you need to discover Pods promptly after they are created, you have a few options:
+
+- Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
+- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
+
+
As mentioned in the [limitations](#limitations) section, you are responsible for
creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services)
responsible for the network identity of the pods.
@@ -278,5 +290,3 @@ StatefulSet will then begin to recreate the Pods using the reverted template.
* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
-
-
diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md
old mode 100755
new mode 100644
index a105f18fb3..c7408721b7
--- a/content/en/docs/concepts/workloads/pods/_index.md
+++ b/content/en/docs/concepts/workloads/pods/_index.md
@@ -1,5 +1,271 @@
---
-title: "Pods"
+reviewers:
+- erictune
+title: Pods
+content_type: concept
weight: 10
+no_list: true
+card:
+ name: concepts
+ weight: 60
---
+
+
+_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes.
+
+A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
+{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification
+for how to run the containers. A Pod's contents are always co-located and
+co-scheduled, and run in a shared context. A Pod models an
+application-specific "logical host": it contains one or more application
+containers which are relatively tightly coupled.
+In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
+
+As well as application containers, a Pod can contain
+[init containers](/docs/concepts/workloads/pods/init-containers/) that run
+during Pod startup. You can also inject
+[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/)
+for debugging if your cluster offers this.
+
+
+
+## What is a Pod?
+
+{{< note >}}
+While Kubernetes supports more
+{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}}
+than just Docker, [Docker](https://www.docker.com/) is the most commonly known
+runtime, and it helps to describe Pods using some terminology from Docker.
+{{< /note >}}
+
+The shared context of a Pod is a set of Linux namespaces, cgroups, and
+potentially other facets of isolation - the same things that isolate a Docker
+container. Within a Pod's context, the individual applications may have
+further sub-isolations applied.
+
+In terms of Docker concepts, a Pod is similar to a group of Docker containers
+with shared namespaces and shared filesystem volumes.
+
+## Using Pods
+
+Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
+term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
+If your Pods need to track state, consider the
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
+
+Pods in a Kubernetes cluster are used in two main ways:
+
+* **Pods that run a single container**. The "one-container-per-Pod" model is the
+ most common Kubernetes use case; in this case, you can think of a Pod as a
+ wrapper around a single container; Kubernetes manages Pods rather than managing
+ the containers directly.
+* **Pods that run multiple containers that need to work together**. A Pod can
+ encapsulate an application composed of multiple co-located containers that are
+ tightly coupled and need to share resources. These co-located containers
+ form a single cohesive unit of service—for example, one container serving data
+ stored in a shared volume to the public, while a separate _sidecar_ container
+ refreshes or updates those files.
+ The Pod wraps these containers, storage resources, and an ephemeral network
+ identity together as a single unit.
+
+ {{< note >}}
+ Grouping multiple co-located and co-managed containers in a single Pod is a
+ relatively advanced use case. You should use this pattern only in specific
+ instances in which your containers are tightly coupled.
+ {{< /note >}}
+
+Each Pod is meant to run a single instance of a given application. If you want to
+scale your application horizontally (to provide more overall resources by running
+more instances), you should use multiple Pods, one for each instance. In
+Kubernetes, this is typically referred to as _replication_.
+Replicated Pods are usually created and managed as a group by a workload resource
+and its {{< glossary_tooltip text="controller" term_id="controller" >}}.
+
+See [Pods and controllers](#pods-and-controllers) for more information on how
+Kubernetes uses workload resources, and their controllers, to implement application
+scaling and auto-healing.
+
+### How Pods manage multiple containers
+
+Pods are designed to support multiple cooperating processes (as containers) that form
+a cohesive unit of service. The containers in a Pod are automatically co-located and
+co-scheduled on the same physical or virtual machine in the cluster. The containers
+can share resources and dependencies, communicate with one another, and coordinate
+when and how they are terminated.
+
+For example, you might have a container that
+acts as a web server for files in a shared volume, and a separate "sidecar" container
+that updates those files from a remote source, as in the following diagram:
+
+{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
+
+Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
+
+Pods natively provide two kinds of shared resources for their constituent containers:
+[networking](#pod-networking) and [storage](#pod-storage).
+
+## Working with Pods
+
+You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This
+is because Pods are designed as relatively ephemeral, disposable entities. When
+a Pod gets created (directly by you, or indirectly by a
+{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is
+scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster.
+The Pod remains on that node until the Pod finishes execution, the Pod object is deleted,
+the Pod is *evicted* for lack of resources, or the node fails.
+
+{{< note >}}
+Restarting a container in a Pod should not be confused with restarting a Pod. A Pod
+is not a process, but an environment for running container(s). A Pod persists until
+it is deleted.
+{{< /note >}}
+
+When you create the manifest for a Pod object, make sure the name specified is a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
+### Pods and controllers
+
+You can use workload resources to create and manage multiple Pods for you. A controller
+for the resource handles replication and rollout and automatic healing in case of
+Pod failure. For example, if a Node fails, a controller notices that Pods on that
+Node have stopped working and creates a replacement Pod. The scheduler places the
+replacement Pod onto a healthy Node.
+
+Here are some examples of workload resources that manage one or more Pods:
+
+* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
+* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
+
+### Pod templates
+
+Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
+from a _pod template_ and manage those Pods on your behalf.
+
+PodTemplates are specifications for creating Pods, and are included in workload resources such as
+[Deployments](/docs/concepts/workloads/controllers/deployment/),
+[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
+[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
+
+Each controller for a workload resource uses the `PodTemplate` inside the workload
+object to make actual Pods. The `PodTemplate` is part of the desired state of whatever
+workload resource you used to run your app.
+
+The sample below is a manifest for a simple Job with a `template` that starts one
+container. The container in that Pod prints a message then pauses.
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: hello
+spec:
+ template:
+ # This is the pod template
+ spec:
+ containers:
+ - name: hello
+ image: busybox
+ command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
+ restartPolicy: OnFailure
+ # The pod template ends here
+```
+
+Modifying the pod template or switching to a new pod template has no effect on the
+Pods that already exist. Pods do not receive template updates directly. Instead,
+a new Pod is created to match the revised pod template.
+
+For example, the deployment controller ensures that the running Pods match the current
+pod template for each Deployment object. If the template is updated, the Deployment has
+to remove the existing Pods and create new Pods based on the updated template. Each workload
+resource implements its own rules for handling changes to the Pod template.
+
+On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not
+directly observe or manage any of the details around pod templates and updates; those
+details are abstracted away. That abstraction and separation of concerns simplifies
+system semantics, and makes it feasible to extend the cluster's behavior without
+changing existing code.
+
+## Resource sharing and communication
+
+Pods enable data sharing and communication among their constituent
+containters.
+
+### Storage in Pods {#pod-storage}
+
+A Pod can specify a set of shared storage
+{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers
+in the Pod can access the shared volumes, allowing those containers to
+share data. Volumes also allow persistent data in a Pod to survive
+in case one of the containers within needs to be restarted. See
+[Storage](/docs/concepts/storage/) for more information on how
+Kubernetes implements shared storage and makes it available to Pods.
+
+### Pod networking
+
+Each Pod is assigned a unique IP address for each address family. Every
+container in a Pod shares the network namespace, including the IP address and
+network ports. Inside a Pod (and **only** then), the containers that belong to the Pod
+can communicate with one another using `localhost`. When containers in a Pod communicate
+with entities *outside the Pod*,
+they must coordinate how they use the shared network resources (such as ports).
+Within a Pod, containers share an IP address and port space, and
+can find each other via `localhost`. The containers in a Pod can also communicate
+with each other using standard inter-process communications like SystemV semaphores
+or POSIX shared memory. Containers in different Pods have distinct IP addresses
+and can not communicate by IPC without
+[special configuration](/docs/concepts/policy/pod-security-policy/).
+Containers that want to interact with a container running in a different Pod can
+use IP networking to comunicate.
+
+Containers within the Pod see the system hostname as being the same as the configured
+`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
+section.
+
+## Privileged mode for containers
+
+Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices.
+Processes within a privileged container get almost the same privileges that are available to processes outside a container.
+
+{{< note >}}
+Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.
+{{< /note >}}
+
+## Static Pods
+
+_Static Pods_ are managed directly by the kubelet daemon on a specific node,
+without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
+observing them.
+Whereas most Pods are managed by the control plane (for example, a
+{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static
+Pods, the kubelet directly supervises each static Pod (and restarts it if it fails).
+
+Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
+The main use for static Pods is to run a self-hosted control plane: in other words,
+using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components).
+
+The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
+on the Kubernetes API server for each static Pod.
+This means that the Pods running on a node are visible on the API server,
+but cannot be controlled from there.
+
+## {{% heading "whatsnext" %}}
+
+* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
+* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
+* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
+ configure different Pods with different container runtime configurations.
+* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
+* Pod is a top-level resource in the Kubernetes REST API.
+ The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+ object definition describes the object in detail.
+* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
+
+To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
+ * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+ * [Borg](https://research.google.com/pubs/pub43438.html)
+ * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
+ * [Omega](https://research.google/pubs/pub41684/)
+ * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md
index 589bde5668..0810b6fec7 100644
--- a/content/en/docs/concepts/workloads/pods/disruptions.md
+++ b/content/en/docs/concepts/workloads/pods/disruptions.md
@@ -11,17 +11,15 @@ weight: 60
This guide is for application owners who want to build
highly available applications, and thus need to understand
-what types of Disruptions can happen to Pods.
+what types of disruptions can happen to Pods.
-It is also for Cluster Administrators who want to perform automated
+It is also for cluster administrators who want to perform automated
cluster actions, like upgrading and autoscaling clusters.
-
-
-## Voluntary and Involuntary Disruptions
+## Voluntary and involuntary disruptions
Pods do not disappear until someone (a person or a controller) destroys them, or
there is an unavoidable hardware or system software error.
@@ -48,7 +46,7 @@ Administrator. Typical application owner actions include:
- updating a deployment's pod template causing a restart
- directly deleting a pod (e.g. by accident)
-Cluster Administrator actions include:
+Cluster administrator actions include:
- [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade.
- Draining a node from a cluster to scale the cluster down (learn about
@@ -68,7 +66,7 @@ Not all voluntary disruptions are constrained by Pod Disruption Budgets. For exa
deleting deployments or pods bypasses Pod Disruption Budgets.
{{< /caution >}}
-## Dealing with Disruptions
+## Dealing with disruptions
Here are some ways to mitigate involuntary disruptions:
@@ -90,58 +88,58 @@ of cluster (node) autoscaling may cause voluntary disruptions to defragment and
Your cluster administrator or hosting provider should have documented what level of voluntary
disruptions, if any, to expect.
-Kubernetes offers features to help run highly available applications at the same
-time as frequent voluntary disruptions. We call this set of features
-*Disruption Budgets*.
-
-## How Disruption Budgets Work
+## Pod disruption budgets
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
-An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application.
-A PDB limits the number of pods of a replicated application that are down simultaneously from
-voluntary disruptions. For example, a quorum-based application would
+Kubernetes offers features to help you run highly available applications even when you
+introduce frequent voluntary disruptions.
+
+As an application owner, you can create a PodDisruptionBudget (PDB) for each application.
+A PDB limits the number of Pods of a replicated application that are down simultaneously from
+voluntary disruptions. For example, a quorum-based application would
like to ensure that the number of replicas running is never brought below the
number needed for a quorum. A web front end might want to
ensure that the number of replicas serving load never falls below a certain
percentage of the total.
Cluster managers and hosting providers should use tools which
-respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
-instead of directly deleting pods or deployments. Examples are the `kubectl drain` command
-and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
+respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
+instead of directly deleting pods or deployments.
-When a cluster administrator wants to drain a node
-they use the `kubectl drain` command. That tool tries to evict all
-the pods on the machine. The eviction request may be temporarily rejected,
-and the tool periodically retries all failed requests until all pods
-are terminated, or until a configurable timeout is reached.
+For example, the `kubectl drain` subcommand lets you mark a node as going out of
+service. When you run `kubectl drain`, the tool tries to evict all of the Pods on
+the Node you're taking out of service. The eviction request that `kubectl` submits on
+your behalf may be temporarily rejected, so the tool periodically retries all failed
+requests until all Pods on the target node are terminated, or until a configurable timeout
+is reached.
A PDB specifies the number of replicas that an application can tolerate having, relative to how
many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is
supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time,
-then the Eviction API will allow voluntary disruption of one, but not two pods, at a time.
+then the Eviction API will allow voluntary disruption of one (but not two) pods at a time.
The group of pods that comprise the application is specified using a label selector, the same
as the one used by the application's controller (deployment, stateful-set, etc).
-The "intended" number of pods is computed from the `.spec.replicas` of the pods controller.
-The controller is discovered from the pods using the `.metadata.ownerReferences` of the object.
+The "intended" number of pods is computed from the `.spec.replicas` of the workload resource
+that is managing those pods. The control plane discovers the owning workload resource by
+examining the `.metadata.ownerReferences` of the Pod.
PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from
occurring, but they do count against the budget.
Pods which are deleted or unavailable due to a rolling upgrade to an application do count
-against the disruption budget, but controllers (like deployment and stateful-set)
-are not limited by PDBs when doing rolling upgrades -- the handling of failures
-during application updates is configured in the controller spec.
-(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
+against the disruption budget, but workload resources (such as Deployment and StatefulSet)
+are not limited by PDBs when doing rolling upgrades. Instead, the handling of failures
+during application updates is configured in the spec for the specific workload resource.
-When a pod is evicted using the eviction API, it is gracefully terminated (see
-`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
+When a pod is evicted using the eviction API, it is gracefully
+[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the
+`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
-## PDB Example
+## PodDisruptionBudget example {#pdb-example}
Consider a cluster with 3 nodes, `node-1` through `node-3`.
The cluster is running several applications. One of them has 3 replicas initially called
@@ -272,4 +270,6 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
* Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)
+* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
+ including steps to maintain its availability during the rollout.
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index 60973c46a8..9075bf1a8b 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -6,16 +6,60 @@ weight: 30
-{{< comment >}}Updated: 4/14/2015{{< /comment >}}
-{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}}
-
-This page describes the lifecycle of a Pod.
+This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting
+in the `Pending` [phase](#pod-phase), moving through `Running` if at least one
+of its primary containers starts OK, and then through either the `Succeeded` or
+`Failed` phases depending on whether any container in the Pod terminated in failure.
+Whilst a Pod is running, the kubelet is able to restart containers to handle some
+kind of faults. Within a Pod, Kubernetes tracks different container
+[states](#container-states) and handles
+In the Kubernetes API, Pods have both a specification and an actual status. The
+status for a Pod object consists of a set of [Pod conditions](#pod-conditions).
+You can also inject [custom readiness information](#pod-readiness-gate) into the
+condition data for a Pod, if that is useful to your application.
+Pods are only [scheduled](/docs/concepts/scheduling-eviction/) once in their lifetime.
+Once a Pod is scheduled (assigned) to a Node, the Pod runs on that Node until it stops
+or is [terminated](#pod-termination).
+## Pod lifetime
+
+Like individual application containers, Pods are considered to be relatively
+ephemeral (rather than durable) entities. Pods are created, assigned a unique
+ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled
+to nodes where they remain until termination (according to restart policy) or
+deletion.
+If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node
+are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
+
+Pods do not, by themselves, self-heal. If a Pod is scheduled to a
+{{< glossary_tooltip text="node" term_id="node" >}} that then fails,
+or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't
+survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a
+higher-level abstraction, called a
+{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of
+managing the relatively disposable Pod instances.
+
+A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead,
+that Pod can be replaced by a new, near-identical Pod, with even the same name i
+desired, but with a different UID.
+
+When something is said to have the same lifetime as a Pod, such as a
+{{< glossary_tooltip term_id="volume" text="volume" >}},
+that means that the thing exists as long as that specific Pod (with that exact UID)
+exists. If that Pod is deleted for any reason, and even if an identical replacement
+is created, the related thing (a volume, in this example) is also destroyed and
+created anew.
+
+{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
+
+*A multi-container Pod that contains a file puller and a
+web server that uses a persistent volume for shared storage between the containers.*
+
## Pod phase
A Pod's `status` field is a
@@ -24,7 +68,7 @@ object, which has a `phase` field.
The phase of a Pod is a simple, high-level summary of where the Pod is in its
lifecycle. The phase is not intended to be a comprehensive rollup of observations
-of Container or Pod state, nor is it intended to be a comprehensive state machine.
+of container or Pod state, nor is it intended to be a comprehensive state machine.
The number and meanings of Pod phase values are tightly guarded.
Other than what is documented here, nothing should be assumed about Pods that
@@ -34,188 +78,106 @@ Here are the possible values for `phase`:
Value | Description
:-----|:-----------
-`Pending` | The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while.
-`Running` | The Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting.
-`Succeeded` | All Containers in the Pod have terminated in success, and will not be restarted.
-`Failed` | All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system.
-`Unknown` | For some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod.
+`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network.
+`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
+`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted.
+`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
+`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
+
+If a node dies or is disconnected from the rest of the cluster, Kubernetes
+applies a policy for setting the `phase` of all Pods on the lost node to Failed.
+
+## Container states
+
+As well as the [phase](#pod-phase) of the Pod overall, Kubernetes tracks the state of
+each container inside a Pod. You can use
+[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/) to
+trigger events to run at certain points in a container's lifecycle.
+
+Once the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}
+assigns a Pod to a Node, the kubelet starts creating containers for that Pod
+using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
+There are three possible container states: `Waiting`, `Running`, and `Terminated`.
+
+To the check state of a Pod's containers, you can use
+`kubectl describe pod `. The output shows the state for each container
+within that Pod.
+
+Each state has a specific meaning:
+
+### `Waiting` {#container-state-waiting}
+
+If a container is not in either the `Running` or `Terminated` state, it `Waiting`.
+A container in the `Waiting` state is still running the operations it requires in
+order to complete start up: for example, pulling the container image from a container
+image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}}
+data.
+When you use `kubectl` to query a Pod with a container that is `Waiting`, you also see
+a Reason field to summarize why the container is in that state.
+
+### `Running` {#container-state-running}
+
+The `Running` status indicates that a container is executing without issues. If there
+was a `postStart` hook configured, it has already executed and executed. When you use
+`kubectl` to query a Pod with a container that is `Running`, you also see information
+about when the container entered the `Running` state.
+
+### `Terminated` {#container-state-terminated}
+
+A container in the `Terminated` state has begin execution and has then either run to
+completion or has failed for some reason. When you use `kubectl` to query a Pod with
+a container that is `Terminated`, you see a reason, and exit code, and the start and
+finish time for that container's period of execution.
+
+If a container has a `preStop` hook configured, that runs before the container enters
+the `Terminated` state.
+
+## Container restart policy {#restart-policy}
+
+The `spec` of a Pod has a `restartPolicy` field with possible values Always, OnFailure,
+and Never. The default value is Always.
+
+The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
+refers to restarts of the containers by the kubelet on the same node. After containers
+in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
+40s, …), that is capped at five minutes. Once a container has executed with no problems
+for 10 minutes without any problems, the kubelet resets the restart backoff timer for
+that container.
## Pod conditions
A Pod has a PodStatus, which has an array of
[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)
-through which the Pod has or has not passed. Each element of the PodCondition
-array has six possible fields:
+through which the Pod has or has not passed:
-* The `lastProbeTime` field provides a timestamp for when the Pod condition
- was last probed.
+* `PodScheduled`: the Pod has been scheduled to a node.
+* `ContainersReady`: all containers in the Pod are ready.
+* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
+ have started successfully.
+* `Ready`: the Pod is able to serve requests and should be added to the load
+ balancing pools of all matching Services.
-* The `lastTransitionTime` field provides a timestamp for when the Pod
- last transitioned from one status to another.
-
-* The `message` field is a human-readable message indicating details
- about the transition.
-
-* The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition.
-
-* The `status` field is a string, with possible values "`True`", "`False`", and "`Unknown`".
-
-* The `type` field is a string with the following possible values:
-
- * `PodScheduled`: the Pod has been scheduled to a node;
- * `Ready`: the Pod is able to serve requests and should be added to the load
- balancing pools of all matching Services;
- * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers)
- have started successfully;
- * `ContainersReady`: all containers in the Pod are ready.
+Field name | Description
+:--------------------|:-----------
+`type` | Name of this Pod condition.
+`status` | Indicates whether that condition is applicable, with possible values "`True`", "`False`", or "`Unknown`".
+`lastProbeTime` | Timestamp of when the Pod condition was last probed.
+`lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another.
+`reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition.
+`messsage | Human-readable message indicating details about the last status transition.
-
-## Container probes
-
-A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
-performed periodically by the [kubelet](/docs/admin/kubelet/)
-on a Container. To perform a diagnostic,
-the kubelet calls a
-[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by
-the Container. There are three types of handlers:
-
-* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
- Executes a specified command inside the Container. The diagnostic
- is considered successful if the command exits with a status code of 0.
-
-* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
- Performs a TCP check against the Container's IP address on
- a specified port. The diagnostic is considered successful if the port is open.
-
-* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
- Performs an HTTP Get request against the Container's IP
- address on a specified port and path. The diagnostic is considered successful
- if the response has a status code greater than or equal to 200 and less than 400.
-
-Each probe has one of three results:
-
-* Success: The Container passed the diagnostic.
-* Failure: The Container failed the diagnostic.
-* Unknown: The diagnostic failed, so no action should be taken.
-
-The kubelet can optionally perform and react to three kinds of probes on running
-Containers:
-
-* `livenessProbe`: Indicates whether the Container is running. If
- the liveness probe fails, the kubelet kills the Container, and the Container
- is subjected to its [restart policy](#restart-policy). If a Container does not
- provide a liveness probe, the default state is `Success`.
-
-* `readinessProbe`: Indicates whether the Container is ready to service requests.
- If the readiness probe fails, the endpoints controller removes the Pod's IP
- address from the endpoints of all Services that match the Pod. The default
- state of readiness before the initial delay is `Failure`. If a Container does
- not provide a readiness probe, the default state is `Success`.
-
-* `startupProbe`: Indicates whether the application within the Container is started.
- All other probes are disabled if a startup probe is provided, until it succeeds.
- If the startup probe fails, the kubelet kills the Container, and the Container
- is subjected to its [restart policy](#restart-policy). If a Container does not
- provide a startup probe, the default state is `Success`.
-
-### When should you use a liveness probe?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-If the process in your Container is able to crash on its own whenever it
-encounters an issue or becomes unhealthy, you do not necessarily need a liveness
-probe; the kubelet will automatically perform the correct action in accordance
-with the Pod's `restartPolicy`.
-
-If you'd like your Container to be killed and restarted if a probe fails, then
-specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
-
-### When should you use a readiness probe?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-If you'd like to start sending traffic to a Pod only when a probe succeeds,
-specify a readiness probe. In this case, the readiness probe might be the same
-as the liveness probe, but the existence of the readiness probe in the spec means
-that the Pod will start without receiving any traffic and only start receiving
-traffic after the probe starts succeeding.
-If your Container needs to work on loading large data, configuration files, or migrations during startup, specify a readiness probe.
-
-If you want your Container to be able to take itself down for maintenance, you
-can specify a readiness probe that checks an endpoint specific to readiness that
-is different from the liveness probe.
-
-Note that if you just want to be able to drain requests when the Pod is deleted,
-you do not necessarily need a readiness probe; on deletion, the Pod automatically
-puts itself into an unready state regardless of whether the readiness probe exists.
-The Pod remains in the unready state while it waits for the Containers in the Pod
-to stop.
-
-### When should you use a startup probe?
-
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-If your Container usually starts in more than `initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a startup probe that checks the same endpoint as the liveness probe. The default for `periodSeconds` is 30s.
-You should then set its `failureThreshold` high enough to allow the Container to start, without changing the default values of the liveness probe. This helps to protect against deadlocks.
-
-For more information about how to set up a liveness, readiness, startup probe, see
-[Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-
-## Pod and Container status
-
-For detailed information about Pod Container status, see
-[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
-and
-[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-Note that the information reported as Pod status depends on the current
-[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-
-## Container States
-
-Once Pod is assigned to a node by scheduler, kubelet starts creating containers using container runtime.There are three possible states of containers: Waiting, Running and Terminated. To check state of container, you can use `kubectl describe pod [POD_NAME]`. State is displayed for each container within that Pod.
-
-* `Waiting`: Default state of container. If container is not in either Running or Terminated state, it is in Waiting state. A container in Waiting state still runs its required operations, like pulling images, applying Secrets, etc. Along with this state, a message and reason about the state are displayed to provide more information.
-
- ```yaml
- ...
- State: Waiting
- Reason: ErrImagePull
- ...
- ```
-
-* `Running`: Indicates that the container is executing without issues. The `postStart` hook (if any) is executed prior to the container entering a Running state. This state also displays the time when the container entered Running state.
-
- ```yaml
- ...
- State: Running
- Started: Wed, 30 Jan 2019 16:46:38 +0530
- ...
- ```
-
-* `Terminated`: Indicates that the container completed its execution and has stopped running. A container enters into this when it has successfully completed execution or when it has failed for some reason. Regardless, a reason and exit code is displayed, as well as the container's start and finish time. Before a container enters into Terminated, `preStop` hook (if any) is executed.
-
- ```yaml
- ...
- State: Terminated
- Reason: Completed
- Exit Code: 0
- Started: Wed, 30 Jan 2019 11:45:26 +0530
- Finished: Wed, 30 Jan 2019 11:45:26 +0530
- ...
- ```
-
-## Pod readiness {#pod-readiness-gate}
+### Pod readiness {#pod-readiness-gate}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
Your application can inject extra feedback or signals into PodStatus:
-_Pod readiness_. To use this, set `readinessGates` in the PodSpec to specify
-a list of additional conditions that the kubelet evaluates for Pod readiness.
+_Pod readiness_. To use this, set `readinessGates` in the Pod's `spec` to
+specify a list of additional conditions that the kubelet evaluates for Pod readiness.
Readiness gates are determined by the current state of `status.condition`
-fields for the Pod. If Kubernetes cannot find such a
-condition in the `status.conditions` field of a Pod, the status of the condition
+fields for the Pod. If Kubernetes cannot find such a condition in the
+`status.conditions` field of a Pod, the status of the condition
is defaulted to "`False`".
Here is an example:
@@ -258,153 +220,226 @@ For a Pod that uses custom conditions, that Pod is evaluated to be ready **only*
when both the following statements apply:
* All containers in the Pod are ready.
-* All conditions specified in `ReadinessGates` are `True`.
+* All conditions specified in `readinessGates` are `True`.
When a Pod's containers are Ready but at least one custom condition is missing or
-`False`, the kubelet sets the Pod's condition to `ContainersReady`.
+`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`.
-## Restart policy
+## Container probes
-A PodSpec has a `restartPolicy` field with possible values Always, OnFailure,
-and Never. The default value is Always.
-`restartPolicy` applies to all Containers in the Pod. `restartPolicy` only
-refers to restarts of the Containers by the kubelet on the same node. Exited
-Containers that are restarted by the kubelet are restarted with an exponential
-back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten
-minutes of successful execution. As discussed in the
-[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof),
-once bound to a node, a Pod will never be rebound to another node.
+A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
+performed periodically by the [kubelet](/docs/admin/kubelet/)
+on a Container. To perform a diagnostic,
+the kubelet calls a
+[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
+the container. There are three types of handlers:
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
+ Executes a specified command inside the container. The diagnostic
+ is considered successful if the command exits with a status code of 0.
-## Pod lifetime
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
+ Performs a TCP check against the Pod's IP address on
+ a specified port. The diagnostic is considered successful if the port is open.
-In general, Pods remain until a human or
+* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
+ Performs an HTTP `GET` request against the Pod's IP
+ address on a specified port and path. The diagnostic is considered successful
+ if the response has a status code greater than or equal to 200 and less than 400.
+
+Each probe has one of three results:
+
+* `Success`: The container passed the diagnostic.
+* `Failure`: The container failed the diagnostic.
+* `Unknown`: The diagnostic failed, so no action should be taken.
+
+The kubelet can optionally perform and react to three kinds of probes on running
+containers:
+
+* `livenessProbe`: Indicates whether the container is running. If
+ the liveness probe fails, the kubelet kills the container, and the container
+ is subjected to its [restart policy](#restart-policy). If a Container does not
+ provide a liveness probe, the default state is `Success`.
+
+* `readinessProbe`: Indicates whether the container is ready to respond to requests.
+ If the readiness probe fails, the endpoints controller removes the Pod's IP
+ address from the endpoints of all Services that match the Pod. The default
+ state of readiness before the initial delay is `Failure`. If a Container does
+ not provide a readiness probe, the default state is `Success`.
+
+* `startupProbe`: Indicates whether the application within the container is started.
+ All other probes are disabled if a startup probe is provided, until it succeeds.
+ If the startup probe fails, the kubelet kills the container, and the container
+ is subjected to its [restart policy](#restart-policy). If a Container does not
+ provide a startup probe, the default state is `Success`.
+
+For more information about how to set up a liveness, readiness, or startup probe,
+see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+
+### When should you use a liveness probe?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+If the process in your container is able to crash on its own whenever it
+encounters an issue or becomes unhealthy, you do not necessarily need a liveness
+probe; the kubelet will automatically perform the correct action in accordance
+with the Pod's `restartPolicy`.
+
+If you'd like your container to be killed and restarted if a probe fails, then
+specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
+
+### When should you use a readiness probe?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+If you'd like to start sending traffic to a Pod only when a probe succeeds,
+specify a readiness probe. In this case, the readiness probe might be the same
+as the liveness probe, but the existence of the readiness probe in the spec means
+that the Pod will start without receiving any traffic and only start receiving
+traffic after the probe starts succeeding.
+If your container needs to work on loading large data, configuration files, or
+migrations during startup, specify a readiness probe.
+
+If you want your container to be able to take itself down for maintenance, you
+can specify a readiness probe that checks an endpoint specific to readiness that
+is different from the liveness probe.
+
+{{< note >}}
+If you just want to be able to drain requests when the Pod is deleted, you do not
+necessarily need a readiness probe; on deletion, the Pod automatically puts itself
+into an unready state regardless of whether the readiness probe exists.
+The Pod remains in the unready state while it waits for the containers in the Pod
+to stop.
+{{< /note >}}
+
+### When should you use a startup probe?
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Startup probes are useful for Pods that have containers that take a long time to
+come into service. Rather than set a long liveness interval, you can configure
+a separate configuration for probing the container as it starts up, allowing
+a time longer than the liveness interval would allow.
+
+If your container usually starts in more than
+`initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a
+startup probe that checks the same endpoint as the liveness probe. The default for
+`periodSeconds` is 30s. You should then set its `failureThreshold` high enough to
+allow the container to start, without changing the default values of the liveness
+probe. This helps to protect against deadlocks.
+
+## Termination of Pods {#pod-termination}
+
+Because Pods represent processes running on nodes in the cluster, it is important to
+allow those processes to gracefully terminate when they are no longer needed (rather
+than being abruptly stopped with a `KILL` signal and having no chance to clean up).
+
+The design aim is for you to be able to request deletion and know when processes
+terminate, but also be able to ensure that deletes eventually complete.
+When you request deletion of a Pod, the cluster records and tracks the intended grace period
+before the Pod is allowed to be forcefully killed. With that forceful shutdown tracking in
+place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful
+shutdown.
+
+Typically, the container runtime sends a a TERM signal is sent to the main process in each
+container. Once the grace period has expired, the KILL signal is sent to any remainig
+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
+cluster retries from the start including the full original grace period.
+
+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.
+ If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as
+ "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.
+ 1. If one of the Pod's containers has defined a `preStop`
+ [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet
+ runs that hook inside of the container. If the `preStop` hook is still running after the
+ grace period expires, the kubelet requests a small, one-off grace period extension of 2
+ seconds.
+ {{< note >}}
+ If the `preStop` hook needs longer to complete than the default grace period allows,
+ you must modify `terminationGracePeriodSeconds` to suit this.
+ {{< /note >}}
+ 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each
+ container.
+ {{< note >}}
+ The containers in the Pod receive the TERM signal at different times and in an arbitrary
+ order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
+ {{< /note >}}
+1. At the same time as the kubelet is starting graceful shutdown, the control plane removes that
+ shutting-down Pod from Endpoints (and, if enabled, EndpointSlice) objects where these represent
+ a {{< glossary_tooltip term_id="service" text="Service" >}} with a configured
+ {{< glossary_tooltip text="selector" term_id="selector" >}}.
+ {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and other workload resources
+ no longer treat the shutting-down Pod as a valid, in-service replica. Pods that shut down slowly
+ cannot continue to serve traffic as load balancers (like the service proxy) remove the Pod from
+ the list of endpoints as soon as the termination grace period _begins_.
+1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends
+ `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).
+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}
+
+{{< caution >}}
+Forced deletions can be potentially disruptiove for some workloads and their Pods.
+{{< /caution >}}
+
+By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports
+the `--grace-period=` option which allows you to override the default and specify your
+own value.
+
+Setting the grace period to `0` forcibly and immediately deletes the Pod from the API
+server. If the pod was still running on a node, that forcible deletion triggers the kubelet to
+begin immediate cleanup.
+
+{{< note >}}
+You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
+{{< /note >}}
+
+When a force deletion is performed, the API server does not wait for confirmation
+from the kubelet that the Pod has been terminated on the node it was running on. It
+removes the Pod in the API immediately so a new Pod can be created with the same
+name. On the node, Pods that are set to terminate immediately will still be given
+a small grace period before being force killed.
+
+If you need to force-delete Pods that are part of a StatefulSet, refer to the task
+documentation for
+[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
+
+### Garbage collection of failed Pods {#pod-garbage-collection}
+
+For failed Pods, the API objects remain in the cluster's API until a human or
{{< glossary_tooltip term_id="controller" text="controller" >}} process
explicitly removes them.
-The control plane cleans up terminated Pods (with a phase of `Succeeded` or
+
+The control plane cleans up terminated Pods (with a phase of `Succeeded` or
`Failed`), when the number of Pods exceeds the configured threshold
(determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
This avoids a resource leak as Pods are created and terminated over time.
-There are different kinds of resources for creating Pods:
-
-- Use a {{< glossary_tooltip term_id="deployment" >}},
- {{< glossary_tooltip term_id="replica-set" >}} or {{< glossary_tooltip term_id="statefulset" >}}
- for Pods that are not expected to terminate, for example, web servers.
-
-- Use a {{< glossary_tooltip term_id="job" >}}
- for Pods that are expected to terminate once their work is complete;
- for example, batch computations. Jobs are appropriate only for Pods with
- `restartPolicy` equal to OnFailure or Never.
-
-- Use a {{< glossary_tooltip term_id="daemonset" >}}
- for Pods that need to run one per eligible node.
-
-All workload resources contain a PodSpec. It is recommended to create the
-appropriate workload resource and let the resource's controller create Pods
-for you, rather than directly create Pods yourself.
-
-If a node dies or is disconnected from the rest of the cluster, Kubernetes
-applies a policy for setting the `phase` of all Pods on the lost node to Failed.
-
-## Examples
-
-### Advanced liveness probe example
-
-Liveness probes are executed by the kubelet, so all requests are made in the
-kubelet network namespace.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- labels:
- test: liveness
- name: liveness-http
-spec:
- containers:
- - args:
- - /server
- image: k8s.gcr.io/liveness
- livenessProbe:
- httpGet:
- # when "host" is not defined, "PodIP" will be used
- # host: my-host
- # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
- # scheme: HTTPS
- path: /healthz
- port: 8080
- httpHeaders:
- - name: X-Custom-Header
- value: Awesome
- initialDelaySeconds: 15
- timeoutSeconds: 1
- name: liveness
-```
-
-### Example states
-
- * Pod is running and has one Container. Container exits with success.
- * Log completion event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Pod `phase` becomes Succeeded.
- * Never: Pod `phase` becomes Succeeded.
-
- * Pod is running and has one Container. Container exits with failure.
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Pod `phase` becomes Failed.
-
- * Pod is running and has two Containers. Container 1 exits with failure.
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Do not restart Container; Pod `phase` stays Running.
- * If Container 1 is not running, and Container 2 exits:
- * Log failure event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Pod `phase` becomes Failed.
-
- * Pod is running and has one Container. Container runs out of memory.
- * Container terminates in failure.
- * Log OOM event.
- * If `restartPolicy` is:
- * Always: Restart Container; Pod `phase` stays Running.
- * OnFailure: Restart Container; Pod `phase` stays Running.
- * Never: Log failure event; Pod `phase` becomes Failed.
-
- * Pod is running, and a disk dies.
- * Kill all Containers.
- * Log appropriate event.
- * Pod `phase` becomes Failed.
- * If running under a controller, Pod is recreated elsewhere.
-
- * Pod is running, and its node is segmented out.
- * Node controller waits for timeout.
- * Node controller sets Pod `phase` to Failed.
- * If running under a controller, Pod is recreated elsewhere.
-
-
-
## {{% heading "whatsnext" %}}
-
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
* Get hands-on experience
- [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-
-* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
-
-
+ [configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
+* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
+and
+[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md
deleted file mode 100644
index e963b7ace6..0000000000
--- a/content/en/docs/concepts/workloads/pods/pod-overview.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-reviewers:
-- erictune
-title: Pod Overview
-content_type: concept
-weight: 10
-card:
- name: concepts
- weight: 60
----
-
-
-This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
-
-
-
-
-## Understanding Pods
-
-A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
-
-A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
-
-[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well.
-
-
-Pods in a Kubernetes cluster can be used in two main ways:
-
-* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
-* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
-
-Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (to provide more overall resources by running more instances), you should use multiple Pods, one for each instance. In Kubernetes, this is typically referred to as _replication_.
-Replicated Pods are usually created and managed as a group by a workload resource and its {{< glossary_tooltip text="_controller_" term_id="controller" >}}.
-See [Pods and controllers](#pods-and-controllers) for more information on how Kubernetes uses controllers to implement workload scaling and healing.
-
-### How Pods manage multiple containers
-
-Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
-
-Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram:
-
-{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
-
-Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
-
-Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
-
-#### Networking
-
-Each Pod is assigned a unique IP address for each address family. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
-
-#### Storage
-
-A Pod can specify a set of shared storage {{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
-
-## Working with Pods
-
-You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a {{< glossary_tooltip text="_controller_" term_id="controller" >}}), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the node fails.
-
-{{< note >}}
-Restarting a container in a Pod should not be confused with restarting a Pod. A Pod is not a process, but an environment for running a container. A Pod persists until it is deleted.
-{{< /note >}}
-
-Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a controller.
-
-### Pods and controllers
-
-You can use workload resources to create and manage multiple Pods for you. A controller for the resource handles replication and rollout and automatic healing in case of Pod failure. For example, if a Node fails, a controller notices that Pods on that Node have stopped working and creates a replacement Pod. The scheduler places the replacement Pod onto a healthy Node.
-
-Here are some examples of workload resources that manage one or more Pods:
-
-* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
-* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
-* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
-
-
-## Pod templates
-
-Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
-from a pod template and manage those Pods on your behalf.
-
-PodTemplates are specifications for creating Pods, and are included in workload resources such as
-[Deployments](/docs/concepts/workloads/controllers/deployment/),
-[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
-[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
-
-Each controller for a workload resource uses the PodTemplate inside the workload object to make actual Pods. The PodTemplate is part of the desired state of whatever workload resource you used to run your app.
-
-The sample below is a manifest for a simple Job with a `template` that starts one container. The container in that Pod prints a message then pauses.
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
- name: hello
-spec:
- template:
- # This is the pod template
- spec:
- containers:
- - name: hello
- image: busybox
- command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
- restartPolicy: OnFailure
- # The pod template ends here
-```
-
-Modifying the pod template or switching to a new pod template has no effect on the Pods that already exist. Pods do not receive template updates directly; instead, a new Pod is created to match the revised pod template.
-
-For example, a Deployment controller ensures that the running Pods match the current pod template. If the template is updated, the controller has to remove the existing Pods and create new Pods based on the updated template. Each workload controller implements its own rules for handling changes to the Pod template.
-
-On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code.
-
-
-
-## {{% heading "whatsnext" %}}
-
-* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
-* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container
-* Learn more about Pod behavior:
- * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
- * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
-
diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 2b16894e6b..c48b2aa5d0 100644
--- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -1,7 +1,7 @@
---
title: Pod Topology Spread Constraints
content_type: concept
-weight: 50
+weight: 40
---
diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md
deleted file mode 100644
index d87dc92cb2..0000000000
--- a/content/en/docs/concepts/workloads/pods/pod.md
+++ /dev/null
@@ -1,209 +0,0 @@
----
-reviewers:
-title: Pods
-content_type: concept
-weight: 20
----
-
-
-
-_Pods_ are the smallest deployable units of computing that can be created and
-managed in Kubernetes.
-
-
-
-
-
-
-## What is a Pod?
-
-A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
-{{< glossary_tooltip text="containers" term_id="container" >}} (such as
-Docker containers), with shared storage/network, and a specification
-for how to run the containers. A Pod's contents are always co-located and
-co-scheduled, and run in a shared context. A Pod models an
-application-specific "logical host" - it contains one or more application
-containers which are relatively tightly coupled — in a pre-container
-world, being executed on the same physical or virtual machine would mean being
-executed on the same logical host.
-
-While Kubernetes supports more container runtimes than just Docker, Docker is
-the most commonly known runtime, and it helps to describe Pods in Docker terms.
-
-The shared context of a Pod is a set of Linux namespaces, cgroups, and
-potentially other facets of isolation - the same things that isolate a Docker
-container. Within a Pod's context, the individual applications may have
-further sub-isolations applied.
-
-Containers within a Pod share an IP address and port space, and
-can find each other via `localhost`. They can also communicate with each
-other using standard inter-process communications like SystemV semaphores or
-POSIX shared memory. Containers in different Pods have distinct IP addresses
-and can not communicate by IPC without
-[special configuration](/docs/concepts/policy/pod-security-policy/).
-These containers usually communicate with each other via Pod IP addresses.
-
-Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined
-as part of a Pod and are made available to be mounted into each application's
-filesystem.
-
-In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as
-a group of Docker containers with shared namespaces and shared filesystem
-volumes.
-
-Like individual application containers, Pods are considered to be relatively
-ephemeral (rather than durable) entities. As discussed in
-[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and
-scheduled to nodes where they remain until termination (according to restart
-policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are
-scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not
-"rescheduled" to a new node; instead, it can be replaced by an identical Pod,
-with even the same name if desired, but with a new UID (see [replication
-controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details).
-
-When something is said to have the same lifetime as a Pod, such as a volume,
-that means that it exists as long as that Pod (with that UID) exists. If that
-Pod is deleted for any reason, even if an identical replacement is created, the
-related thing (e.g. volume) is also destroyed and created anew.
-
-{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
-
-*A multi-container Pod that contains a file puller and a
-web server that uses a persistent volume for shared storage between the containers.*
-
-## Motivation for Pods
-
-### Management
-
-Pods are a model of the pattern of multiple cooperating processes which form a
-cohesive unit of service. They simplify application deployment and management
-by providing a higher-level abstraction than the set of their constituent
-applications. Pods serve as unit of deployment, horizontal scaling, and
-replication. Colocation (co-scheduling), shared fate (e.g. termination),
-coordinated replication, resource sharing, and dependency management are
-handled automatically for containers in a Pod.
-
-### Resource sharing and communication
-
-Pods enable data sharing and communication among their constituents.
-
-The applications in a Pod all use the same network namespace (same IP and port
-space), and can thus "find" each other and communicate using `localhost`.
-Because of this, applications in a Pod must coordinate their usage of ports.
-Each Pod has an IP address in a flat shared networking space that has full
-communication with other physical computers and Pods across the network.
-
-Containers within the Pod see the system hostname as being the same as the configured
-`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
-section.
-
-In addition to defining the application containers that run in the Pod, the Pod
-specifies a set of shared storage volumes. Volumes enable data to survive
-container restarts and to be shared among the applications within the Pod.
-
-## Uses of pods
-
-Pods can be used to host vertically integrated application stacks (e.g. LAMP),
-but their primary motivation is to support co-located, co-managed helper
-programs, such as:
-
-* content management systems, file and data loaders, local cache managers, etc.
-* log and checkpoint backup, compression, rotation, snapshotting, etc.
-* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
-* proxies, bridges, and adapters
-* controllers, managers, configurators, and updaters
-
-Individual Pods are not intended to run multiple instances of the same
-application, in general.
-
-For a longer explanation, see [The Distributed System ToolKit: Patterns for
-Composite
-Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
-
-## Alternatives considered
-
-_Why not just run multiple programs in a single (Docker) container?_
-
-1. Transparency. Making the containers within the Pod visible to the
- infrastructure enables the infrastructure to provide services to those
- containers, such as process management and resource monitoring. This
- facilitates a number of conveniences for users.
-1. Decoupling software dependencies. The individual containers may be
- versioned, rebuilt and redeployed independently. Kubernetes may even support
- live updates of individual containers someday.
-1. Ease of use. Users don't need to run their own process managers, worry about
- signal and exit-code propagation, etc.
-1. Efficiency. Because the infrastructure takes on more responsibility,
- containers can be lighter weight.
-
-_Why not support affinity-based co-scheduling of containers?_
-
-That approach would provide co-location, but would not provide most of the
-benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and
-simplified management.
-
-## Durability of pods (or lack thereof)
-
-Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
-
-In general, users shouldn't need to create Pods directly. They should almost
-always use controllers even for singletons, for example,
-[Deployments](/docs/concepts/workloads/controllers/deployment/).
-Controllers provide self-healing with a cluster scope, as well as replication
-and rollout management.
-Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
-can also provide support to stateful Pods.
-
-The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
-
-Pod is exposed as a primitive in order to facilitate:
-
-* scheduler and controller pluggability
-* support for pod-level operations without the need to "proxy" them via controller APIs
-* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping
-* decoupling of controllers and services — the endpoint controller just watches Pods
-* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
-* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.
-
-## Termination of Pods
-
-Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
-
-An example flow:
-
-1. User sends command to delete Pod, with default grace period (30s)
-1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
-1. Pod shows up as "Terminating" when listed in client commands
-1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process.
- 1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) one-time extended grace period. You must modify `terminationGracePeriodSeconds` if the `preStop` hook needs longer to complete.
- 1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters.
-1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
-1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
-1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.
-
-By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod.
-You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
-
-### Force deletion of pods
-
-Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
-
-Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
-
-## Privileged mode for pod containers
-
-Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet.
-
-{{< note >}}
-Your container runtime must support the concept of a privileged container for this setting to be relevant.
-{{< /note >}}
-
-## API Object
-
-Pod is a top-level resource in the Kubernetes REST API.
-The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition
-describes the object in detail.
-When creating the manifest for a Pod object, make sure the name specified is a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-
-
diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md
index f77e34a3f9..9cbb7bdff8 100644
--- a/content/en/docs/concepts/workloads/pods/podpreset.md
+++ b/content/en/docs/concepts/workloads/pods/podpreset.md
@@ -1,7 +1,7 @@
---
reviewers:
- jessfraz
-title: Pod Preset
+title: Pod Presets
content_type: concept
weight: 50
---
@@ -32,20 +32,20 @@ specific service do not need to know all the details about that service.
In order to use Pod presets in your cluster you must ensure the following:
-1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
- example, this can be done by including `settings.k8s.io/v1alpha1=true` in
- the `--runtime-config` option for the API server. In minikube add this flag
- `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
- starting the cluster.
-1. You have enabled the admission controller `PodPreset`. One way to doing this
- is to include `PodPreset` in the `--enable-admission-plugins` option value specified
- for the API server. In minikube, add this flag
-
- ```shell
- --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
- ```
-
- while starting the cluster.
+1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
+ example, this can be done by including `settings.k8s.io/v1alpha1=true` in
+ the `--runtime-config` option for the API server. In minikube add this flag
+ `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
+ starting the cluster.
+1. You have enabled the admission controller named `PodPreset`. One way to doing this
+ is to include `PodPreset` in the `--enable-admission-plugins` option value specified
+ for the API server. For example, if you use Minikube, add this flag:
+
+ ```shell
+ --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+ ```
+
+ while starting your cluster.
## How it works
@@ -64,31 +64,28 @@ When a pod creation request occurs, the system does the following:
modified by a `PodPreset`. The annotation is of the form
`podpreset.admission.kubernetes.io/podpreset-: ""`.
-Each Pod can be matched by zero or more Pod Presets; and each `PodPreset` can be
-applied to zero or more pods. When a `PodPreset` is applied to one or more
-Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and
-`VolumeMounts`, Kubernetes modifies the container spec for all containers in
-the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.
+Each Pod can be matched by zero or more PodPresets; and each PodPreset can be
+applied to zero or more Pods. When a PodPreset is applied to one or more
+Pods, Kubernetes modifies the Pod Spec. For changes to `env`, `envFrom`, and
+`volumeMounts`, Kubernetes modifies the container spec for all containers in
+the Pod; for changes to `volumes`, Kubernetes modifies the Pod Spec.
{{< note >}}
A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate:
-- The `.spec.containers` field.
-- The `initContainers` field (requires Kubernetes version 1.14.0 or later).
+- The `.spec.containers` field
+- The `.spec.initContainers` field
{{< /note >}}
-### Disable Pod Preset for a Specific Pod
+### Disable Pod Preset for a specific pod
There may be instances where you wish for a Pod to not be altered by any Pod
-Preset mutations. In these cases, you can add an annotation in the Pod Spec
+preset mutations. In these cases, you can add an annotation in the Pod's `.spec`
of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
## {{% heading "whatsnext" %}}
-
See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
-
-
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
index 2f93af4a35..cd1b03efd4 100644
--- a/content/en/docs/contribute/_index.md
+++ b/content/en/docs/contribute/_index.md
@@ -3,6 +3,7 @@ content_type: concept
title: Contribute to Kubernetes docs
linktitle: Contribute
main_menu: true
+no_list: true
weight: 80
card:
name: contribute
@@ -23,47 +24,66 @@ Kubernetes documentation contributors:
Kubernetes documentation welcomes improvements from all contributors, new and experienced!
-
-
## Getting started
-Anyone can open an issue about documentation, or contribute a change with a pull request (PR) to the [`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). You need to be comfortable with [git](https://git-scm.com/) and [GitHub](https://lab.github.com/) to operate effectively in the Kubernetes community.
+Anyone can open an issue about documentation, or contribute a change with a
+pull request (PR) to the
+[`kubernetes/website` GitHub repository](https://github.com/kubernetes/website).
+You need to be comfortable with
+[git](https://git-scm.com/) and
+[GitHub](https://lab.github.com/)
+to work effectively in the Kubernetes community.
To get involved with documentation:
1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
-2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io).
-3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/new-content/) and [reviewing changes](/docs/contribute/review/reviewing-prs/).
+1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
+ and the website's [static site generator](https://gohugo.io).
+1. Make sure you understand the basic processes for
+ [opening a pull request](/docs/contribute/new-content/open-a-pr/) and
+ [reviewing changes](/docs/contribute/review/reviewing-prs/).
Some tasks require more trust and more access in the Kubernetes organization.
-See [Participating in SIG Docs](/docs/contribute/participating/) for more details about
+See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
roles and permissions.
## Your first contribution
-- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute.
-- See [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute) to find issues that make good entry points.
-- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub.
-- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language.
-- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
+- Read the [Contribution overview](/docs/contribute/new-content/overview/) to
+ learn about the different ways you can contribute.
+- Check [kubernetes/website issues list](/https://github.com/kubernetes/website/issues/)
+ for issues that make good entry points.
+- [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github)
+ to existing documentation and learn more about filing issues in GitHub.
+- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other
+ Kubernetes community members for accuracy and language.
+- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and
+ [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Learn about [page content types](/docs/contribute/style/page-content-types/)
+ and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
## Next steps
-- Learn to [work from a local clone](/docs/contribute/new-content/new-content/#fork-the-repo) of the repository.
+- Learn to [work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo)
+ of the repository.
- Document [features in a release](/docs/contribute/new-content/new-features/).
-- Participate in [SIG Docs](/docs/contribute/participating/), and become a [member or reviewer](/docs/contribute/participating/#roles-and-responsibilities).
+- Participate in [SIG Docs](/docs/contribute/participate/), and become a
+ [member or reviewer](/docs/contribute/participate/roles-and-responsibilities/).
+
- Start or help with a [localization](/docs/contribute/localization/).
## Get involved with SIG Docs
-[SIG Docs](/docs/contribute/participating/) is the group of contributors who publish and maintain Kubernetes documentation and the website. Getting involved with SIG Docs is a great way for Kubernetes contributors (feature development or otherwise) to have a large impact on the Kubernetes project.
+[SIG Docs](/docs/contribute/participate/) is the group of contributors who
+publish and maintain Kubernetes documentation and the website. Getting
+involved with SIG Docs is a great way for Kubernetes contributors (feature
+development or otherwise) to have a large impact on the Kubernetes project.
SIG Docs communicates with different methods:
-- [Join `#sig-docs` on the Kubernetes Slack instance](http://slack.k8s.io/). Make sure to
+- [Join `#sig-docs` on the Kubernetes Slack instance](https://slack.k8s.io/). Make sure to
introduce yourself!
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
where broader discussions take place and official decisions are recorded.
@@ -74,5 +94,3 @@ SIG Docs communicates with different methods:
- Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more.
- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
-
-
diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md
index 9cf6a65883..52ae7b0efd 100644
--- a/content/en/docs/contribute/advanced.md
+++ b/content/en/docs/contribute/advanced.md
@@ -13,73 +13,12 @@ This page assumes that you understand how to
to learn about more ways to contribute. You need to use the Git command line
client and other tools for some of these tasks.
-
-
-## Be the PR Wrangler for a week
-
-SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
-
-The PR wrangler’s duties include:
-
-- Review [open pull requests](https://github.com/kubernetes/website/pulls) daily for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides.
- - Review the smallest PRs (`size/XS`) first, then iterate towards the largest (`size/XXL`).
- - Review as many PRs as you can.
-- Ensure that the CLA is signed by each contributor.
- - Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
- - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA.
-- Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs.
- - Provide inline suggestions on the PR for the proposed content changes.
- - If you need to verify content, comment on the PR and request more details.
- - Assign relevant `sig/` label(s).
- - If needed, assign reviewers from the `reviewers:` block in the file's front matter.
- - Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status.
- - Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed.
- - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging.
- - Assign `/lgtm` and `/approve` labels to PRs that can be merged.
-- Merge PRs when they are ready, or close PRs that shouldn’t be accepted.
-- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata.
-
-### Helpful GitHub queries for wranglers
-
-The following queries are helpful when wrangling. After working through these queries, the remaining list of PRs to be
-reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one).
-
-- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
- Remind the contributor to sign the CLA. If they have already been reminded by both the bot and a human, close
- the PR and remind them that they can open it after signing the CLA.
- **Do not review PRs whose authors have not signed the CLA!**
-- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
- If it needs technical review, loop in one of the reviewers suggested by the bot. If it needs docs review
- or copy-editing, either suggest changes or add a copyedit commit to the PR to move it along.
-- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
- Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`.
-- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): If it’s a small PR against master with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
-- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch.
-
-### When to close Pull Requests
-
-Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
-
-- Close any PR where the CLA hasn’t been signed for two weeks.
-PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA.
-
-- Close any PR where the author has not responded to comments or feedback in 2 or more weeks.
-
-Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution.
-
-To close a pull request, leave a `/close` comment on the PR.
-
-{{< note >}}
-
-An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity.
-
-{{< /note >}}
-
## Propose improvements
-SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.
+SIG Docs [members](/docs/contribute/participate/roles-and-responsibilities/#members)
+can propose improvements.
After you've been contributing to the Kubernetes documentation for a while, you
may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/)
@@ -102,13 +41,13 @@ documentation testing might involve working with sig-testing.
## Coordinate docs for a Kubernetes release
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate
-docs for a Kubernetes release.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can coordinate docs for a Kubernetes release.
Each Kubernetes release is coordinated by a team of people participating in the
sig-release Special Interest Group (SIG). Others on the release team for a given
-release include an overall release lead, as well as representatives from sig-pm,
-sig-testing, and others. To find out more about Kubernetes release processes,
+release include an overall release lead, as well as representatives from
+sig-testing and others. To find out more about Kubernetes release processes,
refer to
[https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release).
@@ -133,8 +72,8 @@ rotated among SIG Docs approvers.
## Serve as a New Contributor Ambassador
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as
-New Contributor Ambassadors.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can serve as New Contributor Ambassadors.
New Contributor Ambassadors welcome new contributors to SIG-Docs,
suggest PRs to new contributors, and mentor new contributors through their first
@@ -152,14 +91,14 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and
## Sponsor a new contributor
-SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
-new contributors.
+SIG Docs [reviewers](/docs/contribute/participate/roles-and-responsibilities/#reviewers)
+can sponsor new contributors.
After a new contributor has successfully submitted 5 substantive pull requests
to one or more Kubernetes repositories, they are eligible to apply for
-[membership](/docs/contribute/participating#members) in the Kubernetes
-organization. The contributor's membership needs to be backed by two sponsors
-who are already reviewers.
+[membership](/docs/contribute/participate/roles-and-responsibilities/#members)
+in the Kubernetes organization. The contributor's membership needs to be
+backed by two sponsors who are already reviewers.
New docs contributors can request sponsors by asking in the #sig-docs channel
on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the
@@ -171,7 +110,8 @@ membership in the Kubernetes organization.
## Serve as a SIG Co-chair
-SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term as a co-chair of SIG Docs.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers)
+can serve a term as a co-chair of SIG Docs.
### Prerequisites
@@ -180,7 +120,12 @@ Approvers must meet the following requirements to be a co-chair:
- Have been a SIG Docs approver for at least 6 months
- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases
- Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
-- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
+- Understand how other Kubernetes SIGs and repositories affect the SIG Docs
+ workflow, including:
+ [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
+ [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs),
+ plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of
+ [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months
### Responsibilities
@@ -244,5 +189,3 @@ When you’re ready to start the recording, click Record to Cloud.
When you’re ready to stop recording, click Stop.
The video uploads automatically to YouTube.
-
-
diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md
index f057ce6800..ea6065472e 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubectl.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md
@@ -15,21 +15,16 @@ like
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) and
[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
This topic does not show how to generate the
-[kubectl](/docs/reference/generated/kubectl/kubectl/)
+[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
options reference page. For instructions on how to generate the kubectl options
reference page, see
-[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/).
+[Generating Reference Pages for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/).
{{< /note >}}
-
-
## {{% heading "prerequisites" %}}
-
{{< include "prerequisites-ref-docs.md" >}}
-
-
## Setting up the local repositories
@@ -237,6 +232,9 @@ Build the Kubernetes documentation in your local ``.
cd
make docker-serve
```
+{{< note >}}
+The use of `make docker-serve` is deprecated. Please use `make container-serve` instead.
+{{< /note >}}
View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/).
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
index 10482eda97..f2ec01d8e8 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
@@ -185,21 +185,23 @@ cd
make docker-serve
```
+{{< note >}}
+The use of `make docker-serve` is deprecated. Please use `make container-serve` instead.
+{{< /note >}}
+
## Commit the changes
In `` run `git add` and `git commit` to commit the change.
Submit your changes as a
-[pull request](/docs/contribute/start/) to the
+[pull request](/docs/contribute/new-content/open-a-pr/) to the
[kubernetes/website](https://github.com/kubernetes/website) repository.
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
-
## {{% heading "whatsnext" %}}
-
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
diff --git a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
index a777fb77e5..c719920813 100644
--- a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
+++ b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
@@ -18,4 +18,5 @@
- You need to know how to create a pull request to a GitHub repository.
This involves creating your own fork of the repository. For more
- information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone).
+ information, see [Work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo).
+
diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md
index df5cdbb95f..0790f7925a 100644
--- a/content/en/docs/contribute/generate-ref-docs/quickstart.md
+++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md
@@ -10,15 +10,10 @@ This page shows how to use the `update-imported-docs` script to generate
the Kubernetes reference documentation. The script automates
the build setup and generates the reference documentation for a release.
-
-
## {{% heading "prerequisites" %}}
-
{{< include "prerequisites-ref-docs.md" >}}
-
-
## Getting the docs repository
@@ -87,7 +82,7 @@ The `update-imported-docs` script performs the following steps:
the sections in the `kubectl` command reference.
When the generated files are in your local clone of the ``
-repository, you can submit them in a [pull request](/docs/contribute/start/)
+repository, you can submit them in a [pull request](/docs/contribute/new-content/open-a-pr/)
to ``.
## Configuration file format
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index 0c698305b9..1ae4796522 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -183,7 +183,7 @@ Description | URLs
-----|-----
Home | [All heading and subheading URLs](/docs/home/)
Setup | [All heading and subheading URLs](/docs/setup/)
-Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
+Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/)
Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n)
Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:
diff --git a/content/en/docs/contribute/new-content/blogs-case-studies.md b/content/en/docs/contribute/new-content/blogs-case-studies.md
index 76acbd2d41..2ec9f35ac0 100644
--- a/content/en/docs/contribute/new-content/blogs-case-studies.md
+++ b/content/en/docs/contribute/new-content/blogs-case-studies.md
@@ -12,35 +12,77 @@ weight: 30
Anyone can write a blog post and submit it for review.
Case studies require extensive review before they're approved.
-
-
-## Write a blog post
+## The Kubernetes Blog
-Blog posts should not be
-vendor pitches. They must contain content that applies broadly to
-the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
+The Kubernetes blog is used by the project to communicate new features, community reports, and any news that might be relevant to the Kubernetes community.
+This includes end users and developers.
+Most of the blog's content is about things happening in the core project, but we encourage you to submit about things happening elsewhere in the ecosystem too!
-To submit a blog post, you can either:
+Anyone can write a blog post and submit it for review.
-- Use the
-[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
-- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
+### Guidelines and expectations
-If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information:
+- Blog posts should not be vendor pitches.
+ - Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](https://kubernetes.io/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties.
+ - Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog.
+ - Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out.
+- Blog posts are not published on specific dates.
+ - Articles are reviewed by community volunteers. We'll try our best to accommodate specific timing, but we make no guarantees.
+ - Many core parts of the Kubernetes projects submit blog posts during release windows, delaying publication times. Consider submitting during a quieter period of the release cycle.
+ - If you are looking for greater coordination on post release dates, coordinating with [CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post.
+ - Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs, you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/) to ask in real time.
+- Blog posts should be relevant to Kubernetes users.
+ - Topics related to participation in or results of Kubernetes SIGs activities are always on topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines) for support on these posts).
+ - The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic.
+ - Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft.
+ - Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
+- Blog posts should be original content
+ - The official blog is not for repurposing existing content from a third party as new content.
+ - The [license](https://github.com/kubernetes/website/blob/master/LICENSE) for the blog does allow commercial use of the content for commercial purposes, just not the other way around.
+- Blog posts should aim to be future proof
+ - Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader.
+ - It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post.
+ - Consider concentrating the long technical content as a call to action of the blog post, and focus on the problem space or why readers should care.
-- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
-- The front matter must include the following:
+### Technical Considerations for submitting a blog post
+
+Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use this technology stack.
+
+We recognize that this requirement makes the process more difficult for less-familiar folks to submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to lower the barrier, please volunteer to help out.
+
+The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
+
+To submit a blog post follow these directions:
+
+- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
+
+- Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information:
+
+ - The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
+ - Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes failures during a build.
+ - The front matter must include the following:
+
+ ```yaml
+ ---
+ layout: blog
+ title: "Your Title Here"
+ date: YYYY-MM-DD
+ slug: text-for-URL-link-here-no-spaces
+ ---
+ ```
+ - The first or initial commit message should be a short summary of the work being done and should stand alone as a description of the blog post. Please note that subsequent edits to your blog will be squashed into this main commit, so it should be as useful as possible.
+ - Examples of a good commit message:
+ - _Add blog post on the foo kubernetes feature_
+ - _blog: foobar announcement_
+ - Examples of bad commit message:
+ - _Add blog post_
+ - _._
+ - _initial commit_
+ - _draft post_
+ - The blog team will then review your PR and give you comments on things you might need to fix. After that the bot will merge your PR and your blog post will be published.
-```yaml
----
-layout: blog
-title: "Your Title Here"
-date: YYYY-MM-DD
-slug: text-for-URL-link-here-no-spaces
----
-```
## Submit a case study
@@ -50,11 +92,4 @@ real-world problems. The Kubernetes marketing team and members of the {{< glossa
Have a look at the source for the
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
-Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines.
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-
+Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines.
diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md
index 5b2642dd39..d511360e22 100644
--- a/content/en/docs/contribute/new-content/open-a-pr.md
+++ b/content/en/docs/contribute/new-content/open-a-pr.md
@@ -1,6 +1,5 @@
---
title: Opening a pull request
-slug: new-content
content_type: concept
weight: 10
card:
@@ -97,10 +96,12 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
### Create a local clone and set the upstream
-3. In a terminal window, clone your fork:
+3. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme):
```bash
git clone git@github.com//website
+ cd website
+ git submodule update --init --recursive --depth 1
```
4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote:
@@ -261,18 +262,26 @@ The commands below use Docker as default container engine. Set the `CONTAINER_EN
Alternately, install and use the `hugo` command on your computer:
-5. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
+1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
-6. In a terminal, go to your Kubernetes website repository and start the Hugo server:
+2. If you have not updated your website repository, the `website/themes/docsy` directory is empty.
+ The site cannot build without a local copy of the theme. To update the website theme, run:
+
+ ```bash
+ git submodule update --init --recursive --depth 1
+ ```
+
+3. In a terminal, go to your Kubernetes website repository and start the Hugo server:
```bash
cd /website
- hugo server
+ hugo server --buildFuture
```
-7. In your browser’s address bar, enter `https://localhost:1313`.
+4. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
+ changes and rebuilds the site as needed.
-8. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
+5. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window.
{{% /tab %}}
@@ -496,6 +505,6 @@ the templates with as much detail as possible when you file issues or PRs.
## {{% heading "whatsnext" %}}
-- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process.
+- Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process.
diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md
index e9ef332430..b1f7e4f20a 100644
--- a/content/en/docs/contribute/new-content/overview.md
+++ b/content/en/docs/contribute/new-content/overview.md
@@ -20,8 +20,12 @@ This section contains information you should know before contributing new conten
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
-- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
-- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
+- In addition to the standard Hugo shortcodes, we use a number of
+ [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
+- Documentation source is available in multiple languages in `/content/`. Each
+ language has its own folder with a two-letter code determined by the
+ [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For
+ example, English documentation source is stored in `/content/en/docs/`.
- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
## Before you begin {#before-you-begin}
diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md
new file mode 100644
index 0000000000..a5c0f2880a
--- /dev/null
+++ b/content/en/docs/contribute/participate/_index.md
@@ -0,0 +1,120 @@
+---
+title: Participating in SIG Docs
+content_type: concept
+weight: 60
+card:
+ name: contribute
+ weight: 60
+---
+
+
+
+SIG Docs is one of the
+[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)
+within the Kubernetes project, focused on writing, updating, and maintaining
+the documentation for Kubernetes as a whole. See
+[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs)
+for more information about the SIG.
+
+SIG Docs welcomes content and reviews from all contributors. Anyone can open a
+pull request (PR), and anyone is welcome to file issues about content or comment
+on pull requests in progress.
+
+You can also become a [member](/docs/contribute/participate/roles-and-responsibilities/#members),
+[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers), or
+[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers).
+These roles require greater access and entail certain responsibilities for
+approving and committing changes. See
+[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
+for more information on how membership works within the Kubernetes community.
+
+The rest of this document outlines some unique ways these roles function within
+SIG Docs, which is responsible for maintaining one of the most public-facing
+aspects of Kubernetes -- the Kubernetes website and documentation.
+
+
+
+## SIG Docs chairperson
+
+Each SIG, including SIG Docs, selects one or more SIG members to act as
+chairpersons. These are points of contact between SIG Docs and other parts of
+the Kubernetes organization. They require extensive knowledge of the structure
+of the Kubernetes project as a whole and how SIG Docs works within it. See
+[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
+for the current list of chairpersons.
+
+## SIG Docs teams and automation
+
+Automation in SIG Docs relies on two different mechanisms:
+GitHub teams and OWNERS files.
+
+### GitHub teams
+
+There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub:
+
+- `@sig-docs-{language}-owners` are approvers and leads
+- `@sig-docs-{language}-reviewers` are reviewers
+
+Each can be referenced with their `@name` in GitHub comments to communicate with
+everyone in that group.
+
+Sometimes Prow and GitHub teams overlap without matching exactly. For
+assignment of issues, pull requests, and to support PR approvals, the
+automation uses information from `OWNERS` files.
+
+### OWNERS files and front-matter
+
+The Kubernetes project uses an automation tool called prow for automation
+related to GitHub issues and pull requests. The
+[Kubernetes website repository](https://github.com/kubernetes/website) uses
+two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins):
+
+- blunderbuss
+- approve
+
+These two plugins use the
+[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and
+[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
+files in the top level of the `kubernetes/website` GitHub repository to control
+how prow works within the repository.
+
+An OWNERS file contains a list of people who are SIG Docs reviewers and
+approvers. OWNERS files can also exist in subdirectories, and can override who
+can act as a reviewer or approver of files in that subdirectory and its
+descendants. For more information about OWNERS files in general, see
+[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
+
+In addition, an individual Markdown file can list reviewers and approvers in its
+front-matter, either by listing individual GitHub usernames or GitHub groups.
+
+The combination of OWNERS files and front-matter in Markdown files determines
+the advice PR owners get from automated systems about who to ask for technical
+and editorial review of their PR.
+
+## How merging works
+
+When a pull request is merged to the branch used to publish content, that content is published to http://kubernetes.io. To ensure that
+the quality of our published content is high, we limit merging pull requests to
+SIG Docs approvers. Here's how it works.
+
+- When a pull request has both the `lgtm` and `approve` labels, has no `hold`
+ labels, and all tests are passing, the pull request merges automatically.
+- Kubernetes organization members and SIG Docs approvers can add comments to
+ prevent automatic merging of a given pull request (by adding a `/hold` comment
+ or withholding a `/lgtm` comment).
+- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment.
+- Only SIG Docs approvers can merge a pull request
+ by adding an `/approve` comment. Some approvers also perform additional
+ specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or
+ [SIG Docs chairperson](#sig-docs-chairperson).
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+For more information about contributing to the Kubernetes documentation, see:
+
+- [Contributing new content](/docs/contribute/new-content/overview/)
+- [Reviewing content](/docs/contribute/review/reviewing-prs)
+- [Documentation style guide](/docs/contribute/style/)
diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md
new file mode 100644
index 0000000000..c2ab60a811
--- /dev/null
+++ b/content/en/docs/contribute/participate/pr-wranglers.md
@@ -0,0 +1,69 @@
+---
+title: PR wranglers
+content_type: concept
+weight: 20
+---
+
+
+
+SIG Docs [approvers](/docs/contribute/participating/roles-and-responsibilites/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
+
+This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/).
+
+
+
+## Duties
+
+Each day in a week-long shift as PR Wrangler:
+
+- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata.
+- Review [open pull requests](https://github.com/kubernetes/website/pulls) for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides.
+ - Start with the smallest PRs (`size/XS`) first, and end with the largest (`size/XXL`). Review as many PRs as you can.
+- Make sure PR contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
+ - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to remind contributors that haven’t signed the CLA to do so.
+- Provide feedback on changes and ask for technical reviews from members of other SIGs.
+ - Provide inline suggestions on the PR for the proposed content changes.
+ - If you need to verify content, comment on the PR and request more details.
+ - Assign relevant `sig/` label(s).
+ - If needed, assign reviewers from the `reviewers:` block in the file's front matter.
+- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready.
+ - PRs should have a `/lgtm` comment from another member before merging.
+ - Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns.
+
+### Helpful GitHub queries for wranglers
+
+The following queries are helpful when wrangling.
+After working through these queries, the remaining list of PRs to review is usually small.
+These queries exclude localization PRs. All queries are against the main branch except the last one.
+
+- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
+ Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close
+ the PR and remind them that they can open it after signing the CLA.
+ **Do not review PRs whose authors have not signed the CLA!**
+- [Needs LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
+ Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line.
+- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
+ Lists PRs that need an `/approve` comment to merge.
+- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
+- [Not against the main branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
+
+### When to close Pull Requests
+
+Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
+
+Close PRs where:
+- The author hasn't signed the CLA for two weeks.
+
+ Authors can reopen the PR after signing the CLA. This is a low-risk way to make sure nothing gets merged without a signed CLA.
+
+- The author has not responded to comments or feedback in 2 or more weeks.
+
+Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Often a closure notice is what spurs an author to resume and finish their contribution.
+
+To close a pull request, leave a `/close` comment on the PR.
+
+{{< note >}}
+
+The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity.
+
+{{< /note >}}
\ No newline at end of file
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md
new file mode 100644
index 0000000000..8ebe7a1303
--- /dev/null
+++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md
@@ -0,0 +1,237 @@
+---
+title: Roles and responsibilities
+content_type: concept
+weight: 10
+---
+
+
+
+Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow,
+you can apply for different levels of membership in the community.
+These roles allow you to take on more responsibility within the community.
+Each role requires more time and commitment. The roles are:
+
+- Anyone: regular contributors to the Kubernetes documentation
+- Members: can assign and triage issues and provide non-binding review on pull requests
+- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
+- Approvers: can lead reviews on documentation and merge changes
+
+
+
+## Anyone
+
+Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
+
+Anyone can:
+
+- Open an issue in any [Kubernetes](https://github.com/kubernetes/)
+ repository, including
+ [`kubernetes/website`](https://github.com/kubernetes/website)
+- Give non-binding feedback on a pull request
+- Contribute to a localization
+- Suggest improvements on [Slack](https://slack.k8s.io/) or the
+ [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
+
+- Open a pull request to improve existing content, add new content, or write a blog post or case study
+- Create diagrams, graphics assets, and embeddable screencasts and videos
+
+For more information, see [contributing new content](/docs/contribute/new-content/).
+
+## Members
+
+A member is someone who has submitted multiple pull requests to
+`kubernetes/website`. Members are a part of the
+[Kubernetes GitHub organization](https://github.com/kubernetes).
+
+Members can:
+
+- Do everything listed under [Anyone](#anyone)
+- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
+
+ {{< note >}}
+ Using `/lgtm` triggers automation. If you want to provide non-binding
+ approval, simply commenting "LGTM" works too!
+ {{< /note >}}
+
+- Use the `/hold` comment to block merging for a pull request
+- Use the `/assign` comment to assign a reviewer to a pull request
+- Provide non-binding review on pull requests
+- Use automation to triage and categorize issues
+- Document new features
+
+### Becoming a member
+
+After submitting at least 5 substantial pull requests and meeting the other
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
+
+1. Find two [reviewers](#reviewers) or [approvers](#approvers) to
+ [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your
+ membership.
+
+ Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
+ [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+ {{< note >}}
+ Don't send a direct email or Slack direct message to an individual
+ SIG Docs member. You must request sponsorship before submitting your application.
+ {{< /note >}}
+
+1. Open a GitHub issue in the
+ [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the
+ **Organization Membership Request** issue template.
+
+1. Let your sponsors know about the GitHub issue. You can either:
+ - Mention their GitHub username in an issue (`@`)
+ - Send them the issue link using Slack or email.
+
+ Sponsors will approve your request with a `+1` vote. Once your sponsors
+ approve the request, a Kubernetes GitHub admin adds you as a member.
+ Congratulations!
+
+ If your membership request is not accepted you will receive feedback.
+ After addressing the feedback, apply again.
+
+1. Accept the invitation to the Kubernetes GitHub organization in your email account.
+
+ {{< note >}}
+ GitHub sends the invitation to the default email address in your account.
+ {{< /note >}}
+
+## Reviewers
+
+Reviewers are responsible for reviewing open pull requests. Unlike member
+feedback, you must address reviewer feedback. Reviewers are members of the
+[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs)
+GitHub team.
+
+Reviewers can:
+
+- Do everything listed under [Anyone](#anyone) and [Members](#members)
+- Review pull requests and provide binding feedback
+
+ {{< note >}}
+ To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
+ {{< /note >}}
+
+- Edit user-facing strings in code
+- Improve code comments
+
+You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
+
+### Assigning reviewers to pull requests
+
+Automation assigns reviewers to all pull requests. You can request a
+review from a specific person by commenting: `/assign
+[@_github_handle]`.
+
+If the assigned reviewer has not commented on the PR, another reviewer can
+step in. You can also assign technical reviewers as needed.
+
+### Using `/lgtm`
+
+LGTM stands for "Looks good to me" and indicates that a pull request is
+technically accurate and ready to merge. All PRs need a `/lgtm` comment from a
+reviewer and a `/approve` comment from an approver to merge.
+
+A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
+
+### Becoming a reviewer
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer),
+you can become a SIG Docs reviewer. Reviewers in other SIGs must apply
+separately for reviewer status in SIG Docs.
+
+To apply:
+
+1. Open a pull request that adds your GitHub user name to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
+ in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
+ {{< /note >}}
+
+1. Assign the PR to one or more SIG-Docs approvers (user names listed under
+ `sig-docs-{language}-owners`).
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## Approvers
+
+Approvers review and approve pull requests for merging. Approvers are members of the
+[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs)
+GitHub teams.
+
+Approvers can do the following:
+
+- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
+- Publish contributor content by approving and merging pull requests using the `/approve` comment
+- Propose improvements to the style guide
+- Propose improvements to docs tests
+- Propose improvements to the Kubernetes website or other tooling
+
+If the PR already has a `/lgtm`, or if the approver also comments with
+`/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a
+`/lgtm` on a change that doesn't need additional technical review.
+
+
+### Approving pull requests
+
+Approvers and SIG Docs leads are the only ones who can merge pull requests
+into the website repository. This comes with certain responsibilities.
+
+- Approvers can use the `/approve` command, which merges PRs into the repo.
+
+ {{< warning >}}
+ A careless merge can break the site, so be sure that when you merge something, you mean it.
+ {{< /warning >}}
+
+- Make sure that proposed changes meet the
+ [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
+
+ If you ever have a question, or you're not sure about something, feel free
+ to call for additional review.
+
+- Verify that Netlify tests pass before you `/approve` a PR.
+
+
+
+- Visit the Netlify page preview for a PR to make sure things look good before approving.
+
+- Participate in the
+ [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+ for weekly rotations. SIG Docs expects all approvers to participate in this
+ rotation. See [PR wranglers](/docs/contribute/participate/pr-wranglers/).
+ for more details.
+
+### Becoming an approver
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
+you can become a SIG Docs approver. Approvers in other SIGs must apply
+separately for approver status in SIG Docs.
+
+To apply:
+
+1. Open a pull request adding yourself to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
+ file in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
+ {{< /note >}}
+
+2. Assign the PR to one or more current SIG Docs approvers.
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## {{% heading "whatsnext" %}}
+
+- Read about [PR wrangling](/docs/contribute/participate/pr-wranglers/), a role all approvers take on rotation.
diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md
deleted file mode 100644
index 681c53f994..0000000000
--- a/content/en/docs/contribute/participating.md
+++ /dev/null
@@ -1,316 +0,0 @@
----
-title: Participating in SIG Docs
-content_type: concept
-weight: 60
-card:
- name: contribute
- weight: 60
----
-
-
-
-SIG Docs is one of the
-[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)
-within the Kubernetes project, focused on writing, updating, and maintaining
-the documentation for Kubernetes as a whole. See
-[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs)
-for more information about the SIG.
-
-SIG Docs welcomes content and reviews from all contributors. Anyone can open a
-pull request (PR), and anyone is welcome to file issues about content or comment
-on pull requests in progress.
-
-You can also become a [member](#members),
-[reviewer](#reviewers), or [approver](#approvers). These roles require greater
-access and entail certain responsibilities for approving and committing changes.
-See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
-for more information on how membership works within the Kubernetes community.
-
-The rest of this document outlines some unique ways these roles function within
-SIG Docs, which is responsible for maintaining one of the most public-facing
-aspects of Kubernetes -- the Kubernetes website and documentation.
-
-
-
-
-
-## Roles and responsibilities
-
-- **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) and have a GitHub account.
-- **Members** of the Kubernetes organization are contributors who have spent time and effort on the Kubernetes project, usually by opening pull requests with accepted changes. See [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for membership criteria.
-- A SIG Docs **Reviewer** is a member of the Kubernetes organization who has
- expressed interest in reviewing documentation pull requests, and has been
- added to the appropriate GitHub group and `OWNERS` files in the GitHub
- repository by a SIG Docs Approver.
-- A SIG Docs **Approver** is a member in good standing who has shown a continued
- commitment to the project. An approver can merge pull requests
- and publish content on behalf of the Kubernetes organization.
- Approvers can also represent SIG Docs in the larger Kubernetes community.
- Some duties of a SIG Docs approver, such as coordinating a release,
- require a significant time commitment.
-
-## Anyone
-
-Anyone can do the following:
-
-- Open a GitHub issue against any part of Kubernetes, including documentation.
-- Provide non-binding feedback on a pull request.
-- Help to localize existing content
-- Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-- Use the `/lgtm` Prow command (short for "looks good to me") to recommend the changes in a pull request for merging.
- {{< note >}}
- If you are not a member of the Kubernetes organization, using `/lgtm` has no effect on automated systems.
- {{< /note >}}
-
-After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
-- Open a pull request to improve existing content, add new content, or write a blog post or case study.
-
-## Members
-
-Members are contributors to the Kubernetes project who meet the [membership criteria](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs welcomes contributions from all members of the Kubernetes community,
-and frequently requests reviews from members of other SIGs for technical accuracy.
-
-Any member of the [Kubernetes organization](https://github.com/kubernetes) can do the following:
-
-- Everything listed under [Anyone](#anyone)
-- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request.
-- Use the `/hold` command to prevent a pull request from being merged, if the pull request already has the LGTM and approve labels.
-- Use the `/assign` comment to assign a reviewer to a pull request.
-
-### Becoming a member
-
-After you have successfully submitted at least 5 substantive pull requests, you
-can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member)
-in the Kubernetes organization. Follow these steps:
-
-1. Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor)
- your membership.
-
- Ask for sponsorship in the [#sig-docs channel on the
- Kubernetes Slack instance](https://kubernetes.slack.com) or on the
- [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
- {{< note >}}
- Don't send a direct email or Slack direct message to an individual
- SIG Docs member.
- {{< /note >}}
-
-2. Open a GitHub issue in the `kubernetes/org` repository to request membership.
- Fill out the template using the guidelines at
- [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md).
-
-3. Let your sponsors know about the GitHub issue, either by at-mentioning them
- in the GitHub issue (adding a comment with `@`) or by sending them the link directly,
- so that they can add a `+1` vote.
-
-4. When your membership is approved, the github admin team member assigned to your request updates the
- GitHub issue to show approval and then closes the GitHub issue.
- Congratulations, you are now a member!
-
-If your membership request is not accepted, the
-membership committee provides information or steps to take before applying
-again.
-
-## Reviewers
-
-Reviewers are members of the
-[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
-GitHub group. Reviewers review documentation pull requests and provide feedback on proposed
-changes. Reviewers can:
-
-- Do everything listed under [Anyone](#anyone) and [Members](#members)
-- Document new features
-- Triage and categorize issues
-- Review pull requests and provide binding feedback
-- Create diagrams, graphics assets, and embeddable screencasts and videos
-- Edit user-facing strings in code
-- Improve code comments
-
-### Assigning reviewers to pull requests
-
-Automation assigns reviewers to all pull requests. You can request a
-review from a specific reviewer with a comment on the pull request: `/assign
-[@_github_handle]`. To indicate that a pull request is technically accurate and
-requires no further changes, a reviewer adds a `/lgtm` comment to the pull
-request.
-
-If the assigned reviewer has not yet reviewed the content, another reviewer can
-step in. In addition, you can assign technical reviewers and wait for them to
-provide a `/lgtm` comment.
-
-For a trivial change or one that needs no technical review, SIG Docs
-[approvers](#approvers) can provide the `/lgtm` as well.
-
-An `/approve` comment from a reviewer is ignored by automation.
-
-### Becoming a reviewer
-
-When you meet the
-[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer),
-you can become a SIG Docs reviewer. Reviewers in other SIGs must apply
-separately for reviewer status in SIG Docs.
-
-To apply, open a pull request to add yourself to the `reviewers` section of the
-[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS)
-in the `kubernetes/website` repository. Assign the PR to one or more current SIG
-Docs approvers.
-
-If your pull request is approved, you are now a SIG Docs reviewer.
-[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
-will assign and suggest you as a reviewer on new pull requests.
-
-If you are approved, request that a current SIG Docs approver add you to the
-[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
-GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
-add new members to a GitHub group.
-
-## Approvers
-
-Approvers are members of the
-[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
-GitHub group. See [SIG Docs teams and automation](#sig-docs-teams-and-automation) for details.
-
-Approvers can do the following:
-
-- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
-- Publish contributor content by approving and merging pull requests using the `/approve` comment.
- If someone who is not an approver leaves the approval comment, automation ignores it.
-- Participate in a Kubernetes release team as a docs representative
-- Propose improvements to the style guide
-- Propose improvements to docs tests
-- Propose improvements to the Kubernetes website or other tooling
-
-If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`,
-the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on
-a change that doesn't need additional technical review.
-
-### Becoming an approver
-
-When you meet the
-[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
-you can become a SIG Docs approver. Approvers in other SIGs must apply
-separately for approver status in SIG Docs.
-
-To apply, open a pull request to add yourself to the `approvers` section of the
-[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS)
-in the `kubernetes/website` repository. Assign the PR to one or more current SIG
-Docs approvers.
-
-If your pull request is approved, you are now a SIG Docs approver.
-[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
-will assign and suggest you as a reviewer on new pull requests.
-
-If you are approved, request that a current SIG Docs approver add you to the
-[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
-GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
-add new members to a GitHub group.
-
-### Approver responsibilities
-
-Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities:
-
-- Approvers can use the `/approve` command, which merges PRs into the repo.
-
- A careless merge can break the site, so be sure that when you merge something, you mean it.
-
-- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
-
- If you ever have a question, or you're not sure about something, feel free to call for additional review.
-
-- Verify that Netlify tests pass before you `/approve` a PR.
-
-
-
-- Visit the Netlify page preview for a PR to make sure things look good before approving.
-
-- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this
-rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
-for more details.
-
-## SIG Docs chairperson
-
-Each SIG, including SIG Docs, selects one or more SIG members to act as
-chairpersons. These are points of contact between SIG Docs and other parts of
-the Kubernetes organization. They require extensive knowledge of the structure
-of the Kubernetes project as a whole and how SIG Docs works within it. See
-[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
-for the current list of chairpersons.
-
-## SIG Docs teams and automation
-
-Automation in SIG Docs relies on two different mechanisms for automation:
-GitHub groups and OWNERS files.
-
-### GitHub groups
-
-The SIG Docs group defines two teams on GitHub:
-
- - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
- - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
-
-Each can be referenced with their `@name` in GitHub comments to communicate with
-everyone in that group.
-
-These teams overlap, but do not exactly match, the groups used by the automation
-tooling. For assignment of issues, pull requests, and to support PR approvals,
-the automation uses information from OWNERS files.
-
-### OWNERS files and front-matter
-
-The Kubernetes project uses an automation tool called prow for automation
-related to GitHub issues and pull requests. The
-[Kubernetes website repository](https://github.com/kubernetes/website) uses
-two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins):
-
-- blunderbuss
-- approve
-
-These two plugins use the
-[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and
-[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
-files in the top level of the `kubernetes/website` GitHub repository to control
-how prow works within the repository.
-
-An OWNERS file contains a list of people who are SIG Docs reviewers and
-approvers. OWNERS files can also exist in subdirectories, and can override who
-can act as a reviewer or approver of files in that subdirectory and its
-descendents. For more information about OWNERS files in general, see
-[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
-
-In addition, an individual Markdown file can list reviewers and approvers in its
-front-matter, either by listing individual GitHub usernames or GitHub groups.
-
-The combination of OWNERS files and front-matter in Markdown files determines
-the advice PR owners get from automated systems about who to ask for technical
-and editorial review of their PR.
-
-## How merging works
-
-When a pull request is merged to the branch used to publish content (currently
-`master`), that content is published and available to the world. To ensure that
-the quality of our published content is high, we limit merging pull requests to
-SIG Docs approvers. Here's how it works.
-
-- When a pull request has both the `lgtm` and `approve` labels, has no `hold`
- labels, and all tests are passing, the pull request merges automatically.
-- Kubernetes organization members and SIG Docs approvers can add comments to
- prevent automatic merging of a given pull request (by adding a `/hold` comment
- or withholding a `/lgtm` comment).
-- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment.
-- Only SIG Docs approvers can merge a pull request
- by adding an `/approve` comment. Some approvers also perform additional
- specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or
- [SIG Docs chairperson](#sig-docs-chairperson).
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-For more information about contributing to the Kubernetes documentation, see:
-
-- [Contributing new content](/docs/contribute/overview/)
-- [Reviewing content](/docs/contribute/review/reviewing-prs)
-- [Documentation style guide](/docs/contribute/style/)
-
-
diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md
index 0cddbcba6a..82a05bdb86 100644
--- a/content/en/docs/contribute/review/for-approvers.md
+++ b/content/en/docs/contribute/review/for-approvers.md
@@ -8,7 +8,9 @@ weight: 20
-SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
+SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and
+[Approvers](/docs/contribute/participate/#approvers) do a few extra things
+when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
@@ -19,9 +21,6 @@ requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
-
-
-
## Reviewing a PR
@@ -202,9 +201,9 @@ Sample response to a request for support:
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
-[Kubernetes slack](http://slack.k8s.io/). You can also search
+[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
-[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md
index 3c271aa44f..ff6ef9d709 100644
--- a/content/en/docs/contribute/review/reviewing-prs.md
+++ b/content/en/docs/contribute/review/reviewing-prs.md
@@ -16,10 +16,10 @@ It helps you learn the code base and build trust with other contributors.
Before reviewing, it's a good idea to:
- Read the [content guide](/docs/contribute/style/content-guide/) and
-[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
-
-
+ [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Understand the different
+ [roles and responsibilities](/docs/contribute/participate/roles-and-responsibilities/)
+ in the Kubernetes documentation community.
diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md
index 2f367c9a81..0de4a381a3 100644
--- a/content/en/docs/contribute/style/content-guide.md
+++ b/content/en/docs/contribute/style/content-guide.md
@@ -9,10 +9,10 @@ weight: 10
This page contains guidelines for Kubernetes documentation.
-If you have questions about what's allowed, join the #sig-docs channel in
-[Kubernetes Slack](http://slack.k8s.io/) and ask!
+If you have questions about what's allowed, join the #sig-docs channel in
+[Kubernetes Slack](https://slack.k8s.io/) and ask!
-You can register for Kubernetes Slack at http://slack.k8s.io/.
+You can register for Kubernetes Slack at https://slack.k8s.io/.
For information on creating new content for the Kubernetes
docs, follow the [style guide](/docs/contribute/style/style-guide).
@@ -28,7 +28,7 @@ Source for the Kubernetes website, including the docs, resides in the
Located in the `kubernetes/website/content//docs` folder, the
majority of Kubernetes documentation is specific to the [Kubernetes
-project](https://github.com/kubernetes/kubernetes).
+project](https://github.com/kubernetes/kubernetes).
## What's allowed
@@ -41,12 +41,12 @@ Kubernetes docs allow content for third-party projects only when:
### Third party content
Kubernetes documentation includes applied examples of projects in the Kubernetes project—projects that live in the [kubernetes](https://github.com/kubernetes) and
-[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations.
+[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations.
-Links to active content in the Kubernetes project are always allowed.
+Links to active content in the Kubernetes project are always allowed.
-Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker),
-[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), and [logging](https://kubernetes.io/docs/concepts/cluster-administration/logging/).
+Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker),
+[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/), and [logging](/docs/concepts/cluster-administration/logging/).
Docs can link to third-party open source software (OSS) outside the Kubernetes project only if it's necessary for Kubernetes to function.
@@ -60,14 +60,14 @@ and grows stale more quickly.
{{< note >}}
-If you're a maintainer for a Kubernetes project and need help hosting your own docs,
+If you're a maintainer for a Kubernetes project and need help hosting your own docs,
ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/).
{{< /note >}}
### More information
-If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
+If you have questions about allowed content, join the [Kubernetes Slack](https://slack.k8s.io/) #sig-docs channel and ask!
@@ -75,5 +75,3 @@ If you have questions about allowed content, join the [Kubernetes Slack](http://
* Read the [Style guide](/docs/contribute/style/style-guide).
-
-
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md
index 12d00ae01a..ab949be7fc 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/index.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md
@@ -232,7 +232,7 @@ Renders to:
{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
-{{< tab name="JSON File" include="podtemplate" />}}
+{{< tab name="JSON File" include="podtemplate.json" />}}
{{< /tabs >}}
@@ -240,8 +240,8 @@ Renders to:
## {{% heading "whatsnext" %}}
* Learn about [Hugo](https://gohugo.io/).
-* Learn about [writing a new topic](/docs/home/contribute/style/write-new-topic/).
-* Learn about [page content types](/docs/home/contribute/style/page-content-types/).
-* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/)
-* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
+* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
+* Learn about [page content types](/docs/contribute/style/page-content-types/).
+* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/).
+* Learn about [advanced contributing](/docs/contribute/advanced/).
diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md
index 2a3325d397..5d3b519bc0 100644
--- a/content/en/docs/contribute/style/page-content-types.md
+++ b/content/en/docs/contribute/style/page-content-types.md
@@ -191,7 +191,7 @@ Within each section, write your content. Use the following guidelines:
interested in reading next.
An example of a published tutorial topic is
-[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
+[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
### Reference
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 78ddd4a787..44653708ec 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -22,8 +22,11 @@ discussion.
{{< note >}}
-Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
-and representing feature state.
+Kubernetes documentation uses
+[Goldmark Markdown Renderer](https://github.com/yuin/goldmark)
+with some adjustments along with a few
+[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support
+glossary entries, tabs, and representing feature state.
{{< /note >}}
## Language
@@ -121,7 +124,7 @@ document, use the backtick (`` ` ``).
{{< table caption = "Do and Don't - Use code style for inline code and commands" >}}
Do | Don't
:--| :-----
-The `kubectl run`command creates a Deployment. | The "kubectl run" command creates a Deployment.
+The `kubectl run`command creates a Pod. | The "kubectl run" command creates a Pod.
For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply".
Enclose code samples with triple backticks. (\`\`\`)| Enclose code samples with any other syntax.
Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**.
@@ -496,7 +499,7 @@ Do | Don't
:--| :-----
You can explore the API using a browser. | The API can be explored using a browser.
The YAML file specifies the replica count. | The replica count is specified in the YAML file.
-{{< /table >}}
+{{< /table >}}
Exception: Use passive voice if active voice leads to an awkward construction.
@@ -511,7 +514,7 @@ Do | Don't
To create a ReplicaSet, ... | In order to create a ReplicaSet, ...
See the configuration file. | Please see the configuration file.
View the Pods. | With this next command, we'll view the Pods.
-{{< /table >}}
+{{< /table >}}
### Address the reader as "you"
@@ -520,7 +523,7 @@ Do | Don't
:--| :-----
You can create a Deployment by ... | We'll create a Deployment by ...
In the preceding output, you can see... | In the preceding output, we can see ...
-{{< /table >}}
+{{< /table >}}
### Avoid Latin phrases
@@ -532,7 +535,7 @@ Do | Don't
:--| :-----
For example, ... | e.g., ...
That is, ...| i.e., ...
-{{< /table >}}
+{{< /table >}}
Exception: Use "etc." for et cetera.
@@ -550,7 +553,7 @@ Do | Don't
Version 1.4 includes ... | In version 1.4, we have added ...
Kubernetes provides a new feature for ... | We provide a new feature ...
This page teaches you how to use Pods. | In this page, we are going to learn about Pods.
-{{< /table >}}
+{{< /table >}}
### Avoid jargon and idioms
@@ -562,7 +565,7 @@ Do | Don't
:--| :-----
Internally, ... | Under the hood, ...
Create a new cluster. | Turn up a new cluster.
-{{< /table >}}
+{{< /table >}}
### Avoid statements about the future
@@ -581,15 +584,11 @@ Do | Don't
:--| :-----
In version 1.4, ... | In the current version, ...
The Federation feature provides ... | The new Federation feature provides ...
-{{< /table >}}
-
-
+{{< /table >}}
## {{% heading "whatsnext" %}}
-
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
* Learn about [using page templates](/docs/contribute/style/page-content-types/).
-* Learn about [staging your changes](/docs/contribute/stage-documentation-changes/)
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 8bd4b8fbe2..7cac1aa6b7 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -11,7 +11,7 @@ This page shows how to create a new topic for the Kubernetes docs.
## {{% heading "prerequisites" %}}
Create a fork of the Kubernetes documentation repository as described in
-[Open a PR](/docs/new-content/open-a-pr/).
+[Open a PR](/docs/contribute/new-content/open-a-pr/).
@@ -28,9 +28,17 @@ Task | A task page shows how to do a single thing. The idea is to give readers a
Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.
{{< /table >}}
+### Creating a new page
+
Use a [content type](/docs/contribute/style/page-content-types/) for each new page
-that you write. Using page type helps ensure
-consistency among topics of a given type.
+that you write. The docs site provides templates or
+[Hugo archetypes](https://gohugo.io/content-management/archetypes/) to create
+new content pages. To create a new type of page, run `hugo new` with the path to the file
+you want to create. For example:
+
+```
+hugo new docs/concepts/my-first-concept.md
+```
## Choosing a title and filename
@@ -152,7 +160,7 @@ submitted to ensure all examples pass the tests.
{{< /note >}}
For an example of a topic that uses this technique, see
-[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/).
+[Running a Single-Instance Stateful Application](/docs/tasks/run-application/run-single-instance-stateful-application/).
## Adding images to a topic
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index e0f5ea0f43..7e1f8ced66 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -99,7 +99,9 @@ NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority
## What does each admission controller do?
-### AlwaysAdmit {#alwaysadmit} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### AlwaysAdmit {#alwaysadmit}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller allows all pods into the cluster. It is deprecated because its behavior is the same as if there were no admission controller at all.
@@ -113,7 +115,9 @@ scheduled onto the right node), without any authorization check against the imag
is enabled, images are always pulled prior to starting containers, which means valid credentials are
required.
-### AlwaysDeny {#alwaysdeny} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### AlwaysDeny {#alwaysdeny}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning.
@@ -164,7 +168,9 @@ if the pods don't already have toleration for taints
`node.kubernetes.io/not-ready:NoExecute` or
`node.alpha.kubernetes.io/unreachable:NoExecute`.
-### DenyExecOnPrivileged {#denyexeconprivileged} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### DenyExecOnPrivileged {#denyexeconprivileged}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container.
@@ -175,7 +181,9 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol
which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
is recommended instead.
-### DenyEscalatingExec {#denyescalatingexec} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### DenyEscalatingExec {#denyescalatingexec}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller will deny exec and attach commands to pods that run with escalated privileges that
allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and
@@ -187,7 +195,9 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol
which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
is recommended instead.
-### EventRateLimit {#eventratelimit} {{< feature-state for_k8s_version="v1.13" state="alpha" >}}
+### EventRateLimit {#eventratelimit}
+
+{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
This admission controller mitigates the problem where the API server gets flooded by
event requests. The cluster admin can specify event rate limits by:
@@ -446,7 +456,9 @@ applies a 0.1 CPU requirement to all Pods in the `default` namespace.
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
-### MutatingAdmissionWebhook {#mutatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}}
+### MutatingAdmissionWebhook {#mutatingadmissionwebhook}
+
+{{< feature-state for_k8s_version="v1.13" state="beta" >}}
This admission controller calls any mutating webhooks which match the request. Matching
webhooks are called in serial; each one may modify the object if it desires.
@@ -537,7 +549,9 @@ This admission controller also protects the access to `metadata.ownerReferences[
of an object, so that only users with "update" permission to the `finalizers`
subresource of the referenced *owner* can change it.
-### PersistentVolumeLabel {#persistentvolumelabel} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### PersistentVolumeLabel {#persistentvolumelabel}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller automatically attaches region or zone labels to PersistentVolumes
as defined by the cloud provider (for example, GCE or AWS).
@@ -663,9 +677,6 @@ for more information.
This admission controller acts on creation and modification of the pod and determines if it should be admitted
based on the requested security context and the available Pod Security Policies.
-For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
-extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
-
See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
for more information.
@@ -692,8 +703,8 @@ kind: Namespace
metadata:
name: apps-that-need-nodes-exclusively
annotations:
- scheduler.alpha.kubernetes.io/defaultTolerations: '{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}'
- scheduler.alpha.kubernetes.io/tolerationsWhitelist: '{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}'
+ scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
+ scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
```
### Priority {#priority}
@@ -708,7 +719,9 @@ objects in your Kubernetes deployment, you MUST use this admission controller to
See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
-### RuntimeClass {#runtimeclass} {{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+### RuntimeClass {#runtimeclass}
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
For [RuntimeClass](/docs/concepts/containers/runtime-class/) definitions which describe an overhead associated with running a pod,
this admission controller will set the pod.Spec.Overhead field accordingly.
@@ -729,11 +742,15 @@ We strongly recommend using this admission controller if you intend to make use
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
-### TaintNodesByCondition {#taintnodesbycondition} {{< feature-state for_k8s_version="v1.12" state="beta" >}}
+### TaintNodesByCondition {#taintnodesbycondition}
+
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions.
-### ValidatingAdmissionWebhook {#validatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}}
+### ValidatingAdmissionWebhook {#validatingadmissionwebhook}
+
+{{< feature-state for_k8s_version="v1.13" state="beta" >}}
This admission controller calls any validating webhooks which match the request. Matching
webhooks are called in parallel; if any of them rejects the request, the request
@@ -774,5 +791,3 @@ in the mutating phase.
For earlier versions, there was no concept of validating versus mutating and the
admission controllers ran in the exact order specified.
-
-
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index 8cb8013c76..973c605127 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -26,6 +26,8 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes
does not have objects which represent normal user accounts._ Normal users
cannot be added to a cluster through an API call.
+Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
+
In contrast, service accounts are users managed by the Kubernetes API. They are
bound to specific namespaces, and created automatically by the API server or
manually through API calls. Service accounts are tied to a set of credentials
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 fea62e545e..f208bfb770 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
@@ -48,7 +48,7 @@ The CertificateSigningRequest `status.certificate` field is empty until the sign
Once the `status.certificate` field has been populated, the request has been completed and clients can now
fetch the signed certificate PEM data from the CertificateSigningRequest resource.
-Signers can instead deny certificate signing if the approval conditions are not met.
+The signers can instead deny certificate signing if the approval conditions are not met.
In order to reduce the number of old CertificateSigningRequest resources left in a cluster, a garbage collection
controller runs periodically. The garbage collection removes CertificateSigningRequests that have not changed
@@ -67,10 +67,10 @@ This includes:
1. **Permitted subjects**: any restrictions on and behavior when a disallowed subject is requested.
1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested.
1. **Permitted key usages / extended key usages**: any restrictions on and behavior when usages different than the signer-determined usages are specified in the CSR.
-1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and behavior if an expiration different than the signer-determined expiration is specified in the CSR.
+1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and the behavior when an expiration is different than the signer-determined expiration that is specified in the CSR.
1. **CA bit allowed/disallowed**: and behavior if a CSR contains a request a for a CA certificate when the signer does not permit it.
-Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be certificate plus intermediates to be presented during TLS handshakes.
+Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be the certificate plus intermediates to be presented during TLS handshakes.
### Kubernetes signers
@@ -88,19 +88,18 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
1. `kubernetes.io/kube-apiserver-client-kubelet`: signs client certificates that will be honored as client-certs by the
kube-apiserver.
May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
- 1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle
+ 1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle
is not distributed by any other means.
1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
- 1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions, drops other extensions.
+ 1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions.
1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "client auth"}`
- 1. Expiration/certificate lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer.
+ 1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
1. CA bit allowed/disallowed - not allowed.
1. `kubernetes.io/kubelet-serving`: signs serving certificates that are honored as a valid kubelet serving certificate
by the kube-apiserver, but has no other guarantees.
Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
- 1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet.
- The CA bundle is not distributed by any other means.
+ 1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. The CA bundle is not distributed by any other means.
1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "server auth"}`
@@ -108,13 +107,13 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
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.
+ certs, but that behavior is non-standard Kubernetes behavior.
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
1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
1. Permitted key usages - any
- 1. Expiration/certificate lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer.
+ 1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
1. CA bit allowed/disallowed - not allowed.
{{< note >}}
@@ -226,6 +225,101 @@ rules:
- sign
```
+## 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.
+
+### Create Private Key
+
+The following scripts show how to generate PKI private key and CSR. It is important to set CN and O attribute of the CSR. CN is the name of the user and O is the group that this user will belong to. You can refer to [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
+
+```
+openssl genrsa -out john.key 2048
+openssl req -new -key john.key -out john.csr
+```
+
+### Create Certificate Request Kubernetes Object
+
+Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
+
+```
+cat <
Kubernetes RBAC API discovery roles
-
+
+
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:basic-user
system:authenticated group
@@ -627,6 +630,7 @@ either do not manually edit the role, or disable auto-reconciliation.
system:authenticated and system:unauthenticated groups
Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.
@@ -691,17 +698,21 @@ the contents of Secrets enables access to ServiceAccount credentials
in the namespace, which would allow API access as any ServiceAccount
in the namespace (a form of privilege escalation).
+
### Core component roles
-
+
+
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:kube-scheduler
system:kube-scheduler user
@@ -733,17 +744,21 @@ The system:node role only exists for compatibility with Kubernetes clus
system:kube-proxy user
Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
+
### Other component roles
-
+
+
Default ClusterRole
Default ClusterRoleBinding
Description
+
+
system:auth-delegator
None
@@ -786,6 +801,7 @@ This is commonly used by add-on API servers for unified authentication and autho
### Roles for built-in controllers {#controller-roles}
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
index 78784eace7..9fc130f157 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@@ -129,12 +129,14 @@ different Kubernetes components.
| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
| `RuntimeClass` | `true` | Beta | 1.14 | |
| `SCTPSupport` | `false` | Alpha | 1.12 | |
-| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
| `ServerSideApply` | `true` | Beta | 1.16 | |
+| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
+| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
| `ServiceTopology` | `false` | Alpha | 1.17 | |
-| `StartupProbe` | `false` | Alpha | 1.16 | |
+| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
+| `StartupProbe` | `true` | Beta | 1.18 | |
| `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | Beta | 1.15 | |
| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
@@ -432,7 +434,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
- `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint.
- See [Support Device Monitoring](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md) for more details.
+ See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md) for more details.
- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels.
- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
@@ -472,11 +474,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `ScheduleDaemonSetPods`: Enable DaemonSet Pods to be scheduled by the default scheduler instead of the DaemonSet controller.
- `SCTPSupport`: Enables the usage of SCTP as `protocol` value in `Service`, `Endpoint`, `NetworkPolicy` and `Pod` definitions
- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server.
+- `ServiceAccountIssuerDiscovery`: Enable OIDC discovery endpoints (issuer and JWKS URLs) for the service account issuer in the API server. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) for more details.
- `ServiceAppProtocol`: Enables the `AppProtocol` field on Services and Endpoints.
- `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
- `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider.
A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key or `node.kubernetes.io/exclude-from-external-load-balancers`.
-- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](https://kubernetes.io/docs/concepts/services-networking/service-topology/) for more details.
+- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](/docs/concepts/services-networking/service-topology/) for more details.
- `StartupProbe`: Enable the [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) probe in the kubelet.
- `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
PersistentVolumeClaim objects if they are still being used.
@@ -516,4 +519,3 @@ Each feature gate is designed for enabling/disabling a specific feature:
* The [deprecation policy](/docs/reference/using-api/deprecation-policy/) for Kubernetes explains
the project's approach to removing features and components.
-
diff --git a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
index d510610140..4a788b1ab9 100644
--- a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
+++ b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
@@ -14,7 +14,7 @@ and capacity. The scheduler needs to take into account individual and collective
resource requirements, quality of service requirements, hardware/software/policy
constraints, affinity and anti-affinity specifications, data locality, inter-workload
interference, deadlines, and so on. Workload-specific requirements will be exposed
-through the API as necessary. See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/)
+through the API as necessary. See [scheduling](/docs/concepts/scheduling-eviction/)
for more information about scheduling and the kube-scheduler component.
```
@@ -511,8 +511,3 @@ kube-scheduler [flags]
-
-
-
-
-
diff --git a/content/en/docs/reference/glossary/endpoint.md b/content/en/docs/reference/glossary/endpoint.md
new file mode 100644
index 0000000000..3934faa18a
--- /dev/null
+++ b/content/en/docs/reference/glossary/endpoint.md
@@ -0,0 +1,17 @@
+---
+title: Endpoints
+id: endpoints
+date: 2020-04-23
+full_link:
+short_description: >
+ Endpoints track the IP addresses of Pods with matching Service selectors.
+
+aka:
+tags:
+- networking
+---
+ Endpoints track the IP addresses of Pods with matching {{< glossary_tooltip text="selectors" term_id="selector" >}}.
+
+
+Endpoints can be configured manually for {{< glossary_tooltip text="Services" term_id="service" >}} without selectors specified.
+The {{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} resource provides a scalable and extensible alternative to Endpoints.
diff --git a/content/en/docs/reference/glossary/pod.md b/content/en/docs/reference/glossary/pod.md
index f14393072c..b551dead19 100755
--- a/content/en/docs/reference/glossary/pod.md
+++ b/content/en/docs/reference/glossary/pod.md
@@ -2,7 +2,7 @@
title: Pod
id: pod
date: 2018-04-12
-full_link: /docs/concepts/workloads/pods/pod-overview/
+full_link: /docs/concepts/workloads/pods/
short_description: >
A Pod represents a set of running containers in your cluster.
diff --git a/content/en/docs/reference/glossary/volume.md b/content/en/docs/reference/glossary/volume.md
index 2076378bb3..22cebca917 100755
--- a/content/en/docs/reference/glossary/volume.md
+++ b/content/en/docs/reference/glossary/volume.md
@@ -6,15 +6,15 @@ full_link: /docs/concepts/storage/volumes/
short_description: >
A directory containing data, accessible to the containers in a pod.
-aka:
+aka:
tags:
- core-object
- fundamental
---
A directory containing data, accessible to the {{< glossary_tooltip text="containers" term_id="container" >}} in a {{< glossary_tooltip term_id="pod" >}}.
-
+
A Kubernetes volume lives as long as the Pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data in the volume is preserved across container restarts.
-See [storage](https://kubernetes.io/docs/concepts/storage/) for more information.
+See [storage](/docs/concepts/storage/) for more information.
diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md
index b9b1ce7c37..2d16e37662 100644
--- a/content/en/docs/reference/issues-security/security.md
+++ b/content/en/docs/reference/issues-security/security.md
@@ -19,7 +19,7 @@ This page describes Kubernetes security and disclosure information.
Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements.
-You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50).
+You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50).
## Report a Vulnerability
diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md
index 23d074456c..dda75574a9 100644
--- a/content/en/docs/reference/kubectl/cheatsheet.md
+++ b/content/en/docs/reference/kubectl/cheatsheet.md
@@ -166,6 +166,10 @@ kubectl get pv --sort-by=.spec.capacity.storage
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'
+# Retrieve the value of a key with dots, e.g. 'ca.crt'
+kubectl get configmap myconfig \
+ -o jsonpath='{.data.ca\.crt}'
+
# Get all worker nodes (use a selector to exclude results that have a label
# named 'node-role.kubernetes.io/master')
kubectl get node --selector='!node-role.kubernetes.io/master'
@@ -290,10 +294,10 @@ kubectl logs -f my-pod # stream pod logs (stdout)
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
-kubectl run nginx --image=nginx --restart=Never -n
+kubectl run nginx --image=nginx -n
mynamespace # Run pod nginx in a specific namespace
-kubectl run nginx --image=nginx --restart=Never # Run pod nginx and write its spec into a file called pod.yaml
---dry-run -o yaml > pod.yaml
+kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
+--dry-run=client -o yaml > pod.yaml
kubectl attach my-pod -i # Attach to Running Container
kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
index 790ceea4df..b9c5bf9af1 100644
--- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
+++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
@@ -73,9 +73,6 @@ kubectl run [-i] [--tty] --attach --image=
Unlike `docker run ...`, if you specify `--attach`, then you attach `stdin`, `stdout` and `stderr`. You cannot control which streams are attached (`docker -a ...`).
To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q.
-Because the kubectl run command starts a Deployment for the container, the Deployment restarts if you terminate the attached process by using Ctrl+C, unlike `docker run -it`.
-To destroy the Deployment and its pods you need to run `kubectl delete deployment `.
-
## docker ps
To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get).
@@ -188,7 +185,7 @@ docker exec -ti 55c103fa1296 /bin/sh
kubectl:
```shell
-kubectl exec -ti nginx-app-5jyvm -- /bin/sh
+kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit
```
diff --git a/content/en/docs/reference/scheduling/profiles.md b/content/en/docs/reference/scheduling/profiles.md
index fe28d10bd1..3cb4eb71b3 100644
--- a/content/en/docs/reference/scheduling/profiles.md
+++ b/content/en/docs/reference/scheduling/profiles.md
@@ -91,7 +91,7 @@ extension points:
- `NodeResourcesFit`: Checks if the node has all the resources that the Pod is
requesting.
Extension points: `PreFilter`, `Filter`.
-- `NodeResourcesBallancedAllocation`: Favors nodes that would obtain a more
+- `NodeResourcesBalancedAllocation`: Favors nodes that would obtain a more
balanced resource usage if the Pod is scheduled there.
Extension points: `Score`.
- `NodeResourcesLeastAllocated`: Favors nodes that have a low allocation of
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
index abceaf5f70..d83fb98436 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
@@ -59,7 +59,7 @@ kubeadm join phase kubelet-start --help
```
Similar to the [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)
-command, `kubadm join phase` allows you to skip a list of phases using the `--skip-phases` flag.
+command, `kubeadm join phase` allows you to skip a list of phases using the `--skip-phases` flag.
For example:
diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md
index f83c43c00f..f2109071a1 100644
--- a/content/en/docs/reference/using-api/api-concepts.md
+++ b/content/en/docs/reference/using-api/api-concepts.md
@@ -706,9 +706,9 @@ Resource versions are strings that identify the server's internal version of an
Clients find resource versions in resources, including the resources in watch events, and list responses returned from the server:
-[v1.meta/ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at.
+[v1.meta/ObjectMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at.
-[v1.meta/ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed.
+[v1.meta/ListMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed.
### The ResourceVersion Parameter
@@ -726,11 +726,11 @@ For get and list, the semantics of resource version are:
**List:**
-| paging | resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" |
-|-------------------------------|-----------------------|------------------------------------------------|----------------------------------------|
-| limit unset | Most Recent | Any | Not older than |
-| limit="n", continue unset | Most Recent | Any | Exact |
-| limit="n", continue="" | Continue Token, Exact | Invalid, but treated as Continue Token, Exact | Invalid, HTTP `400 Bad Request` |
+| paging | resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" |
+|---------------------------------|-----------------------|------------------------------------------------|----------------------------------------|
+| limit unset | Most Recent | Any | Not older than |
+| limit="n", continue unset | Most Recent | Any | Exact |
+| limit="n", continue="\" | Continue Token, Exact | Invalid, but treated as Continue Token, Exact | Invalid, HTTP `400 Bad Request` |
The meaning of the get and list semantics are:
diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md
index 25b7d46af9..c0adee3bdb 100644
--- a/content/en/docs/reference/using-api/api-overview.md
+++ b/content/en/docs/reference/using-api/api-overview.md
@@ -33,7 +33,7 @@ if you are writing an application using the Kubernetes API.
To eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path. For example: `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
The version is set at the API level rather than at the resource or field level to:
@@ -106,10 +106,3 @@ When you enable or disable groups or resources, you need to restart the apiserve
to pick up the `--runtime-config` changes.
{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md
new file mode 100644
index 0000000000..a7be3b267f
--- /dev/null
+++ b/content/en/docs/reference/using-api/health-checks.md
@@ -0,0 +1,103 @@
+---
+title: Kubernetes API health endpoints
+reviewers:
+- logicalhan
+content_type: concept
+weight: 50
+---
+
+
+The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server.
+This page describes these API endpoints and explains how you can use them.
+
+
+
+## API endpoints for health
+
+The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server.
+The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead.
+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.
+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.
+
+For all endpoints you can use the `verbose` parameter to print out the checks and their status.
+This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
+
+ ```shell
+ curl -k https://localhost:6443/livez?verbose
+ ```
+
+or from a remote host with authentication:
+
+ ```shell
+ kubectl get --raw='/readyz?verbose'
+ ```
+
+The output will look like this:
+
+ [+]ping ok
+ [+]log ok
+ [+]etcd ok
+ [+]poststarthook/start-kube-apiserver-admission-initializer ok
+ [+]poststarthook/generic-apiserver-start-informers ok
+ [+]poststarthook/start-apiextensions-informers ok
+ [+]poststarthook/start-apiextensions-controllers ok
+ [+]poststarthook/crd-informer-synced ok
+ [+]poststarthook/bootstrap-controller ok
+ [+]poststarthook/rbac/bootstrap-roles ok
+ [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+ [+]poststarthook/start-cluster-authentication-info-controller ok
+ [+]poststarthook/start-kube-aggregator-informers ok
+ [+]poststarthook/apiservice-registration-controller ok
+ [+]poststarthook/apiservice-status-available-controller ok
+ [+]poststarthook/kube-apiserver-autoregistration ok
+ [+]autoregister-completion ok
+ [+]poststarthook/apiservice-openapi-controller ok
+ healthz check passed
+
+The Kubernetes API server also supports to exclude specific checks.
+The query parameters can also be combined like in this example:
+
+ ```shell
+ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+ ```
+
+The output show that the `etcd` check is excluded:
+
+ [+]ping ok
+ [+]log ok
+ [+]etcd excluded: ok
+ [+]poststarthook/start-kube-apiserver-admission-initializer ok
+ [+]poststarthook/generic-apiserver-start-informers ok
+ [+]poststarthook/start-apiextensions-informers ok
+ [+]poststarthook/start-apiextensions-controllers ok
+ [+]poststarthook/crd-informer-synced ok
+ [+]poststarthook/bootstrap-controller ok
+ [+]poststarthook/rbac/bootstrap-roles ok
+ [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+ [+]poststarthook/start-cluster-authentication-info-controller ok
+ [+]poststarthook/start-kube-aggregator-informers ok
+ [+]poststarthook/apiservice-registration-controller ok
+ [+]poststarthook/apiservice-status-available-controller ok
+ [+]poststarthook/kube-apiserver-autoregistration ok
+ [+]autoregister-completion ok
+ [+]poststarthook/apiservice-openapi-controller ok
+ [+]shutdown ok
+ healthz check passed
+
+## Individual health checks
+
+{{< feature-state state="alpha" >}}
+
+Each individual health check exposes an http endpoint and could can be checked individually.
+The schema for the individual health checks is `/livez/` where `livez` and `readyz` and be used to indicate if you want to check thee liveness or the readiness of the API server.
+The `` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
+These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
+
+ ```shell
+ curl -k https://localhost:6443/livez/etcd
+ ```
diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md
index 91b734953c..59db384258 100644
--- a/content/en/docs/setup/_index.md
+++ b/content/en/docs/setup/_index.md
@@ -20,35 +20,20 @@ card:
-This section covers different options to set up and run Kubernetes.
-
-Different Kubernetes solutions meet different requirements: ease of maintenance, security, control, available resources, and expertise required to operate and manage a cluster.
-
-You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. You can also create custom solutions across a wide range of cloud providers, or bare metal environments.
-
-More simply, you can create a Kubernetes cluster in learning and production environments.
-
+This section lists the different ways to set up and run Kubernetes.
+When you install Kubernetes, choose an installation type based on: ease of maintenance, security,
+control, available resources, and expertise required to operate and manage a cluster.
+You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. There are also custom solutions across a wide range of cloud providers, or bare metal environments.
## Learning environment
-If you're learning Kubernetes, use the Docker-based solutions: tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine.
-
-{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}}
-
-|Community |Ecosystem |
-| ------------ | -------- |
-| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
-| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)|
-| | [MicroK8s](https://microk8s.io/)|
-
+If you're learning Kubernetes, use the tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine.
## Production environment
When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider.
[Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers.
-
-
diff --git a/content/en/docs/setup/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md
index a85d44e0f4..9e27b40943 100644
--- a/content/en/docs/setup/best-practices/certificates.md
+++ b/content/en/docs/setup/best-practices/certificates.md
@@ -28,7 +28,7 @@ Kubernetes requires PKI for the following operations:
* Client certificate for the API server to talk to etcd
* Client certificate/kubeconfig for the controller manager to talk to the API server
* Client certificate/kubeconfig for the scheduler to talk to the API server.
-* Client and server certificates for the [front-proxy][proxy]
+* Client and server certificates for the [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
{{< note >}}
`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/).
@@ -54,7 +54,7 @@ Required CAs:
|------------------------|---------------------------|----------------------------------|
| ca.crt,key | kubernetes-ca | Kubernetes general CA |
| etcd/ca.crt,key | etcd-ca | For all etcd-related functions |
-| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy][proxy] |
+| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) |
On top of the above CAs, it is also necessary to get a public/private key pair for service account management, `sa.key` and `sa.pub`.
@@ -74,10 +74,11 @@ Required certificates:
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
-[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm][kubeadm] the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
+[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)
+the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
-where `kind` maps to one or more of the [x509 key usage][usage] types:
+where `kind` maps to one or more of the [x509 key usage](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) types:
| kind | Key usage |
|--------|---------------------------------------------------------------------------------|
@@ -99,7 +100,8 @@ For kubeadm users only:
### Certificate paths
-Certificates should be placed in a recommended path (as used by [kubeadm][kubeadm]). Paths should be specified using the given argument regardless of location.
+Certificates should be placed in a recommended path (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)).
+Paths should be specified using the given argument regardless of location.
| Default CN | recommended key path | recommended cert path | command | key argument | cert argument |
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
@@ -160,8 +162,4 @@ These files are used as follows:
| controller-manager.conf | kube-controller-manager | Must be added to manifest in `manifests/kube-controller-manager.yaml` |
| scheduler.conf | kube-scheduler | Must be added to manifest in `manifests/kube-scheduler.yaml` |
-[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
-[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
-[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/
-
diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md
index c8692c8872..2b8f7b487f 100644
--- a/content/en/docs/setup/best-practices/cluster-large.md
+++ b/content/en/docs/setup/best-practices/cluster-large.md
@@ -20,7 +20,7 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes.
A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).
-Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
+Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.
@@ -80,7 +80,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c
### Addon Resources
-To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
+To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)).
For example:
@@ -94,28 +94,26 @@ For example:
memory: 200Mi
```
-Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
+Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
* Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
- * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
- * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
- * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+ * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+ * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+ * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
* Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
- * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+ * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
* Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
- * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
- * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+ * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+ * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
-For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
-
-In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
-We welcome PRs that implement those features.
+For directions on how to detect if addon containers are hitting resource limits, see the
+[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).
### Allowing minor node failure at startup
@@ -126,3 +124,4 @@ running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to wh
with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the
reason for the failure, those additional nodes may join later or the cluster may remain at a size of
`NUM_NODES - ALLOWED_NOTREADY_NODES`.
+
diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md
index ab61c839a9..7c2622641b 100644
--- a/content/en/docs/setup/best-practices/multiple-zones.md
+++ b/content/en/docs/setup/best-practices/multiple-zones.md
@@ -78,7 +78,7 @@ federation support).
a single master node by default. While services are highly
available and can tolerate the loss of a zone, the control plane is
located in a single zone. Users that want a highly available control
-plane should follow the [high availability](/docs/admin/high-availability) instructions.
+plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
### Volume limitations
The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md
index a794141f2d..009be9adc8 100644
--- a/content/en/docs/setup/learning-environment/minikube.md
+++ b/content/en/docs/setup/learning-environment/minikube.md
@@ -198,7 +198,7 @@ This brief demo guides you on how to start, use, and delete Minikube locally. Fo
The `minikube start` command can be used to start your cluster.
This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
-This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster.
+This command also configures your [kubectl](/docs/reference/kubectl/overview/) installation to communicate with this cluster.
{{< note >}}
If you are behind a web proxy, you need to pass this information to the `minikube start` command:
@@ -514,6 +514,6 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu
## Community
-Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
+Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the `#minikube` channel (get an invitation [here](https://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index 575ac4ba5e..77e7bb577a 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -374,16 +374,19 @@ systemctl restart containerd
## Set up the repository
### Install required packages
yum install -y yum-utils device-mapper-persistent-data lvm2
+```
```shell
## Add docker repository
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
+```
```shell
## Install containerd
yum update -y && yum install -y containerd.io
+```
```shell
## Configure containerd
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
index 1f7d1fd81f..c440f14b31 100644
--- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
+++ b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
@@ -9,12 +9,10 @@ content_type: concept
[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
-[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
+[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
-
-
## Prerequisites
@@ -112,10 +110,7 @@ e9af8293... role=node
## Support Level
-
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
-
-
diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md
index 338dbee0e5..8394c28faf 100644
--- a/content/en/docs/setup/production-environment/tools/kops.md
+++ b/content/en/docs/setup/production-environment/tools/kops.md
@@ -27,7 +27,7 @@ kops is an automated provisioning system:
* You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.
-* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them.
+* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user).
@@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde
but not under `example.com`).
Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using
-the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
+the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here,
@@ -231,9 +231,8 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
## {{% heading "whatsnext" %}}
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index ace94edad2..82184f7784 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -8,7 +8,7 @@ weight: 30
-The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
@@ -42,7 +42,7 @@ To follow this guide, you need:
You also need to use a version of `kubeadm` that can deploy the version
of Kubernetes that you want to use in your new cluster.
-[Kubernetes' version and version skew support policy](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall.
+[Kubernetes' version and version skew support policy](/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall.
Check that policy to learn about what versions of Kubernetes and `kubeadm`
are supported. This page is written for Kubernetes {{< param "version" >}}.
@@ -118,7 +118,7 @@ While `--apiserver-advertise-address` can be used to set the advertise address f
control-plane node's API server, `--control-plane-endpoint` can be used to set the shared endpoint
for all control-plane nodes.
-`--control-plane-endpoint` allows IP addresses but also DNS names that can map to IP addresses.
+`--control-plane-endpoint` allows both IP addresses and DNS names that can map to IP addresses.
Please contact your network administrator to evaluate possible solutions with respect to such mapping.
Here is an example mapping:
@@ -254,11 +254,11 @@ Read all of this advice carefully before proceeding.
**You must deploy a
{{< glossary_tooltip text="Container Network Interface" term_id="cni" >}}
-(CNI) based Pod network add-on so that your Pods can communicate with each other.
+(CNI) based Pod network add-on so that your Pods can communicate with each other.
Cluster DNS (CoreDNS) will not start up before a network is installed.**
- Take care that your Pod network must not overlap with any of the host
- networks: you are likely to see problems if there is any overlap.
+ networks: you are likely to see problems if there is any overlap.
(If you find a collision between your network plugin’s preferred Pod
network and some of your host networks, you should think of a suitable
CIDR block to use instead, then use that during `kubeadm init` with
@@ -266,13 +266,13 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.**
- By default, `kubeadm` sets up your cluster to use and enforce use of
[RBAC](/docs/reference/access-authn-authz/rbac/) (role based access
- control).
+ control).
Make sure that your Pod network plugin supports RBAC, and so do any manifests
that you use to deploy it.
- If you want to use IPv6--either dual-stack, or single-stack IPv6 only
networking--for your cluster, make sure that your Pod network plugin
- supports IPv6.
+ supports IPv6.
IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
{{< /caution >}}
@@ -284,10 +284,10 @@ tracker instead of the kubeadm or kubernetes issue trackers.
{{< /note >}}
Several external projects provide Kubernetes Pod networks using CNI, some of which also
-support [Network Policy](/docs/concepts/services-networking/networkpolicies/).
+support [Network Policy](/docs/concepts/services-networking/network-policies/).
-See the list of available
-[networking and network policy add-ons](https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
+See a list of add-ons that implement the
+[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
You can install a Pod network add-on with the following command on the
control-plane node or a node that has the kubeconfig credentials:
@@ -297,79 +297,6 @@ kubectl apply -f
```
You can install only one Pod network per cluster.
-Below you can find installation instructions for some popular Pod network plugins:
-
-{{< tabs name="tabs-pod-install" >}}
-
-{{% tab name="Calico" %}}
-[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`.
-
-Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration.
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml
-```
-
-{{% /tab %}}
-
-{{% tab name="Cilium" %}}
-
-To deploy Cilium you just need to run:
-
-```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
-```
-
-Once all Cilium Pods are marked as `READY`, you start using your cluster.
-
-```shell
-kubectl get pods -n kube-system --selector=k8s-app=cilium
-```
-The output is similar to this:
-```
-NAME READY STATUS RESTARTS AGE
-cilium-drxkl 1/1 Running 0 18m
-```
-
-Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free).
-
-For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
-
-{{% /tab %}}
-
-{{% tab name="Contiv-VPP" %}}
-[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
-offering feature-rich & high-performance cloud-native networking and services.
-
-It implements k8s services and network policies in the user space (on VPP).
-
-Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
-{{% /tab %}}
-
-{{% tab name="Kube-router" %}}
-
-Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
-
-Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
-
-For information on using the `kubeadm` tool to set up a Kubernetes cluster with Kube-router, please see the official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
-{{% /tab %}}
-
-{{% tab name="Weave Net" %}}
-
-For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/).
-
-Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` platforms without any extra action required.
-Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
-if they don't know their PodIP.
-
-```shell
-kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-```
-{{% /tab %}}
-
-{{< /tabs >}}
-
Once a Pod network has been installed, you can confirm that it is working by
checking that the CoreDNS Pod is `Running` in the output of `kubectl get pods --all-namespaces`.
@@ -531,10 +458,9 @@ Talking to the control-plane node with the appropriate credentials, run:
```bash
kubectl drain --delete-local-data --force --ignore-daemonsets
-kubectl delete node
```
-Then, on the node being removed, reset all `kubeadm` installed state:
+Before removing the node, reset the state installed by `kubeadm`:
```bash
kubeadm reset
@@ -552,6 +478,11 @@ If you want to reset the IPVS tables, you must run the following command:
ipvsadm -C
```
+Now remove the node:
+```bash
+kubectl delete node
+```
+
If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
appropriate arguments.
@@ -574,9 +505,9 @@ options.
* See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
for details about upgrading your cluster using `kubeadm`.
* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
-of Pod network add-ons.
+ of Pod network add-ons.
* See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to
explore other add-ons, including tools for logging, monitoring, network policy, visualization &
control of your Kubernetes cluster.
@@ -640,5 +571,3 @@ supports your chosen platform.
## Troubleshooting {#troubleshooting}
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
-
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 5584309406..e91e9f7a60 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -22,7 +22,7 @@ and environment. [This comparison topic](/docs/setup/production-environment/tool
If you encounter issues with setting up the HA cluster, please provide us with feedback
in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new).
-See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
+See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
{{< caution >}}
This page does not address running your cluster on a cloud provider. In a cloud
@@ -30,8 +30,6 @@ environment, neither approach documented here works with Service objects of type
LoadBalancer, or with dynamic PersistentVolumes.
{{< /caution >}}
-
-
## {{% heading "prerequisites" %}}
@@ -51,8 +49,6 @@ For the external etcd cluster only, you also need:
- Three additional machines for etcd members
-
-
## First steps for both methods
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index e06918d7b8..2996568369 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -54,6 +54,8 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t
## Letting iptables see bridged traffic
+Make sure that the `br_netfilter` module is loaded. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`.
+
As a requirement for your Linux Node's iptables to correctly see bridged traffic, you should ensure `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g.
```bash
@@ -64,9 +66,7 @@ EOF
sudo sysctl --system
```
-Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`.
-
-For more details please see the [Network Plugin Requirements](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page.
+For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page.
## Check required ports
@@ -191,7 +191,7 @@ sudo apt-mark hold kubelet kubeadm kubectl
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
```bash
-cat < /etc/yum.repos.d/kubernetes.repo
+cat < /etc/systemd/system/kubelet.service
-mkdir -p /etc/systemd/system/kubelet.service.d
-curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
+curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
+sudo mkdir -p /etc/systemd/system/kubelet.service.d
+curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
```
Enable and start `kubelet`:
@@ -306,4 +310,3 @@ If you are running into difficulties with kubeadm, please consult our [troublesh
* [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
index 8dfcb250ce..af4eb4a101 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
@@ -173,7 +173,7 @@ Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
-#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
+# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
@@ -198,9 +198,8 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
| Package name | Description |
|--------------|-------------|
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
-| `kubelet` | Installs the `/usr/bin/kubelet` binary. |
+| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. |
| `kubectl` | Installs the `/usr/bin/kubectl` binary. |
-| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. |
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
index 334e2266f2..d860a88bdd 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
@@ -13,14 +13,12 @@ weight: 100
kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control
plane. This means that key components such as the API server, controller
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
-configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
+configured via the Kubernetes API instead of [static pods](/docs/tasks/configure-pod-container/static-pod/)
configured in the kubelet via static files.
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
-
-
#### Caveats
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
index 739b405d14..11ddaaf8f8 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
@@ -23,22 +23,15 @@ becoming unavailable. This task walks through the process of creating a high
availability etcd cluster of three members that can be used as an external etcd
when using kubeadm to set up a kubernetes cluster.
-
-
## {{% heading "prerequisites" %}}
-
* Three hosts that can talk to each other over ports 2379 and 2380. This
document assumes these default ports. However, they are configurable through
the kubeadm config file.
-* Each host must [have docker, kubelet, and kubeadm installed][toolbox].
+* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
* Some infrastructure to copy files between hosts. For example `ssh` and `scp`
can satisfy this requirement.
-[toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/
-
-
-
## Setting up the cluster
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index a4d6d54cc2..696778f974 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -15,11 +15,10 @@ If your problem is not listed below, please follow the following steps:
- Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
- If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
-- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
+- If you are unsure about how kubeadm works, you can ask on [Slack](https://slack.k8s.io/) in `#kubeadm`,
+ or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
-
-
## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC
diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md
index 07c0b3c574..02d99d926a 100644
--- a/content/en/docs/setup/production-environment/tools/kubespray.md
+++ b/content/en/docs/setup/production-environment/tools/kubespray.md
@@ -8,7 +8,7 @@ weight: 30
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
-Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
* a highly available cluster
* composable attributes
@@ -21,9 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
* openSUSE Leap 15
* continuous integration tests
-To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
-
-
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
@@ -35,7 +34,7 @@ Provision servers with the following [requirements](https://github.com/kubernete
* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands**
* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
-* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/downloads.md#offline-environment))
+* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
* The target servers are configured to allow **IPv4 forwarding**
* **Your ssh key must be copied** to all the servers part of your inventory
* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall
@@ -50,7 +49,7 @@ Kubespray provides the following utilities to help provision your environment:
### (2/5) Compose an inventory file
-After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
### (3/5) Plan your cluster deployment
@@ -68,7 +67,7 @@ Kubespray provides the ability to customize many aspects of the deployment:
* {{< glossary_tooltip term_id="cri-o" >}}
* Certificate generation methods
-Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
+Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
### (4/5) Deploy a Cluster
@@ -110,11 +109,9 @@ When running the reset playbook, be sure not to accidentally target your product
## Feedback
-* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
-
-
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md
index 92dd18075c..be75623158 100644
--- a/content/en/docs/setup/production-environment/turnkey/aws.md
+++ b/content/en/docs/setup/production-environment/turnkey/aws.md
@@ -23,9 +23,7 @@ To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secr
* [Kubernetes Operations](https://github.com/kubernetes/kops) - Production Grade K8s Installation, Upgrades, and Management. Supports running Debian, Ubuntu, CentOS, and RHEL in AWS.
-* [CoreOS Tectonic](https://coreos.com/tectonic/) includes the open-source [Tectonic Installer](https://github.com/coreos/tectonic-installer) that creates Kubernetes clusters with Container Linux nodes on AWS.
-
-* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, kube-aws](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
+* [kube-aws](https://github.com/kubernetes-incubator/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
* [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters.
@@ -50,7 +48,7 @@ export PATH=/platforms/darwin/amd64:$PATH
export PATH=/platforms/linux/amd64:$PATH
```
-An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/)
+An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/reference/kubectl/kubectl/)
By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
@@ -65,7 +63,8 @@ For more complete applications, please look in the [examples directory](https://
## Scaling the cluster
-Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
+Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the
+[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
## Tearing down the cluster
@@ -82,13 +81,8 @@ cluster/kube-down.sh
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ----------------------------
AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb))
-AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community
-AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community
+AWS | CoreOS | CoreOS | flannel | - | | Community
+AWS | Juju | Ubuntu | flannel, calico, canal | - | 100% | Commercial, Community
AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md
index 60c4e690d9..3ea666eb7c 100644
--- a/content/en/docs/setup/production-environment/turnkey/gce.md
+++ b/content/en/docs/setup/production-environment/turnkey/gce.md
@@ -72,7 +72,7 @@ cluster/kube-up.sh
If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
-[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
+[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.
The next few steps will show you:
@@ -85,7 +85,7 @@ The next few steps will show you:
The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
-The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster
+The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
manager. It lets you inspect your cluster resources, create, delete, and update
components, and much more. You will use it to look at your new cluster and bring
up example apps.
@@ -98,7 +98,7 @@ gcloud components install kubectl
{{< note >}}
The kubectl version bundled with `gcloud` may be older than the one
-downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
+downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/)
document to see how you can set up the latest `kubectl` on your workstation.
{{< /note >}}
@@ -112,7 +112,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru
kubectl get --all-namespaces services
```
-should show a set of [services](/docs/user-guide/services) that look something like this:
+should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:
```shell
NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE
@@ -122,7 +122,7 @@ kube-system kube-ui ClusterIP 10.0.0.3
...
```
-Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup.
+Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/pod/) that were created during cluster startup.
You can do this via the
```shell
@@ -149,7 +149,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh
### Run some examples
-Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
+Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
@@ -221,9 +221,3 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/production-environment/turnkey/gce/) | | Project
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
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 09a74d1450..0192cfeb5e 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
@@ -17,7 +17,7 @@ Windows applications constitute a large portion of the services and applications
## Windows containers in Kubernetes
-To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers.
+To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is as simple and easy as scheduling Linux-based containers.
In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
@@ -56,7 +56,7 @@ Windows containers with process isolation have strict compatibility rules, [wher
Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows.
-* [Pods](/docs/concepts/workloads/pods/pod-overview/)
+* [Pods](/docs/concepts/workloads/pods/)
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers:
diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md
index d80d6c0ffd..8bc87867bc 100644
--- a/content/en/docs/setup/release/notes.md
+++ b/content/en/docs/setup/release/notes.md
@@ -63,11 +63,9 @@ filename | sha512 hash
## Changelog since v1.17.0
A complete changelog for the release notes is now hosted in a customizable
-format at [https://relnotes.k8s.io][1]. Check it out and please give us your
+format at [https://relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.18.0). Check it out and please give us your
feedback!
-[1]: https://relnotes.k8s.io/?releaseVersions=1.18.0
-
## What’s New (Major Themes)
### Kubernetes Topology Manager Moves to Beta - Align Up!
@@ -80,13 +78,13 @@ Server-side Apply was promoted to Beta in 1.16, but is now introducing a second
### Extending Ingress with and replacing a deprecated annotation with IngressClass
-In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types.
+In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types.
The `IngressClass` resource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new `ingressClassName` field on Ingresses. This new resource and field replace the deprecated `kubernetes.io/ingress.class` annotation.
### SIG CLI introduces kubectl debug
-SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.
+SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.
### Introducing Windows CSI support alpha for Kubernetes
@@ -126,7 +124,7 @@ No Known Issues Reported
#### kubectl:
- `kubectl` and k8s.io/client-go no longer default to a server address of `http://localhost:8080`. If you own one of these legacy clusters, you are *strongly* encouraged to secure your server. If you cannot secure your server, you can set the `$KUBERNETES_MASTER` environment variable to `http://localhost:8080` to continue defaulting the server address. `kubectl` users can also set the server address using the `--server` flag, or in a kubeconfig file specified via `--kubeconfig` or `$KUBECONFIG`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
-- `kubectl run` has removed the previously deprecated generators, along with flags unrelated to creating pods. `kubectl run` now only creates pods. See specific `kubectl create` subcommands to create objects other than pods.
+- `kubectl run` has removed the previously deprecated generators, along with flags unrelated to creating pods. `kubectl run` now only creates pods. See specific `kubectl create` subcommands to create objects other than pods.
([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, CLI and Testing]
- The deprecated command `kubectl rolling-update` has been removed ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing]
@@ -193,13 +191,13 @@ No Known Issues Reported
- node_memory_working_set_bytes --> node_memory_working_set_bytes
- container_cpu_usage_seconds_total --> container_cpu_usage_seconds
- container_memory_working_set_bytes --> container_memory_working_set_bytes
- - scrape_error --> scrape_error
+ - scrape_error --> scrape_error
([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) [SIG Node]
- In a future release, kubelet will no longer create the CSI NodePublishVolume target directory, in accordance with the CSI specification. CSI drivers may need to be updated accordingly to properly create and process the target path. ([#75535](https://github.com/kubernetes/kubernetes/issues/75535)) [SIG Storage]
#### kube-proxy:
- `--healthz-port` and `--metrics-port` flags are deprecated, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
-- a new `EndpointSliceProxying` feature gate has been added to control the use of EndpointSlices in kube-proxy. The EndpointSlice feature gate that used to control this behavior no longer affects kube-proxy. This feature has been disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott))
+- a new `EndpointSliceProxying` feature gate has been added to control the use of EndpointSlices in kube-proxy. The EndpointSlice feature gate that used to control this behavior no longer affects kube-proxy. This feature has been disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott))
#### kubeadm:
- command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
@@ -245,7 +243,7 @@ No Known Issues Reported
- The alpha feature `ServiceAccountIssuerDiscovery` enables publishing OIDC discovery information and service account token verification keys at `/.well-known/openid-configuration` and `/openid/v1/jwks` endpoints by API servers configured to issue service account tokens. ([#80724](https://github.com/kubernetes/kubernetes/pull/80724), [@cceckman](https://github.com/cceckman)) [SIG API Machinery, Auth, Cluster Lifecycle and Testing]
- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing]
- CustomResourceDefinition schemas that use `x-kubernetes-list-type: map` or `x-kubernetes-list-type: set` now enable validation that the list items in the corresponding custom resources are unique. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery]
-
+
#### Configuration file changes:
#### kube-apiserver:
@@ -257,7 +255,7 @@ No Known Issues Reported
- Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.schedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing]
- Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
- The PostFilter of scheduler framework is renamed to PreScore in kubescheduler.config.k8s.io/v1alpha2. ([#87751](https://github.com/kubernetes/kubernetes/pull/87751), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling and Testing]
-
+
#### kube-proxy:
- Added kube-proxy flags `--ipvs-tcp-timeout`, `--ipvs-tcpfin-timeout`, `--ipvs-udp-timeout` to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cluster Lifecycle and Network]
- Added optional `--detect-local-mode` flag to kube-proxy. Valid values are "ClusterCIDR" (default matching previous behavior) and "NodeCIDR" ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling]
@@ -689,8 +687,8 @@ filename | sha512 hash
- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
-- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver.
- After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect.
+- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver.
+ After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect.
The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.
Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
@@ -739,7 +737,7 @@ filename | sha512 hash
- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability]
- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
- Specifying PluginConfig for the same plugin more than once fails scheduler startup.
-
+
Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
- Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI]
- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing]
@@ -806,18 +804,18 @@ filename | sha512 hash
If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node]
- Yes.
-
+
Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster.
-
+
Changes in Pull Request:
-
+
1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources.
2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature.
3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature.
4. Related unit tests.
-
+
None.
-
+
User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider]
## Changes by Kind
@@ -833,8 +831,8 @@ filename | sha512 hash
- Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage]
- AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
- Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery]
-- Introduces optional --detect-local flag to kube-proxy.
- Currently the only supported value is "cluster-cidr",
+- Introduces optional --detect-local flag to kube-proxy.
+ Currently the only supported value is "cluster-cidr",
which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling]
- Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing]
- Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows]
@@ -1048,9 +1046,9 @@ filename | sha512 hash
- aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery]
- API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form
-
+
Throttling request took 1.50705208s, request: GET:
-
+
The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery]
- kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
- disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md
index cc506352d3..5b189667db 100644
--- a/content/en/docs/setup/release/version-skew-policy.md
+++ b/content/en/docs/setup/release/version-skew-policy.md
@@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s
## Supported versions
Kubernetes versions are expressed as **x.y.z**,
-where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology.
+where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}).
@@ -146,3 +146,16 @@ Running a cluster with `kubelet` instances that are persistently two minor versi
* they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
* it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
{{}}
+
+### kube-proxy
+
+* `kube-proxy` must be the same minor version as `kubelet` on the node.
+* `kube-proxy` must not be newer than `kube-apiserver`.
+* `kube-proxy` must be at most two minor versions older than `kube-apiserver.`
+
+Example:
+
+If `kube-proxy` version is **{{< skew latestVersion >}}**:
+
+* `kubelet` version must be at the same minor version as **{{< skew latestVersion >}}**.
+* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
diff --git a/content/en/docs/tasks/_index.md b/content/en/docs/tasks/_index.md
index 552f17e48c..0d424ee4db 100644
--- a/content/en/docs/tasks/_index.md
+++ b/content/en/docs/tasks/_index.md
@@ -11,9 +11,5 @@ This section of the Kubernetes documentation contains pages that
show how to do individual tasks. A task page shows how to do a
single thing, typically by giving a short sequence of steps.
-
-## {{% heading "whatsnext" %}}
-
-
If you would like to write a task page, see
[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/).
diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
index 9288ec3064..a0c68ff682 100644
--- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -132,7 +132,7 @@ The following file is an Ingress resource that sends traffic to your Service via
1. Create `example-ingress.yaml` from the following file:
- apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1
+ apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: example-ingress
@@ -243,7 +243,7 @@ The following file is an Ingress resource that sends traffic to your Service via
Output:
```shell
- ingress.extensions/example-ingress configured
+ ingress.networking/example-ingress configured
```
## Test Your Ingress
diff --git a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
index fe90981432..1194288386 100644
--- a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -45,13 +45,14 @@ Here is the configuration file for the application Deployment:
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
The preceding command creates a
- [Deployment](/docs/concepts/workloads/controllers/deployment/)
- object and an associated
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
- object. The ReplicaSet has two
- [Pods](/docs/concepts/workloads/pods/pod/),
+ {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+ and an associated
+ {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}.
+ The ReplicaSet has two
+ {{< glossary_tooltip text="Pods" term_id="pod" >}}
each of which runs the Hello World application.
+
1. Display information about the Deployment:
```shell
kubectl get deployments hello-world
diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 7a37fdc20b..6d7c1cced2 100644
--- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -101,12 +101,12 @@ If needed, you can expand the **Advanced options** section where you can specify
Example:
-```conf
-release=1.0
-tier=frontend
-environment=pod
-track=stable
-```
+ ```conf
+ release=1.0
+ tier=frontend
+ environment=pod
+ track=stable
+ ```
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
diff --git a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md
index 453cfef221..9c08a2a4ad 100644
--- a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md
+++ b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md
@@ -24,7 +24,7 @@ Depending on the installation method, your Kubernetes cluster may be deployed wi
an existing StorageClass that is marked as default. This default StorageClass
is then used to dynamically provision storage for PersistentVolumeClaims
that do not require any specific storage class. See
-[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#class-1)
+[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
for details.
The pre-installed default StorageClass may not fit well with your expected workload;
diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index 729c7bde4f..be7cbf2673 100644
--- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -19,15 +19,15 @@ PersistentVolume.
## Why change reclaim policy of a PersistentVolume
-`PersistentVolumes` can have various reclaim policies, including "Retain",
-"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`,
+PersistentVolumes can have various reclaim policies, including "Retain",
+"Recycle", and "Delete". For dynamically provisioned PersistentVolumes,
the default reclaim policy is "Delete". This means that a dynamically provisioned
volume is automatically deleted when a user deletes the corresponding
-`PersistentVolumeClaim`. This automatic behavior might be inappropriate if the volume
+PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume
contains precious data. In that case, it is more appropriate to use the "Retain"
-policy. With the "Retain" policy, if a user deletes a `PersistentVolumeClaim`,
-the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to the
-`Released` phase, where all of its data can be manually recovered.
+policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim,
+the corresponding PersistentVolume is not be deleted. Instead, it is moved to the
+Released phase, where all of its data can be manually recovered.
## Changing the reclaim policy of a PersistentVolume
diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md
index 1b29abf17c..5ffc40781a 100644
--- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md
+++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md
@@ -36,7 +36,7 @@ By default, the kubelet uses [CFS quota](https://en.wikipedia.org/wiki/Completel
to enforce pod CPU limits. When the node runs many CPU-bound pods,
the workload can move to different CPU cores depending on
whether the pod is throttled and which CPU cores are available at
-scheduling time. Many workloads are not sensitive to this migration and thus
+scheduling time. Many workloads are not sensitive to this migration and thus
work fine without any intervention.
However, in workloads where CPU cache affinity and scheduling latency
diff --git a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
index f436b641a0..9fb0452ddc 100644
--- a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
+++ b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
@@ -17,7 +17,7 @@ DNS resolution process in your cluster.
{{< include "task-tutorial-prereqs.md" >}}
Your cluster must be running the CoreDNS add-on.
-[Migrating to CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/#migrating-to-coredns)
+[Migrating to CoreDNS](/docs/tasks/administer-cluster/coredns/#migrating-to-coredns)
explains how to use `kubeadm` to migrate from `kube-dns`.
{{% version-check %}}
@@ -117,7 +117,7 @@ You can modify the default CoreDNS behavior by modifying the ConfigMap.
### Configuration of Stub-domain and upstream nameserver using CoreDNS
-CoreDNS has the ability to configure stubdomains and upstream nameservers using the [forward plugin](https://coredns.io/plugins/forward/).
+CoreDNS has the ability to configure stubdomains and upstream nameservers using the [forward plugin](https://coredns.io/plugins/forward/).
#### Example
If a cluster operator has a [Consul](https://www.consul.io/) domain server located at 10.150.0.1, and all Consul names have the suffix .consul.local. To configure it in CoreDNS, the cluster administrator creates the following stanza in the CoreDNS ConfigMap.
@@ -261,4 +261,4 @@ You can also migrate using the offical CoreDNS
## {{% heading "whatsnext" %}}
-- Read [Debugging DNS Resolution](/docs/tasks/debug-application-cluster/dns-debugging-resolution/)
+- Read [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/)
diff --git a/content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
similarity index 100%
rename from content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md
rename to content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index 6fd887bd8f..f333b215a2 100644
--- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -160,7 +160,7 @@ kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
The output is:
- deployment.extensions/dns-autoscaler scaled
+ deployment.apps/dns-autoscaler scaled
Verify that the replica count is zero:
diff --git a/content/en/docs/tasks/administer-cluster/kms-provider.md b/content/en/docs/tasks/administer-cluster/kms-provider.md
index 34cc1d6b66..15bc1290ff 100644
--- a/content/en/docs/tasks/administer-cluster/kms-provider.md
+++ b/content/en/docs/tasks/administer-cluster/kms-provider.md
@@ -7,10 +7,8 @@ content_type: task
This page shows how to configure a Key Management Service (KMS) provider and plugin to enable secret data encryption.
-
## {{% heading "prerequisites" %}}
-
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* Kubernetes version 1.10.0 or later is required
@@ -19,8 +17,6 @@ This page shows how to configure a Key Management Service (KMS) provider and plu
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
-
-
The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS
@@ -30,10 +26,12 @@ plugin. The KMS plugin, which is implemented as a gRPC server and deployed on th
To configure a KMS provider on the API server, include a provider of type ```kms``` in the providers array in the encryption configuration file and set the following properties:
- * `name`: Display name of the KMS plugin.
- * `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket.
- * `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. When cached, DEKs can be used without another call to the KMS; whereas DEKs that are not cached require a call to the KMS to unwrap.
- * `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds).
+* `name`: Display name of the KMS plugin.
+* `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket.
+* `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear.
+ When cached, DEKs can be used without another call to the KMS;
+ whereas DEKs that are not cached require a call to the KMS to unwrap.
+* `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds).
See [Understanding the encryption at rest configuration.](/docs/tasks/administer-cluster/encrypt-data)
@@ -57,17 +55,18 @@ Then use the functions and data structures in the stub file to develop the serve
* kms plugin version: `v1beta1`
-In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version
+ In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version.
* message version: `v1beta1`
-All messages from KMS provider have the version field set to current version v1beta1
+ All messages from KMS provider have the version field set to current version v1beta1.
* protocol: UNIX domain socket (`unix`)
-The gRPC server should listen at UNIX domain socket
+ The gRPC server should listen at UNIX domain socket.
### Integrating a KMS plugin with the remote KMS
+
The KMS plugin can communicate with the remote KMS using any protocol supported by the KMS.
All configuration data, including authentication credentials the KMS plugin uses to communicate with the remote KMS,
are stored and managed by the KMS plugin independently. The KMS plugin can encode the ciphertext with additional metadata that may be required before sending it to the KMS for decryption.
@@ -80,108 +79,113 @@ To encrypt the data:
1. Create a new encryption configuration file using the appropriate properties for the `kms` provider:
- ```yaml
- apiVersion: apiserver.config.k8s.io/v1
- kind: EncryptionConfiguration
- resources:
- - resources:
- - secrets
- providers:
- - kms:
- name: myKmsPlugin
- endpoint: unix:///tmp/socketfile.sock
- cachesize: 100
- timeout: 3s
- - identity: {}
- ```
+ ```yaml
+ apiVersion: apiserver.config.k8s.io/v1
+ kind: EncryptionConfiguration
+ resources:
+ - resources:
+ - secrets
+ providers:
+ - kms:
+ name: myKmsPlugin
+ endpoint: unix:///tmp/socketfile.sock
+ cachesize: 100
+ timeout: 3s
+ - identity: {}
+ ```
-2. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file.
-3. Restart your API server.
-
-Note:
-The alpha version of the encryption feature prior to 1.13 required a config file with
-`kind: EncryptionConfig` and `apiVersion: v1`, and used the `--experimental-encryption-provider-config` flag.
+1. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file.
+1. Restart your API server.
## Verifying that the data is encrypted
-Data is encrypted when written to etcd. After restarting your kube-apiserver, any newly created or updated secret should be encrypted when stored. To verify, you can use the etcdctl command line program to retrieve the contents of your secret.
+
+Data is encrypted when written to etcd. After restarting your `kube-apiserver`,
+any newly created or updated secret should be encrypted when stored. To verify,
+you can use the `etcdctl` command line program to retrieve the contents of your secret.
1. Create a new secret called secret1 in the default namespace:
-```
-kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
-```
-2. Using the etcdctl command line, read that secret out of etcd:
-```
-ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C
-```
- where `[...]` must be the additional arguments for connecting to the etcd server.
+ ```
+ kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
+ ```
+1. Using the etcdctl command line, read that secret out of etcd:
+ ```
+ ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C
+ ```
+ where `[...]` must be the additional arguments for connecting to the etcd server.
-3. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data.
+1. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data.
-4. Verify that the secret is correctly decrypted when retrieved via the API:
-```
-kubectl describe secret secret1 -n default
-```
-should match `mykey: mydata`
+1. Verify that the secret is correctly decrypted when retrieved via the API:
+ ```
+ kubectl describe secret secret1 -n default
+ ```
+ should match `mykey: mydata`
## Ensuring all secrets are encrypted
+
Because secrets are encrypted on write, performing an update on a secret encrypts that content.
-The following command reads all secrets and then updates them to apply server side encryption. If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
+The following command reads all secrets and then updates them to apply server side encryption.
+If an error occurs due to a conflicting write, retry the command.
+For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
+
```
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
## Switching from a local encryption provider to the KMS provider
+
To switch from a local encryption provider to the `kms` provider and re-encrypt all of the secrets:
1. Add the `kms` provider as the first entry in the configuration file as shown in the following example.
- ```yaml
- apiVersion: apiserver.config.k8s.io/v1
- kind: EncryptionConfiguration
- resources:
- - resources:
- - secrets
- providers:
- - kms:
- name : myKmsPlugin
- endpoint: unix:///tmp/socketfile.sock
- cachesize: 100
- - aescbc:
- keys:
- - name: key1
- secret:
- ```
+ ```yaml
+ apiVersion: apiserver.config.k8s.io/v1
+ kind: EncryptionConfiguration
+ resources:
+ - resources:
+ - secrets
+ providers:
+ - kms:
+ name : myKmsPlugin
+ endpoint: unix:///tmp/socketfile.sock
+ cachesize: 100
+ - aescbc:
+ keys:
+ - name: key1
+ secret:
+ ```
-2. Restart all kube-apiserver processes.
+1. Restart all kube-apiserver processes.
-3. Run the following command to force all secrets to be re-encrypted using the `kms` provider.
+1. Run the following command to force all secrets to be re-encrypted using the `kms` provider.
-```
-kubectl get secrets --all-namespaces -o json| kubectl replace -f -
-```
+ ```
+ kubectl get secrets --all-namespaces -o json| kubectl replace -f -
+ ```
## Disabling encryption at rest
+
To disable encryption at rest:
1. Place the `identity` provider as the first entry in the configuration file:
- ```yaml
- apiVersion: apiserver.config.k8s.io/v1
- kind: EncryptionConfiguration
- resources:
- - resources:
- - secrets
- providers:
- - identity: {}
- - kms:
- name : myKmsPlugin
- endpoint: unix:///tmp/socketfile.sock
- cachesize: 100
- ```
-2. Restart all kube-apiserver processes.
-3. Run the following command to force all secrets to be decrypted.
-```
-kubectl get secrets --all-namespaces -o json | kubectl replace -f -
-```
+ ```yaml
+ apiVersion: apiserver.config.k8s.io/v1
+ kind: EncryptionConfiguration
+ resources:
+ - resources:
+ - secrets
+ providers:
+ - identity: {}
+ - kms:
+ name : myKmsPlugin
+ endpoint: unix:///tmp/socketfile.sock
+ cachesize: 100
+ ```
+1. Restart all kube-apiserver processes.
+1. Run the following command to force all secrets to be decrypted.
+ ```
+ kubectl get secrets --all-namespaces -o json | kubectl replace -f -
+ ```
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index e82c53f3a6..c3498fce61 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
### Joining a Windows worker node
{{< note >}}
You must install the `Containers` feature and install Docker. Instructions
-to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise).
+to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html).
{{< /note >}}
{{< note >}}
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
index 461e45bda6..02687a85f2 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
@@ -12,15 +12,11 @@ weight: 10
Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm.
-
-
## {{% heading "prerequisites" %}}
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
-
-
## Using custom certificates {#custom-certificates}
@@ -155,33 +151,29 @@ These are advanced topics for users who need to integrate their organization's c
### Set up a signer
The Kubernetes Certificate Authority does not work out of the box.
-You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the built-in signer.
+You can configure an external signer such as [cert-manager](https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html), or you can use the built-in signer.
-The built-in signer is part of [`kube-controller-manager`][kcm].
+The built-in signer is part of [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/).
To activate the built-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags.
-If you're creating a new cluster, you can use a kubeadm [configuration file][config]:
+If you're creating a new cluster, you can use a kubeadm [configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2):
- ```yaml
- apiVersion: kubeadm.k8s.io/v1beta2
- kind: ClusterConfiguration
- controllerManager:
- extraArgs:
- cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
- cluster-signing-key-file: /etc/kubernetes/pki/ca.key
- ```
-
-[cert-manager-issuer]: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html
-[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/
-[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+controllerManager:
+ extraArgs:
+ cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
+ cluster-signing-key-file: /etc/kubernetes/pki/ca.key
+```
### Create certificate signing requests (CSR)
You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm alpha certs renew --use-api`.
-If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved.
-Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command.
+If you set up an external signer such as [cert-manager](https://github.com/jetstack/cert-manager), certificate signing requests (CSRs) are automatically approved.
+Otherwise, you must manually approve certificates with the [`kubectl certificate`](/docs/setup/best-practices/certificates/) command.
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
```shell
@@ -197,7 +189,7 @@ The output is similar to this:
If you set up an external signer, certificate signing requests (CSRs) are automatically approved.
-Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command. e.g.
+Otherwise, you must manually approve certificates with the [`kubectl certificate`](/docs/setup/best-practices/certificates/) command. e.g.
```shell
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
@@ -229,20 +221,16 @@ Certificates can be renewed with `kubeadm alpha certs renew --csr-only`.
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
-It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate.
+It is the responsibility of the CA to specify [the correct cert usages](/docs/setup/best-practices/certificates/#all-certificates)
+when issuing a certificate.
-* In `openssl` this is done with the [`openssl ca` command][openssl-ca].
-* In `cfssl` you specify [usages in the config file][cfssl-usages]
+* In `openssl` this is done with the
+ [`openssl ca` command](https://superuser.com/questions/738612/openssl-ca-keyusage-extension).
+* In `cfssl` you specify
+ [usages in the config file](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170).
After a certificate is signed using your preferred method, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
-[cert-manager]: https://github.com/jetstack/cert-manager
-[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
-[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
-[certs]: /docs/setup/best-practices/certificates/
-[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca
-[cert-table]: /docs/setup/best-practices/certificates/#all-certificates
-
## Certificate authority (CA) rotation {#certificate-authority-rotation}
Kubeadm does not support rotation or replacement of CA certificates out of the box.
diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
index 2bf0de8231..1d3d34867c 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
@@ -36,7 +36,7 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu
This example assumes the following:
1. You have an [existing Kubernetes cluster](/docs/setup/).
-2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
## Understand the default namespace
diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md
index be7906e40f..3266f06602 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces.md
@@ -13,7 +13,7 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name
## {{% heading "prerequisites" %}}
* Have an [existing Kubernetes cluster](/docs/setup/).
-* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
@@ -82,6 +82,10 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/
## Creating a new namespace
+{{< note >}}
+ Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
+{{< /note >}}
+
1. Create a new YAML file called `my-namespace.yaml` with the contents:
```yaml
diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
index 6218e8ce81..7f56e4ec85 100644
--- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
+++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
@@ -38,7 +38,7 @@ if your cluster is running v1.16 then you can use kubectl v1.15, v1.16
or v1.17; other combinations
[aren't supported](/docs/setup/release/version-skew-policy/#kubectl).
-Some of the examples use the commandline tool
+Some of the examples use the command line tool
[jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task,
because there are manual alternatives.
@@ -380,4 +380,4 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
- For more information on configuring the kubelet via a configuration file, see
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
-- See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
+- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
index e18b2ed87d..ed1b9657c8 100644
--- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md
+++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
@@ -34,7 +34,7 @@ This task assumes that you have met the following prerequisites:
You can use `kubectl drain` to safely evict all of your pods from a
node before you perform maintenance on the node (e.g. kernel upgrade,
hardware maintenance, etc.). Safe evictions allow the pod's containers
-to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods)
+to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
and will respect the `PodDisruptionBudgets` you have specified.
{{< note >}}
diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
index d6aea240c1..60af560e30 100644
--- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
+++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
@@ -57,7 +57,8 @@ The following sysctls are supported in the _safe_ set:
- `kernel.shm_rmid_forced`,
- `net.ipv4.ip_local_port_range`,
-- `net.ipv4.tcp_syncookies`.
+- `net.ipv4.tcp_syncookies`,
+- `net.ipv4.ping_group_range` (since Kubernetes 1.18).
{{< note >}}
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
index f5116e7691..00b9251be8 100644
--- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -75,7 +75,7 @@ set to RUNNING until the postStart handler completes.
Kubernetes sends the preStop event immediately before the Container is terminated.
Kubernetes' management of the Container blocks until the preStop handler completes,
unless the Pod's grace period expires. For more details, see
-[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
{{< note >}}
Kubernetes only sends the preStop event when a Pod is *terminated*.
diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index ed5aa24044..1630708182 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -332,7 +332,7 @@ to 1 second. Minimum value is 1.
* `successThreshold`: Minimum consecutive successes for the probe to be
considered successful after having failed. Defaults to 1. Must be 1 for
liveness. Minimum value is 1.
-* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will
+* `failureThreshold`: When a probe fails, Kubernetes will
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
Defaults to 3. Minimum value is 1.
diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md
index eaaabb9e94..f1b1e22db9 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md
@@ -316,14 +316,14 @@ kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
The kubelet will request and store the token on behalf of the pod, make the
token available to the pod at a configurable file path, and refresh the token as it approaches expiration. Kubelet proactively rotates the token if it is older than 80% of its total TTL, or if the token is older than 24 hours.
-The application is responsible for reloading the token when it rotates. Periodic reloading (e.g. once every 5 minutes) is sufficient for most usecases.
+The application is responsible for reloading the token when it rotates. Periodic reloading (e.g. once every 5 minutes) is sufficient for most use cases.
## Service Account Issuer Discovery
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
The Service Account Issuer Discovery feature is enabled by enabling the
-`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature)
+`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates)
and then enabling the Service Account Token Projection feature as described
[above](#service-account-token-volume-projection).
diff --git a/content/en/docs/tasks/configure-pod-container/security-context.md b/content/en/docs/tasks/configure-pod-container/security-context.md
index 38662760b7..db9a0aa96f 100644
--- a/content/en/docs/tasks/configure-pod-container/security-context.md
+++ b/content/en/docs/tasks/configure-pod-container/security-context.md
@@ -30,8 +30,8 @@ a Pod or Container. Security context settings include, but are not limited to:
* readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.
-The above bullets are not a complete set of security context settings -- please see
-[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
+The above bullets are not a complete set of security context settings -- please see
+[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
for a comprehensive list.
For more information about security mechanisms in Linux, see
@@ -59,11 +59,11 @@ Here is a configuration file for a Pod that has a `securityContext` and an `empt
{{< codenew file="pods/security/security-context.yaml" >}}
In the configuration file, the `runAsUser` field specifies that for any Containers in
-the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for
+the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for
all processes within any containers of the Pod. If this field is omitted, the primary group ID of the containers
-will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified.
-Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000.
-The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000.
+will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified.
+Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000.
+The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000.
Create the Pod:
@@ -138,7 +138,7 @@ $ id
uid=1000 gid=3000 groups=2000
```
You will see that gid is 3000 which is same as `runAsGroup` field. If the `runAsGroup` was omitted the gid would
-remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
+remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
the required group permissions for root(0) group.
Exit your shell:
@@ -180,9 +180,9 @@ This is an alpha feature. To use it, enable the [feature gate](/docs/reference/c
{{< note >}}
This field has no effect on ephemeral volume types such as
-[`secret`](https://kubernetes.io/docs/concepts/storage/volumes/#secret),
-[`configMap`](https://kubernetes.io/docs/concepts/storage/volumes/#configmap),
-and [`emptydir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir).
+[`secret`](/docs/concepts/storage/volumes/#secret),
+[`configMap`](/docs/concepts/storage/volumes/#configmap),
+and [`emptydir`](/docs/concepts/storage/volumes/#emptydir).
{{< /note >}}
@@ -423,6 +423,3 @@ kubectl delete pod security-context-demo-4
* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/)
* [AllowPrivilegeEscalation design
document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
-
-
-
diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md
index 5189fdb882..cf31d822d6 100644
--- a/content/en/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/static-pod.md
@@ -14,7 +14,7 @@ without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
observing them.
Unlike Pods that are managed by the control plane (for example, a
{{< glossary_tooltip text="Deployment" term_id="deployment" >}});
-instead, the kubelet watches each static Pod (and restarts it if it crashes).
+instead, the kubelet watches each static Pod (and restarts it if it fails).
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index 600af51d00..14d5bef7f1 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -22,12 +22,10 @@ answer the following questions:
- from where was it initiated?
- to where was it going?
-
-
-
-[Kube-apiserver][kube-apiserver] performs auditing. Each request on each stage
+[Kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+performs auditing. Each request on each stage
of its execution generates an event, which is then pre-processed according to
a certain policy and written to a backend. The policy determines what's recorded
and the backends persist the records. The current backend implementations
@@ -55,7 +53,8 @@ Additionally, memory consumption depends on the audit logging configuration.
Audit policy defines rules about what events should be recorded and what data
they should include. The audit policy object structure is defined in the
-[`audit.k8s.io` API group][auditing-api]. When an event is processed, it's
+[`audit.k8s.io` API group](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
+When an event is processed, it's
compared against the list of rules in order. The first matching rule sets the
"audit level" of the event. The known audit levels are:
@@ -67,7 +66,7 @@ compared against the list of rules in order. The first matching rule sets the
- `RequestResponse` - log event metadata, request and response bodies.
This does not apply for non-resource requests.
-You can pass a file with the policy to [kube-apiserver][kube-apiserver]
+You can pass a file with the policy to `kube-apiserver`
using the `--audit-policy-file` flag. If the flag is omitted, no events are logged.
Note that the `rules` field __must__ be provided in the audit policy file.
A policy with no (0) rules is treated as illegal.
@@ -86,12 +85,14 @@ rules:
- level: Metadata
```
-The audit profile used by GCE should be used as reference by admins constructing their own audit profiles. You can check the [configure-helper.sh][configure-helper] script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script.
+The audit profile used by GCE should be used as reference by admins constructing their own audit profiles. You can check the
+[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
+script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script.
## Audit backends
Audit backends persist audit events to an external storage.
-[Kube-apiserver][kube-apiserver] out of the box provides three backends:
+`Kube-apiserver` out of the box provides three backends:
- Log backend, which writes events to a disk
- Webhook backend, which sends events to an external API
@@ -99,7 +100,7 @@ Audit backends persist audit events to an external storage.
In all cases, audit events structure is defined by the API in the
`audit.k8s.io` API group. The current version of the API is
-[`v1`][auditing-api].
+[`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
{{< note >}}
In case of patches, request body is a JSON array with patch operations, not a JSON object
@@ -125,7 +126,7 @@ request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
### Log backend
Log backend writes audit events to a file in JSON format. You can configure
-log audit backend using the following [kube-apiserver][kube-apiserver] flags:
+log audit backend using the following `kube-apiserver` flags:
- `--audit-log-path` specifies the log file path that log backend uses to write
audit events. Not specifying this flag disables log backend. `-` means standard out
@@ -136,11 +137,12 @@ log audit backend using the following [kube-apiserver][kube-apiserver] flags:
### Webhook backend
Webhook backend sends audit events to a remote API, which is assumed to be the
-same API as [kube-apiserver][kube-apiserver] exposes. You can configure webhook
+same API as `kube-apiserver` exposes. You can configure webhook
audit backend using the following kube-apiserver flags:
- `--audit-webhook-config-file` specifies the path to a file with a webhook
- configuration. Webhook configuration is effectively a [kubeconfig][kubeconfig].
+ configuration. Webhook configuration is effectively a
+ [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
- `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed
request before retrying. Subsequent requests are retried with exponential backoff.
@@ -327,23 +329,29 @@ Currently, this feature has performance implications for the apiserver in the fo
## Setup for multiple API servers
-If you're extending the Kubernetes API with the [aggregation layer][kube-aggregator], you can also
-set up audit logging for the aggregated apiserver. To do this, pass the configuration options in the
-same format as described above to the aggregated apiserver and set up the log ingesting pipeline
-to pick up audit logs. Different apiservers can have different audit configurations and different
-audit policies.
+If you're extending the Kubernetes API with the [aggregation
+layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/),
+you can also set up audit logging for the aggregated apiserver. To do this,
+pass the configuration options in the same format as described above to the
+aggregated apiserver and set up the log ingesting pipeline to pick up audit
+logs. Different apiservers can have different audit configurations and
+different audit policies.
## Log Collector Examples
### Use fluentd to collect and distribute audit events from log file
-[Fluentd][fluentd] is an open source data collector for unified logging layer.
+[Fluentd](http://www.fluentd.org/) is an open source data collector for unified logging layer.
In this example, we will use fluentd to split audit events by different namespaces.
-{{< note >}}Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
+{{< note >}}
+The `fluent-plugin-forest` and `fluent-plugin-rewrite-tag-filter` are plugins for fluentd.
+You can get details about plugin installation from
+[fluentd plugin-management](https://docs.fluentd.org/v1.0/articles/plugin-management).
{{< /note >}}
-1. Install [fluentd][fluentd_install_doc], fluent-plugin-forest and fluent-plugin-rewrite-tag-filter in the kube-apiserver node
+1. Install [`fluentd`](https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd),
+ `fluent-plugin-forest` and `fluent-plugin-rewrite-tag-filter` in the kube-apiserver node
1. Create a config file for fluentd
@@ -416,11 +424,12 @@ In this example, we will use fluentd to split audit events by different namespac
### Use logstash to collect and distribute audit events from webhook backend
-[Logstash][logstash] is an open source, server-side data processing tool. In this example,
+[Logstash](https://www.elastic.co/products/logstash)
+is an open source, server-side data processing tool. In this example,
we will use logstash to collect audit events from webhook backend, and save events of
different users into different files.
-1. install [logstash][logstash_install_doc]
+1. install [logstash](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html)
1. create config file for logstash
@@ -491,19 +500,6 @@ Note that in addition to file output plugin, logstash has a variety of outputs t
let users route data where they want. For example, users can emit audit events to elasticsearch
plugin which supports full-text search and analytics.
-[kube-apiserver]: /docs/reference/command-line-tools-reference/kube-apiserver/
-[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
-[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
-[configure-helper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
-[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
-[fluentd]: http://www.fluentd.org/
-[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
-[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management
-[logstash]: https://www.elastic.co/products/logstash
-[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
-[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
-
-
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md
index a5c37541c3..edd23c35e7 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md
@@ -118,7 +118,7 @@ You can view this resource with:
kubectl get endpoints ${SERVICE_NAME}
```
-Make sure that the endpoints match up with the number of containers that you expect to be a member of your service.
+Make sure that the endpoints match up with the number of pods that you expect to be members of your service.
For example, if your Service is for an nginx container with 3 replicas, you would expect to see three different
IP addresses in the Service's endpoints.
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 9793b472e0..8fb5bffd37 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -17,7 +17,8 @@ This page shows how to debug Pods and ReplicationControllers.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* You should be familiar with the basics of
- [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
+ {{< glossary_tooltip text="Pods" term_id="pod" >}} and with
+ Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/).
diff --git a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
index 44dcf0e909..543573781b 100644
--- a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+++ b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
@@ -78,7 +78,7 @@ only the termination message:
## Customizing the termination message
Kubernetes retrieves termination messages from the termination message file
-specified in the `terminationMessagePath` field of a Container, which as a default
+specified in the `terminationMessagePath` field of a Container, which has a default
value of `/dev/termination-log`. By customizing this field, you can tell Kubernetes
to use a different file. Kubernetes use the contents from the specified file to
populate the Container's status message on both success and failure.
diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md
deleted file mode 100644
index f5f67406a9..0000000000
--- a/content/en/docs/tasks/debug-application-cluster/falco.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-reviewers:
-- soltysh
-- sttts
-- ericchiang
-content_type: concept
-title: Auditing with Falco
----
-
-
-### Use Falco to collect audit events
-
-[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms.
-This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior.
-
-
-
-
-
-
-#### Install Falco
-
-Install Falco by using one of the following methods:
-
-- [Standalone Falco][falco_installation]
-- [Kubernetes DaemonSet][falco_installation]
-- [Falco Helm Chart][falco_helm_chart]
-
-Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration:
-
-```yaml
-webserver:
- enabled: true
- listen_port: 8765
- k8s_audit_endpoint: /k8s_audit
- ssl_enabled: false
- ssl_certificate: /etc/falco/falco.pem
-```
-
-This configuration is typically found in the `/etc/falco/falco.yaml` file. If Falco is installed as a Kubernetes DaemonSet, edit the `falco-config` ConfigMap and add this configuration.
-
-#### Configure Kubernetes Audit
-
-1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) for the [kube-apiserver][kube-apiserver] webhook audit backend.
-
- cat < /etc/kubernetes/audit-webhook-kubeconfig
- apiVersion: v1
- kind: Config
- clusters:
- - cluster:
- server: http://:8765/k8s_audit
- name: falco
- contexts:
- - context:
- cluster: falco
- user: ""
- name: default-context
- current-context: default-context
- preferences: {}
- users: []
- EOF
-
-1. Start [kube-apiserver][kube-apiserver] with the following options:
-
- ```shell
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
- ```
-
-#### Audit Rules
-
-Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml][falco_k8s_audit_rules]. If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to `/etc/falco/`, so they are available for use.
-
-There are three classes of rules.
-
-The first class of rules looks for suspicious or exceptional activities, such as:
-
-- Any activity by an unauthorized or anonymous user.
-- Creating a pod with an unknown or disallowed image.
-- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking.
-- Creating a NodePort service.
-- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets.
-- Attaching to or executing a command on a running pod.
-- Creating a namespace external to a set of allowed namespaces.
-- Creating a pod or service account in the kube-system or kube-public namespaces.
-- Trying to modify or delete a system ClusterRole.
-- Creating a ClusterRoleBinding to the cluster-admin role.
-- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive.
-- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods.
-
-A second class of rules tracks resources being created or destroyed, including:
-
-- Deployments
-- Services
-- ConfigMaps
-- Namespaces
-- Service accounts
-- Role/ClusterRoles
-- Role/ClusterRoleBindings
-
-The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy.
-
-For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco documentation.
-
-[kube-apiserver]: /docs/admin/kube-apiserver
-[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
-[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
-[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
-[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
-[fluentd]: http://www.fluentd.org/
-[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
-[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management
-[logstash]: https://www.elastic.co/products/logstash
-[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
-[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
-[falco_website]: https://www.falco.org
-[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml
-[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit
-[falco_installation]: https://falco.org/docs/installation
-[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco
-
-
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index dbd4aa6cf4..098776cb7b 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -41,7 +41,7 @@ The API requires metrics server to be deployed in the cluster. Otherwise it will
### CPU
-CPU is reported as the average usage, in [CPU cores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation.
+CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation.
### Memory
@@ -60,5 +60,3 @@ Metrics Server is registered with the main API server through
[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/).
Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
-
-
diff --git a/content/en/docs/tasks/example-task-template.md b/content/en/docs/tasks/example-task-template.md
deleted file mode 100644
index 90d14e98da..0000000000
--- a/content/en/docs/tasks/example-task-template.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: Example Task Template
-reviewers:
-- chenopis
-content_type: task
-toc_hide: true
----
-
-
-
-{{< note >}}
-Be sure to also [create an entry in the table of contents](/docs/contribute/style/write-new-topic/#placing-your-topic-in-the-table-of-contents) for your new document.
-{{< /note >}}
-
-This page shows how to ...
-
-
-
-## {{% heading "prerequisites" %}}
-
-
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* Do this.
-* Do this too.
-
-
-
-
-
-## Doing ...
-
-1. Do this.
-1. Do this next. Possibly read this [related explanation](#).
-
-
-
-
-
-## Understanding ...
-**[Optional Section]**
-
-Here's an interesting thing to know about the steps you just did.
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-**[Optional Section]**
-
-* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
-* Learn about [Page Content Types - Task](/docs/home/contribute/style/page-content-types/#task).
diff --git a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
similarity index 92%
rename from content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md
rename to content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
index e4b58b70e3..b14777111e 100644
--- a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md
+++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
@@ -4,6 +4,7 @@ reviewers:
- madhusudancs
title: Configure Multiple Schedulers
content_type: task
+weight: 20
---
@@ -128,45 +129,8 @@ If RBAC is enabled on your cluster, you must update the `system:kube-scheduler`
```
kubectl edit clusterrole system:kube-scheduler
```
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- annotations:
- rbac.authorization.kubernetes.io/autoupdate: "true"
- labels:
- kubernetes.io/bootstrapping: rbac-defaults
- name: system:kube-scheduler
-rules:
-- apiGroups:
- - coordination.k8s.io
- resources:
- - leases
- verbs:
- - create
-- apiGroups:
- - coordination.k8s.io
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - leases
- verbs:
- - get
- - update
-- apiGroups:
- - ""
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - endpoints
- verbs:
- - delete
- - get
- - patch
- - update
-```
+
+{{< codenew file="admin/sched/clusterrole.yaml" >}}
## Specify schedulers for pods
diff --git a/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md b/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md
index dd80c8c349..b3aae7fc3e 100644
--- a/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md
+++ b/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md
@@ -17,7 +17,7 @@ If you do not already have an application running in your cluster, start
a Hello world application by entering this command:
```shell
-kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080
+kubectl create deployment node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080
```
diff --git a/content/en/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/en/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
new file mode 100644
index 0000000000..74c5c245db
--- /dev/null
+++ b/content/en/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
@@ -0,0 +1,78 @@
+---
+title: Define Dependent Environment Variables
+content_type: task
+weight: 20
+---
+
+
+
+This page shows how to define dependent environment variables for a container
+in a Kubernetes Pod.
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+
+
+
+## Define an environment dependent variable for a container
+
+When you create a Pod, you can set dependent environment variables for the containers that run in the Pod. To set dependent environment variables, you can use $(VAR_NAME) in the `value` of `env` in the configuration file.
+
+In this exercise, you create a Pod that runs one container. The configuration
+file for the Pod defines an dependent environment variable with common usage defined. Here is the configuration manifest for the
+Pod:
+
+{{< codenew file="pods/inject/dependent-envars.yaml" >}}
+
+1. Create a Pod based on that manifest:
+
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
+ ```
+ ```
+ pod/dependent-envars-demo created
+ ```
+
+2. List the running Pods:
+
+ ```shell
+ kubectl get pods dependent-envars-demo
+ ```
+ ```
+ NAME READY STATUS RESTARTS AGE
+ dependent-envars-demo 1/1 Running 0 9s
+ ```
+
+3. Check the logs for the container running in your Pod:
+
+ ```shell
+ kubectl logs pod/dependent-envars-demo
+ ```
+ ```
+
+ UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+ SERVICE_ADDRESS=https://172.17.0.1:80
+ ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+ ```
+
+As shown above, you have defined the correct dependency reference of `SERVICE_ADDRESS`, bad dependency reference of `UNCHANGED_REFERENCE` and skip dependent references of `ESCAPED_REFERENCE`.
+
+When an environment variable is already defined when being referenced,
+the reference can be correctly resolved, such as in the `SERVICE_ADDRESS` case.
+
+When the environment variable is undefined or only includes some variables, the undefined environment variable is treated as a normal string, such as `UNCHANGED_REFERENCE`. Note that incorrectly parsed environment variables, in general, will not block the container from starting.
+
+The `$(VAR_NAME)` syntax can be escaped with a double `$`, ie: `$$(VAR_NAME)`.
+Escaped references are never expanded, regardless of whether the referenced variable
+is defined or not. This can be seen from the `ESCAPED_REFERENCE` case above.
+
+## {{% heading "whatsnext" %}}
+
+
+* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
+* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
+
diff --git a/content/en/docs/tasks/inject-data-application/podpreset.md b/content/en/docs/tasks/inject-data-application/podpreset.md
index 6533629ce4..9eea082321 100644
--- a/content/en/docs/tasks/inject-data-application/podpreset.md
+++ b/content/en/docs/tasks/inject-data-application/podpreset.md
@@ -140,7 +140,7 @@ verify that the preset has been applied.
## ReplicaSet with Pod spec example
-This is an example to show that only Pod specs are modified by Pod presets. Other workload types
+This is an example to show that only Pod specs are modified by Pod presets. Other workload types
like ReplicaSets or Deployments are unaffected.
Here is the manifest for the PodPreset for this example:
@@ -290,7 +290,7 @@ kubectl get pod website -o yaml
You can see there is no preset annotation (`podpreset.admission.kubernetes.io`). Seeing no annotation tells you that no preset has not been applied to the Pod.
However, the
-[PodPreset admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podpreset)
+[PodPreset admission controller](/docs/reference/access-authn-authz/admission-controllers/#podpreset)
logs a warning containing details of the conflict.
You can view the warning using `kubectl`:
@@ -301,7 +301,7 @@ kubectl -n kube-system logs -l=component=kube-apiserver
The output should look similar to:
```
-W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache:
+W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache:
v1.VolumeMount{Name:"other-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil), SubPathExpr:""}
does not match
core.VolumeMount{Name:"cache-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*core.MountPropagationMode)(nil), SubPathExpr:""}
@@ -321,5 +321,3 @@ The output shows that the PodPreset was deleted:
```
podpreset "allow-database" deleted
```
-
-
diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md
index 7a4a94fab4..57e54e6797 100644
--- a/content/en/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/en/docs/tasks/run-application/delete-stateful-set.md
@@ -58,7 +58,7 @@ kubectl delete pods -l app=myapp
### Persistent Volumes
-Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
+Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have terminated might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
{{< note >}}
Use caution when deleting a PVC, as it may lead to data loss.
diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
index 48a61a260d..e706c6179a 100644
--- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -37,7 +37,7 @@ You can perform a graceful pod deletion with the following command:
kubectl delete pods
```
-For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the [Pod shuts down gracefully](/docs/concepts/workloads/pods/pod/#termination-of-pods) before the kubelet deletes the name from the apiserver.
+For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver.
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 7f3b046b68..6806ba0dc0 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -47,7 +47,7 @@ The Dockerfile has the following content:
```
FROM php:5-apache
-ADD index.php /var/www/html/index.php
+COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
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 6dc61f8d4f..f84744cdd7 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -181,7 +181,8 @@ are preserved as annotations when working with `autoscaling/v1`.
When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
More details about the API object can be found at
-[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
+[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling).
+
## Support for Horizontal Pod Autoscaler in kubectl
diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
index 4146608760..a55ff3b5fd 100644
--- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
+++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
@@ -1,7 +1,7 @@
---
title: Manual Rotation of CA Certificates
min-kubernetes-server-version: v1.13
-content_template: templates/task
+content_type: task
---
diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md
index cabf9a3c7b..7f43d34be7 100755
--- a/content/en/docs/tasks/tools/_index.md
+++ b/content/en/docs/tasks/tools/_index.md
@@ -2,5 +2,40 @@
title: "Install Tools"
description: Set up Kubernetes tools on your computer.
weight: 10
+no_list: true
---
+## kubectl
+
+The Kubernetes command-line tool, `kubectl`, allows you to run commands against
+Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage
+cluster resources, and view logs.
+
+See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to
+download and install `kubectl` and set it up for accessing your cluster.
+
+You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/).
+
+## Minikube
+
+[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run
+Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal
+computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes,
+or for daily development work.
+
+You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/)
+guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus
+is on getting the tool installed.
+
+Once you have Minikube working, you can use it to
+[run a sample application](/docs/tutorials/hello-minikube/).
+
+## kind
+
+Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
+your local compute. Unlike Minikuke, kind only works with a single container runtime:
+it requires that you have [Docker](https://docs.docker.com/get-docker/) installed
+and configured.
+
+[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you
+need to do to get up and running with kind.
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 25b5cab9b5..22b960751f 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -28,7 +28,7 @@ You must use a kubectl version that is within one minor version difference of yo
1. Download the latest release with the command:
```
- curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
+ curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
diff --git a/content/en/docs/tasks/tools/install-minikube.md b/content/en/docs/tasks/tools/install-minikube.md
index f1f3788141..a5e7ed0c2b 100644
--- a/content/en/docs/tasks/tools/install-minikube.md
+++ b/content/en/docs/tasks/tools/install-minikube.md
@@ -206,7 +206,7 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru
{{< note >}}
-For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
+For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
{{< /note >}}
diff --git a/content/en/docs/test.md b/content/en/docs/test.md
index 848decff35..a08aeb3caa 100644
--- a/content/en/docs/test.md
+++ b/content/en/docs/test.md
@@ -235,7 +235,6 @@ link target in parentheses. [Link to Kubernetes.io](https://kubernetes.io/) or
You can also use HTML, but it is not preferred.
Link to Kubernetes.io
-
## Images
To format an image, use similar syntax to [links](#links), but add a leading `!`
diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md
index 5551e5a8ea..2313d78e87 100644
--- a/content/en/docs/tutorials/_index.md
+++ b/content/en/docs/tutorials/_index.md
@@ -1,6 +1,7 @@
---
title: Tutorials
main_menu: true
+no_list: true
weight: 60
content_type: concept
---
@@ -14,8 +15,6 @@ each of which has a sequence of steps.
Before walking through each tutorial, you may want to bookmark the
[Standardized Glossary](/docs/reference/glossary/) page for later references.
-
-
## Basics
@@ -64,13 +63,8 @@ Before walking through each tutorial, you may want to bookmark the
* [Using Source IP](/docs/tutorials/services/source-ip/)
-
-
## {{% heading "whatsnext" %}}
-
If you would like to write a tutorial, see
-[Content Page Types](/docs/home/contribute/style/page-content-types/)
+[Content Page Types](/docs/contribute/style/page-content-types/)
for information about the tutorial page type.
-
-
diff --git a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
index 37f6f9e014..7555a58201 100644
--- a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
+++ b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
@@ -93,7 +93,7 @@ Use `kubectl exec` to enter the pod and run the `redis-cli` tool to verify that
the configuration was correctly applied:
```shell
-kubectl exec -it redis redis-cli
+kubectl exec -it redis -- redis-cli
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "2097152"
diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md
index 9ba2de1abf..f0aa44369e 100644
--- a/content/en/docs/tutorials/hello-minikube.md
+++ b/content/en/docs/tutorials/hello-minikube.md
@@ -65,7 +65,7 @@ This tutorial provides a container image that uses NGINX to echo back all the re
## Create a Deployment
-A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers,
+A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers,
tied together for the purposes of administration and networking. The Pod in this
tutorial has only one Container. A Kubernetes
[*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your
diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 6d7e15a7c4..fb782458de 100644
--- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -20,7 +20,7 @@ weight: 20
- A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods.
+ A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods.
Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.
+
Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.
A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a LabelSelector (see below for why you might want a Service without including selector in the spec).
{{< /blocks/section >}}
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}
\ No newline at end of file
diff --git a/content/es/docs/concepts/_index.md b/content/es/docs/concepts/_index.md
index fddd126047..7dd7709bae 100644
--- a/content/es/docs/concepts/_index.md
+++ b/content/es/docs/concepts/_index.md
@@ -17,11 +17,11 @@ La sección de conceptos te ayudará a conocer los componentes de Kubernetes as
En Kubernetes se utilizan los *objetos de la API de Kubernetes* para describir el *estado deseado* del clúster: qué aplicaciones u otras cargas de trabajo se quieren ejecutar, qué imagenes de contenedores usan, el número de replicas, qué red y qué recursos de almacenamiento quieres que tengan disponibles, etc. Se especifica el estado deseado del clúster mediante la creación de objetos usando la API de Kubernetes, típicamente mediante la interfaz de línea de comandos, `kubectl`. También se puede usar la API de Kubernetes directamente para interactuar con el clúster y especificar o modificar tu estado deseado.
-Una vez que se especifica el estado deseado, el *Plano de Control de Kubernetes* realizará las acciones necesarias para que el estado actual del clúster coincida con el estado deseado. Para ello, Kubernetes realiza diferentes tareas de forma automática, como pueden ser: parar o arrancar contenedores, escalar el número de réplicas de una aplicación dada, etc. El Plano de Control de Kubernetes consiste en un grupo de procesos que corren en tu clúster:
+Una vez que se especifica el estado deseado, el *Plano de Control de Kubernetes* realizará las acciones necesarias para que el estado actual del clúster coincida con el estado deseado. Para ello, Kubernetes realiza diferentes tareas de forma automática, como pueden ser: parar o arrancar contenedores, escalar el número de réplicas de una aplicación dada, etc. El Plano de Control de Kubernetes consiste en un grupo de daemons que corren en tu clúster:
-* El **Master de Kubernetes** es un conjunto de tres procesos que se ejecutan en un único nodo del clúster, que se denomina nodo master. Estos procesos son: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) y [kube-scheduler](/docs/admin/kube-scheduler/).
+* El **Master de Kubernetes** es un conjunto de tres daemons que se ejecutan en un único nodo del clúster, que se denomina nodo master. Estos daemons son: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) y [kube-scheduler](/docs/admin/kube-scheduler/).
-* Los restantes nodos no master contenidos en tu clúster, ejecutan los siguientes dos procesos:
+* Los restantes nodos no master contenidos en tu clúster, ejecutan los siguientes dos daemons:
* **[kubelet](/docs/admin/kubelet/)**, el cual se comunica con el Master de Kubernetes.
* **[kube-proxy](/docs/admin/kube-proxy/)**, un proxy de red que implementa los servicios de red de Kubernetes en cada nodo.
@@ -55,7 +55,7 @@ Por ejemplo, cuando usas la API de Kubernetes para crear un Deployment, estás p
El Master de Kubernetes es el responsable de mantener el estado deseado de tu clúster. Cuando interactuas con Kubernetes, como por ejemplo cuando utilizas la interfaz de línea de comandos `kubectl`, te estás comunicando con el master de tu clúster de Kubernetes.
-> Por "master" entendemos la colección de procesos que gestionan el estado del clúster. Típicamente, estos procesos se ejecutan todos en un único nodo del clúster, y este nodo recibe por tanto la denominación de master. El master puede estar replicado por motivos de disponibilidad y redundancia.
+> Por "master" entendemos la colección de daemons que gestionan el estado del clúster. Típicamente, estos daemons se ejecutan todos en un único nodo del clúster, y este nodo recibe por tanto la denominación de master. El master puede estar replicado por motivos de disponibilidad y redundancia.
### Kubernetes Nodes
diff --git a/content/es/docs/concepts/configuration/configmap.md b/content/es/docs/concepts/configuration/configmap.md
new file mode 100644
index 0000000000..b607f0b82d
--- /dev/null
+++ b/content/es/docs/concepts/configuration/configmap.md
@@ -0,0 +1,253 @@
+---
+title: ConfigMaps
+content_type: concept
+weight: 20
+---
+
+
+
+{{< glossary_definition term_id="configmap" prepend="Un configmap es " length="all" >}}
+
+{{< caution >}}
+ConfigMap no proporciona encriptación.
+Si los datos que quieres almacenar son confidenciales, utiliza un
+{{< glossary_tooltip text="Secret" term_id="secret" >}} en lugar de un ConfigMap,
+o utiliza otras herramientas externas para mantener los datos seguros.
+{{< /caution >}}
+
+
+
+
+## Motivo
+
+Utiliza un ConfigMap para crear una configuración separada del código de la aplicación.
+
+Por ejemplo, imagina que estás desarrollando una aplicación que puedes correr en
+tu propio equipo (para desarrollo) y en el cloud (para mantener tráfico real).
+Escribes el código para configurar una variable llamada `DATABASE_HOST`.
+En tu equipo configuras la variable con el valor `localhost`.
+En el cloud, la configuras con referencia a un kubernetes
+{{< glossary_tooltip text="Service" term_id="service" >}} que expone el componente
+de la base de datos en tu cluster.
+
+Esto permite tener una imagen corriendo en un cloud y
+tener el mismo código localmente para checkearlo si es necesario.
+
+## Objeto ConfigMap
+
+Un ConfigMap es un [objeto](/docs/concepts/overview/working-with-objects/kubernetes-objects/) de la API
+que permite almacenar la configuración de otros objetos utilizados. Aunque muchos
+objetos de kubernetes que tienen un `spec`, un ConfigMap tiene una sección `data` para
+almacenar items, identificados por una clave, y sus valores.
+
+El nombre del ConfigMap debe ser un
+[nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido.
+
+## ConfigMaps y Pods
+
+Puedes escribir un Pod `spec` y referenciarlo a un ConfigMap y configurar el contenedor(es)
+de ese {{< glossary_tooltip text="Pod" term_id="pod" >}} en base a los datos del ConfigMap. El {{< glossary_tooltip text="Pod" term_id="pod" >}} y el ConfigMap deben estar en
+el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+
+Este es un ejemplo de ConfigMap que tiene algunas claves con un valor simple,
+y otras claves donde el valor tiene un formato de un fragmento de configuración.
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: game-demo
+data:
+ # property-like keys; each key maps to a simple value
+ player_initial_lives: "3"
+ ui_properties_file_name: "user-interface.properties"
+ #
+ # file-like keys
+ game.properties: |
+ enemy.types=aliens,monsters
+ player.maximum-lives=5
+ user-interface.properties: |
+ color.good=purple
+ color.bad=yellow
+ allow.textmode=true
+```
+Hay cuatro maneras diferentes de usar un ConfigMap para configurar
+un contenedor dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}}:
+
+1. Argumento en la linea de comandos como entrypoint de un contenedor
+1. Variable de enorno de un contenedor
+1. Como fichero en un volumen de solo lectura, para que lo lea la aplicación
+1. Escribir el código para ejecutar dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}} que utiliza la API para leer el ConfigMap
+
+Estos diferentes mecanismos permiten utilizar diferentes métodos para modelar
+los datos que se van a usar.
+Para los primeros tres mecanismos, el
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza la información
+del ConfigMap cuando lanza un contenedor (o varios) en un {{< glossary_tooltip text="Pod" term_id="pod" >}}.
+
+Para el cuarto método, tienes que escribir el código para leer el ConfigMap y sus datos.
+Sin embargo, como estás utilizando la API de kubernetes directamente, la aplicación puede
+suscribirse para obtener actualizaciones cuando el ConfigMap cambie, y reaccionar
+cuando esto ocurra. Accediendo directamente a la API de kubernetes, esta
+técnica también permite acceder al ConfigMap en diferentes namespaces.
+
+En el siguiente ejemplo el Pod utiliza los valores de `game-demo` para configurar el contenedor:
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: configmap-demo-pod
+spec:
+ containers:
+ - name: demo
+ image: game.example/demo-game
+ env:
+ # Define the environment variable
+ - name: PLAYER_INITIAL_LIVES # Notice that the case is different here
+ # from the key name in the ConfigMap.
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo # The ConfigMap this value comes from.
+ key: player_initial_lives # The key to fetch.
+ - name: UI_PROPERTIES_FILE_NAME
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo
+ key: ui_properties_file_name
+ volumeMounts:
+ - name: config
+ mountPath: "/config"
+ readOnly: true
+ volumes:
+ # You set volumes at the Pod level, then mount them into containers inside that Pod
+ - name: config
+ configMap:
+ # Provide the name of the ConfigMap you want to mount.
+ name: game-demo
+ # An array of keys from the ConfigMap to create as files
+ items:
+ - key: "game.properties"
+ path: "game.properties"
+ - key: "user-interface.properties"
+ path: "user-interface.properties"
+```
+
+
+Un ConfigMap no diferencia entre las propiedades de una linea individual y
+un fichero con múltiples lineas y valores.
+Lo importante es como los {{< glossary_tooltip text="Pods" term_id="pod" >}} y otros objetos consumen estos valores.
+
+Para este ejemplo, definimos un {{< glossary_tooltip text="Volumen" term_id="volume" >}} y lo montamos dentro del contenedor
+`demo` como `/config` creando dos ficheros,
+`/config/game.properties` y `/config/user-interface.properties`,
+aunque haya cuatro claves en el ConfigMap. Esto es debido a que enla definición
+del {{< glossary_tooltip text="Pod" term_id="pod" >}} se especifica el array `items` en la sección `volumes`.
+Si quieres omitir el array `items` entero, cada clave del ConfigMap se convierte en
+un fichero con el mismo nombre que la clave, y tienes 4 ficheros.
+
+## Usando ConfigMaps
+
+Los ConfigMaps pueden montarse como volúmenes. También pueden ser utilizados por otras
+partes del sistema, sin ser expuestos directamente al {{< glossary_tooltip text="Pod" term_id="pod" >}}. Por ejemplo,
+los ConfigMaps pueden contener información para que otros elementos del sistema utilicen
+para su configuración.
+
+{{< note >}}
+La manera más común de usar los Configmaps es para configurar
+los contenedores que están corriendo en un {{< glossary_tooltip text="Pod" term_id="pod" >}} en el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+También se pueden usar por separado.
+
+Por ejemplo,
+quizá encuentres {{< glossary_tooltip text="AddOns" term_id="addons" >}}
+u {{< glossary_tooltip text="Operadores" term_id="operator-pattern" >}} que
+ajustan su comportamiento en base a un ConfigMap.
+{{< /note >}}
+
+### Usando ConfigMaps como ficheros en un Pod
+
+Para usar un ConfigMap en un volumen en un {{< glossary_tooltip text="Pod" term_id="pod" >}}:
+
+1. Crear un ConfigMap o usar uno que exista. Múltiples {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar el mismo ConfigMap.
+1. Modifica la configuración del {{< glossary_tooltip text="Pod" term_id="pod" >}} para añadir el volumen en `.spec.volumes[]`. Pon cualquier nombre al {{< glossary_tooltip text="Volumen" term_id="volume" >}}, y tienes un campo `.spec.volumes[].configMap.name` configurado con referencia al objeto ConfigMap.
+1. Añade un `.spec.containers[].volumeMounts[]` a cada contenedor que necesite el ConfigMap. Especifica `.spec.containers[].volumeMounts[].readOnly = true` y `.spec.containers[].volumeMounts[].mountPath` en un directorio sin uso donde quieras que aparezca el ConfigMap.
+1. Modifica la imagen o el comando utilizado para que el programa busque los ficheros en el directorio. Cada clave del ConfigMap `data` se convierte en un un fichero en el `mountPath`.
+
+En este ejemplo, el {{< glossary_tooltip text="Pod" term_id="pod" >}} monta un ConfigMap como un {{< glossary_tooltip text="volumen" term_id="volume" >}}:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: mypod
+spec:
+ containers:
+ - name: mypod
+ image: redis
+ volumeMounts:
+ - name: foo
+ mountPath: "/etc/foo"
+ readOnly: true
+ volumes:
+ - name: foo
+ configMap:
+ name: myconfigmap
+```
+
+Cada ConfigMap que quieras utilizar debe estar referenciado en `.spec.volumes`.
+
+Si hay múltiples contenedores en el {{< glossary_tooltip text="Pod" term_id="pod" >}}, cada contenedor tiene su propio
+bloque `volumeMounts`, pero solo un `.spec.volumes` es necesario por cada ConfigMap.
+
+#### ConfigMaps montados son actualizados automáticamente
+
+Cuando un ConfigMap está siendo utilizado en un {{< glossary_tooltip text="volumen" term_id="volume" >}} y es actualizado, las claves son actualizadas también.
+El {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} comprueba si el ConfigMap montado está actualizado cada periodo de sincronización.
+Sin embargo, el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza su caché local para obtener el valor actual del ConfigMap.
+El tipo de caché es configurable usando el campo `ConfigMapAndSecretChangeDetectionStrategy` en el
+[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
+Un ConfigMap puede ser propagado por vista (default), ttl-based, o simplemente redirigiendo
+todas las consultas directamente a la API.
+Como resultado, el retraso total desde el momento que el ConfigMap es actualizado hasta el momento
+que las nuevas claves son proyectadas en el {{< glossary_tooltip text="Pod" term_id="pod" >}} puede ser tan largo como la sincronización del {{< glossary_tooltip text="Pod" term_id="pod" >}}
++ el retraso de propagación de la caché, donde la propagación de la caché depende del tipo de
+caché elegido (es igual al retraso de propagación, ttl de la caché, o cero correspondientemente).
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+La característica alpha de kubernetes _Immutable Secrets and ConfigMaps_ provee una opción para configurar
+{{< glossary_tooltip text="Secrets" term_id="secret" >}} individuales y ConfigMaps como inmutables. Para los {{< glossary_tooltip text="Clústeres" term_id="cluster" >}} que usan ConfigMaps como extensión
+(al menos decenas o cientos de un único ConfigMap montado en {{< glossary_tooltip text="Pods" term_id="pod" >}}), previene cambios en sus
+datos con las siguientes ventajas:
+
+- protección de actualizaciones accidentales (o no deseadas) que pueden causar caídas de aplicaciones
+- mejora el rendimiento del {{< glossary_tooltip text="Clúster" term_id="cluster" >}} significativamente reduciendo la carga del {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}},
+cerrando las vistas para el ConfigMap marcado como inmutable.
+
+Para usar esta característica, habilita el `ImmutableEmphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) y configura
+el campo del {{< glossary_tooltip text="Secret" term_id="secret" >}} o ConfigMap `immutable` como `true`. Por ejemplo:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ ...
+data:
+ ...
+immutable: true
+```
+
+{{< note >}}
+Una vez que un ConfigMap o un {{< glossary_tooltip text="Secret" term_id="secret" >}} es marcado como inmutable, _no_ es posible revertir el cambio
+ni cambiar el contenido del campo `data`. Solo se puede eliminar y recrear el ConfigMap.
+Los {{< glossary_tooltip text="Pods" term_id="pod" >}} existentes mantiene un punto de montaje del ConfigMap eliminado - es recomendable
+recrear los {{< glossary_tooltip text="Pods" term_id="pod" >}}.
+{{< /note >}}
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Leer sobre [Secrets](/docs/concepts/configuration/secret/).
+* Leer [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+* Leer [The Twelve-Factor App](https://12factor.net/) para entender el motivo de separar
+ el código de la configuración.
diff --git a/content/es/docs/concepts/configuration/pod-overhead.md b/content/es/docs/concepts/configuration/pod-overhead.md
new file mode 100644
index 0000000000..0d7a89bcd6
--- /dev/null
+++ b/content/es/docs/concepts/configuration/pod-overhead.md
@@ -0,0 +1,41 @@
+---
+reviewers:
+- raelga
+title: Sobrecarga de Pod
+content_type: concept
+weight: 20
+---
+
+
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Cuando se está ejecutando un {{< glossary_tooltip text="Pod" term_id="pod" >}} en un {{< glossary_tooltip text="nodo" term_id="node" >}}, el Pod por sí mismo utiliza una cantidad de recursos del sistema. Estos recursos son adicionales a los recursos necesarios para hacer funcionar el/los contenedor(es) dentro del Pod.
+La _Sobrecarga de Pod_ es una característica para contabilizar los recursos consumidos por la infraestructura de Pods que están por encima de los valores de _Requests_ y _Limits_ del/los contenedor(es).
+
+
+
+## Sobrecarga de Pod
+
+En Kubernetes, la sobrecarga de {{< glossary_tooltip text="Pod" term_id="pod" >}} se configura en el tiempo de [admisión](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) con respecto a la sobrecarga asociada con el [RuntimeClass](/docs/concepts/containers/runtime-class/) del Pod.
+
+Cuando se habilita la opción de sobrecarga de {{< glossary_tooltip text="Pod" term_id="pod" >}}, se considera tanto la propia sobrecarga como la suma de solicitudes de recursos del contenedor al programar el {{< glossary_tooltip text="Pod" term_id="pod" >}}. Del mismo modo, {{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} incluirá la sobrecarga de {{< glossary_tooltip text="Pod" term_id="pod" >}} cuando se dimensione el cgroup del {{< glossary_tooltip text="Pod" term_id="pod" >}}, y cuando se realice la clasificación de la expulsión de {{< glossary_tooltip text="Pods" term_id="pod" >}}.
+
+### Configuración
+
+Debe asegurarse de que el [Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodOverhead` esté activado (su valor está desactivado de manera predeterminada) en todo el {{< glossary_tooltip text="clúster" term_id="cluster" >}}. Esto significa:
+
+- en el {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
+- en el {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}
+- en el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} de cada {{< glossary_tooltip text="nodo" term_id="node" >}}
+- en cualquier servidor de API personalizado que necesite [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/).
+
+{{< note >}}
+Los usuarios que pueden escribir recursos del tipo RuntimeClass podrían impactar y poner en riesgo el rendimiento de la carga de trabajo en todo el {{< glossary_tooltip text="clúster" term_id="cluster" >}}. Por ello, se puede limitar el acceso a esta característica usando los controles de acceso de Kubernetes.
+Para obtener más detalles vea la [documentación sobre autorización](/docs/reference/access-authn-authz/authorization/).
+{{< /note >}}
+
+
+
+* [RuntimeClass](/docs/concepts/containers/runtime-class/)
+* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
diff --git a/content/es/docs/concepts/overview/components.md b/content/es/docs/concepts/overview/components.md
new file mode 100644
index 0000000000..0ca6f3126c
--- /dev/null
+++ b/content/es/docs/concepts/overview/components.md
@@ -0,0 +1,117 @@
+---
+reviewers:
+- raelga
+title: Componentes de Kubernetes
+content_type: concept
+weight: 20
+card:
+ name: concepts
+ weight: 20
+---
+
+
+
+Este documento describe los distintos componentes que
+son necesarios para operar un clúster de Kubernetes.
+
+
+
+## Componentes del plano de control
+
+Los componentes que forman el plano de control toman decisiones globales sobre
+el clúster (por ejemplo, la planificación) y detectan y responden a eventos del clúster, como la creación
+de un nuevo pod cuando la propiedad `replicas` de un controlador de replicación no se cumple.
+
+Estos componentes pueden ejecutarse en cualquier nodo del clúster. Sin embargo para simplificar, los
+scripts de instalación típicamente se inician en el mismo nodo de forma exclusiva,
+sin que se ejecuten contenedores de los usuarios en esos nodos. El plano de control se ejecuta en varios nodos
+para garantizar la [alta disponibilidad](/docs/admin/high-availability/).
+
+### kube-apiserver
+
+{{< glossary_definition term_id="kube-apiserver" length="all" >}}
+
+### etcd
+
+{{< glossary_definition term_id="etcd" length="all" >}}
+
+### kube-scheduler
+
+{{< glossary_definition term_id="kube-scheduler" length="all" >}}
+
+### kube-controller-manager
+
+{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
+
+Estos controladores incluyen:
+
+ * Controlador de nodos: es el responsable de detectar y responder cuándo un nodo deja de funcionar
+ * Controlador de replicación: es el responsable de mantener el número correcto de pods para cada controlador
+ de replicación del sistema
+ * Controlador de endpoints: construye el objeto `Endpoints`, es decir, hace una unión entre los `Services` y los `Pods`
+ * Controladores de tokens y cuentas de servicio: crean cuentas y tokens de acceso a la API por defecto para los nuevos {{< glossary_tooltip text="Namespaces" term_id="namespace">}}.
+
+### cloud-controller-manager
+
+[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) ejecuta controladores que
+interactúan con proveedores de la nube. El binario `cloud-controller-manager` es una característica alpha que se introdujo en la versión 1.6 de Kubernetes.
+
+`cloud-controller-manager` sólo ejecuta ciclos de control específicos para cada proveedor de la nube. Es posible
+desactivar estos ciclos en `kube-controller-manager` pasando la opción `--cloud-provider= external` cuando se arranque el `kube-controller-manager`.
+
+`cloud-controller-manager` permite que el código de Kubernetes y el del proveedor de la nube evolucionen de manera independiente. Anteriormente, el código de Kubernetes dependía de la funcionalidad específica de cada proveedor de la nube. En el futuro, el código que sea específico a una plataforma debería ser mantenido por el proveedor de la nube y enlazado a `cloud-controller-manager` al correr Kubernetes.
+
+Los siguientes controladores dependen de alguna forma de un proveedor de la nube:
+
+ * Controlador de nodos: es el responsable de detectar y actuar cuándo un nodo deja de responder
+ * Controlador de rutas: para configurar rutas en la infraestructura de nube subyacente
+ * Controlador de servicios: para crear, actualizar y eliminar balanceadores de carga en la nube
+ * Controlador de volúmenes: para crear, conectar y montar volúmenes e interactuar con el proveedor de la nube para orquestarlos
+
+## Componentes de nodo
+
+Los componentes de nodo corren en cada nodo, manteniendo a los pods en funcionamiento y proporcionando el entorno de ejecución de Kubernetes.
+
+### kubelet
+
+{{< glossary_definition term_id="kubelet" length="all" >}}
+
+### kube-proxy
+
+[kube-proxy](/docs/admin/kube-proxy/) permite abstraer un servicio en Kubernetes manteniendo las
+reglas de red en el anfitrión y haciendo reenvío de conexiones.
+
+### Runtime de contenedores
+
+El {{< glossary_definition term_id="container-runtime" text="runtime de los contenedores" >}} es el software responsable de ejecutar los contenedores. Kubernetes soporta varios de
+ellos: [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) y cualquier implementación de la interfaz de runtime de contenedores de Kubernetes, o [Kubernetes CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
+
+## Addons
+
+Los _addons_ son pods y servicios que implementan funcionalidades del clúster. Estos pueden ser administrados
+por `Deployments`, `ReplicationControllers` y otros. Los _addons_ asignados a un espacio de nombres se crean en el espacio `kube-system`.
+
+Más abajo se describen algunos _addons_. Para una lista más completa de los _addons_ disponibles, por favor visite [Addons](/docs/concepts/cluster-administration/addons/).
+
+### DNS
+
+Si bien los otros _addons_ no son estrictamente necesarios, todos los clústers de Kubernetes deberían tener un [DNS interno del clúster](/docs/concepts/services-networking/dns-pod-service/) ya que la mayoría de los ejemplos lo requieren.
+
+El DNS interno del clúster es un servidor DNS, adicional a los que ya podrías tener en tu red, que sirve registros DNS a los servicios de Kubernetes.
+
+Los contenedores que son iniciados por Kubernetes incluyen automáticamente este servidor en sus búsquedas DNS.
+
+### Interfaz Web (Dashboard) {#dashboard}
+
+El [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) es una interfaz Web de propósito general para clústeres de Kubernetes. Le permite a los usuarios administrar y resolver problemas que puedan presentar tanto las aplicaciones como el clúster.
+
+### Monitor de recursos de contenedores
+
+El [Monitor de recursos de contenedores](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) almacena
+de forma centralizada series de tiempo con métricas sobre los contenedores, y provee una interfaz para navegar estos
+datos.
+
+### Registros del clúster
+
+El mecanismo de [registros del clúster](/docs/concepts/cluster-administration/logging/) está a cargo de almacenar
+los registros de los contenedores de forma centralizada, proporcionando una interfaz de búsqueda y navegación.
diff --git a/content/es/docs/concepts/workloads/controllers/deployment.md b/content/es/docs/concepts/workloads/controllers/deployment.md
new file mode 100644
index 0000000000..89563b3b72
--- /dev/null
+++ b/content/es/docs/concepts/workloads/controllers/deployment.md
@@ -0,0 +1,1110 @@
+---
+title: Deployment
+feature:
+ title: Despliegues y _rollback_ automáticos
+ description: >
+ Kubernetes despliega los cambios a tu aplicación o su configuración de forma progresiva mientras monitoriza la salud de la aplicación para asegurarse que no elimina todas tus instancias al mismo tiempo. Si algo sale mal, Kubernetes revertirá el cambio por ti. Aprovéchate del creciente ecosistema de soluciones de despliegue.
+
+content_type: concept
+weight: 30
+---
+
+
+
+Un controlador de _Deployment_ proporciona actualizaciones declarativas para los [Pods](/docs/concepts/workloads/pods/pod/) y los
+[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
+
+Cuando describes el _estado deseado_ en un objeto Deployment, el controlador del Deployment se encarga de cambiar el estado actual al estado deseado de forma controlada.
+Puedes definir Deployments para crear nuevos ReplicaSets, o eliminar Deployments existentes y adoptar todos sus recursos con nuevos Deployments.
+
+{{< note >}}
+No deberías gestionar directamente los ReplicaSets que pertenecen a un Deployment.
+Todos los casos de uso deberían cubrirse manipulando el objeto Deployment.
+Considera la posibilidad de abrir un incidente en el repositorio principal de Kubernetes si tu caso de uso no está soportado por el motivo que sea.
+{{< /note >}}
+
+
+
+
+
+
+## Casos de uso
+
+A continuación se presentan los casos de uso típicos de los Deployments:
+
+* [Crear un Deployment para desplegar un ReplicaSet](#creating-a-deployment). El ReplicaSet crea los Pods en segundo plano. Comprueba el estado del despliegue para comprobar si es satisfactorio o no.
+* [Declarar el nuevo estado de los Pods](#updating-a-deployment) actualizando el PodTemplateSpec del Deployment. Ello crea un nuevo ReplicaSet y el Deployment gestiona el cambio de los Pods del viejo ReplicaSet al nuevo de forma controlada. Cada nuevo ReplicaSet actualiza la revisión del Deployment.
+* [Retroceder a una revisión anterior del Deployment](#rolling-back-a-deployment) si el estado actual de un Deployment no es estable. Cada retroceso actualiza la revisión del Deployment.
+* [Escalar horizontalmente el Deployment para soportar más carga](#scaling-a-deployment).
+* [Pausar el Deployment](#pausing-and-resuming-a-deployment) para aplicar múltiples arreglos a su PodTemplateSpec y, a continuación, reanúdalo para que comience un nuevo despliegue.
+* [Usar el estado del Deployment](#deployment-status) como un indicador de que el despliegue se ha atascado.
+* [Limpiar los viejos ReplicaSets](#clean-up-policy) que no necesites más.
+
+## Crear un Deployment
+
+El siguiente ejemplo de un Deployment crea un ReplicaSet para arrancar tres Pods con `nginx`:
+
+{{< codenew file="controllers/nginx-deployment.yaml" >}}
+
+En este ejemplo:
+
+* Se crea un Deployment denominado `nginx-deployment`, indicado a través del campo `.metadata.name`.
+* El Deployment crea tres Pods replicados, indicado a través del campo `replicas`.
+* El campo `selector` define cómo el Deployment identifica los Pods que debe gestionar.
+ En este caso, simplemente seleccionas una etiqueta que se define en la plantilla Pod (`app: nginx`).
+ Sin embargo, es posible definir reglas de selección más sofisticadas,
+ siempre que la plantilla Pod misma satisfaga la regla.
+
+ {{< note >}}
+ `matchLabels` es un mapa de entradas {clave,valor}. Una entrada simple {clave,valor} en el mapa `matchLabels`
+ es equivalente a un elemento de `matchExpressions` cuyo campo sea la "clave", el operador sea "In",
+ y la matriz de valores contenga únicamente un "valor". Todos los requisitos se concatenan con AND.
+ {{< /note >}}
+
+* El campo `template` contiene los siguientes sub-campos:
+ * Los Pods se etiquetan como `app: nginx` usando el campo `labels`.
+ * La especificación de la plantilla Pod, o el campo `.template.spec`, indica
+ que los Pods ejecutan un contenedor, `nginx`, que utiliza la versión 1.7.9 de la imagen de `nginx` de
+ [Docker Hub](https://hub.docker.com/).
+ * Crea un contenedor y lo llamar `nginx` usando el campo `name`.
+ * Ejecuta la imagen `nginx` en su versión `1.7.9`.
+ * Abre el puerto `80` para que el contenedor pueda enviar y recibir tráfico.
+
+Para crear este Deployment, ejecuta el siguiente comando:
+
+```shell
+kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
+```
+
+{{< note >}}
+Debes indicar el parámetro `--record` para registrar el comando ejecutado en la anotación de recurso `kubernetes.io/change-cause`.
+Esto es útil para futuras introspecciones, por ejemplo para comprobar qué comando se ha ejecutado en cada revisión del Deployment.
+{{< /note >}}
+
+A continuación, ejecuta el comando `kubectl get deployments`. La salida debe ser parecida a la siguiente:
+
+```shell
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+nginx-deployment 3 0 0 0 1s
+```
+
+Cuando inspeccionas los Deployments de tu clúster, se muestran los siguientes campos:
+
+* `NAME` enumera los nombre de los Deployments del clúster.
+* `DESIRED` muestra el número deseado de _réplicas_ de la aplicación, que se define
+ cuando se crea el Deployment. Esto se conoce como el _estado deseado_.
+* `CURRENT` muestra cuántas réplicas se están ejecutando actualment.
+* `UP-TO-DATE` muestra el número de réplicas que se ha actualizado para alcanzar el estado deseado.
+* `AVAILABLE` muestra cuántas réplicas de la aplicación están disponibles para los usuarios.
+* `AGE` muestra la cantidad de tiempo que la aplicación lleva ejecutándose.
+
+Nótese cómo los valores de cada campo corresponden a los valores de la especificación del Deployment:
+
+* El número de réplicas deseadas es 3 de acuerdo con el campo `.spec.replicas`.
+* El número de réplicas actuales es 0 de acuerdo con el campo `.status.replicas`.
+* El número de réplicas actualizadas es 0 de acuerdo con el campo `.status.updatedReplicas`.
+* El número de réplicas disponibles es 0 de acuerdo con el campo `.status.availableReplicas`.
+
+Para ver el estado del Deployment, ejecuta el comando `kubectl rollout status deployment.v1.apps/nginx-deployment`. Este comando devuelve el siguiente resultado:
+
+```shell
+Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+deployment.apps/nginx-deployment successfully rolled out
+```
+
+Ejecuta de nuevo el comando `kubectl get deployments` unos segundos más tarde:
+
+```shell
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+nginx-deployment 3 3 3 3 18s
+```
+
+Fíjate que el Deployment ha creado todas las tres réplicas, y que todas las réplicas están actualizadas (contienen
+la última plantilla Pod) y están disponibles (el estado del Pod tiene el valor Ready al menos para el campo `.spec.minReadySeconds` del Deployment).
+
+Para ver el ReplicaSet (`rs`) creado por el Deployment, ejecuta el comando `kubectl get rs`:
+
+```shell
+NAME DESIRED CURRENT READY AGE
+nginx-deployment-75675f5897 3 3 3 18s
+```
+
+Fíjate que el nombre del ReplicaSet siempre se formatea con el patrón `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. La cadena aleatoria se
+genera de forma aleatoria y usa el pod-template-hash como semilla.
+
+Para ver las etiquetas generadas automáticamente en cada pod, ejecuta el comando `kubectl get pods --show-labels`. Se devuelve la siguiente salida:
+
+```shell
+NAME READY STATUS RESTARTS AGE LABELS
+nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
+nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
+nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
+```
+
+El ReplicaSet creado garantiza que hay tres Pods de `nginx` ejecutándose en todo momento.
+
+{{< note >}}
+En un Deployment, debes especificar un selector apropiado y etiquetas de plantilla Pod (en este caso,
+`app: nginx`). No entremezcles etiquetas o selectores con otros controladores (incluyendo otros Deployments y StatefulSets).
+Kubernetes no te impide que lo hagas, pero en el caso de que múltiples controladores tengan selectores mezclados, dichos controladores pueden entrar en conflicto y provocar resultados inesperados.
+{{< /note >}}
+
+### Etiqueta pod-template-hash
+
+{{< note >}}
+No cambies esta etiqueta.
+{{< /note >}}
+
+La etiqueta `pod-template-hash` es añadida por el controlador del Deployment a cada ReplicaSet que el Deployment crea o adopta.
+
+Esta etiqueta garantiza que todos los hijos ReplicaSets de un Deployment no se entremezclan. Se genera mediante una función hash aplicada al `PodTemplate` del ReplicaSet
+y usando el resultado de la función hash como el valor de la etiqueta que se añade al selector del ReplicaSet, en las etiquetas de la plantilla Pod,
+y en cualquier Pod existente que el ReplicaSet tenga.
+
+## Actualizar un Deployment
+
+{{< note >}}
+El lanzamiento de un Deployment se activa si y sólo si la plantilla Pod del Deployment (esto es, `.spec.template`)
+se cambia, por ejemplo si se actualiza las etiquetas o las imágenes de contenedor de la plantilla.
+Otras actualizaciones, como el escalado del Deployment, no conllevan un lanzamiento de despliegue.
+{{< /note >}}
+
+Asumiendo que ahora quieres actualizar los Pods nginx para que usen la imagen `nginx:1.9.1`
+en vez de la imagen `nginx:1.7.9`.
+
+```shell
+kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
+```
+```
+image updated
+```
+
+De forma alternativa, puedes `editar` el Deployment y cambiar el valor del campo `.spec.template.spec.containers[0].image` de `nginx:1.7.9` a `nginx:1.9.1`:
+
+```shell
+kubectl edit deployment.v1.apps/nginx-deployment
+```
+```
+deployment.apps/nginx-deployment edited
+```
+
+Para ver el estado del despliegue, ejecuta:
+
+```shell
+kubectl rollout status deployment.v1.apps/nginx-deployment
+```
+```
+Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+deployment.apps/nginx-deployment successfully rolled out
+```
+
+Cuando el despliegue funciona, puede que quieras `obtener` el Deployment:
+
+```shell
+kubectl get deployments
+```
+```
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+nginx-deployment 3 3 3 3 36s
+```
+
+El número de réplicas actualizadas indica que el Deployment ha actualizado las réplicas según la última configuración.
+Las réplicas actuales indican el total de réplicas que gestiona este Deployment, y las réplicas disponibles indican
+el número de réplicas actuales que están disponibles.
+
+Puedes ejecutar el comando `kubectl get rs` para ver que el Deployment actualizó los Pods creando un nuevo ReplicaSet y escalándolo
+hasta las 3 réplicas, así como escalando el viejo ReplicaSet a 0 réplicas.
+
+```shell
+kubectl get rs
+```
+```
+NAME DESIRED CURRENT READY AGE
+nginx-deployment-1564180365 3 3 3 6s
+nginx-deployment-2035384211 0 0 0 36s
+```
+
+Si ejecutas el comando `get pods` deberías ver los nuevos Pods:
+
+```shell
+kubectl get pods
+```
+```
+NAME READY STATUS RESTARTS AGE
+nginx-deployment-1564180365-khku8 1/1 Running 0 14s
+nginx-deployment-1564180365-nacti 1/1 Running 0 14s
+nginx-deployment-1564180365-z9gth 1/1 Running 0 14s
+```
+
+La próxima vez que quieras actualizar estos Pods, sólo necesitas actualizar la plantilla Pod del Deployment otra vez.
+
+El Deployment permite garantizar que sólo un número determinado de Pods puede eliminarse mientras se están actualizando.
+Por defecto, garantiza que al menos el 25% menos del número deseado de Pods se está ejecutando (máx. 25% no disponible).
+
+El Deployment tmabién permite garantizar que sólo un número determinado de Pods puede crearse por encima del número deseado de
+Pods. Por defecto, garantiza que al menos el 25% más del número deseado de Pods se está ejecutando (máx. 25% de aumento).
+
+Por ejemplo, si miras detenidamente el Deployment de arriba, verás que primero creó un Pod,
+luego eliminó algunos viejos Pods y creó otros nuevos. No elimina los viejos Pods hasta que un número suficiente de
+nuevos Pods han arrancado, y no crea nuevos Pods hasta que un número suficiente de viejos Pods se han eliminado.
+De esta forma, asegura que el número de Pods disponibles siempre es al menos 2, y el número de Pods totales es cómo máximo 4.
+
+```shell
+kubectl describe deployments
+```
+```
+Name: nginx-deployment
+Namespace: default
+CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000
+Labels: app=nginx
+Annotations: deployment.kubernetes.io/revision=2
+Selector: app=nginx
+Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
+StrategyType: RollingUpdate
+MinReadySeconds: 0
+RollingUpdateStrategy: 25% max unavailable, 25% max surge
+Pod Template:
+ Labels: app=nginx
+ Containers:
+ nginx:
+ Image: nginx:1.9.1
+ Port: 80/TCP
+ Environment:
+ Mounts:
+ Volumes:
+Conditions:
+ Type Status Reason
+ ---- ------ ------
+ Available True MinimumReplicasAvailable
+ Progressing True NewReplicaSetAvailable
+OldReplicaSets:
+NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3
+ Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1
+ Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2
+ Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2
+ Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1
+ Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
+ Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
+```
+
+Aquí puedes ver que cuando creaste por primera vez el Deployment, este creó un ReplicaSet (nginx-deployment-2035384211)
+y lo escaló a 3 réplicas directamente. Cuando actualizaste el Deployment, creó un nuevo ReplicaSet
+(nginx-deployment-1564180365) y lo escaló a 1 y entonces escaló el viejo ReplicaSet a 2, de forma que al menos
+hubiera 2 Pods disponibles y como mucho 4 Pods en total en todo momento. Entonces, continuó escalando
+el nuevo y el viejo ReplicaSet con la misma estrategia de actualización continua. Finalmente, el nuevo ReplicaSet acaba con 3 réplicas
+disponibles, y el viejo ReplicaSet se escala a 0.
+
+### Sobrescritura (o sea, múltiples actualizaciones a la vez)
+
+Cada vez que el controlador del Deployment observa un nuevo objeto de despliegue, se crea un ReplicaSet para arrancar
+los Pods deseados si es que no existe otro ReplicaSet haciéndolo. Los ReplicaSet existentes que controlan los Pods cuyas etiquetas
+coinciden con el valor del campo `.spec.selector`, pero cuya plantilla no coincide con el valor del campo `.spec.template` se reducen. Al final,
+el nuevo ReplicaSet se escala hasta el valor del campo `.spec.replicas` y todos los viejos ReplicaSets se escalan a 0.
+
+Si actualizas un Deployment mientras otro despliegue está en curso, el Deployment creará un nuevo ReplicaSet
+como consecuencia de la actualización y comenzará a escalarlo, y sobrescribirá al ReplicaSet que estaba escalando anteriormente
+ -- lo añadirá a su lista de viejos ReplicaSets y comenzará a reducirlos.
+
+Por ejemplo, supongamos que creamos un Deployment para crear 5 réplicas de `nginx:1.7.9`,
+pero entonces actualizamos el Deployment para crear 5 réplicas de `nginx:1.9.1` cuando sólo se ha creado 3
+réplicas de `nginx:1.7.9`. En este caso, el Deployment comenzará automáticamente a matar los 3 Pods de `nginx:1.7.9`
+que había creado, y empezará a crear los Pods de `nginx:1.9.1`. Es decir, no esperará a que se creen las 5 réplicas de `nginx:1.7.9`
+antes de aplicar la nueva configuración.
+
+### Actualizaciones del selector de etiquetas
+
+No se recomienda hacer cambios al selector del etiquetas y, por ello, se aconseja encarecidamente planificar el valor de dichos selectores por adelantado.
+En cualquier caso, si necesitas cambiar un selector de etiquetas, hazlo con mucho cuidado y asegúrate que entiendes todas sus implicaciones.
+
+{{< note >}}
+En la versión `apps/v1` de la API, el selector de etiquetas del Deployment es inmutable una vez se ha creado.
+{{< /note >}}
+
+* Las adiciones posteriores al selector obligan también a actualizar las etiquetas de la plantilla Pod en la especificación del Deployment con los nuevos valores,
+ya que de lo contrario se devolvería un error. Este cambio no es de superposición, es decir, que el nuevo selector
+no selecciona los ReplicaSets y Pods creados con el viejo selector, lo que provoca que todos los viejos ReplicaSets se marquen como huérfanos y
+la creación de un nuevo ReplicaSet.
+* Las actualizaciones de selector -- esto es, cambiar el valor actual en una clave de selector -- provocan el mismo comportamiento que las adiciones.
+* Las eliminaciones de selector -- esto es, eliminar una clave actual del selector del Deployment -- no necesitan de cambios en las etiquetas de la plantilla Pod.
+No se marca ningún ReplicaSet existente como huérfano, y no se crea ningún ReplicaSet nuevo, pero debe tenerse en cuenta que
+la etiqueta eliminada todavía existe en los Pods y ReplicaSets que se están ejecutando.
+
+## Revertir un Deployment
+
+En ocasiones necesitas revertir un Deployment; por ejemplo, cuando el Deployment no es estable, como cuando no para de reiniciarse.
+Por defecto, toda la historia de despliegue del Deployment se mantiene en el sistema de forma que puedes revertir en cualquier momento
+(se puede modificar este comportamiento cambiando el límite de la historia de revisiones de modificaciones).
+
+{{< note >}}
+Cuando se lanza el despligue de un Deployment, se crea una nueva revisión. Esto quiere decir que
+la nueva revisión se crea si y sólo si la plantilla Pod del Deployment (`.spec.template`) se cambia;
+por ejemplo, si cambias las etiquetas o la imagen del contenedor de la plantilla.
+Otras actualizaciones, como escalar el Deployment,
+no generan una nueva revisión del Deployment, para poder facilitar el escalado manual simultáneo - o auto-escalado.
+Esto significa que cuando reviertes a una versión anterior, sólo la parte de la plantilla Pod del Deployment se revierte.
+{{< /note >}}
+
+Vamos a suponer que hemos cometido un error al actualizar el Deployment, poniendo como nombre de imagen `nginx:1.91` en vez de `nginx:1.9.1`:
+
+```shell
+kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
+```
+```
+deployment.apps/nginx-deployment image updated
+```
+
+El despliegue se atasca y no progresa.
+
+```shell
+kubectl rollout status deployment.v1.apps/nginx-deployment
+```
+```
+Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
+```
+
+Presiona Ctrl-C para detener la monitorización del despliegue de arriba. Para obtener más información sobre despliegues atascados,
+[lee más aquí](#deployment-status).
+
+Verás que el número de réplicas viejas (nginx-deployment-1564180365 y nginx-deployment-2035384211) es 2, y el número de nuevas réplicas (nginx-deployment-3066724191) es 1.
+
+```shell
+kubectl get rs
+```
+```
+NAME DESIRED CURRENT READY AGE
+nginx-deployment-1564180365 3 3 3 25s
+nginx-deployment-2035384211 0 0 0 36s
+nginx-deployment-3066724191 1 1 0 6s
+```
+
+Echando un vistazo a los Pods creados, verás que uno de los Pods creados por el nuevo ReplicaSet está atascado en un bucle intentando bajar la imagen:
+
+```shell
+kubectl get pods
+```
+```
+NAME READY STATUS RESTARTS AGE
+nginx-deployment-1564180365-70iae 1/1 Running 0 25s
+nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
+nginx-deployment-1564180365-hysrc 1/1 Running 0 25s
+nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
+```
+
+{{< note >}}
+El controlador del Deployment parará el despliegue erróneo de forma automática, y detendrá el escalado del nuevo
+ReplicaSet. Esto depende de los parámetros del rollingUpdate (`maxUnavailable` específicamente) que hayas configurado.
+Kubernetes por defecto establece el valor en el 25%.
+{{< /note >}}
+
+```shell
+kubectl describe deployment
+```
+```
+Name: nginx-deployment
+Namespace: default
+CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
+Labels: app=nginx
+Selector: app=nginx
+Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable
+StrategyType: RollingUpdate
+MinReadySeconds: 0
+RollingUpdateStrategy: 25% max unavailable, 25% max surge
+Pod Template:
+ Labels: app=nginx
+ Containers:
+ nginx:
+ Image: nginx:1.91
+ Port: 80/TCP
+ Host Port: 0/TCP
+ Environment:
+ Mounts:
+ Volumes:
+Conditions:
+ Type Status Reason
+ ---- ------ ------
+ Available True MinimumReplicasAvailable
+ Progressing True ReplicaSetUpdated
+OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
+NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
+Events:
+ FirstSeen LastSeen Count From SubobjectPath Type Reason Message
+ --------- -------- ----- ---- ------------- -------- ------ -------
+ 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
+ 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
+ 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
+ 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
+ 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1
+ 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
+ 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
+ 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
+```
+
+Para arreglar este problema, necesitas volver a una revisión previa del Deployment que sea estable.
+
+### Comprobar la Historia de Despliegues de un Deployment
+
+Primero, comprobemos las revisiones de este despliegue:
+
+```shell
+kubectl rollout history deployment.v1.apps/nginx-deployment
+```
+```
+deployments "nginx-deployment"
+REVISION CHANGE-CAUSE
+1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
+2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
+3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
+```
+En el momento de la creación, el mensaje en `CHANGE-CAUSE` se copia de la anotación `kubernetes.io/change-cause` del Deployment a sus revisiones. Podrías indicar el mensaje `CHANGE-CAUSE`:
+
+* Anotando el Deployment con el comando `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`
+* Añadiendo el parámetro `--record` para registrar el comando `kubectl` que está haciendo cambios en el recurso.
+* Manualmente editando el manifiesto del recursos.
+
+Para ver más detalles de cada revisión, ejecuta:
+
+```shell
+kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
+```
+```
+deployments "nginx-deployment" revision 2
+ Labels: app=nginx
+ pod-template-hash=1159050644
+ Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
+ Containers:
+ nginx:
+ Image: nginx:1.9.1
+ Port: 80/TCP
+ QoS Tier:
+ cpu: BestEffort
+ memory: BestEffort
+ Environment Variables:
+ No volumes.
+```
+
+### Retroceder a una Revisión Previa
+
+Ahora has decidido que quieres deshacer el despliegue actual y retrocederlo a la revisión previa:
+
+```shell
+kubectl rollout undo deployment.v1.apps/nginx-deployment
+```
+```
+deployment.apps/nginx-deployment
+```
+
+Alternativamente, puedes retroceder a una revisión específica con el parámetro `--to-revision`:
+
+```shell
+kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
+```
+```
+deployment.apps/nginx-deployment
+```
+
+Para más detalles acerca de los comandos relacionados con las revisiones de un Deployment, echa un vistazo a [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout).
+
+El Deployment se ha revertido ahora a una revisión previa estable. Como se puede comprobar, el controlador del Deployment genera un evento `DeploymentRollback`
+al retroceder a la revisión 2.
+
+```shell
+kubectl get deployment nginx-deployment
+```
+```
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+nginx-deployment 3 3 3 3 30m
+```
+
+```shell
+kubectl describe deployment nginx-deployment
+```
+```
+Name: nginx-deployment
+Namespace: default
+CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
+Labels: app=nginx
+Annotations: deployment.kubernetes.io/revision=4
+ kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
+Selector: app=nginx
+Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
+StrategyType: RollingUpdate
+MinReadySeconds: 0
+RollingUpdateStrategy: 25% max unavailable, 25% max surge
+Pod Template:
+ Labels: app=nginx
+ Containers:
+ nginx:
+ Image: nginx:1.9.1
+ Port: 80/TCP
+ Host Port: 0/TCP
+ Environment:
+ Mounts:
+ Volumes:
+Conditions:
+ Type Status Reason
+ ---- ------ ------
+ Available True MinimumReplicasAvailable
+ Progressing True NewReplicaSetAvailable
+OldReplicaSets:
+NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created)
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3
+ Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1
+ Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2
+ Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2
+ Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1
+ Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3
+ Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0
+ Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1
+ Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2
+ Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0
+```
+
+## Escalar un Deployment
+
+Puedes escalar un Deployment usando el siguiente comando:
+
+```shell
+kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
+```
+```
+deployment.apps/nginx-deployment scaled
+```
+
+Asumiendo que se ha habilitado el [escalado horizontal de pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
+en tu clúster, puedes configurar un auto-escalado para tu Deployment y elegir el mínimo y máximo número de Pods
+que quieres ejecutar en base al uso de CPU de tus Pods actuales.
+
+```shell
+kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
+```
+```
+deployment.apps/nginx-deployment scaled
+```
+
+### Escalado proporcional
+
+La actualización continua de los Deployments permite la ejecución de múltiples versiones de una aplicación al mismo tiempo.
+Cuando tú o un auto-escalado escala un Deployment con actualización continua que está en medio de otro despliegue (bien en curso o pausado),
+entonces el controlador del Deployment balanceará las réplicas adicionales de los ReplicaSets activos (ReplicaSets con Pods)
+para así poder mitigar el riesgo. Esto se conoce como *escalado proporcional*.
+
+Por ejemplo, imagina que estás ejecutando un Deployment con 10 réplicas, donde [maxSurge](#max-surge)=3, y [maxUnavailable](#max-unavailable)=2.
+
+```shell
+kubectl get deploy
+```
+```
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+nginx-deployment 10 10 10 10 50s
+```
+
+Si actualizas a una nueva imagen que no puede descargarse desde el clúster:
+
+```shell
+kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
+```
+```
+deployment.apps/nginx-deployment image updated
+```
+
+La actualización de la imagen arranca un nuevo despliegue con el ReplicaSet nginx-deployment-1989198191,
+pero se bloquea debido al requisito `maxUnavailable` indicado arriba:
+
+```shell
+kubectl get rs
+```
+```
+NAME DESIRED CURRENT READY AGE
+nginx-deployment-1989198191 5 5 0 9s
+nginx-deployment-618515232 8 8 8 1m
+```
+
+Y entonces se origina una nueva petición de escalado para el Deployment. El auto-escalado incrementa las réplicas del Deployment
+a 15. El controlador del Deployment necesita ahora decidir dónde añadir esas nuevas 5 réplicas.
+Si no estuvieras usando el escalado proporcional, las 5 se añadirían al nuevo ReplicaSet. Pero con el escalado proporcional,
+las réplicas adicionales se distribuyen entre todos los ReplicaSets. Las partes más grandes van a los ReplicaSets
+con el mayor número de réplicas y las partes más pequeñas van a los ReplicaSets con menos réplicas. Cualquier resto sobrante se añade
+al ReplicaSet con mayor número de réplicas. Aquellos ReplicaSets con 0 réplicas no se escalan.
+
+En nuestro ejemplo anterior, se añadirán 3 réplicas al viejo ReplicaSet y 2 réplicas al nuevo ReplicaSet.
+EL proceso de despliegue debería al final mover todas las réplicas al nuevo ReplicaSet, siempre que las nuevas
+réplicas arranquen positivamente.
+
+```shell
+kubectl get deploy
+```
+```
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+nginx-deployment 15 18 7 8 7m
+```
+
+```shell
+kubectl get rs
+```
+```
+NAME DESIRED CURRENT READY AGE
+nginx-deployment-1989198191 7 7 0 7m
+nginx-deployment-618515232 11 11 11 7m
+```
+
+## Pausar y Reanudar un Deployment
+
+Puedes pausar un Deployment antes de arrancar una o más modificaciones y luego reanudarlo. Esto te permite aplicar múltiples arreglos
+entre la pausa y la reanudación sin necesidad de arrancar despliegues innecesarios.
+
+Por ejemplo, con un Deployment que acaba de crearse:
+
+```shell
+kubectl get deploy
+```
+```
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+nginx 3 3 3 3 1m
+```
+```shell
+kubectl get rs
+```
+```
+NAME DESIRED CURRENT READY AGE
+nginx-2142116321 3 3 3 1m
+```
+
+Lo pausamos ejecutando el siguiente comando:
+
+```shell
+kubectl rollout pause deployment.v1.apps/nginx-deployment
+```
+```
+deployment.apps/nginx-deployment paused
+```
+
+Y luego actualizamos la imagen del Deployment:
+
+```shell
+kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
+```
+```
+deployment.apps/nginx-deployment image updated
+```
+
+Nótese que no se arranca ningún despliegue nuevo:
+
+```shell
+kubectl rollout history deployment.v1.apps/nginx-deployment
+```
+```
+deployments "nginx"
+REVISION CHANGE-CAUSE
+1
+```
+
+```shell
+kubectl get rs
+```
+```
+NAME DESIRED CURRENT READY AGE
+nginx-2142116321 3 3 3 2m
+```
+
+Puedes realizar tantas modificaciones como quieras, por ejemplo, para actualizar los recursos a utilizar:
+
+```shell
+kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
+```
+```
+deployment.apps/nginx-deployment resource requirements updated
+```
+
+El estado inicial del Deployment anterior a la pausa continuará su función, pero las nuevas modificaciones
+del Deployment no tendrán efecto ya que el Deployment está pausado.
+
+Al final, reanuda el Deployment y observa cómo se genera un nuevo ReplicaSet con todos los cambios:
+
+```shell
+kubectl rollout resume deployment.v1.apps/nginx-deployment
+```
+
+```
+deployment.apps/nginx-deployment resumed
+```
+
+```shell
+kubectl get rs -w
+```
+
+```
+NAME DESIRED CURRENT READY AGE
+nginx-2142116321 2 2 2 2m
+nginx-3926361531 2 2 0 6s
+nginx-3926361531 2 2 1 18s
+nginx-2142116321 1 2 2 2m
+nginx-2142116321 1 2 2 2m
+nginx-3926361531 3 2 1 18s
+nginx-3926361531 3 2 1 18s
+nginx-2142116321 1 1 1 2m
+nginx-3926361531 3 3 1 18s
+nginx-3926361531 3 3 2 19s
+nginx-2142116321 0 1 1 2m
+nginx-2142116321 0 1 1 2m
+nginx-2142116321 0 0 0 2m
+nginx-3926361531 3 3 3 20s
+
+```
+```shell
+kubectl get rs
+```
+```
+NAME DESIRED CURRENT READY AGE
+nginx-2142116321 0 0 0 2m
+nginx-3926361531 3 3 3 28s
+```
+
+{{< note >}}
+No se puede revertir un Deployment pausado hasta que se vuelve a reanudar.
+{{< /note >}}
+
+## Estado del Deployment
+
+Un Deployment pasa por varios estados a lo largo de su ciclo de vida. Así, puede estar [progresando](#progressing-deployment) mientras
+se despliega un nuevo ReplicaSet, puede estar [completo](#complete-deployment), o puede quedar en estado [fallido](#failed-deployment).
+
+### Progresar un Deployment
+
+Kubernetes marca un Deployment como _progresando_ cuando se realiza cualquiera de las siguientes tareas:
+
+* El Deployment crea un nuevo ReplicaSet.
+* El Deployment está escalando su ReplicaSet más nuevo.
+* El Deployment está reduciendo su(s) ReplicaSet(s) más antiguo(s).
+* Hay nuevos Pods disponibles y listos (listo por lo menos [MinReadySeconds](#min-ready-seconds)).
+
+Puedes monitorizar el progreso de un Deployment usando el comando `kubectl rollout status`.
+
+### Completar un Deployment
+
+Kubernetes marca un Deployment como _completado_ cuando presenta las siguientes características:
+
+* Todas las réplicas asociadas con el Deployment han sido actualizadas a la última versión indicada, lo cual quiere decir
+que todas las actualizaciones se han completado.
+* Todas las réplicas asociadas con el Deployment están disponibles.
+* No están ejecutándose viejas réplicas del Deployment.
+
+Puedes comprobar si un Deployment se ha completado usando el comando `kubectl rollout status`. Si el despliegue se ha completado
+de forma satisfactoria, el comando `kubectl rollout status` devuelve un código 0 de salida.
+
+```shell
+kubectl rollout status deployment.v1.apps/nginx-deployment
+```
+```
+Waiting for rollout to finish: 2 of 3 updated replicas are available...
+deployment.apps/nginx-deployment successfully rolled out
+$ echo $?
+0
+```
+
+### Deployment fallido
+
+Tu Deployment puede quedarse bloqueado intentando desplegar su nuevo ReplicaSet sin nunca completarse. Esto puede ocurrir
+debido a algunos de los factores siguientes:
+
+* Cuota insuficiente
+* Fallos en la prueba de estar listo
+* Errores en la descarga de imágenes
+* Permisos insuficientes
+* Rangos de límites de recursos
+* Mala configuración del motor de ejecución de la aplicación
+
+Una forma de detectar este tipo de situación es especificar un parámetro de vencimiento en la especificación de tu Deployment:
+([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `.spec.progressDeadlineSeconds` denota el número
+de segundos que el controlador del Deployment debe esperar antes de indicar (en el estado del Deployment) que el
+Deployment no avanza.
+
+El siguiente comando `kubectl` configura el campo `progressDeadlineSeconds` para forzar al controlador a
+informar de la falta de avance de un Deployment después de 10 minutos:
+
+```shell
+kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
+```
+```
+deployment.apps/nginx-deployment patched
+```
+Una vez que se ha excedido el vencimiento, el controlador del Deployment añade una DeploymentCondition
+con los siguientes atributos al campo `.status.conditions` del Deployment:
+
+* Type=Progressing
+* Status=False
+* Reason=ProgressDeadlineExceeded
+
+Ver las [convenciones de la API de Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) para más información acerca de las condiciones de estado.
+
+{{< note >}}
+Kubernetes no emprenderá ninguna acción ante un Deployment parado que no sea la de reportar el estado mediante
+`Reason=ProgressDeadlineExceeded`. Los orquestradores de alto nivel pueden aprovecharse y actuar consecuentemente, por ejemplo,
+retrocediendo el Deployment a su versión previa.
+{{< /note >}}
+
+{{< note >}}
+Si pausas un Deployment, Kubernetes no comprueba el avance en base al vencimiento indicado. Así, es posible pausar
+de forma segura un Deployment en medio de un despliegue y reanudarlo sin que se arranque el estado de exceso de vencimiento.
+{{< /note >}}
+
+Puede que notes errores transitorios en tus Deployments, bien debido a un tiempo de vencimiento muy pequeño que hayas configurado
+o bien a cualquier otro tipo de error que puede considerarse como transitorio. Por ejemplo,
+supongamos que no tienes suficiente cuota. Si describes el Deployment, te darás cuenta de la sección siguiente:
+
+```shell
+kubectl describe deployment nginx-deployment
+```
+```
+<...>
+Conditions:
+ Type Status Reason
+ ---- ------ ------
+ Available True MinimumReplicasAvailable
+ Progressing True ReplicaSetUpdated
+ ReplicaFailure True FailedCreate
+<...>
+```
+
+Si ejecutas el comando `kubectl get deployment nginx-deployment -o yaml`, el estado del Deployment puede parecerse a:
+
+```
+status:
+ availableReplicas: 2
+ conditions:
+ - lastTransitionTime: 2016-10-04T12:25:39Z
+ lastUpdateTime: 2016-10-04T12:25:39Z
+ message: Replica set "nginx-deployment-4262182780" is progressing.
+ reason: ReplicaSetUpdated
+ status: "True"
+ type: Progressing
+ - lastTransitionTime: 2016-10-04T12:25:42Z
+ lastUpdateTime: 2016-10-04T12:25:42Z
+ message: Deployment has minimum availability.
+ reason: MinimumReplicasAvailable
+ status: "True"
+ type: Available
+ - lastTransitionTime: 2016-10-04T12:25:39Z
+ lastUpdateTime: 2016-10-04T12:25:39Z
+ message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
+ object-counts, requested: pods=1, used: pods=3, limited: pods=2'
+ reason: FailedCreate
+ status: "True"
+ type: ReplicaFailure
+ observedGeneration: 3
+ replicas: 2
+ unavailableReplicas: 2
+```
+
+Al final, una vez que se supera el vencimiento del progreso del Deployment, Kubernetes actualiza el estado
+y la razón de el estado de progreso:
+
+```
+Conditions:
+ Type Status Reason
+ ---- ------ ------
+ Available True MinimumReplicasAvailable
+ Progressing False ProgressDeadlineExceeded
+ ReplicaFailure True FailedCreate
+```
+
+Puedes solucionar un problema de cuota insuficiente simplemente reduciendo el número de réplicas de tu Deployment, reduciendo
+otros controladores que puedas estar ejecutando, o incrementando la cuota en tu espacio de nombres. Si una vez satisfechas las condiciones de tu cuota,
+el controlador del Deployment completa el despliegue, entonces verás que el estado del Deployment se actualiza al estado satisfactorio (`Status=True` y `Reason=NewReplicaSetAvailable`).
+
+```
+Conditions:
+ Type Status Reason
+ ---- ------ ------
+ Available True MinimumReplicasAvailable
+ Progressing True NewReplicaSetAvailable
+```
+
+`Type=Available` con `Status=True` significa que tu Deployment tiene disponibilidad mínima. La disponibilidad mínima se prescribe
+mediante los parámetros indicados en la estrategia de despligue. `Type=Progressing` con `Status=True` significa que tu Deployment
+está bien en medio de un despliegue y está progresando o bien que se ha completado de forma satisfactoria y el número mínimo
+requerido de nuevas réplicas ya está disponible (ver la Razón del estado para cada caso particular - en nuestro caso
+`Reason=NewReplicaSetAvailable` significa que el Deployment se ha completado).
+
+Puedes comprobar si un Deployment ha fallado en su progreso usando el comando `kubectl rollout status`. `kubectl rollout status`
+devuelve un código de salida distinto de 0 si el Deployment ha excedido su tiempo de vencimiento.
+
+```shell
+kubectl rollout status deployment.v1.apps/nginx-deployment
+```
+```
+Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+error: deployment "nginx" exceeded its progress deadline
+$ echo $?
+1
+```
+
+### Actuar ante un despliegue fallido
+
+Todas las acciones que aplican a un Deployment completado también aplican a un Deployment fallido. Puedes escalarlo/reducirlo, retrocederlo
+a una revisión previa, o incluso pausarlo si necesitas realizar múltiples cambios a la plantilla Pod del Deployment.
+
+## Regla de Limpieza
+
+Puedes configurar el campo `.spec.revisionHistoryLimit` de un Deployment para especificar cuántos ReplicaSets viejos quieres conservar
+para este Deployment. El resto será eliminado en segundo plano. Por defecto, es 10.
+
+{{< note >}}
+Poner este campo de forma explícita a 0 resulta en la limpieza de toda la historia de tu Deployment,
+por lo que tu Deployment no podrá retroceder a revisiones previas.
+{{< /note >}}
+
+## Casos de Uso
+
+### Despligue Canary
+
+Si quieres desplegar nuevas versiones a un sub-conjunto de usuarios o servidores usando el Deployment,
+puedes hacerlo creando múltiples Deployments, uno para cada versión nueva, siguiendo el patrón canary descrito en
+[gestionar recursos](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
+
+## Escribir una especificación de Deployment
+
+Al igual que con el resto de configuraciones de Kubernetes, un Deployment requiere los campos `apiVersion`, `kind`, y `metadata`.
+Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos acerca de [desplegar aplicaciones](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
+configurar contenedores, y [usar kubectl para gestionar recursos](/docs/concepts/overview/object-management-kubectl/overview/).
+
+Un Deployment también necesita una [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
+
+### Plantilla Pod
+
+Tanto `.spec.template` como `.spec.selector` sin campos obligatorios dentro de `.spec`.
+
+El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/),
+excepto por el hecho de que está anidado y no tiene `apiVersion` ni `kind`.
+
+Junto con los campos obligatorios de un Pod, una plantilla Pod de un Deployment debe indicar las etiquetas
+y las reglas de reinicio apropiadas. Para el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver [selector](#selector)).
+
+Únicamente se permite una [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) igual a `Always`,
+que es el valor por defecto si no se indica.
+
+### Réplicas
+
+`.spec.replicas` es un campo opcional que indica el número de Pods deseados. Su valor por defecto es 1.
+
+### Selector
+
+`.spec.selector` es un campo opcional que indica un [selector de etiquetas](/docs/concepts/overview/working-with-objects/labels/)
+para los Pods objetivo del deployment.
+
+`.spec.selector` debe coincidir con `.spec.template.metadata.labels`, o será descartado por la API.
+
+A partir de la versión `apps/v1` de la API, `.spec.selector` y `.metadata.labels` no toman como valor por defecto el valor de `.spec.template.metadata.labels` si no se indica.
+Por ello, debe especificarse de forma explícita. Además hay que mencionar que `.spec.selector` es inmutable tras la creación del Deployment en `apps/v1`.
+
+Un Deployment puede finalizar aquellos Pods cuyas etiquetas coincidan con el selector si su plantilla es diferente
+de `.spec.template` o si el número total de dichos Pods excede `.spec.replicas`. Arranca nuevos
+Pods con `.spec.template` si el número de Pods es menor que el número deseado.
+
+{{< note >}}
+No deberías crear otros Pods cuyas etiquetas coincidan con este selector, ni directamente creando
+otro Deployment, ni creando otro controlador como un ReplicaSet o un ReplicationController. Si lo haces,
+el primer Deployment pensará que también creó esos otros Pods. Kubernetes no te impide hacerlo.
+{{< /note >}}
+
+Si tienes múltiples controladores que entremezclan sus selectores, dichos controladores competirán entre ellos
+y no se comportarán de forma correcta.
+
+### Estrategia
+
+`.spec.strategy` especifica la estrategia usada para remplazar los Pods viejos con los nuevos.
+`.spec.strategy.type` puede tener el valor "Recreate" o "RollingUpdate". "RollingUpdate" el valor predeterminado.
+
+#### Despliegue mediante recreación
+
+Todos los Pods actuales se eliminan antes de que los nuevos se creen cuando `.spec.strategy.type==Recreate`.
+
+#### Despliegue mediante actualización continua
+
+El Deployment actualiza los Pods en modo de [actualización continua](/docs/tasks/run-application/rolling-update-replication-controller/)
+cuando `.spec.strategy.type==RollingUpdate`. Puedes configurar los valores de `maxUnavailable` y `maxSurge`
+para controlar el proceso de actualización continua.
+
+##### Número máximo de pods no disponibles
+
+`.spec.strategy.rollingUpdate.maxUnavailable` es un campo opcional que indica el número máximo
+de Pods que pueden no estar disponibles durante el proceso de actualización. El valor puede ser un número absoluto (por ejemplo, 5)
+o un porcentaje de los Pods deseados (por ejemplo, 10%). El número absoluto se calcula a partir del porcentaje
+con redondeo a la baja. El valor no puede ser 0 si `.spec.strategy.rollingUpdate.maxSurge` es 0. El valor predeterminado es 25%.
+
+Por ejemplo, cuando este valor es 30%, el ReplicaSet viejo puede escalarse al 70% de los
+Pods deseados de forma inmediata tras comenzar el proceso de actualización. Una vez que los Pods están listos,
+el ReplicaSet viejo puede reducirse aún mas, seguido de un escalado del nuevo ReplicaSet,
+asegurándose que el número total de Pods disponibles en todo momento durante la actualización
+es de al menos el 70% de los Pods deseados.
+
+##### Número máximo de pods por encima del número deseado
+
+`.spec.strategy.rollingUpdate.maxSurge` es un campo opcional que indica el número máximo de Pods
+que puede crearse por encima del número deseado de Pods. El valor puede ser un número absoluto (por ejemplo, 5)
+o un porcentaje de los Pods deseados (por ejemplo, 10%). El valor no puede ser 0 si `MaxUnavailable` es 0.
+El número absoluto se calcula a partir del porcentaje con redondeo al alza. El valor predeterminado es 25%.
+
+Por ejemplo, cuando este valor es 30%, el nuevo ReplicaSet puede escalarse inmediatamente cuando
+comienza la actualización continua, de forma que el número total de Pods viejos y nuevos no
+excede el 130% de los Pods deseados. Una vez que los viejos Pods se han eliminado, el nuevo ReplicaSet
+puede seguir escalándose, asegurándose que el número total de Pods ejecutándose en todo momento
+durante la actualización es como mucho del 130% de los Pods deseados.
+
+### Segundos para vencimiento del progreso
+
+`.spec.progressDeadlineSeconds` es un campo opcional que indica el número de segundos que quieres
+esperar a que tu Deployment avance antes de que el sistema reporte que dicho Deployment
+[ha fallado en su avance](#failed-deployment) - expresado como un estado con `Type=Progressing`, `Status=False`.
+y `Reason=ProgressDeadlineExceeded` en el recurso. El controlador del Deployment seguirá intentando
+el despliegue. En el futuro, una vez que se implemente el retroceso automático, el controlador del Deployment
+retrocederá el despliegue en cuanto detecte ese estado.
+
+Si se especifica, este campo debe ser mayor que `.spec.minReadySeconds`.
+
+### Tiempo mínimo para considerar el Pod disponible
+
+`.spec.minReadySeconds` es un campo opcional que indica el número mínimo de segundos en que
+un Pod recién creado debería estar listo sin que falle ninguno de sus contenedores, para que se considere disponible.
+Por defecto su valor es 0 (el Pod se considera disponible en el momento que está listo). Para aprender más acerca de
+cuándo un Pod se considera que está listo, ver las [pruebas de contenedor](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
+
+### Vuelta atrás
+
+El campo `.spec.rollbackTo` se ha quitado de las versiones `extensions/v1beta1` y `apps/v1beta1` de la API, y ya no se permite en las versiones de la API a partir de `apps/v1beta2`.
+En su caso, se debería usar `kubectl rollout undo`, tal y como se explicó en [Retroceder a una Revisión Previa](#rolling-back-to-a-previous-revision).
+
+### Límite del histórico de revisiones
+
+La historia de revisiones de un Deployment se almacena en los ReplicaSets que este controla.
+
+`.spec.revisionHistoryLimit` es un campo opcional que indica el número de ReplicaSets viejos a retener
+para permitir los retrocesos. Estos ReplicaSets viejos consumen recursos en `etcd` y rebosan la salida de `kubectl get rs`.
+La configuración de cada revisión de Deployment se almacena en sus ReplicaSets;
+por lo tanto, una vez que se elimina el ReplicaSet viejo, se pierde la posibilidad de retroceder a dicha revisión del Deployment.
+Por defecto, se retienen hasta 10 ReplicaSets viejos; pero su valor ideal depende de la frecuencia y la estabilidad de los nuevos Deployments.
+
+De forma más específica, si ponemos este campo a cero quiere decir que todos los ReplicaSets viejos con 0 réplicas se limpiarán.
+En este caso, el nuevo despliegue del Deployment no se puede deshacer, ya que su historia de revisiones se habrá limpiado.
+
+### Pausa
+
+`.spec.paused` es un campo booleano opcional para pausar y reanudar un Deployment. La única diferencia entre
+un Deployment pausado y otro que no lo está es que cualquier cambio al PodTemplateSpec del Deployment pausado
+no generará nuevos despliegues mientras esté pausado. Un Deployment se pausa de forma predeterminada cuando se crea.
+
+## Alternativa a los Deployments
+
+### kubectl rolling update
+
+[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) actualiza los Pods y los ReplicationControllers
+de forma similar. Pero se recomienda el uso de Deployments porque se declaran del lado del servidor, y proporcionan características adicionales
+como la posibilidad de retroceder a revisiones anteriores incluso después de haber terminado una actualización continua.
+
+
diff --git a/content/es/docs/concepts/workloads/controllers/garbage-collection.md b/content/es/docs/concepts/workloads/controllers/garbage-collection.md
new file mode 100644
index 0000000000..bc18541ce2
--- /dev/null
+++ b/content/es/docs/concepts/workloads/controllers/garbage-collection.md
@@ -0,0 +1,176 @@
+---
+title: Recolección de Basura
+content_type: concept
+weight: 60
+---
+
+
+
+El papel del recolector de basura de Kubernetes es el de eliminar determinados objetos
+que en algún momento tuvieron un propietario, pero que ahora ya no.
+
+
+
+## Propietarios y subordinados
+
+Algunos objetos de Kubernetes son propietarios de otros objetos. Por ejemplo, un ReplicaSet
+es el propietario de un conjunto de Pods. Los objetos que se poseen se denominan *subordinados* del
+objeto propietario. Cada objeto subordinado tiene un campo `metadata.ownerReferences`
+que apunta al objeto propietario.
+
+En ocasiones, Kubernetes pone el valor del campo `ownerReference` automáticamente.
+ Por ejemplo, cuando creas un ReplicaSet, Kubernetes automáticamente pone el valor del campo
+`ownerReference` de cada Pod en el ReplicaSet. A partir de la versión 1.8, Kubernetes
+automáticamente pone el valor de `ownerReference` para los objetos creados o adoptados
+por un ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job
+y CronJob.
+
+También puedes configurar las relaciones entre los propietarios y sus subordinados
+de forma manual indicando el valor del campo `ownerReference`.
+
+Aquí se muestra un archivo de configuración para un ReplicaSet que tiene tres Pods:
+
+{{< codenew file="controllers/replicaset.yaml" >}}
+
+Si se crea el ReplicaSet y entonces se muestra los metadatos del Pod, se puede
+observar el campo OwnerReferences:
+
+```shell
+kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
+kubectl get pods --output=yaml
+```
+
+La salida muestra que el propietario del Pod es el ReplicaSet denominado `my-repset`:
+
+```shell
+apiVersion: v1
+kind: Pod
+metadata:
+ ...
+ ownerReferences:
+ - apiVersion: apps/v1
+ controller: true
+ blockOwnerDeletion: true
+ kind: ReplicaSet
+ name: my-repset
+ uid: d9607e19-f88f-11e6-a518-42010a800195
+ ...
+```
+
+{{< note >}}
+No se recomienda el uso de OwnerReferences entre Namespaces por diseño. Esto quiere decir que:
+1) Los subordinados dentro del ámbito de Namespaces sólo pueden definir propietarios en ese mismo Namespace,
+y propietarios dentro del ámbito de clúster.
+2) Los subordinados dentro del ámbito del clúster sólo pueden definir propietarios dentro del ámbito del clúster, pero no
+propietarios dentro del ámbito de Namespaces.
+{{< /note >}}
+
+## Controlar cómo el recolector de basura elimina los subordinados
+
+Cuando eliminas un objeto, puedes indicar si sus subordinados deben eliminarse también
+de forma automática. Eliminar los subordinados automáticamente se denomina *borrado en cascada*.
+Hay dos modos de *borrado en cascada*: *en segundo plano* y *en primer plano*.
+
+Si eliminas un objeto sin borrar sus subordinados de forma automática,
+dichos subordinados se convierten en *huérfanos*.
+
+### Borrado en cascada en primer plano
+
+En el *borrado en cascada en primer plano*, el objeto raíz primero entra en un estado
+llamado "deletion in progress". En este estado "deletion in progress",
+se cumplen las siguientes premisas:
+
+ * El objeto todavía es visible a través de la API REST
+ * Se pone el valor del campo `deletionTimestamp` del objeto
+ * El campo `metadata.finalizers` del objeto contiene el valor "foregroundDeletion".
+
+Una vez que se pone el estado "deletion in progress", el recolector de basura elimina
+los subordinados del objeto. Una vez que el recolector de basura ha eliminado todos
+los subordinados "bloqueantes" (los objetos con `ownerReference.blockOwnerDeletion=true`), elimina
+el objeto propietario.
+
+Cabe mencionar que usando "foregroundDeletion", sólo los subordinados con valor en
+`ownerReference.blockOwnerDeletion` bloquean la eliminación del objeto propietario.
+A partir de la versión 1.7, Kubernetes añadió un [controlador de admisión](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)
+que controla el acceso de usuario cuando se intenta poner el campo `blockOwnerDeletion` a true
+con base a los permisos de borrado del objeto propietario, de forma que aquellos subordinados no autorizados
+no puedan retrasar la eliminación del objeto propietario.
+
+Si un controlador (como un Deployment o un ReplicaSet) establece el valor del campo `ownerReferences` de un objeto,
+se pone blockOwnerDeletion automáticamente y no se necesita modificar de forma manual este campo.
+
+### Borrado en cascada en segundo plano
+
+En el *borrado en cascada en segundo plano*, Kubernetes elimina el objeto propietario
+inmediatamente y es el recolector de basura quien se encarga de eliminar los subordinados en segundo plano.
+
+### Configurar la regla de borrado en cascada
+
+Para controlar la regla de borrado en cascada, configura el campo `propagationPolicy`
+del parámetro `deleteOptions` cuando elimines un objeto. Los valores posibles incluyen "Orphan",
+"Foreground", o "Background".
+
+Antes de la versión 1.9 de Kubernetes, la regla predeterminada del recolector de basura para la mayoría de controladores era `orphan`.
+Esto incluía al ReplicationController, ReplicaSet, StatefulSet, DaemonSet, y al Deployment.
+Para los tipos dentro de las versiones de grupo `extensions/v1beta1`, `apps/v1beta1`, y `apps/v1beta2`, a menos que
+se indique de otra manera, los objetos subordinados se quedan huérfanos por defecto.
+En Kubernetes 1.9, para todos los tipos de la versión de grupo `apps/v1`, los objetos subordinados se eliminan por defecto.
+
+Aquí se muestra un ejemplo que elimina los subordinados en segundo plano:
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
+-H "Content-Type: application/json"
+```
+
+Aquí se muestra un ejemplo que elimina los subordinados en primer plano:
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+-H "Content-Type: application/json"
+```
+
+Aquí se muestra un ejemplo de subordinados huérfanos:
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+-H "Content-Type: application/json"
+```
+
+kubectl también permite el borrado en cascada.
+Para eliminar los subordinados automáticamente, utiliza el parámetro `--cascade` a true.
+ Usa false para subordinados huérfanos. Por defecto, el valor de `--cascade`
+es true.
+
+Aquí se muestra un ejemplo de huérfanos de subordinados de un ReplicaSet:
+
+```shell
+kubectl delete replicaset my-repset --cascade=false
+```
+
+### Nota adicional sobre los Deployments
+
+Antes de la versión 1.7, cuando se usaba el borrado en cascada con Deployments se *debía* usar `propagationPolicy: Foreground`
+para eliminar no sólo los ReplicaSets creados, sino también sus Pods correspondientes. Si este tipo de _propagationPolicy_
+no se usa, solo se elimina los ReplicaSets, y los Pods se quedan huérfanos.
+Ver [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) para más información.
+
+## Problemas conocidos
+
+Seguimiento en [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+[Documento de Diseño 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
+
+[Documento de Diseño 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
+
diff --git a/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md
new file mode 100644
index 0000000000..f3bd77b4bf
--- /dev/null
+++ b/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md
@@ -0,0 +1,457 @@
+---
+title: Jobs - Ejecución hasta el final
+content_type: concept
+feature:
+ title: Ejecución en lotes
+ description: >
+ Además de los servicios, Kubernetes puede gestionar tus trabajos por lotes y CI, sustituyendo los contenedores que fallen, si así se desea.
+weight: 70
+---
+
+
+
+Un Job crea uno o más Pods y se asegura de que un número específico de ellos termina de forma satisfactoria.
+Conforme los pods terminan satisfactoriamente, el Job realiza el seguimiento de las ejecuciones satisfactorias.
+Cuando se alcanza un número específico de ejecuciones satisfactorias, la tarea (esto es, el Job) se completa.
+Al eliminar un Job se eliminan los Pods que haya creado.
+
+Un caso simple de uso es crear un objeto Job para que se ejecute un Pod de manera fiable hasta el final.
+El objeto Job arrancará un nuevo Pod si el primer Pod falla o se elimina (por ejemplo
+como consecuencia de un fallo de hardware o un reinicio en un nodo).
+
+También se puede usar un Job para ejecutar múltiples Pods en paralelo.
+
+
+
+
+
+
+## Ejecutar un Job de ejemplo
+
+Aquí se muestra un ejemplo de configuración de Job. Este ejemplo calcula los primeros 2000 decimales de π y los imprime por pantalla.
+Tarda unos 10s en completarse.
+
+{{< codenew file="controllers/job.yaml" >}}
+
+Puedes ejecutar el ejemplo con este comando:
+
+```shell
+kubectl apply -f https://k8s.io/examples/controllers/job.yaml
+```
+```
+job "pi" created
+```
+
+Comprueba el estado del Job con `kubectl`:
+
+```shell
+kubectl describe jobs/pi
+```
+```
+Name: pi
+Namespace: default
+Selector: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495
+Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495
+ job-name=pi
+Annotations:
+Parallelism: 1
+Completions: 1
+Start Time: Tue, 07 Jun 2016 10:56:16 +0200
+Pods Statuses: 0 Running / 1 Succeeded / 0 Failed
+Pod Template:
+ Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495
+ job-name=pi
+ Containers:
+ pi:
+ Image: perl
+ Port:
+ Command:
+ perl
+ -Mbignum=bpi
+ -wle
+ print bpi(2000)
+ Environment:
+ Mounts:
+ Volumes:
+Events:
+ FirstSeen LastSeen Count From SubobjectPath Type Reason Message
+ --------- -------- ----- ---- ------------- -------- ------ -------
+ 1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-dtn4q
+```
+
+Para ver los Pods de un Job que se han completado, usa `kubectl get pods`.
+
+Para listar todos los Pods que pertenecen a un Job de forma que sea legible, puedes usar un comando como:
+
+```shell
+pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
+echo $pods
+```
+```
+pi-aiw0a
+```
+
+En este caso, el selector es el mismo que el selector del Job. La opción `--output=jsonpath` indica un expresión
+que simplemente obtiene el nombre de cada Pod en la lista devuelta.
+
+Mira la salida estándar de uno de los Pods:
+
+```shell
+$ kubectl logs $pods
+3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
+```
+
+## Escribir una especificación de Job
+
+Como con el resto de configuraciones de Kubernetes, un Job necesita los campos `apiVersion`, `kind`, y `metadata`.
+
+Un Job también necesita la [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
+
+### Plantilla Pod
+
+El campo `.spec.template` es el único campo obligatorio de `.spec`.
+
+El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [pod](/docs/user-guide/pods),
+excepto por el hecho de que está anidado y no tiene el campo `apiVersion` o `kind`.
+
+Además de los campos olbigatorios de un Pod, una plantilla Pod de un Job debe indicar las etiquetas apropiadas
+(ver [selector de pod](#pod-selector)) y una regla de reinicio apropiada.
+
+Sólo se permite los valores `Never` o `OnFailure` para [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy).
+
+### Selector de Pod
+
+El campo `.spec.selector` es opcional. En la práctica mayoría de los casos no deberías configurarlo.
+Mira la sección sobre [configurar tu propio selector de pod](#specifying-your-own-pod-selector).
+
+
+### Jobs en paralelo
+
+Hay tres tipos principales de tarea aptos para ejecutarse como un Job:
+
+1. Jobs no paralelos
+ - normalmente, sólo se arranca un Pod, a menos que el Pod falle.
+ - el Job se completa tan pronto como su Pod termine de forma satisfactoria.
+1. Jobs en paralelo con un *cupo fijo de terminación*:
+ - se configura un valor positivo distinto de cero para el campo `.spec.completions`.
+ - el Job representa la tarea en general, y se completa cuando hay una ejecución satisfactoria de un Pod por cada valor dentro del rango de 1 a `.spec.completions`.
+ - **no implementado todavía:** A cada Pod se le pasa un índice diferenente dentro del rango de 1 a `.spec.completions`.
+1. Jobs en paralelo con una *cola de trabajo*:
+ - no se especifica el campo `.spec.completions`, por defecto `.spec.parallelism`.
+ - los Pods deben coordinarse entre ellos mismos o a través de un servicio externo que determine quién debe trabajar en qué.
+ Por ejemplo, un Pod podría ir a buscar un lote de hasta N ítems de una cola de trabajo.
+ - cada Pod es capaz de forma independiente de determinar si sus compañeros han terminado o no, y como consecuencia el Job entero ha terminado.
+ - cuando _cualquier_ Pod del Job termina con éxito, no se crean nuevos Pods.
+ - una vez que al menos uno de los Pods ha terminado con éxito y todos los Pods han terminado, entonces el Job termina con éxito.
+ - una vez que cualquier Pod ha terminado con éxito, ningún otro Pod debería continuar trabajando en la misma tarea o escribiendo ningún resultado. Todos ellos deberían estar en proceso de terminarse.
+
+En un Job _no paralelo_, no debes indicar el valor de `.spec.completions` ni `.spec.parallelism`. Cuando ambos se dejan
+ sin valor, ambos se predeterminan a 1.
+
+En un Job con _cupo fijo de terminación_, deberías poner el valor de `.spec.completions` al número de terminaciones que se necesiten.
+Puedes dar un valor a `.spec.parallelism`, o dejarlo sin valor, en cuyo caso se predetermina a 1.
+
+En un Job con _cola de trabajo_, no debes indicar el valor de `.spec.completions`, y poner el valor de `.spec.parallelism` a
+un entero no negativo.
+
+Para más información acerca de cómo usar los distintos tipos de Job, ver la sección de [patrones de job](#job-patterns).
+
+
+#### Controlar el paralelismo
+
+El paralelismo solicitado (`.spec.parallelism`) puede usar cualquier valor no negativo.
+Si no se indica, se predeterminad a 1.
+Si se indica como 0, entonces el Job se pausa de forma efectiva hasta que se incremente.
+
+El paralelismo actual (número de pods ejecutándose en cada momento) puede que sea mayor o menor que el solicitado,
+por los siguientes motivos:
+
+- Para los Jobs con _cupo fijo de terminaciones_, el número actual de pods ejecutándose en paralelo no excede el número de terminaciones pendientes.
+ Los valores superiores de `.spec.parallelism` se ignoran.
+- Para los Jobs con _cola de trabajo_, no se arranca nuevos Pods después de que cualquier Pod se haya completado -- sin embargo, se permite que se completen los Pods pendientes.
+- Cuando el controlador no ha tenido tiempo para reaccionar.
+- Cuando el controlador no pudo crear los Pods por el motivo que fuera (falta de `ResourceQuota`, falta de permisos, etc.),
+ entonces puede que haya menos pods que los solicitados.
+- El controlador puede que regule la creación de nuevos Pods debido al excesivo número de fallos anteriores en el mismo Job.
+- Cuando un Pod se para de forma controlada, lleva tiempo pararlo.
+
+## Gestionar Fallos de Pod y Contenedor
+
+Un contenedor de un Pod puede fallar por cualquier motivo, como porque el proceso que se estaba ejecutando termina con un código de salida distinto de cero,
+o porque se mató el contenedor por exceder un límite de memoria, etc. Si esto ocurre, y se tiene
+`.spec.template.spec.restartPolicy = "OnFailure"`, entonces el Pod permance en el nodo,
+pero el contenedor se vuelve a ejecutar. Por lo tanto, tu aplicación debe poder gestionar el caso en que se reinicia de forma local,
+o bien especificar `.spec.template.spec.restartPolicy = "Never"`.
+Ver el [ciclo de vida de un pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) para más información sobre `restartPolicy`.
+
+Un Pod entero puede también fallar por cualquier motivo, como cuando se expulsa al Pod del nodo
+(porque el nodo se actualiza, reinicia, elimina, etc.), o si un contenedor del Pod falla
+cuando `.spec.template.spec.restartPolicy = "Never"`. Cuando un Pod falla, entonces el controlador del Job
+arranca un nuevo Pod. Esto quiere decir que tu aplicación debe ser capaz de gestionar el caso en que se reinicia en un nuevo pod.
+En particular, debe ser capaz de gestionar los ficheros temporales, los bloqueos, los resultados incompletos, y cualquier otra dependencia
+de ejecuciones previas.
+
+Nótese que incluso si se configura `.spec.parallelism = 1` y `.spec.completions = 1` y
+`.spec.template.spec.restartPolicy = "Never"`, el mismo programa puede arrancarse dos veces.
+
+Si se especifica `.spec.parallelism` y `.spec.completions` con valores mayores que 1,
+entonces puede que haya múltiples pods ejecutándose a la vez. Por ello, tus pods deben tolerar la concurrencia.
+
+### Regla de retroceso de Pod por fallo
+
+Hay situaciones en que quieres que el Job falle después de intentar ejecutarlo unas cuantas veces debido
+a un error lógico en la configuración, etc.
+Para hacerlo, pon el valor de `.spec.backoffLimit` al número de reintentos que quieres
+antes de considerar el Job como fallido. El límite de retroceso se predetermina a 6.
+Los Pods fallidos asociados al Job son recreados por el controlador del Job con un
+retroceso exponencial (10s, 20s, 40s ...) limitado a seis minutos. El contador
+de retroceso se resetea si no aparecen Pods fallidos antes del siguiente chequeo de estado del Job.
+
+{{< note >}}
+El problema [#54870](https://github.com/kubernetes/kubernetes/issues/54870) todavía existe en las versiones de Kubernetes anteriores a la versión 1.12
+{{< /note >}}
+
+## Terminación y Limpieza de un Job
+
+Cuando un Job se completa, ya no se crea ningún Pod, pero tampoco se elimina los Pods. Guardarlos permite
+ver todavía los logs de los pods acabados para comprobar errores, avisos, o cualquier otro resultado de diagnóstico.
+El objeto job también se conserva una vez que se ha completado para que se pueda ver su estado. Es decisión del usuario si elimina
+los viejos jobs después de comprobar su estado. Eliminar el job con el comando `kubectl` (ej. `kubectl delete jobs/pi` o `kubectl delete -f ./job.yaml`).
+Cuando eliminas un job usando el comando `kubectl`, todos los pods que creó se eliminan también.
+
+Por defecto, un Job se ejecutará de forma ininterrumpida a menos que uno de los Pods falle, en cuyo caso el Job se fija en el valor de
+`.spec.backoffLimit` descrito arriba. Otra forma de acabar un Job es poniéndole un vencimiento activo.
+Haz esto poniendo el valor del campo `.spec.activeDeadlineSeconds` del Job a un número de segundos.
+
+El campo `activeDeadlineSeconds` se aplica a la duración del job, independientemente de cuántos Pods se hayan creado.
+Una vez que el Job alcanza `activeDeadlineSeconds`, se terminan todos sus Pods y el estado del Job se pone como `type: Failed` con `reason: DeadlineExceeded`.
+
+Fíjate que el campo `.spec.activeDeadlineSeconds` de un Job tiene precedencia sobre el campo `.spec.backoffLimit`.
+Por lo tanto, un Job que está reintentando uno o más Pods fallidos no desplegará nuevos Pods una vez que alcance el límite de tiempo especificado por `activeDeadlineSeconds`,
+incluso si todavía no se ha alcanzado el `backoffLimit`.
+
+Ejemplo:
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: pi-with-timeout
+spec:
+ backoffLimit: 5
+ activeDeadlineSeconds: 100
+ template:
+ spec:
+ containers:
+ - name: pi
+ image: perl
+ command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
+ restartPolicy: Never
+```
+
+Fíjate que tanto la especificación del Job como la [especificación de la plantilla Pod](/docs/concepts/workloads/pods/init-containers/#detailed-behavior)
+dentro del Job tienen un campo `activeDeadlineSeconds`. Asegúrate que pones el valor de este campo de forma adecuada.
+
+## Limpiar los Jobs terminados automáticamente
+
+Normalmente, los Jobs que han terminado ya no se necesitan en el sistema. Conservarlos sólo añade
+más presión al servidor API. Si dichos Jobs no se gestionan de forma directa por un controlador de más alto nivel,
+como los [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), los Jobs pueden
+limpiarse por medio de CronJobs en base a la regla de limpieza basada en capacidad que se haya especificado.
+
+### Mecanismo TTL para Jobs terminados
+
+{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+
+Otra forma de limpiar los Jobs terminados (bien `Complete` o `Failed`)
+de forma automática es usando un mecanismo TTL proporcionado por un
+[controlador TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) de recursos finalizados,
+indicando el valor `.spec.ttlSecondsAfterFinished` del Job.
+
+Cuando el controlador TTL limpia el Job, lo eliminará en cascada,
+esto es, eliminará sus objetos subordinados, como Pods, junto con el Job. Nótese
+que cuando se elimina el Job, sus garantías de ciclo de vida, como los finalizadores,
+se tendrán en cuenta.
+
+Por ejemplo:
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: pi-with-ttl
+spec:
+ ttlSecondsAfterFinished: 100
+ template:
+ spec:
+ containers:
+ - name: pi
+ image: perl
+ command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
+ restartPolicy: Never
+```
+
+Aquí el Job `pi-with-ttl` será candidato a ser automáticamente eliminado, `100`
+segundos después de que termine.
+
+Si el campo se pone a `0`, el Job será candidato a ser automáticamente eliminado
+inmediatamente después de haber terminado. Si no se pone valor al campo, este Job no será eliminado
+por el controlador TTL una vez concluya.
+
+Nótese que este mecanismo TTL está todavía en alpha, a través de la característica denominada `TTLAfterFinished`.
+Para más información, ver la documentación del [controlador TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) para
+recursos terminados.
+
+## Patrones de Job
+
+El objeto Job puede usarse para dar soporte a la ejecución fiable de Pods en paralelo. El objeto Job
+no se diseñó para dar soporte a procesos paralelos estrechamente comunicados, como los que comúnmente
+se encuentran en la computación científica. Eso sí, permite el proceso paralelo de un conjunto de *ítems de trabajo* independientes, pero relacionados entre sí.
+Estos pueden ser correos a enviar, marcos a renderizar, archivos a codificar, rangos de claves en una base de datos NoSQL a escanear, y demás.
+
+En un sistema complejo, puede haber múltiples diferentes conjuntos de ítems de trabajo. Aquí sólo se está
+considerando un conjunto de ítems de trabajo que el usuario quiere gestionar de forma conjunta — un *proceso por lotes*.
+
+Hay varios patrones diferentes para computación en paralelo, cada uno con sus fortalezas y sus debilidades.
+Los sacrificios a tener en cuenta son:
+
+- Un objeto Job para cada ítem de trabajo vs. un objeto Job simple para todos los ítems de trabajo. El último es mejor
+ para grandes números de ítems de trabajo. El primero añade sobrecarga para el usuario y para el sistema
+ al tener que gestionar grandes números de objetos Job.
+- El número de pods creados es igual al número de ítems de trabajo vs. cada Pod puede procesar múltiplese ítems de trabajo.
+ El primero típicamente requiere menos modificaciones al código existente y a los contenedores.
+ El último es mejor cuanto mayor sea el número de ítems de trabajo, por las mismas razones que antes..
+- Varios enfoques usan una cola de trabajo. Ello requiere ejecutar un servicio de colas,
+ y modificaciones a las aplicaciones o contenedores existentes para que hagan uso de la cola de trabajo.
+ Otras estrategias son más fáciles de adaptar a una aplicación ya usando contenedores.
+
+
+Los sacrificios a tener en cuenta se indican a continuación, donde las columnas 2 a 4 representan los sacrificios de arriba.
+Los nombres de los patrones son también enlaces a ejemplos e información más detallada.
+
+| Patrón | Objeto Job simple | ¿Menos pods que ítems de trabajo? | ¿No modificar la aplicación? | ¿Funciona en Kube 1.1? |
+| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
+| [Extensión de la Plantilla Job](/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ |
+| [Cola con Pod por Ítem de Trabajo](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | a veces | ✓ |
+| [Cola con Cuenta Variable de Pods](/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ |
+| Job simple con Asignación Estática de Trabajo | ✓ | | ✓ | |
+
+Cuando se especifican terminaciones con `.spec.completions`, cada Pod creado por el controlado del Job
+tiene un [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)idéntico.
+Esto significa que todos los pods de una tarea tendrán la misma línea de comandos y la
+misma imagne, los mismo volúmenes, y (casi) las mismas variables de entorno.
+Estos patrones otorgan diferentes formas de organizar los pods para que trabajen en cosas distintas.
+
+Esta tabla muestra la configuración necesaria para `.spec.parallelism` y `.spec.completions` para cada uno de los patrones.
+Aquí, `T` es el número de ítems de trabajo.
+
+| Patrón | `.spec.completions` | `.spec.parallelism` |
+| -------------------------------------------------------------------- |:-------------------:|:--------------------:|
+| [Extensión de la Plantilla Job](/docs/tasks/job/parallel-processing-expansion/) | 1 | debería ser 1 |
+| [Cola con Pod por Ítem de Trabajo](/docs/tasks/job/coarse-parallel-processing-work-queue/) | T | cualquiera |
+| [Cola con Cuenta Variable de Pods](/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | cualquiera |
+| Job simple con Asignación Estática de Trabajo | T | cualquiera |
+
+
+## Uso Avanzado
+
+### Especificar tu propio selector de pod
+
+Normalmente, cuando creas un objeto Job, no especificas el campo `.spec.selector`.
+La lógica por defecto del sistema añade este campo cuando se crea el Job.
+Se elige un valor de selector que no se entremezcle con otras tareas.
+
+Sin embargo, en algunos casos, puede que necesites sobreescribir este selector que se configura de forma automática.
+Para ello, puedes indicar el valor de `.spec.selector` en el Job.
+
+Pero ten mucho cuidado cuando lo hagas. Si configuras un selector de etiquta que no
+ es único para los pods de ese Job, y que selecciona Pods que no tienen que ver,
+ entonces estos últimos pueden ser eliminados, o este Job puede contar los otros
+ Pods para terminarse, o uno o ambos Jobs pueden negarse a crear Pods o ejecutarse hasta el final.
+ Si se elige un selector que no es único, entonces otros controladores (ej. ReplicationController)
+ y sus Pods puede comportarse de forma impredecibles también. Kubernetes no te impide cometer un error
+ especificando el `.spec.selector`.
+
+Aquí se muestra un ejemplo de un caso en que puede que necesites usar esta característica.
+
+Digamos que el Job `viejo` todavía está ejeuctándose. Quieres que los Pods existentes
+sigan corriendo, pero quieres que el resto de los Pods que se creen
+usen una plantilla pod diferente y que el Job tenga un nombre nuevo.
+Como no puedes modificar el Job porque esos campos no son modificables, eliminas el Job `old`,
+ pero _dejas sus pods ejecutándose_ mediante el comando `kubectl delete jobs/old --cascade=false`.
+Antes de eliminarlo, apúntate el selector actual que está usando:
+
+```
+kind: Job
+metadata:
+ name: viejo
+ ...
+spec:
+ selector:
+ matchLabels:
+ job-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
+ ...
+```
+
+Entonces, creas un nuevo Job con el nombre `nuevo` y le configuras explícitamente el mismo selector.
+Puesto que los Pods existentes tienen la etiqueta `job-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`,
+son controlados por el Job `nuevo` igualmente.
+
+Necesitas configurar `manualSelector: true` en el nuevo Job, ya qye no estás usando
+ el selector que normalmente se genera de forma automática por el sistema.
+
+```
+kind: Job
+metadata:
+ name: nuevo
+ ...
+spec:
+ manualSelector: true
+ selector:
+ matchLabels:
+ job-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
+ ...
+```
+
+El mismo Job nuevo tendrá un uid distinto a `a8f3d00d-c6d2-11e5-9f87-42010af00002`.
+Poniendo `manualSelector: true` le dice al sistema que sabes lo que estás haciendo
+ y que te permita hacer este desajuste.
+
+## Alternativas
+
+### Pods simples
+
+Cuando el nodo donde un Pod simple se estaba ejecutando se reinicia o falla, dicho pod se termina
+y no será reinicado. Sin embargo, un Job creará nuevos Pods para sustituir a los que se han terminando.
+Por esta razón, se recomienda que se use un Job en vez de un Pod simple, incluso si tu aplicación
+sólo necesita un único Pod.
+
+### Replication Controller
+
+Los Jobs son complementarios a los [Replication Controllers](/docs/user-guide/replication-controller).
+Un Replication Controller gestiona aquellos Pods que se espera que no terminen (ej. servidores web), y un Job
+gestiona aquellos Pods que se espera que terminen (ej. tareas por lotes).
+
+Como se discutió en el [Ciclo de vida de un Pod](/docs/concepts/workloads/pods/pod-lifecycle/), un `Job` *sólo* es apropiado
+para aquellos pods con `RestartPolicy` igual a `OnFailure` o `Never`.
+(Nota: Si `RestartPolicy` no se pone, el valor predeterminado es `Always`.)
+
+### Job simple arranca que arranca un controlador de Pod
+
+Otro patrón es aquel donde un Job simple crea un Pod que, a su vez, crea otros Pods, actuando como una especie
+de controlador personalizado para esos Pods. Esto da la máxima flexibilidad, pero puede que
+cueste un poco más de entender y ofrece menos integración con Kubernetes.
+
+Un ejemplo de este patrón sería un Job que arranca un Pod que ejecuta una secuencia de comandos que, a su vez,
+arranca un controlador maestro de Spark (ver el [ejemplo de spark](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)),
+ejecuta un manejador de spark, y a continuación lo limpia todo.
+
+Una ventaja de este enfoque es que el proceso general obtiene la garantía del objeto Job,
+además del control completo de los Pods que se crean y cómo se les asigna trabajo.
+
+## Cron Jobs {#cron-jobs}
+
+Puedes utilizar un [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) para crear un Job que se ejecute en una hora/fecha determinadas, de forma similar
+a la herramienta `cron` de Unix.
+
+
diff --git a/content/es/docs/concepts/workloads/controllers/replicaset.md b/content/es/docs/concepts/workloads/controllers/replicaset.md
new file mode 100644
index 0000000000..38bbf847c6
--- /dev/null
+++ b/content/es/docs/concepts/workloads/controllers/replicaset.md
@@ -0,0 +1,370 @@
+---
+title: ReplicaSet
+content_type: concept
+weight: 10
+---
+
+
+
+El objeto de un ReplicaSet es el de mantener un conjunto estable de réplicas de Pods ejecutándose
+en todo momento. Así, se usa en numerosas ocasiones para garantizar la disponibilidad de un
+número específico de Pods idénticos.
+
+
+
+
+
+
+## Cómo funciona un ReplicaSet
+
+Un ReplicaSet se define con campos, incluyendo un selector que indica cómo identificar a los Pods que puede adquirir,
+un número de réplicas indicando cuántos Pods debería gestionar, y una plantilla pod especificando los datos de los nuevos Pods
+que debería crear para conseguir el número de réplicas esperado. Un ReplicaSet alcanza entonces su propósito
+ mediante la creación y eliminación de los Pods que sea necesario para alcanzar el número esperado.
+ Cuando un ReplicaSet necesita crear nuevos Pods, utiliza su plantilla Pod.
+
+El enlace que un ReplicaSet tiene hacia sus Pods es a través del campo del Pod denominado [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents),
+el cual indica qué recurso es el propietario del objeto actual. Todos los Pods adquiridos por un ReplicaSet tienen su propia
+información de identificación del ReplicaSet en su campo ownerReferences. Y es a través de este enlace
+cómo el ReplicaSet conoce el estado de los Pods que está gestionando y actúa en consecuencia.
+
+Un ReplicaSet identifica los nuevos Pods a adquirir usando su selector. Si hay un Pod que no tiene OwnerReference
+o donde OwnerReference no es un controlador, pero coincide con el selector del ReplicaSet,
+este será inmediatamente adquirido por dicho ReplicaSet.
+
+## Cuándo usar un ReplicaSet
+
+Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejeuctando en todo momento.
+Sin embargo, un Deployment es un concepto de más alto nivel que gestiona ReplicaSets y
+proporciona actualizaciones de forma declarativa de los Pods junto con muchas otras características útiles.
+Por lo tanto, se recomienda el uso de Deployments en vez del uso directo de ReplicaSets, a no ser
+que se necesite una orquestración personalizada de actualización o no se necesite las actualizaciones en absoluto.
+
+En realidad, esto quiere decir que puede que nunca necesites manipular los objetos ReplicaSet:
+en vez de ello, usa un Deployment, y define tu aplicación en la sección spec.
+
+## Ejemplo
+
+{{< codenew file="controllers/frontend.yaml" >}}
+
+Si guardas este manifiesto en un archivo llamado `frontend.yaml` y lo lanzas en un clúster de Kubernetes,
+ se creará el ReplicaSet definido y los Pods que maneja.
+
+```shell
+kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml
+```
+
+Puedes ver los ReplicaSets actuales desplegados:
+```shell
+kubectl get rs
+```
+
+Y ver el frontend que has creado:
+```shell
+NAME DESIRED CURRENT READY AGE
+frontend 3 3 3 6s
+```
+
+También puedes comprobar el estado del replicaset:
+```shell
+kubectl describe rs/frontend
+```
+
+Y verás una salida parecida a la siguiente:
+```shell
+Name: frontend
+Namespace: default
+Selector: tier=frontend,tier in (frontend)
+Labels: app=guestbook
+ tier=frontend
+Annotations:
+Replicas: 3 current / 3 desired
+Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
+Pod Template:
+ Labels: app=guestbook
+ tier=frontend
+ Containers:
+ php-redis:
+ Image: gcr.io/google_samples/gb-frontend:v3
+ Port: 80/TCP
+ Requests:
+ cpu: 100m
+ memory: 100Mi
+ Environment:
+ GET_HOSTS_FROM: dns
+ Mounts:
+ Volumes:
+Events:
+ FirstSeen LastSeen Count From SubobjectPath Type Reason Message
+ --------- -------- ----- ---- ------------- -------- ------ -------
+ 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
+ 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
+ 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
+```
+
+Y por último, puedes comprobar los Pods que ha arrancado:
+```shell
+kubectl get Pods
+```
+
+Deberías ver la información de cada Pod similar a:
+```shell
+NAME READY STATUS RESTARTS AGE
+frontend-9si5l 1/1 Running 0 1m
+frontend-dnjpy 1/1 Running 0 1m
+frontend-qhloh 1/1 Running 0 1m
+```
+
+También puedes verificar que la referencia de propietario de dichos pods está puesta al ReplicaSet frontend.
+Para ello, obtén el yaml de uno de los Pods ejecutándose:
+```shell
+kubectl get pods frontend-9si5l -o yaml
+```
+
+La salida será parecida a esta, donde la información sobre el ReplicaSet aparece en el campo ownerReferences de los metadatos:
+```shell
+apiVersion: v1
+kind: Pod
+metadata:
+ creationTimestamp: 2019-01-31T17:20:41Z
+ generateName: frontend-
+ labels:
+ tier: frontend
+ name: frontend-9si5l
+ namespace: default
+ ownerReferences:
+ - apiVersion: extensions/v1beta1
+ blockOwnerDeletion: true
+ controller: true
+ kind: ReplicaSet
+ name: frontend
+ uid: 892a2330-257c-11e9-aecd-025000000001
+...
+```
+
+## Adquisiciones de Pods fuera de la plantilla
+
+Aunque puedes crear Pods simples sin problemas, se recomienda encarecidamente asegurarse de que dichos Pods no tienen
+etiquetas que puedan coincidir con el selector de alguno de tus ReplicaSets.
+La razón de esta recomendación es que un ReplicaSet no se limita a poseer los Pods
+especificados en su plantilla -- sino que puede adquirir otros Pods como se explicó en secciones anteriores.
+
+Toma el ejemplo anterior del ReplicaSet frontend, y los Pods especificados en el siguiente manifiesto:
+
+{{< codenew file="pods/pod-rs.yaml" >}}
+
+Como estos Pods no tienen un Controlador (o cualquier otro objeto) como referencia de propietario
+y como además su selector coincide con el del ReplicaSet frontend, este último los terminará adquiriendo de forma inmediata.
+
+Supón que creas los Pods después de que el ReplicaSet frontend haya desplegado los suyos
+para satisfacer su requisito de cuenta de réplicas:
+
+```shell
+kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml
+```
+
+Los nuevos Pods serán adquiridos por el ReplicaSet, e inmediatamente terminados ya que
+ el ReplicaSet estaría por encima del número deseado.
+
+Obtener los Pods:
+```shell
+kubectl get Pods
+```
+
+La salida muestra que los nuevos Pods se han terminado, o están en el proceso de terminarse:
+```shell
+NAME READY STATUS RESTARTS AGE
+frontend-9si5l 1/1 Running 0 1m
+frontend-dnjpy 1/1 Running 0 1m
+frontend-qhloh 1/1 Running 0 1m
+pod2 0/1 Terminating 0 4s
+```
+
+Si creas primero los Pods:
+```shell
+kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml
+```
+
+Y entonces creas el ReplicaSet:
+```shell
+kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml
+```
+
+Verás que el ReplicaSet ha adquirido dichos Pods y simplemente ha creado tantos nuevos
+como necesarios para cumplir con su especificación hasta que el número de
+sus nuevos Pods y los originales coincidan con la cuenta deseado. Al obtener los Pods:
+```shell
+kubectl get Pods
+```
+
+Veremos su salida:
+```shell
+NAME READY STATUS RESTARTS AGE
+frontend-pxj4r 1/1 Running 0 5s
+pod1 1/1 Running 0 13s
+pod2 1/1 Running 0 13s
+```
+
+De esta forma, un ReplicaSet puede poseer un conjunto no homogéneo de Pods
+
+## Escribir un manifiesto de ReplicaSet
+
+Al igual que con el esto de los objeto de la API de Kubernetes, un ReplicaSet necesita los campos
+`apiVersion`, `kind`, y `metadata`. Para los ReplicaSets, el tipo es siempre ReplicaSet.
+En la versión 1.9 de Kubernetes, la versión `apps/v1` de la API en un tipo ReplicaSet es la versión actual y está habilitada por defecto.
+La versión `apps/v1beta2` de la API se ha desaprobado.
+Consulta las primeras líneas del ejemplo `frontend.yaml` como guía.
+
+Un ReplicaSet también necesita una [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
+
+### Plantilla Pod
+
+El campo `.spec.template` es una [plantilla pod](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) que es
+ también necesita obligatoriamente tener etiquetas definidas. En nuestro ejemplo `frontend.yaml` teníamos una etiqueta: `tier: frontend`.
+Lleva cuidado de que no se entremezcle con los selectores de otros controladores, no sea que traten de adquirir este Pod.
+
+Para el campo de [regla de reinicio](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) de la plantilla,
+`.spec.template.spec.restartPolicy`, el único valor permitido es `Always`, que es el valor predeterminado.
+
+### Selector de Pod
+
+El campo `.spec.selector` es un [selector de etiqueta](/docs/concepts/overview/working-with-objects/labels/).
+Como se explicó [anteriormente](#how-a-replicaset-works), estas son las etiquetas que se usan para
+ identificar los Pods potenciales a adquirir. En nuestro ejemplo `frontend.yaml`, el selector era:
+```shell
+matchLabels:
+ tier: frontend
+```
+
+El el ReplicaSet, `.spec.template.metadata.labels` debe coincidir con `spec.selector`, o será
+ rechazado por la API.
+
+{{< note >}}
+Cuando 2 ReplicaSets especifican el mismo campo `.spec.selector`, pero los campos
+`.spec.template.metadata.labels` y `.spec.template.spec` diferentes, cada ReplicaSet
+ignora los Pods creados por el otro ReplicaSet.
+{{< /note >}}
+
+### Réplicas
+
+Puedes configurar cuántos Pods deberían ejecutarse de forma concurrente indicando el campo `.spec.replicas`.
+El ReplicaSet creará/eliminará sus Pods para alcanzar este número.
+
+Si no indicas el valor del campo `.spec.replicas`, entonces por defecto se inicializa a 1.
+
+## Trabajar con ReplicaSets
+
+### Eliminar un ReplicaSet y sus Pods
+
+Para eliminar un ReplicaSet y todos sus Pods, utiliza el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
+El [Recolector de basura](/docs/concepts/workloads/controllers/garbage-collection/) eliminará automáticamente
+ todos los Pods subordinados por defecto.
+
+Cuando se usa la API REST o la librería `client-go`, se debe poner el valor de `propagationPolicy` a `Background` o
+`Foreground` en la opción -d.
+Por ejemplo:
+```shell
+kubectl proxy --port=8080
+curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
+> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+> -H "Content-Type: application/json"
+```
+
+### Eliminar sólo un ReplicaSet
+
+Se puede eliminar un ReplicaSet sin afectar a ninguno de sus Pods usando el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) con la opción `--cascade=false`.
+Cuando se usa la API REST o la librería `client-go`, se debe poner `propagationPolicy` a `Orphan`.
+Por ejemplo:
+```shell
+kubectl proxy --port=8080
+curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
+> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+> -H "Content-Type: application/json"
+```
+
+Una vez que se ha eliminado el original, se puede crear un nuevo ReplicaSet para sustituirlo.
+Mientras el viejo y el nuevo `.spec.selector` sean el mismo, el nuevo adoptará a los viejos Pods.
+Sin embargo, no se esforzará en conseguir que los Pods existentes coincidan con una plantilla pod nueva, diferente.
+Para actualizar dichos Pods a la nueva especificación de forma controlada,
+usa una [actualización en línea](#rolling-updates).
+
+### Aislar Pods de un ReplicaSet
+
+Es posible aislar Pods de un ReplicaSet cambiando sus etiquetas. Esta técnica puede usarse
+para eliminar Pods de un servicio para poder depurar, recuperar datos, etc. Los Pods
+que se eliminar de esta forma serán sustituidos de forma automática (siempre que el
+número de réplicas no haya cambiado).
+
+### Escalar un ReplicaSet
+
+Se puede aumentar o reducir fácilmente un ReplicaSet simplemente actualizando el campo `.spec.replicas`.
+El controlador del ReplicaSet se asegura de que el número deseado de Pods con un selector
+de etiquetas coincidente está disponible y operacional.
+
+### ReplicaSet como blanco de un Horizontal Pod Autoscaler
+
+Un ReplicaSet puede también ser el blanco de un
+[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). Esto es,
+un ReplicaSet puede auto-escalarse mediante un HPA. Aquí se muestra un ejemplo de HPA dirigido
+al ReplicaSet que creamos en el ejemplo anterior.
+
+{{< codenew file="controllers/hpa-rs.yaml" >}}
+
+Si guardas este manifiesto en un archivo `hpa-rs.yaml` y lo lanzas contra el clúster de Kubernetes,
+debería crear el HPA definido que auto-escala el ReplicaSet destino dependiendo del uso
+de CPU de los Pods replicados.
+
+```shell
+kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
+```
+
+Alternativamente, puedes usar el comando `kubectl autoscale` para conseguir el mismo objetivo
+(¡y mucho más fácil!)
+
+```shell
+kubectl autoscale rs frontend --max=10
+```
+
+## Alternativas al ReplicaSet
+
+### Deployment (recomendado)
+
+Un[`Deployment`](/docs/concepts/workloads/controllers/deployment/) es un objeto que puede poseer ReplicaSets
+y actualizar a estos y a sus Pods mediante actualizaciones en línea declarativas en el servidor.
+Aunque que los ReplicaSets puede usarse independientemente, hoy en día se usan principalmente a través de los Deployments
+como el mecanismo para orquestrar la creación, eliminación y actualización de los Pods.
+Cuando usas Deployments no tienes que preocuparte de gestionar los ReplicaSets que crean.
+Los Deployments poseen y gestionan sus ReplicaSets.
+Por tanto, se recomienda que se use Deployments cuando se quiera ReplicaSets.
+
+### Pods simples
+
+A diferencia del caso en que un usuario creaba Pods de forma directa, un ReplicaSet sustituye los Pods que se eliminan
+o se terminan por la razón que sea, como en el caso de un fallo de un nodo o
+una intervención disruptiva de mantenimiento, como una actualización de kernel.
+Por esta razón, se recomienda que se use un ReplicaSet incluso cuando la aplicación
+sólo necesita un único Pod. Entiéndelo de forma similar a un proceso supervisor,
+donde se supervisa múltiples Pods entre múltiples nodos en vez de procesos individuales
+en un único nodo. Un ReplicaSet delega los reinicios del contenedor local a algún agente
+del nodo (por ejemplo, Kubelet o Docker).
+
+### Job
+
+Usa un [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) en vez de un ReplicaSet para
+ aquellos Pods que se esperan que terminen por ellos mismos (esto es, trabajos por lotes).
+
+### DaemonSet
+
+Usa un [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) en vez de un ReplicaSet para aquellos
+ Pods que proporcionan funcionalidad a nivel de servidor, como monitorización de servidor o
+ logging de servidor. Estos Pods tienen un ciclo de vida asociado al del servidor mismo:
+ el Pod necesita ejecutarse en el servidor antes de que los otros Pods comiencen, y es seguro
+ que terminen cuando el servidor esté listo para ser reiniciado/apagado.
+
+### ReplicationController
+Los ReplicaSets son los sucesores de los [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/).
+Los dos sirven al mismo propósito, y se comportan de forma similar, excepto porque un ReplicationController
+no soporta los requisitos del selector basado en conjunto, como se describe en la [guía de usuario de etiquetas](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
+Por ello, se prefiere los ReplicaSets a los ReplicationControllers.
+
+
diff --git a/content/es/docs/concepts/workloads/controllers/replicationcontroller.md b/content/es/docs/concepts/workloads/controllers/replicationcontroller.md
index 970eb4e8ec..5fe6c94c1e 100644
--- a/content/es/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/es/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -281,7 +281,7 @@ Incluso se plantea excluir el mecanismo de creación de pods a granel ([#170](ht
El ReplicationController está pensado para ser una primitiva de bloques is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
-## Obejto API
+## Objeto API
El ReplicationController es un recurso de alto nivel en la API REST de Kubernetes. Más detalles acerca del
objeto API se pueden encontrar aquí:
diff --git a/content/es/docs/concepts/workloads/pods/pod.md b/content/es/docs/concepts/workloads/pods/pod.md
index 4c6b5c7498..54ec37ce28 100644
--- a/content/es/docs/concepts/workloads/pods/pod.md
+++ b/content/es/docs/concepts/workloads/pods/pod.md
@@ -1,18 +1,18 @@
---
reviewers:
title: Pods
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
Los _Pods_ son las unidades de computación desplegables más pequeñas que se pueden crear y gestionar en Kubernetes.
-{{% /capture %}}
-{{% capture body %}}
+
+
## ¿Qué és un Pod?
@@ -151,4 +151,4 @@ Pod es un recurso de nivel superior en la API REST de Kubernetes.
La definición de [objeto de API Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
describe el objeto en detalle.
-{{% /capture %}}
+
diff --git a/content/es/docs/contribute/start.md b/content/es/docs/contribute/start.md
new file mode 100644
index 0000000000..607ecc966c
--- /dev/null
+++ b/content/es/docs/contribute/start.md
@@ -0,0 +1,207 @@
+---
+title: Empieza a contribuir
+slug: start
+content_type: concept
+weight: 10
+card:
+ name: contribute
+ weight: 10
+---
+
+
+
+Si quieres empezar a contribuir a la documentación de Kubernetes esta página y su temas enlazados pueden ayudarte a empezar. No necesitas ser un desarrollador o saber escribir de forma técnica para tener un gran impacto en la documentación y experiencia de usuario en Kubernetes! Todo lo que necesitas para los temas en esta página es una [Cuenta en GitHub](https://github.com/join) y un navegador web.
+
+Si estas buscando información sobre cómo comenzar a contribuir a los repositorios de Kubernetes, entonces dirígete a [las guías de la comunidad Kubernetes](https://github.com/kubernetes/community/blob/master/governance.md)
+
+
+
+## Lo básico sobre nuestra documentación
+
+La documentación de Kuberentes esta escrita usando Markdown, procesada y
+desplegada usando Hugo. El código fuente está en GitHub accessible en [git.k8s.io/website/](https://github.com/kubernetes/website).
+La mayoría de la documentación en castellano está en `/content/es/docs`. Alguna de
+la documentación de referencia se genera automática con los scripts del
+directorio `/update-imported-docs`.
+
+Puedes clasificar incidencias, editar contenido y revisar cambios de otros, todo ello
+desde la página de GitHub. También puedes usar la historia embebida de GitHub y
+las herramientas de búsqueda.
+
+No todas las tareas se pueden realizar desde la interfaz web de GitHub, también
+se discute en las guías de contribución a la documentación
+[intermedia](/docs/contribute/intermediate/) y
+[avanzada](/docs/contribute/advanced/)
+
+### Participar en la documentación de los SIG
+
+La documentación de Kubernetes es mantenida por el {{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG) denominado SIG Docs. Nos comunicamos usando un canal de Slack, una lista de correo
+y una reunión semana por video-conferencia. Siempre son bienvenidos nuevos
+participantes al grupo. Para más información ver
+[Participar en SIG Docs](/docs/contribute/participating/).
+
+### Guías de estilo
+
+Se mantienen unas [guías de estilo](/docs/contribute/style/style-guide/) con la información sobre las elecciones que cada comunidad SIG Docs ha realizado referente a gramática, sintaxis, formato del código fuente y convenciones tipográficas. Revisa la guía de estilos antes de hacer tu primera contribución y úsala para resolver tus dudas.
+
+Los cambios en la guía de estilos se hacen desde el SIG Docs como grupo. Para añadir o proponer cambios [añade tus comentarios en la agenda](https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/edit#) para las próximas reuniones del SIG Docs y participe en las discusiones durante la reunión. Revisa el apartado [avanzado](/docs/contribute/advanced/) para más información.
+
+### Plantillas para páginas
+
+Se usan plantillas para las páginas de documentación con el objeto de que todas tengan la misma presentación. Asegúrate de entender como funcionan estas plantillas y revisa el apartado [Uso de plantillas para páginas](/docs/contribute/style/page-templates/). Si tienes alguna consulta, no dudes en ponerte en contacto con el resto del equipo en Slack.
+
+### Hugo shortcodes
+
+La documentación de Kubernetes se transforma a partir de Markdown para obtener HTML usando Hugo. Hay que conocer los shortcodes estándar de Hugo, así como algunos que son personalizados para la documentación de Kubernetes. Para más información de como usarlos revisa [Hugo shortcodes personalizados](/docs/contribute/style/hugo-shortcodes/).
+
+### Múltiples idiomas
+
+La documentación original está disponible en múltiples idiomas en `/content/`. Cada idioma tiene su propia carpeta con el código de dos letras determinado por el [estándar ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php). Por ejemplo, la documentación original en inglés se encuentra en `/content/en/docs/`.
+
+Para más información sobre como contribuir a la documentación en múltiples idiomas revisa ["Localizar contenido"](/docs/contribute/intermediate#localize-content)
+
+Si te interesa empezar una nueva localización revisa ["Localization"](/docs/contribute/localization/).
+
+## Registro de incidencias
+
+Cualquier persona con una cuenta de GitHub puede reportar una incidencia en la documentación de Kubernetes. Si ves algo erróneo, aunque no sepas como resolverlo, [reporta una incidencia](#cómo-reportar-una-incidencia). La única excepción a la regla es si se trata de un pequeño error, como alguno que puedes resolver por ti mismo. En este último caso, puedes tratar de [resolverlo](#mejorar-contenido-existente) sin necesidad de reportar una incidencia primero.
+
+### Cómo reportar una incidencia
+
+- **En una página existente**
+
+ Si ves un problema en una página existente en la [documentación de Kuberenetes](/docs/) ve al final de la página y haz clic en el botón **Abrir un Issue**. Si no estas autenticado en GitHub, te pedirá que te identifiques y posteriormente un formulario de nueva incidencia aparecerá con contenido pre-cargado.
+
+ Utilizando formato Markdown completa todos los detalles que sea posible. En los lugares en que haya corchetes (`[ ]`) pon una `x` en medio de los corchetes para representar la elección de una opción. Si tienes una posible solución al problema añádela.
+
+- **Solicitar una nueva página**
+
+ Si crees que un contenido debería añadirse, pero no estás seguro de donde debería añadirse o si crees que no encaja en las páginas que ya existen, puedes crear un incidente. También puedes elegir una página ya existente donde pienses que pudiera encajar y crear el incidente desde esa página, o ir directamente a [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) y crearlo desde allí.
+
+### Cómo reportar correctamente incidencias
+
+Para estar seguros que tu incidencia se entiende y se puede procesar ten en cuenta esta guía:
+
+- Usa la plantilla de incidencia y aporta detalles, cuantos más es mejor.
+- Explica de forma clara el impacto de la incidencia en los usuarios.
+- Mantén el alcance de una incidencia a una cantidad de trabajo razonable. Para problemas con un alcance muy amplio divídela en incidencias más pequeñas.
+
+ Por ejemplo, "Arreglar la documentación de seguridad" no es una incidencia procesable, pero "Añadir detalles en el tema 'Restringir acceso a la red'" si lo es.
+- Si la incidencia está relacionada con otra o con una petición de cambio puedes referirte a ella tanto por la URL como con el número de la incidencia o petición de cambio con el carácter `#` delante. Por ejemplo `Introducido por #987654`.
+- Se respetuoso y evita desahogarte. Por ejemplo, "La documentación sobre X apesta" no es útil o una crítica constructiva. El [Código de conducta](/community/code-of-conduct/) también aplica para las interacciones en los repositorios de Kubernetes en GitHub.
+
+## Participa en las discusiones de SIG Docs
+
+El equipo de SIG Docs se comunica por las siguientes vías:
+
+- [Únete al Slack de Kubernetes](http://slack.k8s.io/) y entra al canal `#sig-docs` o `#kubernetes-docs-es` para la documentación en castellano. En Slack, discutimos sobre las incidencias de documentación en tiempo real, nos coordinamos y hablamos de temas relacionados con la documentación. No olvides presentarte cuando entres en el canal para que podamos saber un poco más de ti!
+- [Únete a la lista de correo `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), donde tienen lugar las discusiones más amplias y se registran las decisiones oficiales.
+- Participa en la video-conferencia [semanal de SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs), esta se anuncia en el canal de Slack y la lista de correo. Actualmente esta reunión tiene lugar usando Zoom, por lo que necesitas descargar el [cliente Zoom](https://zoom.us/download) o llamar usando un teléfono.
+
+{{< note >}}
+Puedes revisar la reunión semanal de SIG Docs en el [Calendario de reuniones de la comunidad Kubernetes](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles).
+{{< /note >}}
+
+## Mejorar contenido existente
+
+Para mejorar contenido existente crea una _pull request(PR)_ después de crear un _fork_. Estos términos son [específicos de GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/). No es necesario conocer todo sobre estos términos porque todo se realiza a través del navegador web. Cuando continúes con la [guía de contribución de documentación intermedia](/docs/contribute/intermediate/) entonces necesitarás un poco más de conocimiento de la metodología Git.
+
+{{< note >}}
+**Desarrolladores de código de Kubernetes**: Si estás documentando una nueva característica para una versión futura de Kubernetes, entonces el proceso es un poco diferente. Mira el proceso y pautas en [Documentar una característica](/docs/contribute/intermediate/#sig-members-documenting-new-features) así como información sobre plazos.
+{{< /note >}}
+
+### Firma el CNCF CLA {#firma-el-cla}
+
+Antes de poder contribuir o documentar en Kubernetes **es necesario** leer [Guía del contribuidor](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) y [firmar el `Contributor License Agreement` (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). No te preocupes esto no lleva mucho tiempo!
+
+### Busca algo con lo que trabajar
+
+Si ves algo que quieras arreglar directamente, simplemente sigue las instrucciones más abajo. No es necesario que [reportes una incidencia](#registro-de-incidencias) (aunque de todas formas puedes).
+
+Si quieres empezar por buscar una incidencia existente para trabajar puedes ir [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) y buscar una incidencia con la etiqueta `good first issue` (puedes usar [este](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) atajo). Lee los comentarios y asegurate de que no hay una petición de cambio abierta para esa incidencia y que nadie a dejado un comentario indicando que están trabajando en esa misma incidencia recientemente (3 días es una buena regla). Deja un comentario indicando que te gustaría trabajar en la incidencia.
+
+### Elije que rama de Git usar
+
+El aspecto más importante a la hora de mandar una petición de cambio es que rama usar como base para trabajar. Usa estas pautas para tomar la decisión:
+
+- Utiliza `master` para arreglar problemas en contenido ya existente publicado, o hacer mejoras en contenido ya existente.
+ - Utiliza una rama de versión (cómo `dev-{{< release-branch >}}` para la versión {{< release-branch>}}) para documentar futuras características o cambios para futuras versiones que todavía no se han publicado.
+- Utiliza una rama de características que haya sido acordada por SIG Docs para colaborar en grandes mejoras o cambios en la documentación existente, incluida la reorganización de contenido o cambios en la apariencia del sitio web.
+
+Si todavía no estás seguro con que rama utilizar, pregunta en `#sig-docs`en Slack o atiende una reunión semanal del SIG Docs para aclarar tus dudas.
+
+### Enviar una petición de cambio
+
+Sigue estos pasos para enviar una petición de cambio y mejorar la documentación de Kubernetes.
+
+1. En la página que hayas visto una incidencia haz clic en el icono del lápiz arriba a la derecha.
+ Una nueva página de GitHub aparecerá con algunos textos de ayuda.
+2. Si nunca has creado un copia del repositorio de documentación de Kubernetes te pedirá que lo haga.
+ Crea la copia bajo tu usuario de GitHub en lugar de otra organización de la que seas miembro. La copia generalmente tiene una URL como `https://github.com//website`, a menos que ya tengas un repositorio con un nombre en conflicto con este.
+
+ La razón por la que se pide crear una copia del repositorio es porque no tienes permisos para subir cambios directamente a rama en el repositorio original de Kubernetes.
+3. Aparecerá el editor Markdown de GitHub con el fichero Markdown fuente cargado. Realiza tus cambios. Debajo del editor completa el formulario **Propose file change**. El primer campo es el resumen del mensaje de tu commit y no debe ser más largo de 50 caracteres. El segundo campo es opcional, pero puede incluir más información y detalles si procede.
+
+ {{< note >}}
+ No incluyas referencias a otras incidencias o peticiones de cambio de GitHub en el mensaje de los commits. Esto lo puedes añadir después en la descripción de la petición de cambio.
+{{< /note >}}
+
+ Haz clic en **Propose file change**. El cambio se guarda como un commit en una nueva rama de tu copia, automáticamente se le asignará un nombre estilo `patch-1`.
+
+4. La siguiente pantalla resume los cambios que has hecho pudiendo comparar la nueva rama (la **head fork** y cajas de selección **compare**) con el estado actual del **base fork** y la rama **base** (`master` en el repositorio por defecto `kubernetes/website`). Puedes cambiar cualquiera de las cajas de selección, pero no lo hagas ahora. Hecha un vistazo a las distintas vistas en la parte baja de la pantalla y si todo parece correcto haz clic en **Create pull request**.
+
+ {{< note >}}
+ Si no deseas crear una petición de cambio puedes hacerlo más delante, solo basta con navegar a la URL principal del repositorio de Kubernetes website o de tu copia. La página de GitHub te mostrará un mensaje para crear una petición de cambio si detecta que has subido una nueva rama a tu repositorio copia.
+ {{< /note >}}
+
+5. La pantalla **Open a pull request** aparece. El tema de una petición de cambio es el resumen del commit, pero puedes cambiarlo si lo necesitas. El cuerpo está pre-cargado con el mensaje del commit extendido (si lo hay) junto con una plantilla. Lee la plantilla y llena los detalles requeridos, entonces borra el texto extra de la plantilla. Deja la casilla **Allow edits from maintainers** seleccionada. Haz clic en **Create pull request**.
+
+ Enhorabuena! Tu petición de cambio está disponible en [Pull requests](https://github.com/kubernetes/website/pulls).
+
+ Después de unos minutos ya podrás pre-visualizar la página con los cambios de tu PR aplicados. Ve a la pestaña de **Conversation** en tu PR y haz clic en el enlace **Details** para ver el test `deploy/netlify`, localizado casi al final de la página. Se abrirá en la misma ventana del navegado por defecto.
+
+6. Espera una revisión. Generalmente `k8s-ci-robot` sugiere unos revisores. Si un revisor te pide que hagas cambios puedes ir a la pestaña **FilesChanged** y hacer clic en el icono del lápiz para hacer tus cambios en cualquiera de los ficheros en la petición de cambio. Cuando guardes los cambios se creará un commit en la rama asociada a la petición de cambio.
+
+7. Si tu cambio es aceptado, un revisor fusionará tu petición de cambio y tus cambios serán visibles en pocos minutos en la web de [kubernetes.io](https://kubernetes.io).
+
+Esta es solo una forma de mandar una petición de cambio. Si eres un usuario de Git y GitHub avanzado puedes usar una aplicación GUI local o la linea de comandos con el cliente Git en lugar de usar la UI de GitHub. Algunos conceptos básicos sobre el uso de la línea de comandos Git
+cliente se discuten en la guía de documentación [intermedia](/docs/contribute/intermediate/).
+
+## Revisar peticiones de cambio de documentación
+
+Las personas que aún no son aprobadores o revisores todavía pueden revisar peticiones de cambio. Las revisiones no se consideran "vinculantes", lo que significa que su revisión por sí sola no hará que se fusionen las peticiones de cambio. Sin embargo, aún puede ser útil. Incluso si no deja ningún comentario de revisión, puede tener una idea de las convenciones y etiquetas en una petición de cambio y acostumbrarse al flujo de trabajo.
+
+1. Ve a [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). Desde ahí podrás ver una lista de todas las peticiones de cambio en la documentación del website de Kubernetes.
+
+2. Por defecto el único filtro que se aplica es `open`, por lo que no puedes ver las que ya se han cerrado o fusionado. Es una buena idea aplicar el filtro `cncf-cla: yes` y para tu primera revisión es una buena idea añadir `size/S` o `size/XS`. La etiqueta `size` se aplica automáticamente basada en el número de lineas modificadas en la PR. Puedes aplicar filtros con las cajas de selección al principio de la página, o usar [estos atajos](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) solo para PRs pequeñas. Los filtros son aplicados con `AND` todos juntos, por lo que no se puede buscar a la vez `size/S` y `size/XS` en la misma consulta.
+
+3. Ve a la pestaña **Files changed**. Mira los cambios introducidos en la PR, y si aplica, mira también los incidentes enlazados. Si ves un algún problema o posibilidad de mejora pasa el cursor sobre la línea y haz click en el símbolo `+` que aparece.
+
+ Puedes entonces dejar un comentario seleccionando **Add single comment** o **Start a review**. Normalmente empezar una revisión es la forma recomendada, ya que te permite hacer varios comentarios y avisar a propietario de la PR solo cuando tu revisión este completada, en lugar de notificar cada comentario.
+
+4. Cuando hayas acabado de revisar, haz clic en **Review changes** en la parte superior de la página. Puedes ver un resumen de la revisión y puedes elegir entre comentar, aprobar o solicitar cambios. Los nuevos contribuidores siempre deben elegir **Comment**.
+
+Gracias por revisar una petición de cambio! Cuando eres nuevo en un proyecto es buena idea solicitar comentarios y opiniones en las revisiones de una petición de cambio. Otro buen lugar para solicitar comentarios es en el canal de Slack `#sig-docs`.
+
+## Escribir un artículo en el blog
+
+Cualquiera puede escribir un articulo en el blog y enviarlo para revisión. Los artículos del blog no deben ser comerciales y deben consistir en contenido que se pueda aplicar de la forma más amplia posible a la comunidad de Kubernetes.
+
+Para enviar un artículo al blog puedes hacerlo también usando el formulario [Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSch_phFYMTYlrTDuYziURP6nLMijoXx_f7sLABEU5gWBtxJHQ/viewform), o puedes seguir los siguientes pasos.
+
+1. [Firma el CLA](#sign-the-cla) si no lo has hecho ya.
+2. Revisa el formato Markdown en los artículos del blog existentes en el [repositorio website](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts).
+3. Escribe tu artículo usando el editor de texto que prefieras.
+4. En el mismo enlace que el paso 2 haz clic en botón **Create new file**. Pega el contenido de tu editor. Nombra el fichero para que coincida con el título del artículo, pero no pongas la fecha en el nombre. Los revisores del blog trabajarán contigo en el nombre final del fichero y la fecha en la que será publicado.
+5. Cuando guardes el fichero, GitHub te guiará en el proceso de petición de cambio.
+6. Un revisor de artículos del blog revisará tu envío y trabajará contigo aportando comentarios y los detalles finales. Cuando el artículo sea aprobado, se establecerá una fecha de publicación.
+
+## Envía un caso de estudio
+
+Un caso de estudio destaca como organizaciones están usando Kubernetes para resolver problemas del mundo real. Estos se escriben en colaboración con el equipo de marketing de Kubernetes que está dirigido por la {{< glossary_tooltip text="CNCF" term_id="cncf" >}}.
+
+Revisa el código fuente para ver los [casos de estudio existentes](https://github.com/kubernetes/website/tree/master/content/en/case-studies). Usa el formulario [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/) para enviar tu propuesta.
+
+## {{% heading "whatsnext" %}}
+
+Cuando entiendas mejor las tareas mostradas en este tema y quieras formar parte del equipo de documentación de Kubernetes de una forma más activa lee la [guía intermedia de contribución](/docs/contribute/intermediate/).
\ No newline at end of file
diff --git a/content/es/docs/reference/_index.md b/content/es/docs/reference/_index.md
index 070cb93765..a3625a903e 100644
--- a/content/es/docs/reference/_index.md
+++ b/content/es/docs/reference/_index.md
@@ -49,11 +49,11 @@ En estos momento, las librerías con soporte oficial son:
* [kubelet](/docs/admin/kubelet/) - El principal *agente* que se ejecuta en cada nodo. El kubelet toma un conjunto de PodSpecs y asegura que los contenedores descritos estén funcionando y en buen estado.
* [kube-apiserver](/docs/admin/kube-apiserver/) - API REST que valida y configura datos para objetos API como pods, servicios, controladores de replicación, ...
-* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Demonio que integra los bucles de control enviados con Kubernetes.
+* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Daemon que integra los bucles de control enviados con Kubernetes.
* [kube-proxy](/docs/admin/kube-proxy/) - Puede hacer fowarding simple o con round-robin de TCP/UDP a través de un conjunto de back-ends.
* [kube-scheduler](/docs/admin/kube-scheduler/) - Planificador que gestiona la disponibilidad, el rendimiento y la capacidad.
* [federation-apiserver](/docs/admin/federation-apiserver/) - Servidor API para clusters federados.
-* [federation-controller-manager](/docs/admin/federation-controller-manager/) - Demonio que integra los bucles de control enviados con la federación Kubernetes.
+* [federation-controller-manager](/docs/admin/federation-controller-manager/) - Proceso que integra los bucles de control enviados con la federación Kubernetes.
## Documentos de diseño
diff --git a/content/es/docs/reference/glossary/configmap.md b/content/es/docs/reference/glossary/configmap.md
new file mode 100644
index 0000000000..577e24dc1f
--- /dev/null
+++ b/content/es/docs/reference/glossary/configmap.md
@@ -0,0 +1,18 @@
+---
+title: Configmap
+id: configmap
+date: 2020-07-11
+full_link: /docs/concepts/configuration/configmap/
+short_description: >
+ Almacena información no sensible.
+
+aka:
+tags:
+- workload
+---
+Un objeto de la API utilizado para almacenar datos no confidenciales en el formato clave-valor. Los {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar los ConfigMaps como variables de entorno, argumentos de la linea de comandos o como ficheros de configuración en un {{< glossary_tooltip text="Volumen" term_id="volume" >}}.
+
+Un ConfigMap te permite desacoplar la configuración de un entorno específico de una imagen de contenedor, así las aplicaciones son fácilmente portables.
+
+
+
diff --git a/content/es/docs/reference/glossary/controller.md b/content/es/docs/reference/glossary/controller.md
new file mode 100755
index 0000000000..8258d0ae86
--- /dev/null
+++ b/content/es/docs/reference/glossary/controller.md
@@ -0,0 +1,33 @@
+---
+title: Controlador
+id: controller
+date: 2018-04-12
+full_link: /docs/concepts/architecture/controller/
+short_description: >
+ Los controladores son bucles de control que observan el estado del clúster,
+ y ejecutan o solicitan los cambios que sean necesarios para alcanzar el estado
+ deseado.
+
+aka:
+tags:
+- architecture
+- fundamental
+---
+
+En Kubernetes, los controladores son bucles de control que observan el estado del
+{{< glossary_tooltip term_id="cluster" text="clúster">}}, y ejecutan o solicitan
+los cambios que sean necesarios para llevar el estado actual del clúster más
+cerca del estado deseado.
+
+
+
+Los controladores observan el estado compartido del clúster a través del
+{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} (parte del
+{{< glossary_tooltip term_id="control-plane" text="plano de control" >}}).
+
+Algunos controladores también se ejecutan dentro del mismo plano de control,
+proporcionado los bucles de control necesarios para las operaciones principales
+de Kubernetes. Por ejemplo, el controlador de Deployments, el controlador de
+DaemonSets, el controlador de Namespaces y el controlador de volúmenes
+persistentes, entre otros, se ejecutan dentro del
+{{< glossary_tooltip term_id="kube-controller-manager" >}}.
diff --git a/content/es/docs/reference/glossary/etcd.md b/content/es/docs/reference/glossary/etcd.md
new file mode 100755
index 0000000000..5ac470a85c
--- /dev/null
+++ b/content/es/docs/reference/glossary/etcd.md
@@ -0,0 +1,24 @@
+---
+title: etcd
+id: etcd
+date: 2018-04-12
+full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
+short_description: >
+ Almacén de datos persistente, consistente y distribuido de clave-valor utilizado
+ para almacenar toda a la información del clúster de Kubernetes.
+
+aka:
+tags:
+- architecture
+- storage
+---
+
+Almacén de datos persistente, consistente y distribuido de clave-valor utilizado
+para almacenar toda a la información del clúster de Kubernetes.
+
+
+
+Si tu clúster utiliza etcd como sistema de almacenamiento, échale un vistazo a la
+documentación sobre [estrategias de backup](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster).
+
+Puedes encontrar información detallada sobre etcd en su [documentación oficial](https://etcd.io/docs/).
diff --git a/content/es/docs/reference/glossary/kube-apiserver.md b/content/es/docs/reference/glossary/kube-apiserver.md
new file mode 100755
index 0000000000..3363f3edcb
--- /dev/null
+++ b/content/es/docs/reference/glossary/kube-apiserver.md
@@ -0,0 +1,26 @@
+---
+title: API Server
+id: kube-apiserver
+date: 2020-07-01
+full_link: /docs/reference/generated/kube-apiserver/
+short_description: >
+ Componente del plano de control que expone la API de Kubernetes.
+
+aka:
+- Servidor de la API
+- kube-apiserver
+tags:
+- architecture
+- fundamental
+---
+
+El servidor de la API es el componente del {{< glossary_tooltip text="plano de control" term_id="control-plane" >}}
+de Kubernetes que expone la API de Kubernetes. Se trata del frontend de Kubernetes,
+recibe las peticiones y actualiza acordemente el estado en {{< glossary_tooltip term_id="etcd" length="all" >}}.
+
+
+
+La principal implementación de un servidor de la API de Kubernetes es
+[kube-apiserver](/docs/reference/generated/kube-apiserver/).
+Es una implementación preparada para ejecutarse en alta disponiblidad y que
+puede escalar horizontalmente para balancear la carga entre varias instancias.
\ No newline at end of file
diff --git a/content/es/docs/reference/glossary/kube-controller-manager.md b/content/es/docs/reference/glossary/kube-controller-manager.md
new file mode 100755
index 0000000000..4a9bd20877
--- /dev/null
+++ b/content/es/docs/reference/glossary/kube-controller-manager.md
@@ -0,0 +1,21 @@
+---
+title: kube-controller-manager
+id: kube-controller-manager
+date: 2018-04-12
+full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
+short_description: >
+ Componente del plano de control que ejecuta los controladores de Kubernetes.
+
+aka:
+tags:
+- architecture
+- fundamental
+---
+
+Componente del plano de control que ejecuta los {{< glossary_tooltip text="controladores" term_id="controller" >}} de Kubernetes.
+
+
+
+Lógicamente cada {{< glossary_tooltip text="controlador" term_id="controller" >}}
+es un proceso independiente, pero para reducir la complejidad, todos se compilan
+en un único binario y se ejecuta en un mismo proceso.
diff --git a/content/es/docs/reference/glossary/kube-scheduler.md b/content/es/docs/reference/glossary/kube-scheduler.md
new file mode 100755
index 0000000000..ea7914495a
--- /dev/null
+++ b/content/es/docs/reference/glossary/kube-scheduler.md
@@ -0,0 +1,25 @@
+---
+title: kube-scheduler
+id: kube-scheduler
+date: 2018-04-12
+full_link: /docs/reference/generated/kube-scheduler/
+short_description: >
+ Componente del plano de control que está pendiente de los pods que no tienen
+ ningún nodo asignado y seleciona uno dónde ejecutarlo.
+
+aka:
+tags:
+- architecture
+---
+
+Componente del plano de control que está pendiente de los
+{{< glossary_tooltip term_id="pod" text="Pods" >}} que no tienen ningún
+{{< glossary_tooltip term_id="node" text="nodo">}} asignado
+y seleciona uno donde ejecutarlo.
+
+
+
+Para decidir en qué {{< glossary_tooltip term_id="node" text="nodo">}}
+se ejecutará el {{< glossary_tooltip term_id="pod" text="pod" >}}, se tienen
+en cuenta diversos factores: requisitos de recursos, restricciones de hardware/software/políticas,
+afinidad y anti-afinidad, localización de datos dependientes, entre otros.
diff --git a/content/es/docs/reference/glossary/namespace.md b/content/es/docs/reference/glossary/namespace.md
new file mode 100755
index 0000000000..4ceec4db73
--- /dev/null
+++ b/content/es/docs/reference/glossary/namespace.md
@@ -0,0 +1,22 @@
+---
+title: Namespace
+id: namespace
+date: 2018-04-12
+full_link: /es/docs/concepts/overview/working-with-objects/namespaces/
+short_description: >
+ Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales en el mismo clúster físico.
+aka:
+- Espacio de nombres
+tags:
+- fundamental
+---
+
+Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales
+en el mismo {{< glossary_tooltip text="clúster" term_id="cluster" >}} físico.
+
+
+
+Los Namespaces, espacios de nombres, se utilizan para organizar objetos del clúster
+proporcionando un mecanismo para dividir los recusos del clúster. Los nombres de los
+objetos tienen que ser únicos dentro del mismo namespace, pero se pueden repetir en
+otros namespaces del mismo clúster.
\ No newline at end of file
diff --git a/content/es/docs/tasks/_index.md b/content/es/docs/tasks/_index.md
index 12d741e263..1b10eb1d35 100644
--- a/content/es/docs/tasks/_index.md
+++ b/content/es/docs/tasks/_index.md
@@ -65,23 +65,20 @@ Configura componentes en una federación de clústers.
Realiza tareas comunes de gestión de aplicaciones con estado, incluyendo escalado, borrado y depuración de StatefulSets.
-## Demonios del Clúster
+## Daemons del Clúster
Realiza tareas comunes de gestión de un DaemonSet, como llevar a cabo una actualización de lanzamiento.
## Gestionar GPUs
-COnfigura y planifica GPUs de NVIDIA para hacerlas disponibles como recursos a los nodos de un clúster.
+Configura y planifica GPUs de NVIDIA para hacerlas disponibles como recursos a los nodos de un clúster.
## Gestionar HugePages
Configura y planifica HugePages como un recurso planificado en un clúster.
-
-
## {{% heading "whatsnext" %}}
-
Si quisieras escribir una página de Tareas, echa un vistazo a
[Crear una Petición de Subida de Documentación](/docs/home/contribute/create-pull-request/).
diff --git a/content/es/docs/tasks/debug-application-cluster/_index.md b/content/es/docs/tasks/debug-application-cluster/_index.md
index 12bb04c317..6573112172 100644
--- a/content/es/docs/tasks/debug-application-cluster/_index.md
+++ b/content/es/docs/tasks/debug-application-cluster/_index.md
@@ -1,4 +1,4 @@
---
title: "Monitorización, Logs y Debugging"
weight: 80
----
\ No newline at end of file
+---
diff --git a/content/es/docs/tasks/debug-application-cluster/audit.md b/content/es/docs/tasks/debug-application-cluster/audit.md
new file mode 100644
index 0000000000..fc2dec9e27
--- /dev/null
+++ b/content/es/docs/tasks/debug-application-cluster/audit.md
@@ -0,0 +1,434 @@
+---
+content_type: concept
+title: Auditoría
+---
+
+
+
+La auditoría de Kubernetes proporciona un conjunto de registros cronológicos referentes a la seguridad
+que documentan la secuencia de actividades que tanto los usuarios individuales, como
+los administradores y otros componentes del sistema ha realizado en el sistema.
+ Así, permite al administrador del clúster responder a las siguientes cuestiones:
+
+ - ¿qué ha pasado?
+ - ¿cuándo ha pasado?
+ - ¿quién lo ha iniciado?
+ - ¿sobre qué ha pasado?
+ - ¿dónde se ha observado?
+ - ¿desde dónde se ha iniciado?
+ - ¿hacia dónde iba?
+
+
+
+
+
+
+El componente [Kube-apiserver][kube-apiserver] lleva a cabo la auditoría. Cada petición en cada fase
+de su ejecución genera un evento, que se pre-procesa según un cierto reglamento y
+se escribe en un backend. Este reglamento determina lo que se audita
+y los backends persisten los registros. Las implementaciones actuales de backend
+incluyen los archivos de logs y los webhooks.
+
+Cada petición puede grabarse junto con una "etapa" asociada. Las etapas conocidas son:
+
+- `RequestReceived` - La etapa para aquellos eventos generados tan pronto como
+el responsable de la auditoría recibe la petición, pero antes de que sea delegada al
+siguiente responsable en la cadena.
+- `ResponseStarted` - Una vez que las cabeceras de la respuesta se han enviado,
+pero antes de que el cuerpo de la respuesta se envíe. Esta etapa sólo se genera
+en peticiones de larga duración (ej. watch).
+- `ResponseComplete` - El cuerpo de la respuesta se ha completado y no se enviarán más bytes.
+- `Panic` - Eventos que se generan cuando ocurre una situación de pánico.
+
+{{< note >}}
+La característica de registro de auditoría incrementa el consumo de memoria del servidor API
+porque requiere de contexto adicional para lo que se audita en cada petición.
+De forma adicional, el consumo de memoria depende de la configuración misma del registro.
+{{< /note >}}
+
+## Reglamento de Auditoría
+
+El reglamento de auditoría define las reglas acerca de los eventos que deberían registrarse y
+los datos que deberían incluir. La estructura del objeto de reglas de auditoría se define
+en el [`audit.k8s.io` grupo de API][auditing-api]. Cuando se procesa un evento, se compara
+con la lista de reglas en orden. La primera regla coincidente establece el "nivel de auditoría"
+del evento. Los niveles de auditoría conocidos son:
+
+- `None` - no se registra eventos que disparan esta regla.
+- `Metadata` - se registra los metadatos de la petición (usuario que la realiza, marca de fecha y hora, recurso,
+ verbo, etc.), pero no la petición ni el cuerpo de la respuesta.
+- `Request` - se registra los metadatos del evento y el cuerpo de la petición, pero no el cuerpo de la respuesta.
+ Esto no aplica para las peticiones que no son de recurso.
+- `RequestResponse` - se registra los metadatos del evento, y los cuerpos de la petición y la respuesta.
+ Esto no aplica para las peticiones que no son de recurso.
+
+Es posible indicar un archivo al definir el reglamento en el [kube-apiserver][kube-apiserver]
+usando el parámetro `--audit-policy-file`. Si dicho parámetros se omite, no se registra ningún evento.
+Nótese que el campo `rules` __debe__ proporcionarse en el archivo del reglamento de auditoría.
+Un reglamento sin (0) reglas se considera ilegal.
+
+Abajo se presenta un ejemplo de un archivo de reglamento de auditoría:
+
+{{< codenew file="audit/audit-policy.yaml" >}}
+
+Puedes usar un archivo mínimo de reglamento de auditoría para registrar todas las peticiones al nivel `Metadata` de la siguiente forma:
+
+```yaml
+# Log all requests at the Metadata level.
+apiVersion: audit.k8s.io/v1
+kind: Policy
+rules:
+- level: Metadata
+```
+
+El [perfil de auditoría utilizado por GCE][gce-audit-profile] debería servir como referencia para
+que los administradores construyeran sus propios perfiles de auditoría.
+
+## Backends de auditoría
+
+Los backends de auditoría persisten los eventos de auditoría en un almacenamiento externo.
+El [Kube-apiserver][kube-apiserver] por defecto proporciona tres backends:
+
+- Backend de logs, que escribe los eventos en disco
+- Backend de webhook, que envía los eventos a una API externa
+- Backend dinámico, que configura backends de webhook a través de objetos de la API AuditSink.
+
+En todos los casos, la estructura de los eventos de auditoría se define por la API del grupo
+`audit.k8s.io`. La versión actual de la API es
+[`v1`][auditing-api].
+
+{{< note >}}
+En el caso de parches, el cuerpo de la petición es una matriz JSON con operaciones de parcheado, en vez
+de un objeto JSON que incluya el objeto de la API de Kubernetes apropiado. Por ejemplo,
+el siguiente cuerpo de mensaje es una petición de parcheado válida para
+`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
+
+```json
+[
+ {
+ "op": "replace",
+ "path": "/spec/parallelism",
+ "value": 0
+ },
+ {
+ "op": "remove",
+ "path": "/spec/template/spec/containers/0/terminationMessagePolicy"
+ }
+]
+```
+{{< /note >}}
+
+### Backend de Logs
+
+El backend de logs escribe los eventos de auditoría a un archivo en formato JSON.
+ Puedes configurar el backend de logs de auditoría usando el siguiente
+ parámetro de [kube-apiserver][kube-apiserver] flags:
+
+- `--audit-log-path` especifica la ruta al archivo de log que el backend utiliza para
+escribir los eventos de auditoría. Si no se especifica, se deshabilita el backend de logs. `-` significa salida estándar
+- `--audit-log-maxage` define el máximo número de días a retener los archivos de log
+- `--audit-log-maxbackup` define el máximo número de archivos de log a retener
+- `--audit-log-maxsize` define el tamaño máximo en megabytes del archivo de logs antes de ser rotado
+
+### Backend de Webhook
+
+El backend de Webhook envía eventos de auditoría a una API remota, que se supone es la misma API
+que expone el [kube-apiserver][kube-apiserver]. Puedes configurar el backend de webhook de auditoría usando
+los siguientes parámetros de kube-apiserver:
+
+- `--audit-webhook-config-file` especifica la ruta a un archivo con configuración del webhook.
+La configuración del webhook es, de hecho, un archivo [kubeconfig][kubeconfig].
+- `--audit-webhook-initial-backoff` especifica la cantidad de tiempo a esperar tras una petición fallida
+antes de volver a intentarla. Los reintentos posteriores se ejecutan con retraso exponencial.
+
+El archivo de configuración del webhook usa el formato kubeconfig para especificar la dirección remota
+del servicio y las credenciales para conectarse al mismo.
+
+En la versión 1.13, los backends de webhook pueden configurarse [dinámicamente](#dynamic-backend).
+
+### Procesamiento por lotes
+
+Tanto el backend de logs como el de webhook permiten procesamiento por lotes. Si usamos el webhook como ejemplo,
+ aquí se muestra la lista de parámetros disponibles. Para aplicar el mismo parámetro al backend de logs,
+ simplemente sustituye `webhook` por `log` en el nombre del parámetro. Por defecto,
+ el procesimiento por lotes está habilitado en `webhook` y deshabilitado en `log`. De forma similar,
+ por defecto la regulación (throttling) está habilitada en `webhook` y deshabilitada en `log`.
+
+- `--audit-webhook-mode` define la estrategia de memoria intermedia (búfer), que puede ser una de las siguientes:
+ - `batch` - almacenar eventos y procesarlos de forma asíncrona en lotes. Esta es la estrategia por defecto.
+ - `blocking` - bloquear todas las respuestas del servidor API al procesar cada evento de forma individual.
+ - `blocking-strict` - igual que blocking, pero si ocurre un error durante el registro de la audtoría en la etapa RequestReceived, la petición completa al apiserver fallará.
+
+Los siguientes parámetros se usan únicamente en el modo `batch`:
+
+- `--audit-webhook-batch-buffer-size` define el número de eventos a almacenar de forma intermedia antes de procesar por lotes.
+ Si el ritmo de eventos entrantes desborda la memoria intermedia, dichos eventos se descartan.
+- `--audit-webhook-batch-max-size` define el número máximo de eventos en un único proceso por lotes.
+- `--audit-webhook-batch-max-wait` define la cantidad máxima de tiempo a esperar de forma incondicional antes de procesar los eventos de la cola.
+- `--audit-webhook-batch-throttle-qps` define el promedio máximo de procesos por lote generados por segundo.
+- `--audit-webhook-batch-throttle-burst` define el número máximo de procesos por lote generados al mismo tiempo si el QPS permitido no fue usado en su totalidad anteriormente.
+
+#### Ajuste de parámetros
+
+Los parámetros deberían ajustarse a la carga del apiserver.
+
+Por ejemplo, si kube-apiserver recibe 100 peticiones por segundo, y para cada petición se audita
+las etapas `ResponseStarted` y `ResponseComplete`, deberías esperar unos ~200
+eventos de auditoría generados por segundo. Asumiendo que hay hasta 100 eventos en un lote,
+deberías establecer el nivel de regulación (throttling) por lo menos a 2 QPS. Además, asumiendo
+que el backend puede tardar hasta 5 segundos en escribir eventos, deberías configurar el tamaño de la memoria intermedia para almacenar hasta 5 segundos de eventos, esto es,
+10 lotes, o sea, 1000 eventos.
+
+En la mayoría de los casos, sin embargo, los valores por defecto de los parámetros
+deberían ser suficientes y no deberías preocuparte de ajustarlos manualmente.
+Puedes echar un vistazo a la siguientes métricas de Prometheus que expone kube-apiserver
+y también los logs para monitorizar el estado del subsistema de auditoría:
+
+- `apiserver_audit_event_total` métrica que contiene el número total de eventos de auditoría exportados.
+- `apiserver_audit_error_total` métrica que contiene el número total de eventos descartados debido a un error durante su exportación.
+
+### Truncado
+
+Tanto el backend de logs como el de webhook permiten truncado. Como ejemplo, aquí se indica la
+lista de parámetros disponible para el backend de logs:
+
+ - `audit-log-truncate-enabled` indica si el truncado de eventos y por lotes está habilitado.
+ - `audit-log-truncate-max-batch-size` indica el tamaño máximo en bytes del lote enviado al backend correspondiente.
+ - `audit-log-truncate-max-event-size` indica el tamaño máximo en bytes del evento de auditoría enviado al backend correspondiente.
+
+Por defecto, el truncado está deshabilitado tanto en `webhook` como en `log`; un administrador del clúster debe configurar bien el parámetro `audit-log-truncate-enabled` o `audit-webhook-truncate-enabled` para habilitar esta característica.
+
+### Backend dinámico
+
+{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
+
+En la versión 1.13 de Kubernetes, puedes configurar de forma dinámica los backends de auditoría usando objetos de la API AuditSink.
+
+Para habilitar la auditoría dinámica, debes configurar los siguientes parámetros de apiserver:
+
+- `--audit-dynamic-configuration`: el interruptor principal. Cuando esta característica sea GA, el único parámetro necesario.
+- `--feature-gates=DynamicAuditing=true`: en evaluación en alpha y beta.
+- `--runtime-config=auditregistration.k8s.io/v1alpha1=true`: habilitar la API.
+
+Cuando se habilita, un objeto AuditSink se provisiona de la siguiente forma:
+
+```yaml
+apiVersion: auditregistration.k8s.io/v1alpha1
+kind: AuditSink
+metadata:
+ name: mysink
+spec:
+ policy:
+ level: Metadata
+ stages:
+ - ResponseComplete
+ webhook:
+ throttle:
+ qps: 10
+ burst: 15
+ clientConfig:
+ url: "https://audit.app"
+```
+
+Para una definición completa de la API, ver [AuditSink](/docs/reference/generated/kubernetes-api/v1.13/#auditsink-v1alpha1-auditregistration). Múltiples objetos existirán como soluciones independientes.
+
+Aquellos backends estáticos que se configuran con parámetros en tiempo de ejecución no se ven impactados por esta característica.
+ Sin embargo, estos backends dinámicos comparten las opciones de truncado del webhook estático, de forma que si dichas opciones se configura con parámetros en tiempo de ejecución, entonces se aplican a todos los backends dinámicos.
+
+#### Reglamento
+
+El reglamento de AuditSink es diferente del de la auditoría en tiempo de ejecución. Esto es debido a que el objeto de la API sirve para casos de uso diferentes. El reglamento continuará
+evolucionando para dar cabida a más casos de uso.
+
+El campo `level` establece el nivel de auditoría indicado a todas las peticiones. El campo `stages` es actualmente una lista de las etapas que se permite registrar.
+
+#### Seguridad
+
+Los administradores deberían tener en cuenta que permitir el acceso en modo escritura de esta característica otorga el modo de acceso de lectura
+a toda la información del clúster. Así, el acceso debería gestionarse como un privilegio de nivel `cluster-admin`.
+
+#### Rendimiento
+
+Actualmente, esta característica tiene implicaciones en el apiserver en forma de incrementos en el uso de la CPU y la memoria.
+Aunque debería ser nominal cuando se trata de un número pequeño de destinos, se realizarán pruebas adicionales de rendimiento para entender su impacto real antes de que esta API pase a beta.
+
+## Configuración multi-clúster
+
+Si estás extendiendo la API de Kubernetes mediante la [capa de agregación][kube-aggregator], puedes también
+configurar el registro de auditoría para el apiserver agregado. Para ello, pasa las opciones
+de configuración en el mismo formato que se describe arriba al apiserver agregado
+y configura el mecanismo de ingestión de logs para que recolecte los logs de auditoría.
+Cada uno de los apiservers puede tener configuraciones de auditoría diferentes con
+diferentes reglamentos de auditoría.
+
+## Ejemplos de recolectores de Logs
+
+### Uso de fluentd para recolectar y distribuir eventos de auditoría a partir de un archivo de logs
+
+[Fluentd][fluentd] es un recolector de datos de libre distribución que proporciona una capa unificada de registros.
+En este ejemplo, usaremos fluentd para separar los eventos de auditoría por nombres de espacio:
+
+1. Instala [fluentd][fluentd_install_doc], fluent-plugin-forest y fluent-plugin-rewrite-tag-filter en el nodo donde corre kube-apiserver
+{{< note >}}
+Fluent-plugin-forest y fluent-plugin-rewrite-tag-filter son plugins de fluentd. Puedes obtener detalles de la instalación de estos plugins en el documento [fluentd plugin-management][fluentd_plugin_management_doc].
+{{< /note >}}
+
+1. Crea un archivo de configuración para fluentd:
+
+ ```
+ cat <<'EOF' > /etc/fluentd/config
+ # fluentd conf runs in the same host with kube-apiserver
+
+ @type tail
+ # audit log path of kube-apiserver
+ path /var/log/kube-audit
+ pos_file /var/log/audit.pos
+ format json
+ time_key time
+ time_format %Y-%m-%dT%H:%M:%S.%N%z
+ tag audit
+
+
+
+ #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
+ @type record_transformer
+ enable_ruby
+
+ namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ? "none":record["objectRef"]["namespace"])}
+
+
+
+
+ # route audit according to namespace element in context
+ @type rewrite_tag_filter
+
+ key namespace
+ pattern /^(.+)/
+ tag ${tag}.$1
+
+
+
+
+ @type record_transformer
+ remove_keys namespace
+
+
+
+ @type forest
+ subtype file
+ remove_prefix audit
+
+ time_slice_format %Y%m%d%H
+ compress gz
+ path /var/log/audit-${tag}.*.log
+ format json
+ include_time_key true
+
+
+ EOF
+ ```
+
+1. Arranca fluentd:
+
+ ```shell
+ fluentd -c /etc/fluentd/config -vv
+ ```
+
+1. Arranca el componente kube-apiserver con las siguientes opciones:
+
+ ```shell
+ --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
+ ```
+
+1. Comprueba las auditorías de los distintos espacios de nombres en `/var/log/audit-*.log`
+
+### Uso de logstash para recolectar y distribuir eventos de auditoría desde un backend de webhook
+
+[Logstash][logstash] es una herramienta de libre distribución de procesamiento de datos en servidor.
+En este ejemplo, vamos a usar logstash para recolectar eventos de auditoría a partir de un backend de webhook,
+y grabar los eventos de usuarios diferentes en archivos distintos.
+
+1. Instala [logstash][logstash_install_doc]
+
+1. Crea un archivo de configuración para logstash:
+
+ ```
+ cat < /etc/logstash/config
+ input{
+ http{
+ #TODO, figure out a way to use kubeconfig file to authenticate to logstash
+ #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
+ port=>8888
+ }
+ }
+ filter{
+ split{
+ # Webhook audit backend sends several events together with EventList
+ # split each event here.
+ field=>[items]
+ # We only need event subelement, remove others.
+ remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
+ }
+ mutate{
+ rename => {items=>event}
+ }
+ }
+ output{
+ file{
+ # Audit events from different users will be saved into different files.
+ path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
+ }
+ }
+ EOF
+ ```
+
+1. Arranca logstash:
+
+ ```shell
+ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
+ ```
+
+1. Crea un [archivo kubeconfig](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) para el webhook del backend de auditoría de kube-apiserver:
+
+ cat < /etc/kubernetes/audit-webhook-kubeconfig
+ apiVersion: v1
+ clusters:
+ - cluster:
+ server: http://:8888
+ name: logstash
+ contexts:
+ - context:
+ cluster: logstash
+ user: ""
+ name: default-context
+ current-context: default-context
+ kind: Config
+ preferences: {}
+ users: []
+ EOF
+
+1. Arranca kube-apiserver con las siguientes opciones:
+
+ ```shell
+ --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
+ ```
+
+1. Comprueba las auditorías en los directorios `/var/log/kube-audit-*/audit` de los nodos de logstash
+
+Nótese que además del plugin para salida en archivos, logstash ofrece una variedad de salidas adicionales
+que permiten a los usuarios enviar la información donde necesiten. Por ejemplo, se puede enviar los eventos de auditoría
+al plugin de elasticsearch que soporta búsquedas avanzadas y analíticas.
+
+[kube-apiserver]: /docs/admin/kube-apiserver
+[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
+[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
+[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
+[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
+[fluentd]: http://www.fluentd.org/
+[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
+[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management
+[logstash]: https://www.elastic.co/products/logstash
+[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
+[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
+
+
diff --git a/content/es/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/es/docs/tasks/debug-application-cluster/debug-init-containers.md
new file mode 100644
index 0000000000..d4c8ae141b
--- /dev/null
+++ b/content/es/docs/tasks/debug-application-cluster/debug-init-containers.md
@@ -0,0 +1,129 @@
+---
+title: Depurar Contenedores de Inicialización
+content_type: task
+---
+
+
+
+Esta página muestra cómo investigar problemas relacionados con la ejecución
+de los contenedores de inicialización (init containers). Las líneas de comando del ejemplo de abajo
+se refieren al Pod como `` y a los Init Containers como `` e
+ `` respectivamente.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+* Deberías estar familizarizado con el concepto de [Init Containers](/docs/concepts/abstractions/init-containers/).
+* Deberías conocer la [Configuración de un Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
+
+
+
+
+
+## Comprobar el estado de los Init Containers
+
+Muestra el estado de tu pod:
+
+```shell
+kubectl get pod
+```
+
+Por ejemplo, un estado de `Init:1/2` indica que uno de los Init Containers
+se ha ejecutado satisfactoriamente:
+
+```
+NAME READY STATUS RESTARTS AGE
+ 0/1 Init:1/2 0 7s
+```
+
+Echa un vistazo a [Comprender el estado de un Pod](#understanding-pod-status) para más ejemplos
+de valores de estado y sus significados.
+
+## Obtener detalles acerca de los Init Containers
+
+Para ver información detallada acerca de la ejecución de un Init Container:
+
+```shell
+kubectl describe pod
+```
+
+Por ejemplo, un Pod con dos Init Containers podría mostrar lo siguiente:
+
+```
+Init Containers:
+ :
+ Container ID: ...
+ ...
+ State: Terminated
+ Reason: Completed
+ Exit Code: 0
+ Started: ...
+ Finished: ...
+ Ready: True
+ Restart Count: 0
+ ...
+ :
+ Container ID: ...
+ ...
+ State: Waiting
+ Reason: CrashLoopBackOff
+ Last State: Terminated
+ Reason: Error
+ Exit Code: 1
+ Started: ...
+ Finished: ...
+ Ready: False
+ Restart Count: 3
+ ...
+```
+
+También puedes acceder al estado del Init Container de forma programática mediante
+la lectura del campo `status.initContainerStatuses` dentro del Pod Spec:
+
+
+```shell
+kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
+```
+
+
+Este comando devolverá la misma información que arriba en formato JSON.
+
+## Acceder a los logs de los Init Containers
+
+Indica el nombre del Init Container así como el nombre del Pod para
+ acceder a sus logs.
+
+```shell
+kubectl logs -c
+```
+
+Los Init Containers que ejecutan secuencias de línea de comandos muestran los comandos
+conforme se van ejecutando. Por ejemplo, puedes hacer lo siguiente en Bash
+indicando `set -x` al principio de la secuencia.
+
+
+
+
+
+## Comprender el estado de un Pod
+
+Un estado de un Pod que comienza con `Init:` especifica el estado de la ejecución de
+un Init Container. La tabla a continuación muestra algunos valores de estado de ejemplo
+que puedes encontrar al depurar Init Containers.
+
+Estado | Significado
+------ | -------
+`Init:N/M` | El Pod tiene `M` Init Containers, y por el momento se han completado `N`.
+`Init:Error` | Ha fallado la ejecución de un Init Container.
+`Init:CrashLoopBackOff` | Un Init Container ha fallado de forma repetida.
+`Pending` | El Pod todavía no ha comenzado a ejecutar sus Init Containers.
+`PodInitializing` o `Running` | El Pod ya ha terminado de ejecutar sus Init Containers.
+
+
+
+
+
diff --git a/content/es/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/es/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
new file mode 100644
index 0000000000..af95eaff7c
--- /dev/null
+++ b/content/es/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
@@ -0,0 +1,119 @@
+---
+content_type: concept
+title: Escribiendo Logs con Elasticsearch y Kibana
+---
+
+
+
+En la plataforma Google Compute Engine (GCE), por defecto da soporte a la escritura de logs haciendo uso de
+[Stackdriver Logging](https://cloud.google.com/logging/), el cual se describe en detalle en [Logging con Stackdriver Logging](/docs/user-guide/logging/stackdriver).
+
+Este artículo describe cómo configurar un clúster para la ingesta de logs en
+[Elasticsearch](https://www.elastic.co/products/elasticsearch) y su posterior visualización
+con [Kibana](https://www.elastic.co/products/kibana), a modo de alternativa a
+Stackdriver Logging cuando se utiliza la plataforma GCE.
+
+{{< note >}}
+No se puede desplegar de forma automática Elasticsearch o Kibana en un clúster alojado en Google Kubernetes Engine. Hay que desplegarlos de forma manual.
+{{< /note >}}
+
+
+
+
+
+Para utilizar Elasticsearch y Kibana para escritura de logs del clúster, deberías configurar
+la siguiente variable de entorno que se muestra a continuación como parte de la creación
+del clúster con kube-up.sh:
+
+```shell
+KUBE_LOGGING_DESTINATION=elasticsearch
+```
+
+También deberías asegurar que `KUBE_ENABLE_NODE_LOGGING=true` (que es el valor por defecto en la plataforma GCE).
+
+Así, cuando crees un clúster, un mensaje te indicará que la recolección de logs de los daemons de Fluentd
+que corren en cada nodo enviará dichos logs a Elasticsearch:
+
+```shell
+cluster/kube-up.sh
+```
+```
+...
+Project: kubernetes-satnam
+Zone: us-central1-b
+... calling kube-up
+Project: kubernetes-satnam
+Zone: us-central1-b
++++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
++++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
++++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
+Looking for already existing resources
+Starting master and configuring firewalls
+Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
+NAME ZONE SIZE_GB TYPE STATUS
+kubernetes-master-pd us-central1-b 20 pd-ssd READY
+Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
++++ Logging using Fluentd to elasticsearch
+```
+
+Tanto los pods por nodo de Fluentd, como los pods de Elasticsearch, y los pods de Kibana
+ deberían ejecutarse en el namespace de kube-system inmediatamente después
+ de que el clúster esté disponible.
+
+```shell
+kubectl get pods --namespace=kube-system
+```
+```
+NAME READY STATUS RESTARTS AGE
+elasticsearch-logging-v1-78nog 1/1 Running 0 2h
+elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
+fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
+fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h
+fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h
+fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h
+kibana-logging-v1-bhpo8 1/1 Running 0 2h
+kube-dns-v3-7r1l9 3/3 Running 0 2h
+monitoring-heapster-v4-yl332 1/1 Running 1 2h
+monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
+```
+
+Los pods de `fluentd-elasticsearch` recogen los logs de cada nodo y los envían a los
+pods de `elasticsearch-logging`, que son parte de un [servicio](/docs/concepts/services-networking/service/) llamado `elasticsearch-logging`.
+Estos pods de Elasticsearch almacenan los logs y los exponen via una API REST.
+El pod de `kibana-logging` proporciona una UI via web donde leer los logs almacenados en
+Elasticsearch, y es parte de un servicio denominado `kibana-logging`.
+
+Los servicios de Elasticsearch y Kibana ambos están en el namespace `kube-system`
+ y no se exponen de forma directa mediante una IP accesible públicamente. Para poder acceder a dichos logs,
+sigue las instrucciones acerca de cómo [Acceder a servicios corriendo en un clúster](/docs/concepts/cluster-administration/access-clusater/#accessing-services-running-on-the-cluster).
+
+Si tratas de acceder al servicio de `elasticsearch-logging` desde tu navegador,
+verás una página de estado que se parece a la siguiente:
+
+
+
+A partir de ese momento, puedes introducir consultas de Elasticsearch directamente en el navegador, si lo necesitas.
+Echa un vistazo a la [documentación de Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
+para más detalles acerca de cómo hacerlo.
+
+De forma alternativa, puedes ver los logs de tu clúster en Kibana (de nuevo usando las
+[instrucciones para acceder a un servicio corriendo en un clúster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)).
+La primera vez que visitas la URL de Kibana se te presentará una página que te pedirá
+que configures una vista de los logs. Selecciona la opción de valores de serie temporal
+ y luego `@timestamp`. En la página siguiente selecciona la pestaña de `Discover`
+y entonces deberías ver todos los logs. Puedes establecer el intervalo de actualización
+en 5 segundos para refrescar los logs de forma regular.
+
+Aquí se muestra una vista típica de logs desde el visor de Kibana:
+
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+¡Kibana te permite todo tipo de potentes opciones para explorar tus logs! Puedes encontrar
+algunas ideas para profundizar en el tema en la [documentación de Kibana](https://www.elastic.co/guide/en/kibana/current/discover.html).
+
+
diff --git a/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md
new file mode 100644
index 0000000000..3a247b5e88
--- /dev/null
+++ b/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -0,0 +1,366 @@
+---
+title: Escribiendo Logs con Stackdriver
+content_type: concept
+---
+
+
+
+Antes de seguir leyendo esta página, deberías familiarizarte con el
+[resumen de escritura de logs en Kubernetes](/docs/concepts/cluster-administration/logging).
+
+{{< note >}}
+Por defecto, Stackdriver recolecta toda la salida estándar de tus contenedores, así
+como el flujo de la salida de error. Para recolectar cualquier log tu aplicación escribe en un archivo (por ejemplo),
+ver la [estrategia de sidecar](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
+en el resumen de escritura de logs en Kubernetes.
+{{< /note >}}
+
+
+
+
+
+
+## Despliegue
+
+Para ingerir logs, debes desplegar el agente de Stackdriver Logging en cada uno de los nodos de tu clúster.
+Dicho agente configura una instancia de `fluentd`, donde la configuración se guarda en un `ConfigMap`
+y las instancias se gestionan a través de un `DaemonSet` de Kubernetes. El despliegue actual del
+`ConfigMap` y el `DaemonSet` dentro de tu clúster depende de tu configuración individual del clúster.
+
+### Desplegar en un nuevo clúster
+
+#### Google Kubernetes Engine
+
+Stackdriver es la solución por defecto de escritura de logs para aquellos clústeres desplegados en Google Kubernetes Engine.
+Stackdriver Logging se despliega por defecto en cada clúster a no ser que se le indique de forma explícita no hacerlo.
+
+#### Otras plataformas
+
+Para desplegar Stackdriver Logging en un *nuevo* clúster que estés creando con
+`kube-up.sh`, haz lo siguiente:
+
+1. Configura la variable de entorno `KUBE_LOGGING_DESTINATION` con el valor `gcp`.
+1. **Si no estás trabajando en GCE**, incluye `beta.kubernetes.io/fluentd-ds-ready=true`
+en la variable `KUBE_NODE_LABELS`.
+
+Una vez que tu clúster ha arrancado, cada nodo debería ejecutar un agente de Stackdriver Logging.
+Los `DaemonSet` y `ConfigMap` se configuran como extras. Si no estás usando `kube-up.sh`,
+considera la posibilidad de arrancar un clúster sin una solución pre-determinada de escritura de logs
+y entonces desplegar los agentes de Stackdriver Logging una vez el clúster esté ejecutándose.
+
+{{< warning >}}
+El proceso de Stackdriver Logging reporta problemas conocidos en plataformas distintas
+a Google Kubernetes Engine. Úsalo bajo tu propio riesgo.
+{{< /warning >}}
+
+### Desplegar a un clúster existente
+
+1. Aplica una etiqueta en cada nodo, si no estaba presente ya.
+
+ El despliegue del agente de Stackdriver Logging utiliza etiquetas de nodo para
+ determinar en qué nodos debería desplegarse. Estas etiquetas fueron introducidas
+ para distinguir entre nodos de Kubernetes de la versión 1.6 o superior.
+ Si el clúster se creó con Stackdriver Logging configurado y el nodo tiene la
+ versión 1.5.X o inferior, ejecutará fluentd como un pod estático. Puesto que un nodo
+ no puede tener más de una instancia de fluentd, aplica únicamente las etiquetas
+ a los nodos que no tienen un pod de fluentd ya desplegado. Puedes confirmar si tu nodo
+ ha sido etiquetado correctamente ejecutando `kubectl describe` de la siguiente manera:
+
+ ```
+ kubectl describe node $NODE_NAME
+ ```
+
+ La salida debería ser similar a la siguiente:
+
+ ```
+ Name: NODE_NAME
+ Role:
+ Labels: beta.kubernetes.io/fluentd-ds-ready=true
+ ...
+ ```
+
+ Asegúrate que la salida contiene la etiqueta `beta.kubernetes.io/fluentd-ds-ready=true`.
+ Si no está presente, puedes añadirla usando el comando `kubectl label` como se indica:
+
+ ```
+ kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
+ ```
+
+ {{< note >}}
+ Si un nodo falla y tiene que volver a crearse, deberás volver a definir
+ la etiqueta al nuevo nodo. Para facilitar esta tarea, puedes utilizar el
+ parámetro de línea de comandos del Kubelet para aplicar dichas etiquetas
+ cada vez que se arranque un nodo.
+ {{< /note >}}
+
+1. Despliega un `ConfigMap` con la configuración del agente de escritura de logs ejecutando el siguiente comando:
+
+ ```
+ kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
+ ```
+
+ Este comando crea el `ConfigMap` en el espacio de nombres `default`. Puedes descargar el archivo
+ manualmente y cambiarlo antes de crear el objeto `ConfigMap`.
+
+1. Despliega el agente `DaemonSet` de escritura de logs ejecutando el siguiente comando:
+
+ ```
+ kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
+ ```
+
+ Puedes descargar y editar este archivo antes de usarlo igualmente.
+
+## Verificar el despliegue de tu agente de escritura de logs
+
+Tras el despliegue del `DaemonSet` de StackDriver, puedes comprobar el estado de
+cada uno de los despliegues de los agentes ejecutando el siguiente comando:
+
+```shell
+kubectl get ds --all-namespaces
+```
+
+Si tienes 3 nodos en el clúster, la salida debería ser similar a esta:
+
+```
+NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE
+...
+default fluentd-gcp-v2.0 3 3 3 beta.kubernetes.io/fluentd-ds-ready=true 5m
+...
+```
+Para comprender cómo funciona Stackdriver, considera la siguiente especificación
+de un generador de logs sintéticos [counter-pod.yaml](/examples/debug/counter-pod.yaml):
+
+{{< codenew file="debug/counter-pod.yaml" >}}
+
+Esta especificación de pod tiene un contenedor que ejecuta una secuencia de comandos bash
+que escribe el valor de un contador y la fecha y hora cada segundo, de forma indefinida.
+Vamos a crear este pod en el espacio de nombres por defecto.
+
+```shell
+kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+
+Puedes observar el pod corriendo:
+
+```shell
+kubectl get pods
+```
+```
+NAME READY STATUS RESTARTS AGE
+counter 1/1 Running 0 5m
+```
+
+Durante un período de tiempo corto puedes observar que el estado del pod es 'Pending', debido a que el kubelet
+tiene primero que descargar la imagen del contenedor. Cuando el estado del pod cambia a `Running`
+puedes usar el comando `kubectl logs` para ver la salida de este pod contador.
+
+```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
+...
+```
+
+Como se describe en el resumen de escritura de logs, este comando visualiza las entradas de logs
+del archivo de logs del contenedor. Si se termina el contenedor y Kubernetes lo reinicia,
+todavía puedes acceder a los logs de la ejecución previa del contenedor. Sin embargo,
+si el pod se desaloja del nodo, los archivos de log se pierden. Vamos a demostrar este
+comportamiento mediante el borrado del contenedor que ejecuta nuestro contador:
+
+```shell
+kubectl delete pod counter
+```
+```
+pod "counter" deleted
+```
+
+y su posterior re-creación:
+
+```shell
+kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+```
+pod/counter created
+```
+
+Tras un tiempo, puedes acceder a los logs del pod contador otra vez:
+
+```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
+...
+```
+
+Como era de esperar, únicamente se visualizan las líneas de log recientes. Sin embargo,
+para una aplicación real seguramente prefieras acceder a los logs de todos los contenedores,
+especialmente cuando te haga falta depurar problemas. Aquí es donde haber habilitado
+Stackdriver Logging puede ayudarte.
+
+## Ver logs
+
+El agente de Stackdriver Logging asocia metadatos a cada entrada de log, para que puedas usarlos posteriormente
+en consultas para seleccionar sólo los mensajes que te interesan: por ejemplo,
+los mensajes de un pod en particular.
+
+Los metadatos más importantes son el tipo de recurso y el nombre del log.
+El tipo de recurso de un log de contenedor tiene el valor `container`, que se muestra como
+`GKE Containers` en la UI (incluso si el clúster de Kubernetes no está en Google Kubernetes Engine).
+El nombre de log es el nombre del contenedor, de forma que si tienes un pod con
+dos contenedores, denominados `container_1` y `container_2` en la especificación, sus logs
+tendrán los nombres `container_1` y `container_2` respectivamente.
+
+Los componentes del sistema tienen el valor `compute` como tipo de recursos, que se muestra como
+`GCE VM Instance` en la UI. Los nombres de log para los componentes del sistema son fijos.
+Para un nodo de Google Kubernetes Engine, cada entrada de log de cada componente de sistema tiene uno de los siguientes nombres:
+
+* docker
+* kubelet
+* kube-proxy
+
+Puedes aprender más acerca de cómo visualizar los logs en la [página dedicada a Stackdriver](https://cloud.google.com/logging/docs/view/logs_viewer).
+
+Uno de los posibles modos de ver los logs es usando el comando de línea de interfaz
+[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging)
+del [SDK de Google Cloud](https://cloud.google.com/sdk/).
+Este comando usa la [sintaxis de filtrado](https://cloud.google.com/logging/docs/view/advanced_filters) de StackDriver Logging
+para consultar logs específicos. Por ejemplo, puedes ejecutar el siguiente comando:
+
+```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"
+```
+
+Como puedes observar, muestra los mensajes del contenedor contador tanto de la
+primera como de la segunda ejecución, a pesar de que el kubelet ya había eliminado los logs del primer contenedor.
+
+### Exportar logs
+
+Puedes exportar los logs al [Google Cloud Storage](https://cloud.google.com/storage/)
+o a [BigQuery](https://cloud.google.com/bigquery/) para llevar a cabo un análisis más profundo.
+Stackdriver Logging ofrece el concepto de destinos, donde puedes especificar el destino de
+las entradas de logs. Más información disponible en la [página de exportación de logs](https://cloud.google.com/logging/docs/export/configure_export_v2) de StackDriver.
+
+## Configurar los agentes de Stackdriver Logging
+
+En ocasiones la instalación por defecto de Stackdriver Logging puede que no se ajuste a tus necesidades, por ejemplo:
+
+* Puede que quieras añadir más recursos porque el rendimiento por defecto no encaja con tus necesidades.
+* Puede que quieras añadir un parseo adicional para extraer más metadatos de tus mensajes de log,
+como la severidad o referencias al código fuente.
+* Puede que quieras enviar los logs no sólo a Stackdriver o sólo enviarlos a Stackdriver parcialmente.
+
+En cualquiera de estos casos, necesitas poder cambiar los parámetros del `DaemonSet` y el `ConfigMap`.
+
+### Prerequisitos
+
+Si estás usando GKE y Stackdriver Logging está habilitado en tu clúster, no puedes
+cambiar su configuración, porque ya está gestionada por GKE.
+Sin embargo, puedes deshabilitar la integración por defecto y desplegar la tuya propia.
+
+{{< note >}}
+Tendrás que mantener y dar soporte tú mismo a la nueva configuración desplegada:
+actualizar la imagen y la configuración, ajustar los recuros y todo eso.
+{{< /note >}}
+
+Para deshabilitar la integración por defecto, usa el siguiente comando:
+
+```
+gcloud beta container clusters update --logging-service=none CLUSTER
+```
+
+Puedes encontrar notas acerca de cómo instalar los agentes de Stackdriver Logging
+ en un clúster ya ejecutándose en la [sección de despliegue](#deploying).
+
+### Cambiar los parámetros del `DaemonSet`
+
+Cuando tienes un `DaemonSet` de Stackdriver Logging en tu clúster, puedes simplemente
+modificar el campo `template` en su especificación, y el controlador del daemonset actualizará los pods por ti. Por ejemplo,
+asumamos que acabas de instalar el Stackdriver Logging como se describe arriba. Ahora quieres cambiar
+el límite de memoria que se le asigna a fluentd para poder procesar más logs de forma segura.
+
+Obtén la especificación del `DaemonSet` que corre en tu clúster:
+
+```shell
+kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml
+```
+
+A continuación, edita los requisitos del recurso en el `spec` y actualiza el objeto `DaemonSet`
+en el apiserver usando el siguiente comando:
+
+```shell
+kubectl replace -f fluentd-gcp-ds.yaml
+```
+
+Tras un tiempo, los pods de agente de Stackdriver Logging se reiniciarán con la nueva configuración.
+
+### Cambiar los parámetros de fluentd
+
+La configuración de Fluentd se almacena en un objeto `ConfigMap`. Realmente se trata de un conjunto
+de archivos de configuración que se combinan conjuntamente. Puedes aprender acerca de
+la configuración de fluentd en el [sitio oficial](http://docs.fluentd.org).
+
+Imagina que quieres añadir una nueva lógica de parseo a la configuración actual, de forma que fluentd pueda entender
+el formato de logs por defecto de Python. Un filtro apropiado de fluentd para conseguirlo sería:
+
+```
+
+ type parser
+ format /^(?\w):(?\w):(?.*)/
+ reserve_data true
+ suppress_parse_error_log true
+ key_name log
+
+```
+
+Ahora tienes que añadirlo a la configuración actual y que los agentes de Stackdriver Logging la usen.
+Para ello, obtén la versión actual del `ConfigMap` de Stackdriver Logging de tu clúster
+ejecutando el siguiente comando:
+
+```shell
+kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml
+```
+
+Luego, como valor de la clave `containers.input.conf`, inserta un nuevo filtro justo después
+de la sección `source`.
+
+{{< note >}}
+El orden es importante.
+{{< /note >}}
+
+Actualizar el `ConfigMap` en el apiserver es más complicado que actualizar el `DaemonSet`.
+Es mejor considerar que un `ConfigMap` es inmutable. Así, para poder actualizar la configuración, deberías
+crear un nuevo `ConfigMap` con otro nombre y cambiar el `DaemonSet` para que apunte al nuevo
+siguiendo la [guía de arriba](#changing-daemonset-parameters).
+
+### Añadir plugins de fluentd
+
+Fluentd está desarrollado en Ruby y permite extender sus capacidades mediante el uso de
+[plugins](http://www.fluentd.org/plugins). Si quieres usar un plugin que no está incluido en
+la imagen por defecto del contenedor de Stackdriver Logging, debes construir tu propia imagen.
+Imagina que quieres añadir un destino Kafka para aquellos mensajes de un contenedor en particular
+para poder procesarlos posteriormente. Puedes reusar los [fuentes de imagen de contenedor](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
+con algunos pequeños cambios:
+
+* Cambia el archivo Makefile para que apunte a tu repositorio de contenedores, ej. `PREFIX=gcr.io/`.
+* Añade tu dependencia al archivo Gemfile, por ejemplo `gem 'fluent-plugin-kafka'`.
+
+Luego, ejecuta `make build push` desde ese directorio. Cuando el `DaemonSet` haya tomado los cambios de la nueva imagen,
+podrás usar el plugin que has indicado en la configuración de fluentd.
+
+
diff --git a/content/es/docs/tasks/manage-daemon/_index.md b/content/es/docs/tasks/manage-daemon/_index.md
index 000b87a214..dfd787f9c5 100755
--- a/content/es/docs/tasks/manage-daemon/_index.md
+++ b/content/es/docs/tasks/manage-daemon/_index.md
@@ -1,4 +1,4 @@
---
-title: Gestionar y ejecutar demonios
+title: Gestionar y ejecutar daemons
weight: 45
---
\ No newline at end of file
diff --git a/content/es/examples/audit/audit-policy.yaml b/content/es/examples/audit/audit-policy.yaml
new file mode 100644
index 0000000000..cdc46be754
--- /dev/null
+++ b/content/es/examples/audit/audit-policy.yaml
@@ -0,0 +1,68 @@
+apiVersion: audit.k8s.io/v1 # Esto es obligatorio.
+kind: Policy
+# No generar eventos de auditoría para las peticiones en la etapa RequestReceived.
+omitStages:
+ - "RequestReceived"
+rules:
+ # Registrar los cambios del pod al nivel RequestResponse
+ - level: RequestResponse
+ resources:
+ - group: ""
+ # Los recursos "pods" no hacen coincidir las peticiones a cualquier sub-recurso de pods,
+ # lo que es consistente con la regla RBAC.
+ resources: ["pods"]
+ # Registrar "pods/log", "pods/status" al nivel Metadata
+ - level: Metadata
+ resources:
+ - group: ""
+ resources: ["pods/log", "pods/status"]
+
+ # No registrar peticiones al configmap denominado "controller-leader"
+ - level: None
+ resources:
+ - group: ""
+ resources: ["configmaps"]
+ resourceNames: ["controller-leader"]
+
+ # No registrar peticiones de observación hechas por "system:kube-proxy" sobre puntos de acceso o servicios
+ - level: None
+ users: ["system:kube-proxy"]
+ verbs: ["watch"]
+ resources:
+ - group: "" # Grupo API base
+ resources: ["endpoints", "services"]
+
+ # No registrar peticiones autenticadas a ciertas rutas URL que no son recursos.
+ - level: None
+ userGroups: ["system:authenticated"]
+ nonResourceURLs:
+ - "/api*" # Coincidencia por comodín.
+ - "/version"
+
+ # Registrar el cuerpo de la petición de los cambios de configmap en kube-system.
+ - level: Request
+ resources:
+ - group: "" # Grupo API base
+ resources: ["configmaps"]
+ # Esta regla sólo aplica a los recursos en el Namespace "kube-system".
+ # La cadena vacía "" se puede usar para seleccionar los recursos sin Namespace.
+ namespaces: ["kube-system"]
+
+ # Registrar los cambios de configmap y secret en todos los otros Namespaces al nivel Metadata.
+ - level: Metadata
+ resources:
+ - group: "" # Grupo API base
+ resources: ["secrets", "configmaps"]
+
+ # Registrar todos los recursos en core y extensions al nivel Request.
+ - level: Request
+ resources:
+ - group: "" # Grupo API base
+ - group: "extensions" # La versión del grupo NO debería incluirse.
+
+ # Regla para "cazar" todos las demás peticiones al nivel Metadata.
+ - level: Metadata
+ # Las peticiones de larga duración, como los watches, que caen bajo esta regla no
+ # generan un evento de auditoría en RequestReceived.
+ omitStages:
+ - "RequestReceived"
diff --git a/content/es/examples/controllers/frontend.yaml b/content/es/examples/controllers/frontend.yaml
new file mode 100644
index 0000000000..4a10c52a7d
--- /dev/null
+++ b/content/es/examples/controllers/frontend.yaml
@@ -0,0 +1,21 @@
+apiVersion: apps/v1
+kind: ReplicaSet
+metadata:
+ name: frontend
+ labels:
+ app: guestbook
+ tier: frontend
+spec:
+ # modifica las réplicas según tu caso de uso
+ replicas: 3
+ selector:
+ matchLabels:
+ tier: frontend
+ template:
+ metadata:
+ labels:
+ tier: frontend
+ spec:
+ containers:
+ - name: php-redis
+ image: gcr.io/google_samples/gb-frontend:v3
diff --git a/content/es/examples/controllers/hpa-rs.yaml b/content/es/examples/controllers/hpa-rs.yaml
new file mode 100644
index 0000000000..a8388530dc
--- /dev/null
+++ b/content/es/examples/controllers/hpa-rs.yaml
@@ -0,0 +1,11 @@
+apiVersion: autoscaling/v1
+kind: HorizontalPodAutoscaler
+metadata:
+ name: frontend-scaler
+spec:
+ scaleTargetRef:
+ kind: ReplicaSet
+ name: frontend
+ minReplicas: 3
+ maxReplicas: 10
+ targetCPUUtilizationPercentage: 50
diff --git a/content/es/examples/controllers/job.yaml b/content/es/examples/controllers/job.yaml
new file mode 100644
index 0000000000..b448f2eb81
--- /dev/null
+++ b/content/es/examples/controllers/job.yaml
@@ -0,0 +1,14 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: pi
+spec:
+ template:
+ spec:
+ containers:
+ - name: pi
+ image: perl
+ command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
+ restartPolicy: Never
+ backoffLimit: 4
+
diff --git a/content/es/examples/controllers/nginx-deployment.yaml b/content/es/examples/controllers/nginx-deployment.yaml
new file mode 100644
index 0000000000..f7f95deebb
--- /dev/null
+++ b/content/es/examples/controllers/nginx-deployment.yaml
@@ -0,0 +1,21 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: nginx-deployment
+ labels:
+ app: nginx
+spec:
+ replicas: 3
+ selector:
+ matchLabels:
+ app: nginx
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - name: nginx
+ image: nginx:1.7.9
+ ports:
+ - containerPort: 80
diff --git a/content/es/examples/controllers/replicaset.yaml b/content/es/examples/controllers/replicaset.yaml
new file mode 100644
index 0000000000..e5dfdf6c43
--- /dev/null
+++ b/content/es/examples/controllers/replicaset.yaml
@@ -0,0 +1,17 @@
+apiVersion: apps/v1
+kind: ReplicaSet
+metadata:
+ name: my-repset
+spec:
+ replicas: 3
+ selector:
+ matchLabels:
+ pod-is-for: garbage-collection-example
+ template:
+ metadata:
+ labels:
+ pod-is-for: garbage-collection-example
+ spec:
+ containers:
+ - name: nginx
+ image: nginx
diff --git a/content/es/examples/debug/counter-pod.yaml b/content/es/examples/debug/counter-pod.yaml
new file mode 100644
index 0000000000..f997886386
--- /dev/null
+++ b/content/es/examples/debug/counter-pod.yaml
@@ -0,0 +1,10 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: counter
+spec:
+ containers:
+ - name: count
+ image: busybox
+ args: [/bin/sh, -c,
+ 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
diff --git a/content/es/examples/pods/pod-rs.yaml b/content/es/examples/pods/pod-rs.yaml
new file mode 100644
index 0000000000..df7b390597
--- /dev/null
+++ b/content/es/examples/pods/pod-rs.yaml
@@ -0,0 +1,23 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: pod1
+ labels:
+ tier: frontend
+spec:
+ containers:
+ - name: hello1
+ image: gcr.io/google-samples/hello-app:2.0
+
+---
+
+apiVersion: v1
+kind: Pod
+metadata:
+ name: pod2
+ labels:
+ tier: frontend
+spec:
+ containers:
+ - name: hello2
+ image: gcr.io/google-samples/hello-app:1.0
diff --git a/content/fr/_index.html b/content/fr/_index.html
index 89a66f48b6..3b659534e8 100644
--- a/content/fr/_index.html
+++ b/content/fr/_index.html
@@ -3,9 +3,6 @@ title: "Solution professionnelle d’orchestration de conteneurs"
abstract: "Déploiement, mise à l'échelle et gestion automatisée des conteneurs"
cid: home
---
-{{< announcement >}}
-
-{{< deprecationwarning >}}
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
diff --git a/content/fr/docs/concepts/overview/working-with-objects/namespaces.md b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md
new file mode 100644
index 0000000000..90229676b0
--- /dev/null
+++ b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md
@@ -0,0 +1,111 @@
+---
+title: Namespaces
+content_type: concept
+weight: 30
+---
+
+
+
+Kubernetes prend en charge plusieurs clusters virtuels presents sur le même cluster physique.
+Ces clusters virtuels sont appelés namespaces (espaces de noms en français).
+
+
+
+## Quand utiliser plusieurs namespaces
+
+Les namespaces sont destinés à être utilisés dans les environnements ayant de nombreux utilisateurs répartis en plusieurs équipes ou projets. Pour les clusters de quelques dizaines d'utilisateurs, vous n'avez pas
+besoin d'utiliser de namespaces. Commencez à utiliser des namespaces lorsque vous avez
+besoin des fonctionnalités qu'ils fournissent.
+
+Les namespaces sont des groupes de noms. Ils fournissent un modèle d'isolation de nommage des ressources. Les noms des ressources doivent être uniques dans un namespace,
+mais pas dans l'ensemble des namespaces. Les namespaces ne peuvent pas être imbriqués les uns dans les autres et chaque ressource Kubernetes ne peut se trouver que dans un seul namespace.
+
+Les namespaces sont un moyen de répartir les ressources d'un cluster entre plusieurs utilisateurs (via [quota de ressources](/docs/concepts/policy/resource-quotas/)).
+
+Dans les futures versions de Kubernetes, les objets du même namespace auront les mêmes
+stratégies de contrôle d'accès par défaut.
+
+Il n'est pas nécessaire d'utiliser plusieurs namespaces juste pour séparer des ressources légèrement différentes, telles que les versions du même logiciel: utiliser les [labels](/docs/user-guide/labels) pour distinguer les
+ressources dans le même namespace.
+
+## Utilisation des namespaces
+
+La création et la suppression des namespaces sont décrites dans la [Documentation du guide d'administration pour les namespaces](/docs/admin/namespaces).
+
+{{< note >}}
+Évitez de créer des namespaces avec le préfixe `kube-`, car il est réservé aux namespaces système de Kubernetes.
+{{< /note >}}
+
+### Affichage des namespaces
+
+Dans un cluster vous pouvez lister les namespaces actuels à l'aide de:
+
+```shell
+kubectl get namespace
+```
+
+```
+NAME STATUS AGE
+default Active 1d
+kube-node-lease Active 1d
+kube-public Active 1d
+kube-system Active 1d
+```
+
+Kubernetes démarre avec quatre namespaces initiaux:
+
+- `default` Le namespace par défaut pour les objets sans autre namespace
+- `kube-system` Le namespace pour les objets créés par Kubernetes lui-même
+- `kube-public` Ce namespace est créé automatiquement et est visible par tous les utilisateurs (y compris ceux qui ne sont pas authentifiés). Ce namespace est principalement réservé à l'utilisation du cluster, au cas où certaines ressources devraient être disponibles publiquement dans l'ensemble du cluster. L'aspect public de ce namespace n'est qu'une convention, pas une exigence.
+- `kube-node-lease` Ce namespace contient les objets de bail associés à chaque nœud, ce qui améliore les performances des pulsations du nœud à mesure que le cluster évolue.
+
+### Définition du namespaces pour une requête
+
+Pour définir le namespace pour une requête en cours, utilisez l'indicateur `--namespace`.
+
+Par exemple:
+
+```shell
+kubectl run nginx --image=nginx --namespace=
+kubectl get pods --namespace=
+```
+
+### Spécifier un namespace
+
+Vous pouvez enregistrer de manière permanente le namespace à utiliser pour toutes les commandes kubectl à suivre.
+
+```shell
+kubectl config set-context --current --namespace=
+# Validez-le
+kubectl config view --minify | grep namespace:
+```
+
+## Namespaces et DNS
+
+Lorsque vous créez un [Service](/fr/docs/concepts/services-networking/service/), il crée une [entrée DNS](/fr/docs/concepts/services-networking/dns-pod-service/) correspondante.
+Cette entrée est de la forme `..svc.cluster.local`, ce qui signifie
+que si un conteneur utilise simplement ``, il résoudra le service qui
+est local à un namespace. Ceci est utile pour utiliser la même configuration pour
+plusieurs namespaces tels que le Développement, la Qualification et la Production. Si vous voulez naviguer
+entre plusieurs namespaces, vous devez utiliser le nom de domaine complet (FQDN ou nom de domaine complet en français).
+
+## Tous les objets ne se trouvent pas dans un namespace
+
+La plupart des ressources Kubernetes (par exemple, pods, services, contrôleurs de réplication et autres) sont
+dans des namespaces. Cependant, les ressources de type namespace ne sont pas elles-mêmes dans un namespace.
+Et les ressources de bas niveau, telles que les [noeuds](/docs/admin/node) et les volumes persistants, ne se trouvent dans aucun namespace.
+
+Pour voir quelles ressources Kubernetes sont et ne sont pas dans un namespace:
+
+```shell
+# Dans un namespace
+kubectl api-resources --namespaced=true
+
+# Pas dans un namespace
+kubectl api-resources --namespaced=false
+```
+
+## {{% heading "whatsnext" %}}
+
+- En savoir plus sur [créer un nouveau namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace).
+- En savoir plus sur [suppression d'un namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).
diff --git a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md
index 9a6f96d36a..aece7de62c 100644
--- a/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/fr/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -63,10 +63,8 @@ du tableau de PodCondition a six champs possibles :
* `PodScheduled` : le Pod a été affecté à un nœud ;
* `Ready` : le Pod est prêt à servir des requêtes et doit être rajouté aux équilibreurs
de charge de tous les Services correspondants ;
- * `Initialized` : tous les [init containers](/docs/concepts/workloads/pods/init-containers)
+ * `Initialized` : tous les [init containers](/fr/docs/concepts/workloads/pods/init-containers)
ont démarré correctement ;
- * `Unschedulable` : le scheduler ne peut pas affecter le Pod pour l'instant, par exemple
- par manque de ressources ou en raison d'autres contraintes ;
* `ContainersReady` : tous les conteneurs du Pod sont prêts.
@@ -98,12 +96,12 @@ Chaque sonde a un résultat parmi ces trois :
* Failure: Le Conteneur a échoué au diagnostic.
* Unknown: L'exécution du diagnostic a échoué, et donc aucune action ne peut être prise.
-kubelet peut optionnellement exécuter et réagir à deux types de sondes sur des conteneurs
+kubelet peut optionnellement exécuter et réagir à trois types de sondes sur des conteneurs
en cours d'exécution :
* `livenessProbe` : Indique si le Conteneur est en cours d'exécution. Si
la liveness probe échoue, kubelet tue le Conteneur et le Conteneur
- est soumis à sa [politique de redémarrage](#restart-policy) (restart policy).
+ est soumis à sa [politique de redémarrage](#politique-de-redemarrage) (restart policy).
Si un Conteneur ne fournit pas de liveness probe, l'état par défaut est `Success`.
* `readinessProbe` : Indique si le Conteneur est prêt à servir des requêtes.
@@ -113,7 +111,13 @@ en cours d'exécution :
`Failure`. Si le Conteneur ne fournit pas de readiness probe, l'état par
défaut est `Success`.
-### Quand devez-vous utiliser une liveness ou une readiness probe ?
+* `startupProbe`: Indique si l'application à l'intérieur du conteneur a démarré.
+ Toutes les autres probes sont désactivées si une starup probe est fournie,
+ jusqu'à ce qu'elle réponde avec succès. Si la startup probe échoue, le kubelet
+ tue le conteneur, et le conteneur est assujetti à sa [politique de redémarrage](#politique-de-redemarrage).
+ Si un conteneur ne fournit pas de startup probe, l'état par défaut est `Success`.
+
+### Quand devez-vous utiliser une liveness probe ?
Si le process de votre Conteneur est capable de crasher de lui-même lorsqu'il
rencontre un problème ou devient inopérant, vous n'avez pas forcément besoin
@@ -124,6 +128,10 @@ Si vous désirez que votre Conteneur soit tué et redémarré si une sonde écho
spécifiez une liveness probe et indiquez une valeur pour `restartPolicy` à Always
ou OnFailure.
+### Quand devez-vous utiliser une readiness probe ?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
Si vous voulez commencer à envoyer du trafic à un Pod seulement lorsqu'une sonde
réussit, spécifiez une readiness probe. Dans ce cas, la readiness probe peut être
la même que la liveness probe, mais l'existence de la readiness probe dans la spec
@@ -142,8 +150,16 @@ de sa suppression, le Pod se met automatiquement dans un état non prêt, que la
readiness probe existe ou non.
Le Pod reste dans le statut non prêt le temps que les Conteneurs du Pod s'arrêtent.
-Pour plus d'informations sur la manière de mettre en place une liveness ou readiness probe,
-voir [Configurer des Liveness et Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
+### Quand devez-vous utiliser une startup probe ?
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+Si votre conteneur démarre habituellement en plus de `initialDelaySeconds + failureThreshold × periodSeconds`,
+vous devriez spécifier une startup probe qui vérifie le même point de terminaison que la liveness probe. La valeur par défaut pour `periodSeconds` est 30s.
+Vous devriez alors mettre sa valeur `failureThreshold` suffisamment haute pour permettre au conteneur de démarrer, sans changer les valeurs par défaut de la liveness probe. Ceci aide à se protéger de deadlocks.
+
+Pour plus d'informations sur la manière de mettre en place une liveness, readiness ou startup probe,
+voir [Configurer des Liveness, Readiness et Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
## Statut d'un Pod et d'un Conteneur
@@ -172,9 +188,7 @@ d'informations.
...
```
-* `Running` : Indique que le conteneur s'exécute sans problème. Une fois qu'un centeneur est
-dans l'état Running, le hook `postStart` est exécuté (s'il existe). Cet état affiche aussi
-le moment auquel le conteneur est entré dans l'état Running.
+* `Running` : Indique que le conteneur s'exécute sans problème. Le hook `postStart` (s'il existe) est exécuté avant que le conteneur entre dans l'état Running. Cet état affiche aussi le moment auquel le conteneur est entré dans l'état Running.
```yaml
...
@@ -199,27 +213,30 @@ dans l'état Terminated, le hook `preStop` est exécuté (s'il existe).
...
```
-## Pod readiness gate
+## Pod readiness {#pod-readiness-gate}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
-Afin d'étendre la readiness d'un Pod en autorisant l'injection de données
-supplémentaires ou des signaux dans `PodStatus`, Kubernetes 1.11 a introduit
-une fonctionnalité appelée [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md).
-Vous pouvez utiliser le nouveau champ `ReadinessGate` dans `PodSpec`
-pour spécifier des conditions additionnelles à évaluer pour la readiness d'un Pod.
-Si Kubernetes ne peut pas trouver une telle condition dans le champ `status.conditions`
-d'un Pod, le statut de la condition est "`False`" par défaut. Voici un exemple :
+Votre application peut injecter des données dans `PodStatus`.
+
+_Pod readiness_. Pour utiliser cette fonctionnalité, remplissez `readinessGates` dans le PodSpec avec
+une liste de conditions supplémentaires que le kubelet évalue pour la disponibilité du Pod.
+
+Les Readiness gates sont déterminées par l'état courant des champs `status.condition` du Pod.
+Si Kubernetes ne peut pas trouver une telle condition dans le champs `status.conditions` d'un Pod, the statut de la condition
+est mise par défaut à "`False`".
+
+Voici un exemple :
```yaml
-Kind: Pod
+kind: Pod
...
spec:
readinessGates:
- conditionType: "www.example.com/feature-1"
status:
conditions:
- - type: Ready # ceci est une builtin PodCondition
+ - type: Ready # une PodCondition intégrée
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
@@ -233,27 +250,26 @@ status:
...
```
-Les nouvelles conditions du Pod doivent être conformes au [format des étiquettes](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) de Kubernetes.
-La commande `kubectl patch` ne prenant pas encore en charge la modifictaion du statut
-des objets, les nouvelles conditions du Pod doivent être injectées avec
-l'action `PATCH` en utilisant une des [bibliothèques KubeClient](/docs/reference/using-api/client-libraries/).
+Les conditions du Pod que vous ajoutez doivent avoir des noms qui sont conformes au [format des étiquettes](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) de Kubernetes.
-Avec l'introduction de nouvelles conditions d'un Pod, un Pod est considéré comme prêt
-**seulement** lorsque les deux déclarations suivantes sont vraies :
+### Statut de la disponibilité d'un Pod {#statut-pod-disponibilité}
+
+La commande `kubectl patch` ne peut pas patcher le statut d'un objet.
+Pour renseigner ces `status.conditions` pour le pod, les applications et
+{{< glossary_tooltip term_id="operator-pattern" text="operators">}} doivent utiliser l'action `PATCH`.
+Vous pouvez utiliser une [bibliothèque client Kubernetes](/docs/reference/using-api/client-libraries/) pour
+écrire du code qui renseigne les conditions particulières pour la disponibilité dun Pod.
+
+Pour un Pod utilisant des conditions particulières, ce Pod est considéré prêt **seulement**
+lorsque les deux déclarations ci-dessous sont vraies :
* Tous les conteneurs du Pod sont prêts.
-* Toutes les conditions spécifiées dans `ReadinessGates` sont à "`True`".
+* Toutes les conditions spécifiées dans `ReadinessGates` sont `True`.
-Pour faciliter le changement de l'évaluation de la readiness d'un Pod,
-une nouvelle condition de Pod `ContainersReady` est introduite pour capturer
-l'ancienne condition `Ready` d'un Pod.
+Lorsque les conteneurs d'un Pod sont prêts mais qu'au moins une condition particulière
+est manquante ou `False`, le kubelet renseigne la condition du Pod à `ContainersReady`.
-Avec K8s 1.11, en tant que fonctionnalité alpha, "Pod Ready++" doit être explicitement activé en mettant la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodReadinessGates`
-à true.
-
-Avec K8s 1.12, la fonctionnalité est activée par défaut.
-
-## Restart policy
+## Politique de redémarrage
La structure PodSpec a un champ `restartPolicy` avec comme valeur possible
Always, OnFailure et Never. La valeur par défaut est Always.
@@ -267,33 +283,30 @@ une fois attaché à un nœud, un Pod ne sera jamais rattaché à un autre nœud
## Durée de vie d'un Pod
-En général, un Pod ne disparaît pas avant que quelqu'un le détruise. Ceci peut être
-un humain ou un contrôleur. La seule exception à cette règle est pour les Pods ayant
-une `phase` Succeeded ou Failed depuis une durée donnée (déterminée
-par `terminated-pod-gc-threshold` sur le master), qui expireront et seront
-automatiquement détruits.
+En général, les Pods restent jusqu'à ce qu'un humain ou un process de
+{{< glossary_tooltip term_id="controller" text="contrôleur" >}} les supprime explicitement.
-Trois types de contrôleurs sont disponibles :
+Le plan de contrôle nettoie les Pods terminés (avec une phase à `Succeeded` ou
+`Failed`), lorsque le nombre de Pods excède le seuil configuré
+(determiné par `terminated-pod-gc-threshold` dans le kube-controller-manager).
+Ceci empêche une fuite de ressources lorsque les Pods sont créés et supprimés au fil du temps.
-- Utilisez un [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) pour des
-Pods qui doivent se terminer, par exemple des calculs par batch. Les Jobs sont appropriés
+Il y a différents types de ressources pour créer des Pods :
+
+- Utilisez un {{< glossary_tooltip term_id="deployment" >}},
+ {{< glossary_tooltip term_id="replica-set" >}} ou {{< glossary_tooltip term_id="statefulset" >}}
+ pour les Pods qui ne sont pas censés terminer, par exemple des serveurs web.
+
+- Utilisez un {{< glossary_tooltip term_id="job" >}}
+ pour les Pods qui sont censés se terminer une fois leur tâche accomplie. Les Jobs sont appropriés
seulement pour des Pods ayant `restartPolicy` égal à OnFailure ou Never.
-- Utilisez un [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou
- [Deployment](/docs/concepts/workloads/controllers/deployment/)
- pour des Pods qui ne doivent pas s'arrêter, par exemple des serveurs web.
- ReplicationControllers sont appropriés pour des Pods ayant `restartPolicy` égal à
- Always.
+- Utilisez un {{< glossary_tooltip term_id="daemonset" >}}
+ pour les Pods qui doivent s'exécuter sur chaque noeud éligible.
-- Utilisez un [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pour des Pods
- qui doivent s'exécuter une fois par machine, car ils fournissent un service système
- au niveau de la machine.
-
-Les trois types de contrôleurs contiennent un PodTemplate. Il est recommandé
-de créer le contrôleur approprié et de le laisser créer les Pods, plutôt que de
-créer directement les Pods vous-même. Ceci car les Pods seuls ne sont pas résilients
-aux pannes machines, alors que les contrôleurs le sont.
+Toutes les ressources de charges de travail contiennent une PodSpec. Il est recommandé de créer
+la ressource de charges de travail appropriée et laisser le contrôleur de la ressource créer les Pods
+pour vous, plutôt que de créer directement les Pods vous-même.
Si un nœud meurt ou est déconnecté du reste du cluster, Kubernetes applique
une politique pour mettre la `phase` de tous les Pods du nœud perdu à Failed.
@@ -391,7 +404,7 @@ spec:
[attacher des handlers à des événements de cycle de vie d'un conteneur](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
* Apprenez par la pratique
- [configurer des liveness et readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
+ [configurer des liveness, readiness et startup probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
* En apprendre plus sur les [hooks de cycle de vie d'un Conteneur](/docs/concepts/containers/container-lifecycle-hooks/).
diff --git a/content/fr/docs/concepts/workloads/pods/pod-overview.md b/content/fr/docs/concepts/workloads/pods/pod-overview.md
index b1803ba5e0..bfa5e02c62 100644
--- a/content/fr/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/fr/docs/concepts/workloads/pods/pod-overview.md
@@ -16,23 +16,18 @@ Cette page fournit un aperçu du `Pod`, l'objet déployable le plus petit dans l
## Comprendre les Pods
-Un *Pod* est l'unité d'exécution de base d'une application Kubernetes--l'unité la plus petite et la plus simple dans le modèle d'objets de Kubernetes--que vous créez ou déployez. Un Pod représente des process en cours d'exécution dans votre {{< glossary_tooltip term_id="cluster" >}}.
+Un *Pod* est l'unité d'exécution de base d'une application Kubernetes--l'unité la plus petite et la plus simple dans le modèle d'objets de Kubernetes--que vous créez ou déployez. Un Pod représente des process en cours d'exécution dans votre {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
-Un Pod encapsule un conteneur applicatif (ou, dans certains cas, plusieurs conteneurs), des ressources de stockage, une IP réseau unique, et des options qui contrôlent comment le ou les conteneurs doivent s'exécuter. Un Pod représente une unité de déploiement : *une instance unique d'une application dans Kubernetes*, qui peut consister soit en un unique {{< glossary_tooltip text="container" term_id="container" >}} soit en un petit nombre de conteneurs qui sont étroitement liés et qui partagent des ressources.
+Un Pod encapsule un conteneur applicatif (ou, dans certains cas, plusieurs conteneurs), des ressources de stockage, une identité réseau (adresse IP) unique, ainsi que des options qui contrôlent comment le ou les conteneurs doivent s'exécuter. Un Pod représente une unité de déploiement : *une instance unique d'une application dans Kubernetes*, qui peut consister soit en un unique {{< glossary_tooltip text="container" term_id="container" >}} soit en un petit nombre de conteneurs qui sont étroitement liés et qui partagent des ressources.
-> [Docker](https://www.docker.com) est le runtime de conteneurs le plus courant utilisé dans un Pod Kubernetes, mais les Pods prennent également en charge d'autres [runtimes de conteneurs](https://kubernetes.io/docs/setup/production-environment/container-runtimes/).
+> [Docker](https://www.docker.com) est le runtime de conteneurs le plus courant utilisé dans un Pod Kubernetes, mais les Pods prennent également en charge d'autres [runtimes de conteneurs](/docs/setup/production-environment/container-runtimes/).
Les Pods dans un cluster Kubernetes peuvent être utilisés de deux manières différentes :
* **les Pods exécutant un conteneur unique**. Le modèle "un-conteneur-par-Pod" est le cas d'utilisation Kubernetes le plus courant ; dans ce cas, vous pouvez voir un Pod comme un wrapper autour d'un conteneur unique, et Kubernetes gère les Pods plutôt que directement les conteneurs.
* **les Pods exécutant plusieurs conteneurs devant travailler ensemble**. Un Pod peut encapsuler une application composée de plusieurs conteneurs co-localisés qui sont étroitement liés et qui doivent partager des ressources. Ces conteneurs co-localisés pourraient former une unique unité de service cohésive--un conteneur servant des fichiers d'un volume partagé au public, alors qu'un conteneur "sidecar" séparé rafraîchit ou met à jour ces fichiers. Le Pod enveloppe ensemble ces conteneurs et ressources de stockage en une entité maniable de base.
-Le [Blog Kubernetes](http://kubernetes.io/blog) contient quelques informations supplémentaires sur les cas d'utilisation des Pods. Pour plus d'informations, voir :
-
-* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
-* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
-
-Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (par ex., exécuter plusieurs instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle généralement de _réplication_. Des Pods répliqués sont en général créés et gérés comme un groupe par une abstraction appelée Controller. Voir [Pods et Controllers](#pods-and-controllers) pour plus d'informations.
+Chaque Pod est destiné à exécuter une instance unique d'une application donnée. Si vous désirez mettre à l'échelle votre application horizontalement, (pour fournir plus de ressources au global en exécutant plus d'instances), vous devez utiliser plusieurs Pods, un pour chaque instance. Dans Kubernetes, on parle typiquement de _réplication_. Des Pods répliqués sont en général créés et gérés en tant que groupe par une ressource de charge de travail et son {{< glossary_tooltip text="_contrôleur_" term_id="controller" >}}. Voir [Pods et contrôleurs](#pods-et-controleurs) pour plus d'informations.
### Comment les Pods gèrent plusieurs conteneurs
@@ -48,61 +43,76 @@ Les Pods fournissent deux types de ressources partagées pour leurs conteneurs :
#### Réseau
-Chaque Pod se voit assigner une adresse IP unique. Tous les conteneurs d'un Pod partagent le même namespace réseau, y compris l'adresse IP et les ports réseau. Les conteneurs *à l'intérieur d'un Pod* peuvent communiquer entre eux en utilisant `localhost`. Lorsque les conteneurs dans un Pod communiquent avec des entités *en dehors du Pod*, ils doivent coordonner comment ils utilisent les ressources réseau partagées (comme les ports).
+Chaque Pod se voit assigner une adresse IP unique pour chaque famille d'adresses. Tous les conteneurs d'un Pod partagent le même namespace réseau, y compris l'adresse IP et les ports réseau. Les conteneurs *à l'intérieur d'un Pod* peuvent communiquer entre eux en utilisant `localhost`. Lorsque les conteneurs dans un Pod communiquent avec des entités *en dehors du Pod*, ils doivent coordonner comment ils utilisent les ressources réseau partagées (comme les ports).
#### Stockage
-Un Pod peut spécifier un jeu de {{< glossary_tooltip text="Volumes" term_id="volume" >}} de stockage partagés. Tous les conteneurs dans le Pod peuvent accéder aux volumes partagés, permettant à ces conteneurs de partager des données. Les volumes permettent aussi les données persistantes d'un Pod de survivre au cas où un des conteneurs doit être redémarré. Voir [Volumes](/docs/concepts/storage/volumes/) pour plus d'informations sur la façon dont Kubernetes implémente le stockage partagé dans un Pod.
+Un Pod peut spécifier un jeu de {{< glossary_tooltip text="volumes" term_id="volume" >}} de stockage partagés. Tous les conteneurs dans le Pod peuvent accéder aux volumes partagés, permettant à ces conteneurs de partager des données. Les volumes permettent aussi les données persistantes d'un Pod de survivre au cas où un des conteneurs doit être redémarré. Voir [Volumes](/docs/concepts/storage/volumes/) pour plus d'informations sur la façon dont Kubernetes implémente le stockage partagé dans un Pod.
## Travailler avec des Pods
-Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un Controller), il est programmé pour s'exécuter sur un {{< glossary_tooltip term_id="node" >}} dans votre cluster. Le Pod reste sur ce Nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit *expulsé* par manque de ressources, ou le Nœud soit en échec.
+Vous aurez rarement à créer directement des Pods individuels dans Kubernetes--même des Pods à un seul conteneur. Ceci est dû au fait que les Pods sont conçus comme des entités relativement éphémères et jetables. Lorsqu'un Pod est créé (directement par vous ou indirectement par un {{< glossary_tooltip text="_contrôleur_" term_id="controller" >}}), il est programmé pour s'exécuter sur un {{< glossary_tooltip term_id="node" >}} dans votre cluster. Le Pod reste sur ce nœud jusqu'à ce que le process se termine, l'objet pod soit supprimé, le pod soit *expulsé* par manque de ressources, ou le nœud soit en échec.
{{< note >}}
-Redémarrer un conteneur dans un Pod ne doit pas être confondu avec redémarrer le Pod. Le Pod lui-même ne s'exécute pas, mais est un environnement dans lequel les conteneurs s'exécutent, et persiste jusqu'à ce qu'il soit supprimé.
+Redémarrer un conteneur dans un Pod ne doit pas être confondu avec redémarrer un Pod. Un Pod n'est pas un process, mais un environnement pour exécuter un conteneur. Un Pod persiste jusqu'à ce qu'il soit supprimé.
{{< /note >}}
-Les Pods ne se guérissent pas par eux-mêmes. Si un Pod est programmé sur un Nœud qui échoue, ou si l'opération de programmation elle-même échoue, le Pod est supprimé ; de plus, un Pod ne survivra pas à une expulsion due à un manque de ressources ou une mise en maintenance du Nœud. Kubernetes utilise une abstraction de plus haut niveau, appelée un *Controller*, qui s'occupe de gérer les instances de Pods relativement jetables. Ainsi, même s'il est possible d'utiliser des Pods directement, il est beaucoup plus courant dans Kubernetes de gérer vos Pods en utilisant un Controller. Voir [Pods et Controllers](#pods-and-controllers) pour plus d'informations sur la façon dont Kubernetes utilise des Controllers pour implémenter la mise à l'échelle et la guérison des Pods.
+Les Pods ne se guérissent pas par eux-mêmes. Si un Pod est programmé sur un Nœud qui échoue, ou si l'opération de programmation elle-même échoue, le Pod est supprimé ; de plus, un Pod ne survivra pas à une expulsion due à un manque de ressources ou une mise en maintenance du Nœud. Kubernetes utilise une abstraction de plus haut niveau, appelée un *contrôleur*, qui s'occupe de gérer les instances de Pods relativement jetables. Ainsi, même s'il est possible d'utiliser des Pods directement, il est beaucoup plus courant dans Kubernetes de gérer vos Pods en utilisant un contrôleur.
-### Pods et Controllers
+### Pods et contrôleurs
-Un Controller peut créer et gérer plusieurs Pods pour vous, s'occupant de la réplication et du déploiement et fournissant des capacités d'auto-guérison au niveau du cluster. Par exemple, si un Nœud échoue, le Controller peut automatiquement remplacer le Pod en programmant un remplaçant identique sur un Nœud différent.
+Vous pouvez utiliser des ressources de charges de travail pour créer et gérer plusieurs Pods pour vous. Un contrôleur pour la ressource gère la réplication,
+le plan de déploiement et la guérison automatique en cas de problèmes du Pod. Par exemple, si un noeud est en échec, un contrôleur note que les Pods de ce noeud
+ont arrêté de fonctionner et créent des Pods pour les remplacer. L'ordonnanceur place le Pod de remplacement sur un noeud en fonctionnement.
-Quelques exemples de Controllers qui contiennent un ou plusieurs pods :
+Voici quelques exemples de ressources de charges de travail qui gèrent un ou plusieurs Pods :
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-
-En général, les Controllers utilisent des Templates de Pod que vous lui fournissez pour créer les Pods dont il est responsable.
+* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
+* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
## Templates de Pod
-Les Templates de Pod sont des spécifications de pod qui sont inclus dans d'autres objets, comme les
-[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), et
-[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Les Controllers utilisent les Templates de Pod pour créer réellement les pods.
-L'exemple ci-dessous est un manifeste simple pour un Pod d'un conteneur affichant un message.
+Les Templates de Pod sont des spécifications pour créer des Pods, et sont inclus dans les ressources de charges de travail comme
+les [Deployments](/fr/docs/concepts/workloads/controllers/deployment/), les [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) et
+les [DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
+
+Chaque contrôleur pour une ressource de charges de travail utilise le template de pod à l'intérieur de l'objet pour créer les Pods. Le template de pod fait partie de l'état désiré de la ressource de charges de travail que vous avez utilisé pour exécuter votre application.
+
+L'exemple ci-dessous est un manifest pour un Job simple avec un `template` qui démarre un conteneur. Le conteneur dans ce Pod affiche un message puis se met en pause.
```yaml
-apiVersion: v1
-kind: Pod
+apiVersion: batch/v1
+kind: Job
metadata:
- name: myapp-pod
- labels:
- app: myapp
+ name: hello
spec:
- containers:
- - name: myapp-container
- image: busybox
- command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
+ template:
+ # Ceci est un template de pod
+ spec:
+ containers:
+ - name: hello
+ image: busybox
+ command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
+ restartPolicy: OnFailure
+ # Le template de pod se termine ici
```
-Plutôt que de spécifier tous les états désirés courants de tous les réplicas, les templates de pod sont comme des emporte-pièces. Une fois qu'une pièce a été coupée, la pièce n'a plus de relation avec l'outil. Il n'y a pas de lien qui persiste dans le temps entre le template et le pod. Un changement à venir dans le template ou même le changement pour un nouveau template n'a pas d'effet direct sur les pods déjà créés. De manière similaire, les pods créés par un replication controller peuvent par la suite être modifiés directement. C'est en contraste délibéré avec les pods, qui spécifient l'état désiré courant de tous les conteneurs appartenant au pod. Cette approche simplifie radicalement la sémantique système et augmente la flexibilité de la primitive.
+
+Modifier le template de pod ou changer pour un nouvau template de pod n'a pas d'effet sur les pods déjà existants. Les Pods ne reçoivent pas une mise à jour
+du template directement ; au lieu de cela, un nouveau Pod est créé pour correspondre au nouveau template de pod.
+
+Par exemple, un contrôleur de Deployment s'assure que les Pods en cours d'exécution correspondent au template de pod en cours. Si le template est mis à jour,
+le contrôleur doit supprimer les pods existants et créer de nouveaux Pods avec le nouveau template. Chaque contrôleur de charges de travail implémente ses propres
+règles pour gérer les changements du template de Pod.
+
+Sur les noeuds, le {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} n'observe ou ne gère pas directement les détails concernant les templates de pods et leurs mises à jours ; ces détails sont abstraits. Cette abstraction et cette séparation des préoccupations simplifie la sémantique du système, et rend possible l'extension du comportement du cluster sans changer le code existant.
## {{% heading "whatsnext" %}}
* En savoir plus sur les [Pods](/docs/concepts/workloads/pods/pod/)
+* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explique les dispositions courantes pour des Pods avec plusieurs conteneurs
* En savoir plus sur le comportement des Pods :
* [Terminaison d'un Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [Cycle de vie d'un Pod](/docs/concepts/workloads/pods/pod-lifecycle/)
diff --git a/content/fr/docs/concepts/workloads/pods/pod.md b/content/fr/docs/concepts/workloads/pods/pod.md
index 4d685cca80..b989a8fd8d 100644
--- a/content/fr/docs/concepts/workloads/pods/pod.md
+++ b/content/fr/docs/concepts/workloads/pods/pod.md
@@ -164,7 +164,7 @@ Un exemple de déroulement :
1. Le Pod dans l'API server est mis à jour avec le temps au delà duquel le Pod est considéré "mort" ainsi que la période de grâce.
1. Le Pod est affiché comme "Terminating" dans les listes des commandes client
1. (en même temps que 3) Lorsque Kubelet voit qu'un Pod a été marqué "Terminating", le temps ayant été mis en 2, il commence le processus de suppression du pod.
- 1. Si un des conteneurs du Pod a défini un [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), il est exécuté à l'intérieur du conteneur. Si le `preStop` hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire.
+ 1. Si un des conteneurs du Pod a défini un [preStop hook](/fr/docs/concepts/containers/container-lifecycle-hooks/#hook-details), il est exécuté à l'intérieur du conteneur. Si le `preStop` hook est toujours en cours d'exécution à la fin de la période de grâce, l'étape 2 est invoquée avec une courte (2 secondes) période de grâce supplémentaire une seule fois. Vous devez modifier `terminationGracePeriodSeconds` si le hook `preStop` a besoin de plus de temps pour se terminer.
1. Le signal TERM est envoyé aux conteneurs. Notez que tous les conteneurs du Pod ne recevront pas le signal TERM en même temps et il peut être nécessaire de définir des `preStop` hook si l'ordre d'arrêt est important.
1. (en même temps que 3) Le Pod est supprimé des listes d'endpoints des services, et n'est plus considéré comme faisant partie des pods en cours d'exécution pour les contrôleurs de réplication. Les Pods s'arrêtant lentement ne peuvent pas continuer à servir du trafic, les load balancers (comme le service proxy) les supprimant de leurs rotations.
1. Lorsque la période de grâce expire, les processus s'exécutant toujours dans le Pod sont tués avec SIGKILL.
@@ -186,7 +186,6 @@ Si le master exécute Kubernetes v1.1 ou supérieur, et les nœuds exécutent un
Si l'utilisateur appelle `kubectl describe pod FooPodName`, l'utilisateur peut voir la raison pour laquelle le pod est en état "pending". La table d'événements dans la sortie de la commande "describe" indiquera :
`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
-
Si le master exécute une version antérieure à v1.1, les pods privilégiés ne peuvent alors pas être créés. Si l'utilisateur tente de créer un pod ayant un conteneur privilégié, l'utilisateur obtiendra l'erreur suivante :
`The Pod "FooPodName" is invalid.
spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
@@ -196,4 +195,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
Le Pod est une ressource au plus haut niveau dans l'API REST Kubernetes. Plus de détails sur l'objet de l'API peuvent être trouvés à :
[Objet de l'API Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
-
+Lorsque vous créez un manifest pour un objet Pod, soyez certain que le nom spécifié est un [nom de sous-domaine DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) valide.
diff --git a/content/fr/docs/reference/glossary/addons.md b/content/fr/docs/reference/glossary/addons.md
new file mode 100644
index 0000000000..1911696b3f
--- /dev/null
+++ b/content/fr/docs/reference/glossary/addons.md
@@ -0,0 +1,16 @@
+---
+title: Add-ons
+id: addons
+date: 2019-12-15
+full_link: /docs/concepts/cluster-administration/addons/
+short_description: >
+ Ressources qui étendent les fonctionnalités de Kubernetes.
+
+aka:
+tags:
+- tool
+---
+ Ressources qui étendent les fonctionnalités de Kubernetes.
+
+
+[Installer des addons](/docs/concepts/cluster-administration/addons/) explique l'utilisation des modules complémentaires avec votre cluster et répertorie certains modules complémentaires populaires.
diff --git a/content/fr/docs/reference/glossary/uid.md b/content/fr/docs/reference/glossary/uid.md
new file mode 100644
index 0000000000..80f73c9c5c
--- /dev/null
+++ b/content/fr/docs/reference/glossary/uid.md
@@ -0,0 +1,17 @@
+---
+title: UID
+id: uid
+date: 2018-04-12
+full_link: /docs/concepts/overview/working-with-objects/names
+short_description: >
+ Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets.
+
+aka:
+tags:
+- fundamental
+---
+ Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets.
+
+
+
+Chaque objet créé pendant toute la durée de vie d'un cluster Kubernetes possède un UID distinct. Il vise à distinguer les occurrences historiques d'entités similaires.
\ No newline at end of file
diff --git a/content/fr/docs/reference/glossary/volume.md b/content/fr/docs/reference/glossary/volume.md
new file mode 100644
index 0000000000..deeca963b6
--- /dev/null
+++ b/content/fr/docs/reference/glossary/volume.md
@@ -0,0 +1,20 @@
+---
+title: Volume
+id: volume
+date: 2018-04-12
+full_link: /fr/docs/concepts/storage/volumes/
+short_description: >
+ Un répertoire contenant des données, accessible aux conteneurs d'un pod.
+
+aka:
+tags:
+- core-object
+- fundamental
+---
+ Un répertoire contenant des données, accessible aux {{< glossary_tooltip text="conteneurs" term_id="container" >}} d'un {{< glossary_tooltip term_id="pod" >}}.
+
+
+
+Un volume Kubernetes vit aussi longtemps que le pod qui le contient. Par conséquent, un volume survit à tous les conteneurs qui s'exécutent dans le pod, et les données contenues dans le volume sont préservées lors des redémarrages du conteneur.
+
+Voir [stockage](/fr/docs/concepts/storage/) pour plus d'informations.
\ No newline at end of file
diff --git a/content/fr/docs/reference/glossary/workload.md b/content/fr/docs/reference/glossary/workload.md
new file mode 100644
index 0000000000..8b3a0fd3c3
--- /dev/null
+++ b/content/fr/docs/reference/glossary/workload.md
@@ -0,0 +1,22 @@
+---
+title: Workload
+id: workloads
+date: 2019-02-13
+full_link: /fr/docs/concepts/workloads/
+short_description: >
+ Une charge de travail (workload) est une application exécutée sur Kubernetes.
+
+aka:
+tags:
+- fundamental
+---
+ Une charge de travail (workload) est une application exécutée sur Kubernetes.
+
+
+
+Divers objets de base qui représentent différents types ou parties d'une charge de travail
+incluent les objets DaemonSet, Deployment, Job, ReplicaSet et StatefulSet.
+
+Par exemple, une charge de travail constituée d'un serveur Web et d'une base de données peut exécuter la
+base de données dans un {{< glossary_tooltip term_id="StatefulSet" >}} et le serveur web
+dans un {{< glossary_tooltip term_id="Deployment" >}}.
diff --git a/content/fr/docs/reference/kubectl/kubectl.md b/content/fr/docs/reference/kubectl/kubectl.md
index 64a3c89ce1..23d788c0c3 100755
--- a/content/fr/docs/reference/kubectl/kubectl.md
+++ b/content/fr/docs/reference/kubectl/kubectl.md
@@ -1,6 +1,6 @@
---
title: kubectl
-content_template: templates/tool-reference
+content_type: tool-reference
description: Référence kubectl
notitle: true
---
diff --git a/content/fr/docs/setup/independent/kubelet-integration.md b/content/fr/docs/setup/independent/kubelet-integration.md
index 18ea57310b..05f4839c05 100644
--- a/content/fr/docs/setup/independent/kubelet-integration.md
+++ b/content/fr/docs/setup/independent/kubelet-integration.md
@@ -174,7 +174,7 @@ Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
-#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
+# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
diff --git a/content/fr/docs/setup/learning-environment/minikube.md b/content/fr/docs/setup/learning-environment/minikube.md
index 77ddde7f4d..77be61831f 100644
--- a/content/fr/docs/setup/learning-environment/minikube.md
+++ b/content/fr/docs/setup/learning-environment/minikube.md
@@ -235,16 +235,16 @@ minikube start --vm-driver=
Minikube prend en charge les pilotes suivants:
{{< note >}}
-Voir [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) pour plus de détails sur les pilotes pris en charge et comment installer les plugins.
+Voir [DRIVERS](https://minikube.sigs.k8s.io/docs/drivers/) pour plus de détails sur les pilotes pris en charge et comment installer les plugins.
{{< /note >}}
* virtualbox
* vmwarefusion
-* kvm2 ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
-* hyperkit ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
-* hyperv ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
+* kvm2 ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
+* hyperkit ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
+* hyperv ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver))
Notez que l'adresse IP ci-dessous est dynamique et peut changer. Il peut être récupéré avec `minikube ip`.
-* vmware ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver)
+* vmware ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#vmware-unified-driver)) (VMware unified driver)
* none (Exécute les composants Kubernetes sur l’hôte et non sur une machine virtuelle. Il n'est pas recommandé d'exécuter le pilote none sur des postes de travail personnels. L'utilisation de ce pilote nécessite Docker ([docker installer](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) et un environnement Linux)
#### Démarrage d'un cluster sur des exécutions de conteneur alternatives
diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md
new file mode 100644
index 0000000000..1147f2234e
--- /dev/null
+++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md
@@ -0,0 +1,282 @@
+---
+title: Configurer les comptes de service pour les pods
+content_type: task
+weight: 90
+---
+
+
+Un ServiceAccount (compte de service) fournit une identité pour les processus qui s'exécutent dans un Pod.
+
+*Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi
+[Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).*
+
+{{< note >}}
+Ce document décrit le comportement des comptes de service dans un cluster mis en place conformément aux recommandations du projet Kubernetes. L'administrateur de votre cluster a peut-être personnalisé le comportement dans votre cluster, dans ce cas cette documentation pourrait être non applicable.
+{{< /note >}}
+
+Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes
+authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit
+généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster). Les processus dans les conteneurs dans les Pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`).
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+## Utiliser le compte de service par défaut pour accéder au API server.
+
+Si vous obtenez le raw json ou yaml pour un Pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
+
+Vous pouvez accéder à l'API depuis l'intérieur d'un Pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
+Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage.
+
+Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken: false` sur le compte de service :
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+ name: build-robot
+automountServiceAccountToken: false
+...
+```
+
+Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un Pod particulier :
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: my-pod
+spec:
+ serviceAccountName: build-robot
+ automountServiceAccountToken: false
+ ...
+```
+
+La spéc de Pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`.
+
+## Utiliser plusieurs comptes de services.
+
+Chaque Namespace possède une ressource ServiceAccount par défaut appelée `default`.
+Vous pouvez lister cette ressource et toutes les autres ressources de ServiceAccount dans le Namespace avec cette commande :
+
+```shell
+kubectl get serviceAccounts
+```
+La sortie est comme la suivante :
+
+```
+NAME SECRETS AGE
+default 1 1d
+```
+
+Vous pouvez créer des objets ServiceAccount supplémentaires comme ceci :
+
+```shell
+kubectl apply -f - <
+Annotations: kubernetes.io/service-account.name=build-robot
+ kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
+
+Type: kubernetes.io/service-account-token
+
+Data
+====
+ca.crt: 1338 bytes
+namespace: 7 bytes
+token: ...
+```
+
+{{< note >}}
+Le contenu de `token` est éludé ici.
+{{< /note >}}
+
+## Ajouter ImagePullSecrets à un compte de service
+
+Tout d'abord, créez un imagePullSecret, comme décrit [ici](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
+Puis, vérifiez qu'il a été créé. Par exemple :
+
+```shell
+kubectl get secrets myregistrykey
+```
+
+La sortie est comme la suivante :
+
+```
+NAME TYPE DATA AGE
+myregistrykey kubernetes.io/.dockerconfigjson 1 1d
+```
+
+Ensuite, modifiez le compte de service par défaut du Namespace pour utiliser ce Secret comme un `imagePullSecret`.
+
+```shell
+kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
+```
+
+La version interactive nécessite un traitement manuel :
+
+```shell
+kubectl get serviceaccounts default -o yaml > ./sa.yaml
+```
+
+La sortie du fichier `sa.yaml` est similaire à celle-ci :
+
+```shell
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+ creationTimestamp: 2015-08-07T22:02:39Z
+ name: default
+ namespace: default
+ resourceVersion: "243024"
+ selfLink: /api/v1/namespaces/default/serviceaccounts/default
+ uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
+secrets:
+- name: default-token-uudge
+```
+
+En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajoutez les lignes avec `imagePullSecrets:` et sauvegardez.
+
+La sortie du fichier `sa.yaml` est similaire à celle-ci :
+
+```shell
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+ creationTimestamp: 2015-08-07T22:02:39Z
+ name: default
+ namespace: default
+ selfLink: /api/v1/namespaces/default/serviceaccounts/default
+ uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
+secrets:
+- name: default-token-uudge
+imagePullSecrets:
+- name: myregistrykey
+```
+
+Enfin, remplacez le compte de service par le nouveau fichier `sa.yaml` mis à jour.
+
+```shell
+kubectl replace serviceaccount default -f ./sa.yaml
+```
+
+Maintenant, tous les nouveaux Pods créés dans le Namespace courant auront ceci ajouté à leurs spécifications :
+
+```yaml
+spec:
+ imagePullSecrets:
+ - name: myregistrykey
+```
+
+## Projection du volume des tokens de compte de service
+
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
+
+{{< note >}}
+Ce ServiceAccountTokenVolumeProjection est __beta__ en 1.12 et
+activé en passant tous les paramètres suivants au serveur API :
+
+* `--service-account-issuer`
+* `--service-account-signing-key-file`
+* `--service-account-api-audiences`
+
+{{< /note >}}
+
+Kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité.
+Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé
+
+Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé
+[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un
+Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec :
+
+{{< codenew file="pods/pod-projected-svc-token.yaml" >}}
+
+Créez le Pod
+
+```shell
+kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
+```
+
+Kubelet demandera et stockera le token a la place du Pod, rendra le token disponible pour le Pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures.
+
+L'application est responsable du rechargement du token lorsque celui ci est renouvelé. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation.
diff --git a/content/fr/docs/tasks/tools/install-kubectl.md b/content/fr/docs/tasks/tools/install-kubectl.md
index 8d60357aea..2a88388374 100644
--- a/content/fr/docs/tasks/tools/install-kubectl.md
+++ b/content/fr/docs/tasks/tools/install-kubectl.md
@@ -121,7 +121,7 @@ kubectl version --client
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
-2. Rendrez le binaire kubectl exécutable.
+2. Rendez le binaire kubectl exécutable.
```
chmod +x ./kubectl
diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md
index 724919d0e6..a934464b77 100644
--- a/content/fr/docs/tutorials/hello-minikube.md
+++ b/content/fr/docs/tutorials/hello-minikube.md
@@ -78,7 +78,7 @@ Les déploiements sont le moyen recommandé pour gérer la création et la mise
Pod utilise un conteneur basé sur l'image Docker fournie.
```shell
- kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
+ kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
```
2. Affichez le déploiement :
diff --git a/content/fr/examples/pods/pod-projected-svc-token.yaml b/content/fr/examples/pods/pod-projected-svc-token.yaml
new file mode 100644
index 0000000000..985073c8d3
--- /dev/null
+++ b/content/fr/examples/pods/pod-projected-svc-token.yaml
@@ -0,0 +1,20 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+spec:
+ containers:
+ - image: nginx
+ name: nginx
+ volumeMounts:
+ - mountPath: /var/run/secrets/tokens
+ name: vault-token
+ serviceAccountName: build-robot
+ volumes:
+ - name: vault-token
+ projected:
+ sources:
+ - serviceAccountToken:
+ path: vault-token
+ expirationSeconds: 7200
+ audience: vault
diff --git a/content/id/_index.html b/content/id/_index.html
index 47d7f71ced..e95d661b76 100644
--- a/content/id/_index.html
+++ b/content/id/_index.html
@@ -4,7 +4,6 @@ abstract: "Otomatisasi Kontainer deployment, scaling, dan management"
cid: home
---
-{{< deprecationwarning >}}
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
@@ -60,4 +59,4 @@ Kubernetes sebagai open source memberikan kamu kebebasan untuk menggunaka
{{< blocks/kubernetes-features >}}
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}
\ No newline at end of file
diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md
index ebc205d84a..33f4ada445 100644
--- a/content/id/docs/concepts/_index.md
+++ b/content/id/docs/concepts/_index.md
@@ -49,19 +49,19 @@ untuk penjelasan yang lebih mendetail.
Objek mendasar Kubernetes termasuk:
-* [Pod](/docs/concepts/workloads/pods/pod-overview/)
-* [Service](/docs/concepts/services-networking/service/)
-* [Volume](/docs/concepts/storage/volumes/)
-* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
+* [Pod](/id/docs/concepts/workloads/pods/pod-overview/)
+* [Service](/id/docs/concepts/services-networking/service/)
+* [Volume](/id/docs/concepts/storage/volumes/)
+* [Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/)
Sebagai tambahan, Kubernetes memiliki beberapa abstraksi yang lebih tinggi yang disebut kontroler.
Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah:
-* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/)
+* [Deployment](/id/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/)
+* [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/)
## *Control Plane* Kubernetes
@@ -95,7 +95,7 @@ dengan *node* secara langsung.
#### Metadata objek
-* [Anotasi](/docs/concepts/overview/working-with-objects/annotations/)
+* [Anotasi](/id/docs/concepts/overview/working-with-objects/annotations/)
diff --git a/content/id/docs/concepts/architecture/master-node-communication.md b/content/id/docs/concepts/architecture/control-plane-node-communication.md
similarity index 60%
rename from content/id/docs/concepts/architecture/master-node-communication.md
rename to content/id/docs/concepts/architecture/control-plane-node-communication.md
index 80644983a4..b538179670 100644
--- a/content/id/docs/concepts/architecture/master-node-communication.md
+++ b/content/id/docs/concepts/architecture/control-plane-node-communication.md
@@ -1,12 +1,12 @@
---
-title: Komunikasi Master-Node
+title: Komunikasi antara Control Plane dan Node
content_type: concept
weight: 20
---
-Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara klaster Kubernetes dan master yang sebenarnya hanya berhubungan dengan apiserver saja.
+Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara klaster Kubernetes dan control plane yang sebenarnya hanya berhubungan dengan apiserver saja.
Kenapa ada dokumen ini? Supaya kamu, para pengguna Kubernetes, punya gambaran bagaimana mengatur instalasi untuk memperketat konfigurasi jaringan di dalam klaster.
Hal ini cukup penting, karena klaster bisa saja berjalan pada jaringan tak terpercaya (untrusted network), ataupun melalui alamat-alamat IP publik pada penyedia cloud.
@@ -15,31 +15,24 @@ Hal ini cukup penting, karena klaster bisa saja berjalan pada jaringan tak terpe
-## Klaster menuju Master
+## Node Menuju Control Plane
-Semua jalur komunikasi dari klaster menuju master diterminasi pada apiserver.
-Tidak ada komponen apapun di dalam master, selain apiserver, yang terekspos ke luar untuk diakses dari servis remote.
-Untuk instalasi klaster pada umumnya, apiserver diatur untuk listen ke koneksi remote melalui port HTTPS (443) yang aman, dengan satu atau beberapa metode [autentikasi](/docs/reference/access-authn-authz/authentication/) client yang telah terpasang.
+Kubernetes memiliki sebuah pola API "hub-and-spoke". Semua penggunaan API dari Node (atau Pod dimana Pod-Pod tersebut dijalankan) akan diterminasi pada apiserver (tidak ada satu komponen _control plane_ apa pun yang didesain untuk diekspos pada servis _remote_).
+Apiserver dikonfigurasi untuk mendengarkan koneksi aman _remote_ yang pada umumnya terdapat pada porta HTTPS (443) dengan satu atau lebih bentuk [autentikasi](/docs/reference/access-authn-authz/authentication/) klien yang dipasang.
Sebaiknya, satu atau beberapa metode [otorisasi](/docs/reference/access-authn-authz/authorization/) juga dipasang, terutama jika kamu memperbolehkan [permintaan anonim (anonymous request)](/docs/reference/access-authn-authz/authentication/#anonymous-requests) ataupun [service account token](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
-Node-node seharusnya disediakan dengan public root certificate untuk klaster, sehingga node-node tersebut bisa terhubung secara aman ke apiserver dengan kredensial client yang valid.
-Contohnya, untuk instalasi GKE dengan standar konfigurasi, kredensial client harus diberikan kepada kubelet dalam bentuk client certificate.
-Lihat [menghidupkan TLS kubelet](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) untuk menyediakan client certificate untuk kubelet secara otomatis.
+Jika diperlukan, Pod-Pod dapat terhubung pada apiserver secara aman dengan menggunakan ServiceAccount.
+Dengan ini, Kubernetes memasukkan _public root certificate_ dan _bearer token_ yang valid ke dalam Pod, secara otomatis saat Pod mulai dijalankan.
+Kubernetes Service (di dalam semua Namespace) diatur dengan sebuah alamat IP virtual. Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju _endpoint_ HTTPS dari apiserver.
-Jika diperlukan, pod-pod dapat terhubung pada apiserver secara aman dengan menggunakan service account.
-Dengan ini, Kubernetes memasukkan public root certificate dan bearer token yang valid ke dalam pod, secara otomatis saat pod mulai dijalankan.
-Kubernetes service (di dalam semua namespace) diatur dengan sebuah alamat IP virtual.
-Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju endpoint HTTPS dari apiserver.
+Komponen-komponen juga melakukan koneksi pada apiserver klaster melalui porta yang aman.
-Komponen-komponen master juga berkomunikasi dengan apiserver melalui port yang aman di dalam klaster.
-Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari klaster (node-node dan pod-pod yang berjalan di atas node tersebut) menuju master sudah terhubung dengan aman.
-Dan juga, klaster dan master bisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (untrusted).
+Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari klaster (node-node dan pod-pod yang berjalan di atas node tersebut) menujucontrol planesudah terhubung dengan aman.
+Dan juga, klaster dancontrol planebisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (untrusted).
-## Master menuju Klaster
+## Control Plane menuju Node
-Ada dua jalur komunikasi utama dari master (apiserver) menuju klaster.
-Pertama, dari apiserver ke process kubelet yang berjalan pada setiap node di dalam klaster.
-Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi proxy pada apiserver.
+Ada dua jalur komunikasi utama dari _control plane_ (apiserver) menuju klaster. Pertama, dari apiserver ke proses kubelet yang berjalan pada setiap Node di dalam klaster. Kedua, dari apiserver ke setiap Node, Pod, ataupun Service melalui fungsi proksi pada apiserver
### Apiserver menuju kubelet
@@ -67,11 +60,9 @@ Koneksi ini **tidak aman** untuk dilalui pada jaringan publik dan/atau tak terpe
### Tunnel SSH
-Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi Master -> Klaster.
+Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi control plane -> Klaster.
Dengan ini, apiserver menginisiasi sebuah tunnel SSH untuk setiap node di dalam klaster (terhubung ke server SSH di port 22) dan membuat semua trafik menuju kubelet, node, pod, atau service dilewatkan melalui tunnel tesebut.
Tunnel ini memastikan trafik tidak terekspos keluar jaringan dimana node-node berada.
Tunnel SSH saat ini sudah usang (deprecated), jadi sebaiknya jangan digunakan, kecuali kamu tahu pasti apa yang kamu lakukan.
Sebuah desain baru untuk mengganti kanal komunikasi ini sedang disiapkan.
-
-
diff --git a/content/id/docs/concepts/architecture/controller.md b/content/id/docs/concepts/architecture/controller.md
index a0ff6b9256..6cf90cf9e6 100644
--- a/content/id/docs/concepts/architecture/controller.md
+++ b/content/id/docs/concepts/architecture/controller.md
@@ -33,7 +33,7 @@ klaster saat ini mendekati keadaan yang diinginkan.
Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari
Kubernetes.
-[objek-objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
+[objek-objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau
lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat
keadaan sekarang mendekati keadaan yang diinginkan.
@@ -174,6 +174,6 @@ khusus itu lakukan.
* Silahkan baca tentang [_control plane_ Kubernetes](/docs/concepts/#kubernetes-control-plane)
* Temukan beberapa dasar tentang [objek-objek Kubernetes](/docs/concepts/#kubernetes-objects)
-* Pelajari lebih lanjut tentang [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
-* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes.
+* Pelajari lebih lanjut tentang [Kubernetes API](/id/docs/concepts/overview/kubernetes-api/)
+* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/id/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes.
diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md
index 8913c9df65..ab13cf122a 100644
--- a/content/id/docs/concepts/architecture/nodes.md
+++ b/content/id/docs/concepts/architecture/nodes.md
@@ -8,8 +8,8 @@ weight: 10
Node merupakan sebuah mesin worker di dalam Kubernetes, yang sebelumnya dinamakan `minion`.
Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya.
-Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
-Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
+Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/id/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
+Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/id/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
Untuk lebih detail, lihat dokumentasi desain arsitektur pada [Node Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node).
@@ -67,12 +67,12 @@ Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berk
Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali.
Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati schedule untuk dihilangkan.
-Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
+Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam klaster.
Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster mungkin perlu untuk menghilangkan node secara manual.
Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali.
-Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions.
+Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/id/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions.
Akibatnya, scheduler menghiraukan conditions ketika mempertimbangkan sebuah Node; scheduler akan melihat pada taints sebuah Node dan tolerations sebuah Pod.
Sekarang, para pengguna dapat memilih antara model scheduling yang lama dan model scheduling yang lebih fleksibel.
@@ -93,7 +93,7 @@ Informasi ini dikumpulkan oleh Kubelet di dalam node.
## Manajemen
-Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya.
+Tidak seperti [pod](/id/docs/concepts/workloads/pods/pod/) dan [service](/id/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya.
Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat.
Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak.
Contohnya, jika kamu mencoba untuk membuat node dari konten berikut:
@@ -164,7 +164,7 @@ Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan m
Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints `NoExecute`, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints.
Sebagai tambahan, hal ini di-nonaktifkan secara default pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan taints yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`.
-Lihat [dokumentasi ini](/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha.
+Lihat [dokumentasi ini](/id/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha.
Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan taints yang merepresentasikan node condition.
Ini merupakan fitur alpha untuk versi 1.8.
@@ -218,7 +218,7 @@ Jika kamu melakukan [administrasi node manual](#manual-node-administration), mak
Scheduler Kubernetes memastikan kalau ada resource yang cukup untuk menjalankan semua pod di dalam sebuah node.
Kubernetes memeriksa jumlah semua request untuk kontainer pada sebuah node tidak lebih besar daripada kapasitas node.
-Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer.
+Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/id/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer.
Kalau kamu ingin secara eksplisit menyimpan resource cadangan untuk menjalankan process-process selain Pod, ikut tutorial [menyimpan resource cadangan untuk system daemon](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md
index b404465d8f..ca50347492 100644
--- a/content/id/docs/concepts/cluster-administration/addons.md
+++ b/content/id/docs/concepts/cluster-administration/addons.md
@@ -32,7 +32,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk
* [Multus](https://github.com/Intel-Corp/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan *policy-based* jaringan antara Kubernetes Pods dan non-Kubernetes *environment* dengan *monitoring* visibilitas dan keamanan.
-* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
+* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/id/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta *policy* jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal.
## _Service Discovery_
diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md
index a605a78547..ee1f91cbeb 100644
--- a/content/id/docs/concepts/cluster-administration/certificates.md
+++ b/content/id/docs/concepts/cluster-administration/certificates.md
@@ -245,6 +245,6 @@ done.
Kamu dapat menggunakan API `Certificate.k8s.io` untuk menyediakan
sertifikat x509 yang digunakan untuk autentikasi seperti yang didokumentasikan
-[di sini](/docs/tasks/tls/managing-tls-in-a-cluster).
+[di sini](/id/docs/tasks/tls/managing-tls-in-a-cluster).
diff --git a/content/id/docs/concepts/cluster-administration/cloud-providers.md b/content/id/docs/concepts/cluster-administration/cloud-providers.md
index 45820e3660..9a32af1eb8 100644
--- a/content/id/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/id/docs/concepts/cluster-administration/cloud-providers.md
@@ -56,7 +56,7 @@ Bagian ini akan menjelaskan semua konfigurasi yang dapat diatur saat menjalankan
Penyedia layanan cloud AWS menggunakan nama DNS privat dari *instance* AWS sebagai nama dari objek Kubernetes Node.
### *Load Balancer*
-Kamu dapat mengatur [load balancers eksternal](/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini.
+Kamu dapat mengatur [load balancers eksternal](/id/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini.
```yaml
apiVersion: v1
diff --git a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
index b485b5e142..b2bd349908 100644
--- a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
+++ b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md
@@ -20,10 +20,10 @@ Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tent
Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan:
- Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu.
- - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/docs/concepts/cluster-administration/federation/).
+ - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/id/docs/concepts/cluster-administration/federation/).
- Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klastermu**?
- Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster.
- - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/docs/concepts/cluster-administration/networking/) yang paling sesuai.
+ - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/id/docs/concepts/cluster-administration/networking/) yang paling sesuai.
- Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**?
- Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan.
- Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster.
@@ -36,13 +36,13 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
* Pelajari bagaimana cara [mengatur *node*](/docs/concepts/nodes/node/).
-* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
+* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/id/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
## Mengamankan Klaster
-* [Sertifikat (*certificate*)](/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
+* [Sertifikat (*certificate*)](/id/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
-* [Kubernetes *Container Environment*](/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*.
+* [Kubernetes *Container Environment*](/id/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*.
* [Mengontrol Akses ke Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) akan menjabarkan bagaimana cara mengatur izin (*permission*) untuk akun pengguna dan *service account*.
@@ -63,9 +63,9 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
## Layanan Tambahan Klaster
-* [Integrasi DNS](/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
+* [Integrasi DNS](/id/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
-* [*Logging* dan *Monitoring* Aktivitas Klaster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
+* [*Logging* dan *Monitoring* Aktivitas Klaster](/id/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md
index 7690a75a82..d59da126ad 100644
--- a/content/id/docs/concepts/cluster-administration/federation.md
+++ b/content/id/docs/concepts/cluster-administration/federation.md
@@ -106,7 +106,7 @@ Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara
* [Namespaces](/docs/tasks/administer-federation/namespaces/)
* [ReplicaSets](/docs/tasks/administer-federation/replicaset/)
* [Secrets](/docs/tasks/administer-federation/secret/)
-* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
+* [Services](/id/docs/concepts/cluster-administration/federation-service-discovery/)
[Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar
diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md
index 53203777f2..75f3b97189 100644
--- a/content/id/docs/concepts/cluster-administration/logging.md
+++ b/content/id/docs/concepts/cluster-administration/logging.md
@@ -173,7 +173,7 @@ Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat pengguna
{{< /note >}}
Sebagai contoh, kamu dapat menggunakan [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
-yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
+yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md
index 81c0ba4d08..d67da9c13e 100644
--- a/content/id/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md
@@ -6,7 +6,7 @@ weight: 40
-Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/docs/concepts/configuration/overview/) dan [label](/docs/concepts/overview/working-with-objects/labels/).
+Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/id/docs/concepts/configuration/overview/) dan [label](/id/docs/concepts/overview/working-with-objects/labels/).
@@ -290,7 +290,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
Akan muncul semua _pod_ dengan "app=nginx" dan sebuah kolom label tambahan yaitu tier (ditentukan dengan `-L` atau `--label-columns`).
-Untuk informasi lebih lanjut, silahkan baca [label](/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
+Untuk informasi lebih lanjut, silahkan baca [label](/id/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
## Memperbarui anotasi
@@ -309,7 +309,7 @@ metadata:
...
```
-Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate).
+Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/id/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate).
## Memperbesar dan memperkecil aplikasi kamu
@@ -432,7 +432,7 @@ Untuk memperbarui versi ke 1.9.1, ganti `.spec.template.spec.containers[0].image
kubectl edit deployment/my-nginx
```
-Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/docs/concepts/workloads/controllers/deployment/).
+Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/id/docs/concepts/workloads/controllers/deployment/).
@@ -440,6 +440,6 @@ Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berang
- [Pelajari tentang bagaimana memakai `kubectl` untuk memeriksa dan _debug_ aplikasi.](/docs/tasks/debug-application-cluster/debug-application-introspection/)
-- [Praktik Terbaik dan Tips Konfigurasi](/docs/concepts/configuration/overview/)
+- [Praktik Terbaik dan Tips Konfigurasi](/id/docs/concepts/configuration/overview/)
diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md
index 038465bcb8..6bcd78d7ef 100644
--- a/content/id/docs/concepts/cluster-administration/networking.md
+++ b/content/id/docs/concepts/cluster-administration/networking.md
@@ -10,10 +10,10 @@ untuk memahami persis bagaimana mengharapkannya bisa bekerja.
Ada 4 masalah yang berbeda untuk diatasi:
1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh
- [Pod](/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
+ [Pod](/id/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`.
2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini.
-3. Komunikasi Pod dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
-4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/).
+3. Komunikasi Pod dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/).
+4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/).
@@ -213,7 +213,7 @@ Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solus
### Romana
-[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
+[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/id/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan.
### Weave Net dari Weaveworks
diff --git a/content/id/docs/concepts/cluster-administration/proxies.md b/content/id/docs/concepts/cluster-administration/proxies.md
index 5595414aa9..f3567233e0 100644
--- a/content/id/docs/concepts/cluster-administration/proxies.md
+++ b/content/id/docs/concepts/cluster-administration/proxies.md
@@ -14,7 +14,7 @@ Laman ini menjelaskan berbagai proxy yang ada di dalam Kubernetes.
Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes:
-1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
+1. [kubectl proxy](/id/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
- dijalankan pada desktop pengguna atau di dalam sebuah Pod
- melakukan proxy dari alamat localhost ke apiserver Kubernetes
@@ -23,7 +23,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes
- mencari lokasi apiserver
- menambahkan header autentikasi
-1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
+1. [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
- merupakan sebuah bastion yang ada di dalam apiserver
- menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau
@@ -33,7 +33,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes
- dapat digunakan untuk menghubungi Node, Pod, atau Service
- melakukan load balancing saat digunakan untuk menjangkau sebuah Service
-1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1. [kube proxy](/id/docs/concepts/services-networking/service/#ips-and-vips):
- dijalankan pada setiap Node
- melakukan proxy untuk UDP, TCP dan SCTP
diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md
index 8af1abba28..ee9e8bf2f4 100644
--- a/content/id/docs/concepts/configuration/assign-pod-node.md
+++ b/content/id/docs/concepts/configuration/assign-pod-node.md
@@ -7,7 +7,7 @@ weight: 30
-Kamu dapat memaksa sebuah [pod](/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
+Kamu dapat memaksa sebuah [pod](/id/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/id/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/id/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama.
Kamu dapat menemukan semua berkas untuk contoh-contoh berikut pada [dokumentasi yang kami sediakan di sini](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/)
@@ -114,7 +114,7 @@ Berikut ini contoh dari pod yang menggunakan afinitas node:
Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan.
-Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
+Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/id/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat.
@@ -284,7 +284,7 @@ Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#toler
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
-Kamu juga dapat mengecek [Taints](/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
+Kamu juga dapat mengecek [Taints](/id/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod.
## nodeName
diff --git a/content/id/docs/concepts/configuration/manage-compute-resources-container.md b/content/id/docs/concepts/configuration/manage-compute-resources-container.md
index 3450bab459..600a4cc6cd 100644
--- a/content/id/docs/concepts/configuration/manage-compute-resources-container.md
+++ b/content/id/docs/concepts/configuration/manage-compute-resources-container.md
@@ -10,7 +10,7 @@ feature:
-Saat kamu membuat spesifikasi sebuah [Pod](/docs/concepts/workloads/pods/pod/), kamu
+Saat kamu membuat spesifikasi sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), kamu
dapat secara opsional menentukan seberapa banyak CPU dan memori (RAM) yang dibutuhkan
oleh setiap Container. Saat Container-Container menentukan _request_ (permintaan) sumber daya,
scheduler dapat membuat keputusan yang lebih baik mengenai Node mana yang akan dipilih
@@ -42,8 +42,8 @@ Hal ini berbeda dari sumber daya `memory` dan `cpu` (yang dapat di-_overcommit_)
CPU dan memori secara kolektif disebut sebagai _sumber daya komputasi_, atau cukup
_sumber daya_ saja. Sumber daya komputasi adalah jumlah yang dapat diminta, dialokasikan,
-dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/docs/concepts/overview/kubernetes-api/).
-Sumber daya API, seperti Pod dan [Service](/docs/concepts/services-networking/service/) adalah
+dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/id/docs/concepts/overview/kubernetes-api/).
+Sumber daya API, seperti Pod dan [Service](/id/docs/concepts/services-networking/service/) adalah
objek-objek yang dapat dibaca dan diubah melalui Kubernetes API Server.
## Request dan Limit Sumber daya dari Pod dan Container
@@ -270,7 +270,7 @@ _daemon_ sistem menggunakan sebagian dari sumber daya yang ada. Kolom `allocatab
memberikan jumlah sumber daya yang tersedia untuk Pod-Pod. Untuk lebih lanjut, lihat
[Sumber daya Node yang dapat dialokasikan](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
-Fitur [kuota sumber daya](/docs/concepts/policy/resource-quotas/) dapat disetel untuk
+Fitur [kuota sumber daya](/id/docs/concepts/policy/resource-quotas/) dapat disetel untuk
membatasi jumlah sumber daya yang dapat digunakan. Jika dipakai bersama dengan Namespace,
kuota sumber daya dapat mencegah suatu tim menghabiskan semua sumber daya.
@@ -489,7 +489,7 @@ Sumber daya yang diperluas pada tingkat Node terikat pada Node.
##### Sumber daya Device Plugin yang dikelola
Lihat [Device
-Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk
+Plugin](/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk
cara menyatakan sumber daya _device plugin_ yang dikelola pada setiap node.
##### Sumber daya lainnya
diff --git a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
index 929c895821..caba991a8d 100644
--- a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+++ b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -24,7 +24,7 @@ tanda [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/).
Instruksi langkah demi langkah untuk membuat dan menentukan berkas kubeconfig,
bisa mengacu pada [Mengatur Akses Pada Beberapa Klaster]
-(/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
+(/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
@@ -103,7 +103,7 @@ kubeconfig:
abaikan mereka.
Beberapa contoh pengaturan variabel _environment_ `KUBECONFIG`, bisa melihat pada
- [pengaturan vaiabel _environment_ KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
+ [pengaturan vaiabel _environment_ KUBECONFIG](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
Sebaliknya, bisa menggunakan berkas kubeconfig _default_, `$HOME/.kube/config`,
tanpa melakukan penggabungan.
@@ -158,7 +158,7 @@ _absolute path_ akan disimpan secara mutlak.
## {{% heading "whatsnext" %}}
-* [Mengatur Akses Pada Beberapa Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [Mengatur Akses Pada Beberapa Klaster](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/id/docs/concepts/configuration/overview.md b/content/id/docs/concepts/configuration/overview.md
index 76d68658ec..67fb2061fe 100644
--- a/content/id/docs/concepts/configuration/overview.md
+++ b/content/id/docs/concepts/configuration/overview.md
@@ -32,14 +32,14 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
## "Naked" Pods vs ReplicaSets, Deployments, and Jobs
-- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
+- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/id/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
- Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai.
+ Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/id/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai.
## Services
-- Buat [Service](/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya:
+- Buat [Service](/id/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya:
```shell
FOO_SERVICE_HOST=
@@ -48,26 +48,26 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
*Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
-- Opsional (meskipun sangat disarankan) [cluster add-on](/docs/concepts/cluster-administration/addons/) adalah server DNS.
+- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS.
Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis.
- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`.
- Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
+ Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
- Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
+ Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`.
-- Gunakan [headless Services](/docs/concepts/services-networking/service/#headless-
+- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless-
services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
## Menggunakan label
-- Deklarasi dan gunakan [labels] (/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
+- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
-Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
+Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan terhadap spesifikasi tersebut adalah _applied_, Deployment controller mengubah keadaan aktual ke keadaan yang diinginkan pada tingkat yang terkontrol.
@@ -75,7 +75,7 @@ Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan
## Container Images
-Ini [imagePullPolicy](/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan
+Ini [imagePullPolicy](/id/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan
- `imagePullPolicy: IfNotPresent`: image ditarik hanya jika belum ada secara lokal.
@@ -105,7 +105,7 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul
- Gunakan `kubectl apply -f `. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` `dan meneruskannya ke` apply`.
-- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
- Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
diff --git a/content/id/docs/concepts/configuration/pod-overhead.md b/content/id/docs/concepts/configuration/pod-overhead.md
index e59301bb96..13db4e32f8 100644
--- a/content/id/docs/concepts/configuration/pod-overhead.md
+++ b/content/id/docs/concepts/configuration/pod-overhead.md
@@ -22,7 +22,7 @@ _Pod Overhead_ adalah fitur yang berfungsi untuk menghitung sumber daya digunaka
Pada Kubernetes, Overhead Pod ditentukan pada
[saat admisi](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) sesuai dengan Overhead yang ditentukan di dalam
-[RuntimeClass](/docs/concepts/containers/runtime-class/) milik Pod.
+[RuntimeClass](/id/docs/concepts/containers/runtime-class/) milik Pod.
Ketika Overhead Pod diaktifkan, Overhead akan dipertimbangkan sebagai tambahan terhadap jumlah permintaan sumber daya Container
saat menjadwalkan Pod. Begitu pula Kubelet, yang akan memasukkan Overhead Pod saat menentukan ukuran
@@ -49,7 +49,7 @@ Lihat [Ringkasan Otorisasi](/docs/reference/access-authn-authz/authorization/) u
## {{% heading "whatsnext" %}}
-* [RuntimeClass](/docs/concepts/containers/runtime-class/)
+* [RuntimeClass](/id/docs/concepts/containers/runtime-class/)
* [Desain PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
diff --git a/content/id/docs/concepts/configuration/pod-priority-preemption.md b/content/id/docs/concepts/configuration/pod-priority-preemption.md
index a0c6035482..7350470fa3 100644
--- a/content/id/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/id/docs/concepts/configuration/pod-priority-preemption.md
@@ -24,7 +24,7 @@ Versi Kubernetes | Keadaan Priority and Pemindahan | Dihidupkan secara Bawaan
1.11 | beta | ya
1.14 | stable | ya
-{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12.
+{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/id/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12.
{{< /warning >}}
@@ -178,11 +178,11 @@ Harap catat bahwa Pod P tidak harus dijadwalkan pada "_nominated_ Node" (Node ya
#### Penghentian secara sopan dari korban-korban pemindahan Pod
-Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil.
+Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/id/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil.
#### PodDisruptionBudget didukung, tapi tidak dijamin!
-Sebuah [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar.
+Sebuah [Pod Disruption Budget (PDB)](/id/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar.
#### Afinitas antar-Pod pada Pod-pod dengan prioritas lebih rendah
diff --git a/content/id/docs/concepts/configuration/secret.md b/content/id/docs/concepts/configuration/secret.md
index a6ca8dca88..40875648ff 100644
--- a/content/id/docs/concepts/configuration/secret.md
+++ b/content/id/docs/concepts/configuration/secret.md
@@ -49,7 +49,7 @@ Mekanisme otomatisasi pembuatan secret dan penggunaan kredensial API dapat di no
atau di-_override_ jika kamu menginginkannya. Meskipun begitu, jika apa yang kamu butuhkan
hanyalah mengakses apiserver secara aman, maka mekanisme _default_ inilah yang disarankan.
-Baca lebih lanjut dokumentasi [_Service Account_](/docs/tasks/configure-pod-container/configure-service-account/)
+Baca lebih lanjut dokumentasi [_Service Account_](/id/docs/tasks/configure-pod-container/configure-service-account/)
untuk informasi lebih lanjut mengenai bagaimana cara kerja _Service Account_.
### Membuat Objek Secret Kamu Sendiri
@@ -569,7 +569,7 @@ _delay_ propagasi _cache_, dimana _delay_ propagasi _cache_ bergantung pada jeni
{{< note >}}
Sebuah container menggunakan Secret sebagai
-[subPath](/docs/concepts/storage/volumes#using-subpath) dari _volume_
+[subPath](/id/docs/concepts/storage/volumes#using-subpath) dari _volume_
yang di-_mount_ tidak akan menerima perubahan Secret.
{{< /note >}}
@@ -636,7 +636,7 @@ pada Kubelet, sehingga Kubelet dapat mengunduh _image_ dan menempatkannya pada P
**Memberikan spesifikasi manual dari sebuah imagePullSecret**
-Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
+Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
### Mekanisme yang Dapat Diterapkan agar imagePullSecrets dapat Secara Otomatis Digunakan
@@ -644,7 +644,7 @@ Kamu dapat secara manual membuat sebuah imagePullSecret, serta merujuk imagePull
yang sudah kamu buat dari sebuah serviceAccount. Semua Pod yang dibuat dengan menggunakan
serviceAccount tadi atau serviceAccount _default_ akan menerima _field_ imagePullSecret dari
serviceAccount yang digunakan.
-Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
+Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
untuk informasi lebih detail soal proses yang dijalankan.
### Mekanisme _Mounting_ Otomatis dari Secret yang Sudah Dibuat
@@ -985,7 +985,7 @@ hanya boleh dimiliki oleh komponen pada sistem level yang paling _previleged_.
Aplikasi yang membutuhkan akses ke API secret harus melakukan _request_ `get` pada
secret yang dibutuhkan. Hal ini memungkinkan administrator untuk membatasi
-akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/docs/reference/access-authn-authz/rbac/#referring-to-resources)
+akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/id/docs/reference/access-authn-authz/rbac/#referring-to-resources)
yang dibutuhkan aplikasi.
Untuk meningkatkan performa dengan menggunakan iterasi `get`, klien dapat mendesain
diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/configuration/taint-and-toleration.md
index 9a30b48f5b..723bbd1c9c 100644
--- a/content/id/docs/concepts/configuration/taint-and-toleration.md
+++ b/content/id/docs/concepts/configuration/taint-and-toleration.md
@@ -6,7 +6,7 @@ weight: 40
-Afinitas Node, seperti yang dideskripsikan [di sini](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
+Afinitas Node, seperti yang dideskripsikan [di sini](/id/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi
untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau
_hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas --
@@ -193,7 +193,7 @@ khusus (misalnya, `kubectl taint nodes nodename special=true:NoSchedule` atau
yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada
kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis
[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang
-bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus
dengan nama _extended resource_ dan jalankan _admission controller_
[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration).
@@ -244,7 +244,7 @@ dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ terten
dari _Ready_ yang ada pada _NodeCondition_ dinonaktifkan.
{{< note >}}
-Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang
+Untuk menjaga perilaku [_rate limiting_](/id/docs/concepts/architecture/nodes/) yang
ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan
_taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_
pada skenario dimana master menjadi terpisah dari _node_ lainnya.
@@ -280,7 +280,7 @@ _node_ apabila salah satu masalah terdeteksi.
Kedua _toleration_ _default_ tadi ditambahkan oleh [DefaultTolerationSeconds
_admission controller_](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
-_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
+_Pod-pod_ pada [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
`NoExecute` untuk _taint_ tanpa `tolerationSeconds`:
* `node.kubernetes.io/unreachable`
diff --git a/content/id/docs/concepts/containers/container-environment.md b/content/id/docs/concepts/containers/container-environment.md
index affb371001..6c0ba354e8 100644
--- a/content/id/docs/concepts/containers/container-environment.md
+++ b/content/id/docs/concepts/containers/container-environment.md
@@ -17,7 +17,7 @@ Laman ini menjelaskan berbagai *resource* yang tersedia di dalam Kontainer pada
*Environment* Kontainer pada Kubernetes menyediakan beberapa *resource* penting yang tersedia di dalam Kontainer:
-* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/docs/concepts/storage/volumes/).
+* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/id/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/id/docs/concepts/storage/volumes/).
* Informasi tentang Kontainer tersebut.
* Informasi tentang objek-objek lain di dalam klaster.
@@ -53,7 +53,7 @@ jika [*addon* DNS](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/a
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/docs/concepts/containers/container-lifecycle-hooks/).
+* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/).
* Dapatkan pengalaman praktis soal
[memberikan *handler* untuk *event* dari *lifecycle* Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
diff --git a/content/id/docs/concepts/containers/container-lifecycle-hooks.md b/content/id/docs/concepts/containers/container-lifecycle-hooks.md
index a7b5164864..d45a5ad23e 100644
--- a/content/id/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/id/docs/concepts/containers/container-lifecycle-hooks.md
@@ -40,7 +40,7 @@ Hal ini bersifat *blocking*, yang artinya panggilan bersifat sinkron (*synchrono
untuk menghapus kontainer tersebut.
Tidak ada parameter yang diberikan pada *handler*.
-Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods).
+Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods).
### Implementasi *handler* untuk *hook*
@@ -113,7 +113,7 @@ Events:
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut tentang [*environment* Kontainer](/docs/concepts/containers/container-environment-variables/).
+* Pelajari lebih lanjut tentang [*environment* Kontainer](/id/docs/concepts/containers/container-environment-variables/).
* Pelajari bagaimana caranya
[melakukan *attach handler* pada *event lifecycle* sebuah Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
diff --git a/content/id/docs/concepts/containers/images.md b/content/id/docs/concepts/containers/images.md
index 7a5fa28154..8fa81801ff 100644
--- a/content/id/docs/concepts/containers/images.md
+++ b/content/id/docs/concepts/containers/images.md
@@ -26,7 +26,7 @@ selalu diunduh, kamu bisa melakukan salah satu dari berikut:
- buang `imagePullPolicy` dan juga _tag_ untuk _image_.
- aktifkan [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) _admission controller_.
-Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut.
+Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/id/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut.
## Membuat Image Multi-arsitektur dengan Manifest
@@ -142,7 +142,7 @@ Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk lo
* `DOCKER_EMAIL`: `${some-email-address}`
Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat
-[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
+[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
### Menggunakan IBM Cloud Container Registry
IBM Cloud Container Registry menyediakan sebuah registri _image_ privat yang _multi-tenant_, dapat kamu gunakan untuk menyimpan dan membagikan _image-image_ secara aman. Secara _default_, _image-image_ di dalam registri privat kamu akan dipindai (_scan_) oleh Vulnerability Advisor terintegrasi untuk deteksi isu
@@ -291,7 +291,7 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER
Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas,
kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret.
-[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini.
+[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/id/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini.
Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat,
perintah `kubectl create secret docker-registry` akan membuat sebuah Secret yang akan
hanya bekerja menggunakan satu registri privat.
@@ -331,7 +331,7 @@ Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri pr
Hanya saja, mengatur _field_ ini dapat diotomasi dengan mengatur imagePullSecrets di dalam
sumber daya [serviceAccount](/docs/user-guide/service-accounts).
-Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail.
+Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail.
Kamu dapat menggunakan cara ini bersama `.docker/config.json` pada setiap Node. Kredensial-kredensial
akan dapat di-_merged_. Cara ini akan dapat bekerja pada Google Kubernetes Engine.
diff --git a/content/id/docs/concepts/containers/overview.md b/content/id/docs/concepts/containers/overview.md
index d31c760ee0..715230d14d 100644
--- a/content/id/docs/concepts/containers/overview.md
+++ b/content/id/docs/concepts/containers/overview.md
@@ -21,7 +21,7 @@ ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda.
## Image-Image Kontainer
-[Kontainer image](/docs/concepts/containers/images/) meruapakan paket perangkat lunak
+[Kontainer image](/id/docs/concepts/containers/images/) meruapakan paket perangkat lunak
yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan
sebuah aplikasi: kode dan setiap *runtime* yang dibutuhkan, *library* dari
aplikasi dan sistem, dan nilai *default* untuk penganturan yang penting.
diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md
index 31bd8a25ec..73252a03e4 100644
--- a/content/id/docs/concepts/containers/runtime-class.md
+++ b/content/id/docs/concepts/containers/runtime-class.md
@@ -45,7 +45,7 @@ soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki.
Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya
konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari
yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass
-melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/docs/concepts/configuration/assign-pod-node/)).
+melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/id/docs/concepts/configuration/assign-pod-node/)).
{{< /note >}}
Seluruh konfigurasi memiliki nama `handler` yang terkait, dijadikan referensi oleh RuntimeClass.
@@ -91,7 +91,7 @@ spec:
Kubelet akan mendapat instruksi untuk menggunakan RuntimeClass dengan nama yang sudah ditentukan tersebut
untuk menjalankan Pod ini. Jika RuntimeClass dengan nama tersebut tidak ditemukan, atau CRI tidak dapat
-menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`.
+menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`.
Lihat [_event_](/docs/tasks/debug-application-cluster/debug-application-introspection/) untuk mengetahui pesan error yang terkait.
Jika tidak ada `runtimeClassName` yang ditentukan di dalam Pod, maka RuntimeHandler yang _default_ akan digunakan.
diff --git a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index d8be642856..3a3ece65b0 100644
--- a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -14,7 +14,7 @@ _Custom Resource_ adalah ekstensi dari Kubernetes API. Laman ini mendiskusikan k
## _Custom Resource_
-Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.
+Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.
Sebuah _Custom Resource_ adalah sebuah ekstensi dari Kubernetes API yang tidak seharusnya tersedia pada pemasangan default Kubernetes. Namun, banyak fungsi-fungsi inti Kubernetes yang sekarang dibangun menggunakan _Custom Resource_, membuat Kubernetes lebih modular.
@@ -25,7 +25,7 @@ dipasang, pengguna dapat membuat dan mengakses objek-objek _Custom Resource_ men
Dengan sendirinya, _Custom Resource_ memungkinkan kamu untuk menyimpan dan mengambil data terstruktur. Ketika kamu menggabungkan sebuah _Custom Resource_ dengan _controller_ khusus, _Custom Resource_ akan memberikan sebuah API deklaratif yang sebenarnya.
-Sebuah [API deklaratif](/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes)
+Sebuah [API deklaratif](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes)
memungkinkan kamu untuk mendeklarasikan atau menspesifikasikan keadaan dari sumber daya kamu dan mencoba untuk menjaga agar keadaan saat itu tersinkronisasi dengan keadaan yang diinginkan. *Controller* menginterpretasikan data terstruktur sebagai sebuah rekaman dari keadaan yang diinginkan pengguna, dan secara kontinu menjaga keadaan ini.
Kamu bisa men-_deploy_ dan memperbaharui sebuah _controller_ khusus pada sebuah klaster yang berjalan, secara independen dari siklus hidup klaster itu sendiri. _Controller_ khusus dapat berfungsi dengan sumber daya jenis apapun, tetapi mereka sangat efektif ketika dikombinasikan dengan _Custom Resource_. [_Operator pattern_](https://coreos.com/blog/introducing-operators.html) mengkombinasikan _Custom Resource_ dan _controller_ khusus. Kamu bisa menggunakan _controller_ khusus untuk menyandi pengetahuan domain untuk aplikasi spesifik menjadi sebuah ekstensi dari Kubernetes API.
@@ -40,7 +40,7 @@ Ketika membuat sebuah API baru, pikirkan apakah kamu ingin [mengagregasikan API
| Kamu mau tipe baru yang dapat dibaca dan ditulis dengan `kubectl`.| Dukungan `kubectl` tidak diperlukan |
| Kamu mau melihat tipe baru pada sebuah Kubernetes UI, seperti dasbor, bersama dengan tipe-tipe bawaan. | Dukungan Kubernetes UI tidak diperlukan. |
| Kamu mengembangkan sebuah API baru. | Kamu memiliki sebuah program yang melayani API kamu dan dapat berkerja dengan baik. |
-| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. |
+| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/id/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. |
| Sumber daya kamu secara alami mencakup hingga sebuah klaster atau sebuah *namespace* dari sebuah klaster. | Sumber daya yang mencakup klaster atau *namespace* adalah sebuah ketidakcocokan; kamu perlu mengendalikan jalur sumber daya spesifik. |
| Kamu ingin menggunakan kembali [dukungan fitur Kubernetes API](#fitur-umum). | Kamu tidak membutuhkan fitur tersebut. |
@@ -77,7 +77,7 @@ Gunakan ConfigMap jika salah satu hal berikut berlaku:
* Kamu ingin melakukan pembaharuan bergulir lewat Deployment, dll, ketika berkas diperbaharui.
{{< note >}}
-Gunakan sebuah [Secret](/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman.
+Gunakan sebuah [Secret](/id/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman.
{{< /note >}}
Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dari hal berikut berlaku:
@@ -93,11 +93,11 @@ Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dar
Kubernetes menyediakan dua cara untuk menambahkan sumber daya ke klaster kamu:
- CRD cukup sederhana dan bisa diciptakan tanpa pemrograman apapun.
-- [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.
+- [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.
Kubernetes menyediakan kedua opsi tersebut untuk memenuhi kebutuhan pengguna berbeda, jadi tidak ada kemudahan penggunaan atau fleksibilitas yang dikompromikan.
-_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.
+_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.
CRD memungkinkan pengguna untuk membuat tipe baru sumber daya tanpa menambahkan APIserver lain. Kamu tidak perlu mengerti Agregasi API untuk menggunakan CRD.
@@ -115,7 +115,7 @@ Lihat [contoh *controller* khusus](https://github.com/kubernetes/sample-controll
Biasanya, tiap sumber daya di API Kubernetes membutuhkan kode yang menangani permintaan REST dan mengatur peyimpanan tetap dari objek-objek. Server Kubernetes API utama menangani sumber daya bawaan seperti Pod dan Service, dan juga menangani _Custom Resource_ dalam sebuah cara yang umum melalui [CRD](#customresourcedefinition).
-[Lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya.
+[Lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya.
## Memilih sebuah metode untuk menambahkan _Custom Resource_
@@ -216,7 +216,7 @@ Ketika kamu menambahkan sebuah _Custom Resource_, kamu dapat mengaksesnya dengan
## {{% heading "whatsnext" %}}
-* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
* Belajar bagaimana untuk [Memperluas Kubernetes API dengan CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 014a40171e..62f7c8d41d 100644
--- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -37,7 +37,7 @@ Dalam pendaftaran, _plugin_ perangkat perlu mengirim:
* Nama Unix socket-nya.
* Versi API Plugin Perangkat yang dipakai.
* `ResourceName` yang ingin ditunjukkan. `ResourceName` ini harus mengikuti
- [skema penamaan sumber daya ekstensi](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
+ [skema penamaan sumber daya ekstensi](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
sebagai `vendor-domain/tipe-sumber-daya`.
(Contohnya, NVIDIA GPU akan dinamai `nvidia.com/gpu`.)
@@ -221,7 +221,7 @@ Berikut beberapa contoh implementasi _plugin_ perangkat:
* [Plugin perangkat RDMA](https://github.com/hustcat/k8s-rdma-device-plugin)
* [Plugin perangkat Solarflare](https://github.com/vikaschoudhary16/sfc-device-plugin)
* [Plugin perangkat SR-IOV Network](https://github.com/intel/sriov-network-device-plugin)
-* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) untuk perangkat Xilinx FPGA
+* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) untuk perangkat Xilinx FPGA
## {{% heading "whatsnext" %}}
diff --git a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
index b7b07b46ff..9d80881724 100644
--- a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -36,7 +36,7 @@ _Flag-flag_ dan _berkas-berkas konfigurasi_ didokumentasikan di bagian Referensi
_Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain.
-*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
+*API kebijakan bawaan*, seperti [ResourceQuota](/id/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/id/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/id/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/id/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
## Perluasan
@@ -107,7 +107,7 @@ Untuk lebih jelasnya tentang Sumber Daya _Custom_, lihat [Panduan Konsep Sumber
### Menggabungkan API Baru dengan Otomasi
-Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.
+Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.
### Mengubah Sumber Daya Bawaan
@@ -173,6 +173,6 @@ Penjadwal juga mendukung [_webhook_](https://github.com/kubernetes/community/blo
* [_Plugin_ Jaringan](/docs/concepts/cluster-administration/network-plugins/)
* [_Plugin_ Perangkat](/docs/concepts/cluster-administration/device-plugins/)
* Pelajari tentang [_Plugin_ kubectl](/docs/tasks/extend-kubectl/kubectl-plugins/)
-* Pelajari tentang [Pola Operator](/docs/concepts/extend-kubernetes/operator/)
+* Pelajari tentang [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/)
diff --git a/content/id/docs/concepts/extend-kubernetes/operator.md b/content/id/docs/concepts/extend-kubernetes/operator.md
index 02df63bb79..315ae35e3d 100644
--- a/content/id/docs/concepts/extend-kubernetes/operator.md
+++ b/content/id/docs/concepts/extend-kubernetes/operator.md
@@ -7,7 +7,7 @@ weight: 30
Operator adalah ekstensi perangkat lunak untuk Kubernetes yang memanfaatkan
-[_custom resource_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+[_custom resource_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
untuk mengelola aplikasi dan komponen-komponennya. Operator mengikuti prinsip
Kubernetes, khususnya dalam hal [_control loop_](/docs/concepts/#kubernetes-control-plane).
@@ -124,11 +124,9 @@ Kamu juga dapat mengimplementasikan Operator (yaitu, _Controller_) dengan
menggunakan bahasa / _runtime_ yang dapat bertindak sebagai
[klien dari API Kubernetes](/docs/reference/using-api/client-libraries/).
+## {{% heading "whatsnext" %}}
-
-{{% capture Selanjutnya %}}
-
-* Memahami lebih lanjut tentang [_custome resources_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* Memahami lebih lanjut tentang [_custome resources_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Temukan "ready-made" _operators_ dalam [OperatorHub.io](https://operatorhub.io/)
untuk memenuhi use case kamu
* Menggunakan perangkat yang ada untuk menulis Operator kamu sendiri, misalnya:
diff --git a/content/id/docs/concepts/extend-kubernetes/service-catalog.md b/content/id/docs/concepts/extend-kubernetes/service-catalog.md
index efea4eda97..cd63a89355 100644
--- a/content/id/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/id/docs/concepts/extend-kubernetes/service-catalog.md
@@ -46,7 +46,7 @@ untuk berkomunikasi dengan makelar servis, bertindak sebagai perantara untuk API
merundingkan penyediaan awal dan mengambil kredensial untuk aplikasi bisa menggunakan servis terkelola tersebut.
Ini terimplementasi sebagai ekstensi API Server dan pengontrol, menggunakan etcd sebagai media penyimpanan.
-Ini juga menggunakan [lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+Ini juga menggunakan [lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
yang tersedia pada Kubernetes versi 1.7+ untuk menampilkan API-nya.
diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md
index 63e7b4b3af..aa2ee52152 100644
--- a/content/id/docs/concepts/overview/components.md
+++ b/content/id/docs/concepts/overview/components.md
@@ -120,7 +120,7 @@ Meskipun tidak semua addons dibutuhkan, semua klaster Kubernetes hendakny
memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen
lainnya.
-[Klaster DNS](/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di
+[Klaster DNS](/id/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di
environment kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes services
Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini
@@ -129,7 +129,7 @@ ke dalam mekanisme pencarian DNS yang dimilikinya.
### Web UI (Dasbor)
-[Dasbor](/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes.
+[Dasbor](/id/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes.
Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting klaster maupun
aplikasi yang ada pada klaster itu sendiri.
@@ -143,7 +143,7 @@ untuk melakukan pencarian data yang dibutuhkan.
### Cluster-level Logging
-[Cluster-level logging](/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada
+[Cluster-level logging](/id/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada
penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan
pencarian.
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
index 9599feaf24..46066769d4 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
@@ -25,8 +25,8 @@ Lihat [Pengelolaan Objek Kubernetes](/docs/concepts/overview/object-management-k
Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik
tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut:
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan
dalam dokumen ini:
@@ -862,8 +862,8 @@ template:
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
index e77cc9ca63..23489efb59 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
@@ -126,8 +126,8 @@ kubectl create --edit -f /tmp/srv.yaml
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/docs/concepts/overview/object-management-kubectl/imperative-config/)
-- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
index 7df68f579d..94f1082e35 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
+++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
@@ -108,8 +108,8 @@ template:
## {{% heading "whatsnext" %}}
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
- [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/id/docs/concepts/overview/working-with-objects/annotations.md b/content/id/docs/concepts/overview/working-with-objects/annotations.md
index 8a822f255d..aaa238add5 100644
--- a/content/id/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/id/docs/concepts/overview/working-with-objects/annotations.md
@@ -80,5 +80,5 @@ Prefiks `kubernetes.io/` dan `k8s.io/` merupakan reservasi dari komponen inti Ku
## {{% heading "whatsnext" %}}
-Pelajari lebih lanjut tentang [Label dan Selektor](/docs/concepts/overview/working-with-objects/labels/).
+Pelajari lebih lanjut tentang [Label dan Selektor](/id/docs/concepts/overview/working-with-objects/labels/).
diff --git a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
index 7cd81495cd..e46916ee3d 100644
--- a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
+++ b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md
@@ -3,14 +3,14 @@ title: Selektor Field
weight: 60
---
-Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan
+Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/id/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan
nilai dari satu atau banyak *field resource*. Di bawah ini merupakan contoh dari beberapa *query* selektor *field*:
* `metadata.name=my-service`
* `metadata.namespace!=default`
* `status.phase=Pending`
-Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai
+Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai
`Running`:
```shell
@@ -50,7 +50,7 @@ kubectl get services --field-selector metadata.namespace!=default
## Selektor berantai
-Seperti halnya [label](/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai
+Seperti halnya [label](/id/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai
(*chained*) dengan *list* yang dipisahkan oleh koma. Perintah `kubectl` di bawah ini memilih semua Pod dengan `status.phase` tidak sama dengan
`Running` dan *field* `spec.restartPolicy` sama dengan `Always`:
diff --git a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 57eef5e9c6..aa702827b9 100644
--- a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -30,7 +30,7 @@ memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu i
dengan kata lain ini merupakan definisi _state_ klaster yang kamu inginkan.
Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu
-harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/).
+harus menggunakan [API Kubernetes](/id/docs/concepts/overview/kubernetes-api/).
Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah
yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki
menggunakan salah satu [_library_ klien](/docs/reference/using-api/client-libraries/) yang disediakan.
@@ -103,7 +103,7 @@ dan format _spec_ untuk _Deployment_ dapat ditemukan
## {{% heading "whatsnext" %}}
-* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/docs/concepts/workloads/pods/pod-overview/).
+* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/id/docs/concepts/workloads/pods/pod-overview/).
diff --git a/content/id/docs/concepts/overview/working-with-objects/names.md b/content/id/docs/concepts/overview/working-with-objects/names.md
index 5527c15b72..0d6528c41d 100644
--- a/content/id/docs/concepts/overview/working-with-objects/names.md
+++ b/content/id/docs/concepts/overview/working-with-objects/names.md
@@ -8,7 +8,7 @@ weight: 20
Seluruh objek di dalam REST API Kubernetes secara jelas ditandai dengan nama dan UID.
-Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/docs/concepts/overview/working-with-objects/annotations/).
+Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/).
Bacalah [dokumentasi desain penanda](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) agar kamu dapat memahami lebih lanjut sintaks yang digunakan untuk Nama dan UID.
diff --git a/content/id/docs/concepts/overview/working-with-objects/namespaces.md b/content/id/docs/concepts/overview/working-with-objects/namespaces.md
index 5eb358a17a..89ffb8ea14 100644
--- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md
@@ -19,7 +19,7 @@ Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster
*Namespace* menyediakan ruang untuk nama objek. Nama dari *resource* atau objek harus berbeda di dalam sebuah *namespace*, tetapi boleh sama jika berbeda *namespace*. *Namespace* tidak bisa dibuat di dalam *namespace* lain dan setiap *resource* atau objek Kubernetes hanya dapat berada di dalam satu *namespace*.
-*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)).
+*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/id/docs/concepts/policy/resource-quotas/)).
Dalam versi Kubernetes yang akan datang, objek di dalam satu *namespace* akan mempunyai *access control policies* yang sama secara *default*.
@@ -74,7 +74,7 @@ kubectl config view | grep namespace:
## Namespace dan DNS
-Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*.
+Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*.
## Tidak semua objek di dalam Namespace
diff --git a/content/id/docs/concepts/policy/limit-range.md b/content/id/docs/concepts/policy/limit-range.md
index 6de9d69dd2..106f4c1a84 100644
--- a/content/id/docs/concepts/policy/limit-range.md
+++ b/content/id/docs/concepts/policy/limit-range.md
@@ -1,6 +1,6 @@
---
title: LimitRange
-content_template: templates/concept
+content_type: concept
weight: 10
---
diff --git a/content/id/docs/concepts/policy/pod-security-policy.md b/content/id/docs/concepts/policy/pod-security-policy.md
index 2dbbd53144..991ebb44aa 100644
--- a/content/id/docs/concepts/policy/pod-security-policy.md
+++ b/content/id/docs/concepts/policy/pod-security-policy.md
@@ -45,13 +45,13 @@ Sejak API dari Pod Security Policy (`policy/v1beta1/podsecuritypolicy`) diaktifk
## Mengizinkan Kebijakan
-Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut.
+Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut.
-Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)).
+Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)).
### Melalui RBAC
-[RBAC](/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.
+[RBAC](/id/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.
Pertama-tama, sebuah `Role` atau `ClusterRole` perlu memberikan akses pada kata kerja `use` terhadap kebijakan-kebijakan yang diinginkan. `rules` yang digunakan untuk memberikan akses tersebut terlihat seperti berikut:
@@ -103,12 +103,12 @@ Jika sebuah `RoleBinding` (bukan `ClusterRoleBinding`) digunakan, maka ia hanya
name: system:authenticated
```
-Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/docs/reference/access-authn-authz/rbac#role-binding-examples).
+Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/id/docs/reference/access-authn-authz/rbac#role-binding-examples).
Untuk contoh lengkap untuk mengotorisasi sebuah PodSecurityPolicy, lihat [di bawah](#contoh).
### Mengatasi Masalah
-- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles).
+- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/id/docs/reference/access-authn-authz/rbac/#controller-roles).
## Urutan Kebijakan
@@ -324,7 +324,7 @@ determines if any container in a pod can enable privileged mode.
### Volume dan _file system_
-**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume.
+**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/id/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume.
**Kumpulan Volume-volume minimal yang direkomendasikan** untuk PodSecurityPolicy baru adalah sebagai berikut:
diff --git a/content/id/docs/concepts/policy/resource-quotas.md b/content/id/docs/concepts/policy/resource-quotas.md
index 47bfa996bb..c001ef4a40 100644
--- a/content/id/docs/concepts/policy/resource-quotas.md
+++ b/content/id/docs/concepts/policy/resource-quotas.md
@@ -81,7 +81,7 @@ Berikut jenis-jenis sumber daya yang didukung:
### Resource Quota untuk sumber daya yang diperluas
Sebagai tambahan untuk sumber daya yang disebutkan di atas, pada rilis 1.10, dukungan kuota untuk
-[sumber daya yang diperluas](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan.
+[sumber daya yang diperluas](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan.
Karena _overcommit_ tidak diperbolehkan untuk sumber daya yang diperluas, tidak masuk akal untuk menentukan
keduanya; `requests` dan `limits` untuk sumber daya yang diperluas yang sama pada sebuah kuota. Jadi, untuk
@@ -98,7 +98,7 @@ Lihat [Melihat dan Menyetel Kuota](#melihat-dan-menyetel-kuota) untuk informasi
## Resource Quota untuk penyimpanan
-Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/docs/concepts/storage/persistent-volumes/) yang dapat
+Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/id/docs/concepts/storage/persistent-volumes/) yang dapat
diminta pada sebuah Namespace.
Sebagai tambahan, kamu dapat membatasi penggunaan sumber daya penyimpanan berdasarkan _storage class_
@@ -107,9 +107,9 @@ sumber daya penyimpanan tersebut.
| Nama Sumber Daya | Deskripsi |
| --------------------- | ----------------------------------------------------------- |
| `requests.storage` | Pada seluruh Persistent Volume Claim, jumlah `requests` penyimpanan tidak dapat melebihi nilai ini. |
-| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
+| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
| `.storageclass.storage.k8s.io/requests.storage` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah permintaan penyimpanan tidak dapat melebihi nilai ini. |
-| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
+| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. |
Sebagai contoh, jika sebuah operator ingin membatasi penyimpanan dengan Storage Class `gold` yang berbeda dengan Storage Class `bronze`, maka operator tersebut dapat menentukan kuota sebagai berikut:
@@ -163,7 +163,7 @@ Berikut jenis-jenis yang telah didukung:
| Nama Sumber Daya | Deskripsi |
| ------------------------------- | ------------------------------------------------- |
| `configmaps` | Jumlah total ConfigMap yang dapat berada pada suatu Namespace. |
-| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. |
+| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. |
| `pods` | Jumlah total Pod yang berada pada kondisi non-terminal yang dapat berada pada suatu Namespace. Sebuah Pod berada kondisi terminal yaitu jika `.status.phase in (Failed, Succeded)` adalah `true`. |
| `replicationcontrollers` | Jumlah total ReplicationController yang dapat berada pada suatu Namespace. |
| `resourcequotas` | Jumlah total [ResourceQuota](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) yang dapat berada pada suatu Namespace. |
@@ -208,7 +208,7 @@ Lingkup `Terminating`, `NotTerminating`, dan `NotBestEffort` membatasi sebuah k
{{< feature-state for_k8s_version="1.12" state="beta" >}}
-Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu.
+Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/id/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu.
Kamu dapat mengontrol konsumsi sumber daya sistem sebuah Pod berdasarkan Priority Pod tersebut, menggunakan
kolom `scopeSelector` pada spesifikasi kuota tersebut.
diff --git a/content/id/docs/concepts/scheduling/kube-scheduler.md b/content/id/docs/concepts/scheduling/kube-scheduler.md
index f4cd477608..6f7efab3d9 100644
--- a/content/id/docs/concepts/scheduling/kube-scheduler.md
+++ b/content/id/docs/concepts/scheduling/kube-scheduler.md
@@ -94,10 +94,10 @@ penilaian oleh penjadwal:
## {{% heading "whatsnext" %}}
-* Baca tentang [penyetelan performa penjadwal](/docs/concepts/scheduling/scheduler-perf-tuning/)
-* Baca tentang [pertimbangan penyebarang topologi pod](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/)
+* Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_
* Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Pelajari tentang [aturan manajemen topologi](/docs/tasks/administer-cluster/topology-manager/)
-* Pelajari tentang [pengeluaran tambahan Pod](/docs/concepts/configuration/pod-overhead/)
+* Pelajari tentang [pengeluaran tambahan Pod](/id/docs/concepts/configuration/pod-overhead/)
diff --git a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
index 0a20d9050a..3689ecf7cb 100644
--- a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
+++ b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md
@@ -8,7 +8,7 @@ weight: 70
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
-[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
+[kube-scheduler](/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab
terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster.
@@ -66,7 +66,7 @@ Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minim
persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi
bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi
cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler
-akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
+akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
[Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail.
diff --git a/content/id/docs/concepts/security/overview.md b/content/id/docs/concepts/security/overview.md
index caff040bc5..bc271e0645 100644
--- a/content/id/docs/concepts/security/overview.md
+++ b/content/id/docs/concepts/security/overview.md
@@ -107,11 +107,11 @@ Kebanyakan dari saran yang disebut di atas dapat diotomasi di dalam _delivery pi
## {{% heading "whatsnext" %}}
-* Pelajari tentang [Network Policy untuk Pod](/docs/concepts/services-networking/network-policies/)
+* Pelajari tentang [Network Policy untuk Pod](/id/docs/concepts/services-networking/network-policies/)
* Pelajari tentang [mengamankan klaster kamu](/docs/tasks/administer-cluster/securing-a-cluster/)
* Pelajari tentang [kontrol akses API](/docs/reference/access-authn-authz/controlling-access/)
-* Pelajari tentang [enkripsi data saat transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
+* Pelajari tentang [enkripsi data saat transit](/id/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
* Pelajari tentang [enkripsi data saat diam](/docs/tasks/administer-cluster/encrypt-data/)
-* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/docs/concepts/configuration/secret/)
+* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/id/docs/concepts/configuration/secret/)
diff --git a/content/id/docs/concepts/services-networking/connect-applications-service.md b/content/id/docs/concepts/services-networking/connect-applications-service.md
index 4bbd0bbf56..806fff3a46 100644
--- a/content/id/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/id/docs/concepts/services-networking/connect-applications-service.md
@@ -47,7 +47,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam klaster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam klaster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya.
-Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
+Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/id/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
## Membuat Service
@@ -107,7 +107,7 @@ NAME ENDPOINTS AGE
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
```
-Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
+Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/id/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
## Mengakses Service
@@ -194,7 +194,7 @@ Hingga sekarang kita hanya mengakses *nginx* server dari dalam klaster. Sebelum
* *Self signed certificates* untuk *https* (kecuali jika kamu sudah mempunyai *identity certificate*)
* Sebuah server *nginx* yang terkonfigurasi untuk menggunakan *certificate* tersebut
-* Sebuah [secret](/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod*
+* Sebuah [secret](/id/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod*
Kamu dapat melihat semua itu di [contoh nginx https](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). Contoh ini mengaharuskan kamu melakukan instalasi *go* dan *make*. Jika kamu tidak ingin melakukan instalasi tersebut, ikuti langkah-langkah manualnya nanti, singkatnya:
@@ -362,6 +362,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
## {{% heading "whatsnext" %}}
-Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
+Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/id/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
diff --git a/content/id/docs/concepts/services-networking/dns-pod-service.md b/content/id/docs/concepts/services-networking/dns-pod-service.md
index 52ec19a420..efdba8d7a1 100644
--- a/content/id/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/id/docs/concepts/services-networking/dns-pod-service.md
@@ -50,7 +50,7 @@ menggunakan penjadwalan Round-Robin dari set yang ada.
### SRV _record_
SRV _record_ dibuat untuk port bernama yang merupakan bagian dari Service normal maupun [Headless
-Services](/docs/concepts/services-networking/service/#headless-services).
+Services](/id/docs/concepts/services-networking/service/#headless-services).
Untuk setiap port bernama, SRV _record_ akan memiliki format
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
Untuk sebuah Service normal, ini akan melakukan resolusi pada nomor port dan
diff --git a/content/id/docs/concepts/services-networking/endpoint-slices.md b/content/id/docs/concepts/services-networking/endpoint-slices.md
index 224e7b4bbd..1782f4273e 100644
--- a/content/id/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/id/docs/concepts/services-networking/endpoint-slices.md
@@ -45,7 +45,7 @@ term_id="selector" >}} dituliskan. EndpointSlice tersebut akan memiliki
referensi-referensi menuju Pod manapun yang cocok dengan selektor pada Service tersebut. EndpointSlice mengelompokkan
_endpoint_ jaringan berdasarkan kombinasi Service dan Port yang unik.
Nama dari sebuah objek EndpointSlice haruslah berupa
-[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
+[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
Sebagai contoh, berikut merupakan sampel sumber daya EndpointSlice untuk sebuah Service Kubernetes
yang bernama `example`.
@@ -180,6 +180,6 @@ bersangkutan.
* [Mengaktifkan EndpointSlice](/docs/tasks/administer-cluster/enabling-endpointslices)
-* Baca [Menghubungkan Aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
+* Baca [Menghubungkan Aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/)
diff --git a/content/id/docs/concepts/services-networking/ingress-controllers.md b/content/id/docs/concepts/services-networking/ingress-controllers.md
index 9491f5dc1c..645f2dbf8d 100644
--- a/content/id/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/id/docs/concepts/services-networking/ingress-controllers.md
@@ -71,7 +71,7 @@ Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang
## {{% heading "whatsnext" %}}
-* Pelajari [Ingress](/docs/concepts/services-networking/ingress/) lebih lanjut.
+* Pelajari [Ingress](/id/docs/concepts/services-networking/ingress/) lebih lanjut.
* [Melakukan konfigurasi Ingress pada Minikube dengan kontroler NGINX](/docs/tasks/access-application-cluster/ingress-minikube)
diff --git a/content/id/docs/concepts/services-networking/ingress.md b/content/id/docs/concepts/services-networking/ingress.md
index 617581b421..1cc56c5960 100644
--- a/content/id/docs/concepts/services-networking/ingress.md
+++ b/content/id/docs/concepts/services-networking/ingress.md
@@ -16,8 +16,8 @@ Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipak
* Node: Sebuah mesin fisik atau virtual yang berada di dalam klaster Kubernetes.
* Klaster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*.
* *Edge router*: Sebuah *router* mengatur *policy firewall* pada klaster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras.
-* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/).
-* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
+* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/id/docs/concepts/cluster-administration/networking/).
+* *Service*: Sebuah [*Service*](/id/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
## Apakah *Ingress* itu?
@@ -34,11 +34,11 @@ Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pa
```
Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar klaster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama.
-Sebuah [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
+Sebuah [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan
-*service* dengan tipe [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) atau
-[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer).
+*service* dengan tipe [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport) atau
+[Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer).
## Prasyarat
@@ -47,7 +47,7 @@ Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Se
Sebelum kamu mulai menggunakan *Ingress*, ada beberapa hal yang perlu kamu ketahui sebelumnya. *Ingress* merupakan *resource* dengan tipe beta.
{{< note >}}
-Kamu harus terlebih dahulu memiliki [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun.
+Kamu harus terlebih dahulu memiliki [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun.
{{< /note >}}
GCE/Google Kubernetes Engine melakukan deploy kontroler *Ingress* pada *master*. Perhatikan laman berikut
@@ -56,7 +56,7 @@ kontroler ini jika kamu menggunakan GCE/GKE.
Jika kamu menggunakan *environment* selain GCE/Google Kubernetes Engine, kemungkinan besar kamu harus
[melakukan proses deploy kontroler ingress kamu sendiri](https://kubernetes.github.io/ingress-nginx/deploy/). Terdapat beberapa jenis
-[kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih.
+[kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih.
### Sebelum kamu memulai
@@ -89,10 +89,10 @@ spec:
```
Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`.
- Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/docs/concepts/cluster-administration/manage-deployment/).
+ Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/id/docs/concepts/cluster-administration/manage-deployment/).
Ingress seringkali menggunakan anotasi untuk melakukan konfigurasi beberapa opsi yang ada bergantung pada kontroler Ingress yang digunakan, sebagai contohnya
adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
- [Kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
+ [Kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan.
[Spesifikasi](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) Ingress
@@ -111,7 +111,7 @@ Setiap *rule* HTTP mengandung informasi berikut:
dan `servicePort`. Baik *host* dan *path* harus sesuai dengan konten dari *request* yang masuk sebelum
*loadbalancer* akan mengarahkan trafik pada *service* yang sesuai.
* Suatu *backend* adalah kombinasi *service* dan *port* seperti yang dideskripsikan di
- [dokumentasi *Service*](/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan
+ [dokumentasi *Service*](/id/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan
*host* dan *path* yang ada pada *rule* akan diteruskan pada *backend* terkait.
*Backend default* seringkali dikonfigurasi pada kontroler kontroler Ingress, tugas *backend default* ini adalah
@@ -120,7 +120,7 @@ Setiap *rule* HTTP mengandung informasi berikut:
### *Backend Default*
Sebuah Ingress yang tidak memiliki *rules* akan mengarahkan semua trafik pada sebuah *backend default*. *Backend default* inilah yang
-biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress.
+biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress.
Jika tidak ada *host* atau *path* yang sesuai dengan *request* HTTP pada objek Ingress, maka trafik tersebut
akan diarahkan pada *backend default*.
@@ -218,8 +218,8 @@ Apabila *Ingress* selesai dibuat, maka kamu dapat melihat alamat IP dari berbaga
pada kolom `address`.
{{< note >}}
-Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/docs/concepts/services-networking/service/)
-bergantung pada [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang kamu pakai.
+Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/id/docs/concepts/services-networking/service/)
+bergantung pada [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang kamu pakai.
{{< /note >}}
### Virtual Host berbasis Nama
@@ -291,7 +291,7 @@ spec:
### TLS
-Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/docs/concepts/configuration/secret)
+Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/id/docs/concepts/configuration/secret)
yang mengandung *private key* dan sertifikat TLS. Saat ini, Ingress hanya
memiliki fitur untuk melakukan konfigurasi *single TLS port*, yaitu 443, serta melakukan terminasi TLS.
Jika *section* TLS pada Ingress memiliki spesifikasi *host* yang berbeda,
@@ -448,8 +448,8 @@ Ingress yang ingin diubah.
## Mekanisme *failing* pada beberapa zona *availability*
Teknik untuk menyeimbangkan persebaran trafik pada *failure domain* berbeda antar penyedia layanan *cloud*.
-Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers)
-untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/docs/concepts/cluster-administration/federation/)
+Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/id/docs/concepts/services-networking/ingress-controllers)
+untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/id/docs/concepts/cluster-administration/federation/)
untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi klaster.
## Pengembangan selanjutnya
@@ -463,8 +463,8 @@ soal perubahan berbagai kontroler.
Kamu dapat mengekspos sebuah *Service* dalam berbagai cara, tanpa harus menggunakan *resource* Ingress, dengan menggunakan:
-* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
-* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
+* [Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer)
+* [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport)
* [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md
index 25f42ddb98..fe510b846d 100644
--- a/content/id/docs/concepts/services-networking/network-policies.md
+++ b/content/id/docs/concepts/services-networking/network-policies.md
@@ -80,7 +80,7 @@ kecuali penyedia jaringan mendukung network policy.
**_Field-field_ yang bersifat wajib**: Sama dengan seluruh _config_ Kubernetes lainnya, sebuah `NetworkPolicy`
membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai
bagaimana bekerja dengan _file_ `config`, dapat dilihat di
-[Konfigurasi Kontainer menggunakan `ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+[Konfigurasi Kontainer menggunakan `ConfigMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/),
serta [Manajemen Objek](/docs/concepts/overview/object-management-kubectl/overview/).
**spec**: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) memiliki semua informasi yang harus diberikan untuk memberikan definisi _network policy_ yang ada pada _namespace_ tertentu.
diff --git a/content/id/docs/concepts/services-networking/service-topology.md b/content/id/docs/concepts/services-networking/service-topology.md
index ef15d1ab3d..05abffa323 100644
--- a/content/id/docs/concepts/services-networking/service-topology.md
+++ b/content/id/docs/concepts/services-networking/service-topology.md
@@ -186,5 +186,5 @@ spec:
* Baca tentang [mengaktifkan topologi Service](/docs/tasks/administer-cluster/enabling-service-topology)
-* Baca [menghubungkan aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
+* Baca [menghubungkan aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/)
diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md
index 97626bf9ce..00bf4e6241 100644
--- a/content/id/docs/concepts/services-networking/service.md
+++ b/content/id/docs/concepts/services-networking/service.md
@@ -12,9 +12,9 @@ weight: 10
-[`Pod`](/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
+[`Pod`](/id/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut
-tidak akan dihidupkan kembali. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) secara
+tidak akan dihidupkan kembali. [`ReplicaSets`](/id/docs/concepts/workloads/controllers/replicaset/) secara
khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*).
Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP
yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil.
@@ -26,7 +26,7 @@ Inilah alasan kenapa `Service` ada.
Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi
set logis yang terdiri beberapa `Pod` serta _policy_ bagaimana cara kamu mengakses sekumpulan `Pod` tadi - seringkali disebut sebagai _microservices_.
-Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors)
(lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa
sebuah _selector_).
@@ -95,7 +95,7 @@ mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja:
* Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_,
kamu ingin menggunakan basis datamu sendiri.
* Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada
- [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
+ [_Namespace_](/id/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
* Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih
berada di luar klaster Kubernetes.
@@ -319,7 +319,7 @@ Meskipun begitu, DNS tidak memiliki keterbatasan ini.
### DNS
-Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional
+Salah satu [_add-on_](/id/docs/concepts/cluster-administration/addons/) opsional
(meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah
terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk
_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis
@@ -338,7 +338,7 @@ nomor _port_ yang digunakan oleh _http_.
Server DNS Kubernetes adalah satu-satunya cara untuk mengakses
_Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di
-[DNS _Pods_ dan _Services_](/docs/concepts/services-networking/dns-pod-service/).
+[DNS _Pods_ dan _Services_](/id/docs/concepts/services-networking/dns-pod-service/).
## `Service` _headless_
@@ -745,10 +745,10 @@ dan tidak akan menerima trafik apa pun.
Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan
_DaemonSet_ atau melakukan spesifikasi
-[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
+[pod anti-affinity](/id/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
agar `Pod` tidak di-_assign_ ke _node_ yang sama.
-NLB juga dapat digunakan dengan anotasi [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer).
+NLB juga dapat digunakan dengan anotasi [internal load balancer](/id/docs/concepts/services-networking/service/#internal-load-balancer).
Agar trafik klien berhasil mencapai _instances_ dibelakang ELB,
_security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut:
@@ -1006,7 +1006,7 @@ alternatif penggunaan `Service` untuk HTTP/HTTPS.
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)),
+Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/id/docs/concepts/cluster-administration/cloud-providers/#aws)),
_Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_
di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks
[protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt).
diff --git a/content/id/docs/concepts/storage/dynamic-provisioning.md b/content/id/docs/concepts/storage/dynamic-provisioning.md
index ac206dfacd..4b9fa6f35c 100644
--- a/content/id/docs/concepts/storage/dynamic-provisioning.md
+++ b/content/id/docs/concepts/storage/dynamic-provisioning.md
@@ -8,7 +8,7 @@ weight: 40
Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_).
Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin klaster secara manual harus
-memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/)
+memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/id/docs/concepts/storage/persistent-volumes/)
sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan
penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis
ketika diminta oleh pengguna.
@@ -32,7 +32,7 @@ kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu kh
rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk
memilih berbagai macam pilihan penyimpanan.
-Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concepts/storage/storage-classes/).
+Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/id/docs/concepts/storage/storage-classes/).
## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_)
@@ -123,6 +123,6 @@ tidak bisa terbuat.
Pada klaster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona
pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada
Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur
-[Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
+[Mode Volume Binding](/id/docs/concepts/storage/storage-classes/#volume-binding-mode).
diff --git a/content/id/docs/concepts/storage/persistent-volumes.md b/content/id/docs/concepts/storage/persistent-volumes.md
index f75941b86a..51163d36a9 100644
--- a/content/id/docs/concepts/storage/persistent-volumes.md
+++ b/content/id/docs/concepts/storage/persistent-volumes.md
@@ -11,7 +11,7 @@ weight: 20
-Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/docs/concepts/storage/volumes/).
+Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/id/docs/concepts/storage/volumes/).
@@ -34,7 +34,7 @@ mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimpl
kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya
`StorageClass`.
-Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
+Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
## Siklus hidup dari sebuah volume dan klaim
@@ -360,7 +360,7 @@ Pada CLI, mode-mode akses tersebut disingkat menjadi:
Sebuah PV bisa memiliki sebuah kelas, yang dispesifikasi dalam pengaturan atribut
`storageClassName` menjadi nama
-[StorageClass](/docs/concepts/storage/storage-classes/).
+[StorageClass](/id/docs/concepts/storage/storage-classes/).
Sebuah PV dari kelas tertentu hanya dapat terikat dengan PVC yang meminta
kelas tersebut. Sebuah PV tanpa `storageClassName` tidak memiliki kelas dan hanya dapat terikat
dengan PVC yang tidak meminta kelas tertentu.
@@ -412,7 +412,7 @@ akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang.
### Afinitas Node
{{< note >}}
-Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/docs/concepts/storage/volumes/#local).
+Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/id/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/id/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/id/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/id/docs/concepts/storage/volumes/#local).
{{< /note >}}
Sebuah PV dapat menspesifikasi [afinitas node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) untuk mendefinisikan batasan yang membatasi _node_ mana saja yang dapat mengakses volume tersebut. _Pod_ yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke _node_ yang dipilih oleh afinitas _node_.
@@ -466,7 +466,7 @@ Klaim, seperti _pod_, bisa meminta sumber daya dengan jumlah tertentu. Pada kas
### _Selector_
-Klaim dapat menspesifikasi [_label selector_](/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom:
+Klaim dapat menspesifikasi [_label selector_](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom:
* `matchLabels` - volume harus memiliki label dengan nilai ini
* `matchExpressions` - daftar dari persyaratan yang dibuat dengan menentukan kunci, daftar nilai, dan operator yang menghubungkan kunci dengan nilai. Operator yang valid meliputi In, NotIn, Exists, dan DoesNotExist.
@@ -476,7 +476,7 @@ Semua persyaratan tersebut, dari `matchLabels` dan `matchExpressions` akan dilak
### Kelas
Sebuah klaim dapat meminta kelas tertentu dengan menspesifikasi nama dari
-[StorageClass](/docs/concepts/storage/storage-classes/)
+[StorageClass](/id/docs/concepts/storage/storage-classes/)
menggunakan atribut `storageClassName`.
Hanya PV dari kelas yang diminta, yang memiliki `storageClassName` yang sama dengan PVC, yang dapat
terikat dengan PVC.
@@ -647,7 +647,7 @@ Hanya volume yang disediakan secara statis yang didukung untuk rilis alfa. Admin
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/docs/concepts/storage/volume-snapshots/).
+Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/id/docs/concepts/storage/volume-snapshots/).
Untuk mengaktifkan dukungan pemulihan sebuah volume dari sebuah sumber data _volume snapshot_, aktifkan
gerbang fitur `VolumeSnapshotDataSource` pada apiserver dan _controller-manager_.
diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md
index 6de85830e8..2897399e80 100644
--- a/content/id/docs/concepts/storage/storage-classes.md
+++ b/content/id/docs/concepts/storage/storage-classes.md
@@ -8,8 +8,8 @@ weight: 30
Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes.
Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap
-[volumes](/docs/concepts/storage/volumes/) dan
-[peristent volume](/docs/concepts/storage/persistent-volumes) terlebih dahulu.
+[volumes](/id/docs/concepts/storage/volumes/) dan
+[peristent volume](/id/docs/concepts/storage/persistent-volumes) terlebih dahulu.
@@ -40,7 +40,7 @@ dan objek yang sudah dibuat tidak dapat diubah lagi definisinya.
Administrator dapat memberikan spesifikasi StorageClass _default_ bagi
PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_:
-kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#class-1)
+kamu dapat membaca [bagian `PersistentVolumeClaim`](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
untuk penjelasan lebih lanjut.
```yaml
@@ -131,7 +131,7 @@ akan gagal apabila salah satu dari keduanya bersifat invalid.
### Mode Volume _Binding_
_Field_ `volumeBindingMode` mengontrol kapan mekanisme [_binding_ volume dan
-_provisioning_ dinamis](/docs/concepts/storage/persistent-volumes/#provisioning)
+_provisioning_ dinamis](/id/docs/concepts/storage/persistent-volumes/#provisioning)
harus dilakukan.
Secara _default_, ketika mode `Immediate` yang mengindikasikan
@@ -148,11 +148,11 @@ dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan
PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_
sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan
oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada,
-[persyaratan sumber daya](/docs/concepts/configuration/manage-compute-resources-container),
-[_node selector_](/docs/concepts/configuration/assign-pod-node/#nodeselector),
+[persyaratan sumber daya](/id/docs/concepts/configuration/manage-compute-resources-container),
+[_node selector_](/id/docs/concepts/configuration/assign-pod-node/#nodeselector),
[afinitas dan
-anti-afinitas Pod](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
-serta [_taint_ dan _toleration_](/docs/concepts/configuration/taint-and-toleration).
+anti-afinitas Pod](/id/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
+serta [_taint_ dan _toleration_](/id/docs/concepts/configuration/taint-and-toleration).
Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_
dinamis:
@@ -168,7 +168,7 @@ PersistentVolume yang terlebih dahulu dibuat:
* [Lokal](#lokal)
{{< feature-state state="beta" for_k8s_version="1.14" >}}
-[Volume-volume CSI](/docs/concepts/storage/volumes/#csi) juga didukung
+[Volume-volume CSI](/id/docs/concepts/storage/volumes/#csi) juga didukung
dengan adanya _provisioning_ dinamis serta PV yang telah terlebih dahulu dibuat,
meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi
untuk driver spesifik CSI untuk melihat topologi _key_ yang didukung
@@ -634,8 +634,8 @@ parameters:
di dalam grup sumber daya yang sama dengan klaster, serta `skuName` dan `location` akan diabaikan.
Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika klaster
-menggunakan konsep [RBAC](/docs/reference/access-authn-authz/rbac/) dan
-[_Roles_ Controller](/docs/reference/access-authn-authz/rbac/#controller-roles),
+menggunakan konsep [RBAC](/id/docs/reference/access-authn-authz/rbac/) dan
+[_Roles_ Controller](/id/docs/reference/access-authn-authz/rbac/#controller-roles),
menambahkan kapabilitas `create` untuk sumber daya `secret` bagi clusterrole
`system:controller:persistent-volume-binder`.
diff --git a/content/id/docs/concepts/storage/volume-pvc-datasource.md b/content/id/docs/concepts/storage/volume-pvc-datasource.md
index 4a5f5d8c8c..481e74c976 100644
--- a/content/id/docs/concepts/storage/volume-pvc-datasource.md
+++ b/content/id/docs/concepts/storage/volume-pvc-datasource.md
@@ -7,7 +7,7 @@ weight: 30
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
-Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/docs/concepts/storage/volumes) disarankan.
+Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/id/docs/concepts/storage/volumes) disarankan.
diff --git a/content/id/docs/concepts/storage/volume-snapshot-classes.md b/content/id/docs/concepts/storage/volume-snapshot-classes.md
index 0414a9d7de..fff7de9baa 100644
--- a/content/id/docs/concepts/storage/volume-snapshot-classes.md
+++ b/content/id/docs/concepts/storage/volume-snapshot-classes.md
@@ -7,8 +7,8 @@ weight: 30
Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan,
-sangat disarankan untuk membaca [_snapshot_ volume](/docs/concepts/storage/volume-snapshots/)
-dan [kelas penyimpanan (_storage class_)](/docs/concepts/storage/storage-classes) terlebih dahulu.
+sangat disarankan untuk membaca [_snapshot_ volume](/id/docs/concepts/storage/volume-snapshots/)
+dan [kelas penyimpanan (_storage class_)](/id/docs/concepts/storage/storage-classes) terlebih dahulu.
diff --git a/content/id/docs/concepts/storage/volume-snapshots.md b/content/id/docs/concepts/storage/volume-snapshots.md
index 39ab3d31aa..5ddfc2aaa6 100644
--- a/content/id/docs/concepts/storage/volume-snapshots.md
+++ b/content/id/docs/concepts/storage/volume-snapshots.md
@@ -7,7 +7,7 @@ weight: 20
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/docs/concepts/storage/persistent-volumes/) terlebih dahulu.
+Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) terlebih dahulu.
@@ -48,7 +48,7 @@ Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing
#### Dinamis
Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja
mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot.
-Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/)
dan administrator harus membuat serta mengatur _class_ tersebut supaya penyediaan dinamis bisa terjadi.
### Ikatan (_Binding_)
@@ -93,7 +93,7 @@ spec:
### _Class_
Suatu VolumeSnapshotContent dapat memiliki suatu _class_, yang didapat dengan mengatur atribut
-`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/).
+`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/).
VolumeSnapshotContent dari _class_ tertentu hanya dapat terikat (_bound_) dengan VolumeSnapshot yang
"meminta" _class_ tersebut. VolumeSnapshotContent tanpa `snapshotClassName` tidak memiliki _class_ dan hanya dapat
terikat (_bound_) dengan VolumeSnapshot yang "meminta" untuk tidak menggunakan _class_.
@@ -117,7 +117,7 @@ spec:
### _Class_
Suatu VolumeSnapshot dapat meminta sebuah _class_ tertentu dengan mengatur nama dari
-[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+[VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/)
menggunakan atribut `snapshotClassName`.
Hanya VolumeSnapshotContent dari _class_ yang diminta, memiliki `snapshotClassName` yang sama
dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut.
@@ -127,6 +127,6 @@ dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut.
Kamu dapat menyediakan sebuah volume baru, yang telah terisi dengan data dari suatu _snapshot_, dengan
menggunakan _field_ `dataSource` pada objek PersistentVolumeClaim.
-Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
+Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/id/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md
index 679de8c865..8d593f1eba 100644
--- a/content/id/docs/concepts/storage/volumes.md
+++ b/content/id/docs/concepts/storage/volumes.md
@@ -185,7 +185,7 @@ Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahk
### configMap {#configmap}
-Sumber daya [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod.
+Sumber daya [`configMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod.
Data yang ditaruh di dalam sebuah objek `ConfigMap` dapat dirujuk dalam sebuah Volume dengan tipe `configMap` dan kemudian digunakan oleh aplikasi/container yang berjalan di dalam sebuah Pod.
Saat mereferensikan sebuah objek `configMap`, kamu tinggal memasukkan nama ConfigMap tersebut ke dalam rincian Volume yang bersangkutan. Kamu juga dapat mengganti _path_ spesifik yang akan digunakan pada ConfigMap. Misalnya, untuk menambatkan ConfigMap `log-config` pada Pod yang diberi nama `configmap-pod`, kamu dapat menggunakan YAML ini:
@@ -215,7 +215,7 @@ ConfigMap `log-config` ditambatkan sebagai sebuah Volume, dan semua isinya yang
Perlu dicatat bahwa _path_ tersebut berasal dari isian `mountPath` pada Volume, dan `path` yang ditunjuk dengan `key` bernama `log_level`.
{{< caution >}}
-Kamu harus membuat sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya.
+Kamu harus membuat sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya.
{{< /caution >}}
{{< note >}}
@@ -346,7 +346,7 @@ Fitur [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#r
#### Menyediakan sebuah Regional PD PersistentVolume Secara Manual
-Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/docs/concepts/storage/storage-classes/#gce).
+Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/id/docs/concepts/storage/storage-classes/#gce).
Sebelum membuat sebuah PersistentVolume, kamu harus membuat PD-nya:
```shell
@@ -533,7 +533,7 @@ Kolom `nodeAffinity` ada PersistentVolue dibutuhkan saat menggunakan Volume `loc
Kolom `volumeMode` pada PersistentVolume sekarang dapat disetel menjadi "Block" (menggantikan nilai bawaan "Filesystem") untuk membuka Volume `local` tersebut sebagai media penyimpanan blok mentah. Hal ini membutuhkan diaktifkannya _Alpha feature gate_ `BlockVolume`.
-Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`.
+Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/id/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`.
Sebuah penyedia statis eksternal dapat berjalan secara terpisah untuk memperbaik pengaturan siklus hidup Volume `local`. Perlu dicatat bahwa penyedia ini belum mendukung _dynamic provisioning_. Untuk contoh bagaimana menjalankan penyedia Volume `local` eksternal, lihat [petunjuk penggunaannya](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner).
@@ -554,9 +554,9 @@ Lihat [contoh NFS](https://github.com/kubernetes/examples/tree/{{< param "github
### persistentVolumeClaim {#persistentvolumeclaim}
-Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan.
+Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan.
-Lihat [contoh PersistentVolumes](/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut.
+Lihat [contoh PersistentVolumes](/id/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut.
### projected {#projected}
@@ -742,7 +742,7 @@ Lihat [contoh RBD](https://github.com/kubernetes/examples/tree/{{< param "github
### scaleIO {#scaleio}
-ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)).
+ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/id/docs/concepts/storage/persistent-volumes/#scaleio)).
{{< caution >}}
Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya.
@@ -1033,7 +1033,7 @@ Dimulai pada versi 1.11, CSI memperkenalkan dukungak untuk volume blok _raw_, ya
Dukungan untuk volume blok CSI bersifat _feature-gate_, tapi secara bawaan diaktifkan. Kedua _feature-gate_ yang harus diaktifkan adalah `BlockVolume` dan `CSIBlockVolume`.
-Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
+Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/id/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
#### Volume CSI Sementara
diff --git a/content/id/docs/concepts/workloads/controllers/cron-jobs.md b/content/id/docs/concepts/workloads/controllers/cron-jobs.md
index 29fde331ea..ca5df2d86d 100644
--- a/content/id/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/id/docs/concepts/workloads/controllers/cron-jobs.md
@@ -6,7 +6,7 @@ weight: 80
-Suatu CronJob menciptakan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
+Suatu CronJob menciptakan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
Satu objek CronJob sepadan dengan satu baris pada _file_ _crontab_ (_cron table_). CronJob tersebut menjalankan suatu pekerjaan secara berkala
pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wiki/Cron).
@@ -15,7 +15,7 @@ pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wik
Seluruh waktu `schedule:` pada _**CronJob**_ mengikuti zona waktu dari _master_ di mana Job diinisiasi.
{{< /note >}}
-Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/docs/tasks/job/automated-tasks-with-cron-jobs).
+Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/id/docs/tasks/job/automated-tasks-with-cron-jobs).
diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md
index baa79aa3f2..0b1c0e71e9 100644
--- a/content/id/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/id/docs/concepts/workloads/controllers/daemonset.md
@@ -48,7 +48,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
Seperti semua konfigurasi Kubernetes lainnya, DaemonSet membutuhkan _field_
`apiVersion`, `kind`, dan `metadata`. Untuk informasi umum tentang berkas konfigurasi, lihat dokumen [men-_deploy_ aplikasi](/docs/user-guide/deploying-applications/),
-[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/docs/concepts/overview/working-with-objects/object-management/).
+[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/id/docs/concepts/overview/working-with-objects/object-management/).
DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -61,7 +61,7 @@ DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contrib
Selain _field_ wajib untuk Pod, templat Pod di DaemonSet harus
menspesifikasikan label yang sesuai (lihat [selektor Pod](#selektor-pod)).
-Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
yang bernilai `Always`, atau tidak dispesifikasikan, sehingga _default_ menjadi `Always`.
DaemonSet dengan nilai `Always` membuat Pod akan selalu di-_restart_ saat kontainer
keluar/berhenti atau terjadi _crash_.
@@ -77,7 +77,7 @@ Mengubah selektor Pod dapat menyebabkan Pod _orphan_ yang tidak disengaja, dan m
Objek `.spec.selector` memiliki dua _field_:
-* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
+* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/).
* `matchExpressions` - bisa digunakan untuk membuat selektor yang lebih canggih
dengan mendefinisikan _key_, daftar _value_ dan operator yang menyatakan
hubungan antara _key_ dan _value_.
@@ -97,8 +97,8 @@ membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_.
Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan
membuat Pod pada Node yang cocok dengan [selektor
-Node](/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
-maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/docs/concepts/configuration/assign-pod-node/).
+Node](/id/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
+maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/configuration/assign-pod-node/).
Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan
membuat Pod pada semua Node.
@@ -116,7 +116,7 @@ mendatangkan masalah-masalah berikut:
* Inkonsistensi perilaku Pod: Pod normal yang menunggu dijadwalkan akan dibuat
dalam keadaan `Pending`, tapi Pod DaemonSet tidak seperti itu. Ini
membingungkan untuk pengguna.
- * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
+ * [Pod preemption](/id/docs/concepts/configuration/pod-priority-preemption/)
ditangani oleh _default scheduler_. Ketika _preemption_ dinyalakan,
_controller_ DaemonSet akan membuat keputusan penjadwalan tanpa
memperhitungkan prioritas Pod dan _preemption_.
@@ -148,7 +148,7 @@ mengabaikan Node `unschedulable` ketika menjadwalkan Pod DaemonSet.
### _Taint_ dan _Toleration_
Meskipun Pod Daemon menghormati
-[taint dan toleration](/docs/concepts/configuration/taint-and-toleration),
+[taint dan toleration](/id/docs/concepts/configuration/taint-and-toleration),
_toleration_ berikut ini akan otomatis ditambahkan ke Pod DaemonSet sesuai
dengan fitur yang bersangkutan.
@@ -170,7 +170,7 @@ Beberapa pola yang mungkin digunakan untuk berkomunikasi dengan Pod dalam Daemon
- **Push**: Pod dalam DaemonSet diatur untuk mengirim pembaruan status ke servis lain,
contohnya _stats database_. Pod ini tidak memiliki klien.
- **IP Node dan Konvensi Port**: Pod dalam DaemonSet dapat menggunakan `hostPort`, sehingga Pod dapat diakses menggunakan IP Node. Klien tahu daftar IP Node dengan suatu cara, dan tahu port berdasarkan konvensi.
-- **DNS**: Buat [headless service](/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
+- **DNS**: Buat [headless service](/id/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
dan temukan DaemonSet menggunakan _resource_ `endpoints` atau mengambil beberapa A _record_ dari DNS.
- **Service**: Buat Servis dengan Pod selektor yang sama, dan gunakan Servis untuk mengakses _daemon_ pada
Node random. (Tidak ada cara mengakses spesifik Node)
@@ -223,7 +223,7 @@ _bootstrapping_ klaster.
### Deployment
-DaemonSet mirip dengan [Deployment](/docs/concepts/workloads/controllers/deployment/) sebab mereka
+DaemonSet mirip dengan [Deployment](/id/docs/concepts/workloads/controllers/deployment/) sebab mereka
sama-sama membuat Pod, dan Pod yang mereka buat punya proses yang seharusnya tidak berhenti (e.g. peladen web,
peladen penyimpanan)
diff --git a/content/id/docs/concepts/workloads/controllers/deployment.md b/content/id/docs/concepts/workloads/controllers/deployment.md
index 045c04e59b..8eae6c579f 100644
--- a/content/id/docs/concepts/workloads/controllers/deployment.md
+++ b/content/id/docs/concepts/workloads/controllers/deployment.md
@@ -51,14 +51,14 @@ Dalam contoh ini:
Dalam kasus ini, kamu hanya perlu memilih sebuah label yang didefinisikan pada templat Pod (`app: nginx`).
Namun, aturan pemilihan yang lebih canggih mungkin dilakukan asal templat Pod-nya memenuhi aturan.
{{< note >}}
- Kolom `matchLabels` berbentuk pasangan {key,value}. Sebuah {key,value} dalam _map_ `matchLabels` ekuivalen dengan
+ Kolom `matchLabels` berbentuk pasangan {key,value}. Sebuah {key,value} dalam _map_ `matchLabels` ekuivalen dengan
elemen pada `matchExpressions`, yang mana kolom key adalah "key", operator adalah "In", dan larik values hanya berisi "value".
Semua prasyarat dari `matchLabels` maupun `matchExpressions` harus dipenuhi agar dapat dicocokkan.
{{< /note >}}
* Kolom `template` berisi sub kolom berikut:
* Pod dilabeli `app: nginx` dengan kolom `labels`.
- * Spesifikasi templat Pod atau kolom `.template.spec` menandakan bahwa Pod mennjalankan satu kontainer `nginx`,
+ * Spesifikasi templat Pod atau kolom `.template.spec` menandakan bahwa Pod mennjalankan satu kontainer `nginx`,
yang menjalankan image `nginx` [Docker Hub](https://hub.docker.com/) dengan versi 1.7.9.
* Membuat satu kontainer bernama `nginx` sesuai kolom `name`.
@@ -123,8 +123,8 @@ Dalam contoh ini:
ReplicaSet yang dibuat menjamin bahwa ada tiga Pod `nginx`.
{{< note >}}
- Kamu harus memasukkan selektor dan label templat Pod yang benar pada Deployment (dalam kasus ini, `app: nginx`).
- Jangan membuat label atau selektor yang beririsan dengan kontroler lain (termasuk Deployment dan StatefulSet lainnya). Kubernetes tidak akan mencegah adanya label yang beririsan.
+ Kamu harus memasukkan selektor dan label templat Pod yang benar pada Deployment (dalam kasus ini, `app: nginx`).
+ Jangan membuat label atau selektor yang beririsan dengan kontroler lain (termasuk Deployment dan StatefulSet lainnya). Kubernetes tidak akan mencegah adanya label yang beririsan.
Namun, jika beberapa kontroler memiliki selektor yang beririsan, kontroler itu mungkin akan konflik dan berjalan dengan tidak semestinya.
{{< /note >}}
@@ -144,7 +144,7 @@ Label ini menjamin anak-anak ReplicaSet milik Deployment tidak tumpang tindih. D
Rilis Deployment hanya dapat dipicu oleh perubahan templat Pod Deployment (yaitu, `.spec.template`), contohnya perubahan kolom label atau image container. Yang lain, seperti replika, tidak akan memicu rilis.
{{< /note >}}
-Ikuti langkah-langkah berikut untuk membarui Deployment:
+Ikuti langkah-langkah berikut untuk membarui Deployment:
1. Ganti Pod nginx menjadi image `nginx:1.9.1` dari image `nginx:1.7.9`.
@@ -191,7 +191,7 @@ Untuk menampilkan detail lain dari Deployment yang terbaru:
nginx-deployment 3 3 3 3 36s
```
-* Jalankan `kubectl get rs` to see that the Deployment updated the Pods dengan membuat ReplicaSet baru dan
+* Jalankan `kubectl get rs` to see that the Deployment updated the Pods dengan membuat ReplicaSet baru dan
menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replika.
```shell
@@ -228,7 +228,7 @@ menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replik
Umumnya, dia memastikan paling banyak ada 125% jumlah Pod yang diinginkan menyala (25% tambahan maksimal).
Misalnya, jika kamu lihat Deployment diatas lebih jauh, kamu akan melihat bahwa pertama-tama dia membuat Pod baru,
- kemudian menghapus beberapa Pod lama, dan membuat yang baru. Dia tidak akan menghapus Pod lama sampai ada cukup
+ kemudian menghapus beberapa Pod lama, dan membuat yang baru. Dia tidak akan menghapus Pod lama sampai ada cukup
Pod baru menyala, dan pula tidak membuat Pod baru sampai ada cukup Pod lama telah mati.
Dia memastikan paling sedikit 2 Pod menyala dan paling banyak total 4 Pod menyala.
@@ -236,7 +236,7 @@ menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replik
```shell
kubectl describe deployments
```
- Keluaran akan tampil seperti berikut:
+ Keluaran akan tampil seperti berikut:
```
Name: nginx-deployment
Namespace: default
@@ -277,15 +277,15 @@ menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replik
```
Disini bisa dilihat ketika pertama Deployment dibuat, dia membuat ReplicaSet (nginx-deployment-2035384211)
dan langsung menggandakannya menjadi 3 replika. Saat Deployment diperbarui, dia membuat ReplicaSet baru
- (nginx-deployment-1564180365) dan menambah 1 replika kemudian mengecilkan ReplicaSet lama menjadi 2,
+ (nginx-deployment-1564180365) dan menambah 1 replika kemudian mengecilkan ReplicaSet lama menjadi 2,
sehingga paling sedikit 2 Pod menyala dan paling banyak 4 Pod dibuat setiap saat. Dia kemudian lanjut menaik-turunkan
- ReplicaSet baru dan ReplicaSet lama, dengan strategi pembaruan rolling yang sama.
+ ReplicaSet baru dan ReplicaSet lama, dengan strategi pembaruan rolling yang sama.
Terakhir, kamu akan dapat 3 replika di ReplicaSet baru telah menyala, dan ReplicaSet lama akan hilang (berisi 0).
### Perpanjangan (alias banyak pembaruan secara langsung)
-Setiap kali Deployment baru is teramati oleh Deployment kontroler, ReplicaSet dibuat untuk membangkitkan Pod sesuai keinginan.
-Jika Deployment diperbarui, ReplicaSet yang terkait Pod dengan label `.spec.selector` yang cocok,
+Setiap kali Deployment baru is teramati oleh Deployment kontroler, ReplicaSet dibuat untuk membangkitkan Pod sesuai keinginan.
+Jika Deployment diperbarui, ReplicaSet yang terkait Pod dengan label `.spec.selector` yang cocok,
namun kolom `.spec.template` pada templat tidak cocok akan dihapus. Kemudian, ReplicaSet baru akan
digandakan sebanyak `.spec.replicas` dan semua ReplicaSet lama dihapus.
@@ -294,7 +294,7 @@ tiap perubahan dan memulai penggandaan. Lalu, dia akan mengganti ReplicaSet yang
-- mereka ditambahkan ke dalam daftar ReplicaSet lama dan akan mulai dihapus.
Contohnya, ketika kamu membuat Deployment untuk membangkitkan 5 replika `nginx:1.7.9`,
-kemudian membarui Deployment dengan versi `nginx:1.9.1` ketika ada 3 replika `nginx:1.7.9` yang dibuat.
+kemudian membarui Deployment dengan versi `nginx:1.9.1` ketika ada 3 replika `nginx:1.7.9` yang dibuat.
Dalam kasus ini, Deployment akan segera menghapus 3 replika Pod `nginx:1.7.9` yang telah dibuat, dan mulai membuat
Pod `nginx:1.9.1`. Dia tidak akan menunggu kelima replika `nginx:1.7.9` selesai baru menjalankan perubahan.
@@ -310,8 +310,8 @@ Pada versi API `apps/v1`, selektor label Deployment tidak bisa diubah ketika sel
* Penambahan selektor mensyaratkan label templat Pod di spek Deployment untuk diganti dengan label baru juga.
Jika tidak, galat validasi akan muncul. Perubahan haruslah tidak tumpang-tindih, dengan kata lain selektor baru tidak mencakup ReplicaSet dan Pod yang dibuat dengan selektor lama. Sehingga, semua ReplicaSet lama akan menggantung sedangkan ReplicaSet baru tetap dibuat.
* Pengubahan selektor mengubah nilai pada kunci selektor -- menghasilkan perilaku yang sama dengan penambahan.
-* Penghapusan selektor menghilangkan kunci yang ada pada selektor Deployment -- tidak mensyaratkan perubahan apapun pada label templat Pod.
-ReplicaSet yang ada tidak menggantung dan ReplicaSet baru tidak dibuat.
+* Penghapusan selektor menghilangkan kunci yang ada pada selektor Deployment -- tidak mensyaratkan perubahan apapun pada label templat Pod.
+ReplicaSet yang ada tidak menggantung dan ReplicaSet baru tidak dibuat.
Tapi perhatikan bahwa label yang dihapus masih ada pada Pod dan ReplicaSet masing-masing.
## Membalikkan Deployment
@@ -321,10 +321,10 @@ Umumnya, semua riwayat rilis Deployment disimpan oleh sistem sehingga kamu dapat
(kamu dapat mengubahnya dengan mengubah batas riwayat revisi).
{{< note >}}
-Revisi Deployment dibuat saat rilis Deployment dipicu. Ini berarti revisi baru dibuat jika dan hanya jika
-templat Pod Deployment (`.spec.template`) berubah, misalnya jika kamu membarui label atau image kontainer pada templat.
-Pembaruan lain, seperti penggantian skala Deployment, tidak membuat revisi Deployment, jadi kamu dapat memfasilitasi
-penggantian skala secara manual atau otomatis secara simultan. Artinya saat kamu membalikkan ke versi sebelumnya,
+Revisi Deployment dibuat saat rilis Deployment dipicu. Ini berarti revisi baru dibuat jika dan hanya jika
+templat Pod Deployment (`.spec.template`) berubah, misalnya jika kamu membarui label atau image kontainer pada templat.
+Pembaruan lain, seperti penggantian skala Deployment, tidak membuat revisi Deployment, jadi kamu dapat memfasilitasi
+penggantian skala secara manual atau otomatis secara simultan. Artinya saat kamu membalikkan ke versi sebelumnya,
hanya bagian templat Pod Deployment yang dibalikkan.
{{< /note >}}
@@ -350,7 +350,7 @@ hanya bagian templat Pod Deployment yang dibalikkan.
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
```
-* Tekan Ctrl-C untuk menghentikan pemeriksaan status rilis di atas. Untuk info lebih lanjut
+* Tekan Ctrl-C untuk menghentikan pemeriksaan status rilis di atas. Untuk info lebih lanjut
tentang rilis tersendat, [baca disini](#status-deployment).
* Kamu lihat bahwa jumlah replika lama (`nginx-deployment-1564180365` dan `nginx-deployment-2035384211`) adalah 2, dan replika baru (nginx-deployment-3066724191) adalah 1.
@@ -383,17 +383,17 @@ tentang rilis tersendat, [baca disini](#status-deployment).
```
{{< note >}}
- Controller Deployment menghentikan rilis yang buruk secara otomatis dan juga berhenti meningkatkan ReplicaSet baru.
+ Controller Deployment menghentikan rilis yang buruk secara otomatis dan juga berhenti meningkatkan ReplicaSet baru.
Ini tergantung pada parameter rollingUpdate (secara khusus `maxUnavailable`) yang dimasukkan.
Kubernetes umumnya mengatur jumlahnya menjadi 25%.
{{< /note >}}
-* Tampilkan deskripsi Deployment:
+* Tampilkan deskripsi Deployment:
```shell
kubectl describe deployment
```
- Keluaran akan tampil seperti berikut:
+ Keluaran akan tampil seperti berikut:
```
Name: nginx-deployment
Namespace: default
@@ -440,11 +440,11 @@ tentang rilis tersendat, [baca disini](#status-deployment).
Ikuti langkah-langkah berikut untuk mengecek riwayat rilis:
-1. Pertama, cek revisi Deployment sekarang:
+1. Pertama, cek revisi Deployment sekarang:
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment
```
- Keluaran akan tampil seperti berikut:
+ Keluaran akan tampil seperti berikut:
```
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
@@ -464,7 +464,7 @@ Ikuti langkah-langkah berikut untuk mengecek riwayat rilis:
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
```
- Keluaran akan tampil seperti berikut:
+ Keluaran akan tampil seperti berikut:
```
deployments "nginx-deployment" revision 2
Labels: app=nginx
@@ -489,7 +489,7 @@ Ikuti langkah-langkah berikut untuk membalikkan Deployment dari versi sekarang k
kubectl rollout undo deployment.v1.apps/nginx-deployment
```
- Keluaran akan tampil seperti berikut:
+ Keluaran akan tampil seperti berikut:
```
deployment.apps/nginx-deployment
```
@@ -499,7 +499,7 @@ Ikuti langkah-langkah berikut untuk membalikkan Deployment dari versi sekarang k
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
```
- Keluaran akan tampil seperti berikut:
+ Keluaran akan tampil seperti berikut:
```
deployment.apps/nginx-deployment
```
@@ -514,16 +514,16 @@ Ikuti langkah-langkah berikut untuk membalikkan Deployment dari versi sekarang k
kubectl get deployment nginx-deployment
```
- Keluaran akan tampil seperti berikut:
+ Keluaran akan tampil seperti berikut:
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 30m
```
-3. Tampilkan deskripsi Deployment:
+3. Tampilkan deskripsi Deployment:
```shell
kubectl describe deployment nginx-deployment
```
- Keluaran akan tampil seperti berikut:
+ Keluaran akan tampil seperti berikut:
```
Name: nginx-deployment
Namespace: default
@@ -594,9 +594,9 @@ deployment.apps/nginx-deployment scaled
### Pengaturan skala proporsional
-Deployment RollingUpdate mendukung beberapa versi aplikasi berjalan secara bersamaan. Ketika kamu atau autoscaler
-mengubah skala Deployment RollingUpdate yang ada di tengah rilis (yang sedang berjalan maupun terjeda),
-kontroler Deployment menyeimbangkan replika tambahan dalam ReplicaSet aktif (ReplicaSet dengan Pod) untuk mencegah resiko.
+Deployment RollingUpdate mendukung beberapa versi aplikasi berjalan secara bersamaan. Ketika kamu atau autoscaler
+mengubah skala Deployment RollingUpdate yang ada di tengah rilis (yang sedang berjalan maupun terjeda),
+kontroler Deployment menyeimbangkan replika tambahan dalam ReplicaSet aktif (ReplicaSet dengan Pod) untuk mencegah resiko.
Ini disebut *pengaturan skala proporsional*.
Sebagai contoh, kamu menjalankan Deployment dengan 10 replika, [maxSurge](#max-surge)=3, dan [maxUnavailable](#max-unavailable)=2.
@@ -636,20 +636,20 @@ persyaratan `maxUnavailable` yang disebut di atas. Cek status rilis:
* Kemudian, permintaan peningkatan untuk Deployment akan masuk. Autoscaler menambah replika Deployment
menjadi 15. Controller Deployment perlu menentukan dimana 5 replika ini ditambahkan. Jika kamu memakai
-pengaturan skala proporsional, kelima replika akan ditambahkan ke ReplicaSet baru. Dengan pengaturan skala proporsional,
+pengaturan skala proporsional, kelima replika akan ditambahkan ke ReplicaSet baru. Dengan pengaturan skala proporsional,
kamu menyebarkan replika tambahan ke semua ReplicaSet. Proporsi terbesar ada pada ReplicaSet dengan
-replika terbanyak dan proporsi yang lebih kecil untuk replika dengan ReplicaSet yang lebih sedikit.
+replika terbanyak dan proporsi yang lebih kecil untuk replika dengan ReplicaSet yang lebih sedikit.
Sisanya akan diberikan ReplicaSet dengan replika terbanyak. ReplicaSet tanpa replika tidak akan ditingkatkan.
-Dalam kasus kita di atas, 3 replika ditambahkan ke ReplicaSet lama dan 2 replika ditambahkan ke ReplicaSet baru.
-Proses rilis akan segera memindahkan semua ReplicaSet baru, dengan asumsi semua replika dalam kondisi sehat.
-Untuk memastikannya, jalankan:
+Dalam kasus kita di atas, 3 replika ditambahkan ke ReplicaSet lama dan 2 replika ditambahkan ke ReplicaSet baru.
+Proses rilis akan segera memindahkan semua ReplicaSet baru, dengan asumsi semua replika dalam kondisi sehat.
+Untuk memastikannya, jalankan:
```shell
kubectl get deploy
```
-Keluaran akan tampil seperti berikut:
+Keluaran akan tampil seperti berikut:
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 15 18 7 8 7m
@@ -668,7 +668,7 @@ nginx-deployment-618515232 11 11 11 7m
## Menjeda dan Melanjutkan Deployment
-Kamu dapat menjeda Deployment sebelum memicu satu atau lebih pembaruan kemudian meneruskannya.
+Kamu dapat menjeda Deployment sebelum memicu satu atau lebih pembaruan kemudian meneruskannya.
Hal ini memungkinkanmu menerapkan beberapa perbaikan selama selang jeda tanpa melakukan rilis yang tidak perlu.
* Sebagai contoh, Deployment yang baru dibuat:
@@ -743,7 +743,7 @@ Hal ini memungkinkanmu menerapkan beberapa perbaikan selama selang jeda tanpa me
deployment.apps/nginx-deployment resource requirements updated
```
- The state awal Deployment sebelum jeda akan melanjutkan fungsinya, tapi perubahan
+ The state awal Deployment sebelum jeda akan melanjutkan fungsinya, tapi perubahan
Deployment tidak akan berefek apapun selama Deployment masih terjeda.
* Kemudian, mulai kembali Deployment dan perhatikan ReplicaSet baru akan muncul dengan semua perubahan baru:
@@ -795,7 +795,7 @@ Kamu tidak bisa membalikkan Deployment yang terjeda sampai dia diteruskan.
## Status Deployment
-Deployment melalui berbagai state dalam daur hidupnya. Dia dapat [berlangsung](#deployment-berlangsung) selagi merilis ReplicaSet baru, bisa juga [selesai](#deployment-selesai),
+Deployment melalui berbagai state dalam daur hidupnya. Dia dapat [berlangsung](#deployment-berlangsung) selagi merilis ReplicaSet baru, bisa juga [selesai](#deployment-selesai),
atau juga [gagal](#deployment-gagal).
### Deployment Berlangsung
@@ -817,7 +817,7 @@ Kubernetes menandai Deployment sebagai _complete_ saat memiliki karakteristik be
* Semua replika terkait Deployment dapat diakses.
* Tidak ada replika lama untuk Deployment yang berjalan.
-Kamu dapat mengecek apakah Deployment telah selesai dengan `kubectl rollout status`.
+Kamu dapat mengecek apakah Deployment telah selesai dengan `kubectl rollout status`.
Jika rilis selesai, `kubectl rollout status` akan mengembalikan nilai balik nol.
```shell
@@ -833,7 +833,7 @@ $ echo $?
### Deployment Gagal
-Deployment-mu bisa saja terhenti saat mencoba deploy ReplicaSet terbaru tanpa pernah selesai.
+Deployment-mu bisa saja terhenti saat mencoba deploy ReplicaSet terbaru tanpa pernah selesai.
Ini dapat terjadi karena faktor berikut:
* Kuota tidak mencukupi
@@ -868,7 +868,7 @@ berikut ke `.status.conditions` milik Deployment:
Lihat [konvensi Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) untuk info lebih lanjut tentang kondisi status.
{{< note >}}
-Kubernetes tidak melakukan apapun pada Deployment yang tersendat selain melaporkannya sebagai `Reason=ProgressDeadlineExceeded`.
+Kubernetes tidak melakukan apapun pada Deployment yang tersendat selain melaporkannya sebagai `Reason=ProgressDeadlineExceeded`.
Orkestrator yang lebih tinggi dapat memanfaatkannya untuk melakukan tindak lanjut. Misalnya, mengembalikan Deployment ke versi sebelumnya.
{{< /note >}}
@@ -877,7 +877,7 @@ Jika Deployment terjeda, Kubernetes tidak akan mengecek kemajuan pada selang itu
Kamu dapat menjeda Deployment di tengah rilis dan melanjutkannya dengan aman tanpa memicu kondisi saat tenggat telah lewat.
{{< /note >}}
-Kamu dapat mengalami galat sejenak pada Deployment disebabkan timeout yang dipasang terlalu kecil atau
+Kamu dapat mengalami galat sejenak pada Deployment disebabkan timeout yang dipasang terlalu kecil atau
hal-hal lain yang terjadi sementara. Misalnya, kamu punya kuota yang tidak mencukupi. Jika kamu mendeskripsikan Deployment
kamu akan menjumpai pada bagian ini:
@@ -937,7 +937,7 @@ Conditions:
ReplicaFailure True FailedCreate
```
-Kamu dapat menangani isu keterbatasan kuota dengan menurunkan jumlah Deployment, bisa dengan menghapus kontrolers
+Kamu dapat menangani isu keterbatasan kuota dengan menurunkan jumlah Deployment, bisa dengan menghapus kontrolers
yang sedang berjalan, atau dengan meningkatkan kuota pada namespace. Jika kuota tersedia, kemudian kontroler Deployment
akan dapat menyelesaikan rilis Deployment. Kamu akan melihat bahwa status Deployment berubah menjadi kondisi sukses (`Status=True` dan `Reason=NewReplicaSetAvailable`).
@@ -951,7 +951,7 @@ Conditions:
`Type=Available` dengan `Status=True` artinya Deployment-mu punya ketersediaan minimum. Ketersediaan minimum diatur
oleh parameter yang dibuat pada strategi deployment. `Type=Progressing` dengan `Status=True` berarti Deployment
-sedang dalam rilis dan masih berjalan atau sudah selesai berjalan dan jumlah minimum replika tersedia
+sedang dalam rilis dan masih berjalan atau sudah selesai berjalan dan jumlah minimum replika tersedia
(lihat bagian Alasan untuk kondisi tertentu - dalam kasus ini `Reason=NewReplicaSetAvailable` berarti Deployment telah selesai).
Kamu dapat mengecek apakah Deployment gagal berkembang dengan perintah `kubectl rollout status`. `kubectl rollout status`
@@ -974,7 +974,7 @@ Semua aksi yang dapat diterapkan pada Deployment yang selesai berjalan juga pada
## Kebijakan Pembersihan
-Kamu dapat mengisi kolom `.spec.revisionHistoryLimit` di Deployment untuk menentukan banyak ReplicaSet
+Kamu dapat mengisi kolom `.spec.revisionHistoryLimit` di Deployment untuk menentukan banyak ReplicaSet
pada Deployment yang ingin dipertahankan. Sisanya akan di garbage-collected di balik layar. Umumnya, nilai kolom berisi 10.
{{< note >}}
@@ -984,7 +984,7 @@ sehingga Deployment tidak akan dapat dikembalikan.
## Deployment Canary
-Jika kamu ingin merilis ke sebagian pengguna atau server menggunakan Deployment,
+Jika kamu ingin merilis ke sebagian pengguna atau server menggunakan Deployment,
kamu dapat membuat beberapa Deployment, satu tiap rilis, dengan mengikuti pola canary yang didesripsikan pada
[mengelola sumber daya](/id/docs/concepts/cluster-administration/manage-deployment/#deploy-dengan-canary).
@@ -1002,7 +1002,7 @@ Dalam `.spec` hanya ada kolom `.spec.template` dan `.spec.selector` yang wajib d
`.spec.template` adalah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#templat-pod). Dia memiliki skema yang sama dengan [Pod](/id/docs/concepts/workloads/pods/pod/). Bedanya dia bersarang dan tidak punya `apiVersion` atau `kind`.
-Selain kolom wajib untuk Pod, templat Pod pada Deployment harus menentukan label dan aturan menjalankan ulang yang tepat.
+Selain kolom wajib untuk Pod, templat Pod pada Deployment harus menentukan label dan aturan menjalankan ulang yang tepat.
Untuk label, pastikaan tidak bertumpang tindih dengan kontroler lainnya. Lihat [selektor](#selektor)).
[`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#aturan-menjalankan-ulang) hanya boleh berisi `Always`,
@@ -1019,21 +1019,21 @@ untuk Pod yang dituju oleh Deployment ini.
`.spec.selector` harus sesuai `.spec.template.metadata.labels`, atau akan ditolak oleh API.
-Di versi API `apps/v1`, `.spec.selector` dan `.metadata.labels` tidak berisi `.spec.template.metadata.labels` jika tidak disetel.
+Di versi API `apps/v1`, `.spec.selector` dan `.metadata.labels` tidak berisi `.spec.template.metadata.labels` jika tidak disetel.
Jadi mereka harus disetel secara eksplisit. Perhatikan juga `.spec.selector` tidak dapat diubah setelah Deployment dibuat pada `apps/v1`.
Deployment dapat mematikan Pod yang labelnya cocok dengan selektor jika templatnya berbeda
-dari `.spec.template` atau total jumlah Pod melebihi `.spec.replicas`. Dia akan membuat Pod baru
+dari `.spec.template` atau total jumlah Pod melebihi `.spec.replicas`. Dia akan membuat Pod baru
dengan `.spec.template` jika jumlah Pod kurang dari yang diinginkan.
{{< note >}}
-Kamu sebaiknya tidak membuat Pod lain yang labelnya cocok dengan selektor ini, baik secara langsung,
-melalui Deployment lain, atau membuat kontroler lain seperti ReplicaSet atau ReplicationController.
-Kalau kamu melakukannya, Deployment pertama akan mengira dia yang membuat Pod-pod ini.
+Kamu sebaiknya tidak membuat Pod lain yang labelnya cocok dengan selektor ini, baik secara langsung,
+melalui Deployment lain, atau membuat kontroler lain seperti ReplicaSet atau ReplicationController.
+Kalau kamu melakukannya, Deployment pertama akan mengira dia yang membuat Pod-pod ini.
Kubernetes tidak akan mencegahmu melakukannya.
{{< /note >}}
-Jika kamu punya beberapa kontroler dengan selektor bertindihan, mereka akan saling bertikai
+Jika kamu punya beberapa kontroler dengan selektor bertindihan, mereka akan saling bertikai
dan tidak akan berjalan semestinya.
### Strategi
@@ -1047,65 +1047,65 @@ Semua Pod yang ada dimatikan sebelum yang baru dibuat ketika nilai `.spec.strate
#### Membarui Deployment secara Bergulir
-Deployment membarui Pod secara [bergulir](/id/docs/tasks/run-application/rolling-update-replication-controller/)
+Deployment membarui Pod secara bergulir
saat `.spec.strategy.type==RollingUpdate`. Kamu dapat menentukan `maxUnavailable` dan `maxSurge` untuk mengatur
proses pembaruan bergulir.
##### Ketidaktersediaan Maksimum
-`.spec.strategy.rollingUpdate.maxUnavailable` adalah kolom opsional yang mengatur jumlah Pod maksimal
-yang tidak tersedia selama proses pembaruan. Nilainya bisa berupa angka mutlak (contohnya 5)
-atau persentase dari Pod yang diinginkan (contohnya 10%). Angka mutlak dihitung berdasarkan persentase
-dengan pembulatan ke bawah. Nilai tidak bisa nol jika `.spec.strategy.rollingUpdate.maxSurge` juga nol.
+`.spec.strategy.rollingUpdate.maxUnavailable` adalah kolom opsional yang mengatur jumlah Pod maksimal
+yang tidak tersedia selama proses pembaruan. Nilainya bisa berupa angka mutlak (contohnya 5)
+atau persentase dari Pod yang diinginkan (contohnya 10%). Angka mutlak dihitung berdasarkan persentase
+dengan pembulatan ke bawah. Nilai tidak bisa nol jika `.spec.strategy.rollingUpdate.maxSurge` juga nol.
Nilai bawaannya yaitu 25%.
-Sebagai contoh, ketika nilai berisi 30%, ReplicaSet lama dapat segera diperkecil menjadi 70% dari Pod
-yang diinginkan saat pembaruan bergulir dimulai. Seketika Pod baru siap, ReplicaSet lama dapat lebih diperkecil lagi,
-diikuti dengan pembesaran ReplicaSet, menjamin total jumlah Pod yang siap kapanpun ketika pembaruan
+Sebagai contoh, ketika nilai berisi 30%, ReplicaSet lama dapat segera diperkecil menjadi 70% dari Pod
+yang diinginkan saat pembaruan bergulir dimulai. Seketika Pod baru siap, ReplicaSet lama dapat lebih diperkecil lagi,
+diikuti dengan pembesaran ReplicaSet, menjamin total jumlah Pod yang siap kapanpun ketika pembaruan
paling sedikit 70% dari Pod yang diinginkan.
##### Kelebihan Maksimum
-`.spec.strategy.rollingUpdate.maxSurge` adalah kolom opsional yang mengatur jumlah Pod maksimal yang
-dapat dibuat melebihi jumlah Pod yang diinginkan. Nilainya bisa berupa angka mutlak (contohnya 5) atau persentase
-dari Pod yang diinginkan (contohnya 10%). Nilai tidak bisa nol jika `MaxUnavailable` juga nol. Angka mutlak
+`.spec.strategy.rollingUpdate.maxSurge` adalah kolom opsional yang mengatur jumlah Pod maksimal yang
+dapat dibuat melebihi jumlah Pod yang diinginkan. Nilainya bisa berupa angka mutlak (contohnya 5) atau persentase
+dari Pod yang diinginkan (contohnya 10%). Nilai tidak bisa nol jika `MaxUnavailable` juga nol. Angka mutlak
dihitung berdasarkan persentase dengan pembulatan ke bawah. Nilai bawaannya yaitu 25%.
-Sebagai contoh, ketika nilai berisi 30%, ReplicaSet baru dapat segera diperbesar saat pembaruan bergulir dimulai,
-sehingga total jumlah Pod yang baru dan lama tidak melebihi 130% dari Pod yang diinginkan.
-Saat Pod lama dimatikan, ReplicaSet baru dapat lebih diperbesar lagi, menjamin total jumlah Pod yang siap
+Sebagai contoh, ketika nilai berisi 30%, ReplicaSet baru dapat segera diperbesar saat pembaruan bergulir dimulai,
+sehingga total jumlah Pod yang baru dan lama tidak melebihi 130% dari Pod yang diinginkan.
+Saat Pod lama dimatikan, ReplicaSet baru dapat lebih diperbesar lagi, menjamin total jumlah Pod yang siap
kapanpun ketika pembaruan paling banyak 130% dari Pod yang diinginkan.
### Tenggat Kemajuan dalam Detik
-`.spec.progressDeadlineSeconds` adalah kolom opsional yang mengatur lama tunggu dalam dalam detik untuk Deployment-mu berjalan
-sebelum sistem melaporkan lagi bahwa Deployment [gagal](#deployment-gagal) - ditunjukkan dengan kondisi `Type=Progressing`, `Status=False`,
-dan `Reason=ProgressDeadlineExceeded` pada status sumber daya. Controller Deployment akan tetap mencoba ulang Deployment.
-Nantinya begitu pengembalian otomatis diimplementasikan, kontroler Deployment akan membalikkan Deployment segera
+`.spec.progressDeadlineSeconds` adalah kolom opsional yang mengatur lama tunggu dalam dalam detik untuk Deployment-mu berjalan
+sebelum sistem melaporkan lagi bahwa Deployment [gagal](#deployment-gagal) - ditunjukkan dengan kondisi `Type=Progressing`, `Status=False`,
+dan `Reason=ProgressDeadlineExceeded` pada status sumber daya. Controller Deployment akan tetap mencoba ulang Deployment.
+Nantinya begitu pengembalian otomatis diimplementasikan, kontroler Deployment akan membalikkan Deployment segera
saat dia menjumpai kondisi tersebut.
Jika ditentukan, kolom ini harus lebih besar dari `.spec.minReadySeconds`.
### Lama Minimum untuk Siap dalam Detik
-`.spec.minReadySeconds` adalah kolom opsional yang mengatur lama minimal sebuah Pod yang baru dibuat
+`.spec.minReadySeconds` adalah kolom opsional yang mengatur lama minimal sebuah Pod yang baru dibuat
seharusnya siap tanpa ada kontainer yang rusak, untuk dianggap tersedia, dalam detik.
-Nilai bawaannya yaitu 0 (Pod akan dianggap tersedia segera ketika siap). Untuk mempelajari lebih lanjut
+Nilai bawaannya yaitu 0 (Pod akan dianggap tersedia segera ketika siap). Untuk mempelajari lebih lanjut
kapan Pod dianggap siap, lihat [Pemeriksaan Kontainer](/id/docs/concepts/workloads/pods/pod-lifecycle/#pemeriksaan-kontainer).
### Kembali Ke
-Kolom `.spec.rollbackTo` telah ditinggalkan pada versi API `extensions/v1beta1` dan `apps/v1beta1`, dan sudah tidak didukung mulai versi API `apps/v1beta2`.
+Kolom `.spec.rollbackTo` telah ditinggalkan pada versi API `extensions/v1beta1` dan `apps/v1beta1`, dan sudah tidak didukung mulai versi API `apps/v1beta2`.
Sebagai gantinya, disarankan untuk menggunakan `kubectl rollout undo` sebagaimana diperkenalkan dalam [Kembali ke Revisi Sebelumnya](#kembali-ke-revisi-sebelumnya).
### Batas Riwayat Revisi
Riwayat revisi Deployment disimpan dalam ReplicaSet yang dia kendalikan.
-`.spec.revisionHistoryLimit` adalah kolom opsional yang mengatur jumlah ReplicaSet lama yang dipertahankan
-untuk memungkinkan pengembalian. ReplicaSet lama ini mengambil sumber daya dari `etcd` dan memunculkan keluaran
-dari `kubectl get rs`. Konfigurasi tiap revisi Deployment disimpan pada ReplicaSet-nya; sehingga, begitu ReplicaSet lama dihapus,
-kamu tidak mampu lagi membalikkan revisi Deployment-nya. Umumnya, 10 ReplicaSet lama akan dipertahankan,
+`.spec.revisionHistoryLimit` adalah kolom opsional yang mengatur jumlah ReplicaSet lama yang dipertahankan
+untuk memungkinkan pengembalian. ReplicaSet lama ini mengambil sumber daya dari `etcd` dan memunculkan keluaran
+dari `kubectl get rs`. Konfigurasi tiap revisi Deployment disimpan pada ReplicaSet-nya; sehingga, begitu ReplicaSet lama dihapus,
+kamu tidak mampu lagi membalikkan revisi Deployment-nya. Umumnya, 10 ReplicaSet lama akan dipertahankan,
namun nilai idealnya tergantung pada frekuensi dan stabilitas Deployment-deployment baru.
Lebih spesifik, mengisi kolom dengan nol berarti semua ReplicaSet lama dengan 0 replika akan dibersihkan.
@@ -1114,7 +1114,7 @@ Dalam kasus ini, rilis Deployment baru tidak dapat dibalikkan, sebab riwayat rev
### Terjeda
`.spec.paused` adalah kolom boolean opsional untuk menjeda dan melanjutkan Deployment. Perbedaan antara Deployment yang terjeda
-dan yang tidak hanyalah perubahan apapun pada PodTemplateSpec Deployment terjeda tidak akan memicu rilis baru selama masih terjeda.
+dan yang tidak hanyalah perubahan apapun pada PodTemplateSpec Deployment terjeda tidak akan memicu rilis baru selama masih terjeda.
Deployment umumnya tidak terjeda saat dibuat.
## Alternatif untuk Deployment
@@ -1122,7 +1122,6 @@ Deployment umumnya tidak terjeda saat dibuat.
### kubectl rolling update
[`kubectl rolling update`](/id/docs/reference/generated/kubectl/kubectl-commands#rolling-update) membarui Pod dan ReplicationController
-dengan cara yang serupa. Namun, Deployments lebih disarankan karena deklaratif, berjalan di sisi server, dan punya fitur tambahan,
+dengan cara yang serupa. Namun, Deployments lebih disarankan karena deklaratif, berjalan di sisi server, dan punya fitur tambahan,
seperti pembalikkan ke revisi manapun sebelumnya bahkan setelah pembaruan rolling selesais.
-
diff --git a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
index 4aca03535f..5f4720646b 100644
--- a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+++ b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md
@@ -119,14 +119,14 @@ Sebuah Job juga membutuhkan sebuah [bagian `.spec`](https://git.k8s.io/community
_Field_ `.spec.template` merupakan satu-satunya _field_ wajib pada `.spec`.
-_Field_ `.spec.template` merupakan sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
+_Field_ `.spec.template` merupakan sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
kecuali _field_ ini bersifat _nested_ dan tidak memiliki _field_ `apiVersion` atau _field_ `kind`.
Sebagai tambahan dari _field_ wajib pada sebuah Job, sebuah tempat pod pada Job
haruslah menspesifikasikan label yang sesuai (perhatikan [selektor pod](#pod-selektor))
dan sebuah mekanisme _restart_ yang sesuai.
-Hanya sebuah [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
+Hanya sebuah [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
### Selektor Pod
@@ -194,7 +194,7 @@ Jika hal ini terjadi, dan `.spec.template.spec.restartPolicy = "OnFailure"`, mak
akan tetap ada di dalam node, tetapi Container tersebut akan dijalankan kembali. Dengan demikian,
program kamu harus dapat mengatasi kasus dimana program tersebut di-_restart_ secara lokal, atau jika
tidak maka spesifikasikan `.spec.template.spec.restartPolicy = "Never"`. Perhatikan
-[_lifecycle_ pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
+[_lifecycle_ pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
Sebuah Pod juga dapat gagal secara menyeluruh, untuk beberapa alasan yang mungkin, misalnya saja,
ketika Pod tersebut dipindahkan dari Node (ketika Node diperbarui, di-_restart_, dihapus, dsb.), atau
@@ -288,7 +288,7 @@ Pastikan kamu telah menspesifikasikan nilai tersebut pada level yang dibutuhkan.
Job yang sudah selesai biasanya tidak lagi dibutuhkan di dalam sistem. Tetap menjaga keberadaan
objek-objek tersebut di dalam sistem akan memberikan tekanan tambahan pada API server. Jika sebuah Job
yang diatur secara langsung oleh _controller_ dengan level yang lebih tinggi, seperti
-[CronJob](/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
+[CronJob](/id/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesifikasikan.
### Mekanisme TTL untuk Job yang Telah Selesai Dijalankan
@@ -298,7 +298,7 @@ di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesif
Salah satu cara untuk melakukan _clean up_ Job yang telah selesai dijalankan
(baik dengan status `Complete` atau `Failed`) secara otomatis adalah dengan
menerapkan mekanisme TTL yang disediakan oleh
-[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
+[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
sumber daya yang telah selesai digunakan, dengan cara menspesifikasikan
_field_ `.spec.ttlSecondsAfterFinished` dari Job tersebut.
@@ -334,7 +334,7 @@ maka Job ini tidak akan dihapus oleh _controller_ TTL setelah Job ini selesai di
Perhatikan bahwa mekanisme TTL ini merupakan fitur alpha, dengan gerbang fitur `TTLAfterFinished`.
Untuk informasi lebih lanjut, kamu dapat membaca dokumentasi untuk
-[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
+[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
sumber daya yang telah selesai dijalankan.
## Pola Job
@@ -478,7 +478,7 @@ Job merupakan komplemen dari [Replication Controller](/docs/user-guide/replicati
Sebuah Replication Controller mengatur Pod yang diharapkan untuk tidak dihentikan (misalnya, _web server_), dan sebuah Job
mengatur Pod yang diharapkan untuk berhenti (misalnya, _batch task_).
-Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
+Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
digunakan untuk Pod dengan `RestartPolicy` yang sama dengan `OnFailure` atau `Never`.
(Perhatikan bahwa: Jika `RestartPolicy` tidak dispesifikasikan, nilai defaultnya adalah `Always`.)
@@ -499,7 +499,7 @@ dari sebuah Job, tetapi kontrol secara mutlak atas Pod yang dibuat serta tugas y
## CronJob {#cron-jobs}
-Kamu dapat menggunakan [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
+Kamu dapat menggunakan [`CronJob`](/id/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
dijalankan pada waktu/tanggal yang spesifik, mirip dengan perangkat lunak `cron` yang ada pada Unix.
diff --git a/content/id/docs/concepts/workloads/controllers/replicaset.md b/content/id/docs/concepts/workloads/controllers/replicaset.md
index c0c3a83d51..57b1124208 100644
--- a/content/id/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/id/docs/concepts/workloads/controllers/replicaset.md
@@ -197,7 +197,7 @@ Untuk _field_ [_restart policy_](/docs/concepts/workloads/Pods/pod-lifecycle/#re
### Selektor Pod
-_Field_ `.spec.selector` adalah sebuah [selektor labe](/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
+_Field_ `.spec.selector` adalah sebuah [selektor labe](/id/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
```shell
matchLabels:
tier: frontend
@@ -219,7 +219,7 @@ Jika nilai `.spec.replicas` tidak ditentukan maka akan diatur ke nilai _default_
### Menghapus ReplicaSet dan Pod-nya
-Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
+Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/id/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
Ketika menggunakan REST API atau _library_ `client-go`, kamu harus mengatur nilai `propagationPolicy` menjadi `Background` atau `Foreground` pada opsi -d.
Sebagai contoh:
@@ -243,7 +243,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
```
Ketika ReplicaSet yang asli telah dihapus, kamu dapat membuat ReplicaSet baru untuk menggantikannya. Selama _field_ `.spec.selector` yang lama dan baru memilki nilai yang sama, maka ReplicaSet baru akan mengadopsi Pod lama namun tidak serta merta membuat Pod yang sudah ada sama dan sesuai dengan templat Pod yang baru.
-Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
+Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/id/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
### Mengisolasi Pod dari ReplicaSet
@@ -275,7 +275,7 @@ kubectl autoscale rs frontend --max=10
### Deployment (direkomendasikan)
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
Walaupun ReplicaSet dapat digunakan secara independen, seringkali ReplicaSet digunakan oleh Deployments sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan dan pembaruan Pod. Ketika kamu menggunakan Deployments kamu tidak perlu khawatir akan pengaturan dari ReplicaSet yang dibuat. Deployments memiliki dan mengatur ReplicaSet-nya sendiri.
Maka dari itu penggunaan Deployments direkomendasikan jika kamu menginginkan ReplicaSet.
@@ -289,9 +289,9 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) alih-al
### DaemonSet
-Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
+Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
### ReplicationController
-ReplicaSet adalah suksesor dari [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
+ReplicaSet adalah suksesor dari [_ReplicationControllers_](/id/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
diff --git a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
index f828ff9c64..48ec718a6d 100644
--- a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -13,7 +13,7 @@ weight: 20
{{< note >}}
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
{{< /note >}}
Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia.
@@ -101,7 +101,7 @@ Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan y
Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`.
-Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/).
+Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/id/docs/concepts/overview/working-with-objects/object-management/).
Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -109,11 +109,11 @@ Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.i
`.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`.
-`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
+`.spec.template` adalah sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod).
-Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
+Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker.
@@ -123,7 +123,7 @@ ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Bia
### Selektor Pod
-_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
+_Field_ `.spec.selector` adalah sebuah [selektor label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`.
@@ -216,13 +216,13 @@ ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubern
### ReplicaSet
-[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
+[`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/id/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali.
### Deployment (Direkomendasikan)
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
+[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
### Pod sederhana
@@ -234,7 +234,7 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai
### DaemonSet
-Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
+Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
## Informasi lanjutan
diff --git a/content/id/docs/concepts/workloads/controllers/statefulset.md b/content/id/docs/concepts/workloads/controllers/statefulset.md
index 9d12de91dd..aa99acd6e6 100644
--- a/content/id/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/id/docs/concepts/workloads/controllers/statefulset.md
@@ -31,8 +31,8 @@ Stabil dalam poin-poin di atas memiliki arti yang sama dengan persisten pada
Pod saat dilakukan _(re)scheduling_. Jika suatu aplikasi tidak membutuhkan
identitas yang stabil atau _deployment_ yang memiliki urutan, penghapusan, atau
mekanisme _scaling_, kamu harus melakukan _deploy_ aplikasi dengan _controller_ yang menyediakan
-replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads/controllers/deployment/) atau
-[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
+replika _stateless_. _Controller_ seperti [Deployment](/id/docs/concepts/workloads/controllers/deployment/) atau
+[ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
## Keterbatasan
@@ -40,7 +40,7 @@ replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads
pada Kubernetes rilis sebelum versi 1.5.
* Penyimpanan untuk sebuah Pod harus terlebih dahulu di-_provision_ dengan menggunakan sebuah [Provisioner PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) berdasarkan `storage class` yang dispesifikasikan, atau sudah ditentukan sebelumnya oleh administrator.
* Menghapus dan/atau _scaling_ sebuah StatefulSet *tidak akan* menghapus volume yang berkaitan dengan StatefulSet tersebut. Hal ini dilakukan untuk menjamin data yang disimpan, yang secara umum dinilai lebih berhaga dibandingkan dengan mekanisme penghapusan data secara otomatis pada sumber daya terkait.
-* StatefulSet saat ini membutuhkan sebuah [Headless Service](/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
+* StatefulSet saat ini membutuhkan sebuah [Headless Service](/id/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
* StatefulSet tidak menjamin terminasi Pod ketika sebuah StatefulSet dihapus. Untuk mendapatkan terminasi Pod yang terurut dan _graceful_ pada StatefulSet, kita dapat melakukan _scale down_ Pod ke 0 sebelum penghapusan.
* Ketika menggunakan [Rolling Update](#mekanisme-strategi-update-rolling-update) dengan
[Kebijakan Manajemen Pod](#kebijakan-manajemen-pod) (`OrderedReady`) secara default,
@@ -52,7 +52,7 @@ Contoh di bawah ini akna menunjukkan komponen-komponen penyusun StatefulSet.
* Sebuah Service Headless, dengan nama nginx, digunakan untuk mengontrol domain jaringan.
* StatefulSet, dengan nama web, memiliki Spek yang mengindikasikan terdapat 3 replika Container yang akan dihidupkan pada Pod yang unik.
-* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
+* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
```yaml
apiVersion: v1
@@ -124,7 +124,7 @@ Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama Satetul
serta ordinal Pod tersebut. Pola pada _hostname_ yang terbentuk adalah
`$(statefulset name)-$(ordinal)`. Contoh di atas akan menghasilkan tiga Pod
dengan nama `web-0,web-1,web-2`.
-Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services)
+Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format:
`$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan
domain klaster.
@@ -133,7 +133,7 @@ Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendi
_field_ `serviceName` pada StatefulSet.
Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah yang bertanggung jawab
-untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services)
+untuk membuat [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
yang bertanggung jawab terhadap identitas jaringan pada Pod.
Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service,
@@ -147,12 +147,12 @@ Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet
{{< note >}}
Domain klaster akan diatur menjadi `cluster.local` kecuali
-[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/).
+[nilainya dikonfigurasi](/id/docs/concepts/services-networking/dns-pod-service/).
{{< /note >}}
### Penyimpanan Stabil
-Kubernetes membuat sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) untuk setiap
+Kubernetes membuat sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) untuk setiap
VolumeClaimTemplate. Pada contoh nginx di atas, setiap Pod akan menerima sebuah PersistentVolume
dengan StorageClass `my-storage-class` dan penyimpanan senilai 1 Gib yang sudah di-_provisioning_. Jika tidak ada StorageClass
yang dispesifikasikan, maka StorageClass _default_ akan digunakan. Ketika sebuah Pod dilakukan _(re)schedule_
diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
index f2c232faf2..0e1b36ccc5 100644
--- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -10,7 +10,7 @@ weight: 65
Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu
objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani
-[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/),
+[Jobs](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/),
dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan
misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya.
@@ -32,7 +32,7 @@ Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster
dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik
`Complete` atau `Failed`) secara otomatis dengan menentukan _field_
`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di
-[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
+[contoh](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila
TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini
dilakukan secara berantai, dimana sumber daya lain yang
@@ -83,7 +83,7 @@ Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selai
## {{% heading "whatsnext" %}}
-[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[Membersikan Job secara Otomatis](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
diff --git a/content/id/docs/concepts/workloads/pods/disruptions.md b/content/id/docs/concepts/workloads/pods/disruptions.md
index 1adde6c949..7a09eed3a5 100644
--- a/content/id/docs/concepts/workloads/pods/disruptions.md
+++ b/content/id/docs/concepts/workloads/pods/disruptions.md
@@ -79,7 +79,7 @@ Jumlah Pod yang "diharapkan" dihitung dari `.spec.replicas` dari pengendali Pod
PDB tidak dapat mencegah [disrupsi yang tidak disengaja](#disrupsi-yang-disengaja-dan-tidak-disengaja), tapi disrupsi ini akan dihitung terhadap bujet PDB.
-Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
+Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/id/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).)
Saat sebuah Pod diusir menggunakan _eviction API_, Pod tersebut akan dihapus secara _graceful_ (lihat `terminationGracePeriodSeconds` pada [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#Podspec-v1-core).))
diff --git a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
index 45154caf25..e952bdd19b 100644
--- a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -80,7 +80,7 @@ pun, sehingga sulit untuk memecahkan masalah _image distroless_ dengan
menggunakan `kubectl exec` saja.
Saat menggunakan kontainer sementara, akan sangat membantu untuk mengaktifkan
-[_process namespace sharing_](/docs/tasks/configure-pod-container/share-process-namespace/)
+[_process namespace sharing_](/id/docs/tasks/configure-pod-container/share-process-namespace/)
sehingga kamu dapat melihat proses pada kontainer lain.
### Contoh
diff --git a/content/id/docs/concepts/workloads/pods/init-containers.md b/content/id/docs/concepts/workloads/pods/init-containers.md
index 91807fdaf6..9cd208fbc8 100644
--- a/content/id/docs/concepts/workloads/pods/init-containers.md
+++ b/content/id/docs/concepts/workloads/pods/init-containers.md
@@ -14,7 +14,7 @@ Fitur ini telah keluar dari trek Beta sejak versi 1.6. Init Container dapat disp
## Memahami Init Container
-Sebuah [Pod](/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.
+Sebuah [Pod](/id/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.
Init Container sama saja seperti Container biasa, kecuali:
@@ -59,7 +59,7 @@ Berikut beberapa contoh kasus penggunaan Init Container:
* Mengklon sebuah _git repository_ ke dalam sebuah _volume_.
* Menaruh nilai-nilai tertentu ke dalam sebuah _file_ konfigurasi dan menjalankan peralatan _template_ untuk membuat _file_ konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja.
-Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
+Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/).
### Menggunakan Init Container
diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
index 8dac6706a7..fdb3e7b71c 100644
--- a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -52,7 +52,7 @@ Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions]
* `PodScheduled`: Pod telah dijadwalkan masuk ke node;
* `Ready`: Pod sudah mampu menerima _request_ masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama;
- * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
+ * `Initialized`: Semua [init containers](/id/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna.
* `Unschedulable`: _scheduler_ belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan _resources_ atau ada batasan-batasan lain.
* `ContainersReady`: Semua kontainer di dalam Pod telah siap.
@@ -191,7 +191,7 @@ status:
...
```
-Kondisi Pod yang baru harus memenuhi [format label](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes.
+Kondisi Pod yang baru harus memenuhi [format label](/id/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes.
Sejak perintah `kubectl patch` belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi `PATCH` dengan menggunakan
salah satu dari [KubeClient _libraries_](/docs/reference/using-api/client-libraries/).
@@ -232,13 +232,13 @@ Tiga tipe pengontrol yang tersedia yaitu:
sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang
bernilai OnFailure atau Never.
-- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
- [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau
- [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
+- Menggunakan sebuah [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/),
+ [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau
+ [Deployment](/id/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir,
sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy`
yang bernilai Always.
-- Menggunakan sebuah [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan
+- Menggunakan sebuah [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan
hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin.
@@ -346,7 +346,7 @@ spec:
* Dapatkan pengalaman langsung mengenai
[pengaturan _liveness_ dan _readiness probes_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
-* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/docs/concepts/containers/container-lifecycle-hooks/).
+* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/).
diff --git a/content/id/docs/concepts/workloads/pods/pod-overview.md b/content/id/docs/concepts/workloads/pods/pod-overview.md
index 0e9593e0d1..f427358999 100644
--- a/content/id/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/id/docs/concepts/workloads/pods/pod-overview.md
@@ -47,7 +47,7 @@ Setiap *Pod* diberikan sebuah alamat *IP* unik. Setiap kontainer di dalam *Pod*
#### Penyimpanan
-*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*.
+*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/id/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*.
## Bekerja dengan Pod
@@ -66,16 +66,16 @@ Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replika
Beberapa contoh kontroler yang berisi satu atau lebih *Pod* meliputi:
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
+* [Deployment](/id/docs/concepts/workloads/controllers/deployment/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/)
Secara umum, kontroler menggunakan templat *Pod* yang kamu sediakan untuk membuat *Pod*.
## Templat Pod
Templat *Pod* adalah spesifikasi dari *Pod* yang termasuk di dalam objek lain seperti
-[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*.
+[Replication Controllers](/id/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/id/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*.
Contoh di bawah merupakan manifestasi sederhana untuk *Pod* yang berisi kontainer yang membuat sebuah pesan.
@@ -102,6 +102,6 @@ Perubahan yang terjadi pada templat atau berganti ke templat yang baru tidak mem
## {{% heading "whatsnext" %}}
* Pelajari lebih lanjut tentang perilaku *Pod*:
- * [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)
- * [Lifecycle Pod](/docs/concepts/workloads/pods/pod-lifecycle/)
+ * [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods)
+ * [Lifecycle Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/)
diff --git a/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
new file mode 100644
index 0000000000..f1d970a473
--- /dev/null
+++ b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -0,0 +1,290 @@
+---
+title: Batasan Persebaran Topologi Pod
+content_type: concept
+weight: 50
+---
+
+
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+Kamu dapat menggunakan batasan perseberan topologi (_topology spread constraints_)
+untuk mengatur bagaimana {{< glossary_tooltip text="Pod" term_id="Pod" >}} akan disebarkan
+pada klaster yang ditetapkan sebagai _failure-domains_, seperti wilayah, zona, Node dan domain
+topologi yang ditentukan oleh pengguna. Ini akan membantu untuk mencapai ketersediaan yang tinggi
+dan juga penggunaan sumber daya yang efisien.
+
+
+
+
+
+## Persyaratan
+
+### Mengaktifkan Gerbang Fitur
+
+[Gerbang fitur (_feature gate_)](/docs/reference/command-line-tools-reference/feature-gates/)
+`EvenPodsSpread` harus diaktifkan untuk
+{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **dan**
+{{< glossary_tooltip text="penjadwal (_scheduler_)" term_id="kube-scheduler" >}}.
+
+### Label Node
+
+Batasan persebaran topologi bergantung dengan label pada Node untuk menentukan
+domain topologi yang memenuhi untuk semua Node. Misalnya saja, sebuah Node bisa memiliki
+label sebagai berikut: `node=node1,zone=us-east-1a,region=us-east-1`
+
+Misalkan kamu memiliki klaster dengan 4 Node dengan label sebagai berikut:
+
+```
+NAME STATUS ROLES AGE VERSION LABELS
+node1 Ready
+
+Most people who are familiar with Kubernetes are probably used to associating it with Linux. The connection makes sense, since Kubernetes ran on Linux from its very beginning. However, many teams and organizations working on adopting Kubernetes need the ability to orchestrate containers on Windows. Since the release of Docker and rise to popularity of containers, there have been efforts both from the community and from Microsoft itself to make container technology as accessible in Windows systems as it is in Linux systems.
+
+Within the Kubernetes community, those who are passionate about making Kubernetes accessible to the Windows community can find a home in the Windows Special Interest Group. To learn more about SIG-Windows and the future of Kubernetes on Windows, I spoke to co-chairs [Mark Rossetti](https://github.com/marosset) and [Michael Michael](https://github.com/michmike) about the SIG's goals and how others can contribute.
+
+## Intro to Windows Containers & Kubernetes
+
+Kubernetes is the most popular tool for orchestrating container workloads, so to understand the Windows Special Interest Group (SIG) within the Kubernetes project, it's important to first understand what we mean when we talk about running containers on Windows.
+
+***
+_"When looking at Windows support in Kubernetes," says SIG (Special Interest Group) Co-chairs Mark Rossetti and Michael Michael, "many start drawing comparisons to Linux containers. Although some of the comparisons that highlight limitations are fair, it is important to distinguish between operational limitations and differences between the Windows and Linux operating systems. Windows containers run the Windows operating system and Linux containers run Linux."_
+***
+
+In essence, any "container" is simply a process being run on its host operating system, with some key tooling in place to isolate that process and its dependencies from the rest of the environment. The goal is to make that running process safely isolated, while taking up minimal resources from the system to perform that isolation. On Linux, the tooling used to isolate processes to create "containers" commonly boils down to cgroups and namespaces (among a few others), which are themselves tools built in to the Linux Kernel.
+
+
+
+#### _If dogs were processes: containerization would be like giving each dog their own resources like toys and food using cgroups, and isolating troublesome dogs using namespaces._
+
+
+Native Windows processes are processes that are or must be run on a Windows operating system. This makes them fundamentally different from a process running on a Linux operating system. Since Linux containers are Linux processes being isolated by the Linux kernel tools known as cgroups and namespaces, containerizing native Windows processes meant implementing similar isolation tools within the Windows kernel itself. Thus, "Windows Containers" and "Linux Containers" are fundamentally different technologies, even though they have the same goals (isolating processes) and in some ways work similarly (using kernel level containerization).
+
+So when it comes to running containers on Windows, there are actually two very important concepts to consider:
+
+* Native Windows processes running as native Windows Server style containers,
+* and traditional Linux containers running on a Linux Kernel, generally hosted on a lightweight Hyper-V Virtual Machine.
+
+You can learn more about Linux and Windows containers in this [tutorial](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers) from Microsoft.
+
+
+
+### Kubernetes on Windows
+
+Kubernetes was initially designed with Linux containers in mind and was itself designed to run on Linux systems. Because of that, much of the functionality of Kubernetes involves unique Linux functionality. The Linux-specific work is intentional--we all want Kubernetes to run optimally on Linux--but there is a growing demand for similar optimization for Windows servers. For cases where users need container orchestration on Windows, the Kubernetes contributor community of SIG-Windows has incorporated functionality for Windows-specific use cases.
+
+***
+_"A common question we get is, will I be able to have a Windows-only cluster. The answer is NO. Kubernetes control plane components will continue to be based on Linux, while SIG-Windows is concentrating on the experience of having Windows worker nodes in a Kubernetes cluster."_
+***
+
+Rather than separating out the concepts of "Windows Kubernetes," and "Linux Kubernetes," the community of SIG-Windows works toward adding functionality to the main Kubernetes project which allows it to handle use cases for Windows. These Windows capabilities mirror, and in some cases add unique functionality to, the Linux use cases Kubernetes has served since its release in 2014 (want to learn more history? Scroll through this [original design document](https://github.com/kubernetes/kubernetes/blob/e2b948dbfbba62b8cb681189377157deee93bb43/DESIGN.md).
+
+
+## What Does SIG-Windows Do?
+
+***
+_"SIG-Windows is really the center for all things Windows in Kubernetes,"_ SIG chairs Mark and Michael said, _"We mainly focus on the compute side of things, but really anything related to running Kubernetes on Windows is in scope for SIG-Windows."_
+***
+
+In order to best serve users, SIG-Windows works to make the Kubernetes user experience as consistent as possible for users of Windows and Linux. However some use cases simply only apply to one Operating System, and as such, the SIG-Windows group also works to create functionality that is unique to Windows-only workloads.
+
+Many SIGs, or "Special Interest Groups" within Kubernetes have a narrow focus, allowing members to dive deep on a certain facet of the technology. While specific expertise is welcome, those interested in SIG-Windows will find it to be a great community to build broad understanding across many focus areas of Kubernetes. "Members from our SIG interface with storage, network, testing, cluster-lifecycle and others groups in Kubernetes."
+
+### Who are SIG-Windows' Users?
+The best way to understand the technology a group makes, is often to understand who their customers or users are.
+
+
+
+#### "A majority of the users we've interacted with have business-critical infrastructure running on Windows developed over many years and can't move those workloads to Linux for various reasons (cost, time, compliance, etc)," the SIG chairs shared. "By transporting those workloads into Windows containers and running them in Kubernetes they are able to quickly modernize their infrastructure and help migrate it to the cloud."
+
+As anyone in the Kubernetes space can attest, companies around the world, in many different industries, see Kubernetes as their path to modernizing their infrastructure. Often this involves re-architecting or event totally re-inventing many of the ways they've been doing business. With the goal being to make their systems more scalable, more robust, and more ready for anything the future may bring. But not every application or workload can or should change the core operating system it runs on, so many teams need the ability to run containers at scale on Windows, or Linux, or both.
+
+"Sometimes the driver to Windows containers is a modernization effort and sometimes it’s because of expiring hardware warranties or end-of-support cycles for the current operating system. Our efforts in SIG-Windows enable Windows developers to take advantage of cloud native tools and Kubernetes to build and deploy distributed applications faster. That’s exciting! In essence, users can retain the benefits of application availability while decreasing costs."
+
+## Who are SIG-Windows?
+
+Who are these contributors working on enabling Windows workloads for Kubernetes? It could be you!
+
+Like with other Kubernetes SIGs, contributors to SIG-Windows can be anyone from independent hobbyists to professionals who work at many different companies. They come from many different parts of the world and bring to the table many different skill sets.
+
+
+
+_"Like most other Kubernetes SIGs, we are a very welcome and open community," explained the SIG co-chairs Michael Michael and Mark Rosetti._
+
+
+### Becoming a contributor
+
+For anyone interested in getting started, the co-chairs added, "New contributors can view old community meetings on GitHub (we record every single meeting going back three years), read our documentation, attend new community meetings, ask questions in person or on Slack, and file some issues on Github. We also attend all KubeCon conferences and host 1-2 sessions, a contributor session, and meet-the-maintainer office hours."
+
+The co-chairs also shared a glimpse into what the path looks like to becoming a member of the SIG-Windows community:
+
+"We encourage new contributors to initially just join our community and listen, then start asking some questions and get educated on Windows in Kubernetes. As they feel comfortable, they could graduate to improving our documentation, file some bugs/issues, and eventually they can be a code contributor by fixing some bugs. If they have long-term and sustained substantial contributions to Windows, they could become a technical lead or a chair of SIG-Windows. You won't know if you love this area unless you get started :) To get started, [visit this getting-started page](https://github.com/kubernetes/community/tree/master/sig-windows). It's a one stop shop with links to everything related to SIG-Windows in Kubernetes."
+
+When asked if there were any useful skills for new contributors, the co-chairs said,
+
+"We are always looking for expertise in Go and Networking and Storage, along with a passion for Windows. Those are huge skills to have. However, we don’t require such skills, and we welcome any and all contributors, with varying skill sets. If you don’t know something, we will help you acquire it."
+
+You can get in touch with the folks at SIG-Windows in their [Slack channel](https://kubernetes.slack.com/archives/C0SJ4AFB7) or attend one of their regular meetings - currently 30min long on Tuesdays at 12:30PM EST! You can find links to their regular meetings as well as past meeting notes and recordings from the [SIG-Windows README](https://github.com/kubernetes/community/tree/master/sig-windows#readme) on GitHub.
+
+As a closing message from SIG-Windows:
+
+***
+#### _"We welcome you to get involved and join our community to share feedback and deployment stories, and contribute to code, docs, and improvements of any kind."_
+***
diff --git a/content/en/case-studies/OWNERS b/content/en/case-studies/OWNERS
deleted file mode 100644
index e4131d339e..0000000000
--- a/content/en/case-studies/OWNERS
+++ /dev/null
@@ -1,10 +0,0 @@
-# See the OWNERS docs at https://go.k8s.io/owners
-
-# Owned by Kubernetes Blog reviewers.
-options:
- no_parent_owners: false
-reviewers:
- - alexcontini
-approvers:
- - alexcontini
- - sarahkconway
diff --git a/content/en/case-studies/adform/index.html b/content/en/case-studies/adform/index.html
index e9a8acc7a2..be35a2d837 100644
--- a/content/en/case-studies/adform/index.html
+++ b/content/en/case-studies/adform/index.html
@@ -12,7 +12,7 @@ quote: >
Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier.
---
-
+
+
+
+
+## Extension Points
+
+This diagram shows the extension points in a Kubernetes system.
+
+
+
+
+
+1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
+2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
+3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
+4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
+5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
+6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
+7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
+
+If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
+
+
+
+
+
+
+## API Extensions
+### User-Defined Types
+
+Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
+
+Do not use a Custom Resource as data storage for application, user, or monitoring data.
+
+For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/).
+
+
+### Combining New APIs with Automation
+
+The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies.
+
+### Changing Built-in Resources
+
+When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups.
+Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do.
+
+
+### API Access Extensions
+
+When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
+
+Each of these steps offers extension points.
+
+Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
+
+### Authentication
+
+[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
+
+Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
+
+
+### Authorization
+
+[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
+
+
+### Dynamic Admission Control
+
+After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
+
+* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
+* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
+
+## Infrastructure Extensions
+
+
+### Storage Plugins
+
+[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
+) allow users to mount volume types without built-in support by having the
+Kubelet call a Binary Plugin to mount the volume.
+
+
+### Device Plugins
+
+Device plugins allow a node to discover new Node resources (in addition to the
+builtin ones like cpu and memory) via a [Device
+Plugin](/docs/concepts/cluster-administration/device-plugins/).
+
+
+### Network Plugins
+
+Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/).
+
+### Scheduler Extensions
+
+The scheduler is a special type of controller that watches pods, and assigns
+pods to nodes. The default scheduler can be replaced entirely, while
+continuing to use other Kubernetes components, or [multiple
+schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
+can run at the same time.
+
+This is a significant undertaking, and almost all Kubernetes users find they
+do not need to modify the scheduler.
+
+The scheduler also supports a
+[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
+that permits a webhook backend (scheduler extension) to filter and prioritize
+the nodes chosen for a pod.
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
+* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+* Learn more about Infrastructure extensions
+ * [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)
+ * [Device Plugins](/docs/concepts/cluster-administration/device-plugins/)
+* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
+* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
+
+
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index f2ca2e2435..bd7d27305e 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -178,7 +178,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
| Feature | Description | CRDs | Aggregated API |
| ------- | ----------- | ---- | -------------- |
-| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
+| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes |
| Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes |
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index d27dddd384..7e6a648669 100644
--- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -223,7 +223,7 @@ Here are some examples of device plugin implementations:
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
-* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
+* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices
## {{% heading "whatsnext" %}}
@@ -232,6 +232,6 @@ Here are some examples of device plugin implementations:
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
-* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
+* Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/)
diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
index 7914b1cab5..bc06bd4ab0 100644
--- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -50,7 +50,7 @@ Extensions are software components that extend and deeply integrate with Kuberne
They adapt it to support new types and new kinds of hardware.
Most cluster administrators will use a hosted or distribution
-instance of Kubernetes. As a result, most Kubernetes users will need to
+instance of Kubernetes. As a result, most Kubernetes users will not need to
install extensions and fewer will need to author new ones.
## Extension Patterns
diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
deleted file mode 100644
index 7f81439c41..0000000000
--- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Poseidon-Firmament Scheduler
-content_type: concept
-weight: 80
----
-
-
-
-{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
-
-The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler.
-
-
-
-
-
-
-## Introduction
-
-Poseidon is a service that acts as the integration glue between the [Firmament scheduler](https://github.com/Huawei-PaaS/firmament) and Kubernetes. Poseidon-Firmament augments the current Kubernetes scheduling capabilities. It incorporates novel flow network graph based scheduling capabilities alongside the default Kubernetes scheduler. The Firmament scheduler models workloads and clusters as flow networks and runs min-cost flow optimizations over these networks to make scheduling decisions.
-
-Firmament models the scheduling problem as a constraint-based optimization over a flow network graph. This is achieved by reducing scheduling to a min-cost max-flow optimization problem. The Poseidon-Firmament scheduler dynamically refines the workload placements.
-
-Poseidon-Firmament scheduler runs alongside the default Kubernetes scheduler as an alternate scheduler. You can simultaneously run multiple, different schedulers.
-
-Flow graph scheduling with the Poseidon-Firmament scheduler provides the following advantages:
-
-- Workloads (Pods) are bulk scheduled to enable scheduling at massive scale.
- The Poseidon-Firmament scheduler outperforms the Kubernetes default scheduler by a wide margin when it comes to throughput performance for scenarios where compute resource requirements are somewhat uniform across your workload (Deployments, ReplicaSets, Jobs).
-- The Poseidon-Firmament's scheduler's end-to-end throughput performance and bind time improves as the number of nodes in a cluster increases. As you scale out, Poseidon-Firmament scheduler is able to amortize more and more work across workloads.
-- Scheduling in Poseidon-Firmament is dynamic; it keeps cluster resources in a global optimal state during every scheduling run.
-- The Poseidon-Firmament scheduler supports scheduling complex rule constraints.
-
-## How the Poseidon-Firmament scheduler works
-
-Kubernetes supports [using multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/). You can specify, for a particular Pod, that it is scheduled by a custom scheduler (“poseidon” for this case), by setting the `schedulerName` field in the PodSpec at the time of pod creation. The default scheduler will ignore that Pod and allow Poseidon-Firmament scheduler to schedule the Pod on a relevant node.
-
-For example:
-
-```yaml
-apiVersion: v1
-kind: Pod
-...
-spec:
- schedulerName: poseidon
-...
-```
-
-## Batch scheduling
-
-As mentioned earlier, Poseidon-Firmament scheduler enables an extremely high throughput scheduling environment at scale due to its bulk scheduling approach versus Kubernetes pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods are uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs.
-
-Although, Poseidon-Firmament scheduler is capable of scheduling various types of workloads, such as service, batch, etc., the following are a few use cases where it excels the most:
-
-1. For “Big Data/AI” jobs consisting of large number of tasks, throughput benefits are tremendous.
-2. Service or batch jobs where workload resource requirements are uniform across jobs (Replicasets/Deployments/Jobs).
-
-## Feature state
-
-Poseidon-Firmament is designed to work with Kubernetes release 1.6 and all subsequent releases.
-
-{{< caution >}}
-Poseidon-Firmament scheduler does not provide support for high availability; its implementation assumes that the scheduler cannot fail.
-{{< /caution >}}
-
-## Feature comparison {#feature-comparison-matrix}
-
-{{< table caption="Feature comparison of Kubernetes and Poseidon-Firmament schedulers." >}}
-|Feature|Kubernetes Default Scheduler|Poseidon-Firmament Scheduler|Notes|
-|--- |--- |--- |--- |
-|Node Affinity/Anti-Affinity|Y|Y||
-|Pod Affinity/Anti-Affinity - including support for pod anti-affinity symmetry|Y|Y|The default scheduler outperforms the Poseidon-Firmament scheduler pod affinity/anti-affinity functionality.|
-|Taints & Tolerations|Y|Y||
-|Baseline Scheduling capability in accordance to available compute resources (CPU & Memory) on a node|Y|Y†|**†** Not all Predicates & Priorities are supported with Poseidon-Firmament.|
-|Extreme Throughput at scale|Y†|Y|**†** Bulk scheduling approach scales or increases workload placement. Firmament scheduler offers high throughput when resource requirements (CPU/Memory) for incoming Pods are uniform across ReplicaSets/Deployments/Jobs.|
-|Colocation Interference Avoidance|N|N||
-|Priority Preemption|Y|N†|**†** Partially exists in Poseidon-Firmament versus extensive support in Kubernetes default scheduler.|
-|Inherent Rescheduling|N|Y†|**†** Poseidon-Firmament scheduler supports workload re-scheduling. In each scheduling run, Poseidon-Firmament considers all Pods, including running Pods, and as a result can migrate or evict Pods – a globally optimal scheduling environment.|
-|Gang Scheduling|N|Y||
-|Support for Pre-bound Persistence Volume Scheduling|Y|Y||
-|Support for Local Volume & Dynamic Persistence Volume Binding Scheduling|Y|N||
-|High Availability|Y|N||
-|Real-time metrics based scheduling|N|Y†|**†** Partially supported in Poseidon-Firmament using Heapster (now deprecated) for placing Pods using actual cluster utilization statistics rather than reservations.|
-|Support for Max-Pod per node|Y|Y|Poseidon-Firmament scheduler seamlessly co-exists with Kubernetes default scheduler.|
-|Support for Ephemeral Storage, in addition to CPU/Memory|Y|Y||
-{{< /table >}}
-
-## Installation
-
-The [Poseidon-Firmament installation guide](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md#Installation) explains how to deploy Poseidon-Firmament to your cluster.
-
-## Performance comparison
-
-{{< note >}}
- Please refer to the [latest benchmark results](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md) for detailed throughput performance comparison test results between Poseidon-Firmament scheduler and the Kubernetes default scheduler.
-{{< /note >}}
-
-Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in small batches (typically one at a time). These schedulers have the following crucial drawbacks:
-
-1. The scheduler commits to a pod placement early and restricts the choices for other pods that wait to be placed.
-2. There is limited opportunities for amortizing work across pods because they are considered for placement individually.
-
-These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput.
-
-
-## {{% heading "whatsnext" %}}
-
-* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information.
-* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon.
-* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design.
-* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md).
-
diff --git a/content/en/docs/concepts/overview/_index.md b/content/en/docs/concepts/overview/_index.md
index ec86980c4b..a52c470446 100755
--- a/content/en/docs/concepts/overview/_index.md
+++ b/content/en/docs/concepts/overview/_index.md
@@ -1,4 +1,5 @@
---
title: "Overview"
weight: 20
----
\ No newline at end of file
+description: Get a high-level outline of Kubernetes and the components it is built from.
+---
diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md
index f83f00683e..53e6b84c16 100644
--- a/content/en/docs/concepts/overview/components.md
+++ b/content/en/docs/concepts/overview/components.md
@@ -3,6 +3,9 @@ reviewers:
- lavalamp
title: Kubernetes Components
content_type: concept
+description: >
+ A Kubernetes cluster consists of the components that represent the control plane
+ and a set of machines called nodes.
weight: 20
card:
name: concepts
diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md
index dd69fb6ccb..42d12425b7 100644
--- a/content/en/docs/concepts/overview/kubernetes-api.md
+++ b/content/en/docs/concepts/overview/kubernetes-api.md
@@ -4,6 +4,9 @@ reviewers:
title: The Kubernetes API
content_type: concept
weight: 30
+description: >
+ The Kubernetes API lets you query and manipulate the state of objects in Kubernetes.
+ The core of Kubernetes' control plane is the API server and the HTTP API that it exposes. Users, the different parts of your cluster, and external components all communicate with one another through the API server.
card:
name: concepts
weight: 30
@@ -22,8 +25,6 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
-
-
## API changes
@@ -84,7 +85,7 @@ Kubernetes implements an alternative Protobuf based serialization format for the
To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path, such as `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
Versioning is done at the API level rather than at the resource or field level to ensure that the
API presents a clear, consistent view of system resources and behavior, and to enable controlling
@@ -154,14 +155,6 @@ The flag accepts comma separated set of key=value pairs describing runtime confi
{{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the
kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}}
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
-
## Persistence
Kubernetes stores its serialized state in terms of the API resources by writing them into
diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md
index 5b30c8e66e..5060b6f287 100644
--- a/content/en/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/en/docs/concepts/overview/what-is-kubernetes.md
@@ -74,7 +74,7 @@ Kubernetes lets you store and manage sensitive information, such as passwords, O
## What Kubernetes is not
-Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
+Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, and lets users integrate their logging, monitoring, and alerting solutions. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
Kubernetes:
diff --git a/content/en/docs/concepts/overview/working-with-objects/_index.md b/content/en/docs/concepts/overview/working-with-objects/_index.md
index 8661349a3f..f872c20697 100755
--- a/content/en/docs/concepts/overview/working-with-objects/_index.md
+++ b/content/en/docs/concepts/overview/working-with-objects/_index.md
@@ -1,5 +1,7 @@
---
title: "Working with Kubernetes Objects"
weight: 40
+description: >
+ Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster.
+ Learn about the Kubernetes object model and how to work with these objects.
---
-
diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
index 11e8944c8a..a0a68c6dff 100644
--- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
@@ -35,7 +35,7 @@ on every resource object.
| Key | Description | Example | Type |
| ----------------------------------- | --------------------- | -------- | ---- |
| `app.kubernetes.io/name` | The name of the application | `mysql` | string |
-| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `wordpress-abcxzy` | string |
+| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `mysql-abcxzy` | string |
| `app.kubernetes.io/version` | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
| `app.kubernetes.io/component` | The component within the architecture | `database` | string |
| `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string |
@@ -49,7 +49,7 @@ kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
- app.kubernetes.io/instance: wordpress-abcxzy
+ app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 1f4f4e7509..ab447cdcd6 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -92,7 +92,7 @@ and the `spec` format for a Deployment can be found in
## {{% heading "whatsnext" %}}
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
-* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
+* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
index 5e3acc5123..59b1763450 100644
--- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
@@ -26,7 +26,7 @@ need to create or think about namespaces at all. Start using namespaces when yo
need the features they provide.
Namespaces provide a scope for names. Names of resources need to be unique within a namespace,
-but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes
+but not across namespaces. Namespaces cannot be nested inside one another and each Kubernetes
resource can only be in one namespace.
Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
@@ -43,6 +43,10 @@ resources within the same namespace.
Creation and deletion of namespaces are described in the [Admin Guide documentation
for namespaces](/docs/admin/namespaces).
+{{< note >}}
+ Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
+{{< /note >}}
+
### Viewing namespaces
You can list the current namespaces in a cluster using:
diff --git a/content/en/docs/concepts/overview/working-with-objects/object-management.md b/content/en/docs/concepts/overview/working-with-objects/object-management.md
index 97f57ff275..7cb65b5497 100644
--- a/content/en/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/en/docs/concepts/overview/working-with-objects/object-management.md
@@ -40,12 +40,6 @@ objects, it provides no history of previous configurations.
Run an instance of the nginx container by creating a Deployment object:
-```sh
-kubectl run nginx --image nginx
-```
-
-Do the same thing using a different syntax:
-
```sh
kubectl create deployment nginx --image nginx
```
diff --git a/content/en/docs/concepts/policy/_index.md b/content/en/docs/concepts/policy/_index.md
index 41d91de546..d2b42bc4cd 100755
--- a/content/en/docs/concepts/policy/_index.md
+++ b/content/en/docs/concepts/policy/_index.md
@@ -1,5 +1,6 @@
---
title: "Policies"
weight: 90
+description: >
+ Policies you can configure that apply to groups of resources.
---
-
diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md
index 5a5241c42e..835bbc8475 100644
--- a/content/en/docs/concepts/policy/pod-security-policy.md
+++ b/content/en/docs/concepts/policy/pod-security-policy.md
@@ -302,7 +302,7 @@ kubectl-user delete pod pause
Let's try that again, slightly differently:
```shell
-kubectl-user run pause --image=k8s.gcr.io/pause
+kubectl-user create deployment pause --image=k8s.gcr.io/pause
deployment "pause" created
kubectl-user get pods
diff --git a/content/en/docs/concepts/scheduling-eviction/_index.md b/content/en/docs/concepts/scheduling-eviction/_index.md
index a30a80a451..3a2bf9359f 100644
--- a/content/en/docs/concepts/scheduling-eviction/_index.md
+++ b/content/en/docs/concepts/scheduling-eviction/_index.md
@@ -1,5 +1,8 @@
---
title: "Scheduling and Eviction"
weight: 90
+description: >
+ In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them.
+ Eviction is the process of proactively failing one or more Pods on resource-starved Nodes.
---
diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
index 406c3f974b..d469661849 100644
--- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -28,7 +28,7 @@ page will help you learn about scheduling.
## kube-scheduler
-[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
+[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
is the default scheduler for Kubernetes and runs as part of the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
kube-scheduler is designed so that, if you want and need to, you can
@@ -95,4 +95,3 @@ of the scheduler:
* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
-
diff --git a/content/en/docs/concepts/security/_index.md b/content/en/docs/concepts/security/_index.md
index aecc16eee7..3dfb62fe48 100644
--- a/content/en/docs/concepts/security/_index.md
+++ b/content/en/docs/concepts/security/_index.md
@@ -1,4 +1,6 @@
---
title: "Security"
weight: 81
+description: >
+ Concepts for keeping your cloud-native workload secure.
---
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index 2afd6c7335..20574c8f91 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -236,11 +236,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
spec.securityContext.supplementalGroups[*]
+
+- Visit the Netlify page preview for a PR to make sure things look good before approving.
+
+- Participate in the
+ [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+ for weekly rotations. SIG Docs expects all approvers to participate in this
+ rotation. See [PR wranglers](/docs/contribute/participate/pr-wranglers/).
+ for more details.
+
+### Becoming an approver
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
+you can become a SIG Docs approver. Approvers in other SIGs must apply
+separately for approver status in SIG Docs.
+
+To apply:
+
+1. Open a pull request adding yourself to a section of the
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
+ file in the `kubernetes/website` repository.
+
+ {{< note >}}
+ If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
+ {{< /note >}}
+
+2. Assign the PR to one or more current SIG Docs approvers.
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+assigns and suggests you as a reviewer on new pull requests.
+
+## {{% heading "whatsnext" %}}
+
+- Read about [PR wrangling](/docs/contribute/participate/pr-wranglers/), a role all approvers take on rotation.
diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md
deleted file mode 100644
index 681c53f994..0000000000
--- a/content/en/docs/contribute/participating.md
+++ /dev/null
@@ -1,316 +0,0 @@
----
-title: Participating in SIG Docs
-content_type: concept
-weight: 60
-card:
- name: contribute
- weight: 60
----
-
-
-
-SIG Docs is one of the
-[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)
-within the Kubernetes project, focused on writing, updating, and maintaining
-the documentation for Kubernetes as a whole. See
-[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs)
-for more information about the SIG.
-
-SIG Docs welcomes content and reviews from all contributors. Anyone can open a
-pull request (PR), and anyone is welcome to file issues about content or comment
-on pull requests in progress.
-
-You can also become a [member](#members),
-[reviewer](#reviewers), or [approver](#approvers). These roles require greater
-access and entail certain responsibilities for approving and committing changes.
-See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
-for more information on how membership works within the Kubernetes community.
-
-The rest of this document outlines some unique ways these roles function within
-SIG Docs, which is responsible for maintaining one of the most public-facing
-aspects of Kubernetes -- the Kubernetes website and documentation.
-
-
-
-
-
-## Roles and responsibilities
-
-- **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) and have a GitHub account.
-- **Members** of the Kubernetes organization are contributors who have spent time and effort on the Kubernetes project, usually by opening pull requests with accepted changes. See [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for membership criteria.
-- A SIG Docs **Reviewer** is a member of the Kubernetes organization who has
- expressed interest in reviewing documentation pull requests, and has been
- added to the appropriate GitHub group and `OWNERS` files in the GitHub
- repository by a SIG Docs Approver.
-- A SIG Docs **Approver** is a member in good standing who has shown a continued
- commitment to the project. An approver can merge pull requests
- and publish content on behalf of the Kubernetes organization.
- Approvers can also represent SIG Docs in the larger Kubernetes community.
- Some duties of a SIG Docs approver, such as coordinating a release,
- require a significant time commitment.
-
-## Anyone
-
-Anyone can do the following:
-
-- Open a GitHub issue against any part of Kubernetes, including documentation.
-- Provide non-binding feedback on a pull request.
-- Help to localize existing content
-- Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-- Use the `/lgtm` Prow command (short for "looks good to me") to recommend the changes in a pull request for merging.
- {{< note >}}
- If you are not a member of the Kubernetes organization, using `/lgtm` has no effect on automated systems.
- {{< /note >}}
-
-After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
-- Open a pull request to improve existing content, add new content, or write a blog post or case study.
-
-## Members
-
-Members are contributors to the Kubernetes project who meet the [membership criteria](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs welcomes contributions from all members of the Kubernetes community,
-and frequently requests reviews from members of other SIGs for technical accuracy.
-
-Any member of the [Kubernetes organization](https://github.com/kubernetes) can do the following:
-
-- Everything listed under [Anyone](#anyone)
-- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request.
-- Use the `/hold` command to prevent a pull request from being merged, if the pull request already has the LGTM and approve labels.
-- Use the `/assign` comment to assign a reviewer to a pull request.
-
-### Becoming a member
-
-After you have successfully submitted at least 5 substantive pull requests, you
-can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member)
-in the Kubernetes organization. Follow these steps:
-
-1. Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor)
- your membership.
-
- Ask for sponsorship in the [#sig-docs channel on the
- Kubernetes Slack instance](https://kubernetes.slack.com) or on the
- [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-
- {{< note >}}
- Don't send a direct email or Slack direct message to an individual
- SIG Docs member.
- {{< /note >}}
-
-2. Open a GitHub issue in the `kubernetes/org` repository to request membership.
- Fill out the template using the guidelines at
- [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md).
-
-3. Let your sponsors know about the GitHub issue, either by at-mentioning them
- in the GitHub issue (adding a comment with `@
The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+