Do | Don't |
---|---|
The Pod has two containers. | The pod has two containers. |
The Deployment is responsible for ... | The Deployment object is responsible for ... |
A PodList is a list of Pods. | A Pod List is a list of pods. |
The two ContainerPorts ... | The two ContainerPort objects ... |
The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ... |
Do | Don't |
---|---|
Click Fork. | Click "Fork". |
Select Other. | Select 'Other'. |
Do | Don't |
---|---|
A cluster is a set of nodes ... | A "cluster" is a set of nodes ... |
These components form the control plane. | These components form the control plane. |
Do | Don't |
---|---|
Open the envars.yaml file. | Open the envars.yaml file. |
Go to the /docs/tutorials directory. | Go to the /docs/tutorials directory. |
Open the /_data/concepts.yaml file. | Open the /_data/concepts.yaml file. |
Do | Don't |
---|---|
events are recorded with an associated "stage". | events are recorded with an associated "stage." |
The copy is called a "fork". | The copy is called a "fork." |
` tag. In a Markdown
document, use the backtick (`).
-
- Do Don't
- The kubectl run
command creates a Deployment. The "kubectl run" command creates a Deployment.
- 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**. Use triple backticks before and after a multi-line block of code for fenced code blocks. Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations. Use meaningful variable names that have a context. Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context. Remove trailing spaces in the code. Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well.
-
+{{< 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.
+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**.
+Use triple backticks before and after a multi-line block of code for fenced code blocks. | Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations.
+Use meaningful variable names that have a context. | Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context.
+Remove trailing spaces in the code. | Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well.
+{{< /table >}}
{{< note >}}
The website supports syntax highlighting for code samples, but specifying a language is optional. Syntax highlighting in the code block should conform to the [contrast guidelines.](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=141%2C143#contrast-minimum)
@@ -127,31 +139,36 @@ The website supports syntax highlighting for code samples, but specifying a lang
### Use code style for object field names
-
- Do Don't
- Set the value of the replicas
field in the configuration file. Set the value of the "replicas" field in the configuration file.
- The value of the exec
field is an ExecAction object. The value of the "exec" field is an ExecAction object.
-
+{{< table caption = "Do and Don't - Use code style for object field names" >}}
+Do | Don't
+:--| :-----
+Set the value of the `replicas` field in the configuration file. | Set the value of the "replicas" field in the configuration file.
+The value of the `exec` field is an ExecAction object. | The value of the "exec" field is an ExecAction object.
+{{< /table >}}
### Use normal style for string and integer field values
For field values of type string or integer, use normal style without quotation marks.
-
- Do Don't
- Set the value of imagePullPolicy
to Always. Set the value of imagePullPolicy
to "Always".
- Set the value of image
to nginx:1.8. Set the value of image
to nginx:1.8
.
- Set the value of the replicas
field to 2. Set the value of the replicas
field to 2
.
-
+{{< table caption = "Do and Don't - Use normal style for string and integer field values" >}}
+Do | Don't
+:--| :-----
+Set the value of `imagePullPolicy` to Always. | Set the value of `imagePullPolicy` to "Always".
+Set the value of `image` to nginx:1.8. | Set the value of `image` to `nginx:1.8`.
+Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`.
+{{< /table >}}
+
## Code snippet formatting
### Don't include the command prompt
-
- Do Don't
- kubectl get pods $ kubectl get pods
-
+{{< table caption = "Do and Don't - Don't include the command prompt" >}}
+Do | Don't
+:--| :-----
+kubectl get pods | $ kubectl get pods
+{{< /table >}}
+
### Separate commands from output
@@ -198,13 +215,14 @@ kind: Pod
A list of Kubernetes-specific terms and words to be used consistently across the site.
-
- Term Usage
- Kubernetes Kubernetes should always be capitalized.
- Docker Docker should always be capitalized.
- SIG Docs SIG Docs rather than SIG-DOCS or other variations.
- On-premises On-premises or On-prem rather than On-premise or other variations.
-
+{{< table caption = "Kubernetes.io word list" >}}
+Term | Usage
+:--- | :----
+Kubernetes | Kubernetes should always be capitalized.
+Docker | Docker should always be capitalized.
+SIG Docs | SIG Docs rather than SIG-DOCS or other variations.
+On-premises | On-premises or On-prem rather than On-premise or other variations.
+{{< /table >}}
## Shortcodes
@@ -377,26 +395,33 @@ Use a single newline to separate block-level content like headings, lists, image
### Headings
People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest.
-
- Do Don't
- Update the title in the front matter of the page or blog post. Use first level heading, as Hugo automatically converts the title in the front matter of the page into a first-level heading. Use ordered headings to provide a meaningful high-level outline of your content. Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles.
- Use pound or hash signs (#) for non-blog post content. Use underlines (--- or ===) to designate first-level headings.
- Use sentence case for headings. For example, Extend kubectl with plugins Use title case for headings. For example, Extend Kubectl With Plugins
-
+{{< table caption = "Do and Don't - Headings" >}}
+Do | Don't
+:--| :-----
+Update the title in the front matter of the page or blog post. | Use first level heading, as Hugo automatically converts the title in the front matter of the page into a first-level heading.
+Use ordered headings to provide a meaningful high-level outline of your content. | Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles.
+Use pound or hash signs (#) for non-blog post content. | Use underlines (--- or ===) to designate first-level headings.
+Use sentence case for headings. For example, **Extend kubectl with plugins** | Use title case for headings. For example, **Extend Kubectl With Plugins**
+{{< /table >}}
### Paragraphs
-
- Do Don't
- Try to keep paragraphs under 6 sentences. Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it.
- Use three hyphens (---) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section. Use horizontal rules for decoration.
-
+{{< table caption = "Do and Don't - Paragraphs" >}}
+Do | Don't
+:--| :-----
+Try to keep paragraphs under 6 sentences. | Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it.
+Use three hyphens (---) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section. | Use horizontal rules for decoration.
+{{< /table >}}
### Links
-
- Do Don't
- Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See Check required ports for more details. Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See here for more details. Write Markdown-style links ([link text](URL)). For example, [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)
and the output is Hugo shortcodes. Write HTML-style links (<link href="/media/examples/link-element-example.css" target="_blank">Visit our tutorial!)
or create links that open in new tabs or windows. For example, [example website](https://example.com){target="_blank"}
-
+
+{{< table caption = "Do and Don't - Links" >}}
+Do | Don't
+:--| :-----
+Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See Check required ports for more details. | Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See here for more details.
+Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)` and the output is [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions). | Write HTML-style links: `Visit our tutorial!`, or create links that open in new tabs or windows. For example: `[example website](https://example.com){target="_blank"}`
+{{< /table >}}
+
### Lists
Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list.
@@ -428,21 +453,25 @@ This section contains suggested best practices for clear, concise, and consisten
### Use present tense
-
- Do Don't
- This command starts a proxy. This command will start a proxy.
-
+{{< table caption = "Do and Don't - Use present tense" >}}
+Do | Don't
+:--| :-----
+This command starts a proxy. | This command will start a proxy.
+ {{< /table >}}
+
Exception: Use future or past tense if it is required to convey the correct
meaning.
### Use active voice
-
- 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 caption = "Do and Don't - Use active voice" >}}
+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 >}}
+
Exception: Use passive voice if active voice leads to an awkward construction.
@@ -450,31 +479,35 @@ Exception: Use passive voice if active voice leads to an awkward construction.
Use simple and direct language. Avoid using unnecessary phrases, such as saying "please."
-
- 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 caption = "Do and Don't - Use simple and direct language" >}}
+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 >}}
### Address the reader as "you"
-
- 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 caption = "Do and Don't - Addressing the reader" >}}
+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 >}}
+
### Avoid Latin phrases
Prefer English terms over Latin abbreviations.
-
- Do Don't
- For example, ... e.g., ...
- That is, ... i.e., ...
-
+{{< table caption = "Do and Don't - Avoid Latin phrases" >}}
+Do | Don't
+:--| :-----
+For example, ... | e.g., ...
+That is, ...| i.e., ...
+{{< /table >}}
+
Exception: Use "etc." for et cetera.
@@ -485,22 +518,26 @@ Exception: Use "etc." for et cetera.
Using "we" in a sentence can be confusing, because the reader might not know
whether they're part of the "we" you're describing.
-
- 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 caption = "Do and Don't - Patterns to avoid" >}}
+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 >}}
+
### Avoid jargon and idioms
Some readers speak English as a second language. Avoid jargon and idioms to help them understand better.
-
- Do Don't
- Internally, ... Under the hood, ...
- Create a new cluster. Turn up a new cluster.
-
+{{< table caption = "Do and Don't - Avoid jargon and idioms" >}}
+Do | Don't
+:--| :-----
+Internally, ... | Under the hood, ...
+Create a new cluster. | Turn up a new cluster.
+{{< /table >}}
+
### Avoid statements about the future
@@ -513,11 +550,13 @@ information.
Avoid words like "currently" and "new." A feature that is new today might not be
considered new in a few months.
-
- Do Don't
- In version 1.4, ... In the current version, ...
- The Federation feature provides ... The new Federation feature provides ...
-
+{{< table caption = "Do and Don't - Avoid statements that will soon be out of date" >}}
+Do | Don't
+:--| :-----
+In version 1.4, ... | In the current version, ...
+The Federation feature provides ... | The new Federation feature provides ...
+{{< /table >}}
+
{{% /capture %}}
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 98f70cc7d4..8a5d7949e4 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -19,24 +19,13 @@ Create a fork of the Kubernetes documentation repository as described in
As you prepare to write a new topic, think about the page type that would fit your content the best:
-
-
-
- Concept
- A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see Nodes.
-
-
-
- Task
- A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see Configure a Pod to Use a Volume for Storage. For an example of a longer task page, see Configure Liveness and Readiness Probes
-
-
-
- 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 caption = "Guidelines for choosing a page type" >}}
+Type | Description
+:--- | :----------
+Concept | A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see Nodes.
+Task | A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see Configure a Pod to Use a Volume for Storage. For an example of a longer task page, see Configure Liveness and Readiness Probes
+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 >}}
Use a template for each new page. Each page type has a
[template](/docs/contribute/style/page-templates/)
diff --git a/content/en/docs/getting-started-guides/OWNERS b/content/en/docs/getting-started-guides/OWNERS
deleted file mode 100644
index fecf081d73..0000000000
--- a/content/en/docs/getting-started-guides/OWNERS
+++ /dev/null
@@ -1,5 +0,0 @@
-# See the OWNERS docs at https://go.k8s.io/owners
-
-reviewers:
-- errordeveloper
-
diff --git a/content/en/docs/getting-started-guides/_index.md b/content/en/docs/getting-started-guides/_index.md
deleted file mode 100755
index 0e925b92bd..0000000000
--- a/content/en/docs/getting-started-guides/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "Independent Solutions"
-weight: 50
----
-
diff --git a/content/en/docs/getting-started-guides/alternatives.md b/content/en/docs/getting-started-guides/alternatives.md
deleted file mode 100644
index 7fcef3f3f1..0000000000
--- a/content/en/docs/getting-started-guides/alternatives.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-reviewers:
-- pwittrock
-title: Deprecated Alternatives
----
-
-# *Stop. These guides are superseded by [Minikube](../minikube/). They are only listed here for completeness.*
-
-* [Using Vagrant](https://git.k8s.io/community/contributors/devel/vagrant.md)
-* *Advanced:* [Directly using Kubernetes raw binaries (Linux Only)](https://git.k8s.io/community/contributors/devel/running-locally.md)
\ No newline at end of file
diff --git a/content/en/docs/getting-started-guides/fedora/OWNERS b/content/en/docs/getting-started-guides/fedora/OWNERS
deleted file mode 100644
index 67c11df3a5..0000000000
--- a/content/en/docs/getting-started-guides/fedora/OWNERS
+++ /dev/null
@@ -1,7 +0,0 @@
-# See the OWNERS docs at https://go.k8s.io/owners
-
-reviewers:
-- aveshagarwal
-- eparis
-- thockin
-
diff --git a/content/en/docs/getting-started-guides/fedora/_index.md b/content/en/docs/getting-started-guides/fedora/_index.md
deleted file mode 100755
index d8a5bb38a0..0000000000
--- a/content/en/docs/getting-started-guides/fedora/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "Bare Metal"
-weight: 60
----
-
diff --git a/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md b/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md
deleted file mode 100644
index 887f362798..0000000000
--- a/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-reviewers:
-- aveshagarwal
-- eparis
-- thockin
-title: Fedora (Single Node)
----
-
-{{< toc >}}
-
-## Prerequisites
-
-1. You need 2 or more machines with Fedora installed. These can be either bare metal machines or virtual machines.
-
-## Instructions
-
-This is a getting started guide for Fedora. It is a manual configuration so you understand all the underlying packages / services / ports, etc...
-
-This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](/docs/concepts/cluster-administration/networking/) done outside of Kubernetes. Although the additional Kubernetes configuration requirements should be obvious.
-
-The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: `/etc/kubernetes`. We will break the services up between the hosts. The first host, fed-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_ (not needed if _etcd_ runs on a different host but this guide assumes that _etcd_ and Kubernetes master run on the same host). The remaining host, fed-node will be the node and run kubelet, proxy and docker.
-
-**System Information:**
-
-Hosts:
-
-```conf
-fed-master = 192.168.121.9
-fed-node = 192.168.121.65
-```
-
-**Prepare the hosts:**
-
-* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with Kubernetes-0.18 and beyond.
-* Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the `enable=0` to `enable=1` for extras.
-
-```shell
-dnf -y install kubernetes
-```
-
-* Install etcd
-
-```shell
-dnf -y install etcd
-```
-
-* Add master and node to `/etc/hosts` on all machines (not needed if hostnames already in DNS). Make sure that communication works between fed-master and fed-node by using a utility such as ping.
-
-```shell
-echo "192.168.121.9 fed-master
-192.168.121.65 fed-node" >> /etc/hosts
-```
-
-* Edit `/etc/kubernetes/config` (which should be the same on all hosts) to set
-the name of the master server:
-
-```shell
-# Comma separated list of nodes in the etcd cluster
-KUBE_MASTER="--master=http://fed-master:8080"
-```
-
-* Disable the firewall on both the master and node, as Docker does not play well with other firewall rule managers. Please note that iptables.service does not exist on the default Fedora Server install.
-
-```shell
-systemctl mask firewalld.service
-systemctl stop firewalld.service
-
-systemctl disable --now iptables.service
-```
-
-**Configure the Kubernetes services on the master.**
-
-* Edit `/etc/kubernetes/apiserver` to appear as such. The service-cluster-ip-range IP addresses must be an unused block of addresses, not used anywhere else. They do not need to be routed or assigned to anything.
-
-```shell
-# The address on the local server to listen to.
-KUBE_API_ADDRESS="--address=0.0.0.0"
-
-# Comma separated list of nodes in the etcd cluster
-KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:2379"
-
-# Address range to use for services
-KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
-
-# Add your own!
-KUBE_API_ARGS=""
-```
-
-* Edit `/etc/etcd/etcd.conf` to let etcd listen on all available IPs instead of 127.0.0.1. If you have not done this, you might see an error such as "connection refused".
-
-```shell
-ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
-```
-
-* Start the appropriate services on master:
-
-```shell
-for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do
- systemctl enable --now $SERVICES
- systemctl status $SERVICES
-done
-```
-
-**Configure the Kubernetes services on the node.**
-
-***We need to configure the kubelet on the node.***
-
-* Edit `/etc/kubernetes/kubelet` to appear as such:
-
-```shell
-###
-# Kubernetes kubelet (node) config
-
-# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)
-KUBELET_ADDRESS="--address=0.0.0.0"
-
-# You may leave this blank to use the actual hostname
-KUBELET_HOSTNAME="--hostname-override=fed-node"
-
-# location of the api-server
-KUBELET_ARGS="--cgroup-driver=systemd --kubeconfig=/etc/kubernetes/master-kubeconfig.yaml"
-
-```
-
-* Edit `/etc/kubernetes/master-kubeconfig.yaml` to contain the following information:
-
-```yaml
-kind: Config
-clusters:
-- name: local
- cluster:
- server: http://fed-master:8080
-users:
-- name: kubelet
-contexts:
-- context:
- cluster: local
- user: kubelet
- name: kubelet-context
-current-context: kubelet-context
-```
-
-* Start the appropriate services on the node (fed-node).
-
-```shell
-for SERVICES in kube-proxy kubelet docker; do
- systemctl enable --now $SERVICES
- systemctl status $SERVICES
-done
-```
-
-* Check to make sure now the cluster can see the fed-node on fed-master, and its status changes to _Ready_.
-
-```shell
-kubectl get nodes
-NAME STATUS AGE VERSION
-fed-node Ready 4h
-```
-
-* Deletion of nodes:
-
-To delete _fed-node_ from your Kubernetes cluster, one should run the following on fed-master (Please do not do it, it is just for information):
-
-```shell
-kubectl delete -f ./node.json
-```
-
-*You should be finished!*
-
-**The cluster should be running! Launch a test pod.**
-
-## Support Level
-
-
-IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
--------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
-Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config) | | Project
diff --git a/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md b/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
deleted file mode 100644
index 88ef0615fd..0000000000
--- a/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
+++ /dev/null
@@ -1,196 +0,0 @@
----
-reviewers:
-- dchen1107
-- erictune
-- thockin
-title: Fedora (Multi Node)
----
-
-{{< toc >}}
-
-This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/docs/getting-started-guides/fedora/fedora_manual_config/) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. Flannel on each node configures an overlay network that docker uses. Flannel runs on each node to setup a unique class-C container network.
-
-## Prerequisites
-
-You need 2 or more machines with Fedora installed.
-
-## Master Setup
-
-**Perform following commands on the Kubernetes master**
-
-* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. Flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are:
-
-```json
-{
- "Network": "18.16.0.0/16",
- "SubnetLen": 24,
- "Backend": {
- "Type": "vxlan",
- "VNI": 1
- }
-}
-```
-
-{{< note >}}
-Choose an IP range that is *NOT* part of the public IP address range.
-{{< /note >}}
-
-Add the configuration to the etcd server on fed-master.
-
-```shell
-etcdctl set /coreos.com/network/config < flannel-config.json
-```
-
-* Verify that the key exists in the etcd server on fed-master.
-
-```shell
-etcdctl get /coreos.com/network/config
-```
-
-## Node Setup
-
-**Perform following commands on all Kubernetes nodes**
-
-Install the flannel package
-
-```shell
-# dnf -y install flannel
-```
-
-Edit the flannel configuration file /etc/sysconfig/flanneld as follows:
-
-```shell
-# Flanneld configuration options
-
-# etcd url location. Point this to the server where etcd runs
-FLANNEL_ETCD="http://fed-master:2379"
-
-# etcd config key. This is the configuration key that flannel queries
-# For address range assignment
-FLANNEL_ETCD_KEY="/coreos.com/network"
-
-# Any additional options that you want to pass
-FLANNEL_OPTIONS=""
-```
-
-{{< note >}}
-By default, flannel uses the interface for the default route. If you have multiple interfaces and would like to use an interface other than the default route one, you could add "-iface=" to FLANNEL_OPTIONS. For additional options, run `flanneld --help` on command line.
-{{< /note >}}
-
-Enable the flannel service.
-
-```shell
-systemctl enable flanneld
-```
-
-If docker is not running, then starting flannel service is enough and skip the next step.
-
-```shell
-systemctl start flanneld
-```
-
-If docker is already running, then stop docker, delete docker bridge (docker0), start flanneld and restart docker as follows. Another alternative is to just reboot the system (`systemctl reboot`).
-
-```shell
-systemctl stop docker
-ip link delete docker0
-systemctl start flanneld
-systemctl start docker
-```
-
-
-## Test the cluster and flannel configuration
-
-Now check the interfaces on the nodes. Notice there is now a flannel.1 interface, and the ip addresses of docker0 and flannel.1 interfaces are in the same network. You will notice that docker0 is assigned a subnet (18.16.29.0/24 as shown below) on each Kubernetes node out of the IP range configured above. A working output should look like this:
-
-```shell
-# ip -4 a|grep inet
- inet 127.0.0.1/8 scope host lo
- inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic eth0
- inet 18.16.29.0/16 scope global flannel.1
- inet 18.16.29.1/24 scope global docker0
-```
-
-From any node in the cluster, check the cluster members by issuing a query to etcd server via curl (only partial output is shown using `grep -E "\{|\}|key|value"`). If you set up a 1 master and 3 nodes cluster, you should see one block for each node showing the subnets they have been assigned. You can associate those subnets to each node by the MAC address (VtepMAC) and IP address (Public IP) that is listed in the output.
-
-```shell
-curl -s http://fed-master:2379/v2/keys/coreos.com/network/subnets | python -mjson.tool
-```
-
-```json
-{
- "node": {
- "key": "/coreos.com/network/subnets",
- {
- "key": "/coreos.com/network/subnets/18.16.29.0-24",
- "value": "{\"PublicIP\":\"192.168.122.77\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"46:f1:d0:18:d0:65\"}}"
- },
- {
- "key": "/coreos.com/network/subnets/18.16.83.0-24",
- "value": "{\"PublicIP\":\"192.168.122.36\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"ca:38:78:fc:72:29\"}}"
- },
- {
- "key": "/coreos.com/network/subnets/18.16.90.0-24",
- "value": "{\"PublicIP\":\"192.168.122.127\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"92:e2:80:ba:2d:4d\"}}"
- }
- }
-}
-```
-
-From all nodes, review the `/run/flannel/subnet.env` file. This file was generated automatically by flannel.
-
-```shell
-# cat /run/flannel/subnet.env
-FLANNEL_SUBNET=18.16.29.1/24
-FLANNEL_MTU=1450
-FLANNEL_IPMASQ=false
-```
-
-At this point, we have etcd running on the Kubernetes master, and flannel / docker running on Kubernetes nodes. Next steps are for testing cross-host container communication which will confirm that docker and flannel are configured properly.
-
-Issue the following commands on any 2 nodes:
-
-```shell
-# docker run -it fedora:latest bash
-bash-4.3#
-```
-
-This will place you inside the container. Install iproute and iputils packages to install ip and ping utilities. Due to a [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1142311), it is required to modify capabilities of ping binary to work around "Operation not permitted" error.
-
-```shell
-bash-4.3# dnf -y install iproute iputils
-bash-4.3# setcap cap_net_raw-ep /usr/bin/ping
-```
-
-Now note the IP address on the first node:
-
-```shell
-bash-4.3# ip -4 a l eth0 | grep inet
- inet 18.16.29.4/24 scope global eth0
-```
-
-And also note the IP address on the other node:
-
-```shell
-bash-4.3# ip a l eth0 | grep inet
- inet 18.16.90.4/24 scope global eth0
-```
-Now ping from the first node to the other node:
-
-```shell
-bash-4.3# ping 18.16.90.4
-PING 18.16.90.4 (18.16.90.4) 56(84) bytes of data.
-64 bytes from 18.16.90.4: icmp_seq=1 ttl=62 time=0.275 ms
-64 bytes from 18.16.90.4: icmp_seq=2 ttl=62 time=0.372 ms
-```
-
-Now Kubernetes multi-node cluster is set up with overlay networking set up by flannel.
-
-## Support Level
-
-
-IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
--------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
-Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
-libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
-KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
diff --git a/content/en/docs/getting-started-guides/ubuntu.md b/content/en/docs/getting-started-guides/ubuntu.md
deleted file mode 100644
index 733e8d1d1f..0000000000
--- a/content/en/docs/getting-started-guides/ubuntu.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Kubernetes on Ubuntu
-content_template: templates/concept
----
-
-{{% capture overview %}}
-There are multiple ways to run a Kubernetes cluster with Ubuntu on public and
-private clouds, as well as bare metal.
-{{% /capture %}}
-
-{{% capture body %}}
-## The Charmed Distribution of Kubernetes(CDK)
-
-[CDK](https://www.ubuntu.com/cloud/kubernetes) is a distribution of Kubernetes
-packaged as a bundle of *charms* for Juju, the open source application modeller.
-
-CDK is the latest version of Kubernetes with upstream binaries, packaged in a format
-which makes it fast and easy to deploy. It supports various public
-and private clouds including AWS, GCE, Azure, Joyent, OpenStack, VMware, Bare Metal
-and localhost deployments.
-
-See the [Official documentation](https://www.ubuntu.com/kubernetes/docs) for
-more information.
-
-## MicroK8s
-
-[MicroK8s](https://microk8s.io) is a minimal install of Kubernetes designed to run locally.
-It can be installed on Ubuntu (or any snap enabled operating system) with the command:
-
-```shell
-snap install microk8s --classic
-```
-
-Full documentation is available on the [MicroK8s website](https://microk8s.io/docs)
-
-
-
-
-
-
-{{% /capture %}}
diff --git a/content/en/docs/reference/access-authn-authz/abac.md b/content/en/docs/reference/access-authn-authz/abac.md
index 287f85bad2..40c56a985c 100644
--- a/content/en/docs/reference/access-authn-authz/abac.md
+++ b/content/en/docs/reference/access-authn-authz/abac.md
@@ -8,10 +8,6 @@ title: Using ABAC Authorization
content_template: templates/concept
weight: 80
---
-{{< note >}}
-{{< feature-state state="deprecated" for_k8s_version="1.6" >}}
-The ABAC Authorization feature has been considered deprecated from the Kubernetes 1.6 release.
-{{< /note >}}
{{% capture overview %}}
Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together.
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 76be84b769..fd31a45c97 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
@@ -75,6 +75,7 @@ different Kubernetes components.
| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
| `CustomPodDNS` | `true` | GA | 1.14 | - |
+| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | |
| `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
| `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | |
| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.11 |
@@ -117,6 +118,7 @@ different Kubernetes components.
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | Beta | 1.15 | |
+| `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha| 1.15 | |
@@ -124,6 +126,7 @@ different Kubernetes components.
| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
| `MountPropagation` | `true` | GA | 1.12 | |
+| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
| `NodeLease` | `true` | Beta | 1.14 | |
| `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
@@ -274,6 +277,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property.
Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)
for more details.
+- `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas.
- `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs.
- `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
@@ -314,11 +318,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
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.
+- `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.
- `MountContainers`: Enable using utility containers on host as the volume mounter.
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
+- `NodeDisruptionExclusion`: Enable use of the node label `node.kubernetes.io/exclude-disruption` which prevents nodes from being evacuated during zone failures.
- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal.
- `NonPreemptingPriority`: Enable NonPreempting option for PriorityClass and Pod.
- `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
@@ -352,7 +358,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server.
- `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 annotated with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key.
+ A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key (when `LegacyNodeRoleBehavior` is on) or `node.kubernetes.io/exclude-from-external-load-balancers`.
- `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.
diff --git a/content/en/docs/reference/glossary/applications.md b/content/en/docs/reference/glossary/applications.md
index 33901436be..f097c05620 100644
--- a/content/en/docs/reference/glossary/applications.md
+++ b/content/en/docs/reference/glossary/applications.md
@@ -5,7 +5,6 @@ date: 2019-05-12
full_link:
short_description: >
The layer where various containerized applications run.
-
aka:
tags:
- fundamental
diff --git a/content/en/docs/reference/glossary/static-pod.md b/content/en/docs/reference/glossary/static-pod.md
index b633aee0f2..dc77a035cc 100755
--- a/content/en/docs/reference/glossary/static-pod.md
+++ b/content/en/docs/reference/glossary/static-pod.md
@@ -2,13 +2,17 @@
title: Static Pod
id: static-pod
date: 2019-02-12
-full_link: /docs/tasks/administer-cluster/static-pod/
+full_link: /docs/tasks/configure-pod-container/static-pod/
short_description: >
- A pod managed directly by kubelet daemon on a specific node
+ A pod managed directly by the kubelet daemon on a specific node.
aka:
tags:
- fundamental
---
- A {{< glossary_tooltip text="pod" term_id="pod" >}} managed directly by the kubelet
- daemon on a specific node, without the API server observing it.
+
+A {{< glossary_tooltip text="pod" term_id="pod" >}} managed directly by the kubelet
+ daemon on a specific node,
+
+
+without the API server observing it.
\ No newline at end of file
diff --git a/content/en/docs/reference/glossary/workload.md b/content/en/docs/reference/glossary/workload.md
index 966703fcd4..f2fabbab77 100644
--- a/content/en/docs/reference/glossary/workload.md
+++ b/content/en/docs/reference/glossary/workload.md
@@ -1,28 +1,22 @@
---
-title: Workloads
+title: Workload
id: workloads
date: 2019-02-13
full_link: /docs/concepts/workloads/
short_description: >
- Workloads are objects you use to manage and run your containers on the cluster.
+ A workload is an application running on Kubernetes.
aka:
tags:
- fundamental
-- core-object
-- workload
---
- Workloads are objects you use to manage and run your containers on the cluster.
+ A workload is an application running on Kubernetes.
-Kubernetes performs the
-deployment and updates the workload with the current state of the application.
-Workloads include the DaemonSet, Deployments, Jobs, Pods, ReplicaSet, ReplicationController, and StatefulSet objects.
-
-For example, a workload that has a web element and a database element might run the
-database in one {{< glossary_tooltip term_id="StatefulSet" >}} of
-{{< glossary_tooltip text="pods" term_id="pod" >}} and the webserver via
-a {{< glossary_tooltip term_id="Deployment" >}} that consists of many web app
-{{< glossary_tooltip text="pods" term_id="pod" >}}, all alike.
+Various core objects that represent different types or parts of a workload
+include the DaemonSet, Deployment, Job, ReplicaSet, and StatefulSet objects.
+For example, a workload that has a web server and a database might run the
+database in one {{< glossary_tooltip term_id="StatefulSet" >}} and the web server
+in a {{< glossary_tooltip term_id="Deployment" >}}.
diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md
index b61c5286f5..37ea821daa 100644
--- a/content/en/docs/setup/_index.md
+++ b/content/en/docs/setup/_index.md
@@ -82,7 +82,7 @@ The following production environment solutions table lists the providers and the
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔
| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | | | | ✔ | ✔
| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/) | | | | | | ✔
-| [Gardener](https://gardener.cloud/) | |✔ | | ✔ | |
+| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ (via OpenStack) | ✔ | |
| [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | |
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
@@ -109,5 +109,6 @@ The following production environment solutions table lists the providers and the
| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ |
| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | |
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
+| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | |
{{% /capture %}}
diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md
index 99501c8d1a..57de8cd47a 100644
--- a/content/en/docs/setup/release/version-skew-policy.md
+++ b/content/en/docs/setup/release/version-skew-policy.md
@@ -28,8 +28,8 @@ The Kubernetes project maintains release branches for the most recent three mino
Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
Patch releases are cut from those branches at a regular cadence, or as needed.
-This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/patch-release-manager/README.md#release-timing).
-The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/releases/).
+This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing).
+The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/release-team).
Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.
@@ -37,7 +37,7 @@ Minor releases occur approximately every 3 months, so each minor release branch
### kube-apiserver
-In [highly-available (HA) clusters](/docs/setup/production-environment/tools/independent/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
+In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
Example:
@@ -120,7 +120,7 @@ Upgrade `kube-apiserver` to **1.(n+1)**
{{< note >}}
Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
-[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md)
+[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.
{{< /note >}}
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 12c8d7165d..9312ccf395 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
@@ -30,7 +30,7 @@ Dashboard also provides information on the state of Kubernetes resources in your
The Dashboard UI is not deployed by default. To deploy it, run the following command:
```
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta4/aio/deploy/recommended.yaml
```
## Accessing the Dashboard UI
diff --git a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md
index 3947b64a28..83924865c5 100644
--- a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md
+++ b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md
@@ -36,7 +36,7 @@ may be disabled by setting `--feature-gates=PodShareProcessNamespace=false`.
## Configure a Pod
-Process Namespace Sharing is enabled using the `ShareProcessNamespace` field of
+Process Namespace Sharing is enabled using the `shareProcessNamespace` field of
`v1.PodSpec`. For example:
{{< codenew file="pods/share-process-namespace.yaml" >}}
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index 5b72f04643..8b8571ca0b 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -490,6 +490,18 @@ let users route data where they want. For example, users can emit audit events t
plugin which supports full-text search and analytics.
+[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
+
{{% /capture %}}
{{% capture whatsnext %}}
diff --git a/content/en/examples/service/access/Dockerfile b/content/en/examples/service/access/Dockerfile
index 7de606a642..b7b09d492a 100644
--- a/content/en/examples/service/access/Dockerfile
+++ b/content/en/examples/service/access/Dockerfile
@@ -1,4 +1,4 @@
-FROM nginx:1.9.14
+FROM nginx:1.17.3
RUN rm /etc/nginx/conf.d/default.conf
COPY frontend.conf /etc/nginx/conf.d
diff --git a/content/es/docs/concepts/containers/container-lifecycle-hooks.md b/content/es/docs/concepts/containers/container-lifecycle-hooks.md
new file mode 100644
index 0000000000..2d5763476a
--- /dev/null
+++ b/content/es/docs/concepts/containers/container-lifecycle-hooks.md
@@ -0,0 +1,120 @@
+---
+title: Container Lifecycle Hooks
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+Esta página describe como los contenedores gestionados por kubelet pueden utilizar el framework _Container lifecycle hook_ (hook del ciclo de vida del contenedor)
+para ejecutar código disparado por eventos durante la gestión de su ciclo de vida (lifecycle).
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Introducción
+
+De manera análoga a muchos frameworks de lenguajes de programación que tienen componentes hooks de lifecycle, como Angular,
+Kubernetes también proporciona esta funcionalidad para los contenedores.
+Los hooks permiten a los contenedores conocer los eventos en su gestión de ciclo de vida
+y ejecutar el código implementado en un controlador cuando el hook de ciclo de vida correspondiente es ejecutado.
+
+## Hooks de contenedores
+
+Hay dos hooks expuestos en los contenedores:
+
+`PostStart`
+
+Este hook se ejecuta inmediatamente después de crear un contenedor.
+Sin embargo, no es posible garantizar que el hook se ejecute antes del ENTRYPOINT del contenedor.
+No se le pasa ningún parámetro.
+
+`PreStop`
+
+Este hook se llama inmediatamente antes de que se finalice un contenedor debido a una solicitud de API o evento de gestión como un fallo liveness, o contención de recursos entre otros. Una llamada al hook de Prestop falla si el contenedor ya está en estado terminated (finalizado) o completed (completado).
+Es bloqueante, lo que significa que es sincrónico,
+por lo que debe completarse antes de que la llamada para eliminar el contenedor pueda ser enviada.
+No se le pasa ningún parámetro.
+
+Puedes encontrar información más detallada sobre el comportamiento de finalización de un contenedor
+[Finalización de Pods](/docs/es/concepts/workloads/pods/pod/#termination-of-pods).
+
+### Implementación de controladores de hooks
+
+Los contenedores pueden acceder a un hook implementando y registrado en un controlador de este hook.
+Hay dos tipos de controladores de hooks que se pueden implementar para los contenedores:
+
+* Exec: ejecuta un comando específico, como `pre-stop.sh`, dentro de cgroups y namespaces del contenedor.
+Los recursos consumidos por el comando serán tomados en cuenta para el contenedor.
+* HTTP: ejecuta una petición HTTP contra un endpoint específico dentro del contenedor.
+
+### Ejecución de controladores de hooks
+
+Cuando se llama un hook de gestión de ciclo de vida de un contenedor,
+el sistema de gestión de Kubernetes ejecuta el controlador en el contenedor registrado para este hook.
+
+Las llamadas al controlador de hooks son síncronas dentro del contexto del Pod que contiene el contenedor.
+Esto significa que para un hook `PostStart`,
+el ENTRYPOINT del contenedor y el hook se disparan de forma asíncrona.
+Sin embargo, si el hook tarda demasiado en ejecutarse o se cuelga,
+el contenedor no puede alcanzar el estado de `running` (en ejecución).
+
+El comportamiento es similar para un hook `PreStop`.
+Si el hook se cuelga durante la ejecución,
+la fase del Pod permanece en un estado de `terminating` (finalizando) y se cancela después del `terminationGracePeriodSeconds` (finalización después del periodo de gracia) del pod en cuestión.
+Si un hook `PostStart` o` PreStop` falla, se mata el contenedor.
+
+Los usuarios deben hacer que sus controladores de hooks sean lo más livianos posible.
+Hay casos, sin embargo, que los comandos de larga ejecución tienen sentido,
+como cuando se guarda el estado antes de detener un contenedor.
+
+### Garantías de entrega de hooks
+
+La entrega de un hook está destinada a ser enviada *al menos una vez*,
+lo que significa que un hook puede ser llamado varias veces para cualquier evento dado,
+tanto para `PostStart` como para ` PreStop`.
+Depende de la implementación del hook manejar esto correctamente.
+
+En general, solo se realizan entregas individuales.
+Si, por ejemplo, un receptor hook HTTP está inactivo y no puede recibir tráfico,
+no hay ningún reintento.
+Sin embargo, en algunos casos puede ocurrir una doble entrega.
+Por ejemplo, si un Kubelet se reinicia durante la ejecución de envio de un hook,
+el hook puede volver a enviarse después de que el kubelet se levante.
+
+
+### Depurando controladores de hooks
+
+Los logs de un controlador de hooks no son expuestos en los eventos del Pod.
+Si un controlador falla por alguna razón, emite un evento.
+Para `PostStart`, es el evento `FailedPostStartHook`,
+y para `PreStop`, el evento `FailedPreStopHook`.
+Puedes ver que eventos están en ejecución con el comando `kubectl describe pod `.
+El siguiente ejemplo muestra los eventos en ejecución a través del comando anterior:
+
+```
+Events:
+ FirstSeen LastSeen Count From SubobjectPath Type Reason Message
+ --------- -------- ----- ---- ------------- -------- ------ -------
+ 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
+ 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
+ 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
+ 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
+ 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
+ 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
+ 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
+ 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
+ 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* Aprende más sobre [variables de entorno de contenedores](/docs/concepts/containers/container-environment-variables/).
+* Practica
+ [adjuntando controladores a los eventos de lifecycle de los contenedores](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
+
+{{% /capture %}}
diff --git a/content/es/docs/reference/glossary/kube-proxy.md b/content/es/docs/reference/glossary/kube-proxy.md
new file mode 100755
index 0000000000..df2efc923d
--- /dev/null
+++ b/content/es/docs/reference/glossary/kube-proxy.md
@@ -0,0 +1,25 @@
+---
+title: kube-proxy
+id: kube-proxy
+date: 2018-04-12
+full_link: /docs/reference/command-line-tools-reference/kube-proxy/
+short_description: >
+ `kube-proxy` es un componente de red que se ejecuta en cada nodo del clúster.
+
+aka:
+tags:
+- fundamental
+- networking
+---
+[kube-proxy](/es/docs/reference/command-line-tools-reference/kube-proxy/) es un
+componente de red que se ejecuta en cada uno de los nodos del clúster, implementando
+parte del concepto de Kubernetes {{< glossary_tooltip term_id="service">}}.
+
+
+
+kube-proxy mantiene las reglas de red en los nodos, permitiendo la
+comunicación entre sus Pods desde las sesiones de red dentro o fuera
+del clúster.
+
+kube-proxy usa la capa de filtrado de paquetes del sistema operativo si la hay
+y está disponible; de lo contrario, kube-proxy reenvía el tráfico por sí mismo.
diff --git a/content/es/docs/reference/glossary/persistent-volume-claim.md b/content/es/docs/reference/glossary/persistent-volume-claim.md
new file mode 100755
index 0000000000..246a5be6d5
--- /dev/null
+++ b/content/es/docs/reference/glossary/persistent-volume-claim.md
@@ -0,0 +1,18 @@
+---
+title: Persistent Volume Claim
+id: persistent-volume-claim
+date: 2018-04-12
+full_link: /docs/concepts/storage/persistent-volumes/
+short_description: >
+ Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor.
+
+aka:
+tags:
+- core-object
+- storage
+---
+ Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor.
+
+
+
+Especifica la cantidad de almacenamiento, cómo acceder a él (sólo lectura, lectura y escritura y/o exclusivo) y qué hacer una vez eliminemos el PersistentVolumeClaim (mantener, reciclar o eliminar). Los detalles sobre almacenamiento están disponibles en la especificación de PersistentVolume.
diff --git a/content/fr/community/_index.html b/content/fr/community/_index.html
new file mode 100644
index 0000000000..7603accf7c
--- /dev/null
+++ b/content/fr/community/_index.html
@@ -0,0 +1,237 @@
+---
+title: Communauté
+layout: basic
+cid: community
+---
+
+
+
+
+La communauté Kubernetes -- les utilisateurs, les contributeurs ainsi que la culture que nous avons bâtie ensemble -- est l'une des principales raisons de la popularité fulgurante de ce projet open source. Notre culture et nos valeurs continuent de croître et de changer au fur et à mesure que le projet lui-même grandit et change. Nous travaillons tous ensemble à l'amélioration constante du projet et de la façon dont nous y travaillons.
+
Nous sommes les personnes qui déposent les problèmes (issues) et les demandes de changements (pull requests), assistent aux réunions de SIG, aux réunions de Kubernetes et la KubeCon, plaident pour son adoption et son innovation, lancent kubectl get pods
, et contribuent de mille autres manières toutes aussi vitales. Lisez ce qui suit pour savoir comment vous pouvez vous impliquer et faire partie de cette incroyable communauté.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vidéos
+
+Nous sommes souvent sur YouTube. Abonnez-vous pour un large éventail de sujets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Discussions
+
+Nous parlons beaucoup ! Rejoignez-nous et prenez part à la conversation sur n'importe laquelle des ces plateformes.
+
+
+
+
+
+
+forum ▶
+
+
+Discussions techniques par thématiques qui établissent un pont entre les docs, StackOverflow, et plus encore
+
+
+
+
+
+
+twitter ▶
+
+
+Annonces en temps réel d'articles de blog, d'événements, d'actualités, d'idées
+
+
+
+
+
+
+github ▶
+
+
+Tout le projet ainsi que les issues et bien évidemment le code
+
+
+
+
+
+
+stack overflow ▶
+
+
+
+
+
+
+
+
+
+
+
+
+ Événements À Venir
+ {{< upcoming-events >}}
+
+
+
+
+
+
+Communauté Mondiale
+Avec plus de 150 meetups dans le monde et toujours plus, allez trouver les gens de votre région qui comme vous, s'intéressent à Kubernetes. Si vous n'avez pas de meetup à proximité, prenez les choses en main et créez le vôtre.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/content/fr/community/code-of-conduct.md b/content/fr/community/code-of-conduct.md
new file mode 100644
index 0000000000..82204af8da
--- /dev/null
+++ b/content/fr/community/code-of-conduct.md
@@ -0,0 +1,26 @@
+---
+title: Communauté
+layout: basic
+cid: community
+css: /css/community.css
+---
+
+
+
+
+Code de conduite de la communauté Kubernetes
+
+Kubernetes suit le
+Code de Conduite de la CNCF.
+Le texte du CdC de la CNCF est reproduit ci-dessous
+commit 214585e.
+Si vous remarquez que ce document n'est plus à jour, n'hésitez pas à
+créer une issue.
+
+
+Si vous remarquez une violation du Code de conduite lors d'un événement ou d'une réunion, sur Slack, ou sur tout autre mécanisme de communication, contactez le Comité du Code de conduite de Kubernetes.
+Vous pouvez nous joindre par courriel à conduct@kubernetes.io.
+Votre anonymat sera protégé.
+
+
+{{< include "/static/cncf-code-of-conduct.md" >}}
+
+
diff --git a/content/fr/community/static/README.md b/content/fr/community/static/README.md
new file mode 100644
index 0000000000..cadc3f649c
--- /dev/null
+++ b/content/fr/community/static/README.md
@@ -0,0 +1,2 @@
+Les fichiers présents dans ce dossier on été importés depuis une autre source.
+Veuillez ne pas les éditer directement sauf en les remplaçant par une nouvelle version.
\ No newline at end of file
diff --git a/content/fr/community/static/cncf-code-of-conduct.md b/content/fr/community/static/cncf-code-of-conduct.md
new file mode 100644
index 0000000000..32db3dbcc1
--- /dev/null
+++ b/content/fr/community/static/cncf-code-of-conduct.md
@@ -0,0 +1,31 @@
+
+Code de conduite de la communauté de la CNCF v1.0
+-------------------------------------------------
+
+### Code de conduite des contributeurs
+
+En tant que contributeurs et éditeurs dans le cadre de ce projet, et afin d’encourager le développement d’une communauté ouverte et accueillante, nous nous engageons à respecter chaque personne qui apporte sa contribution en signalant des problèmes, en publiant des suggestions de fonctionnalités, en mettant à jour la documentation, en envoyant des demandes de tirage ou sous une autre forme.
+
+Nous mettons tout en œuvre afin que la participation à ce projet ne soit source de désagrément pour personne, quel que soit le niveau d’expérience, le sexe, l’identité, l’expression ou l’orientation sexuelle, le handicap, l’apparence physique, la taille et/ou le poids, l’origine ethnique, l’âge, la religion ou la nationalité des personnes qui y participent.
+
+Voici quelques exemples de comportements qui ne seront pas acceptés de la part des participants:
+
+- l’utilisation de propos ou d’images à caractère sexuel ;
+- les critiques personnelles ;
+- les commentaires provocateurs, insultants ou péjoratifs ;
+- le harcèlement en public ou en privé ;
+- la publication, sans autorisation expresse, d’informations privées de tiers, telles que l’adresse postale ou l’adresse e-mail ;
+- tout autre comportement contraire à l’éthique ou non professionnel.
+
+Les éditeurs du projet ont le droit et la responsabilité de retirer, modifier ou rejeter les commentaires, les validations, le code, les modifications de wiki, les problèmes et toute autre contribution qui ne respecte pas ce Code de conduite. En adoptant ce Code de conduite, les éditeurs du projet s’engagent eux-mêmes à appliquer ces principes de manière juste et systématique dans tous les aspects de la gestion du projet. Les éditeurs du projet qui ne respectent pas le Code de conduite ou ne le font pas respecter pourront être retirés définitivement de l’équipe du projet.
+
+Ce Code de conduite s’applique à la fois dans le cadre du projet et dans le cadre public, lorsqu’une personne représente le projet ou la communauté.
+
+Des cas de conduite abusive, de harcèlement ou autre pratique inacceptable ayant cours sur Kubernetes peuvent être signalés en contactant le [comité pour le code de conduite de Kubernetes](https://git.k8s.io/community/committee-code-of-conduct) via l'adresse . Pour d'autres projets, bien vouloir contacter un responsable de projet CNCF ou notre médiateur, Mishi Choudhary à l'adresse .
+
+Ce Code de conduite est inspiré du « Contributor Covenant » (http://contributor-covenant.org) version 1.2.0, disponible à l’adresse http://contributor-covenant.org/version/1/2/0/.
+
+### Code de conduite pour les événements de la CNCF
+
+Les événements de la CNCF sont régis par le Code de conduite de The Linux Foundation, disponible sur la page des événements. Ce Code est compatible avec la politique ci-dessus et inclut davantage de détails sur la façon de gérer les incidents.
\ No newline at end of file
diff --git a/content/fr/docs/contribute/participating.md b/content/fr/docs/contribute/participating.md
new file mode 100644
index 0000000000..455106d448
--- /dev/null
+++ b/content/fr/docs/contribute/participating.md
@@ -0,0 +1,206 @@
+---
+title: Participez au SIG Docs
+content_template: templates/concept
+card:
+ name: contribute
+ weight: 40
+---
+
+{{% capture overview %}}
+
+SIG Docs est l'un des [groupes d'intérêts spéciaux](https://github.com/kubernetes/community/blob/master/sig-list.md) au sein du projet Kubernetes, axé sur la rédaction, la mise à jour et la maintenance de la documentation de Kubernetes dans son ensemble.
+Pour plus d'informations sur le SIG consultez [le dépôt GitHub de la communauté](https://github.com/kubernetes/community/tree/master/sig-docs).
+
+SIG Docs accueille le contenu et les critiques de tous les contributeurs.
+Tout le monde peut ouvrir une pull request (PR), et tout le monde est invité à déposer des questions sur le contenu ou à commenter les pull requests ouvertes.
+
+Dans SIG Docs, vous pouvez aussi devenir un [membre](#membres), [relecteur](#reviewers), ou [approbateur](#approvers).
+Ces rôles nécessitent un plus grand accès et impliquent certaines responsabilités pour approuver et valider les changements.
+Voir [appartenance à la communauté](https://github.com/kubernetes/community/blob/master/community-membership.md) pour plus d'informations sur le fonctionnement de l'adhésion au sein de la communauté Kubernetes.
+Le reste de ce document décrit certaines fonctions uniques de ces rôles au sein du SIG Docs, responsable de la gestion de l’un des aspects les plus accessibles du public de Kubernetes: le site Web et la documentation de Kubernetes.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Rôles et responsabilités
+
+Lorsqu'une pull request est mergée à la branche utilisée pour publier le contenu (actuellement `master`), ce contenu est publié et disponible dans le monde entier.
+Pour nous assurer que la qualité de notre contenu publié est élevée, nous limitons aux approbateurs SIG Docs le droit de merger des pull requests.
+Voici comment ça fonctionne.
+
+- Lorsqu'une pull request a les deux labels `lgtm` et `approve` et n'a pas de label `hold`, la pull request est mergée automatiquement.
+- Les membres de l'organisation Kubernetes et les approbateurs SIG Docs peuvent ajouter des commentaires à une pull request ou empêcher le merge automatique d'une pull request donnée (en ajoutant un commentaire `/hold` ou en retirant un commentaire `/lgtm`).
+- Tout membre de Kubernetes peut ajouter le label `lgtm`, en ajoutant un commentaire `/lgtm`.
+- Seul un approbateur membre de SIG Docs peut causer le merge d'une pull request en ajoutant un commentaire `/approve`.
+ Certains approbateurs remplissent également des rôles spécifiques supplémentaires, tels que [PR Wrangler](#pr-wrangler) or [président(e) du SIG Docs](#sig-docs-chairperson).
+
+Pour plus d'informations sur les attentes et les différences entre les rôles de membre d'organisation Kubernetes et d'approbateurs SIG Docs, voir [Types de contributeur](/docs/contribute#types-of-contributor).
+Les sections suivantes couvrent plus de détails sur ces rôles et leur fonctionnement dans SIG-Docs.
+
+### N'importe qui
+
+Tout le monde peut ouvrir un ticket sur n'importe quelle partie de Kubernetes, y compris la documentation.
+
+Toute personne ayant signé le CLA peut ouvrir une Pull Request.
+Si vous ne pouvez pas signer le CLA, le projet Kubernetes ne peut pas accepter votre contribution.
+
+### Membres
+
+Tout membre de l'[organisation Kubernetes](https://github.com/kubernetes) peut faire une revue d'une pull request, et SIG Docs les membres de l’équipe demandent fréquemment aux membres d’autres SIG d’être révisés pour des raisons de précision technique.
+SIG Docs accueille également des critiques et des commentaires indépendamment du statut de membre d'une personne dans l'organisation Kubernetes.
+Vous pouvez indiquer votre approbation en ajoutant un commentaire de `/lgtm` à une pull request.
+Si vous n'êtes pas membre de l'organisation Kubernetes, votre `/lgtm` n'a aucun effet sur les systèmes automatisés.
+
+Tout membre de l’organisation Kubernetes peut ajouter un commentaire `/ hold` pour empêcher la pull request d'être mergée.
+Tout membre peut également supprimer un commentaire `/hold` pour merger une PR s'il a déjà les deux commentaires `/lgtm` et `/approve` appliqué par les personnes appropriées.
+
+#### Devenir membre
+
+Après avoir soumis avec succès au moins 5 pull requests significatives, vous pouvez demander l'[adhésion](https://github.com/kubernetes/community/blob/master/community-membership.md#member) dans l'organisation Kubernetes.
+Suivez ces étapes:
+
+1. Trouvez deux relecteurs ou approbateurs pour [parrainer](/docs/contribute/advanced#sponsor-a-new-contributor) votre adhésion.
+
+ Demander un parrainage dans le [canal #sig-docs sur l'instance de Kubernetes Slack](https://kubernetes.slack.com) ou sur la [mailing list SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+ {{< note >}}
+ N'envoyez pas de courrier électronique direct ou de message direct Slack à un membre individuel de SIG Docs.
+ {{< /note >}}
+
+2. Ouvrez un ticket Github dans le dépôt `kubernetes/org` pour adhérer à l'organisation.
+ Remplissez le modèle en suivant les directives de l'[Adhésion à la communauté](https://github.com/kubernetes/community/blob/master/community-membership.md).
+
+3. Informez vos sponsors du ticket Github, soit en les mentionnant dans le ticket Github (en ajoutant un commentaire avec `@`) ou en leur envoyant directement le lien, afin qu’ils puissent ajouter un vote `+ 1`.
+
+4. Lorsque votre adhésion est approuvée, le membre de l'équipe d'administration github affecté à votre demande met à jour le ticket Github pour indiquer son approbation, puis ferme le ticket Github.
+ Félicitations, vous êtes maintenant membre!
+
+Si, pour une raison quelconque, votre demande d'adhésion n'est pas acceptée immédiatement, le comité des membres fournit des informations ou des mesures à prendre avant de présenter une nouvelle demande.
+
+### Relecteurs
+
+Les relecteurs sont membres du groupe Github [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews).
+Voir [Equipes et groupes au sein de SIG Docs](#teams-and-groups-within-sig-docs).
+
+Les relecteurs examinent les Pull Request de documentation et font des commentaires sur les changements proposés.
+
+L'automatisation assigne des relecteurs aux pull requets, et les contributeurs peuvent demander une revue d'un relecteur spécifique en laissant un commentaire tel que: `/assign [@_github_handle]`.
+Pour indiquer qu'une pull request est techniquement exacte et ne nécessite aucune modification supplémentaire, un examinateur ajoute un commentaire `/lgtm` à la Pull Request.
+
+Si le relecteur affecté n'a pas encore revu le contenu, un autre relecteur peut intervenir.
+En outre, vous pouvez affecter des relecteurs techniques et attendre qu'ils fournissent des `/lgtm`.
+
+Pour un changement trivial ou ne nécessitant aucun examen technique, l'[approbateur](#approvers) SIG Docs peut fournir le `/lgtm` aussi.
+
+Un commentaire `/approve` d'un relecteur est ignoré par l'automatisation.
+
+Pour en savoir plus sur comment devenir un relecteur SIG Docs et sur les responsabilités et l’engagement de temps que cela implique, voir [Devenir relecteur ou approbateur](#becoming-an-approver-or-reviewer).
+
+#### Devenir relecteur
+
+Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), vous pouvez devenir un relecteur SIG Docs.
+Les relecteurs d'autres SIG doivent demander séparément le statut de relecteur dans le SIG Docs.
+
+Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépôt `kubernetes/website`.
+Affectez la PR à un ou plusieurs approbateurs SIG Docs.
+
+Si votre pull request est approuvé, vous êtes maintenant un relecteur SIG Docs.
+[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) vous assignera et vous suggérera en tant que relecteur pour les nouvelles Pull Requests.
+
+Si vous êtes approuvé, demandez qu’un approbateur SIG Docs en cours vous ajoute au groupe Github [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews).
+Seuls les membres du groupe Github `kubernetes-website-admins` peuvent ajouter de nouveaux membres à un groupe Github.
+
+### Approbateurs
+
+Les approbateurs sont membres du groupe Github [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers).
+Voir [Equipes et groupes au sein de SIG Docs](#teams-and-groups-within-sig-docs).
+
+Les approbateurs ont la capacité de merger une PR, et ainsi, publier du contenu sur le site Web de Kubernetes.
+Pour approuver une PR, un approbateur laisse un commentaire `/approve` sur la PR.
+Si quelqu'un qui n'est pas un approbateur laisse le commentaire d'approbation, l'automatisation l'ignore.
+
+Si la PR a déjà un `/lgtm`, ou si l'approbateur fait également des commentaires avec `/lgtm`, la PR est mergée automatiquement.
+Un approbateur SIG Docs ne doit laisser qu'un `/lgtm` sur un changement qui ne nécessite pas de relecture supplémentaire.
+
+Pour en savoir plus sur comment devenir un approbateur SIG Docs et sur les responsabilités et l’engagement de temps que cela implique, voir [Devenir relecteur ou approbateur](#becoming-an-approver-or-reviewer).
+
+#### Devenir approbateur
+
+Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), vous pouvez devenir un approbateur SIG Docs.
+Les approbateurs appartenant à d'autres SIG doivent demander séparément le statut d'approbateur dans SIG Docs.
+
+Pour postuler, ouvrez une pull request pour vous ajouter à la section `approvers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépot `kubernetes/website`.
+Affectez la PR à un ou plusieurs approbateurs SIG Docs.
+
+Si votre Pull Request est approuvée, vous êtes à présent approbateur SIG Docs.
+Le [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) vous assignera et vous suggérera en tant que relecteur pour les nouvelles Pull Requests.
+
+Si vous êtes approuvé, demandez qu’un approbateur SIG Docs en cours vous ajoute au groupe Github [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers).
+Seuls les membres du groupe Github `kubernetes-website-admins` peuvent ajouter de nouveaux membres à un groupe Github.
+
+#### Devenir un administrateur de site Web
+
+Les membres du groupe GitHub `kubernetes-website-admins` peut gérer l’appartenance au groupe Github et disposer de tous les droits administratifs sur les paramètres du dépôt, y compris la possibilité d'ajouter, de supprimer et de debugger des Webhooks.
+Tous les approbateurs SIG Docs n'ont pas besoin de ce niveau d'accès.
+
+Si vous pensez avoir besoin de ce niveau d’accès, adressez-vous à un administrateur de site Web existant ou posez la question dans le canal Slack [#sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/).
+
+#### Auxiliaires de traitement des Pull Requests
+
+Les approbateurs SIG Docs sont ajoutés au [calendrier de rotations des auxiliaires de traitement des PullRequests](https://github.com/kubernetes/website/wiki/PR-Wranglers) pour les rotations hebdomadaires.
+Tous les approbateurs SIG Docs devraient participer à cette rotation.
+Voir [Soyez l'auxiliaire des PR pendant une semaine](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) pour plus de détails.
+
+#### Présidence du SIG Docs
+
+Chaque SIG, y compris SIG Docs, sélectionne un ou plusieurs membres du SIG qui assumeront les fonctions de président(e).
+Ce sont des points de contact entre SIG Docs et d’autres parties de l’organisation Kubernetes.
+Ils nécessitent une connaissance approfondie de la structure du projet Kubernetes dans son ensemble et du fonctionnement de SIG Docs au sein de celui-ci.
+Voir [Direction](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) pour la liste actuelle des président(e)s.
+
+## Equipes SIG Docs et automatisation
+
+L'automatisation dans SIG Docs repose sur deux mécanismes différents:
+Groupes Github et fichiers OWNERS.
+
+### Groupes Github
+
+Le groupe SIG Docs définit deux équipes sur 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)
+
+Chacun peut être référencé avec son `@name` dans Github, commentez pour communiquer avec tous les membres de ce groupe.
+
+Ces équipes peuvent avoir des membres en commun.
+Pour l'affectation des tickets, des pull requests, et aider la validation des PR, l'automatisation utilise les informations des fichiers OWNERS.
+
+### OWNERS files et front-matter
+
+Le projet Kubernetes utilise un outil d'automatisation appelé prow pour l'automatisation liée aux Github issues et aux pull requests.
+Le [dépôt du site web Kubernetes](https://github.com/kubernetes/website) utilise deux [plugins prow](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210):
+
+- blunderbuss
+- approve
+
+Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne.
+
+Un fichier [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs.
+Les fichiers OWNERS existent aussi dans les sous-dossiers, et peut ignorer qui peut agir en tant que relecteur ou approbateur des fichiers de ce sous-répertoire et de ses descendants.
+Pour plus d'informations sur les fichiers OWNERS en général, voir [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
+
+En outre, un fichier Markdown individuel peut répertorier les relecteurs et les approbateurs dans l'entête, soit en répertoriant les noms d’utilisateur ou les groupes de Github.
+
+La combinaison des fichiers `OWNERS` et des entêtes dans les fichiers Markdown determinent les suggestions automatiques de relecteurs dans la PullRequest.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+Pour plus d'informations sur la contribution à la documentation Kubernetes, voir:
+
+- [Commencez à contribuer](/docs/contribute/start/)
+- [Documentation style](/docs/contribute/style/)
+
+{{% /capture %}}
diff --git a/content/fr/docs/reference/glossary/cri.md b/content/fr/docs/reference/glossary/cri.md
new file mode 100644
index 0000000000..f134b93b3f
--- /dev/null
+++ b/content/fr/docs/reference/glossary/cri.md
@@ -0,0 +1,17 @@
+---
+title: Container Runtime Interface (CRI)
+id: cri
+date: 2019-03-07
+full_link: https://kubernetes.io/docs/concepts/overview/components/#container-runtime
+short_description: >
+ Une API pour les runtimes de conteneurs à intégrer avec kubelet
+
+
+aka:
+tags:
+- fundamental
+---
+L'interface d'exécution de conteneur (CRI, de l'anglais Container Runtime Interface) est une API pour les runtimes de conteneurs à intégrer avec kubelet, sur un nœud.
+
+
+Pour plus d'informations, se référer aux spécificités de l'API [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
diff --git a/content/fr/docs/setup/custom-cloud/kubespray.md b/content/fr/docs/setup/custom-cloud/kubespray.md
index 66815b085b..0568cb2a1a 100644
--- a/content/fr/docs/setup/custom-cloud/kubespray.md
+++ b/content/fr/docs/setup/custom-cloud/kubespray.md
@@ -90,7 +90,7 @@ Kubespray fournit le moyen de vérifier la connectivité inter-pods ainsi que la
Les pods netchecker-agents s'assurent que la résolution DNS (services Kubernetes) ainsi que le ping entre les pods fonctionnent correctement.
Ces pods reproduisent un comportement similaire à celui des autres applications et offrent un indicateur de santé du cluster.
-## Opérations sur le clutser
+## Opérations sur le cluster
Kubespray fournit des playbooks supplémentaires qui permettent de gérer votre cluster: _scale_ et _upgrade_.
diff --git a/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md
new file mode 100644
index 0000000000..11aab62fd2
--- /dev/null
+++ b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -0,0 +1,259 @@
+---
+title: Configurer la qualité de service pour les pods
+content_template: templates/task
+weight: 30
+---
+
+
+{{% capture overview %}}
+
+Cette page montre comment configurer les Pods pour qu'ils soient affectés à des classes particulières de qualité de service (QoS). Kubernetes utilise des classes de QoS pour prendre des décisions concernant l'ordonnancement et les évictions des pods.
+
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+
+{{% capture steps %}}
+
+## Les Classes de QoS
+
+Quand Kubernetes crée un Pod, il affecte une de ces classes QoS au Pod :
+
+* Guaranteed
+* Burstable
+* BestEffort
+
+## Créez un namespace
+
+Créez un namespace de manière à ce que les ressources que vous créez dans cet exercice soient isolées du reste de votre cluster.
+
+```shell
+kubectl create namespace qos-example
+```
+
+## Créez un Pod qui se fait attribuer une classe QoS de Guaranteed
+
+Pour qu'un Pod reçoive une classe de QoS Guaranteed :
+
+* Chaque conteneur du Pod doit avoir une limite de mémoire et une demande de mémoire, et elles doivent être les mêmes.
+* Chaque conteneur dans le Pod doit avoir une limite CPU et une demande CPU, et ils doivent être les mêmes.
+
+Ci-dessous le fichier de configuration d'un Pod qui a un seul conteneur.
+Le conteneur dispose d'une limite de mémoire et d'une demande de mémoire, tous deux égaux à 200 MiB. Le conteneur a également une limite CPU et une demande CPU, toutes deux égales à 700 milliCPU :
+
+{{< codenew file="pods/qos/qos-pod.yaml" >}}
+
+Créez le Pod :
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example
+```
+
+Consultez des informations détaillées sur le Pod :
+
+```shell
+kubectl get pod qos-demo --namespace=qos-example --output=yaml
+```
+
+Le résultat indique que Kubernetes a donné au pod une classe de qualité de service de type Guaranteed. De plus, il affiche que la demande de mémoire du conteneur du pod correspond à sa limite de mémoire, et que la demande de CPU correspond à sa limite de CPU.
+
+```yaml
+spec:
+ containers:
+ ...
+ resources:
+ limits:
+ cpu: 700m
+ memory: 200Mi
+ requests:
+ cpu: 700m
+ memory: 200Mi
+...
+ qosClass: Guaranteed
+```
+
+{{< note >}}
+Si un conteneur spécifie sa propre limite de mémoire, mais ne spécifie pas de demande de mémoire, Kubernetes attribue automatiquement une demande de mémoire correspondant à la limite. De même, si un conteneur spécifie sa propre limite CPU, mais ne spécifie pas de demande de CPU, Kubernetes lui attribue automatiquement une demande de CPU qui correspond à cette limite.
+{{< /note >}}
+
+Supprimez votre Pod :
+
+```shell
+kubectl delete pod qos-demo --namespace=qos-example
+```
+
+## Créez un Pod qui se fait attribuer une classe QoS de type Burstable
+
+Un Pod reçoit une classe QoS de Burstable si :
+
+* Le Pod ne répond pas aux critères de la classe QoS Guaranteed.
+* Au moins un conteneur dans le Pod dispose d'une demande de mémoire ou de CPU.
+
+Voici le fichier de configuration d'un pod qui a un seul conteneur. Le conteneur a une limite de mémoire de 200 MiB et une demande de mémoire de 100 MiB.
+
+{{< codenew file="pods/qos/qos-pod-2.yaml" >}}
+
+Créez le Pod :
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example
+```
+
+Consultez des informations détaillées sur le Pod :
+
+```shell
+kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml
+```
+
+La sortie montre que Kubernetes a accordé au pod une classe QoS de type Burstable.
+```yaml
+spec:
+ containers:
+ - image: nginx
+ imagePullPolicy: Always
+ name: qos-demo-2-ctr
+ resources:
+ limits:
+ memory: 200Mi
+ requests:
+ memory: 100Mi
+...
+ qosClass: Burstable
+```
+
+Supprimez votre Pod :
+
+```shell
+kubectl delete pod qos-demo-2 --namespace=qos-example
+```
+
+## Créez un Pod qui se fait attribuer une classe QoS de type BestEffort
+
+Pour qu'un pod puisse avoir la classe QoS de BestEffort, les conteneurs dans le pod ne doivent pas
+avoir des limites ou des demandes de mémoire ou de CPU.
+
+Voici le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur n'a pas des limites ou des demandes de mémoire ou de CPU :
+
+{{< codenew file="pods/qos/qos-pod-3.yaml" >}}
+
+Créez le Pod :
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example
+```
+
+Consultez des informations détaillées sur le Pod :
+
+```shell
+kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml
+```
+
+Le résultat montre que Kubernetes a accordé au pod une classe QoS de BestEffort.
+
+```yaml
+spec:
+ containers:
+ ...
+ resources: {}
+ ...
+ qosClass: BestEffort
+```
+
+Supprimez votre Pod :
+
+```shell
+kubectl delete pod qos-demo-3 --namespace=qos-example
+```
+
+## Créez un pod qui contient deux conteneurs
+
+
+Voici le fichier de configuration d'un Pod qui a deux conteneurs. Un conteneur spécifie une
+demande de mémoire de 200 MiB. L'autre conteneur ne spécifie aucune demande ou limite.
+
+{{< codenew file="pods/qos/qos-pod-4.yaml" >}}
+
+Notez que le pod répond aux critères de la classe QoS Burstable. En d'autres termes, il ne répond pas aux exigences de la classe de qualité de service Guaranteed, et l'un de ses conteneurs dispose d'une demande de mémoire.
+
+Créez le Pod :
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example
+```
+
+Consultez des informations détaillées sur le Pod :
+
+```shell
+kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml
+```
+
+Le résultat montre que Kubernetes a accordé au pod une classe QoS de Burstable:
+
+```yaml
+spec:
+ containers:
+ ...
+ name: qos-demo-4-ctr-1
+ resources:
+ requests:
+ memory: 200Mi
+ ...
+ name: qos-demo-4-ctr-2
+ resources: {}
+ ...
+ qosClass: Burstable
+```
+
+Supprimez votre pod :
+
+```shell
+kubectl delete pod qos-demo-4 --namespace=qos-example
+```
+
+## Nettoyage
+
+Supprimez votre namespace.
+
+```shell
+kubectl delete namespace qos-example
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+
+### Pour les développeurs d'applications
+
+* [Allocation des ressources CPU aux conteneurs et pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+
+* [Allocation des ressources mémoire aux conteneurs et pods](/fr/docs/tasks/configure-pod-container/assign-memory-resource/)
+
+
+### Pour les administrateurs de cluster
+
+* [Configuration des demandes et des limites de mémoire par défaut pour un Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
+
+* [Configuration des demandes et des limites par défaut de CPU pour un Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
+
+* [Configuration des contraintes de mémoire minimales et maximales pour un Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
+
+* [Configuration des contraintes minimales et maximales du CPU pour un Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
+
+* [Configuration des quotas de mémoire et de CPU pour un Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
+
+* [Configuration du quota de pods pour un Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
+
+* [Configuration des quotas pour les objets API](/docs/tasks/administer-cluster/quota-api-object/)
+{{% /capture %}}
+
+
+
+
+
diff --git a/content/fr/examples/pods/qos/qos-pod-2.yaml b/content/fr/examples/pods/qos/qos-pod-2.yaml
new file mode 100644
index 0000000000..115d4de21e
--- /dev/null
+++ b/content/fr/examples/pods/qos/qos-pod-2.yaml
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: qos-demo-2
+ namespace: qos-example
+spec:
+ containers:
+ - name: qos-demo-2-ctr
+ image: nginx
+ resources:
+ limits:
+ memory: "200Mi"
+ requests:
+ memory: "100Mi"
diff --git a/content/fr/examples/pods/qos/qos-pod-3.yaml b/content/fr/examples/pods/qos/qos-pod-3.yaml
new file mode 100644
index 0000000000..dac3629942
--- /dev/null
+++ b/content/fr/examples/pods/qos/qos-pod-3.yaml
@@ -0,0 +1,9 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: qos-demo-3
+ namespace: qos-example
+spec:
+ containers:
+ - name: qos-demo-3-ctr
+ image: nginx
diff --git a/content/fr/examples/pods/qos/qos-pod-4.yaml b/content/fr/examples/pods/qos/qos-pod-4.yaml
new file mode 100644
index 0000000000..d4818b277e
--- /dev/null
+++ b/content/fr/examples/pods/qos/qos-pod-4.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: qos-demo-4
+ namespace: qos-example
+spec:
+ containers:
+
+ - name: qos-demo-4-ctr-1
+ image: nginx
+ resources:
+ requests:
+ memory: "200Mi"
+
+ - name: qos-demo-4-ctr-2
+ image: redis
diff --git a/content/fr/examples/pods/qos/qos-pod.yaml b/content/fr/examples/pods/qos/qos-pod.yaml
new file mode 100644
index 0000000000..b4a6b1ea82
--- /dev/null
+++ b/content/fr/examples/pods/qos/qos-pod.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: qos-demo
+ namespace: qos-example
+spec:
+ containers:
+ - name: qos-demo-ctr
+ image: nginx
+ resources:
+ limits:
+ memory: "200Mi"
+ cpu: "700m"
+ requests:
+ memory: "200Mi"
+ cpu: "700m"
diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md
new file mode 100644
index 0000000000..0d9ab08793
--- /dev/null
+++ b/content/id/docs/concepts/cluster-administration/logging.md
@@ -0,0 +1,198 @@
+---
+title: Arsitektur Logging
+content_template: templates/concept
+weight: 60
+---
+
+{{% capture overview %}}
+
+Log aplikasi dan sistem dapat membantu kamu untuk memahami apa yang terjadi di dalam kluster kamu. Log berguna untuk mengidentifikasi dan menyelesaikan masalah serta memonitor aktivitas kluster. Hampir semua aplikasi modern mempunyai sejenis mekanisme log sehingga hampir semua mesin kontainer didesain untuk mendukung suatu mekanisme _logging_. Metode _logging_ yang paling mudah untuk aplikasi dalam bentuk kontainer adalah menggunakan _standard output_ dan _standard error_.
+
+Namun, fungsionalitas bawaan dari mesin kontainer atau _runtime_ biasanya tidak cukup memadai sebagai solusi log. Contohnya, jika sebuah kontainer gagal, sebuah pod dihapus, atau suatu _node_ mati, kamu biasanya tetap menginginkan untuk mengakses log dari aplikasimu. Oleh sebab itu, log sebaiknya berada pada penyimpanan dan _lifecyle_ yang terpisah dari node, pod, atau kontainer. Konsep ini dinamakan sebagai _logging_ pada level kluster. _Logging_ pada level kluster ini membutuhkan _backend_ yang terpisah untuk menyimpan, menganalisis, dan mengkueri log. Kubernetes tidak menyediakan solusi bawaan untuk penyimpanan data log, namun kamu dapat mengintegrasikan beragam solusi _logging_ yang telah ada ke dalam kluster Kubernetes kamu.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+Arsitektur _logging_ pada level kluster yang akan dijelaskan berikut mengasumsikan bahwa sebuah _logging backend_ telah tersedia baik di dalam maupun di luar klustermu. Meskipun kamu tidak tertarik menggunakan _logging_ pada level kluster, penjelasan tentang bagaimana log disimpan dan ditangani pada node di bawah ini mungkin dapat berguna untukmu.
+
+## Hal dasar _logging_ pada Kubernetes
+
+Pada bagian ini, kamu dapat melihat contoh tentang dasar _logging_ pada Kubernetes yang mengeluarkan data pada _standard output_. Demonstrasi berikut ini menggunakan sebuah [spesifikasi pod](/examples/debug/counter-pod.yaml) dengan kontainer yang akan menuliskan beberapa teks ke _standard output_ tiap detik.
+
+{{< codenew file="debug/counter-pod.yaml" >}}
+
+Untuk menjalankan pod ini, gunakan perintah berikut:
+
+```shell
+kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+Keluarannya adalah:
+```
+pod/counter created
+```
+
+Untuk mengambil log, gunakan perintah `kubectl logs` sebagai berikut:
+
+```shell
+kubectl logs counter
+```
+Keluarannya adalah:
+```
+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
+...
+```
+
+Kamu dapat menambahkan parameter `--previous` pada perintah `kubectl logs` untuk mengambil log dari kontainer sebelumnya yang gagal atau _crash_. Jika pod kamu memiliki banyak kontainer, kamu harus menspesifikasikan kontainer mana yang kamu ingin akses lognya dengan menambahkan nama kontainer pada perintah tersebut. Lihat [dokumentasi `kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) untuk informasi lebih lanjut.
+
+## Node-level _logging_
+
+![Node-level _logging_](/images/docs/user-guide/logging/logging-node-level.png)
+
+Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview), yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam file dalam format json.
+
+{{< note >}}
+_Logging driver_ json dari Docker memperlakukan tiap baris sebagai pesan yang terpisah. Saat menggunakan _logging driver_ Docker, tidak ada dukungan untuk menangani pesan _multi-line_. Kamu harus menangani pesan _multi-line_ pada level agen log atau yang lebih tinggi.
+{{< /note >}}
+
+Secara _default_, jika suatu kontainer _restart_, kubelet akan menjaga kontainer yang mati tersebut beserta lognya. Namun jika suatu pod dibuang dari _node_, maka semua hal dari kontainernya juga akan dibuang, termasuk lognya.
+
+Hal lain yang perlu diperhatikan dalam _logging_ pada level _node_ adalah implementasi rotasi log, sehingga log tidak menghabiskan semua penyimpanan yang tersedia pada _node._ Kubernetes saat ini tidak bertanggung jawab dalam melakukan rotasi log, namun _deployment tool_ seharusnya memberikan solusi terhadap masalah tersebut.
+Contohnya, pada kluster Kubernetes, yang di _deployed_ menggunakan `kube-up.sh`, terdapat alat bernama [`logrotate`](https://linux.die.net/man/8/logrotate) yang dikonfigurasi untuk berjalan tiap jamnya. Kamu juga dapat menggunakan _runtime_ kontainer untuk melakukan rotasi log otomatis, misalnya menggunakan `log-opt` Docker.
+Pada `kube-up.sh`, metode terakhir digunakan untuk COS _image_ pada GCP, sedangkan metode pertama digunakan untuk lingkungan lainnya. Pada kedua metode, secara _default_ akan dilakukan rotasi pada saat berkas log melewati 10MB.
+
+Sebagai contoh, kamu dapat melihat informasi lebih rinci tentang bagaimana `kube-up.sh` mengatur _logging_ untuk COS _image_ pada GCP yang terkait dengan [_script_][cosConfigureHelper].
+
+Saat kamu menjalankan perintah [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) seperti pada contoh tadi, kubelet di _node_ tersebut akan menangani permintaan untuk membaca langsung isi berkas log sebagai respon.
+
+{{< note >}}
+Saat ini, jika suatu sistem eksternal telah melakukan rotasi, hanya konten dari berkas log terbaru yang akan tersedia melalui perintah `kubectl logs`. Contoh, jika terdapat sebuah berkas 10MB, `logrotate` akan melakukan rotasi sehingga akan ada dua buah berkas, satu dengan ukuran 10MB, dan satu berkas lainnya yang kosong. Maka `kubectl logs` akan mengembalikan respon kosong.
+{{< /note >}}
+
+[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
+
+### Komponen sistem log
+
+Terdapat dua jenis komponen sistem: yaitu yang berjalan di dalam kontainer dan komponen lain yang tidak berjalan di dalam kontainer. Sebagai contoh:
+
+* Kubernetes _scheduler_ dan kube-proxy berjalan di dalam kontainer.
+* Kubelet dan _runtime_ kontainer, contohnya Docker, tidak berjalan di dalam kontainer.
+
+Pada mesin yang menggunakan systemd, kubelet dan runtime _runtime_ menulis ke journald. Jika systemd tidak tersedia, keduanya akan menulis ke berkas `.log` pada folder `/var/log`.
+Komponen sistem di dalam kontainer akan selalu menuliskan ke folder `/var/log`, melewati mekanisme _default logging_. Mereka akan menggunakan _logging library_ [klog][klog].
+Kamu dapat menemukan konvensi tentang tingkat kegawatan _logging_ untuk komponen-komponen tersebut pada [dokumentasi _development logging_](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
+
+Seperti halnya pada log kontainer, komponen sistem yang menuliskan log pada folder `/var/log` juga harus melakukan rotasi log. Pada kluster Kubernetes yang menggunakan `kube-up.sh`, log tersebut telah dikonfigurasi dan akan dirotasi oleh `logrotate` secara harian atau saat ukuran log melebihi 100MB.
+
+[klog]: https://github.com/kubernetes/klog
+
+## Arsitektur kluster-level _logging_
+
+Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level kluster, ada beberapa pendekatan yang dapat kamu pertimbangkan. Berikut beberapa diantaranya:
+
+* Menggunakan agen _logging_ pada level _node_ yang berjalan pada setiap _node_.
+* Menggunakan kontainer _sidecar_ khusus untuk _logging_ aplikasi di dalam pod.
+* Mengeluarkan log langsung ke _backend_ dari dalam aplikasi
+
+### Menggunakan agen node-level _logging_
+
+![Menggunakan agen node-level _logging_](/images/docs/user-guide/logging/logging-with-node-agent.png)
+
+Kamu dapat mengimplementasikan kluster-level _logging_ dengan menggunakan agen yang berjalan pada setiap _node_. Agen _logging_ merupakan perangkat khusus yang akan mengekspos log atau mengeluarkan log ke _backend_. Umumnya agen _logging_ merupakan kontainer yang memiliki akses langsung ke direktori tempat berkas log berada dari semua kontainer aplikasi yang berjalan pada _node_ tersebut.
+
+Karena agen _logging_ harus berjalan pada setiap _node_, umumnya dilakukan dengan menggunakan replika DaemonSet, _manifest_ pod, atau menjalankan proses khusus pada _node_. Namun dua cara terakhir sudah dideprekasi dan sangat tidak disarankan.
+
+Menggunakan agen _logging_ pada level _node_ merupakan cara yang paling umum dan disarankan untuk kluster Kubernetes. Hal ini karena hanya dibutuhkan satu agen tiap node dan tidak membutuhkan perubahan apapun dari sisi aplikasi yang berjalan pada _node_. Namun, node-level _logging_ hanya dapat dilakukan untuk aplikasi yang menggunakan _standard output_ dan _standard error_.
+
+Kubernetes tidak menspesifikasikan khusus suatu agen _logging_, namun ada dua agen _logging_ yang dimasukkan dalam rilis Kubernetes: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) untuk digunakan pada Google Cloud Platform, dan [Elasticsearch](/docs/user-guide/logging/elasticsearch). Kamu dapat melihat informasi dan instruksi pada masing-masing dokumentasi. Keduanya menggunakan [fluentd](http://www.fluentd.org/) dengan konfigurasi kustom sebagai agen pada _node_.
+
+### Menggunakan kontainer _sidecar_ dengan agen _logging_
+
+Kamu dapat menggunakan kontainer _sidecar_ dengan salah satu cara berikut:
+
+* Kontainer _sidecar_ mengeluarkan log aplikasi ke `stdout` miliknya sendiri.
+* Kontainer _sidecar_ menjalankan agen _logging_ yang dikonfigurasi untuk mengambil log dari aplikasi kontainer.
+
+#### Kontainer _streaming_ _sidecar_
+
+![Kontainer _sidecar_ dengan kontainer _streaming_](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png)
+
+Kamu dapat memanfaatkan kubelet dan agen _logging_ yang telah berjalan pada tiap _node_ dengan menggunakan kontainer _sidecar_. Kontainer _sidecar_ dapat membaca log dari sebuah berkas, _socket_ atau journald. Tiap kontainer _sidecar_ menuliskan log ke `stdout` atau `stderr` mereka sendiri.
+
+Dengan menggunakan cara ini kamu dapat memisahkan aliran log dari bagian-bagian yang berbeda dari aplikasimu, yang beberapa mungkin tidak mendukung log ke `stdout` dan `stderr`. Perubahan logika aplikasimu dengan menggunakan cara ini cukup kecil, sehingga hampir tidak ada _overhead_. Selain itu, karena `stdout` dan `stderr` ditangani oleh kubelet, kamu juga dapat menggunakan alat bawaan seperti `kubectl logs`.
+
+Sebagai contoh, sebuah pod berjalan pada satu kontainer tunggal, dan kontainer menuliskan ke dua berkas log yang berbeda, dengan dua format yang berbeda pula. Berikut ini _file_ konfigurasi untuk Pod:
+
+{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
+
+Hal ini akan menyulitkan untuk mengeluarkan log dalam format yang berbeda pada aliran log yang sama, meskipun kamu dapat me-_redirect_ keduanya ke `stdout` dari kontainer. Sebagai gantinya, kamu dapat menggunakan dua buah kontainer _sidecar_. Tiap kontainer _sidecar_ dapat membaca suatu berkas log tertentu dari _shared volume_ kemudian mengarahkan log ke `stdout`-nya sendiri.
+
+Berikut _file_ konfigurasi untuk pod yang memiliki dua buah kontainer _sidecard_:
+
+{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
+
+Saat kamu menjalankan pod ini, kamu dapat mengakses tiap aliran log secara terpisah dengan menjalankan perintah berikut:
+
+```shell
+kubectl logs counter count-log-1
+```
+```
+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
+...
+```
+
+```shell
+kubectl logs counter count-log-2
+```
+```
+Mon Jan 1 00:00:00 UTC 2001 INFO 0
+Mon Jan 1 00:00:01 UTC 2001 INFO 1
+Mon Jan 1 00:00:02 UTC 2001 INFO 2
+...
+```
+
+Agen node-level yang terpasang di klustermu akan mengambil aliran log tersebut secara otomatis tanpa perlu melakukan konfigurasi tambahan. Bahkan jika kamu mau, kamu dapat mengonfigurasi agen untuk melakukan _parse_ baris log tergantung dari kontainer sumber awalnya.
+
+Sedikit catatan, meskipun menggunakan memori dan CPU yang cukup rendah (sekitar beberapa milicore untuk CPU dan beberapa megabytes untuk memori), penulisan log ke _file_ kemudian mengalirkannya ke `stdout` dapat berakibat penggunaan disk yang lebih besar. Jika kamu memiliki aplikasi yang menuliskan ke _file_ tunggal, umumnya lebih baik menggunakan `/dev/stdout` sebagai tujuan daripada menggunakan pendekatan dengan kontainer _sidecar_.
+
+Kontainer _sidecar_ juga dapat digunakan untuk melakukan rotasi berkas log yang tidak dapat dirotasi oleh aplikasi itu sendiri. Contoh dari pendekatan ini adalah sebuah kontainer kecil yang menjalankan rotasi log secara periodik. Namun, direkomendasikan untuk menggunakan `stdout` dan `stderr` secara langsung dan menyerahkan kebijakan rotasi dan retensi pada kubelet.
+
+#### Kontainer _sidecar_ dengan agen _logging_
+
+![Kontainer _sidecar_ dengan agen _logging_](/images/docs/user-guide/logging/logging-with-sidecar-agent.png)
+
+Jika agen node-level _logging_ tidak cukup fleksible untuk kebutuhanmu, kamu dapat membuat kontainer _sidecar_ dengan agen _logging_ yang terpisah, yang kamu konfigurasi spesifik untuk berjalan dengan aplikasimu.
+
+{{< note >}}
+Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat penggunaan _resource_ yang signifikan. Selain itu, kamu tidak dapat mengakses log itu dengan menggunakan perintah `kubectl logs`, karena mereka tidak dikontrol oleh kubelet.
+{{< /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.
+
+{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
+
+{{< note >}}
+Konfigurasi fluentd berada diluar cakupan artikel ini. Untuk informasi lebih lanjut tentang cara mengonfigurasi fluentd, silakan lihat [dokumentasi resmi fluentd ](http://docs.fluentd.org/).
+{{< /note >}}
+
+_File_ yang kedua mendeskripsikan sebuah pod yang memiliki kontainer _sidecar_ yang menjalankan fluentd. Pod ini melakukan _mount_ sebuah volume yang akan digunakan fluentd untuk mengambil data konfigurasinya.
+
+{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
+
+Setelah beberapa saat, kamu akan mendapati pesan log pada _interface_ Stackdriver.
+
+Ingat, ini hanya contoh saja dan kamu dapat mengganti fluentd dengan agen _logging_ lainnya, yang dapat membaca sumber apa saja dari dalam kontainer aplikasi.
+
+### Mengekspos log langsung dari aplikasi
+
+![Mengekspos log langsung dari aplikasi](/images/docs/user-guide/logging/logging-from-application.png)
+
+Kamu dapat mengimplementasikan kluster-level _logging_ dengan mengekspos atau mengeluarkan log langsung dari tiap aplikasi; namun cara implementasi mekanisme _logging_ tersebut diluar cakupan dari Kubernetes.
+
+{{% /capture %}}
diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md
new file mode 100644
index 0000000000..aaddac7334
--- /dev/null
+++ b/content/id/docs/concepts/configuration/assign-pod-node.md
@@ -0,0 +1,324 @@
+---
+title: Menetapkan Pod ke Kontainer
+content_template: templates/concept
+weight: 30
+---
+
+
+{{% capture overview %}}
+
+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 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/)
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## nodeSelector
+
+Penggunaan `nodeSelector` adalah cara pembatasan pemilihan node paling sederhana yang direkomendasikan. `nodeSelector` adalah sebuah _field_ pada PodSpec. `nodeSelector` memerinci sebuah map berisi pasangan kunci-nilai. Agar pod dapat dijalankan pada sebuah node yang memenuhi syarat, node tersebut harus memiliki masing-masing dari pasangan kunci-nilai yang dinyatakan sebagai label (namun node juga dapat memiliki label tambahan diluar itu). Penggunaan paling umum adalah satu pasang kunci-nilai.
+
+Mari kita telusuri contoh dari penggunaan `nodeSelector`.
+
+### Langkah Nol: Prasyarat
+
+Contoh ini mengasumsikan bahwa kamu memiliki pemahaman dasar tentang pod Kubernetes dan kamu telah [membuat kluster Kubernetes](https://github.com/kubernetes/kubernetes#documentation).
+
+### Langkah Satu: Menyematkan label pada node
+
+Jalankan `kubectl get nodes` untuk mendapatkan nama dari node-node yang ada dalam kluster kamu. Temukan node yang akan kamu tambahkan label, kemudian jalankan perintah `kubectl label nodes =` untuk menambahkan label pada node yang telah kamu pilih. Sebagai contoh, jika nama node yang saya pilih adalah 'kubernetes-foo-node-1.c.a-robinson.internal' dan label yang ingin saya tambahkan adalah 'disktype=ssd', maka saya dapat menjalankan `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
+
+Jika terjadi kegagalan dengan kesalahan perintah yang tidak _valid_ ("_invalid command_"), kemungkinan besar kamu menggunakan kubectl dengan versi lebih lama yang tidak memiliki perintah `label`. Dalam hal ini, lihat [versi sebelumnya] (https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) dari petunjuk ini untuk instruksi tentang cara menetapkan label pada node.
+
+Kamu dapat memastikan perintah telah berhasil dengan menjalankan ulang perintah `kubectl get nodes --show-labels` and memeriksa bahwa node yang dipilih sekarang sudah memiliki label yang ditambahkan. Kamu juga dapat menggunakan `kubectl describe node "nodename"` untuk melihat daftar lengkap label yang dimiliki sebuah node.
+
+### Langkah Dua: Menambahkan sebuah nodeSelector ke konfigurasi pod kamu
+
+Ambil berkas konfigurasi pod manapun yang akan kamu jalankan, dan tambahkan sebuah bagian `nodeSelector` pada berkas tersebut, seperti berikut. Sebagai contoh, jika berikut ini adalah konfigurasi pod saya:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+ labels:
+ env: test
+spec:
+ containers:
+ - name: nginx
+ image: nginx
+```
+
+Kemudian tambahkan sebuah `nodeSelector` seperti berikut:
+
+{{< codenew file="pods/pod-nginx.yaml" >}}
+
+Ketika kamu menjalankan perintah `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`, pod tersebut akan dijadwalkan pada node yang memiliki label yang dirinci. Kamu dapat memastikan penambahan nodeSelector berhasil dengan menjalankan `kubectl get pods -o wide` dan melihat "NODE" tempat Pod ditugaskan.
+
+## Selingan: label node _built-in_
+
+Sebagai tambahan dari label yang kamu [sematkan](#step-one-attach-label-to-the-node), node sudah terisi dengan satu set label standar. Pada Kubernetes v1.4 label tersebut adalah
+
+* `kubernetes.io/hostname`
+* `failure-domain.beta.kubernetes.io/zone`
+* `failure-domain.beta.kubernetes.io/region`
+* `beta.kubernetes.io/instance-type`
+* `kubernetes.io/os`
+* `kubernetes.io/arch`
+
+{{< note >}}
+Nilai dari label-label tersebut spesifik untuk setiap penyedia layanan _cloud_ dan tidak dijamin reliabilitasnya.
+Contohnya, nilai dari `kubernetes.io/hostname` bisa saja sama dengan nama node pada beberapa lingkungan dan berbeda pada lingkungan lain.
+{{< /note >}}
+
+## Isolasi/pembatasan Node
+
+Menambahkan label pada objek node memungkinkan penargetan pod pada node atau grup node yang spesifik. Penambahan label ini dapat digunakan untuk memastikan pod yang spesifik hanya berjalan pada node dengan isolasi, keamanan, atau pengaturan tertentu. Saat menggunakan label untuk tujuan tersebut, memilih kunci label yang tidak bisa dimodifikasi oleh proses kubelet pada node sangat direkomendasikan. Hal ini mencegah node yang telah diubah untuk menggunakan kredensial kubelet-nya untuk mengatur label-label pada objek nodenya sediri, dan mempengaruhi scheduler untuk menjadwalkan _workload_ ke node yang telah diubah tersebut.
+
+_Plugin_ penerimaan `NodeRestriction` mencegah kubeletes untuk megatur atau mengubah label dengan awalan `node-restriction.kubernetes.io/`.
+Untuk memanfaatkan awalan label untuk isolasi node:
+
+1. Pastikan kamu menggunakan [_authorizer_ node](/docs/reference/access-authn-authz/node/) dan mengaktifkan [_plugin admission NodeRestriction_(/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
+
+2. Tambah label dengan awalan `node-restriction.kubernetes.io/` ke objek node kamu, dan gunakan label tersebut pada node _selector_ kamu. Contohnya, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`.
+
+## Afinitas dan anti-afinitas
+
+`_Field_ nodeSelector` menyediakan cara yang sangat sederhana untuk membatasi pod ke node dengan label-label tertentu. Fitur afinitas/anti-afinitas saat ini bersifat beta dan memperluas tipe pembatasan yang dapat kamu nyatakan. Peningkatan kunci dari fitur ini adalah
+
+1. Bahasa yang lebih ekspresif (tidak hanya "AND of exact match")
+2. Kamu dapat memberikan indikasi bahwa aturan yang dinyatakan bersifat rendah/preferensi dibanding dengan persyaratan mutlak sehingga jika scheduler tidak dapat memenuhinya, pod tetap akan dijadwalkan
+3. Kamu dapat membatasi dengan label pada pod-pod lain yang berjalan pada node (atau domain _topological_ lain), daripada dengan label pada node itu sendiri, yang memungkinkan pengaturan tentang pod yang dapat dan tidak dapat dilokasikan bersama.
+
+Fitur afinitas terdiri dari dua tipe afinitas yaitu "node afinitas" dan "inter-pod afinitas/anti-afinitas"
+Node afinitas adalah seperti `nodeSelector` yang telah ada (tetapi dengam dua kelebihan pertama yang terdaftar di atas), sementara inter-pod afinitas/anti-afinitas membatasi pada label pod daripada label node, seperti yang dijelaskan pada item ketiga pada daftar di atas, sebagai tambahan dari item pertama dan kedua.
+
+_Field_ `nodeSelector` tetap berjalan seperti biasa, namun pada akhirnya akan ditinggalkan karena afinitas node dapat menyatakan semua yang `nodeSelector` dapat nyatakan.
+
+### Afinitas node (fitur beta)
+
+Afinitas node diperkenalkan sebagai fitur alfa pada Kubernetes 1.2.
+Afinitas node secara konseptual mirip dengan `nodeSelector` yang memungkinkan kamu untuk membatasi node yang memenuhi syarat untuk penjadwalan pod, berdasarkan label pada node.
+
+Saat ini ada dia tipe afinitas node, yaitu `requiredDuringSchedulingIgnoredDuringExecution` dan
+`preferredDuringSchedulingIgnoredDuringExecution`. Kamu dapat menganggap dua tipe ini sebagai "kuat" dan "lemah" secara berurutan, dalam arti tipe pertama menyatakan peraturan yang *harus* dipenuhi agar pod dapat dijadwalkan pada node (sama seperti `nodeSelector` tetapi menggunakan sintaksis yang lebih ekpresif), sementara tipe kedua menyatakan *preferensi* yang akan dicoba dilaksanakan tetapi tidak akan dijamin oleh scheduler. Bagian "IgnoredDuringExecution" dari nama tipe ini berarti, mirip dengan cara kerja `nodeSelector`, jika label pada node berubah pada _runtime_ yang menyebabkan aturan afinitas pada pod tidak lagi terpenuhi, pod akan tetap berjalan pada node. Pada masa yang akan datang kami berencana menawarkan `requiredDuringSchedulingRequiredDuringExecution` yang akan berjalan seperti `requiredDuringSchedulingIgnoredDuringExecution` hanya saja tipe ini akan mengeluarkan pod dari node yang gagal untuk memenuhi persyaratan afinitas node pod.
+
+Dengan denikian, contoh dari `requiredDuringSchedulingIgnoredDuringExecution` adalah "hanya jalankan pod pada node dengan Intel CPU" dan contoh dari `preferredDuringSchedulingIgnoredDuringExecution` adalah "coba jalankan set pod ini dalam zona ketersediaan XYZ, tetapi jika tidak memungkinkan, maka biarkan beberapa pod berjalan di tempat lain".
+
+Afinitas node dinyatakan sebagai _field_ `nodeAffinity` dari _field_ `affinity` pada PodSpec.
+
+Berikut ini contoh dari pod yang menggunakan afinitas node:
+
+{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
+
+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.
+
+Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat.
+
+Jika kamu menyatakan beberapa `nodeSelectorTerms` yang terkait dengan tipe `nodeAffinity`, maka pod akan dijadwalkan pada node **jika salah satu** dari `nodeSelectorTerms` dapat terpenuhi.
+
+Jika kamu menyatakan beberapa `matchExpressions` yang terkait dengan `nodeSelectorTerms`, makan pod dapat dijadwalkan pada node **hanya jika semua** `matchExpressions` dapat terpenuhi.
+
+Jika kamu menghapus atau mengubah label pada node tempat pod dijadwalkan, pod tidak akan dihapus. Dengan kata lain, pemilihan afinitas hanya bekerja pada saat waktu penjadwalan pod.
+
+_Field_ `weight` pada `preferredDuringSchedulingIgnoredDuringExecution` berada pada rentang nilai 1-100. Untuk setiap node yang memenuhi semua persyaratan penjadwalan (permintaan sumber daya, pernyataan afinitas RequiredDuringScheduling, dll.), _scheduler_ akan menghitung nilai jumlah dengan melakukan iterasi pada elemen-elemen dari _field_ ini dan menambah "bobot" pada jumlah jika node cocok dengan MatchExpressions yang sesuai. Nilai ini kemudian digabungkan dengan nilai dari fungsi prioritas lain untuk node. Node dengan nilai tertinggi adalah node lebih diutamakan.
+
+Untuk informasi lebih lanjut tentang afinitas node kamu dapat melihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md).
+
+
+### Afinitas and anti-afinitas antar pod (fitur beta)
+
+Afinitas and anti-afinitas antar pod diperkenalkan pada Kubernetes 1.4. Afinitas and anti-afinitas antar pod memungkinkan kamu untuk membatasi node yang memenuhi syarat untuk penjadwalan pod *berdasarkan label-label pada pod yang sudah berjalan pada node* daripada berdasarkan label-label pada node. Aturan tersebut berbentuk "pod ini harus (atau, dalam kasus
+anti-afinitas, tidak boleh) berjalan dalam X jika X itu sudah menjalankan satu atau lebih pod yang memenuhi aturan Y". Y dinyatakan sebagai sebuah LabelSelector dengan daftar namespace terkait; tidak seperti node, karena pod are namespaced (maka dari itu label-label pada pod diberi namespace secara implisit), sebuah label selector di atas label-label pod harus menentukan namespace yang akan diterapkan selector. Secara konsep X adalah domain topologi seperti node, rack, zona penyedia cloud, daerah penyedia cloud, dll. Kamu dapat menyatakannya menggunakan `topologyKey` yang merupakan kunci untuk label node yang digunakan sistem untuk menunjukkan domain topologi tersebut, contohnya lihat kunci label yang terdaftar di atas pada bagian [Selingan: label node built-in](#interlude-built-in-node-labels).
+
+{{< note >}}
+Afinitas and anti-afinitas antar pod membutuhkan jumlah pemrosesan yang substansial yang dapat memperlambat penjadwalan pada kluster berukuran besar secara signifikan. Kami tidak merekomendasikan penggunaan mereka pada kluster yang berukuran lebih besar dari beberapa ratus node.
+{{< /note >}}
+
+{{< note >}}
+Anti-afinitas pod mengharuskan node untuk diberi label secara konsisten, misalnya setiap node dalam kluster harus memiliki label sesuai yang cocok dengan `topologyKey`. Jika sebagian atau semua node tidak memiliki label `topologyKey` yang dinyatakan, hal ini dapat menyebabkan perilaku yang tidak diinginkan.
+{{< /note >}}
+
+Seperti afinitas node, ada dua tipe afinitas dan anti-afinitas pod, yaitu `requiredDuringSchedulingIgnoredDuringExecution` dan
+`preferredDuringSchedulingIgnoredDuringExecution` yang menunjukan persyaratan "kuat" vs. "lemah". Lihat deskripsi pada bagian afinitas node sebelumnya.
+Sebuah contoh dari afinitas `requiredDuringSchedulingIgnoredDuringExecution` adalah "Tempatkan bersamaan pod layanan A dan layanan B di zona yang sama, karena mereka banyak berkomunikasi satu sama lain"
+dan contoh `preferDuringSchedulingIgnoredDuringExecution` anti-afinitas akan menjadi "sebarkan pod dari layanan ini di seluruh zona" (persyaratan kuat tidak masuk akal, karena kamu mungkin memiliki lebih banyak pod daripada zona).
+
+Afinitas antar pod dinyatakan sebagai _field_ `podAffinity` dari _field_ `affinity` pada PodSpec dan anti-afinitas antar pod dinyatakan sebagai _field_ `podAntiAffinity` dari _field_ `affinity` pada PodSpec.
+
+#### Contoh pod yang menggunakan pod affinity:
+
+{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
+
+Afinitas pada pod tersebut menetapkan sebuah aturan afinitas pod dan aturan anti-afinitas pod. Pada contoh ini, `podAffinity` adalah `requiredDuringSchedulingIgnoredDuringExecution`
+sementara `podAntiAffinity` adalah `preferredDuringSchedulingIgnoredDuringExecution`. Aturan afinitas pod menyatakan bahwa pod dapat dijadwalkan pada node hanya jika node tersebut berada pada zona yang sama dengan minimal satu pod yang sudah berjalan yang memiliki label dengan kunci "security" dan bernilai "S1". (Lebih detail, pod dapat berjalan pada node N jika node N memiliki label dengan kunci `failure-domain.beta.kubernetes.io/zone`dan nilai V sehingga ada minimal satu node dalam kluster dengan kunci `failure-domain.beta.kubernetes.io/zone` dan bernilai V yang menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S1".) Aturan anti-afinitas pod menyatakan bahwa pod memilih untuk tidak dijadwalkan pada sebuah node jika node tersebut sudah menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S2". (Jika `topologyKey` adalah `failure-domain.beta.kubernetes.io/zone` maka dapat diartikan bahwa pod tidak dapat dijadwalkan pada node jika node berada pada zona yang sama dengan pod yang memiliki label dengan kunci "security" dan bernilai "S2".) Lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) untuk lebih banyak contoh afinitas dan anti-afinitas pod, baik `requiredDuringSchedulingIgnoredDuringExecution`
+maupun `preferredDuringSchedulingIgnoredDuringExecution`.
+
+Operator yang sah untuk afinitas dan anti-afinitas pod adalah `In`, `NotIn`, `Exists`, `DoesNotExist`.
+
+Pada dasarnya, `topologyKey` dapat berupa label-kunci apapun yang sah. Namun, untuk alasan performa dan keamanan, ada beberapa batasan untuk `topologyKey`:
+
+1. Untuk afinitas and anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, `topologyKey` tidak boleh kosong.
+2. Untuk anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, pengontrol penerimaan `LimitPodHardAntiAffinityTopology` diperkenalkan untuk membatasi `topologyKey` pada `kubernetes.io/hostname`. Jika kamu menginginkan untuk membuatnya tersedia untuk topologi khusus, kamu dapat memodifikasi pengontrol penerimaan, atau cukup menonaktifkannya saja.
+3. Untuk anti-afinitas pod `preferredDuringSchedulingIgnoredDuringExecution`, `topologyKey` yang kosong diinterpretasikan sebagai "semua topologi" ("semua topologi" sekarang dibatasi pada kombinasi dari `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` dan `failure-domain.beta.kubernetes.io/region`).
+4. Kecuali untuk kasus-kasus di atas, `topologyKey` dapat berupa label-kunci apapun yang sah.
+
+Sebagai tambahan untuk `labelSelector` and `topologyKey`, kamu secara opsional dapat menyatakan daftar `namespaces` dari namespaces yang akan digunakan untuk mencocokan `labelSelector` (daftar ini berjalan pada level definisi yang sama dengan `labelSelector` dan `topologyKey`)
+
+Jika dihilangkan atau kosong, daftar ini sesuai standar akan merujuk pada _namespace_ dari pod tempat definisi afinitas/anti-afinitas dinyatakan.
+
+Semua `matchExpressions` berkaitan dengan afinitas and anti-afinitas `requiredDuringSchedulingIgnoredDuringExecution` harus dipenuhi agar pod dapat dijadwalkan pada node.
+
+#### Penggunaan yang lebih praktikal
+
+Afinitas and anti-afinitas antar pod dapat menjadi lebih berguna saat digunakan bersamaan dengan koleksi dengan level yang lebih tinggi seperti ReplicaSets, StatefulSets, Deployments, dll. Pengguna dapat dengan mudah mengkonfigurasi bahwa satu set workload harus
+ditempatkan bersama dalam topologi yang didefinisikan sama, misalnya, node yang sama.
+
+##### Selalu ditempatkan bersamaan pada node yang sama
+
+Dalam kluster berisi 3 node, sebuah aplikasi web memiliki in-memory cache seperti redis. Kita menginginkan agar _web-server_ dari aplikasi ini sebisa mungkin ditempatkan bersamaan dengan cache.
+
+Berikut ini kutipan yaml dari deployment redis sederhana dengan 3 replika dan label selector `app=store`, Deployment memiliki konfigurasi `PodAntiAffinity` untuk memastikan _scheduler_ tidak menempatkan replika bersamaan pada satu node.
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: redis-cache
+spec:
+ selector:
+ matchLabels:
+ app: store
+ replicas: 3
+ template:
+ metadata:
+ labels:
+ app: store
+ spec:
+ affinity:
+ podAntiAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - store
+ topologyKey: "kubernetes.io/hostname"
+ containers:
+ - name: redis-server
+ image: redis:3.2-alpine
+```
+
+Kutipan yaml dari deployment webserver berikut ini memiliki konfigurasi `podAntiAffinity` dan `podAffinity`. Konfigurasi ini menginformasikan scheduler bahwa semua replika harus ditempatkan bersamaan dengan pod yang memiliki label selector `app=store`. Konfigurasi ini juga memastikan bahwa setiap replika webserver tidak ditempatkan bersamaan pada satu node.
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: web-server
+spec:
+ selector:
+ matchLabels:
+ app: web-store
+ replicas: 3
+ template:
+ metadata:
+ labels:
+ app: web-store
+ spec:
+ affinity:
+ podAntiAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - web-store
+ topologyKey: "kubernetes.io/hostname"
+ podAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - store
+ topologyKey: "kubernetes.io/hostname"
+ containers:
+ - name: web-app
+ image: nginx:1.12-alpine
+```
+
+Jika kita membuat kedua dployment di atas, kluster berisi 3 node kita seharusnya menjadi seperti berikut.
+
+| node-1 | node-2 | node-3 |
+|:--------------------:|:-------------------:|:------------------:|
+| *webserver-1* | *webserver-2* | *webserver-3* |
+| *cache-1* | *cache-2* | *cache-3* |
+
+
+st
+Seperti yang kamu lihat, semua 3 replika dari `web-server` secara otomatis ditempatkan bersama dengan cache seperti yang diharapkan.
+
+```
+$ kubectl get pods -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3
+redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1
+redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2
+web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1
+web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3
+web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2
+```
+
+##### Tidak akan pernah ditempatkan bersamaan dalam node yang sama
+
+
+Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy kluster redis sehingga tidak ada dua instance terletak pada hos yang sama.
+Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama.
+
+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.
+
+## nodeName
+
+`nodeName` adalah bentuk paling sederhana dari pembatasan pemilihan node, tetapi karena
+keterbatasannya biasanya tidak digunakan. `nodeName` adalah sebuah _field_ dari
+PodSpec. Jika tidak kosong, scheduler mengabaikan pod dan
+kubelet yang berjalan pada node tersebut yang mencoba menjalankan pod. Maka, jika
+`nodeName` disediakan dalam PodSpec, ia memiliki hak yang lebih tinggi dibanding metode-metode di atas untuk pemilihan node.
+
+Beberapa keterbatasan dari penggunaan `nodeName` untuk memilih node adalah:
+
+- Jika node yang disebut tidak ada, maka pod tidak akan dijalankan, dan dalam beberapa kasus akan
+ dihapus secara otomatis.
+- Jika node yang disebut tidak memiliki resource yang cukup untuk mengakomodasi pod, pod akan gagal
+ dan alasannya akan mengindikasikan sebab kegagalan, misalnya OutOfmemory atau OutOfcpu.
+- Nama node pada lingkungan cloud tidak selalu dapat diprediksi atau stabil.
+
+Berikut ini contoh konfigurasi pod menggunakan _field_ `nodeName`:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+spec:
+ containers:
+ - name: nginx
+ image: nginx
+ nodeName: kube-01
+```
+Pod di atas akan berjalan pada node kube-01.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+{{% /capture %}}
diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
new file mode 100644
index 0000000000..5681c4a9e8
--- /dev/null
+++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -0,0 +1,89 @@
+---
+title: Pengendali TTL untuk Sumber Daya yang Telah Selesai Digunakan
+content_template: templates/concept
+weight: 65
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+
+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/),
+dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan
+misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya.
+
+Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifkan dengan
+[_feature gate_](/docs/reference/command-line-tools-reference/feature-gates/)
+`TTLAfterFinished`.
+
+
+{{% /capture %}}
+
+
+
+
+{{% capture body %}}
+
+## Pengendali TTL
+
+Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator kluster
+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).
+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
+berkaitan akan ikut terhapus. Perhatikan bahwa ketika sebuah sumber daya dihapus,
+siklus hidup yang ada akan menjaga bahwa _finalizer_ akan tetap dijalankan sebagaimana mestinya.
+
+Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk mengaktifkan _field_
+`.spec.ttlSecondsAfterFinished` pada suatu Job:
+
+* Spesifikasikan _field_ ini pada _manifest_ sumber daya, sehingga Job akan
+ dihapus secara otomatis beberapa saat setelah selesai dieksekusi.
+* Aktifkan _field_ ini pada sumber daya yang sudah selesai dieksekusi untuk
+ menerapkan fitur ini.
+* Gunakan sebuah
+ [mengubah (_mutating_) _admission)](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
+ untuk mengaktifkan _field_ ini secara dinamis pada saat pembuatan sumber daya.
+ Administrator kluster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada
+ sumber daya yang telah selesai digunakan.
+* Gunakan sebuah
+ [mengubah (_mutating_) _admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
+ untuk mengaktifkan _field_ ini secara dinamis setelah sumber daya
+ selesai digunakan dan TTL didefinisikan sesuai dengan status, label, atau hal lain
+ yang diinginkan.
+
+## Peringatan
+
+### Mengubah TTL Detik
+
+Perhatikan bahwa periode TTL, yaitu _field_ `.spec.ttlSecondsAfterFinished` pada Job,
+dapat dimodifikasi baik setelah sumber daya dibuat atau setelah selesai digunakan.
+Meskipun begitu, setelah Job dapat dihapus (TTL sudah habis), sistem tidak akan
+menjamin Job tersebut akan tetap ada, meskipun nilai TTL berhasil diubah.
+
+### _Time Skew_
+
+Karena pengendali TTL menggunakan cap waktu (_timestamp_) yang disimpan di sumber daya
+Kubernetes untuk menentukan apakah TTL sudah habis atau belum, fitur ini tidak sensitif
+terhadap _time skew_ yang ada pada kluster dan bisa saja menghapus objek pada waktu yang salah
+bagi objek tersebut akibat adanya _time skew_.
+
+Pada Kubernetes, NTP haruslah dilakukan pada semua node untuk mecegah adanya _time skew_
+(lihat [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)).
+_Clock_ tidak akan selalu tepat, meskipun begitu perbedaan yang ada haruslah diminimalisasi.
+Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selain 0.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+[Membersikan Job secara Otomatis](/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)
+
+{{% /capture %}}
diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
new file mode 100644
index 0000000000..cc6c992ab8
--- /dev/null
+++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -0,0 +1,353 @@
+---
+title: Siklus Hidup Pod
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+{{< comment >}}Pembaruan: 4/14/2015{{< /comment >}}
+{{< comment >}}Diubah dan dipindahkan ke bagian konsep: 2/2/17{{< /comment >}}
+
+Halaman ini menjelaskan siklus hidup sebuah Pod
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Fase Pod
+
+_Field_ `status` dari sebuah Pod merupakan sebuah objek [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core), yang memiliki sebuah _field_ `phase`.
+
+Fase dari sebuah Pod adalah sesuatu yang sederhana, ringkasan yang lebih tinggi tentang Pod dalam siklus hidupnya. Fase ini tidak ditujukan sebagai sebuah kesimpulan yang luas dari observasi suatu kontainer atau _state_ suatu Pod, serta tidak ditujukan sebagai _state machine_ yang luas.
+
+Jumlah dan arti dari nilai-nilai fase Pod dijaga ketat. Selain yang ada dalam dokumentasi ini, tidak perlu berasumsi mengenai Pod telah diberikan nilai `phase`.
+
+Berikut adalah nilai yang mungkin diberikan untuk suatu `phase`:
+
+Nilai | Deskripsi
+:-----|:-----------
+`Pending` | Pod telah disetujui oleh sistem Kubernetes, tapi ada satu atau lebih _image_ kontainer yang belum terbuat. Ini termasuk saat sebelum dijadwalkan dan juga saat mengunduh _image_ melalui jaringan, yang mungkin butuh beberapa waktu.
+`Running` | Pod telah terikat ke suatu node, dan semua kontainer telah terbuat. Setidaknya ada 1 kontainer yang masih berjalan, atau dalam proses memulai atau _restart_.
+`Succeeded` | Semua kontainer di dalam Pod sudah berhasil dihentikan, dan tidak akan dilakukan _restart_.
+`Failed` | Semua kontainer dalan suatu Pod telah dihentikan, dan setidaknya ada satu kontainer yang terhenti karena kegagalan. Itu merupakan kontainer yang keluar dengan kode status bukan 0 atau dihentikan oleh sistem.
+`Unknown` | _State_ suatu Pod tidak dapat diperoleh karena suatu alasan, biasanya karena kesalahan dalam komunikasi dengan _host_ yang digunakan Pod tersebut.
+
+## Kondisi Pod
+
+Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) yang telah atau belum dilewati oleh Pod. Setiap elemen dari _array_ PodConditions mungkin memiliki enam _field_ berikut:
+
+* _Field_ `lastProbeTime` memberikan nilai _timestamp_ yang menandakan kapan terakhir kali kondisi kondisi Pod diperiksa.
+
+* _Field_ `lastTransitionTime` memberikan nilai _timestamp_ yang menandakan kapan terakhir kali Pod berubah status ke status lain.
+
+* _Field_ `message` adalah pesan yang bisa dibaca manusia yang mengidikasikan detail dari suatu transisi.
+
+* _Field_ `reason` adalah suatu alasan yang unik, satu kata, ditulis secara _CamelCase_ untuk kondisi transisi terakhir.
+
+* _Field_ `status` adalah sebuah kata dengan kemungkinan nilainya berupa "`True`", "`False`", dan "`Unknown`".
+
+* _Field_ `type` adalah sebuah kata yang memiliki kemungkinan nilai sebagai berikut:
+
+ * `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.
+ * `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.
+
+
+## Pemeriksaan Kontainer
+
+Sebuah [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) adalah sebuah diagnosa yang dilakukan secara berkala oleh [kubelet](/docs/admin/kubelet/) dalam suatu kontainer. Untuk melakukan diagnosa, kubelet memanggil sebuah [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) yang diimplementasikan oleh kontainer. Ada 3 tipe _Handler_ yang tersedia, yaitu:
+
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): Mengeksekusi perintah tertentu di dalam kontainer. Diagnosa dikatakan berhasil jika perintah selesai dengan kode status 0.
+
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): Melakukan pengecekan TCP terhadap alamat IP kontainer dengan _port_ tertentu. Diagnosa dikatakan berhasil jika _port_ tersebut terbuka.
+
+* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): Melakukan sebuah _request_ HTTP Get terhadap alamat IP kontainer dengan _port_ dan _path_ tertentu. Diagnosa dikatakan berhasil jika responnya memiliki kode status lebih besar atau sama dengan 200 dan kurang dari 400.
+
+Setiap pemeriksaan akan menghasilkan salah satu dari tiga hasil berikut:
+
+* _Success_: Kontainer berhasil melakukan diagnosa.
+* _Failure_: Kontainer gagal melakukan diagnosa.
+* _Unknown_: Gagal melakukan diagnosa, sehingga tidak ada aksi yang harus dilakukan.
+
+_Kubelet_ dapat secara optimal melakukan dan bereaksi terhadap dua jenis pemeriksaan yang sedang berjalan pada kontainer, yaitu:
+
+* `livenessProbe`: Ini menunjukkan apakah kontainer sedang berjalan. Jika tidak berhasil melakukan pemeriksaan terhadap _liveness_ dari kontainer, maka kubelet akan mematikan kontainer, dan kontainer akan mengikuti aturan dari [_restart policy_](#restart-policy). Jika kontainer tidak menyediakan pemeriksaan terhadap _liveness_, maka nilai dari _state_ adalah `Success`.
+
+* `readinessProbe`: Ini menunjukan apakah kontainer sudah siap melayani _request_. Jika tidak berhasil melakukan pemeriksaan terhadap kesiapan dari kontainer, maka _endpoints controller_ akan menghapus alamat IP Pod dari daftar semua _endpoint_ untuk servis yang sama dengan Pod. Nilai awal _state_ sebelum jeda awal adalah `Failure`. Jika kontainer tidak menyediakan pemeriksaan terhadap _readiness_, maka nilai awal _state_ adalah `Success`.
+
+### Kapan sebaiknya menggunakan pemeriksaan terhadap _liveness_ atau _readiness_?
+
+Jika proses dalam kontainer mungkin gagal yang dikarenakan menghadapi suatu masalah
+atau menjadi tidak sehat, maka pemeriksaan terhadap _liveness_ tidak diperlukan.
+Kubelet akan secara otomatis melakukan aksi yang tepat mengikuti `restartPolicy` dari Pod.
+
+Jika kamu ingin kontainer bisa dimatikan dan dijalankan ulang ketika gagal melakukan
+pemeriksaan, maka tentukan pemeriksaan _liveness_ dan tentukan nilai `restartPolicy` sebagai `Always` atau `OnFailure`.
+
+Jika kamu ingin mulai mengirim _traffic_ ke Pod hanya ketika pemeriksaan berhasil,
+maka tentukan pemeriksaan _readiness_. Dalam kasus ini, pemeriksaan _readiness_ mungkin
+akan sama dengan pemeriksaan _liveness_, tapi keberadaan pemeriksaan _readiness_ dalam
+_spec_ berarti Pod akan tetap dijalankan tanpa menerima _traffic_ apapun dan akan
+mulai menerima _traffic_ ketika pemeriksaan yang dilakukan mulai berhasil.
+Jika kontainermu dibutuhkan untuk tetap berjalan ketika _loading_ data yang besar,
+_file_ konfigurasi, atau melakukan migrasi ketika _startup_, maka tentukanlah pemeriksaan _readiness_.
+
+Jika kamu ingin kontainermu dalam mematikan dirinya sendiri, kamu dapat menentukan
+suatu pemeriksaan _readiness_ yang melakukan pengecekan terhadap _endpoint_ untuk _readiness_.
+_endpoint_ tersebut berbeda dengan _endpoint_ untuk pengecekan _liveness_.
+
+Perlu dicatat, jika kamu hanya ingin bisa menutup _request_ ketika Pod sedang dihapus
+maka kamu tidak perlu menggunakan pemeriksaan _readiness_. Dalam penghapusan, Pod akan
+secara otomatis mengubah _state_ dirinya menjadi _unready_ tanpa peduli apakah terdapat
+pemeriksaan _readiness_ atau tidak. Pod tetap ada pada _state unready_ selama menunggu
+kontainer dalam Pod berhenti.
+
+Untuk informasi lebih lanjut mengenai pengaturan pemeriksaan _liveness_ atau _readiness_, lihat bagian
+[Konfigurasi _Liveness_ dan _Readiness_ _Probe_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
+
+## Status Pod dan Kontainer
+
+Untuk informasi lebih mendalam mengenai status Pod dan kontainer, silakan lihat
+[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
+dan
+[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
+Mohon diperhatikan, informasi tentang status Pod bergantung pada
+[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
+
+## State Kontainer
+
+Ketika Pod sudah ditempatkan pada suatu node oleh scheduler, kubelet mulai membuat kontainer menggunakan _runtime_ kontainer.
+Ada tiga kemungkinan _state_ untuk suatu kontainer, yaitu Waiting, Running, dan Terminated.
+Untuk mengecek _state_ suatu kontainer, kamu bisa menggunakan perintah `kubectl describe pod [NAMA_POD]`.
+_State_ akan ditampilkan untuk masing-masing kontainer dalam Pod tersebut.
+
+* `Waiting`: Merupakan _state_ default dari kontainer. Jika _state_ kontainer bukan Running atau Terminated, berarti dalam _Wating state_.
+Suatu kontainer dalam Waiting _state_ akan tetap menjalan operasi-operasi yang dibutuhkan, misalnya mengunduh _images_, mengaplikasikan Secrets, dsb.
+Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditampilkan untuk memberi informasi lebih.
+
+ ```yaml
+ ...
+ State: Waiting
+ Reason: ErrImagePull
+ ...
+ ```
+
+* `Running`: Menandakan kontainer telah berjalan tanpa masalah. Setelah kontainer masuk ke _state_ Running, jika terdapat _hook_ `postStart` maka akan dijalankan. _State_ ini juga menampilkan waktu ketika kontainer masuk ke _state_ Running.
+
+ ```yaml
+ ...
+ State: Running
+ Started: Wed, 30 Jan 2019 16:46:38 +0530
+ ...
+ ```
+
+* `Terminated`: Menandakan kontainer telah menyelesaikan "tugasnya". Kontainer akan menjadi _state_ ini ketika telah menyelesaikan eksekusi atau terjadi kesalahan. Terlepas dari itu, sebuah alasan dan _exit code_ akan ditampilkan, bersama dengan waktu kontainer mulai dijalankan dan waktu berhenti. Sebelum kontainer masuk ke _state_ Terminated, jika terdapat `preStop` _hook_ maka akan dijalankan.
+
+ ```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 gate
+
+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
+
+Dalam rangka menambahkan ekstensibilitas terhadap kesiapan Pod dengan menggunakan
+injeksi umpan balik tambahan atau sinyal ke dalam `PodStatus`,
+Kubernetes 1.11 memperkenalkan sebuah fitur bernama [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md).
+Kamu dapat menggunakan _field_ baru `ReadinessGate` dalam sebuah `PodSpec` untuk
+menunjukan kondisi tambahan yang akan dievaluasi untuk kesiapan Pod. Jika Kubernetes
+tidak dapat menemukan kondisi pada _field_ `status.conditions` dalam suatu Pod,
+maka statusnya akan secara otomatis menjadi `False`. Berikut adalah contoh pemakaiannya:
+
+```yaml
+Kind: Pod
+...
+spec:
+ readinessGates:
+ - conditionType: "www.example.com/feature-1"
+status:
+ conditions:
+ - type: Ready # ini adalah PodCondition yang telah tersedia
+ status: "False"
+ lastProbeTime: null
+ lastTransitionTime: 2018-01-01T00:00:00Z
+ - type: "www.example.com/feature-1" # sebuah PodCondition tambahan
+ status: "False"
+ lastProbeTime: null
+ lastTransitionTime: 2018-01-01T00:00:00Z
+ containerStatuses:
+ - containerID: docker://abcd...
+ ready: true
+...
+```
+
+Kondisi Pod yang baru harus memenuhi [format label](/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/).
+
+Dengan diperkenalkannya kondisi Pod yang baru, sebuah Pod akan dianggap siap hanya jika memenuhi dua syarat berikut:
+
+* Semua kontainer dalam Pod telah siap.
+* Semua kontainer yang diatur dalam `ReadinessGates` bernilai "`True`".
+
+
+Untuk memfasilitasi perubahan tersebut terhadap evaluasi kesiapan Pod, dibuatkan sebuah kondisi Pod baru yaitu `ContainerReady`,
+untuk dapat menangani kondisi Pod `Ready` yang sudah ada.
+
+Dalam K8s 1.11, sebagai fitur _alpha_, fitur "Pod Ready++" harus diaktifkan melalui pengaturan
+ [fitur _gate_ pada `PodReadinessGates`](/docs/reference/command-line-tools-reference/feature-gates/).
+
+Dalam K8s 1.12, fitur tersebut sudah diaktifkan dari awal.
+
+
+## Aturan Menjalankan Ulang
+
+Sebuah PodSpec memiliki _field_ `restartPolicy` dengan kemungkinan nilai berupa Always, OnFailure, dan Never.
+Nilai awalnya berupa Always. `restartPolicy` akan berlaku untuk semua kontainer dalam Pod.
+Kontainer yang mati dan dijalankan ulang oleh kubelet akan dijalankan ulang dengan jeda waktu yang ekponensial (10s, 20s, 40s, ...)
+dengan batas atas senilai lima menit. Jeda waktu ini akan diatur ulang setelah sukses berjalan selama 10 menit.
+Sesuai dengan diskusi pada [dokumen Pod](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof),
+setelah masuk ke suatu node, sebuah Pod tidak akan pindah ke node lain.
+
+## Umur Pod
+
+Secara umum, Pod tidak hilang sampai ada yang menghapusnya. Ini mungkin dihapus oleh orang atau pengontrol.
+Satu pengecualian untuk aturan ini adalah Pod dengan `phase` bernilai Succeeded atau Failed untuk waktu
+beberapa lama yang akan berakhir dan secara otomatis akan dihapus.
+(diatur dalam `terminated-pod-gc-threshold` pada master)
+
+Tiga tipe pengontrol yang tersedia yaitu:
+
+- Menggunakan sebuah [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) untuk Pod yang diharapkan akan berakhir,
+ 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,
+ 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
+ hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin.
+
+
+Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk membuat
+pengontrol yang sesuai dan membiarkan ini membuat Pod, daripada membuat Pod sendiri secara langsung.
+Karena Pod itu sendiri tidak tahan terhadap gagalnya suatu mesin, namun pengontrol tahan.
+
+Jika node mati atau sambungannya terputus dari kluster, Kubernetes mengatur
+`phase` dari semua Pod pada node yang mati untuk menjadi Failed.
+
+## Contoh
+
+### Contoh _Liveness Probe_ tingkat lanjut
+
+_Liveness probe_ dieksekusi oleh kubelet, jadi semua permintaan akan dilakukan
+di dalam _namespace_ jaringan kubelet.
+
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ labels:
+ test: liveness
+ name: liveness-http
+spec:
+ containers:
+ - args:
+ - /server
+ image: k8s.gcr.io/liveness
+ livenessProbe:
+ httpGet:
+ # ketika "host" tidak ditentukan, "PodIP" akan digunakan
+ # host: my-host
+ # ketika "scheme" tidak ditentukan, _scheme_ "HTTP" akan digunakan. Hanya "HTTP" and "HTTPS" yang diperbolehkan
+ # scheme: HTTPS
+ path: /healthz
+ port: 8080
+ httpHeaders:
+ - name: X-Custom-Header
+ value: Awesome
+ initialDelaySeconds: 15
+ timeoutSeconds: 1
+ name: liveness
+```
+
+### Contoh _State_
+
+
+ * Pod sedang berjalan dan memiliki sebuah kontainer. Kontainer berhenti dengan sukses.
+ * Mencatat _event_ penyelesaian.
+ * Jika nilai `restartPolicy` adalah:
+ * Always: Jalankan ulang kontainer; nilai `phase` Pod akan tetap Running.
+ * OnFailure: nilai `phase` Pod akan berubah menjadi Succeeded.
+ * Never: nilai `phase` Pod akan berubah menjadi Succeeded.
+
+ * Pod sedang berjalan dan memiliki sebuah kontainer. Kontainer berhenti dengan kegagalan.
+ * Mencatat _event_ kegagalan.
+ * Jika nilai `restartPolicy` adalah:
+ * Always: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * OnFailure: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * Never: nilai `phase` Pod akan menjadi Failed.
+
+ * Pod sedang berjalan dan memiliki dua kontainer. Kontainer pertama berhenti dengan kegagalan.
+ * Mencatat _event_ kegagalan.
+ * Jika nilai `restartPolicy` adalah:
+ * Always: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * OnFailure: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * Never: Tidak akan menjalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * Jika kontainer pertama tidak berjalan dan kontainer kedua berhenti:
+ * Mencatat _event_ kegagalan.
+ * Jika nilai `restartPolicy` adalah:
+ * Always: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * OnFailure: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * Never: nilai `phase` Pod akan menjadi Failed.
+
+ * Pod sedang berjalan dan memiliki satu kontainer. Kontainer berhenti karena kehabisan _memory_.
+ * Kontainer diberhentikan dengan kegagalan.
+ * Mencatat kejadian kehabisan _memory_ (OOM)
+ * Jika nilai `restartPolicy` adalah:
+ * Always: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * OnFailure: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running.
+ * Never: Mencatat kejadian kegagalan, nilai `phase` Pod akan menjadi Failed.
+
+ * Pod sedang berjalan dan sebuah _disk_ mati.
+ * Menghentikan semua kontainer.
+ * Mencatat kejadian yang sesuai.
+ * Nilai `phase` Pod menjadi Failed.
+ * Jika berjalan menggunakan pengontrol, maka Pod akan dibuat ulang di tempat lain.
+
+ * Pod sedang berjalan, dan node mengalami _segmented out_.
+ * Node pengontrol menunggu sampai suatu batas waktu.
+ * Node pengontrol mengisi nilai `phase` Pod menjadi Failed.
+ * Jika berjalan menggunakan pengontrol, maka Pod akan dibuat ulang di tempat lain.
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+
+* Dapatkan pengalaman langsung mengenai
+ [penambahan _handlers_ pada kontainer _lifecycle events_](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
+
+* 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/).
+
+{{% /capture %}}
+
+
+
diff --git a/content/id/examples/admin/logging/fluentd-sidecar-config.yaml b/content/id/examples/admin/logging/fluentd-sidecar-config.yaml
new file mode 100644
index 0000000000..eea1849b03
--- /dev/null
+++ b/content/id/examples/admin/logging/fluentd-sidecar-config.yaml
@@ -0,0 +1,25 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: fluentd-config
+data:
+ fluentd.conf: |
+
+
+
+
+
+ type google_cloud
+
diff --git a/content/id/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/id/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml
new file mode 100644
index 0000000000..b37b616e6f
--- /dev/null
+++ b/content/id/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml
@@ -0,0 +1,39 @@
+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)" >> /var/log/1.log;
+ echo "$(date) INFO $i" >> /var/log/2.log;
+ i=$((i+1));
+ sleep 1;
+ done
+ volumeMounts:
+ - name: varlog
+ mountPath: /var/log
+ - name: count-agent
+ image: k8s.gcr.io/fluentd-gcp:1.30
+ env:
+ - name: FLUENTD_ARGS
+ value: -c /etc/fluentd-config/fluentd.conf
+ volumeMounts:
+ - name: varlog
+ mountPath: /var/log
+ - name: config-volume
+ mountPath: /etc/fluentd-config
+ volumes:
+ - name: varlog
+ emptyDir: {}
+ - name: config-volume
+ configMap:
+ name: fluentd-config
diff --git a/content/id/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml b/content/id/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml
new file mode 100644
index 0000000000..87bd198cfd
--- /dev/null
+++ b/content/id/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml
@@ -0,0 +1,38 @@
+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)" >> /var/log/1.log;
+ echo "$(date) INFO $i" >> /var/log/2.log;
+ i=$((i+1));
+ sleep 1;
+ done
+ volumeMounts:
+ - name: varlog
+ mountPath: /var/log
+ - name: count-log-1
+ image: busybox
+ args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
+ volumeMounts:
+ - name: varlog
+ mountPath: /var/log
+ - name: count-log-2
+ image: busybox
+ args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
+ volumeMounts:
+ - name: varlog
+ mountPath: /var/log
+ volumes:
+ - name: varlog
+ emptyDir: {}
diff --git a/content/id/examples/admin/logging/two-files-counter-pod.yaml b/content/id/examples/admin/logging/two-files-counter-pod.yaml
new file mode 100644
index 0000000000..6ebeb717a1
--- /dev/null
+++ b/content/id/examples/admin/logging/two-files-counter-pod.yaml
@@ -0,0 +1,26 @@
+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)" >> /var/log/1.log;
+ echo "$(date) INFO $i" >> /var/log/2.log;
+ i=$((i+1));
+ sleep 1;
+ done
+ volumeMounts:
+ - name: varlog
+ mountPath: /var/log
+ volumes:
+ - name: varlog
+ emptyDir: {}
diff --git a/content/id/examples/debug/counter-pod.yaml b/content/id/examples/debug/counter-pod.yaml
new file mode 100644
index 0000000000..f997886386
--- /dev/null
+++ b/content/id/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/id/examples/pods/pod-nginx.yaml b/content/id/examples/pods/pod-nginx.yaml
new file mode 100644
index 0000000000..134ddae2aa
--- /dev/null
+++ b/content/id/examples/pods/pod-nginx.yaml
@@ -0,0 +1,13 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+ labels:
+ env: test
+spec:
+ containers:
+ - name: nginx
+ image: nginx
+ imagePullPolicy: IfNotPresent
+ nodeSelector:
+ disktype: ssd
diff --git a/content/id/examples/pods/pod-with-node-affinity.yaml b/content/id/examples/pods/pod-with-node-affinity.yaml
new file mode 100644
index 0000000000..253d2b21ea
--- /dev/null
+++ b/content/id/examples/pods/pod-with-node-affinity.yaml
@@ -0,0 +1,26 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: with-node-affinity
+spec:
+ affinity:
+ nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: kubernetes.io/e2e-az-name
+ operator: In
+ values:
+ - e2e-az1
+ - e2e-az2
+ preferredDuringSchedulingIgnoredDuringExecution:
+ - weight: 1
+ preference:
+ matchExpressions:
+ - key: another-node-label-key
+ operator: In
+ values:
+ - another-node-label-value
+ containers:
+ - name: with-node-affinity
+ image: k8s.gcr.io/pause:2.0
\ No newline at end of file
diff --git a/content/id/examples/pods/pod-with-pod-affinity.yaml b/content/id/examples/pods/pod-with-pod-affinity.yaml
new file mode 100644
index 0000000000..35e645ef1f
--- /dev/null
+++ b/content/id/examples/pods/pod-with-pod-affinity.yaml
@@ -0,0 +1,29 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: with-pod-affinity
+spec:
+ affinity:
+ podAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - labelSelector:
+ matchExpressions:
+ - key: security
+ operator: In
+ values:
+ - S1
+ topologyKey: failure-domain.beta.kubernetes.io/zone
+ podAntiAffinity:
+ preferredDuringSchedulingIgnoredDuringExecution:
+ - weight: 100
+ podAffinityTerm:
+ labelSelector:
+ matchExpressions:
+ - key: security
+ operator: In
+ values:
+ - S2
+ topologyKey: failure-domain.beta.kubernetes.io/zone
+ containers:
+ - name: with-pod-affinity
+ image: k8s.gcr.io/pause:2.0
diff --git a/content/ja/case-studies/chinaunicom/chinaunicom_featured_logo.png b/content/ja/case-studies/chinaunicom/chinaunicom_featured_logo.png
new file mode 100644
index 0000000000..f90ff1e509
Binary files /dev/null and b/content/ja/case-studies/chinaunicom/chinaunicom_featured_logo.png differ
diff --git a/content/ja/case-studies/chinaunicom/index.html b/content/ja/case-studies/chinaunicom/index.html
new file mode 100644
index 0000000000..561c47e0d3
--- /dev/null
+++ b/content/ja/case-studies/chinaunicom/index.html
@@ -0,0 +1,104 @@
+---
+title: China Unicom Case Study
+
+linkTitle: chinaunicom
+case_study_styles: true
+cid: caseStudies
+css: /css/style_case_studies.css
+logo: chinaunicom_featured_logo.png
+featured: true
+weight: 1
+quote: >
+ Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところこれに代わるテクノロジーはありません。
+---
+
+
+
+
+ 企業名 China Unicom 所在地 中国、北京 業界 テレコム
+
+
+
+
+
+
+ 課題
+ China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 VMWare、OpenStackのインフラやDockerによるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。
+
+
+ ソリューション
+ 急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところこれに代わるテクノロジーはありません。」また、China Unicomはそのマイクロサービスフレームワークのために、Istio、 Envoy、 CoreDNS、そしてFluentdも活用しています。
+
+インパクト
+ KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。
+リソース使用率は20〜50%上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。
+
+
+
+
+
+
+
+
+ China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。
+
+ その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」
+
+ そこで新しいテクノロジー、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。
+
+
+
+
+
+ China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。
+
+ 同社のKubernetes対応クラウドプラットフォームは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単にテクノロジーが利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。
+
+ 「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところこれに代わるテクノロジーはありません。」
+
+
+
+
+
+
+
+ 事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50%上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」
+ China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。
+
+
+
+
+
+ プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブテクノロジーは比較的シンプルなのではないか」と指摘しています。
+ 「企業は Rancher のような事業者が提供するマネージドサービスを活用することができます。こういったテクノロジーはカスタマイズてされて提供されるので、簡単に利用することができるでしょう。」
+
+ 今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。
+
+ それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」
+
+
+
+