diff --git a/config.toml b/config.toml index 1daf9e4274..cf3c2106d8 100644 --- a/config.toml +++ b/config.toml @@ -78,6 +78,11 @@ nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/" githubWebsiteRepo = "github.com/kubernetes/website" githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website" +# param for displaying an announcement block on every page; see PR #16210 +announcement = false +# announcement_message is only displayed when announcement = true; update with your specific message +announcement_message = "The Kubernetes Documentation team would like your feedback! Please take a short survey so we can improve the Kubernetes online documentation." + [[params.versions]] fullversion = "v1.16.0" version = "v1.16" diff --git a/content/en/_index.html b/content/en/_index.html index 7813606b80..39e9796be0 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -3,6 +3,7 @@ title: "Production-Grade Container Orchestration" abstract: "Automated container deployment, scaling, and management" cid: home --- +{{< announcement >}} {{< deprecationwarning >}} diff --git a/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md index ab02152b6b..d1a2c45cb3 100644 --- a/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md @@ -418,7 +418,7 @@ zk-budget 2 1 2h -zk-budget indicates that at least two members of the ensemble must be available at all times for the ensemble to be healthy. If you attempt to drain a node prior taking it offline, and if draining it would terminate a Pod that violates the budget, the drain operation will fail. If you use [kubectl drain](/docs/user-guide/kubectl/kubectl_drain/), in conjunction with PodDisruptionBudgets, to cordon your nodes and to evict all Pods prior to maintenance or decommissioning, you can ensure that the procedure won’t be disruptive to your stateful applications. +zk-budget indicates that at least two members of the ensemble must be available at all times for the ensemble to be healthy. If you attempt to drain a node prior taking it offline, and if draining it would terminate a Pod that violates the budget, the drain operation will fail. If you use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain), in conjunction with PodDisruptionBudgets, to cordon your nodes and to evict all Pods prior to maintenance or decommissioning, you can ensure that the procedure won’t be disruptive to your stateful applications. diff --git a/content/en/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md b/content/en/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md index cc09e27b7b..c17d76d67b 100644 --- a/content/en/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md +++ b/content/en/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md @@ -87,5 +87,5 @@ With today’s [announcement from CNCF](https://www.cncf.io/announcement/2018/08 Want to find out more? Come check out these resources: -* [Prow: Testing the way to Kubernetes Next](https://bentheelder.io/posts/prow) +* [Prow: Testing the way to Kubernetes Next](https://elder.dev/posts/prow) * [Automation and the Kubernetes Contributor Experience](https://www.youtube.com/watch?v=BsIC7gPkH5M) diff --git a/content/en/blog/_posts/2019-08-30-announcing-etcd-3.4.md b/content/en/blog/_posts/2019-08-30-announcing-etcd-3.4.md new file mode 100644 index 0000000000..07004b78d1 --- /dev/null +++ b/content/en/blog/_posts/2019-08-30-announcing-etcd-3.4.md @@ -0,0 +1,65 @@ + +--- +layout: blog +title: "Announcing etcd 3.4" +date: 2019-08-30 +slug: announcing-etcd-3-4 +--- + +**Authors:** Gyuho Lee (Amazon Web Services, @[gyuho](https://github.com/gyuho)), Jingyi Hu (Google, @[jingyih](https://github.com/jingyih)) + +etcd 3.4 focuses on stability, performance and ease of operation, with features like pre-vote and non-voting member and improvements to storage backend and client balancer. + +Please see [CHANGELOG](https://github.com/etcd-io/etcd/blob/master/CHANGELOG-3.4.md) for full lists of changes. + +## Better Storage Backend + +etcd v3.4 includes a number of performance improvements for large scale Kubernetes workloads. + +In particular, etcd experienced performance issues with a large number of concurrent read transactions even when there is no write (e.g. `“read-only range request ... took too long to execute”`). Previously, the storage backend commit operation on pending writes blocks incoming read transactions, even when there was no pending write. Now, the commit [does not block reads](https://github.com/etcd-io/etcd/pull/9296) which improve long-running read transaction performance. + +We further made [backend read transactions fully concurrent](https://github.com/etcd-io/etcd/pull/10523). Previously, ongoing long-running read transactions block writes and upcoming reads. With this change, write throughput is increased by 70% and P99 write latency is reduced by 90% in the presence of long-running reads. We also ran [Kubernetes 5000-node scalability test on GCE](https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/ci-kubernetes-e2e-gce-scale-performance/1130745634945503235) with this change and observed similar improvements. For example, in the very beginning of the test where there are a lot of long-running “LIST pods”, the P99 latency of “POST clusterrolebindings” is [reduced by 97.4%](https://github.com/etcd-io/etcd/pull/10523#issuecomment-499262001). This non-blocking read transaction is now [used for compaction](https://github.com/etcd-io/etcd/pull/11034), which, combined with the reduced compaction batch size, reduces the P99 server request latency during compaction. + +More improvements have been made to lease storage. We enhanced [lease expire/revoke performance](https://github.com/etcd-io/etcd/pull/9418) by storing lease objects more efficiently, and made [lease look-up operation non-blocking](https://github.com/etcd-io/etcd/pull/9229) with current lease grant/revoke operation. And etcd v3.4 introduces [lease checkpoint](https://github.com/etcd-io/etcd/pull/9924) as an experimental feature to persist remaining time-to-live values through consensus. This ensures short-lived lease objects are not auto-renewed after leadership election. This also prevents lease object pile-up when the time-to-live value is relatively large (e.g. [1-hour TTL never expired in Kubernetes use case](https://github.com/kubernetes/kubernetes/issues/65497)). + +## Improved Raft Voting Process + +etcd server implements [Raft consensus algorithm](https://raft.github.io) for data replication. Raft is a leader-based protocol. Data is replicated from leader to follower; a follower forwards proposals to a leader, and the leader decides what to commit or not. Leader persists and replicates an entry, once it has been agreed by the quorum of cluster. The cluster members elect a single leader, and all other members become followers. The elected leader periodically sends heartbeats to its followers to maintain its leadership, and expects responses from each follower to keep track of its progress. + +In its simplest form, a Raft leader steps down to a follower when it receives a message with higher terms without any further cluster-wide health checks. This behavior can affect the overall cluster availability. + +For instance, a flaky (or rejoining) member drops in and out, and starts campaign. This member ends up with higher terms, ignores all incoming messages with lower terms, and sends out messages with higher terms. When the leader receives this message of a higher term, it reverts back to follower. + +This becomes more disruptive when there’s a network partition. Whenever the partitioned node regains its connectivity, it can possibly trigger the leader re-election. To address this issue, etcd Raft introduces a new node state pre-candidate with the [pre-vote feature](https://github.com/etcd-io/etcd/pull/9352). The pre-candidate first asks other servers whether it's up-to-date enough to get votes. Only if it can get votes from the majority, it increments its term and starts an election. This extra phase improves the robustness of leader election in general. And helps the leader remain stable as long as it maintains its connectivity with the quorum of its peers. + +Similarly, etcd availability can be affected when a restarting node has not received the leader heartbeats in time (e.g. due to slow network), which triggers the leader election. Previously, etcd fast-forwards election ticks on server start, with only one tick left for leader election. For example, when the election timeout is 1-second, the follower only waits 100ms for leader contacts before starting an election. This speeds up initial server start, by not having to wait for the election timeouts (e.g. election is triggered in 100ms instead of 1-second). Advancing election ticks is also useful for cross datacenter deployments with larger election timeouts. However, in many cases, the availability is more critical than the speed of initial leader election. To ensure better availability with rejoining nodes, etcd now [adjusts election ticks](https://github.com/etcd-io/etcd/pull/9415) with more than one tick left, thus more time for the leader to prevent a disruptive restart. + +## Raft Non-Voting Member, Learner + +The challenge with membership reconfiguration is that it often leads to quorum size changes, which are prone to cluster unavailabilities. Even if it does not alter the quorum, clusters with membership change are more likely to experience other underlying problems. To improve the reliability and confidence of reconfiguration, a new role - learner is introduced in etcd 3.4 release. + +A new etcd member joins the cluster with no initial data, requesting all historical updates from the leader until it catches up to the leader’s logs. This means the leader’s network is more likely to be overloaded, blocking or dropping leader heartbeats to followers. In such cases, a follower may experience election-timeout and start a new leader election. That is, a cluster with a new member is more vulnerable to leader election. Both leader election and the subsequent update propagation to the new member are prone to causing periods of cluster unavailability (see *Figure 1*). + +![learner-figure-1](/images/blog/2019-08-30-announcing-etcd-3.4/figure-1.png) + +The worst case is a misconfigured membership add. Membership reconfiguration in etcd is a two-step process: `etcdctl member add` with peer URLs, and starting a new etcd to join the cluster. That is, `member add` command is applied whether the peer URL value is invalid or not. If the first step is to apply the invalid URLs and change the quorum size, it is possible that the cluster already loses the quorum until the new node connects. Since the node with invalid URLs will never become online and there’s no leader, it is impossible to revert the membership change (see *Figure 2*). + +![learner-figure-2](/images/blog/2019-08-30-announcing-etcd-3.4/figure-2.png) + +This becomes more complicated when there are partitioned nodes (see the [design document](https://github.com/etcd-io/etcd/blob/master/Documentation/learning/design-learner.md) for more). + +In order to address such failure modes, etcd introduces a [new node state “Learner”](https://github.com/etcd-io/etcd/issues/10537), which joins the cluster as a non-voting member until it catches up to leader’s logs. This means the learner still receives all updates from leader, while it does not count towards the quorum, which is used by the leader to evaluate peer activeness. The learner only serves as a standby node until promoted. This relaxed requirements for quorum provides the better availability during membership reconfiguration and operational safety (see *Figure 3*). + +![learner-figure-3](/images/blog/2019-08-30-announcing-etcd-3.4/figure-3.png) + +We will further improve learner robustness, and explore auto-promote mechanisms for easier and more reliable operation. Please read our [learner design documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/learning/design-learner.md) and [runtime-configuration document](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#add-a-new-member-as-learner) for user guides. + +## New Client Balancer + +etcd is designed to tolerate various system and network faults. By design, even if one node goes down, the cluster “appears” to be working normally, by providing one logical cluster view of multiple servers. But, this does not guarantee the liveness of the client. Thus, etcd client has implemented a different set of intricate protocols to guarantee its correctness and high availability under faulty conditions. + +Historically, etcd client balancer heavily relied on old gRPC interface: every gRPC dependency upgrade broke client behavior. A majority of development and debugging efforts were devoted to fixing those client behavior changes. As a result, its implementation has become overly complicated with bad assumptions on server connectivity. The primary goal was to [simplify balancer failover logic in etcd v3.4 client](https://github.com/etcd-io/etcd/pull/9860); instead of maintaining a list of unhealthy endpoints, which may be stale, simply roundrobin to the next endpoint whenever client gets disconnected from the current endpoint. It does not assume endpoint status. Thus, no more complicated status tracking is needed. + +Furthermore, the new client now creates its own credential bundle to [fix balancer failover against secure endpoints](https://github.com/etcd-io/etcd/pull/10911). This resolves the [year-long bug](https://github.com/kubernetes/kubernetes/issues/72102), where kube-apiserver loses its connectivity to etcd cluster when the first etcd server becomes unavailable. + +Please see [client balancer design documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/learning/design-client.md) for more. diff --git a/content/en/docs/concepts/architecture/cloud-controller.md b/content/en/docs/concepts/architecture/cloud-controller.md index 1c62bf741c..836d4330c0 100644 --- a/content/en/docs/concepts/architecture/cloud-controller.md +++ b/content/en/docs/concepts/architecture/cloud-controller.md @@ -224,13 +224,14 @@ rules: The following cloud providers have implemented CCMs: -* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) * [AWS](https://github.com/kubernetes/cloud-provider-aws) +* [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [GCP](https://github.com/kubernetes/cloud-provider-gcp) * [Linode](https://github.com/linode/linode-cloud-controller-manager) +* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) +* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) ## Cluster Administration diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/configuration/assign-pod-node.md index 28aa9c4a27..14d01fdcc6 100644 --- a/content/en/docs/concepts/configuration/assign-pod-node.md +++ b/content/en/docs/concepts/configuration/assign-pod-node.md @@ -120,9 +120,6 @@ Node affinity is like the existing `nodeSelector` (but with the first two benefi while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as described in the third item listed above, in addition to having the first and second properties listed above. -`nodeSelector` continues to work as usual, but will eventually be deprecated, as node affinity can express -everything that `nodeSelector` can express. - ### Node affinity Node affinity is conceptually similar to `nodeSelector` -- it allows you to constrain which nodes your diff --git a/content/en/docs/concepts/configuration/manage-compute-resources-container.md b/content/en/docs/concepts/configuration/manage-compute-resources-container.md index 95de47de74..98ff861dd7 100644 --- a/content/en/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/en/docs/concepts/configuration/manage-compute-resources-container.md @@ -142,7 +142,7 @@ When using Docker: - The `spec.containers[].resources.requests.cpu` is converted to its core value, which is potentially fractional, and multiplied by 1024. The greater of this number or 2 is used as the value of the - [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) flag in the `docker run` command. - The `spec.containers[].resources.limits.cpu` is converted to its millicore value and diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index e585444ffa..f77d83a553 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -69,7 +69,7 @@ detail: to provide durable database storage, a StatefulSet to run SampleDB and a Job to handle initial configuration. * If you delete it, the Operator takes a snapshot, then makes sure that - the the StatefulSet and Volumes are also removed. + the StatefulSet and Volumes are also removed. 6. The operator also manages regular database backups. For each SampleDB resource, the operator determines when to create a Pod that can connect to the database and take backups. These Pods would rely on a ConfigMap diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md index 075235521e..016d4231f7 100644 --- a/content/en/docs/concepts/overview/what-is-kubernetes.md +++ b/content/en/docs/concepts/overview/what-is-kubernetes.md @@ -81,7 +81,7 @@ Kubernetes: * Does not dictate logging, monitoring, or alerting solutions. It provides some integrations as proof of concept, and mechanisms to collect and export metrics. * Does not provide nor mandate a configuration language/system (for example, jsonnet). It provides a declarative API that may be targeted by arbitrary forms of declarative specifications. * Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems. -* Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes is comprised of a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible. +* Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible. {{% /capture %}} diff --git a/content/en/docs/concepts/policy/limit-range.md b/content/en/docs/concepts/policy/limit-range.md index 455f51b1aa..6fb7b1dcd6 100644 --- a/content/en/docs/concepts/policy/limit-range.md +++ b/content/en/docs/concepts/policy/limit-range.md @@ -1,382 +1,382 @@ ---- -reviewers: -- nelvadas -title: Limit Ranges -content_template: templates/concept -weight: 10 ---- - -{{% capture overview %}} - -By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster. -With Resource quotas, cluster administrators can restrict the resource consumption and creation on a namespace basis. -Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all of the resources. Limit Range is a policy to constrain resource by Pod or Container in a namespace. - -{{% /capture %}} - - -{{% capture body %}} - -A limit range, defined by a `LimitRange` object, provides constraints that can: - -- Enforce minimum and maximum compute resources usage per Pod or Container in a namespace. -- Enforce minimum and maximum storage request per PersistentVolumeClaim in a namespace. -- Enforce a ratio between request and limit for a resource in a namespace. -- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime. - -## Enabling Limit Range - -Limit Range support is enabled by default for many Kubernetes distributions. It is -enabled when the apiserver `--enable-admission-plugins=` flag has `LimitRanger` admission controller as -one of its arguments. - -A limit range is enforced in a particular namespace when there is a -`LimitRange` object in that namespace. - -### Overview of Limit Range: - -- The administrator creates one `LimitRange` in one namespace. -- Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace. -- The `LimitRanger` admission controller enforces defaults limits for all Pods and Container that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum , maximum and ratio defined in any `LimitRange` present in the namespace. -- If creating or updating a resource (Pod, Container, PersistentVolumeClaim) violates a limit range constraint, the request to the API server will fail with HTTP status code `403 FORBIDDEN` and a message explaining the constraint that would have been violated. -- If limit range is activated in a namespace for compute resources like `cpu` and `memory`, users must specify - requests or limits for those values; otherwise, the system may reject pod creation. -- LimitRange validations occurs only at Pod Admission stage, not on Running pods. - - -Examples of policies that could be created using limit range are: - -- In a 2 node cluster with a capacity of 8 GiB RAM, and 16 cores, constrain Pods in a namespace to request 100m and not exceeds 500m for CPU , request 200Mi and not exceed 600Mi -- Define default CPU limits and request to 150m and Memory default request to 300Mi for containers started with no cpu and memory requests in their spec. - -In the case where the total limits of the namespace is less than the sum of the limits of the Pods/Containers, -there may be contention for resources; The Containers or Pods will not be created. - -Neither contention nor changes to limitrange will affect already created resources. - -## Limiting Container compute resources - -The following section discusses the creation of a LimitRange acting at Container Level. -A Pod with 04 containers is first created; each container within the Pod has a specific `spec.resource` configuration -each containerwithin the pod is handled differently by the LimitRanger admission controller. - - Create a namespace `limitrange-demo` using the following kubectl command - -```shell -kubectl create namespace limitrange-demo -``` - -To avoid passing the target limitrange-demo in your kubectl commands, change your context with the following command - -```shell -kubectl config set-context --current --namespace=limitrange-demo -``` - -Here is the configuration file for a LimitRange object: -{{< codenew file="admin/resource/limit-mem-cpu-container.yaml" >}} - -This object defines minimum and maximum Memory/CPU limits, default cpu/Memory requests and default limits for CPU/Memory resources to be apply to containers. - -Create the `limit-mem-cpu-per-container` LimitRange in the `limitrange-demo` namespace with the following kubectl command. -```shell -kubectl create -f https://k8s.io/examples/admin/resource/limit-mem-cpu-container.yaml -n limitrange-demo -``` - - -```shell - kubectl describe limitrange/limit-mem-cpu-per-container -n limitrange-demo - ``` - - -```shell -Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ----- -------- --- --- --------------- ------------- ----------------------- -Container cpu 100m 800m 110m 700m - -Container memory 99Mi 1Gi 111Mi 900Mi - -``` - - - -Here is the configuration file for a Pod with 04 containers to demonstrate LimitRange features : -{{< codenew file="admin/resource/limit-range-pod-1.yaml" >}} - -Create the `busybox1` Pod : - -```shell -kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-1.yaml -n limitrange-demo -``` - -### Container spec with valid CPU/Memory requests and limits -View the the `busybox-cnt01` resource configuration - -```shell -kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[0].resources" -``` - -```json -{ - "limits": { - "cpu": "500m", - "memory": "200Mi" - }, - "requests": { - "cpu": "100m", - "memory": "100Mi" - } -} -``` - -- The `busybox-cnt01` Container inside `busybox` Pod defined `requests.cpu=100m` and `requests.memory=100Mi`. -- `100m <= 500m <= 800m` , The container cpu limit (500m) falls inside the authorized CPU limit range. -- `99Mi <= 200Mi <= 1Gi` , The container memory limit (200Mi) falls inside the authorized Memory limit range. -- No request/limits ratio validation for CPU/Memory , thus the container is valid and created. - - -### Container spec with a valid CPU/Memory requests but no limits - -View the `busybox-cnt02` resource configuration - -```shell -kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[1].resources" -``` - -```json -{ - "limits": { - "cpu": "700m", - "memory": "900Mi" - }, - "requests": { - "cpu": "100m", - "memory": "100Mi" - } -} -``` -- The `busybox-cnt02` Container inside `busybox1` Pod defined `requests.cpu=100m` and `requests.memory=100Mi` but not limits for cpu and memory. -- The container do not have a limits section, the default limits defined in the limit-mem-cpu-per-container LimitRange object are injected to this container `limits.cpu=700mi` and `limits.memory=900Mi`. -- `100m <= 700m <= 800m` , The container cpu limit (700m) falls inside the authorized CPU limit range. -- `99Mi <= 900Mi <= 1Gi` , The container memory limit (900Mi) falls inside the authorized Memory limit range. -- No request/limits ratio set , thus the container is valid and created. - - -### Container spec with a valid CPU/Memory limits but no requests -View the `busybox-cnt03` resource configuration - -```shell -kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[2].resources" -``` -```json -{ - "limits": { - "cpu": "500m", - "memory": "200Mi" - }, - "requests": { - "cpu": "500m", - "memory": "200Mi" - } -} -``` - -- The `busybox-cnt03` Container inside `busybox1` Pod defined `limits.cpu=500m` and `limits.memory=200Mi` but no `requests` for cpu and memory. -- The container do not define a request section, the defaultRequest defined in the limit-mem-cpu-per-container LimitRange is not used to fill its limits section but the limits defined by the container are set as requests `limits.cpu=500m` and `limits.memory=200Mi`. -- `100m <= 500m <= 800m` , The container cpu limit (500m) falls inside the authorized CPU limit range. -- `99Mi <= 200Mi <= 1Gi` , The container memory limit (200Mi) falls inside the authorized Memory limit range. -- No request/limits ratio set , thus the container is valid and created. - - - -### Container spec with no CPU/Memory requests/limits -View the `busybox-cnt04` resource configuration -```shell -kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[3].resources" -``` -```json -{ - "limits": { - "cpu": "700m", - "memory": "900Mi" - }, - "requests": { - "cpu": "110m", - "memory": "111Mi" - } -} -``` - -- The `busybox-cnt04` Container inside `busybox1` define neither `limits` nor `requests`. -- The container do not define a limit section, the default limit defined in the limit-mem-cpu-per-container LimitRange is used to fill its request - `limits.cpu=700m and` `limits.memory=900Mi` . -- The container do not define a request section, the defaultRequest defined in the limit-mem-cpu-per-container LimitRange is used to fill its request section requests.cpu=110m and requests.memory=111Mi -- `100m <= 700m <= 800m` , The container cpu limit (700m) falls inside the authorized CPU limit range. -- `99Mi <= 900Mi <= 1Gi` , The container memory limit (900Mi) falls inside the authorized Memory limitrange . -- No request/limits ratio set , thus the container is valid and created. - -All containers defined in the `busybox` Pod passed LimitRange validations, this the Pod is valid and create in the namespace. - -## Limiting Pod compute resources -The following section discusses how to constrain resources at Pod level. - -{{< codenew file="admin/resource/limit-mem-cpu-pod.yaml" >}} - -Without having to delete `busybox1` Pod, create the `limit-mem-cpu-pod` LimitRange in the `limitrange-demo` namespace -```shell -kubectl apply -f https://k8s.io/examples/admin/resource/limit-mem-cpu-pod.yaml -n limitrange-demo -``` -The limitrange is created and limits CPU to 2 Core and Memory to 2Gi per Pod. -```shell -limitrange/limit-mem-cpu-per-pod created -``` -Describe the `limit-mem-cpu-per-pod` limit object using the following kubectl command -```shell -kubectl describe limitrange/limit-mem-cpu-per-pod -``` - -```shell -Name: limit-mem-cpu-per-pod -Namespace: limitrange-demo -Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ----- -------- --- --- --------------- ------------- ----------------------- -Pod cpu - 2 - - - -Pod memory - 2Gi - - - -``` -Now create the `busybox2` Pod. - -{{< codenew file="admin/resource/limit-range-pod-2.yaml" >}} - -```shell -kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-2.yaml -n limitrange-demo -``` -The `busybox2` Pod definition is identical to `busybox1` but an error is reported since Pod's resources are now limited -```shell -Error from server (Forbidden): error when creating "limit-range-pod-2.yaml": pods "busybox2" is forbidden: [maximum cpu usage per Pod is 2, but limit is 2400m., maximum memory usage per Pod is 2Gi, but limit is 2306867200.] -``` - -```shell -kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[].resources.limits.memory" -"200Mi" -"900Mi" -"200Mi" -"900Mi" -``` -`busybox2` Pod will not be admitted on the cluster since the total memory limit of its container is greater than the limit defined in the LimitRange. -`busybox1` will not be evicted since it was created and admitted on the cluster before the LimitRange creation. - - -## Limiting Storage resources - -You can enforce minimum and maximum size of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested by each PersistentVolumeClaim in a namespace using a LimitRange. - -{{< codenew file="admin/resource/storagelimits.yaml" >}} - -Apply the YAML using `kubectl create`. - -```shell -kubectl create -f https://k8s.io/examples/admin/resource/storagelimits.yaml -n limitrange-demo -``` - -```shell -limitrange/storagelimits created -``` -Describe the created object, - -```shell -kubectl describe limits/storagelimits -``` -the output should look like - -```shell -Name: storagelimits -Namespace: limitrange-demo -Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ----- -------- --- --- --------------- ------------- ----------------------- -PersistentVolumeClaim storage 1Gi 2Gi - - - -``` - -{{< codenew file="admin/resource/pvc-limit-lower.yaml" >}} - -```shell -kubectl create -f https://k8s.io/examples/admin/resource//pvc-limit-lower.yaml -n limitrange-demo -``` - -While creating a PVC with `requests.storage` lower than the Min value in the LimitRange, an Error thrown by the server - -```shell -Error from server (Forbidden): error when creating "pvc-limit-lower.yaml": persistentvolumeclaims "pvc-limit-lower" is forbidden: minimum storage usage per PersistentVolumeClaim is 1Gi, but request is 500Mi. -``` - -Same behaviour is noted if the `requests.storage` is greater than the Max value in the LimitRange - -{{< codenew file="admin/resource/pvc-limit-greater.yaml" >}} - -```shell -kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-greater.yaml -n limitrange-demo -``` - -```shell -Error from server (Forbidden): error when creating "pvc-limit-greater.yaml": persistentvolumeclaims "pvc-limit-greater" is forbidden: maximum storage usage per PersistentVolumeClaim is 2Gi, but request is 5Gi. -``` - -## Limits/Requests Ratio - -If `LimitRangeItem.maxLimitRequestRatio` if specified in th `LimitRangeSpec`, the named resource must have a request and limit that are both non-zero where limit divided by request is less than or equal to the enumerated value - - the following `LimitRange` enforces memory limit to be at most twice the amount of the memory request for any pod in the namespace. - -{{< codenew file="admin/resource/limit-memory-ratio-pod.yaml" >}} - -```shell -kubectl apply -f https://k8s.io/examples/admin/resource/limit-memory-ratio-pod.yaml -``` - -Describe the LimitRange with the following kubectl command: - -```shell -$ kubectl describe limitrange/limit-memory-ratio-pod -``` - -```shell -Name: limit-memory-ratio-pod -Namespace: limitrange-demo -Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ----- -------- --- --- --------------- ------------- ----------------------- -Pod memory - - - - 2 -``` - - -Let's create a pod with `requests.memory=100Mi` and `limits.memory=300Mi` -{{< codenew file="admin/resource/limit-range-pod-3.yaml" >}} - - -```shell -kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-3.yaml -``` - -The pod creation failed as the ratio here (`3`) is greater than the enforced limit (`2`) in `limit-memory-ratio-pod` LimitRange - - -```shell -Error from server (Forbidden): error when creating "limit-range-pod-3.yaml": pods "busybox3" is forbidden: memory max limit to request ratio per Pod is 2, but provided ratio is 3.000000. -``` - - -### Clean up -Delete the `limitrange-demo` namespace to free all resources -```shell -kubectl delete ns limitrange-demo -``` - - -## Examples - -- See [a tutorial on how to limit compute resources per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) . -- Check [how to limit storage consumption](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). -- See a [detailed example on quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). - -{{% /capture %}} - -{{% capture whatsnext %}} - -See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information. - -{{% /capture %}} +--- +reviewers: +- nelvadas +title: Limit Ranges +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster. +With Resource quotas, cluster administrators can restrict the resource consumption and creation on a namespace basis. +Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all of the resources. Limit Range is a policy to constrain resource by Pod or Container in a namespace. + +{{% /capture %}} + + +{{% capture body %}} + +A limit range, defined by a `LimitRange` object, provides constraints that can: + +- Enforce minimum and maximum compute resources usage per Pod or Container in a namespace. +- Enforce minimum and maximum storage request per PersistentVolumeClaim in a namespace. +- Enforce a ratio between request and limit for a resource in a namespace. +- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime. + +## Enabling Limit Range + +Limit Range support is enabled by default for many Kubernetes distributions. It is +enabled when the apiserver `--enable-admission-plugins=` flag has `LimitRanger` admission controller as +one of its arguments. + +A limit range is enforced in a particular namespace when there is a +`LimitRange` object in that namespace. + +### Overview of Limit Range: + +- The administrator creates one `LimitRange` in one namespace. +- Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace. +- The `LimitRanger` admission controller enforces defaults limits for all Pods and Container that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum , maximum and ratio defined in any `LimitRange` present in the namespace. +- If creating or updating a resource (Pod, Container, PersistentVolumeClaim) violates a limit range constraint, the request to the API server will fail with HTTP status code `403 FORBIDDEN` and a message explaining the constraint that would have been violated. +- If limit range is activated in a namespace for compute resources like `cpu` and `memory`, users must specify + requests or limits for those values; otherwise, the system may reject pod creation. +- LimitRange validations occurs only at Pod Admission stage, not on Running pods. + + +Examples of policies that could be created using limit range are: + +- In a 2 node cluster with a capacity of 8 GiB RAM, and 16 cores, constrain Pods in a namespace to request 100m and not exceeds 500m for CPU , request 200Mi and not exceed 600Mi +- Define default CPU limits and request to 150m and Memory default request to 300Mi for containers started with no cpu and memory requests in their spec. + +In the case where the total limits of the namespace is less than the sum of the limits of the Pods/Containers, +there may be contention for resources; The Containers or Pods will not be created. + +Neither contention nor changes to limitrange will affect already created resources. + +## Limiting Container compute resources + +The following section discusses the creation of a LimitRange acting at Container Level. +A Pod with 04 containers is first created; each container within the Pod has a specific `spec.resource` configuration +each containerwithin the pod is handled differently by the LimitRanger admission controller. + + Create a namespace `limitrange-demo` using the following kubectl command + +```shell +kubectl create namespace limitrange-demo +``` + +To avoid passing the target limitrange-demo in your kubectl commands, change your context with the following command + +```shell +kubectl config set-context --current --namespace=limitrange-demo +``` + +Here is the configuration file for a LimitRange object: +{{< codenew file="admin/resource/limit-mem-cpu-container.yaml" >}} + +This object defines minimum and maximum Memory/CPU limits, default cpu/Memory requests and default limits for CPU/Memory resources to be apply to containers. + +Create the `limit-mem-cpu-per-container` LimitRange in the `limitrange-demo` namespace with the following kubectl command. +```shell +kubectl create -f https://k8s.io/examples/admin/resource/limit-mem-cpu-container.yaml -n limitrange-demo +``` + + +```shell + kubectl describe limitrange/limit-mem-cpu-per-container -n limitrange-demo + ``` + + +```shell +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +Container cpu 100m 800m 110m 700m - +Container memory 99Mi 1Gi 111Mi 900Mi - +``` + + + +Here is the configuration file for a Pod with 04 containers to demonstrate LimitRange features : +{{< codenew file="admin/resource/limit-range-pod-1.yaml" >}} + +Create the `busybox1` Pod : + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-1.yaml -n limitrange-demo +``` + +### Container spec with valid CPU/Memory requests and limits +View the the `busybox-cnt01` resource configuration + +```shell +kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[0].resources" +``` + +```json +{ + "limits": { + "cpu": "500m", + "memory": "200Mi" + }, + "requests": { + "cpu": "100m", + "memory": "100Mi" + } +} +``` + +- The `busybox-cnt01` Container inside `busybox` Pod defined `requests.cpu=100m` and `requests.memory=100Mi`. +- `100m <= 500m <= 800m` , The container cpu limit (500m) falls inside the authorized CPU limit range. +- `99Mi <= 200Mi <= 1Gi` , The container memory limit (200Mi) falls inside the authorized Memory limit range. +- No request/limits ratio validation for CPU/Memory , thus the container is valid and created. + + +### Container spec with a valid CPU/Memory requests but no limits + +View the `busybox-cnt02` resource configuration + +```shell +kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[1].resources" +``` + +```json +{ + "limits": { + "cpu": "700m", + "memory": "900Mi" + }, + "requests": { + "cpu": "100m", + "memory": "100Mi" + } +} +``` +- The `busybox-cnt02` Container inside `busybox1` Pod defined `requests.cpu=100m` and `requests.memory=100Mi` but not limits for cpu and memory. +- The container do not have a limits section, the default limits defined in the limit-mem-cpu-per-container LimitRange object are injected to this container `limits.cpu=700mi` and `limits.memory=900Mi`. +- `100m <= 700m <= 800m` , The container cpu limit (700m) falls inside the authorized CPU limit range. +- `99Mi <= 900Mi <= 1Gi` , The container memory limit (900Mi) falls inside the authorized Memory limit range. +- No request/limits ratio set , thus the container is valid and created. + + +### Container spec with a valid CPU/Memory limits but no requests +View the `busybox-cnt03` resource configuration + +```shell +kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[2].resources" +``` +```json +{ + "limits": { + "cpu": "500m", + "memory": "200Mi" + }, + "requests": { + "cpu": "500m", + "memory": "200Mi" + } +} +``` + +- The `busybox-cnt03` Container inside `busybox1` Pod defined `limits.cpu=500m` and `limits.memory=200Mi` but no `requests` for cpu and memory. +- The container do not define a request section, the defaultRequest defined in the limit-mem-cpu-per-container LimitRange is not used to fill its limits section but the limits defined by the container are set as requests `limits.cpu=500m` and `limits.memory=200Mi`. +- `100m <= 500m <= 800m` , The container cpu limit (500m) falls inside the authorized CPU limit range. +- `99Mi <= 200Mi <= 1Gi` , The container memory limit (200Mi) falls inside the authorized Memory limit range. +- No request/limits ratio set , thus the container is valid and created. + + + +### Container spec with no CPU/Memory requests/limits +View the `busybox-cnt04` resource configuration +```shell +kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[3].resources" +``` +```json +{ + "limits": { + "cpu": "700m", + "memory": "900Mi" + }, + "requests": { + "cpu": "110m", + "memory": "111Mi" + } +} +``` + +- The `busybox-cnt04` Container inside `busybox1` define neither `limits` nor `requests`. +- The container do not define a limit section, the default limit defined in the limit-mem-cpu-per-container LimitRange is used to fill its request + `limits.cpu=700m and` `limits.memory=900Mi` . +- The container do not define a request section, the defaultRequest defined in the limit-mem-cpu-per-container LimitRange is used to fill its request section requests.cpu=110m and requests.memory=111Mi +- `100m <= 700m <= 800m` , The container cpu limit (700m) falls inside the authorized CPU limit range. +- `99Mi <= 900Mi <= 1Gi` , The container memory limit (900Mi) falls inside the authorized Memory limitrange . +- No request/limits ratio set , thus the container is valid and created. + +All containers defined in the `busybox` Pod passed LimitRange validations, this the Pod is valid and create in the namespace. + +## Limiting Pod compute resources +The following section discusses how to constrain resources at Pod level. + +{{< codenew file="admin/resource/limit-mem-cpu-pod.yaml" >}} + +Without having to delete `busybox1` Pod, create the `limit-mem-cpu-pod` LimitRange in the `limitrange-demo` namespace +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-mem-cpu-pod.yaml -n limitrange-demo +``` +The limitrange is created and limits CPU to 2 Core and Memory to 2Gi per Pod. +```shell +limitrange/limit-mem-cpu-per-pod created +``` +Describe the `limit-mem-cpu-per-pod` limit object using the following kubectl command +```shell +kubectl describe limitrange/limit-mem-cpu-per-pod +``` + +```shell +Name: limit-mem-cpu-per-pod +Namespace: limitrange-demo +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +Pod cpu - 2 - - - +Pod memory - 2Gi - - - +``` +Now create the `busybox2` Pod. + +{{< codenew file="admin/resource/limit-range-pod-2.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-2.yaml -n limitrange-demo +``` +The `busybox2` Pod definition is identical to `busybox1` but an error is reported since Pod's resources are now limited +```shell +Error from server (Forbidden): error when creating "limit-range-pod-2.yaml": pods "busybox2" is forbidden: [maximum cpu usage per Pod is 2, but limit is 2400m., maximum memory usage per Pod is 2Gi, but limit is 2306867200.] +``` + +```shell +kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[].resources.limits.memory" +"200Mi" +"900Mi" +"200Mi" +"900Mi" +``` +`busybox2` Pod will not be admitted on the cluster since the total memory limit of its container is greater than the limit defined in the LimitRange. +`busybox1` will not be evicted since it was created and admitted on the cluster before the LimitRange creation. + + +## Limiting Storage resources + +You can enforce minimum and maximum size of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested by each PersistentVolumeClaim in a namespace using a LimitRange. + +{{< codenew file="admin/resource/storagelimits.yaml" >}} + +Apply the YAML using `kubectl create`. + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/storagelimits.yaml -n limitrange-demo +``` + +```shell +limitrange/storagelimits created +``` +Describe the created object, + +```shell +kubectl describe limits/storagelimits +``` +the output should look like + +```shell +Name: storagelimits +Namespace: limitrange-demo +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +PersistentVolumeClaim storage 1Gi 2Gi - - - +``` + +{{< codenew file="admin/resource/pvc-limit-lower.yaml" >}} + +```shell +kubectl create -f https://k8s.io/examples/admin/resource//pvc-limit-lower.yaml -n limitrange-demo +``` + +While creating a PVC with `requests.storage` lower than the Min value in the LimitRange, an Error thrown by the server + +```shell +Error from server (Forbidden): error when creating "pvc-limit-lower.yaml": persistentvolumeclaims "pvc-limit-lower" is forbidden: minimum storage usage per PersistentVolumeClaim is 1Gi, but request is 500Mi. +``` + +Same behaviour is noted if the `requests.storage` is greater than the Max value in the LimitRange + +{{< codenew file="admin/resource/pvc-limit-greater.yaml" >}} + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-greater.yaml -n limitrange-demo +``` + +```shell +Error from server (Forbidden): error when creating "pvc-limit-greater.yaml": persistentvolumeclaims "pvc-limit-greater" is forbidden: maximum storage usage per PersistentVolumeClaim is 2Gi, but request is 5Gi. +``` + +## Limits/Requests Ratio + +If `LimitRangeItem.maxLimitRequestRatio` if specified in th `LimitRangeSpec`, the named resource must have a request and limit that are both non-zero where limit divided by request is less than or equal to the enumerated value + + the following `LimitRange` enforces memory limit to be at most twice the amount of the memory request for any pod in the namespace. + +{{< codenew file="admin/resource/limit-memory-ratio-pod.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-memory-ratio-pod.yaml +``` + +Describe the LimitRange with the following kubectl command: + +```shell +$ kubectl describe limitrange/limit-memory-ratio-pod +``` + +```shell +Name: limit-memory-ratio-pod +Namespace: limitrange-demo +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +Pod memory - - - - 2 +``` + + +Let's create a pod with `requests.memory=100Mi` and `limits.memory=300Mi` +{{< codenew file="admin/resource/limit-range-pod-3.yaml" >}} + + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-3.yaml +``` + +The pod creation failed as the ratio here (`3`) is greater than the enforced limit (`2`) in `limit-memory-ratio-pod` LimitRange + + +```shell +Error from server (Forbidden): error when creating "limit-range-pod-3.yaml": pods "busybox3" is forbidden: memory max limit to request ratio per Pod is 2, but provided ratio is 3.000000. +``` + + +### Clean up +Delete the `limitrange-demo` namespace to free all resources +```shell +kubectl delete ns limitrange-demo +``` + + +## Examples + +- See [a tutorial on how to limit compute resources per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) . +- Check [how to limit storage consumption](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). +- See a [detailed example on quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). + +{{% /capture %}} + +{{% capture whatsnext %}} + +See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information. + +{{% /capture %}} diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 3150d5cf2a..c4f1f4a240 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -1,578 +1,578 @@ ---- -reviewers: -- derekwaynecarr -title: Resource Quotas -content_template: templates/concept -weight: 10 ---- - -{{% capture overview %}} - -When several users or teams share a cluster with a fixed number of nodes, -there is a concern that one team could use more than its fair share of resources. - -Resource quotas are a tool for administrators to address this concern. - -{{% /capture %}} - - -{{% capture body %}} - -A resource quota, defined by a `ResourceQuota` object, provides constraints that limit -aggregate resource consumption per namespace. It can limit the quantity of objects that can -be created in a namespace by type, as well as the total amount of compute resources that may -be consumed by resources in that project. - -Resource quotas work like this: - -- Different teams work in different namespaces. Currently this is voluntary, but - support for making this mandatory via ACLs is planned. -- The administrator creates one `ResourceQuota` for each namespace. -- Users create resources (pods, services, etc.) in the namespace, and the quota system - tracks usage to ensure it does not exceed hard resource limits defined in a `ResourceQuota`. -- If creating or updating a resource violates a quota constraint, the request will fail with HTTP - status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated. -- If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify - requests or limits for those values; otherwise, the quota system may reject pod creation. Hint: Use - the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements. - See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem. - -Examples of policies that could be created using namespaces and quotas are: - -- In a cluster with a capacity of 32 GiB RAM, and 16 cores, let team A use 20 GiB and 10 cores, - let B use 10GiB and 4 cores, and hold 2GiB and 2 cores in reserve for future allocation. -- Limit the "testing" namespace to using 1 core and 1GiB RAM. Let the "production" namespace - use any amount. - -In the case where the total capacity of the cluster is less than the sum of the quotas of the namespaces, -there may be contention for resources. This is handled on a first-come-first-served basis. - -Neither contention nor changes to quota will affect already created resources. - -## Enabling Resource Quota - -Resource Quota support is enabled by default for many Kubernetes distributions. It is -enabled when the apiserver `--enable-admission-plugins=` flag has `ResourceQuota` as -one of its arguments. - -A resource quota is enforced in a particular namespace when there is a -`ResourceQuota` in that namespace. - -## Compute Resource Quota - -You can limit the total sum of [compute resources](/docs/user-guide/compute-resources) that can be requested in a given namespace. - -The following resource types are supported: - -| Resource Name | Description | -| --------------------- | ----------------------------------------------------------- | -| `limits.cpu` | Across all pods in a non-terminal state, the sum of CPU limits cannot exceed this value. | -| `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. | -| `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. | -| `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. | - -### Resource Quota For Extended Resources - -In addition to the resources mentioned above, in release 1.10, quota support for -[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added. - -As overcommit is not allowed for extended resources, it makes no sense to specify both `requests` -and `limits` for the same extended resource in a quota. So for extended resources, only quota items -with prefix `requests.` is allowed for now. - -Take the GPU resource as an example, if the resource name is `nvidia.com/gpu`, and you want to -limit the total number of GPUs requested in a namespace to 4, you can define a quota as follows: - -* `requests.nvidia.com/gpu: 4` - -See [Viewing and Setting Quotas](#viewing-and-setting-quotas) for more detail information. - - -## Storage Resource Quota - -You can limit the total sum of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested in a given namespace. - -In addition, you can limit consumption of storage resources based on associated storage-class. - -| Resource Name | Description | -| --------------------- | ----------------------------------------------------------- | -| `requests.storage` | Across all persistent volume claims, the sum of storage requests cannot exceed this value. | -| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | -| `.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the storage-class-name, the sum of storage requests cannot exceed this value. | -| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Across all persistent volume claims associated with the storage-class-name, the total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | - -For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can -define a quota as follows: - -* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi` -* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi` - -In release 1.8, quota support for local ephemeral storage is added as an alpha feature: - -| Resource Name | Description | -| ------------------------------- |----------------------------------------------------------- | -| `requests.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage requests cannot exceed this value. | -| `limits.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage limits cannot exceed this value. | - -## Object Count Quota - -The 1.9 release added support to quota all standard namespaced resource types using the following syntax: - -* `count/.` - -Here is an example set of resources users may want to put under object count quota: - -* `count/persistentvolumeclaims` -* `count/services` -* `count/secrets` -* `count/configmaps` -* `count/replicationcontrollers` -* `count/deployments.apps` -* `count/replicasets.apps` -* `count/statefulsets.apps` -* `count/jobs.batch` -* `count/cronjobs.batch` -* `count/deployments.extensions` - -The 1.15 release added support for custom resources using the same syntax. -For example, to create a quota on a `widgets` custom resource in the `example.com` API group, use `count/widgets.example.com`. - -When using `count/*` resource quota, an object is charged against the quota if it exists in server storage. -These types of quotas are useful to protect against exhaustion of storage resources. For example, you may -want to quota the number of secrets in a server given their large size. Too many secrets in a cluster can -actually prevent servers and controllers from starting! You may choose to quota jobs to protect against -a poorly configured cronjob creating too many jobs in a namespace causing a denial of service. - -Prior to the 1.9 release, it was possible to do generic object count quota on a limited set of resources. -In addition, it is possible to further constrain quota for particular resources by their type. - -The following types are supported: - -| Resource Name | Description | -| ------------------------------- | ------------------------------------------------- | -| `configmaps` | The total number of config maps that can exist in the namespace. | -| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | -| `pods` | The total number of pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true. | -| `replicationcontrollers` | The total number of replication controllers that can exist in the namespace. | -| `resourcequotas` | The total number of [resource quotas](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) that can exist in the namespace. | -| `services` | The total number of services that can exist in the namespace. | -| `services.loadbalancers` | The total number of services of type load balancer that can exist in the namespace. | -| `services.nodeports` | The total number of services of type node port that can exist in the namespace. | -| `secrets` | The total number of secrets that can exist in the namespace. | - -For example, `pods` quota counts and enforces a maximum on the number of `pods` -created in a single namespace that are not terminal. You might want to set a `pods` -quota on a namespace to avoid the case where a user creates many small pods and -exhausts the cluster's supply of Pod IPs. - -## Quota Scopes - -Each quota can have an associated set of scopes. A quota will only measure usage for a resource if it matches -the intersection of enumerated scopes. - -When a scope is added to the quota, it limits the number of resources it supports to those that pertain to the scope. -Resources specified on the quota outside of the allowed set results in a validation error. - -| Scope | Description | -| ----- | ----------- | -| `Terminating` | Match pods where `.spec.activeDeadlineSeconds >= 0` | -| `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` | -| `BestEffort` | Match pods that have best effort quality of service. | -| `NotBestEffort` | Match pods that do not have best effort quality of service. | - -The `BestEffort` scope restricts a quota to tracking the following resource: `pods` - -The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota to tracking the following resources: - -* `cpu` -* `limits.cpu` -* `limits.memory` -* `memory` -* `pods` -* `requests.cpu` -* `requests.memory` - -### Resource Quota Per PriorityClass - -{{< feature-state for_k8s_version="1.12" state="beta" >}} - -Pods can be created at a specific [priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority). -You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector` -field in the quota spec. - -A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod. - -This example creates a quota object and matches it with pods at specific priorities. The example -works as follows: - -- Pods in the cluster have one of the three priority classes, "low", "medium", "high". -- One quota object is created for each priority. - -Save the following YAML to a file `quota.yml`. - -```yaml -apiVersion: v1 -kind: List -items: -- apiVersion: v1 - kind: ResourceQuota - metadata: - name: pods-high - spec: - hard: - cpu: "1000" - memory: 200Gi - pods: "10" - scopeSelector: - matchExpressions: - - operator : In - scopeName: PriorityClass - values: ["high"] -- apiVersion: v1 - kind: ResourceQuota - metadata: - name: pods-medium - spec: - hard: - cpu: "10" - memory: 20Gi - pods: "10" - scopeSelector: - matchExpressions: - - operator : In - scopeName: PriorityClass - values: ["medium"] -- apiVersion: v1 - kind: ResourceQuota - metadata: - name: pods-low - spec: - hard: - cpu: "5" - memory: 10Gi - pods: "10" - scopeSelector: - matchExpressions: - - operator : In - scopeName: PriorityClass - values: ["low"] -``` - -Apply the YAML using `kubectl create`. - -```shell -kubectl create -f ./quota.yml -``` - -```shell -resourcequota/pods-high created -resourcequota/pods-medium created -resourcequota/pods-low created -``` - -Verify that `Used` quota is `0` using `kubectl describe quota`. - -```shell -kubectl describe quota -``` - -```shell -Name: pods-high -Namespace: default -Resource Used Hard --------- ---- ---- -cpu 0 1k -memory 0 200Gi -pods 0 10 - - -Name: pods-low -Namespace: default -Resource Used Hard --------- ---- ---- -cpu 0 5 -memory 0 10Gi -pods 0 10 - - -Name: pods-medium -Namespace: default -Resource Used Hard --------- ---- ---- -cpu 0 10 -memory 0 20Gi -pods 0 10 -``` - -Create a pod with priority "high". Save the following YAML to a -file `high-priority-pod.yml`. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: high-priority -spec: - containers: - - name: high-priority - image: ubuntu - command: ["/bin/sh"] - args: ["-c", "while true; do echo hello; sleep 10;done"] - resources: - requests: - memory: "10Gi" - cpu: "500m" - limits: - memory: "10Gi" - cpu: "500m" - priorityClassName: high -``` - -Apply it with `kubectl create`. - -```shell -kubectl create -f ./high-priority-pod.yml -``` - -Verify that "Used" stats for "high" priority quota, `pods-high`, has changed and that -the other two quotas are unchanged. - -```shell -kubectl describe quota -``` - -```shell -Name: pods-high -Namespace: default -Resource Used Hard --------- ---- ---- -cpu 500m 1k -memory 10Gi 200Gi -pods 1 10 - - -Name: pods-low -Namespace: default -Resource Used Hard --------- ---- ---- -cpu 0 5 -memory 0 10Gi -pods 0 10 - - -Name: pods-medium -Namespace: default -Resource Used Hard --------- ---- ---- -cpu 0 10 -memory 0 20Gi -pods 0 10 -``` - -`scopeSelector` supports the following values in the `operator` field: - -* `In` -* `NotIn` -* `Exist` -* `DoesNotExist` - -## Requests vs Limits - -When allocating compute resources, each container may specify a request and a limit value for either CPU or memory. -The quota can be configured to quota either value. - -If the quota has a value specified for `requests.cpu` or `requests.memory`, then it requires that every incoming -container makes an explicit request for those resources. If the quota has a value specified for `limits.cpu` or `limits.memory`, -then it requires that every incoming container specifies an explicit limit for those resources. - -## Viewing and Setting Quotas - -Kubectl supports creating, updating, and viewing quotas: - -```shell -kubectl create namespace myspace -``` - -```shell -cat < compute-resources.yaml -apiVersion: v1 -kind: ResourceQuota -metadata: - name: compute-resources -spec: - hard: - pods: "4" - requests.cpu: "1" - requests.memory: 1Gi - limits.cpu: "2" - limits.memory: 2Gi - requests.nvidia.com/gpu: 4 -EOF -``` - -```shell -kubectl create -f ./compute-resources.yaml --namespace=myspace -``` - -```shell -cat < object-counts.yaml -apiVersion: v1 -kind: ResourceQuota -metadata: - name: object-counts -spec: - hard: - configmaps: "10" - persistentvolumeclaims: "4" - replicationcontrollers: "20" - secrets: "10" - services: "10" - services.loadbalancers: "2" -EOF -``` - -```shell -kubectl create -f ./object-counts.yaml --namespace=myspace -``` - -```shell -kubectl get quota --namespace=myspace -``` - -```shell -NAME AGE -compute-resources 30s -object-counts 32s -``` - -```shell -kubectl describe quota compute-resources --namespace=myspace -``` - -```shell -Name: compute-resources -Namespace: myspace -Resource Used Hard --------- ---- ---- -limits.cpu 0 2 -limits.memory 0 2Gi -pods 0 4 -requests.cpu 0 1 -requests.memory 0 1Gi -requests.nvidia.com/gpu 0 4 -``` - -```shell -kubectl describe quota object-counts --namespace=myspace -``` - -```shell -Name: object-counts -Namespace: myspace -Resource Used Hard --------- ---- ---- -configmaps 0 10 -persistentvolumeclaims 0 4 -replicationcontrollers 0 20 -secrets 1 10 -services 0 10 -services.loadbalancers 0 2 -``` - -Kubectl also supports object count quota for all standard namespaced resources -using the syntax `count/.`: - -```shell -kubectl create namespace myspace -``` - -```shell -kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace -``` - -```shell -kubectl run nginx --image=nginx --replicas=2 --namespace=myspace -``` - -```shell -kubectl describe quota --namespace=myspace -``` - -```shell -Name: test -Namespace: myspace -Resource Used Hard --------- ---- ---- -count/deployments.extensions 1 2 -count/pods 2 3 -count/replicasets.extensions 1 4 -count/secrets 1 4 -``` - -## Quota and Cluster Capacity - -`ResourceQuotas` are independent of the cluster capacity. They are -expressed in absolute units. So, if you add nodes to your cluster, this does *not* -automatically give each namespace the ability to consume more resources. - -Sometimes more complex policies may be desired, such as: - - - Proportionally divide total cluster resources among several teams. - - Allow each tenant to grow resource usage as needed, but have a generous - limit to prevent accidental resource exhaustion. - - Detect demand from one namespace, add nodes, and increase quota. - -Such policies could be implemented using `ResourceQuotas` as building blocks, by -writing a "controller" that watches the quota usage and adjusts the quota -hard limits of each namespace according to other signals. - -Note that resource quota divides up aggregate cluster resources, but it creates no -restrictions around nodes: pods from several namespaces may run on the same node. - -## Limit Priority Class consumption by default - -It may be desired that pods at a particular priority, eg. "cluster-services", should be allowed in a namespace, if and only if, a matching quota object exists. - -With this mechanism, operators will be able to restrict usage of certain high priority classes to a limited number of namespaces and not every namespace will be able to consume these priority classes by default. - -To enforce this, kube-apiserver flag `--admission-control-config-file` should be used to pass path to the following configuration file: - -```yaml -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: "ResourceQuota" - configuration: - apiVersion: resourcequota.admission.k8s.io/v1beta1 - kind: Configuration - limitedResources: - - resource: pods - matchScopes: - - scopeName: PriorityClass - operator: In - values: ["cluster-services"] -``` - -Now, "cluster-services" pods will be allowed in only those namespaces where a quota object with a matching `scopeSelector` is present. -For example: -```yaml - scopeSelector: - matchExpressions: - - scopeName: PriorityClass - operator: In - values: ["cluster-services"] -``` - -See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md) for more information. - -## Example - -See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/). - -{{% /capture %}} - -{{% capture whatsnext %}} - -See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information. - -{{% /capture %}} +--- +reviewers: +- derekwaynecarr +title: Resource Quotas +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +When several users or teams share a cluster with a fixed number of nodes, +there is a concern that one team could use more than its fair share of resources. + +Resource quotas are a tool for administrators to address this concern. + +{{% /capture %}} + + +{{% capture body %}} + +A resource quota, defined by a `ResourceQuota` object, provides constraints that limit +aggregate resource consumption per namespace. It can limit the quantity of objects that can +be created in a namespace by type, as well as the total amount of compute resources that may +be consumed by resources in that project. + +Resource quotas work like this: + +- Different teams work in different namespaces. Currently this is voluntary, but + support for making this mandatory via ACLs is planned. +- The administrator creates one `ResourceQuota` for each namespace. +- Users create resources (pods, services, etc.) in the namespace, and the quota system + tracks usage to ensure it does not exceed hard resource limits defined in a `ResourceQuota`. +- If creating or updating a resource violates a quota constraint, the request will fail with HTTP + status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated. +- If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify + requests or limits for those values; otherwise, the quota system may reject pod creation. Hint: Use + the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements. + See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem. + +Examples of policies that could be created using namespaces and quotas are: + +- In a cluster with a capacity of 32 GiB RAM, and 16 cores, let team A use 20 GiB and 10 cores, + let B use 10GiB and 4 cores, and hold 2GiB and 2 cores in reserve for future allocation. +- Limit the "testing" namespace to using 1 core and 1GiB RAM. Let the "production" namespace + use any amount. + +In the case where the total capacity of the cluster is less than the sum of the quotas of the namespaces, +there may be contention for resources. This is handled on a first-come-first-served basis. + +Neither contention nor changes to quota will affect already created resources. + +## Enabling Resource Quota + +Resource Quota support is enabled by default for many Kubernetes distributions. It is +enabled when the apiserver `--enable-admission-plugins=` flag has `ResourceQuota` as +one of its arguments. + +A resource quota is enforced in a particular namespace when there is a +`ResourceQuota` in that namespace. + +## Compute Resource Quota + +You can limit the total sum of [compute resources](/docs/user-guide/compute-resources) that can be requested in a given namespace. + +The following resource types are supported: + +| Resource Name | Description | +| --------------------- | ----------------------------------------------------------- | +| `limits.cpu` | Across all pods in a non-terminal state, the sum of CPU limits cannot exceed this value. | +| `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. | +| `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. | +| `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. | + +### Resource Quota For Extended Resources + +In addition to the resources mentioned above, in release 1.10, quota support for +[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added. + +As overcommit is not allowed for extended resources, it makes no sense to specify both `requests` +and `limits` for the same extended resource in a quota. So for extended resources, only quota items +with prefix `requests.` is allowed for now. + +Take the GPU resource as an example, if the resource name is `nvidia.com/gpu`, and you want to +limit the total number of GPUs requested in a namespace to 4, you can define a quota as follows: + +* `requests.nvidia.com/gpu: 4` + +See [Viewing and Setting Quotas](#viewing-and-setting-quotas) for more detail information. + + +## Storage Resource Quota + +You can limit the total sum of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested in a given namespace. + +In addition, you can limit consumption of storage resources based on associated storage-class. + +| Resource Name | Description | +| --------------------- | ----------------------------------------------------------- | +| `requests.storage` | Across all persistent volume claims, the sum of storage requests cannot exceed this value. | +| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | +| `.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the storage-class-name, the sum of storage requests cannot exceed this value. | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Across all persistent volume claims associated with the storage-class-name, the total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | + +For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can +define a quota as follows: + +* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi` +* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi` + +In release 1.8, quota support for local ephemeral storage is added as an alpha feature: + +| Resource Name | Description | +| ------------------------------- |----------------------------------------------------------- | +| `requests.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage requests cannot exceed this value. | +| `limits.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage limits cannot exceed this value. | + +## Object Count Quota + +The 1.9 release added support to quota all standard namespaced resource types using the following syntax: + +* `count/.` + +Here is an example set of resources users may want to put under object count quota: + +* `count/persistentvolumeclaims` +* `count/services` +* `count/secrets` +* `count/configmaps` +* `count/replicationcontrollers` +* `count/deployments.apps` +* `count/replicasets.apps` +* `count/statefulsets.apps` +* `count/jobs.batch` +* `count/cronjobs.batch` +* `count/deployments.extensions` + +The 1.15 release added support for custom resources using the same syntax. +For example, to create a quota on a `widgets` custom resource in the `example.com` API group, use `count/widgets.example.com`. + +When using `count/*` resource quota, an object is charged against the quota if it exists in server storage. +These types of quotas are useful to protect against exhaustion of storage resources. For example, you may +want to quota the number of secrets in a server given their large size. Too many secrets in a cluster can +actually prevent servers and controllers from starting! You may choose to quota jobs to protect against +a poorly configured cronjob creating too many jobs in a namespace causing a denial of service. + +Prior to the 1.9 release, it was possible to do generic object count quota on a limited set of resources. +In addition, it is possible to further constrain quota for particular resources by their type. + +The following types are supported: + +| Resource Name | Description | +| ------------------------------- | ------------------------------------------------- | +| `configmaps` | The total number of config maps that can exist in the namespace. | +| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | +| `pods` | The total number of pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true. | +| `replicationcontrollers` | The total number of replication controllers that can exist in the namespace. | +| `resourcequotas` | The total number of [resource quotas](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) that can exist in the namespace. | +| `services` | The total number of services that can exist in the namespace. | +| `services.loadbalancers` | The total number of services of type load balancer that can exist in the namespace. | +| `services.nodeports` | The total number of services of type node port that can exist in the namespace. | +| `secrets` | The total number of secrets that can exist in the namespace. | + +For example, `pods` quota counts and enforces a maximum on the number of `pods` +created in a single namespace that are not terminal. You might want to set a `pods` +quota on a namespace to avoid the case where a user creates many small pods and +exhausts the cluster's supply of Pod IPs. + +## Quota Scopes + +Each quota can have an associated set of scopes. A quota will only measure usage for a resource if it matches +the intersection of enumerated scopes. + +When a scope is added to the quota, it limits the number of resources it supports to those that pertain to the scope. +Resources specified on the quota outside of the allowed set results in a validation error. + +| Scope | Description | +| ----- | ----------- | +| `Terminating` | Match pods where `.spec.activeDeadlineSeconds >= 0` | +| `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` | +| `BestEffort` | Match pods that have best effort quality of service. | +| `NotBestEffort` | Match pods that do not have best effort quality of service. | + +The `BestEffort` scope restricts a quota to tracking the following resource: `pods` + +The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota to tracking the following resources: + +* `cpu` +* `limits.cpu` +* `limits.memory` +* `memory` +* `pods` +* `requests.cpu` +* `requests.memory` + +### Resource Quota Per PriorityClass + +{{< feature-state for_k8s_version="1.12" state="beta" >}} + +Pods can be created at a specific [priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority). +You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector` +field in the quota spec. + +A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod. + +This example creates a quota object and matches it with pods at specific priorities. The example +works as follows: + +- Pods in the cluster have one of the three priority classes, "low", "medium", "high". +- One quota object is created for each priority. + +Save the following YAML to a file `quota.yml`. + +```yaml +apiVersion: v1 +kind: List +items: +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-high + spec: + hard: + cpu: "1000" + memory: 200Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["high"] +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-medium + spec: + hard: + cpu: "10" + memory: 20Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["medium"] +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-low + spec: + hard: + cpu: "5" + memory: 10Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["low"] +``` + +Apply the YAML using `kubectl create`. + +```shell +kubectl create -f ./quota.yml +``` + +```shell +resourcequota/pods-high created +resourcequota/pods-medium created +resourcequota/pods-low created +``` + +Verify that `Used` quota is `0` using `kubectl describe quota`. + +```shell +kubectl describe quota +``` + +```shell +Name: pods-high +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 1k +memory 0 200Gi +pods 0 10 + + +Name: pods-low +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 5 +memory 0 10Gi +pods 0 10 + + +Name: pods-medium +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 10 +memory 0 20Gi +pods 0 10 +``` + +Create a pod with priority "high". Save the following YAML to a +file `high-priority-pod.yml`. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: high-priority +spec: + containers: + - name: high-priority + image: ubuntu + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello; sleep 10;done"] + resources: + requests: + memory: "10Gi" + cpu: "500m" + limits: + memory: "10Gi" + cpu: "500m" + priorityClassName: high +``` + +Apply it with `kubectl create`. + +```shell +kubectl create -f ./high-priority-pod.yml +``` + +Verify that "Used" stats for "high" priority quota, `pods-high`, has changed and that +the other two quotas are unchanged. + +```shell +kubectl describe quota +``` + +```shell +Name: pods-high +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 500m 1k +memory 10Gi 200Gi +pods 1 10 + + +Name: pods-low +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 5 +memory 0 10Gi +pods 0 10 + + +Name: pods-medium +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 10 +memory 0 20Gi +pods 0 10 +``` + +`scopeSelector` supports the following values in the `operator` field: + +* `In` +* `NotIn` +* `Exist` +* `DoesNotExist` + +## Requests vs Limits + +When allocating compute resources, each container may specify a request and a limit value for either CPU or memory. +The quota can be configured to quota either value. + +If the quota has a value specified for `requests.cpu` or `requests.memory`, then it requires that every incoming +container makes an explicit request for those resources. If the quota has a value specified for `limits.cpu` or `limits.memory`, +then it requires that every incoming container specifies an explicit limit for those resources. + +## Viewing and Setting Quotas + +Kubectl supports creating, updating, and viewing quotas: + +```shell +kubectl create namespace myspace +``` + +```shell +cat < compute-resources.yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: compute-resources +spec: + hard: + pods: "4" + requests.cpu: "1" + requests.memory: 1Gi + limits.cpu: "2" + limits.memory: 2Gi + requests.nvidia.com/gpu: 4 +EOF +``` + +```shell +kubectl create -f ./compute-resources.yaml --namespace=myspace +``` + +```shell +cat < object-counts.yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: object-counts +spec: + hard: + configmaps: "10" + persistentvolumeclaims: "4" + replicationcontrollers: "20" + secrets: "10" + services: "10" + services.loadbalancers: "2" +EOF +``` + +```shell +kubectl create -f ./object-counts.yaml --namespace=myspace +``` + +```shell +kubectl get quota --namespace=myspace +``` + +```shell +NAME AGE +compute-resources 30s +object-counts 32s +``` + +```shell +kubectl describe quota compute-resources --namespace=myspace +``` + +```shell +Name: compute-resources +Namespace: myspace +Resource Used Hard +-------- ---- ---- +limits.cpu 0 2 +limits.memory 0 2Gi +pods 0 4 +requests.cpu 0 1 +requests.memory 0 1Gi +requests.nvidia.com/gpu 0 4 +``` + +```shell +kubectl describe quota object-counts --namespace=myspace +``` + +```shell +Name: object-counts +Namespace: myspace +Resource Used Hard +-------- ---- ---- +configmaps 0 10 +persistentvolumeclaims 0 4 +replicationcontrollers 0 20 +secrets 1 10 +services 0 10 +services.loadbalancers 0 2 +``` + +Kubectl also supports object count quota for all standard namespaced resources +using the syntax `count/.`: + +```shell +kubectl create namespace myspace +``` + +```shell +kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace +``` + +```shell +kubectl run nginx --image=nginx --replicas=2 --namespace=myspace +``` + +```shell +kubectl describe quota --namespace=myspace +``` + +```shell +Name: test +Namespace: myspace +Resource Used Hard +-------- ---- ---- +count/deployments.extensions 1 2 +count/pods 2 3 +count/replicasets.extensions 1 4 +count/secrets 1 4 +``` + +## Quota and Cluster Capacity + +`ResourceQuotas` are independent of the cluster capacity. They are +expressed in absolute units. So, if you add nodes to your cluster, this does *not* +automatically give each namespace the ability to consume more resources. + +Sometimes more complex policies may be desired, such as: + + - Proportionally divide total cluster resources among several teams. + - Allow each tenant to grow resource usage as needed, but have a generous + limit to prevent accidental resource exhaustion. + - Detect demand from one namespace, add nodes, and increase quota. + +Such policies could be implemented using `ResourceQuotas` as building blocks, by +writing a "controller" that watches the quota usage and adjusts the quota +hard limits of each namespace according to other signals. + +Note that resource quota divides up aggregate cluster resources, but it creates no +restrictions around nodes: pods from several namespaces may run on the same node. + +## Limit Priority Class consumption by default + +It may be desired that pods at a particular priority, eg. "cluster-services", should be allowed in a namespace, if and only if, a matching quota object exists. + +With this mechanism, operators will be able to restrict usage of certain high priority classes to a limited number of namespaces and not every namespace will be able to consume these priority classes by default. + +To enforce this, kube-apiserver flag `--admission-control-config-file` should be used to pass path to the following configuration file: + +```yaml +apiVersion: apiserver.k8s.io/v1alpha1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + apiVersion: resourcequota.admission.k8s.io/v1beta1 + kind: Configuration + limitedResources: + - resource: pods + matchScopes: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` + +Now, "cluster-services" pods will be allowed in only those namespaces where a quota object with a matching `scopeSelector` is present. +For example: +```yaml + scopeSelector: + matchExpressions: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` + +See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md) for more information. + +## Example + +See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/). + +{{% /capture %}} + +{{% capture whatsnext %}} + +See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information. + +{{% /capture %}} diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 8ecc851431..f243a812ff 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -268,7 +268,7 @@ Expanding EBS volumes is a time consuming operation. Also, there is a per-volume * AzureDisk * CSI * FC (Fibre Channel) -* Flexvolume +* FlexVolume * Flocker * NFS * iSCSI diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index a8def3012b..9e3a254a20 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -53,6 +53,7 @@ provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Retain +allowVolumeExpansion: true mountOptions: - debug volumeBindingMode: Immediate @@ -110,6 +111,31 @@ either `Delete` or `Retain`. If no `reclaimPolicy` is specified when a Persistent Volumes that are created manually and managed via a storage class will have whatever reclaim policy they were assigned at creation. +### Allow Volume Expansion + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +Persistent Volumes can be configured to be expandable. This feature when set to `true`, +allows the users to resize the volume by editing the corresponding PVC object. + +The following types of volumes support volume expansion, when the underlying +Storage Class has the field `allowVolumeExpansion` set to true. + +* gcePersistentDisk +* awsElasticBlockStore +* Cinder +* glusterfs +* rbd +* Azure File +* Azure Disk +* Portworx +* FlexVolumes +* CSI {{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +{{< note >}} +This feature cannot be used to shrink volumes. +{{< /note >}} + ### Mount Options Persistent Volumes that are dynamically created by a storage class will have the diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index bde634a6ea..7aba5a1cdb 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -15,10 +15,6 @@ weight: 40 StatefulSet is the workload API object used to manage stateful applications. -{{< note >}} -StatefulSets are stable (GA) in 1.9. -{{< /note >}} - {{< glossary_definition term_id="statefulset" length="all" >}} {{% /capture %}} @@ -43,7 +39,6 @@ provides a set of stateless replicas. Controllers such as ## Limitations -* StatefulSet was a beta resource prior to 1.9 and not available in any Kubernetes release prior to 1.5. * The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. * Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources. * StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service. diff --git a/content/en/docs/contribute/intermediate.md b/content/en/docs/contribute/intermediate.md index a7e36af944..086fb5350d 100644 --- a/content/en/docs/contribute/intermediate.md +++ b/content/en/docs/contribute/intermediate.md @@ -62,7 +62,8 @@ yourself, but the project is better in the long term when we have a diversity of active participants. Before you start reviewing PRs, make sure you are familiar with the -[Documentation Style Guide](/docs/contribute/style/style-guide/) +[Documentation Content Guide](/docs/contribute/style/content-guide/), the +[Documentation Style Guide](/docs/contribute/style/style-guide/), and the [code of conduct](/community/code-of-conduct/). ### Find a PR to review diff --git a/content/en/docs/contribute/start.md b/content/en/docs/contribute/start.md index c736e0914a..dfcc9acaf9 100644 --- a/content/en/docs/contribute/start.md +++ b/content/en/docs/contribute/start.md @@ -44,6 +44,15 @@ called SIG Docs. We [communicate](#participate-in-sig-docs-discussions) using a weekly video meetings. New participants are welcome. For more information, see [Participating in SIG Docs](/docs/contribute/participating/). +### Content guildelines + +The SIG Docs community created guidelines about what kind of content is allowed +in the Kubernetes documentation. Look over the [Documentation Content +Guide](/docs/contribute/style/content-guide/) to determine if the content +contribution you want to make is allowed. You can ask questions about allowed +content in the [#sig-docs]((#participate-in-sig-docs-discussions)) Slack +channel. + ### Style guidelines We maintain a [style guide](/docs/contribute/style/style-guide/) with information @@ -330,7 +339,7 @@ commercial in nature and should consist of content that will apply broadly to the Kubernetes community. To submit a blog post, you can either submit it using the -[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSch_phFYMTYlrTDuYziURP6nLMijoXx_f7sLABEU5gWBtxJHQ/viewform), +[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform), or follow the steps below. 1. [Sign the CLA](#sign-the-cla) if you have not yet done so. diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md new file mode 100644 index 0000000000..bbc76aa6be --- /dev/null +++ b/content/en/docs/contribute/style/content-guide.md @@ -0,0 +1,116 @@ +--- +title: Documentation Content Guide +linktitle: Content guide +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 20 + title: Documentation Content Guide +--- + +{{% capture overview %}} +This page contains guidelines for adding content to the Kubernetes documentation. +If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask! Use your best judgment, and feel free to +propose changes to this document in a pull request. + +For additional information on creating new content for the Kubernetes +docs, follow the instructions in the [Style guide](/docs/contribute/style/style-guide). +{{% /capture %}} + +{{% capture body %}} +## Contributing content + +The Kubernetes documentation comprises the content of the +[kubernetes/website](https://github.com/kubernetes/website) source repository. +Located in the `kubernetes/website/content//docs` folder, the +majority of the Kubernetes documentation is specific to the [Kubernetes +project](https://github.com/kubernetes/kubernetes). The Kubernetes +documentation may also include content from projects in the +[kubernetes](https://github.com/kubernetes) and +[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations if +those projects do not have their own documentation. Linking to active kubernetes, +kubernetes-sigs, and ({{< glossary_tooltip text="CNCF" term_id="cncf" >}}) projects from the Kubernetes documentation is always +allowed, but linking to vendor-specific products is not. Check the CNCF project lists +([Graduated/Incubating](https://www.cncf.io/projects/), +[Sandbox](https://www.cncf.io/sandbox-projects/), +[Archived](https://www.cncf.io/archived-projects/)) if you are unsure of a +project's CNCF status. + +### Dual-sourced content + +Kubernetes documentation does not include duplicate content sourced from multiple +locations (*dual-sourced* content). Dual-sourced content requires duplicated +effort from project maintainers and tends to become outdated more quickly. +Before adding content, ask yourself this: + +- Is the content about an active CNCF project OR a project in the kubernetes or kubernetes-sigs GitHub organizations? + - If yes, then: + - Does the project have its own documentation? + - if yes, link to the project's documention from the Kubernetes documentation + - if no, add the content to the project's repository if possible and then link to it from the Kubernetes documentation + - If no, then: + - Stop! + - Adding content about vendor-specific products is not allowed + - Linking to vendor-specific documentation and websites is not allowed + +### What is and isn't allowed + +There are some scenarios in which the Kubernetes documentation includes content from non-Kubernetes projects. +Below are general categories of non-Kubernetes project content along with guidelines of what is and is not allowed: + +1. Instructional content involving non-Kubernetes projects during setup or operation of Kubernetes + - Allowed: + - Referring to or linking to existing documentation about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations + - Example: for installating Kubernetes in a learning environment, including a prerequisite stating that successful installation and configuration of minikube is required and linking to the relevant minikube documentation + - Adding content for kubernetes or kubernetes-sigs projects that don't have their own instructional content + - Example: including [kubadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions + - Not Allowed: + - Adding content that duplicates documentation in another repository + - Examples: + - Including minikube installation and configuration instructions; minikube has its own [documentation](https://minikube.sigs.k8s.io/docs/) that provides those instructions + - Including instructions for installing Docker, CRI-O, containerd, and other container runtimes on various operating systems + - Including instructions for installing Kubernetes on production environments using various projects: + - Kubernetes Rebar Integrated Bootstrap (KRIB) is a vendor-specific project and content belongs in the vendor's documentation + - [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) has installation instructions and tutorials in its GitHub repository + - [Kubespray](https://kubespray.io) has its own documenation + - Adding a tutorial that explains how to perform a task using a vendor-specific product or an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations + - Adding a tutorial on how to use a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations if the project has its own documentation +1. Detailed technical content about how to use a non-Kubernetes project or how that project is designed + + Adding this type of content to the Kubernetes documentation is not allowed. +1. Content that describes a non-Kubernetes project + - Allowed: + - Adding a brief introductory paragraph about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations; the paragraph may contain links to the project + - Not Allowed: + - Adding content describing a vendor-specific product + - Adding content describing an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations + - Adding content that duplicates documentation from another project, regardless of source repository + - Example: adding [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) documentation to the Kubernetes documentation +1. Content that simply links to information about a non-Kubernetes project + - Allowed: + - Linking to projects in the kubernetes and kubernetes-sigs GitHub organizations + - Example: linking to Kubernetes in Docker (KinD) [documentation](https://kind.sigs.k8s.io/docs/user/quick-start), which resides in the kubernetes-sigs GitHub organization + - Linking to active CNCF projects + - Example: linking to the Prometheus [documentation](https://prometheus.io/docs/introduction/overview/); Prometheus is an active CNCF project + - Not Allowed: + - Linking to vendor-specific products + - Linking to archived CNCF projects + - Linking to inactive projects in the kubernetes and kubernetes-sigs GitHub organizations + - Linking to open source projects that are not CNCF projects or do not reside in the kubernetes or kubernetes-sigs GitHub organizations +1. Content about training courses + - Allowed: + - Linking to vendor-neutral Kubernetes training courses offered by the [CNCF](https://www.cncf.io/), the [Linux Foundation](https://www.linuxfoundation.org/), and the [Linux Academy](https://linuxacademy.com/), which is a partner of the Linux Foundation + - Example: linking to Linux Academy courses such as [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) and [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/) + - Not Allowed: + - Linking to online training outside of the CNCF, the Linux Foundation, or the Linux Academy; the Kubernetes documentation does not link to third-party content + - Example: linking to Kubernetes tutorials or courses on Medium, KodeKloud, Udacity, Coursera, learnk8s, and similar websites + - Linking to vendor-specific tutorials regardless of the training provider + - Example: linking to Linux Academy courses such as [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) and [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/) + +If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask! +{{% /capture %}} + +{{% capture whatsnext %}} +* Read the [Style guide](/docs/contribute/style/style-guide). +{{% /capture %}} diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 771684b1e5..64502dd7a6 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -14,10 +14,12 @@ This page gives writing style guidelines for the Kubernetes documentation. These are guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. -For additional information on creating new content for the Kubernetes -docs, follow the instructions on -[using page templates](/docs/contribute/style/page-templates/) and -[creating a documentation pull request](/docs/contribute/start/#improve-existing-content). +For additional information on creating new content for the Kubernetes +documentation, read the [Documentation Content +Guide](/docs/contribute/style/content-guide/) and follow the instructions on +[using page templates](/docs/contribute/style/page-templates/) and [creating a +documentation pull request](/docs/contribute/start/#improve-existing-content). + {{% /capture %}} {{% capture body %}} @@ -53,14 +55,16 @@ PodTemplateList, not Pod Template List. Refer to API objects without saying "object," unless omitting "object" leads to an awkward construction. - - - - - - - -
DoDon't
The Pod has two containers.The pod has two containers.
The Deployment is responsible for ...The Deployment object is responsible for ...
A PodList is a list of Pods.A Pod List is a list of pods.
The two ContainerPorts ...The two ContainerPort objects ...
The two ContainerStateTerminated objects ...The two ContainerStateTerminateds ...
+{{< table caption = "Do and Don't - API objects" >}} +Do | Don't +:--| :----- +The Pod has two containers. | The pod has two containers. +The Deployment is responsible for ... | The Deployment object is responsible for ... +A PodList is a list of Pods. | A Pod List is a list of pods. +The two ContainerPorts ... | The two ContainerPort objects ... +The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ... +{{< /table >}} + ### Use angle brackets for placeholders @@ -75,36 +79,40 @@ represents. ### Use bold for user interface elements - - - - -
DoDon't
Click Fork.Click "Fork".
Select Other.Select 'Other'.
+{{< table caption = "Do and Don't - Bold interface elements" >}} +Do | Don't +:--| :----- +Click **Fork**. | Click "Fork". +Select **Other**. | Select "Other". +{{< /table >}} ### Use italics to define or introduce new terms - - - - - -
DoDon't
A cluster is a set of nodes ...A "cluster" is a set of nodes ...
These components form the control plane.These components form the control plane.
+ +{{< table caption = "Do and Don't - Use italics for new terms" >}} +Do | Don't +:--| :----- +A _cluster_ is a set of nodes ... | A "cluster" is a set of nodes ... +These components form the _control plane_. | These components form the **control plane**. +{{< /table >}} ### Use code style for filenames, directories, and paths - - - - - -
DoDon't
Open the envars.yaml file.Open the envars.yaml file.
Go to the /docs/tutorials directory.Go to the /docs/tutorials directory.
Open the /_data/concepts.yaml file.Open the /_data/concepts.yaml file.
+{{< table caption = "Do and Don't - Use code style for filenames, directories, and paths" >}} +Do | Don't +:--| :----- +Open the `envars.yaml` file. | Open the envars.yaml file. +Go to the `/docs/tutorials` directory. | Go to the /docs/tutorials directory. +Open the `/_data/concepts.yaml` file. | Open the /_data/concepts.yaml file. +{{< /table >}} ### Use the international standard for punctuation inside quotes - - - - -
DoDon't
events are recorded with an associated "stage".events are recorded with an associated "stage."
The copy is called a "fork".The copy is called a "fork."
+{{< table caption = "Do and Don't - Use the international standard for punctuation inside quotes" >}} +Do | Don't +:--| :----- +events are recorded with an associated "stage". | events are recorded with an associated "stage." +The copy is called a "fork". | The copy is called a "fork." +{{< /table >}} ## Inline code formatting @@ -113,13 +121,17 @@ represents. For inline code in an HTML document, use the `` tag. In a Markdown document, use the backtick (`). - - - - - - -
DoDon't
The kubectl run command creates a Deployment.The "kubectl run" command creates a Deployment.
For declarative management, use kubectl apply.For declarative management, use "kubectl apply".
Enclose code samples with triple backticks. (```)Enclose code samples with any other syntax.
Use single backticks to enclose inline code. For example, `var example = true`.Use two asterisks (**) or an underscore (_) to enclose inline code. For example, **var example = true**.
Use triple backticks before and after a multi-line block of code for fenced code blocks.Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations.
Use meaningful variable names that have a context.Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context.
Remove trailing spaces in the code.Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well.
+{{< table caption = "Do and Don't - Use code style for inline code and commands" >}} +Do | Don't +:--| :----- +The `kubectl run`command creates a Deployment. | The "kubectl run" command creates a Deployment. +For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply". +Enclose code samples with triple backticks. `(```)`| Enclose code samples with any other syntax. +Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (**) or an underscore (_) to enclose inline code. For example, **var example = true**. +Use triple backticks before and after a multi-line block of code for fenced code blocks. | Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations. +Use meaningful variable names that have a context. | Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context. +Remove trailing spaces in the code. | Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well. +{{< /table >}} {{< note >}} The website supports syntax highlighting for code samples, but specifying a language is optional. Syntax highlighting in the code block should conform to the [contrast guidelines.](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=141%2C143#contrast-minimum) @@ -127,31 +139,36 @@ The website supports syntax highlighting for code samples, but specifying a lang ### Use code style for object field names - - - - -
DoDon't
Set the value of the replicas field in the configuration file.Set the value of the "replicas" field in the configuration file.
The value of the exec field is an ExecAction object.The value of the "exec" field is an ExecAction object.
+{{< table caption = "Do and Don't - Use code style for object field names" >}} +Do | Don't +:--| :----- +Set the value of the `replicas` field in the configuration file. | Set the value of the "replicas" field in the configuration file. +The value of the `exec` field is an ExecAction object. | The value of the "exec" field is an ExecAction object. +{{< /table >}} ### Use normal style for string and integer field values For field values of type string or integer, use normal style without quotation marks. - - - - - -
DoDon't
Set the value of imagePullPolicy to Always.Set the value of imagePullPolicy to "Always".
Set the value of image to nginx:1.8.Set the value of image to nginx:1.8.
Set the value of the replicas field to 2.Set the value of the replicas field to 2.
+{{< table caption = "Do and Don't - Use normal style for string and integer field values" >}} +Do | Don't +:--| :----- +Set the value of `imagePullPolicy` to Always. | Set the value of `imagePullPolicy` to "Always". +Set the value of `image` to nginx:1.8. | Set the value of `image` to `nginx:1.8`. +Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`. +{{< /table >}} + ## Code snippet formatting ### Don't include the command prompt - - - -
DoDon't
kubectl get pods$ kubectl get pods
+{{< table caption = "Do and Don't - Don't include the command prompt" >}} +Do | Don't +:--| :----- +kubectl get pods | $ kubectl get pods +{{< /table >}} + ### Separate commands from output @@ -198,13 +215,14 @@ kind: Pod A list of Kubernetes-specific terms and words to be used consistently across the site. - - - - - - -
TermUsage
KubernetesKubernetes should always be capitalized.
DockerDocker should always be capitalized.
SIG DocsSIG Docs rather than SIG-DOCS or other variations.
On-premisesOn-premises or On-prem rather than On-premise or other variations.
+{{< table caption = "Kubernetes.io word list" >}} +Term | Usage +:--- | :---- +Kubernetes | Kubernetes should always be capitalized. +Docker | Docker should always be capitalized. +SIG Docs | SIG Docs rather than SIG-DOCS or other variations. +On-premises | On-premises or On-prem rather than On-premise or other variations. +{{< /table >}} ## Shortcodes @@ -377,26 +395,33 @@ Use a single newline to separate block-level content like headings, lists, image ### Headings People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest. - - - - - -
DoDon't
Update the title in the front matter of the page or blog post.Use first level heading, as Hugo automatically converts the title in the front matter of the page into a first-level heading.
Use ordered headings to provide a meaningful high-level outline of your content.Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles.
Use pound or hash signs (#) for non-blog post content. Use underlines (--- or ===) to designate first-level headings.
Use sentence case for headings. For example, Extend kubectl with pluginsUse title case for headings. For example, Extend Kubectl With Plugins
+{{< table caption = "Do and Don't - Headings" >}} +Do | Don't +:--| :----- +Update the title in the front matter of the page or blog post. | Use first level heading, as Hugo automatically converts the title in the front matter of the page into a first-level heading. +Use ordered headings to provide a meaningful high-level outline of your content. | Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles. +Use pound or hash signs (#) for non-blog post content. | Use underlines (--- or ===) to designate first-level headings. +Use sentence case for headings. For example, **Extend kubectl with plugins** | Use title case for headings. For example, **Extend Kubectl With Plugins** +{{< /table >}} ### Paragraphs - - - - -
DoDon't
Try to keep paragraphs under 6 sentences.Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it.
Use three hyphens (---) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section.Use horizontal rules for decoration.
+{{< table caption = "Do and Don't - Paragraphs" >}} +Do | Don't +:--| :----- +Try to keep paragraphs under 6 sentences. | Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it. +Use three hyphens (---) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section. | Use horizontal rules for decoration. +{{< /table >}} ### Links - - - -
DoDon't
Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See Check required ports for more details.Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See here for more details.
Write Markdown-style links ([link text](URL)). For example, [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions) and the output is Hugo shortcodes.Write HTML-style links (<link href="/media/examples/link-element-example.css" target="_blank">Visit our tutorial!) or create links that open in new tabs or windows. For example, [example website](https://example.com){target="_blank"}
+ +{{< table caption = "Do and Don't - Links" >}} +Do | Don't +:--| :----- +Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See Check required ports for more details. | Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See here for more details. +Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)` and the output is [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions). | Write HTML-style links: `Visit our tutorial!`, or create links that open in new tabs or windows. For example: `[example website](https://example.com){target="_blank"}` +{{< /table >}} + ### Lists Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list. @@ -428,21 +453,25 @@ This section contains suggested best practices for clear, concise, and consisten ### Use present tense - - - -
DoDon't
This command starts a proxy.This command will start a proxy.
+{{< table caption = "Do and Don't - Use present tense" >}} +Do | Don't +:--| :----- +This command starts a proxy. | This command will start a proxy. + {{< /table >}} + Exception: Use future or past tense if it is required to convey the correct meaning. ### Use active voice - - - - -
DoDon't
You can explore the API using a browser.The API can be explored using a browser.
The YAML file specifies the replica count.The replica count is specified in the YAML file.
+{{< table caption = "Do and Don't - Use active voice" >}} +Do | Don't +:--| :----- +You can explore the API using a browser. | The API can be explored using a browser. +The YAML file specifies the replica count. | The replica count is specified in the YAML file. +{{< /table >}} + Exception: Use passive voice if active voice leads to an awkward construction. @@ -450,31 +479,35 @@ Exception: Use passive voice if active voice leads to an awkward construction. Use simple and direct language. Avoid using unnecessary phrases, such as saying "please." - - - - - - -
DoDon't
To create a ReplicaSet, ...In order to create a ReplicaSet, ...
See the configuration file.Please see the configuration file.
View the Pods.With this next command, we'll view the Pods.
+{{< table caption = "Do and Don't - Use simple and direct language" >}} +Do | Don't +:--| :----- +To create a ReplicaSet, ... | In order to create a ReplicaSet, ... +See the configuration file. | Please see the configuration file. +View the Pods. | With this next command, we'll view the Pods. +{{< /table >}} ### Address the reader as "you" - - - - -
DoDon't
You can create a Deployment by ...We'll create a Deployment by ...
In the preceding output, you can see...In the preceding output, we can see ...
+{{< table caption = "Do and Don't - Addressing the reader" >}} +Do | Don't +:--| :----- +You can create a Deployment by ... | We'll create a Deployment by ... +In the preceding output, you can see... | In the preceding output, we can see ... +{{< /table >}} + ### Avoid Latin phrases Prefer English terms over Latin abbreviations. - - - - -
DoDon't
For example, ...e.g., ...
That is, ...i.e., ...
+{{< table caption = "Do and Don't - Avoid Latin phrases" >}} +Do | Don't +:--| :----- +For example, ... | e.g., ... +That is, ...| i.e., ... +{{< /table >}} + Exception: Use "etc." for et cetera. @@ -485,22 +518,26 @@ Exception: Use "etc." for et cetera. Using "we" in a sentence can be confusing, because the reader might not know whether they're part of the "we" you're describing. - - - - - -
DoDon't
Version 1.4 includes ...In version 1.4, we have added ...
Kubernetes provides a new feature for ...We provide a new feature ...
This page teaches you how to use Pods.In this page, we are going to learn about Pods.
+{{< table caption = "Do and Don't - Patterns to avoid" >}} +Do | Don't +:--| :----- +Version 1.4 includes ... | In version 1.4, we have added ... +Kubernetes provides a new feature for ... | We provide a new feature ... +This page teaches you how to use Pods. | In this page, we are going to learn about Pods. +{{< /table >}} + ### Avoid jargon and idioms Some readers speak English as a second language. Avoid jargon and idioms to help them understand better. - - - - -
DoDon't
Internally, ...Under the hood, ...
Create a new cluster.Turn up a new cluster.
+{{< table caption = "Do and Don't - Avoid jargon and idioms" >}} +Do | Don't +:--| :----- +Internally, ... | Under the hood, ... +Create a new cluster. | Turn up a new cluster. +{{< /table >}} + ### Avoid statements about the future @@ -513,11 +550,13 @@ information. Avoid words like "currently" and "new." A feature that is new today might not be considered new in a few months. - - - - -
DoDon't
In version 1.4, ...In the current version, ...
The Federation feature provides ...The new Federation feature provides ...
+{{< table caption = "Do and Don't - Avoid statements that will soon be out of date" >}} +Do | Don't +:--| :----- +In version 1.4, ... | In the current version, ... +The Federation feature provides ... | The new Federation feature provides ... +{{< /table >}} + {{% /capture %}} diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md index 98f70cc7d4..8a5d7949e4 100644 --- a/content/en/docs/contribute/style/write-new-topic.md +++ b/content/en/docs/contribute/style/write-new-topic.md @@ -19,24 +19,13 @@ Create a fork of the Kubernetes documentation repository as described in As you prepare to write a new topic, think about the page type that would fit your content the best: - - - - - - - - - - - - - - - - - -
ConceptA concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see Nodes.
TaskA task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see Configure a Pod to Use a Volume for Storage. For an example of a longer task page, see Configure Liveness and Readiness Probes
TutorialA tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.
+{{< table caption = "Guidelines for choosing a page type" >}} +Type | Description +:--- | :---------- +Concept | A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see Nodes. +Task | A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see Configure a Pod to Use a Volume for Storage. For an example of a longer task page, see Configure Liveness and Readiness Probes +Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features. +{{< /table >}} Use a template for each new page. Each page type has a [template](/docs/contribute/style/page-templates/) diff --git a/content/en/docs/getting-started-guides/OWNERS b/content/en/docs/getting-started-guides/OWNERS deleted file mode 100644 index fecf081d73..0000000000 --- a/content/en/docs/getting-started-guides/OWNERS +++ /dev/null @@ -1,5 +0,0 @@ -# See the OWNERS docs at https://go.k8s.io/owners - -reviewers: -- errordeveloper - diff --git a/content/en/docs/getting-started-guides/_index.md b/content/en/docs/getting-started-guides/_index.md deleted file mode 100755 index 0e925b92bd..0000000000 --- a/content/en/docs/getting-started-guides/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Independent Solutions" -weight: 50 ---- - diff --git a/content/en/docs/getting-started-guides/alternatives.md b/content/en/docs/getting-started-guides/alternatives.md deleted file mode 100644 index 7fcef3f3f1..0000000000 --- a/content/en/docs/getting-started-guides/alternatives.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -reviewers: -- pwittrock -title: Deprecated Alternatives ---- - -# *Stop. These guides are superseded by [Minikube](../minikube/). They are only listed here for completeness.* - -* [Using Vagrant](https://git.k8s.io/community/contributors/devel/vagrant.md) -* *Advanced:* [Directly using Kubernetes raw binaries (Linux Only)](https://git.k8s.io/community/contributors/devel/running-locally.md) \ No newline at end of file diff --git a/content/en/docs/getting-started-guides/fedora/OWNERS b/content/en/docs/getting-started-guides/fedora/OWNERS deleted file mode 100644 index 67c11df3a5..0000000000 --- a/content/en/docs/getting-started-guides/fedora/OWNERS +++ /dev/null @@ -1,7 +0,0 @@ -# See the OWNERS docs at https://go.k8s.io/owners - -reviewers: -- aveshagarwal -- eparis -- thockin - diff --git a/content/en/docs/getting-started-guides/fedora/_index.md b/content/en/docs/getting-started-guides/fedora/_index.md deleted file mode 100755 index d8a5bb38a0..0000000000 --- a/content/en/docs/getting-started-guides/fedora/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Bare Metal" -weight: 60 ---- - diff --git a/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md b/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md deleted file mode 100644 index 887f362798..0000000000 --- a/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -reviewers: -- aveshagarwal -- eparis -- thockin -title: Fedora (Single Node) ---- - -{{< toc >}} - -## Prerequisites - -1. You need 2 or more machines with Fedora installed. These can be either bare metal machines or virtual machines. - -## Instructions - -This is a getting started guide for Fedora. It is a manual configuration so you understand all the underlying packages / services / ports, etc... - -This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](/docs/concepts/cluster-administration/networking/) done outside of Kubernetes. Although the additional Kubernetes configuration requirements should be obvious. - -The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: `/etc/kubernetes`. We will break the services up between the hosts. The first host, fed-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_ (not needed if _etcd_ runs on a different host but this guide assumes that _etcd_ and Kubernetes master run on the same host). The remaining host, fed-node will be the node and run kubelet, proxy and docker. - -**System Information:** - -Hosts: - -```conf -fed-master = 192.168.121.9 -fed-node = 192.168.121.65 -``` - -**Prepare the hosts:** - -* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with Kubernetes-0.18 and beyond. -* Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the `enable=0` to `enable=1` for extras. - -```shell -dnf -y install kubernetes -``` - -* Install etcd - -```shell -dnf -y install etcd -``` - -* Add master and node to `/etc/hosts` on all machines (not needed if hostnames already in DNS). Make sure that communication works between fed-master and fed-node by using a utility such as ping. - -```shell -echo "192.168.121.9 fed-master -192.168.121.65 fed-node" >> /etc/hosts -``` - -* Edit `/etc/kubernetes/config` (which should be the same on all hosts) to set -the name of the master server: - -```shell -# Comma separated list of nodes in the etcd cluster -KUBE_MASTER="--master=http://fed-master:8080" -``` - -* Disable the firewall on both the master and node, as Docker does not play well with other firewall rule managers. Please note that iptables.service does not exist on the default Fedora Server install. - -```shell -systemctl mask firewalld.service -systemctl stop firewalld.service - -systemctl disable --now iptables.service -``` - -**Configure the Kubernetes services on the master.** - -* Edit `/etc/kubernetes/apiserver` to appear as such. The service-cluster-ip-range IP addresses must be an unused block of addresses, not used anywhere else. They do not need to be routed or assigned to anything. - -```shell -# The address on the local server to listen to. -KUBE_API_ADDRESS="--address=0.0.0.0" - -# Comma separated list of nodes in the etcd cluster -KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:2379" - -# Address range to use for services -KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" - -# Add your own! -KUBE_API_ARGS="" -``` - -* Edit `/etc/etcd/etcd.conf` to let etcd listen on all available IPs instead of 127.0.0.1. If you have not done this, you might see an error such as "connection refused". - -```shell -ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379" -``` - -* Start the appropriate services on master: - -```shell -for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do - systemctl enable --now $SERVICES - systemctl status $SERVICES -done -``` - -**Configure the Kubernetes services on the node.** - -***We need to configure the kubelet on the node.*** - -* Edit `/etc/kubernetes/kubelet` to appear as such: - -```shell -### -# Kubernetes kubelet (node) config - -# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces) -KUBELET_ADDRESS="--address=0.0.0.0" - -# You may leave this blank to use the actual hostname -KUBELET_HOSTNAME="--hostname-override=fed-node" - -# location of the api-server -KUBELET_ARGS="--cgroup-driver=systemd --kubeconfig=/etc/kubernetes/master-kubeconfig.yaml" - -``` - -* Edit `/etc/kubernetes/master-kubeconfig.yaml` to contain the following information: - -```yaml -kind: Config -clusters: -- name: local - cluster: - server: http://fed-master:8080 -users: -- name: kubelet -contexts: -- context: - cluster: local - user: kubelet - name: kubelet-context -current-context: kubelet-context -``` - -* Start the appropriate services on the node (fed-node). - -```shell -for SERVICES in kube-proxy kubelet docker; do - systemctl enable --now $SERVICES - systemctl status $SERVICES -done -``` - -* Check to make sure now the cluster can see the fed-node on fed-master, and its status changes to _Ready_. - -```shell -kubectl get nodes -NAME STATUS AGE VERSION -fed-node Ready 4h -``` - -* Deletion of nodes: - -To delete _fed-node_ from your Kubernetes cluster, one should run the following on fed-master (Please do not do it, it is just for information): - -```shell -kubectl delete -f ./node.json -``` - -*You should be finished!* - -**The cluster should be running! Launch a test pod.** - -## Support Level - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config) | | Project diff --git a/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md b/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md deleted file mode 100644 index 88ef0615fd..0000000000 --- a/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md +++ /dev/null @@ -1,196 +0,0 @@ ---- -reviewers: -- dchen1107 -- erictune -- thockin -title: Fedora (Multi Node) ---- - -{{< toc >}} - -This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/docs/getting-started-guides/fedora/fedora_manual_config/) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. Flannel on each node configures an overlay network that docker uses. Flannel runs on each node to setup a unique class-C container network. - -## Prerequisites - -You need 2 or more machines with Fedora installed. - -## Master Setup - -**Perform following commands on the Kubernetes master** - -* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. Flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are: - -```json -{ - "Network": "18.16.0.0/16", - "SubnetLen": 24, - "Backend": { - "Type": "vxlan", - "VNI": 1 - } -} -``` - -{{< note >}} -Choose an IP range that is *NOT* part of the public IP address range. -{{< /note >}} - -Add the configuration to the etcd server on fed-master. - -```shell -etcdctl set /coreos.com/network/config < flannel-config.json -``` - -* Verify that the key exists in the etcd server on fed-master. - -```shell -etcdctl get /coreos.com/network/config -``` - -## Node Setup - -**Perform following commands on all Kubernetes nodes** - -Install the flannel package - -```shell -# dnf -y install flannel -``` - -Edit the flannel configuration file /etc/sysconfig/flanneld as follows: - -```shell -# Flanneld configuration options - -# etcd url location. Point this to the server where etcd runs -FLANNEL_ETCD="http://fed-master:2379" - -# etcd config key. This is the configuration key that flannel queries -# For address range assignment -FLANNEL_ETCD_KEY="/coreos.com/network" - -# Any additional options that you want to pass -FLANNEL_OPTIONS="" -``` - -{{< note >}} -By default, flannel uses the interface for the default route. If you have multiple interfaces and would like to use an interface other than the default route one, you could add "-iface=" to FLANNEL_OPTIONS. For additional options, run `flanneld --help` on command line. -{{< /note >}} - -Enable the flannel service. - -```shell -systemctl enable flanneld -``` - -If docker is not running, then starting flannel service is enough and skip the next step. - -```shell -systemctl start flanneld -``` - -If docker is already running, then stop docker, delete docker bridge (docker0), start flanneld and restart docker as follows. Another alternative is to just reboot the system (`systemctl reboot`). - -```shell -systemctl stop docker -ip link delete docker0 -systemctl start flanneld -systemctl start docker -``` - - -## Test the cluster and flannel configuration - -Now check the interfaces on the nodes. Notice there is now a flannel.1 interface, and the ip addresses of docker0 and flannel.1 interfaces are in the same network. You will notice that docker0 is assigned a subnet (18.16.29.0/24 as shown below) on each Kubernetes node out of the IP range configured above. A working output should look like this: - -```shell -# ip -4 a|grep inet - inet 127.0.0.1/8 scope host lo - inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic eth0 - inet 18.16.29.0/16 scope global flannel.1 - inet 18.16.29.1/24 scope global docker0 -``` - -From any node in the cluster, check the cluster members by issuing a query to etcd server via curl (only partial output is shown using `grep -E "\{|\}|key|value"`). If you set up a 1 master and 3 nodes cluster, you should see one block for each node showing the subnets they have been assigned. You can associate those subnets to each node by the MAC address (VtepMAC) and IP address (Public IP) that is listed in the output. - -```shell -curl -s http://fed-master:2379/v2/keys/coreos.com/network/subnets | python -mjson.tool -``` - -```json -{ - "node": { - "key": "/coreos.com/network/subnets", - { - "key": "/coreos.com/network/subnets/18.16.29.0-24", - "value": "{\"PublicIP\":\"192.168.122.77\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"46:f1:d0:18:d0:65\"}}" - }, - { - "key": "/coreos.com/network/subnets/18.16.83.0-24", - "value": "{\"PublicIP\":\"192.168.122.36\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"ca:38:78:fc:72:29\"}}" - }, - { - "key": "/coreos.com/network/subnets/18.16.90.0-24", - "value": "{\"PublicIP\":\"192.168.122.127\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"92:e2:80:ba:2d:4d\"}}" - } - } -} -``` - -From all nodes, review the `/run/flannel/subnet.env` file. This file was generated automatically by flannel. - -```shell -# cat /run/flannel/subnet.env -FLANNEL_SUBNET=18.16.29.1/24 -FLANNEL_MTU=1450 -FLANNEL_IPMASQ=false -``` - -At this point, we have etcd running on the Kubernetes master, and flannel / docker running on Kubernetes nodes. Next steps are for testing cross-host container communication which will confirm that docker and flannel are configured properly. - -Issue the following commands on any 2 nodes: - -```shell -# docker run -it fedora:latest bash -bash-4.3# -``` - -This will place you inside the container. Install iproute and iputils packages to install ip and ping utilities. Due to a [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1142311), it is required to modify capabilities of ping binary to work around "Operation not permitted" error. - -```shell -bash-4.3# dnf -y install iproute iputils -bash-4.3# setcap cap_net_raw-ep /usr/bin/ping -``` - -Now note the IP address on the first node: - -```shell -bash-4.3# ip -4 a l eth0 | grep inet - inet 18.16.29.4/24 scope global eth0 -``` - -And also note the IP address on the other node: - -```shell -bash-4.3# ip a l eth0 | grep inet - inet 18.16.90.4/24 scope global eth0 -``` -Now ping from the first node to the other node: - -```shell -bash-4.3# ping 18.16.90.4 -PING 18.16.90.4 (18.16.90.4) 56(84) bytes of data. -64 bytes from 18.16.90.4: icmp_seq=1 ttl=62 time=0.275 ms -64 bytes from 18.16.90.4: icmp_seq=2 ttl=62 time=0.372 ms -``` - -Now Kubernetes multi-node cluster is set up with overlay networking set up by flannel. - -## Support Level - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) diff --git a/content/en/docs/getting-started-guides/ubuntu.md b/content/en/docs/getting-started-guides/ubuntu.md deleted file mode 100644 index 733e8d1d1f..0000000000 --- a/content/en/docs/getting-started-guides/ubuntu.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Kubernetes on Ubuntu -content_template: templates/concept ---- - -{{% capture overview %}} -There are multiple ways to run a Kubernetes cluster with Ubuntu on public and -private clouds, as well as bare metal. -{{% /capture %}} - -{{% capture body %}} -## The Charmed Distribution of Kubernetes(CDK) - -[CDK](https://www.ubuntu.com/cloud/kubernetes) is a distribution of Kubernetes -packaged as a bundle of *charms* for Juju, the open source application modeller. - -CDK is the latest version of Kubernetes with upstream binaries, packaged in a format -which makes it fast and easy to deploy. It supports various public -and private clouds including AWS, GCE, Azure, Joyent, OpenStack, VMware, Bare Metal -and localhost deployments. - -See the [Official documentation](https://www.ubuntu.com/kubernetes/docs) for -more information. - -## MicroK8s - -[MicroK8s](https://microk8s.io) is a minimal install of Kubernetes designed to run locally. -It can be installed on Ubuntu (or any snap enabled operating system) with the command: - -```shell -snap install microk8s --classic -``` - -Full documentation is available on the [MicroK8s website](https://microk8s.io/docs) - - - - - - -{{% /capture %}} diff --git a/content/en/docs/reference/access-authn-authz/abac.md b/content/en/docs/reference/access-authn-authz/abac.md index 287f85bad2..40c56a985c 100644 --- a/content/en/docs/reference/access-authn-authz/abac.md +++ b/content/en/docs/reference/access-authn-authz/abac.md @@ -8,10 +8,6 @@ title: Using ABAC Authorization content_template: templates/concept weight: 80 --- -{{< note >}} -{{< feature-state state="deprecated" for_k8s_version="1.6" >}} -The ABAC Authorization feature has been considered deprecated from the Kubernetes 1.6 release. -{{< /note >}} {{% capture overview %}} Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 76be84b769..fd31a45c97 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -75,6 +75,7 @@ different Kubernetes components. | `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 | | `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 | | `CustomPodDNS` | `true` | GA | 1.14 | - | +| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | | | `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 | | `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | | | `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.11 | @@ -117,6 +118,7 @@ different Kubernetes components. | `KubeletPluginsWatcher` | `true` | GA | 1.13 | - | | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | +| `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | | | `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha| 1.15 | | @@ -124,6 +126,7 @@ different Kubernetes components. | `MountPropagation` | `false` | Alpha | 1.8 | 1.9 | | `MountPropagation` | `true` | Beta | 1.10 | 1.11 | | `MountPropagation` | `true` | GA | 1.12 | | +| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | | | `NodeLease` | `false` | Alpha | 1.12 | 1.13 | | `NodeLease` | `true` | Beta | 1.14 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | | @@ -274,6 +277,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property. Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config) for more details. +- `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas. - `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs. - `CustomResourceSubresources`: Enable `/status` and `/scale` subresources on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/). @@ -314,11 +318,13 @@ Each feature gate is designed for enabling/disabling a specific feature: to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi). - `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint. See [Support Device Monitoring](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md) for more details. +- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels. - `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir). - `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy. - `MountContainers`: Enable using utility containers on host as the volume mounter. - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods. For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation). +- `NodeDisruptionExclusion`: Enable use of the node label `node.kubernetes.io/exclude-disruption` which prevents nodes from being evacuated during zone failures. - `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal. - `NonPreemptingPriority`: Enable NonPreempting option for PriorityClass and Pod. - `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods. @@ -352,7 +358,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server. - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers. - `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider. - A node is eligible for exclusion if annotated with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key. + A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key (when `LegacyNodeRoleBehavior` is on) or `node.kubernetes.io/exclude-from-external-load-balancers`. - `StartupProbe`: Enable the [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) probe in the kubelet. - `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or PersistentVolumeClaim objects if they are still being used. diff --git a/content/en/docs/reference/glossary/applications.md b/content/en/docs/reference/glossary/applications.md index 33901436be..f097c05620 100644 --- a/content/en/docs/reference/glossary/applications.md +++ b/content/en/docs/reference/glossary/applications.md @@ -5,7 +5,6 @@ date: 2019-05-12 full_link: short_description: > The layer where various containerized applications run. - aka: tags: - fundamental diff --git a/content/en/docs/reference/glossary/static-pod.md b/content/en/docs/reference/glossary/static-pod.md index b633aee0f2..dc77a035cc 100755 --- a/content/en/docs/reference/glossary/static-pod.md +++ b/content/en/docs/reference/glossary/static-pod.md @@ -2,13 +2,17 @@ title: Static Pod id: static-pod date: 2019-02-12 -full_link: /docs/tasks/administer-cluster/static-pod/ +full_link: /docs/tasks/configure-pod-container/static-pod/ short_description: > - A pod managed directly by kubelet daemon on a specific node + A pod managed directly by the kubelet daemon on a specific node. aka: tags: - fundamental --- - A {{< glossary_tooltip text="pod" term_id="pod" >}} managed directly by the kubelet - daemon on a specific node, without the API server observing it. + +A {{< glossary_tooltip text="pod" term_id="pod" >}} managed directly by the kubelet + daemon on a specific node, + + +without the API server observing it. \ No newline at end of file diff --git a/content/en/docs/reference/glossary/workload.md b/content/en/docs/reference/glossary/workload.md index 966703fcd4..f2fabbab77 100644 --- a/content/en/docs/reference/glossary/workload.md +++ b/content/en/docs/reference/glossary/workload.md @@ -1,28 +1,22 @@ --- -title: Workloads +title: Workload id: workloads date: 2019-02-13 full_link: /docs/concepts/workloads/ short_description: > - Workloads are objects you use to manage and run your containers on the cluster. + A workload is an application running on Kubernetes. aka: tags: - fundamental -- core-object -- workload --- - Workloads are objects you use to manage and run your containers on the cluster. + A workload is an application running on Kubernetes. -Kubernetes performs the -deployment and updates the workload with the current state of the application. -Workloads include the DaemonSet, Deployments, Jobs, Pods, ReplicaSet, ReplicationController, and StatefulSet objects. - -For example, a workload that has a web element and a database element might run the -database in one {{< glossary_tooltip term_id="StatefulSet" >}} of -{{< glossary_tooltip text="pods" term_id="pod" >}} and the webserver via -a {{< glossary_tooltip term_id="Deployment" >}} that consists of many web app -{{< glossary_tooltip text="pods" term_id="pod" >}}, all alike. +Various core objects that represent different types or parts of a workload +include the DaemonSet, Deployment, Job, ReplicaSet, and StatefulSet objects. +For example, a workload that has a web server and a database might run the +database in one {{< glossary_tooltip term_id="StatefulSet" >}} and the web server +in a {{< glossary_tooltip term_id="Deployment" >}}. diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index b61c5286f5..37ea821daa 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -82,7 +82,7 @@ The following production environment solutions table lists the providers and the | [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ | [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ | [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ -| [Gardener](https://gardener.cloud/) | |✔ | | ✔ | | +| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ (via OpenStack) | ✔ | | | [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | | | [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | | [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | @@ -109,5 +109,6 @@ The following production environment solutions table lists the providers and the | [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ | | [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | | [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) +| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | | {{% /capture %}} diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md index 99501c8d1a..57de8cd47a 100644 --- a/content/en/docs/setup/release/version-skew-policy.md +++ b/content/en/docs/setup/release/version-skew-policy.md @@ -28,8 +28,8 @@ The Kubernetes project maintains release branches for the most recent three mino Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. Patch releases are cut from those branches at a regular cadence, or as needed. -This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/patch-release-manager/README.md#release-timing). -The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/releases/). +This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing). +The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/release-team). Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months. @@ -37,7 +37,7 @@ Minor releases occur approximately every 3 months, so each minor release branch ### kube-apiserver -In [highly-available (HA) clusters](/docs/setup/production-environment/tools/independent/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version. +In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version. Example: @@ -120,7 +120,7 @@ Upgrade `kube-apiserver` to **1.(n+1)** {{< note >}} Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and -[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md) +[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters. {{< /note >}} diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 12c8d7165d..9312ccf395 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -30,7 +30,7 @@ Dashboard also provides information on the state of Kubernetes resources in your The Dashboard UI is not deployed by default. To deploy it, run the following command: ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta4/aio/deploy/recommended.yaml ``` ## Accessing the Dashboard UI diff --git a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md index 3947b64a28..83924865c5 100644 --- a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md +++ b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md @@ -36,7 +36,7 @@ may be disabled by setting `--feature-gates=PodShareProcessNamespace=false`. ## Configure a Pod -Process Namespace Sharing is enabled using the `ShareProcessNamespace` field of +Process Namespace Sharing is enabled using the `shareProcessNamespace` field of `v1.PodSpec`. For example: {{< codenew file="pods/share-process-namespace.yaml" >}} diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 5b72f04643..8b8571ca0b 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -490,6 +490,18 @@ let users route data where they want. For example, users can emit audit events t plugin which supports full-text search and analytics. +[kube-apiserver]: /docs/admin/kube-apiserver +[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md +[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go +[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 +[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ +[fluentd]: http://www.fluentd.org/ +[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd +[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management +[logstash]: https://www.elastic.co/products/logstash +[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html +[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation + {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/en/examples/service/access/Dockerfile b/content/en/examples/service/access/Dockerfile index 7de606a642..b7b09d492a 100644 --- a/content/en/examples/service/access/Dockerfile +++ b/content/en/examples/service/access/Dockerfile @@ -1,4 +1,4 @@ -FROM nginx:1.9.14 +FROM nginx:1.17.3 RUN rm /etc/nginx/conf.d/default.conf COPY frontend.conf /etc/nginx/conf.d diff --git a/content/es/docs/concepts/containers/container-lifecycle-hooks.md b/content/es/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000..2d5763476a --- /dev/null +++ b/content/es/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,120 @@ +--- +title: Container Lifecycle Hooks +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Esta página describe como los contenedores gestionados por kubelet pueden utilizar el framework _Container lifecycle hook_ (hook del ciclo de vida del contenedor) +para ejecutar código disparado por eventos durante la gestión de su ciclo de vida (lifecycle). + +{{% /capture %}} + + +{{% capture body %}} + +## Introducción + +De manera análoga a muchos frameworks de lenguajes de programación que tienen componentes hooks de lifecycle, como Angular, +Kubernetes también proporciona esta funcionalidad para los contenedores. +Los hooks permiten a los contenedores conocer los eventos en su gestión de ciclo de vida +y ejecutar el código implementado en un controlador cuando el hook de ciclo de vida correspondiente es ejecutado. + +## Hooks de contenedores + +Hay dos hooks expuestos en los contenedores: + +`PostStart` + +Este hook se ejecuta inmediatamente después de crear un contenedor. +Sin embargo, no es posible garantizar que el hook se ejecute antes del ENTRYPOINT del contenedor. +No se le pasa ningún parámetro. + +`PreStop` + +Este hook se llama inmediatamente antes de que se finalice un contenedor debido a una solicitud de API o evento de gestión como un fallo liveness, o contención de recursos entre otros. Una llamada al hook de Prestop falla si el contenedor ya está en estado terminated (finalizado) o completed (completado). +Es bloqueante, lo que significa que es sincrónico, +por lo que debe completarse antes de que la llamada para eliminar el contenedor pueda ser enviada. +No se le pasa ningún parámetro. + +Puedes encontrar información más detallada sobre el comportamiento de finalización de un contenedor +[Finalización de Pods](/docs/es/concepts/workloads/pods/pod/#termination-of-pods). + +### Implementación de controladores de hooks + +Los contenedores pueden acceder a un hook implementando y registrado en un controlador de este hook. +Hay dos tipos de controladores de hooks que se pueden implementar para los contenedores: + +* Exec: ejecuta un comando específico, como `pre-stop.sh`, dentro de cgroups y namespaces del contenedor. +Los recursos consumidos por el comando serán tomados en cuenta para el contenedor. +* HTTP: ejecuta una petición HTTP contra un endpoint específico dentro del contenedor. + +### Ejecución de controladores de hooks + +Cuando se llama un hook de gestión de ciclo de vida de un contenedor, +el sistema de gestión de Kubernetes ejecuta el controlador en el contenedor registrado para este hook. + +Las llamadas al controlador de hooks son síncronas dentro del contexto del Pod que contiene el contenedor. +Esto significa que para un hook `PostStart`, +el ENTRYPOINT del contenedor y el hook se disparan de forma asíncrona. +Sin embargo, si el hook tarda demasiado en ejecutarse o se cuelga, +el contenedor no puede alcanzar el estado de `running` (en ejecución). + +El comportamiento es similar para un hook `PreStop`. +Si el hook se cuelga durante la ejecución, +la fase del Pod permanece en un estado de `terminating` (finalizando) y se cancela después del `terminationGracePeriodSeconds` (finalización después del periodo de gracia) del pod en cuestión. +Si un hook `PostStart` o` PreStop` falla, se mata el contenedor. + +Los usuarios deben hacer que sus controladores de hooks sean lo más livianos posible. +Hay casos, sin embargo, que los comandos de larga ejecución tienen sentido, +como cuando se guarda el estado antes de detener un contenedor. + +### Garantías de entrega de hooks + +La entrega de un hook está destinada a ser enviada *al menos una vez*, +lo que significa que un hook puede ser llamado varias veces para cualquier evento dado, +tanto para `PostStart` como para ` PreStop`. +Depende de la implementación del hook manejar esto correctamente. + +En general, solo se realizan entregas individuales. +Si, por ejemplo, un receptor hook HTTP está inactivo y no puede recibir tráfico, +no hay ningún reintento. +Sin embargo, en algunos casos puede ocurrir una doble entrega. +Por ejemplo, si un Kubelet se reinicia durante la ejecución de envio de un hook, +el hook puede volver a enviarse después de que el kubelet se levante. + + +### Depurando controladores de hooks + +Los logs de un controlador de hooks no son expuestos en los eventos del Pod. +Si un controlador falla por alguna razón, emite un evento. +Para `PostStart`, es el evento `FailedPostStartHook`, +y para `PreStop`, el evento `FailedPreStopHook`. +Puedes ver que eventos están en ejecución con el comando `kubectl describe pod `. +El siguiente ejemplo muestra los eventos en ejecución a través del comando anterior: + +``` +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 + 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 + 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 + 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" + 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* Aprende más sobre [variables de entorno de contenedores](/docs/concepts/containers/container-environment-variables/). +* Practica + [adjuntando controladores a los eventos de lifecycle de los contenedores](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). + +{{% /capture %}} diff --git a/content/es/docs/reference/glossary/kube-proxy.md b/content/es/docs/reference/glossary/kube-proxy.md new file mode 100755 index 0000000000..df2efc923d --- /dev/null +++ b/content/es/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,25 @@ +--- +title: kube-proxy +id: kube-proxy +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-proxy/ +short_description: > + `kube-proxy` es un componente de red que se ejecuta en cada nodo del clúster. + +aka: +tags: +- fundamental +- networking +--- +[kube-proxy](/es/docs/reference/command-line-tools-reference/kube-proxy/) es un +componente de red que se ejecuta en cada uno de los nodos del clúster, implementando +parte del concepto de Kubernetes {{< glossary_tooltip term_id="service">}}. + + + +kube-proxy mantiene las reglas de red en los nodos, permitiendo la +comunicación entre sus Pods desde las sesiones de red dentro o fuera +del clúster. + +kube-proxy usa la capa de filtrado de paquetes del sistema operativo si la hay +y está disponible; de lo contrario, kube-proxy reenvía el tráfico por sí mismo. diff --git a/content/es/docs/reference/glossary/persistent-volume-claim.md b/content/es/docs/reference/glossary/persistent-volume-claim.md new file mode 100755 index 0000000000..246a5be6d5 --- /dev/null +++ b/content/es/docs/reference/glossary/persistent-volume-claim.md @@ -0,0 +1,18 @@ +--- +title: Persistent Volume Claim +id: persistent-volume-claim +date: 2018-04-12 +full_link: /docs/concepts/storage/persistent-volumes/ +short_description: > + Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor. + +aka: +tags: +- core-object +- storage +--- + Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor. + + + +Especifica la cantidad de almacenamiento, cómo acceder a él (sólo lectura, lectura y escritura y/o exclusivo) y qué hacer una vez eliminemos el PersistentVolumeClaim (mantener, reciclar o eliminar). Los detalles sobre almacenamiento están disponibles en la especificación de PersistentVolume. diff --git a/content/fr/community/_index.html b/content/fr/community/_index.html new file mode 100644 index 0000000000..7603accf7c --- /dev/null +++ b/content/fr/community/_index.html @@ -0,0 +1,237 @@ +--- +title: Communauté +layout: basic +cid: community +--- + +
+
+ + +
+ +
+
+

La communauté Kubernetes -- les utilisateurs, les contributeurs ainsi que la culture que nous avons bâtie ensemble -- est l'une des principales raisons de la popularité fulgurante de ce projet open source. Notre culture et nos valeurs continuent de croître et de changer au fur et à mesure que le projet lui-même grandit et change. Nous travaillons tous ensemble à l'amélioration constante du projet et de la façon dont nous y travaillons. +

Nous sommes les personnes qui déposent les problèmes (issues) et les demandes de changements (pull requests), assistent aux réunions de SIG, aux réunions de Kubernetes et la KubeCon, plaident pour son adoption et son innovation, lancent kubectl get pods, et contribuent de mille autres manières toutes aussi vitales. Lisez ce qui suit pour savoir comment vous pouvez vous impliquer et faire partie de cette incroyable communauté.

+
+
+ + +

+
+
+
+ +
+ +
+ +
+ +
+ +
+ + + +
+ + + +
+
+

+

+

Code de Conduite

+La communauté Kubernetes valorise le respect et l'inclusivité, et applique un code de conduite à suivre dans toutes ses interactions. Si vous remarquez une violation du Code de conduite lors d'un événement ou d'une réunion, que ce soit sur Slack, ou sur tout autre mécanisme de communication, contactez le Comité du Code de conduite de Kubernetes à conduct@kubernetes.io. Tous les rapports sont gardés confidentiels. Pour en savoir plus sur le comité, cliquez ici. +
+ +

+ + +LIRE PLUS + +
+
+
+
+ + + +
+

+

+

Vidéos

+ +
Nous sommes souvent sur YouTube. Abonnez-vous pour un large éventail de sujets.
+ + +
+ + +
+

+

+

Discussions

+ +
Nous parlons beaucoup ! Rejoignez-nous et prenez part à la conversation sur n'importe laquelle des ces plateformes.
+ +
+ +
+ + +forum ▶ + +
+Discussions techniques par thématiques qui établissent un pont entre les docs, StackOverflow, et plus encore +
+
+ +
+ + +twitter ▶ + +
+Annonces en temps réel d'articles de blog, d'événements, d'actualités, d'idées +
+
+ +
+ + +github ▶ + +
+Tout le projet ainsi que les issues et bien évidemment le code +
+
+ +
+ + +stack overflow ▶ + +
+ Dépannage technique pour tous les cas d'utilisation + +
+
+ + + +
+
+
+

+

+
+

Événements À Venir

+ {{< upcoming-events >}} +
+
+ +
+
+
+

Communauté Mondiale

+Avec plus de 150 meetups dans le monde et toujours plus, allez trouver les gens de votre région qui comme vous, s'intéressent à Kubernetes. Si vous n'avez pas de meetup à proximité, prenez les choses en main et créez le vôtre. +
+ +
+TROUVEZ UN MEETUP +
+
+ +
+
+ + + + +
+

+

+

Actualités récentes

+ +
+ + +
+



+
+ +
diff --git a/content/fr/community/code-of-conduct.md b/content/fr/community/code-of-conduct.md new file mode 100644 index 0000000000..82204af8da --- /dev/null +++ b/content/fr/community/code-of-conduct.md @@ -0,0 +1,26 @@ +--- +title: Communauté +layout: basic +cid: community +css: /css/community.css +--- + +
+

Code de conduite de la communauté Kubernetes

+ +Kubernetes suit le +Code de Conduite de la CNCF. +Le texte du CdC de la CNCF est reproduit ci-dessous +commit 214585e. +Si vous remarquez que ce document n'est plus à jour, n'hésitez pas à +créer une issue. + + +Si vous remarquez une violation du Code de conduite lors d'un événement ou d'une réunion, sur Slack, ou sur tout autre mécanisme de communication, contactez le Comité du Code de conduite de Kubernetes. +Vous pouvez nous joindre par courriel à conduct@kubernetes.io. +Votre anonymat sera protégé. + +
+{{< include "/static/cncf-code-of-conduct.md" >}} +
+
diff --git a/content/fr/community/static/README.md b/content/fr/community/static/README.md new file mode 100644 index 0000000000..cadc3f649c --- /dev/null +++ b/content/fr/community/static/README.md @@ -0,0 +1,2 @@ +Les fichiers présents dans ce dossier on été importés depuis une autre source. +Veuillez ne pas les éditer directement sauf en les remplaçant par une nouvelle version. \ No newline at end of file diff --git a/content/fr/community/static/cncf-code-of-conduct.md b/content/fr/community/static/cncf-code-of-conduct.md new file mode 100644 index 0000000000..32db3dbcc1 --- /dev/null +++ b/content/fr/community/static/cncf-code-of-conduct.md @@ -0,0 +1,31 @@ + +Code de conduite de la communauté de la CNCF v1.0 +------------------------------------------------- + +### Code de conduite des contributeurs + +En tant que contributeurs et éditeurs dans le cadre de ce projet, et afin d’encourager le développement d’une communauté ouverte et accueillante, nous nous engageons à respecter chaque personne qui apporte sa contribution en signalant des problèmes, en publiant des suggestions de fonctionnalités, en mettant à jour la documentation, en envoyant des demandes de tirage ou sous une autre forme. + +Nous mettons tout en œuvre afin que la participation à ce projet ne soit source de désagrément pour personne, quel que soit le niveau d’expérience, le sexe, l’identité, l’expression ou l’orientation sexuelle, le handicap, l’apparence physique, la taille et/ou le poids, l’origine ethnique, l’âge, la religion ou la nationalité des personnes qui y participent. + +Voici quelques exemples de comportements qui ne seront pas acceptés de la part des participants: + +- l’utilisation de propos ou d’images à caractère sexuel ; +- les critiques personnelles ; +- les commentaires provocateurs, insultants ou péjoratifs ; +- le harcèlement en public ou en privé ; +- la publication, sans autorisation expresse, d’informations privées de tiers, telles que l’adresse postale ou l’adresse e-mail ; +- tout autre comportement contraire à l’éthique ou non professionnel. + +Les éditeurs du projet ont le droit et la responsabilité de retirer, modifier ou rejeter les commentaires, les validations, le code, les modifications de wiki, les problèmes et toute autre contribution qui ne respecte pas ce Code de conduite. En adoptant ce Code de conduite, les éditeurs du projet s’engagent eux-mêmes à appliquer ces principes de manière juste et systématique dans tous les aspects de la gestion du projet. Les éditeurs du projet qui ne respectent pas le Code de conduite ou ne le font pas respecter pourront être retirés définitivement de l’équipe du projet. + +Ce Code de conduite s’applique à la fois dans le cadre du projet et dans le cadre public, lorsqu’une personne représente le projet ou la communauté. + +Des cas de conduite abusive, de harcèlement ou autre pratique inacceptable ayant cours sur Kubernetes peuvent être signalés en contactant le [comité pour le code de conduite de Kubernetes](https://git.k8s.io/community/committee-code-of-conduct) via l'adresse . Pour d'autres projets, bien vouloir contacter un responsable de projet CNCF ou notre médiateur, Mishi Choudhary à l'adresse . + +Ce Code de conduite est inspiré du « Contributor Covenant » (http://contributor-covenant.org) version 1.2.0, disponible à l’adresse http://contributor-covenant.org/version/1/2/0/. + +### Code de conduite pour les événements de la CNCF + +Les événements de la CNCF sont régis par le Code de conduite de The Linux Foundation, disponible sur la page des événements. Ce Code est compatible avec la politique ci-dessus et inclut davantage de détails sur la façon de gérer les incidents. \ No newline at end of file diff --git a/content/fr/docs/contribute/participating.md b/content/fr/docs/contribute/participating.md new file mode 100644 index 0000000000..455106d448 --- /dev/null +++ b/content/fr/docs/contribute/participating.md @@ -0,0 +1,206 @@ +--- +title: Participez au SIG Docs +content_template: templates/concept +card: + name: contribute + weight: 40 +--- + +{{% capture overview %}} + +SIG Docs est l'un des [groupes d'intérêts spéciaux](https://github.com/kubernetes/community/blob/master/sig-list.md) au sein du projet Kubernetes, axé sur la rédaction, la mise à jour et la maintenance de la documentation de Kubernetes dans son ensemble. +Pour plus d'informations sur le SIG consultez [le dépôt GitHub de la communauté](https://github.com/kubernetes/community/tree/master/sig-docs). + +SIG Docs accueille le contenu et les critiques de tous les contributeurs. +Tout le monde peut ouvrir une pull request (PR), et tout le monde est invité à déposer des questions sur le contenu ou à commenter les pull requests ouvertes. + +Dans SIG Docs, vous pouvez aussi devenir un [membre](#membres), [relecteur](#reviewers), ou [approbateur](#approvers). +Ces rôles nécessitent un plus grand accès et impliquent certaines responsabilités pour approuver et valider les changements. +Voir [appartenance à la communauté](https://github.com/kubernetes/community/blob/master/community-membership.md) pour plus d'informations sur le fonctionnement de l'adhésion au sein de la communauté Kubernetes. +Le reste de ce document décrit certaines fonctions uniques de ces rôles au sein du SIG Docs, responsable de la gestion de l’un des aspects les plus accessibles du public de Kubernetes: le site Web et la documentation de Kubernetes. + +{{% /capture %}} + +{{% capture body %}} + +## Rôles et responsabilités + +Lorsqu'une pull request est mergée à la branche utilisée pour publier le contenu (actuellement `master`), ce contenu est publié et disponible dans le monde entier. +Pour nous assurer que la qualité de notre contenu publié est élevée, nous limitons aux approbateurs SIG Docs le droit de merger des pull requests. +Voici comment ça fonctionne. + +- Lorsqu'une pull request a les deux labels `lgtm` et `approve` et n'a pas de label `hold`, la pull request est mergée automatiquement. +- Les membres de l'organisation Kubernetes et les approbateurs SIG Docs peuvent ajouter des commentaires à une pull request ou empêcher le merge automatique d'une pull request donnée (en ajoutant un commentaire `/hold` ou en retirant un commentaire `/lgtm`). +- Tout membre de Kubernetes peut ajouter le label `lgtm`, en ajoutant un commentaire `/lgtm`. +- Seul un approbateur membre de SIG Docs peut causer le merge d'une pull request en ajoutant un commentaire `/approve`. + Certains approbateurs remplissent également des rôles spécifiques supplémentaires, tels que [PR Wrangler](#pr-wrangler) or [président(e) du SIG Docs](#sig-docs-chairperson). + +Pour plus d'informations sur les attentes et les différences entre les rôles de membre d'organisation Kubernetes et d'approbateurs SIG Docs, voir [Types de contributeur](/docs/contribute#types-of-contributor). +Les sections suivantes couvrent plus de détails sur ces rôles et leur fonctionnement dans SIG-Docs. + +### N'importe qui + +Tout le monde peut ouvrir un ticket sur n'importe quelle partie de Kubernetes, y compris la documentation. + +Toute personne ayant signé le CLA peut ouvrir une Pull Request. +Si vous ne pouvez pas signer le CLA, le projet Kubernetes ne peut pas accepter votre contribution. + +### Membres + +Tout membre de l'[organisation Kubernetes](https://github.com/kubernetes) peut faire une revue d'une pull request, et SIG Docs les membres de l’équipe demandent fréquemment aux membres d’autres SIG d’être révisés pour des raisons de précision technique. +SIG Docs accueille également des critiques et des commentaires indépendamment du statut de membre d'une personne dans l'organisation Kubernetes. +Vous pouvez indiquer votre approbation en ajoutant un commentaire de `/lgtm` à une pull request. +Si vous n'êtes pas membre de l'organisation Kubernetes, votre `/lgtm` n'a aucun effet sur les systèmes automatisés. + +Tout membre de l’organisation Kubernetes peut ajouter un commentaire `/ hold` pour empêcher la pull request d'être mergée. +Tout membre peut également supprimer un commentaire `/hold` pour merger une PR s'il a déjà les deux commentaires `/lgtm` et `/approve` appliqué par les personnes appropriées. + +#### Devenir membre + +Après avoir soumis avec succès au moins 5 pull requests significatives, vous pouvez demander l'[adhésion](https://github.com/kubernetes/community/blob/master/community-membership.md#member) dans l'organisation Kubernetes. +Suivez ces étapes: + +1. Trouvez deux relecteurs ou approbateurs pour [parrainer](/docs/contribute/advanced#sponsor-a-new-contributor) votre adhésion. + + Demander un parrainage dans le [canal #sig-docs sur l'instance de Kubernetes Slack](https://kubernetes.slack.com) ou sur la [mailing list SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + + {{< note >}} + N'envoyez pas de courrier électronique direct ou de message direct Slack à un membre individuel de SIG Docs. + {{< /note >}} + +2. Ouvrez un ticket Github dans le dépôt `kubernetes/org` pour adhérer à l'organisation. + Remplissez le modèle en suivant les directives de l'[Adhésion à la communauté](https://github.com/kubernetes/community/blob/master/community-membership.md). + +3. Informez vos sponsors du ticket Github, soit en les mentionnant dans le ticket Github (en ajoutant un commentaire avec `@`) ou en leur envoyant directement le lien, afin qu’ils puissent ajouter un vote `+ 1`. + +4. Lorsque votre adhésion est approuvée, le membre de l'équipe d'administration github affecté à votre demande met à jour le ticket Github pour indiquer son approbation, puis ferme le ticket Github. + Félicitations, vous êtes maintenant membre! + +Si, pour une raison quelconque, votre demande d'adhésion n'est pas acceptée immédiatement, le comité des membres fournit des informations ou des mesures à prendre avant de présenter une nouvelle demande. + +### Relecteurs + +Les relecteurs sont membres du groupe Github [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews). +Voir [Equipes et groupes au sein de SIG Docs](#teams-and-groups-within-sig-docs). + +Les relecteurs examinent les Pull Request de documentation et font des commentaires sur les changements proposés. + +L'automatisation assigne des relecteurs aux pull requets, et les contributeurs peuvent demander une revue d'un relecteur spécifique en laissant un commentaire tel que: `/assign [@_github_handle]`. +Pour indiquer qu'une pull request est techniquement exacte et ne nécessite aucune modification supplémentaire, un examinateur ajoute un commentaire `/lgtm` à la Pull Request. + +Si le relecteur affecté n'a pas encore revu le contenu, un autre relecteur peut intervenir. +En outre, vous pouvez affecter des relecteurs techniques et attendre qu'ils fournissent des `/lgtm`. + +Pour un changement trivial ou ne nécessitant aucun examen technique, l'[approbateur](#approvers) SIG Docs peut fournir le `/lgtm` aussi. + +Un commentaire `/approve` d'un relecteur est ignoré par l'automatisation. + +Pour en savoir plus sur comment devenir un relecteur SIG Docs et sur les responsabilités et l’engagement de temps que cela implique, voir [Devenir relecteur ou approbateur](#becoming-an-approver-or-reviewer). + +#### Devenir relecteur + +Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), vous pouvez devenir un relecteur SIG Docs. +Les relecteurs d'autres SIG doivent demander séparément le statut de relecteur dans le SIG Docs. + +Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépôt `kubernetes/website`. +Affectez la PR à un ou plusieurs approbateurs SIG Docs. + +Si votre pull request est approuvé, vous êtes maintenant un relecteur SIG Docs. +[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) vous assignera et vous suggérera en tant que relecteur pour les nouvelles Pull Requests. + +Si vous êtes approuvé, demandez qu’un approbateur SIG Docs en cours vous ajoute au groupe Github [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews). +Seuls les membres du groupe Github `kubernetes-website-admins` peuvent ajouter de nouveaux membres à un groupe Github. + +### Approbateurs + +Les approbateurs sont membres du groupe Github [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers). +Voir [Equipes et groupes au sein de SIG Docs](#teams-and-groups-within-sig-docs). + +Les approbateurs ont la capacité de merger une PR, et ainsi, publier du contenu sur le site Web de Kubernetes. +Pour approuver une PR, un approbateur laisse un commentaire `/approve` sur la PR. +Si quelqu'un qui n'est pas un approbateur laisse le commentaire d'approbation, l'automatisation l'ignore. + +Si la PR a déjà un `/lgtm`, ou si l'approbateur fait également des commentaires avec `/lgtm`, la PR est mergée automatiquement. +Un approbateur SIG Docs ne doit laisser qu'un `/lgtm` sur un changement qui ne nécessite pas de relecture supplémentaire. + +Pour en savoir plus sur comment devenir un approbateur SIG Docs et sur les responsabilités et l’engagement de temps que cela implique, voir [Devenir relecteur ou approbateur](#becoming-an-approver-or-reviewer). + +#### Devenir approbateur + +Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), vous pouvez devenir un approbateur SIG Docs. +Les approbateurs appartenant à d'autres SIG doivent demander séparément le statut d'approbateur dans SIG Docs. + +Pour postuler, ouvrez une pull request pour vous ajouter à la section `approvers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépot `kubernetes/website`. +Affectez la PR à un ou plusieurs approbateurs SIG Docs. + +Si votre Pull Request est approuvée, vous êtes à présent approbateur SIG Docs. +Le [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) vous assignera et vous suggérera en tant que relecteur pour les nouvelles Pull Requests. + +Si vous êtes approuvé, demandez qu’un approbateur SIG Docs en cours vous ajoute au groupe Github [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers). +Seuls les membres du groupe Github `kubernetes-website-admins` peuvent ajouter de nouveaux membres à un groupe Github. + +#### Devenir un administrateur de site Web + +Les membres du groupe GitHub `kubernetes-website-admins` peut gérer l’appartenance au groupe Github et disposer de tous les droits administratifs sur les paramètres du dépôt, y compris la possibilité d'ajouter, de supprimer et de debugger des Webhooks. +Tous les approbateurs SIG Docs n'ont pas besoin de ce niveau d'accès. + +Si vous pensez avoir besoin de ce niveau d’accès, adressez-vous à un administrateur de site Web existant ou posez la question dans le canal Slack [#sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/). + +#### Auxiliaires de traitement des Pull Requests + +Les approbateurs SIG Docs sont ajoutés au [calendrier de rotations des auxiliaires de traitement des PullRequests](https://github.com/kubernetes/website/wiki/PR-Wranglers) pour les rotations hebdomadaires. +Tous les approbateurs SIG Docs devraient participer à cette rotation. +Voir [Soyez l'auxiliaire des PR pendant une semaine](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) pour plus de détails. + +#### Présidence du SIG Docs + +Chaque SIG, y compris SIG Docs, sélectionne un ou plusieurs membres du SIG qui assumeront les fonctions de président(e). +Ce sont des points de contact entre SIG Docs et d’autres parties de l’organisation Kubernetes. +Ils nécessitent une connaissance approfondie de la structure du projet Kubernetes dans son ensemble et du fonctionnement de SIG Docs au sein de celui-ci. +Voir [Direction](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) pour la liste actuelle des président(e)s. + +## Equipes SIG Docs et automatisation + +L'automatisation dans SIG Docs repose sur deux mécanismes différents: +Groupes Github et fichiers OWNERS. + +### Groupes Github + +Le groupe SIG Docs définit deux équipes sur Github: + +- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) +- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) + +Chacun peut être référencé avec son `@name` dans Github, commentez pour communiquer avec tous les membres de ce groupe. + +Ces équipes peuvent avoir des membres en commun. +Pour l'affectation des tickets, des pull requests, et aider la validation des PR, l'automatisation utilise les informations des fichiers OWNERS. + +### OWNERS files et front-matter + +Le projet Kubernetes utilise un outil d'automatisation appelé prow pour l'automatisation liée aux Github issues et aux pull requests. +Le [dépôt du site web Kubernetes](https://github.com/kubernetes/website) utilise deux [plugins prow](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210): + +- blunderbuss +- approve + +Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne. + +Un fichier [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs. +Les fichiers OWNERS existent aussi dans les sous-dossiers, et peut ignorer qui peut agir en tant que relecteur ou approbateur des fichiers de ce sous-répertoire et de ses descendants. +Pour plus d'informations sur les fichiers OWNERS en général, voir [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). + +En outre, un fichier Markdown individuel peut répertorier les relecteurs et les approbateurs dans l'entête, soit en répertoriant les noms d’utilisateur ou les groupes de Github. + +La combinaison des fichiers `OWNERS` et des entêtes dans les fichiers Markdown determinent les suggestions automatiques de relecteurs dans la PullRequest. + +{{% /capture %}} + +{{% capture whatsnext %}} + +Pour plus d'informations sur la contribution à la documentation Kubernetes, voir: + +- [Commencez à contribuer](/docs/contribute/start/) +- [Documentation style](/docs/contribute/style/) + +{{% /capture %}} diff --git a/content/fr/docs/reference/glossary/cri.md b/content/fr/docs/reference/glossary/cri.md new file mode 100644 index 0000000000..f134b93b3f --- /dev/null +++ b/content/fr/docs/reference/glossary/cri.md @@ -0,0 +1,17 @@ +--- +title: Container Runtime Interface (CRI) +id: cri +date: 2019-03-07 +full_link: https://kubernetes.io/docs/concepts/overview/components/#container-runtime +short_description: > + Une API pour les runtimes de conteneurs à intégrer avec kubelet + + +aka: +tags: +- fundamental +--- +L'interface d'exécution de conteneur (CRI, de l'anglais Container Runtime Interface) est une API pour les runtimes de conteneurs à intégrer avec kubelet, sur un nœud. + + +Pour plus d'informations, se référer aux spécificités de l'API [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). diff --git a/content/fr/docs/setup/custom-cloud/kubespray.md b/content/fr/docs/setup/custom-cloud/kubespray.md index 66815b085b..0568cb2a1a 100644 --- a/content/fr/docs/setup/custom-cloud/kubespray.md +++ b/content/fr/docs/setup/custom-cloud/kubespray.md @@ -90,7 +90,7 @@ Kubespray fournit le moyen de vérifier la connectivité inter-pods ainsi que la Les pods netchecker-agents s'assurent que la résolution DNS (services Kubernetes) ainsi que le ping entre les pods fonctionnent correctement. Ces pods reproduisent un comportement similaire à celui des autres applications et offrent un indicateur de santé du cluster. -## Opérations sur le clutser +## Opérations sur le cluster Kubespray fournit des playbooks supplémentaires qui permettent de gérer votre cluster: _scale_ et _upgrade_. diff --git a/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md new file mode 100644 index 0000000000..11aab62fd2 --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md @@ -0,0 +1,259 @@ +--- +title: Configurer la qualité de service pour les pods +content_template: templates/task +weight: 30 +--- + + +{{% capture overview %}} + +Cette page montre comment configurer les Pods pour qu'ils soient affectés à des classes particulières de qualité de service (QoS). Kubernetes utilise des classes de QoS pour prendre des décisions concernant l'ordonnancement et les évictions des pods. + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + +## Les Classes de QoS + +Quand Kubernetes crée un Pod, il affecte une de ces classes QoS au Pod : + +* Guaranteed +* Burstable +* BestEffort + +## Créez un namespace + +Créez un namespace de manière à ce que les ressources que vous créez dans cet exercice soient isolées du reste de votre cluster. + +```shell +kubectl create namespace qos-example +``` + +## Créez un Pod qui se fait attribuer une classe QoS de Guaranteed + +Pour qu'un Pod reçoive une classe de QoS Guaranteed : + +* Chaque conteneur du Pod doit avoir une limite de mémoire et une demande de mémoire, et elles doivent être les mêmes. +* Chaque conteneur dans le Pod doit avoir une limite CPU et une demande CPU, et ils doivent être les mêmes. + +Ci-dessous le fichier de configuration d'un Pod qui a un seul conteneur. +Le conteneur dispose d'une limite de mémoire et d'une demande de mémoire, tous deux égaux à 200 MiB. Le conteneur a également une limite CPU et une demande CPU, toutes deux égales à 700 milliCPU : + +{{< codenew file="pods/qos/qos-pod.yaml" >}} + +Créez le Pod : + +```shell +kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example +``` + +Consultez des informations détaillées sur le Pod : + +```shell +kubectl get pod qos-demo --namespace=qos-example --output=yaml +``` + +Le résultat indique que Kubernetes a donné au pod une classe de qualité de service de type Guaranteed. De plus, il affiche que la demande de mémoire du conteneur du pod correspond à sa limite de mémoire, et que la demande de CPU correspond à sa limite de CPU. + +```yaml +spec: + containers: + ... + resources: + limits: + cpu: 700m + memory: 200Mi + requests: + cpu: 700m + memory: 200Mi +... + qosClass: Guaranteed +``` + +{{< note >}} +Si un conteneur spécifie sa propre limite de mémoire, mais ne spécifie pas de demande de mémoire, Kubernetes attribue automatiquement une demande de mémoire correspondant à la limite. De même, si un conteneur spécifie sa propre limite CPU, mais ne spécifie pas de demande de CPU, Kubernetes lui attribue automatiquement une demande de CPU qui correspond à cette limite. +{{< /note >}} + +Supprimez votre Pod : + +```shell +kubectl delete pod qos-demo --namespace=qos-example +``` + +## Créez un Pod qui se fait attribuer une classe QoS de type Burstable + +Un Pod reçoit une classe QoS de Burstable si : + +* Le Pod ne répond pas aux critères de la classe QoS Guaranteed. +* Au moins un conteneur dans le Pod dispose d'une demande de mémoire ou de CPU. + +Voici le fichier de configuration d'un pod qui a un seul conteneur. Le conteneur a une limite de mémoire de 200 MiB et une demande de mémoire de 100 MiB. + +{{< codenew file="pods/qos/qos-pod-2.yaml" >}} + +Créez le Pod : + +```shell +kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example +``` + +Consultez des informations détaillées sur le Pod : + +```shell +kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml +``` + +La sortie montre que Kubernetes a accordé au pod une classe QoS de type Burstable. +```yaml +spec: + containers: + - image: nginx + imagePullPolicy: Always + name: qos-demo-2-ctr + resources: + limits: + memory: 200Mi + requests: + memory: 100Mi +... + qosClass: Burstable +``` + +Supprimez votre Pod : + +```shell +kubectl delete pod qos-demo-2 --namespace=qos-example +``` + +## Créez un Pod qui se fait attribuer une classe QoS de type BestEffort + +Pour qu'un pod puisse avoir la classe QoS de BestEffort, les conteneurs dans le pod ne doivent pas +avoir des limites ou des demandes de mémoire ou de CPU. + +Voici le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur n'a pas des limites ou des demandes de mémoire ou de CPU : + +{{< codenew file="pods/qos/qos-pod-3.yaml" >}} + +Créez le Pod : + +```shell +kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example +``` + +Consultez des informations détaillées sur le Pod : + +```shell +kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml +``` + +Le résultat montre que Kubernetes a accordé au pod une classe QoS de BestEffort. + +```yaml +spec: + containers: + ... + resources: {} + ... + qosClass: BestEffort +``` + +Supprimez votre Pod : + +```shell +kubectl delete pod qos-demo-3 --namespace=qos-example +``` + +## Créez un pod qui contient deux conteneurs + + +Voici le fichier de configuration d'un Pod qui a deux conteneurs. Un conteneur spécifie une +demande de mémoire de 200 MiB. L'autre conteneur ne spécifie aucune demande ou limite. + +{{< codenew file="pods/qos/qos-pod-4.yaml" >}} + +Notez que le pod répond aux critères de la classe QoS Burstable. En d'autres termes, il ne répond pas aux exigences de la classe de qualité de service Guaranteed, et l'un de ses conteneurs dispose d'une demande de mémoire. + +Créez le Pod : + +```shell +kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example +``` + +Consultez des informations détaillées sur le Pod : + +```shell +kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml +``` + +Le résultat montre que Kubernetes a accordé au pod une classe QoS de Burstable: + +```yaml +spec: + containers: + ... + name: qos-demo-4-ctr-1 + resources: + requests: + memory: 200Mi + ... + name: qos-demo-4-ctr-2 + resources: {} + ... + qosClass: Burstable +``` + +Supprimez votre pod : + +```shell +kubectl delete pod qos-demo-4 --namespace=qos-example +``` + +## Nettoyage + +Supprimez votre namespace. + +```shell +kubectl delete namespace qos-example +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + +### Pour les développeurs d'applications + +* [Allocation des ressources CPU aux conteneurs et pods](/docs/tasks/configure-pod-container/assign-cpu-resource/) + +* [Allocation des ressources mémoire aux conteneurs et pods](/fr/docs/tasks/configure-pod-container/assign-memory-resource/) + + +### Pour les administrateurs de cluster + +* [Configuration des demandes et des limites de mémoire par défaut pour un Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [Configuration des demandes et des limites par défaut de CPU pour un Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) + +* [Configuration des contraintes de mémoire minimales et maximales pour un Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [Configuration des contraintes minimales et maximales du CPU pour un Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [Configuration des quotas de mémoire et de CPU pour un Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [Configuration du quota de pods pour un Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) + +* [Configuration des quotas pour les objets API](/docs/tasks/administer-cluster/quota-api-object/) +{{% /capture %}} + + + + + diff --git a/content/fr/examples/pods/qos/qos-pod-2.yaml b/content/fr/examples/pods/qos/qos-pod-2.yaml new file mode 100644 index 0000000000..115d4de21e --- /dev/null +++ b/content/fr/examples/pods/qos/qos-pod-2.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: qos-demo-2 + namespace: qos-example +spec: + containers: + - name: qos-demo-2-ctr + image: nginx + resources: + limits: + memory: "200Mi" + requests: + memory: "100Mi" diff --git a/content/fr/examples/pods/qos/qos-pod-3.yaml b/content/fr/examples/pods/qos/qos-pod-3.yaml new file mode 100644 index 0000000000..dac3629942 --- /dev/null +++ b/content/fr/examples/pods/qos/qos-pod-3.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: Pod +metadata: + name: qos-demo-3 + namespace: qos-example +spec: + containers: + - name: qos-demo-3-ctr + image: nginx diff --git a/content/fr/examples/pods/qos/qos-pod-4.yaml b/content/fr/examples/pods/qos/qos-pod-4.yaml new file mode 100644 index 0000000000..d4818b277e --- /dev/null +++ b/content/fr/examples/pods/qos/qos-pod-4.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: qos-demo-4 + namespace: qos-example +spec: + containers: + + - name: qos-demo-4-ctr-1 + image: nginx + resources: + requests: + memory: "200Mi" + + - name: qos-demo-4-ctr-2 + image: redis diff --git a/content/fr/examples/pods/qos/qos-pod.yaml b/content/fr/examples/pods/qos/qos-pod.yaml new file mode 100644 index 0000000000..b4a6b1ea82 --- /dev/null +++ b/content/fr/examples/pods/qos/qos-pod.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: qos-demo + namespace: qos-example +spec: + containers: + - name: qos-demo-ctr + image: nginx + resources: + limits: + memory: "200Mi" + cpu: "700m" + requests: + memory: "200Mi" + cpu: "700m" diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md new file mode 100644 index 0000000000..0d9ab08793 --- /dev/null +++ b/content/id/docs/concepts/cluster-administration/logging.md @@ -0,0 +1,198 @@ +--- +title: Arsitektur Logging +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + +Log aplikasi dan sistem dapat membantu kamu untuk memahami apa yang terjadi di dalam kluster kamu. Log berguna untuk mengidentifikasi dan menyelesaikan masalah serta memonitor aktivitas kluster. Hampir semua aplikasi modern mempunyai sejenis mekanisme log sehingga hampir semua mesin kontainer didesain untuk mendukung suatu mekanisme _logging_. Metode _logging_ yang paling mudah untuk aplikasi dalam bentuk kontainer adalah menggunakan _standard output_ dan _standard error_. + +Namun, fungsionalitas bawaan dari mesin kontainer atau _runtime_ biasanya tidak cukup memadai sebagai solusi log. Contohnya, jika sebuah kontainer gagal, sebuah pod dihapus, atau suatu _node_ mati, kamu biasanya tetap menginginkan untuk mengakses log dari aplikasimu. Oleh sebab itu, log sebaiknya berada pada penyimpanan dan _lifecyle_ yang terpisah dari node, pod, atau kontainer. Konsep ini dinamakan sebagai _logging_ pada level kluster. _Logging_ pada level kluster ini membutuhkan _backend_ yang terpisah untuk menyimpan, menganalisis, dan mengkueri log. Kubernetes tidak menyediakan solusi bawaan untuk penyimpanan data log, namun kamu dapat mengintegrasikan beragam solusi _logging_ yang telah ada ke dalam kluster Kubernetes kamu. + +{{% /capture %}} + + +{{% capture body %}} + +Arsitektur _logging_ pada level kluster yang akan dijelaskan berikut mengasumsikan bahwa sebuah _logging backend_ telah tersedia baik di dalam maupun di luar klustermu. Meskipun kamu tidak tertarik menggunakan _logging_ pada level kluster, penjelasan tentang bagaimana log disimpan dan ditangani pada node di bawah ini mungkin dapat berguna untukmu. + +## Hal dasar _logging_ pada Kubernetes + +Pada bagian ini, kamu dapat melihat contoh tentang dasar _logging_ pada Kubernetes yang mengeluarkan data pada _standard output_. Demonstrasi berikut ini menggunakan sebuah [spesifikasi pod](/examples/debug/counter-pod.yaml) dengan kontainer yang akan menuliskan beberapa teks ke _standard output_ tiap detik. + +{{< codenew file="debug/counter-pod.yaml" >}} + +Untuk menjalankan pod ini, gunakan perintah berikut: + +```shell +kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml +``` +Keluarannya adalah: +``` +pod/counter created +``` + +Untuk mengambil log, gunakan perintah `kubectl logs` sebagai berikut: + +```shell +kubectl logs counter +``` +Keluarannya adalah: +``` +0: Mon Jan 1 00:00:00 UTC 2001 +1: Mon Jan 1 00:00:01 UTC 2001 +2: Mon Jan 1 00:00:02 UTC 2001 +... +``` + +Kamu dapat menambahkan parameter `--previous` pada perintah `kubectl logs` untuk mengambil log dari kontainer sebelumnya yang gagal atau _crash_. Jika pod kamu memiliki banyak kontainer, kamu harus menspesifikasikan kontainer mana yang kamu ingin akses lognya dengan menambahkan nama kontainer pada perintah tersebut. Lihat [dokumentasi `kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) untuk informasi lebih lanjut. + +## Node-level _logging_ + +![Node-level _logging_](/images/docs/user-guide/logging/logging-node-level.png) + +Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview), yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam file dalam format json. + +{{< note >}} +_Logging driver_ json dari Docker memperlakukan tiap baris sebagai pesan yang terpisah. Saat menggunakan _logging driver_ Docker, tidak ada dukungan untuk menangani pesan _multi-line_. Kamu harus menangani pesan _multi-line_ pada level agen log atau yang lebih tinggi. +{{< /note >}} + +Secara _default_, jika suatu kontainer _restart_, kubelet akan menjaga kontainer yang mati tersebut beserta lognya. Namun jika suatu pod dibuang dari _node_, maka semua hal dari kontainernya juga akan dibuang, termasuk lognya. + +Hal lain yang perlu diperhatikan dalam _logging_ pada level _node_ adalah implementasi rotasi log, sehingga log tidak menghabiskan semua penyimpanan yang tersedia pada _node._ Kubernetes saat ini tidak bertanggung jawab dalam melakukan rotasi log, namun _deployment tool_ seharusnya memberikan solusi terhadap masalah tersebut. +Contohnya, pada kluster Kubernetes, yang di _deployed_ menggunakan `kube-up.sh`, terdapat alat bernama [`logrotate`](https://linux.die.net/man/8/logrotate) yang dikonfigurasi untuk berjalan tiap jamnya. Kamu juga dapat menggunakan _runtime_ kontainer untuk melakukan rotasi log otomatis, misalnya menggunakan `log-opt` Docker. +Pada `kube-up.sh`, metode terakhir digunakan untuk COS _image_ pada GCP, sedangkan metode pertama digunakan untuk lingkungan lainnya. Pada kedua metode, secara _default_ akan dilakukan rotasi pada saat berkas log melewati 10MB. + +Sebagai contoh, kamu dapat melihat informasi lebih rinci tentang bagaimana `kube-up.sh` mengatur _logging_ untuk COS _image_ pada GCP yang terkait dengan [_script_][cosConfigureHelper]. + +Saat kamu menjalankan perintah [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) seperti pada contoh tadi, kubelet di _node_ tersebut akan menangani permintaan untuk membaca langsung isi berkas log sebagai respon. + +{{< note >}} +Saat ini, jika suatu sistem eksternal telah melakukan rotasi, hanya konten dari berkas log terbaru yang akan tersedia melalui perintah `kubectl logs`. Contoh, jika terdapat sebuah berkas 10MB, `logrotate` akan melakukan rotasi sehingga akan ada dua buah berkas, satu dengan ukuran 10MB, dan satu berkas lainnya yang kosong. Maka `kubectl logs` akan mengembalikan respon kosong. +{{< /note >}} + +[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh + +### Komponen sistem log + +Terdapat dua jenis komponen sistem: yaitu yang berjalan di dalam kontainer dan komponen lain yang tidak berjalan di dalam kontainer. Sebagai contoh: + +* Kubernetes _scheduler_ dan kube-proxy berjalan di dalam kontainer. +* Kubelet dan _runtime_ kontainer, contohnya Docker, tidak berjalan di dalam kontainer. + +Pada mesin yang menggunakan systemd, kubelet dan runtime _runtime_ menulis ke journald. Jika systemd tidak tersedia, keduanya akan menulis ke berkas `.log` pada folder `/var/log`. +Komponen sistem di dalam kontainer akan selalu menuliskan ke folder `/var/log`, melewati mekanisme _default logging_. Mereka akan menggunakan _logging library_ [klog][klog]. +Kamu dapat menemukan konvensi tentang tingkat kegawatan _logging_ untuk komponen-komponen tersebut pada [dokumentasi _development logging_](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). + +Seperti halnya pada log kontainer, komponen sistem yang menuliskan log pada folder `/var/log` juga harus melakukan rotasi log. Pada kluster Kubernetes yang menggunakan `kube-up.sh`, log tersebut telah dikonfigurasi dan akan dirotasi oleh `logrotate` secara harian atau saat ukuran log melebihi 100MB. + +[klog]: https://github.com/kubernetes/klog + +## Arsitektur kluster-level _logging_ + +Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level kluster, ada beberapa pendekatan yang dapat kamu pertimbangkan. Berikut beberapa diantaranya: + +* Menggunakan agen _logging_ pada level _node_ yang berjalan pada setiap _node_. +* Menggunakan kontainer _sidecar_ khusus untuk _logging_ aplikasi di dalam pod. +* Mengeluarkan log langsung ke _backend_ dari dalam aplikasi + +### Menggunakan agen node-level _logging_ + +![Menggunakan agen node-level _logging_](/images/docs/user-guide/logging/logging-with-node-agent.png) + +Kamu dapat mengimplementasikan kluster-level _logging_ dengan menggunakan agen yang berjalan pada setiap _node_. Agen _logging_ merupakan perangkat khusus yang akan mengekspos log atau mengeluarkan log ke _backend_. Umumnya agen _logging_ merupakan kontainer yang memiliki akses langsung ke direktori tempat berkas log berada dari semua kontainer aplikasi yang berjalan pada _node_ tersebut. + +Karena agen _logging_ harus berjalan pada setiap _node_, umumnya dilakukan dengan menggunakan replika DaemonSet, _manifest_ pod, atau menjalankan proses khusus pada _node_. Namun dua cara terakhir sudah dideprekasi dan sangat tidak disarankan. + +Menggunakan agen _logging_ pada level _node_ merupakan cara yang paling umum dan disarankan untuk kluster Kubernetes. Hal ini karena hanya dibutuhkan satu agen tiap node dan tidak membutuhkan perubahan apapun dari sisi aplikasi yang berjalan pada _node_. Namun, node-level _logging_ hanya dapat dilakukan untuk aplikasi yang menggunakan _standard output_ dan _standard error_. + +Kubernetes tidak menspesifikasikan khusus suatu agen _logging_, namun ada dua agen _logging_ yang dimasukkan dalam rilis Kubernetes: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) untuk digunakan pada Google Cloud Platform, dan [Elasticsearch](/docs/user-guide/logging/elasticsearch). Kamu dapat melihat informasi dan instruksi pada masing-masing dokumentasi. Keduanya menggunakan [fluentd](http://www.fluentd.org/) dengan konfigurasi kustom sebagai agen pada _node_. + +### Menggunakan kontainer _sidecar_ dengan agen _logging_ + +Kamu dapat menggunakan kontainer _sidecar_ dengan salah satu cara berikut: + +* Kontainer _sidecar_ mengeluarkan log aplikasi ke `stdout` miliknya sendiri. +* Kontainer _sidecar_ menjalankan agen _logging_ yang dikonfigurasi untuk mengambil log dari aplikasi kontainer. + +#### Kontainer _streaming_ _sidecar_ + +![Kontainer _sidecar_ dengan kontainer _streaming_](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) + +Kamu dapat memanfaatkan kubelet dan agen _logging_ yang telah berjalan pada tiap _node_ dengan menggunakan kontainer _sidecar_. Kontainer _sidecar_ dapat membaca log dari sebuah berkas, _socket_ atau journald. Tiap kontainer _sidecar_ menuliskan log ke `stdout` atau `stderr` mereka sendiri. + +Dengan menggunakan cara ini kamu dapat memisahkan aliran log dari bagian-bagian yang berbeda dari aplikasimu, yang beberapa mungkin tidak mendukung log ke `stdout` dan `stderr`. Perubahan logika aplikasimu dengan menggunakan cara ini cukup kecil, sehingga hampir tidak ada _overhead_. Selain itu, karena `stdout` dan `stderr` ditangani oleh kubelet, kamu juga dapat menggunakan alat bawaan seperti `kubectl logs`. + +Sebagai contoh, sebuah pod berjalan pada satu kontainer tunggal, dan kontainer menuliskan ke dua berkas log yang berbeda, dengan dua format yang berbeda pula. Berikut ini _file_ konfigurasi untuk Pod: + +{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}} + +Hal ini akan menyulitkan untuk mengeluarkan log dalam format yang berbeda pada aliran log yang sama, meskipun kamu dapat me-_redirect_ keduanya ke `stdout` dari kontainer. Sebagai gantinya, kamu dapat menggunakan dua buah kontainer _sidecar_. Tiap kontainer _sidecar_ dapat membaca suatu berkas log tertentu dari _shared volume_ kemudian mengarahkan log ke `stdout`-nya sendiri. + +Berikut _file_ konfigurasi untuk pod yang memiliki dua buah kontainer _sidecard_: + +{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}} + +Saat kamu menjalankan pod ini, kamu dapat mengakses tiap aliran log secara terpisah dengan menjalankan perintah berikut: + +```shell +kubectl logs counter count-log-1 +``` +``` +0: Mon Jan 1 00:00:00 UTC 2001 +1: Mon Jan 1 00:00:01 UTC 2001 +2: Mon Jan 1 00:00:02 UTC 2001 +... +``` + +```shell +kubectl logs counter count-log-2 +``` +``` +Mon Jan 1 00:00:00 UTC 2001 INFO 0 +Mon Jan 1 00:00:01 UTC 2001 INFO 1 +Mon Jan 1 00:00:02 UTC 2001 INFO 2 +... +``` + +Agen node-level yang terpasang di klustermu akan mengambil aliran log tersebut secara otomatis tanpa perlu melakukan konfigurasi tambahan. Bahkan jika kamu mau, kamu dapat mengonfigurasi agen untuk melakukan _parse_ baris log tergantung dari kontainer sumber awalnya. + +Sedikit catatan, meskipun menggunakan memori dan CPU yang cukup rendah (sekitar beberapa milicore untuk CPU dan beberapa megabytes untuk memori), penulisan log ke _file_ kemudian mengalirkannya ke `stdout` dapat berakibat penggunaan disk yang lebih besar. Jika kamu memiliki aplikasi yang menuliskan ke _file_ tunggal, umumnya lebih baik menggunakan `/dev/stdout` sebagai tujuan daripada menggunakan pendekatan dengan kontainer _sidecar_. + +Kontainer _sidecar_ juga dapat digunakan untuk melakukan rotasi berkas log yang tidak dapat dirotasi oleh aplikasi itu sendiri. Contoh dari pendekatan ini adalah sebuah kontainer kecil yang menjalankan rotasi log secara periodik. Namun, direkomendasikan untuk menggunakan `stdout` dan `stderr` secara langsung dan menyerahkan kebijakan rotasi dan retensi pada kubelet. + +#### Kontainer _sidecar_ dengan agen _logging_ + +![Kontainer _sidecar_ dengan agen _logging_](/images/docs/user-guide/logging/logging-with-sidecar-agent.png) + +Jika agen node-level _logging_ tidak cukup fleksible untuk kebutuhanmu, kamu dapat membuat kontainer _sidecar_ dengan agen _logging_ yang terpisah, yang kamu konfigurasi spesifik untuk berjalan dengan aplikasimu. + +{{< note >}} +Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat penggunaan _resource_ yang signifikan. Selain itu, kamu tidak dapat mengakses log itu dengan menggunakan perintah `kubectl logs`, karena mereka tidak dikontrol oleh kubelet. +{{< /note >}} + +Sebagai contoh, kamu dapat menggunakan [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/), +yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd. + +{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} + +{{< note >}} +Konfigurasi fluentd berada diluar cakupan artikel ini. Untuk informasi lebih lanjut tentang cara mengonfigurasi fluentd, silakan lihat [dokumentasi resmi fluentd ](http://docs.fluentd.org/). +{{< /note >}} + +_File_ yang kedua mendeskripsikan sebuah pod yang memiliki kontainer _sidecar_ yang menjalankan fluentd. Pod ini melakukan _mount_ sebuah volume yang akan digunakan fluentd untuk mengambil data konfigurasinya. + +{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} + +Setelah beberapa saat, kamu akan mendapati pesan log pada _interface_ Stackdriver. + +Ingat, ini hanya contoh saja dan kamu dapat mengganti fluentd dengan agen _logging_ lainnya, yang dapat membaca sumber apa saja dari dalam kontainer aplikasi. + +### Mengekspos log langsung dari aplikasi + +![Mengekspos log langsung dari aplikasi](/images/docs/user-guide/logging/logging-from-application.png) + +Kamu dapat mengimplementasikan kluster-level _logging_ dengan mengekspos atau mengeluarkan log langsung dari tiap aplikasi; namun cara implementasi mekanisme _logging_ tersebut diluar cakupan dari Kubernetes. + +{{% /capture %}} diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md new file mode 100644 index 0000000000..aaddac7334 --- /dev/null +++ b/content/id/docs/concepts/configuration/assign-pod-node.md @@ -0,0 +1,324 @@ +--- +title: Menetapkan Pod ke Kontainer +content_template: templates/concept +weight: 30 +--- + + +{{% capture overview %}} + +Kamu dapat memaksa sebuah [pod](/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama. + +Kamu dapat menemukan semua berkas untuk contoh-contoh berikut pada [dokumentasi yang kami sediakan di sini](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/) + +{{% /capture %}} + +{{% capture body %}} + +## nodeSelector + +Penggunaan `nodeSelector` adalah cara pembatasan pemilihan node paling sederhana yang direkomendasikan. `nodeSelector` adalah sebuah _field_ pada PodSpec. `nodeSelector` memerinci sebuah map berisi pasangan kunci-nilai. Agar pod dapat dijalankan pada sebuah node yang memenuhi syarat, node tersebut harus memiliki masing-masing dari pasangan kunci-nilai yang dinyatakan sebagai label (namun node juga dapat memiliki label tambahan diluar itu). Penggunaan paling umum adalah satu pasang kunci-nilai. + +Mari kita telusuri contoh dari penggunaan `nodeSelector`. + +### Langkah Nol: Prasyarat + +Contoh ini mengasumsikan bahwa kamu memiliki pemahaman dasar tentang pod Kubernetes dan kamu telah [membuat kluster Kubernetes](https://github.com/kubernetes/kubernetes#documentation). + +### Langkah Satu: Menyematkan label pada node + +Jalankan `kubectl get nodes` untuk mendapatkan nama dari node-node yang ada dalam kluster kamu. Temukan node yang akan kamu tambahkan label, kemudian jalankan perintah `kubectl label nodes =` untuk menambahkan label pada node yang telah kamu pilih. Sebagai contoh, jika nama node yang saya pilih adalah 'kubernetes-foo-node-1.c.a-robinson.internal' dan label yang ingin saya tambahkan adalah 'disktype=ssd', maka saya dapat menjalankan `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`. + +Jika terjadi kegagalan dengan kesalahan perintah yang tidak _valid_ ("_invalid command_"), kemungkinan besar kamu menggunakan kubectl dengan versi lebih lama yang tidak memiliki perintah `label`. Dalam hal ini, lihat [versi sebelumnya] (https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) dari petunjuk ini untuk instruksi tentang cara menetapkan label pada node. + +Kamu dapat memastikan perintah telah berhasil dengan menjalankan ulang perintah `kubectl get nodes --show-labels` and memeriksa bahwa node yang dipilih sekarang sudah memiliki label yang ditambahkan. Kamu juga dapat menggunakan `kubectl describe node "nodename"` untuk melihat daftar lengkap label yang dimiliki sebuah node. + +### Langkah Dua: Menambahkan sebuah nodeSelector ke konfigurasi pod kamu + +Ambil berkas konfigurasi pod manapun yang akan kamu jalankan, dan tambahkan sebuah bagian `nodeSelector` pada berkas tersebut, seperti berikut. Sebagai contoh, jika berikut ini adalah konfigurasi pod saya: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx +``` + +Kemudian tambahkan sebuah `nodeSelector` seperti berikut: + +{{< codenew file="pods/pod-nginx.yaml" >}} + +Ketika kamu menjalankan perintah `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`, pod tersebut akan dijadwalkan pada node yang memiliki label yang dirinci. Kamu dapat memastikan penambahan nodeSelector berhasil dengan menjalankan `kubectl get pods -o wide` dan melihat "NODE" tempat Pod ditugaskan. + +## Selingan: label node _built-in_ + +Sebagai tambahan dari label yang kamu [sematkan](#step-one-attach-label-to-the-node), node sudah terisi dengan satu set label standar. Pada Kubernetes v1.4 label tersebut adalah + +* `kubernetes.io/hostname` +* `failure-domain.beta.kubernetes.io/zone` +* `failure-domain.beta.kubernetes.io/region` +* `beta.kubernetes.io/instance-type` +* `kubernetes.io/os` +* `kubernetes.io/arch` + +{{< note >}} +Nilai dari label-label tersebut spesifik untuk setiap penyedia layanan _cloud_ dan tidak dijamin reliabilitasnya. +Contohnya, nilai dari `kubernetes.io/hostname` bisa saja sama dengan nama node pada beberapa lingkungan dan berbeda pada lingkungan lain. +{{< /note >}} + +## Isolasi/pembatasan Node + +Menambahkan label pada objek node memungkinkan penargetan pod pada node atau grup node yang spesifik. Penambahan label ini dapat digunakan untuk memastikan pod yang spesifik hanya berjalan pada node dengan isolasi, keamanan, atau pengaturan tertentu. Saat menggunakan label untuk tujuan tersebut, memilih kunci label yang tidak bisa dimodifikasi oleh proses kubelet pada node sangat direkomendasikan. Hal ini mencegah node yang telah diubah untuk menggunakan kredensial kubelet-nya untuk mengatur label-label pada objek nodenya sediri, dan mempengaruhi scheduler untuk menjadwalkan _workload_ ke node yang telah diubah tersebut. + +_Plugin_ penerimaan `NodeRestriction` mencegah kubeletes untuk megatur atau mengubah label dengan awalan `node-restriction.kubernetes.io/`. +Untuk memanfaatkan awalan label untuk isolasi node: + +1. Pastikan kamu menggunakan [_authorizer_ node](/docs/reference/access-authn-authz/node/) dan mengaktifkan [_plugin admission NodeRestriction_(/docs/reference/access-authn-authz/admission-controllers/#noderestriction). + +2. Tambah label dengan awalan `node-restriction.kubernetes.io/` ke objek node kamu, dan gunakan label tersebut pada node _selector_ kamu. Contohnya, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`. + +## Afinitas dan anti-afinitas + +`_Field_ nodeSelector` menyediakan cara yang sangat sederhana untuk membatasi pod ke node dengan label-label tertentu. Fitur afinitas/anti-afinitas saat ini bersifat beta dan memperluas tipe pembatasan yang dapat kamu nyatakan. Peningkatan kunci dari fitur ini adalah + +1. Bahasa yang lebih ekspresif (tidak hanya "AND of exact match") +2. Kamu dapat memberikan indikasi bahwa aturan yang dinyatakan bersifat rendah/preferensi dibanding dengan persyaratan mutlak sehingga jika scheduler tidak dapat memenuhinya, pod tetap akan dijadwalkan +3. Kamu dapat membatasi dengan label pada pod-pod lain yang berjalan pada node (atau domain _topological_ lain), daripada dengan label pada node itu sendiri, yang memungkinkan pengaturan tentang pod yang dapat dan tidak dapat dilokasikan bersama. + +Fitur afinitas terdiri dari dua tipe afinitas yaitu "node afinitas" dan "inter-pod afinitas/anti-afinitas" +Node afinitas adalah seperti `nodeSelector` yang telah ada (tetapi dengam dua kelebihan pertama yang terdaftar di atas), sementara inter-pod afinitas/anti-afinitas membatasi pada label pod daripada label node, seperti yang dijelaskan pada item ketiga pada daftar di atas, sebagai tambahan dari item pertama dan kedua. + +_Field_ `nodeSelector` tetap berjalan seperti biasa, namun pada akhirnya akan ditinggalkan karena afinitas node dapat menyatakan semua yang `nodeSelector` dapat nyatakan. + +### Afinitas node (fitur beta) + +Afinitas node diperkenalkan sebagai fitur alfa pada Kubernetes 1.2. +Afinitas node secara konseptual mirip dengan `nodeSelector` yang memungkinkan kamu untuk membatasi node yang memenuhi syarat untuk penjadwalan pod, berdasarkan label pada node. + +Saat ini ada dia tipe afinitas node, yaitu `requiredDuringSchedulingIgnoredDuringExecution` dan +`preferredDuringSchedulingIgnoredDuringExecution`. Kamu dapat menganggap dua tipe ini sebagai "kuat" dan "lemah" secara berurutan, dalam arti tipe pertama menyatakan peraturan yang *harus* dipenuhi agar pod dapat dijadwalkan pada node (sama seperti `nodeSelector` tetapi menggunakan sintaksis yang lebih ekpresif), sementara tipe kedua menyatakan *preferensi* yang akan dicoba dilaksanakan tetapi tidak akan dijamin oleh scheduler. Bagian "IgnoredDuringExecution" dari nama tipe ini berarti, mirip dengan cara kerja `nodeSelector`, jika label pada node berubah pada _runtime_ yang menyebabkan aturan afinitas pada pod tidak lagi terpenuhi, pod akan tetap berjalan pada node. Pada masa yang akan datang kami berencana menawarkan `requiredDuringSchedulingRequiredDuringExecution` yang akan berjalan seperti `requiredDuringSchedulingIgnoredDuringExecution` hanya saja tipe ini akan mengeluarkan pod dari node yang gagal untuk memenuhi persyaratan afinitas node pod. + +Dengan denikian, contoh dari `requiredDuringSchedulingIgnoredDuringExecution` adalah "hanya jalankan pod pada node dengan Intel CPU" dan contoh dari `preferredDuringSchedulingIgnoredDuringExecution` adalah "coba jalankan set pod ini dalam zona ketersediaan XYZ, tetapi jika tidak memungkinkan, maka biarkan beberapa pod berjalan di tempat lain". + +Afinitas node dinyatakan sebagai _field_ `nodeAffinity` dari _field_ `affinity` pada PodSpec. + +Berikut ini contoh dari pod yang menggunakan afinitas node: + +{{< codenew file="pods/pod-with-node-affinity.yaml" >}} + +Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan. + +Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu. + +Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat. + +Jika kamu menyatakan beberapa `nodeSelectorTerms` yang terkait dengan tipe `nodeAffinity`, maka pod akan dijadwalkan pada node **jika salah satu** dari `nodeSelectorTerms` dapat terpenuhi. + +Jika kamu menyatakan beberapa `matchExpressions` yang terkait dengan `nodeSelectorTerms`, makan pod dapat dijadwalkan pada node **hanya jika semua** `matchExpressions` dapat terpenuhi. + +Jika kamu menghapus atau mengubah label pada node tempat pod dijadwalkan, pod tidak akan dihapus. Dengan kata lain, pemilihan afinitas hanya bekerja pada saat waktu penjadwalan pod. + +_Field_ `weight` pada `preferredDuringSchedulingIgnoredDuringExecution` berada pada rentang nilai 1-100. Untuk setiap node yang memenuhi semua persyaratan penjadwalan (permintaan sumber daya, pernyataan afinitas RequiredDuringScheduling, dll.), _scheduler_ akan menghitung nilai jumlah dengan melakukan iterasi pada elemen-elemen dari _field_ ini dan menambah "bobot" pada jumlah jika node cocok dengan MatchExpressions yang sesuai. Nilai ini kemudian digabungkan dengan nilai dari fungsi prioritas lain untuk node. Node dengan nilai tertinggi adalah node lebih diutamakan. + +Untuk informasi lebih lanjut tentang afinitas node kamu dapat melihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md). + + +### Afinitas and anti-afinitas antar pod (fitur beta) + +Afinitas and anti-afinitas antar pod diperkenalkan pada Kubernetes 1.4. Afinitas and anti-afinitas antar pod memungkinkan kamu untuk membatasi node yang memenuhi syarat untuk penjadwalan pod *berdasarkan label-label pada pod yang sudah berjalan pada node* daripada berdasarkan label-label pada node. Aturan tersebut berbentuk "pod ini harus (atau, dalam kasus +anti-afinitas, tidak boleh) berjalan dalam X jika X itu sudah menjalankan satu atau lebih pod yang memenuhi aturan Y". Y dinyatakan sebagai sebuah LabelSelector dengan daftar namespace terkait; tidak seperti node, karena pod are namespaced (maka dari itu label-label pada pod diberi namespace secara implisit), sebuah label selector di atas label-label pod harus menentukan namespace yang akan diterapkan selector. Secara konsep X adalah domain topologi seperti node, rack, zona penyedia cloud, daerah penyedia cloud, dll. Kamu dapat menyatakannya menggunakan `topologyKey` yang merupakan kunci untuk label node yang digunakan sistem untuk menunjukkan domain topologi tersebut, contohnya lihat kunci label yang terdaftar di atas pada bagian [Selingan: label node built-in](#interlude-built-in-node-labels). + +{{< note >}} +Afinitas and anti-afinitas antar pod membutuhkan jumlah pemrosesan yang substansial yang dapat memperlambat penjadwalan pada kluster berukuran besar secara signifikan. Kami tidak merekomendasikan penggunaan mereka pada kluster yang berukuran lebih besar dari beberapa ratus node. +{{< /note >}} + +{{< note >}} +Anti-afinitas pod mengharuskan node untuk diberi label secara konsisten, misalnya setiap node dalam kluster harus memiliki label sesuai yang cocok dengan `topologyKey`. Jika sebagian atau semua node tidak memiliki label `topologyKey` yang dinyatakan, hal ini dapat menyebabkan perilaku yang tidak diinginkan. +{{< /note >}} + +Seperti afinitas node, ada dua tipe afinitas dan anti-afinitas pod, yaitu `requiredDuringSchedulingIgnoredDuringExecution` dan +`preferredDuringSchedulingIgnoredDuringExecution` yang menunjukan persyaratan "kuat" vs. "lemah". Lihat deskripsi pada bagian afinitas node sebelumnya. +Sebuah contoh dari afinitas `requiredDuringSchedulingIgnoredDuringExecution` adalah "Tempatkan bersamaan pod layanan A dan layanan B di zona yang sama, karena mereka banyak berkomunikasi satu sama lain" +dan contoh `preferDuringSchedulingIgnoredDuringExecution` anti-afinitas akan menjadi "sebarkan pod dari layanan ini di seluruh zona" (persyaratan kuat tidak masuk akal, karena kamu mungkin memiliki lebih banyak pod daripada zona). + +Afinitas antar pod dinyatakan sebagai _field_ `podAffinity` dari _field_ `affinity` pada PodSpec dan anti-afinitas antar pod dinyatakan sebagai _field_ `podAntiAffinity` dari _field_ `affinity` pada PodSpec. + +#### Contoh pod yang menggunakan pod affinity: + +{{< codenew file="pods/pod-with-pod-affinity.yaml" >}} + +Afinitas pada pod tersebut menetapkan sebuah aturan afinitas pod dan aturan anti-afinitas pod. Pada contoh ini, `podAffinity` adalah `requiredDuringSchedulingIgnoredDuringExecution` +sementara `podAntiAffinity` adalah `preferredDuringSchedulingIgnoredDuringExecution`. Aturan afinitas pod menyatakan bahwa pod dapat dijadwalkan pada node hanya jika node tersebut berada pada zona yang sama dengan minimal satu pod yang sudah berjalan yang memiliki label dengan kunci "security" dan bernilai "S1". (Lebih detail, pod dapat berjalan pada node N jika node N memiliki label dengan kunci `failure-domain.beta.kubernetes.io/zone`dan nilai V sehingga ada minimal satu node dalam kluster dengan kunci `failure-domain.beta.kubernetes.io/zone` dan bernilai V yang menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S1".) Aturan anti-afinitas pod menyatakan bahwa pod memilih untuk tidak dijadwalkan pada sebuah node jika node tersebut sudah menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S2". (Jika `topologyKey` adalah `failure-domain.beta.kubernetes.io/zone` maka dapat diartikan bahwa pod tidak dapat dijadwalkan pada node jika node berada pada zona yang sama dengan pod yang memiliki label dengan kunci "security" dan bernilai "S2".) Lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) untuk lebih banyak contoh afinitas dan anti-afinitas pod, baik `requiredDuringSchedulingIgnoredDuringExecution` +maupun `preferredDuringSchedulingIgnoredDuringExecution`. + +Operator yang sah untuk afinitas dan anti-afinitas pod adalah `In`, `NotIn`, `Exists`, `DoesNotExist`. + +Pada dasarnya, `topologyKey` dapat berupa label-kunci apapun yang sah. Namun, untuk alasan performa dan keamanan, ada beberapa batasan untuk `topologyKey`: + +1. Untuk afinitas and anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, `topologyKey` tidak boleh kosong. +2. Untuk anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, pengontrol penerimaan `LimitPodHardAntiAffinityTopology` diperkenalkan untuk membatasi `topologyKey` pada `kubernetes.io/hostname`. Jika kamu menginginkan untuk membuatnya tersedia untuk topologi khusus, kamu dapat memodifikasi pengontrol penerimaan, atau cukup menonaktifkannya saja. +3. Untuk anti-afinitas pod `preferredDuringSchedulingIgnoredDuringExecution`, `topologyKey` yang kosong diinterpretasikan sebagai "semua topologi" ("semua topologi" sekarang dibatasi pada kombinasi dari `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` dan `failure-domain.beta.kubernetes.io/region`). +4. Kecuali untuk kasus-kasus di atas, `topologyKey` dapat berupa label-kunci apapun yang sah. + +Sebagai tambahan untuk `labelSelector` and `topologyKey`, kamu secara opsional dapat menyatakan daftar `namespaces` dari namespaces yang akan digunakan untuk mencocokan `labelSelector` (daftar ini berjalan pada level definisi yang sama dengan `labelSelector` dan `topologyKey`) + +Jika dihilangkan atau kosong, daftar ini sesuai standar akan merujuk pada _namespace_ dari pod tempat definisi afinitas/anti-afinitas dinyatakan. + +Semua `matchExpressions` berkaitan dengan afinitas and anti-afinitas `requiredDuringSchedulingIgnoredDuringExecution` harus dipenuhi agar pod dapat dijadwalkan pada node. + +#### Penggunaan yang lebih praktikal + +Afinitas and anti-afinitas antar pod dapat menjadi lebih berguna saat digunakan bersamaan dengan koleksi dengan level yang lebih tinggi seperti ReplicaSets, StatefulSets, Deployments, dll. Pengguna dapat dengan mudah mengkonfigurasi bahwa satu set workload harus +ditempatkan bersama dalam topologi yang didefinisikan sama, misalnya, node yang sama. + +##### Selalu ditempatkan bersamaan pada node yang sama + +Dalam kluster berisi 3 node, sebuah aplikasi web memiliki in-memory cache seperti redis. Kita menginginkan agar _web-server_ dari aplikasi ini sebisa mungkin ditempatkan bersamaan dengan cache. + +Berikut ini kutipan yaml dari deployment redis sederhana dengan 3 replika dan label selector `app=store`, Deployment memiliki konfigurasi `PodAntiAffinity` untuk memastikan _scheduler_ tidak menempatkan replika bersamaan pada satu node. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-cache +spec: + selector: + matchLabels: + app: store + replicas: 3 + template: + metadata: + labels: + app: store + spec: + affinity: + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - store + topologyKey: "kubernetes.io/hostname" + containers: + - name: redis-server + image: redis:3.2-alpine +``` + +Kutipan yaml dari deployment webserver berikut ini memiliki konfigurasi `podAntiAffinity` dan `podAffinity`. Konfigurasi ini menginformasikan scheduler bahwa semua replika harus ditempatkan bersamaan dengan pod yang memiliki label selector `app=store`. Konfigurasi ini juga memastikan bahwa setiap replika webserver tidak ditempatkan bersamaan pada satu node. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: web-server +spec: + selector: + matchLabels: + app: web-store + replicas: 3 + template: + metadata: + labels: + app: web-store + spec: + affinity: + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - web-store + topologyKey: "kubernetes.io/hostname" + podAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - store + topologyKey: "kubernetes.io/hostname" + containers: + - name: web-app + image: nginx:1.12-alpine +``` + +Jika kita membuat kedua dployment di atas, kluster berisi 3 node kita seharusnya menjadi seperti berikut. + +| node-1 | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| *webserver-1* | *webserver-2* | *webserver-3* | +| *cache-1* | *cache-2* | *cache-3* | + + +st +Seperti yang kamu lihat, semua 3 replika dari `web-server` secara otomatis ditempatkan bersama dengan cache seperti yang diharapkan. + +``` +$ kubectl get pods -o wide +NAME READY STATUS RESTARTS AGE IP NODE +redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3 +redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1 +redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2 +web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1 +web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3 +web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2 +``` + +##### Tidak akan pernah ditempatkan bersamaan dalam node yang sama + + +Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy kluster redis sehingga tidak ada dua instance terletak pada hos yang sama. +Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama. + +Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md). + +Kamu juga dapat mengecek [Taints](/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod. + +## nodeName + +`nodeName` adalah bentuk paling sederhana dari pembatasan pemilihan node, tetapi karena +keterbatasannya biasanya tidak digunakan. `nodeName` adalah sebuah _field_ dari +PodSpec. Jika tidak kosong, scheduler mengabaikan pod dan +kubelet yang berjalan pada node tersebut yang mencoba menjalankan pod. Maka, jika +`nodeName` disediakan dalam PodSpec, ia memiliki hak yang lebih tinggi dibanding metode-metode di atas untuk pemilihan node. + +Beberapa keterbatasan dari penggunaan `nodeName` untuk memilih node adalah: + +- Jika node yang disebut tidak ada, maka pod tidak akan dijalankan, dan dalam beberapa kasus akan + dihapus secara otomatis. +- Jika node yang disebut tidak memiliki resource yang cukup untuk mengakomodasi pod, pod akan gagal + dan alasannya akan mengindikasikan sebab kegagalan, misalnya OutOfmemory atau OutOfcpu. +- Nama node pada lingkungan cloud tidak selalu dapat diprediksi atau stabil. + +Berikut ini contoh konfigurasi pod menggunakan _field_ `nodeName`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - name: nginx + image: nginx + nodeName: kube-01 +``` +Pod di atas akan berjalan pada node kube-01. + +{{% /capture %}} + +{{% capture whatsnext %}} + +{{% /capture %}} diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md new file mode 100644 index 0000000000..5681c4a9e8 --- /dev/null +++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -0,0 +1,89 @@ +--- +title: Pengendali TTL untuk Sumber Daya yang Telah Selesai Digunakan +content_template: templates/concept +weight: 65 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu +objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani +[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/), +dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan +misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya. + +Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifkan dengan +[_feature gate_](/docs/reference/command-line-tools-reference/feature-gates/) +`TTLAfterFinished`. + + +{{% /capture %}} + + + + +{{% capture body %}} + +## Pengendali TTL + +Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator kluster +dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik +`Complete` atau `Failed`) secara otomatis dengan menentukan _field_ +`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di +[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). +Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila +TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini +dilakukan secara berantai, dimana sumber daya lain yang +berkaitan akan ikut terhapus. Perhatikan bahwa ketika sebuah sumber daya dihapus, +siklus hidup yang ada akan menjaga bahwa _finalizer_ akan tetap dijalankan sebagaimana mestinya. + +Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk mengaktifkan _field_ +`.spec.ttlSecondsAfterFinished` pada suatu Job: + +* Spesifikasikan _field_ ini pada _manifest_ sumber daya, sehingga Job akan + dihapus secara otomatis beberapa saat setelah selesai dieksekusi. +* Aktifkan _field_ ini pada sumber daya yang sudah selesai dieksekusi untuk + menerapkan fitur ini. +* Gunakan sebuah + [mengubah (_mutating_) _admission)](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) + untuk mengaktifkan _field_ ini secara dinamis pada saat pembuatan sumber daya. + Administrator kluster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada + sumber daya yang telah selesai digunakan. +* Gunakan sebuah + [mengubah (_mutating_) _admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) + untuk mengaktifkan _field_ ini secara dinamis setelah sumber daya + selesai digunakan dan TTL didefinisikan sesuai dengan status, label, atau hal lain + yang diinginkan. + +## Peringatan + +### Mengubah TTL Detik + +Perhatikan bahwa periode TTL, yaitu _field_ `.spec.ttlSecondsAfterFinished` pada Job, +dapat dimodifikasi baik setelah sumber daya dibuat atau setelah selesai digunakan. +Meskipun begitu, setelah Job dapat dihapus (TTL sudah habis), sistem tidak akan +menjamin Job tersebut akan tetap ada, meskipun nilai TTL berhasil diubah. + +### _Time Skew_ + +Karena pengendali TTL menggunakan cap waktu (_timestamp_) yang disimpan di sumber daya +Kubernetes untuk menentukan apakah TTL sudah habis atau belum, fitur ini tidak sensitif +terhadap _time skew_ yang ada pada kluster dan bisa saja menghapus objek pada waktu yang salah +bagi objek tersebut akibat adanya _time skew_. + +Pada Kubernetes, NTP haruslah dilakukan pada semua node untuk mecegah adanya _time skew_ +(lihat [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)). +_Clock_ tidak akan selalu tepat, meskipun begitu perbedaan yang ada haruslah diminimalisasi. +Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selain 0. + +{{% /capture %}} + +{{% capture whatsnext %}} + +[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) + +[Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) + +{{% /capture %}} diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md new file mode 100644 index 0000000000..cc6c992ab8 --- /dev/null +++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md @@ -0,0 +1,353 @@ +--- +title: Siklus Hidup Pod +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +{{< comment >}}Pembaruan: 4/14/2015{{< /comment >}} +{{< comment >}}Diubah dan dipindahkan ke bagian konsep: 2/2/17{{< /comment >}} + +Halaman ini menjelaskan siklus hidup sebuah Pod + +{{% /capture %}} + + +{{% capture body %}} + +## Fase Pod + +_Field_ `status` dari sebuah Pod merupakan sebuah objek [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core), yang memiliki sebuah _field_ `phase`. + +Fase dari sebuah Pod adalah sesuatu yang sederhana, ringkasan yang lebih tinggi tentang Pod dalam siklus hidupnya. Fase ini tidak ditujukan sebagai sebuah kesimpulan yang luas dari observasi suatu kontainer atau _state_ suatu Pod, serta tidak ditujukan sebagai _state machine_ yang luas. + +Jumlah dan arti dari nilai-nilai fase Pod dijaga ketat. Selain yang ada dalam dokumentasi ini, tidak perlu berasumsi mengenai Pod telah diberikan nilai `phase`. + +Berikut adalah nilai yang mungkin diberikan untuk suatu `phase`: + +Nilai | Deskripsi +:-----|:----------- +`Pending` | Pod telah disetujui oleh sistem Kubernetes, tapi ada satu atau lebih _image_ kontainer yang belum terbuat. Ini termasuk saat sebelum dijadwalkan dan juga saat mengunduh _image_ melalui jaringan, yang mungkin butuh beberapa waktu. +`Running` | Pod telah terikat ke suatu node, dan semua kontainer telah terbuat. Setidaknya ada 1 kontainer yang masih berjalan, atau dalam proses memulai atau _restart_. +`Succeeded` | Semua kontainer di dalam Pod sudah berhasil dihentikan, dan tidak akan dilakukan _restart_. +`Failed` | Semua kontainer dalan suatu Pod telah dihentikan, dan setidaknya ada satu kontainer yang terhenti karena kegagalan. Itu merupakan kontainer yang keluar dengan kode status bukan 0 atau dihentikan oleh sistem. +`Unknown` | _State_ suatu Pod tidak dapat diperoleh karena suatu alasan, biasanya karena kesalahan dalam komunikasi dengan _host_ yang digunakan Pod tersebut. + +## Kondisi Pod + +Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) yang telah atau belum dilewati oleh Pod. Setiap elemen dari _array_ PodConditions mungkin memiliki enam _field_ berikut: + +* _Field_ `lastProbeTime` memberikan nilai _timestamp_ yang menandakan kapan terakhir kali kondisi kondisi Pod diperiksa. + +* _Field_ `lastTransitionTime` memberikan nilai _timestamp_ yang menandakan kapan terakhir kali Pod berubah status ke status lain. + +* _Field_ `message` adalah pesan yang bisa dibaca manusia yang mengidikasikan detail dari suatu transisi. + +* _Field_ `reason` adalah suatu alasan yang unik, satu kata, ditulis secara _CamelCase_ untuk kondisi transisi terakhir. + +* _Field_ `status` adalah sebuah kata dengan kemungkinan nilainya berupa "`True`", "`False`", dan "`Unknown`". + +* _Field_ `type` adalah sebuah kata yang memiliki kemungkinan nilai sebagai berikut: + + * `PodScheduled`: Pod telah dijadwalkan masuk ke node; + * `Ready`: Pod sudah mampu menerima _request_ masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama; + * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna. + * `Unschedulable`: _scheduler_ belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan _resources_ atau ada batasan-batasan lain. + * `ContainersReady`: Semua kontainer di dalam Pod telah siap. + + +## Pemeriksaan Kontainer + +Sebuah [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) adalah sebuah diagnosa yang dilakukan secara berkala oleh [kubelet](/docs/admin/kubelet/) dalam suatu kontainer. Untuk melakukan diagnosa, kubelet memanggil sebuah [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) yang diimplementasikan oleh kontainer. Ada 3 tipe _Handler_ yang tersedia, yaitu: + +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): Mengeksekusi perintah tertentu di dalam kontainer. Diagnosa dikatakan berhasil jika perintah selesai dengan kode status 0. + +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): Melakukan pengecekan TCP terhadap alamat IP kontainer dengan _port_ tertentu. Diagnosa dikatakan berhasil jika _port_ tersebut terbuka. + +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): Melakukan sebuah _request_ HTTP Get terhadap alamat IP kontainer dengan _port_ dan _path_ tertentu. Diagnosa dikatakan berhasil jika responnya memiliki kode status lebih besar atau sama dengan 200 dan kurang dari 400. + +Setiap pemeriksaan akan menghasilkan salah satu dari tiga hasil berikut: + +* _Success_: Kontainer berhasil melakukan diagnosa. +* _Failure_: Kontainer gagal melakukan diagnosa. +* _Unknown_: Gagal melakukan diagnosa, sehingga tidak ada aksi yang harus dilakukan. + +_Kubelet_ dapat secara optimal melakukan dan bereaksi terhadap dua jenis pemeriksaan yang sedang berjalan pada kontainer, yaitu: + +* `livenessProbe`: Ini menunjukkan apakah kontainer sedang berjalan. Jika tidak berhasil melakukan pemeriksaan terhadap _liveness_ dari kontainer, maka kubelet akan mematikan kontainer, dan kontainer akan mengikuti aturan dari [_restart policy_](#restart-policy). Jika kontainer tidak menyediakan pemeriksaan terhadap _liveness_, maka nilai dari _state_ adalah `Success`. + +* `readinessProbe`: Ini menunjukan apakah kontainer sudah siap melayani _request_. Jika tidak berhasil melakukan pemeriksaan terhadap kesiapan dari kontainer, maka _endpoints controller_ akan menghapus alamat IP Pod dari daftar semua _endpoint_ untuk servis yang sama dengan Pod. Nilai awal _state_ sebelum jeda awal adalah `Failure`. Jika kontainer tidak menyediakan pemeriksaan terhadap _readiness_, maka nilai awal _state_ adalah `Success`. + +### Kapan sebaiknya menggunakan pemeriksaan terhadap _liveness_ atau _readiness_? + +Jika proses dalam kontainer mungkin gagal yang dikarenakan menghadapi suatu masalah +atau menjadi tidak sehat, maka pemeriksaan terhadap _liveness_ tidak diperlukan. +Kubelet akan secara otomatis melakukan aksi yang tepat mengikuti `restartPolicy` dari Pod. + +Jika kamu ingin kontainer bisa dimatikan dan dijalankan ulang ketika gagal melakukan +pemeriksaan, maka tentukan pemeriksaan _liveness_ dan tentukan nilai `restartPolicy` sebagai `Always` atau `OnFailure`. + +Jika kamu ingin mulai mengirim _traffic_ ke Pod hanya ketika pemeriksaan berhasil, +maka tentukan pemeriksaan _readiness_. Dalam kasus ini, pemeriksaan _readiness_ mungkin +akan sama dengan pemeriksaan _liveness_, tapi keberadaan pemeriksaan _readiness_ dalam +_spec_ berarti Pod akan tetap dijalankan tanpa menerima _traffic_ apapun dan akan +mulai menerima _traffic_ ketika pemeriksaan yang dilakukan mulai berhasil. +Jika kontainermu dibutuhkan untuk tetap berjalan ketika _loading_ data yang besar, +_file_ konfigurasi, atau melakukan migrasi ketika _startup_, maka tentukanlah pemeriksaan _readiness_. + +Jika kamu ingin kontainermu dalam mematikan dirinya sendiri, kamu dapat menentukan +suatu pemeriksaan _readiness_ yang melakukan pengecekan terhadap _endpoint_ untuk _readiness_. +_endpoint_ tersebut berbeda dengan _endpoint_ untuk pengecekan _liveness_. + +Perlu dicatat, jika kamu hanya ingin bisa menutup _request_ ketika Pod sedang dihapus +maka kamu tidak perlu menggunakan pemeriksaan _readiness_. Dalam penghapusan, Pod akan +secara otomatis mengubah _state_ dirinya menjadi _unready_ tanpa peduli apakah terdapat +pemeriksaan _readiness_ atau tidak. Pod tetap ada pada _state unready_ selama menunggu +kontainer dalam Pod berhenti. + +Untuk informasi lebih lanjut mengenai pengaturan pemeriksaan _liveness_ atau _readiness_, lihat bagian +[Konfigurasi _Liveness_ dan _Readiness_ _Probe_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). + +## Status Pod dan Kontainer + +Untuk informasi lebih mendalam mengenai status Pod dan kontainer, silakan lihat +[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +dan +[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). +Mohon diperhatikan, informasi tentang status Pod bergantung pada +[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). + +## State Kontainer + +Ketika Pod sudah ditempatkan pada suatu node oleh scheduler, kubelet mulai membuat kontainer menggunakan _runtime_ kontainer. +Ada tiga kemungkinan _state_ untuk suatu kontainer, yaitu Waiting, Running, dan Terminated. +Untuk mengecek _state_ suatu kontainer, kamu bisa menggunakan perintah `kubectl describe pod [NAMA_POD]`. +_State_ akan ditampilkan untuk masing-masing kontainer dalam Pod tersebut. + +* `Waiting`: Merupakan _state_ default dari kontainer. Jika _state_ kontainer bukan Running atau Terminated, berarti dalam _Wating state_. +Suatu kontainer dalam Waiting _state_ akan tetap menjalan operasi-operasi yang dibutuhkan, misalnya mengunduh _images_, mengaplikasikan Secrets, dsb. +Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditampilkan untuk memberi informasi lebih. + + ```yaml + ... + State: Waiting + Reason: ErrImagePull + ... + ``` + +* `Running`: Menandakan kontainer telah berjalan tanpa masalah. Setelah kontainer masuk ke _state_ Running, jika terdapat _hook_ `postStart` maka akan dijalankan. _State_ ini juga menampilkan waktu ketika kontainer masuk ke _state_ Running. + + ```yaml + ... + State: Running + Started: Wed, 30 Jan 2019 16:46:38 +0530 + ... + ``` + +* `Terminated`: Menandakan kontainer telah menyelesaikan "tugasnya". Kontainer akan menjadi _state_ ini ketika telah menyelesaikan eksekusi atau terjadi kesalahan. Terlepas dari itu, sebuah alasan dan _exit code_ akan ditampilkan, bersama dengan waktu kontainer mulai dijalankan dan waktu berhenti. Sebelum kontainer masuk ke _state_ Terminated, jika terdapat `preStop` _hook_ maka akan dijalankan. + + ```yaml + ... + State: Terminated + Reason: Completed + Exit Code: 0 + Started: Wed, 30 Jan 2019 11:45:26 +0530 + Finished: Wed, 30 Jan 2019 11:45:26 +0530 + ... + ``` + +## Pod readiness gate + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +Dalam rangka menambahkan ekstensibilitas terhadap kesiapan Pod dengan menggunakan +injeksi umpan balik tambahan atau sinyal ke dalam `PodStatus`, +Kubernetes 1.11 memperkenalkan sebuah fitur bernama [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md). +Kamu dapat menggunakan _field_ baru `ReadinessGate` dalam sebuah `PodSpec` untuk +menunjukan kondisi tambahan yang akan dievaluasi untuk kesiapan Pod. Jika Kubernetes +tidak dapat menemukan kondisi pada _field_ `status.conditions` dalam suatu Pod, +maka statusnya akan secara otomatis menjadi `False`. Berikut adalah contoh pemakaiannya: + +```yaml +Kind: Pod +... +spec: + readinessGates: + - conditionType: "www.example.com/feature-1" +status: + conditions: + - type: Ready # ini adalah PodCondition yang telah tersedia + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + - type: "www.example.com/feature-1" # sebuah PodCondition tambahan + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + containerStatuses: + - containerID: docker://abcd... + ready: true +... +``` + +Kondisi Pod yang baru harus memenuhi [format label](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes. +Sejak perintah `kubectl patch` belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi `PATCH` dengan menggunakan +salah satu dari [KubeClient _libraries_](/docs/reference/using-api/client-libraries/). + +Dengan diperkenalkannya kondisi Pod yang baru, sebuah Pod akan dianggap siap hanya jika memenuhi dua syarat berikut: + +* Semua kontainer dalam Pod telah siap. +* Semua kontainer yang diatur dalam `ReadinessGates` bernilai "`True`". + + +Untuk memfasilitasi perubahan tersebut terhadap evaluasi kesiapan Pod, dibuatkan sebuah kondisi Pod baru yaitu `ContainerReady`, +untuk dapat menangani kondisi Pod `Ready` yang sudah ada. + +Dalam K8s 1.11, sebagai fitur _alpha_, fitur "Pod Ready++" harus diaktifkan melalui pengaturan + [fitur _gate_ pada `PodReadinessGates`](/docs/reference/command-line-tools-reference/feature-gates/). + +Dalam K8s 1.12, fitur tersebut sudah diaktifkan dari awal. + + +## Aturan Menjalankan Ulang + +Sebuah PodSpec memiliki _field_ `restartPolicy` dengan kemungkinan nilai berupa Always, OnFailure, dan Never. +Nilai awalnya berupa Always. `restartPolicy` akan berlaku untuk semua kontainer dalam Pod. +Kontainer yang mati dan dijalankan ulang oleh kubelet akan dijalankan ulang dengan jeda waktu yang ekponensial (10s, 20s, 40s, ...) +dengan batas atas senilai lima menit. Jeda waktu ini akan diatur ulang setelah sukses berjalan selama 10 menit. +Sesuai dengan diskusi pada [dokumen Pod](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), +setelah masuk ke suatu node, sebuah Pod tidak akan pindah ke node lain. + +## Umur Pod + +Secara umum, Pod tidak hilang sampai ada yang menghapusnya. Ini mungkin dihapus oleh orang atau pengontrol. +Satu pengecualian untuk aturan ini adalah Pod dengan `phase` bernilai Succeeded atau Failed untuk waktu +beberapa lama yang akan berakhir dan secara otomatis akan dihapus. +(diatur dalam `terminated-pod-gc-threshold` pada master) + +Tiga tipe pengontrol yang tersedia yaitu: + +- Menggunakan sebuah [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) untuk Pod yang diharapkan akan berakhir, + sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang + bernilai OnFailure atau Never. + +- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/), + [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau + [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir, + sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy` + yang bernilai Always. + +- Menggunakan sebuah [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan + hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin. + + +Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk membuat +pengontrol yang sesuai dan membiarkan ini membuat Pod, daripada membuat Pod sendiri secara langsung. +Karena Pod itu sendiri tidak tahan terhadap gagalnya suatu mesin, namun pengontrol tahan. + +Jika node mati atau sambungannya terputus dari kluster, Kubernetes mengatur +`phase` dari semua Pod pada node yang mati untuk menjadi Failed. + +## Contoh + +### Contoh _Liveness Probe_ tingkat lanjut + +_Liveness probe_ dieksekusi oleh kubelet, jadi semua permintaan akan dilakukan +di dalam _namespace_ jaringan kubelet. + + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + test: liveness + name: liveness-http +spec: + containers: + - args: + - /server + image: k8s.gcr.io/liveness + livenessProbe: + httpGet: + # ketika "host" tidak ditentukan, "PodIP" akan digunakan + # host: my-host + # ketika "scheme" tidak ditentukan, _scheme_ "HTTP" akan digunakan. Hanya "HTTP" and "HTTPS" yang diperbolehkan + # scheme: HTTPS + path: /healthz + port: 8080 + httpHeaders: + - name: X-Custom-Header + value: Awesome + initialDelaySeconds: 15 + timeoutSeconds: 1 + name: liveness +``` + +### Contoh _State_ + + + * Pod sedang berjalan dan memiliki sebuah kontainer. Kontainer berhenti dengan sukses. + * Mencatat _event_ penyelesaian. + * Jika nilai `restartPolicy` adalah: + * Always: Jalankan ulang kontainer; nilai `phase` Pod akan tetap Running. + * OnFailure: nilai `phase` Pod akan berubah menjadi Succeeded. + * Never: nilai `phase` Pod akan berubah menjadi Succeeded. + + * Pod sedang berjalan dan memiliki sebuah kontainer. Kontainer berhenti dengan kegagalan. + * Mencatat _event_ kegagalan. + * Jika nilai `restartPolicy` adalah: + * Always: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * OnFailure: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * Never: nilai `phase` Pod akan menjadi Failed. + + * Pod sedang berjalan dan memiliki dua kontainer. Kontainer pertama berhenti dengan kegagalan. + * Mencatat _event_ kegagalan. + * Jika nilai `restartPolicy` adalah: + * Always: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * OnFailure: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * Never: Tidak akan menjalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * Jika kontainer pertama tidak berjalan dan kontainer kedua berhenti: + * Mencatat _event_ kegagalan. + * Jika nilai `restartPolicy` adalah: + * Always: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * OnFailure: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * Never: nilai `phase` Pod akan menjadi Failed. + + * Pod sedang berjalan dan memiliki satu kontainer. Kontainer berhenti karena kehabisan _memory_. + * Kontainer diberhentikan dengan kegagalan. + * Mencatat kejadian kehabisan _memory_ (OOM) + * Jika nilai `restartPolicy` adalah: + * Always: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * OnFailure: Jalankan ulang kontainer, nilai `phase` Pod akan tetap Running. + * Never: Mencatat kejadian kegagalan, nilai `phase` Pod akan menjadi Failed. + + * Pod sedang berjalan dan sebuah _disk_ mati. + * Menghentikan semua kontainer. + * Mencatat kejadian yang sesuai. + * Nilai `phase` Pod menjadi Failed. + * Jika berjalan menggunakan pengontrol, maka Pod akan dibuat ulang di tempat lain. + + * Pod sedang berjalan, dan node mengalami _segmented out_. + * Node pengontrol menunggu sampai suatu batas waktu. + * Node pengontrol mengisi nilai `phase` Pod menjadi Failed. + * Jika berjalan menggunakan pengontrol, maka Pod akan dibuat ulang di tempat lain. + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* Dapatkan pengalaman langsung mengenai + [penambahan _handlers_ pada kontainer _lifecycle events_](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). + +* Dapatkan pengalaman langsung mengenai + [pengaturan _liveness_ dan _readiness probes_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). + +* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/docs/concepts/containers/container-lifecycle-hooks/). + +{{% /capture %}} + + + diff --git a/content/id/examples/admin/logging/fluentd-sidecar-config.yaml b/content/id/examples/admin/logging/fluentd-sidecar-config.yaml new file mode 100644 index 0000000000..eea1849b03 --- /dev/null +++ b/content/id/examples/admin/logging/fluentd-sidecar-config.yaml @@ -0,0 +1,25 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: fluentd-config +data: + fluentd.conf: | + + type tail + format none + path /var/log/1.log + pos_file /var/log/1.log.pos + tag count.format1 + + + + type tail + format none + path /var/log/2.log + pos_file /var/log/2.log.pos + tag count.format2 + + + + type google_cloud + diff --git a/content/id/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/id/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml new file mode 100644 index 0000000000..b37b616e6f --- /dev/null +++ b/content/id/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml @@ -0,0 +1,39 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-agent + image: k8s.gcr.io/fluentd-gcp:1.30 + env: + - name: FLUENTD_ARGS + value: -c /etc/fluentd-config/fluentd.conf + volumeMounts: + - name: varlog + mountPath: /var/log + - name: config-volume + mountPath: /etc/fluentd-config + volumes: + - name: varlog + emptyDir: {} + - name: config-volume + configMap: + name: fluentd-config diff --git a/content/id/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml b/content/id/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml new file mode 100644 index 0000000000..87bd198cfd --- /dev/null +++ b/content/id/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-1 + image: busybox + args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-2 + image: busybox + args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/id/examples/admin/logging/two-files-counter-pod.yaml b/content/id/examples/admin/logging/two-files-counter-pod.yaml new file mode 100644 index 0000000000..6ebeb717a1 --- /dev/null +++ b/content/id/examples/admin/logging/two-files-counter-pod.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/id/examples/debug/counter-pod.yaml b/content/id/examples/debug/counter-pod.yaml new file mode 100644 index 0000000000..f997886386 --- /dev/null +++ b/content/id/examples/debug/counter-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: [/bin/sh, -c, + 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'] diff --git a/content/id/examples/pods/pod-nginx.yaml b/content/id/examples/pods/pod-nginx.yaml new file mode 100644 index 0000000000..134ddae2aa --- /dev/null +++ b/content/id/examples/pods/pod-nginx.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + nodeSelector: + disktype: ssd diff --git a/content/id/examples/pods/pod-with-node-affinity.yaml b/content/id/examples/pods/pod-with-node-affinity.yaml new file mode 100644 index 0000000000..253d2b21ea --- /dev/null +++ b/content/id/examples/pods/pod-with-node-affinity.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: with-node-affinity +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/e2e-az-name + operator: In + values: + - e2e-az1 + - e2e-az2 + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: another-node-label-key + operator: In + values: + - another-node-label-value + containers: + - name: with-node-affinity + image: k8s.gcr.io/pause:2.0 \ No newline at end of file diff --git a/content/id/examples/pods/pod-with-pod-affinity.yaml b/content/id/examples/pods/pod-with-pod-affinity.yaml new file mode 100644 index 0000000000..35e645ef1f --- /dev/null +++ b/content/id/examples/pods/pod-with-pod-affinity.yaml @@ -0,0 +1,29 @@ +apiVersion: v1 +kind: Pod +metadata: + name: with-pod-affinity +spec: + affinity: + podAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: security + operator: In + values: + - S1 + topologyKey: failure-domain.beta.kubernetes.io/zone + podAntiAffinity: + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 100 + podAffinityTerm: + labelSelector: + matchExpressions: + - key: security + operator: In + values: + - S2 + topologyKey: failure-domain.beta.kubernetes.io/zone + containers: + - name: with-pod-affinity + image: k8s.gcr.io/pause:2.0 diff --git a/content/ja/case-studies/chinaunicom/chinaunicom_featured_logo.png b/content/ja/case-studies/chinaunicom/chinaunicom_featured_logo.png new file mode 100644 index 0000000000..f90ff1e509 Binary files /dev/null and b/content/ja/case-studies/chinaunicom/chinaunicom_featured_logo.png differ diff --git a/content/ja/case-studies/chinaunicom/index.html b/content/ja/case-studies/chinaunicom/index.html new file mode 100644 index 0000000000..561c47e0d3 --- /dev/null +++ b/content/ja/case-studies/chinaunicom/index.html @@ -0,0 +1,104 @@ +--- +title: China Unicom Case Study + +linkTitle: chinaunicom +case_study_styles: true +cid: caseStudies +css: /css/style_case_studies.css +logo: chinaunicom_featured_logo.png +featured: true +weight: 1 +quote: > + Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところこれに代わるテクノロジーはありません。 +--- + +
+

ケーススタディ:
China Unicom社:KubernetesによるITコスト削減と効率性向上をいかにして実現したか
+ +

+ +
+ +
+ 企業名  China Unicom     所在地 中国、北京     業界 テレコム +
+ +
+
+
+
+

課題

+ China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 VMWareOpenStackのインフラやDockerによるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。 +

+ +

ソリューション

+ 急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところこれに代わるテクノロジーはありません。」また、China Unicomはそのマイクロサービスフレームワークのために、IstioEnvoyCoreDNS、そしてFluentdも活用しています。 +

+

インパクト

+ KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。 +リソース使用率は20〜50%上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。 + +
+ +
+
+
+
+ 「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところこれに代わるテクノロジーはありません。」 +
- Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー
+
+
+
+
+

China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。

+ + その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」 +

+ そこで新しいテクノロジー、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。 +
+
+
+
+ 「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」
- Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー
+ +
+
+
+
+ China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。

+ + 同社のKubernetes対応クラウドプラットフォームは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単にテクノロジーが利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。

+ + 「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところこれに代わるテクノロジーはありません。」 + +
+
+
+
+ 「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」

- Jie Jia、China Unicom プラットフォーム技術 R&D
+
+
+ +
+
+ 事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50%上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」

+ China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。 +
+ +
+
+「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こういったテクノロジーはすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」

- Jie Jia、China Unicom プラットフォーム技術 R&D
+
+ +
+ プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブテクノロジーは比較的シンプルなのではないか」と指摘しています。

+ 「企業は Rancher のような事業者が提供するマネージドサービスを活用することができます。こういったテクノロジーはカスタマイズてされて提供されるので、簡単に利用することができるでしょう。」

+ + 今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。

+ + それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」 + +
+
+ + diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index ae27b0842a..62cc04cb7a 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -7,7 +7,7 @@ weight: 40 {{% capture overview %}} -The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your cluster, and helps you obtain a deeper understanding of how Kubernetes works. +本セクションは、Kubernetesシステムの各パートと、クラスターを表現するためにKubernetesが使用する抽象概念について学習し、Kubernetesの仕組みをより深く理解するのに役立ちます。 {{% /capture %}} @@ -15,61 +15,61 @@ The Concepts section helps you learn about the parts of the Kubernetes system an ## 概要 -To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state. +Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired sate (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。 -Once you've set your desired state, the *Kubernetes Control Plane* works to make the cluster's current state match the desired state. To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster: +一旦desired state (望ましい状態)を設定すると、*Kubernetes コントロールプレーン* が働き、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。 -* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/). -* Each individual non-master node in your cluster runs two processes: - * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master. - * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node. +* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。 +* クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。 + * **[kubelet](/docs/admin/kubelet/)**, Kubernetes Masterと通信します。 + * **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。 ## Kubernetesオブジェクト -Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details. +Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクト概要](/docs/concepts/abstractions/overview/) をご覧ください。 -The basic Kubernetes objects include: +基本的なKubernetesのオブジェクトは次のとおりです。 -* [Pod](/docs/concepts/workloads/pods/pod-overview/) +* [Pod](/ja/docs/concepts/workloads/pods/pod-overview/) * [Service](/docs/concepts/services-networking/service/) * [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) +* [Namespace](/ja/docs/concepts/overview/working-with-objects/namespaces/) -In addition, Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features. They include: +上記に加え、Kubernetesにはコントローラーと呼ばれる多くの高レベルの抽象概念が含まれています。コントローラーは基本オブジェクトに基づいて構築され、以下のような追加の機能と便利な機能を提供します。 -* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) +* [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) * [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) +* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/) * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## Kubernetesコントロールプレーン -The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. +Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。 -For example, when you use the Kubernetes API to create a Deployment object, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state. +たとえば、Kubernetes APIを使用してDeploymentオブジェクトを作成する場合、システムには新しいdesired state (望ましい状態)が提供されます。Kubernetesコントロールプレーンは、そのオブジェクトの作成を記録します。そして、要求されたアプリケーションの開始、およびクラスターノードへのスケジューリングにより指示を完遂します。このようにしてクラスターの実際の状態を望ましい状態に一致させます。 ### Kubernetesマスター -The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master. +Kubernetesのマスターは、クラスターの望ましい状態を維持する責務を持ちます。`kubectl` コマンドラインインターフェイスを使用するなどしてKubernetesとやり取りするとき、ユーザーは実際にはクラスターにあるKubernetesのマスターと通信しています。 -> The "master" refers to a collection of processes managing the cluster state. Typically these processes are all run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. +「マスター」とは、クラスター状態を管理するプロセスの集合を指します。通常これらのプロセスは、すべてクラスター内の単一ノードで実行されます。このノードはマスターとも呼ばれます。マスターは、可用性と冗長性のために複製することもできます。 ### Kubernetesノード -The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly. +クラスターのノードは、アプリケーションとクラウドワークフローを実行するマシン(VM、物理サーバーなど)です。Kubernetesのマスターは各ノードを制御します。運用者自身がノードと直接対話することはほとんどありません。 #### オブジェクトメタデータ -* [Annotations](/docs/concepts/overview/working-with-objects/annotations/) +* [Annotations](/ja/docs/concepts/overview/working-with-objects/annotations/) {{% /capture %}} {{% capture whatsnext %}} -If you would like to write a concept page, see -[Using Page Templates](/docs/home/contribute/page-templates/) -for information about the concept page type and the concept template. +コンセプトページを追加したい場合は、 +[ページテンプレートの使用](/docs/home/contribute/page-templates/) +のコンセプトページタイプとコンセプトテンプレートに関する情報を確認してください。 {{% /capture %}} diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md new file mode 100755 index 0000000000..ad442f3ab3 --- /dev/null +++ b/content/ja/docs/concepts/containers/_index.md @@ -0,0 +1,5 @@ +--- +title: "Containers" +weight: 40 +--- + diff --git a/content/ja/docs/concepts/containers/container-environment-variables.md b/content/ja/docs/concepts/containers/container-environment-variables.md new file mode 100644 index 0000000000..1057cc0518 --- /dev/null +++ b/content/ja/docs/concepts/containers/container-environment-variables.md @@ -0,0 +1,55 @@ +--- +title: コンテナ環境変数 +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +このページでは、コンテナ環境で利用可能なリソースについて説明します。 + +{{% /capture %}} + + +{{% capture body %}} + +## コンテナ環境 + +Kubernetesはコンテナにいくつかの重要なリソースを提供します。 + +* イメージと1つ以上のボリュームの組み合わせのファイルシステム +* コンテナ自体に関する情報 +* クラスター内の他のオブジェクトに関する情報 + +### コンテナ情報 + +コンテナの *ホスト名* は、コンテナが実行されているPodの名前です。 +ホスト名は`hostname`コマンドまたはlibcの[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html)関数呼び出しにより利用可能です。 + +Podの名前と名前空間は[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)を通じて環境変数として利用可能です。 + +Pod定義からのユーザー定義の環境変数もコンテナで利用できます。 +Dockerイメージで静的に指定されている環境変数も同様です。 + +### クラスター情報 + +コンテナの作成時に実行されていたすべてのサービスのリストは、環境変数として使用できます。 +これらの環境変数はDockerリンクの構文と一致します。 + +*bar* という名前のコンテナに対応する *foo* という名前のサービスの場合、以下の変数が定義されています。 + +```shell +FOO_SERVICE_HOST=<サービスが実行されているホスト> +FOO_SERVICE_PORT=<サービスが実行されているポート> +``` + +サービスは専用のIPアドレスを持ち、[DNSアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)が有効の場合、DNSを介してコンテナで利用可能です。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [コンテナライフサイクルフック](/docs/concepts/containers/container-lifecycle-hooks/)の詳細 +* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン + +{{% /capture %}} diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000..4eb737ff15 --- /dev/null +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,104 @@ +--- +title: コンテナライフサイクルフック +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +このページでは、kubeletにより管理されるコンテナがコンテナライフサイクルフックフレームワークを使用して、管理ライフサイクル中にイベントによって引き起こされたコードを実行する方法について説明します。 + +{{% /capture %}} + + +{{% capture body %}} + +## 概要 + +Angularなどのコンポーネントライフサイクルフックを持つ多くのプログラミング言語フレームワークと同様に、Kubernetesはコンテナにライフサイクルフックを提供します。 +フックにより、コンテナは管理ライフサイクル内のイベントを認識し、対応するライフサイクルフックが実行されたときにハンドラーに実装されたコードを実行できます。 + +## コンテナフック + +コンテナに公開されている2つのフックがあります。 + +`PostStart` + +このフックはコンテナが作成された直後に実行されます。 +しかし、フックがコンテナのENTRYPOINTの前に実行されるという保証はありません。 +ハンドラーにパラメーターは渡されません。 + +`PreStop` + +このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナが既に終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。 +これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 +ハンドラーにパラメーターは渡されません。 + +終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。 + +### フックハンドラーの実装 + +コンテナは、フックのハンドラーを実装して登録することでそのフックにアクセスできます。 +コンテナに実装できるフックハンドラーは2種類あります。 + +* Exec - コンテナのcgroupsと名前空間の中で、 `pre-stop.sh`のような特定のコマンドを実行します。 +コマンドによって消費されたリソースはコンテナに対してカウントされます。 +* HTTP - コンテナ上の特定のエンドポイントに対してHTTP要求を実行します。 + +### フックハンドラーの実行 + +コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはそのフック用に登録されたコンテナ内のハンドラーを実行します。 + +フックハンドラーの呼び出しは、コンテナを含むPodのコンテキスト内で同期しています。 +これは、`PostStart`フックの場合、コンテナのENTRYPOINTとフックは非同期に起動することを意味します。 +しかし、フックの実行に時間がかかりすぎたりハングしたりすると、コンテナは`running`状態になることができません。 + +その振る舞いは `PreStop`フックに似ています。 +実行中にフックがハングした場合、Podフェーズは`Terminating`状態に留まり、Podの`terminationGracePeriodSeconds`が終了した後に終了します。 +`PostStart`または`PreStop`フックが失敗した場合、コンテナを強制終了します。 + +ユーザーはフックハンドラーをできるだけ軽量にするべきです。 +ただし、コンテナを停止する前に状態を保存する場合など、長時間実行されるコマンドが意味をなす場合があります。 + +### フック配送保証 + +フックの配送は *少なくとも1回* を意図しています。これはフックが`PostStart`や`PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。 +これを正しく処理するのはフックの実装次第です。 + +通常、単一の配送のみが行われます。 +たとえば、HTTPフックレシーバーがダウンしていてトラフィックを受け取れない場合、再送信は試みられません。 +ただし、まれに二重配送が発生することがあります。 +たとえば、フックの送信中にkubeletが再起動した場合、kubeletが起動した後にフックが再送信される可能性があります。 + +### フックハンドラーのデバッグ + +フックハンドラーのログは、Podのイベントには表示されません。 +ハンドラーが何らかの理由で失敗した場合は、イベントをブロードキャストします。 +`PostStart`の場合、これは`FailedPostStartHook`イベントで、`PreStop`の場合、これは`FailedPreStopHook`イベントです。 +これらのイベントは `kubectl describe pod `を実行することで見ることができます。 +このコマンドの実行によるイベントの出力例をいくつか示します。 + +``` +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 + 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 + 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 + 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" + 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [コンテナ環境](/docs/concepts/containers/container-environment-variables/)の詳細 +* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン + + +{{% /capture %}} diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md new file mode 100644 index 0000000000..8d9c72aca2 --- /dev/null +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -0,0 +1,142 @@ +--- +reviewers: +title: ランタイムクラス(Runtime Class) +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.14" state="beta" >}} + +このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。 + +{{< warning >}} +RuntimeClassはKubernetes1.14のβ版アップグレードにおいて*破壊的な* 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、[RuntimeClassのα版からβ版へのアップグレード](#upgrading-runtimeclass-from-alpha-to-beta)を参照してください。 +{{< /warning >}} + +{{% /capture %}} + + +{{% capture body %}} + +## RuntimeClassについて + +RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。 + +### セットアップ + +RuntimeClass機能のFeature Gateが有効になっていることを確認してください(デフォルトで有効です)。Feature Gateを有効にする方法については、[Feature +Gates](/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 +その`RuntimeClass`のFeature GateはApiServerとkubeletのどちらも有効になっていなければなりません。 + +1. ノード上でCRI実装を設定する。(ランタイムに依存) +2. 対応するRuntimeClassリソースを作成する。 + +#### 1. ノード上でCRI実装を設定する。 + +RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。 +ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 + +{{< note >}} +RuntimeClassは現時点において、クラスター全体で同じ種類のNode設定であることを仮定しています。(これは全てのNodeがコンテナランタイムに関して同じ方法で構成されていることを意味します)。 +設定が異なるNodeに関しては、スケジューリング機能を通じてRuntimeClassとは独立して管理されなくてはなりません。([PodをNodeに割り当てる方法](/docs/concepts/configuration/assign-pod-node/)を参照して下さい)。 +{{< /note >}} + +RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。 + +#### 2. 対応するRuntimeClassリソースを作成する + +ステップ1にて設定する各項目は、関連する`ハンドラー` 名を持ちます。それはどの設定かを指定するものです。各ハンドラーにおいて、対応するRuntimeClassオブジェクトが作成されます。 + +そのRuntimeClassリソースは現時点で2つの重要なフィールドを持ちます。それはRuntimeClassの名前(`metadata.name`)とハンドラー(`handler`)です。そのオブジェクトの定義は下記のようになります。 + +```yaml +apiVersion: node.k8s.io/v1beta1 # RuntimeClassはnode.k8s.ioというAPIグループで定義されます。 +kind: RuntimeClass +metadata: + name: myclass # RuntimeClass名 + # RuntimeClassはネームスペースなしのリソースです。 +handler: myconfiguration # 対応するCRI設定 +``` + +{{< note >}} +RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター管理者のみに制限されることを推奨します。 +これはたいていデフォルトで有効となっています。さらなる詳細に関しては[Authorization +Overview](/docs/reference/access-authn-authz/authorization/)を参照してください。 +{{< /note >}} + +### 使用例 + +一度RuntimeClassがクラスターに対して設定されると、それを使用するのは非常に簡単です。PodSpecの`runtimeClassName`を指定してください。 +例えば + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + runtimeClassName: myclass + # ... +``` + +これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。 +エラーメッセージに関しては対応する[イベント](/docs/tasks/debug-application-cluster/debug-application-introspection/)を参照して下さい。 + +もし`runtimeClassName`が指定されていない場合、デフォルトのRuntimeHandlerが使用され、これはRuntimeClassの機能が無効であるときのふるまいと同じものとなります。 + +### CRIの設定 + +CRIランタイムのセットアップに関するさらなる詳細は、[CRIのインストール](/docs/setup/cri/)を参照してください。 + +#### dockershim + +Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラーをサポートしていません。 + +#### [containerd](https://containerd.io/) + +ランタイムハンドラーは、`/etc/containerd/config.toml`にあるcontainerdの設定ファイルにより設定されます。 +正しいハンドラーは、その`runtime`セクションで設定されます。 + +``` +[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +``` + +containerdの設定に関する詳細なドキュメントは下記を参照してください。 +https://github.com/containerd/cri/blob/master/docs/config.md + +#### [cri-o](https://cri-o.io/) + +ランタイムハンドラーは、`/etc/crio/crio.conf`にあるcri-oの設定ファイルにより設定されます。 +正しいハンドラーは[crio.runtime +table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)で設定されます。 + +``` +[crio.runtime.runtimes.${HANDLER_NAME}] + runtime_path = "${PATH_TO_BINARY}" +``` + +cri-oの設定に関する詳細なドキュメントは下記を参照してください。 +https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go + + +### RutimeClassをα版からβ版にアップグレードする + +RuntimeClassのβ版の機能は、下記の変更点を含みます。 + +- `node.k8s.io`APIグループと`runtimeclasses.node.k8s.io`リソースはCustomResourceDefinitionからビルトインAPIへとマイグレーションされました。 +- `spec`はRuntimeClassの定義内にインライン化されました(RuntimeClassSpecはすでにありません)。 +- `runtimeHandler`フィールドは`handler`にリネームされました。 +- `handler`フィールドは、全てのAPIバージョンにおいて必須となりました。これはα版のAPIでの`runtimeHandler`フィールドもまた必須であることを意味します。 +- `handler`フィールドは正しいDNSラベルの形式である必要があり([RFC 1123](https://tools.ietf.org/html/rfc1123))、これは`.`文字はもはや含むことができないことを意味します(全てのバージョンにおいて)。有効なハンドラー名は、次の正規表現に従います。`^[a-z0-9]([-a-z0-9]*[a-z0-9])?$` + +**Action Required:** 次のアクションはRuntimeClassのα版からβ版へのアップグレードにおいて対応が必須です。 + +- RuntimeClassリソースはKubernetes v1.14にアップグレードされた*後に* 再作成されなくてはなりません。そして`runtimeclasses.node.k8s.io`というCRDは手動で削除されるべきです。 + ``` + kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io + ``` +- `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md new file mode 100644 index 0000000000..3aa001d294 --- /dev/null +++ b/content/ja/docs/concepts/overview/components.md @@ -0,0 +1,107 @@ +--- +reviewers: +title: Kubernetesコンポーネント +content_template: templates/concept +weight: 20 +card: + name: concepts + weight: 20 +--- + +{{% capture overview %}} + +このページでは、Kubernetesクラスターの機能を提供するために必要になる様々なコンポーネントを説明します。(実行ファイル形式で提供される) + +{{% /capture %}} + +{{% capture body %}} + +## マスターコンポーネント + +マスターコンポーネントは、クラスターのコントロールプレーンです。マスターコンポーネントはクラスターに関する全体的な決定を行い(例えばスケジューリングなど)、クラスターのイベントを検知し、それらに応答します(例えば、レプリケーションコントローラーの'replicas'フィールドが充足されていない場合、新しいPodを立ち上げます)。 + +マスターコンポーネントは、クラスター内のどのマシン上でも動かすことが出来ます。しかし、話を簡単にするために、環境構築を行うスクリプトは通常、全てのマスターコンポーネントを同じマシン上で稼働させ、ユーザーのコンテナはそのマシンでは稼働させません。複数マスターマシン構成の構築例は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。 + +### kube-apiserver + +{{< glossary_definition term_id="kube-apiserver" length="all" >}} + +### etcd + +{{< glossary_definition term_id="etcd" length="all" >}} + +### kube-scheduler + +{{< glossary_definition term_id="kube-scheduler" length="all" >}} + +### kube-controller-manager + +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} + +コントローラーには下記のものがあります: + + * ノードコントローラー: ノードがダウンした場合に、通知と応答を行います。 + * レプリケーションコントローラー: それぞれのレプリケーションコントローラーオブジェクト内に、正しい数のポッドが存在しているかを管理します。 + * エンドポイントコントローラー: エンドポイントを設定します。(これは、サービスとPodを結合するということです) + * サービスアカウント & トークンコントローラー: 新しい名前空間にデフォルトアカウントとAPIアクセストークンを作成します。 + +### クラウドコントローラーマネージャー(cloud-controller-manager) + +[クラウドコントローラーマネージャー](/docs/tasks/administer-cluster/running-cloud-controller/)は、基盤となるクラウドサービスと連携するコントローラーを動かします。クラウドコントローラーマネージャーはKubernetes 1.6でリリースされたアルファの機能です。 + +クラウドコントローラーマネージャーは、クラウドサービス固有の制御ループのみを動かします。これらの制御ループは kube-controller-manager から無効にしなければなりません。無効にするには、kube-controller-managerの起動時に、`--cloud-provider`フラグに`external`を指定します。 + +クラウドコントローラーマネージャーは、クラウドベンダー固有のコードと、Kubernetes本体のコードを独立して開発することを可能にします。以前のリリースでは、Kubernetes本体のコードがクラウドサービス固有のコードに機能的に依存していました。将来のリリースでは、クラウドベンダー固有のコードはクラウドベンダー自身が保持し、Kubernetesが稼働している時にクラウドコントローラーマネージャーに紐付けられるようになっていきます。 + +以下のコントローラーがクラウドサービスとの依存関係を持っています: + + * ノードコントローラー: クラウドから応答が無くなった後、ノードが削除されていないかを確認します。 + * ルートコントローラー: クラウド基盤にルーティング情報を設定します。 + * サービスコントローラー: クラウドサービス上のロードバランサーを作成、更新、削除します。 + * ボリュームコントローラー: ボリュームを作成、アタッチ、マウント、またクラウドサービスと連携し、ボリュームを編成します。 + +## ノードコンポーネント + +ノードコンポーネントは全てのノード上で稼働し、稼働中Podの管理、Kubernetes実行環境を提供します。 + +### kubelet + +{{< glossary_definition term_id="kubelet" length="all" >}} + +### kube-proxy + +[kube-proxy](/docs/admin/kube-proxy/)は、ホスト上のネットワークルールを管理し、コネクションの転送を行うことで、Kubernetesサービスの抽象化を可能にします。 + +### コンテナランタイム + +コンテナランタイムは、コンテナを稼働させる責務を持つソフトウェアです。 +Kubernetesはいくつかのランタイムをサポートしています: [Docker](http://www.docker.com)、[containerd](https://containerd.io)、[cri-o](https://cri-o.io/)、[rktlet](https://github.com/kubernetes-incubator/rktlet)、また[Kubernetes CRI (コンテナランタイムインターフェース)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)の実装があります。 + +## アドオン + +アドオンは、クラスターの機能群を実装したPodとサービスです。そのPodは、Deployment、レプリケーションコントローラーなどによって管理されるでしょう。名前空間に属するアドオンオブジェクトは、`kube-system`名前空間に作られます。 + +一部のアドオンを下記に示します。その他の利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/)を確認してください。 + +### DNS + +厳密には他のアドオンは必須ではありませんが、多数の実例が依存しているため、全てのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。 + +クラスターDNSはDNSサーバーで、あなたの環境で動いている他のDNSサーバーに加え、Kubernetesサービスで利用するDNSレコードも扱います。 + +Kubernetesから起動されたコンテナは、DNSの検索対象として、自動的にこのDNSサーバーを含めます。 + +### Web UI (ダッシュボード) + +[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、汎用のKubernetesのクラスターを管理するためのWebベースのUIです。ユーザーはこれを用いて、クラスター上で稼働しているアプリケーション、またクラスターそのものの管理、トラブルシュートが可能です。 + +### コンテナリソース監視 + +[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列のメトリクスをセントラルなデータベースに記録し、そのデータを閲覧するUIを提供します。 + +### クラスターレベルロギング + +[クラスターレベルロギング](/docs/concepts/cluster-administration/logging/)機構は、コンテナのログを、検索、閲覧のインターフェースを持ったセントラルなログ保管場所に保存します。 + +{{% /capture %}} + diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md new file mode 100644 index 0000000000..43fe3feb9d --- /dev/null +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -0,0 +1,116 @@ +--- +reviewers: +title: Kubernetes API +content_template: templates/concept +weight: 30 +card: + name: concepts + weight: 30 +--- + +{{% capture overview %}} + +全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/api-conventions.md)に記載されています。 + +APIエンドポイント、リソースタイプ、そしてサンプルは[APIリファレンス](/docs/reference)に記載されています。 + +APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。 + +Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することが出来ます。 + +また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。 + +Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。 + +{{% /capture %}} + +{{% capture body %}} + +## APIの変更 + +我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。 + +何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md)に詳解されています。 + +## OpenAPIとSwaggerの定義 + +完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)に記載されています。 + +Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポイントを通じて、OpenAPI仕様を提供しています。 +リクエストフォーマットは、HTTPヘッダーを下記のように設定することで指定されます: + +ヘッダ | 設定可能な値 +------ | --------------- +Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません) +Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています) + +1.14より前のバージョンでは、フォーマット分離エンドポイント(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。 + +**OpenAPI仕様の取得サンプル**: + +1.10より前 | Kubernetes1.10以降 +----------- | ----------------------------- +GET /swagger.json | GET /openapi/v2 **Accept**: application/json +GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf +GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip + +Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。 + +また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。 +このエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。 + +## APIバージョニング + +フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/extensions/v1beta1`のように、それぞれ異なるAPIのパスが割り当てられています。 + +APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンを付けることを選択しました。JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。 + +APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。 + +異なるバージョンのAPIは、異なるレベル(版)の安定性とサポートを持っています。それぞれのレベル(版)の基準は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)に詳細が記載されています。下記に簡潔にまとめます: + +- アルファレベル(版): + - バージョン名に`alpha`を含みます(例、`v1alpha1`)。 + - バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。 + - アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。 + - ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。 + - バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。 +- ベータレベル(版): + - バージョン名に`beta`を含みます(例、`v2beta3`)。 + - コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。 + - 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。 + - オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。 + - 今後のリリースで、互換性の無い変更が行われる可能性があるため、ビジネスクリティカルな場面以外での利用を推奨します。もし複数のクラスターを持っており、それぞれ個別にアップグレードが可能な場合、この制限の影響を緩和できるかもしれません。 + - **是非ベータ機能を試して、フィードバックをください!ベータから安定版になってしまうと、より多くの変更を加えることが難しくなってしまいます。** +- 安定版: + - バージョン名は`vX`のようになっており、`X`は整数です。 + - 安定版の機能は、今後のリリースバージョンにも適用されます。 + +## APIグループ + +KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。 +APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。 + +現在、いくつかのAPIグループが利用されています: + +1. *core* グループ(度々、*legacy group* と呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。 + +1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。 + +[カスタムリソース](/docs/concepts/api-extension/custom-resources/)でAPIを拡張するために、2つの方法がサポートされています: + +1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。 +1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。 + +## APIグループの有効化 + +いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 + +重要: APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。 + +## APIグループのリソースの有効化 + +DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。 +その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/overview/working-with-objects/_index.md b/content/ja/docs/concepts/overview/working-with-objects/_index.md new file mode 100755 index 0000000000..8661349a3f --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/_index.md @@ -0,0 +1,5 @@ +--- +title: "Working with Kubernetes Objects" +weight: 40 +--- + diff --git a/content/ja/docs/concepts/overview/working-with-objects/annotations.md b/content/ja/docs/concepts/overview/working-with-objects/annotations.md new file mode 100644 index 0000000000..a169bdee03 --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/annotations.md @@ -0,0 +1,67 @@ +--- +title: アノテーション(Annotations) +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} +ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。 +{{% /capture %}} + +{{% capture body %}} +## オブジェクトにメタデータを割り当てる + +ユーザーは、Kubernetesオブジェクトに対してラベルやアノテーションの両方またはどちらか一方を割り当てることができます。 +ラベルはオブジェクトの選択や、特定の条件を満たしたオブジェクトの集合を探すことに使うことができます。 +それと対照的に、アノテーションはオブジェクトを識別、または選択するために使用されません。 +アノテーション内のメタデータは大小様々で、構造化されているものや、そうでないものも設定でき、ラベルでは許可されていない文字も含むことができます。 + +アノテーションは、ラベルと同様に、キーとバリューのマップとなります。 + +```json +"metadata": { + "annotations": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +下記は、アノテーション内で記録できる情報の例です。 + +* 宣言的設定レイヤによって管理されているフィールド。これらのフィールドをアノテーションとして割り当てることで、クライアントもしくはサーバによってセットされたデフォルト値、オートサイジングやオートスケーリングシステムによってセットされたフィールドや、自動生成のフィールドなどと区別することができます。 + +* ビルド、リリースやタイムスタンプのようなイメージの情報、リリースID、gitのブランチ、PR番号、イメージハッシュ、レジストリアドレスなど + +* ロギング、監視、分析用のポインタ、もしくは監査用リポジトリ + +* デバッグ目的で使用されるためのクライアントライブラリやツールの情報。例えば、名前、バージョン、ビルド情報など。 + +* 他のエコシステムのコンポーネントからの関連オブジェクトのURLなど、ユーザーやツール、システムの出所情報。 + +* 軽量ロールアウトツールのメタデータ。 例えば設定やチェックポイントなど。 + +* 情報をどこで確認できるかを示すためのもの。例えばチームのウェブサイト、責任者の電話番号や、ページャー番号やディレクトリエンティティなど。 + +* システムのふるまいの変更や、標準ではない機能を利用可能にするために、エンドユーザーがシステムに対して指定する値 + +アノテーションを使用するかわりに、ユーザーはこのようなタイプの情報を外部のデータベースやディレクトリに保存することもできます。しかし、それによりデプロイ、管理、イントロスペクションを行うためのクライアンライブラリやツールの生成が非常に難しくなります。 + +## 構文と文字セット + +_アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は2つのセグメントがあります。 +プレフィックス(オプション)と名前で、それらはスラッシュ`/`で区切られます。 +名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。 +プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。 + +もしプレフィックスが除外された場合、アノテーションキーはそのユーザーに対してプライベートであると推定されます。 +エンドユーザーのオブジェクトにアノテーションを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。 + +`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。 + +{{% /capture %}} + +{{% capture whatsnext %}} +[ラベルとセレクター](/docs/concepts/overview/working-with-objects/labels/)について学習してください。 +{{% /capture %}} + diff --git a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md new file mode 100644 index 0000000000..9a6c4508df --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md @@ -0,0 +1,156 @@ +--- +title: 推奨ラベル(Recommended Labels) +content_template: templates/concept +--- + +{{% capture overview %}} +ユーザーはkubectlやダッシュボード以外に、多くのツールでKubernetesオブジェクトの管理と可視化ができます。共通のラベルセットにより、全てのツールにおいて解釈可能な共通のマナーに沿ってオブジェクトを表現することで、ツールの相互運用を可能にします。 + +ツール化に対するサポートに加えて、推奨ラベルはクエリ可能な方法でアプリケーションを表現します。 +{{% /capture %}} + +{{% capture body %}} +メタデータは、_アプリケーション_ のコンセプトを中心に構成されています。KubernetesはPaaS(Platform as a Service)でなく、アプリケーションの公式な概念を持たず、またそれを強制することはありません。 +そのかわり、アプリケーションは、非公式で、メタデータによって表現されています。単一のアプリケーションが有する項目に対する定義は厳密に決められていません。 + +{{< note >}} +ラベルには推奨ラベルというものがあります。それらのラベルはアプリケーションの管理を容易にします。しかしコア機能のツール化において必須のものではありません。 +{{< /note >}} + +共有されたラベルとアノテーションは、`app.kubernetes.io`という共通のプレフィックスを持ちます。プレフィックスの無いラベルはユーザーに対してプライベートなものになります。その共有されたプレフィックスは、共有ラベルがユーザーのカスタムラベルに干渉しないことを保証します。 + +## ラベル + +これらの推奨ラベルの利点を最大限得るためには、全てのリソースオブジェクトに対して推奨ラベルが適用されるべきです。 + +| キー | 説明 | 例 | 型 | +| ----------------------------------- | --------------------- | -------- | ---- | +| `app.kubernetes.io/name` | アプリケーション名 | `mysql` | 文字列 | +| `app.kubernetes.io/instance` | アプリケーションのインスタンスを特定するための固有名 | `wordpress-abcxzy` | 文字列 | +| `app.kubernetes.io/version` | アプリケーションの現在のバージョン (例: セマンティックバージョン、リビジョンのハッシュなど) | `5.7.21` | 文字列 | +| `app.kubernetes.io/component` | アーキテクチャ内のコンポーネント | `database` | 文字列 | +| `app.kubernetes.io/part-of` | このアプリケーションによって構成される上位レベルのアプリケーション | `wordpress` | 文字列 | +| `app.kubernetes.io/managed-by` | このアプリケーションの操作を管理するために使われているツール | `helm` | 文字列 | + +これらのラベルが実際にどう使われているかを表すために、下記のStatefulSetのオブジェクトを考えましょう。 + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/managed-by: helm +``` + +## アプリケーションとアプリケーションのインスタンス + +単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。 +例えば、WordPressは複数のウェブサイトがあれば、それぞれ別のWordPressが複数回インストールされることがあります。 + +アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。 +例えば、WordPressは`app.kubernetes.io/name`に`wordpress`と記述され、インスタンス名に関しては`app.kubernetes.io/instance`に`wordpress-abcxzy`と記述されます。この仕組みはアプリケーションと、アプリケーションのインスタンスを特定可能にします。全てのアプリケーションインスタンスは固有の名前を持たなければなりません。 + +## ラベルの使用例 +ここでは、ラベルの異なる使用例を示します。これらの例はそれぞれシステムの複雑さが異なります。 + +### シンプルなステートレスサービス + +`Deployment`と`Service`オブジェクトを使って、シンプルなステートレスサービスをデプロイするケースを考えます。下記の2つのスニペットはラベルが最もシンプルな形式においてどのように使われるかをあらわします。 + +下記の`Deployment`は、アプリケーションを稼働させるポッドを管理するのに使われます。 +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + +下記の`Service`は、アプリケーションを公開するために使われます。 +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + +### データベースを使ったウェブアプリケーション + +次にもう少し複雑なアプリケーションについて考えます。データベース(MySQL)を使ったウェブアプリケーション(WordPress)で、Helmを使ってインストールします。 +下記のスニペットは、このアプリケーションをデプロイするために使うオブジェクト設定の出だし部分です。 + +はじめに下記の`Deployment`は、WordPressのために使われます。 + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +下記の`Service`は、WordPressを公開するために使われます。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` +MySQLは`StatefulSet`として公開され、MySQL自身と、MySQLが属する親アプリケーションのメタデータを持ちます。 + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/version: "5.7.21" +... +``` + +この`Service`はMySQLをWordPressアプリケーションの一部として公開します。 +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/version: "5.7.21" +... +``` + +MySQLの`StatefulSet`と`Service`により、MySQLとWordPressに関するより広範な情報が含まれていることに気づくでしょう。 + +{{% /capture %}} \ No newline at end of file diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md new file mode 100644 index 0000000000..98d03bfec6 --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -0,0 +1,64 @@ +--- +title: フィールドセレクター(Field Selectors) +weight: 60 +--- + +_フィールドセレクター(Field Selectors)_ は、1つかそれ以上のリソースフィールドの値を元に[Kubernetesリソースを選択](/docs/concepts/overview/working-with-objects/kubernetes-objects)するためのものです。 +フィールドセレクタークエリの例は以下の通りです。 + +* `metadata.name=my-service` +* `metadata.namespace!=default` +* `status.phase=Pending` + +下記の`kubectl`コマンドは、[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)フィールドの値が`Running`である全てのPodを選択します。 + +```shell +kubectl get pods --field-selector status.phase=Running +``` + +{{< note >}} +フィールドセレクターは本質的にリソースの*フィルター*となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、下記の2つの`kubectl`クエリが同じであることを意味します。 + +```shell +kubectl get pods +kubectl get pods --field-selector "" +``` +{{< /note >}} + +## サポートされているフィールド +サポートされているフィールドセレクターはKubernetesリソースタイプによって異なります。全てのリソースタイプは`metadata.name`と`metadata.namespace`フィールドをサポートしています。サポートされていないフィールドセレクターの使用をするとエラーとなります。 +例えば以下の通りです。 + +```shell +kubectl get ingress --field-selector foo.bar=baz +``` + +``` +Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" +``` + +## サポートされているオペレーター + +ユーザーは、`=`、`==`や`!=`といったオペレーターをフィールドセレクターと組み合わせて使用できます。(`=`と`==`は同義) +例として、下記の`kubectl`コマンドは`default`ネームスペースに属していない全てのKubernetes Serviceを選択します。 + +```shell +kubectl get services --field-selector metadata.namespace!=default +``` + +## 連結されたセレクター +[ラベル](/docs/concepts/overview/working-with-objects/labels)や他のセレクターと同様に、フィールドセレクターはコンマ区切りのリストとして連結することができます。 +下記の`kubectl`コマンドは、`status.phase`が`Runnning`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。 + +```shell +kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always +``` + +## 複数のリソースタイプ + +ユーザーは複数のリソースタイプにまたがったフィールドセレクターを利用できます。 +下記の`kubectl`コマンドは、`default`ネームスペースに属していない全てのStatefulSetとServiceを選択します。 + +```shell +kubectl get statefulsets,services --field-selector metadata.namespace!=default +``` \ No newline at end of file diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md new file mode 100644 index 0000000000..336d4af7ce --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -0,0 +1,72 @@ +--- +title: Kubernetesオブジェクトを理解する +content_template: templates/concept +weight: 10 +card: + name: concepts + weight: 40 +--- + +{{% capture overview %}} +このページでは、KubernetesオブジェクトがKubernetes APIでどのように表現されているか、またそれらを`.yaml`フォーマットでどのように表現するかを説明します。 +{{% /capture %}} + +{{% capture body %}} +## Kubernetesオブジェクトを理解する + +*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます: + +* どのようなコンテナ化されたアプリケーションが稼働しているか(またそれらはどのノード上で動いているか) +* それらのアプリケーションから利用可能なリソース +* アプリケーションがどのように振る舞うかのポリシー、例えば再起動、アップグレード、耐障害性ポリシーなど + +Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。 + +Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。 + +### オブジェクトのspec(仕様)とstatus(状態) + +全てのKubernetesオブジェクトは、オブジェクトの設定を管理する2つの入れ子になったオブジェクトのフィールドを持っています。それは *spec* オブジェクトと *status* オブジェクトです。*spec* オブジェクトはあなたが指定しなければならない項目で、オブジェクトの *望ましい状態* を記述し、オブジェクトに持たせたい特徴を表現します。*status* オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。常に、Kubernetesコントロールプレーンは、あなたから指定された望ましい状態と現在の状態が一致するよう積極的に管理をします。 + +例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を3つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを3つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合(statusが変わる)、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 + +spec、status、metadataに関するさらなる情報は、[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)をご確認ください。 + +### Kubernetesオブジェクトを記述する + +Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報(例えば名前)と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合(直接APIを呼ぶか、`kubectl`を利用するかに関わらず)、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。 + +ここで、KubernetesのDeploymentに必要なフィールドとオブジェクトのspecを記載した`.yaml`ファイルの例を示します: + +{{< codenew file="application/deployment.yaml" >}} + +上に示した`.yaml`ファイルを利用してDeploymentを作成するには、`kubectl`コマンドラインインターフェースに含まれている[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)コマンドに`.yaml`ファイルを引数に指定し、実行します。ここで例を示します: + +```shell +kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record +``` + +出力結果は、下記に似た形になります: + +```shell +deployment.apps/nginx-deployment created +``` + +### 必須フィールド + +Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場合、下記に示すフィールドに値をセットしておく必要があります: + +* `apiVersion` - どのバージョンのKubernetesAPIを利用してオブジェクトを作成するか +* `kind` - どの種類のオブジェクトを作成するか +* `metadata` - オブジェクトを一意に特定するための情報、`name`、string、UID、また任意の`namespace`が該当する + +またオブジェクトの`spec`の値も指定する必要があります。`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。 +例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/docs/concepts/workloads/pods/pod-overview/)です。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000..7451cf35c2 --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,219 @@ +--- +title: ラベル(Labels)とセレクター(Selectors) +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +_ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキーとバリューのペアです。 +ラベルはユーザーに関連した意味のあるオブジェクトの属性を指定するために使われることを目的としています。しかしKubernetesのコアシステムに対して直接的にその意味を暗示するものではありません。 +ラベルはオブジェクトのサブセットを選択し、グルーピングするために使うことができます。また、ラベルはオブジェクトの作成時に割り当てられ、その後いつでも追加、修正ができます。 +各オブジェクトはキーとバリューのラベルのセットを定義できます。各キーは、単一のオブジェクトに対してはユニークである必要があります。 +```json +"metadata": { + "labels": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。 +識別用途でない情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。 + +{{% /capture %}} + + +{{% capture body %}} + +## ラベルを使う動機 + +ラベルは、クライアントにそのマッピング情報を保存することを要求することなく、ユーザー独自の組織構造をシステムオブジェクト上で疎結合にマッピングできます。 + +サービスデプロイメントとバッチ処理のパイプラインは多くの場合、多次元のエンティティとなります(例: 複数のパーティション、Deployment、リリーストラック、ティアー、ティアー毎のマイクロサービスなど) +管理は分野横断的な操作が必要になることが多く、それによって厳密な階層表現、特にユーザーによるものでなく、インフラストラクチャーによって定義された厳格な階層のカプセル化が破られます。 + +ラベルの例: + + * `"release" : "stable"`, `"release" : "canary"` + * `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` + * `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` + * `"partition" : "customerA"`, `"partition" : "customerB"` + * `"track" : "daily"`, `"track" : "weekly"` + +これらは単によく使われるラベルの例です。ユーザーは自由に規約を決めることができます。 +ラベルのキーは、ある1つのオブジェクトに対してユニークである必要があることは覚えておかなくてはなりません。 + +## 構文と文字セット + +ラベルは、キーとバリューのベアです。正しいラベルキーは2つのセグメントを持ちます。 +それは`/`によって分割されたオプショナルなプレフィックスと名前です。 +名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)で、文字列の間ではこれに加えてダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。 +プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。 + +もしプレフィックスが省略された場合、ラベルキーはそのユーザーに対してプライベートであると推定されます。 +エンドユーザーのオブジェクトにラベルを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。 + +`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。 + +正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間がダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)と英数字である文字列を使うことができます。 + +## ラベルセレクター + +[名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。 + +*ラベルセレクター* を介して、クライアントとユーザーはオブジェクトのセットを指定できます。ラベルセレクターはKubernetesにおいてコアなグルーピング機能となります。 + +Kubernetes APIは現在2タイプのセレクターをサポートしています。 +それは*等価ベース(equality-based)* と*集合ベース(set-based)* です。 +単一のラベルセレクターは、コンマ区切りの複数の*要件(requirements)* で構成されています。 +複数の要件がある場合、コンマセパレーターは論理積 _AND_(`&&`)オペレーターと同様にふるまい、全ての要件を満たす必要があります。 + +空文字の場合や、指定なしのセレクターに関するセマンティクスは、コンテキストに依存します。 +そしてセレクターを使うAPIタイプは、それらのセレクターの妥当性とそれらが示す意味をドキュメントに記載するべきです。 + +{{< note >}} +ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。 +{{< /note >}} + +### *等価ベース(Equality-based)* の要件(requirement) + +*等価ベース(Equality-based)* もしくは*不等ベース(Inequality-based)* の要件は、ラベルキーとラベル値によるフィルタリングを可能にします。 +要件に一致したオブジェクトは、指定されたラベルの全てを満たさなくてはいけませんが、それらのオブジェクトはさらに追加のラベルも持つことができます。 +そして等価ベースの要件においては、3つの種類のオペレーターの利用が許可されています。`=`、`==`、`!=`となります。 +最初の2つのオペレーター(`=`、`==`)は*等価(Equality)* を表現し(この2つは単なる同義語)、最後の1つ(`!=`)は*不等(Inequality)* を意味します。 +例えば + +``` +environment = production +tier != frontend +``` + +最初の例は、キーが`environment`で、値が`production`である全てのリソースを対象にします。 +次の例は、キーが`tier`で、値が`frontend`とは異なるリソースと、`tier`という名前のキーを持たない全てのリソースを対象にします。 +コンマセパレーター`,`を使って、`production`の中から、`frontend`のものを除外するようにフィルターすることもできます。 +`environment=production,tier!=frontend` + +等価ベースのラベル要件の1つの使用シナリオとして、PodにおけるNodeの選択要件を指定するケースがあります。 +例えば、下記のサンプルPodは、ラベル`accelerator=nvidia-tesla-p100`をもったNodeを選択します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-test +spec: + containers: + - name: cuda-test + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 +``` + +### *集合ベース(Set-based)* の要件(requirement) + +*集合ベース(Set-based)* のラベルの要件は値のセットによってキーをフィルタリングします。 +`in`、`notin`、`exists`の3つのオペレーターをサポートしています(キーを特定するのみ)。 + +例えば: +``` +environment in (production, qa) +tier notin (frontend, backend) +partition +!partition +``` + +最初の例では、キーが`environment`で、値が`production`か`qa`に等しいリソースを全て選択します。 +第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。 +第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。 +第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。 +同様に、コンマセパレーターは、_AND_ オペレーターと同様にふるまいます。そのため、`partition`と`environment`キーの値がともに`qa`でないラベルを選択するには、`partition,environment notin (qa)`と記述することで可能です。 +*集合ベース* のラベルセレクターは、`environment=production`という記述が`environment in (production)`と等しいため、一般的な等価形式となります。 `!=`と`notin`も同様に等価となります。 + +*集合ベース* の要件は、*等価ベース* の要件と混在できます。 +例えば: +`partition in (customerA, customerB),environment!=qa`. + +## API + +### LISTとWATCHによるフィルタリング + +LISTとWATCHオペレーションは、単一のクエリパラメータを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます。 +*集合ベース* と*等価ベース* のどちらの要件も許可されています(ここでは、URLクエリストリング内で出現します)。 + + * *等価ベース* での要件: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` + * *集合ベース* での要件: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` + +上記の2つの形式のラベルセレクターはRESTクライアントを介してリストにしたり、もしくは確認するために使われます。 +例えば、`kubectl`によって`apiserver`をターゲットにし、*等価ベース* の要件でフィルターすると以下のように書けます。 + +```shell +kubectl get pods -l environment=production,tier=frontend +``` + +もしくは、*集合ベース* の要件を指定すると以下のようになります。 +```shell +kubectl get pods -l 'environment in (production),tier in (frontend)' +``` + +すでに言及したように、*集合ベース* の要件は、*等価ベース* の要件より表現力があります。 +例えば、値に対する_OR_ オペレーターを実装して以下のように書けます。 + +```shell +kubectl get pods -l 'environment in (production, qa)' +``` + +もしくは、_exists_ オペレーターを介して、否定マッチングによる制限もできます。 + +```shell +kubectl get pods -l 'environment,environment notin (frontend)' +``` + +### APIオブジェクトに参照を設定する +[`Service`](/docs/user-guide/services) と [`ReplicationController`](/docs/user-guide/replication-controller)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/docs/user-guide/pods)のような他のリソースのセットを指定するのにも使われます。 + +#### ServiceとReplicationController +`Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。 +同様に、`ReplicationController`が管理するべきPod数についてもラベルセレクターを使って定義されます。 + +それぞれのオブジェクトに対するラベルセレクターはマップを使って`json`もしくは`yaml`形式のファイルで定義され、*等価ベース* のセレクターのみサポートされています。 + +```json +"selector": { + "component" : "redis", +} +``` +もしくは + +```yaml +selector: + component: redis +``` + +このセレクター(それぞれ`json`または`yaml`形式)は、`component=redis`または`component in (redis)`と等価です。 + +#### *集合ベース* の要件指定をサポートするリソース + +[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)や[`Deployment`](/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 +```yaml +selector: + matchLabels: + component: redis + matchExpressions: + - {key: tier, operator: In, values: [cache]} + - {key: environment, operator: NotIn, values: [dev]} +``` + +`matchLabels`は、`{key,value}`ペアのマップです。`matchLabels`内の単一の`{key,value}`は、`matchExpressions`の要素と等しく、それは、`key`フィールドがキー名で、`operator`が"In"で、`values`配列は単に"値"を保持します。 +`matchExpressions`はPodセレクター要件のリストです。対応しているオペレーターは`In`、`NotIn`、`Exists`と`DoesNotExist`です。`values`のセットは、`In`と`NotIn`オペレーターにおいては空文字を許容しません。 +`matchLabels`と`matchExpressions`の両方によって指定された全ての要件指定はANDで判定されます。つまり要件にマッチするには指定された全ての要件を満たす必要があります。 + +#### Nodeのセットを選択する +ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。 +さらなる情報に関しては、[Node選定](/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/overview/working-with-objects/names.md b/content/ja/docs/concepts/overview/working-with-objects/names.md new file mode 100644 index 0000000000..b8762cb33c --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/names.md @@ -0,0 +1,30 @@ +--- +reviewers: +title: 名前 +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +KubernetesのREST API内の全てのオブジェクトは、名前とUIDで明確に識別されます。 + +ユーザーが付与する一意ではない属性については、Kubernetesが[ラベル](/docs/user-guide/labels)と[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を付与します。 + +名前とUIDに関する正確な構文については、[識別子デザインドキュメント](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)を参照してください。 + +{{% /capture %}} + +{{% capture body %}} + +## 名前 + +{{< glossary_definition term_id="name" length="all" >}} + +慣例的に、Kubernetesリソースの名前は最長253文字で、かつ英小文字、数字、また`-`、`.`から構成します。しかし、特定のリソースはより具体的な制限があります。 + +## UID + +{{< glossary_definition term_id="uid" length="all" >}} + +{{% /capture %}} diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000..8e21224587 --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,100 @@ +--- +title: Namespace(名前空間) +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。 +この仮想クラスターをNamespaceと呼びます。 + +{{% /capture %}} + + +{{% capture body %}} + +## 複数のNamespaceを使う時 + +Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。 +数人から数十人しかユーザーのいないクラスターに対して、あなたはNamespaceを作成したり、考える必要は全くありません。 +Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。 + +Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。 + +Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。) + +Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。 + +同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。 +同一のNamespace内でリソースを区別するためには[ラベル](/docs/user-guide/labels)を使用してください。 + +## Namespaceを利用する + +Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/admin/namespaces)に記載されています。 + +### Namespaceの表示 + +ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。 + +```shell +kubectl get namespaces +``` +``` +NAME STATUS AGE +default Active 1d +kube-system Active 1d +kube-public Active 1d +``` + +Kubernetesの起動時には3つの初期Namespaceが作成されています。 + + * `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace + * `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace + * `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。) + このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。 + +### Namespaceの設定 + +一時的な要求のためにNamespaceを設定したい場合、`--namespace`フラグを使用します。 +例: + +```shell +kubectl --namespace= run nginx --image=nginx +kubectl --namespace= get pods +``` + +### Namespace設定の永続化 + +ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。 + +```shell +kubectl config set-context $(kubectl config current-context) --namespace= +# Validate it +kubectl config view | grep namespace: +``` + +## NamespaceとDNS + +ユーザーが[Service](/docs/user-guide/services)を作成するとき、Serviceは対応する[DNSエントリ](/docs/concepts/services-networking/dns-pod-service/)を作成します。 +このエントリは`..svc.cluster.local`という形式になり,これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 +これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。 +もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。 + +## すべてのオブジェクトはNamespaceに属しているとは限らない + +ほとんどのKubernetesリソース(例えば、Pod、Service、ReplicationControllerなど)はいくつかのNamespaceにあります。 +しかしNamespaceのリソースそれ自体は単一のNamespace内にありません。 +そして[Node](/docs/admin/node)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。 + +どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。 + +```shell +# Namespaceに属しているもの +kubectl api-resources --namespaced=true + +# Namespaceに属していないもの +kubectl api-resources --namespaced=false +``` + +{{% /capture %}} diff --git a/content/ja/docs/concepts/services-networking/_index.md b/content/ja/docs/concepts/services-networking/_index.md new file mode 100755 index 0000000000..eea2c65b33 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/_index.md @@ -0,0 +1,5 @@ +--- +title: "Services, Load Balancing, and Networking" +weight: 60 +--- + diff --git a/content/ja/docs/concepts/services-networking/dns-pod-service.md b/content/ja/docs/concepts/services-networking/dns-pod-service.md new file mode 100644 index 0000000000..558f1d7b03 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/dns-pod-service.md @@ -0,0 +1,203 @@ +--- +reviewers: +title: ServiceとPodに対するDNS +content_template: templates/concept +weight: 20 +--- +{{% capture overview %}} +このページではKubernetesによるDNSサポートについて概観します。 +{{% /capture %}} + +{{% capture body %}} + +## イントロダクション + +KubernetesのDNSはクラスター上でDNS PodとServiceをスケジュールし、DNSの名前解決をするために各コンテナに対してDNS ServiceのIPを使うようにKubeletを設定します。 + +### 何がDNS名を取得するか + +クラスター内(DNSサーバーそれ自体も含む)で定義された全てのServiceはDNS名を割り当てられます。デフォルトでは、クライアントPodのDNSサーチリストはPod自身のネームスペースと、クラスターのデフォルトドメインを含みます。 +下記の例でこの仕組みを説明します。 + +Kubernetesの`bar`というネームスペース内で`foo`という名前のServiceがあると仮定します。`bar`ネームスペース内で稼働しているPodは、`foo`に対してDNSクエリを実行するだけでこのServiceを探すことができます。`bar`とは別の`quux`ネームスペース内で稼働しているPodは、`foo.bar`に対してDNSクエリを実行するだけでこのServiceを探すことができます。 + +下記のセクションでは、サポートされているレコードタイプとレイアウトについて詳しくまとめています。 +うまく機能する他のレイアウト、名前、またはクエリーは、実装の詳細を考慮し、警告なしに変更されることがあります。 +最新の仕様に関する詳細は、[KubernetesにおけるDNSベースのServiceディスカバリ](https://github.com/kubernetes/dns/blob/master/docs/specification.md)を参照ください。 + +## Service + +### Aレコード + +"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS Aレコードを割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。 + +"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS Aレコードを割り当てられます。通常のServiceとは異なり、このAレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います… + +### SRVレコード + +SRVレコードは、通常のServiceもしくは[Headless +Services](/docs/concepts/services-networking/service/#headless-services)の一部である名前付きポート向けに作成されます。それぞれの名前付きポートに対して、そのSRVレコードは`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local`という形式となります。 +通常のServiceに対しては、このSRVレコードは`my-svc.my-namespace.svc.cluster.local`という形式のドメイン名とポート番号へ名前解決します。 +Headless Serviceに対しては、このSRVレコードは複数の結果を返します。それはServiceの背後にある各Podの1つを返すのと、`auto-generated-name.my-svc.my-namespace.svc.cluster.local`という形式のPodのドメイン名とポート番号を含んだ結果を返します。 + +## Pod + +### Aレコード + +DNSが有効なとき、Podは"`pod-ip-address.my-namespace.pod.cluster.local`"という形式のAレコードを割り当てられます。 + +例えば、`default`ネームスペース内で`cluster.local`というDNS名を持ち、`1.2.3.4`というIPを持ったPodは次の形式のエントリーを持ちます。: `1-2-3-4.default.pod.cluster.local`。 + +### Podのhostnameとsubdomainフィールド + +現在、Podが作成されたとき、そのPodのホスト名はPodの`metadata.name`フィールドの値となります。 + +Pod Specは、オプションである`hostname`フィールドを持ち、Podのホスト名を指定するために使うことができます。`hostname`が指定されたとき、`hostname`はそのPodの名前よりも優先されます。例えば、`hostname`フィールドが"`my-host`"にセットされたPodを考えると、Podはそのhostnameが"`my-host`"に設定されます。 + +Pod Specはまた、オプションである`subdomain`フィールドも持ち、Podのサブドメイン名を指定するために使うことができます。例えば、"`my-namespace`"というネームスペース内で`hostname`が`foo`とセットされていて、`subdomain`が`bar`とセットされているPodの場合、そのPodは"`foo.bar.my-namespace.svc.cluster.local`"という名前の完全修飾ドメイン名(FQDN)を持つことになります。 + +例: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: default-subdomain +spec: + selector: + name: busybox + clusterIP: None + ports: + - name: foo # 実際は、portは必要ありません。 + port: 1234 + targetPort: 1234 +--- +apiVersion: v1 +kind: Pod +metadata: + name: busybox1 + labels: + name: busybox +spec: + hostname: busybox-1 + subdomain: default-subdomain + containers: + - image: busybox:1.28 + command: + - sleep + - "3600" + name: busybox +--- +apiVersion: v1 +kind: Pod +metadata: + name: busybox2 + labels: + name: busybox +spec: + hostname: busybox-2 + subdomain: default-subdomain + containers: + - image: busybox:1.28 + command: + - sleep + - "3600" + name: busybox +``` + +もしそのPodと同じネームスペース内で、同じサブドメインを持ったHeadless Serviceが存在していた場合、クラスターのKubeDNSサーバーもまた、そのPodの完全修飾ドメイン名(FQDN)に対するAレコードを返します。 +例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはそのPodのIPを指し示すAレコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したAレコードを持ちます。 + +そのエンドポイントオブジェクトはそのIPに加えて`hostname`を任意のエンドポイントアドレスに対して指定できます。 + +{{< note >}} +AレコードはPodの名前に対して作成されないため、`hostname`はPodのAレコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するAレコードのみ作成します。 +{{< /note >}} + +### PodのDNSポリシー + +DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。 + +- "`Default`": そのPodはPodが稼働しているNodeから名前解決の設定を継承します。詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)を参照してください。 +- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。 +- "`ClusterFirstWithHostNet`": hostNetworkによって稼働しているPodに対しては、ユーザーは明示的にDNSポリシーを"`ClusterFirstWithHostNet`"とセットするべきです。 +- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-s-dns-config)を参照ください。 + +{{< note >}} +"Default"は、デフォルトのDNSポリシーではありません。もし`dnsPolicy`が明示的に指定されていない場合、"ClusterFirst"が使用されます。 +{{< /note >}} + +下記の例では、`hostNetwork`フィールドが`true`にセットされているため、`dnsPolicy`が"`ClusterFirstWithHostNet`"とセットされているPodを示します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: busybox + namespace: default +spec: + containers: + - image: busybox:1.28 + command: + - sleep + - "3600" + imagePullPolicy: IfNotPresent + name: busybox + restartPolicy: Always + hostNetwork: true + dnsPolicy: ClusterFirstWithHostNet +``` + +### PodのDNS設定 + +PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさらに制御するための手段を提供します。 + +`dnsConfig`フィールドはオプションで、どのような設定の`dnsPolicy`でも共に機能することができます。しかし、Podの`dnsPolicy`が"`None`"にセットされていたとき、`dnsConfig`フィールドは必ず指定されなくてはなりません。 + +下記の項目は、ユーザーが`dnsConfig`フィールドに指定可能なプロパティーとなります。 + +- `nameservers`: そのPodに対するDNSサーバーとして使われるIPアドレスのリストです。これは最大で3つのIPアドレスを指定することができます。Podの`dnsPolicy`が"`None`"に指定されていたとき、そのリストは最低1つのIPアドレスを指定しなければならず、もし指定されていなければ、それ以外の`dnsPolicy`の値の場合は、このプロパティーはオプションとなります。 +- `searches`: Pod内のホスト名のルックアップのためのDNSサーチドメインのリストです。このプロパティーはオプションです。指定されていたとき、このリストは選択されたDNSポリシーから生成されたサーチドメイン名のベースとなるリストにマージされます。重複されているドメイン名は削除されます。Kubernetesでは最大6つのサーチドメインの設定を許可しています。 +- `options`: `name`プロパティー(必須)と`value`プロパティー(オプション)を持つような各オプジェクトのリストで、これはオプションです。このプロパティー内の内容は指定されたDNSポリシーから生成されたオプションにマージされます。重複されたエントリーは削除されます。 + +下記のファイルはカスタムDNS設定を持ったPodの例です。 + +{{< codenew file="service/networking/custom-dns.yaml" >}} + +上記のPodが作成されたとき、`test`コンテナは、コンテナ内の`/etc/resolv.conf`ファイル内にある下記の内容を取得します。 + +``` +nameserver 1.2.3.4 +search ns1.svc.cluster.local my.dns.search.suffix +options ndots:2 edns0 +``` + +IPv6用のセットアップのためには、サーチパスとname serverは下記のようにセットアップするべきです。 + +``` +$ kubectl exec -it dns-example -- cat /etc/resolv.conf +nameserver fd00:79:30::a +search default.svc.cluster.local svc.cluster.local cluster.local +options ndots:5 +``` + +### DNS機能を利用可用なバージョン + +PodのDNS設定と"`None`"というDNSポリシーの利用可能なバージョンに関しては下記の通りです。 + +| k8s version | Feature support | +| :---------: |:-----------:| +| 1.14 | ステーブル | +| 1.10 | β版 (デフォルトで有効)| +| 1.9 | α版 | + +{{% /capture %}} + +{{% capture whatsnext %}} + +DNS設定の管理方法に関しては、[DNS Serviceの設定](/docs/tasks/administer-cluster/dns-custom-nameservers/) +を確認してください。 + +{{% /capture %}} + + diff --git a/content/ja/docs/concepts/storage/_index.md b/content/ja/docs/concepts/storage/_index.md new file mode 100755 index 0000000000..7e0dd19b12 --- /dev/null +++ b/content/ja/docs/concepts/storage/_index.md @@ -0,0 +1,5 @@ +--- +title: "Storage" +weight: 70 +--- + diff --git a/content/ja/docs/concepts/storage/dynamic-provisioning.md b/content/ja/docs/concepts/storage/dynamic-provisioning.md new file mode 100644 index 0000000000..e2361e5e83 --- /dev/null +++ b/content/ja/docs/concepts/storage/dynamic-provisioning.md @@ -0,0 +1,90 @@ +--- +reviewers: +title: ボリュームの動的プロビジョニング(Dynamic Volume Provisioning) +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +ボリュームの動的プロビジョニングにより、ストレージ用のボリュームをオンデマンドに作成することができます。 +動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。 + +{{% /capture %}} + + +{{% capture body %}} + +## バックグラウンド + +ボリュームの動的プロビジョニングの実装は`storage.k8s.io`というAPIグループ内の`StorageClass`というAPIオブジェクトに基づいています。クラスター管理者は`StorageClass`オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする*Volumeプラグイン* (別名*プロビジョナー*)と、プロビジョンされるときにプロビジョナーに渡されるパラメータを指定します。 +クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメータのカスタムセットを持ちます。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。 + +StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/persistent-volumes/#storageclasses)を参照ください。 + +## 動的プロビジョニングを有効にする + +動的プロビジョニングを有効にするために、クラスター管理者はユーザーのために1つまたはそれ以上のStorageClassを事前に作成する必要があります。StorageClassオブジェクトは、動的プロビジョニングが実行されるときに、どのプロビジョナーが使用されるべきか、またどのようなパラメーターをプロビジョナーに渡すべきか定義します。 +下記のマニフェストでは標準的な永続化ディスクをプロビジョンする"slow"というStorageClassを作成します。 + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard +``` + +下記のマニフェストではSSDを使った永続化ディスクをプロビジョンする"fast"というStorageClassを作成します。 + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: fast +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-ssd +``` + +## 動的プロビジョニングの使用 + +ユーザーは`PersistentVolumeClaim`リソース内でStorageClassを含むことで、動的にプロビジョンされたStorageをリクエストできます。Kubernetes v1.6以前では、この機能は`volume.beta.kubernetes.io/storage-class`アノテーションを介して使うことができました。しかしこのアノテーションではv1.6から廃止になりました。その代わりユーザーは現在では`PersistentVolumeClaim`オブジェクトの`storageClassName`を使う必要があります。このフィールドの値は、管理者によって設定された`StorageClass`の名前と一致しなければなりません([下記](#enabling-dynamic-provisioning)のセクションも参照ください)。 + +"fast"というStorageClassを選択するために、例としてユーザーは下記の`PersistentVolumeClaim`を作成します。 + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: claim1 +spec: + accessModes: + - ReadWriteOnce + storageClassName: fast + resources: + requests: + storage: 30Gi +``` + +このリソースによってSSDのような永続化ディスクが自動的にプロビジョンされます。このリソースが削除された時、そのボリュームは削除されます。 + +## デフォルトの挙動 + +動的プロビジョニングは、もしStorageClassが1つも指定されていないときに全てのPersistentVolumeClaimが動的にプロビジョンされるようにクラスター上で有効にできます。クラスター管理者は、下記を行うことによりこのふるまいを有効にできます。 + +- 1つの`StorageClass`オブジェクトを*default* としてマーキングする +- API Server上で[`DefaultStorageClass`管理コントローラー](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)を有効にする。 + +管理者は`StorageClass`に対して`storageclass.kubernetes.io/is-default-class`アノテーションをつけることで、デフォルトのStorageClassとしてマーキングできます。 +デフォルトの`StorageClass`がクラスター内で存在し、かつユーザーが`PersistentVolumeClaim`リソースで`storageClassName`を指定しなかった場合、`DefaultStorageClass`という管理コントローラーは`storageClassName`フィールドの値をデフォルトのStorageClassを指し示すように自動で追加します。 + +注意点として、クラスター上では最大1つしか*デフォルト* のStorageClassが指定できず、`storageClassName`を明示的に指定しない`PersistentVolumeClaim`は作成することもできません。 + +## トポロジーに関する注意 + +[マルチゾーン](/docs/setup/multiple-zones)クラスター内では、Podは単一のリージョン内のゾーンをまたいでしか稼働できません。シングルゾーンのStorageバックエンドはPodがスケジュールされるゾーン内でプロビジョンされる必要があります。これは[Volume割り当てモード](/docs/concepts/storage/storage-classes/#volume-binding-mode)を設定することにより可能となります。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/storage/volume-snapshot-classes.md b/content/ja/docs/concepts/storage/volume-snapshot-classes.md new file mode 100644 index 0000000000..829bde8a2e --- /dev/null +++ b/content/ja/docs/concepts/storage/volume-snapshot-classes.md @@ -0,0 +1,48 @@ +--- +reviewers: +title: VolumeSnapshotClass +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +このドキュメントでは、Kubernetesにおける`VolumeSnapshotClass`のコンセプトについて説明します。 +関連する項目として、[Volumeのスナップショット](/docs/concepts/storage/volume-snapshots/)と[ストレージクラス](/docs/concepts/storage/storage-classes)も参照してください。 + +{{% /capture %}} + + +{{% capture body %}} + +## イントロダクション + +`StorageClass`はVolumeをプロビジョンするときに、ストレージの"クラス"に関する情報を記述する方法を提供します。それと同様に、`VolumeSnapshotClass`ではVolumeSnapshotをプロビジョンするときに、ストレージの"クラス"に関する情報を記述する方法を提供します。 + +## VolumeSnapshotClass リソース + +各`VolumeSnapshotClass`は`snapshotter`と`parameters`フィールドを含み、それらは、そのクラスに属する`VolumeSnapshot`が動的にプロビジョンされるときに使われます。 + +`VolumeSnapshotClass`オブジェクトの名前は重要であり、それはユーザーがどのように特定のクラスをリクエストできるかを示したものです。管理者は初めて`VolumeSnapshotClass`オブジェクトを作成するときに、その名前と他のパラメーターをセットし、そのオブジェクトは一度作成されるとそのあと更新することができません。 + +管理者は、バインド対象のクラスを1つもリクエストしないようなVolumeSnapshotのために、デフォルトの`VolumeSnapshotClass`を指定することができます。 + +```yaml +apiVersion: snapshot.storage.k8s.io/v1alpha1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass +snapshotter: csi-hostpath +parameters: +``` + +### Snapshotter + +VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何のCSIボリュームプラグインを使うか決定するための`snapshotter`フィールドを持っています。このフィールドは必須となります。 + +## Parameters + +VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています。 +`snapshotter`に応じて様々なパラメータを使用できます。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/_index.md b/content/ja/docs/concepts/workloads/_index.md new file mode 100644 index 0000000000..ca394ebd00 --- /dev/null +++ b/content/ja/docs/concepts/workloads/_index.md @@ -0,0 +1,5 @@ +--- +title: "Workloads" +weight: 50 +--- + diff --git a/content/ja/docs/concepts/workloads/controllers/_index.md b/content/ja/docs/concepts/workloads/controllers/_index.md new file mode 100644 index 0000000000..6aaa7405b5 --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/_index.md @@ -0,0 +1,5 @@ +--- +title: "Controllers" +weight: 20 +--- + diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md new file mode 100644 index 0000000000..2d896a9610 --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -0,0 +1,46 @@ +--- +title: CronJob +content_template: templates/concept +weight: 80 +--- + +{{% capture overview %}} + +_CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。 + +_CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。 +[Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。 + +{{< note >}} +すべての**CronJob**`スケジュール`: 時刻はジョブが開始されたマスタータイムゾーンに基づいています。 +{{< /note >}} + +cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。 + +{{% /capture %}} + +{{% capture body %}} + +## CronJobの制限 + +cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1つのジョブオブジェクトを作成します。ここで _おおよそ_ と言っているのは、ある状況下では2つのジョブが作成される、もしくは1つも作成されない場合があるためです。通常、このようなことが起こらないようになっていますが、完全に防ぐことはできません。したがって、ジョブは _冪等_ であるべきです。 + +`startingDeadlineSeconds`が大きな値、もしくは設定されていない(デフォルト)、そして、`concurrencyPolicy`を`Allow`に設定している場合には、少なくとも一度、ジョブが実行されることを保証します。 + +最後にスケジュールされた時刻から現在までの間に、CronJobコントローラーはどれだけスケジュールが間に合わなかったのかをCronJobごとにチェックします。もし、100回以上スケジュールが失敗していると、ジョブは開始されずに、ログにエラーが記録されます。 + +```` +Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. +```` + +`startingDeadlineSeconds`フィールドが設定されると(`nil`ではない)、最後に実行された時刻から現在までではなく、`startingDeadlineSeconds`の値から現在までで、どれだけジョブを逃したのかをコントローラーが数えます。 `startingDeadlineSeconds`が`200`の場合、過去200秒間にジョブが失敗した回数を記録します。 + +スケジュールされた時間にCronJobが作成できないと、失敗したとみなされます。たとえば、`concurrencyPolicy`が`Forbid`に設定されている場合、前回のスケジュールがまだ実行中にCronJobをスケジュールしようとすると、CronJobは作成されません。 + +例として、CronJobが`08:30:00`を開始時刻として1分ごとに新しいJobをスケジュールするように設定され、`startingDeadlineSeconds`フィールドが設定されていない場合を想定します。`startingDeadlineSeconds`のデフォルト値は`100`秒です。CronJobコントローラーが`08:29:00` から`10:21:00`の間にダウンしていた場合、スケジューリングを逃したジョブの数が100を超えているため、ジョブは開始されません。 + +このコンセプトを更に掘り下げるために、CronJobが`08:30:00`から1分ごとに新しいJobを作成し、`startingDeadlineSeconds`が200秒に設定されている場合を想定します。CronJobコントローラーが前回の例と同じ期間(`08:29:00` から`10:21:00`まで)にダウンしている場合でも、10:22:00時点でJobはまだ動作しています。このようなことは、過去200秒間(言い換えると、3回の失敗)に何回スケジュールが間に合わなかったをコントローラーが確認するときに発生します。これは最後にスケジュールされた時間から今までのものではありません。 + +CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md new file mode 100644 index 0000000000..4f10338dac --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -0,0 +1,180 @@ +--- +reviewers: +title: DaemonSet +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + +_DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピーを稼働させることを保証します。Nodeがクラスターに追加されるとき、PodがNode上に追加されます。Nodeがクラスターから削除されたとき、それらのPodはガーベージコレクターにより除去されます。DaemonSetの削除により、DaemonSetが作成したPodもクリーンアップします。 + +DaemonSetのいくつかの典型的な使用例は以下の通りです。 + +- `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。 +- `fluentd`や`logstash`のようなログ集計デーモンを各Node上で稼働させる。 +- [Prometheus Node Exporter]( + https://github.com/prometheus/node_exporter)や`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などのようなNodeのモニタリングデーモンを各Node上で稼働させる。 + +シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。 +さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。 + +{{% /capture %}} + + +{{% capture body %}} + +## DaemonSet Specの記述 + +### DaemonSetの作成 + +ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。 +例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。 + +{{< codenew file="controllers/daemonset.yaml" >}} + +* YAMLファイルに基づいてDaemonSetを作成します。 +``` +kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml +``` + +### 必須のフィールド + +他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。 +設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/docs/user-guide/deploying-applications/)、[コンテナの設定](/docs/tasks/)、[kuberctlを用いたオブジェクトの管理](/docs/concepts/overview/object-management-kubectl/overview/)といったドキュメントを参照ください。 + +また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)セクションも必須となります。 + +### Podテンプレート + +`.spec.template`は`.spec`内での必須のフィールドの1つです。 + +`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/pod-overview/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、[Pod](/docs/concepts/workloads/pods/pod/)のテンプレートと同じスキーマとなります。 + +Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。 + +DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/docs/user-guide/pod-states)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。 + +### Podセレクター + +`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)の`.spec.selector`と同じものです。 + +Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。Podセレクターは、値を空のままにしてもデフォルト設定にならなくなりました。セレクターのデフォルト化は`kubectl apply`と互換性はありません。また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。 + +`.spec.selector`は2つのフィールドからなるオブジェクトです。 + +* `matchLabels` - [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)の`.spec.selector`と同じように機能します。 +* `matchExpressions` - キーと、値のリストとさらにはそれらのキーとバリューに関連したオペレーターを指定することにより、より洗練された形式のセレクターを構成できます。 + +上記の2つが指定された場合は、2つの条件をANDでどちらも満たすものを結果として返します。 + +もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。 + +また、ユーザーは通常、DaemonSetやReplicaSetのような他のコントローラーを使用するか直接かによらず、このセレクターとマッチするラベルを持つPodを作成すべきではありません。 +さもないと、DaemonSetコントローラーが、それらのPodがDaemonSetによって作成されたものと扱われてしまいます。Kubernetesはユーザーがこれを行うことを止めることはありません。ユーザーがこれを行いたい1つのケースとしては、テストのためにNode上に異なる値をもったPodを手動で作成するような場合があります。 + +### 特定のいくつかのNode上のみにPodを稼働させる + +もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node +selector](/docs/concepts/configuration/assign-pod-node/)にマッチするPodをNode上に作成します。 +同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/docs/concepts/configuration/assign-pod-node/)マッチするPodをNode上に作成します。 +もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。 + +## Daemon Podがどのようにスケジューリングされるか + +### DaemonSetコントローラーによってスケジューリングされる場合(Kubernetes1.12からデフォルトで無効) + +通常、Podが稼働するマシンはKubernetesスケジューラーによって選択されます。 +しかし、DaemonSetコントローラーによって作成されたPodは既に選択されたマシンを持っています(`.spec.nodeName`はPodの作成時に指定され、Kubernetesスケジューラーによって無視されます)。 +従って: + + - Nodeの[`unschedulable`](/docs/admin/node/#manual-node-administration)フィールドはDaemonSetコントローラーによって尊重されません。 + - DaemonSetコントローラーは、スケジューラーが起動していないときでも稼働でき、これはクラスターの自力での起動を助けます。 + +### デフォルトスケジューラーによってスケジューリングされる場合(Kubernetes1.12からデフォルトで有効) + +{{< feature-state state="beta" for-kubernetes-version="1.12" >}} + +DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働させることを保証します。通常、Podが稼働するNodeはKubernetesスケジューラーによって選択されます。しかし、DaemonSetのPodは代わりにDaemonSetコントローラーによって作成され、スケジューリングされます。 +下記の問題について説明します: + + * 矛盾するPodのふるまい: スケジューリングされるのを待っている通常のPodは、作成されているが`Pending`状態となりますが、DaemonSetのPodは`Pending`状態で作成されません。これはユーザーにとって困惑するものです。 + * [Podプリエンプション(Pod preemption)](/docs/concepts/configuration/pod-priority-preemption/)はデフォルトスケジューラーによってハンドルされます。もしプリエンプションが有効な場合、そのDaemonSetコントローラーはPodの優先順位とプリエンプションを考慮することなくスケジューリングの判断を行います。 + +`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。 + +```yaml +nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchFields: + - key: metadata.name + operator: In + values: + - target-host-name +``` + +さらに、`node.kubernetes.io/unschedulable:NoSchedule`というtolarationがDaemonSetのPodに自動的に追加されます。デフォルトスケジューラーは、DaemonSetのPodのスケジューリングのときに、`unschedulable`なNodeを無視します。 + +### TaintsとTolerations + +DaemonSetのPodは[TaintsとTolerations](/docs/concepts/configuration/taint-and-toleration)の設定を尊重します。 +下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。 + +| Toleration Key | Effect | Version | Description | +| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。| +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。| +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。 + +## Daemon Podとのコミュニケーション + +DaemonSet内のPodとのコミュニケーションをする際に考えられるパターンは以下の通りです。: + +- **Push**: DaemonSet内のPodは他のサービスに対して更新情報を送信するように設定されます。 +- **NodeIPとKnown Port**: PodがNodeIPを介して疎通できるようにするため、DaemonSet内のPodは`hostPort`を使用できます。慣例により、クライアントはNodeIPのリストとポートを知っています。 +- **DNS**: 同じPodセレクターを持つ[HeadlessService](/docs/concepts/services-networking/service/#headless-services)を作成し、`endpoints`リソースを使ってDaemonSetを探すか、DNSから複数のAレコードを取得します。 +- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。 + +## DaemonSetの更新 + +もしNodeラベルが変更されたとき、そのDaemonSetは直ちに新しくマッチしたNodeにPodを追加し、マッチしなくなったNodeからPodを削除します。 + +ユーザーはDaemonSetが作成したPodを修正可能です。しかし、Podは全てのフィールドの更新を許可していません。また、DaemonSetコントローラーは次のNode(同じ名前でも)が作成されたときにオリジナルのテンプレートを使ってPodを作成します。 + +ユーザーはDaemonSetを削除可能です。もし`kubectl`コマンドで`--cascade=false`を指定したとき、DaemonSetのPodはNode上で残り続けます。そしてユーザーは異なるテンプレートを使って新しいDaemonSetを作成可能です。 +異なるテンプレートを使った新しいDaemonSetは、マッチしたラベルを持っている全ての存在しているPodを認識します。DaemonSetはPodのテンプレートがミスマッチしていたとしても、それらのPodを修正もしくは削除をしません。 +ユーザーはPodもしくはNodeの削除によって新しいPodの作成を強制する必要があります。 + +Kubernetes1.6とそれ以降のバージョンでは、ユーザーはDaemonSet上で[ローリングアップデートの実施](/docs/tasks/manage-daemon/update-daemon-set/)が可能です。 + +## DaemonSetの代替案 + +### Initスクリプト + +Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`を使用する)、デーモンプロセスを稼働することが可能です。この方法は非常に良いですが、このようなプロセスをDaemonSetを介して起動することはいくつかの利点があります。 + +- アプリケーションと同じ方法でデーモンの監視とログの管理ができる。 +- デーモンとアプリケーションで同じ設定用の言語とツール(例: Podテンプレート、`kubectl`)を使える。 +- リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離を促進します。しかし、これはPod内でなく、コンテナ内でデーモンを稼働させることにより可能です(Dockerを介して直接起動する)。 + +### ベアPod + +特定のNode上で稼働するように指定したPodを直接作成することは可能です。しかし、DaemonSetはNodeの故障やNodeの破壊的なメンテナンスやカーネルのアップグレードなど、どのような理由に限らず、削除されたもしくは停止されたPodを置き換えます。このような理由で、ユーザーはPod単体を作成するよりもむしろDaemonSetを使うべきです。 + +### 静的Pod Pods + +Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/concepts/cluster-administration/static-pod/)と呼ばれます。 +DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。 + +### Deployment + +DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。 + +フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。 +Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md new file mode 100644 index 0000000000..0463849cd0 --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md @@ -0,0 +1,149 @@ +--- +title: ガベージコレクション +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + +Kubernetesのガベージコレクターの役割は、かつてオーナーがいたが、現時点でもはやオーナーがいないようなオブジェクトの削除を行うことです。 +{{% /capture %}} + + +{{% capture body %}} + +## オーナーとその従属オブジェクト + +いくつかのKubernetesオブジェクトは他のオブジェクトのオーナーとなります。例えば、ReplicaSetはPodのセットに対するオーナーです。オーナーによって所有されたオブジェクトは、オーナーオブジェクトの*従属オブジェクト(Dependents)* と呼ばれます。全ての従属オブジェクトは、オーナーオブジェクトを指し示す`metadata.ownerReferences`というフィールドを持ちます。 + +時々、Kubernetesは`ownerReference`フィールドに値を自動的にセットします。例えば、ユーザーがReplicaSetを作成したとき、KubernetesはReplicaSet内の各Podの`ownerReference`フィールドに自動的に値をセットします。Kubernetes1.8において、KubernetesはReplicaController、ReplicaSet、StatefulSet、DaemonSet、Deployment、Job、CronJobによって作成され、適用されたオブジェクトの`ownerReference`フィールドに自動的にその値をセットします。 + +ユーザーはまた`ownerReference`フィールドに手動で値をセットすることにより、オーナーと従属オブジェクト間の関係を指定することができます。 + +下記の例は、3つのPodを持つReplicaSetの設定ファイルとなります。 + +{{< codenew file="controllers/replicaset.yaml" >}} + +もしユーザーがReplicaSetを作成し、Podのメタデータを見る時、`ownerReference`フィールドの値を確認できます。 + +```shell +kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml +kubectl get pods --output=yaml +``` + +その出力結果によると、そのPodのオーナーは`my-repset`という名前のReplicaSetです。 + +```shell +apiVersion: v1 +kind: Pod +metadata: + ... + ownerReferences: + - apiVersion: apps/v1 + controller: true + blockOwnerDeletion: true + kind: ReplicaSet + name: my-repset + uid: d9607e19-f88f-11e6-a518-42010a800195 + ... +``` + +{{< note >}} +ネームスペースをまたいだownerReferenceは意図的に許可されていません。これは以下のことを意味します。 +1) ネームスペース内のスコープの従属オブジェクトは、同一のネームスペース内のオーナーと、クラスターのスコープ内のオーナーのみ指定できます。 +2) クラスターのスコープ内の従属オブジェクトは、クラスターのスコープ内のオーナーオブジェクトのみ指定でき、ネームスペース内のスコープのオーナーオブジェクトは指定できません。 +{{< /note >}} + +## ガベージコレクターがどのように従属オブジェクトの削除をするかを制御する + +ユーザーがオブジェクトを削除するとき、それに紐づく従属オブジェクトも自動で削除するか指定できます。従属オブジェクトの自動削除は、*カスケード削除(Cascading deletion)* と呼ばれます。*カスケード削除* には2つのモードがあり、*バックグラウンド* と*フォアグラウンド* があります。 + +もしユーザーが、従属オブジェクトの自動削除なしにあるオブジェクトを削除する場合、その従属オブジェクトは*みなしご(orphaned)* と呼ばれます。 + +### フォアグラウンドのカスケード削除 + +*フォアグラウンドのカスケード削除* において、そのルートオブジェクトは最初に"削除処理中"という状態に遷移します。その*削除処理中* 状態において、下記の項目は正となります。 + + * そのオブジェクトはREST APIを介して確認可能です。 + * そのオブジェクトの`deletionTimestamp`がセットされます。 + * そのオブジェクトの`metadata.finalizers`フィールドは、`foregroundDeletion`という値を含みます。 + +一度"削除処理中"状態に遷移すると、そのガベージコレクターはオブジェクトの従属オブジェクトを削除します。一度そのガベージコレクターが全ての”ブロッキングしている”従属オブジェクトを削除すると(`ownerReference.blockOwnerDeletion=true`という値を持つオブジェクト)、それはオーナーのオブジェクトも削除します。 + +注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。 +Kubernetes1.7では、認証されていない従属オブジェクトがオーナーオブジェクトの削除を遅らせることができないようにするために[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)が追加され、それは、オーナーオブジェクトの削除パーミッションに基づいて`blockOwnerDeletion`の値がtrueに設定してユーザーアクセスをコントロールします。 + +もしオブジェクトの`ownerReferences`フィールドがコントローラー(DeploymentやReplicaSetなど)によってセットされている場合、`blockOwnerDeletion`は自動的にセットされ、ユーザーはこのフィールドを手動で修正する必要はありません。 + +### バックグラウンドのカスケード削除 + +*バックグラウンドのカスケード削除* において、Kubernetesはそのオーナーオブジェクトを即座に削除し、ガベージコレクションはその従属オブジェクトをバックグラウンドで削除します。 + +### カスケード削除ポリシーの設定 + +カスケード削除ポリシーを制御するためには、オブジェクトをいつ設定するか`deleteOptions`引数上の`propagationPolicy`フィールドに設定してください。設定可能な値は`Orphan`、`Foreground`、もしくは`Background`のどれかです。 + +Kubernetes1.9以前では多くのコントローラーにおけるデフォルトのガベージコレクションポリシーは`orphan`でした。 +この対象のコントローラーはReplicationController、ReplicaSet、StatefulSet、DaemonSetとDeploymentを含みます。`extensions/v1beta1`、`apps/v1beta1`、`apps/v1beta2`のグループバージョンに含まれるオブジェクト種においては、もしユーザーがガベージコレクションに他の値を設定しない限り、デフォルトで従属オブジェクトはみなしご(orphaned)になります。 +Kubernetes1.9において、`apps/v1`というグループバージョンにおいて、従属オブジェクトはデフォルトで削除されます。 + +下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。 + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ +-H "Content-Type: application/json" +``` + +下記のコマンドは従属オブジェクトをフォアグラウンドで削除する例です。 + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +-H "Content-Type: application/json" +``` + +下記のコマンドは従属オブジェクトをみなしご状態になった従属オブジェクトの例です。 + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +-H "Content-Type: application/json" +``` + +kubectlもまたカスケード削除をサポートしています。 +kubectlを使って従属オブジェクトを自動的に削除するためには、`--cascade`をtrueにセットしてください。 +従属オブジェクトを削除せず、みなしご状態にするには`--cascade`をfalseにセットしてください。 +`--cascade`オプションのデフォルト値はtrueになります。 + +下記のコマンドは、ReplicaSetを削除し、その従属オブジェクトをみなしご状態にします。 + +```shell +kubectl delete replicaset my-repset --cascade=false +``` + +### Deploymentsに関する追記事項 + +Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの_propagationPolicy_ が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。 +さらなる詳細に関しては[kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)を参照してください。 + +## 既知の問題について + +[#26120](https://github.com/kubernetes/kubernetes/issues/26120)にてイシューがトラックされています。 + +{{% /capture %}} + + +{{% capture whatsnext %}} + +[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) + +[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) + +{{% /capture %}} + + + diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md new file mode 100644 index 0000000000..0c4a47f694 --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -0,0 +1,315 @@ +--- +reviewers: +title: ReplicaSet +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +ReplicaSetの目的は、どのような時でも安定したレプリカPodのセットを維持することです。これは、理想的なレプリカ数のPodが利用可能であることを保証するものとして使用されます。 + + +{{% /capture %}} + +{{% capture body %}} + +## ReplicaSetがどのように動くか + +ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示すためのセレクターや、稼働させたいPodのレプリカ数、Podテンプレート(理想のレプリカ数の条件を満たすために作成される新しいPodのデータを指定するために用意されるもの)といったフィールドとともに定義されます。ReplicaSetは、指定された理想のレプリカ数にするためにPodの作成と削除を行うことにより、その目的を達成します。ReplicaSetが新しいPodを作成するとき、ReplicaSetはそのPodテンプレートを使用します。 + +ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。 + +ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値がコントローラーでないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。 + +## ReplicaSetを使うとき + +ReplicaSetはどんな時でも指定された数のPodのレプリカが稼働することを保証します。しかし、DeploymentはReplicaSetを管理する、より上位レベルの概念で、Deploymentはその他の多くの有益な機能と共に、宣言的なPodのアップデート機能を提供します。それゆえ、我々はユーザーが独自のアップデートオーケストレーションを必要としたり、アップデートを全く必要としないような場合を除いて、ReplicaSetを直接使うよりも代わりにDeploymentを使うことを推奨します。 + +これは、ユーザーがReplicaSetのオブジェクトを操作する必要が全く無いことを意味します。 +代わりにDeploymentを使用して、`spec`セクションにユーザーのアプリケーションを定義してください。 + +## ReplicaSetの使用例 + +{{< codenew file="controllers/frontend.yaml" >}} + +上記のマニフェストを`frontend.yaml`ファイルに保存しKubernetesクラスターに適用すると、マニフェストに定義されたReplicaSetとそれが管理するPod群を作成します。 + +```shell +kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml +``` + +ユーザーはデプロイされた現在のReplicaSetの情報も取得できます。 +```shell +kubectl get rs +``` + +そして、ユーザーが作成したfrontendリソースについての情報も取得できます。 +```shell +NAME DESIRED CURRENT READY AGE +frontend 3 3 3 6s +``` + +ユーザーはまたReplicaSetの状態も確認できます。 +```shell +kubectl describe rs/frontend +``` + +その結果は以下のようになります。 +```shell +Name: frontend +Namespace: default +Selector: tier=frontend,tier in (frontend) +Labels: app=guestbook + tier=frontend +Annotations: +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: app=guestbook + tier=frontend + Containers: + php-redis: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: 80/TCP + Requests: + cpu: 100m + memory: 100Mi + Environment: + GET_HOSTS_FROM: dns + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l +``` + +そして最後に、ユーザーはReplicaSetによって作成されたPodもチェックできます。 +```shell +kubectl get Pods +``` + +表示されるPodに関する情報は以下のようになります。 +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +``` + +ユーザーはまた、それらのPodの`ownerReferences`が`frontend`ReplicaSetに設定されていることも確認できます。 +これを確認するためには、稼働しているPodの中のどれかのyamlファイルを取得します。 +```shell +kubectl get pods frontend-9si5l -o yaml +``` + +その表示結果は、以下のようになります。その`frontend`ReplicaSetの情報が`metadata`の`ownerReferences`フィールドにセットされています。 +```shell +apiVersion: v1 +kind: Pod +metadata: + creationTimestamp: 2019-01-31T17:20:41Z + generateName: frontend- + labels: + tier: frontend + name: frontend-9si5l + namespace: default + ownerReferences: + - apiVersion: extensions/v1beta1 + blockOwnerDeletion: true + controller: true + kind: ReplicaSet + name: frontend + uid: 892a2330-257c-11e9-aecd-025000000001 +... +``` + +## テンプレートなしのPodの所有 + +ユーザーが問題なくベアPod(Bare Pod: ここではPodテンプレート無しのPodのこと)を作成しているとき、そのベアPodがユーザーのReplicaSetの中のいずれのセレクターともマッチしないことを確認することを強く推奨します。 +この理由として、ReplicaSetは、所有対象のPodがReplicaSetのテンプレートによって指定されたPodのみに限定されていないからです(ReplicaSetは前のセクションで説明した方法によって他のPodも所有できます)。 + +前のセクションで取り上げた`frontend`ReplicaSetと、下記のマニフェストのPodをみてみます。 + +{{< codenew file="pods/pod-rs.yaml" >}} + +これらのPodは`ownerReferences`に何のコントローラー(もしくはオブジェクト)も指定されておらず、そして`frontend`ReplicaSetにマッチするセレクターをもっており、これらのPodは即座に`frontend`ReplicaSetによって所有されます。 + +この`frontend`ReplicaSetがデプロイされ、初期のPodレプリカがレプリカ数の要求を満たすためにセットアップされた後で、ユーザーがそのPodを作成することを考えます。 + +```shell +kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml +``` + +新しいPodはそのReplicaSetによって所有され、そのReplicaSetのレプリカ数が、設定された理想のレプリカ数を超えた場合すぐにそれらのPodは削除されます。 + +下記のコマンドでPodを取得できます。 +```shell +kubectl get Pods +``` + +その表示結果で、新しいPodがすでに削除済みか、削除中のステータスになっているのを確認できます。 +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +pod2 0/1 Terminating 0 4s +``` + +もしユーザーがそのPodを最初に作成する場合 +```shell +kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml +``` + +そしてその後に`frontend`ReplicaSetを作成すると、 +```shell +kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml +``` + +ユーザーはそのReplicaSetが作成したPodを所有し、さらにもともと存在していたPodと今回新たに作成されたPodの数が、理想のレプリカ数になるまでPodを作成するのを確認できます。 +ここでまたPodの状態を取得します。 +```shell +kubectl get Pods +``` + +取得結果は下記のようになります。 +```shell +NAME READY STATUS RESTARTS AGE +frontend-pxj4r 1/1 Running 0 5s +pod1 1/1 Running 0 13s +pod2 1/1 Running 0 13s +``` + +この方法で、ReplicaSetはテンプレートで指定されたもの以外のPodを所有することができます。 + +## ReplicaSetのマニフェストを記述する。 + +他の全てのKubernetes APIオブジェクトのように、ReplicaSetは`apiVersion`、`kind`と`metadata`フィールドを必要とします。 +ReplicaSetでは、`kind`フィールドの値は`ReplicaSet`です。 +Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが現在のバージョンで、デフォルトで有効です。`apps/v1beta2`というAPIバージョンは廃止されています。先ほど作成した`frontend.yaml`ファイルの最初の行を参考にしてください。 + +また、ReplicaSetは[`.spec` セクション](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)も必須です。 + +### Pod テンプレート + +`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。 +他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。 + +テンプレートの[再起動ポリシー](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。 + +### Pod セレクター + +`.spec.selector`フィールドは[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)です。 +[先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。 +先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました +```shell +matchLabels: + tier: frontend +``` + +そのReplicaSetにおいて、`.spec.template.metadata.labels`フィールドの値は`spec.selector`と一致しなくてはならず、一致しない場合はAPIによって拒否されます。 + +{{< note >}} +2つのReplicaSetが同じ`.spec.selector`の値を設定しているが、それぞれ異なる`.spec.template.metadata.labels`と`.spec.template.spec`フィールドの値を持っていたとき、それぞれのReplicaSetはもう一方のReplicaSetによって作成されたPodを無視します。 +{{< /note >}} + +### レプリカ数について + +ユーザーは`.spec.replicas`フィールドの値を設定することにより、いくつのPodを同時に稼働させるか指定できます。そのときReplicaSetはレプリカ数がこの値に達するまでPodを作成、または削除します。 + +もしユーザーが`.spec.replicas`を指定しない場合、デフォルト値として1がセットされます。 + +## ReplicaSetを利用する + +### ReplicaSetとPodの削除 + +ReplicaSetとそれが所有する全てのPod削除したいときは、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドを使ってください。 +[ガーベージコレクター](/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。 + +REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Background`か`Foreground`と指定しなくてはなりません。 +例えば下記のように実行します。 +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +> -H "Content-Type: application/json" +``` + +### ReplicaSetのみを削除する + +ユーザーは[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドで`--cascade=false`オプションを付けることにより、所有するPodに影響を与えることなくReplicaSetを削除できます。 +REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Orphan`と指定しなくてはなりません。 +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +> -H "Content-Type: application/json" +``` + +一度元のReplicaSetが削除されると、ユーザーは新しいものに置き換えるため新しいReplicaSetを作ることができます。新旧のReplicaSetの`.spec.selector`の値が同じである間、新しいReplicaSetは古いReplicaSetで稼働していたPodを取り入れます。 +しかし、存在するPodが新しく異なるPodテンプレートとマッチさせようとするとき、この仕組みは機能しません。 +ユーザーのコントロール下において新しいspecのPodをアップデートしたい場合は、[ローリングアップデート](#rolling-updates)を使用してください。 + +### PodをReplicaSetから分離させる + +ユーザーはPodのラベルを変更することにより、ReplicaSetからそのPodを削除できます。この手法はデバッグや、データ修復などのためにサービスからPodを削除したいときに使用できます。 +この方法で削除されたPodは自動的に新しいものに置き換えられます。(レプリカ数は変更されないものと仮定します。) + +### ReplicaSetのスケーリング + +ReplicaSetは、ただ`.spec.replicas`フィールドを更新することによって簡単にスケールアップまたはスケールダウンできます。ReplicaSetコントローラーは、ラベルセレクターにマッチするような指定した数のPodが利用可能であり、操作可能であることを保証します。 + +### HorizontalPodAutoscaler(HPA)のターゲットとしてのReplicaSet + +ReplicaSetはまた、[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/)のターゲットにもなることができます。 +これはつまりReplicaSetがHPAによってオートスケールされうることを意味します。 +ここではHPAが、前の例で作成したReplicaSetをターゲットにする例を示します。 + +{{< codenew file="controllers/hpa-rs.yaml" >}} + +このマニフェストを`hpa-rs.yaml`に保存し、Kubernetesクラスターに適用すると、レプリケートされたPodのCPU使用量にもとづいてターゲットのReplicaSetをオートスケールするHPAを作成します。 + +```shell +kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml +``` + +同様のことを行うための代替案として、`kubectl autoscale`コマンドも使用できます。(こちらの方がより簡単です。) + +```shell +kubectl autoscale rs frontend --max=10 +``` + +## ReplicaSetの代替案 + +### Deployment (推奨) + +[`Deployment`](/docs/concepts/workloads/controllers/deployment/)はReplicaSetを所有することのできるオブジェクトで、宣言的なサーバサイドのローリングアップデートを介してReplicaSetとPodをアップデートできます。 +ReplicaSetは単独で使用可能ですが、現在では、ReplicaSetは主にPodの作成、削除とアップデートを司るためのメカニズムとしてDeploymentによって使用されています。ユーザーがDeploymentを使用するとき、Deploymentによって作成されるReplicaSetの管理について心配する必要はありません。DeploymentはReplicaSetを所有し、管理します。 +このため、もしユーザーがReplicaSetを必要とするとき、Deploymentの使用を推奨します。 + +### ベアPod(Bare Pods) + +ユーザーがPodを直接作成するケースとは異なり、ReplicaSetはNodeの故障やカーネルのアップグレードといった破壊的なNodeのメンテナンスなど、どのような理由に限らず削除または停止されたPodを置き換えます。 +このため、我々はもしユーザーのアプリケーションが単一のPodのみ必要とする場合でもReplicaSetを使用することを推奨します。プロセスのスーパーバイザーについても同様に考えると、それは単一Node上での独立したプロセスの代わりに複数のNodeにまたがった複数のPodを監視します。 +ReplicaSetは、Node上のいくつかのエージェント(例えば、KubeletやDocker)に対して、ローカルのコンテナ再起動を移譲します。 + +### Job + +PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用してください。 + +### DaemonSet + +マシンの監視やロギングなど、マシンレベルの機能を提供したい場合は、ReplicaSetの代わりに[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/)を使用してください。 +これらのPodはマシン自体のライフタイムに紐づいています: そのPodは他のPodが起動する前に、そのマシン上で稼働される必要があり、マシンが再起動またはシャットダウンされるときには、安全に停止されます。 + +### ReplicationController + +ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/)の後継となるものです。 +この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。 +このように、ReplicaSetはReplicationControllerよりも好まれます。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md new file mode 100644 index 0000000000..b10c4156a4 --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -0,0 +1,202 @@ +--- +reviewers: +title: StatefulSet +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。 + +{{< note >}} +StatefulSetはKubernetes1.9において利用可能(GA)です。 +{{< /note >}} + +{{< glossary_definition term_id="statefulset" length="all" >}} +{{% /capture %}} + +{{% capture body %}} + +## StatefulSetの使用 + +StatefulSetは下記の1つ以上の項目を要求するアプリケーションにおいて最適です。 + +* 安定した一意のネットワーク識別子 +* 安定した永続ストレージ +* 規則的で安全なデプロイとスケーリング +* 規則的で自動化されたローリングアップデート + +上記において安定とは、Podのスケジュール(または再スケジュール)をまたいでも永続的であることと同義です。 +もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するコントローラーを使ってアプリケーションをデプロイするべきです。 +[Deployment](/docs/concepts/workloads/controllers/deployment/)や[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)のようなコントローラーはこのようなステートレスな要求に対して最適です。 + +## 制限事項 + +* StatefuleSetはKubernetes1.9より以前のバージョンではβ版のリソースであり、1.5より前のバージョンでは利用できません。 +* 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。 +* StatefulSetの削除もしくはスケールダウンをすることにより、StatefulSetに関連したボリュームは削除*されません* 。 これはデータ安全性のためで、関連するStatefulSetのリソース全てを自動的に削除するよりもたいてい有効です。 +* StatefulSetは現在、Podのネットワークアイデンティティーに責務をもつために[Headless Service](/docs/concepts/services-networking/service/#headless-services)を要求します。ユーザーはこのServiceを作成する責任があります。 +* StatefulSetは、StatefulSetが削除されたときにPodの停止を行うことを保証していません。StatefulSetにおいて、規則的で安全なPodの停止を行う場合、削除のために事前にそのStatefulSetの数を0にスケールダウンさせることが可能です。 +* デフォルト設定の[Pod管理ポリシー](#pod-management-policies) (`OrderedReady`)によって[ローリングアップデート](#rolling-updates)を行う場合、[修復のための手動介入](#forced-rollback)を要求するようなブロークンな状態に遷移させることが可能です。 + +## コンポーネント + +下記の例は、StatefulSetのコンポーネントのデモンストレーションとなります。 + +* nginxという名前のHeadlessServiceは、ネットワークドメインをコントロールするために使われます。 +* webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。 +* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: nginx + labels: + app: nginx +spec: + ports: + - port: 80 + name: web + clusterIP: None + selector: + app: nginx +--- +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web +spec: + selector: + matchLabels: + app: nginx # .spec.template.metadata.labelsの値と一致する必要があります + serviceName: "nginx" + replicas: 3 # by default is 1 + template: + metadata: + labels: + app: nginx # .spec.selector.matchLabelsの値と一致する必要があります + spec: + terminationGracePeriodSeconds: 10 + containers: + - name: nginx + image: k8s.gcr.io/nginx-slim:0.8 + ports: + - containerPort: 80 + name: web + volumeMounts: + - name: www + mountPath: /usr/share/nginx/html + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: "my-storage-class" + resources: + requests: + storage: 1Gi +``` + +## Podセレクター +ユーザーは、StatefulSetの`.spec.template.metadata.labels`のラベルと一致させるため、StatefulSetの`.spec.selector`フィールドをセットしなくてはなりません。Kubernetes1.8以前では、`.spec.selector`フィールドは省略された場合デフォルト値になります。Kubernetes1.8とそれ以降のバージョンでは、ラベルに一致するPodセレクターの指定がない場合はStatefulSetの作成時にバリデーションエラーになります。 + +## Podアイデンティティー +StatefulSetのPodは、順番を示す番号、安定したネットワークアイデンティティー、安定したストレージからなる一意なアイデンティティーを持ちます。 +そのアイデンティティーはどのNode上にスケジュール(もしくは再スケジュール)されるかに関わらず、そのPodに紐付きます。 + +### 順序インデックス + +N個のレプリカをもったStatefulSetにおいて、StatefulSet内の各Podは、0からはじまりN-1までの整数値を順番に割り当てられ、そのStatefulSetにおいては一意となります。 + +### 安定したネットワークID + +StatefulSet内の各Podは、そのStatefulSet名とPodの順序番号から派生してホストネームが割り当てられます。 +作成されたホストネームの形式は`$(StatefulSet名)-$(順序番号)`となります。先ほどの上記の例では、`web-0,web-1,web-2`という3つのPodが作成されます。 +StatefulSetは、Podのドメインをコントロールするために[Headless Service](/docs/concepts/services-networking/service/#headless-services)を使うことができます。 +このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。 +各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。 + +[制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/docs/concepts/services-networking/service/#headless-services)を作成する責任があります。 + +ここで、クラスタードメイン、Service名、StatefulSet名の選択と、それらがStatefulSetのPodのDNS名にどう影響するかの例をあげます。 + +Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain | Pod DNS | Pod Hostname | +-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ | + cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} | + cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | + kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | + +{{< note >}} +クラスタードメインは[その他の設定](/docs/concepts/services-networking/dns-pod-service/#how-it-works)がされない限り、`cluster.local`にセットされます。 +{{< /note >}} + +### 安定したストレージ + +Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1Gibのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。 +注意点として、PodのPersistentVolume Claimと関連したPersistentVolumeは、PodやStatefulSetが削除されたときに削除されません。 +削除する場合は手動で行わなければなりません。 + +### Podのネームラベル + +StatefulSetのコントローラーがPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。 + +## デプロイとスケーリングの保証 + +* N個のレプリカをもつStatefulSetにおいて、Podがデプロイされるとき、それらのPodは{0..N-1}の番号で順番に作成されます。 +* Podが削除されるとき、それらのPodは{N-1..0}の番号で降順に削除されます。 +* Podに対してスケーリングオプションが適用される前に、そのPodの前の順番の全てのPodがRunningかつReady状態になっていなくてはなりません。 +* Podが停止される前に、そのPodの番号より大きい番号を持つの全てのPodは完全にシャットダウンされていなくてはなりません。 + +StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 + +上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。 + +もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。 + +### Podの管理ポリシー +Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podManagementPolicy`フィールドを介して、Podの一意性とアイデンティティーを保証します。 + +#### OrderedReadyなPod管理 + +`OrderedReady`なPod管理はStatefulSetにおいてデフォルトです。これは[デプロイとスケーリングの保証](#deployment-and-scaling-guarantees)に記載されている項目の振る舞いを実装します。 + +#### 並行なPod管理Parallel Pod Management +`並行`なPod管理は、StatefulSetコントローラーに対して、他のPodが起動や停止される前にそのPodが完全に起動し準備完了になるか停止するのを待つことなく、Podが並行に起動もしくは停止するように指示します。 + +## アップデートストラテジー + +Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStarategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。 + +### OnDelete + +`OnDelete`というアップデートストラテジーは、レガシーな(Kubernetes1.6以前)振る舞いとなります。StatefulSetの`.spec.updateStrategy.type`が`OnDelete`にセットされていたとき、そのStatefulSetコントローラーはStatefulSet内でPodを自動的に更新しません。StatefulSetの`.spec.template`項目の修正を反映した新しいPodの作成をコントローラーに支持するためには、ユーザーは手動でPodを削除しなければなりません。 + +### RollinUpdate + +`RollinUpdate`というアップデートストラテジーは、StatefulSet内のPodに対する自動化されたローリングアップデートの機能を実装します。これは`.spec.updateStrategy`フィールドが未指定の場合のデフォルトのストラテジーです。StatefulSetの`.spec.updateStrategy.type`が`RollingUpdate`にセットされたとき、そのStatefulSetコントローラーは、StatefulSet内のPodを削除し、再作成します。これはPodの停止(Podの番号の降順)と同じ順番で、一度に1つのPodを更新します。コントローラーは、その前のPodの状態がRunningかつReady状態になるまで次のPodの更新を待ちます。 + +#### パーティション + +`RollingUpdate`というアップデートストラテジーは、`.spec.updateStrategy.rollingUpdate.partition`を指定することにより、パーティションに分けることができます。もしパーティションが指定されていたとき、そのパーティションの値と等しいか、大きい番号を持つPodが更新されます。パーティションの値より小さい番号を持つPodは更新されず、たとえそれらのPodが削除されたとしても、それらのPodは以前のバージョンで再作成されます。もしStatefulSetの`.spec.updateStrategy.rollingUpdate.partition`が、`.spec.replicas`より大きい場合、`.spec.template`への更新はPodに反映されません。 +多くのケースの場合、ユーザーはパーティションを使う必要はありませんが、もし一部の更新を行う場合や、カナリー版のバージョンをロールアウトする場合や、段階的ロールアウトを行う場合に最適です。 + +#### 強制ロールバック + +デフォルトの[Pod管理ポリシー](#pod-management-policies)(`OrderedReady`)による[ローリングアップデート](#rolling-updates)を行う際、修復のために手作業が必要な状態にすることが可能です。 + +もしユーザーが、決してRunningかつReady状態にならないような設定になるようにPodテンプレートを更新した場合(例えば、不正なバイナリや、アプリケーションレベルの設定エラーなど)、StatefulSetはロールアウトを停止し、待機します。 + +この状態では、Podテンプレートを正常な状態に戻すだけでは不十分です。[既知の問題](https://github.com/kubernetes/kubernetes/issues/67250)によって、StatefulSetは元の正常な状態へ戻す前に、壊れたPodがReady状態(決して起こりえない)に戻るのを待ち続けます。 + +そのテンプレートを戻したあと、ユーザーはまたStatefulSetが異常状態で稼働しようとしていたPodをすべて削除する必要があります。StatefulSetはその戻されたテンプレートを使ってPodの再作成を始めます。 + +{{% /capture %}} +{{% capture whatsnext %}} + +* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。 +* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。 + +{{% /capture %}} + diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md new file mode 100644 index 0000000000..aed6b33169 --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -0,0 +1,56 @@ +--- +reviewers: +title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources) +content_template: templates/concept +weight: 65 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL機構を提供します。 +TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 + +α版の免責事項: この機能は現在α版の機能で、[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 + +{{% /capture %}} + + + + +{{% capture body %}} + +## TTLコントローラー + +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 + +TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 + +* Jobがその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。 +* この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。 +* リソース作成時に、このフィールドを動的にセットするために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。クラスター管理者は、終了したリソースに対して、このTTLポリシーを強制するために使うことができます。 +* リソースが終了した後に、このフィールドを動的にセットしたり、リソースステータスやラベルなどの値に基づいて異なるTTL値を選択するために、[管理webhookの変更](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)をさせます。 + +## 注意 + +### TTL秒の更新 + +注意点として、Jobの`.spec.ttlSecondsAfterFinished`フィールドといったTTL期間はリソースが作成された後、もしくは終了した後に変更できます。しかし、一度Jobが削除可能(TTLの期限が切れたとき)になると、それがたとえTTLを伸ばすような更新に対してAPIのレスポンスで成功したと返されたとしても、そのシステムはJobが稼働し続けることをもはや保証しません。 + +### タイムスキュー(Time Skew) + +TTLコントローラーが、TTL値が期限切れかそうでないかを決定するためにKubernetesリソース内に保存されたタイムスタンプを使うため、この機能はクラスター内のタイムスキュー(時刻のずれ)に対してセンシティブとなります。タイムスキューは、誤った時間にTTLコントローラーに対してリソースオブジェクトのクリーンアップしてしまうことを引き起こすものです。 + +Kubernetesにおいてタイムスキューを避けるために、全てのNode上でNTPの稼働を必須とします([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)を参照してください)。クロックは常に正しいものではありませんが、Node間におけるその差はとても小さいものとなります。TTLに0でない値をセットするときにこのリスクに対して注意してください。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) + +[設計ドキュメント](https://github.com/kubernetes/community/blob/master/keps/sig-apps/0026-ttl-after-finish.md) + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/pods/_index.md b/content/ja/docs/concepts/workloads/pods/_index.md new file mode 100755 index 0000000000..a105f18fb3 --- /dev/null +++ b/content/ja/docs/concepts/workloads/pods/_index.md @@ -0,0 +1,5 @@ +--- +title: "Pods" +weight: 10 +--- + diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md new file mode 100644 index 0000000000..5c3e42530f --- /dev/null +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -0,0 +1,276 @@ +--- +title: Initコンテナ(Init Containers) +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} +このページでは、Initコンテナについて概観します。Initコンテナとは、アプリケーションコンテナの前に実行され、アプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含んだ特別なコンテナです。 +{{% /capture %}} + +この機能はKubernetes1.6からβ版の機能として存在しています。InitコンテナはPodSpec内で、アプリケーションの`containers`という配列と並べて指定されます。そのベータ版のアノテーション値はまだ扱われ、PodSpecのフィールド値を上書きします。しかしながら、それらはKubernetesバージョン1.6と1.7において廃止されました。Kubernetesバージョン1.8からはそのアノテーション値はサポートされず、PodSpecフィールドの値に変換する必要があります。 + +{{% capture body %}} +## Initコンテナを理解する + +単一の[Pod](/docs/concepts/workloads/pods/pod-overview/)は、Pod内に複数のコンテナを稼働させることができますが、Initコンテナもまた、アプリケーションコンテナが稼働する前に1つまたは複数稼働できます。 + +Initコンテナは下記の項目をのぞいて、通常のコンテナと全く同じものとなります。 + +* Initコンテナは常に完了するまで稼働します。 +* 各Initコンテナは、次のInitコンテナが稼働する前に正常に完了しなくてはなりません。 + +もしあるPodの単一のInitコンテナが失敗した場合、KubernetesはInitコンテナが成功するまで何度もそのPodを再起動します。しかし、もしそのPodの`restartPolicy`が`Never`の場合、再起動されません。 + +単一のコンテナをInitコンテナとして指定するためには、PodSpecにそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトのJSON配列として指定してください。 +Initコンテナのステータスは、`.status.initContainerStatuses`フィールドにコンテナのステータスの配列として返されます(`.status.containerStatuses`と同様)。 + +### 通常のコンテナとの違い + +Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは微妙に異なり、下記の[Resources](#resources)にて説明します。また、InitコンテナはそのPodの準備ができ前に完了しなくてはならないため、`readinessProbe`をサポートしていません。 + +もし複数のInitコンテナが単一のPodに対して指定された場合、それらのInitコンテナは1つずつ順番に実行されます。各Initコンテナは次のコンテナが完了できる前に完了しなくてはなりません。全てのInitコンテナが実行完了した時、KubernetesはPodを初期化し、通常通りアプリケーションコンテナを稼働させます。 + +## Initコンテナは何に使用できるか? + +Initコンテナはアプリケーションコンテナのイメージとは分離されているため、コンテナの起動に関連したコードにおいていくつかの利点があります。 + +* セキュリティの理由からアプリケーションコンテナのイメージに含めたくないユーティリティーを含んだり実行できます。 +* アプリケーションのイメージに存在していないセットアップ用のユーティリティーやカスタムコードを含むことができます。例えば、セットアップ中に`sed`、`awk`、`python`や、`dig`のようなツールを使うための他のイメージから、アプリケーションのイメージを作る必要がなくなります。 +* アプリケーションイメージをひとまとめにしてビルドすることなく、アプリケーションのイメージ作成と、デプロイ処理を独立して行うことができます。 +* アプリケーションコンテナと別のファイルシステムビューを持つために、Linuxの名前空間を使用します。その結果、アプリケーションコンテナがアクセスできない箇所へのシークレットなアクセス権限を得ることができます。 +* Initコンテナはアプリケーションコンテナの実行の前に完了しますが、その一方で、複数のアプリケーションコンテナは並列に実行されます。そのためInitコンテナはいくつかの前提条件をセットされるまで、アプリケーションコンテナの起動をブロックしたり遅らせることができます。 + +### 使用例 + +ここではInitコンテナの使用例を挙げます。 + +* シェルコマンドを使って単一のServiceが作成されるのを待機します。 + + for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 + +* コマンドを使って下位のAPIからこのPodをリモートサーバに登録します。 + + `curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()'` + +* `sleep 60`のようなコマンドを使ってアプリケーションコンテナが起動する前に待機します。 +* ボリュームにあるgitリポジトリをクローンします。 +* メインのアプリケーションコンテナのための設定ファイルを動的に生成するために、いくつかの値を設定ファイルに移してテンプレートツールを稼働させます。例えば、設定ファイルにそのPodのPOD_IPを移して、Jinjaを使ってメインのアプリケーションコンテナの設定ファイルを生成します。 + +さらに詳細な使用例は、[StatefulSetsのドキュメント](/docs/concepts/workloads/controllers/statefulset/)と[Production Pods guide](/docs/tasks/configure-pod-container/configure-pod-initialization/)にまとまっています。 + +### Initコンテナの使用 + +下記のKubernetes1.5用のyamlファイルは、2つのInitコンテナを含む単一のシンプルなポッドの概要となります。 +最初のInitコンテナの例は、`myservies`、2つ目のInitコンテナは`mydb`の起動をそれぞれ待ちます。2つのコンテナの実行が完了するとPodの起動が始まります。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp + annotations: + pod.beta.kubernetes.io/init-containers: '[ + { + "name": "init-myservice", + "image": "busybox:1.28", + "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"] + }, + { + "name": "init-mydb", + "image": "busybox:1.28", + "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"] + } + ]' +spec: + containers: + - name: myapp-container + image: busybox:1.28 + command: ['sh', '-c', 'echo The app is running! && sleep 3600'] +``` + +古いアノテーション構文がKubernetes1.6と1.7において有効ですが、1.6では新しい構文にも対応しています。Kubernetes1.8以降では新しい構文はを使用する必要があります。KubernetesではInitコンテナの宣言を`spec`に移行させました。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp +spec: + containers: + - name: myapp-container + image: busybox:1.28 + command: ['sh', '-c', 'echo The app is running! && sleep 3600'] + initContainers: + - name: init-myservice + image: busybox:1.28 + command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'] + - name: init-mydb + image: busybox:1.28 + command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] +``` + +Kubernetes1.5での構文は1.6においても稼働しますが、1.6の構文の使用を推奨します。Kubernetes1.6において、API内でInitコンテナのフィールド作成されます。ベータ版のアノテーションはKubernetes1.6と1.7において有効ですが、1.8以降ではサポートされません。 + +下記のyamlファイルは`mydb`と`myservice`というServiceの概要です。 + +```yaml +kind: Service +apiVersion: v1 +metadata: + name: myservice +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9376 +--- +kind: Service +apiVersion: v1 +metadata: + name: mydb +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9377 +``` + +このPodは、下記のコマンドによって起動とデバッグすることが可能です。 + +```shell +kubectl apply -f myapp.yaml +``` +``` +pod/myapp-pod created +``` + +```shell +kubectl get -f myapp.yaml +``` +``` +NAME READY STATUS RESTARTS AGE +myapp-pod 0/1 Init:0/2 0 6m +``` + +```shell +kubectl describe -f myapp.yaml +``` +``` +Name: myapp-pod +Namespace: default +[...] +Labels: app=myapp +Status: Pending +[...] +Init Containers: + init-myservice: +[...] + State: Running +[...] + init-mydb: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Containers: + myapp-container: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201 + 16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 +``` +```shell +kubectl logs myapp-pod -c init-myservice # 1つ目のInitコンテナを調査する +kubectl logs myapp-pod -c init-mydb # 2つ目のInitコンテナを調査する +``` + +一度`mydq`と`myservice` Serviceを起動させると、Initコンテナが完了して`myapp-pod`が作成されるのを確認できます。 + +```shell +kubectl apply -f services.yaml +``` +``` +service/myservice created +service/mydb created +``` + +```shell +kubectl get -f myapp.yaml +NAME READY STATUS RESTARTS AGE +myapp-pod 1/1 Running 0 9m +``` + +この例は非常にシンプルですが、ユーザー独自のInitコンテナを作成するためのインスピレーションを提供するでしょう。 + +## Initコンテナのふるまいに関する詳細 + +単一のPodが起動している間、ネットワークとボリュームが初期化されたのちに、Initコンテナは順番に起動されます。各Initコンテナは次のInitコンテナが起動する前に完了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値をもとにリトライされます。しかし、もしPodの`retartPolicy`が`Always`に設定されていた場合、そのInitコンテナの`restartPolicy`は`OnFailure`となります。 + +Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initializing`という値はtrueとなります。 + +もしそのPodが[再起動](#pod-restart-reasons)されたとき、全てのInitコンテナは再度実行されなくてはなりません。 + +Initコンテナのスペックに対する変更はコンテナのイメージフィールドのみに限定されます。 +Initコンテナのイメージフィールド値の変更は、そのPodの再起動することと等しいです。 + +Initコンテナは何度も再起動、リトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れるべきです。 + +Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に強要されます。 + +Initコンテナがずっと失敗し続けたままの状態を防ぐために、Podに`activeDeadlineSeconds`、コンテナに`livenessProbe`の設定をそれぞれ使用してください。`activeDeadlineSeconds`の設定はInitコンテナにも適用されます。 + +あるPod内の各アプリケーションコンテナとInitコンテナの名前はユニークである必要があります。他のコンテナと同じ名前を共有していた場合、バリデーションエラーが返されます。 + +### リソース + +Initコンテナの順序と実行を考えるとき、リソースの使用に関して下記のルールが適用されます。 + +* 全てのInitコンテナの中で定義された最も高いリソースリクエストとリソースリミットが、*有効なInitリクエストとリミット* になります。 +* Podのリソースの*有効なリクエストとリミット* は、下記の2つの中のどちらか高い方となります。 + * そのリソースの全てのアプリケーションコンテナのリクエストとリミットの合計 + * そのリソースの有効なInitリクエストとリミット +* スケジューリングは有効なリクエストとリミットに基づいて実行されます。これはInitコンテナがそのPodの生存中に使われない初期化のためのリソースを保持することができることを意味しています。 +* Podの*有効なQosティアー* は、Initコンテナとアプリケーションコンテナで同様です。 + +クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。 + +Podレベルのcgroupsは、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。 + +### Podの再起動の理由 + +単一のPodは再起動可能で、Initコンテナの再実行も引き起こします。それらは下記の理由によるものです。 + +* あるユーザーが、そのPodのInitコンテナのイメージを変更するようにPodSpecを更新する場合。アプリケーションコンテナのイメージの変更はそのアプリケーションコンテナの再起動のみ行われます。 +* そのPodのインフラストラクチャーコンテナが再起動された場合。これはあまり起きるものでなく、Nodeに対するルート権限を持ったユーザーにより行われることがあります。 +* `restartPolicy`が`Always`と設定されているとき、単一Pod内の全てのコンテナが停止され、再起動が行われた時と、ガーベージコレクションによりInitコンテナの完了記録が失われた場合。 + +## サポートと互換性 + +ApiServerのバージョン1.6.0かそれ以上のバージョンのクラスターは、`.spec.initContainers`フィールドを使ったInitコンテナの機能をサポートしています。 +それ以前のバージョンでは、α版かβ版のアノテーションを使ってInitコンテナを使用できます。また、`.spec.initContainers`フィールドは、Kubernetes1.3.0かそれ以上のバージョンでInitコンテナを使用できるようにするためと、ApiServerバージョン1.6において、1.5.xなどの古いバージョンにロールバックできるようにするために、α版かβ版のアノテーションにミラーされ、存在するPodのInitコンテナの機能が失われることが無いように安全にロールバックできるようにします。 + +ApiServerとKubeletバージョン1.8.0かそれ以上のバージョンでは、α版とβ版のアノテーションは削除されており、廃止されたアノテーションは`.spec.initContainers`フィールドへの移行が必須となります。 + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [Initコンテナを持っているPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md new file mode 100644 index 0000000000..65dfd22a2a --- /dev/null +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -0,0 +1,330 @@ +--- +title: Podのライフサイクル +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +このページではPodのライフサイクルについて説明します。 + +{{% /capture %}} + + +{{% capture body %}} + +## PodのPhase + +Podの`status`項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは`phase`のフィールドがあります。 + +Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。 +このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。 + +Podの各フェーズの値と意味は厳重に守られています。 +ここに記載されているもの以外に`phase`の値は存在しないと思ってください。 + +これらが`phase`の取りうる値です。 + +値 | 概要 +:-----|:----------- +`Pending` | PodがKubernetesシステムによって承認されましたが、1つ以上のコンテナイメージが作成されていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。これには時間がかかることがあります。 +`Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。 +`Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。 +`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。 +`Unknown` | 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。 + +## Podのconditions + +PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。 +PodCondition配列の各要素には、次の6つのフィールドがあります。 + +* `lastProbeTime` は、Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。 + +* `lastTransitionTime` は、最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。 + +* `message` は、ステータスの遷移に関する詳細を示す人間向けのメッセージです。 + +* `reason` は、最後の状態遷移の理由を示す、一意のキャメルケースでの単語です。 + +* `status` は`True`と`False`、`Unknown`のうちのどれかです。 + +* `type` 次の値を取る文字列です。 + + * `PodScheduled`: PodがNodeにスケジュールされました。 + * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。 + * `Initialized`: すべての[init containers](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。 + * `Unschedulable`: リソースの枯渇やその他の理由で、Podがスケジュールできない状態です。 + * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。 + + +## コンテナのProbe + +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。 +診断を行うために、kubeletはコンテナに実装された [ハンドラー](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)を呼びます。 +Handlerには次の3つの種類があります: + +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): + コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 + +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): + コンテナのIPの特定のポートにTCPチェックを行います。 + そのポートが空いていれば診断を成功とみなします。 + +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): + コンテナのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。 + レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。 + +各Probe 次の3つのうちの一つの結果を持ちます: + +* Success: コンテナの診断が成功しました。 +* Failure: コンテナの診断が失敗しました。 +* Unknown: コンテナの診断が失敗し、取れるアクションがありません。 + +Kubeletは2種類のProbeを実行中のコンテナで行い、また反応することができます: + +* `livenessProbe`: コンテナが動いているかを示します。 + livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 + コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。 + +* `readinessProbe`: コンテナがServiceのリクエストを受けることができるかを示します。 + readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。 + initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 + コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 + +### livenessProbeとreadinessProbeをいつ使うべきか? + +コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば +livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。 + +Probeに失敗したときにコンテナを殺したり再起動させたりするには、 +livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。 + +Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。 +この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、 +readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。 +コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。 + +コンテナがメンテナンスのために停止できるようにするには、 +livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。 + +Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。 +Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunhealthyにします。 +Pod内のコンテナが停止するのを待つ間Podはunhealthyのままです。 + +livenessProbeまたはreadinessProbeを設定する方法の詳細については、 +[Configure Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)を参照してください + +## Podとコンテナのステータス + +PodとContainerのステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と +[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。 +Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。 + +## コンテナのステータス + +PodがスケジューラによってNodeに割り当てられると、 +kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。 +コンテナの状態はWaiting、RunningまたはTerminatedの3ついずれかです。 +コンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。 +Pod内のコンテナごとにStateの項目として表示されます。 + +* `Waiting`: コンテナのデフォルトの状態。コンテナがRunningまたはTerminatedのいずれの状態でもない場合コンテナはWaitingの状態になります。Waiting状態のコンテナは引き続きイメージを取得したりSecretsを適用したりするなど必要な操作を実行します。この状態に加えてメッセージに関する情報と状態に関する理由が表示されます。 + + ```yaml + ... + State: Waiting + Reason: ErrImagePull + ... + ``` + +* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunningに入ると`postStart`フック(もしあれば)が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。 + + ```yaml + ... + State: Running + Started: Wed, 30 Jan 2019 16:46:38 +0530 + ... + ``` + +* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあればあれば実行されます。 + + ```yaml + ... + State: Terminated + Reason: Completed + Exit Code: 0 + Started: Wed, 30 Jan 2019 11:45:26 +0530 + Finished: Wed, 30 Jan 2019 11:45:26 +0530 + ... + ``` + +## PodReadinessGate + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +追加のフィードバックやシグナルを`PodStatus`に注入できるようにしてPodのReadinessに拡張性を持たせるため、 +Kubernetes 1.11 では[Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)という機能が導入されました。 +`PodSpec`の新しいフィールド`ReadinessGate`を使用して、PodのRedinessを評価する追加の状態を指定できます。 +KubernetesがPodのstatus.conditionsフィールドでそのような状態を発見できない場合、 +ステータスはデフォルトで`False`になります。以下はその例です。 + +```yaml +Kind: Pod +... +spec: + readinessGates: + - conditionType: "www.example.com/feature-1" +status: + conditions: + - type: Ready # これはビルトインのPodCondition + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + - type: "www.example.com/feature-1" # 追加のPodCondition + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + containerStatuses: + - containerID: docker://abcd... + ready: true +... +``` + +新しいPod Conditionは、Kubernetesの[label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。 +`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、 +新しいPod Conditionは[KubeClient libraries](/docs/reference/using-api/client-libraries/)のどれかを使用する必要があります。 + +新しいPod Conditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます: + +* Pod内のすべてのコンテナが準備完了している。 +* `ReadinessGates`で指定された条件が全て`True`である。 + +PodのReadinessの評価へのこの変更を容易にするために、新しいPod Conditionである`ContainersReady`が導入され、古いPodの`Ready`条件を取得します。 + +K8s 1.1ではAlpha機能のため"Pod Ready++" 機能は`PodReadinessGates` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)にて明示的に指定する必要があります。 + +K8s 1.12ではこの機能はデフォルトで有効になっています。 + +## RestartPolicy + +PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。 +デフォルト値はAlwaysです。`restartPolicy`は、Pod内のすべてのコンテナに適用されます。 +`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。 +kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延(10秒、20秒、40秒...)で再起動され、10分間の実行後にリセットされます。[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)に書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。 + +## Podのライフタイム + +一般にPodは誰かが破棄するまで消えません。これは人間またはコントローラかもしれません。 +このルールの唯一の例外は、一定の期間以上の(マスターで`terminated-pod-gc-threshold`によって判断される)SucceededまたはFailedの`phase`を持つPodは期限切れになり自動的に破棄されます。 + +次の3種類のコントローラがあります。 + +- バッチ計算などのように終了が予想されるPodに対しては、[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用します。 + Jobは`restartPolicy`がOnFailureまたはNeverになるPodに対してのみ適切です。 + +- 停止することを期待しないPod(たとえばWebサーバーなど)には、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)、または[Deployment](/docs/concepts/workloads/controllers/deployment/)を使用します。ReplicationControllerは`restartPolicy`がAlwaysのPodに対してのみ適切です。 + +- マシン固有のシステムサービスを提供するため、マシンごとに1つずつ実行する必要があるPodには[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)を使用します。 + +3種類のコントローラにはすべてPodTemplateが含まれます。 +Podを自分で直接作成するのではなく適切なコントローラを作成してPodを作成させることをおすすめします。 +これはPod単独ではマシンの障害に対して回復力がないためです。コントローラにはこの機能があります。 + +Nodeが停止したりクラスタの他のNodeから切断された場合、 +Kubernetesは失われたノード上のすべてのPodの`phase`をFailedに設定するためのポリシーを適用します。 + +## 例 + +### 高度なliveness probeの例 + +Liveness Probeはkubeletによって実行されるため、 +すべてのリクエストはkubeletネットワークのnamespaceで行われます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + test: liveness + name: liveness-http +spec: + containers: + - args: + - /server + image: k8s.gcr.io/liveness + livenessProbe: + httpGet: + # "host" が定義されていない場合、"PodIP"が使用されます + # host: my-host + # "scheme"が定義されていない場合、HTTPスキームが使用されます。"HTTP"と"HTTPS"のみ + # scheme: HTTPS + path: /healthz + port: 8080 + httpHeaders: + - name: X-Custom-Header + value: Awesome + initialDelaySeconds: 15 + timeoutSeconds: 1 + name: liveness +``` + +### statesの例 + + * Podが実行中でそのPodには1つのコンテナがあります。コンテナは正常終了しました。 + * 完了のイベントを記録します。 + * `restartPolicy`が、 + * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 + * OnFailure: Podの`phase`はSucceededになります。 + * Never: Podの`phase`はSucceededになります。 + + * Podが実行中でそのPodには1つのコンテナがあります。コンテナは失敗終了しました。 + * 失敗イベントを記録します。 + * `restartPolicy`が、 + * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 + * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 + * Never: Podの`phase`はFailedになります。 + + * Podが実行中で、その中には2つのコンテナがあります。コンテナ1は失敗終了しました。 + * 失敗イベントを記録します。 + * `restartPolicy`が、 + * Always: コンテナを再起動します。Podの`phase`はunningのままです。 + * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 + * Never: コンテナを再起動しません。Podの`phase`はRunningのままです。 + * コンテナ1が死んでいてコンテナ2は動いている場合 + * 失敗イベントを記録します。 + * `restartPolicy`が、 + * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 + * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 + * Never: Podの`phase`はFailedになります。 + + * Podが実行中でそのPodには1つのコンテナがあります。コンテナはメモリーを使い果たしました。 + * コンテナは失敗で終了します。 + * OOMイベントを記録します。 + * `restartPolicy`が、 + * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 + * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 + * Never: 失敗イベントを記録します。Podの`phase`はFailedになります。 + + * Podが実行中ですがディスクは死んでいます。 + * すべてのコンテンを殺します。 + * 適切なイベントを記録します。 + * Podの`phase`はFailedになります。 + * Podがコントローラで作成されていた場合は、別の場所で再作成されます。 + + * Podが実行中ですがNodeが切り離されました。 + * Nodeコントローラがタイムアウトを待ちます。 + * NodeコントローラがPodの`phase`をFailedにします。 + * Podがコントローラで作成されていた場合は、別の場所で再作成されます。 + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオンをやってみる + +* [configuring liveness and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のハンズオンをやってみる + +* [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md new file mode 100644 index 0000000000..2386912c76 --- /dev/null +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -0,0 +1,121 @@ +--- +reviewers: +- erictune +title: Podについての概観(Pod Overview) +content_template: templates/concept +weight: 10 +card: + name: concepts + weight: 60 +--- + +{{% capture overview %}} +このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して概観します。 +{{% /capture %}} + + +{{% capture body %}} +## Podについて理解する + +*Pod* は、Kubernetesの基本的なビルディングブロックとなります。Kubernetesオブジェクトモデルの中で、ユーザーが作成し、デプロイ可能なシンプルで最も最小のユニットです。単一のPodはクラスター上で稼働する単一のプロセスを表現します。 + +単一のPodは、アプリケーションコンテナ(いくつかの場合においては複数のコンテナ)や、ストレージリソース、ユニークなネットワークIPや、コンテナがどのように稼働すべきか統制するためのオプションをカプセル化します。単一のPodは、ある単一のDeploymentのユニット(単一のコンテナもしくはリソースを共有する、密接に連携された少数のコンテナ群を含むような*Kubernetes内でのアプリケーションの単一のインスタンス*) を表現します。 + +> [Docker](https://www.docker.com)はKubernetesのPod内で使われる最も一般的なコンテナランタイムですが、Podは他のコンテナランタイムも同様にサポートしています。 + +Kubernetesクラスター内でのPodは2つの主な方法で使うことができます。 + +* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。 +このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができ、Kubernetesはコンテナを直接扱うというよりは、Podを管理することになります。 +* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。 +-- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。 + +[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。 +さらなる情報を得たい場合は、下記のページを参照ください。 + +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) +* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns) + +各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。 +Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。 +レプリケーションされたPodは、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。 +さらなる情報に関しては[Podとコントローラー](#pods-and-controllers)を参照して下さい。 + +### Podがどのように複数のコンテナを管理しているか + +Podは凝集性の高いサービスのユニットを構成するような複数の協調プロセス(コンテナ)をサポートするためにデザインされました。 +単一のPod内のコンテナ群は、クラスター内において同一の物理マシンもしくは仮想マシン上において自動で同じ環境に配備され、スケジュールされます。コンテナはリソースや依存関係を共有し、お互いにコミュニケートし、それらがいつ、どのように削除されるかを調整できます。 + +注意点として、単一のPod内で同じ環境に配備され、同時管理される複数のコンテナをグルーピングするのは、比較的に発展的なユースケースとなります。 +ユーザーは、コンテナ群が密接に連携するような、特定のインスタンスにおいてのみこのパターンを使用するべきです。 +例えば、ユーザーが共有ボリューム内にあるファイル用のWebサーバとして稼働するコンテナと、下記のダイアグラムにあるような、リモートのソースからファイルを更新するような分離された*サイドカー* コンテナを持っているような場合です。 + + +{{< figure src="/images/docs/pod.svg" title="Podのダイアグラム" width="50%" >}} + +Podは、Podによって構成されたコンテナ群のために2種類の共有リソースを提供します。 *ネットワーキング* と*ストレージ* です。 + +#### ネットワーキング + +各Podは固有のIPアドレスを割り当てられます。単一のPod内の各コンテナは、IPアドレスやネットワークポートを含む、そのネットワークの名前空間を共有します。*Pod内の* コンテナは`localhost`を使用してお互いに疎通できます。単一のPod内のコンテナが*Pod外* のエンティティと疎通する場合、共有されたネットワークリソース(ポートなど)をどのように使うかに関して調整しなければなりません。 + +#### ストレージ + +単一のPodは共有されたストレージ*ボリューム* のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。 +単一のPod内での共有ストレージをKubernetesがどう実装しているかについてのさらなる情報については、[Volumes](/docs/concepts/storage/volumes/)を参照してください。 + +## Podを利用する + +ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。 +これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時(ユーザーによって直接的、またはコントローラーによって間接的に作成された場合)、ユーザーのクラスター内の単一のNode上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、Nodeが故障するまでNode上に残り続けます。 + +{{< note >}} +単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。 +{{< /note >}} + +Podは、Podそれ自体によって自己修復しません。もし、稼働されていないNode上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、Nodeのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。 +このように、Podを直接使うのは可能ですが、コントローラーを使用したPodを管理する方がより一般的です。KubernetesがPodのスケーリングと修復機能を実現するためにコントローラーをどのように使うかに関する情報は[Podとコントローラー](#pods-and-controllers)を参照してください。 + +### Podとコントローラー + +単一のコントローラーは、ユーザーのために複数のPodを作成・管理し、レプリケーションやロールアウト、クラスターのスコープ内で自己修復の機能をハンドリングします。例えば、もしNodeが故障した場合、コントローラーは異なるNode上にPodを置き換えるようにスケジューリングすることで、自動的にリプレース可能となります。 + +1つまたはそれ以上のPodを含むコントローラーの例は下記の通りです。 + +* [Deployment](/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) + +通常は、コントローラーはユーザーが作成したPodテンプレートを使用して、担当するPodを作成します。 + +## Podテンプレート + +Podテンプレートは、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)や、 +[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のような他のオブジェクト内で含まれるPodの仕様となります。 +コントローラーは実際のPodを作成するためにPodテンプレートを使用します。 +下記のサンプルは、メッセージを表示する単一のコンテナを含んだ、シンプルなPodのマニフェストとなります。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp +spec: + containers: + - name: myapp-container + image: busybox + command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600'] +``` + +全てのレプリカの現在の理想的な状態を指定するというよりも、Podテンプレートはクッキーの抜き型のようなものです。一度クッキーがカットされると、そのクッキーは抜き型から離れて関係が無くなります。そこにはいわゆる”量子もつれ”といったものはありません。テンプレートに対するその後の変更や新しいテンプレートへの切り替えは、すでに作成されたPod上には直接的な影響はありません。 +同様に、ReplicationControllerによって作成されたPodは、変更後に直接更新されます。これはPodとの意図的な違いとなり、そのPodに属する全てのコンテナの現在の理想的な状態を指定します。このアプローチは根本的にシステムのセマンティクスを単純化し、機能の柔軟性を高めます。 + +{{% /capture %}} + +{{% capture whatsnext %}} +* Podの振る舞いに関して学ぶには下記を参照してください。 + * [Podの停止](/docs/concepts/workloads/pods/pod/#termination-of-pods) + * [Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/) +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md new file mode 100644 index 0000000000..3987e9f842 --- /dev/null +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -0,0 +1,190 @@ +--- +reviewers: +title: Pod +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。 + +{{% /capture %}} + + +{{% capture body %}} + +## Podとは + +_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。 + +Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。 + +Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離する一連の要素と同じものがコンテキストとして共有されます。 +Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。 + +Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。 +また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。 +異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。 +これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。 + +Pod内のアプリケーションからアクセスできる共有ボリュームを、Podの一部として定義できます。 +このボリュームは個々のアプリケーションのファイルシステムにマウント可能です。 + +[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。 + +個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。 +[Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。 +Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。 +特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。 +代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。 + +ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。 +そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 + +{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} + +*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。* + +## Podを用いる動機 + +### 管理 + +Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。 +構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。 +Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。 +Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。 + +### リソース共有と通信 + +Podは、構成要素間でのデータ共有および通信を可能にします。 + +Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。 +このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。 +各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。 + +Pod内のアプリケーションコンテナのホスト名には、Podの名前が設定されます。 +詳細は[クラスターネットワーク](/docs/concepts/cluster-administration/networking/)をご覧ください。 + +Podで実行されるアプリケーションコンテナの定義に加えて、Podによって共有ストレージであるボリュームを複数設定することも可能です。 +ボリュームを使用すると、データはコンテナの再起動後も存続し、Pod内のアプリケーション間で共有できます。 + +## Podの用途 + +Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。 +しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。 + +* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど +* ログとチェックポイントのバックアップ、圧縮、ローテーション、スナップショットなど +* データの変更を監視するもの、ログをtailするもの、ロギングおよび監視の補助プログラム、イベントを発行するものなど +* プロキシ、ブリッジ、およびアダプタ +* コントローラー、マネージャー、コンフィギュレーター、およびアップデーター + +個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。 + +詳細については、[The Distributed System ToolKit: Patterns for +Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット:複合コンテナのパターン)を参照してください。 + +## 考えられる代替案 + +_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか?_ + +1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。 +これは、ユーザーに多くの便益を提供します。 +1. ソフトウェアの依存関係を減らすため。 +個々のコンテナは、独立してバージョン管理、再構築、および再デプロイできます。 +Kubernetesはいつか個々のコンテナのライブアップデートをサポートするかもしれません。 +1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。 +1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。 + +_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか?_ + +このアプローチによって、コンテナの共同配置は提供されるでしょう。 +しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。 + + +## Podの耐久性(またはその欠如) + +Podは、耐久性のある存在として扱われることを意図していません。 +スケジューリングの失敗や、Nodeの故障には耐えられません。 +リソースの不足やNodeのメンテナンスといった場合に、追い出されて停止することもあり得ます。 + +一般に、ユーザーはPodを直接作成する必要はありません。 +ほとんどの場合、対象がシングルトンであったとしても、[Deployments](/docs/concepts/workloads/controllers/deployment/)などのコントローラーを使用するべきです。 +コントローラーは、レプリケーションとロールアウト管理だけでなく、クラスターレベルの自己修復機能も提供します。 +[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)ようなコントローラーもステートフルなPodをサポートします。 + +主要なユーザー向けのプリミティブとして集合APIを使用することは、[Borg](https://research.google.com/pubs/pub43438.html)、 [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、[Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)などのクラスタースケジューリングシステムで比較的一般的です。 + +Podは、以下のことを容易にするためにプリミティブとして公開されています。 + +* スケジューラーとコントローラーをプラガブルにする +* コントローラーAPIを介して「プロキシ」の必要なしに、Podレベルの操作をサポートする +* ブートストラップなどのために、コントローラーの寿命からPodの寿命を切り離す +* コントローラーとサービスを分離する――エンドポイントコントローラーはPodのみを監視する +* Kubeletレベルの機能とクラスターレベルの機能をきれいに組み合わせる――Kubeletは事実上「Podコントローラー」となる +* アプリケーションの可用性を高める。 +即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する + +## Podの終了 + +Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。 +ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。 +ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。 +猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。 +プロセスの終了を待っている間にKubeletかコンテナマネージャーが再起動されると、終了処理は猶予期間の後にリトライされます。 + +フローの例は下のようになります。 + +1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する +1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される +1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される +1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する + 1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。 + 猶予期間が終了した後も `preStop` フックがまだ実行されている場合は、次に、短い延長された猶予期間(2秒)でステップ2が呼び出される + 1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある +1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 +ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない +1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される +1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。 +PodはAPIから消え、クライアントからは見えなくなる + +デフォルトでは、すべての削除は30秒以内に正常に行われます。 +`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=` オプションをサポートします。 +値 `0` はPodを[強制的に削除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)します。 +kubectlのバージョン1.5以降では、強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。 + +### Podの強制削除 + +Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。 +強制削除が実行されると、apiserverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。 +API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。 +Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。 + +強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。 +StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 + +## Podコンテナの特権モード + +Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。 +これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。 +コンテナ内のプロセスは、コンテナ外のプロセスで利用できるものとほぼ同じ特権を獲得します。 +特権モードでは、ネットワークプラグインとボリュームプラグインを別々のPodとして作成する方が簡単なはずです。それらをkubeletにコンパイルする必要はありません。 + +マスターがKubernetes v1.1以降を実行しており、Nodeがv1.1より前のバージョンを実行している場合、新しい特権付きのPodはAPIサーバーに受け入れられますが、起動されません。 +それらは保留状態になります。 +ユーザーが `kubectl describe pod FooPodName` を実行すると、Podが保留状態になっている理由を確認できます。 +describeコマンド出力のイベントテーブルには、次のように表示されます。 +`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` + +マスターがv1.1より前のバージョンを実行している場合、特権を持つPodは作成できません。 +ユーザーが特権付きのコンテナを含むPodを作成しようとすると、次のエラーを受け取ります。 +`The Pod "FooPodName" is invalid. +spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'` + +## APIオブジェクト + +PodはKubernetes REST APIのトップレベルのリソースです。 +APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。 + +{{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md new file mode 100644 index 0000000000..7638d63acb --- /dev/null +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -0,0 +1,60 @@ +--- +reviewers: +title: Pod Preset +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} +このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 +{{% /capture %}} + + +{{% capture body %}} +## PodPresetを理解する + +`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。 +ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 + +PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。 +この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。 + +PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。 + +## PodPresetはどのように動くか + +Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。 +Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。 + +1. 使用可能な全ての`PodPreset`を取得する。 +1. それらの`PodPreset`のラベルセレクターが、作成されたPod上のラベルと一致するかチェックする。 +1. `PodPreset`によって定義された様々なリソースを、作成されたPodにマージしようと試みる。 +1. エラーが起きた時、そのPod上でマージエラーが起きたことを説明するイベントをスローし、`PodPreset`からリソースを1つも注入されていないPodを作成します。 +1. `PodPreset`によって修正されたことを示すために、マージ後の修正されたPodにアノテーションをつけます。そのアノテーションは`podpreset.admission.kubernetes.io/podpreset-: "<リソースのバージョン>"`という形式になります。 + +各Podは0以上のPodPresetにマッチすることができます。そして各`PodPreset`は0以上のPodに適用されます。単一の`PodPreset`が1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`Env`、`EnvFrom`、`VolumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`Volume`への変更があった場合、KubernetesはそのPodのSpecを修正します。 + +{{< note >}} +単一のPodPresetは必要に応じてPodのSpec内の`.spec.containers`を修正することができます。PodPresetからのリソース定義は`initContainers`フィールドに対して1つも適用されません。 +{{< /note >}} + +### 特定のPodに対するPodPresetを無効にする + +PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。 +`podpreset.admission.kubernetes.io/exclude: "true"` + +## PodPresetを有効にする + +ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。 + +1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。 +1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`を追加することで可能になります。 +1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/) + +{{% /capture %}} diff --git a/content/ja/docs/contribute/_index.md b/content/ja/docs/contribute/_index.md new file mode 100644 index 0000000000..b452fa57f7 --- /dev/null +++ b/content/ja/docs/contribute/_index.md @@ -0,0 +1,59 @@ +--- +content_template: templates/concept +title: Kubernetesのドキュメントに貢献する +linktitle: 貢献 +main_menu: true +weight: 80 +--- + +{{% capture overview %}} + +あなたがKubernetesのドキュメンテーションやWebサイトに貢献するのを手伝いたいのであれば、私たちはあなたの貢献を嬉しく思います!プロジェクトに関わって日が浅いのか、それとも長きに渡って関わっているのか、開発者、エンドユーザ、または誤植に耐えられない人かどうかに関係なく、誰でも貢献できます。 + +Kubernetesコミュニティに参加する、または私たちについて学ぶためのより多くの方法については、[Kubernetesコミュニティサイト](/community/)をご覧ください。Kubernetesドキュメントのスタイルガイドについては、[スタイルガイド](/docs/contribute/style/style-guide/)を参照してください。 + +{{% capture body %}} + +## 寄稿者のタイプ + +- [CLAに署名](/docs/contribute/start#sign-the-cla)し、プロジェクトにいくらかの時間と努力を費やしたKubernetes組織の*メンバー*。メンバーシップの具体的な基準については、[コミュニティメンバーシップ](https://github.com/kubernetes/community/blob/master/community-membership.md)を参照してください。 +- SIG Docs*レビューワー*は、ドキュメントのプルリクエストのレビューに関心を示し、SIG Docs承認者によってGithubリポジトリの適切なGithubグループと`OWNERS`ファイルに追加されたKubernetes組織のメンバーです。 +- SIG Docs*承認者*は、プロジェクトに対する継続的なコミットメントを示している優秀なメンバーです。承認者はKubernetes組織に代わってプルリクエストをマージし、コンテンツを公開できます。承認者は、より大きなKubernetesコミュニティのSIG Docsを代表することもできます。リリースの調整など、SIG Docs承認者の任務の中には、かなりの時間を要するものがあります。 + +## 貢献する方法 + +このリストは、誰でもできること、Kubernetes組織のメンバーができること、そしてより高いレベルのアクセスとSIG Docsプロセスへの精通を必要とすることに分けられます。時間をかけて一貫して貢献することで、すでに行われた作業や組織上の決定について理解するのに役立ちます。 + +これはKubernetesのドキュメントに貢献できる方法の網羅的なリストではありませんが、始めるのに役立ちます。 + +- [全ての人](/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の確認 + - ダイアグラム、グラフィックアセット、および埋め込み可能なスクリーンキャスト/ビデオの作成 + - ローカライゼーション + - ドキュメントの代表として他のリポジトリに貢献する + - コード内のユーザー向け文字列を編集する + - Godoc、コードのコメントを改善する +- [承認者](/docs/contribute/advanced/) + - PRを承認およびマージして寄稿者コンテンツを公開 + - ドキュメント代表としてKubernetesリリースチームに参加する + - スタイルガイドに改善を提案する + - docsテストの改善を提案する + - KubernetesのWebサイトまたはその他のツールの改良を提案する + + +## 貢献するその他の方法 + +- TwitterやStack Overflowなどのオンラインフォーラムを通じてKubernetesコミュニティに貢献したり、ローカルのミートアップやKubernetesイベントについて学ぶには、[Kubernetesコミュニティサイト](/community/)にアクセスしてください。 +- 機能の開発に貢献するには、[コントリビューターチートシート](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)を読んで始めてください。 + +{{% /capture %}} diff --git a/content/ja/docs/home/_index.md b/content/ja/docs/home/_index.md index 4f086ca39b..ec4e3222fa 100644 --- a/content/ja/docs/home/_index.md +++ b/content/ja/docs/home/_index.md @@ -1,4 +1,5 @@ --- +approvers: title: Kubernetesドキュメント noedit: true cid: docsHome @@ -15,42 +16,42 @@ menu: post: >

チュートリアル、サンプルやドキュメントのリファレンスを使って Kubernetes の利用方法を学んでください。あなたはドキュメントへコントリビュートをすることもできます!

overview: > - Kubernetesは、自動デプロイ、スケーリング、およびコンテナ化されたアプリケーションの管理を行うための、オープンソースのコンテナオーケストレーションエンジンです。本オープンソースプロジェクトは、Cloud Native Computing Foundation (CNCF).によって管理されています。 + Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています(CNCF)。 cards: - name: concepts title: "基本を理解する" - description: "Kubernetesに基本的なコンセプトについて学びます。" + description: "Kubernetesとその基本的なコンセプトを学びます。" button: "コンセプトを学ぶ" - button_path: "/ja/docs/concepts" + button_path: "/docs/concepts" - name: tutorials - title: "Kubernetesを試用する" - description: "チュートリアルに沿って、Kubernetesにアプリケーションをデプロイする方法を学びます。" + title: "Kubernetesを試す" + description: "Kubernetesにどのようにアプリケーションを展開するかを、チュートリアルから学びます。" button: "チュートリアルを見る" - button_path: "/ja/docs/tutorials" + button_path: "/docs/tutorials" - name: setup - title: "クラスターを立ち上げる" - description: "ご自身のリソースや要件に合わせたKubernetes環境を動かしてみましょう。" - button: "Kubernetesをセットアップする" - button_path: "/ja/docs/setup" + title: "クラスターを構築する" + description: "リソースと要求に基づいて、Kubernetesを実行します。" + button: "Kubernetesを構築する" + button_path: "/docs/setup" - name: tasks title: "Kubernetesの使い方を学ぶ" - description: "一般的な使い方と、それらを実行するための短い手順を調べます。" - button: "View Tasks" - button_path: "/ja/docs/tasks" + description: "一般的なタスク、そのタスクを短い手順でどのように実行するかを見てみます。" + button: "タスクを見る" + button_path: "/docs/tasks" - name: reference - title: 参考情報を探す - description: 用語、コマンドラインの構文、APIのリソースタイプ、およびセットアップツールのドキュメントを参照します。 - button: View Reference - button_path: /ja/docs/reference + title: "リファレンス情報を調べる" + description: "用語、コマンドラインの構文、APIリソースタイプ、そして構築ツールのドキュメントを見て回ります。" + button: "リファレンスを見る" + button_path: /docs/reference - name: contribute - title: ドキュメントに貢献する - description: 本プロジェクトに不慣れな方でも、久しぶりの方も、どなたでも貢献することができます。 - button: ドキュメントに貢献する - button_path: /ja/docs/contribute + title: "ドキュメントにコントリビュートする" + description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることが出来ます。" + button: "ドキュメントにコントリビュートする" + button_path: /docs/contribute - name: download - title: Kubernetesをダウンロードする - description: Kubernetesをインストールする場合や最新バージョンにアップグレードする場合は、現在のリリースノートを参照してください。 + title: "Kubernetesをダウンロードする" + description: "もしKubernetesをインストールする、また最新バージョンにアップグレードする場合、最新のリリースノートを参照してください。" - name: about - title: ドキュメントについて - description: このWebサイトには、Kubernetesの現在および以前の4つのバージョンに関するドキュメントが含まれています。 + title: "ドキュメントについて" + description: "このサイトは、Kubernetesの最新バージョンと過去4世代のドキュメントを含んでいます。" --- diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..908ef77785 --- /dev/null +++ b/content/ja/docs/reference/glossary/controller.md @@ -0,0 +1,19 @@ +--- +title: Controller +id: controller +date: 2018-04-12 +full_link: /docs/admin/kube-controller-manager/ +short_description: > + クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。 + +aka: +tags: +- architecture +- fundamental +--- + クラスターの状態を{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}から取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。 + + + +今日、Kubernetesで提供されるコントローラーの例として、レプリケーションコントローラー、エンドポイントコントローラー、名前空間コントローラー、またサービスアカウントコントローラーがあります。 + diff --git a/content/ja/docs/reference/glossary/etcd.md b/content/ja/docs/reference/glossary/etcd.md new file mode 100755 index 0000000000..34f2c7335f --- /dev/null +++ b/content/ja/docs/reference/glossary/etcd.md @@ -0,0 +1,19 @@ +--- +title: etcd +id: etcd +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ +short_description: > + 一貫性、高可用性を持ったキーバリューストアで、Kubernetesの全てのクラスター情報の保存場所として利用されています。 + +aka: +tags: +- architecture +- storage +--- + 一貫性、高可用性を持ったキーバリューストアで、Kubernetesの全てのクラスター情報の保存場所として利用されています。 + + + +あなたのKubernetesクラスター情報を守るため、etcdのデータのバックアッププランを持っておいて下さい。etcdに関するより詳細な情報は、[etcdドキュメント](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)を確認してください。 + diff --git a/content/ja/docs/reference/glossary/kube-apiserver.md b/content/ja/docs/reference/glossary/kube-apiserver.md new file mode 100755 index 0000000000..9c9a130a2e --- /dev/null +++ b/content/ja/docs/reference/glossary/kube-apiserver.md @@ -0,0 +1,19 @@ +--- +title: kube-apiserver +id: kube-apiserver +date: 2018-04-12 +full_link: /docs/reference/generated/kube-apiserver/ +short_description: > + Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。 + +aka: +tags: +- architecture +- fundamental +--- + Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。 + + + +このコンポーネントは、水平スケールするように設計されています。つまり追加でインスタンスを足すことでスケール可能です。さらなる情報は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。 + diff --git a/content/ja/docs/reference/glossary/kube-controller-manager.md b/content/ja/docs/reference/glossary/kube-controller-manager.md new file mode 100755 index 0000000000..e38df64e71 --- /dev/null +++ b/content/ja/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,19 @@ +--- +title: kube-controller-manager +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/generated/kube-controller-manager/ +short_description: > + マスター上で動く、コントローラー群を動かすコンポーネントです。 + +aka: +tags: +- architecture +- fundamental +--- + マスター上で動く、{{< glossary_tooltip text="controllers" term_id="controller" >}}を動かすコンポーネントです。 + + + +論理的には、各{{< glossary_tooltip text="controller" term_id="controller" >}}は、それぞれ別のプロセスですが、複雑になるのを避けるため、一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。 + diff --git a/content/ja/docs/reference/glossary/kube-scheduler.md b/content/ja/docs/reference/glossary/kube-scheduler.md new file mode 100755 index 0000000000..3c97492e48 --- /dev/null +++ b/content/ja/docs/reference/glossary/kube-scheduler.md @@ -0,0 +1,18 @@ +--- +title: kube-scheduler +id: kube-scheduler +date: 2018-04-12 +full_link: /docs/reference/generated/kube-scheduler/ +short_description: > + マスター上で動くコンポーネントで、まだノードに紐付けられていない新規に作成されたPodを見張り、稼働させるべきノードを選択します。 + +aka: +tags: +- architecture +--- + マスター上で動くコンポーネントで、まだノードに紐付けられていない新規に作成されたPodを見張り、稼働させるべきノードを選択します。 + + + +スケジューリングで考慮される要因は個別、集合的なものを含んでおり、ハードウェア/ソフトウェア/ポリシーの制約、アフィニティ、アンチアフィニティ設定、データの保存位置関係、稼働しているワークロードごとの干渉と処理完了期限があります。 + diff --git a/content/ja/docs/reference/glossary/kubelet.md b/content/ja/docs/reference/glossary/kubelet.md new file mode 100755 index 0000000000..f9dbdc156b --- /dev/null +++ b/content/ja/docs/reference/glossary/kubelet.md @@ -0,0 +1,19 @@ +--- +title: Kubelet +id: kubelet +date: 2018-04-12 +full_link: /docs/reference/generated/kubelet +short_description: > + クラスター内の各ノードで稼働するエージェントです。コンテナがPod内で稼働していることを保証します。 + +aka: +tags: +- fundamental +- core-object +--- + クラスター内の各ノードで稼働するエージェントです。コンテナがPod内で稼働していることを保証します。 + + + +Kubeletは、様々な機構から提供されるPodSpecs情報を受け取り、それらのPodSpecs情報に記述されているコンテナが正常に稼働していることを保証します。Kubeletは、Kubernetes外で作成されたコンテナは管理しません。 + diff --git a/content/ja/docs/reference/glossary/name.md b/content/ja/docs/reference/glossary/name.md new file mode 100755 index 0000000000..c9b0bcd5ef --- /dev/null +++ b/content/ja/docs/reference/glossary/name.md @@ -0,0 +1,18 @@ +--- +title: 名前(Name) +id: name +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + クライアントから提供され、リソースURL内のオブジェクトを参照する文字列です。例えば`/api/v1/pods/何らかの名前`のようになります。 + +aka: +tags: +- fundamental +--- + クライアントから提供され、リソースURL内のオブジェクトを参照する文字列です。例えば`/api/v1/pods/何らかの名前`のようになります。 + + + +同じ種類のオブジェクトは、同じ名前を同時に持つことは出来ません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。 + diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md new file mode 100755 index 0000000000..3b23ea48ce --- /dev/null +++ b/content/ja/docs/reference/glossary/statefulset.md @@ -0,0 +1,24 @@ +--- +title: StatefulSet +id: statefulset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/statefulset/ +short_description: > + Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods. + +aka: +tags: +- fundamental +- core-object +- workload +- storage +--- + +StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}のセットのスケーリングの管理をし、それらのPodの*順序とユニーク性を保証* します。 + + + +{{< glossary_tooltip term_id="deployment" >}}のように、StatefulSetは指定したコンテナのspecに基づいてPodを管理します。Deploymentとは異なり、StatefulSetは各Podにおいて管理が大変な同一性を維持します。これらのPodは同一のspecから作成されますが、それらは交換可能ではなく、リスケジュール処理をまたいで維持される永続的な識別子を持ちます。 + +StatefulSetは他のコントローラーと同様のパターンで動作します。ユーザーはStatefulSet*オブジェクト* の理想的な状態を定義し、StatefulSet*コントローラー* は現在の状態から、理想状態になるために必要なアップデートを行います。 + diff --git a/content/ja/docs/reference/glossary/uid.md b/content/ja/docs/reference/glossary/uid.md new file mode 100755 index 0000000000..550e6fb988 --- /dev/null +++ b/content/ja/docs/reference/glossary/uid.md @@ -0,0 +1,18 @@ +--- +title: UID +id: uid +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + オブジェクトを一意に識別するためのKubernetesが生成する文字列です。 + +aka: +tags: +- fundamental +--- + オブジェクトを一意に識別するためのKubernetesが生成する文字列です。 + + + +Kubernetesクラスターの生存期間中にわたって生成された全てのオブジェクトは、異なるUIDを持っています。これは類似のエンティティの、同一時間軸での存在を区別するのが目的です。 + diff --git a/content/ja/docs/setup/minikube.md b/content/ja/docs/setup/minikube.md index 913a9b18ba..483f87c732 100644 --- a/content/ja/docs/setup/minikube.md +++ b/content/ja/docs/setup/minikube.md @@ -340,7 +340,7 @@ NodePort上では、 `NodePort` タイプのどのサービスもそのIPアド `kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'` -## 永続化ボリューム +## 永続ボリューム Minikubeは `hostPath` タイプの[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)をサポートします。 このPersistentVolumesはMinikubeのVM内のディレクトリーにマッピングされます。 diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md new file mode 100644 index 0000000000..2958ed3242 --- /dev/null +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -0,0 +1,142 @@ +--- +title: Serviceを利用したクラスター内のアプリケーションへのアクセス +content_template: templates/tutorial +weight: 60 +--- + +{{% capture overview %}} + +ここでは、クラスター内で稼働しているアプリケーションに外部からアクセスするために、KubernetesのServiceオブジェクトを作成する方法を紹介します。 +例として、2つのインスタンスから成るアプリケーションへのロードバランシングを扱います。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture objectives %}} + +* 2つのHellow Worldアプリケーションを稼働させる。 +* Nodeのポートを公開するServiceオブジェクトを作成する。 +* 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。 + +{{% /capture %}} + + +{{% capture lessoncontent %}} + +## 2つのPodから成るアプリケーションのServiceを作成 + +1. クラスタでHello Worldアプリケーションを稼働させます: + ```shell + kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080 + ``` + このコマンドは + [Deployment](/docs/concepts/workloads/controllers/deployment/) + オブジェクトとそれに紐付く + [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) + オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの + [Pod](/ja/docs/concepts/workloads/pods/pod/) + から構成されます。 + +1. Deploymentの情報を表示します: + ```shell + kubectl get deployments hello-world + kubectl describe deployments hello-world + ``` + +1. ReplicaSetオブジェクトの情報を表示します: + ```shell + kubectl get replicasets + kubectl describe replicasets + ``` + +1. Deploymentを公開するServiceオブジェクトを作成します: + ```shell + kubectl expose deployment hello-world --type=NodePort --name=example-service + ``` + +1. Serviceに関する情報を表示します: + ```shell + kubectl describe services example-service + ``` + 出力例は以下の通りです: + ```shell + Name: example-service + Namespace: default + Labels: run=load-balancer-example + Annotations: + Selector: run=load-balancer-example + Type: NodePort + IP: 10.32.0.16 + Port: 8080/TCP + TargetPort: 8080/TCP + NodePort: 31496/TCP + Endpoints: 10.200.1.4:8080,10.200.2.5:8080 + Session Affinity: None + Events: + ``` + NodePortの値を記録しておきます。上記の例では、31496です。 + +1. Hello Worldアプリーションが稼働しているPodを表示します: + ```shell + kubectl get pods --selector="run=load-balancer-example" --output=wide + ``` + 出力例は以下の通りです: + ```shell + NAME READY STATUS ... IP NODE + hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1 + hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2 + ``` +1. Hello World podが稼働するNodeのうち、いずれか1つのパブリックIPアドレスを確認します。 + 確認方法は、使用している環境により異なります。 + 例として、Minikubeの場合は`kubectl cluster-info`、Google Compute Engineの場合は`gcloud compute instances list`によって確認できます。 + +1. 選択したノード上で、NodePortの値でのTCP通信を許可するファイヤーウォールを作成します。 + NodePortの値が31568の場合、31568番のポートを利用したTCP通信を許可するファイヤーウォールを作成します。 + クラウドプロバイダーによって設定方法が異なります。 + +1. Hello World applicationにアクセスするために、Nodeのアドレスとポート番号を使用します: + ```shell + curl http://: + ``` + ここで `` はNodeのパブリックIPアドレス、 + `` はNodePort Serviceのポート番号の値を表しています。 + リクエストが成功すると、下記のメッセージが表示されます: + ```shell + Hello Kubernetes! + ``` + +## service configuration fileの利用 + +`kubectl expose`コマンドの代わりに、 +[service configuration file](/docs/concepts/services-networking/service/) +を使用してServiceを作成することもできます。 + +{{% /capture %}} + + +{{% capture cleanup %}} + +Serviceを削除するには、以下のコマンドを実行します: + + kubectl delete services example-service + +Hello Worldアプリケーションが稼働しているDeployment、ReplicaSet、Podを削除するには、以下のコマンドを実行します: + + kubectl delete deployment hello-world + +{{% /capture %}} + + +{{% capture whatsnext %}} + +詳細は +[serviceを利用してアプリケーションと接続する](/docs/concepts/services-networking/connect-applications-service/) +を確認してください。 +{{% /capture %}} diff --git a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md new file mode 100644 index 0000000000..e0acddd5f7 --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -0,0 +1,90 @@ +--- +title: コンテナライフサイクルイベントへのハンドラー紐付け +content_template: templates/task +weight: 140 +--- + +{{% capture overview %}} + +このページでは、コンテナのライフサイクルイベントにハンドラーを紐付けする方法を説明します。KubernetesはpostStartとpreStopイベントをサポートしています。Kubernetesはコンテナの起動直後にpostStartイベントを送信し、コンテナの終了直前にpreStopイベントを送信します。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + +## postStartハンドラーとpreStopハンドラーを定義する + +この課題では、1つのコンテナを持つPodを作成します。コンテナには、postStartイベントとpreStopイベントのハンドラーがあります。 + +これがPodの設定ファイルです: + +{{< codenew file="pods/lifecycle-events.yaml" >}} + +設定ファイルでは、postStartコマンドが`message`ファイルをコンテナの`/usr/share`ディレクトリに書き込むことがわかります。preStopコマンドはnginxを適切にシャットダウンします。これは、障害のためにコンテナが終了している場合に役立ちます。 + +Podを作成します: + + kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml + +Pod内のコンテナが実行されていることを確認します: + + kubectl get pod lifecycle-demo + +Pod内で実行されているコンテナでシェルを実行します: + + kubectl exec -it lifecycle-demo -- /bin/bash + +シェルで、`postStart`ハンドラーが`message`ファイルを作成したことを確認します: + + root@lifecycle-demo:/# cat /usr/share/message + +出力は、postStartハンドラーによって書き込まれたテキストを示しています。 + + Hello from the postStart handler + +{{% /capture %}} + + + +{{% capture discussion %}} + +## 議論 + +コンテナが作成された直後にKubernetesはpostStartイベントを送信します。 +ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。 + +Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。 +コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#podの終了)を参照してください。 + +{{< note >}} +Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。 +これは、Podが *完了* したときにpreStopフックが呼び出されないことを意味します。 +この制限は[issue #55087](https://github.com/kubernetes/kubernetes/issues/55807)で追跡されています。 +{{< /note >}} + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [コンテナライフサイクルフック](/ja/docs/concepts/containers/container-lifecycle-hooks/)の詳細 +* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)の詳細 + + +### 参照 + +* [ライフサイクル](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lifecycle-v1-core) +* [コンテナ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)の`terminationGracePeriodSeconds` + +{{% /capture %}} + + diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md new file mode 100644 index 0000000000..b9638ff0ba --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -0,0 +1,117 @@ +--- +title: Init Containerのデバッグ +content_template: templates/task +--- + +{{% capture overview %}} + +このページでは、Init Containerの実行に関連する問題を調査する方法を説明します。以下のコマンドラインの例では、Podを``、Init Containerを``および``として参照しています。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* [Init Container](/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。 +* [Init Containerを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。 + +{{% /capture %}} + +{{% capture steps %}} + +## Init Containerのステータスを確認する + +Podのステータスを表示します: + +```shell +kubectl get pod +``` + +たとえば、`Init:1/2`というステータスは、2つのInit Containerのうちの1つが正常に完了したことを示します。 + +``` +NAME READY STATUS RESTARTS AGE + 0/1 Init:1/2 0 7s +``` + +ステータス値とその意味の例については、[Podのステータスを理解する](#understanding-pod-status)を参照してください。 + +## Init Containerの詳細を取得する + +Init Containerの実行に関する詳細情報を表示します: + +```shell +kubectl describe pod +``` + +たとえば、2つのInit Containerを持つPodでは、次のように表示されます: + +``` +Init Containers: + : + Container ID: ... + ... + State: Terminated + Reason: Completed + Exit Code: 0 + Started: ... + Finished: ... + Ready: True + Restart Count: 0 + ... + : + Container ID: ... + ... + State: Waiting + Reason: CrashLoopBackOff + Last State: Terminated + Reason: Error + Exit Code: 1 + Started: ... + Finished: ... + Ready: False + Restart Count: 3 + ... +``` + +また、Pod Specの`status.initContainerStatuses`フィールドを読むことでプログラムでInit Containerのステータスにアクセスすることもできます。: + + +```shell +kubectl get pod nginx --template '{{.status.initContainerStatuses}}' +``` + + +このコマンドは生のJSONで上記と同じ情報を返します。 + +## Init Containerのログにアクセスする + +ログにアクセスするには、Init Container名とPod名を渡します。 + +```shell +kubectl logs -c +``` + +シェルスクリプトを実行するInit Containerは、実行時にコマンドを出力します。たとえば、スクリプトの始めに`set -x`を実行することでBashで同じことができます。 + +{{% /capture %}} + +{{% capture discussion %}} + +## Podのステータスを理解する + +`Init:`で始まるPodステータスはInit Containerの実行ステータスを要約します。以下の表は、Init Containerのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。 + +ステータス | 意味 +------ | ------- +`Init:N/M` | Podは`M`個のInit Containerを持ち、これまでに`N`個完了しました。 +`Init:Error` | Init Containerが実行に失敗しました。 +`Init:CrashLoopBackOff` | Init Containerが繰り返し失敗しました。 +`Pending` | PodはまだInit Containerの実行を開始していません。 +`PodInitializing` or `Running` | PodはすでにInit Containerの実行を終了しています。 + +{{% /capture %}} + + + diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md new file mode 100644 index 0000000000..817db0ecde --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -0,0 +1,40 @@ +--- +title: StatefulSetのデバッグ +content_template: templates/task +--- + +{{% capture overview %}} + +このタスクでは、StatefulSetをデバッグする方法を説明します。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +* Kubernetesクラスターが必要です。また、kubectlコマンドラインツールがクラスターと通信するように設定されている必要があります。 +* 調べたいStatefulSetを実行しておきましょう。 + +{{% /capture %}} + +{{% capture steps %}} + +## StatefulSetのデバッグ + +StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのPodを一覧表示するには、以下のコマンドを利用できます。 + +```shell +kubectl get pods -l app=myapp +``` + +Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/manage-stateful-set/delete-pods/)タスクを参照してください。 +[Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +[Init Containerのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)の詳細 + +{{% /capture %}} + + diff --git a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md new file mode 100644 index 0000000000..5de335c32b --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -0,0 +1,96 @@ +--- +title: Pod障害の原因を特定する +content_template: templates/task +--- + +{{% capture overview %}} + +このページでは、コンテナ終了メッセージの読み書き方法を説明します。 + +終了メッセージは、致命的なイベントに関する情報を、ダッシュボードや監視ソフトウェアなどのツールで簡単に取得して表示できる場所にコンテナが書き込むための手段を提供します。 ほとんどの場合、終了メッセージに入力した情報も一般的な[Kubernetesログ](/docs/concepts/cluster-administration/logging/)に書き込まれるはずです。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + +## 終了メッセージの書き込みと読み取り + +この課題では、1つのコンテナを実行するPodを作成します。 +設定ファイルには、コンテナの開始時に実行されるコマンドを指定します。 + +{{< codenew file="debug/termination.yaml" >}} + +1. YAML設定ファイルに基づいてPodを作成します: + + kubectl apply -f https://k8s.io/examples/debug/termination.yaml + + YAMLファイルの`cmd`フィールドと`args`フィールドで、コンテナが10秒間スリープしてから`/dev/termination-log`ファイルに「Sleep expired」と書いているのがわかります。コンテナが「Sleep expired」メッセージを書き込んだ後、コンテナは終了します。 + +1. Podに関する情報を表示します: + + kubectl get pod termination-demo + + Podが実行されなくなるまで、上記のコマンドを繰り返します。 + +1. Podに関する詳細情報を表示します: + + kubectl get pod termination-demo --output=yaml + + 出力には「Sleep expired」メッセージが含まれています: + + apiVersion: v1 + kind: Pod + ... + lastState: + terminated: + containerID: ... + exitCode: 0 + finishedAt: ... + message: | + Sleep expired + ... + +1. Goテンプレートを使用して、終了メッセージのみが含まれるように出力をフィルタリングします: + + kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}" + +## 終了メッセージのカスタマイズ + +Kubernetesは、コンテナの`terminationMessagePath`フィールドで指定されている終了メッセージファイルから終了メッセージを取得します。デフォルト値は`/dev/termination-log`です。このフィールドをカスタマイズすることで、Kubernetesに別のファイルを使うように指示できます。Kubernetesは指定されたファイルの内容を使用して、成功と失敗の両方についてコンテナのステータスメッセージを入力します。 + +次の例では、コンテナはKubernetesが取得するために終了メッセージを`/tmp/my-log`に書き込みます: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: msg-path-demo +spec: + containers: + - name: msg-path-demo-container + image: debian + terminationMessagePath: "/tmp/my-log" +``` + +さらに、ユーザーは追加のカスタマイズをするためにContainerの`terminationMessagePolicy`フィールドを設定できます。このフィールドのデフォルト値は`File`です。これは、終了メッセージが終了メッセージファイルからのみ取得されることを意味します。`terminationMessagePolicy`を`FallbackToLogsOnError`に設定することで、終了メッセージファイルが空でコンテナがエラーで終了した場合に、コンテナログ出力の最後のチャンクを使用するようにKubernetesに指示できます。ログ出力は、2048バイトまたは80行のどちらか小さい方に制限されています。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [コンテナ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)の`terminationMessagePath`フィールド参照 +* [ログ取得](/docs/concepts/cluster-administration/logging/)について +* [Goテンプレート](https://golang.org/pkg/text/template/)について + +{{% /capture %}} + + + diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md new file mode 100644 index 0000000000..40f903789f --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -0,0 +1,142 @@ +--- +title: 実行中のコンテナへのシェルを取得する +content_template: templates/task +--- + +{{% capture overview %}} + + +このページは`kubectl exec`を使用して実行中のコンテナへのシェルを取得する方法を説明します。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + +## コンテナへのシェルの取得 + +このエクササイズでは、1つのコンテナを持つPodを作成します。 +コンテナはnginxのイメージを実行します。以下がそのPodの設定ファイルです: + +{{< codenew file="application/shell-demo.yaml" >}} + +Podを作成します: + +```shell +kubectl create -f https://k8s.io/examples/application/shell-demo.yaml +``` + +コンテナが実行中であることを確認します: + +```shell +kubectl get pod shell-demo +``` + +実行中のコンテナへのシェルを取得します: + +```shell +kubectl exec -it shell-demo -- /bin/bash +``` +{{< note >}} + +ダブルダッシュの記号 "--" はコマンドに渡す引数とkubectlの引数を分離します。 + +{{< /note >}} + +シェル内で、ルートディレクトリーのファイル一覧を表示します: + +```shell +root@shell-demo:/# ls / +``` + +シェル内で、他のコマンドを試しましょう。以下がいくつかの例です: + +```shell +root@shell-demo:/# ls / +root@shell-demo:/# cat /proc/mounts +root@shell-demo:/# cat /proc/1/maps +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install -y tcpdump +root@shell-demo:/# tcpdump +root@shell-demo:/# apt-get install -y lsof +root@shell-demo:/# lsof +root@shell-demo:/# apt-get install -y procps +root@shell-demo:/# ps aux +root@shell-demo:/# ps aux | grep nginx +``` + +## nginxのルートページへの書き込み + +Podの設定ファイルを再度確認します。Podは`emptyDir`ボリュームを持ち、 +コンテナは`/usr/share/nginx/html`ボリュームをマウントします。 + +シェル内で、`/usr/share/nginx/html`ディレクトリに`index.html`を作成します。 + +```shell +root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html +``` + +シェル内で、nginxサーバーにGETリクエストを送信します: + +```shell +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install curl +root@shell-demo:/# curl localhost +``` + +出力に`index.html`ファイルに書き込んだ文字列が表示されます: + +```shell +Hello shell demo +``` + +シェルを終了する場合、`exit`を入力します。 + +## コンテナ内での各コマンドの実行 + +シェルではない通常のコマンドウインドウ内で、実行中のコンテナの環境変数の一覧を表示します: + +```shell +kubectl exec shell-demo env +``` + +他のコマンドを試します。以下がいくつかの例です: + +```shell +kubectl exec shell-demo ps aux +kubectl exec shell-demo ls / +kubectl exec shell-demo cat /proc/1/mounts +``` + +{{% /capture %}} + +{{% capture discussion %}} + +## Podが1つ以上のコンテナを持つ場合にシェルを開く + +Podが1つ以上のコンテナを持つ場合、`--container`か`-c`を使用して、`kubectl exec`コマンド内でコンテナを指定します。 +例えば、my-podという名前のPodがあり、そのPodがmain-appとhelper-appという2つのコンテナを持つとします。 +以下のコマンドはmain-appのコンテナへのシェルを開きます。 + +```shell +kubectl exec -it my-pod --container main-app -- /bin/bash +``` + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) + +{{% /capture %}} + + + diff --git a/content/ja/docs/tasks/run-application/delete-stateful-set.md b/content/ja/docs/tasks/run-application/delete-stateful-set.md new file mode 100644 index 0000000000..d6f7d981e4 --- /dev/null +++ b/content/ja/docs/tasks/run-application/delete-stateful-set.md @@ -0,0 +1,85 @@ +--- +title: StatefulSetの削除 +content_template: templates/task +weight: 60 +--- + +{{% capture overview %}} + +このタスクでは、StatefulSetを削除する方法を説明します。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +* このタスクは、クラスター上で、StatefulSetで表現されるアプリケーションが実行されていることを前提としています。 + +{{% /capture %}} + +{{% capture steps %}} + +## StatefulSetの削除 + +Kubernetesで他のリソースを削除するのと同じ方法でStatefulSetを削除することができます。つまり、`kubectl delete`コマンドを使い、StatefulSetをファイルまたは名前で指定します。 + +```shell +kubectl delete -f +``` + +```shell +kubectl delete statefulsets +``` + +StatefulSet自体が削除された後で、関連するヘッドレスサービスを個別に削除する必要があるかもしれません。 + +```shell +kubectl delete service +``` + +kubectlを使ってStatefulSetを削除すると0にスケールダウンされ、すべてのPodが削除されます。PodではなくStatefulSetだけを削除したい場合は、`--cascade=false`を使用してください。 + +```shell +kubectl delete -f --cascade=false +``` + +`--cascade=false`を`kubectl delete`に渡すことで、StatefulSetオブジェクト自身が削除された後でも、StatefulSetによって管理されていたPodは残ります。Podに`app=myapp`というラベルが付いている場合は、次のようにして削除できます: + +```shell +kubectl delete pods -l app=myapp +``` + +### 永続ボリューム + +StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#podの終了)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。 + +{{< note >}} +データを損失する可能性があるため、PVCを削除するときは注意してください。 +{{< /note >}} + +### StatefulSetの完全削除 + +関連付けられたPodを含むStatefulSet内のすべてのものを単純に削除するには、次のような一連のコマンドを実行します: + +```shell +grace=$(kubectl get pods --template '{{.spec.terminationGracePeriodSeconds}}') +kubectl delete statefulset -l app=myapp +sleep $grace +kubectl delete pvc -l app=myapp + +``` + +上の例では、Podは`app=myapp`というラベルを持っています。必要に応じてご利用のラベルに置き換えてください。 + +### StatefulSet Podの強制削除 + +StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細 + +{{% /capture %}} + + diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md new file mode 100644 index 0000000000..b76b8e0ada --- /dev/null +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -0,0 +1,490 @@ +--- +title: レプリカを持つステートフルアプリケーションを実行する +content_template: templates/tutorial +weight: 30 +--- + +{{% capture overview %}} + +このページでは、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +コントローラーを使用して、レプリカを持つステートフルアプリケーションを実行する方法を説明します。 +ここでの例は、非同期レプリケーションを行う複数のスレーブを持つ、単一マスターのMySQLです。 + +**この例は本番環境向けの構成ではない**ことに注意してください。 +具体的には、MySQLの設定が安全ではないデフォルトのままとなっています。 +これはKubernetesでステートフルアプリケーションを実行するための一般的なパターンに焦点を当てるためです。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* {{< include "default-storage-class-prereqs.md" >}} +* このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/) + と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、 + さらには[Pod](/ja/docs/concepts/workloads/pods/pod/)、 + [Service](/docs/concepts/services-networking/service/)、 + [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの + 他のコアな概念に精通していることを前提としています。 +* MySQLに関する知識は記事の理解に役立ちますが、 + このチュートリアルは他のシステムにも役立つ一般的なパターンを提示することを目的としています。 + +{{% /capture %}} + +{{% capture objectives %}} + +* StatefulSetコントローラーを使用して、レプリカを持つMySQLトポロジーをデプロイします。 +* MySQLクライアントトラフィックを送信します。 +* ダウンタイムに対する耐性を観察します。 +* StatefulSetをスケールアップおよびスケールダウンします。 + +{{% /capture %}} + +{{% capture lessoncontent %}} + +## MySQLをデプロイする + +このMySQLのデプロイの例は、1つのConfigMap、2つのService、および1つのStatefulSetから構成されます。 + +### ConfigMap + +次のYAML設定ファイルからConfigMapを作成します。 + +```shell +kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml +``` + +{{< codenew file="application/mysql/mysql-configmap.yaml" >}} + +このConfigMapは、MySQLマスターとスレーブの設定を独立して制御するために、 +それぞれの`my.cnf`を上書きする内容を提供します。 +この場合、マスターはスレーブにレプリケーションログを提供するようにし、 +スレーブはレプリケーション以外の書き込みを拒否するようにします。 + +ConfigMap自体に特別なことはありませんが、ConfigMapの各部分は異なるPodに適用されます。 +各Podは、StatefulSetコントローラーから提供される情報に基づいて、 +初期化時にConfigMapのどの部分を見るかを決定します。 + +### Services + +以下のYAML設定ファイルからServiceを作成します。 + +```shell +kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml +``` + +{{< codenew file="application/mysql/mysql-services.yaml" >}} + +ヘッドレスサービスは、StatefulSetコントローラーが +StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。 +この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスタの +同じ名前空間内の他のPodは、`.mysql`を名前解決することでPodにアクセスできます。 + +`mysql-read`と呼ばれるクライアントサービスは、独自のクラスタIPを持つ通常のServiceであり、 +Ready状態のすべてのMySQL Podに接続を分散します。 +Serviceのエンドポイントには、MySQLマスターとすべてのスレーブが含まれる可能性があります。 + +読み込みクエリーのみが、負荷分散されるクライアントサービスを使用できることに注意してください。 +MySQLマスターは1つしかいないため、クライアントが書き込みを実行するためには、 +(ヘッドレスサービス内のDNSエントリーを介して)MySQLのマスターPodに直接接続する必要があります。 + +### StatefulSet + +最後に、次のYAML設定ファイルからStatefulSetを作成します。 + +```shell +kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml +``` + +{{< codenew file="application/mysql/mysql-statefulset.yaml" >}} + +次のコマンドを実行して起動の進行状況を確認できます。 + +```shell +kubectl get pods -l app=mysql --watch +``` + +しばらくすると、3つのPodすべてがRunning状態になるはずです。 + +``` +NAME READY STATUS RESTARTS AGE +mysql-0 2/2 Running 0 2m +mysql-1 2/2 Running 0 1m +mysql-2 2/2 Running 0 1m +``` + +**Ctrl+C**を押してウォッチをキャンセルします。 +起動が進行しない場合は、[始める前に](#始める前に)で説明されているように、 +PersistentVolumeの動的プロビジョニング機能が有効になっていることを確認してください。 + +このマニフェストでは、StatefulSetの一部としてステートフルなPodを管理するためにさまざまな手法を使用しています。 +次のセクションでは、これらの手法のいくつかに焦点を当て、StatefulSetがPodを作成するときに何が起こるかを説明します。 + +## ステートフルなPodの初期化を理解する + +StatefulSetコントローラーは、序数インデックスの順にPodを一度に1つずつ起動します。 +各PodがReady状態を報告するまで待機してから、その次のPodの起動が開始されます。 + +さらに、コントローラーは各Podに `-`という形式の一意で不変の名前を割り当てます。 +この例の場合、Podの名前は`mysql-0`、`mysql-1`、そして`mysql-2`となります。 + +上記のStatefulSetマニフェスト内のPodテンプレートは、これらのプロパティーを利用して、 +MySQLレプリケーションの起動を順序正しく実行します。 + +### 構成を生成する + +Podスペック内のコンテナを起動する前に、Podは最初に +[初期化コンテナ](/ja/docs/concepts/workloads/pods/init-containers/)を定義された順序で実行します。 + +最初の初期化コンテナは`init-mysql`という名前で、序数インデックスに基づいて特別なMySQL設定ファイルを生成します。 + +スクリプトは、`hostname`コマンドによって返されるPod名の末尾から抽出することによって、自身の序数インデックスを特定します。 +それから、序数を(予約された値を避けるために数値オフセット付きで)MySQLの`conf.d`ディレクトリーの`server-id.cnf`というファイルに保存します。 +これは、StatefulSetコントローラーによって提供される一意で不変のIDを、同じ特性を必要とするMySQLサーバーIDの領域に変換します。 + +さらに、`init-mysql`コンテナ内のスクリプトは、`master.cnf`または`slave.cnf`のいずれかを、 +ConfigMapから内容を`conf.d`にコピーすることによって適用します。 +このトポロジー例は単一のMySQLマスターと任意の数のスレーブで構成されているため、 +スクリプトは単に序数の`0`がマスターになるように、それ以外のすべてがスレーブになるように割り当てます。 +StatefulSetコントローラーによる +[デプロイ順序の保証](/ja/docs/concepts/workloads/controllers/statefulset/#デプロイとスケーリングの保証)と組み合わせると、 +スレーブが作成される前にMySQLマスターがReady状態になるため、スレーブはレプリケーションを開始できます。 + +### 既存データをクローンする + +一般に、新しいPodがセットにスレーブとして参加するときは、 +MySQLマスターにはすでにデータがあるかもしれないと想定する必要があります。 +また、レプリケーションログが期間の先頭まで全て揃っていない場合も想定する必要があります。 +これらの控えめな仮定は、実行中のStatefulSetのサイズを初期サイズに固定するのではなく、 +時間の経過とともにスケールアップまたはスケールダウンできるようにするために重要です。 + +2番目の初期化コンテナは`clone-mysql`という名前で、スレーブPodが空のPersistentVolumeで最初に起動したときに、 +クローン操作を実行します。 +つまり、実行中の別のPodから既存のデータをすべてコピーするので、 +そのローカル状態はマスターからレプリケーションを開始するのに十分な一貫性があります。 + +MySQL自体はこれを行うためのメカニズムを提供していないため、この例ではPercona XtraBackupという人気のあるオープンソースツールを使用しています。 +クローンの実行中は、ソースとなるMySQLサーバーのパフォーマンスが低下する可能性があります。 +MySQLマスターへの影響を最小限に抑えるために、スクリプトは各Podに序数インデックスが自分より1低いPodからクローンするように指示します。 +StatefulSetコントローラーは、`N+1`のPodを開始する前には必ず`N`のPodがReady状態であることを保証するので、この方法が機能します。 + +### レプリケーションを開始する + +初期化コンテナが正常に完了すると、通常のコンテナが実行されます。 +MySQLのPodは実際に`mysqld`サーバーを実行する`mysql`コンテナと、 +[サイドカー](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) +として機能する`xtrabackup`コンテナから成ります。 + +`xtrabackup`サイドカーはクローンされたデータファイルを見て、 +スレーブ上でMySQLレプリケーションを初期化する必要があるかどうかを決定します。 +もし必要がある場合、`mysqld`が準備できるのを待ってから、 +XtraBackupクローンファイルから抽出されたレプリケーションパラメーターで`CHANGE MASTER TO`と`START SLAVE`コマンドを実行します。 + +スレーブがレプリケーションを開始すると、スレーブはMySQLマスターを記憶し、 +サーバーが再起動した場合または接続が停止した場合に、自動的に再接続します。 +また、スレーブはその不変のDNS名(`mysql-0.mysql`)でマスターを探すため、 +再スケジュールされたために新しいPod IPを取得したとしても、自動的にマスターを見つけます。 + +最後に、レプリケーションを開始した後、`xtrabackup`コンテナはデータのクローンを要求する他のPodからの接続を待ち受けます。 +StatefulSetがスケールアップした場合や、次のPodがPersistentVolumeClaimを失ってクローンをやり直す必要がある場合に備えて、 +このサーバーは無期限に起動したままになります。 + +## クライアントトラフィックを送信する + +テストクエリーをMySQLマスター(ホスト名 `mysql-0.mysql`)に送信するには、 +`mysql:5.7`イメージを使って一時的なコンテナーを実行し、`mysql`クライアントバイナリーを実行します。 + +```shell +kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\ + mysql -h mysql-0.mysql <`は前のステップで確認したノードの名前に置き換えてください。 + +この操作はノード上の他のアプリケーションに影響を与える可能性があるため、 +**テストクラスタでのみこの操作を実行**するのが最善です。 + +```shell +kubectl drain --force --delete-local-data --ignore-daemonsets +``` + +Podが別のノードに再スケジュールされる様子を確認しましょう。 + +```shell +kubectl get pod mysql-2 -o wide --watch +``` + +次のような出力が見られるはずです。 + +``` +NAME READY STATUS RESTARTS AGE IP NODE +mysql-2 2/2 Terminating 0 15m 10.244.1.56 kubernetes-minion-group-9l2t +[...] +mysql-2 0/2 Pending 0 0s kubernetes-minion-group-fjlm +mysql-2 0/2 Init:0/2 0 0s kubernetes-minion-group-fjlm +mysql-2 0/2 Init:1/2 0 20s 10.244.5.32 kubernetes-minion-group-fjlm +mysql-2 0/2 PodInitializing 0 21s 10.244.5.32 kubernetes-minion-group-fjlm +mysql-2 1/2 Running 0 22s 10.244.5.32 kubernetes-minion-group-fjlm +mysql-2 2/2 Running 0 30s 10.244.5.32 kubernetes-minion-group-fjlm +``` + +また、サーバーID`102`が`SELECT @@server_id`ループの出力からしばらくの消えて、 +そして戻ることが確認できるはずです。 + +それでは、ノードをuncordonして正常な状態に戻しましょう。 + +```shell +kubectl uncordon +``` + +## スレーブの数をスケーリングする + +MySQLレプリケーションでは、スレーブを追加することで読み取りクエリーのキャパシティーをスケールできます。 +StatefulSetを使用している場合、単一のコマンドでこれを実行できます。 + +```shell +kubectl scale statefulset mysql --replicas=5 +``` + +次のコマンドを実行して、新しいPodが起動してくるのを確認します。 + +```shell +kubectl get pods -l app=mysql --watch +``` + +新しいPodが起動すると、サーバーID`103`と`104`が`SELECT @@server_id`ループの出力に現れます。 + +また、これらの新しいサーバーが、これらのサーバーが存在する前に追加したデータを持っていることを確認することもできます。 + +```shell +kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\ + mysql -h mysql-3.mysql -e "SELECT * FROM test.messages" +``` + +``` +Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false ++---------+ +| message | ++---------+ +| hello | ++---------+ +pod "mysql-client" deleted +``` + +元の状態へのスケールダウンもシームレスに可能です。 + +```shell +kubectl scale statefulset mysql --replicas=3 +``` + +ただし、スケールアップすると新しいPersistentVolumeClaimが自動的に作成されますが、 +スケールダウンしてもこれらのPVCは自動的には削除されないことに注意して下さい。 +このため、初期化されたPVCをそのまま置いておいくことで再スケールアップを速くしたり、 +PVを削除する前にデータを抽出するといった選択が可能になります。 + +次のコマンドを実行してこのことを確認できます。 + +```shell +kubectl get pvc -l app=mysql +``` + +StatefulSetを3にスケールダウンしたにもかかわらず、5つのPVCすべてがまだ存在しています。 + +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +data-mysql-0 Bound pvc-8acbf5dc-b103-11e6-93fa-42010a800002 10Gi RWO 20m +data-mysql-1 Bound pvc-8ad39820-b103-11e6-93fa-42010a800002 10Gi RWO 20m +data-mysql-2 Bound pvc-8ad69a6d-b103-11e6-93fa-42010a800002 10Gi RWO 20m +data-mysql-3 Bound pvc-50043c45-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m +data-mysql-4 Bound pvc-500a9957-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m +``` + +余分なPVCを再利用するつもりがないのであれば、削除することができます。 + +```shell +kubectl delete pvc data-mysql-3 +kubectl delete pvc data-mysql-4 +``` + +{{% /capture %}} + +{{% capture cleanup %}} + +1. `SELECT @@server_id`ループを実行している端末で**Ctrl+C**を押すか、 + 別の端末から次のコマンドを実行して、ループをキャンセルします。 + + ```shell + kubectl delete pod mysql-client-loop --now + ``` + +1. StatefulSetを削除します。これによってPodの終了も開始されます。 + + ```shell + kubectl delete statefulset mysql + ``` + +1. Podが消えたことを確認します。 + Podが終了処理が完了するのには少し時間がかかるかもしれません。 + + ```shell + kubectl get pods -l app=mysql + ``` + + 上記のコマンドから以下の出力が戻れば、Podが終了したことがわかります。 + + ``` + No resources found. + ``` + +1. ConfigMap、Services、およびPersistentVolumeClaimを削除します。 + + ```shell + kubectl delete configmap,service,pvc -l app=mysql + ``` + +1. PersistentVolumeを手動でプロビジョニングした場合は、それらを手動で削除し、 + また、下層にあるリソースも解放する必要があります。 + 動的プロビジョニング機能を使用した場合は、PersistentVolumeClaimを削除すれば、自動的にPersistentVolumeも削除されます。 + 一部の動的プロビジョナー(EBSやPDなど)は、PersistentVolumeを削除すると同時に下層にあるリソースも解放します。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* その他のステートフルアプリケーションの例は、[Helm Charts repository](https://github.com/kubernetes/charts)を見てください。 + +{{% /capture %}} + + + diff --git a/content/ja/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/ja/docs/tasks/run-application/run-single-instance-stateful-application.md new file mode 100644 index 0000000000..ce6e5643af --- /dev/null +++ b/content/ja/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -0,0 +1,181 @@ +--- +title: 単一レプリカのステートフルアプリケーションを実行する +content_template: templates/tutorial +weight: 20 +--- + +{{% capture overview %}} + +このページでは、PersistentVolumeとDeploymentを使用して、Kubernetesで単一レプリカのステートフルアプリケーションを実行する方法を説明します。アプリケーションはMySQLです。 + +{{% /capture %}} + + +{{% capture objectives %}} + +* 自身の環境のディスクを参照するPersistentVolumeを作成します。 +* MySQLのDeploymentを作成します。 +* MySQLをDNS名でクラスター内の他のPodに公開します。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* {{< include "default-storage-class-prereqs.md" >}} + +{{% /capture %}} + + +{{% capture lessoncontent %}} + +## MySQLをデプロイする + +Kubernetes Deploymentを作成し、PersistentVolumeClaimを使用して既存のPersistentVolumeに接続することで、ステートフルアプリケーションを実行できます。 +たとえば、以下のYAMLファイルはMySQLを実行し、PersistentVolumeClaimを参照するDeploymentを記述しています。 +このファイルは/var/lib/mysqlのボリュームマウントを定義してから、20Gのボリュームを要求するPersistentVolumeClaimを作成します。 +この要求は、要件を満たす既存のボリューム、または動的プロビジョナーによって満たされます。 + +注:パスワードはYAMLファイル内に定義されており、これは安全ではありません。安全な解決策については[Kubernetes Secret](/docs/concepts/configuration/secret/)を参照してください 。 + +{{< codenew file="application/mysql/mysql-deployment.yaml" >}} +{{< codenew file="application/mysql/mysql-pv.yaml" >}} + +1. YAMLファイルに記述されたPVとPVCをデプロイします。 + + kubectl create -f https://k8s.io/examples/application/mysql/mysql-pv.yaml + +1. YAMLファイルの内容をデプロイします。 + + kubectl create -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml + +1. 作成したDeploymentの情報を表示します。 + + kubectl describe deployment mysql + + Name: mysql + Namespace: default + CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700 + Labels: app=mysql + Annotations: deployment.kubernetes.io/revision=1 + Selector: app=mysql + Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable + StrategyType: Recreate + MinReadySeconds: 0 + Pod Template: + Labels: app=mysql + Containers: + mysql: + Image: mysql:5.6 + Port: 3306/TCP + Environment: + MYSQL_ROOT_PASSWORD: password + Mounts: + /var/lib/mysql from mysql-persistent-storage (rw) + Volumes: + mysql-persistent-storage: + Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) + ClaimName: mysql-pv-claim + ReadOnly: false + Conditions: + Type Status Reason + ---- ------ ------ + Available False MinimumReplicasUnavailable + Progressing True ReplicaSetUpdated + OldReplicaSets: + NewReplicaSet: mysql-63082529 (1/1 replicas created) + Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1 + +1. Deploymentによって作成されたPodを一覧表示します。 + + kubectl get pods -l app=mysql + + NAME READY STATUS RESTARTS AGE + mysql-63082529-2z3ki 1/1 Running 0 3m + +1. PersistentVolumeClaimを確認します。 + + kubectl describe pvc mysql-pv-claim + + Name: mysql-pv-claim + Namespace: default + StorageClass: + Status: Bound + Volume: mysql-pv-volume + Labels: + Annotations: pv.kubernetes.io/bind-completed=yes + pv.kubernetes.io/bound-by-controller=yes + Capacity: 20Gi + Access Modes: RWO + Events: + +## MySQLインスタンスにアクセスする + +前述のYAMLファイルは、クラスター内の他のPodがデータベースにアクセスできるようにするServiceを作成します。 +Serviceのオプションで`clusterIP: None`を指定すると、ServiceのDNS名がPodのIPアドレスに直接解決されます。 +このオプションは、ServiceのバックエンドのPodが1つのみであり、Podの数を増やす予定がない場合に適しています。 + +MySQLクライアントを実行してサーバーに接続します。 + +``` +kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword +``` + +このコマンドは、クラスター内にMySQLクライアントを実行する新しいPodを作成し、Serviceを通じてMySQLサーバーに接続します。 +接続できれば、ステートフルなMySQLデータベースが稼働していることが確認できます。 + +``` +Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false +If you don't see a command prompt, try pressing enter. + +mysql> +``` + +## アップデート + +イメージまたはDeploymentの他の部分は、`kubectl apply`コマンドを使用して通常どおりに更新できます。 +ステートフルアプリケーションに固有のいくつかの注意事項を以下に記載します。 + +* アプリケーションをスケールしないでください。このセットアップは単一レプリカのアプリケーション専用です。 + 下層にあるPersistentVolumeは1つのPodにしかマウントできません。 + クラスター化されたステートフルアプリケーションについては、[StatefulSetのドキュメント](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。 +* Deploymentを定義するYAMLファイルでは`strategy: type: Recreate`を使用して下さい。 + この設定はKubernetesにローリングアップデートを使用 _しない_ ように指示します。 + 同時に複数のPodを実行することはできないため、ローリングアップデートは使用できません。 + `Recreate`戦略は、更新された設定で新しいPodを作成する前に、最初のPodを停止します。 + +## Deploymentの削除 + +名前を指定してデプロイしたオブジェクトを削除します。 + +``` +kubectl delete deployment,svc mysql +kubectl delete pvc mysql-pv-claim +kubectl delete pv mysql-pv-volume +``` + +PersistentVolumeを手動でプロビジョニングした場合は、PersistentVolumeを手動で削除し、また、下層にあるリソースも解放する必要があります。 +動的プロビジョニング機能を使用した場合は、PersistentVolumeClaimを削除すれば、自動的にPersistentVolumeも削除されます。 +一部の動的プロビジョナー(EBSやPDなど)は、PersistentVolumeを削除すると同時に下層にあるリソースも解放します。 + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [Deploymentオブジェクト](/docs/concepts/workloads/controllers/deployment/)についてもっと学ぶ + +* [アプリケーションのデプロイ](/docs/user-guide/deploying-applications/)についてもっと学ぶ + +* [kubectl runのドキュメント](/docs/reference/generated/kubectl/kubectl-commands/#run) + +* [Volumes](/docs/concepts/storage/volumes/)と[Persistent Volumes](/docs/concepts/storage/persistent-volumes/) + +{{% /capture %}} + + diff --git a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md new file mode 100644 index 0000000000..c38b40171a --- /dev/null +++ b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md @@ -0,0 +1,150 @@ +--- +title: Deploymentを使用してステートレスアプリケーションを実行する +min-kubernetes-server-version: v1.9 +content_template: templates/tutorial +weight: 10 +--- + +{{% capture overview %}} + +このページでは、Kubernetes Deploymentオブジェクトを使用してアプリケーションを実行する方法を説明します。 + +{{% /capture %}} + + +{{% capture objectives %}} + +* nginx deploymentを作成します。 +* kubectlを使ってdeploymentに関する情報を一覧表示します。 +* deploymentを更新します。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture lessoncontent %}} + +## nginx deploymentの作成と探検 + +Kubernetes Deploymentオブジェクトを作成することでアプリケーションを実行できます。また、YAMLファイルでDeploymentを記述できます。例えば、このYAMLファイルはnginx:1.7.9 Dockerイメージを実行するデプロイメントを記述しています: + +{{< codenew file="application/deployment.yaml" >}} + + +1. YAMLファイルに基づいてDeploymentを作成します: + + kubectl apply -f https://k8s.io/examples/application/deployment.yaml + +1. Deploymentに関する情報を表示します: + + kubectl describe deployment nginx-deployment + + 出力はこのようになります: + + user@computer:~/website$ kubectl describe deployment nginx-deployment + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=1 + Selector: app=nginx + Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 1 max unavailable, 1 max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.7.9 + Port: 80/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created) + No events. + +1. Deploymentによって作成されたPodを一覧表示します: + + kubectl get pods -l app=nginx + + 出力はこのようになります: + + NAME READY STATUS RESTARTS AGE + nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h + nginx-deployment-1771418926-r18az 1/1 Running 0 16h + +1. Podに関する情報を表示します: + + kubectl describe pod + + ここで``はPodの1つの名前を指定します。 + +## Deploymentの更新 + +新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.8を使用するように指定しています。 + +{{< codenew file="application/deployment-update.yaml" >}} + +1. 新しいYAMLファイルを適用します: + + kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml + +1. Deploymentが新しい名前でPodを作成し、古いPodを削除するのを監視します: + + kubectl get pods -l app=nginx + +## レプリカ数を増やすことによるアプリケーションのスケール + +新しいYAMLファイルを適用することで、Deployment内のPodの数を増やすことができます。このYAMLファイルは`replicas`を4に設定します。これはDeploymentが4つのPodを持つべきであることを指定します: + +{{< codenew file="application/deployment-scale.yaml" >}} + +1. 新しいYAMLファイルを適用します: + + kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml + +1. Deploymentに4つのPodがあることを確認します: + + kubectl get pods -l app=nginx + + 出力はこのようになります: + + NAME READY STATUS RESTARTS AGE + nginx-deployment-148880595-4zdqq 1/1 Running 0 25s + nginx-deployment-148880595-6zgi1 1/1 Running 0 25s + nginx-deployment-148880595-fxcez 1/1 Running 0 2m + nginx-deployment-148880595-rwovn 1/1 Running 0 2m + +## Deploymentの削除 + +Deploymentを名前を指定して削除します: + + kubectl delete deployment nginx-deployment + +## ReplicationControllers -- 昔のやり方 + +複製アプリケーションを作成するための好ましい方法はDeploymentを使用することです。そして、DeploymentはReplicaSetを使用します。 DeploymentとReplicaSetがKubernetesに追加される前は、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を使用して複製アプリケーションを構成していました。 + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [Deploymentオブジェクト](/docs/concepts/workloads/controllers/deployment/)の詳細 + +{{% /capture %}} + + diff --git a/content/ja/docs/tasks/run-application/scale-stateful-set.md b/content/ja/docs/tasks/run-application/scale-stateful-set.md new file mode 100644 index 0000000000..7e9352c1c1 --- /dev/null +++ b/content/ja/docs/tasks/run-application/scale-stateful-set.md @@ -0,0 +1,80 @@ +--- +title: StatefulSetのスケール +content_template: templates/task +weight: 50 +--- + +{{% capture overview %}} +このタスクは、StatefulSetをスケールする方法を示します。StatefulSetをスケーリングするとは、レプリカの数を増減することです。 +{{% /capture %}} + +{{% capture prerequisites %}} + +* StatefulSetはKubernetesバージョン1.5以降でのみ利用可能です。 + Kubernetesのバージョンを確認するには、`kubectl version`を実行してください。 + +* すべてのステートフルアプリケーションがうまくスケールできるわけではありません。StatefulSetがスケールするかどうかわからない場合は、[StatefulSetの概念](/ja/docs/concepts/workloads/controllers/statefulset/)または[StatefulSetのチュートリアル](/docs/tutorials/stateful-application/basic-stateful-set/)を参照してください。 + +* ステートフルアプリケーションクラスターが完全に健全であると確信できる場合にのみ、スケーリングを実行してください。 + +{{% /capture %}} + +{{% capture steps %}} + +## StatefulSetのスケール + +### kubectlを使用したStatefulSetのスケール + +まず、スケールしたいStatefulSetを見つけます。 + +```shell +kubectl get statefulsets +``` + +StatefulSetのレプリカ数を変更します: + +```shell +kubectl scale statefulsets --replicas= +``` + +### StatefulSetのインプレースアップデート + +コマンドライン上でレプリカ数を変更する代わりに、StatefulSetに[インプレースアップデート](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)が可能です。 + +StatefulSetが最初に `kubectl apply`で作成されたのなら、StatefulSetマニフェストの`.spec.replicas`を更新してから、`kubectl apply`を実行します: + +```shell +kubectl apply -f +``` + +そうでなければ、`kubectl edit`でそのフィールドを編集してください: + +```shell +kubectl edit statefulsets +``` + +あるいは`kubectl patch`を使ってください: + +```shell +kubectl patch statefulsets -p '{"spec":{"replicas":}}' +``` + +## トラブルシューティング + +### スケールダウンがうまくいかない + +管理するステートフルPodのいずれかが異常である場合、StatefulSetをスケールダウンすることはできません。それらのステートフルPodが実行され準備ができた後にのみ、スケールダウンが行われます。 + +spec.replicas > 1の場合、Kubernetesは不健康なPodの理由を判断できません。それは、永続的な障害または一時的な障害の結果である可能性があります。一時的な障害は、アップグレードまたはメンテナンスに必要な再起動によって発生する可能性があります。 + +永続的な障害が原因でPodが正常でない場合、障害を修正せずにスケーリングすると、StatefulSetメンバーシップが正しく機能するために必要な特定の最小レプリカ数を下回る状態になる可能性があります。これにより、StatefulSetが利用できなくなる可能性があります。 + +一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスタが完全に健全であることが確実な場合にのみスケーリングを実行してください。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [StatefulSetの削除](/ja/docs/tasks/run-application/delete-stateful-set/)の詳細 + +{{% /capture %}} diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md new file mode 100644 index 0000000000..7f848c2afd --- /dev/null +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -0,0 +1,132 @@ +--- +title: Minikubeのインストール +content_template: templates/task +weight: 20 +card: + name: tasks + weight: 10 +--- + +{{% capture overview %}} + +このページでは[Minikube](/ja/docs/tutorials/hello-minikube)のインストール方法を説明し、コンピューターの仮想マシン上で単一ノードのKubernetesクラスターを実行します。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +コンピューターのBIOS上でVT-xもしくはAMD-vの仮想化が使用可能でなければなりません。Linux上で確認するために以下のコマンドを実行し、出力されることを確認してください。 +```shell +egrep --color 'vmx|svm' /proc/cpuinfo +``` + +{{% /capture %}} + +{{% capture steps %}} + +## ハイパーバイザーのインストール + +ハイパーバイザーがインストールされていなかったら、OSにいずれかをインストールしてください。 + +Operating system | サポートしているハイパーバイザー +:----------------|:--------------------- +macOS | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion), [HyperKit](https://github.com/moby/hyperkit) +Linux | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [KVM](http://www.linux-kvm.org/) +Windows | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) + +{{< note >}} +MinikubeはVMの中ではなくホスト上のKubernetesのコンポーネントの一部として実行する`--vm-driver=none`をサポートしています。このドライバーはハイパーバイザーではなく、DockerやLinuxの環境を必要とします。 +{{< /note >}} + +## kubectlのインストール + +* kubectlのインストールは[kubectlのインストールと設定](/ja/docs/tasks/tools/install-kubectl/)を確認してください。 + +## Minikubeのインストール + +### macOS + +[Homebrew](https://brew.sh)を使うことでmacOSにMinikubeを簡単にインストールできます。 + +```shell +brew cask install minikube +``` + +バイナリファイルを使用してmacOSにインストールすることも可能です。 + +```shell +curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ + && chmod +x minikube +``` + +以下のコマンドを入力して、Minikubeを実行可能にしてください。 + +```shell +sudo mv minikube /usr/local/bin +``` + +### Linux + +{{< note >}} +ここではバイナリを使ってLinux上にMinikubeをインストールする方法を示します。 +{{< /note >}} + +バイナリファイルを使用してLinuxにインストールできます。 + +```shell +curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \ + && chmod +x minikube +``` + +以下のコマンドを入力して、Minikubeを実行可能にしてください。 + +```shell +sudo cp minikube /usr/local/bin && rm minikube +``` + +### Windows + +{{< note >}} +MinikubeをWindowsで実行するために、[Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)もしくは[VirtualBox](https://www.virtualbox.org/)をインストールする必要があります。Hyper-VはWindows 10 Enterprise、Windows 10 Professional、Windows 10 Educationで実行できます。より詳しいインストールについてのドキュメントはMinikube公式の[GitHub](https://github.com/kubernetes/minikube/#installation)のリポジトリを参照してください。 +{{< /note >}} + +[Chocolatey](https://chocolatey.org/)を使うことでWindowsにMinikubeを簡単にインストールできます(管理者権限で実行する必要があります)。 + +```shell +choco install minikube kubernetes-cli +``` + +Minikubeのインストールが終わったら、現在のCLIのセッションを終了して再起動します。Minikubeは自動的にパスに追加されます。 + +#### 手動でWindowsにインストールする方法 + +Windowsに手動でMinikubeをダウンロードする場合、[`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)をダウンロードし、名前を`minikube.exe`に変更してこれをパスに加えます。 + +#### Windowsのインストーラー + +[Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)を使ってWindowsに手動でインストールする場合、[`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest)をインストールし、インストーラーを実行します。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [Minikubeを使ってローカルでKubernetesを実行する](/ja/docs/setup/minikube/) + +{{% /capture %}} + +## クリーンアップし、新たに始める場合 + +もし以前に Minikubeをインストールしていたら、以下のコマンドを実行します。 +```shell +minikube start +``` + +このエラーが返ってきます。 +```shell +machine does not exist +``` + +以下のファイルを消去する必要があります。 +```shell +rm -rf ~/.minikube +``` \ No newline at end of file diff --git a/content/ja/docs/tutorials/_index.md b/content/ja/docs/tutorials/_index.md index 74ae96f915..f451618f9b 100644 --- a/content/ja/docs/tutorials/_index.md +++ b/content/ja/docs/tutorials/_index.md @@ -37,7 +37,7 @@ content_template: templates/concept * [StatefulSetの基本](/docs/tutorials/stateful-application/basic-stateful-set/) -* [例: 永続化ボリュームを使ったWordPressとMySQLのデプロイ](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) +* [例: 永続ボリュームを使ったWordPressとMySQLのデプロイ](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) * [例: Stateful Setsを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/) diff --git a/content/ja/examples/pods/pod-rs.yaml b/content/ja/examples/pods/pod-rs.yaml new file mode 100644 index 0000000000..df7b390597 --- /dev/null +++ b/content/ja/examples/pods/pod-rs.yaml @@ -0,0 +1,23 @@ +apiVersion: v1 +kind: Pod +metadata: + name: pod1 + labels: + tier: frontend +spec: + containers: + - name: hello1 + image: gcr.io/google-samples/hello-app:2.0 + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: pod2 + labels: + tier: frontend +spec: + containers: + - name: hello2 + image: gcr.io/google-samples/hello-app:1.0 diff --git a/content/ja/examples/service/access/Dockerfile b/content/ja/examples/service/access/Dockerfile index 7de606a642..b7b09d492a 100644 --- a/content/ja/examples/service/access/Dockerfile +++ b/content/ja/examples/service/access/Dockerfile @@ -1,4 +1,4 @@ -FROM nginx:1.9.14 +FROM nginx:1.17.3 RUN rm /etc/nginx/conf.d/default.conf COPY frontend.conf /etc/nginx/conf.d diff --git a/content/ja/includes/default-storage-class-prereqs.md b/content/ja/includes/default-storage-class-prereqs.md new file mode 100644 index 0000000000..588439eb89 --- /dev/null +++ b/content/ja/includes/default-storage-class-prereqs.md @@ -0,0 +1,2 @@ +ここで使用されている[PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)の要件を満たすには、デフォルトの[StorageClass](/docs/concepts/storage/storage-classes/)を使用して動的PersistentVolumeプロビジョナーを作成するか、[PersistentVolumesを静的にプロビジョニングする](/docs/user-guide/persistent-volumes/#provisioning)必要があります。 + diff --git a/content/ja/includes/federated-task-tutorial-prereqs.md b/content/ja/includes/federated-task-tutorial-prereqs.md new file mode 100644 index 0000000000..b254407a67 --- /dev/null +++ b/content/ja/includes/federated-task-tutorial-prereqs.md @@ -0,0 +1,5 @@ +This guide assumes that you have a running Kubernetes Cluster Federation installation. +If not, then head over to the [federation admin guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) to learn how to +bring up a cluster federation (or have your cluster administrator do this for you). +Other tutorials, such as Kelsey Hightower's [Federated Kubernetes Tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation), +might also help you create a Federated Kubernetes cluster. diff --git a/content/ja/includes/federation-deprecation-warning-note.md b/content/ja/includes/federation-deprecation-warning-note.md new file mode 100644 index 0000000000..b7a05b1077 --- /dev/null +++ b/content/ja/includes/federation-deprecation-warning-note.md @@ -0,0 +1,3 @@ +Use of `Federation v1` is strongly discouraged. `Federation V1` never achieved GA status and is no longer under active development. Documentation is for historical purposes only. + +For more information, see the intended replacement, [Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2). diff --git a/content/ja/includes/index.md b/content/ja/includes/index.md new file mode 100644 index 0000000000..ca03031f1e --- /dev/null +++ b/content/ja/includes/index.md @@ -0,0 +1,3 @@ +--- +headless: true +--- diff --git a/content/ja/includes/partner-script.js b/content/ja/includes/partner-script.js new file mode 100644 index 0000000000..499dc3f2e3 --- /dev/null +++ b/content/ja/includes/partner-script.js @@ -0,0 +1,1609 @@ +;(function () { + var partners = [ + { + type: 0, + name: 'Sysdig', + logo: 'sys_dig', + link: 'https://sysdig.com/blog/monitoring-kubernetes-with-sysdig-cloud/', + blurb: 'Sysdig is the container intelligence company. Sysdig has created the only unified platform to deliver monitoring, security, and troubleshooting in a microservices-friendly architecture.' + }, + { + type: 0, + name: 'Puppet', + logo: 'puppet', + link: 'https://puppet.com/blog/announcing-kream-and-new-kubernetes-helm-and-docker-modules', + blurb: 'We\'ve developed tools and products to make your adoption of Kubernetes as efficient as possible, covering your full workflow cycle from development to production. And now Puppet Pipelines for Containers is your complete DevOps dashboard for Kubernetes.' + }, + { + type: 0, + name: 'Citrix', + logo: 'citrix', + link: 'https://www.citrix.com/networking/microservices.html', + blurb: 'Netscaler CPX gives app developers all the features they need to load balance their microservices and containerized apps with Kubernetes.' + }, + { + type: 0, + name: 'Cockroach Labs', + logo: 'cockroach_labs', + link: 'https://www.cockroachlabs.com/blog/running-cockroachdb-on-kubernetes/', + blurb: 'CockroachDB is a distributed SQL database whose built-in replication and survivability model pair with Kubernetes to truly make data easy.' + }, + { + type: 2, + name: 'Weaveworks', + logo: 'weave_works', + link: ' https://weave.works/kubernetes', + blurb: 'Weaveworks enables Developers and Dev/Ops teams to easily connect, deploy, secure, manage, and troubleshoot microservices in Kubernetes.' + }, + { + type: 0, + name: 'Intel', + logo: 'intel', + link: 'https://tectonic.com/press/intel-coreos-collaborate-on-openstack-with-kubernetes.html', + blurb: 'Powering the GIFEE (Google’s Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.' + }, + { + type: 3, + name: 'Platform9', + logo: 'platform9', + link: 'https://platform9.com/products/kubernetes/', + blurb: 'Platform9 is the open source-as-a-service company that takes all of the goodness of Kubernetes and delivers it as a managed service.' + }, + { + type: 0, + name: 'Datadog', + logo: 'datadog', + link: 'http://docs.datadoghq.com/integrations/kubernetes/', + blurb: 'Full-stack observability for dynamic infrastructure & applications. Includes precision alerting, analytics and deep Kubernetes integrations. ' + }, + { + type: 0, + name: 'AppFormix', + logo: 'appformix', + link: 'http://www.appformix.com/solutions/appformix-for-kubernetes/', + blurb: 'AppFormix is a cloud infrastructure performance optimization service helping enterprise operators streamline their cloud operations on any Kubernetes cloud. ' + }, + { + type: 0, + name: 'Crunchy', + logo: 'crunchy', + link: 'http://info.crunchydata.com/blog/advanced-crunchy-containers-for-postgresql', + blurb: 'Crunchy PostgreSQL Container Suite is a set of containers for managing PostgreSQL with DBA microservices leveraging Kubernetes and Helm.' + }, + { + type: 0, + name: 'Aqua', + logo: 'aqua', + link: 'http://blog.aquasec.com/security-best-practices-for-kubernetes-deployment', + blurb: 'Deep, automated security for your containers running on Kubernetes.' + }, + { + type: 0, + name: 'Distelli', + logo: 'distelli', + link: 'https://www.distelli.com/', + blurb: 'Pipelines from your source repositories to your Kubernetes Clusters on any cloud.' + }, + { + type: 0, + name: 'Nuage networks', + logo: 'nuagenetworks', + link: 'https://github.com/nuagenetworks/nuage-kubernetes', + blurb: 'The Nuage SDN platform provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.' + }, + { + type: 0, + name: 'Sematext', + logo: 'sematext', + link: 'https://sematext.com/kubernetes/', + blurb: 'Logging & Monitoring: Automatic collection and processing of Metrics, Events and Logs for auto-discovered pods and Kubernetes nodes.' + }, + { + type: 0, + name: 'Diamanti', + logo: 'diamanti', + link: 'https://www.diamanti.com/products/', + blurb: 'Diamanti deploys containers with guaranteed performance using Kubernetes in the first hyperconverged appliance purpose built for containerized applications.' + }, + { + type: 0, + name: 'Aporeto', + logo: 'aporeto', + link: 'https://aporeto.com/trireme', + blurb: 'Aporeto makes cloud-native applications secure by default without impacting developer velocity and works at any scale, on any cloud.' + }, + { + type: 2, + name: 'Giant Swarm', + logo: 'giantswarm', + link: 'https://giantswarm.io', + blurb: 'Giant Swarm enables you to simply and rapidly create and use Kubernetes clusters on-demand either on-premises or in the cloud. Contact Giant Swarm to learn about the best way to run cloud native applications anywhere.' + }, + { + type: 3, + name: 'Giant Swarm', + logo: 'giantswarm', + link: 'https://giantswarm.io/product/', + blurb: 'Giant Swarm enables you to simply and rapidly create and use Kubernetes clusters on-demand either on-premises or in the cloud. Contact Giant Swarm to learn about the best way to run cloud native applications anywhere.' + }, + { + type: 3, + name: 'Hasura', + logo: 'hasura', + link: 'https://hasura.io', + blurb: 'Hasura is a Kubernetes-based PaaS and a Postgres-based BaaS that accelerates app development with ready-to-use components.' + }, + { + type: 3, + name: 'Mirantis', + logo: 'mirantis', + link: 'https://www.mirantis.com/software/kubernetes/', + blurb: 'Mirantis - Mirantis Cloud Platform' + }, + { + type: 2, + name: 'Mirantis', + logo: 'mirantis', + link: 'https://content.mirantis.com/Containerizing-OpenStack-on-Kubernetes-Video-Landing-Page.html', + blurb: 'Mirantis builds and manages private clouds with open source software such as OpenStack, deployed as containers orchestrated by Kubernetes.' + }, + { + type: 0, + name: 'Kubernetic', + logo: 'kubernetic', + link: 'https://kubernetic.com/', + blurb: 'Kubernetic is a Kubernetes Desktop client that simplifies and democratizes cluster management for DevOps.' + }, + { + type: 1, + name: 'Reactive Ops', + logo: 'reactive_ops', + link: 'https://www.reactiveops.com/the-kubernetes-experts/', + blurb: 'ReactiveOps has written automation on best practices for infrastructure as code on GCP & AWS using Kubernetes, helping you build and maintain a world-class infrastructure at a fraction of the price of an internal hire.' + }, + { + type: 2, + name: 'Livewyer', + logo: 'livewyer', + link: 'https://livewyer.io/services/kubernetes-experts/', + blurb: 'Kubernetes experts that on-board applications and empower IT teams to get the most out of containerised technology.' + }, + { + type: 2, + name: 'Samsung SDS', + logo: 'samsung_sds', + link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes', + blurb: 'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.' + }, + { + type: 2, + name: 'Container Solutions', + logo: 'container_solutions', + link: 'http://container-solutions.com/resources/kubernetes/', + blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.' + }, + { + type: 4, + name: 'Container Solutions', + logo: 'container_solutions', + link: 'http://container-solutions.com/resources/kubernetes/', + blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.' + }, + { + type: 2, + name: 'Jetstack', + logo: 'jetstack', + link: 'https://www.jetstack.io/', + blurb: 'Jetstack is an organisation focused entirely on Kubernetes. They will help you to get the most out of Kubernetes through expert professional services and open source tooling. Get in touch, and accelerate your project.' + }, + { + type: 0, + name: 'Tigera', + logo: 'tigera', + link: 'http://docs.projectcalico.org/latest/getting-started/kubernetes/', + blurb: 'Tigera builds high performance, policy driven, cloud native networking solutions for Kubernetes.' + }, + { + type: 1, + name: 'Harbur', + logo: 'harbur', + link: 'https://harbur.io/', + blurb: 'Based in Barcelona, Harbur is a consulting firm that helps companies deploy self-healing solutions empowered by Container technologies' + }, + { + type: 0, + name: 'Spotinst', + logo: 'spotinst', + link: 'http://blog.spotinst.com/2016/08/04/elastigroup-kubernetes-minions-steroids/', + blurb: 'Your Kubernetes For 80% Less. Run K8s workloads on Spot Instances with 100% availability to save 80% + autoscale your Kubernetes with maximum efficiency in heterogenous environments.' + }, + { + type: 2, + name: 'InwinSTACK', + logo: 'inwinstack', + link: 'http://www.inwinstack.com/index.php/en/solutions-en/', + blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.' + }, + { + type: 4, + name: 'InwinSTACK', + logo: 'inwinstack', + link: 'http://www.inwinstack.com/index.php/en/solutions-en/', + blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.' + }, + { + type: 3, + name: 'InwinSTACK', + logo: 'inwinstack', + link: 'https://github.com/inwinstack/kube-ansible', + blurb: 'inwinSTACK - kube-ansible' + }, + { + type: 1, + name: 'Semantix', + logo: 'semantix', + link: 'http://www.semantix.com.br/', + blurb: 'Semantix is a company that works with data analytics and distributed systems. Kubernetes is used to orchestrate services for our customers.' + }, + { + type: 0, + name: 'ASM Technologies Limited', + logo: 'asm', + link: 'http://www.asmtech.com/', + blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' + }, + { + type: 1, + name: 'InfraCloud Technologies', + logo: 'infracloud', + link: 'http://blog.infracloud.io/state-of-kubernetes/', + blurb: 'InfraCloud Technologies is software consultancy which provides services in Containers, Cloud and DevOps.' + }, + { + type: 0, + name: 'SignalFx', + logo: 'signalfx', + link: 'https://github.com/signalfx/integrations/tree/master/kubernetes', + blurb: 'Gain real-time visibility across metrics & the most intelligent alerts for todays architectures, including deep integration with Kubernetes' + }, + { + type: 0, + name: 'NATS', + logo: 'nats', + link: 'https://github.com/pires/kubernetes-nats-cluster', + blurb: 'NATS is a simple, secure, and scalable cloud native messaging system.' + }, + { + type: 2, + name: 'RX-M', + logo: 'rxm', + link: 'http://rx-m.com/training/kubernetes-training/', + blurb: 'Market neutral Kubernetes Dev, DevOps and Production training and consulting services.' + }, + { + type: 4, + name: 'RX-M', + logo: 'rxm', + link: 'http://rx-m.com/training/kubernetes-training/', + blurb: 'Market neutral Kubernetes Dev, DevOps and Production training and consulting services.' + }, + { + type: 1, + name: 'Emerging Technology Advisors', + logo: 'eta', + link: 'https://www.emergingtechnologyadvisors.com/services/kubernetes.html', + blurb: 'ETA helps companies architect, implement, and manage scalable applications using Kubernetes on public or private cloud.' + }, + { + type: 0, + name: 'CloudPlex.io', + logo: 'cloudplex', + link: 'http://www.cloudplex.io', + blurb: 'CloudPlex enables operations teams to visually deploy, orchestrate, manage, and monitor infrastructure, applications, and services in public or private cloud.' + }, + { + type: 2, + name: 'Kumina', + logo: 'kumina', + link: 'https://www.kumina.nl/managed_kubernetes', + blurb: 'Kumina combines the power of Kubernetes with 10+ years of experience in IT operations. We create, build and support fully managed Kubernetes solutions on your choice of infrastructure. We also provide consulting and training.' + }, + { + type: 0, + name: 'CA Technologies', + logo: 'ca', + link: 'https://docops.ca.com/ca-continuous-delivery-director/integrations/en/plug-ins/kubernetes-plug-in', + blurb: 'The CA Continuous Delivery Director Kubernetes plugin orchestrates deployment of containerized applications within an end-to-end release pipeline.' + }, + { + type: 0, + name: 'CoScale', + logo: 'coscale', + link: 'http://www.coscale.com/blog/how-to-monitor-your-kubernetes-cluster', + blurb: 'Full stack monitoring of containers and microservices orchestrated by Kubernetes. Powered by anomaly detection to find problems faster.' + }, + { + type: 2, + name: 'Supergiant.io', + logo: 'supergiant', + link: 'https://supergiant.io/blog/supergiant-packing-algorithm-unique-save-money', + blurb: 'Supergiant autoscales hardware for Kubernetes. Open-source, it makes HA, distributed, stateful apps easy to deploy, manage, and scale.' + }, + { + type: 0, + name: 'Avi Networks', + logo: 'avinetworks', + link: 'https://kb.avinetworks.com/avi-vantage-openshift-installation-guide/', + blurb: 'Avis elastic application services fabric provides scalable, feature rich & integrated L4-7 networking for K8S environments.' + }, + { + type: 1, + name: 'Codecrux web technologies pvt ltd', + logo: 'codecrux', + link: 'http://codecrux.com/kubernetes/', + blurb: 'At CodeCrux we help your organization get the most out of Containers and Kubernetes, regardless of where you are in your journey' + }, + { + type: 0, + name: 'Greenqloud', + logo: 'qstack', + link: 'https://www.qstack.com/application-orchestration/', + blurb: 'Qstack provides self-serviceable on-site Kubernetes clusters with an intuitive User Interface for Infrastructure and Kubernetes management.' + }, + { + type: 1, + name: 'StackOverdrive.io', + logo: 'stackoverdrive', + link: 'http://www.stackoverdrive.net/kubernetes-consulting/', + blurb: 'StackOverdrive helps organizations of all sizes leverage Kubernetes for container based orchestration and management.' + }, + { + type: 0, + name: 'StackIQ, Inc.', + logo: 'stackiq', + link: 'https://www.stackiq.com/kubernetes/', + blurb: 'With Stacki and the Stacki Pallet for Kubernetes, you can go from bare metal to containers in one step very quickly and easily.' + }, + { + type: 0, + name: 'Cobe', + logo: 'cobe', + link: 'https://cobe.io/product-page/', + blurb: 'Manage Kubernetes clusters with a live, searchable model that captures all relationships and performance data in full visualised context.' + }, + { + type: 0, + name: 'Datawire', + logo: 'datawire', + link: 'http://www.datawire.io', + blurb: 'Datawires open source tools let your microservices developers be awesomely productive on Kubernetes, while letting ops sleep at night.' + }, + { + type: 0, + name: 'Mashape, Inc.', + logo: 'kong', + link: 'https://getkong.org/install/kubernetes/', + blurb: 'Kong is a scalable open source API layer that runs in front of any RESTful API and can be provisioned to a Kubernetes cluster.' + }, + { + type: 0, + name: 'F5 Networks', + logo: 'f5networks', + link: 'http://github.com/f5networks', + blurb: 'We have a LB integration into Kubernetes.' + }, + { + type: 1, + name: 'Lovable Tech', + logo: 'lovable', + link: 'http://lovable.tech/', + blurb: 'World class engineers, designers, and strategic consultants helping you ship Lovable web & mobile technology.' + }, + { + type: 0, + name: 'StackState', + logo: 'stackstate', + link: 'http://stackstate.com/platform/container-monitoring', + blurb: 'Operational Analytics across teams and tools. Includes topology visualization, root cause analysis and anomaly detection for Kubernetes.' + }, + { + type: 1, + name: 'INEXCCO INC', + logo: 'inexcco', + link: 'https://www.inexcco.com/', + blurb: 'Strong DevOps and Cloud talent working with couple clients on kubernetes and helm implementations. ' + }, + { + type: 2, + name: 'Bitnami', + logo: 'bitnami', + link: 'http://bitnami.com/kubernetes', + blurb: 'Bitnami brings a catalog of trusted, up to date, and easy to use applications and application building blocks to Kubernetes.' + }, + { + type: 1, + name: 'Nebulaworks', + logo: 'nebulaworks', + link: 'http://www.nebulaworks.com/container-platforms', + blurb: 'Nebulaworks provides services to help the enterprise adopt modern container platforms and optimized processes to enable innovation at scale.' + }, + { + type: 1, + name: 'EASYNUBE', + logo: 'easynube', + link: 'http://easynube.co.uk/devopsnube/', + blurb: 'EasyNube provide architecture, implementation, and manage scalable applications using Kubernetes and Openshift.' + }, + { + type: 1, + name: 'Opcito Technologies', + logo: 'opcito', + link: 'http://www.opcito.com/kubernetes/', + blurb: 'Opcito is a software consultancy that uses Kubernetes to help organisations build, architect & deploy highly scalable applications.' + }, + { + type: 0, + name: 'code by Dell EMC', + logo: 'codedellemc', + link: 'https://blog.codedellemc.com', + blurb: 'Respected as a thought leader in storage persistence for containerized applications. Contributed significant work to K8 and Ecosystem' + }, + { + type: 0, + name: 'Instana', + logo: 'instana', + link: 'https://www.instana.com/supported-technologies/', + blurb: 'Instana monitors performance of the applications, infrastructure, containers and services deployed on a Kubernetes cluster.' + }, + { + type: 0, + name: 'Netsil', + logo: 'netsil', + link: 'https://netsil.com/kubernetes/', + blurb: 'Generate a real-time, auto-discovered application topology map! Monitor Kubernetes pods and namespaces without any code instrumentation.' + }, + { + type: 2, + name: 'Treasure Data', + logo: 'treasuredata', + link: 'https://fluentd.treasuredata.com/kubernetes-logging/', + blurb: 'Fluentd Enterprise brings smart, secure logging to Kubernetes, and brings integrations with backends such as Splunk, Kafka, or AWS S3.' + }, + { + type: 2, + name: 'Kenzan', + logo: 'Kenzan', + link: 'http://kenzan.com/?ref=kubernetes', + blurb: 'We provide custom consulting services leveraging Kubernetes as our foundation. This involves the platform development, delivery pipelines, and the application development within Kubernetes.' + }, + { + type: 2, + name: 'New Context', + logo: 'newcontext', + link: 'https://www.newcontext.com/devsecops-infrastructure-automation-orchestration/', + blurb: 'New Context builds and uplifts secure Kubernetes implementations and migrations, from initial design to infrastructure automation and management.' + }, + { + type: 2, + name: 'Banzai', + logo: 'banzai', + link: 'https://banzaicloud.com/platform/', + blurb: 'Banzai Cloud brings cloud native to the enterprise and simplifies the transition to microservices on Kubernetes.' + }, + { + type: 3, + name: 'Kublr', + logo: 'kublr', + link: 'http://kublr.com', + blurb: 'Kublr - Accelerate and control the deployment, scaling, monitoring and management of your containerized applications.' + }, + { + type: 1, + name: 'ControlPlane', + logo: 'controlplane', + link: 'https://control-plane.io', + blurb: 'We are a London-based Kubernetes consultancy with a focus on security and continuous delivery. We offer consulting & training.' + }, + { + type: 3, + name: 'Nirmata', + logo: 'nirmata', + link: 'https://www.nirmata.com/', + blurb: 'Nirmata - Nirmata Managed Kubernetes' + }, + { + type: 2, + name: 'Nirmata', + logo: 'nirmata', + link: 'https://www.nirmata.com/', + blurb: 'Nirmata is a software platform that helps DevOps teams deliver enterprise-grade and cloud-provider agnostic Kubernetes based container management solutions.' + }, + { + type: 3, + name: 'TenxCloud', + logo: 'tenxcloud', + link: 'https://tenxcloud.com', + blurb: 'TenxCloud - TenxCloud Container Engine (TCE)' + }, + { + type: 2, + name: 'TenxCloud', + logo: 'tenxcloud', + link: 'https://www.tenxcloud.com/', + blurb: 'Founded in October 2014, TenxCloud is a leading enterprise container cloud computing service provider in China, covering the areas such as container PaaS cloud platform, micro-service management, DevOps, development test, AIOps and so on. Provide private cloud PaaS products and solutions for financial, energy, operator, manufacturing, education and other industry customers.' + }, + { + type: 0, + name: 'Twistlock', + logo: 'twistlock', + link: 'https://www.twistlock.com/', + blurb: 'Security at Kubernetes Scale: Twistlock allows you to deploy fearlessly with assurance that your images and containers are free of vulnerabilities and protected at runtime.' + }, + { + type: 0, + name: 'Endocode AG', + logo: 'endocode', + link: 'https://endocode.com/kubernetes/', + blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.' + }, + { + type: 2, + name: 'Accenture', + logo: 'accenture', + link: 'https://www.accenture.com/us-en/service-application-containers', + blurb: 'Architecture, implementation and operation of world-class Kubernetes solutions for cloud-native clients.' + }, + { + type: 1, + name: 'Biarca', + logo: 'biarca', + link: 'http://biarca.io/', + blurb: 'Biarca is a cloud services provider and key focus areas Key areas of focus for Biarca include Cloud Adoption Services, Infrastructure Services, DevOps Services and Application Services. Biarca leverages Kubernetes to deliver containerized solutions.' + }, + { + type: 2, + name: 'Claranet', + logo: 'claranet', + link: 'http://www.claranet.co.uk/hosting/google-cloud-platform-consulting-managed-services', + blurb: 'Claranet helps people migrate to the cloud and take full advantage of the new world it offers. We consult, design, build and proactively manage the right infrastructure and automation tooling for clients to achieve this.' + }, + { + type: 1, + name: 'CloudKite', + logo: 'cloudkite', + link: 'https://cloudkite.io/', + blurb: 'CloudKite.io helps companies build and maintain highly automated, resilient, and impressively performing software on Kubernetes.' + }, + { + type: 2, + name: 'CloudOps', + logo: 'CloudOps', + link: 'https://www.cloudops.com/services/docker-and-kubernetes-workshops/', + blurb: 'CloudOps gets you hands-on with the K8s ecosystem via workshop/lab. Get prod ready K8s in cloud(s) of your choice with our managed services.' + }, + { + type: 2, + name: 'Ghostcloud', + logo: 'ghostcloud', + link: 'https://www.ghostcloud.cn/ecos-kubernetes', + blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.' + }, + { + type: 3, + name: 'Ghostcloud', + logo: 'ghostcloud', + link: 'https://www.ghostcloud.cn/ecos-kubernetes', + blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.' + }, + { + type: 2, + name: 'Contino', + logo: 'contino', + link: 'https://www.contino.io/', + blurb: 'We help enterprise organizations adopt DevOps, containers and cloud computing. Contino is a global consultancy that enables regulated organizations to accelerate innovation through the adoption of modern approaches to software delivery.' + }, + { + type: 2, + name: 'Booz Allen Hamilton', + logo: 'boozallenhamilton', + link: 'https://www.boozallen.com/', + blurb: 'Booz Allen partners with public and private sector clients to solve their most difficult challenges through a combination of consulting, analytics, mission operations, technology, systems delivery, cybersecurity, engineering, and innovation expertise.' + }, + { + type: 1, + name: 'BigBinary', + logo: 'bigbinary', + link: 'http://blog.bigbinary.com/categories/Kubernetes', + blurb: 'Provider of Digital Solutions for federal and commercial clients, to include DevSecOps, cloud platforms, transformation strategy, cognitive solutions, and UX.' + }, + { + type: 0, + name: 'CloudPerceptions', + logo: 'cloudperceptions', + link: 'https://www.meetup.com/Triangle-Kubernetes-Meetup/files/', + blurb: 'Container security solution for small-to-medium size enterprises who plan to run Kubernetes on shared infrastructure.' + }, + { + type: 2, + name: 'Creationline, Inc.', + logo: 'creationline', + link: 'https://www.creationline.com/ci', + blurb: 'Total solution for container based IT resource management.' + }, + { + type: 0, + name: 'DataCore Software', + logo: 'datacore', + link: 'https://www.datacore.com/solutions/virtualization/containerization', + blurb: 'DataCore provides highly-available, high-performance universal block storage for Kubernetes, radically improving the speed of deployment.' + }, + { + type: 0, + name: 'Elastifile', + logo: 'elastifile', + link: 'https://www.elastifile.com/stateful-containers', + blurb: 'Elastifile’s cross-cloud data fabric delivers elastically scalable, high performance, software-defined persistent storage for Kubernetes.' + }, + { + type: 0, + name: 'GitLab', + logo: 'gitlab', + link: 'https://about.gitlab.com/2016/11/14/idea-to-production/', + blurb: 'With GitLab and Kubernetes, you can deploy a complete CI/CD pipeline with multiple environments, automatic deployments, and automatic monitoring.' + }, + { + type: 0, + name: 'Gravitational, Inc.', + logo: 'gravitational', + link: 'https://gravitational.com/telekube/', + blurb: 'Telekube combines Kubernetes with Teleport, our modern SSH server, so operators can remotely manage a multitude of K8s application deployments.' + }, + { + type: 0, + name: 'Hitachi Data Systems', + logo: 'hitachi', + link: 'https://www.hds.com/en-us/products-solutions/application-solutions/unified-compute-platform-with-kubernetes-orchestration.html', + blurb: 'Build the Applications You Need to Drive Your Business - DEVELOP AND DEPLOY APPLICATIONS FASTER AND MORE RELIABLY.' + }, + { + type: 1, + name: 'Infosys Technologies', + logo: 'infosys', + link: 'https://www.infosys.com', + blurb: 'Monolithic to microservices on openshift is a offering that we are building as part of open source practice.' + }, + { + type: 0, + name: 'JFrog', + logo: 'jfrog', + link: 'https://www.jfrog.com/use-cases/12584/', + blurb: 'You can use Artifactory to store and manage all of your application’s container images and deploy to Kubernetes and setup a build, test, deploy pipeline using Jenkins and Artifactory. Once an image is ready to be rolled out, Artifactory can trigger a rolling-update deployment into a Kubernetes cluster without downtime – automatically!' + }, + { + type: 0, + name: 'Navops by Univa', + logo: 'navops', + link: 'https://www.navops.io', + blurb: 'Navops is a suite of products that enables enterprises to take full advantage of Kubernetes and provides the ability to quickly and efficiently run containers at scale.' + }, + { + type: 0, + name: 'NeuVector', + logo: 'neuvector', + link: 'http://neuvector.com/solutions-for-kubernetes-security/', + blurb: 'NeuVector delivers an application and network intelligent container network security solution integrated with and optimized for Kubernetes.' + }, + { + type: 1, + name: 'OpsZero', + logo: 'opszero', + link: 'https://www.opszero.com/kubernetes.html', + blurb: 'opsZero provides DevOps for Startups. We build and service your Kubernetes and Cloud Infrastructure to accelerate your release cycle.' + }, + { + type: 1, + name: 'Shiwaforce.com Ltd.', + logo: 'shiwaforce', + link: 'https://www.shiwaforce.com/en/', + blurb: 'Shiwaforce.com is the Agile Partner in Digital Transformation. Our solutions follow business changes quickly, easily and cost-effectively.' + }, + { + type: 1, + name: 'SoftServe', + logo: 'softserve', + link: 'https://www.softserveinc.com/en-us/blogs/kubernetes-travis-ci/', + blurb: 'SoftServe allows its clients to adopt modern application design patterns and benefit from fully integrated, highly available, cost effective Kubernetes clusters at any scale.' + }, + { + type: 1, + name: 'Solinea', + logo: 'solinea', + link: 'https://www.solinea.com/cloud-consulting-services/container-microservices-offerings', + blurb: 'Solinea is a digital transformation consultancy that enables businesses to build innovative solutions by adopting cloud native computing.' + }, + { + type: 1, + name: 'Sphere Software, LLC', + logo: 'spheresoftware', + link: 'https://sphereinc.com/kubernetes/', + blurb: 'The Sphere Software team of experts allows customers to architect and implement scalable applications using Kubernetes in Google Cloud, AWS, and Azure.' + }, + { + type: 1, + name: 'Altoros', + logo: 'altoros', + link: 'https://www.altoros.com/container-orchestration-tools-enablement.html', + blurb: 'Deployment and configuration of Kubernetes, Optimization of existing solutions, training for developers on using Kubernetes, support.' + }, + { + type: 0, + name: 'Cloudbase Solutions', + logo: 'cloudbase', + link: 'https://cloudbase.it/kubernetes', + blurb: 'Cloudbase Solutions provides Kubernetes cross-cloud interoperability for Windows and Linux deployments based on open source technologies.' + }, + { + type: 0, + name: 'Codefresh', + logo: 'codefresh', + link: 'https://codefresh.io/kubernetes-deploy/', + blurb: 'Codefresh is a complete DevOps platform built for containers and Kubernetes. With CI/CD pipelines, image management, and deep integrations into Kubernetes and Helm.' + }, + { + type: 0, + name: 'NetApp', + logo: 'netapp', + link: 'http://netapp.io/2016/12/23/introducing-trident-dynamic-persistent-volume-provisioner-kubernetes/', + blurb: 'Dynamic provisioning and persistent storage support.' + }, + { + type: 0, + name: 'OpenEBS', + logo: 'OpenEBS', + link: 'https://openebs.io/', + blurb: 'OpenEBS is containerized storage for containers integrated tightly into Kubernetes and based on distributed block storage and containerization of storage control. OpenEBS derives intent from K8s and other YAML or JSON such as per container QoS SLAs, tiering and replica policies, and more. OpenEBS is EBS API compliant.' + }, + { + type: 3, + name: 'Google Kubernetes Engine', + logo: 'google', + link: 'https://cloud.google.com/kubernetes-engine/', + blurb: 'Google - Google Kubernetes Engine' + }, + { + type: 1, + name: 'Superorbital', + logo: 'superorbital', + link: 'https://superorbit.al/workshops/kubernetes/', + blurb: 'Helping companies navigate the Cloud Native waters through Kubernetes consulting and training.' + }, + { + type: 3, + name: 'Apprenda', + logo: 'apprenda', + link: 'https://apprenda.com/kismatic/', + blurb: 'Apprenda - Kismatic Enterprise Toolkit (KET)' + }, + { + type: 3, + name: 'Red Hat', + logo: 'redhat', + link: 'https://www.openshift.com', + blurb: 'Red Hat - OpenShift Online and OpenShift Container Platform' + }, + { + type: 3, + name: 'Rancher', + logo: 'rancher', + link: 'http://rancher.com/kubernetes/', + blurb: 'Rancher Inc. - Rancher Kubernetes' + }, + { + type: 3, + name: 'Canonical', + logo: 'canonical', + link: 'https://www.ubuntu.com/kubernetes', + blurb: 'The Canonical Distribution of Kubernetes enables you to operate Kubernetes clusters on demand on any major public cloud and private infrastructure.' + }, + { + type: 2, + name: 'Canonical', + logo: 'canonical', + link: 'https://www.ubuntu.com/kubernetes', + blurb: 'Canonical Ltd. - Canonical Distribution of Kubernetes' + }, + { + type: 3, + name: 'Cisco', + logo: 'cisco', + link: 'https://www.cisco.com', + blurb: 'Cisco Systems - Cisco Container Platform' + }, + { + type: 3, + name: 'Cloud Foundry', + logo: 'cff', + link: 'https://www.cloudfoundry.org/container-runtime/', + blurb: 'Cloud Foundry - Cloud Foundry Container Runtime' + }, + { + type: 3, + name: 'IBM', + logo: 'ibm', + link: 'https://www.ibm.com/cloud/container-service', + blurb: 'IBM - IBM Cloud Kubernetes Service' + }, + { + type: 2, + name: 'IBM', + logo: 'ibm', + link: 'https://www.ibm.com/cloud-computing/bluemix/containers', + blurb: 'The IBM Bluemix Container Service combines Docker and Kubernetes to deliver powerful tools, an intuitive user experiences, and built-in security and isolation to enable rapid delivery of applications all while leveraging Cloud Services including cognitive capabilities from Watson.' + }, + { + type: 3, + name: 'Samsung', + logo: 'samsung_sds', + link: 'https://github.com/samsung-cnct/kraken', + blurb: 'Samsung SDS - Kraken' + }, + { + type: 3, + name: 'IBM', + logo: 'ibm', + link: 'https://www.ibm.com/cloud-computing/products/ibm-cloud-private/', + blurb: 'IBM - IBM Cloud Private' + }, + { + type: 3, + name: 'Kinvolk', + logo: 'kinvolk', + link: 'https://github.com/kinvolk/kube-spawn', + blurb: 'Kinvolk - kube-spawn' + }, + { + type: 3, + name: 'Heptio', + logo: 'heptio', + link: 'https://aws.amazon.com/quickstart/architecture/heptio-kubernetes', + blurb: 'Heptio - AWS-Quickstart' + }, + { + type: 2, + name: 'Heptio', + logo: 'heptio', + link: 'http://heptio.com', + blurb: 'Heptio helps businesses of all sizes get closer to the vibrant Kubernetes community.' + }, + { + type: 3, + name: 'StackPointCloud', + logo: 'stackpoint', + link: 'https://stackpoint.io', + blurb: 'StackPointCloud - StackPointCloud' + }, + { + type: 2, + name: 'StackPointCloud', + logo: 'stackpoint', + link: 'https://stackpoint.io', + blurb: 'StackPointCloud offers a wide range of support plans for managed Kubernetes clusters built through its universal control plane for Kubernetes Anywhere.' + }, + { + type: 3, + name: 'Caicloud', + logo: 'caicloud', + link: 'https://caicloud.io/products/compass', + blurb: 'Caicloud - Compass' + }, + { + type: 2, + name: 'Caicloud', + logo: 'caicloud', + link: 'https://caicloud.io/', + blurb: 'Founded by ex-Googlers,and early Kubernetes contributors, Caicloud leverages Kubernetes to provide container products which have successfully served Fortune 500 enterprises, and further utilizes Kubernetes as a vehicle to deliver ultra-speed deep learning experience.' + }, + { + type: 3, + name: 'Alibaba', + logo: 'alibaba', + link: 'https://www.aliyun.com/product/containerservice?spm=5176.8142029.388261.219.3836dbccRpJ5e9', + blurb: 'Alibaba Cloud - Alibaba Cloud Container Service' + }, + { + type: 3, + name: 'Tencent', + logo: 'tencent', + link: 'https://cloud.tencent.com/product/ccs?lang=en', + blurb: 'Tencent Cloud - Tencent Cloud Container Service' + }, + { + type: 3, + name: 'Huawei', + logo: 'huawei', + link: 'http://www.huaweicloud.com/product/cce.html', + blurb: 'Huawei - Huawei Cloud Container Engine' + }, + { + type: 2, + name: 'Huawei', + logo: 'huawei', + link: 'http://developer.huawei.com/ict/en/site-paas', + blurb: 'FusionStage is an enterprise-grade Platform as a Service product, the core of which is based on mainstream open source container technology including Kubernetes and Docker.' + }, + { + type: 3, + name: 'Google', + logo: 'google', + link: 'https://github.com/kubernetes/kubernetes/tree/master/cluster', + blurb: 'Google - kube-up.sh on Google Compute Engine' + }, + { + type: 3, + name: 'Poseidon', + logo: 'poseidon', + link: 'https://typhoon.psdn.io/', + blurb: 'Poseidon - Typhoon' + }, + { + type: 3, + name: 'Netease', + logo: 'netease', + link: 'https://www.163yun.com/product/container-service-dedicated', + blurb: 'Netease - Netease Container Service Dedicated' + }, + { + type: 2, + name: 'Loodse', + logo: 'loodse', + link: 'https://loodse.com', + blurb: 'Loodse provides Kubernetes training & consulting, and host related events regularly across Europe.' + }, + { + type: 4, + name: 'Loodse', + logo: 'loodse', + link: 'https://loodse.com', + blurb: 'Loodse provides Kubernetes training & consulting, and host related events regularly across Europe.' + }, + { + type: 4, + name: 'LF Training', + logo: 'lf-training', + link: 'https://training.linuxfoundation.org/', + blurb: 'The Linux Foundation’s training program combines the broad, foundational knowledge with the networking opportunities that attendees need to thrive in their careers today.' + }, + { + type: 3, + name: 'Loodse', + logo: 'loodse', + link: 'https://loodse.com', + blurb: 'Loodse - Kubermatic Container Engine' + }, + { + type: 1, + name: 'LTI', + logo: 'lti', + link: 'https://www.lntinfotech.com/', + blurb: 'LTI helps enterprises architect, develop and support scalable cloud native apps using Docker and Kubernetes for private or public cloud.' + }, + { + type: 3, + name: 'Microsoft', + logo: 'microsoft', + link: 'https://github.com/Azure/acs-engine', + blurb: 'Microsoft - Azure acs-engine' + }, + { + type: 3, + name: 'Microsoft', + logo: 'microsoft', + link: 'https://docs.microsoft.com/en-us/azure/aks/', + blurb: 'Microsoft - Azure Container Service AKS' + }, + { + type: 3, + name: 'Oracle', + logo: 'oracle', + link: 'http://www.wercker.com/product', + blurb: 'Oracle - Oracle Container Engine' + }, + { + type: 3, + name: 'Oracle', + logo: 'oracle', + link: 'https://github.com/oracle/terraform-kubernetes-installer', + blurb: 'Oracle - Oracle Terraform Kubernetes Installer' + }, + { + type: 3, + name: 'Mesosphere', + logo: 'mesosphere', + link: 'https://mesosphere.com/kubernetes/', + blurb: 'Mesosphere - Kubernetes on DC/OS' + }, + { + type: 3, + name: 'Appscode', + logo: 'appscode', + link: 'https://appscode.com/products/cloud-deployment/', + blurb: 'Appscode - Pharmer' + }, + { + type: 3, + name: 'SAP', + logo: 'sap', + link: 'https://cloudplatform.sap.com/index.html', + blurb: 'SAP - Cloud Platform - Gardener (not yet released)' + }, + { + type: 3, + name: 'Oracle', + logo: 'oracle', + link: 'https://www.oracle.com/linux/index.html', + blurb: 'Oracle - Oracle Linux Container Services for use with Kubernetes' + }, + { + type: 3, + name: 'CoreOS', + logo: 'coreos', + link: 'https://github.com/kubernetes-incubator/bootkube', + blurb: 'CoreOS - bootkube' + }, + { + type: 2, + name: 'CoreOS', + logo: 'coreos', + link: 'https://coreos.com/', + blurb: 'Tectonic is the enterprise-ready Kubernetes product, by CoreOS. It adds key features to allow you to manage, update, and control clusters in production.' + }, + { + type: 3, + name: 'Weaveworks', + logo: 'weave_works', + link: '/docs/setup/independent/create-cluster-kubeadm/', + blurb: 'Weaveworks - kubeadm' + }, + { + type: 3, + name: 'Joyent', + logo: 'joyent', + link: 'https://github.com/joyent/triton-kubernetes', + blurb: 'Joyent - Triton Kubernetes' + }, + { + type: 3, + name: 'Wise2c', + logo: 'wise2c', + link: 'http://www.wise2c.com/solution', + blurb: 'Wise2C Technology - WiseCloud' + }, + { + type: 2, + name: 'Wise2c', + logo: 'wise2c', + link: 'http://www.wise2c.com', + blurb: 'Using Kubernetes to providing IT continuous delivery and Enterprise grade container management solution to Financial Industry.' + }, + { + type: 3, + name: 'Docker', + logo: 'docker', + link: 'https://www.docker.com/enterprise-edition', + blurb: 'Docker - Docker Enterprise Edition' + }, + { + type: 3, + name: 'Daocloud', + logo: 'daocloud', + link: 'http://www.daocloud.io/dce', + blurb: 'DaoCloud - DaoCloud Enterprise' + }, + { + type: 2, + name: 'Daocloud', + logo: 'daocloud', + link: 'http://www.daocloud.io/dce', + blurb: 'We provide enterprise-level cloud native application platform that supports both Kubernetes and Docker Swarm.' + }, + { + type: 4, + name: 'Daocloud', + logo: 'daocloud', + link: 'http://www.daocloud.io/dce', + blurb: 'We provide enterprise-level cloud native application platform that supports both Kubernetes and Docker Swarm.' + }, + { + type: 3, + name: 'SUSE', + logo: 'suse', + link: 'https://www.suse.com/products/caas-platform/', + blurb: 'SUSE - SUSE CaaS (Container as a Service) Platform' + }, + { + type: 3, + name: 'Pivotal', + logo: 'pivotal', + link: 'https://cloud.vmware.com/pivotal-container-service', + blurb: 'Pivotal/VMware - Pivotal Container Service (PKS)' + }, + { + type: 3, + name: 'VMware', + logo: 'vmware', + link: 'https://cloud.vmware.com/pivotal-container-service', + blurb: 'Pivotal/VMware - Pivotal Container Service (PKS)' + }, + { + type: 3, + name: 'Alauda', + logo: 'alauda', + link: 'http://www.alauda.cn/product/detail/id/68.html', + blurb: 'Alauda - Alauda EE' + }, + { + type: 4, + name: 'Alauda', + logo: 'alauda', + link: 'http://www.alauda.cn/product/detail/id/68.html', + blurb: 'Alauda provides Kubernetes-Centric Enterprise Platform-as-a-Service offerings with a razor focus on delivering Cloud Native capabilities and DevOps best practices to enterprise customers across industries in China.' + }, + { + type: 2, + name: 'Alauda', + logo: 'alauda', + link: 'www.alauda.io', + blurb: 'Alauda provides Kubernetes-Centric Enterprise Platform-as-a-Service offerings with a razor focus on delivering Cloud Native capabilities and DevOps best practices to enterprise customers across industries in China.' + }, + { + type: 3, + name: 'EasyStack', + logo: 'easystack', + link: 'https://easystack.cn/eks/', + blurb: 'EasyStack - EasyStack Kubernetes Service (EKS)' + }, + { + type: 3, + name: 'CoreOS', + logo: 'coreos', + link: 'https://coreos.com/tectonic/', + blurb: 'CoreOS - Tectonic' + }, + { + type: 0, + name: 'GoPaddle', + logo: 'gopaddle', + link: 'https://gopaddle.io', + blurb: 'goPaddle is a DevOps platform for Kubernetes developers. It simplifies the Kubernetes Service creation and maintenance through source to image conversion, build & version management, team management, access controls and audit logs, single click provision of Kubernetes Clusters across multiple clouds from a single console.' + }, + { + type: 0, + name: 'Vexxhost', + logo: 'vexxhost', + link: 'https://vexxhost.com/public-cloud/container-services/kubernetes/', + blurb: 'VEXXHOST offers a high-performance container management service powered by Kubernetes and OpenStack Magnum.' + }, + { + type: 1, + name: 'Component Soft', + logo: 'componentsoft', + link: 'https://www.componentsoft.eu/?p=3925', + blurb: 'Component Soft offers training, consultation and support around open cloud technologies like Kubernetes, Docker, Openstack and Ceph.' + }, + { + type: 0, + name: 'Datera', + logo: 'datera', + link: 'http://www.datera.io/kubernetes/', + blurb: 'Datera delivers high performance, self-managing elastic block storage with self-service provisioning for deploying Kubernetes at scale.' + }, + { + type: 0, + name: 'Containership', + logo: 'containership', + link: 'https://containership.io/', + blurb: 'Containership is a cloud agnostic managed kubernetes offering that supports automatic provisioning on over 14 cloud providers.' + }, + { + type: 0, + name: 'Pure Storage', + logo: 'pure_storage', + link: 'https://hub.docker.com/r/purestorage/k8s/', + blurb: 'Our flexvol driver and dynamic provisioner allow FlashArray/Flashblade storage devices to be consumed as first class persistent storage from within Kubernetes.' + }, + { + type: 0, + name: 'Elastisys', + logo: 'elastisys', + link: 'https://elastisys.com/kubernetes/', + blurb: 'Predictive autoscaling - detects recurring workload variations, irregular traffic spikes, and everything in between. Runs K8s in any public or private cloud.' + }, + { + type: 0, + name: 'Portworx', + logo: 'portworx', + link: 'https://portworx.com/use-case/kubernetes-storage/', + blurb: 'With Portworx, you can manage any database or stateful service on any infrastructure using Kubernetes. You get a single data management layer for all of your stateful services, no matter where they run.' + }, + { + type: 1, + name: 'Object Computing, Inc.', + logo: 'objectcomputing', + link: 'https://objectcomputing.com/services/software-engineering/devops/kubernetes-services', + blurb: 'Our portfolio of DevOps consulting services includes Kubernetes support, development, and training.' + }, + { + type: 1, + name: 'Isotoma', + logo: 'isotoma', + link: 'https://www.isotoma.com/blog/2017/10/24/containerisation-tips-for-using-kubernetes-with-aws/', + blurb: 'Based in the North of England, Amazon partners who are delivering Kubernetes solutions on AWS for replatforming and native development.' + }, + { + type: 1, + name: 'Servian', + logo: 'servian', + link: 'https://www.servian.com/cloud-and-technology/', + blurb: 'Based in Australia, Servian provides advisory, consulting and managed services to support both application and data centric kubernetes use cases.' + }, + { + type: 1, + name: 'Redzara', + logo: 'redzara', + link: 'http://redzara.com/cloud-service', + blurb: 'Redzara has wide and in-depth experience in Cloud automation, now taking one giant step by providing container service offering and services to our customers.' + }, + { + type: 0, + name: 'Dataspine', + logo: 'dataspine', + link: 'http://dataspine.xyz/', + blurb: 'Dataspine is building a secure, elastic and serverless deployment platform for production ML/AI workloads on top of k8s.' + }, + { + type: 1, + name: 'CloudBourne', + logo: 'cloudbourne', + link: 'https://cloudbourne.com/kubernetes-enterprise-hybrid-cloud/', + blurb: 'Want to achieve maximum build, deploy and monitoring automation using Kubernetes? We can help.' + }, + { + type: 0, + name: 'CloudBourne', + logo: 'cloudbourne', + link: 'https://cloudbourne.com/', + blurb: 'Our AppZ Hybrid Cloud Platform can help you achieve your digital transformation goals using the powerful Kubernetes.' + }, + { + type: 3, + name: 'BoCloud', + logo: 'bocloud', + link: 'http://www.bocloud.com.cn/en/index.html', + blurb: 'BoCloud - BeyondcentContainer' + }, + { + type: 2, + name: 'Naitways', + logo: 'naitways', + link: 'https://www.naitways.com/', + blurb: 'Naitways is an Operator (AS57119), Integrator and Cloud Services Provider (our own !). We aim to provide value-added services through our mastering of the whole value chain (Infrastructure, Network, Human skills). Private and Public Cloud is available through Kubernetes managed or unmanaged.' + }, + { + type: 2, + name: 'Kinvolk', + logo: 'kinvolk', + link: 'https://kinvolk.io/kubernetes/', + blurb: 'Kinvolk offers Kubernetes engineering & operations support from cluster to kernel. Leading cloud-native organizations turn to Kinvolk for deep-stack Linux expertise.' + }, + { + type: 1, + name: 'Cascadeo Corporation', + logo: 'cascadeo', + link: 'http://www.cascadeo.com/', + blurb: 'Cascadeo designs, implements, and manages containerized workloads with Kubernetes, for both existing applications and greenfield development projects.' + }, + { + type: 1, + name: 'Elastisys AB', + logo: 'elastisys', + link: 'https://elastisys.com/services/#kubernetes', + blurb: 'We design, build, and operate Kubernetes clusters. We are experts in highly available and self-optimizing Kubernetes infrastructures' + }, + { + type: 1, + name: 'Greenfield Guild', + logo: 'greenfield', + link: 'http://greenfieldguild.com/', + blurb: 'The Greenfield Guild builds quality open source solutions on, and offers training and support for, Kubernetes in any environment.' + }, + { + type: 1, + name: 'PolarSeven', + logo: 'polarseven', + link: 'https://polarseven.com/what-we-do/kubernetes/', + blurb: 'To get started up and running with Kubernetes (K8s) our PolarSeven consultants can help you with creating a fully functional dockerized environment to run and deploy your applications.' + }, + { + type: 1, + name: 'Kloia', + logo: 'kloia', + link: 'https://kloia.com/kubernetes/', + blurb: 'Kloia is DevOps and Microservices Consultancy company that helps its customers to migrate their environment to cloud platforms for enabling more scalable and secure environments. We use Kubernetes to provide our customers all-in-one solutions in an cloud-agnostic way.' + }, + { + type: 0, + name: 'Bluefyre', + logo: 'bluefyre', + link: 'https://www.bluefyre.io', + blurb: 'Bluefyre offers a developer-first security platform that is native to Kubernetes. Bluefyre helps your development team ship secure code on Kubernetes faster!' + }, + { + type: 0, + name: 'Harness', + logo: 'harness', + link: 'https://harness.io/harness-continuous-delivery/secret-sauce/smart-automation/', + blurb: 'Harness offers Continuous Delivery As-A-Service will full support for containerized apps and Kubernetes clusters.' + }, + { + type: 0, + name: 'VMware - Wavefront', + logo: 'wavefront', + link: 'https://www.wavefront.com/solutions/container-monitoring/', + blurb: 'The Wavefront platform provides metrics-driven analytics and monitoring for Kubernetes and container dashboards for DevOps and developer teams delivering visibility into high-level services as well as granular container metrics.' + }, + { + type: 0, + name: 'Bloombase, Inc.', + logo: 'bloombase', + link: 'https://www.bloombase.com/go/kubernetes', + blurb: 'Bloombase provides high bandwidth, defense-in-depth data-at-rest encryption to lock down Kubernetes crown-jewels at scale.' + }, + { + type: 0, + name: 'Kasten', + logo: 'kasten', + link: 'https://kasten.io/product/', + blurb: 'Kasten provides enterprise solutions specifically built to address the operational complexity of data management in cloud-native environments.' + }, + { + type: 0, + name: 'Humio', + logo: 'humio', + link: 'https://humio.com', + blurb: 'Humio is a log aggregation database. We offer a Kubernetes integration that will give you insights to your logs across apps and instances.' + }, + { + type: 0, + name: 'Outcold Solutions LLC', + logo: 'outcold', + link: 'https://www.outcoldsolutions.com/#monitoring-kubernetes', + blurb: 'Powerful Certified Splunk applications for Monitoring OpenShift, Kubernetes and Docker.' + }, + { + type: 0, + name: 'SysEleven GmbH', + logo: 'syseleven', + link: 'http://www.syseleven.de/', + blurb: 'Enterprise Customers who are in need of bulletproof operations (High Performance E-Commerce and Enterprise Portals)' + }, + { + type: 0, + name: 'Landoop', + logo: 'landoop', + link: 'http://lenses.stream', + blurb: 'Lenses for Apache Kafka, to deploy, manage and operate with confidence data streaming pipelines and topologies at scale with confidence and native Kubernetes integration.' + }, + { + type: 0, + name: 'Redis Labs', + logo: 'redis', + link: 'https://redislabs.com/blog/getting-started-with-kubernetes-and-redis-using-redis-enterprise/', + blurb: 'Redis Enterprise extends open source Redis and delivers stable high performance and linear scaling required for building microservices on the Kubernetes platform.' + }, + { + type: 3, + name: 'Diamanti', + logo: 'diamanti', + link: 'https://diamanti.com/', + blurb: 'Diamanti - Diamanti-D10' + }, + { + type: 3, + name: 'Eking', + logo: 'eking', + link: 'http://www.eking-tech.com/', + blurb: 'Hainan eKing Technology Co. - eKing Cloud Container Platform' + }, + { + type: 3, + name: 'Harmony Cloud', + logo: 'harmony', + link: 'http://harmonycloud.cn/products/rongqiyun/', + blurb: 'Harmonycloud - Harmonycloud Container Platform' + }, + { + type: 3, + name: 'Woqutech', + logo: 'woqutech', + link: 'http://woqutech.com/product_qfusion.html', + blurb: 'Woqutech - QFusion' + }, + { + type: 3, + name: 'Baidu', + logo: 'baidu', + link: 'https://cloud.baidu.com/product/cce.html', + blurb: 'Baidu Cloud - Baidu Cloud Container Engine' + }, + { + type: 3, + name: 'ZTE', + logo: 'zte', + link: 'https://sdnfv.zte.com.cn/en/home', + blurb: 'ZTE - TECS OpenPalette' + }, + { + type: 1, + name: 'Automatic Server AG', + logo: 'asag', + link: 'http://www.automatic-server.com/paas.html', + blurb: 'We install and operate Kubernetes in big enterprises, create deployment workflows and help to migrate.' + }, + { + type: 1, + name: 'Circulo Siete', + logo: 'circulo', + link: 'https://circulosiete.com/consultoria/kubernetes/', + blurb: 'We are a Mexico based company offering training, consulting and support to migrate your workloads to Kubernetes, Cloud Native Microservices & Devops.' + }, + { + type: 1, + name: 'DevOpsGuru', + logo: 'devopsguru', + link: 'http://devopsguru.ca/workshop', + blurb: 'DevOpsGuru work with small business to transform from physical to virtual to containerization.' + }, + { + type: 1, + name: 'EIN Intelligence Co., Ltd', + logo: 'ein', + link: 'https://ein.io', + blurb: 'Startups and agile enterprises in South Korea.' + }, + { + type: 0, + name: 'GuardiCore', + logo: 'guardicore', + link: 'https://www.guardicore.com/', + blurb: 'GuardiCore provided process level visibility and network policy enforcement on containerized assets on the Kubernetes platform.' + }, + { + type: 0, + name: 'Hedvig', + logo: 'hedvig', + link: 'https://www.hedviginc.com/blog/provisioning-hedvig-storage-with-kubernetes', + blurb: 'Hedvig is software-defined storage that uses NFS or iSCSI for persistent volumes for provisioning shared storage for pods and containers.' + }, + { + type: 0, + name: 'Hewlett Packard Enterprise', + logo: 'hpe', + link: ' https://www.hpe.com/us/en/storage/containers.html', + blurb: 'Persistent Storage that makes data as easy to manage as containers: dynamic provisioning, policy-based performance & protection, QoS, & more.' + }, + { + type: 0, + name: 'JetBrains', + logo: 'jetbrains', + link: 'https://blog.jetbrains.com/teamcity/2017/10/teamcity-kubernetes-support-plugin/', + blurb: 'Run TeamCity cloud build agents in a Kubernetes cluster. Provides Helm support as a build step.' + }, + { + type: 2, + name: 'Opensense', + logo: 'opensense', + link: 'http://www.opensense.fr/en/kubernetes-en/', + blurb: 'We provide Kubernetes services (integration, operation, training) as well as development of banking microservices based on our extended experience with cloud of containers, microservices, data management and financial sector.' + }, + { + type: 2, + name: 'SAP SE', + logo: 'sap', + link: 'https://cloudplatform.sap.com', + blurb: 'The SAP Cloud Platform provides in-memory capabilities and unique business services for building and extending applications. With open sourced Project Gardener, SAP utilizes the power of Kubernetes to enable an open, robust, multi-cloud experience for our customers. You can use simple, modern cloud native design principles and leverage skills your organization already has to deliver agile and transformative applications, while integrating with the latest SAP Leonardo business features.' + }, + { + type: 1, + name: 'Mobilise Cloud Services Limited', + logo: 'mobilise', + link: 'https://www.mobilise.cloud/en/services/serverless-application-delivery/', + blurb: 'Mobilise helps organisations adopt Kubernetes and integrate with their CI/CD tooling.' + }, + { + type: 3, + name: 'AWS', + logo: 'aws', + link: 'https://aws.amazon.com/eks/', + blurb: 'Amazon Elastic Container Service for Kubernetes (Amazon EKS) is a managed service that makes it easy for you to run Kubernetes on AWS without needing to install and operate your own Kubernetes clusters.' + }, + { + type: 3, + name: 'Kontena', + logo: 'kontena', + link: 'https://pharos.sh', + blurb: 'Kontena Pharos - The simple, solid, certified Kubernetes distribution that just works.' + }, + { + type: 2, + name: 'NTTData', + logo: 'nttdata', + link: 'http://de.nttdata.com/altemista-cloud', + blurb: 'NTT DATA, a member of the NTT Group, brings the power of the worlds leading infrastructure provider in the global K8s community.' + }, + { + type: 2, + name: 'OCTO', + logo: 'octo', + link: 'https://www.octo.academy/fr/formation/275-kubernetes-utiliser-architecturer-et-administrer-une-plateforme-de-conteneurs', + blurb: 'OCTO technology provides training, architecture, technical consulting and delivery services including containers and Kubernetes.' + }, + { + type: 0, + name: 'Logdna', + logo: 'logdna', + link: 'https://logdna.com/kubernetes', + blurb: 'Pinpoint production issues instantly with LogDNA, the best logging platform you will ever use. Get started with only 2 kubectl commands.' + } + ] + + var kcspContainer = document.getElementById('kcspContainer') + var distContainer = document.getElementById('distContainer') + var ktpContainer = document.getElementById('ktpContainer') + var isvContainer = document.getElementById('isvContainer') + var servContainer = document.getElementById('servContainer') + + var sorted = partners.sort(function (a, b) { + if (a.name > b.name) return 1 + if (a.name < b.name) return -1 + return 0 + }) + + sorted.forEach(function (obj) { + var box = document.createElement('div') + box.className = 'partner-box' + + var img = document.createElement('img') + img.src = '/images/square-logos/' + obj.logo + '.png' + + var div = document.createElement('div') + + var p = document.createElement('p') + p.textContent = obj.blurb + + var link = document.createElement('a') + link.href = obj.link + link.target = '_blank' + link.textContent = 'Learn more' + + div.appendChild(p) + div.appendChild(link) + + box.appendChild(img) + box.appendChild(div) + + var container; + if (obj.type === 0) { + container = isvContainer; + } else if (obj.type === 1) { + container = servContainer; + } else if (obj.type === 2) { + container = kcspContainer; + } else if (obj.type === 3) { + container = distContainer; + } else if (obj.type === 4) { + container = ktpContainer; + } + + container.appendChild(box) + }) +})(); diff --git a/content/ja/includes/partner-style.css b/content/ja/includes/partner-style.css new file mode 100644 index 0000000000..7aeb255dd5 --- /dev/null +++ b/content/ja/includes/partner-style.css @@ -0,0 +1,202 @@ +/* SECTIONS */ +.section { + clear: both; + padding: 0px; + margin-bottom: 2em; +} + +.kcsp_section { + clear: both; + padding: 0px; + margin-bottom: 2em; +} + +/* COLUMN SETUP */ +.col { + display: block; + float:left; + margin: 1% 0 1% 1.6%; + background-color: #f9f9f9; +} +.col:first-child { margin-left: 0; } + + +/* GROUPING */ +.group:before, +.group:after { + content:""; + display:table; +} +.group:after { + clear:both; +} +.group { + zoom:1; /* For IE 6/7 */ +} + +/* GRID OF THREE */ +.span_3_of_3 { + width: 35%; + background-color: #f9f9f9; + padding: 20px; +} +.span_2_of_3 { + width: 35%; + background-color: #f9f9f9; + padding: 20px; +} +.span_1_of_3 { + width: 35%; + background-color: #f9f9f9; + padding: 20px; +} + +.col-container { + display: table; /* Make the container element behave like a table */ + width: 100%; /* Set full-width to expand the whole page */ + padding-bottom: 30px; +} + +.col-nav { + display: table-cell; /* Make elements inside the container behave like table cells */ + width: 18%; + background-color: #f9f9f9; + padding: 20px; + border: 5px solid white; +} + +/* GO FULL WIDTH AT LESS THAN 480 PIXELS */ + +@media only screen and (max-width: 480px) { + .col { margin: 1% 0 1% 0%;} + .span_3_of_3, .span_2_of_3, .span_1_of_3 { width: 100%; } +} + +@media only screen and (max-width: 650px) { + .col-nav { + display: block; + width: 100%; + } +} + +.button{ + max-width: 100%; + box-sizing: border-box; + font-family: "Roboto", sans-serif; + margin: 0; + display: inline-block; + border-radius: 6px; + padding: 0 20px; + line-height: 40px; + color: #ffffff; + font-size: 16px; + background-color: #3371e3; + text-decoration: none; + } + +h5 { + font-size: 16px; + line-height: 1.5em; + margin-bottom: 2em; +} + +#usersGrid a { + display: inline-block; + background-color: #f9f9f9; +} + +#ktpContainer, #distContainer, #kcspContainer, #isvContainer, #servContainer { + position: relative; + width: 100%; + display: flex; + justify-content: space-between; + flex-wrap: wrap; +} + +#isvContainer { + margin-bottom: 80px; +} + +#kcspContainer { + margin-bottom: 80px; +} + +#distContainer { + margin-bottom: 80px; +} + +#ktpContainer { + margin-bottom: 80px; +} + +.partner-box { + position: relative; + width: 47%; + max-width: 48%; + min-width: 48%; + margin-bottom: 20px; + padding: 20px; + flex: 1; + display: flex; + justify-content: left; + align-items: flex-start; +} + +.partner-box img { + background-color: #f9f9f9; +} + +.partner-box > div { + margin-left: 30px; +} + +.partner-box a { + color: #3576E3; +} + +@media screen and (max-width: 1024px) { + .partner-box { + flex-direction: column; + justify-content: flex-start; + } + + .partner-box > div { + margin: 20px 0 0; + } +} + +@media screen and (max-width: 568px) { + #ktpContainer, #distContainter, #kcspContainer, #isvContainer, #servContainer { + justify-content: center; + } + + .partner-box { + flex-direction: column; + justify-content: flex-start; + width: 100%; + max-width: 100%; + min-width: 100%; + } + + .partner-box > div { + margin: 20px 0 0; + } +} + +@media screen and (max-width: 568px) { + #ktpContainer, #distContainer, #kcspContainer, #isvContainer, #servContainer { + justify-content: center; + } + + .partner-box { + flex-direction: column; + justify-content: flex-start; + width: 100%; + max-width: 100%; + min-width: 100%; + } + + .partner-box > div { + margin: 20px 0 0; + } +} diff --git a/content/ja/includes/task-tutorial-prereqs.md b/content/ja/includes/task-tutorial-prereqs.md new file mode 100644 index 0000000000..043e14681a --- /dev/null +++ b/content/ja/includes/task-tutorial-prereqs.md @@ -0,0 +1,6 @@ +Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 +まだクラスターがない場合、[Minikube](/ja/docs/setup/minikube)を使って作成するか、 +以下のいずれかのKubernetesプレイグラウンドも使用できます: + +* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Play with Kubernetes](http://labs.play-with-k8s.com/) diff --git a/content/ja/includes/user-guide-content-moved.md b/content/ja/includes/user-guide-content-moved.md new file mode 100644 index 0000000000..8b93e29f12 --- /dev/null +++ b/content/ja/includes/user-guide-content-moved.md @@ -0,0 +1,3 @@ +The topics in the [User Guide](/docs/user-guide/) section of the Kubernetes docs +are being moved to the [Tasks](/docs/tasks/), [Tutorials](/docs/tutorials/), and +[Concepts](/docs/concepts) sections. The content in this topic has moved to: diff --git a/content/ja/includes/user-guide-migration-notice.md b/content/ja/includes/user-guide-migration-notice.md new file mode 100644 index 0000000000..366a05907c --- /dev/null +++ b/content/ja/includes/user-guide-migration-notice.md @@ -0,0 +1,12 @@ + + + + + + +
+

NOTICE

+

As of March 14, 2017, the Kubernetes SIG-Docs-Maintainers group have begun migration of the User Guide content as announced previously to the SIG Docs community through the kubernetes-sig-docs group and kubernetes.slack.com #sig-docs channel.

+

The user guides within this section are being refactored into topics within Tutorials, Tasks, and Concepts. Anything that has been moved will have a notice placed in its previous location as well as a link to its new location. The reorganization implements a new table of contents and should improve the documentation's findability and readability for a wider range of audiences.

+

For any questions, please contact: kubernetes-sig-docs@googlegroups.com

+
diff --git a/content/ko/_index.html b/content/ko/_index.html index 854a54c7ee..f932ba6c2e 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -30,7 +30,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 {{% blocks/feature image="suitcase" %}} #### 어디서나 동작 -쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. +쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. {{% /blocks/feature %}} @@ -44,12 +44,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준


- Attend KubeCon in Shanghai on June 24-26, 2019 -
-
-
-
Attend KubeCon in San Diego on Nov. 18-21, 2019 +
+
+
+
+ Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index cd639c39c7..2028073489 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -22,6 +22,10 @@ weight: 10 * [용량과 할당가능](#capacity) * [정보](#info) +노드의 상태와 상세 정보는 다음 커맨드를 통해 확인할 수 있다. +```shell +kubectl describe node +``` 각 섹션은 아래 상세하게 기술되었다. ### 주소 {#addresses} @@ -88,7 +92,8 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll ### 정보 {#info} -커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은 노드에 대한 일반적인 정보이다. 정보는 Kubelet에 의해 노드로부터 수집된다. +커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다. +이 정보는 Kubelet에 의해 노드로부터 수집된다. ## 관리 diff --git a/content/ko/docs/concepts/cluster-administration/proxies.md b/content/ko/docs/concepts/cluster-administration/proxies.md new file mode 100644 index 0000000000..fedef39322 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/proxies.md @@ -0,0 +1,67 @@ +--- +title: 쿠버네티스에서 프락시(Proxy) +content_template: templates/concept +weight: 90 +--- + +{{% capture overview %}} +이 페이지는 쿠버네티스에서 함께 사용되는 프락시(Proxy)를 설명한다. +{{% /capture %}} + +{{% capture body %}} + +## 프락시 + +쿠버네티스를 이용할 때에 사용할 수 있는 여러 프락시가 있다. + +1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api): + + - 사용자의 데스크탑이나 파드 안에서 실행한다. + - 로컬 호스트 주소에서 쿠버네티스의 API 서버로 프락시한다. + - 클라이언트로 프락시는 HTTP를 사용한다. + - API 서버로 프락시는 HTTPS를 사용한다. + - API 서버를 찾는다. + - 인증 헤더를 추가한다. + +1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): + + - API 서버에 내장된 요새(bastion)이다. + - 클러스터 외부의 사용자가 도달할 수 없는 클러스터 IP 주소로 연결한다. + - API 서버 프로세스에서 실행한다. + - 클라이언트로 프락시는 HTTPS(또는 API서버에서 HTTP로 구성된 경우는 HTTP)를 사용한다. + - 사용 가능한 정보를 이용하여 프락시에 의해 선택한 HTTP나 HTTPS를 사용할 수 있는 대상이다. + - 노드, 파드, 서비스에 도달하는데 사용할 수 있다. + - 서비스에 도달할 때에는 로드 밸런싱을 수행한다. + +1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): + + - 각 노드에서 실행한다. + - UDP, TCP, SCTP를 이용하여 프락시 한다. + - HTTP는 이해하지 못한다. + - 로드 밸런싱을 제공한다. + - 단지 서비스에 도달하는데 사용한다. + +1. API 서버 앞단의 프락시/로드밸런서 + + - 존재 및 구현은 클러스터 마다 다르다. (예: nginx) + - 모든 클라이언트와 하나 이상의 API 서버에 위치한다. + - 여러 API 서버가 있는 경우 로드 밸런서로서 작동한다. + +1. 외부 서비스의 클라우드 로드 밸런서 + + - 일부 클라우드 제공자는 제공한다. (예: AWS ELB, 구글 클라우드 로드 밸런서) + - 쿠버네티스 서비스로 `LoadBalancer` 유형이 있으면 자동으로 생성된다. + - 일반적으로 UDP/TCP만 지원한다. + - SCTP 지원은 클라우드 제공자의 구현에 달려 있다. + - 구현은 클라우드 제공자에 따라 다양하다. + +쿠버네티스 사용자는 보통 처음 두 가지 유형 외의 것은 걱정할 필요없다. +클러스터 관리자는 일반적으로 후자의 유형이 올바르게 구성되었는지 확인한다. + +## 요청을 리다이렉트하기 + +프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다. + +{{% /capture %}} + + diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md new file mode 100644 index 0000000000..d5ffe7a508 --- /dev/null +++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -0,0 +1,156 @@ +--- +title: kubeconfig 파일을 사용하여 클러스터 접근 구성하기 +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + +kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스 및 인증 메커니즘에 대한 정보를 관리하자. +`kubectl` 커맨드라인 툴은 kubeconfig 파일을 사용하여 +클러스터의 선택과 +클러스터의 API 서버와의 통신에 필요한 정보를 찾는다. + +{{< note >}} +클러스터에 대한 접근을 구성하는 데 사용되는 파일을 *kubeconfig 파일* 이라 한다. +이는 구성 파일을 참조하는 일반적인 방법을 의미한다. +`kubeconfig`라는 이름의 파일이 있다는 의미는 아니다. +{{< /note >}} + +기본적으로 `kubectl`은 `$HOME/.kube` 디렉터리에서 `config`라는 이름의 파일을 찾는다. +`KUBECONFIG` 환경 변수를 설정하거나 +[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) 플래그를 지정해서 +다른 kubeconfig 파일을 사용할 수 있다. + +kubeconfig 파일을 생성하고 지정하는 단계별 지시사항은 +[다중 클러스터로 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)를 참조한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 다중 클러스터, 사용자와 인증 메커니즘 지원 + +여러 클러스터가 있고, 사용자와 구성 요소가 다양한 방식으로 인증한다고 가정하자. +예를 들면 다음과 같다. + +- 실행 중인 kubelet은 인증서를 이용하여 인증할 수 있다. +- 사용자는 토큰으로 인증할 수 있다. +- 관리자는 개별 사용자에게 제공하는 인증서 집합을 가지고 있다. + +kubeconfig 파일을 사용하면 클러스터와 사용자와 네임스페이스를 구성할 수 있다. +또한 컨텍스트를 정의하여 +빠르고 쉽게 클러스터와 네임스페이스 간에 전환할 수 있다. + +## 컨텍스트 + +kubeconfig에서 *컨텍스트* 요소는 편리한 이름으로 접속 매개 변수를 묶는데 사용한다. +각 컨텍스트는 클러스터, 네임스페이스와 사용자라는 세 가지 매개 변수를 가진다. +기본적으로 `kubectl` 커맨드라인 툴은 *현재 컨텍스트* 의 매개 변수를 +사용하여 클러스터와 통신한다. + +현재 컨택스트를 선택하려면 다음을 실행한다. +``` +kubectl config use-context +``` + +## KUBECONFIG 환경 변수 + +`KUBECONFIG` 환경 변수는 kubeconfig 파일 목록을 보유한다. +Linux 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다. +Windows는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다. +`KUBECONFIG` 환경 변수가 없으면, +`kubectl`은 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다. + +`KUBECONFIG` 환경 변수가 존재하면, `kubectl`은 +`KUBECONFIG` 환경 변수에 나열된 파일을 병합한 결과 형태의 +효과적 구성을 이용한다. + +## kubeconfig 파일 병합 + +구성을 보려면, 다음 커맨드를 입력한다. + +```shell +kubectl config view +``` + +앞서 설명한 것처럼, 이 출력 내용은 단일 kubeconfig 파일이나 +여러 kubeconfig 파일을 병합한 결과 일 수 있다. + +다음은 kubeconfig 파일을 병합할 때에 `kubectl`에서 사용하는 규칙이다. + +1. `--kubeconfig` 플래그를 설정했으면, 지정한 파일만 사용한다. 병합하지 않는다. + 이 플래그는 오직 한 개 인스턴스만 허용한다. + + 그렇지 않고, `KUBECONFIG` 환경 변수를 설정하였다면 + 병합해야 하는 파일의 목록으로 사용한다. + `KUBECONFIG` 환경 변수의 나열된 파일은 + 다음 규칙에 따라 병합한다. + + * 빈 파일명은 무시한다. + * 역 직렬화 불가한 파일 내용에 대해서 오류를 일으킨다. + * 특정 값이나 맵 키를 설정한 첫 번째 파일을 우선한다. + * 값이나 맵 키를 변경하지 않는다. + 예: `현재 컨텍스트`를 설정할 첫 번째 파일의 컨택스트를 유지한다. + 예: 두 파일이 `red-user`를 지정했다면, 첫 번째 파일의 `red-user` 값만을 사용한다. + 두 번째 파일의 `red-user` 하위에 충돌하지 않는 항목이 있어도 버린다. + + `KUBECONFIG` 환경 변수 설정의 예로, + [KUBECONFIG 환경 변수 설정](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)를 참조한다. + + 그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다. + +1. 이 체인에서 첫 번째를 기반으로 사용할 컨텍스트를 결정한다. + + 1. 커맨드라인 플래그의 `--context`를 사용한다. + 1. 병합된 kubeconfig 파일에서 `current-context`를 사용한다. + + 이 시점에서는 빈 컨텍스트도 허용한다. + +1. 클러스터와 사용자를 결정한다. 이 시점에서는 컨텍스트가 있을 수도 있고 없을 수도 있다. + 사용자에 대해 한 번, 클러스터에 대해 한 번 총 두 번에 걸친 + 이 체인에서 첫 번째 것을 기반으로 클러스터와 사용자를 결정한다. + + 1. 커맨드라인 플래그가 존재하면, `--user` 또는 `--cluster`를 사용한다. + 1. 컨텍스트가 비어있지 않다면, 컨텍스트에서 사용자 또는 클러스터를 가져온다. + + 이 시점에서는 사용자와 클러스터는 비워둘 수 있다. + +1. 사용할 실제 클러스터 정보를 결정한다. + 이 시점에서 클러스터 정보가 있을 수 있고 없을 수도 있다. + 이 체인을 기반으로 클러스터 정보를 구축한다. 첫 번째 것을 사용한다. + + 1. 커맨드라인 플래그가 존재하면, `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`를 사용한다. + 1. 병합된 kubeconfig 파일에서 클러스터 정보 속성이 있다면 사용한다. + 1. 서버 위치가 없다면 실패한다. + +1. 사용할 실제 사용자 정보를 결정한다. + 사용자 당 하나의 인증 기법만 허용하는 것을 제외하고는 + 클러스터 정보와 동일한 규칙을 사용하여 사용자 정보를 작성한다. + + 1. 커맨드라인 플래그가 존재하면, `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`을 사용한다. + 1. 병합된 kubeconfig 파일에서 `user` 필드를 사용한다. + 1. 충돌하는 두 가지 기법이 있다면 실패한다. + +1. 여전히 누락된 정보는 기본 값을 사용하고 + 인증 정보를 묻는 메시지가 표시될 수 있다. + +## 파일 참조 + +kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치와 관련 있다. +커맨드라인 상에 파일 참조는 현재 디렉터리를 기준으로 한다. +`$HOME/.kube/config`에서 상대 경로는 상대적으로, 절대 경로는 +절대적으로 저장한다. + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [다중 클러스터 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) + +{{% /capture %}} + + diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md new file mode 100644 index 0000000000..d1294c119d --- /dev/null +++ b/content/ko/docs/concepts/configuration/overview.md @@ -0,0 +1,107 @@ +--- +title: 구성 모범 사례 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} +이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된 구성 모범 사례를 강조하고 통합한다. + +이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면, 새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다. +{{% /capture %}} + +{{% capture body %}} +## 일반적인 구성 팁 + +- 구성을 정의할 때, 안정된 최신 API 버전을 명시한다. + +- 구성 파일들은 클러스터에 적용되기 전에 버전 컨트롤에 저장되어 있어야 한다. 이는 만약 필요하다면 구성의 변경 사항을 빠르게 되돌릴 수 있도록 해준다. 이는 또한 클러스터의 재-생성과 복원을 도와준다. + +- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다. + +- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다. + +- 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다. + +- 불필요하게 기본 값을 명시하지 않는다. 간단하고 최소한의 설정은 에러를 덜 발생시킨다. + +- 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다. + + +## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 + +- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. + + 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다. + + +## 서비스 + +- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. + + ```shell + FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> + FOO_SERVICE_PORT=<서비스가 동작 중인 포트> + ``` + + *이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드` 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. DNS는 이러한 제한을 가지고 있지 않다. + +- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/docs/concepts/cluster-administration/addons/)은 DNS 서버이다. +DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, 모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다. + +- 반드시 필요한 것이 아니라면 파드에 `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/)를 사용할 수 있다. + + 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다. + +- `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. + +- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless- +services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. + +## 레이블 사용하기 + +- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. + +릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다. + +오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다. + +- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카 셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. + +## 컨테이너 이미지 + +[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/admin/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다. + +- `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다. + +- `imagePullPolicy: Always`: 파드가 시작될 때마다 이미지가 풀(Pull) 된다. + +- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다. + +- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `IfNotPresent`가 적용된다. + +- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다. + +{{< note >}} +컨테이너가 항상 같은 버전의 이미지를 사용하도록 만들기 위해, `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`와 같은 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다. +{{< /note >}} + +{{< note >}} +운영 환경에서 컨테이너를 생성할 때 `:latest` 태그의 사용을 피하는 것이 좋은데, 이는 어떠한 버전의 이미지가 실행 중인지 추적하기가 어렵고, 적절히 롤백하기가 더 어려워지기 때문이다. +{{< /note >}} + +{{< note >}} +기반이 되는 이미지 제공자의 캐시 방법은 `imagePullPolicy: Always`를 효율적으로 만든다. 예를 들어, 도커에서는 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다. +{{< /note >}} + +## kubectl 사용하기 + +- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다. + +- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다. + +- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 50291bd72d..09143afa7d 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -57,7 +57,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - 각 클러스터에 대하여 - Google 컴퓨트 엔진 또는 Google 쿠버네티스 엔진에서 자동적으로 구성됨 - 모든 파드는 해당 프로젝트의 프라이빗 레지스트리를 읽을 수 있음 - - AWS EC2 컨테이너 레지스트리(ECR) 사용 + - AWS Elastic Container Registry(ECR) 사용 - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함 - ECR 로그인 자격 증명은 자동으로 갱신됨 - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용 @@ -67,7 +67,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음 - 클러스터 관리자에 의한 노드 구성 필요 - - 미리 풀링(pre-pulling)된 이미지 + - 미리 내려받은(pre-pulled) 이미지 - 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능 - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요 - 파드에 ImagePullSecrets을 명시 @@ -89,10 +89,9 @@ Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 GCR을 인스턴스의 서비스 계정은 `https://www.googleapis.com/auth/devstorage.read_only`라서, 프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다. -### AWS EC2 컨테이너 레지스트리 사용 +### Amazon Elastic Container Registry 사용 -쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [AWS EC2 컨테이너 -레지스트리](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다. +쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다. 간단히 이미지의 전체 이름(예: `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)을 파드 정의에 사용하면 된다. @@ -240,7 +239,7 @@ kubectl describe pods/private-image-test-1 | grep "Failed" 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다. -### 미리 풀링(pre-pulling)된 이미지 +### 미리 내려받은 이미지 {{< note >}} Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다. @@ -257,11 +256,11 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 로컬 이미지가 사용된다(우선적으로 또는 배타적으로). 레지스트리 인증의 대안으로 미리 풀 된 이미지에 의존하고 싶다면, -클러스터의 모든 노드가 동일한 미리 풀 된 이미지를 가지고 있는지 확인해야 한다. +클러스터의 모든 노드가 동일한 미리 내려받은 이미지를 가지고 있는지 확인해야 한다. 이것은 특정 이미지를 속도를 위해 미리 로드하거나 프라이빗 레지스트리에 대한 인증의 대안으로 사용될 수 있다. -모든 파드는 미리 풀 된 이미지에 대해 읽기 접근 권한을 가질 것이다. +모든 파드는 미리 내려받은 이미지에 대해 읽기 접근 권한을 가질 것이다. ### 파드에 ImagePullSecrets 명시 diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 575d5e2e5c..f2b58c7113 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -16,7 +16,7 @@ card: ## 마스터 컴포넌트 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정 -(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다. +(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동 시키는 것)를 감지하고 반응한다. 마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나, 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고, @@ -110,6 +110,9 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 [클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다. +* [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기 +* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기 +* etcd의 공식 [문서](https://etcd.io/docs/) 읽기 {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md new file mode 100644 index 0000000000..450255c37c --- /dev/null +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -0,0 +1,169 @@ +--- +title: 권장 레이블 +content_template: templates/concept +--- + +{{% capture overview %}} +kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝트를 시각화 하고 관리할 수 있다. +공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고 +도구들이 상호 운용적으로 작동할 수 있도록 한다. + +권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다. +{{% /capture %}} + +{{% capture body %}} +메타데이터는 _애플리케이션_ 의 개념을 중심으로 정리된다. +쿠버네티스는 플랫폼 서비스(PaaS)가 아니며 애플리케이션에 대해 공식적인 개념이 없거나 강요하지 않는다. +대신 애플리케이션은 비공식적이며 메타데이터로 설명된다. +애플리케이션에 포함된 정의는 유연하다. + +{{< note >}} +메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 코어 도구에는 필요하지 않다. +{{< /note >}} + +공유 레이블과 주석에는 공통 접두사인 `app.kubernetes.io` 가 있다. +접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다. +공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다. + + +## 레이블 + +레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다. + +| Key | Description | Example | Type | +| ----------------------------------- | --------------------- | -------- | ---- | +| `app.kubernetes.io/name` | 애플리케이션 이름 | `mysql` | 문자열 | +| `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `wordpress-abcxzy` | 문자열 | +| `app.kubernetes.io/version` | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 | +| `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 | +| `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 | +| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는데 사용되는 도구 | `helm` | 문자열 | + +위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다. + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/managed-by: helm +``` + +## 애플리케이션과 애플리케이션 인스턴스 + +애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 한번 또는 그 이상 설치할 수 있다. +예를 들어 워드프레스는 다른 워드프레스가 설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다. + +애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다. +예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는 +`app.kubernetes.io/instance` 에 `wordpress-abcxzy` 의 값을 가진다. +이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다. +모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다. + +## 예시 + +위 레이블을 사용하는 다른 방식에 대한 예시는 다양한 복잡성이 있다. + +### 단순한 스테이트리스 서비스 + +`Deployment` 와 `Service` 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다. + +`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는데 사용한다. +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + +`Service`는 애플리케이션을 노출하기 위해 사용한다. +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + +### 데이터베이스가 있는 웹 애플리케이션 + +Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. +다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다. + +WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +`Service` 는 애플리케이션을 노출하기 위해 사용한다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +MySQL은 `StatefulSet` 에 MySQL의 소속과 상위 애플리케이션에 대한 메타데이터가 포함되어 노출된다. + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +`Service` 는 WordPress의 일부로 MySQL을 노출하는데 이용한다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000..58d29c2532 --- /dev/null +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,225 @@ +--- +title: 레이블과 셀렉터 +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +_레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다. +레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. +레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다. +오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다. + +```json +"metadata": { + "labels": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 사용동기 + +레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다. + +서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔터티들이다(예: 다중파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다. + +레이블 예시: + + * `"release" : "stable"`, `"release" : "canary"` + * `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` + * `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` + * `"partition" : "customerA"`, `"partition" : "customerB"` + * `"track" : "daily"`, `"track" : "weekly"` + +레이블 예시는 일반적으로 사용하는 경우에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야한다는 것을 기억해야한다. + +## 구문과 캐릭터 셋 + +_레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(`/`)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야하며, 점(`.`)과, 전체 253자 이하, 슬래시(`/`)로 구분되는 DNS 레이블이다. + +접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 구성 요소(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다. + +`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 구성요소로 예약되어있다. + +유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. + +다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다. + +```yaml + +apiVersion: v1 +kind: Pod +metadata: + name: label-demo + labels: + environment: production + app: nginx +spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 + +``` + +## 레이블 셀렉터 + +[이름과 UID](/docs/user-guide/identifiers)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다. + +레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다. + +API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 셀렉터를 지원한다. +레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다. + +비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다. +셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화 해야 한다. + +{{< note >}} +레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충되는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다. +{{< /note >}} + +### _일치성 기준_ 요건 + +_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만 레이블의 명시된 제약 조건을 모두 만족해야 한다. +`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_를 의미한다. 예를 들면, + +``` +environment = production +tier != frontend +``` + +전자는 `environment`를 키로 가지는 것과 `production`를 값으로 가지는 모든 리소스를 선택한다. +후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다. +`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다. + +균등-기반 레이블의 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다. +예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다. + + + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-test +spec: + containers: + - name: cuda-test + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 +``` + +### _집합성 기준_ 요건 + +_집합성 기준_ 레이블 요건에 따라 값 집합을 키로 필터링할 수 있다. `in`,`notin` and `exists`(키 식별자만 해당)의 3개의 연산자를 지원한다. 예를 들면, + +``` +environment in (production, qa) +tier notin (frontend, backend) +partition +!partition +``` + +첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다. +두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와, 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다. +세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하는 모든 리소스를 선택한다. +네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하지 않는 모든 리소스를 선택한다. +마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다. +_집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production` 과 `environment in (production)`를 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다. + +_집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa` + +## API + +### LIST와 WATCH 필터링 + +LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀럭터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함). + + * _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` + * _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` + +두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `API 서버`를 대상으로 _불일치 기준_으로 하는 셀렉터를 다음과 같이 이용할 수 있다. + +```shell +kubectl get pods -l environment=production,tier=frontend +``` + +또는 _집합성 기준_ 요건을 사용하면 + +```shell +kubectl get pods -l 'environment in (production),tier in (frontend)' +``` + +앞서 안내한 것처럼 _집합성 기준_ 요건은 더 보여준다. 예시에서 다음과 같이 OR 연산자를 구현할 수 있다. + +```shell +kubectl get pods -l 'environment in (production, qa)' +``` + +또는 _exists_ 연산자에 불일치한 것으로 제한할 수 있다. + +```shell +kubectl get pods -l 'environment,environment notin (frontend)' +``` + +### API 오브젝트에서 참조 설정 + +[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다. + +#### 서비스와 리플리케이션 컨트롤러 + +`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `리플레케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다. + +서비스와 리플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다. + +```json +"selector": { + "component" : "redis", +} +``` +or + +```yaml +selector: + component: redis +``` + +`json` 또는 `yaml` 서식에서 셀렉터는 `component=redis` 또는 `component in (redis)` 모두 같은 것이다. + + +#### 세트-기반 요건을 지원하는 리소스 + +[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다. + +```yaml +selector: + matchLabels: + component: redis + matchExpressions: + - {key: tier, operator: In, values: [cache]} + - {key: environment, operator: NotIn, values: [dev]} +``` + +`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`과 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다. + +#### 노드 셋 선택 + +레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. +자세한 내용은 [노드 선택](/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index 119cf34fe6..63229eb600 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -61,13 +61,13 @@ kube-public Active 1d ### 요청에 네임스페이스 설정하기 -임시로 네임스페이스를 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다. +네임스페이스를 현재 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다. 예를 들면, ```shell -kubectl --namespace= run nginx --image=nginx -kubectl --namespace= get pods +kubectl run nginx --image=nginx --namespace= +kubectl get pods --namespace= ``` ### 선호하는 네임스페이스 설정하기 @@ -108,3 +108,10 @@ kubectl api-resources --namespaced=false ``` {{% /capture %}} + +{{% capture whatsnext %}} +* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기. +* [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기. + +{{% /capture %}} + diff --git a/content/ko/docs/concepts/scheduling/_index.md b/content/ko/docs/concepts/scheduling/_index.md new file mode 100644 index 0000000000..0ffab2ef77 --- /dev/null +++ b/content/ko/docs/concepts/scheduling/_index.md @@ -0,0 +1,5 @@ +--- +title: "스케줄링" +weight: 90 +--- + diff --git a/content/ko/docs/concepts/configuration/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling/scheduler-perf-tuning.md similarity index 91% rename from content/ko/docs/concepts/configuration/scheduler-perf-tuning.md rename to content/ko/docs/concepts/scheduling/scheduler-perf-tuning.md index 0416b9b1c4..6ff8b288f7 100644 --- a/content/ko/docs/concepts/configuration/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -8,14 +8,20 @@ weight: 70 {{< feature-state for_k8s_version="1.14" state="beta" >}} -Kube-scheduler는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 -노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는 -클러스터의 노드를 파드에 "적합한(feasible)" 노드라고 한다. 스케줄러는 -파드에 대해 적합한 노드를 찾고 기능 셋을 실행하여 해당 노드의 점수를 -측정한다. 그리고 스케줄러는 파드를 실행하는데 적합한 모든 노드 중 가장 -높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 "바인딩"이라는 프로세스로 +[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) +는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 +노드에 파드를 배치하는 역할을 한다. + +파드의 스케줄링 요건을 충족하는 +클러스터의 노드를 파드에 _적합한(feasible)_ 노드라고 한다. 스케줄러는 +파드에 대해 적합한 노드를 찾고 기능 셋을 실행하여 해당 노드의 점수를 +측정한다. 그리고 스케줄러는 파드를 실행하는데 적합한 모든 노드 중 가장 +높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 _바인딩_ 이라는 프로세스로 API 서버에 해당 결정을 통지한다. +본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 +최적화에 대해 설명한다. + {{% /capture %}} {{% capture body %}} diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md new file mode 100644 index 0000000000..bf373c8d2b --- /dev/null +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -0,0 +1,1144 @@ +--- +title: 디플로이먼트 +feature: + title: 자동화된 롤아웃과 롤백 + description: > + 쿠버네티스는 애플리케이션 또는 애플리케이션의 설정 변경시 점진적으로 롤아웃하는 동시에 애플리케이션을 모니터링해서 모든 인스턴스가 동시에 종료되지 않도록 보장한다. 만약 어떤 문제가 발생하면 쿠버네티스는 변경 사항을 롤백한다. 성장하는 디플로이먼트 솔루션 생태계를 이용한다. + +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +_디플로이먼트_ 컨트롤러는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 +[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다. + +디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 컨트롤러는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다. + +{{< note >}} +디플로이먼트가 소유하는 레플리카셋은 관리하지 말아야 한다. 사용자의 유스케이스가 다음에 포함되지 않는 경우 쿠버네티스 리포지터리에 이슈를 올릴 수 있다. +{{< /note >}} + +{{% /capture %}} + + +{{% capture body %}} + +## 유스케이스 + +다음은 디플로이먼트의 일반적인 유스케이스이다. + +* [레플리카셋을 롤아웃 할 디플로이먼트 생성](#디플로이먼트-생성). 레플리카셋은 백그라운드에서 파드를 생성한다. 롤아웃 상태를 체크해서 성공 여부를 확인한다. +* 디플로이먼트의 PodTemplateSpec을 업데이트해서 [파드의 새로운 상태를 선언한다](#디플로이먼트-업데이트). 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다. +* 만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 [디플로이먼트의 이전 버전으로 롤백](#디플로이먼트-롤백)한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다. +* [더 많은 로드를 위해 디플로이먼트의 스케일 업](#디플로이먼트-스케일링). +* [디플로이먼트 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 새로운 롤아웃의 시작을 재개한다. +* 롤아웃이 막혀있는지를 나타내는 [디플로이먼트 상태를 이용](#디플로이먼트-상태). +* 더 이상 필요 없는 [이전 레플리카셋 정리](#정책-초기화). + +## 디플로이먼트 생성 + +다음은 디플로이먼트의 예시이다. 예시는 3개의 `nginx` 파드를 불러오기 위한 레플리카셋을 생성한다. + +{{< codenew file="controllers/nginx-deployment.yaml" >}} + +이 예시에 대한 설명은 다음과 같다. + +* `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다. +* `replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다. +* `selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다. + 이 사례에서는 간단하게 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다. + 그러나 파드 템플릿 자체의 규칙이 만족되는 한, + 보다 정교한 선택 규칙의 적용이 가능하다. + {{< note >}} + `matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 + 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 + 값 배열은 "value"만 포함한다. + 매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다. + {{< /note >}} + +* `template` 필드에는 다음 하위 필드가 포함되어있다. + * 파드는 `labels` 필드를 사용해서 `app: nginx` 이라는 레이블을 붙인다. + * 파드 템플릿의 사양 또는 `.template.spec` 필드는 + 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.7.9 버전 이미지를 실행하는 + `nginx` 컨테이너 1개를 실행하는 것을 나타낸다. + * 컨테이너 1개를 생성하고, `name` 필드를 사용해서 `nginx` 이름을 붙인다. + + 위의 디플로이먼트를 생성하려면 다음 단계를 따른다. + + 시작하기 전에, 쿠버네티스 클러스터가 시작되고 실행 중인지 확인한다. + + 1. 다음 명령어를 실행해서 디플로이먼트를 생성한다. + + {{< note >}} + `--record` 플래그를 지정해서 실행된 명령을 `kubernetes.io/change-cause` 리소스 어노테이션에 작성할 수 있다. 이것은 향후 인트로스펙션(introspection)에 유용하다. + 예를 들면, 디플로이먼트의 각 수정 버전에서 실행된 명령을 볼 수 있다. + {{< /note >}} + + ```shell + kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml + ``` + + 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. 만약 디플로이먼트가 여전히 생성중이면 다음과 유사하게 출력된다. + ```shell + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 0 0 0 1s + ``` + 클러스터에서 디플로이먼트를 점검할 때 다음 필드가 표시된다. + + * `NAME` 은 클러스터에 있는 디플로이먼트 이름의 목록이다. + * `DESIRED` 는 디플로이먼트의 생성시 정의된 의도한 애플리케이션 _레플리카_ 의 수를 표시한다. 이것이 _의도한 상태_ 이다. + * `CURRENT` 는 현재 실행 중인 레플리카의 수를 표시한다. + * `UP-TO-DATE` 는 의도한 상태를 얻기위해 업데이트 된 레플리카의 수를 표시한다. + * `AVAILABLE` 은 사용자가 사용 가능한 애플리케이션 레플리카의 수를 표시한다. + * `AGE` 는 애플리케이션의 실행 된 시간을 표시한다. + + `.spec.replicas` 필드에 따라 의도한 레플리카의 수가 3개인지 알 수 있다. + + 3. 디플로이먼트의 롤아웃 상태를 보려면 `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다. 다음과 유사하게 출력된다. + ```shell + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + deployment.apps/nginx-deployment successfully rolled out + ``` + + 4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다. 다음과 유사하게 출력된다. + ```shell + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 3 3 3 18s + ``` + 디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다. + + 5. 디플로이먼트로 생성된 레플리카셋(`rs`)을 보려면 `kubectl get rs` 를 실행한다. 다음과 유사하게 출력된다. + ```shell + NAME DESIRED CURRENT READY AGE + nginx-deployment-75675f5897 3 3 3 18s + ``` + 레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[RANDOM-STRING]` 형식으로 된 것을 알 수 있다. 무작위 문자열은 + 무작위로 생성되며, Pod-template-hash를 시드(seed)로 사용한다. + + 6. 각 파드에 자동으로 생성된 레이블을 보려면 `kubectl get pods --show-labels` 를 실행한다. 다음과 유사하게 출력된다. + ```shell + NAME READY STATUS RESTARTS AGE LABELS + nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + ``` + 만들어진 레플리카셋은 3개의 `nginx` 파드가 있는 것을 보장한다. + + {{< note >}} + 디플로이먼트에는 파드 템플릿 레이블과 적절한 셀렉터를 반드시 명시해야 한다(이 예시에서는 `app: nginx`). + 레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀 셋 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다. + {{< /note >}} + +### Pod-template-hash 레이블 + +{{< note >}} +이 레이블은 변경하면 안 된다. +{{< /note >}} + +`pod-template-hash` 레이블은 디플로이먼트 컨트롤러에 의해서 디플로이먼트가 생성 또는 채택한 모든 레플리케셋에 추가된다. + +이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 `PodTemplate` 을 해싱하고, 해시 결과를 레플리카셋 셀렉터, +파드 템플릿 레이블 및 레플리카셋 이 가질 수 있는 기존의 모든 파드에 레이블 값으로 추가해서 사용하도록 생성한다. + +## 디플로이먼트 업데이트 + +{{< note >}} +디플로이먼트의 파드 템플릿(즉, `.spec.template`)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다. +예를 들면 템플릿의 레이블이나 컨테이너 이미지가 업데이트된 경우이다. 디플로이먼트의 스케일링과 같은 다른 업데이트는 롤아웃을 트리거하지 말아야 한다. +{{< /note >}} + +다음 단계에 따라 디플로이먼트를 업데이트한다. + +1. nginx 파드를 이용 중인 `nginx:1.9.1` 이미지에서 `nginx:1.7.9` 로 업데이트 한다. + + ```shell + kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 + ``` + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment image updated + ``` + + 대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.7.9` 에서 `nginx:1.9.1` 로 변경한다. + + ```shell + kubectl edit deployment.v1.apps/nginx-deployment + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment edited + ``` + +2. 롤아웃 상태를 보려면 다음을 실행한다. + + ```shell + kubectl rollout status deployment.v1.apps/nginx-deployment + ``` + + 이와 유사하게 출력된다. + ``` + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + ``` + 또는 + ``` + deployment.apps/nginx-deployment successfully rolled out + ``` + +업데이트된 디플로이먼트에 대해 자세한 정보 보기 + +* 롤아웃이 성공하면 `kubectl get deployments` 를 실행해서 디플로이먼트를 볼 수 있다. + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 3 3 3 36s + ``` + +* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, +새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다. + + ```shell + kubectl get rs + ``` + + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 6s + nginx-deployment-2035384211 0 0 0 36s + ``` + +* `get pods` 를 실행하면 새 파드만 표시된다. + + ```shell + kubectl get pods + ``` + + 이와 유사하게 출력된다. + ``` + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-khku8 1/1 Running 0 14s + nginx-deployment-1564180365-nacti 1/1 Running 0 14s + nginx-deployment-1564180365-z9gth 1/1 Running 0 14s + ``` + + 다음에 이러한 파드를 업데이트 하려면 디플로이먼트의 파드 템플릿만 다시 업데이트 하면 된다. + + 디플로이먼트는 업데이트되는 동안 일정한 수의 파드만 중단되도록 보장한다. 기본적으로 + 적어도 의도한 파드 수의 25% 이상이 동작하도록 보장한다(최대 25% 이상 불가). + + 또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다. + 기본적으로, 의도한 파드의 수 기준 최대 25%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지). + + 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 + 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, + 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. + 이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. + +* 디플로이먼트의 세부 정보 가져오기 + ```shell + kubectl describe deployments + ``` + 이와 유사하게 출력된다. + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=2 + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3 + Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1 + Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2 + Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2 + Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1 + Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 + Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 + ``` + 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 + 3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. + 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 + 이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다. + 이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. + 마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다. + +### 롤오버(일명 인-플라이트 다중 업데이트) + +디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 +의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 +`.spec.selector` 레이블과 일치하는 파드를 컨트롤 하지만, 템플릿과 `.spec.template` 이 불일치하면 스케일 다운이 된다. +결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카 셋은 0개로 스케일된다. + +만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고, +스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다. + --이것은 기존 레플리카셋 목록에 추가하고 스케일 다운을 할 것이다. + +예를 들어 디플로이먼트로 `nginx:1.7.9` 레플리카를 5개 생성을 한다. +하지만 `nginx:1.7.9` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.9.1` +레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의 +`nginx:1.7.9` 파드 3개를 죽이기 시작하고 `nginx:1.9.1` 파드를 생성하기 시작한다. +이것은 과정이 변경되기 전 `nginx:1.7.9` 레플리카 5개가 +생성되는 것을 기다리지 않는다. + +### 레이블 셀렉터 업데이트 + +일반적으로 레이블 셀렉터를 업데이트 하는 것을 권장하지 않으며 셀렉터를 미리 계획하는 것을 권장한다. +어떤 경우든 레이블 셀렉터의 업데이트를 해야하는 경우 매우 주의하고, +모든 영향을 파악했는지 확인해야 한다. + +{{< note >}} +API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이후에는 변경할 수 없다. +{{< /note >}} + +* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다. +그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가 +이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며, +새로운 레플리카셋을 생성하게 된다. +* 셀렉터 업데이트는 기존 셀렉터 키 값을 변경하며, 결과적으로 추가와 동일한 동작을 한다. +* 셀렉터 삭제는 디플로이먼트 셀렉터의 기존 키를 삭제하며 파드 템플릿 레이블의 변경을 필요로 하지 않는다. +기존 레플리카셋은 고아가 아니고, 새 레플리카셋은 생성되지 않는다. +그러나 제거된 레이블은 기존 파드와 레플리카셋에 여전히 존재한다는 점을 참고해야 한다. + +## 디플로이먼트 롤백 + +때때로 디플로이먼트의 롤백을 원할 수도 있다. 예를 들어 디플로이먼트가 지속적인 충돌로 안정적이지 않은 경우. +기본적으로 모든 디플로이먼트의 롤아웃 기록은 시스템에 남아있어 언제든지 원할 때 롤백이 가능하다 +(이 사항은 수정 기록에 대한 상한 수정을 통해서 변경할 수 있다). + +{{< note >}} +디플로이먼트의 수정 버전은 디플로이먼트 롤아웃시 생성된다. 이는 디플로이먼트 파드 템플릿 +(`.spec.template`)이 변경되는 경우에만 새로운 수정 버전이 생성된다는 것을 의미한다. +예를 들어 템플릿의 레이블 또는 컨테이너 이미지를 업데이트 하는 경우. +디플로이먼트의 스케일링과 같은 다른 업데이트시 디플로이먼트 수정 버전은 생성되지 않으며 수동-스케일링 또는 자동-스케일링을 동시에 수행할 수 있다. +이는 이전 수정 버전으로 롤백을 하는 경우에 디플로이먼트 파드 템플릿 부분만 +롤백된다는 것을 의미한다. +{{< /note >}} + +* 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.9.1` 이 아닌 `nginx:1.91` 로 입력해서 오타를 냈다고 가정한다. + + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment image updated + ``` + +* 롤아웃이 고착 된다. 고착된 롤아웃 상태를 확인할 수 있다. + + + ```shell + kubectl rollout status deployment.v1.apps/nginx-deployment + ``` + + 이와 유사하게 출력된다. + ``` + Waiting for rollout to finish: 1 out of 3 new replicas have been updated... + ``` + +* Ctrl-C 를 눌러 위의 롤아웃 상태 보기를 중지한다. 고착된 롤아웃 상태에 대한 자세한 정보는 [이 것을 더 읽어본다](#디플로이먼트-상태). + +* 이전 레플리카는 2개(`nginx-deployment-1564180365` 과 `nginx-deployment-2035384211`), 새 레플리카는 1개(nginx-deployment-3066724191)임을 알 수 있다. + + ```shell + kubectl get rs + ``` + + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 25s + nginx-deployment-2035384211 0 0 0 36s + nginx-deployment-3066724191 1 1 0 6s + ``` + +* 생성된 파드를 보면, 새로운 레플리카셋에 생성된 1개의 파드가 이미지 풀 루프(pull loop)에서 고착된 것을 볼 수 있다. + + ```shell + kubectl get pods + ``` + + 이와 유사하게 출력된다. + ``` + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-70iae 1/1 Running 0 25s + nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s + nginx-deployment-1564180365-hysrc 1/1 Running 0 25s + nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s + ``` + + {{< note >}} + 디플로이먼트 컨트롤러가 잘못된 롤아웃을 자동으로 중지하고, 새로운 레플리카셋의 스케일 업을 중지한다. + 이는 지정한 롤링 업데이트의 파라미터(구체적으로 `maxUnavailable`)에 따라 달라진다. + 쿠버네티스는 기본값으로 25%를 설정한다. + {{< /note >}} + +* 디플로이먼트에 대한 설명 보기 + ```shell + kubectl describe deployment + ``` + + 이와 유사하게 출력된다. + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 + Labels: app=nginx + Selector: app=nginx + Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.91 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) + NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) + Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 + ``` + + 이 문제를 해결하려면 디플로이먼트를 안정적인 이전 수정 버전으로 롤백해야 한다. + +### 디플로이먼트의 롤아웃 기록 확인 + +다음 순서에 따라 롤아웃 기록을 확인한다. + +1. 먼저 이 디플로이먼트의 수정 사항을 확인한다. + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment + ``` + 이와 유사하게 출력된다. + ``` + deployments "nginx-deployment" + REVISION CHANGE-CAUSE + 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true + 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true + ``` + + `CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다. + + * 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` 로 주석을 단다. + * `kubectl` 명령어 이용시 `--record` 플래그를 추가해서 리소스 변경을 저장한다. + * 수동으로 리소스 매니페스트 편집. + +2. 각 수정 버전의 세부 정보를 보려면 다음을 실행한다. + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 + ``` + + 이와 유사하게 출력된다. + ``` + deployments "nginx-deployment" revision 2 + Labels: app=nginx + pod-template-hash=1159050644 + Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + QoS Tier: + cpu: BestEffort + memory: BestEffort + Environment Variables: + No volumes. + ``` + +### 이전 수정 버전으로 롤백 +다음 단계에 따라 디플로이먼트를 현재 버전에서 이전 버전인 버전 2로 롤백한다. + +1. 이제 현재 롤아웃의 실행 취소 및 이전 수정 버전으로 롤백 하기로 결정했다. + ```shell + kubectl rollout undo deployment.v1.apps/nginx-deployment + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment + ``` + Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`: + + ```shell + kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment + ``` + + 롤아웃 관련 명령에 대한 자세한 내용은 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)을 참조한다. + + 이제 디플로이먼트가 이전 안정 수정 버전으로 롤백 된다. 버전 2로 롤백하기 위해 `DeploymentRollback` 이벤트가 + 디플로이먼트 컨트롤러에서 생성되는 것을 볼 수 있다. + +2. 만약 롤백에 성공하고, 디플로이먼트가 예상대로 실행되는지 확인하려면 다음을 실행한다. + ```shell + kubectl get deployment nginx-deployment + ``` + + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 3 3 3 30m + ``` +3. 디플로이먼트의 설명 가져오기. + ```shell + kubectl describe deployment nginx-deployment + ``` + 이와 유사하게 출력된다. + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=4 + kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 + Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 + Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0 + ``` + +## 디플로이먼트 스케일링 + +다음 명령어를 사용해서 디플로이먼트의 스케일을 할 수 있다. + +```shell +kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 +``` +이와 유사하게 출력된다. +``` +deployment.apps/nginx-deployment scaled +``` + +가령 클러스터에서 [horizontal Pod autoscaling](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 설정 +한 경우 디플로이먼트에 대한 오토스케일러를 설정할 수 있다. 그리고 기존 파드의 CPU 사용률을 기준으로 +실행할 최소 파드 및 최대 파드의 수를 선택할 수 있다. + +```shell +kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 +``` +이와 유사하게 출력된다. +``` +deployment.apps/nginx-deployment scaled +``` + +### 비례적 스케일링(Proportional Scaling) + +디플로이먼트 롤링업데이트는 여러 버전의 애플리케이션을 동시에 실행할 수 있도록 지원한다. +사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우(진행중 또는 일시 중지 중), +디플로이먼트 컨트롤러는 위험을 줄이기 위해 기존 활성화된 레플리카셋(파드와 레플리카셋)의 추가 레플리카의 균형을 조절 한다. +이것을 *proportional scaling* 라 부른다. + +예를 들어, 10개의 레플리카를 디플로이먼트로 [maxSurge](#최대-서지-max-surge)=3, 그리고 [maxUnavailable](#최대-불가-max-unavailable)=2 로 실행 한다. + +* 디플로이먼트에 있는 10개의 레플리카가 실행되는지 확인한다. + ```shell + kubectl get deploy + ``` + 이와 유사하게 출력된다. + + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 10 10 10 10 50s + ``` + +* 클러스터 내부에서 확인할 수 없는 새 이미지로 업데이트 된다. + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment image updated + ``` + +* 이미지 업데이트는 레플리카셋 nginx-deployment-1989198191 으로 새로운 롤 아웃이 시작하지만, +위에서 언급한 `maxUnavailable` 의 요구 사항으로 인해 차단된다. 롤아웃 상태를 확인한다. + ```shell + kubectl get rs + ``` + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1989198191 5 5 0 9s + nginx-deployment-618515232 8 8 8 1m + ``` + +* 그 다음 디플로이먼트에 대한 새로운 스케일링 요청이 함께 따라온다. 오토스케일러는 디플로이먼트 레플리카를 15로 증가시킨다. +디플로이먼트 컨트롤러는 새로운 5개의 레플리카의 추가를 위한 위치를 결정해야 한다. +만약 비례적 스케일링을 사용하지 않으면 5개 모두 새 레플리카셋에 추가된다. +비례적 스케일링으로 추가 레플리카를 모든 레플리카셋에 걸쳐 분산할 수 있다. +비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카 셋으로 이동한다. +남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가된다. 0개의 레플리카가 있는 레플리카셋은 스케일 업 되지 않는다. + +위의 예시에서 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다. +결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다. +이를 확인하려면 다음을 실행한다. + +```shell +kubectl get deploy +``` + +이와 유사하게 출력된다. +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 15 18 7 8 7m +``` +롤아웃 상태는 레플리카가 각 레플리카셋에 어떻게 추가되었는지 확인한다. +```shell +kubectl get rs +``` + +이와 유사하게 출력된다. +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 7 7 0 7m +nginx-deployment-618515232 11 11 11 7m +``` + +## 디플로이먼트의 일시 중지와 재개 + +하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다. +이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다. + +* 예를 들어, 방금 생성된 디플로이먼트의 경우 + 디플로이먼트 상세 정보를 가져온다. + ```shell + kubectl get deploy + ``` + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx 3 3 3 3 1m + ``` + 롤아웃 상태를 가져온다. + ```shell + kubectl get rs + ``` + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 1m + ``` + +* 다음 명령을 사용해서 일시 중지한다. + ```shell + kubectl rollout pause deployment.v1.apps/nginx-deployment + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment paused + ``` + +* 그런 다음 디플로이먼트의 이미지를 업데이트 한다. + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment image updated + ``` + +* 새로운 롤아웃이 시작되지 않는다. + ```shell + kubectl rollout history deployment.v1.apps/nginx-deployment + ``` + + 이와 유사하게 출력된다. + ``` + deployments "nginx" + REVISION CHANGE-CAUSE + 1 + ``` +* 롤아웃 상태를 가져와서 디플로이먼트 업데이트가 성공적인지 확인한다. + ```shell + kubectl get rs + ``` + + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 2m + ``` + +* 예를 들어 사용할 리소스를 업데이트하는 것처럼 원하는 만큼 업데이트할 수 있다. + ```shell + kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment resource requirements updated + ``` + + 디플로이먼트를 일시 중지하기 전의 초기 상태는 해당 기능을 지속한다. + 그러나 디플로이먼트가 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다. + +* 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다. + ```shell + kubectl rollout resume deployment.v1.apps/nginx-deployment + ``` + + 이와 유사하게 출력된다. + ``` + deployment.apps/nginx-deployment resumed + ``` +* 롤아웃이 완료될 때까지 상태를 관찰한다. + ```shell + kubectl get rs -w + ``` + + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 2 2 2 2m + nginx-3926361531 2 2 0 6s + nginx-3926361531 2 2 1 18s + nginx-2142116321 1 2 2 2m + nginx-2142116321 1 2 2 2m + nginx-3926361531 3 2 1 18s + nginx-3926361531 3 2 1 18s + nginx-2142116321 1 1 1 2m + nginx-3926361531 3 3 1 18s + nginx-3926361531 3 3 2 19s + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 20s + ``` +* 롤아웃 최신 상태를 가져온다. + ```shell + kubectl get rs + ``` + + 이와 유사하게 출력된다. + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 28s + ``` +{{< note >}} +일시 중지된 디플로이먼트를 재개할 때까지 롤백할 수 없다. +{{< /note >}} + +## 디플로이먼트 상태 + +디플로이먼트는 라이프사이클 동안 다양한 상태로 전환된다. +이는 새 레플리카셋을 롤아웃하는 동안 [진행 중](#디플로이먼트-진행-중)이 될 수 있고, [완료](#디플로이먼트-완료)이거나 [진행 실패](#디플로이먼트-실패)일 수 있다. + +### 디플로이먼트 진행 중 + +쿠버네티스는 다음 작업중 하나를 수행할 때 디플로이먼트를 _진행 중_ 으로 표시한다. + +* 디플로이먼트로 새 레플리카셋을 생성. +* 디플로이먼트로 새로운 레플리카셋을 스케일 업. +* 디플로이먼트로 기존 레플리카셋을 스케일 다운. +* 새 파드가 준비되거나 이용할 수 있음(최소 [준비 시간(초)](#최소-대기-시간-초) 동안 준비됨). + +`kubectl rollout status` 를 사용해서 디플로이먼트의 진행사황을 모니터할 수 있다. + +### 디플로이먼트 완료 + +쿠버네티스는 다음과 같은 특성을 가지게 되면 디플로이먼트를 _완료_ 로 표시한다. + +* 디플로이먼트과 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되었을 때. +즉, 요청한 모든 업데이트가 완료되었을 때. +* 디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때. +* 디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때. + +`kubectl rollout status` 를 사용해서 디플로이먼트가 완료되었는지 확인할 수 있다. +만약 롤아웃이 성공적으로 완료되면 `kubectl rollout status` 는 종료 코드로 0이 반환된다. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +이와 유사하게 출력된다. +``` +Waiting for rollout to finish: 2 of 3 updated replicas are available... +deployment.apps/nginx-deployment successfully rolled out +$ echo $? +0 +``` + +### 디플로이먼트 실패 + +디플로이먼트시 새 레플리카셋인 완료되지 않은 상태에서는 배포를 시도하면 고착될 수 있다. +이 문제는 다음 몇 가지 요인으로 인해 발생한다. + +* 할당량 부족 +* 준비성 프로브(readiness probe)의 실패 +* 이미지 풀 에러 +* 권한 부족 +* 범위 제한 +* 애플리케이션 런타임의 잘못된 구성 + +이 조건을 찾을 수 있는 한 가지 방법은 디플로이먼트 스펙에서 데드라인 파라미터를 지정하는 것이다 +([`.spec.progressDeadlineSeconds`](#진행-기한-시간-초)). `.spec.progressDeadlineSeconds` 는 +(디플로이먼트 상태에서) 디플로이먼트의 진행이 정지되었음을 나타내는 디플로이먼트 컨트롤러가 +대기하는 시간(초)를 나타낸다. + +다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가 +10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다. + +```shell +kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +``` +이와 유사하게 출력된다. +``` +deployment.apps/nginx-deployment patched +``` +만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의 +디플로이먼트 컨디션(DeploymentCondition)을 추가한다. + +* Type=Progressing +* Status=False +* Reason=ProgressDeadlineExceeded + +컨디션 상태에 대한 자세한 내용은 [쿠버네티스 API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)을 참고한다. + +{{< note >}} +쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을 +보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며, +예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다. +{{< /note >}} + +{{< note >}} +만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다. +롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고 +재개할 수 있다. +{{< /note >}} + +설정한 타임아웃이 낮거나 일시적으로 처리될 수 있는 다른 종료의 에러로 인해 디플로이먼트에 일시적인 에러가 발생할 수 있다. +예를 들어, 할당량이 부족하다고 가정해보자. +만약 디플로이먼트를 설명하려면 다음 섹션을 확인한다. + +```shell +kubectl describe deployment nginx-deployment +``` +이와 유사하게 출력된다. +``` +<...> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + ReplicaFailure True FailedCreate +<...> +``` + +만약 `kubectl get deployment nginx-deployment -o yaml` 을 실행하면 디플로이먼트 상태는 다음과 유사하다. + +``` +status: + availableReplicas: 2 + conditions: + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: Replica set "nginx-deployment-4262182780" is progressing. + reason: ReplicaSetUpdated + status: "True" + type: Progressing + - lastTransitionTime: 2016-10-04T12:25:42Z + lastUpdateTime: 2016-10-04T12:25:42Z + message: Deployment has minimum availability. + reason: MinimumReplicasAvailable + status: "True" + type: Available + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: + object-counts, requested: pods=1, used: pods=3, limited: pods=2' + reason: FailedCreate + status: "True" + type: ReplicaFailure + observedGeneration: 3 + replicas: 2 + unavailableReplicas: 2 +``` + +결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 +상태와 이유를 업데이트한다. + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing False ProgressDeadlineExceeded + ReplicaFailure True FailedCreate +``` + +디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나, +네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다. +만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면 +성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`Status=True` 와 `Reason=NewReplicaSetAvailable`). + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +``` + +`Type=Available` 과 `Status=True` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다. +최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가 +롤아웃 도중에 진행 중 이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것이다. +(자세한 내용은 특정 조건의 이유를 참조한다. +이 경우 `Reason=NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.) + +`kubectl rollout status` 를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다. +`kubectl rollout status` 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +이와 유사하게 출력된다. +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +error: deployment "nginx" exceeded its progress deadline +$ echo $? +1 +``` + +### 실패한 디플로이먼트에서의 운영 + +완료된 디플로이먼트에 적용되는 모든 행동은 실패한 디플로이먼트에도 적용된다. +디플로이먼트 파드 템플릿에서 여러개의 수정사항을 적용해야하는 경우 스케일 업/다운 하거나, 이전 수정 버전으로 롤백하거나, 일시 중지할 수 있다. + +## 정책 초기화 + +디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서 +디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다. +기본적으로 10으로 되어있다. + +{{< note >}} +명시적으로 이 필드를 0으로 설정하면 그 결과로 디플로이먼트의 기록을 전부 초기화를 하고, +디플로이먼트는 롤백할 수 없게 된다. +{{< /note >}} + +## 카나리 디플로이먼트 + +만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 +[리소스 관리](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)에 +설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다. + +## 디플로이먼트 사양 작성 + +다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. +설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. + +디플로이먼트에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. + +### 파드 템플릿 + +`.spec.template` 과 `.spec.selector` 은 `.spec` 에서 유일한 필수 필드이다. + +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. +이것은 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다. + +파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다. +레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다. + +[`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고, +명시되지 않으면 기본값이 된다. + +### 레플리카 + +`.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 이것의 기본값은 1이다. + +### 셀렉터 + +`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 +지정하는 필수 필드이다. + +`.spec.selector` 는 `.spec.template.metadata.labels` 과 일치해야 하며, 그렇지 않으면 API에 의해 거부된다. + +API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설정되지 않으면 `.spec.template.metadata.labels` 은 기본 설정되지 않는다. 그래서 이것들은 명시적으로 설정되어야 한다. 또한 `apps/v1` 에서는 디플로이먼트를 생성한 후에는 `.spec.selector` 이 변경되지 않는 점을 참고한다. + + +디플로이먼트는 템플릿의 `.spec.template` 와 다르거나 파드의 수가 `.spec.replicas` 를 초과할 경우 +셀렉터와 일치하는 레이블을 가진 파드를 종료할 수 있다. +파드의 수가 의도한 수량보다 적을 경우 `.spec.template` 에 맞는 새 파드를 띄운다. + +{{< note >}} +다른 디플로이먼트를 생성하거나, 레플리카셋 또는 레플리케이션컨트롤러와 같은 다른 컨트롤러를 사용해서 직접적으로 레이블과 셀렉터가 일치하는 다른 파드를 생성하지 말아야 한다. +만약 이렇게 하면 첫 번째 디플로이먼트는 다른 파드를 만들었다고 생각한다. +쿠버네티스는 이 일을 막지 않는다. +{{< /note >}} + +만약 셀렉터가 겹치는 컨트롤러가 어러 개 있는 경우, 컨트롤러는 서로 싸우고 +올바르게 작동하지 않는다. + +### 전략 + +`.spec.strategy` 는 이전 파드를 새로운 파드로 대체하는 전략을 명시한다. +`.spec.strategy.type` 은 "재생성" 또는 "롤링업데이트"가 될 수 있다. +"롤링업데이트"가 기본값이다. + +#### 디플로이먼트 재생성 + +기존의 모든 파드는 `.spec.strategy.type==Recreate` 이면 새 파드가 생성되기 전에 죽는다. + +#### 디플로이먼트 롤링 업데이트 + +디플로이먼트는 `.spec.strategy.type==RollingUpdate` 이면 파드를 [롤링 업데이트](/docs/tasks/run-application/rolling-update-replication-controller/) +방식으로 업데이트 한다. `maxUnavailable` 와 `maxSurge` 를 명시해서 +롤링 업데이트 프로세스를 제어할 수 있다. + +##### 최대 불가(Max Unavailable) + +`.spec.strategy.rollingUpdate.maxUnavailable` 은 업데이트 프로세스 중에 사용할 수 없는 최대 파드의 수를 지정하는 선택적 필드이다. +이 값은 절대 숫자(예: 5) 또는 의도한 파드 비율(예: 10%)이 될 수 있다. +절대 값은 반올림해서 백분율로 계산한다. +만약 `.spec.strategy.rollingUpdate.maxSurge` 가 0면 값이 0이 될 수 없다. 기본 값은 25% 이다. + +예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를 +의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, +업데이트 중에 항상 사용가능한 전체 파드의 수는 의도한 파드의 수의 70%이상이 되도록 새 레플리카셋을 스케일을 업 할수 있다. + +##### 최대 서지(Max Surge) + +`.spec.strategy.rollingUpdate.maxSurge` 는 의도한 파드의 수에 대해 생성할 수 있는 최대 파드의 수를 지정하는 선택적 필드이다. +이 값은 절대 숫자(예: 5) 또는 의도한 파드 비율(예: 10%)이 될 수 있다. +`MaxUnavailable` 값이 0이면 이 값은 0이 될 수 없다. +절대 값은 반올림해서 백분율로 계산한다. 기본 값은 25% 이다. + +예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서 +기존 및 새 파드의 전체 갯수를 의도한 파드의 130%를 넘지 않도록 한다. +기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며, +업데이트하는 동안 항상 실행하는 총 파드의 수는 최대 의도한 파드의 수의 130%가 되도록 보장한다. + +### 진행 기한 시간(초) + +`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의 +상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에 +디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다. +디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. +미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고, +그 즉시 디플로이먼트를 롤백할 것이다. + +만약 명시된다면 이 필드는 `.spec.minReadySeconds` 보다 커야 한다. + +### 최소 대기 시간(초) + +`.spec.minReadySeconds` 는 새롭게 생성된 파드의 컨테이너가 어떤 것과도 충돌하지 않고 사 +용할 수 있도록 준비되어야 하는 최소 시간(초)을 지정하는 선택적 필드이다. +이 기본 값은 0이다(파드는 준비되는 즉시 사용할 수 있는 것으로 간주됨). +파드가 준비되었다고 간주되는 시기에 대한 자세한 내용은 [컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참조한다. + +### 롤백 대상 + +`.spec.rollbackTo` 필드는 API 버전 `extensions/v1beta1` 과 `apps/v1beta1` 에서 사용되지 않는다. `apps/v1beta2` 로 시작하는 API 버전에서는 더 이상 지원되지 않는다. 대신, [이전 수정 버전으로 롤백](#이전-수정-버전으로-롤백)에서 소개한 `kubectl rollout undo` 를 사용해야 한다. + +### 수정 버전 기록 제한 + +디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다. + +`.spec.revisionHistoryLimit` 은 롤백을 허용하기 위해 보존할 이전 레플리카셋의 수를 지정하는 선택적 필드이다. +이 이전 레플리카셋은 `etcd` 의 리소스를 소비하고, `kubectl get rs` 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다. + +더욱 구체적으로 이 필드를 0으로 설정하면 레플리카가 0이 되며 이전 레플리카셋이 정리된다. +이 경우, 새로운 디플로이먼트 롤아웃을 취소할 수 없다. 새로운 디플로이먼트 롤아웃은 수정 버전 이력이 정리되기 때문이다. + +### 일시 정지 + +`.spec.paused` 는 디플로이먼트를 일시 중지나 재개하기 위한 선택적 부울 필드이다. +일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은 +일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다. +디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다. + +## 디플로이먼트의 대안 + +### kubectl 롤링 업데이트 + +[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)도 +비슷한 방식으로 파드와 레플리케이션 컨트롤러를 업데이트한다. 그러나 디플로이먼트는 선언적이고, 서버 측면이며, +롤링 업데이트가 완료된 후에도 이전 수정 버전으로 롤백하는 것과 같은 추가 기능을 가지고 있으므로 권장한다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md new file mode 100644 index 0000000000..545d4a2a11 --- /dev/null +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -0,0 +1,351 @@ +--- +title: 레플리카셋 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다. +이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다. + + +{{% /capture %}} + +{{% capture body %}} + +## 레플리카셋의 작동 방식 + +레플리카셋을 정의하는 필드는 획득 가능한 파드를 식별하는 방법이 명시된 셀렉터, 유지해야 하는 파드 개수를 명시하는 레플리카의 개수, +그리고 레플리카 수 유지를 위해 생성하는 신규 파드에 대한 데이터를 명시하는 파드 템플릿을 포함한다. +그러면 레플리카셋은 필드에 지정된 설정을 충족하기 위해 필요한 만큼 파드를 만들고 삭제한다. +레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을 +사용한다. + +레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents) +필드를 통해서 제공되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다. +레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다. +이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다. + +레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에 OwnerReference이 없거나 +OwnerReference가 컨트롤러가 아니고 레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를 +가지게 될 것이다. + +## 레플리카셋을 사용하는 시기 + +레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다. +그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께 +파드에 대한 선언적 업데이트를 제공하는 상위 개념이다. +따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면 +레플리카셋을 직접적으로 사용하기 보다는 디플로이먼트를 사용하는 것을 권장한다. + +이는 레플리카셋 오브젝트를 직접 조작할 필요가 없다는 것을 의미한다. +대신 디플로이먼트를 이용하고 사양 부분에서 애플리케이션을 정의하면 된다. + +## 예시 + +{{< codenew file="controllers/frontend.yaml" >}} + +이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어있는 레플리카셋이 +생성되고 레플리카셋이 관리하는 파드가 생성된다. + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml +``` + +현재 배포된 레플리카셋을 확인할 수 있다. +```shell +kubectl get rs +``` + +그리고 생성된 프런트엔드를 볼 수 있다. +```shell +NAME DESIRED CURRENT READY AGE +frontend 3 3 3 6s +``` + +또한 레플리카셋의 상태를 확인할 수 있다. +```shell +kubectl describe rs/frontend +``` + +출력은 다음과 유사할 것이다. +```shell +Name: frontend +Namespace: default +Selector: tier=frontend,tier in (frontend) +Labels: app=guestbook + tier=frontend +Annotations: +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: app=guestbook + tier=frontend + Containers: + php-redis: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: 80/TCP + Requests: + cpu: 100m + memory: 100Mi + Environment: + GET_HOSTS_FROM: dns + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l +``` + +마지막으로 파드가 올라왔는지 확인할 수 있다. +```shell +kubectl get Pods +``` + +다음과 유사한 파드 정보를 볼 수 있다. +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +``` + +또한 파드들의 소유자 참조 정보가 해당 프런트엔드 레플리카셋으로 설정되어 있는지 확인할 수 있다. +확인을 위해서는 실행 중인 파드 중 하나의 yaml을 확인한다. +```shell +kubectl get pods frontend-9si5l -o yaml +``` + +메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다. +```shell +apiVersion: v1 +kind: Pod +metadata: + creationTimestamp: 2019-01-31T17:20:41Z + generateName: frontend- + labels: + tier: frontend + name: frontend-9si5l + namespace: default + ownerReferences: + - apiVersion: extensions/v1beta1 + blockOwnerDeletion: true + controller: true + kind: ReplicaSet + name: frontend + uid: 892a2330-257c-11e9-aecd-025000000001 +... +``` + +## 템플릿을 사용하지 않는 파드의 획득 + +단독(bare) 파드를 생성하는 것에는 문제가 없지만, 단독 파드가 레플리카셋의 셀렉터와 일치하는 레이블을 가지지 +않도록 하는 것을 강력하게 권장한다. 그 이유는 레플리카셋이 소유하는 파드가 템플릿에 명시된 파드에만 국한되지 않고, +이전 섹션에서 명시된 방식에 의해서도 다른 파드의 획득이 가능하기 때문이다. + +이전 프런트엔드 레플리카셋 예제와 다음의 매니페스트에 명시된 파드를 가져와 참조한다. + +{{< codenew file="pods/pod-rs.yaml" >}} + +기본 파드는 소유자 관련 정보에 컨트롤러(또는 오브젝트)를 가지지 않기 때문에 프런트엔드 +레플리카셋의 셀렉터와 일치하면 즉시 레플리카셋에 소유된다. + +프런트엔드 레플리카셋이 배치되고 초기 파드 레플리카가 셋업된 이후에, 레플리카 수 요구 사항을 충족시키기 위해서 +신규 파드를 생성한다고 가정해보자. + +```shell +kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml +``` + +새로운 파드는 레플리카셋에 의해 인식되며 레플리카셋이 필요한 수량을 초과하면 +즉시 종료된다. + +파드를 가져온다. +```shell +kubectl get Pods +``` + +결과에는 새로운 파드가 이미 종료되었거나 종료가 진행 중인 것을 보여준다. +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +pod2 0/1 Terminating 0 4s +``` + +파드를 먼저 생성한다. +```shell +kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml +``` + +그 다음 레플리카셋을 생성한다. +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml +``` + +레플리카셋이 해당 파드를 소유한 것을 볼 수 있으며 새 파드 및 기존 파드의 수가 +레플리카셋이 필요로 하는 수와 일치할 때까지 사양에 따라 신규 파드만 생성한다. 파드를 가져온다. +```shell +kubectl get Pods +``` + +다음 출력에서 볼 수 있다. +```shell +NAME READY STATUS RESTARTS AGE +frontend-pxj4r 1/1 Running 0 5s +pod1 1/1 Running 0 13s +pod2 1/1 Running 0 13s +``` + +이러한 방식으로 레플리카셋은 템플릿을 사용하지 않는 파드를 소유하게 된다. + +## 레플리카셋 매니페스트 작성하기 + +레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다. +레플리카셋에 대한 kind 필드의 값은 항상 레플리카셋이다. +쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다. +API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다. + +레플리카셋도 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)이 필요하다. + +### 파드 템플릿 + +`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. +우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다. +이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다. + +템플릿의 [재시작 정책](ko/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) 필드인 +`.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다. + +### 파드 셀렉터 + +`.spec.selector` 필드는 [레이블 셀렉터](ko/docs/concepts/overview/working-with-objects/labels/)이다. +[앞서](#레플리카-셋의-작동-방식) 논의한 것처럼 이 레이블은 소유될 가능성이 있는 파드를 식별하는데 사용된다. +우리 `frontend.yaml` 예제에서의 셀렉터는 다음과 같다. +```shell +matchLabels: + tier: frontend +``` + +레플리카셋에서 `.spec.template.metadata.labels`는 `spec.selector`과 일치해야 하며 +그렇지 않으면 API에 의해 거부된다. + +{{< note >}} +2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카 셋은 다른 레플리카 셋이 생성한 파드를 무시한다. +{{< /note >}} + +### 레플리카 + +`.spec.replicas`를 설정해서 동시에 동작하는 파드의 수를 지정할 수 있다. +레플리카셋은 파드의 수가 일치하도록 생성 및 삭제한다. + +만약 `.spec.replicas`를 지정하지 않으면 기본값은 1이다. + +## 레플리카셋 작업 + +### 레플리카셋과 해당 파드 삭제 + +레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다. + +REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로 +설정해야 한다. +예시: +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +> -H "Content-Type: application/json" +``` + +### 레플리카셋만 삭제하기 + +레플리카셋을 `--cascade=false` 옵션과 함께 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다. +REST API 또는 `client-go` 라이브러리를 이용할 때는 `propagationPolicy`에 `Orphan`을 설정해야 한다. +예시: +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +> -H "Content-Type: application/json" +``` + +원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다. +기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다. +하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다. +컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment)를 이용하면 된다. +이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다. + +### 레플리카셋에서 파드 격리 + +레이블을 변경하면 레플리카셋에서 파드를 제거할 수 있다. 이 방식은 디버깅과 데이터 복구 등을 +위해 서비스에서 파드를 제거하는 데 사용할 수 있다. 이 방식으로 제거된 파드는 자동으로 교체된다( +레플리카의 수가 변경되지 않는다고 가정한다). + +### 레플리카셋의 스케일링 + +레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 `.spec.replicas` 필드를 업데이트 하면 된다. +레플리카셋 컨트롤러는 일치하는 레이블 셀렉터가 있는 파드가 의도한 수 만큼 가용하고 운영 가능하도록 보장한다. + +### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정 + +레플리카 셋은 +[Horizontal Pod Autoscalers (HPA)](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)의 대상이 될 수 있다. +즉, 레플리카셋은 HPA에 의해 오토스케일될 수 있다. +다음은 이전에 만든 예시에서 만든 레플리카셋을 대상으로 하는 HPA 예시이다. + +{{< codenew file="controllers/hpa-rs.yaml" >}} + +이 매니페스트를 `hpa-rs.yaml`로 저장한 다음 쿠버네티스 +클러스터에 적용하면 CPU 사용량에 따라 파드가 복제되는 +오토스케일 레플리카 셋 HPA가 생성된다. + +```shell +kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml +``` + +또는 `kubectl autoscale` 커맨드을 사용해서 동일한 작업을 할 수 있다. +(그리고 더 쉽다!) + +```shell +kubectl autoscale rs frontend --max=10 +``` + +## 레플리카셋의 대안 + +### 디플로이먼트(권장) + +[`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/)는 레플리카셋을 소유하거나 업데이트를 하고, +파드의 선언적인 업데이트와 서버측 롤링 업데이트를 할 수 있는 오브젝트이다. +레플리카셋은 단독으로 사용할 수 있지만, 오늘날에는 주로 디플로이먼트로 파드의 생성과 삭제 그리고 업데이트를 오케스트레이션하는 메커니즘으로 사용한다. +디플로이먼트를 이용해서 배포할 때 생성되는 레플리카셋을 관리하는 것에 대해 걱정하지 않아도 된다. +디플로이먼트는 레플리카셋을 소유하거나 관리한다. +따라서 레플리카셋을 원한다면 디플로이먼트를 사용하는 것을 권장한다. + +### 기본 파드 + +사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는 노드의 커널 업그레이드와 같은 관리 목적의 중단 등 어떤 이유로든 종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도 레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면, 레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다. 레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 어떤 에이전트에게 위임한다(예를들어 Kubelet 또는 도커). + +### 잡 + +스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 이용한다 +(즉, 배치 잡). + +### 데몬셋 + +머신 모니터링 또는 머신 로깅과 같은 머신-레벨의 기능을 제공하는 파드를 위해서는 레플리카셋 대신 +[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용한다. +이러한 파드의 수명은 머신의 수명과 연관되어 있고, 머신에서 다른 파드가 시작하기 전에 실행되어야 하며, +머신의 재부팅/종료가 준비되었을 때, 해당 파드를 종료하는 것이 안전하다. + +### 레플리케이션 컨트롤러 +레플리카셋은 [_레플리케이션 컨트롤러_](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 계승하였다. +이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/docs/concepts/overview/working-with-objects/labels/#label-selectors)에 +설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다. +따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md new file mode 100644 index 0000000000..3f0947d5ae --- /dev/null +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -0,0 +1,252 @@ +--- +title: 중단(disruption) +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} +이 가이드는 고가용성 애플리케이션을 구성하려는 소유자와 +파드에서 발생하는 장애 유형을 이해하기 +원하는 애플리케이션 소유자를 위한 것이다. + +또한 클러스터의 업그레이드와 오토스케일링과 같은 +클러스터의 자동화 작업을 하려는 관리자를 위한 것이다. + +{{% /capture %}} + + +{{% capture body %}} + +## 자발적 중단과 비자발적 중단 + +파드는 누군가(사람 또는 컨트롤러)가 파괴하거나 +불가피한 하드웨어 오류 또는 시스템 소프트웨어 오류가 아니면 사라지지 않는다. + +우리는 이런 불가피한 상황을 애플리케이션의 *비자발적 중단* 으로 부른다. +예시: + +- 노드를 지원하는 물리 머신의 하드웨어 오류 +- 클러스터 관리자의 실수로 VM(인스턴스) 삭제 +- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애 +- 커널 패닉 +- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐 +- 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨 + +리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다. +왜냐하면 그 조건은 쿠버네티스에 국한되지 않기 때문이다. + +우리는 다른 상황을 *자발적인 중단* 으로 부른다. +여기에는 애플리케이션 소유자의 작업과 클러스터 관리자의 작업이 모두 포함된다. +다음은 대표적인 애플리케이션 소유자의 작업이다. + +- 디플로이먼트 제거 또는 다른 파드를 관리하는 컨트롤러의 제거 +- 재시작을 유발하는 디플로이먼트의 파드 템플릿 업데이트 +- 파드를 직접 삭제(예: 우연히) + +클러스터 관리자의 작업: + +- 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/). +- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기). +- 노드에 다른 무언가를 추가하기 위해 파드를 제거. + +위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며, +클러스터 호스팅 공급자에 의해서도 수행된다. + +클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지 +클러스터 관리자에게 문의하거나 클라우드 공급자에게 문의하고, 배포 문서를 참조해서 확인해야 한다. +만약 자발적인 중단을 일으킬 수 있는 원인이 없다면 Pod Disruption Budget의 생성을 넘길 수 있다. + +{{< caution >}} +모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다. +예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget를 무시한다. +{{< /caution >}} + +## 중단 다루기 + +비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다. + +- 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다. +- 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.) +- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는 +영역 간(또는 [다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다.)에 +애플리케이션을 분산해야 한다. + +자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다. +그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다. +예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다. +또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. +클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. + +쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을 +실행 할 수 있는 기능을 제공한다. +우리는 이 기능을 *Disruption Budgets* 이라 부른다. + +## Disruption Budgets의 작동 방식 + +애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다. +PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다. +예를 들어 정족수 기반의 애플리케이션이 +실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다. +웹 프런트 엔드는 부하를 처리하는 레플리카의 수가 +일정 비율 이하로 떨어지지 않도록 보장할 수 있다. + +클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신 +[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로 +불리는 Pod Disruption Budgets를 준수하는 도구를 이용해야 한다. +예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다. + +클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다. +해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다. +축출 요청은 일시적으로 거부될 수 있으며, 도구는 모든 파드가 종료되거나 +설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다. + +PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다. +예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다. +만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다. + +파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며 +애플리케이션 컨트롤러(디플로이먼트, 스테이트풀 셋 등)를 사용한 것과 같다. + +파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다. +컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다. + +PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만, +버짓이 차감된다. + +애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다. +그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다. +애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다. +([디플로이먼트 업데이트](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)에 대해 알아보기.) + +파드를 Eviction API로 축출하면 정상적으로 종료된다. +([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.) + +## PDB 예시 + +`node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자. +클러스터에는 여러 애플리케이션을 실행하고 있다. +여러 애플리케이션 중 하나는 `pod-a`, `pod-b`, `pod-c` 로 부르는 3개의 레플리카가 있다. 여기에 `pod-x` 라고 부르는 PDB와 무관한 파드가 보인다. +초기에 파드는 다음과 같이 배치된다. + +| node-1 | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| pod-a *available* | pod-b *available* | pod-c *available* | +| pod-x *available* | | | + +전체 3개 파드는 디플로이먼트의 일부분으로 전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다. + +예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자. +클러스터 관리자는 첫째로 `node-1` 을 `kubectl drain` 명령어를 사용해서 비우려 한다. +`kubectl` 은 `pod-a` 과 `pod-x` 를 축출하려고 한다. 이는 즉시 성공한다. +두 파드는 동시에 `terminating` 상태로 진입한다. +이렇게 하면 클러스터는 다음의 상태가 된다. + +| node-1 *draining* | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| pod-a *terminating* | pod-b *available* | pod-c *available* | +| pod-x *terminating* | | | + +디플로이먼트는 한 개의 파드가 중지되는 것을 알게되고, `pod-d` 라는 대체 파드를 생성한다. +`node-1` 은 차단되어 있어 다른 노드에 위치한다. +무언가가 `pod-x` 의 대체 파드로 `pod-y` 도 생성했다. + +(참고: 스테이트풀 셋은 `pod-0`처럼 불릴, `pod-a`를 +교체하기 전에 완전히 중지해야 하며, `pod-0` 로 불리지만, 다른 UID로 생성된다. +그렇지 않으면 이 예시는 스테이트풀 셋에도 적용된다.) + +이제 클러스터는 다음과 같은 상태이다. + +| node-1 *draining* | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| pod-a *terminating* | pod-b *available* | pod-c *available* | +| pod-x *terminating* | pod-d *starting* | pod-y | + +어느 순간 파드가 종료되고, 클러스터는 다음과 같은 상태가 된다. + +| node-1 *drained* | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| | pod-b *available* | pod-c *available* | +| | pod-d *starting* | pod-y | + +이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을 +비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고, +PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d`가 available 상태가 된다. + +이제 클러스터는 다음과 같은 상태이다. + +| node-1 *drained* | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| | pod-b *available* | pod-c *available* | +| | pod-d *available* | pod-y | + +이제 클러스터 관리자는 `node-2` 를 비우려고 한다. +drain 커멘드는 `pod-b`에서 `pod-d`와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다. +drain 커멘드는 `pod-b`를 축출하는데 성공했다. +그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우 +디플로이먼트에 available 상태의 파드는 1개로 축출이 거부된다. + +디플로이먼트는`pod-b` 를 대체할 `pod-e`라는 파드를 생성한다. +클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에 +드레이닝 명령어는 차단된다. +클러스터는 다음 상태로 끝나게 된다. + +| node-1 *drained* | node-2 | node-3 | *no node* | +|:--------------------:|:-------------------:|:------------------:|:------------------:| +| | pod-b *available* | pod-c *available* | pod-e *pending* | +| | pod-d *available* | pod-y | | + +이 시점에서 클러스터 관리자는 +클러스터에 노드를 추가해서 업그레이드를 진행해야 한다. + +쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지 +다음의 사례를 통해 알 수 있다. + +- 애플리케이션에 필요한 레플리카의 수 +- 인스턴스를 정상적으로 종료하는데 소요되는 시간 +- 새 인스턴스를 시작하는데 소요되는 시간 +- 컨트롤러의 유형 +- 클러스터의 리소스 용량 + +## 클러스터 소유자와 애플리케이션 소유자의 역할 분리 + +보통 클러스터 매니저와 애플리케이션 소유자는 +서로에 대한 지식이 부족한 별도의 역할로 생각하는 것이 유용하다. +이와 같은 책임의 분리는 +다음의 시나리오에서 타당할 수 있다. + +- 쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우 +- 타사 도구 또는 타사 서비스를 이용해서 클러스터 관리를 자동화 하는 경우 + +Pod Disruption Budgets는 역할 분리에 따라 +역할에 맞는 인터페이스를 제공한다. + +만약 조직에 역할 분리에 따른 책임의 분리가 없다면 +Pod Disruption Budgets를 사용할 필요가 없다. + +## 클러스터에서 중단이 발생할 수 있는 작업을 하는 방법 + +만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은 +중단이 발생할 수 있는 작업을 수행하는 경우 다음과 같은 옵션을 선택한다. + +- 업그레이드 하는 동안 다운타임을 허용한다. +- 다른 레플리카 클러스터로 장애조치를 한다. + - 다운타임은 없지만, 노드 사본과 + 전환 작업을 조정하기 위한 인력 비용이 많이 발생할 수 있다. +- PDB를 이용해서 애플리케이션의 중단에 견디도록 작성한다. + - 다운타임 없음 + - 최소한의 리소스 중복 + - 클러스터 관리의 자동화 확대 적용 + - 내결함성이 있는 애플리케이션의 작성은 까다롭지만 + 자발적 중단를 허용하는 작업의 대부분은 오토스케일링과 + 비자발적 중단를 지원하는 작업과 겹친다. + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다. + +* [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기 + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 1555ff06e4..3c9aaa09ec 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -19,7 +19,7 @@ card: 파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함. -[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다. +[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다. 쿠버네티스 클러스터 내부의 파드는 주로 두 가지 방법으로 사용된다. diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md index f58d6f8b4f..fdadf15710 100644 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ b/content/ko/docs/concepts/workloads/pods/pod.md @@ -139,7 +139,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도 위와 같은 기능 제공을 할 수 있다. -사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. +사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. 파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다: @@ -176,7 +176,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 ### 파드 강제 삭제 -파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, apiserver는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. +파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. 노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다. diff --git a/content/ko/docs/reference/glossary/admission-controller.md b/content/ko/docs/reference/glossary/admission-controller.md new file mode 100644 index 0000000000..05a9a91709 --- /dev/null +++ b/content/ko/docs/reference/glossary/admission-controller.md @@ -0,0 +1,22 @@ +--- +title: 어드미션 컨트롤러(Admission Controller) +id: admission-controller +date: 2019-06-28 +full_link: /docs/reference/access-authn-authz/admission-controllers/ +short_description: > + 쿠버네티스 API 서버에서 요청을 처리하여 오브젝트가 지속되기 전에 그 요청을 가로채는 코드 조각. + +aka: +tags: +- extension +- security +--- +쿠버네티스 API 서버에서 요청을 처리하여 오브젝트가 지속되기 전에 그 요청을 가로채는 코드 조각. + + + +어드미션 컨트롤러는 쿠버네티스 API 서버에서 구성할 수 있고, "유효성 검사"나 "변조하기" 혹은 모두를 진행할 수 있다. +모든 어드미션 컨트롤러는 요청을 거부할 수 있다. 변조하는 컨트롤러는 자신이 승인하는 오브젝트를 수정할 수 있지만 +유효성 검사 컨트롤러는 수정할 수 없다. + +* [쿠버네티스 문서에서 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/) diff --git a/content/ko/docs/reference/glossary/aggregation-layer.md b/content/ko/docs/reference/glossary/aggregation-layer.md new file mode 100644 index 0000000000..404257f20b --- /dev/null +++ b/content/ko/docs/reference/glossary/aggregation-layer.md @@ -0,0 +1,19 @@ +--- +title: 애그리게이션 레이어(Aggregation Layer) +id: aggregation-layer +date: 2018-10-08 +full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ +short_description: > + 애그리게이션 레이어를 이용하면 사용자가 추가로 쿠버네티스 형식의 API를 클러스터에 설치할 수 있다. + +aka: +tags: +- architecture +- extension +- operation +--- +애그리게이션 레이어를 이용하면 사용자가 추가로 쿠버네티스 형식의 API를 클러스터에 설치할 수 있다. + + + +{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다. diff --git a/content/ko/docs/reference/glossary/certificate.md b/content/ko/docs/reference/glossary/certificate.md new file mode 100644 index 0000000000..b5bc067015 --- /dev/null +++ b/content/ko/docs/reference/glossary/certificate.md @@ -0,0 +1,18 @@ +--- +title: 인증서(Certificate) +id: certificate +date: 2018-04-12 +full_link: /docs/tasks/tls/managing-tls-in-a-cluster/ +short_description: > + 암호화된 안전한 파일로 쿠버네티스 클러스터 접근 검증에 사용한다. + +aka: +tags: +- security +--- +암호화된 안전한 파일로 쿠버네티스 클러스터 접근 검증에 사용한다. + + + +인증서는 쿠버네티스 클러스터에서 애플리케이션이 쿠버네티스 API에 안전하게 접근할 수 있게 한다. 인증서는 클라이언트의 API 접근 허용 여부를 검증한다. + diff --git a/content/ko/docs/reference/glossary/cgroup.md b/content/ko/docs/reference/glossary/cgroup.md new file mode 100644 index 0000000000..a8c424cf89 --- /dev/null +++ b/content/ko/docs/reference/glossary/cgroup.md @@ -0,0 +1,17 @@ +--- +title: cgroup +id: cgroup +date: 2019-06-25 +full_link: +short_description: > + 선택적으로 리소스를 격리, 관리, 제한하는 리눅스 프로세스의 그룹. + +aka: +tags: +- fundamental +--- +선택적으로 리소스를 격리, 관리, 제한하는 리눅스 프로세스의 그룹. + + + +cgroup은 프로세스 집합에 대해서 리소스 사용(CPU, 메모리, 디스크 I/O, 네트워크)을 격리하고, 관리하며, 제한하는 리눅스 커널 기능이다. diff --git a/content/ko/docs/reference/glossary/controller.md b/content/ko/docs/reference/glossary/controller.md index 947470e054..05cbd4d55f 100644 --- a/content/ko/docs/reference/glossary/controller.md +++ b/content/ko/docs/reference/glossary/controller.md @@ -4,16 +4,16 @@ id: controller date: 2018-04-12 full_link: /docs/admin/kube-controller-manager/ short_description: > - Apiserver를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프. + API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프. -aka: +aka: tags: - architecture - fundamental --- - {{< glossary_tooltip text="Apiserver" term_id="kube-apiserver" >}}를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프. + {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프. - + 현재 쿠버네티스에 포함된 컨트롤러의 예시로는 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러, 서비스 어카운트 컨트롤러가 있다. diff --git a/content/ko/docs/reference/glossary/customresourcedefinition.md b/content/ko/docs/reference/glossary/customresourcedefinition.md index c5c754d270..d21612e118 100755 --- a/content/ko/docs/reference/glossary/customresourcedefinition.md +++ b/content/ko/docs/reference/glossary/customresourcedefinition.md @@ -4,17 +4,17 @@ id: CustomResourceDefinition date: 2018-04-12 full_link: docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ short_description: > - 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API server에 추가할 리소스를 정의하는 사용자 정의 코드. + 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드. -aka: +aka: tags: - fundamental - operation - extension --- - 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API server에 추가할 리소스를 정의하는 사용자 정의 코드. + 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드. - + -만약 공개적으로 지원되는 API 리소스가 사용자의 요구를 충족할 수 없는 경우, 커스텀 리소스 데피니션은 사용자의 환경에 따라 쿠버네티스 API를 확장하게 해준다. +만약 공개적으로 지원되는 API 리소스가 사용자의 요구를 충족할 수 없는 경우, 커스텀 리소스 데피니션은 사용자의 환경에 따라 쿠버네티스 API를 확장하게 해준다. diff --git a/content/ko/docs/reference/glossary/device-plugin.md b/content/ko/docs/reference/glossary/device-plugin.md index 61a857e58e..cd850a828b 100644 --- a/content/ko/docs/reference/glossary/device-plugin.md +++ b/content/ko/docs/reference/glossary/device-plugin.md @@ -4,7 +4,7 @@ id: device-plugin date: 2019-02-02 full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > - 장치 플러그인은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. + 쿠버네티스에서 동작하는 컨테이너로, 공급 업체 고유의 리소스에 대한 액세스를 제공한다. aka: tags: - fundamental @@ -14,4 +14,4 @@ tags: -[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 kubelet에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 데몬 셋으로도 디플로이 가능하다. +[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로도 디플로이 가능하다. diff --git a/content/ko/docs/reference/glossary/kube-proxy.md b/content/ko/docs/reference/glossary/kube-proxy.md index 5f8a4fc612..ea7eb79d58 100755 --- a/content/ko/docs/reference/glossary/kube-proxy.md +++ b/content/ko/docs/reference/glossary/kube-proxy.md @@ -2,21 +2,19 @@ title: kube-proxy id: kube-proxy date: 2018-04-12 -full_link: /docs/reference/generated/kube-proxy +full_link: /docs/reference/command-line-tools-reference/kube-proxy/ short_description: > `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. aka: tags: - fundamental -- core-object +- networking --- - `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. - -이는 호스트의 네트워크 규칙을 관리하고 접속 포워딩을 수행하여 -쿠버네티스 서비스 추상화를 가능케 한다. + [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 {{< glossary_tooltip text="서비스" term_id="service">}} 개념의 구현부이다. -`kube-proxy`는 요청에 대한 포워딩을 책임진다. `kube-proxy`는 TCP 및 UDP 스트림 포워딩을 허용하거나 TCP 및 UDP 포워딩을 백 엔드 기능 집합에 걸쳐 라운드 로빈을 제공한다. +kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. +kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다. diff --git a/content/ko/docs/reference/glossary/kubectl.md b/content/ko/docs/reference/glossary/kubectl.md index ac68b191af..0de6f95898 100755 --- a/content/ko/docs/reference/glossary/kubectl.md +++ b/content/ko/docs/reference/glossary/kubectl.md @@ -4,16 +4,16 @@ id: kubectl date: 2018-04-12 full_link: /docs/user-guide/kubectl-overview/ short_description: > - 쿠버네티스 API server와 통신하기 위한 커맨드라인 툴. + 쿠버네티스 API 서버와 통신하기 위한 커맨드라인 툴. -aka: +aka: tags: - tool - fundamental --- - {{< glossary_tooltip text="쿠버네티스 API" term_id="kubernetes-api" >}} server와 통신하기 위한 커맨드라인 툴. + {{< glossary_tooltip text="쿠버네티스 API" term_id="kubernetes-api" >}} 서버와 통신하기 위한 커맨드라인 툴. - + 사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 kubectl를 사용할 수 있다. diff --git a/content/ko/docs/reference/glossary/mirror-pod.md b/content/ko/docs/reference/glossary/mirror-pod.md index d3b610db28..1819e74917 100755 --- a/content/ko/docs/reference/glossary/mirror-pod.md +++ b/content/ko/docs/reference/glossary/mirror-pod.md @@ -1,8 +1,7 @@ --- title: 미러 파드(Mirror Pod) id: mirror-pod -date: 2091-02-12 -full_link: +date: 2019-08-06 short_description: > Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 객체. diff --git a/content/ko/docs/reference/glossary/service-account.md b/content/ko/docs/reference/glossary/service-account.md index 2dc318a569..ce110187e4 100755 --- a/content/ko/docs/reference/glossary/service-account.md +++ b/content/ko/docs/reference/glossary/service-account.md @@ -6,14 +6,14 @@ full_link: /docs/tasks/configure-pod-container/configure-service-account/ short_description: > 파드에서 실행 중인 프로세스를 위한 신원(identity)을 제공한다. -aka: +aka: tags: - fundamental - core-object --- {{< glossary_tooltip text="파드" term_id="pod" >}}에서 실행 중인 프로세스를 위한 신원(identity)을 제공한다. - + -파드 내부의 프로세스가 클러스터에 엑세스할 때, API server에 의해서 특별한 서비스 어카운트(예를 들면, 기본(default))로 인증된다. 파드를 생성할 때, 서비스 어카운트를 명시하지 않는다면, 동일한 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}의 기본 서비스 어카운트가 자동적으로 할당된다. +파드 내부의 프로세스가 클러스터에 엑세스할 때, API 서버에 의해서 특별한 서비스 어카운트(예를 들면, 기본(default))로 인증된다. 파드를 생성할 때, 서비스 어카운트를 명시하지 않는다면, 동일한 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}의 기본 서비스 어카운트가 자동적으로 할당된다. diff --git a/content/ko/docs/reference/glossary/static-pod.md b/content/ko/docs/reference/glossary/static-pod.md index ec5ea8c8e8..6b80d40e24 100755 --- a/content/ko/docs/reference/glossary/static-pod.md +++ b/content/ko/docs/reference/glossary/static-pod.md @@ -1,7 +1,7 @@ --- title: 스태틱 파드(Static Pod) id: static-pod -date: 2091-02-12 +date: 2019-02-12 full_link: /docs/tasks/administer-cluster/static-pod/ short_description: > 특정 노드의 Kubelet 데몬이 직접 관리하는 파드 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 76e05c79e6..a19454f9d6 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -154,6 +154,10 @@ kubectl get services --sort-by=.metadata.name # Name으로 정렬된 서비스 # 재시작 횟수로 정렬된 파드의 목록 조회 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' +# test 네임스페이스 내 파드 목록을 용량으로 정렬해서 조회 + +kubectl get pods -n test --sort-by=.spec.capacity.storage + # app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회 kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' @@ -197,9 +201,12 @@ kubectl get events --sort-by=.metadata.creationTimestamp ```bash kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트 +kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크 kubectl rollout undo deployment/frontend # 이전 디플로이먼트로 롤백 +kubectl rollout undo deployment/frontend --to-revision=2 # 특정 리비전으로 롤백 kubectl rollout status -w deployment/frontend # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시 + # 버전 1.11 부터 사용 중단 kubectl rolling-update frontend-v1 -f frontend-v2.json # (사용중단) frontend-v1 파드의 롤링 업데이트 kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (사용중단) 리소스 이름 변경과 이미지 업데이트 diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md index 3c77ed24b8..a3ed2d4a7d 100644 --- a/content/ko/docs/reference/using-api/api-overview.md +++ b/content/ko/docs/reference/using-api/api-overview.md @@ -43,7 +43,7 @@ API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된 [API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. {{< /note >}} -API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [API 변경 문서](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다. +API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다. 아래는 각 수준의 기준에 대한 요약이다. diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md new file mode 100644 index 0000000000..ddd47ef1e8 --- /dev/null +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -0,0 +1,74 @@ +--- +title: 클라이언트 라이브러리 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} +이 페이지는 다양한 프로그래밍 언어에서 쿠버네티스 API를 사용하기 위한 +클라이언트 라이브러리에 대한 개요를 포함하고 있다. +{{% /capture %}} + +{{% capture body %}} +[쿠버네티스 REST API](/ko/docs/reference/using-api/api-overview/)를 사용해 애플리케이션을 작성하기 위해 +API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. +사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다. + +클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다. +대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증 +또는 [kubeconfig 파일](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) 포맷을 통해 +자격증명과 API 서버 주소를 읽을 수 있게 +쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다. + +## 공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리 + +다음의 클라이언트 라이브러리들은 [쿠버네티스 SIG API +Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다. + + +| 언어 | 클라이언트 라이브러리 | 예제 프로그램 | +|----------|----------------|-----------------| +| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples) +| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) +| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation) +| dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [둘러보기](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) +| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) +| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [둘러보기](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) + + +## 커뮤니티에 의해 관리되는 클라이언트 라이브러리 + +다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌 +각각의 저자들이 제공하고 관리한다. + +| 언어 | 클라이언트 라이브러리 | +| -------------------- | ---------------------------------------- | +| Clojure | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) | +| Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | +| Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | +| Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | +| Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) | +| Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) | +| Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | +| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | +| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | +| Node.js | [github.com/ajpauwels/easy-k8s](https://github.com/ajpauwels/easy-k8s) +| Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) | +| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | +| PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) | +| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) | +| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | +| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | +| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | +| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | +| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | +| Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | +| Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | +| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | +| 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/) | +| Haskell | [github.com/soundcloud/haskell-kubernetes](https://github.com/soundcloud/haskell-kubernetes) | +{{% /capture %}} + + diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 29789d5dbd..3a03610299 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -37,8 +37,8 @@ card: |커뮤니티 |생태계 | | ------------ | -------- | | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| -| [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind) | [Minishift](https://docs.okd.io/latest/minishift/)| +| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/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) | | | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| @@ -71,14 +71,14 @@ card: | [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | | | [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | | [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| -| [Canonical](https://www.ubuntu.com/kubernetes/docs/quickstart) | | ✔ | | ✔ |✔ | ✔ +| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔ | [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | | | [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ | [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | | [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ | [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ | [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ -| [Gardner](https://gardener.cloud/) | |✔ | | ✔ | | +| [Gardener](https://gardener.cloud/) | |✔ | | ✔ | | | [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | | | [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | | [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index 510013d88c..449589fdf7 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -19,7 +19,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. * 노드 포트 * 컨피그 맵과 시크릿 * 대시보드 -* 컨테이너 런타임: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd) +* 컨테이너 런타임: Docker, [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd) * CNI(Container Network Interface) 사용 * 인그레스 @@ -228,7 +228,6 @@ minikube start \ {{% /tab %}} {{% tab name="CRI-O" %}} [CRI-O](https://github.com/kubernetes-incubator/cri-o)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. - ```bash minikube start \ --network-plugin=cni \ @@ -248,17 +247,6 @@ minikube start \ --bootstrapper=kubeadm ``` {{% /tab %}} -{{% tab name="rkt container engine" %}} -[rkt](https://github.com/rkt/rkt)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. - -```shell -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=rkt -``` -이것은 rkt와 Docker와 CNI 네트워킹을 포함하는 대안적인 Minikube ISO 이미지를 이용한다. -{{% /tab %}} {{< /tabs >}} #### Docker 데몬 재사용을 통한 로컬 이미지 사용하기 @@ -452,10 +440,8 @@ export no_proxy=$no_proxy,$(minikube ip) ``` ## 알려진 이슈 -* 클라우드 공급자를 필요로 하는 기능은 Minikube에서 동작하지 않는다. 여기에는 다음이 포함된다. - * 로드밸런서 -* 다중 노드를 위한 기능들이다. 여기에는 다음이 포함된다. - * 진보된 스케쥴링 정책 + +다중 노드가 필요한 기능은 Minukube에서 동작하지 않는다. ## 설계 diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 74a9489426..6f17b470b6 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -187,7 +187,7 @@ apt-get install cri-o-1.13 {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} # 선행 조건 설치 -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/ +yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ # CRI-O 설치 yum install --nogpgcheck cri-o @@ -213,6 +213,11 @@ Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사 ### 선행 조건 ```shell +cat > /etc/modules-load.d/containerd.conf <}} + +kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는 기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다. + +- `apiServer` +- `controllerManager` +- `scheduler` + +`extraArgs` 필드는 `key: value` 쌍으로 구성되어 있다. 컨트롤 플레인 구성요소를 위한 플래그를 대체하려면 다음을 수행한다. + +1. 사용자 구성에서 적절한 필드를 추가한다. +2. 필드에 대체할 플래그를 추가한다. +3. `kubeadm init`에 `--config ` 파라미터를 추가해서 실행한다. + +각 필드의 구성에서 자세한 정보를 보려면, +[API 참고 문서](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration)에서 확인해 볼 수 있다. + +{{< note >}} +`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을 저장하여 기본값인 `ClusterConfiguration` 오브젝트를 생성할 수 있다. +{{< /note >}} + +{{% /capture %}} + +{{% capture body %}} + +## APIServer 플래그 + +자세한 내용은 [kube-apiserver에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다. + +사용 예: +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +kubernetesVersion: v1.13.0 +apiServer: + extraArgs: + advertise-address: 192.168.0.103 + anonymous-auth: "false" + enable-admission-plugins: AlwaysPullImages,DefaultStorageClass + audit-log-path: /home/johndoe/audit.log +``` + +## 컨트롤러매니저 플래그 + +자세한 내용은 [kube-controller-manager에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다. + +사용 예: +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +kubernetesVersion: v1.13.0 +controllerManager: + extraArgs: + cluster-signing-key-file: /home/johndoe/keys/ca.key + bind-address: 0.0.0.0 + deployment-controller-sync-period: "50" +``` + +## 스케줄러 플래그 + +자세한 내용은 [kube-scheduler에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다. + +사용 예: +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +kubernetesVersion: v1.13.0 +scheduler: + extraArgs: + address: 0.0.0.0 + config: /home/johndoe/schedconfig.yaml + kubeconfig: /home/johndoe/kubeconfig.yaml +``` + +{{% /capture %}} diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/ko/docs/setup/production-environment/tools/kubeadm/ha-topology.md new file mode 100644 index 0000000000..ac6cab8aa5 --- /dev/null +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -0,0 +1,70 @@ +--- +reviewers: +title: 고가용성 토폴로지 선택 +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + +이 페이지는 고가용성(HA) 쿠버네티스 클러스터의 토플로지를 구성하는 두 가지 선택 사항을 설명한다. + +다음과 같이 HA 클러스터를 구성할 수 있다. + +- etcd 노드와 컨트롤 플레인 노드를 함께 위치시키는 중첩된(stacked) 컨트롤 플레인 노드 방식 +- etcd와 컨트롤 플레인이 분리된 노드에서 운영되는 외부 etcd 노드 방식 + +HA 클러스터를 구성하기 전에 각 토플로지의 장단점을 주의 깊게 고려해야 한다. + +{{% /capture %}} + +{{% capture body %}} + +## 중첩된 etcd 토플로지 + +중첩된 HA 클러스터는 etcd에서 제공하는 분산 데이터 저장소 클러스터를, +컨트롤 플레인 구성 요소를 실행하는 kubeadm으로 관리되는 노드에 의해서 형성된 클러스터 상단에 +중첩하는 [토플로지](https://en.wikipedia.org/wiki/Network_topology)이다. + +각 컨트롤 플레인 노드는 `kube-apiserver`, `kube-scheduler`, `kube-controller-manager` 인스턴스를 운영한다. +`kube-apiserver`는 로드 밸런서를 이용하여 워커 노드에 노출되어 있다. + +각 컨트롤 플레인 노드는 지역 etcd 맴버를 생성하고 +이 etcd 맴버는 오직 해당 노드의 `kube-apiserver`와 통신한다. +비슷한 방식이 지역의 `kube-controller-manager`와 `kube-scheduler`에도 적용된다. + +이 토플로지는 컨트롤 플레인과 etcd 맴버가 같은 노드에 묶여 있다. +이는 외부 etcd 노드의 클러스터를 구성하는 것보다는 단순하며 복제 관리도 간단하다. + +그러나 중첩된 클러스터는 커플링에 실패할 위험이 있다. 한 노드가 다운되면 etcd 맴버와 컨트롤 플레인을 모두 잃어버리고, +중복성도 손상된다. 더 많은 컨트롤 플레인 노드를 추가하여 이 위험을 완화할 수 있다. + +그러므로 HA 클러스터를 위해 최소 3개인 중첩된 컨트롤 플레인 노드를 운영해야 한다. + +이는 kubeadm의 기본 토플로지이다. 지역 etcd 맴버는 +`kubeadm init`와 `kubeadm join --control-plane` 을 이용할 때에 컨트롤 플레인 노드에 자동으로 생성된다. + +![중첩된 etcd 토플로지](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg) + +## 외부 etcd 토플로지 + +외부 etcd를 이용하는 HA 클러스터는 etcd로 제공한 분산된 데이터 스토리지 클러스터가 컨트롤 플레인 구성 요소를 운영하는 노드로 형성하는 클러스터의 외부에 있는 [토플로지](https://en.wikipedia.org/wiki/Network_topology)이다. + +중첩된 etcd 토플로지와 유사하게, 외부 etcd 토플로지에 각 컨트롤 플레인 노드는 `kube-apiserver`, `kube-scheduler`, `kube-controller-manager`의 인스턴스를 운영한다. 그리고 `kube-apiserver`는 로드 밸런서를 이용하여 워커노드에 노출한다. 그러나 etcd 맴버는 분리된 호스트에서 운영되고, 각 etcd 호스트는 각 컨트롤 플레인 노드의 `kube-apiserver`와 통신한다. + +이 토플로지는 컨트롤 플레인과 etcd 맴버를 분리한다. 이는 그러므로 +컨트롤 플레인 인스턴스나 etcd 맴버를 잃는 충격이 덜하고, +클러스터 중복성에 있어 중첩된 HA 토플로지만큼 영향을 미치지 않는다. + +그러나, 이 토플로지는 중첩된 토플로지에 비해 호스트 개수가 두배나 필요하다. +이 토플로지로 HA 클러스터를 구성하기 위해서는 최소한 3개의 컨트롤 플레인과 3개의 etcd 노드가 필요하다. + +![외부 etcd 토플로지](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg) + +{{% /capture %}} + +{{% capture whatsnext %}} + +- [kubeadm을 이용하여 고가용성 클러스터 구성하기](/docs/setup/production-environment/tools/kubeadm/high-availability/) + +{{% /capture %}} diff --git a/content/ko/docs/setup/production-environment/windows/_index.md b/content/ko/docs/setup/production-environment/windows/_index.md new file mode 100644 index 0000000000..0656236239 --- /dev/null +++ b/content/ko/docs/setup/production-environment/windows/_index.md @@ -0,0 +1,4 @@ +--- +title: "쿠버네티스에서 윈도우" +weight: 50 +--- diff --git a/content/ko/docs/setup/production-environment/windows/flannel-master-kubectl-get-pods.png b/content/ko/docs/setup/production-environment/windows/flannel-master-kubectl-get-pods.png new file mode 100644 index 0000000000..73da333fcf Binary files /dev/null and b/content/ko/docs/setup/production-environment/windows/flannel-master-kubectl-get-pods.png differ diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md new file mode 100644 index 0000000000..af58c4965e --- /dev/null +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -0,0 +1,138 @@ +--- +reviewers: +title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드 +content_template: templates/concept +weight: 75 +--- + +{{% capture overview %}} + +많은 조직에서 실행하는 서비스와 애플리케이션의 상당 부분이 윈도우 애플리케이션으로 구성된다. 이 가이드는 쿠버네티스에서 윈도우 컨테이너를 구성하고 배포하는 단계를 안내한다. + +{{% /capture %}} + +{{% capture body %}} + +## 목표 + +* 윈도우 노드에서 윈도우 컨테이너를 실행하는 예시 디플로이먼트를 구성한다. +* (선택) 그룹 매니지드 서비스 어카운트(GMSA)를 이용한 사용자 파드를 위한 액티브 디렉터리 신원(Active Directory Identity)을 구성한다. + +## 시작하기 전에 + +* [윈도우 서버에서 운영하는 마스터와 워커 노드](../user-guide-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다. +* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다. + +## 시작하기: 윈도우 컨테이너 배포하기 + +쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다. 아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다. 아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`로 생성하자. + +```yaml + apiVersion: v1 + kind: Service + metadata: + name: win-webserver + labels: + app: win-webserver + spec: + ports: + # 이 서비스에서 제공하는 포트 + - port: 80 + targetPort: 80 + selector: + app: win-webserver + type: NodePort + --- + apiVersion: extensions/v1beta1 + kind: Deployment + metadata: + labels: + app: win-webserver + name: win-webserver + spec: + replicas: 2 + template: + metadata: + labels: + app: win-webserver + name: win-webserver + spec: + containers: + - name: windowswebserver + image: mcr.microsoft.com/windows/servercore:ltsc2019 + command: + - powershell.exe + - -command + - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " + nodeSelector: + beta.kubernetes.io/os: windows +``` + +{{< note >}} +포트 매핑도 지원하지만, 간략한 예시를 위해 컨테이너 포트 80을 직접 서비스로 노출한다. +{{< /note >}} + +1. 모든 노드가 건강한지 확인한다. + + ```bash + kubectl get nodes + ``` + +1. 서비스를 배포하고 파드 갱신을 지켜보자. + + ```bash + kubectl apply -f win-webserver.yaml + kubectl get pods -o wide -w + ``` + + 이 서비스가 정확히 배포되면 모든 파드는 Ready로 표기된다. 지켜보기를 중단하려면, Ctrl+C 를 누르자. + +1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자. + + * 윈도우 노드에 파드당 두 컨테이너, `docker ps`를 사용한다. + * 리눅스 마스터에서 나열된 두 파드, `kubectl get pods`를 사용한다. + * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다. + * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 핑(ping)한다(윈도우 노드를 여럿가지고 있다면 호스트를 달리하며). + * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 IP 주소(`kubectl get services`로 보여지는)로 실행한다. + * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/docs/concepts/services-networking/dns-pod-service/#services)와 서비스 이름으로 `curl`을 실행한다. + * 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다. + * 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다. + +{{< note >}} +윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다. +{{< /note >}} + +## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기 + +쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자. + +## 테인트(Taint)와 톨러레이션(Toleration) + +오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와 노드 셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. + +### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기 + +사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다. 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다. + +* beta.kubernetes.io/os = [windows|linux] +* beta.kubernetes.io/arch = [amd64|arm64|...] + +파드 사양에 노드 셀렉터를 `"beta.kubernetes.io/os": windows`와 같이 지정하지 않았다면, 그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. 윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. 가장 좋은 방법은 노드 셀렉터를 사용하는 것이다. + +그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, 헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. 이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. 이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, 윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다. + +예를 들면, `--register-with-taints='os=Win1809:NoSchedule'` + +모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). 윈도우 파드가 윈도우 노드에 스케줄링되려면, 윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다. + +```yaml +nodeSelector: + "beta.kubernetes.io/os": windows +tolerations: + - key: "os" + operator: "Equal" + value: "Win1809" + effect: "NoSchedule" +``` + +{{% /capture %}} diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md new file mode 100644 index 0000000000..6e60bffaa8 --- /dev/null +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md @@ -0,0 +1,313 @@ +--- +reviewers: +title: 쿠버네티스에서 윈도우 노드 추가 가이드 +content_template: templates/concept +weight: 70 +--- + +{{% capture overview %}} + +쿠버네티스 플랫폼은 이제 리눅스와 윈도우 컨테이너 모두 운영할 수 있다. 윈도우 노드도 클러스터에 등록할 수 있다. 이 가이드는 다음을 어떻게 하는지 보여준다. + +* 윈도우 노드를 클러스터에 등록하기 +* 리눅스와 윈도우에서 동작하는 파드가 상호 간에 통신할 수 있게 네트워크를 구성하기 + +{{% /capture %}} + +{{% capture body %}} + +## 시작하기 전에 + +* 윈도우 컨테이너를 호스트하는 윈도우 노드를 구성하려면 [윈도우 서버 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)를 소유해야 한다. 클러스터를 위해서 소속 기관의 라이선스를 사용하거나, Microsoft, 리셀러로 부터 취득할 수 있으며, GCP, AWS, Azure와 같은 주요 클라우드 제공자의 마켓플레이스를 통해 윈도우 서버를 운영하는 가상머신을 프로비저닝하여 취득할 수도 있다. [사용시간이 제한된 시험판](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial)도 활용 가능하다. + +* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 클러스터를 구축한다.(몇 가지 예시는 [kubeadm으로 단일 컨트롤플레인 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/docs/setup/production-environment/turnkey/azure/), [GCE](/docs/setup/production-environment/turnkey/gce/), [AWS](/docs/setup/production-environment/turnkey/aws/)를 포함한다) + +## 시작하기: 사용자 클러스터에 윈도우 노드 추가하기 + +### IP 주소 체계 설계하기 + +쿠버네티스 클러스터 관리를 위해 실수로 네트워크 충돌을 일으키지 않도록 IP 주소에 대해 신중히 설계해야 한다. 이 가이드는 [쿠버네티스 네트워킹 개념](/docs/concepts/cluster-administration/networking/)에 익숙하다 가정한다. + +클러스터를 배포하려면 다음 주소 공간이 필요하다. + +| 서브넷 / 주소 범위 | 비고 | 기본값 | +| --- | --- | --- | +| 서비스 서브넷 | 라우트 불가한 순수한 가상 서브넷으로 네트워크 토플로지에 관계없이 파드에서 서비스로 단일화된 접근을 제공하기 위해 사용한다. 서비스 서브넷은 노드에서 실행 중인 `kube-proxy`에 의해서 라우팅 가능한 주소 공간으로(또는 반대로) 번역된다. | 10.96.0.0/12 | +| 클러스터 서브넷 | 클러스터 내에 모든 파드에 사용되는 글로벌 서브넷이다. 각 노드에는 파드가 사용하기 위한 /24 보다 작거나 같은 서브넷을 할당한다. 서브넷은 클러스터 내에 모든 파드를 수용할 수 있을 정도로 충분히 큰 값이어야 한다. *최소 서브넷*의 크기를 계산하려면: `(노드의 개수) + (노드의 개수 * 구성하려는 노드 당 최대 파드 개수)`. 예: 노드 당 100개 파드인 5 노드짜리 클러스터 = `(5) + (5 * 100) = 505.` | 10.244.0.0/16 | +| 쿠버네티스 DNS 서비스 IP | DNS 확인 및 클러스터 서비스 검색에 사용되는 서비스인 `kube-dns`의 IP 주소이다. | 10.96.0.10 | + +클러스터에 IP 주소를 얼마나 할당해야 할지 결정하기 위해 '쿠버네티스에서 윈도우 컨테이너: 지원되는 기능: 네트워킹'에서 소개한 네트워킹 선택 사항을 검토하자. + +### 윈도우에서 실행되는 구성 요소 + +쿠버네티스 컨트롤 플레인이 리눅스 노드에서 운영되는 반면, 다음 요소는 윈도우 노드에서 구성되고 운영된다. + +1. kubelet +2. kube-proxy +3. kubectl (선택적) +4. 컨테이너 런타임 + +v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes/releases](https://github.com/kubernetes/kubernetes/releases)에서 받아온다. kubeadm, kubectl, kubelet, kube-proxy의 Windows-amd64 바이너리는 CHANGELOG 링크에서 찾아볼 수 있다. + +### 네트워크 구성 + +리눅스 기반의 쿠버네티스 마스터 노드를 가지고 있다면 네트워킹 솔루션을 선택할 준비가 된 것이다. 이 가이드는 단순화를 위해 VXLAN 방식의 플라넬(Flannel)을 사용하여 설명한다. + +#### 리눅스 컨트롤러에서 VXLAN 방식으로 플라넬 구성하기 + +1. 플라넬을 위해 쿠버네티스 마스터를 준비한다. + + 클러스터의 쿠버네티스 마스터에서 사소한 준비를 권장한다. 플라넬을 사용할 때에 iptables 체인으로 IPv4 트래픽을 브릿지할 수 있게 하는 것은 추천한다. 이는 다음 커맨드를 이용하여 수행할 수 있다. + + ```bash + sudo sysctl net.bridge.bridge-nf-call-iptables=1 + ``` + +1. 플라넬 다운로드 받고 구성하기 + + 가장 최신의 플라넬 메니페스트를 다운로드한다. + + ```bash + wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml + ``` + + VXLAN 네트워킹 벡엔드를 가능하게 하기 위해 수정할 곳은 두 곳이다. + + 아래 단계를 적용하면 `kube-flannel.yml`의 `net-conf.json`부분을 다음과 같게 된다. + + ```json + net-conf.json: | + { + "Network": "10.244.0.0/16", + "Backend": { + "Type": "vxlan", + "VNI" : 4096, + "Port": 4789 + } + } + ``` + + {{< note >}}리눅스의 플라넬과 윈도우의 플라넬이 상호운용하기 위해서 `VNI`는 반드시 4096이고, `Port`는 4789여야 한다. 다른 VNI는 곧 지원될 예정이다. [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)에서 + 이 필드의 설명 부분을 보자.{{< /note >}} + +1. `kube-flannel.yml`의 `net-conf.json` 부분을 거듭 확인하자. + 1. 클러스터 서브넷(예, "10.244.0.0/16")은 IP 주소 설계에 따라 설정되어야 한다. + * VNI 4096 은 벡엔드에 설정한다. + * Port 4789 는 벡엔드에 설정한다. + 1. `kube-flannel.yml`의 `cni-conf.json` 부분에서 네트워크 이름을 `vxlan0`로 바꾼다. + + `cni-conf.json`는 다음과 같다. + + ```json + cni-conf.json: | + { + "name": "vxlan0", + "plugins": [ + { + "type": "flannel", + "delegate": { + "hairpinMode": true, + "isDefaultGateway": true + } + }, + { + "type": "portmap", + "capabilities": { + "portMappings": true + } + } + ] + } + ``` + +1. 플라넬 yaml 을 적용하고 확인하기 + + 플라넬 구성을 적용하자. + + ```bash + kubectl apply -f kube-flannel.yml + ``` + + 다음은 플라넬 파드는 리눅스 기반이라 [여기](https://github.com/Microsoft/SDN/blob/1d5c055bb195fecba07ad094d2d7c18c188f9d2d/Kubernetes/flannel/l2bridge/manifests/node-selector-patch.yml) 나온 노드 셀렉터 패치를 플라넬 데몬셋 파드에 적용한다. + + ```bash + kubectl patch ds/kube-flannel-ds-amd64 --patch "$(cat node-selector-patch.yml)" -n=kube-system + ``` + + 몇 분 뒤에 플라넬 파드 네트워크가 배포되었다면, 모든 파드에서 운영 중인 것을 확인할 수 있다. + + ```bash + kubectl get pods --all-namespaces + ``` + + 결과는 다음과 같다. + + ``` + NAMESPACE NAME READY STATUS RESTARTS AGE + kube-system etcd-flannel-master 1/1 Running 0 1m + kube-system kube-apiserver-flannel-master 1/1 Running 0 1m + kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m + kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m + kube-system kube-flannel-ds-54954 1/1 Running 0 1m + kube-system kube-proxy-Zjlxz 1/1 Running 0 1m + kube-system kube-scheduler-flannel-master 1/1 Running 0 1m + ``` + + 플라넬 데몬셋에 노드 셀렉터가 적용되었음을 확인한다. + + ```bash + kubectl get ds -n kube-system + ``` + + 결과는 다음과 같다. 노드 셀렉터 `beta.kubernetes.io/os=linux`가 적용되었다. + + ``` + NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE + kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d + kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d + ``` + +#### 윈도우 워커 조인 + +이번 단원은 맨 땅에서부터 온프레미스 클러스터에 가입하기까지 윈도우 노드 구성을 다룬다. 클러스터가 클라우드상에 있다면, 다음 단원에 있는 클라우드에 특정한 가이드를 따르도록 된다. + +#### 윈도우 노드 준비하기 + +{{< note >}} +윈도우 단원에서 모든 코드 부분은 높은 권한(Admin)으로 파워쉘(PowerShell) 환경에서 구동한다. +{{< /note >}} + +1. 도커(Docker) 설치(시스템 리부팅 필요) + + 쿠버네티스는 [도커](https://www.docker.com/)를 컨테이너 엔진으로 사용하므로, 도커를 설치해야 한다. [공식 문서 설치 요령](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#install-docker), [도커 명령](https://store.docker.com/editions/enterprise/docker-ee-server-windows)을 따라 해보거나 다음의 *권장하는* 단계를 시도하자. + + ```PowerShell + Enable-WindowsOptionalFeature -FeatureName Containers + Restart-Computer -Force + Install-Module -Name DockerMsftProvider -Repository PSGallery -Force + Install-Package -Name Docker -ProviderName DockerMsftProvider + ``` + + 네트워크 프록시 안쪽에서 작업한다면 다음 파워쉘 환경 변수를 반드시 정의하자. + + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` + + 리부팅 후에 다음 오류를 보게되면, 도커 서비스를 수동으로 재시작해야 한다. + + ```PowerShell + docker version + ``` + + 만약 다음과 같은 에러 메시지를 보게되면, 도커 서비스를 수동으로 시작해야 한다. + + ``` + Client: + Version: 17.06.2-ee-11 + API version: 1.30 + Go version: go1.8.7 + Git commit: 06fc007 + Built: Thu May 17 06:14:39 2018 + OS/Arch: windows / amd64 + error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c + annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to + connect. This error may also indicate that the docker daemon is not running. + ``` + + 다음과 같이 도커 서비스를 수동으로 시작할 수 있다. + + ```PowerShell + Start-Service docker + ``` + +{{< note >}} +`pause`(인프라스트럭처) 이미지는 Microsoft 컨테이너 레지스트리(MCR)에 등록되어 있다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`로 접근할 수 있다. `DOCKERFILE`은 https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat 에 있다. +{{< /note >}} + +1. 쿠버네티스를 위한 윈도우 디렉터리 준비하기 + + 쿠버네티스 바이너리와 배포 스크립트와 구성 파일을 저장할 "윈도우를 위한 쿠버네티스" 디렉터리를 생성한다. + + ```PowerShell + mkdir c:\k + ``` + +1. 쿠버네티스 인증서 복사하기 + + 쿠버네티스 인증서 파일인 `$HOME/.kube/config`을 [리눅스 컨트롤러](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/creating-a-linux-master#collect-cluster-information)에서 윈도우 노드의 새로운 `C:\k` 디렉터리로 복사한다. + + 팁: 노드 간에 구성 파일 전송을 위해 [xcopy](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy), [WinSCP](https://winscp.net/eng/download.php)나 [WinSCP 파워쉘 래퍼](https://www.powershellgallery.com/packages/WinSCP/5.13.2.0)같은 도구를 이용할 수 있다. + +1. 쿠버네티스 바이너리 다운로드 하기 + + 쿠버네티스르 운영을 가능하게 하기 위해 먼저 `kubelet`과 `kube-proxy` 바이너리를 다운로드해야 한다. 이 바이너리를 [최신 릴리스](https://github.com/kubernetes/kubernetes/releases/)의 CHANGELOG.md 파일에 노드 바이너리 링크에서 다운로드 한다. 예를 들어 'kubernetes-node-windows-amd64.tar.gz'. 또한 클라이언트 바이너리 항목에서 찾을 수 있는 윈도우에서 실행되는 `kubectl`을 선택적으로 다운로드 받을 수 있다. + + 압축 파일을 풀고, `C:\k`로 바이너리를 위치하기 위해 [Expand-Archive](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.archive/expand-archive?view=powershell-6) 파워쉘 커맨드를 이용할 수 있다. + +#### 윈도우 노드를 플라넬 클러스터에 가입하기 + +플라넬 오버레이 배포 스크립트와 문서는 [이 리포지터리](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/overlay)에 있다. 다음 단계는 그곳에 있는 자세한 요령을 따라서 단순히 진행하는 것이다. + +[Flannel start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) 스크립트를 다운로드받고, 그 내용을 `C:\k`에 풀어 넣자. + +```PowerShell +cd c:\k +[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 +wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/start.ps1 -o c:\k\start.ps1 +``` + +{{< note >}} +[start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1)은 [install.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/install.ps1)을 참고하는데, 이는 사용자를 위해 `flanneld` 실행 **파일 같은** 추가 파일과 [인프라스트럭처 파드를 위한 Dockerfile](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/Dockerfile)을 다운로드하고 설치한다. 오버레이 네트워킹 방식에서 [방화벽](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/helper.psm1#L111)은 지역 UDP 4789 포트에 대해 열려있다. 여러 파워쉘 윈도우가 열렸다 닫히며, 포드 네트워크를 위한 새로운 외부 vSwitch가 처음 생성되는 동안 몇 초간은 네트워크가 중단된다. 아래 지정한 인수를 사용하여 스크립트를 실행하자. +{{< /note >}} + +```PowerShell +cd c:\k +.\start.ps1 -ManagementIP ` + -NetworkMode overlay ` + -ClusterCIDR ` + -ServiceCIDR ` + -KubeDnsServiceIP ` + -LogDir +``` + +| 파라미터 | 기본값 | 비고 | +| --- | --- | --- | +| -ManagementIP | N/A (필요함) | 윈도우 노드에 할당할 IP 주소. 이 값을 찾기 위해 `ipconfig` 이용할 수 있다. | +| -NetworkMode | l2bridge | 여기서는 `overlay`를 사용한다. | +| -ClusterCIDR | 10.244.0.0/16 | 클러스터 IP 설계을 참고한다. | +| -ServiceCIDR | 10.96.0.0/12 | 클러스터 IP 설계을 참고한다. | +| -KubeDnsServiceIP | 10.96.0.10 | | +| -InterfaceName | Ethernet | 윈도우 호스트의 네트워크 인터페이스 이름. 이 값을 찾기 위해 ipconfig 이용할 수 있다. | +| -LogDir | C:\k | Kubelet과 Kube-proxy가 각각의 로그 출력 파일을 리다이렉션하는 디렉터리이다. | + +이제 다음을 실행하여 사용자 클러스터 내에 윈도우 노드를 볼 수 있다. + +```bash +kubectl get nodes +``` + +{{< note >}} +Kubelet, kueb-proxy 같은 윈도우 노드 구성요소를 윈도우 서비스로 구성할 수 있다. 추가적인 방법은 [문제 해결](#troubleshooting)의 서비스와 백그라운드 프로세스 단원을 보자. 노드의 구성요소를 서비스로 실행하면 로그 수집하는 것이 문제 해결에 있어 중요한 부분이 된다. 추가 지침으로 기여 가이드에서 [로그 수집하기](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) 단원을 보자. +{{< /note >}} + +### 공개 클라우드 제공자 + +#### Azure + +AKS-Engine은 완전하고, 맞춤 설정이 가능한 쿠버네티스 클러스터를 리눅스와 윈도우 노드에 배포할 수 있다. 단계별 안내가 [GitHub에 있는 문서](https://github.com/Azure/aks-engine/blob/master/docs/topics/windows.md)로 제공된다. + +#### GCP + +사용자가 [GitHub](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/windows/README-GCE-Windows-kube-up.md)에 있는 단계별 안내를 따라서 완전한 쿠버네티스 클러스터를 GCE 상에 쉽게 배포할 수 있다. + +#### kubeadm과 클러스터 API로 배포하기 + +Kubeadm은 쿠버네티스 클러스터를 배포하는 사용자에게 산업 표준이 되었다. Kubeadm에서 윈도우 노드 지원은 미래 릴리스에 나올 것이다. 또한 윈도우 노드가 올바르게 프로비저닝되도록 클러스터 API에 투자하고 있다. + +### 다음 단계 + +이제 클러스터 내에 윈도우 컨테이너를 실행하도록 윈도우 워커를 구성했으니, 리눅스 컨테이너를 실행할 리눅스 노드를 1개 이상 추가할 수 있다. 이제 윈도우 컨테이너를 클러스터에 스케줄링할 준비가 됬다. + +{{% /capture %}} diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md new file mode 100644 index 0000000000..97eb33b87b --- /dev/null +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -0,0 +1,165 @@ +--- +title: 웹 UI (대시보드) +content_template: templates/concept +weight: 10 +card: + name: tasks + weight: 30 + title: Use the Web UI Dashboard +--- + +{{% capture overview %}} +대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다. + +또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다. + +![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png) + +{{% /capture %}} + + +{{% capture body %}} + +## 대시보드 UI 배포 + +대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다. + +``` +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml +``` + +## 대시보드 UI 접근 + +클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user) 가이드를 따른다. + +{{< warning >}} +시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다. +{{< /warning >}} + +### 커맨드 라인 프록시 +kubectl 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로써 대시보드를 사용할 수 있다. + +``` +kubectl proxy +``` + +kubectl은 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 에 대시보드를 사용하는 것을 가능하게 해줄 것이다. + +UI는 커맨드가 실행된 머신에서 _오직_ 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다. + +{{< note >}} +Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 인증서를 지원하지 않는다. +{{< /note >}} + +## 웰컴 뷰 + +초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다. 이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다. 게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system` [네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다. + +![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png) + +## 컨테이너화 된 애플리케이션 배포 + +대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다. + +시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다. + +### 애플리케이션 세부 정보 지정 + +배포 마법사는 다음 정보를 제공한다. + +- **앱 이름** (필수): 애플리케이션 이름. [레이블](/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다. + + 애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다. + +- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다. + +- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다. + + 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. + +- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. + + 클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다. + + 서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. + +만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다. + +- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다. + +- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. + + 예를 들면: + + ```conf +release=1.0 +tier=frontend +environment=pod +track=stable +``` + +- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다. + + 대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다. 네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다. + 네임스페이스 이름은 숫자로만 구성할 수 없다. 만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다. + + 네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다. 만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다. + +- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다. + + 대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다. + + 이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다. + +- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다. + +- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/docs/user-guide/containers/#containers-and-commands)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다. + +- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. + +- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. + +### YAML 또는 JSON 파일 업로드 + +쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다. + +배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. + +## 대시보드 사용 +다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다. + +### 탐색 + +클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다. 기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, 이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다. + +대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다. + +#### 어드민 개요 +클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다. + +#### 워크로드 +선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. + +워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. + +#### 서비스(Service) +외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. + +#### 스토리지 +스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다. + +#### 컨피그 맵과 시크릿 +클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. 컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다. + +#### 로그 뷰어 +파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다. 뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다. + +![Logs viewer](/images/docs/ui-dashboard-logs-view.png) + +{{% /capture %}} + +{{% capture whatsnext %}} + +더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다. + +{{% /capture %}} diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-master.md b/content/ko/docs/tasks/administer-cluster/highly-available-master.md new file mode 100644 index 0000000000..4f4a2ce184 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/highly-available-master.md @@ -0,0 +1,175 @@ +--- +reviewers: +title: 고가용성 쿠버네티스 클러스터 마스터 설정하기 +content_template: templates/task +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="1.5" state="alpha" >}} + +구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 마스터를 복제할 수 있다. +이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 마스터를 관리하는 방법과 GCE와 함께 사용하기 위해 HA 마스터를 구현하는 방법에 관해 설명한다. + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## HA 호환 클러스터 시작 + +새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다. + +* `MULTIZONE=true` - 서버의 기본 존(zone)과 다른 존에서 마스터 복제본의 kubelet이 제거되지 않도록 한다. +다른 존에서 마스터 복제본을 실행하려는 경우에 권장하고 필요하다. + +* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다. +true인 경우, Etcd의 리더 복제본에서 읽는다. +이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다. + +선택적으로 첫 번째 마스터 복제본이 생성될 GCE 존을 지정할 수 있다. +다음 플래그를 설정한다. + +* `KUBE_GCE_ZONE=zone` - 첫 마스터 복제본이 실행될 존. + +다음 샘플 커맨드는 europe-west1-b GCE 존에 HA 호환 클러스터를 구성한다. + +```shell +MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh +``` + +위에 커맨드는 하나의 마스터로 클러스터를 생성한다. +그러나 후속 커맨드로 새 마스터 복제본을 추가할 수 있다. + +## 새 마스터 복제본 추가 + +HA 호환 클러스터를 생성한 다음 그것의 마스터 복제본을 추가할 수 있다. +`kube-up` 스크립트에 다음 플래그를 사용하여 마스터 복제본을 추가한다. + +* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 마스터의 복제본을 +만든다. + +* `KUBE_GCE_ZONE=zone` - 마스터 복제본이 실행될 존. +반드시 다른 복제본 존과 동일한 존에 있어야 한다. + +HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로 +설정할 필요는 없다. + +다음 샘플 커맨드는 기존 HA 호환 클러스터에서 마스터를 복제한다. + +```shell +KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh +``` + +## 마스터 복제본 제거 + +다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 마스터 복제본을 제거할 수 있다. + +* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다. + +* `KUBE_GCE_ZONE=zone` - 마스터 복제본이 제거될 존. + +* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 마스터 복제본의 이름. +비어있는 경우, 해당 존의 모든 복제본이 제거된다. + +다음 샘플 커맨드는 기존 HA 클러스터에서 마스터 복제본을 제거한다. + +```shell +KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh +``` + +## 마스터 복제 실패 처리 + +HA 클러스터의 마스터 복제본 중 하나가 실패하면, +클러스터에서 복제본을 제거하고 동일한 존에서 새 복제본을 추가하는 것이 가장 좋다. +다음 샘플 커맨드로 이 과정을 시연한다. + +1. 손상된 복제본을 제거한다. + + ```shell + KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh + ``` + +1. 기존 복제본 대신 새 복제본을 추가한다. + + ```shell + KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh + ``` + +## HA 클러스터에서 마스터 복제에 관한 모범 사례 + +* 다른 존에 마스터 복제본을 배치하도록 한다. 한 존이 실패하는 동안, 해당 존에 있는 마스터도 모두 실패할 것이다. +존 장애를 극복하기 위해 노드를 여러 존에 배치한다 +(더 자세한 내용은 [멀티 존](/docs/setup/best-practices/multiple-zones/)를 참조한다). + +* 두 개의 마스터 복제본은 사용하지 않는다. 두 개의 복제 클러스터에 대한 합의는 지속적 상태를 변경해야 할 때 두 복제본 모두 실행해야 한다. +결과적으로 두 복제본 모두 필요하고, 어떤 복제본의 장애에도 클러스터가 대부분 장애 상태로 변한다. +따라서 두 개의 복제본 클러스터는 HA 관점에서 단일 복제 클러스터보다 열등하다. + +* 마스터 복제본을 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다. +클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다. +이 작업은 [여기](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) 기술한 대로 +Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다). + +{{% /capture %}} + +{{% capture discussion %}} + +## 구현 지침 + +![ha-master-gce](/images/docs/ha-master-gce.png) + +### 개요 + +각 마스터 복제본은 다음 모드에서 다음 구성 요소를 실행한다. + +* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다. + +* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다. + +* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다. + +* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다. + +또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다. + +### 로드 밸런싱 + +두 번째 마스터 복제본을 시작할 때, 두 개의 복제본을 포함된 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다. +비슷하게 끝에서 두 번째의 마스터 복제본을 제거한 후에는 로드 밸런서가 제거되고 +해당 IP 주소는 마지막으로 남은 복제본에 할당된다. +로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다. + +### 마스터 서비스와 Kubelet + +쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신, +시스템은 모든 트래픽을 외부 IP 주소로 보낸다. + +* 단일 마스터 클러스터에서 IP 주소는 단일 마스터를 가리킨다. + +* 다중 마스터 클러스터에서 IP 주소는 마스터 앞에 로드밸런서를 가리킨다. + +마찬가지로 Kubelet은 외부 IP 주소를 사용하여 마스터와 통신한다. + +### 마스터 인증서 + +쿠버네티스는 각 복제본의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 마스터 TLS 인증서를 발급한다. +복제본의 임시 공개 IP 주소에 대한 인증서는 없다. +임시 퍼블릭 IP 주소를 통해 복제본에 접근하려면, TLS 검증을 건너뛰어야 한다. + +### etcd 클러스터화 + +etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용). +이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다. + +## 추가 자료 + +[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) + +{{% /capture %}} diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/_index.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/_index.md new file mode 100644 index 0000000000..94d43ce6f0 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/_index.md @@ -0,0 +1,4 @@ +--- +title: 네트워크 폴리시 제공자(Network Policy Provider) 설치 +weight: 30 +--- diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md new file mode 100644 index 0000000000..209d07a3b0 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -0,0 +1,53 @@ +--- +reviewers: +title: 네트워크 폴리시로 캘리코(Calico) 사용하기 +content_template: templates/task +weight: 10 +--- + +{{% capture overview %}} +이 페이지는 쿠버네티스에서 캘리코(Calico) 클러스터를 생성하는 몇 가지 빠른 방법을 살펴본다. +{{% /capture %}} + +{{% capture prerequisites %}} +[클라우드](#creating-a-calico-cluster-with-google-kubernetes-engine-gke)나 [지역](#creating-a-local-calico-cluster-with-kubeadm) 클러스터 중에 어디에 배포할지 결정한다. +{{% /capture %}} + +{{% capture steps %}} +## 구글 쿠버네티스 엔진(GKE)에 캘리코 클러스터 생성하기 {#creating-a-calico-cluster-with-google-kubernetes-engine-gke} + +**사전요구사항**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts). + +1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가하면 된다. + + **문법** + ```shell + gcloud container clusters create [클러스터_이름] --enable-network-policy + ``` + + **예시** + ```shell + gcloud container clusters create my-calico-cluster --enable-network-policy + ``` + +1. 배포를 확인하기 위해, 다음 커맨드를 이용하자. + + ```shell + kubectl get pods --namespace=kube-system + ``` + + 캘리코 파드는 `calico`로 시작한다. 각각의 상태가 `Running`임을 확인하자. + +## kubeadm으로 지역 캘리코 클러스터 생성하기 {#creating-a-local-calico-cluster-with-kubeadm} + +Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러스터를 생성하려면, +[캘리코 빠른 시작](https://docs.projectcalico.org/latest/getting-started/kubernetes/)을 참고한다. + +{{% /capture %}} + + +{{% capture whatsnext %}} +클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해 +[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. +{{% /capture %}} + diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md new file mode 100644 index 0000000000..b0cba9681e --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -0,0 +1,106 @@ +--- +reviewers: +title: 네트워크 폴리시로 실리움(Cilium) 사용하기 +content_template: templates/task +weight: 20 +--- + +{{% capture overview %}} +이 페이지는 어떻게 네트워크 폴리시(NetworkPolicy)로 실리움(Cilium)를 사용하는지 살펴본다. + +실리움의 배경에 대해서는 [실리움 소개](https://cilium.readthedocs.io/en/stable/intro)를 읽어보자. +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} +## 기본 시험을 위해 실리움을 Minikube에 배포하기 + +실리움에 쉽게 친숙해지기 위해 +Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는 +[실리움 쿠버네티스 시작하기 안내](https://cilium.readthedocs.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다. + +Minikube를 시작하려면 최소 버전으로 >= v0.33.1 이 필요하고, +다음의 실행 파라미터로 실행한다. + +```shell +minikube version +``` +``` +minikube version: v0.33.1 +``` + +```shell +minikube start --network-plugin=cni --memory=4096 +``` + +Minikube에서 실리움의 데몬셋 구성과 Minikube에 배포된 etcd 인스턴스로 접속하는데 필요한 구성 뿐만 아니라 +RBAC 설정을 포함하는 필요한 구성을 +이 간단한 ``올인원`` YAML 파일로 배포할 수 있다. + +```shell +kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium-minikube.yaml +``` +``` +configmap/cilium-config created +daemonset.apps/cilium created +clusterrolebinding.rbac.authorization.k8s.io/cilium created +clusterrole.rbac.authorization.k8s.io/cilium created +serviceaccount/cilium created +``` + +시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여 +L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예, HTTP)의 보안 정책을 +적용하는 방법을 설명한다. + +## 실리움을 실 서비스 용도로 배포하기 + +실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은 +[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)를 살펴본다. +이 문서는 자세한 요구사항, 방법과 +실제 데몬셋 예시를 포함한다. + +{{% /capture %}} + +{{% capture discussion %}} +## 실리움 구성요소 이해하기 + +실리움으로 클러스터를 배포하면 파드가 `kube-system` 네임스페이스에 추가된다. +파드의 목록을 보려면 다음을 실행한다. + +```shell +kubectl get pods --namespace=kube-system +``` + +다음과 유사한 파드의 목록을 볼 것이다. + +```console +NAME READY STATUS RESTARTS AGE +cilium-6rxbd 1/1 Running 0 1m +... +``` + +알고 있어야 할 두 가지 주요 구성요소는 다음과 같다. + +- 먼저는 `cilium` 파드가 클러스터의 각 노드에서 운영되고, +노드의 파드로 보내고/받는 트래픽을 리눅스 BPF를 이용하여 네트워크 폴리시를 적용한다. +- 실 서비스에 배포하는 경우 실리움은 키-값 저장소(예, etcd)를 활용해야 한다. +[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)에서 +키-값 저장소를 설치하는 방법과 실리움에서 이를 구성하는 필수 단계를 +제공할 것이다. + +{{% /capture %}} + +{{% capture whatsnext %}} +클러스터가 동작하면, +실리움으로 쿠버네티스 네트워크 폴리시를 시도하기 위해 +[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. +재미있게 즐기고, 질문이 있다면 +[실리움 슬랙 채널](https://cilium.herokuapp.com/)을 이용하여 연락한다. +{{% /capture %}} + + diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md new file mode 100644 index 0000000000..1ff8d7c4cc --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md @@ -0,0 +1,25 @@ +--- +reviewers: +title: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기 +content_template: templates/task +weight: 30 +--- + +{{% capture overview %}} +이 페이지는 네트워크 폴리시(NetworkPolicy)로 [큐브 라우터(Kube-router)](https://github.com/cloudnativelabs/kube-router)를 사용하는 방법을 살펴본다. +{{% /capture %}} + +{{% capture prerequisites %}} +운영 중인 쿠버네티스 클러스터가 필요하다. 클러스터가 없다면, Kops, Bootkube, Kubeadm 등을 이용해서 클러스터를 생성할 수 있다. +{{% /capture %}} + +{{% capture steps %}} +## 큐브 라우터 애드온 설치하기 +큐브 라우터 애드온은 갱신된 모든 네트워크 폴리시 및 파드에 대해 쿠버네티스 API 서버를 감시하고, 정책에 따라 트래픽을 허용하거나 차단하도록 iptables 규칙와 ipset을 구성하는 네트워크 폴리시 컨트롤러와 함께 제공된다. 큐브 라우터 애드온을 설치하는 [큐브 라우터를 클러스터 인스톨러와 함께 사용하기](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) 안내서를 따라해 봅니다. +{{% /capture %}} + +{{% capture whatsnext %}} +큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. +{{% /capture %}} + + diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md new file mode 100644 index 0000000000..5e2c28a7c9 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -0,0 +1,42 @@ +--- +reviewers: +title: 네트워크 폴리시로 로마나(Romana) +content_template: templates/task +weight: 40 +--- + +{{% capture overview %}} + +이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다. + +{{% /capture %}} + +{{% capture prerequisites %}} + +[kubeadm 시작하기](/docs/getting-started-guides/kubeadm/)의 1, 2, 3 단계를 완료하자. + +{{% /capture %}} + +{{% capture steps %}} + +## kubeadm으로 로마나 설치하기 + +Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/romana/romana/tree/master/containerize)를 따른다. + +## 네트워크 폴리시 적용하기 + +네트워크 폴리시를 적용하기 위해 다음 중에 하나를 사용하자. + +* [Romana 네트워크 폴리시](https://github.com/romana/romana/wiki/Romana-policies). + * [Romana 네트워크 폴리시의 예](https://github.com/romana/core/blob/master/doc/policy.md). +* 네트워크 폴리시 API. + +{{% /capture %}} + +{{% capture whatsnext %}} + +로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. + +{{% /capture %}} + + diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md new file mode 100644 index 0000000000..91456a0385 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -0,0 +1,58 @@ +--- +reviewers: +title: 네트워크 폴리시로 위브넷(Weave Net) 사용하기 +content_template: templates/task +weight: 50 +--- + +{{% capture overview %}} + +이 페이지는 네트워크 폴리시(NetworkPolicy)로 위브넷(Weave Net)를 사용하는 방법을 살펴본다. + +{{% /capture %}} + +{{% capture prerequisites %}} + +쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 [kubeadm 시작하기 안내서](/docs/getting-started-guides/kubeadm/)를 따른다. + +{{% /capture %}} + +{{% capture steps %}} + +## Weave Net 애드온을 설치한다 + +[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kube-addon/) 가이드를 따른다. + +쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의 네크워크 정책 어노테이션을 자동으로 모니터링하며, 정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는 [네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다. + +## 설치 시험 + +위브넷이 동작하는지 확인한다. + +다음 커맨드를 입력한다. + +```shell +kubectl get pods -n kube-system -o wide +``` + +출력은 다음과 유사하다. + +``` +NAME READY STATUS RESTARTS AGE IP NODE +weave-net-1t1qg 2/2 Running 0 9d 192.168.2.10 worknode3 +weave-net-231d7 2/2 Running 1 7d 10.2.0.17 worknodegpu +weave-net-7nmwt 2/2 Running 3 9d 192.168.2.131 masternode +weave-net-pmw8w 2/2 Running 0 9d 192.168.2.216 worknode2 +``` + +위브넷 파드를 가진 각 노드와 모든 파드는 `Running`이고 `2/2 READY`이다(`2/2`는 각 파드가 `weave`와 `weave-npc`를 가지고 있음을 뜻한다). + +{{% /capture %}} + +{{% capture whatsnext %}} + +위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다. + +{{% /capture %}} + + diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index ca5003a98d..b314f9683c 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -6,7 +6,7 @@ content_template: templates/concept {{% capture overview %}} 쿠버네티스 1.8 부터 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 -쿠버네티스의 Metrics API를 통해 사용할 수 있다. 이 메트릭은 +쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은 `kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. @@ -15,9 +15,9 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 {{% capture body %}} -## Metrics API +## 메트릭 API -Metrics API를 통해 주어진 노드나 파드에서 현재 사용중인 +메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인 리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지 않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을 가져오는 것과 같은 일을 할 수는 없다. @@ -31,23 +31,23 @@ Metrics API를 통해 주어진 노드나 파드에서 현재 사용중인 리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다. {{< note >}} -이 API를 사용하려면 Metrics server를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다. +이 API를 사용하려면 메트릭 서버를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다. {{< /note >}} -## Metrics Server +## 메트릭 서버 -[Metrics server](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. -쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 Metrics server가 +[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. +쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 -[배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 Metrics server를 배포할 수 있다. +[배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 메트릭 서버를 배포할 수 있다. 이 방식은 쿠버네티스 1.7 이상에서 지원된다. (상세 사항은 아래를 참조) -Metric server는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다. +메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다. -Metrics server는 쿠버네티스 1.7에서 도입된 +메트릭 서버는 쿠버네티스 1.7에서 도입된 [쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를 통해 메인 API 서버에 등록된다. -[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 Metrics server에 대해 자세하게 배울 수 있다. +[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다. {{% /capture %}} diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index 41e33f80d2..b0a175ee11 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -19,98 +19,40 @@ title: 리소스 모니터링 도구 {{% capture body %}} 쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. -신규 클러스터에서는 기본적으로 두 개의 개별 파이프라인을 사용하여 모니터링 통계를 +신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 +메트릭 파이프라인](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다. -- [**리소스 메트릭 파이프라인**](#리소스-메트릭-파이프라인)은 HorizontalPodAutoscaler - 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로 - 제한된 집합을 제공한다. 이 메트릭은 - [metrics-server](https://github.com/kubernetes-incubator/metrics-server) - 에 의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. `metrics-server`는 클러스터 - 상의 모든 노드를 발견하고 각 노드의 - [Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리 - 사용량을 질의한다. Kubelet은 [cAdvisor](https://github.com/google/cadvisor)에서 - 데이터를 가져온다. `metrics-server`는 경량의 단기 인메모리 저장소이다. - -- 프로메테우스 같이 [**완전한 메트릭 파이프라인**](#완전한-메트릭-파이프라인)은 보다 풍부한 - 메트릭에 액세스할 수 있게 해준다. 추가적으로 쿠버네티스는 Horizontal Pod Autoscaler와 - 같은 메커니즘을 사용하여 현재 상태를 기반으로 클러스터를 자동으로 확장 또는 - 조정함으로써 이런 메트릭에 응답할 수 있다. 모니터링 파이프라인은 Kubelet에서 - 메트릭을 가져온 다음 `custom.metrics.k8s.io` 이나 - `external.metrics.k8s.io` API로 구현된 어댑터를 통해 - 이들을 쿠버네티스에 노출한다. - ## 리소스 메트릭 파이프라인 -### Kubelet +리소스 메트릭 파이프라인은 +[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) +컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 +메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인 +[metrics-server](https://github.com/kubernetes-incubator/metrics-server)에 +의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. -Kubelet은 쿠버네티스 마스터와 노드들 사이의 다리 역할을 한다. 이는 머신 상에서 실행되는 파드들과 컨테이너들을 관리한다. Kubelet은 각 파드를 이를 구성하는 컨테이너들로 변환하며 컨테이너 런타임 인터페이스를 통해 컨테이너 런타임에서 개별 컨테이너의 사용량 통계를 가져온다. 레거시 도커 통합에서는 cAdvisor에서 이 정보를 가져온다. 그런 다음 Kubelet 리소스 메트릭 API를 통해 집계된 파드 리소스 사용량 통계를 노출한다. 이 API는 Kubelet의 인증되고 읽기 전용의 포트들 상에서 `/metrics/resource/v1alpha1`으로 제공된다. - -### cAdvisor - -cAdvisor는 오픈 소스 컨테이너 자원 사용률/성능 분석 에이전트이다. 이는 컨테이너 전용으로 설계되었으며 도커 컨테이너를 기본적으로 지원한다. 쿠버네티스에서 cAdvisor는 Kubelet 바이너리와 통합된다. cAdvisor는 머신 내 모든 컨테이너를 자동으로 발견하며 CPU, 메모리, 파일시스템, 네트워크 사용량 통계를 수집한다. cAdvisor는 또한 machine 상의 'root' 컨테이너 분석에 의한 전체 머신 사용량도 제공한다. - -Kubelet은 기본 포트 4194를 통해 머신의 컨테이너에 대한 단순한 cAdvisor UI를 노출한다. -아래 그림은 전체 머신의 사용량을 예제로 보여준다. 하지만, 이 기능은 v1.10에서는 사용 중단(deprecated)으로 -표시되었으며, v1.12에서는 완전히 제거되었다. - -![cAdvisor](/images/docs/cadvisor.png) - -v1.13부터, [cAdvisor를 데몬셋으로 배포](https://github.com/google/cadvisor/tree/master/deploy/kubernetes)하여 cAdvisor UI에 액세스할 수 있다. +metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의 +[Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리 +사용량을 질의한다. Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서 +머신에서 구동되는 파드와 컨테이너를 관리한다. Kubelet은 각각의 파드를 해당하는 +컨테이너로 변환하고 컨테이너 런타임 인터페이스를 통해서 컨테이너 런타임에서 +개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의 +통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져온다. 그 다음으로 취합된 파드 +리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출한다. 이 API는 +kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서 +제공된다. ## 완전한 메트릭 파이프라인 -쿠버네티스를 위한 많은 완전한 메트릭 솔루션들이 존재한다. +완전한 메트릭 파이프라인은 보다 풍부한 메트릭에 접근할 수 있도록 해준다. +쿠버네티스는 Horizontal Pod Autoscaler와 같은 메커니즘을 활용해서 이런 메트릭에 +대한 반응으로 클러스터의 현재 상태를 기반으로 자동으로 스케일링하거나 클러스터를 +조정할 수 있다. 모니터링 파이프라인은 kubelet에서 메트릭을 가져와서 쿠버네티스에 +`custom.metrics.k8s.io`와 `external.metrics.k8s.io` API를 구현한 어댑터를 통해 +노출한다. -### 프로메테우스 - -[프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다. -[Prometheus Operator](https://coreos.com/operators/prometheus/docs/latest/)는 -쿠버네티스에서 프로메테우스 설정을 단순화하고, -[Prometheus adapter](https://github.com/directxman12/k8s-prometheus-adapter)를 -사용하여 커스텀 메트릭 API를 제공할 수 있게 해준다. -프로메테우스는 강력한 쿼리 언어와 데이터 쿼리와 시각화를 위한 내장 대시보드를 제공한다. -또한 [Grafana](https://prometheus.io/docs/visualization/grafana/)에서는 -데이터 소스로 프로메테우스가 지원된다. - -### Sysdig -[Sysdig](http://sysdig.com)는 완전한 스펙트럼 컨테이너와 플랫폼 인텔리전스를 제공하며, -진정한 컨테이너 네이티브 솔루션이다. Sysdig는 시스템 호출, 쿠버네티스 이벤트, 프로메테우스 메트릭, -statsD, JMX 등의 데이터를 하나의 창으로 통합하여 환경에 대한 포괄적인 그림을 제공한다. -또한 Sysdig는 강력하고 사용자 정의가 가능한 솔루션을 제공하기 위해 쿼리를 실행할 수 있는 API를 제공한다. -Sysdig는 오픈 소스로 만들어졌다. [Sysdig와 Sysdig Inspect](https://sysdig.com/opensource/inspect/)는 -자유롭게 트러블슈팅, 분석, 포렌식을 수행할 수 있는 기능을 제공한다. - -### 구글 클라우드 모니터링 - -구글 클라우드 모니터링은 호스팅 모니터링 서비스로 애플리케이션의 -중요한 메트릭을 시각화하고 경고하는데 사용할 수 있으며, -쿠버네티스에서 메트릭을 수집하고 -[Cloud Monitoring Console](https://app.google.stackdriver.com/)을 -통해 이 메트릭들에 접근할 수 있다. 대시보드를 만들고 사용자 정의하여 쿠버네티스 클러스터에서 -수집한 데이터를 시각화할 수 있다. - -이 동영상은 힙스터(Heapster)를 기반으로 구글 클라우드 모니터링을 구성하고 실행하는 방법을 보여준다. - -[![힙스터를 기반으로 구글 클라우드 모니터링을 구성하고 실행하는 방법](https://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](https://www.youtube.com/watch?v=xSMNR2fcoLs) - - -{{< figure src="/images/docs/gcm.png" alt="구글 클라우드 모니터링 대시보드 예제" title="구글 클라우드 모니터링 대시보드 예제" caption="대시보드는 클러스터 전역의 리소스 사용량을 보여준다." >}} - -## 크론잡 모니터링 - -### Kubernetes Job Monitor - -[Kubernetes Job Monitor](https://github.com/pietervogelaar/kubernetes-job-monitor) 대시보드를 사용하여 클러스터 관리자는 실행되고 있는 잡들과 완료된 잡의 상태를 볼 수 있다. - -### New Relic 쿠버네티스 모니터링 통합 - -[New Relic 쿠버네티스](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration) 통합은 쿠버네티스 환경의 성능에 대한 가시성을 향상시킨다. New Relic의 쿠버네티스 통합은 쿠버네티스 오브젝트의 메트릭을 리포팅하는 것으로 컨테이너 오케스트레이션 계층을 측정한다. 통합을 통해 쿠버네티스 노드, 네임스페이스, 디플로이먼트, 레플리카 셋, 파드, 컨테이너에 대한 인사이트를 얻을 수 있다. - -중요 기능: -사전 구축된 대시보드에서 데이터를 확인하여 쿠버네티스 환경에 대한 즉각적인 인사이트를 확인한다. -자동으로 보고되는 데이터의 인사이트로 커스텀 쿼리와 차트를 생성한다. -쿠버네티스 데이터에 대해 경고 조건을 생성한다. -이 [페이지](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration)에서 더 알아볼 수 있다. +CNCF 프로젝트인, [프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다. +CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는 쿠버네티스 문서의 범위가 아니다. {{% /capture %}} diff --git a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md new file mode 100644 index 0000000000..639668b3f9 --- /dev/null +++ b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md @@ -0,0 +1,158 @@ +--- +title: 컨테이너를 위한 커맨드와 인자 정의하기 +content_template: templates/task +weight: 10 +--- + +{{% capture overview %}} + +본 페이지는 {{< glossary_tooltip text="파드" term_id="pod" >}} 안에서 컨테이너를 실행할 +때 커맨드와 인자를 정의하는 방법에 대해 설명한다. + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + +## 파드를 생성할 때 커맨드와 인자를 정의하기 + +파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 커맨드와 인자를 +정의할 수 있다. 커맨드를 정의하기 위해서는, 파드 안에서 실행되는 컨테이너에 +`command` 필드를 포함시킨다. 커맨드에 대한 인자를 정의하기 위해서는, 구성 +파일에 `args` 필드를 포함시킨다. 정의한 커맨드와 인자들은 파드가 생성되고 +난 이후에는 변경될 수 없다. + +구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가 +제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을 +정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와 +함께 사용된다. + +{{< note >}} +`command` 필드는 일부 컨테이너 런타임에서 `entrypoint`에 해당된다. +아래의 [참고사항](#참고사항)을 확인하자. +{{< /note >}} + +이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 +파일에서 커맨드와 두 개의 인자를 정의한다. + +{{< codenew file="pods/commands.yaml" >}} + +1. YAML 구성 파일을 활용해 파드를 생성한다. + + ```shell + kubectl apply -f https://k8s.io/examples/pods/commands.yaml + ``` + +1. 실행 중인 파드들의 목록을 조회한다. + + ```shell + kubectl get pods + ``` + + 출력은 command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 표시할 + 것이다. + +1. 컨테이너 안에서 실행된 커맨드의 출력을 보기 위해, 파드의 로그를 +확인한다. + + ```shell + kubectl logs command-demo + ``` + + 출력은 HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들을 표시할 + 것이다. + + ``` + command-demo + tcp://10.3.240.1:443 + ``` + +## 인자를 정의하기 위해 환경 변수를 사용하기 + +이전 예제에서는, 문자열을 제공하면서 직접 인자를 정의해보았다. +문자열을 직접 제공하는 것에 대한 대안으로, 환경 변수들을 사용하여 인자들을 +정의할 수 있다. + +```yaml +env: +- name: MESSAGE + value: "hello world" +command: ["/bin/echo"] +args: ["$(MESSAGE)"] +``` + +이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure +-pod-configmap/)과 [시크릿](/docs/concepts/configuration/secret/)을 +포함해, 환경 변수를 정의하는데 활용할 수 있는 모든 방법들을 활용해서 파드를 위한 인자를 +정의할 +수 있다는 것을 의미한다. + +{{< note >}} +환경 변수는 `"$(VAR)"`와 같이 괄호 안에 나타난다. 이는 변수가 `command`나 `args` +필드 안에서 전개되기 위해 필요한 것이다. +{{< /note >}} + +## 셸 안에서 커맨드 실행하기 + +일부 경우들에서는 커맨드를 셸 안에서 실행해야할 필요가 있다. 예를 들어, 실행할 커맨드가 +서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서 +커맨드를 실행하려고 한다면, 이런 방식으로 감싸주면 된다. + +```shell +command: ["/bin/sh"] +args: ["-c", "while true; do echo hello; sleep 10;done"] +``` + +## 참고사항 + +이 테이블은 도커와 쿠버네티스에서 사용되는 필드 이름들을 정리한 것이다. + +| 설명 | 도커 필드 이름 | 쿠버네티스 필드 이름 | +|----------------------------------------|------------------------|-----------------------| +| 컨테이너에서 실행되는 커맨드 | Entrypoint | command | +| 커맨드에 전달되는 인자들 | Cmd | arg | + +기본 Entrypoint와 Cmd 값을 덮어쓰려고 한다면, 아래의 규칙들이 적용된다. + +* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에 +제공되는 기본 값들이 사용된다. + +* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면, +제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본 +Cmd 값은 덮어쓰여진다. + +* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint +값이 정의한 `args` 값들과 함께 실행된다. + +* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본 +EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께 +실행된다. + +여기 몇 가지 예시들이 있다. + +| 이미지 Entrypoint | 이미지 Cmd | 컨테이너 command | 컨테이너 args | 실행되는 커맨드 | +|--------------------|------------------|---------------------|--------------------|------------------| +| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | <설정되지 않음> | `[ep-1 foo bar]` | +| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <설정되지 않음> | `[ep-2]` | +| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | `[zoo boo]` | `[ep-1 zoo boo]` | +| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` | + + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다. +* [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다. +* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다. + +{{% /capture %}} + + diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index ee7cf0093a..4b63acd807 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -60,7 +60,7 @@ index.php는 CPU 과부하 연산을 수행한다. 첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다. ```shell -kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80 +kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80 ``` ``` service/php-apache created @@ -285,7 +285,7 @@ HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수 `kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다. ```yaml -apiVersion: autoscaling/v2beta1 +apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: php-apache diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 80100f534d..5d80c63981 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -18,17 +18,19 @@ card: {{< tabs name="minikube_before_you_begin" >}} {{% tab name="리눅스" %}} 리눅스에서 가상화 지원 여부를 확인하려면, 아래의 명령을 실행하고 출력이 비어있지 않은지 확인한다. -```shell -egrep --color 'vmx|svm' /proc/cpuinfo +``` +grep -E --color 'vmx|svm' /proc/cpuinfo ``` {{% /tab %}} + {{% tab name="맥OS" %}} 맥OS에서 가상화 지원 여부를 확인하려면, 아래 명령어를 터미널에서 실행한다. ``` -sysctl -a | grep machdep.cpu.features +sysctl -a | grep -E --color 'machdep.cpu.features|VMX' ``` -만약 출력 중에 `VMX`를 볼 수 있다면 VT-x 기능을 운영체제에서 지원한다. +만약 출력 중에 (색상으로 강조된) `VMX`를 볼 수 있다면, VT-x 기능이 머신에서 활성화된 것이다. {{% /tab %}} + {{% tab name="윈도우" %}} 윈도우 8 이후 버전에서 가상화 지원 여부를 확인하려면, 다음 명령어를 윈도우 터미널이나 명령 프롬프트에서 실행한다. ``` @@ -73,7 +75,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) {{< note >}} -Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경을 필요로 한다. +Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. {{< /note >}} ### 패키지를 이용하여 Minikube 설치 @@ -158,14 +160,14 @@ Hyper-V는 다음 세 버전의 윈도우 10에서 실행할 수 있다. Windows 윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다(관리자 권한으로 실행). ```shell -choco install minikube kubernetes-cli +choco install minikube ``` Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube 실행 파일의 경로는 실행 경로(path)에 자동으로 추가된다. ### 인스톨러 실행파일을 통한 Minikube 설치 -윈도우에서 수동으로 [Windows 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다. +[윈도우 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)를 사용하여 윈도우에 Minikube를 수동으로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다. ### 직접 다운로드하여 Minikube 설치 diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index be7cb5f61d..27db50cdf1 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -96,6 +96,11 @@ kubectl exec -it redis redis-cli 2) "allkeys-lru" ``` +생성된 파드를 삭제한다. +```shell +kubectl delete pod redis +``` + {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index a7f8e8bfec..f9d24d711d 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -102,13 +102,13 @@ weight: 10

+

+ 첫 번째 디플로이먼트로, 도커 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자. + (Node.js 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면, + Hello Minikube 튜토리얼의 지시를 따른다.)

+

-

우리의 첫 번째 디플로이먼트로, Docker 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자. - Node.js 애플리케이션을 작성하고 Docker 컨테이너를 배포하기 위해서, - Hello Minikube 튜토리얼의 지시를 따른다.

- -

이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자!

- +

이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자!


diff --git a/content/ko/docs/tutorials/online-training/overview.md b/content/ko/docs/tutorials/online-training/overview.md index 402cb29a10..6311540391 100644 --- a/content/ko/docs/tutorials/online-training/overview.md +++ b/content/ko/docs/tutorials/online-training/overview.md @@ -43,6 +43,8 @@ content_template: templates/concept * [Kubernetes for the Absolute Beginners with Hands-on Labs (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on) +* [Kubernetes Fundamentals (LFS258) (The Linux Foundation)](https://training.linuxfoundation.org/training/kubernetes-fundamentals/) + * [Kubernetes Quick Start with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start) * [Kubernetes the Hard Way with Hands-On Labs (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way) diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 2014c301a7..991d43262c 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -92,6 +92,13 @@ EOF {{< codenew file="application/wordpress/mysql-deployment.yaml" >}} +다음의 매니페스트는 단일-인스턴스 WordPress 디플로이먼트를 기술한다. WordPress 컨테이너는 +웹사이트 데이터 파일을 위해 `/var/www/html`에 퍼시스턴트볼륨을 마운트한다. `WORDPRESS_DB_HOST` 환경 변수에는 +위에서 정의한 MySQL 서비스의 이름이 설정되며, WordPress는 서비스를 통해 데이터베이스에 접근한다. +`WORDPRESS_DB_PASSWORD` 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다. + +{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}} + 1. MySQL 디플로이먼트 구성 파일을 다운로드한다. ```shell diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index 23aeaa2165..8c921c9f77 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -146,12 +146,12 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml 서비스를 삭제하려면, 아래의 명령어를 입력한다. - kubectl delete services my-service + kubectl delete services my-service Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카 셋, 파드를 삭제하려면, 아래의 명령어를 입력한다. - kubectl delete deployment hello-world + kubectl delete deployment hello-world {{% /capture %}} diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md new file mode 100644 index 0000000000..01c24a16f9 --- /dev/null +++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -0,0 +1,401 @@ +--- +title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가" +reviewers: +content_template: templates/tutorial +weight: 21 +card: + name: tutorials + weight: 31 + title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가" +--- + +{{% capture overview %}} +이 튜토리얼은 [Redis를 이용한 PHP 방명록](../guestbook) 튜토리얼을 기반으로 한다. Elastic의 경량 로그, 메트릭, 네트워크 데이터 오픈소스 배송기인 *Beats* 를 방명록과 동일한 쿠버네티스 클러스터에 배포한다. Beats는 데이터를 수집하고 구문분석하여 Elasticsearch에 색인화하므로, Kibana에서 동작 정보를 결과로 보며 분석할 수 있다. 이 예시는 다음과 같이 구성되어 있다. + +* [Redis를 이용한 PHP 방명록](../guestbook)을 실행한 인스턴스 +* Elasticsearch와 Kibana +* Filebeat +* Metricbeat +* Packetbeat + +{{% /capture %}} + +{{% capture objectives %}} +* Redis를 이용한 PHP 방명록 시작. +* kube-state-metrics 설치. +* 쿠버네티스 시크릿 생성. +* Beats 배포. +* 로그와 메트릭의 대시보드 보기. +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} +{{< version-check >}} + +추가로 다음이 필요하다. + +* 실행 중인 [Redis를 이용한 PHP 방명록](../guestbook) 튜토리얼의 배포본. + +* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나, [파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) 워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다. + +{{% /capture %}} + +{{% capture lessoncontent %}} + +## Redis를 이용한 PHP 방명록 시작 +이 튜토리얼은 [Redis를 이용한 PHP 방명록](../guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자. + +## 클러스터 롤 바인딩 추가 +[클러스터 단위 롤 바인딩](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다. + +```shell +kubectl create clusterrolebinding cluster-admin-binding \ + --clusterrole=cluster-admin --user= +``` + +## kube-state-metrics 설치 + +[*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다. + +### kube-state-metrics 실행 여부 확인 +```shell +kubectl get pods --namespace=kube-system | grep kube-state +``` +### 필요하면 kube-state-metrics 설치 + +```shell +git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics +kubectl create -f kube-state-metrics/kubernetes +kubectl get pods --namespace=kube-system | grep kube-state +``` +kube-state-metrics이 실행 중이고 준비되었는지 확인한다. +```shell +kubectl get pods -n kube-system -l k8s-app=kube-state-metrics +``` + +출력 +```shell +NAME READY STATUS RESTARTS AGE +kube-state-metrics-89d656bf8-vdthm 2/2 Running 0 21s +``` +## Elastic의 예제를 GitHub 리포지터리에 클론한다. +```shell +git clone https://github.com/elastic/examples.git +``` + +나머지 커맨드는 `examples/beats-k8s-send-anywhere` 디렉터리의 파일을 참조할 것이라서, 그쪽으로 현재 디렉터리를 변경한다. +```shell +cd examples/beats-k8s-send-anywhere +``` + +## 쿠버네티스 시크릿 만들기 +쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}은 암호나 토큰, 키 같이 소량의 민감한 데이터를 포함하는 오브젝트이다. 이러한 정보는 다른 방식으로도 파드 스펙이나 이미지에 넣을 수 있을 것이다. 시크릿 오브젝트에 넣으면 이것이 어떻게 사용되는지 다양하게 제어할 수 있고, 우발적인 노출 사고의 위험이 줄일 수 있다. + +{{< note >}} +여기에는 방식이 나뉘는데, 하나는 *자체 관리(Self managed)* 로 Elasticsearch와 Kibana(Elastic의 Helm 차트를 이용하여 사용자 서버를 구동하는)를 사용하는 경우이고 다른 경우는 Elastic Cloud의 Elasticsearch 서비스의 *관리 서비스(Managed service)* 를 사용하는 방식이다. 이 튜토리얼에서는 사용할 Elasticsearch와 Kibana 시스템의 종류에 따라 시크릿을 만들어야 한다. +{{< /note >}} + +{{< tabs name="tab_with_md" >}} +{{% tab name="자체 관리(Self Managed)" %}} + +### 자체 관리 +Elastic Cloud의 Elasticsearch 서비스로 연결한다면 **관리 서비스** 탭으로 전환한다. + +### 자격증명(credentials) 설정 +자체 관리 Elasticsearch와 Kibana(자체 관리는 사실상 Elastic Cloud의 관리 서비스 Elasticsearch와 다르다) 서비스에 접속할 때에 4개 파일을 수정하여 쿠버네티스 시크릿을 생성한다. 파일은 다음과 같다. + +1. ELASTICSEARCH_HOSTS +1. ELASTICSEARCH_PASSWORD +1. ELASTICSEARCH_USERNAME +1. KIBANA_HOST + +이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시가 있다. + +#### `ELASTICSEARCH_HOSTS` +1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup). + + ```shell + ["http://elasticsearch-master.default.svc.cluster.local:9200"] + ``` +1. Mac을 위한 Docker에서 Beats를 운영 중인 Mac에서 운영하는 단일 Elasticsearch 노드. + + ```shell + ["http://host.docker.internal:9200"] + ``` +1. VM이나 물리 장비에서 운영 중인 두 개의 ELASTICSEARCH 노드. + + ```shell + ["http://host1.example.com:9200", "http://host2.example.com:9200"] + ``` +`ELASTICSEARCH_HOSTS` 수정한다. +```shell +vi ELASTICSEARCH_HOSTS +``` + +#### `ELASTICSEARCH_PASSWORD` +화이트 스페이스나 인용 부호나 <> 도 없는 암호이다. + + <사용자의 시크릿 암호> + +`ELASTICSEARCH_PASSWORD` 수정한다. +```shell +vi ELASTICSEARCH_PASSWORD +``` + +#### `ELASTICSEARCH_USERNAME` +화이트 스페이스나 인용 부호나 <> 도 없는 이름이다. + + + +`ELASTICSEARCH_USERNAME` 수정한다. +```shell +vi ELASTICSEARCH_USERNAME +``` + +#### `KIBANA_HOST` + +1.Elastic의 Kibana Helm 차트의 인스턴스이다. 하위 도메인 `default`는 기본 네임스페이스를 참조한다. 다른 네임스페이스를 사용하여 Helm 차트를 배포한 경우 하위 도메인이 다릅니다. + + ```shell + "kibana-kibana.default.svc.cluster.local:5601" + ``` +1. Mac 용 Docker에서 실행하는 Beats가 있는 Mac에서 실행하는 Kibana 인스턴스 + + ```shell + "host.docker.internal:5601" + ``` +1. 가상머신이나 물리적 하드웨어에서 실행 중인 두 개의 Elasticsearch 노드 + + ```shell + "host1.example.com:5601" + ``` +`KIBANA_HOST`를 편집한다. +```shell +vi KIBANA_HOST +``` + +### 쿠버네티스 시크릿 만들기 +이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(kube-system)에 시크릿을 만든다. + + kubectl create secret generic dynamic-logging \ + --from-file=./ELASTICSEARCH_HOSTS \ + --from-file=./ELASTICSEARCH_PASSWORD \ + --from-file=./ELASTICSEARCH_USERNAME \ + --from-file=./KIBANA_HOST \ + --namespace=kube-system + +{{% /tab %}} +{{% tab name="관리 서비스(Managed service)" %}} + +## 관리 서비스 +이 탭은 Elastic Cloud에서 Elasticsearch 서비스 만에 대한 것으로, 이미 자체 관리 Elasticsearch와 Kibana 배포로 시크릿을 생성했다면, [Beats 배포](#deploy-the-beats)를 계속한다. +### 자격증명(credentials) 설정 +Elastic Cloud에서 관리되는 Elastic 서비스에 연결할 때, 쿠버네티스 시크릿을 생성하기 위해 편집할 두 파일이 있다. 파일은 다음과 같다. + +1. ELASTIC_CLOUD_AUTH +1. ELASTIC_CLOUD_ID + +디플로이먼트를 생성할 때에 Elasticsearch 콘솔에서 제공한 정보로 이를 설정한다. 여기 예시들이 있다. + +#### ELASTIC_CLOUD_ID +```shell +devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ== +``` + +#### ELASTIC_CLOUD_AUTH +사용자 이름, 콜론(`:`) 및 비밀번호인데, 공백 또는 따옴표는 없다. +```shell +elastic:VFxJJf9Tjwer90wnfTghsn8w +``` + +### 필요 파일 편집하기 +```shell +vi ELASTIC_CLOUD_ID +vi ELASTIC_CLOUD_AUTH +``` +### 쿠버네티스 시크릿 생성하기 +이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(kube-system)에 시크릿을 생성한다. + + kubectl create secret generic dynamic-logging \ + --from-file=./ELASTIC_CLOUD_ID \ + --from-file=./ELASTIC_CLOUD_AUTH \ + --namespace=kube-system + + {{% /tab %}} +{{< /tabs >}} + +## Beats 배포하기 {#deploy-the-beats} +각 Beat마다 메니페스트 파일을 제공한다. 이 메니페스트 파일은 앞서 생성한 시크릿을 사용하여, Elasticsearch 및 Kibana 서버에 연결하도록 Beats를 구성한다. + +### Filebeat에 대해 +Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파드에서 실행되는 컨테이너의 로그를 수집한다. Filebeat는 {{< glossary_tooltip text="데몬 셋" term_id="daemonset" >}}으로 배포한다. Filebeat는 쿠버네티스 클러스터에서 실행 중인 애플리케이션을 자동 검색할 수 있다. 시작시에 Filebeat는 기존 컨테이너를 검색하고 이에 적절한 구성을 시작하고 새 시작/종료 이벤트를 감시한다. + +아래 내용은 Filebeat가 방명록 애플리케이션과 함께 배포된 Redis 컨테이너에서 Redis 로그를 찾아 구문분석할 수 있게 하는 자동 검색 구성이다. 이 구성은 `filebeat-kubernetes.yaml`파일에 있다. + +```yaml +- condition.contains: + kubernetes.labels.app: redis + config: + - module: redis + log: + input: + type: docker + containers.ids: + - ${data.kubernetes.container.id} + slowlog: + enabled: true + var.hosts: ["${data.host}:${data.port}"] +``` +이것은 `redis` 컨테이너가 `app` 문자열을 포함하는 레이블로 감지될 때에 Filebeat 모듈 `redis`를 적용하도록 Filebeat를 구성한다. Redis 모듈은 Docker 입력 유형을 사용하여 컨테이너에서 `로그` 스트림을 수집할 수 있다(이 Redis 컨테이너의 STDOUT 스트림과 연관된 쿠버네티스 노드에서 파일 읽기). 또한 이 모듈은 컨테이너 메타 데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 Redis의 `slowlog` 항목을 수집할 수 있다. + +### Filebeat 배포 +```shell +kubectl create -f filebeat-kubernetes.yaml +``` + +#### 확인 +```shell +kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic +``` + +### Metricbeat에 대해 +Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음은 Redis 컨테이너에 대한 Metricbeat의 자동 검색 구성이다. 이 구성은 `metricbeat-kubernetes.yaml`에 있다. +```yaml +- condition.equals: + kubernetes.labels.tier: backend + config: + - module: redis + metricsets: ["info", "keyspace"] + period: 10s + + # Redis hosts + hosts: ["${data.host}:${data.port}"] +``` +이것은 컨테이너가 `tier` 레이블이 `backend` 문자열과 같은 레이블로 감지될 때에 Metricbeat 모듈 `redis`를 적용하도록 Metricbeat를 구성한다. `redis` 모듈은 컨테이너 메타데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 컨테이너에서 `info` 및 `keyspace` 메트릭을 수집할 수 있다. + +### Metricbeat 배포 +```shell +kubectl create -f metricbeat-kubernetes.yaml +``` +#### 확인 +```shell +kubectl get pods -n kube-system -l k8s-app=metricbeat +``` + +### Packetbeat에 대해 +Packetbeat 구성은 Filebeat와 Metricbeat와는 다르다. 컨테이너 레이블과 일치시킬 패턴을 지정하지 않고, 구성은 관련 프로토콜 및 포트 번호를 기반으로 한다. 아래는 포트 번호의 하위 집합이다. + +{{< note >}} +비표준 포트로 서비스를 실행했다면 해당 포트를 `filebeat.yaml`에 적절한 유형에 추가하고, Packetbeat 데몬 셋을 삭제하고 생성한다. +{{< /note >}} + +```yaml +packetbeat.interfaces.device: any + +packetbeat.protocols: +- type: dns + ports: [53] + include_authorities: true + include_additionals: true + +- type: http + ports: [80, 8000, 8080, 9200] + +- type: mysql + ports: [3306] + +- type: redis + ports: [6379] + +packetbeat.flows: + timeout: 30s + period: 10s +``` + +#### Packetbeat 배포하기 +```shell +kubectl create -f packetbeat-kubernetes.yaml +``` + +#### 확인하기 +```shell +kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic +``` + +## Kibana에서 보기 + +브라우저에서 Kibana를 열고, **대시보드** 애플리케이션을 열어보자. 검색창에 kubernetes를 입력하고 쿠버네티스를 위한 Metricbeat 대시보드를 클릭한다. 이 대시보드에는 노드 상태, 배포 등의 보고 내용이 있다. + +대시보드 페이지에 Packetbeat를 검색하고 Packetbeat의 개요 페이지를 살펴보자. + +마찬가지로 Apache와 Redis를 위한 대시보드를 확인한다. 각 로그와 메트릭에 대한 대시보드가 표시된다. 이 Apache Metricbeat 대시보드는 비어 있다. Apache Filebeat 대시보드를 보고, 맨 아래로 스크롤하여 Apache 오류 로그를 확인한다. Apache에서 보여줄 메트릭이 없는 이유를 알려줄 것이다. + +Metricbeat에서 Apache 메트릭을 가져올 수 있게 하려면, mod-status 구성 파일을 포함한 컨피그맵을 추가하고 방명록을 재배포하여 서버 상태를 활성화해야 한다. + + +## 디플로이먼트를 확장하고 모니터링중인 새 파드를 확인하기 +기존 디플로이먼트를 확인한다. +```shell +kubectl get deployments +``` + +출력 +```shell +NAME READY UP-TO-DATE AVAILABLE AGE +frontend 3/3 3 3 3h27m +redis-master 1/1 1 1 3h27m +redis-slave 2/2 2 2 3h27m +``` + +front의 디플로이먼트를 두 개의 파드로 축소한다. +```shell +kubectl scale --replicas=2 deployment/frontend +``` +출력 +```shell +deployment.extensions/frontend scaled +``` + +## Kibana에서 변화 확인하기 +스크린 캡처를 확인하여, 표시된 필터를 추가하고 해당 열을 뷰에 추가한다. ScalingReplicaSet 항목이 표시되고, 여기에서 이벤트 목록의 맨 위에 풀링되는 이미지, 마운트된 볼륨, 파드 시작 등을 보여준다. +![Kibana 디스커버리](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-discover.png) + +{{% /capture %}} + +{{% capture cleanup %}} +디플로이먼트와 서비스를 삭제하면 실행중인 파드도 삭제된다. 한 커맨드로 여러 개의 리소스를 삭제하기 위해 레이블을 이용한다. + +1. 다음 커맨드를 실행하여 모든 파드, 디플로이먼트, 서비스를 삭제한다. + + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment -l app=guestbook + kubectl delete service -l app=guestbook + kubectl delete -f filebeat-kubernetes.yaml + kubectl delete -f metricbeat-kubernetes.yaml + kubectl delete -f packetbeat-kubernetes.yaml + kubectl delete secret dynamic-logging -n kube-system + ``` + +1. 실행 중인 파드가 없음을 확인하기 위해 파드 목록을 조회한다. + + ```shell + kubectl get pods + ``` + + 커맨드의 출력은 다음과 같아야 한다. + + ``` + No resources found. + ``` + +{{% /capture %}} + +{{% capture whatsnext %}} +* [리소스 모니터링 도구](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다. +* [로깅 아키텍처](/docs/concepts/클러스터-administration/logging/)를 더 읽어본다. +* [애플리케이션 검사 및 디버깅](/docs/tasks/debug-application-cluster/)을 더 읽어본다. +* [애플리케이션 문제 해결](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다. +{{% /capture %}} diff --git a/content/ko/examples/application/mysql/mysql-pv.yaml b/content/ko/examples/application/mysql/mysql-pv.yaml index 6f4e692f3b..c89779a83f 100644 --- a/content/ko/examples/application/mysql/mysql-pv.yaml +++ b/content/ko/examples/application/mysql/mysql-pv.yaml @@ -1,5 +1,5 @@ -kind: PersistentVolume apiVersion: v1 +kind: PersistentVolume metadata: name: mysql-pv-volume labels: diff --git a/content/ko/examples/application/mysql/mysql-statefulset.yaml b/content/ko/examples/application/mysql/mysql-statefulset.yaml index e0c04007a8..b69af02c59 100644 --- a/content/ko/examples/application/mysql/mysql-statefulset.yaml +++ b/content/ko/examples/application/mysql/mysql-statefulset.yaml @@ -106,16 +106,16 @@ spec: cd /var/lib/mysql # Determine binlog position of cloned data, if any. - if [[ -f xtrabackup_slave_info ]]; then + if [[ -f xtrabackup_slave_info && "x$( change_master_to.sql.in # Ignore xtrabackup_binlog_info in this case (it's useless). - rm -f xtrabackup_binlog_info + rm -f xtrabackup_slave_info xtrabackup_binlog_info elif [[ -f xtrabackup_binlog_info ]]; then # We're cloning directly from master. Parse binlog position. [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1 - rm xtrabackup_binlog_info + rm -f xtrabackup_binlog_info xtrabackup_slave_info echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\ MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in fi @@ -126,16 +126,15 @@ spec: until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done echo "Initializing replication from clone position" + mysql -h 127.0.0.1 \ + -e "$( -
-
images/flower.png
-
- -

Kubernetes 是用于自动部署,扩展和管理容器化应用程序的开源系统。

-

它将组成应用程序的容器组合成逻辑单元,以便于管理和服务发现,Kubernetes 构建在 Google 15 年生产环境经验基础之上,并结合来自社区的最佳创意和实践。

-
-
-
-
images/scalable.png
-
- -

全球规模

-

基于允许 Google 每周运行数十亿个容器的原则进行设计,Kubernetes 可以在不增加您的运维团队的情况下进行弹性扩展。

-
-
-
-
images/blocks.png
-
- -

永不过时

-

无论您应用运行在本地还是运行于全球任何地域,Kubernetes 的灵活性都可以随着您的需求复杂度不断增加,还可以持续、轻松地对外提供服务。

-
-
-
-
images/suitcase.png
-
- -

随处运行

-

Kubernetes 是开源的,可以让您自由地部署在企业内部,私有云、混合云或公有云基础架构,使您轻松将应用迁移至任何位置。

-
-
- -
-
- -

Kubernetes: 最后… 它是真正的云平台

-

Box 的联合创始人和服务架构师 Sam Ghods 发表了热情洋溢的演讲,随着使用 Kubernetes,我们首次有一个通用接口,可以建立真正的部署工具。

+{{< deprecationwarning >}} + +{{< blocks/section id="oceanNodes" >}} +{{% blocks/feature image="flower" %}} +### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) +是一个开源系统,用于容器化应用的自动部署、扩缩和管理。 + +Kubernetes 将构成应用的容器按逻辑单位进行分组以便于管理和发现。 +Kubernetes 基于 [谷歌公司在运行生产负载上的 15 年经验](http://queue.acm.org/detail.cfm?id=2898444) +打造,并融合了来自社区的最佳建议与实践。 +{{% /blocks/feature %}} + +{{% blocks/feature image="scalable" %}} +#### 星际规模 + +基于一定的规则原理,谷歌公司每周能够运行数十亿的容器;通过遵循相同的设计, +Kubernetes 能够在保持现有运维团队规模的前提下完成集群的弹性伸缩。 + +{{% /blocks/feature %}} + +{{% blocks/feature image="blocks" %}} +#### 永不过时 + +无论是在本地测试还是支撑全球化企业业务,Kubernetes 的灵活性使得其能够与您一起成长。 +无论您的需求多么复杂,Kubernetes 都能助您始终如一地、轻而易举地交付应用。 + +{{% /blocks/feature %}} + +{{% blocks/feature image="suitcase" %}} +#### 随处运行 + +作为一个开源系统,Kubernetes 使您能够自由地获得内部云、混合云或公有云基础设施所提供的便利, +并根据需要轻松地迁移工作负载。 + +{{% /blocks/feature %}} + +{{< /blocks/section >}} + +{{< blocks/section id="video" background-image="kub_video_banner_homepage" >}} +
+

将超过 150 个微服务迁移到 Kubernetes 时遇到的挑战

+

Sarah Wells, Technical Director for Operations and Reliability, Financial Times

-
- -
-
-
- -

Kubernetes 特性

-
-
- -

自动包装

-

根据资源需求和其他约束自动放置容器,同时不会牺牲可用性,混合关键和最大努力的工作负载,以提高资源利用率并节省更多资源。

-
-
- -

自我修复

-

重新启动失败的容器,在节点不可用时,替换和重新调度节点上的容器,对用户定义的健康检查不响应的容器会被中止,并且在容器准备好服务之前不会把其向客户端广播。

-
-
-
-
- -

横向缩放

-

使用简单的命令或 UI,或者根据 CPU 的使用情况自动调整应用程序副本数。

-
-
- -

服务发现和负载均衡

-

不需要修改您的应用程序来使用不熟悉的服务发现机制,Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称,并可以在它们之间进行负载均衡。

-
-
-
-
- -

自动部署和回滚

-

Kubernetes 逐渐部署对应用程序或其配置的更改,同时监视应用程序运行状况,以确保它不会同时终止所有实例。 如果出现问题,Kubernetes会为您恢复更改,利用日益增长的部署解决方案的生态系统。

-
-
-

密钥配置 管理

-

部署和更新密钥和应用程序配置,不会重新编译您的镜像,不会在堆栈配置中暴露密钥(secrets)。

-
-
-
-
-

存储编排

-

自动安装您所选择的存储系统,无论是本地存储,如公有云提供商 GCPAWS, 还是网络存储系统 NFS, iSCSI, - Gluster, Ceph, Cinder, 或 Flocker。

-
-
-

批处理

-

除了服务之外,Kubernetes还可以管理您的批处理和 CI 工作负载,如果需要,替换出现故障的容器。

-
-
-
-
-
-
- -

实例探究

-
-
-

使用Kubernetes来重塑世界上最大的教育公司

- 阅读更多 -
-
-

Kubernetes at Box: 微服务的最大优势

- 阅读更多 -
-
-

在 eBay 内部转移到 OpenStack 上的 Kubernetes 和容器

- 阅读更多 -
-
-

将本地的集群迁移至 Kubernetes

- 观看视频 -
-
- - - - - - - - - - - - - - - - - - - - - - - -
探究所有的案例
-
-
- +
+ + +
+{{< /blocks/section >}} + +{{< blocks/kubernetes-features >}} + +{{< blocks/case-studies >}} diff --git a/layouts/docs/baseof.html b/layouts/docs/baseof.html index 39fc908057..11342585f1 100644 --- a/layouts/docs/baseof.html +++ b/layouts/docs/baseof.html @@ -11,12 +11,13 @@ {{ partial "docs/top-menu.html" . }} {{ end }} + {{ block "announcement" . }}{{ partial "announcement.html" . }}{{ end }} {{ block "deprecation" . }}{{ partial "deprecation-warning.html" . }}{{ end }}
{{ block "side-menu" . }}{{ end }}
{{ block "content" . }}{{ end }} - + {{ partial "feedback.html" . }} {{ partial "git-info.html" . }} diff --git a/layouts/partials/announcement.html b/layouts/partials/announcement.html new file mode 100644 index 0000000000..33f6f1c86c --- /dev/null +++ b/layouts/partials/announcement.html @@ -0,0 +1,11 @@ +{{ if .Param "announcement"}} +
+
+
+

+ {{ .Param "announcement_message" | markdownify }} +

+
+
+
+{{ end }} \ No newline at end of file diff --git a/layouts/shortcodes/announcement.html b/layouts/shortcodes/announcement.html new file mode 100644 index 0000000000..b1b0ef0c2b --- /dev/null +++ b/layouts/shortcodes/announcement.html @@ -0,0 +1,11 @@ +{{ if .Page.Param "announcement" }} +
+
+
+

+ {{ .Page.Param "announcement_message" | markdownify }} +

+
+
+
+{{ end }} \ No newline at end of file diff --git a/scripts/README.md b/scripts/README.md index 29dd7aa9d9..74ef8debdd 100644 --- a/scripts/README.md +++ b/scripts/README.md @@ -5,6 +5,9 @@ - `test_examples.sh`: This script tests whether a change affects example files bundled in the website. - `check-headers-file.sh`: This script checks the headers if you are in a production environment. - `hugo-version-check.sh`: This script checks whether your local Hugo version matches the version used in production. +- `diff_l10n_branches.py`: This script generates a report of outdated contents in `content/` directory +by comparing two l10n team milestone branches. + ## Requirements @@ -71,3 +74,22 @@ This script checks the headers if you are in a production environment. This script checks whether your local Hugo version matches the version used in production. ./scripts/hugo-version-check.sh + +## diff_l10n_branches.py + +``` +$ scripts/diff_l10n_branches.py --help +Usage: diff_l10n_branches.py [OPTIONS] L10N_LANG L_COMMIT R_COMMIT + + This script generates a report of outdated contents in `content/` directory by comparing two l10n team milestone branches. + + L10n team owners can open a GitHub issue with the report generated by this + script when they start a new team milestone. + + ex: `scripts/diff_l10n_branches.py ko dev-1.15-ko.3 dev-1.15-ko.4` + +Options: + --src-lang TEXT Source language + --help Show this message and exit. +``` diff --git a/scripts/diff_l10n_branches.py b/scripts/diff_l10n_branches.py new file mode 100755 index 0000000000..5ac131a4df --- /dev/null +++ b/scripts/diff_l10n_branches.py @@ -0,0 +1,137 @@ +#!/usr/bin/env python + +import os +import subprocess +import jinja2 +import click + +DEVNULL = open(os.devnull, 'w') +ISSUE_TEMPLATE = """\ +# This is a Bug Report +## Problem +Outdated files in the {{ r_commit }} branch. + +### {{ files_to_be_modified | count }} files to be modified +{% for m_file in files_to_be_modified -%} + 1. [ ] {{ m_file.filepath }} {{ m_file.shortstat }} +{% endfor %} + +### {{ files_to_be_renamed | count }} files to be renamed +{% for r_file in files_to_be_renamed -%} + 1. [ ] {{ r_file.diff_status_letter }} {{ r_file.src_filepath }} -> {{ r_file.dest_filepath }} +{% endfor %} + +### {{ files_to_be_deleted | count }} files to be deleted +{% for d_file in files_to_be_deleted -%} + 1. [ ] {{ d_file }} +{% endfor %} + +## Proposed Solution + +{% if files_to_be_modified %} + +Use `git diff` to check what is changed in the upstream. And apply the upstream changes manually +to the `{{ l10n_lang_path }}` of `{{ r_commit }}` branch. + +For example: +``` +# checkout `{{ r_commit }}` +... +# check what is updated in the upstream +git diff {{ l_commit }} {{ r_commit }} -- {{ files_to_be_modified.0.filepath }} +# apply changes to content/ko +vi {{ files_to_be_modified.0.filepath | replace(src_lang_path, l10n_lang_path) }} +... +# commit and push +... +# make PR to `{{ r_commit }}` +``` + +{% endif %} + +## Pages to Update + +""" + +files_to_be_deleted = [] +files_to_be_renamed = [] +files_to_be_modified = [] + + +def git_diff(filepath, l_commit, r_commit, shortstat=False): + cmd = ["git", "diff", l_commit, r_commit, "--", filepath] + + if shortstat: + cmd = ["git", "diff", l_commit, r_commit, "--shortstat", "--", filepath] + + return subprocess.check_output(cmd).decode("UTF-8").strip() + + +def git_exists(path, filepath): + cmd = ["git", "cat-file", "-e", "{}:{}".format(path, filepath)] + ret_code = subprocess.call(cmd, stderr=DEVNULL) + return ret_code == 0 + + +def process_diff_status(diff_status, l_commit, r_commit, src_lang_path, + l10n_lang_path): + status_letter = diff_status[0] + filepath = diff_status[1] + + if git_exists(r_commit, filepath.replace(src_lang_path, l10n_lang_path)): + if status_letter == 'D': + files_to_be_deleted.append(filepath) + elif status_letter.startswith('R'): + replaced = {"diff_status_letter": diff_status[0], + "src_filepath": diff_status[1], + "dest_filepath": diff_status[2]} + files_to_be_renamed.append(replaced) + elif status_letter == 'M': + modified = {"filepath": filepath, + "shortstat": git_diff(filepath, l_commit, r_commit, + shortstat=True), + "diff": git_diff(filepath, l_commit, r_commit)} + files_to_be_modified.append(modified) + + +def git_diff_name_status(l_commit, r_commit, src_lang_path, l10n_lang_path): + cmd = ["git", "diff", l_commit, r_commit, "--name-status", "--", + src_lang_path] + name_status_output = subprocess.check_output(cmd).strip() + for line in name_status_output.decode('utf-8').splitlines(): + diff_status = line.split() + process_diff_status(diff_status, l_commit, r_commit, src_lang_path, + l10n_lang_path) + + +@click.command() +@click.argument("l10n-lang") +@click.argument("l-commit") +@click.argument("r-commit") +@click.option("--src-lang", help="Source language", default="en") +def main(l10n_lang, src_lang, l_commit, r_commit): + """ + This script generates a report of outdated contents in `content/` + directory by comparing two l10n team milestone branches. + + L10n team owners can open a GitHub issue with the report generated by this + script when they start a new team milestone. + + ex: `scripts/diff_l10n_branches.py ko dev-1.15-ko.3 dev-1.15-ko.4` + """ + l10n_lang_path = "content/" + l10n_lang + src_lang_path = "content/" + src_lang + git_diff_name_status(l_commit, r_commit, src_lang_path, + l10n_lang_path) + issue_template = jinja2.Template(ISSUE_TEMPLATE) + ret = issue_template.render(l_commit=l_commit, r_commit=r_commit, + src_lang_path=src_lang_path, + l10n_lang_path=l10n_lang_path, + files_to_be_deleted=files_to_be_deleted, + files_to_be_modified=files_to_be_modified, + files_to_be_renamed=files_to_be_renamed) + print(ret) + + +if __name__ == "__main__": + main() diff --git a/static/_redirects b/static/_redirects index 718f9c64af..0a35628ffe 100644 --- a/static/_redirects +++ b/static/_redirects @@ -161,51 +161,10 @@ /docs/federation/api-reference/federation/v1beta1/operations.html /docs/reference/generated/federation/extensions/v1beta1/operations/ 301 /docs/federation/api-reference/README/ /docs/reference/generated/federation/ 301 -/docs/getting-started-guide/* /docs/setup/ 301 -/docs/getting-started-guides/ /docs/setup/pick-right-solution/ 301 -/docs/getting-started-guides/binary_release/ /docs/setup/release/building-from-source/ 301 -/docs/getting-started-guides/cloudstack/ /docs/setup/on-premises-vm/cloudstack/ 301 -/docs/getting-started-guides/dcos/ /docs/setup/on-premises-vm/dcos/ 301 -/docs/getting-started-guides/ovirt/ /docs/setup/on-premises-vm/ovirt/ 301 -/docs/getting-started-guides/coreos/ /docs/setup/custom-cloud/coreos/ 301 -/docs/getting-started-guides/kops/ /docs/setup/custom-cloud/kops/ 301 -/docs/getting-started-guides/kubespray/ /docs/setup/custom-cloud/kubespray/ 301 -/docs/getting-started-guides/coreos/azure/ /docs/getting-started-guides/coreos/ 301 -/docs/getting-started-guides/coreos/bare_metal_calico/ /docs/getting-started-guides/coreos/ 301 -/docs/getting-started-guides/docker-multinode/* /docs/setup/independent/create-cluster-kubeadm/ 301 -/docs/getting-started-guides/juju/ /docs/getting-started-guides/ubuntu/installation/ 301 -/docs/getting-started-guides/kargo/ /docs/getting-started-guides/kubespray/ 301 -/docs/getting-started-guides/kubeadm/ /docs/setup/independent/create-cluster-kubeadm/ 301 -/docs/getting-started-guides/kubectl/ /docs/reference/kubectl/overview/ 301 -/docs/getting-started-guides/logging/ /docs/concepts/cluster-administration/logging/ 301 -/docs/getting-started-guides/logging-elasticsearch/ /docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/ 301 -/docs/getting-started-guides/meanstack/ https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d/ 301 -/docs/getting-started-guides/minikube/ /docs/setup/minikube/ 301 -/docs/getting-started-guides/network-policy/calico/ /docs/tasks/administer-cluster/calico-network-policy/ 301 -/docs/getting-started-guides/network-policy/romana/ /docs/tasks/administer-cluster/romana-network-policy/ 301 -/docs/getting-started-guides/network-policy/walkthrough/ /docs/tasks/administer-cluster/declare-network-policy/ 301 -/docs/getting-started-guides/network-policy/weave/ /docs/tasks/administer-cluster/weave-network-policy/ 301 -/docs/getting-started-guides/rackspace/ /docs/setup/pick-right-solution/ 301 -/docs/getting-started-guides/running-cloud-controller/ /docs/tasks/administer-cluster/running-cloud-controller/ 301 -/docs/getting-started-guides/scratch/ /docs/setup/release/building-from-source/ 301 -/docs/getting-started-guides/ubuntu-calico/ /docs/getting-started-guides/ubuntu/ 301 -/docs/getting-started-guides/ubuntu/automated/ /docs/getting-started-guides/ubuntu/ 301 -/docs/getting-started-guides/ubuntu/calico/ /docs/getting-started-guides/ubuntu/ 301 -/docs/getting-started-guides/vagrant/ /docs/getting-started-guides/alternatives/ 301 -/docs/getting-started-guides/vsphere/ https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/ 301 -/docs/getting-started-guides/windows/While/ /docs/setup/windows/ 301 -/docs/getting-started-guides/windows/ /docs/setup/windows/ 301 -/docs/getting-started-guides/centos/* /docs/setup/independent/create-cluster-kubeadm/ 301 -/docs/getting-started-guides/alibaba-cloud/ /docs/setup/turnkey/alibaba-cloud/ 301 -/docs/getting-started-guides/aws/ /docs/setup/turnkey/aws/ 301 -/docs/getting-started-guides/azure/ /docs/setup/turnkey/azure/ 301 -/docs/getting-started-guides/clc/ /docs/setup/turnkey/clc/ 301 -/docs/getting-started-guides/gce/ /docs/setup/turnkey/gce/ 301 -/docs/getting-started-guides/stackpoint/ /docs/setup/turnkey/stackpoint/ 301 +/docs/getting-started-guides/* /docs/setup/ 301 /docs/hellonode/ /docs/tutorials/stateless-application/hello-minikube/ 301 /docs/home/contribute/stage-documentation-changes/ /docs/home/contribute/create-pull-request/ 301 -/docs/home/coreos/ /docs/getting-started-guides/coreos/ 301 /docs/home/deprecation-policy/ /docs/reference/using-api/deprecation-policy/ 301 /docs/home/contribute/ /docs/contribute/ 301 @@ -344,13 +303,6 @@ /docs/tutorials/federation/set-up-cluster-federation-kubefed.md /docs/tasks/federation/set-up-cluster-federation-kubefed/ 301 /docs/tutorials/federation/set-up-coredns-provider-federation/ /docs/tasks/federation/set-up-coredns-provider-federation/ 301 /docs/tutorials/federation/set-up-placement-policies-federation/ /docs/tasks/federation/set-up-placement-policies-federation/ 301 -/docs/tutorials/getting-started/cluster-intro/ /docs/tutorials/kubernetes-basics/cluster-intro/ 301 -/docs/tutorials/getting-started/create-cluster/ /docs/tutorials/kubernetes-basics/cluster-intro/ 301 -/docs/tutorials/getting-started/expose-intro/ /docs/tutorials/kubernetes-basics/expose-intro/ 301 -/docs/tutorials/getting-started/scale-app/ /docs/tutorials/kubernetes-basics/scale-interactive/ 301 -/docs/tutorials/getting-started/scale-intro/ /docs/tutorials/kubernetes-basics/scale-intro/ 301 -/docs/tutorials/getting-started/update-interactive/ /docs/tutorials/kubernetes-basics/update-interactive/ 301 -/docs/tutorials/getting-started/update-intro/ /docs/tutorials/kubernetes-basics/ 301 /docs/tutorials/kubernetes-basics/cluster-interactive/ /docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/ 301 /docs/tutorials/kubernetes-basics/cluster-intro/ /docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/ 301 /docs/tutorials/kubernetes-basics/deploy-interactive/ /docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive/ 301 @@ -418,7 +370,6 @@ /docs/user-guide/federation/secrets/ /docs/tasks/administer-federation/secret/ 301 /docs/user-guide/garbage-collection/ /docs/concepts/workloads/controllers/garbage-collection/ 301 /docs/user-guide/garbage-collector/* /docs/concepts/workloads/controllers/garbage-collection/ 301 -/docs/user-guide/getting-into-containers/ /docs/tasks/debug-application-cluster/get-shell-running-container/ 301 /docs/user-guide/gpus/ /docs/tasks/manage-gpus/scheduling-gpus/ 301 /docs/user-guide/horizontal-pod-autoscaler/* /docs/tasks/run-application/horizontal-pod-autoscale/ 301 /docs/user-guide/horizontal-pod-autoscaling/ /docs/tasks/run-application/horizontal-pod-autoscale/ 301 @@ -501,7 +452,6 @@ /docs/whatisk8s/ /docs/concepts/overview/what-is-kubernetes/ 301 /events/ /docs/community 301 -/gettingstarted/ /docs/home/ 301 /horizontal-pod-autoscaler/ /docs/tasks/run-application/horizontal-pod-autoscale/ 301 /kubernetes/ /docs/ 301 /kubernetes-bootcamp/* /docs/tutorials/kubernetes-basics/ 301 @@ -515,7 +465,6 @@ /swagger-spec/* https://github.com/kubernetes/kubernetes/tree/master/api/swagger-spec/ 301 /third_party/swagger-ui/* /docs/reference/ 301 /v1.1/docs/admin/networking.html /docs/concepts/cluster-administration/networking/ 301 -/v1.1/docs/getting-started-guides/ /docs/tutorials/kubernetes-basics/ 301 https://kubernetes-io-v1-7.netlify.com/* https://v1-7.docs.kubernetes.io/:splat 301 @@ -587,5 +536,5 @@ https://kubernetes-io-v1-7.netlify.com/* https://v1-7.docs.kubernetes.io/:spl /docs/setup/multiple-zones/ /docs/setup/best-practices/multiple-zones/ 301 /docs/setup/cluster-large/ /docs/setup/best-practices/cluster-large/ 301 /docs/setup/node-conformance/ /docs/setup/best-practices/node-conformance/ 301 -/docs/setup/certificates/ /docs/setup/best-practices/certificates/ 301 +/docs/setup/certificates/ /docs/setup/best-practices/certificates/ 301 diff --git a/static/css/announcement.css b/static/css/announcement.css new file mode 100644 index 0000000000..2819cba501 --- /dev/null +++ b/static/css/announcement.css @@ -0,0 +1,6 @@ +.announcement { + padding: 20px; + margin: 20px 0; + border-radius: 3px; + background-color: #eeeeee; +} \ No newline at end of file diff --git a/static/docs/reference/generated/kubernetes-api/v1.15/index.html b/static/docs/reference/generated/kubernetes-api/v1.15/index.html index 168e3020da..a62e6f15ea 100644 --- a/static/docs/reference/generated/kubernetes-api/v1.15/index.html +++ b/static/docs/reference/generated/kubernetes-api/v1.15/index.html @@ -55697,7 +55697,7 @@ $ curl -X GET 'http://127.0.0.1:8001/apis/extensions/v1beta1/watch/namespaces/de
- + diff --git a/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-1.png b/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-1.png new file mode 100644 index 0000000000..aa51876d74 Binary files /dev/null and b/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-1.png differ diff --git a/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-2.png b/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-2.png new file mode 100644 index 0000000000..c521160d37 Binary files /dev/null and b/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-2.png differ diff --git a/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-3.png b/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-3.png new file mode 100644 index 0000000000..d12aaf1b7e Binary files /dev/null and b/static/images/blog/2019-08-30-announcing-etcd-3.4/figure-3.png differ