Merge pull request #19453 from zacharysarah/zacharysarah-merged-master-dev-1.18

Merge master into dev-1.18
2020-03-03 12:43:47 -08:00
parent 78193337e4 4582f017e2
commit bd99f2ab93
115 changed files with 3895 additions and 613 deletions
@@ -30,7 +30,6 @@ aliases:
    - onlydole
    - parispittman
    - vonguard
-    - onlydole
  sig-docs-de-owners: # Admins for German content
    - bene2k1
    - mkorbi
@@ -49,6 +48,7 @@ aliases:
    - kbarnard10
    - kbhawkey
    - makoscafee
+    - onlydole
    - Rajakavitha1
    - sftim
    - steveperry-53
@@ -67,6 +67,7 @@ aliases:
    - kbarnard10
    - kbhawkey
    - makoscafee
+    - onlydole
    - rajakavitha1
    - sftim
    - steveperry-53
@@ -133,18 +133,21 @@ $feature-box-div-width: 45%
        max-width: 25%
        max-height: 100%
        transform: translateY(-50%)
+        width: 100%

      &:nth-child(odd)
        padding-right: 210px

        .image-wrapper
          right: 0
+          text-align: right

      &:nth-child(even)
        padding-left: 210px

        .image-wrapper
          left: 0
+          text-align: left

      &:nth-child(1)
        padding-right: 0
@@ -52,7 +52,7 @@ Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen,

 ### Kubernetes Master

-Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters.
+Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommandozeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters.

 > Der Begriff "Master" bezeichnet dabei eine Reihe von Prozessen, die den Clusterstatus verwalten.  Normalerweise werden diese Prozesse alle auf einem einzigen Node im Cluster ausgeführt. Dieser Node wird auch als Master bezeichnet. Der Master kann repliziert werden, um die Verfügbarkeit und Redundanz zu erhöhen.

@@ -96,7 +96,7 @@ Das Google service Konto der Instanz hat einen `https://www.googleapis.com/auth/

 Kubernetes eine native Unterstützung für die [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) wenn Knoten AWS EC2 Instanzen sind.

-Es muss einfah nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden.
+Es muss einfach nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden.

 Alle Benutzer eines Clusters die Pods erstellen dürfen können dann jedes der Images in der ECR Registry zum Ausführen von Pods nutzen.

@@ -205,7 +205,7 @@ Weitere Informationen zu unterstützten Treibern und zur Installation von Plugin

 ### Lokale Images durch erneute Verwendung des Docker-Daemon ausführen

-Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importortieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben.
+Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben.

 Um mit dem Docker-Daemon auf Ihrem Mac/Linux-Computer arbeiten zu können, verwenden Sie den `docker-env`-Befehl in Ihrer Shell:

@@ -0,0 +1,82 @@
+---
+title: Bring your ideas to the world with kubectl plugins
+date: 2020-02-28
+---
+
+**Author:** Cornelius Weig (TNG Technology Consulting GmbH)
+
+`kubectl` is the most critical tool to interact with Kubernetes and has to address multiple user personas, each with their own needs and opinions. 
+One way to make `kubectl` do what you need is to build new functionality into `kubectl`.
+
+
+## Challenges with building commands into `kubectl`
+
+However, that's easier said than done. Being such an important cornerstone of
+Kubernetes, any meaningful change to `kubectl` needs to undergo a Kubernetes
+Enhancement Proposal (KEP) where the intended change is discussed beforehand.
+
+When it comes to implementation, you'll find that `kubectl` is an ingenious and
+complex piece of engineering. It might take a long time to get used to
+the processes and style of the codebase to get done what you want to achieve. Next
+comes the review process which may go through several rounds until it meets all
+the requirements of the Kubernetes maintainers -- after all, they need to take
+over ownership of this feature and maintain it from the day it's merged.
+
+When everything goes well, you can finally rejoice. Your code will be shipped
+with the next Kubernetes release. Well, that could mean you need to wait
+another 3 months to ship your idea in `kubectl` if you are unlucky.
+
+So this was the happy path where everything goes well. But there are good
+reasons why your new functionality may never make it into `kubectl`. For one,
+`kubectl` has a particular look and feel and violating that style will not be
+acceptable by the maintainers. For example, an interactive command that
+produces output with colors would be inconsistent with the rest of `kubectl`.
+Also, when it comes to tools or commands useful only to a minuscule proportion
+of users, the maintainers may simply reject your proposal as `kubectl` needs to
+address common needs.
+
+But this doesn’t mean you can’t ship your ideas to `kubectl` users.
+
+## What if you didn’t have to change `kubectl` to add functionality?
+
+This is where `kubectl` [plugins](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/) shine.
+Since `kubectl` v1.12, you can simply
+drop executables into your `PATH`, which follows the naming pattern
+`kubectl-myplugin`. Then you can execute this plugin as `kubectl myplugin`, and
+it will just feel like a normal sub-command of `kubectl`.
+
+Plugins give you the opportunity to try out new experiences like terminal UIs,
+colorful output, specialized functionality, or other innovative ideas. You can
+go creative, as you’re the owner of your own plugin.
+
+Further, plugins offer safe experimentation space for commands you’d like to
+propose to `kubectl`. By pre-releasing as a plugin, you can push your
+functionality faster to the end-users and quickly gather feedback. For example,
+the [kubectl-debug](https://github.com/verb/kubectl-debug) plugin is proposed
+to become a built-in command in `kubectl` in a
+[KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md)).
+In the meanwhile, the plugin author can ship the functionality and collect
+feedback using the plugin mechanism.
+
+## How to get started with developing plugins
+
+If you already have an idea for a plugin, how do you best make it happen?
+First you have to ask yourself if you can implement it as a wrapper around
+existing `kubectl` functionality. If so, writing the plugin as a shell script
+is often the best way forward, because the resulting plugin will be small,
+works cross-platform, and has a high level of trust because it is not
+compiled.
+
+On the other hand, if the plugin logic is complex, a general-purpose language
+is usually better. The canonical choice here is Go, because you can use the
+excellent `client-go` library to interact with the Kubernetes API. The Kubernetes
+maintained [sample-cli-plugin](https://github.com/kubernetes/sample-cli-plugin)
+demonstrates some best practices and can be used as a template for new plugin
+projects.
+
+When the development is done, you just need to ship your plugin to the
+Kubernetes users. For the best plugin installation experience and discoverability,
+you should consider doing so via the
+[krew](https://github.com/kubernetes-sigs/krew) plugin manager. For an in-depth
+discussion about the technical details around `kubectl` plugins, refer to the
+documentation on [kubernetes.io](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/).
@@ -157,7 +157,7 @@ controller deletes the node from its list of nodes.
 The third is monitoring the nodes' health. The node controller is
 responsible for updating the NodeReady condition of NodeStatus to
 ConditionUnknown when a node becomes unreachable (i.e. the node controller stops
-receiving heartbeats for some reason, e.g. due to the node being down), and then later evicting
+receiving heartbeats for some reason, for example due to the node being down), and then later evicting
 all the pods from the node (using graceful termination) if the node continues
 to be unreachable. (The default timeouts are 40s to start reporting
 ConditionUnknown and 5m after that to start evicting pods.) The node controller
@@ -94,7 +94,7 @@ Different settings can be applied to a load balancer service in AWS using _annot
 * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix.
 * `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`.
 * `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`.
+* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, for example `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`.
 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining.
 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
 * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
@@ -140,7 +140,7 @@ Reasons to prefer fewer clusters per availability zone are:

  - improved bin packing of Pods in some cases with more nodes in one cluster (less resource fragmentation).
  - reduced operational overhead (though the advantage is diminished as ops tooling and processes mature).
-  - reduced costs for per-cluster fixed resource costs, e.g. apiserver VMs (but small as a percentage
+  - reduced costs for per-cluster fixed resource costs, for example apiserver VMs (but small as a percentage
    of overall cluster cost for medium to large clusters).

 Reasons to have multiple clusters include:
@@ -76,7 +76,7 @@ should set up a solution to address that.
 For example, in Kubernetes clusters, deployed by the `kube-up.sh` script,
 there is a [`logrotate`](https://linux.die.net/man/8/logrotate)
 tool configured to run each hour. You can also set up a container runtime to
-rotate application's logs automatically, e.g. by using Docker's `log-opt`.
+rotate application's logs automatically, for example by using Docker's `log-opt`.
 In the `kube-up.sh` script, the latter approach is used for COS image on GCP,
 and the former approach is used in any other environment. In both cases, by
 default rotation is configured to take place when log file exceeds 10MB.
@@ -17,7 +17,7 @@ There are several ways to do this, and the recommended approaches all use
 [label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
 Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
 (e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.)
-but there are some circumstances where you may want more control on a node where a pod lands, e.g. to ensure
+but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure
 that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
 services that communicate a lot into the same availability zone.

@@ -176,7 +176,7 @@ Y is expressed as a LabelSelector with an optional associated list of namespaces
 (and therefore the labels on pods are implicitly namespaced),
 a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain
 like node, rack, cloud provider zone, cloud provider region, etc. You express it using a `topologyKey` which is the
-key for the node label that the system uses to denote such a topology domain, e.g. see the label keys listed above
+key for the node label that the system uses to denote such a topology domain; for example, see the label keys listed above
 in the section [Interlude: built-in node labels](#built-in-node-labels).

 {{< note >}}
@@ -366,7 +366,7 @@ Some of the limitations of using `nodeName` to select nodes are:
    some cases may be automatically deleted.
 -   If the named node does not have the resources to accommodate the
    pod, the pod will fail and its reason will indicate why,
-    e.g. OutOfmemory or OutOfcpu.
+    for example OutOfmemory or OutOfcpu.
 -   Node names in cloud environments are not always predictable or
    stable.

@@ -158,12 +158,9 @@ globalDefault: false
 description: "This priority class should be used for XYZ service pods only."
 ```

-### Non-preempting PriorityClasses (alpha) {#non-preempting-priority-class}
+## Non-preempting PriorityClass {#non-preempting-priority-class}

-1.15 adds the `PreemptionPolicy` field as an alpha feature.
-It is disabled by default in 1.15,
-and requires the `NonPreemptingPriority`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/
-) to be enabled.
+{{< feature-state for_k8s_version="1.15" state="alpha" >}}

 Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue
 ahead of lower-priority pods,
@@ -187,6 +184,10 @@ which will allow pods of that PriorityClass to preempt lower-priority pods
 If `PreemptionPolicy` is set to `Never`,
 pods in that PriorityClass will be non-preempting.

+The use of the `PreemptionPolicy` field requires the `NonPreemptingPriority`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+to be enabled.
+
 An example use case is for data science workloads.
 A user may submit a job that they want to be prioritized above other workloads,
 but do not wish to discard existing work by preempting running pods.
@@ -194,7 +195,7 @@ The high priority job with `PreemptionPolicy: Never` will be scheduled
 ahead of other queued pods,
 as soon as sufficient cluster resources "naturally" become free.

-#### Example Non-preempting PriorityClass
+### Example Non-preempting PriorityClass

 ```yaml
 apiVersion: scheduling.k8s.io/v1
@@ -128,7 +128,12 @@ Regardless of how they are installed, the new resources are referred to as Custo

 ## CustomResourceDefinitions

-The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource.
+The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
+API resource allows you to define custom resources.
+Defining a CRD object creates a new custom resource with a name and schema that you specify.
+The Kubernetes API serves and handles the storage of your custom resource.
+The name of a CRD object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

 This frees you from writing your own API server to handle the custom resource,
 but the generic nature of the implementation means you have less flexibility than with
@@ -179,7 +184,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
 | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes |
 | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
 | Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource)  | Yes |
-| Status Subresource | <ul><li>Finer-grained access control: user writes spec section, controller writes status section.</li><li>Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)</li></ul> | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes |
+| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes |
 | Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes |
 | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes |
 | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
@@ -154,7 +154,7 @@ most network plugins.

 Where needed, you can specify the MTU explicitly with the `network-plugin-mtu` kubelet option.  For example,
 on AWS the `eth0` MTU is typically 9001, so you might specify `--network-plugin-mtu=9001`.  If you're using IPSEC you
-might reduce it to allow for encapsulation overhead e.g. `--network-plugin-mtu=8873`.
+might reduce it to allow for encapsulation overhead; for example: `--network-plugin-mtu=8873`.

 This option is provided to the network-plugin; currently **only kubenet supports `network-plugin-mtu`**.

@@ -55,7 +55,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/
      * `--feature-gates="IPv6DualStack=true"`
   * kube-proxy:
      * `--proxy-mode=ipvs`
-      * `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>`
+      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
      * `--feature-gates="IPv6DualStack=true"`

 {{< caution >}}
@@ -350,7 +350,7 @@ parameters:
  contains user password to use when talking to Gluster REST service. These
  parameters are optional, empty password will be used when both
  `secretNamespace` and `secretName` are omitted. The provided secret must have
-  type `"kubernetes.io/glusterfs"`, e.g. created in this way:
+  type `"kubernetes.io/glusterfs"`, for example created in this way:

    ```
    kubectl create secret generic heketi-secret \
@@ -514,7 +514,7 @@ parameters:
  same as `adminId`.
 * `userSecretName`: The name of Ceph Secret for `userId` to map RBD image. It
  must exist in the same namespace as PVCs. This parameter is required.
-  The provided secret must have type "kubernetes.io/rbd", e.g. created in this
+  The provided secret must have type "kubernetes.io/rbd", for example created in this
  way:

    ```shell
@@ -561,7 +561,7 @@ parameters:
 * `adminSecretName`: secret that holds information about the Quobyte user and
  the password to authenticate against the API server. The provided secret
  must have type "kubernetes.io/quobyte" and the keys `user` and `password`,
-  e.g. created in this way:
+  for example:

    ```shell
    kubectl create secret generic quobyte-admin-secret \
@@ -39,7 +39,8 @@ You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` f

 {{< codenew file="controllers/daemonset.yaml" >}}

-* Create a DaemonSet based on the YAML file:
+Create a DaemonSet based on the YAML file:
+
 ```
 kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 ```
@@ -50,6 +51,9 @@ As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and
 general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/),
 [configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents.

+The name of a DaemonSet object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section.

 ### Pod Template
@@ -1020,6 +1020,8 @@ can create multiple Deployments, one for each release, following the canary patt
 As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields.
 For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
 configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
+The name of a Deployment object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

 A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).

@@ -58,22 +58,26 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```

 You can then get the current ReplicaSets deployed:
+
 ```shell
 kubectl get rs
 ```

 And see the frontend one you created:
+
 ```shell
 NAME       DESIRED   CURRENT   READY   AGE
 frontend   3         3         3       6s
 ```

-You can also check on the state of the replicaset:
+You can also check on the state of the ReplicaSet:
+
 ```shell
 kubectl describe rs/frontend
 ```

 And you will see output similar to:
+
 ```shell
 Name:		frontend
 Namespace:	default
@@ -106,11 +110,13 @@ Events:
 ```

 And lastly you can check for the Pods brought up:
+
 ```shell
 kubectl get Pods
 ```

 You should see Pod information similar to:
+
 ```shell
 NAME             READY     STATUS    RESTARTS   AGE
 frontend-9si5l   1/1       Running   0          1m
@@ -120,11 +126,13 @@ frontend-qhloh   1/1       Running   0          1m

 You can also verify that the owner reference of these pods is set to the frontend ReplicaSet.
 To do this, get the yaml of one of the Pods running:
+
 ```shell
 kubectl get pods frontend-9si5l -o yaml
 ```

 The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field:
+
 ```shell
 apiVersion: v1
 kind: Pod
@@ -169,11 +177,13 @@ The new Pods will be acquired by the ReplicaSet, and then immediately terminated
 its desired count.

 Fetching the Pods:
+
 ```shell
 kubectl get Pods
 ```

 The output shows that the new Pods are either already terminated, or in the process of being terminated:
+
 ```shell
 NAME             READY   STATUS        RESTARTS   AGE
 frontend-9si5l   1/1     Running       0          1m
@@ -183,17 +193,20 @@ pod2             0/1     Terminating   0          4s
 ```

 If you create the Pods first:
+
 ```shell
 kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
 ```

 And then create the ReplicaSet however:
+
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```

 You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the
 number of its new Pods and the original matches its desired count. As fetching the Pods:
+
 ```shell
 kubectl get Pods
 ```
@@ -215,6 +228,9 @@ For ReplicaSets, the kind is always just ReplicaSet.
 In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
 Refer to the first lines of the `frontend.yaml` example for guidance.

+The name of a ReplicaSet object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).

 ### Pod Template
@@ -109,10 +109,15 @@ In the above example:
 * The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
 * The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.

+The name of a StatefulSet object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 ## Pod Selector
+
 You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.

 ## Pod Identity
+
 StatefulSet Pods have a unique identity that is comprised of an ordinal, a
 stable network identity, and stable storage. The identity sticks to the Pod,
 regardless of which node it's (re)scheduled on.
@@ -732,7 +732,7 @@ For Kubernetes 1.9 and earlier, we recommend running the following set of admiss
  ```

  * It's worth reiterating that in 1.9, these happen in a mutating phase
-and a validating phase, and that e.g. `ResourceQuota` runs in the validating
+and a validating phase, and that for example `ResourceQuota` runs in the validating
 phase, and therefore is the last admission controller to run.
 `MutatingAdmissionWebhook` appears before it in this list, because it runs
 in the mutating phase.
@@ -1048,7 +1048,7 @@ to turn up in a new cluster.

 The scheme must be "https"; the URL must begin with "https://".

-Attempting to use a user or basic auth e.g. "user:password@" is not allowed.
+Attempting to use a user or basic auth (for example "user:password@") is not allowed.
 Fragments ("#...") and query parameters ("?...") are also not allowed.

 Here is an example of a mutating webhook configured to call a URL
@@ -578,7 +578,7 @@ A number of markers were added in Kubernetes 1.16 and 1.17, to allow API develop
 | Golang marker | OpenAPI extension | Accepted values | Description | Introduced in |
 |---|---|---|---|---|
 | `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16          |
-| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries e.g. `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 |
+| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 |
 | `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 |
 | `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 |

@@ -88,7 +88,7 @@ The following production environment solutions table lists the providers and the
 | [Ionos](https://www.ionos.com/enterprise-cloud)        | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
 | [Kontena Pharos](https://www.kontena.io/pharos/)          |    |&#x2714;|    &#x2714;    |        |         |
 | [KubeOne](https://kubeone.io/) |  | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |
-| [Kubermatic](https://kubermatic.io/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |  |
+| [Kubermatic](https://kubermatic.io/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |
 | [KubeSail](https://kubesail.com/)    | &#x2714;       |  |      |     |        |
 | [Kubespray](https://kubespray.io/#/)       |       |    |       |&#x2714;  | &#x2714; | &#x2714; |
 | [Kublr](https://kublr.com/)        |&#x2714; | &#x2714;  |&#x2714;       |&#x2714;  |&#x2714; |&#x2714; |
@@ -397,7 +397,7 @@ If your network is not working or CoreDNS is not in the Running state, checkout
 ### Control plane node isolation

 By default, your cluster will not schedule Pods on the control-plane node for security
-reasons. If you want to be able to schedule Pods on the control-plane node, e.g. for a
+reasons. If you want to be able to schedule Pods on the control-plane node, for example for a
 single-machine Kubernetes cluster for development, run:

 ```bash
@@ -63,7 +63,7 @@ The jsonpath is interpreted as follows:
 - `.image`: get the image

 {{< note >}}
-When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
+When fetching a single Pod by name, for example `kubectl get pod nginx`,
 the `.items[*]` portion of the path should be omitted because a single
 Pod is returned instead of a list of items.
 {{< /note >}}
@@ -113,7 +113,7 @@ track=stable

 - **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials.

-  Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, e.g. `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a  [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters.
+  Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a  [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters.

  In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied.

@@ -246,6 +246,9 @@ spec:
  caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
 ```

+The name of an APIService object must be a valid
+[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
+
 #### Contacting the extension apiserver

 Once the Kubernetes apiserver has determined a request should be sent to a extension apiserver,
@@ -502,7 +502,7 @@ to turn up in a new cluster.

 The scheme must be "https"; the URL must begin with "https://".

-Attempting to use a user or basic auth e.g. "user:password@" is not allowed.
+Attempting to use a user or basic auth (for example "user:password@") is not allowed.
 Fragments ("#...") and query parameters ("?...") are also not allowed.

 Here is an example of a conversion webhook configured to call a URL
@@ -366,7 +366,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables

 {{< feature-state state="stable" for_kubernetes_version="1.16" >}}

-CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources like e.g. a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.
+CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.

 {{< tabs name="CustomResourceDefinition_pruning" >}}
 {{% tab name="apiextensions.k8s.io/v1" %}}
@@ -37,7 +37,7 @@ The agent configuration file must be written in YAML or JSON syntax, and may con

 *   **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
 *   **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
-*   **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc...
+*   **resyncInterval:** A time interval at which the agent attempts to reload config from disk. For example: '30s', where 's' means seconds, 'ms' means milliseconds, etc...

 Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded.  An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range.   Any other traffic will be masqueraded by default.  The below entries show the default set of rules that are applied by the ip-masq-agent:

@@ -72,9 +72,9 @@ cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be
 scheduled, but will fail to launch.

 With the warning above in mind, the cluster admin can allow certain _unsafe_
-sysctls for very special situations like e.g. high-performance or real-time
+sysctls for very special situations such as high-performance or real-time
 application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
-flag of the kubelet, e.g.:
+flag of the kubelet; for example:

 ```shell
 kubelet --allowed-unsafe-sysctls \
@@ -63,7 +63,7 @@ For example, this is how to start a simple web server as a static Pod:
    ssh my-node1
    ```

-2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:
+2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, for example `/etc/kubelet.d/static-web.yaml`:

    ```shell
    # Run this command on the node where kubelet is running
@@ -34,13 +34,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re

 ```sh
 # Linux
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-linux-amd64 -o kompose
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-linux-amd64 -o kompose

 # macOS
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-darwin-amd64 -o kompose
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-darwin-amd64 -o kompose

 # Windows
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-windows-amd64.exe -o kompose.exe
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-windows-amd64.exe -o kompose.exe

 chmod +x kompose
 sudo mv ./kompose /usr/local/bin/kompose
@@ -580,7 +580,7 @@ If you want to create normal pods without controllers you can use `restart` cons
 The controller object could be `deployment` or `replicationcontroller`, etc.
 {{< /note >}}

-For e.g. `pival` service will become pod down here. This container calculated value of `pi`.
+For example, the `pival` service will become pod down here. This container calculated value of `pi`.

 ```yaml
 version: '2'
@@ -272,7 +272,7 @@ to turn up in a new cluster.

 The scheme must be "https"; the URL must begin with "https://".

-Attempting to use a user or basic auth e.g. "user:password@" is not allowed.
+Attempting to use a user or basic auth (for example "user:password@") is not allowed.
 Fragments ("#...") and query parameters ("?...") are also not allowed.

 Here is an example of a webhook configured to call a URL
@@ -55,7 +55,7 @@ This is an incomplete list of things that could go wrong, and how to adjust your
  - Network partition within cluster, or between cluster and users
  - Crashes in Kubernetes software
  - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume)
-  - Operator error, e.g. misconfigured Kubernetes software or application software
+  - Operator error, for example misconfigured Kubernetes software or application software

 ### Specific scenarios:

@@ -362,7 +362,7 @@ you want to add Kafka sink for messages from a particular container for addition
 You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
 with minor changes:

-* Change Makefile to point to your container repository, e.g. `PREFIX=gcr.io/<your-project-id>`.
+* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/<your-project-id>`.
 * Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`.

 Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
@@ -21,9 +21,7 @@ encryption keys, into Pods.
 ## Convert your secret data to a base-64 representation

 Suppose you want to have two pieces of secret data: a username `my-app` and a password
-`39528$vdg7Jb`. First, use online Base 64 Encoding Tool [Base64 encoding](https://www.base64encode.org/), [Base64 encode](https://goonlinetools.com/base64-encode/) to
-convert your username and password to a base-64 representation. Here's a Linux
-example:
+`39528$vdg7Jb`. First, use a base64 encoding tool to convert your username and password to a base64 representation. Here's an example using the commonly available base64 program:

 ```shell
 echo -n 'my-app' | base64
@@ -132,7 +132,8 @@ NAME                               CONTROLLER                     REVISION   AGE
 ```

 Each `ControllerRevision` stores the annotations and template of a DaemonSet
-revision.
+revision. The name of a ControllerRevision object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

 `kubectl rollout undo` takes a specific `ControllerRevision` and replaces
 DaemonSet template with the template stored in the `ControllerRevision`.
@@ -33,7 +33,7 @@ DaemonSet has two update strategy types:
 * RollingUpdate: This is the default update strategy.  
  With `RollingUpdate` update strategy, after you update a
  DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods
-  will be created automatically, in a controlled fashion.
+  will be created automatically, in a controlled fashion. At most one pod of the DaemonSet will be running on each node during the whole update process.

 ## Performing a Rolling Update

@@ -45,12 +45,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
        <br>
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
+        <a href="https://www.lfasiallc.cn/kubecon-cloudnativecon-open-source-summit-china/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncch20" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -26,12 +26,12 @@ weight: 40

 ## 쿠버네티스 오브젝트

-쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 문서를 참조한다.
+쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 문서를 참조한다.

 기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다.

 * [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
-* [서비스](/docs/concepts/services-networking/service/)
+* [서비스](/ko/docs/concepts/services-networking/service/)
 * [볼륨](/docs/concepts/storage/volumes/)
 * [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/)

@@ -26,7 +26,7 @@ weight: 30
 ## 컨트롤러 패턴

 컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다.
-이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
 는 의도한 상태를 표현하는 사양 필드를 가지고 있다.
 해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 
 상태에 가깝게 만드는 역할을 한다.
@@ -103,7 +103,7 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll

 ## 관리

-[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/docs/concepts/services-networking/service/)와 달리,
+[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/ko/docs/concepts/services-networking/service/)와 달리,
 노드는 본래 쿠버네티스에 의해 생성되지 않는다. 구글 컴퓨트 엔진과 같은 클라우드 제공사업자에 의해 
 외부로부터 생성 되거나, 물리적 또는 가상 머신의 풀 내에서 존재한다. 
 그래서 쿠버네티스가 노드를 생성할 때, 
@@ -272,6 +272,12 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄
 애플리케이션을 유출시키는 중이라 할지라도 머신 상에 속한 데몬으로 여긴다.
 {{< /note >}}

+{{< caution >}}
+`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는
+서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에
+사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다.
+{{< /caution >}}
+
 ### 노드 용량

 노드의 용량 (cpu 수와 메모리 양) 은 노드 오브젝트의 한 부분이다.
@@ -1,48 +0,0 @@
---
-title: 컨트롤러 관리자 메트릭
-content_template: templates/concept
-weight: 100
---
-
-{{% capture overview %}}
-컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한
-중요한 통찰을 제공한다.
-
-{{% /capture %}}
-
-{{% capture body %}}
-## 컨트롤러 관리자 메트릭은 무엇인가
-
-컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 통찰을 제공한다.
-메트릭은 go_routine count와 같은 일반적인 Go 언어 런타임 메트릭과 
-etcd 요청 대기 시간 또는 클라우드 제공자(AWS, GCE, OpenStack) API 대기 시간과 같이 클러스터 상태를
-측정할 수 있는 컨트롤러 특징적 메트릭을 포함한다.
-
-쿠버네티스 1.7 부터, GCE, AWS, Vsphere 그리고 OpenStack의 저장소 작업에 대한 자세한 클라우드 제공자 메트릭을 사용할 수 있다.
-이 메트릭은 영구 볼륨 작업의 상태 감시에 사용될 수 있다.
-
-예를 들어, GCE의 경우 다음과 같은 메트릭이 호출된다:
-
-```
-cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
-cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
-```
-
-
-
-## 구성
-
-
-클러스터에서 컨트롤러-관리자 메트릭은 컨트롤러-관리자가 실행되고 있는 호스트의 `http://localhost:10252/metrics`를 통해서
-이용 가능하다.
-
-메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)에서 나오고, 사람이 읽을 수 있다.
-
-운영 환경에서는 주기적으로 메트릭을 모으고, 일종의 시계열 데이터베이스로 만들기 위해,
-프로메테우스 설정이나 다른 메트릭 수집기를 구성할 것이다.
-
-{{% /capture %}}
@@ -33,7 +33,7 @@ weight: 90
    - 노드, 파드, 서비스에 도달하는데 사용할 수 있다.
    - 서비스에 도달할 때에는 로드 밸런싱을 수행한다.

-1.  [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1.  [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips):

    - 각 노드에서 실행한다.
    - UDP, TCP, SCTP를 이용하여 프락시 한다.
@@ -37,7 +37,7 @@ weight: 10

 ## 서비스

- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
+- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.

  ```shell
  FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
@@ -51,14 +51,14 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며

 - 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다.

-  만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.
+  만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.

-  만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다.
+  만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다.

 - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다.

- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-
-services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
+- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-
+서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.

 ## 레이블 사용하기

@@ -56,7 +56,7 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
 {{< note >}}
 런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정
 (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다.
-이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄링](#scheduling)을 참고한다.
+이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다.
 {{< /note >}}

 해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
@@ -162,7 +162,7 @@ https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
 노드의 합집합을 취한다.

 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면
-[노드에 파드 할당](/docs/concepts/configuration/assign-pod-node/)을 참고한다.
+[노드에 파드 할당](/ko/docs/concepts/configuration/assign-pod-node/)을 참고한다.

 [어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/

@@ -0,0 +1,4 @@
+---
+title: 쿠버네티스 확장하기
+weight: 110
+---
@@ -0,0 +1,4 @@
+---
+title: 쿠버네티스 API 확장하기
+weight: 20
+---
@@ -0,0 +1,38 @@
+---
+title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기
+content_template: templates/concept
+weight: 10
+---
+
+{{% capture overview %}}
+
+애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 개요
+
+애그리게이션 레이어는 부가적인 쿠버네티스-스타일 API를 클러스터에 설치할 수 있게 해준다. 이는 [서비스-카탈로그](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)와 같이 사전에 구축되어 있는 서드 파티 솔루션일 수 있고, [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)로 시작해볼 수 있는 것과 같은 사용자 정의 API일 수도 있다.
+
+애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.
+
+대개, APIService는 클러스터 내에서 구동 중인 파드(pod) 내 *extension-apiserver* 로 구현된다. 이 extension-apiserver는 일반적으로 추가된 리소스에 대한 적극적인 관리가 필요한 경우 하나 이상의 컨트롤러와 짝지어진다. 결과적으로, apiserver-builder는 실제로 그 둘 모두에 대한 스켈레톤을 제공한다. 또 다른 예로, 서비스-카탈로그가 설치된 경우에는, 제공하는 서비스에 대한 extension-apiserver와 컨트롤러를 모두 제공한다.
+
+Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮아야 한다.
+특히, kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
+사용자의 환경에서 달성할 수 없는 경우에는, 이를 어떻게 바꿀 수 있을지 고려해야 한다. 지금은,
+`EnableAggregatedDiscoveryTimeout=false` 기능 게이트를 설정해서 타임아웃 제한을
+비활성화 할 수 있다. 이 기능은 미래의 릴리스에서는 삭제될 예정이다.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
+* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
+* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다.
+
+{{% /capture %}}
+
@@ -12,7 +12,7 @@ card:
 {{% /capture %}}

 {{% capture body %}}
-## 쿠버네티스 오브젝트 이해하기
+## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}

 *쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다.

@@ -41,8 +41,9 @@ card:

 {{< codenew file="application/deployment.yaml" >}}

-위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
-
+위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는
+`kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네
+[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.

 ```shell
 kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
@@ -50,8 +51,7 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record

 그 출력 내용은 다음과 유사하다.

-
-```shell
+```
 deployment.apps/nginx-deployment created
 ```

@@ -65,14 +65,15 @@ deployment.apps/nginx-deployment created
 * `spec` - 오브젝트에 대해 어떤 상태를 의도하는지

 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. 
-예를 들어, `파드`에 대한 `spec` 포맷은 
-[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
-에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은 
-[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
+예를 들어, 파드에 대한 `spec` 포맷은 
+[PodSpec v1 Core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은 
+[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.

 {{% /capture %}}

 {{% capture whatsnext %}}
+* API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다.
 * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
 * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
 {{% /capture %}}
@@ -70,7 +70,7 @@ spec:
    image: nginx:1.7.9
    ports:
    - containerPort: 80
-    
+
 ```

 ## 레이블 셀렉터
@@ -209,7 +209,7 @@ selector:

 #### 세트-기반 요건을 지원하는 리소스

-[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
+[`잡`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.

 ```yaml
 selector:
@@ -225,6 +225,6 @@ selector:
 #### 노드 셋 선택

 레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
-자세한 내용은 [노드 선택](/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다.
+자세한 내용은 [노드 선택](/ko/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다.

 {{% /capture %}}
@@ -123,7 +123,7 @@ my-nginx   10.244.2.5:80,10.244.3.4:80   1m
 이제 클러스터의 모든 노드에서 `<CLUSTER-IP>:<PORT>` 로 nginx 서비스를
 curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외부에서는 절대로 연결되지
 않음에 참고한다. 만약 이것이 어떻게 작동하는지 궁금하다면
-[서비스 프록시](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)에 대해 더 읽어본다.
+[서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)에 대해 더 읽어본다.

 ## 서비스에 접근하기

@@ -38,22 +38,24 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.

 ## 서비스

-### A 레코드
+### A/AAAA 레코드

-"노멀"(헤드리스가 아닌) 서비스는 
+"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라
 `my-svc.my-namespace.svc.cluster-domain.example` 
-형식의 이름을 가진 DNS A 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다.
+형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터
+IP로 해석된다.

-"헤드리스"(클러스터 IP가 없는) 서비스 또한 
+"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라
 `my-svc.my-namespace.svc.cluster-domain.example` 
-형식의 이름을 가진 DNS A 레코드가 할당된다. 
+형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 
 노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. 
-클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다.
+클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을
+통해 선택할 수 있다.

 ### SRV 레코드

 SRV 레코드는 노멀 서비스 또는 
-[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)에 
+[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 
 속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. 
 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
 정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. 
@@ -128,22 +130,22 @@ spec:
 ```

 파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, 
-클러스터의 KubeDNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 레코드를 반환한다.
+클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다.
 예를 들어 호스트네임이 "`busybox-1`"이고, 
 서브도메인이 "`default-subdomain`"이고, 
 같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, 
 파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. 
 "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`".
-DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 레코드를 제공한다. 
-"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 레코드를 가지고 있다.
+DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. 
+"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.

 엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다.

 {{< note >}}
-A 레코드는 파드의 이름으로 생성되지 않기 때문에 
-파드의 A 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. 
+A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 
+파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. 
 `hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 
-A 레코드만 생성할 수 있다. 
+A 또는 AAAA 레코드만 생성할 수 있다. 
 (`default-subdomain.my-namespace.svc.cluster-domain.example`)
 또한 레코드를 가지기 위해서는 파드가 준비되어야 한다. 
 그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다.
@@ -27,7 +27,6 @@ weight: 70

   * 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
   * IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.)
-   * Kubenet 다중 주소 패밀리 지원(IPv4와 IPv6)
   * IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 이그레스 라우팅(예: 인터넷)

 ## 필수 구성 요소
@@ -36,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음

   * 쿠버네티스 1.16 또는 이후 버전
   * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
-   * Kubenet 네트워크 플러그인
+   * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
   * IPVS 모드에서 구동 중인 Kube-Proxy

 ## IPv4/IPv6 이중 스택 활성화
@@ -52,7 +51,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요
      * `--feature-gates="IPv6DualStack=true"`
   * kube-proxy:
      * `--proxy-mode=ipvs`
-      * `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>` 
+      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
      * `--feature-gates="IPv6DualStack=true"`

 {{< caution >}}
@@ -15,24 +15,15 @@ weight: 40

 이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다.

-노드(Node)
-: 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
-
-클러스터(Cluster)
-: 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
-
-에지 라우터(Edge router)
-: 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
-
-클러스터 네트워크(Cluster network)
-: 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
-
-서비스(Service)
-: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
+노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
+클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
+에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
+클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
+서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.

 ## 인그레스란?

-인그레스는 클러스터 외부에서 클러스터 내부
+[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
 {{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.

@@ -47,8 +38,8 @@ weight: 40
 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.

 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
-[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는
-[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.
+[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
+[Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.

 ## 전제 조건들

@@ -107,7 +98,7 @@ spec:
 * 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련
  백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가
  모두 수신 요청의 내용과 일치해야 한다.
-* 백엔드는 [서비스 문서](/docs/concepts/services-networking/service/)에 설명된 바와 같이
+* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/)에 설명된 바와 같이
  서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한
  HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.

@@ -220,7 +211,7 @@ Events:
 {{< note >}}
 사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
 에 따라 default-http-backend
-[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
+[서비스](/ko/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
 {{< /note >}}

 ### 이름 기반의 가상 호스팅
@@ -466,12 +457,13 @@ Events:

 사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다.

-* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 사용.
-* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 사용.
+* [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용.
+* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용.

 {{% /capture %}}

 {{% capture whatsnext %}}
+* [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
 {{% /capture %}}
@@ -7,16 +7,16 @@ weight: 50
 {{< toc >}}

 {{% capture overview %}}
-네트워크 정책은 파드 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
+네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.

-`NetworkPolicy` 리소스는 레이블을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
+`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.

 {{% /capture %}}

 {{% capture body %}}
 ## 전제 조건

-네트워크 정책은 네트워크 플러그인으로 구현되므로 `NetworkPolicy` 를 지원하는 네트워킹 솔루션을 사용해야 한다. - 컨트롤러가 없이 단순하게 리소스를 생성하게 되면 아무런 효과가 없기 때문이다. 
+네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다.

 ## 격리 및 격리되지 않은 파드

@@ -26,11 +26,11 @@ weight: 50

 네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.

-## `NetworkPolicy` 리소스
+## NetworkPolicy 리소스 {#networkpolicy-resource}

-리소스에 대한 전체 정의는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
+리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.

-`NetworkPolicy` 의 예시는 다음과 같다.
+NetworkPolicy 의 예시는 다음과 같다.

 ```yaml
 apiVersion: networking.k8s.io/v1
@@ -69,23 +69,25 @@ spec:
      port: 5978
 ```

-*선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 API 서버에 이를 POST 하더라도 효과가 없다.*
+{{< note >}}
+선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
+{{< /note >}}

-__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 `NetworkPolicy` 에는
+__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는
 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일
 작업에 대한 일반적인 정보는
 [컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/),
 그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다.

-__spec__: `NetworkPolicy` [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
+__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.

-__podSelector__: 각 `NetworkPolicy` 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
+__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.

-__policyTypes__: 각 `NetworkPolicy` 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
+__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.

-__ingress__: 각 `NetworkPolicy` 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
+__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.

-__egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
+__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.

 따라서 예시의 NetworkPolicy는 다음과 같이 동작한다.

@@ -103,7 +105,7 @@ __egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포

 `ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다.

-__podSelector__: `NetworkPolicy` 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
+__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.

 __namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다.

@@ -164,16 +166,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C

 모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny
-spec:
-  podSelector: {}
-  policyTypes:
-  - Ingress
-```
+{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}

 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.

@@ -181,33 +174,13 @@ spec:

 만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: allow-all
-spec:
-  podSelector: {}
-  ingress:
-  - {}
-  policyTypes:
-  - Ingress
-```
+{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}

 ### 기본적으로 모든 이그레스 트래픽 거부

 모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny
-spec:
-  podSelector: {}
-  policyTypes:
-  - Egress
-```
+{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}

 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 
 기본 인그레스 격리 정책을 변경하지 않는다.
@@ -216,34 +189,13 @@ spec:

 만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: allow-all
-spec:
-  podSelector: {}
-  egress:
-  - {}
-  policyTypes:
-  - Egress
-```
+{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}

 ### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부

 해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny
-spec:
-  podSelector: {}
-  policyTypes:
-  - Ingress
-  - Egress
-```
+{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}

 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.

@@ -251,9 +203,12 @@ spec:

 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

-쿠버네티스는 `NetworkPolicy` 정의에서 `protocol` 값으로 SCTP를 알파 기능으로 지원한다. 이 기능을 활성화하려면 클러스터 관리자가 apiserver 에서 `SCTPSupport` 기능 게이트를 활성화 할 필요가 있다. 예를 들면, `“--feature-gates=SCTPSupport=true,...”` . 기능 게이트가 활성화 되면 `NetworkPolicy` 의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
+이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
+기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.

-CNI 플러그인은 SCTP를 `NetworkPolicy` 에서 `protocol` 값으로 지원해야 한다.
+{{< note >}}
+SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
+{{< /note >}}


 {{% /capture %}}
@@ -43,23 +43,6 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수
 트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에
 연결된 노드로 트래픽을 유지하는 것이 있다.

-## 전제 조건
-
-서비스 라우팅을 인식하는 토폴로지를 활성화 하려면 다음과 같은 전제 조건이
-필요하다.
-
-   * 쿠버네티스 1.17 또는 이후 버전
-   * Kube-proxy 가 iptables 모드 또는 IPVS 모드에서 실행 중
-   * [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)의 활성화
-
-## 서비스 토폴로지 활성화하기
-
-서비스 토폴로지를 활성화하려면 kube-apiserver 와 kube-proxy의
-기능 게이트에서 `ServiceTopology` 를 활성화 한다.
-
-```
--feature-gates="ServiceTopology=true"
-```

 ## 서비스 토폴로지 사용하기

@@ -114,6 +97,98 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수
  한다.


+## 예시들
+
+다음은 서비스 토폴로지 기능을 사용하는 일반적인 예시이다.
+
+### 노드 로컬 엔드포인트만
+
+노드 로컬 엔드포인트로만 라우팅하는 서비스이다. 만약 노드에 엔드포인트가 없으면 트레픽이 드롭된다.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+```
+
+### 노드 로컬 엔드포인트 선호
+
+노드 로컬 엔드포인트를 선호하지만, 노드 로컬 엔드포인트가 없는 경우 클러스터 전체 엔드포인트로 폴백 하는 서비스이다.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+    - "*"
+```
+
+
+### 영역 또는 지리적 엔드포인트만
+
+영역보다는 지리적 엔드포인트를 선호하는 서비스이다. 만약 엔드포인트가 없다면, 트래픽은 드롭된다.
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "topology.kubernetes.io/zone"
+    - "topology.kubernetes.io/region"
+```
+
+### 노드 로컬, 영역 및 지역 엔드포인트 선호
+
+노드 로컬, 영역 및 지역 엔드포인트를 선호하지만, 클러스터 전체 엔드포인트로 폴백하는 서비스이다.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+    - "topology.kubernetes.io/zone"
+    - "topology.kubernetes.io/region"
+    - "*"
+```
+
+
 {{% /capture %}}

 {{% capture whatsnext %}}
@@ -847,7 +847,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스
 헬스 체크에 실패하고 트래픽을 수신하지 못하게 된다.

 트래픽을 균일하게 하려면, DaemonSet을 사용하거나,
-[파드 안티어피니티(pod anti-affinity)](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
+[파드 안티어피니티(pod anti-affinity)](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
 를 지정하여 동일한 노드에 위치하지 않도록 한다.

 [내부 로드 밸런서](/ko/docs/concepts/services-networking/service/#internal-load-balancer) 어노테이션과 함께 NLB 서비스를
@@ -936,7 +936,7 @@ spec:
 {{< note >}}
 ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
 정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
-[헤드리스(headless) 서비스](#headless-services) 사용을 고려한다.
+[헤드리스(headless) 서비스](#헤드리스-headless-서비스) 사용을 고려한다.
 {{< /note >}}

 `my-service.prod.svc.cluster.local` 호스트를 검색하면, 클러스터 DNS 서비스는
@@ -0,0 +1,5 @@
+---
+title: "스토리지"
+weight: 70
+---
+
@@ -13,8 +13,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
 데몬셋의 일부 대표적인 용도는 다음과 같다.

 - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
+- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행.
+- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행.

 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 
@@ -88,9 +88,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 ### 오직 일부 노드에서만 파드 실행

 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 
-[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/#nodeselector)와 
+[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/#노드-셀렉터-nodeselector)와 
 일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 
-데몬셋 컨트롤러는 [노트 어피니티](/docs/concepts/configuration/assign-pod-node/#node-affinity)와 일치하는 노드에 파드를 생성한다. 
+데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/configuration/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 
 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.

 ## 데몬 파드가 스케줄 되는 방법
@@ -161,7 +161,7 @@ nodeAffinity:
 - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
  구성되어있다. 그들은 클라이언트들을 가지지 않는다.
 - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 만들고, 
+- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, 
  그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를
  검색한다.
 - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
@@ -22,7 +22,7 @@ weight: 10
 레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을
 사용한다.

-레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
+레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent)
 필드를 통해서 제공되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다.
 레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
 이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
@@ -250,7 +250,7 @@ matchLabels:

 ### 레플리카셋과 해당 파드 삭제

-레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
+레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.

 REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로 
 설정해야 한다.
@@ -34,7 +34,7 @@ weight: 40

 * 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
 * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. 
-* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
+* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
 * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
 * [롤링 업데이트](#롤링-업데이트)와 기본 
  [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를
@@ -121,7 +121,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 `$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 
 `web-0,web-1,web-2` 이다.
 스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 
-[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 사용할 수 있다.
+[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 사용할 수 있다.
 이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, 
 여기서 "cluster.local"은 클러스터 도메인이다.
 각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 
@@ -130,7 +130,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있

 [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는
 파드의 네트워크 신원을 책임지는 
-[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 생성할 책임이 있다.
+[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다.

 여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, 
 그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다.
@@ -9,7 +9,7 @@ weight: 65
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

 TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
-제한하는 TTL 메커니즘을 제공한다. TTL 컨트롤러는 현재
+제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
 [잡(Job)](/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.
@@ -67,8 +67,6 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수
    모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함.
  * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가
    성공적으로 시작 완료되었음.
-  * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서
-    지금 당장은 파드를 스케줄할 수 없음.
  * `ContainersReady`: 파드 내의 모든 컨테이너가 준비 상태임.


@@ -256,12 +254,6 @@ status:
 파드 준비성 평가에 대한 변경을 촉진하기 위해서,
 이전 파드 조건인 `Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다.

-K8s 1.11에서, 알파 특징으로서, "파드 준비++" 특징을 사용하기 위해서는
-[특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 `PodReadinessGates`를
-참으로 설정함으로써 명시적으로 활성화해야 한다.
-
-K8s 1.12에서는, 해당 특징이 기본으로 활성화되어 있다.
-
 ## 재시작 정책

 PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다.
@@ -13,68 +13,50 @@ weight: 80
 오랜 시간 동안 진행해온 누군가로서,
 혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로서 기여할 수 있다.

-쿠버네티스 문서 내용과 스타일에
-대해 더 많은 정보를 알고 싶다면, 
-[문서 스타일 개요](/docs/contribute/style/)를 참고하자.
+{{% /capture %}}

 {{% capture body %}}

-## 문서 컨트리뷰터 유형
+## 시작하기

- 쿠버네티스 조직의 _멤버_ 는 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고,
-  프로젝트에 어느 정도 시간과 노력을 바친 사람이다.
-  멤버십 자격에 대한 구체적인 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을
-  참고하라.
- SIG Docs _리뷰어_ 는 문서 풀 리퀘스트(pull request) 리뷰하는 일에 관심을 보여서
-  SIG Docs 승인자가 적합한
-  GitHub 그룹 및 저장소 내 그룹과 `OWNERS` 파일에 등록한
-  쿠버네티스 조직의 멤버이다.
- SIG Docs _승인자_ 는 지속적으로 프로젝트에 기여를 해온 좋은 입지를 가진 멤버이다.
-  승인자는 풀 리퀘스트를 머지(merge)할 수 있고,
-  쿠버네티스 조직을 대표하여 콘텐츠를 공개한다.
-  승인자는 거대한 쿠버네티스 커뮤니티에서 SIG Docs를 대표할 수 있다.
-  SIG Docs 승인자의 의무 중 릴리스 조정과 같은 일은
-  상당한 시간을 필요로 한다.
+누구든지 문제에 대한 설명이나, 원하는 문서의 개선사항에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)로 변경하는 기여를 할 수 있다.
+일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있다.
+역할과 권한에 대한 자세한 내용은
+[SIG Docs 참여](/ko/docs/contribute/participating/)를 본다.

-## 문서화에 기여할 수 있는 방법
+쿠버네티스 문서는 GitHub 리포지터리에 있다. 우리는 누구나
+기여를 환경하지만, 쿠버네티스 커뮤니티에서 효과적으로 활동하려면 git과 GitHub의
+기초적인 이해가 필요하다.

-이 목록은 누구나 할 수 있는 일, 쿠버네티스 조직 멤버가 할 수 있는 일,
-그리고 SIG Docs 프로세스의 더 높은 레벨의 접근과 친숙함을 요구하는 일로 나누어졌다.
-지속적으로 기여를 하는 것은
-이미 만들어진 도구(tooling)와 조직의 결정을
-이해하는 데 도움이 될 것이다.
+문서에 참여하려면

-이것은 쿠버네티스 문서에 기여하는 완전한 방법은 아니지만,
-시작하는 데에 도움이 될 것이다.
+1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명한다.
+2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지한다.
+3. [콘텐츠 향상](https://kubernetes.io/docs/contribute/start/#improve-existing-content)과 [변경 검토](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests)의 기본 프로세스를 이해하도록 한다.

- [누구나](/docs/contribute/start/)
-  - 조치 가능한 이슈 열기
- [멤버](/docs/contribute/start/)
-  - 기존 문서 개선
-  - [Slack](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 개선을 위한 아이디어 제시
-  - 문서 접근성 개선
-  - PR에 대한 구속력 없는 피드백 제공
-  - 블로그 포스트 또는 사례 연구 작성
- [리뷰어](/docs/contribute/intermediate/)
-  - 새로운 기능 문서화
-  - 이슈 선별 및 분류
-  - PR 리뷰
-  - 다이어그램, 그래픽 자료, 내장 스크린샷 생성
-  - 현지화(Localization)
-  - docs 대표로 다른 저장소에 기여
-  - 코드 내 사용자 대면 문자열 편집
-  - 코드 주석 및 Godoc 개선
- [승인자](/docs/contribute/advanced/)
-  - 승인되어 머지된 PR을 바탕으로 컨트리뷰터 콘텐츠 출시
-  - docs 대표로 쿠버네티스 릴리스 팀에 참가
-  - 스타일 가이드 개선 제안
-  - 문서 테스트 개선 제안
-  - 쿠버네티스 website 또는 기타 도구(tooling) 개선 제안
+## 기여 모범 사례

+- 명확하고, 의미있는 GIT 커밋 메시지를 작성한다.
+- 이슈를 참조하고, PR이 병합될 때 이슈를 자동으로 닫는 _Github 특수 키워드_ 를 포함한다.
+- 오타 수정, 스타일 변경 또는 문법 변경과 같이 변경이 적은 PR을 생성할때, 비교적으로 적은 변화로 많은 커밋 개수를 받지 않도록 반드시 커밋을 스쿼시(squash)한다.
+- 변경한 코드를 묘사하고, 코드를 변경한 이유를 포함하는 멋진 PR 설명을 포함하고 있는지와 리뷰어를 위한 충분한 정보가 있는지 꼭 확인한다.
+- 추가적인 읽을거리들
+    - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/)
+    - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests )
+    - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git )

-## 추가적인 기여 방법
+## 다른 방법으로 기여하기

 - 트위터나 스택오버플로(Stack Overflow) 등의 온라인 포럼의 쿠버네티스 커뮤니티에 기여하거나 지역 모임과 쿠버네티스 이벤트에 관하여 알고 싶다면 [쿠버네티스 커뮤니티 사이트](/community/)를 확인한다.
 - 기능 개발에 기여하려면 [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 시작한다.

 {{% /capture %}}
+
+{{% capture whatsnext %}}
+
+- 문서에 기여하는 기본적인 사항들에 대한 자세한 내용은 [기여 시작](/docs/contribute/start/)을 본다.
+- 변경을 제안할 때는 [쿠버네티스 문서 스타일가이드](/docs/contribute/style/style-guide/)를 따른다.
+- SIG Docs에 대한 더 자세한 정보는 [SIG Docs에 참여하기](/ko/docs/contribute/participating/)를 본다.
+- 쿠버네티스 문서 현지화에 대한 자세한 내용은 [쿠버네티스 문서 현지화](/docs/contribute/localization/)를 본다.
+
+{{% /capture %}}
@@ -19,7 +19,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
 누구나 풀 리퀘스트(PR)를 요청할 수 있고,
 누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.

-SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수도 있다.
+[멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수 있다.
 이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
 쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
@@ -34,51 +34,47 @@ SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인

 ## 역할과 책임

-풀 리퀘스트가 콘텐츠를 게재하는데 사용되는 브랜치(현재는 `master`)에 머지되면, 해당 콘텐츠가 세상에
-발행되어 널리 읽힐 수 있게 된다. 발행된 콘텐츠가 높은 품질을 유지하도록,
-SIG Docs 승인자만 풀 리퀘스트를 머지할 수 있도록 제한한다.
-다음과 같이 진행된다.
+- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다.
+- 쿠버네티스 조직의 **맴버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 맴버십 기준은 [커뮤니티 맴버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다.
+- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로
+  문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에
+  의해 GitHub 리포지터리에 있는 GitHub
+  그룹과 `OWNER` 파일에 추가되었다.
+- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준 
+  좋은 맴버이다. 승인자는 쿠버네티스 조직을 대신해서
+  풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다. 
+  또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다.
+  릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는
+  상당한 시간 투입이 필요하다.

- 풀 리퀘스트에 `lgtm`과 `approve` 레이블이 부여되고 `hold` 레이블이 없는 경우에, 해당
-  풀 리퀘스트가 자동으로 머지된다.
- 쿠버네티스 조직 멤버와 SIG Docs 승인자는 코멘트를 추가해서(`/hold` 코멘트를 추가하거나
-  `/lgtm` 코멘트를 달지 않아서) 주어진 풀 리퀘스트가
-  자동으로 머지되는 것을 막을 수 있다.
- 쿠버네티스 멤버 누구나 `/lgtm` 코멘트를 달아서 `lgtm` 레이블을 추가할 수 있다.
- `/approve` 코멘트를 달아서 풀 리퀘스트를 머지할 수 있는 SIG Docs 멤버는 승인자 뿐이다.
-  일부 승인자는 추가로 [PR Wrangler](#pr-wrangler) 또는
-  [SIG Docs chairperson](#sig-docs-chairperson) 같이
-  특화된 역할을 수행한다.
+## 모든 사람

-쿠버네티스 조직 멤버와 SIG Docs 승인자 역할 사이의 기대와 차이에 대한 보다 많은 정보는
-[컨트리뷰터 유형](/docs/contribute#types-of-contributor) 문서를 참고한다.
-다음 섹션에서는 이런 역할과 SIG Docs에서
-이들이 작동하는 방식에 대해
-보다 상세한 내용을 다룬다.
+누구나 다음 작업을 할 수 있다.

-### 모든 사람
+- 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기.
+- 풀 리퀘스트/ 에 대한 구속력 없는 피드백 제공
+- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다.
+- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다.
+  {{< note >}}
+  만약 쿠버네티스 조직의 맴버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다.
+  {{< /note >}}

-문서를 포함해서, 쿠버네티스의 모든 부분에 대해서 누구나 이슈를 제기할 수 있다.
+[CLS에 서명](/docs/contribute/start#sign-the-cla) 후에 누구나 다음을 할 수 있다.
+- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.

-CLA에 서명한 누구나 풀 리퀘스트를 제출할 수 있다. CLA에 서명할 수 없다면,
-쿠버네티스 프로젝트는 컨트리뷰션을 수용할 수 없다.
+## 맴버

-### 멤버
+맴버는 [맴버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 맴버로부터 기여를 환경하며,
+기술적 정확성에 대한 다른 SIG 맴버들의 검토를 수시로 요청한다.

-[쿠버네티스 조직](https://github.com/kubernetes)의 모든 멤버가 풀 리퀘스트를 리뷰할 수 있고,
-기술적 정확도를 기하기 위해 SIG Docs 팀 멤버가 다른 분과회 멤버의 리뷰를 요청하는 일도 자주
-발생한다.
-SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주는 리뷰와 피드백 또한 환영한다.
-풀 리퀘스트에 `/lgtm` 코멘트를 달아서 찬성 의사를 표시할 수 있다.
-쿠버네티스 조직의 멤버가 아니라면,
-`/lgtm` 코멘트는 자동화 시스템에 유효하지는 않다.
+쿠버네티스 조직의 모든 맴버는 다음 작업을 할 수 있다.

-쿠버네티스 조직의 모든 멤버는 `/hold` 코멘트를 달아서 풀 리퀘스트가 머지되는 것을 막을 수 있다.
-또한 모든 멤버가 `/hold` 코멘트를 삭제해서 PR이 머지될 수 있도록 할 수도 있다.
-해당 PR이 이미 적임자로부터
-`/lgtm`과 `/approve`를 받은 경우라면 말이다.
+- [모든 사람](#모든-사람) 하위에 나열된 모든 것
+- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다.
+- 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다.
+- 코멘트에 `/assgin` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다.

-#### 멤버 되기
+### 멤버 되기

 최소 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 경우, 쿠버네티스 조직의
 [멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을
@@ -108,20 +104,29 @@ SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주
    해당 GitHub 이슈를 종료한다.
    축하한다, 이제 멤버가 되었다!

-어떤 이유에서 멤버십 요청이 즉시 수용되지 않는 경우,
+만약 맴버십 요청이 받아들여지지 않으면,
 멤버십 위원회에서 재지원 전에
 필요한 정보나 단계를 알려준다.

-### 리뷰어
+## 리뷰어

 리뷰어는
 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
-GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참고한다.
+GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을
+제공한다. 리뷰어는 다음 작업을 수행할 수 있다.

-리뷰어는 문서 풀 리퀘스트를 리뷰하고
-제안받은 변경에 대한 피드백을 제공한다.
+- [모든 사람](#모든-사람)과 [맴버](#맴버)에 나열된 모든 것을 수행
+- 새 기능의 문서화
+- 이슈 해결 및 분류
+- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공
+- 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성
+- 현지화
+- 코드에서 사용자 화면 문자열 편집
+- 코드 코멘트 개선

-자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 컨트리뷰터는 해당 풀 리퀘스트에
+### 풀 리퀘스트에 대한 리뷰어 할당
+
+자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 사용자는 해당 풀 리퀘스트에
 `/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다.
 풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로,
 리뷰어는 `/lgtm` 코멘트를
@@ -136,11 +141,7 @@ GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-wit

 리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다.

-SIG Docs 리뷰어가 되는 방법과
-수반되는 책임과 시간 할애에 대한 보다 많은 정보는
-[리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다.
-
-#### 리뷰어 되기
+### 리뷰어 되기

 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
 충족하면, SIG Docs 리뷰어가 될 수 있다.
@@ -161,26 +162,27 @@ SIG Docs 리뷰어가 되는 방법과
 GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.

-### 승인자
+## 승인자

 승인자는
 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
 GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참조한다.

-승인자는 PR을 머지할 수 있으므로, 쿠버네티스 웹사이트에 콘텐츠를 게재할 수 있다.
-PR을 승인하려면, 승인자는 `/approve` 코멘트를 해당 PR에 남긴다.
-승인자가 아닌 누군가가 승인 코멘트를 남기더라도,
-자동화 시스템은 이를 무시한다.
+승인자는 다음의 작업을 할 수 있다.
+
+- [모든 사람](#모든-사람), [맴버](#맴버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다.
+- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다.
+  만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다.
+- 쿠버네티스 릴리즈팀에 문서 담당자로 참여
+- 스타일 가이드 개선 제안
+- 문서 테스트 개선 제안
+- 쿠버네티스 웹사이트 또는 다른 도구 개선 제안

 PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는
 해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만
 `/lgtm`을 남겨야한다.

-SIG Docs 승인자가 되는 방법과
-수반되는 책임과 시간 할애에 대한 보다 많은 정보는
-[리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다.
-
-#### 승인자 되기
+### 승인자 되기

 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을
 충족하면, SIG Docs 승인자가 될 수 있다.
@@ -201,7 +203,7 @@ SIG Docs 승인자가 되는 방법과
 GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.

-#### 승인자의 책임
+### 승인자의 책임

 승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다.

@@ -209,7 +211,7 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm

    부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다.

- 제안된 변경이 컨트리뷰션 가이드 라인에 적합한지 확인한다.
+- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다.

    질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다.

@@ -219,16 +221,11 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm

 - 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다.

-#### PR Wrangler
-
-SIG Docs 승인자는
-[PR Wrangler 회람 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에
-참여하여 주 단위로 돌아가며 역할을 수행한다.
-SIG Docs는 모든 승인자들이 이 회람에 참여하기를 기대한다. 보다 자세한 내용은
-[일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
+- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할
+것으로 기대한다. [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
 문서를 참고한다.

-#### SIG Docs chairperson
+## SIG Docs chairperson

 SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
 다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
@@ -285,6 +282,24 @@ OWNERS 파일과 마크다운 파일 내 전문의 조합은
 자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를
 PR 소유자에게 조언하는데 활용된다.

+## 병합 작업 방식
+
+풀 리퀘스트 요청이 콘텐츠(현재 `master`)를 발행하는데 사용하는
+브랜치에 병합되면 그 내용이 전 세계에 공개된다. 게시된 콘텐츠의
+품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
+작동 방식은 다음과 같다.
+
+- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,
+  모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
+- 쿠버네티스 조직의 맴버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
+  자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는
+  `/lgtm` 코멘트 보류).
+- 모든 쿠버네티스 맴버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
+- SIG Docs 승인자들만이 코멘트에 `/approve` 를
+  추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
+  [PR Wrangler](#pr-wrangler) EHsms [SIG Docs 의장](#sig-docs-chairperson)과
+  같은 특정 역할도 수행한다.
+
 {{% /capture %}}

 {{% capture whatsnext %}}
@@ -296,4 +311,3 @@ PR 소유자에게 조언하는데 활용된다.

 {{% /capture %}}

-
@@ -17,12 +17,7 @@ content_template: templates/concept
 ## API 레퍼런스

 * [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
-* 쿠버네티스 API 버전
-  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
-  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
-  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
-  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
-  * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
+* [Kubernetes API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)

 ## API 클라이언트 라이브러리

@@ -37,18 +32,17 @@ content_template: templates/concept

 ## CLI 레퍼런스

-* [kubectl](/docs/user-guide/kubectl-overview) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
-    * [JSONPath](/docs/user-guide/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
-* [kubeadm](/docs/admin/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
-* [kubefed](/docs/admin/kubefed/) - 연합된(federated) 클러스터 관리를 도와주는 CLI 도구.
+* [kubectl](/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
+    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
+* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.

 ## 설정 레퍼런스

-* [kubelet](/docs/admin/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
-* [kube-apiserver](/docs/admin/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API.
-* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
-* [kube-proxy](/docs/admin/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
-* [kube-scheduler](/docs/admin/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API.
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
+* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.

 ## 설계 문서

@@ -4,14 +4,26 @@ id: device-plugin
 date: 2019-02-02
 full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
 short_description: >
-  쿠버네티스에서 동작하는 컨테이너로, 공급 업체 고유의 리소스에 대한 액세스를 제공한다.
+  파드가 공급자별 초기화 또는 설정이 필요한 장치에 접근할 수 있도록 하는 소프트웨어 확장
 aka:
 tags:
 - fundamental
 - extension
 ---
- 장치 플러그인은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다.
+ 장치 플러그인은 워커\
+ {{< glossary_tooltip term_id="node" text="노드">}}에서 실행되며,
+ 공급자별 초기화 또는 설정 단계가 필요한 로컬 하드웨어와
+ 같은 리소스에 접근할 수 있는
+ {{< glossary_tooltip term_id="pod" text="파드">}}.

 <!--more-->

-[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로도 디플로이 가능하다.
+장치 플러그인은 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}에
+리소스를 알리기에 워크로드 파드는 해당 파드가 실행중인
+노드와 관련된 하드웨어 기능에 접근할 수 있다.
+장치 플러그인을 {{< glossary_tooltip term_id="daemonset" >}}으로 배포하거나,
+각 대상 노드에 직접 장치 플러그인 소프트웨어를 설치할 수 있다.
+
+[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+의 더 자세한 정보를
+본다
@@ -140,7 +140,7 @@ EOF
 # 기본 출력을 위한 Get 커맨드
 kubectl get services                          # 네임스페이스 내 모든 서비스의 목록 조회
 kubectl get pods --all-namespaces             # 모든 네임스페이스 내 모든 파드의 목록 조회
-kubectl get pods -o wide                      # 네임스페이스 내 모든 파드의 상세 목록 조회
+kubectl get pods -o wide                      # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회
 kubectl get deployment my-dep                 # 특정 디플로이먼트의 목록 조회
 kubectl get pods                              # 네임스페이스 내 모든 파드의 목록 조회
 kubectl get pod my-pod -o yaml                # 파드의 YAML 조회
@@ -156,9 +156,8 @@ kubectl get services --sort-by=.metadata.name
 # 재시작 횟수로 정렬된 파드의 목록 조회
 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

-# test 네임스페이스를 가지는 PersistentVolumes을 용량별로 정렬해서 조회
-
-kubectl get pv -n test --sort-by=.spec.capacity.storage
+# PersistentVolumes을 용량별로 정렬해서 조회
+kubectl get pv --sort-by=.spec.capacity.storage

 # app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회
 kubectl get pods --selector=app=cassandra -o \
@@ -69,6 +69,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 | dotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
 | DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
 | Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
+| Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
 | Haskell              | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) |
 {{% /capture %}}

@@ -37,7 +37,7 @@ card:
 |커뮤니티              |생태계     |
 | ------------       | --------     |
 | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
-| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
+| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
 |                     | [Minishift](https://docs.okd.io/latest/minishift/)|
 |                     | [MicroK8s](https://microk8s.io/)|
 |                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
@@ -199,7 +199,11 @@ minikube start --vm-driver=<driver_name>
 * hyperv ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
 다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다.
 * vmware ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver)
-* none (쿠버네티스 컴포넌트를 VM이 아닌 호스트 상에서 구동한다. 개인용 워크스테이션에서 none 드라이버를 사용하는 것을 권장하지 않는다. 이 드라이버를 사용하려면 도커와 리눅스 환경이 필요하다.([도커 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/)))
+* none (쿠버네티스 컴포넌트를 가상 머신이 아닌 호스트 상에서 구동한다. 리눅스를 실행중이어야 하고, {{< glossary_tooltip term_id="docker" >}}가 설치되어야 한다.)
+  
+{{< caution >}}
+`none` 드라이버를 사용한다면 일부 쿠버네티스 컴포넌트는 Minikube 환경 외부에 있는 부작용이 있는 권한을 가진 컨테이너로 실행된다. 이런 부작용은 개인용 워크스테이션에는 `none` 드라이버가 권장하지 않는 것을 의미 한다.
+{{< /caution >}}

 #### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기
 Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다.
@@ -15,7 +15,7 @@ weight: 10

 {{< caution >}}
 컨테이너를 실행할 때 runc가 시스템 파일 디스크립터를 처리하는 방식에서 결함이 발견되었다.
-악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며 
+악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며
 따라서 컨테이너 호스트 시스템에서 임의의 명령을 실행할 수 있다.

 이 문제에 대한 자세한 내용은
@@ -34,18 +34,18 @@ weight: 10

 ### Cgroup 드라이버

-Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는 
-root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. 
-Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. 
-컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. 
+Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는
+root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다.
+Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다.
+컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다.
 systemd와 함께`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다.

-Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다. 
-단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고, 
-기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다. 
-관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는 
-`cgroupfs`를 사용하고 나머지 프로세스는 
-`systemd`를 사용하도록 노드가 설정된 경우, 
+Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다.
+단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고,
+기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다.
+관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는
+`cgroupfs`를 사용하고 나머지 프로세스는
+`systemd`를 사용하도록 노드가 설정된 경우,
 리소스가 부족할 때 불안정해지는 사례를 본 적이 있다.

 컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면
@@ -53,7 +53,7 @@ Control group은 프로세스에 할당된 리소스를 제한하는데 사용

 {{< caution >}}
 클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 권장하지 않는다.
-하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면, 
+하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면,
 컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 PodSandBox를 재생성을 시도할 때, 에러가 발생할 수 있다.
 kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
 추천하는 방법은 워크로드에서 노드를 제거하고, 클러스터에서 제거한 다음 다시 결합시키는 것이다.
@@ -62,7 +62,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
 ## Docker

 각 머신들에 대해서, Docker를 설치한다.
-버전 19.03.4가 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. 
+버전 19.03.4가 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다.
 쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 Docker 버전의 지속적인 파악이 필요하다.

 시스템에 Docker를 설치하기 위해서 아래의 커맨드들을 사용한다.
@@ -72,8 +72,8 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
 # Docker CE 설치
 ## 리포지터리 설정
 ### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치
-apt-get update && apt-get install \
-  apt-transport-https ca-certificates curl software-properties-common
+apt-get update && apt-get install -y \
+  apt-transport-https ca-certificates curl software-properties-common gnupg2

 ### Docker의 공식 GPG 키 추가
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
@@ -160,6 +160,11 @@ systemctl restart docker

 시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다.

+{{< note >}}
+CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 버전이 일치해야 한다.
+더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o)를 본다.
+{{< /note >}}
+
 ### 선행 조건

 ```shell
@@ -213,7 +218,7 @@ systemctl start crio

 ## Containerd

-이 섹션은 `containerd`를 CRI 런타임으로써 사용하는데 필요한 단계를 담고 있다. 
+이 섹션은 `containerd`를 CRI 런타임으로써 사용하는데 필요한 단계를 담고 있다.

 Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사용한다.

@@ -299,4 +304,4 @@ kubeadm을 사용하는 경우에도 마찬가지로, 수동으로

 자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다.

-{{% /capture %}}
+{{% /capture %}}
@@ -352,7 +352,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
    - 노드, 파드, 서비스에 접근하는 데 사용될 수 있다
    - 서비스에 접근하는 데 사용되면 load balacing한다

-1.  [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+1.  [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips):

    - 각 노드 상에서 실행된다
    - UDP와 TCP를 proxy한다
@@ -79,7 +79,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509

  클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.

- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
+- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.

  클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다.

@@ -8,7 +8,7 @@ title: 리소스 모니터링 도구
 애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면, 
 애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다. 
 컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod), 
-[서비스](/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 
+[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 
 검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서 
 애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다.
 이 정보는 애플리케이션의 성능을 평가하고 
@@ -81,7 +81,14 @@ kubectl apply -f <디렉터리>/
 kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
 ```
 {{< note >}}
-`diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다.
+`diff`는 `kube-apiserver`의 활성화가 필요한
+[서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다.
+
+`diff` 는 dry-run 모드에서 서버 측 적용 요청을 수행하므로,
+`PATCH`, `CREATE`, 그리고 `UPDATE` 권한을 부여해야 한다.
+자세한 것은
+[Dry-Run 인증](/docs/reference/using-api/api-concepts#dry-run-authorization)을 본다.
+
 {{< /note >}}

 `kubectl apply`를 사용하여 오브젝트를 생성한다.
@@ -57,14 +57,19 @@ index.php는 CPU 과부하 연산을 수행한다.
 ?>
 ```

-첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다.
+첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를
+시작하고 서비스로 노출시킨다.

+{{< codenew file="application/php-apache.yaml" >}}
+
+
+다음의 명령어를 실행한다.
 ```shell
-kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80
+kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
 ```
 ```
-service/php-apache created
 deployment.apps/php-apache created
+service/php-apache created
 ```

 ## Horizontal Pod Autoscaler 생성
@@ -154,12 +154,15 @@ HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
 큰 값이 선택된다. 이러한 메트릭 중 어떠한 것도 원하는
 레플리카 수로 변환할 수 없는 경우(예 : 메트릭 API에서 메트릭을
 가져오는 중 오류 발생) 스케일을 건너뛴다.
+이는 하나 이상의 메트릭이
+현재 값보다 높은 `desiredReplicas` 을 제공하는 경우
+HPA가 여전히 확장할 수 있음을 의미한다.

-마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는
-구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
+마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다.
+컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
 모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
-즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
-영향을 완만하게 한다.
+즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는
+메트릭 값의 영향을 완만하게 한다.

 ## API 오브젝트

@@ -206,8 +209,8 @@ Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을
 평가된 메트릭의 동적인 특징 때문에 레플리카 수가
 자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.

-v1.6부터 클러스터 운영자는 `kube-controller-manager` 구성
-요소의 플래그로 노출된 글로벌 HPA 설정을 조정하여 이 문제를 완화할 수 있다.
+v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로
+노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다.

 v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
 필요성을 제거하였다.
@@ -283,4 +286,4 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
 * kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
 * [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제.

-{{% /capture %}}
+{{% /capture %}}
@@ -74,9 +74,17 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설

 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads)

-{{< note >}}
-Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않는다. none 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 에서 도커를 apt로 설치하기를 사용하는 것을 권장한다. 도커의 스냅 설치는 minikube에서 작동하지 않는다.
-{{< /note >}}
+Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다.
+이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. 
+
+데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우,
+Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다.
+[도커](https://www.docker.com/products/docker-desktop)에서 `.deb` 패키지를 다운로드 할 수 있다.
+
+{{< caution >}}
+`none` VM 드라이버는 보안과 데이터 손실 이슈를 일으킬 수 있다.
+`--vm-driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다.
+{{< /caution >}}

 ### 패키지를 이용하여 Minikube 설치

@@ -329,7 +329,7 @@ Events:
 현재 쿠버네티스는 AppArmor 프로파일을 노드에 적재하기 위한 네이티브 메커니즘을 제공하지 않는다.
 프로파일을 설정하는 여러 방법이 있다. 예를 들면 다음과 같다.

-* 각 노드에서 파드를 실행하는 [데몬셋](/docs/concepts/workloads/controllers/daemonset/)을 통해서
+* 각 노드에서 파드를 실행하는 [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 통해서
  올바른 프로파일이 적재되었는지 확인한다. 예시 구현은
  [여기](https://git.k8s.io/kubernetes/test/images/apparmor-loader)에서 찾아볼 수 있다.
 * 노드 초기화 시간에 노드 초기화 스크립트(예를 들어 Salt, Ansible 등)나
@@ -340,7 +340,7 @@ Events:
 스케줄러는 어떤 프로파일이 어떤 노드에 적재되는지 고려하지 않으니, 프로파일 전체 집합이
 모든 노드에 적재되어야 한다. 대안적인 방법은
 각 프로파일(혹은 프로파일의 클래스)을 위한 노드 레이블을 노드에 추가하고,
-[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/)를 이용하여
+[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/)를 이용하여
 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.

 ### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
@@ -10,12 +10,12 @@ menu:
      <p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
 card:
  name: tutorials
-  weight: 10 
+  weight: 10
 ---

 {{% capture overview %}}

-이 튜토리얼에서는 [Minikube](/ko/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 
+이 튜토리얼에서는 [Minikube](/ko/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여
 쿠버네티스에서 Node.js 로 작성된 간단한 Hello World 애플리케이션을 어떻게 실행하는지 살펴본다.
 Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.

@@ -69,7 +69,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.

 쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/pod/)는 관리와
 네트워킹 목적으로 함께 묶여 있는 하나 이상의 컨테이너 그룹이다.
-이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스 
+이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스
 [*디플로이먼트*](/ko/docs/concepts/workloads/controllers/deployment/)는 파드의
 헬스를 검사해서 파드의 컨테이너가 종료되었다면 재시작해준다.
 파드의 생성 및 스케일링을 관리하는 방법으로 디플로이먼트를 권장한다.
@@ -117,7 +117,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
    ```shell
    kubectl config view
    ```
-  
+
    {{< note >}}`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개관](/docs/user-guide/kubectl-overview/)을 살펴보자.{{< /note >}}

 ## 서비스 만들기
@@ -125,14 +125,14 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
 기본적으로 파드는 쿠버네티스 클러스터 내부의 IP 주소로만
 접근할 수 있다. `hello-node` 컨테이너를 쿠버네티스 가상 네트워크
 외부에서 접근하려면 파드를 쿠버네티스
-[*서비스*](/docs/concepts/services-networking/service/)로 노출해야 한다.
+[*서비스*](/ko/docs/concepts/services-networking/service/)로 노출해야 한다.

 1. `kubectl expose` 명령어로 퍼블릭 인터넷에 파드 노출하기

    ```shell
    kubectl expose deployment hello-node --type=LoadBalancer --port=8080
    ```
-    
+
    `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기
    원한다는 뜻이다.

@@ -199,13 +199,13 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
    storage-provisioner: enabled
    storage-provisioner-gluster: disabled
    ```
-   
-2. 한 애드온을 활성화 한다. 예를 들어 `heapster`
+
+2. 한 애드온을 활성화 한다. 예를 들어 `metrics-server`

    ```shell
    minikube addons enable heapster
    ```
-  
+
    다음과 유사하게 출력된다.

    ```
@@ -246,7 +246,7 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
    ```shell
    minikube addons disable heapster
    ```
-  
+
    다음과 유사하게 출력된다.

    ```
@@ -279,7 +279,7 @@ minikube delete
 {{% capture whatsnext %}}

 * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
-* [애플리케이션 배포](/docs/user-guide/deploying-applications/)에 대해서 더 배워 본다.
-* [서비스 오브젝트](/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.
+* [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
+* [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.

-{{% /capture %}}
+{{% /capture %}}
@@ -23,8 +23,8 @@ content_template: templates/tutorial
 * [NAT](https://en.wikipedia.org/wiki/Network_address_translation): 네트워크 주소 변환
 * [소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소
 * [대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소
-* [VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은
-* [Kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다.
+* [VIP](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은
+* [Kube-proxy](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다.


 ## 전제 조건
@@ -34,7 +34,7 @@ content_template: templates/tutorial
 작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다.

 ```console
-kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
+kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4
 ```
 출력은 다음과 같다.
 ```
@@ -57,7 +57,7 @@ deployment.apps/source-ip-app created
 ## Type=ClusterIP인 서비스에서 소스 IP

 쿠버네티스 1.2부터 기본으로 제공하는
-[iptables 모드](/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우
+[iptables 모드](/ko/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우
 클러스터 내에서 클러스터 IP로 패킷을 보내면 소스 NAT를 통과하지 않는다.
 Kube-proxy는 이 모드를 `proxyMode` 엔드포인트를 통해 노출한다.

@@ -122,7 +122,7 @@ client_address는 클라이언트 파드와 서버 파드가 같은 노드 또

 ## Type=NodePort인 서비스에서 소스 IP

-쿠버네티스 1.5부터 [Type=NodePort](/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은
+쿠버네티스 1.5부터 [Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은
 소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다.

 ```console
@@ -221,7 +221,7 @@ client_address=104.132.1.79

 ## Type=LoadBalancer인 서비스에서 소스 IP

-쿠버네티스 1.5 부터 [Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)인 서비스로
+쿠버네티스 1.5 부터 [Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer)인 서비스로
 보낸 패킷은 소스 NAT를 기본으로 하는데, `Ready` 상태로 모든 스케줄된 모든 쿠버네티스 노드는
 로드 밸런싱 트래픽에 적합하다. 따라서 엔드포인트가 없는 노드에
 패킷이 도착하면 시스템은 엔드포인트를 *포함한* 노드에 프록시를
@@ -17,7 +17,7 @@ weight: 10

 * [파드](/docs/user-guide/pods/single-container/)
 * [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/)
-* [헤드리스 서비스(Headless Services)](/docs/concepts/services-networking/service/#headless-services)
+* [헤드리스 서비스(Headless Services)](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
 * [퍼시스턴트볼륨(PersistentVolumes)](/docs/concepts/storage/persistent-volumes/)
 * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
 * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
@@ -51,7 +51,7 @@ weight: 10
 아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는
 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인
 예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는
-[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인
+[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)인
 `nginx` 를 생성한다.

 {{< codenew file="application/web/web.yaml" >}}
@@ -29,7 +29,7 @@ weight: 30
 {{% /capture %}}

 {{% capture objectives %}}
-* 카산드라 헤드리스 [*서비스*](/docs/concepts/services-networking/service/)를 생성하고 검증한다.
+* 카산드라 헤드리스 [*서비스*](/ko/docs/concepts/services-networking/service/)를 생성하고 검증한다.
 * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다.
 * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 검증한다.
 * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 수정한다.
@@ -37,7 +37,7 @@ weight: 30
 {{% /capture %}}

 {{% capture prerequisites %}}
-이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로
+이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/ko/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로

 * *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자.

@@ -65,7 +65,7 @@ minikube start --memory 5120 --cpus=4
 {{% capture lessoncontent %}}
 ## 카산드라 헤드리스 서비스 생성하기

-쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다.
+쿠버네티스 [서비스](/ko/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다.

 다음의 `서비스`는 쿠버네티스 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다.

@@ -233,7 +233,7 @@ kubectl apply -k ./

 * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자.
 * [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자.
-* [포트 포워딩](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자.
+* [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자.
 * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.

 {{% /capture %}}
@@ -6,9 +6,9 @@ weight: 40

 {{% capture overview %}}
 이 튜토리얼은 [아파치 ZooKeeper](https://zookeeper.apache.org)
-쿠버네티스에서 [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)과
-[파드디스룹선버짓(PodDisruptionBudget)](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과
-[파드안티어피니티(PodAntiAffinity)](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다.
+쿠버네티스에서 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과
+[파드디스룹선버짓(PodDisruptionBudget)](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과
+[파드안티어피니티(PodAntiAffinity)](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다.
 {{% /capture %}}

 {{% capture prerequisites %}}
@@ -18,12 +18,12 @@ weight: 40

 -   [파드](/docs/user-guide/pods/single-container/)
 -   [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
-   [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)
+-   [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
 -   [퍼시스턴트볼륨](/docs/concepts/storage/volumes/)
 -   [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
 -   [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
 -   [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)
-   [파드안티어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)
+-   [파드안티어피니티](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)
 -   [kubectl CLI](/docs/user-guide/kubectl/)

 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.
@@ -62,8 +62,8 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변
 ## ZooKeeper 앙상블 생성하기

 아래 메니페스트에는
-[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services),
-[서비스](/docs/concepts/services-networking/service/),
+[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스),
+[서비스](/ko/docs/concepts/services-networking/service/),
 [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget),
 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다.

@@ -80,8 +80,17 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
        NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
        my-service   LoadBalancer   10.3.245.137   104.198.205.71   8080/TCP   54s

-    참고: 만약 외부 IP 주소가 \<pending\>으로 표시되면 잠시 기다린 다음,
-    동일한 명령어를 다시 입력한다.
+    {{< note >}}
+
+    `type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer를 참조한다.
+
+    {{< /note >}}
+
+    {{< note >}}
+
+    만약 외부 IP 주소가 \<pending\>으로 표시되면 잠시 기다린 다음, 동일한 명령어를 다시 입력한다.
+
+    {{< /note >}}

 1. 서비스에 대한 자세한 정보를 확인한다.

@@ -77,7 +77,7 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다.

 ### Redis 마스터 서비스 생성하기

-방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다.
+방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다.

 {{< codenew file="application/guestbook/redis-master-service.yaml" >}}

@@ -197,7 +197,7 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추

 ### 프론트엔드 서비스 생성하기

-서비스의 기본 유형은 [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다.
+서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다.

 게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 통해서만 서비스를 노출할 수 있다.

@@ -0,0 +1,39 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: php-apache
+spec:
+  selector:
+    matchLabels:
+      run: php-apache
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        run: php-apache
+    spec:
+      containers:
+      - name: php-apache
+        image: k8s.gcr.io/hpa-example
+        ports:
+        - containerPort: 80
+        resources:
+          limits:
+            cpu: 500m
+          requests:
+            cpu: 200m
+
+---
+
+apiVersion: v1
+kind: Service
+metadata:
+  name: php-apache
+  labels:
+    run: php-apache
+spec:
+  ports:
+  - port: 80
+  selector:
+    run: php-apache
+
@@ -0,0 +1,11 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-egress
+spec:
+  podSelector: {}
+  egress:
+  - {}
+  policyTypes:
+  - Egress
@@ -0,0 +1,11 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-ingress
+spec:
+  podSelector: {}
+  ingress:
+  - {}
+  policyTypes:
+  - Ingress
@@ -0,0 +1,10 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-all
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress
+  - Egress
@@ -0,0 +1,9 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-egress
+spec:
+  podSelector: {}
+  policyTypes:
+  - Egress
@@ -0,0 +1,9 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-ingress
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress
@@ -58,7 +58,7 @@ Kubernetes предоставляет вам:

 * **Мониторинг сервисов и распределение нагрузки**
 Kubernetes может обнаружить контейнер, используя имя DNS или собственный IP-адрес. Если трафик в контейнере высокий, Kubernetes может сбалансировать нагрузку и распределить сетевой трафик, чтобы развертывание было стабильным.
-* **Орекстрация хранилища**
+* **Оркестрация хранилища**
 Kubernetes позволяет вам автоматически смонтировать систему хранения по вашему выбору, такую как локальное хранилище, провайдеры общедоступного облака и многое другое.
 * **Автоматическое развертывание и откаты**
 Используя Kubernetes можно описать желаемое состояние развернутых контейнеров и изменить фактическое состояние на желаемое. Например, вы можете автоматизировать Kubernetes на создание новых контейнеров для развертывания, удаления существующих контейнеров и распределения всех их ресурсов в новый контейнер.
@@ -0,0 +1,196 @@
+---
+title: Участие для опытных
+slug: advanced
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+На этой странице предполагается, что вы изучили темы [Участие для начинающих](/ru/docs/contribute/start/) и [Участие для опытных](/ru/docs/contribute/intermediate/) и теперь хотите узнать ещё больше про то, как можно помочь проекту. Для решения некоторых задач вам потребуется использовать Git из командной строки и прочие другие инструменты.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Дежурный по PR на неделю
+
+[Утверждающие](/ru/docs/contribute/participating/#утверждающие) группы SIG Docs регулярно по очереди становятся дежурными по PR в репозитории и поэтому участвуют в [графике ротации PR-дежурного](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) на неделю.
+
+В обязанности дежурного по PR входят:
+
+- Ежедневно проверять [открытые пулреквесты](https://github.com/kubernetes/website/pulls) для контроля качества и соблюдения рекомендаций по [оформлению](/docs/contribute/style/style-guide/) и [содержимому](/docs/contribute/style/content-guide/).
+    - В первую очередь просматривайте самые маленькие пулреквесты (`size/XS`), и только потом беритесь за самые большие (`size/XXL`).
+    - Проверяйте столько пулреквестов, сколько сможете.
+- Проследить, что CLA подписан каждым участником.
+    - Помогайте новым участникам подписать [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
+    - Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, чтобы они подписали CLA.
+- Оставить свое мнение о предложенных изменениях и поспособствовать в проведении технического обзора от членов других SIG-групп.
+    - Предложить исправления для измененного контента в PR.
+    - Если вы хотите убедиться в правильности контента, прокомментируйте PR и задайте уточняющие вопросы.
+    - Добавьте нужны метки с `sig/`.
+    - Если нужно, то назначьте рецензентов из секции `reviewers:` в фронтальной части файла.
+    - Добавьте метки `Docs Review` и `Tech Review` для установки статуса проверки PR.
+    - Добавьте метку `Needs Doc Review` или `Needs Tech Review` для пулреквестов, которые ещё не были проверены.
+    - Добавьте метку `Doc Review: Open Issues` или `Tech Review: Open Issues` для пулреквестов, которые были проверены и требуют дополнительную информацию и выполнение действия перед слиянием.
+    - Добавьте метки `/lgtm` и `/approve` для пулреквестов, которые могут быть приняты.
+- Объедините пулреквесты, если они готовы, либо закройте те, которые не могут быть приняты.
+- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использование метаданных SIG Docs.
+
+### Полезные ссылки на GitHub для дежурных
+
+Следующие ссылки помогут при дежурстве. После обработки заявок по трём первым ссылкам, как правило, список пулреквестов для проверки сократится. По указанным ссылкам вы найдете PR только в английскую версию, предназначенные для слияния в ветку `master` (кроме последней ссылки).
+
+- [Нет CLA, нет права на слияние](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): напомните участнику подписать CLA. Если об этом уже напомнил и бот, и человек, то закройте PR и напишите автору, что он может открыть свой PR после подписания CLA.
+**Не проверяйте PR, если их авторы не подписали CLA!**
+- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужен проверка с технической точки зрения, попросите её провести одного из рецензентов, который предложил бот. Если требуется просмотр пулреквест со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста.
+- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слияния, оставьте комментарий с текстом `/approve`.
+- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения. (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]).
+- [Вне основной ветки](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): если PR отправлен в ветку `dev-`, значит он предназначается для будущего выпуска. Убедитесь, что [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) знает об этом, добавив комментарий с `/assign @<meister's_github-username>`. Если он направлен в старую ветку, помогите автору PR изменить на более подходящую ветку.
+
+### Когда закрывать пулреквесты
+
+Обзоры и одобрения — это только один из способов, позволяющих держать список PR коротким и актуальным. Закрытие пулреквестов — альтернативный метод для этого.
+
+- Можете закрыть любой PR, если CLA-соглашение не было подписано в течение двух недель.
+Авторы PR могут повторно открыть PR после подписания CLA, так что это безопасный способ убедиться, что ничто не будет объединено без подписанного CLA.
+
+- Закройте любой PR, если автор не отреагировал на комментарии или проверки в течение 2 или более недель.
+
+Не бойтесь закрывать пулреквесты. Участники с лёгкостью открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулировать автора возобновить и закончить свой вклад.
+
+Чтобы закрыть пулреквест, оставьте комментарий `/close` в PR.
+
+{{< note >}}
+
+Бот [`fejta-bot`](https://github.com/fejta-bot) автоматически помечает заявки как устаревшие после 90 дней отсутствия активности, а затем закрывает их после ещё 30 дней простоя, когда они становятся тухлыми. Дежурные по PR должны закрывать заявки после 14-30 дней бездействия.
+
+{{< /note >}}
+
+## Внесение улучшений
+
+[Члены](/ru/docs/contribute/participating/#члены) SIG Docs могут предлагать улучшения.
+
+После того, как вы давно начали работать над документацией Kubernetes, у наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по оформлению](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их на канале `#sig-docs` Slack на [kubernetes.slack.com](https://kubernetes.slack.com).
+
+Когда обсуждение состоялось, а SIG-группа согласилась с желаемым результатом, вы можете работать над предлагаемыми изменениями наиболее приемлемым способом. Например, обновление руководства по оформлению или функциональности сайта может включать открытие пулреквеста, а изменение, связанное с тестированием документации, может предполагать взаимодействие с sig-testing.
+
+## Координация документации по выпуску Kubernetes
+
+[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут координировать документацию для выпуска Kubernetes.
+
+Каждый выпуск Kubernetes координируется командой людей, участвующих в специальной группе (Special Interest Group, SIG) sig-release. Другие члены команды в данном выпуске включают в себя общего руководителя выпуском, а также представителей sig-pm, sig-testing и др. Чтобы узнать больше о процессах выпуска версий Kubernetes, обратитесь к [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release).
+
+Представитель SIG Docs для данного выпуска координирует следующие задачи:
+
+- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивают документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск.
+- Регулярное посещение встречи sig-release и обновлять информацию о статусе документации в выпуске.
+- Проверка и вычитка документации по функциональности, подготовленной SIG-группой, ответственной за реализацию этой функциональности.
+- Объединение связанных с выпуском пулреквестов и поддержка Git-ветки выпуска.
+- Консультируйте других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing).
+- Публикация изменений в документации, связанные с выпуском при размещении артефактов.
+
+Координация выпуска обычно занимает 3-4 месяца, а обязанности распределяются между утверждающими SIG Docs.
+
+## Амбассадор нового участника
+
+[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут выступать в качестве амбассадоров новых участников.
+
+Амбассадоры новых участников работают бок о бок, чтобы поприветствовать новых участников SIG Docs, предлагать PR новым участникам и консультировать новых участников в их собственных PR.
+
+Обязанности амбассадоров новых участников включают в себя:
+
+- Отвечать на вопросы новых участников на [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com).
+- Совместно работать с дежурным по PR, чтобы определять заявки, которые подойдут для решения новыми участниками.
+- Консультировать новых участников в их PR.
+- Помогать новых участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes.
+- [Оказывать содействие участникам](/ru/docs/contribute/advanced/#поддержка-нового-участника) на их пути становления членом в Kubernetes.
+
+Текущие амбассадоры новых участников объявляются на каждом собрании SIG Docs и на канале [#sig-docs в Kubernetes](https://kubernetes.slack.com).
+
+## Поддержка нового участника
+
+[Рецензенты](/ru/docs/contribute/participating/#рецензенты) SIG Docs могут содействовать новым участникам в членстве организации.
+
+Если участник сделал 5 значительных пулреквестов в один или несколько репозиториев Kubernetes, он имеет право на [членство](/ru/docs/contribute/participating#члены) в организации Kubernetes. Членство участника должно быть поддержано двумя спонсорами, которые уже являются рецензентами.
+
+Новые участники документации могут найти спонсоров в канале #sig-docs в [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes.
+
+## Сопредседатель SIG
+
+[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут быть сопредседателями SIG Docs.
+
+### Требования
+
+Сопредседатели должны соответствовать следующим требованиям:
+
+- Быть утверждающим SIG Docs не меньше 6 месяцев
+- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопровождать два выпуска
+- Понимание рабочих процессов и инструментов SIG Docs: git, Hugo, локализация, блог
+- Понимать, как другие SIG-группы и репозитории Kubernetes влияют на рабочий процесс SIG Docs, включая: [команды в k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [процессы в k/community](https://github.com/kubernetes/community/tree/master/sig-docs), плагины в [k/test-infra](https://github.com/kubernetes/test-infra/) и роль [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
+- Уделять не менее 5 часов в неделю (но зачастую больше) в течение как минимум 6 месяцев для выполнения обязанностей.
+
+### Обязанности
+
+Роль сопредседателя посвящена в основном одной из задач: сопредседатели управляют процессом и политикой, планируют и проводят собрания, назначают дежурных по PR и, как правило, делают то, что никто больше не хочет делать, для увеличения количества участников.
+
+Обязанности включают в себя:
+
+- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию
+- Быть примером соблюдения [норм поведения сообщества]https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG
+- Изучение и внедрение передовых практик для SIG-группы, обновляя рекомендации по участию
+- Планирование и проведение встреч SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое
+- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях
+- Набирать персонал и выступать в поддержку {{< glossary_tooltip text="CNCF" term_id="cncf" >}} и его платиновых партнеров, включая Google, Oracle, Azure, IBM и Huawei.
+- Поддерживать нормальную работу SIG
+
+### Проведение продуктивных встреч
+
+Для планирования и проведения результативных встреч мы составили рекомендации, которые показывают и объясняют, как лучше всего их подготовить.
+
+**Соблюдайте [нормы поведения сообщества](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**:
+
+- Привлекайте самый широкий круг участников к дискуссии и уважительно общайтесь между собой, стараясь никого не обидеть.
+
+**Сформулируйте четкую повестку дня**:
+
+- Определите конкретную цель встречи
+- Опубликуйте программу дня заранее
+
+Для еженедельных встреч скопируйте примечания из предыдущей недели в раздел "Past meetings".
+
+**Работайте вместе для создания точных примечания**:
+
+- Запишите обсуждение встречи
+- Подумайте над тем, чтобы делегировать роль стенографист кому-нибудь другому
+
+**Определяйте решения по пунктам повестки четко и точно**:
+
+- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения
+
+**Руководите обсуждением, когда это необходимо**:
+
+- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему
+- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей
+
+**Уважайте время людей**:
+
+- Начинайте и заканчивайте встречи своевременно
+
+**Используйте Zoom эффективно**:
+
+- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md)
+- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего
+
+<img src="/images/docs/contribute/claim-host.png" width="75%" alt="Исполнение роли ведущего в Zoom" />
+
+### Запись встреч на Zoom
+
+Когда вам потребуется начать запись, нажмите пункт с надписью Record to Cloud.
+
+Если нужно остановить запись, нажмите на кнопку Stop.
+
+Запись автоматически загрузится на YouTube.
+
+{{% /capture %}}
--- a/Show More
+++ b/Show More