diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index e3e643e339..2292bd3522 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -30,7 +30,6 @@ aliases: - onlydole - parispittman - vonguard - - onlydole sig-docs-de-owners: # Admins for German content - bene2k1 - mkorbi @@ -49,6 +48,7 @@ aliases: - kbarnard10 - kbhawkey - makoscafee + - onlydole - Rajakavitha1 - sftim - steveperry-53 @@ -67,6 +67,7 @@ aliases: - kbarnard10 - kbhawkey - makoscafee + - onlydole - rajakavitha1 - sftim - steveperry-53 diff --git a/assets/sass/_tablet.sass b/assets/sass/_tablet.sass index 96b24322a2..90215de1af 100644 --- a/assets/sass/_tablet.sass +++ b/assets/sass/_tablet.sass @@ -133,18 +133,21 @@ $feature-box-div-width: 45% max-width: 25% max-height: 100% transform: translateY(-50%) + width: 100% &:nth-child(odd) padding-right: 210px .image-wrapper right: 0 + text-align: right &:nth-child(even) padding-left: 210px .image-wrapper left: 0 + text-align: left &:nth-child(1) padding-right: 0 diff --git a/content/de/docs/concepts/_index.md b/content/de/docs/concepts/_index.md index b8fc0272db..82b5b0e5b0 100644 --- a/content/de/docs/concepts/_index.md +++ b/content/de/docs/concepts/_index.md @@ -52,7 +52,7 @@ Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen, ### Kubernetes Master -Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters. +Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommandozeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters. > Der Begriff "Master" bezeichnet dabei eine Reihe von Prozessen, die den Clusterstatus verwalten. Normalerweise werden diese Prozesse alle auf einem einzigen Node im Cluster ausgeführt. Dieser Node wird auch als Master bezeichnet. Der Master kann repliziert werden, um die Verfügbarkeit und Redundanz zu erhöhen. diff --git a/content/de/docs/concepts/containers/images.md b/content/de/docs/concepts/containers/images.md index 98e012640c..8f41b0c2e1 100644 --- a/content/de/docs/concepts/containers/images.md +++ b/content/de/docs/concepts/containers/images.md @@ -96,7 +96,7 @@ Das Google service Konto der Instanz hat einen `https://www.googleapis.com/auth/ Kubernetes eine native Unterstützung für die [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) wenn Knoten AWS EC2 Instanzen sind. -Es muss einfah nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden. +Es muss einfach nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden. Alle Benutzer eines Clusters die Pods erstellen dürfen können dann jedes der Images in der ECR Registry zum Ausführen von Pods nutzen. diff --git a/content/de/docs/setup/minikube.md b/content/de/docs/setup/minikube.md index f4d19ea80c..06734bd28f 100644 --- a/content/de/docs/setup/minikube.md +++ b/content/de/docs/setup/minikube.md @@ -205,7 +205,7 @@ Weitere Informationen zu unterstützten Treibern und zur Installation von Plugin ### Lokale Images durch erneute Verwendung des Docker-Daemon ausführen -Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importortieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben. +Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben. Um mit dem Docker-Daemon auf Ihrem Mac/Linux-Computer arbeiten zu können, verwenden Sie den `docker-env`-Befehl in Ihrer Shell: diff --git a/content/en/blog/_posts/2020-02-28-bring-your-ideas-to-world-with-kubectl-plugins.md b/content/en/blog/_posts/2020-02-28-bring-your-ideas-to-world-with-kubectl-plugins.md new file mode 100644 index 0000000000..1b94e4fa20 --- /dev/null +++ b/content/en/blog/_posts/2020-02-28-bring-your-ideas-to-world-with-kubectl-plugins.md @@ -0,0 +1,82 @@ +--- +title: Bring your ideas to the world with kubectl plugins +date: 2020-02-28 +--- + +**Author:** Cornelius Weig (TNG Technology Consulting GmbH) + +`kubectl` is the most critical tool to interact with Kubernetes and has to address multiple user personas, each with their own needs and opinions. +One way to make `kubectl` do what you need is to build new functionality into `kubectl`. + + +## Challenges with building commands into `kubectl` + +However, that's easier said than done. Being such an important cornerstone of +Kubernetes, any meaningful change to `kubectl` needs to undergo a Kubernetes +Enhancement Proposal (KEP) where the intended change is discussed beforehand. + +When it comes to implementation, you'll find that `kubectl` is an ingenious and +complex piece of engineering. It might take a long time to get used to +the processes and style of the codebase to get done what you want to achieve. Next +comes the review process which may go through several rounds until it meets all +the requirements of the Kubernetes maintainers -- after all, they need to take +over ownership of this feature and maintain it from the day it's merged. + +When everything goes well, you can finally rejoice. Your code will be shipped +with the next Kubernetes release. Well, that could mean you need to wait +another 3 months to ship your idea in `kubectl` if you are unlucky. + +So this was the happy path where everything goes well. But there are good +reasons why your new functionality may never make it into `kubectl`. For one, +`kubectl` has a particular look and feel and violating that style will not be +acceptable by the maintainers. For example, an interactive command that +produces output with colors would be inconsistent with the rest of `kubectl`. +Also, when it comes to tools or commands useful only to a minuscule proportion +of users, the maintainers may simply reject your proposal as `kubectl` needs to +address common needs. + +But this doesn’t mean you can’t ship your ideas to `kubectl` users. + +## What if you didn’t have to change `kubectl` to add functionality? + +This is where `kubectl` [plugins](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/) shine. +Since `kubectl` v1.12, you can simply +drop executables into your `PATH`, which follows the naming pattern +`kubectl-myplugin`. Then you can execute this plugin as `kubectl myplugin`, and +it will just feel like a normal sub-command of `kubectl`. + +Plugins give you the opportunity to try out new experiences like terminal UIs, +colorful output, specialized functionality, or other innovative ideas. You can +go creative, as you’re the owner of your own plugin. + +Further, plugins offer safe experimentation space for commands you’d like to +propose to `kubectl`. By pre-releasing as a plugin, you can push your +functionality faster to the end-users and quickly gather feedback. For example, +the [kubectl-debug](https://github.com/verb/kubectl-debug) plugin is proposed +to become a built-in command in `kubectl` in a +[KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md)). +In the meanwhile, the plugin author can ship the functionality and collect +feedback using the plugin mechanism. + +## How to get started with developing plugins + +If you already have an idea for a plugin, how do you best make it happen? +First you have to ask yourself if you can implement it as a wrapper around +existing `kubectl` functionality. If so, writing the plugin as a shell script +is often the best way forward, because the resulting plugin will be small, +works cross-platform, and has a high level of trust because it is not +compiled. + +On the other hand, if the plugin logic is complex, a general-purpose language +is usually better. The canonical choice here is Go, because you can use the +excellent `client-go` library to interact with the Kubernetes API. The Kubernetes +maintained [sample-cli-plugin](https://github.com/kubernetes/sample-cli-plugin) +demonstrates some best practices and can be used as a template for new plugin +projects. + +When the development is done, you just need to ship your plugin to the +Kubernetes users. For the best plugin installation experience and discoverability, +you should consider doing so via the +[krew](https://github.com/kubernetes-sigs/krew) plugin manager. For an in-depth +discussion about the technical details around `kubectl` plugins, refer to the +documentation on [kubernetes.io](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/). diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index cb5b78d55e..312eeddc9a 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -157,7 +157,7 @@ controller deletes the node from its list of nodes. The third is monitoring the nodes' health. The node controller is responsible for updating the NodeReady condition of NodeStatus to ConditionUnknown when a node becomes unreachable (i.e. the node controller stops -receiving heartbeats for some reason, e.g. due to the node being down), and then later evicting +receiving heartbeats for some reason, for example due to the node being down), and then later evicting all the pods from the node (using graceful termination) if the node continues to be unreachable. (The default timeouts are 40s to start reporting ConditionUnknown and 5m after that to start evicting pods.) The node controller diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index 9c031807e0..b9a320192c 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -94,7 +94,7 @@ Different settings can be applied to a load balancer service in AWS using _annot * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix. * `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`. * `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used. -* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. +* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, for example `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout. diff --git a/content/en/docs/concepts/cluster-administration/federation.md b/content/en/docs/concepts/cluster-administration/federation.md index 7900b53d27..e26aef3fa8 100644 --- a/content/en/docs/concepts/cluster-administration/federation.md +++ b/content/en/docs/concepts/cluster-administration/federation.md @@ -140,7 +140,7 @@ Reasons to prefer fewer clusters per availability zone are: - improved bin packing of Pods in some cases with more nodes in one cluster (less resource fragmentation). - reduced operational overhead (though the advantage is diminished as ops tooling and processes mature). - - reduced costs for per-cluster fixed resource costs, e.g. apiserver VMs (but small as a percentage + - reduced costs for per-cluster fixed resource costs, for example apiserver VMs (but small as a percentage of overall cluster cost for medium to large clusters). Reasons to have multiple clusters include: diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index 2c1ab5f3fe..e464a2869e 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -76,7 +76,7 @@ should set up a solution to address that. For example, in Kubernetes clusters, deployed by the `kube-up.sh` script, there is a [`logrotate`](https://linux.die.net/man/8/logrotate) tool configured to run each hour. You can also set up a container runtime to -rotate application's logs automatically, e.g. by using Docker's `log-opt`. +rotate application's logs automatically, for example by using Docker's `log-opt`. In the `kube-up.sh` script, the latter approach is used for COS image on GCP, and the former approach is used in any other environment. In both cases, by default rotation is configured to take place when log file exceeds 10MB. diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/configuration/assign-pod-node.md index 2c5becff54..19f33c47e8 100644 --- a/content/en/docs/concepts/configuration/assign-pod-node.md +++ b/content/en/docs/concepts/configuration/assign-pod-node.md @@ -17,7 +17,7 @@ There are several ways to do this, and the recommended approaches all use [label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection. Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement (e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.) -but there are some circumstances where you may want more control on a node where a pod lands, e.g. to ensure +but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different services that communicate a lot into the same availability zone. @@ -176,7 +176,7 @@ Y is expressed as a LabelSelector with an optional associated list of namespaces (and therefore the labels on pods are implicitly namespaced), a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain like node, rack, cloud provider zone, cloud provider region, etc. You express it using a `topologyKey` which is the -key for the node label that the system uses to denote such a topology domain, e.g. see the label keys listed above +key for the node label that the system uses to denote such a topology domain; for example, see the label keys listed above in the section [Interlude: built-in node labels](#built-in-node-labels). {{< note >}} @@ -366,7 +366,7 @@ Some of the limitations of using `nodeName` to select nodes are: some cases may be automatically deleted. - If the named node does not have the resources to accommodate the pod, the pod will fail and its reason will indicate why, - e.g. OutOfmemory or OutOfcpu. + for example OutOfmemory or OutOfcpu. - Node names in cloud environments are not always predictable or stable. diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md index 399f8b4e22..5c2edb1a0a 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md @@ -158,12 +158,9 @@ globalDefault: false description: "This priority class should be used for XYZ service pods only." ``` -### Non-preempting PriorityClasses (alpha) {#non-preempting-priority-class} +## Non-preempting PriorityClass {#non-preempting-priority-class} -1.15 adds the `PreemptionPolicy` field as an alpha feature. -It is disabled by default in 1.15, -and requires the `NonPreemptingPriority`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/ -) to be enabled. +{{< feature-state for_k8s_version="1.15" state="alpha" >}} Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue ahead of lower-priority pods, @@ -187,6 +184,10 @@ which will allow pods of that PriorityClass to preempt lower-priority pods If `PreemptionPolicy` is set to `Never`, pods in that PriorityClass will be non-preempting. +The use of the `PreemptionPolicy` field requires the `NonPreemptingPriority` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +to be enabled. + An example use case is for data science workloads. A user may submit a job that they want to be prioritized above other workloads, but do not wish to discard existing work by preempting running pods. @@ -194,7 +195,7 @@ The high priority job with `PreemptionPolicy: Never` will be scheduled ahead of other queued pods, as soon as sufficient cluster resources "naturally" become free. -#### Example Non-preempting PriorityClass +### Example Non-preempting PriorityClass ```yaml apiVersion: scheduling.k8s.io/v1 diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 660d589169..94879a72fa 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -128,7 +128,12 @@ Regardless of how they are installed, the new resources are referred to as Custo ## CustomResourceDefinitions -The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource. +The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) +API resource allows you to define custom resources. +Defining a CRD object creates a new custom resource with a name and schema that you specify. +The Kubernetes API serves and handles the storage of your custom resource. +The name of a CRD object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). This frees you from writing your own API server to handle the custom resource, but the generic nature of the implementation means you have less flexibility than with @@ -179,7 +184,7 @@ Aggregated APIs offer more advanced API features and customization of other feat | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes | | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes | | Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes | -| Status Subresource | | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes | +| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes | | Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes | | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes | | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes | diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index cb9b6d83a9..76d03d28b7 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -154,7 +154,7 @@ most network plugins. Where needed, you can specify the MTU explicitly with the `network-plugin-mtu` kubelet option. For example, on AWS the `eth0` MTU is typically 9001, so you might specify `--network-plugin-mtu=9001`. If you're using IPSEC you -might reduce it to allow for encapsulation overhead e.g. `--network-plugin-mtu=8873`. +might reduce it to allow for encapsulation overhead; for example: `--network-plugin-mtu=8873`. This option is provided to the network-plugin; currently **only kubenet supports `network-plugin-mtu`**. diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 0e34fa926f..81f45b5aed 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -55,7 +55,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/ * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--proxy-mode=ipvs` - * `--cluster-cidrs=,` + * `--cluster-cidr=,` * `--feature-gates="IPv6DualStack=true"` {{< caution >}} diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 89788349b8..5a55665db3 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -350,7 +350,7 @@ parameters: contains user password to use when talking to Gluster REST service. These parameters are optional, empty password will be used when both `secretNamespace` and `secretName` are omitted. The provided secret must have - type `"kubernetes.io/glusterfs"`, e.g. created in this way: + type `"kubernetes.io/glusterfs"`, for example created in this way: ``` kubectl create secret generic heketi-secret \ @@ -514,7 +514,7 @@ parameters: same as `adminId`. * `userSecretName`: The name of Ceph Secret for `userId` to map RBD image. It must exist in the same namespace as PVCs. This parameter is required. - The provided secret must have type "kubernetes.io/rbd", e.g. created in this + The provided secret must have type "kubernetes.io/rbd", for example created in this way: ```shell @@ -561,7 +561,7 @@ parameters: * `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate against the API server. The provided secret must have type "kubernetes.io/quobyte" and the keys `user` and `password`, - e.g. created in this way: + for example: ```shell kubectl create secret generic quobyte-admin-secret \ diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 8627978427..f2feb36515 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -39,7 +39,8 @@ You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` f {{< codenew file="controllers/daemonset.yaml" >}} -* Create a DaemonSet based on the YAML file: +Create a DaemonSet based on the YAML file: + ``` kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` @@ -50,6 +51,9 @@ As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/), [configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents. +The name of a DaemonSet object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section. ### Pod Template diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6e83992421..03c58c6525 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -1020,6 +1020,8 @@ can create multiple Deployments, one for each release, following the canary patt As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/), configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents. +The name of a Deployment object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index 7077bd5ad3..74ccf6a2d9 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/content/en/docs/concepts/workloads/controllers/replicaset.md @@ -58,22 +58,26 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml ``` You can then get the current ReplicaSets deployed: + ```shell kubectl get rs ``` And see the frontend one you created: + ```shell NAME DESIRED CURRENT READY AGE frontend 3 3 3 6s ``` -You can also check on the state of the replicaset: +You can also check on the state of the ReplicaSet: + ```shell kubectl describe rs/frontend ``` And you will see output similar to: + ```shell Name: frontend Namespace: default @@ -106,11 +110,13 @@ Events: ``` And lastly you can check for the Pods brought up: + ```shell kubectl get Pods ``` You should see Pod information similar to: + ```shell NAME READY STATUS RESTARTS AGE frontend-9si5l 1/1 Running 0 1m @@ -120,11 +126,13 @@ frontend-qhloh 1/1 Running 0 1m You can also verify that the owner reference of these pods is set to the frontend ReplicaSet. To do this, get the yaml of one of the Pods running: + ```shell kubectl get pods frontend-9si5l -o yaml ``` The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field: + ```shell apiVersion: v1 kind: Pod @@ -169,11 +177,13 @@ The new Pods will be acquired by the ReplicaSet, and then immediately terminated its desired count. Fetching the Pods: + ```shell kubectl get Pods ``` The output shows that the new Pods are either already terminated, or in the process of being terminated: + ```shell NAME READY STATUS RESTARTS AGE frontend-9si5l 1/1 Running 0 1m @@ -183,17 +193,20 @@ pod2 0/1 Terminating 0 4s ``` If you create the Pods first: + ```shell kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml ``` And then create the ReplicaSet however: + ```shell kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml ``` You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the number of its new Pods and the original matches its desired count. As fetching the Pods: + ```shell kubectl get Pods ``` @@ -215,6 +228,9 @@ For ReplicaSets, the kind is always just ReplicaSet. In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated. Refer to the first lines of the `frontend.yaml` example for guidance. +The name of a ReplicaSet object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). ### Pod Template diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 4519cb4bec..aa6a07788b 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -109,10 +109,15 @@ In the above example: * The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods. * The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner. +The name of a StatefulSet object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + ## Pod Selector + You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation. ## Pod Identity + StatefulSet Pods have a unique identity that is comprised of an ordinal, a stable network identity, and stable storage. The identity sticks to the Pod, regardless of which node it's (re)scheduled on. diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index 2e741afd76..f4e61518a5 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -732,7 +732,7 @@ For Kubernetes 1.9 and earlier, we recommend running the following set of admiss ``` * It's worth reiterating that in 1.9, these happen in a mutating phase -and a validating phase, and that e.g. `ResourceQuota` runs in the validating +and a validating phase, and that for example `ResourceQuota` runs in the validating phase, and therefore is the last admission controller to run. `MutatingAdmissionWebhook` appears before it in this list, because it runs in the mutating phase. diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index 3500ed0c53..970fc148c9 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -1048,7 +1048,7 @@ to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". -Attempting to use a user or basic auth e.g. "user:password@" is not allowed. +Attempting to use a user or basic auth (for example "user:password@") is not allowed. Fragments ("#...") and query parameters ("?...") are also not allowed. Here is an example of a mutating webhook configured to call a URL diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index 776715c8a2..8c7464d694 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -578,7 +578,7 @@ A number of markers were added in Kubernetes 1.16 and 1.17, to allow API develop | Golang marker | OpenAPI extension | Accepted values | Description | Introduced in | |---|---|---|---|---| | `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16 | -| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries e.g. `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 | +| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 | | `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 | | `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 | diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index 28ed6e1fcf..6c903d4e60 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -88,7 +88,7 @@ The following production environment solutions table lists the providers and the | [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | | [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | | [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | -| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | | +| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | | [KubeSail](https://kubesail.com/) | ✔ | | | | | | [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | | [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index bfb26fa1ca..fdacab8491 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -397,7 +397,7 @@ If your network is not working or CoreDNS is not in the Running state, checkout ### Control plane node isolation By default, your cluster will not schedule Pods on the control-plane node for security -reasons. If you want to be able to schedule Pods on the control-plane node, e.g. for a +reasons. If you want to be able to schedule Pods on the control-plane node, for example for a single-machine Kubernetes cluster for development, run: ```bash diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md index caf20d7f2e..8b4480de2f 100644 --- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -63,7 +63,7 @@ The jsonpath is interpreted as follows: - `.image`: get the image {{< note >}} -When fetching a single Pod by name, e.g. `kubectl get pod nginx`, +When fetching a single Pod by name, for example `kubectl get pod nginx`, the `.items[*]` portion of the path should be omitted because a single Pod is returned instead of a list of items. {{< /note >}} 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 9b5e997782..ecda7709cf 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 @@ -113,7 +113,7 @@ track=stable - **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials. - Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, e.g. `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters. + Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters. In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied. diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md index ef5f904079..037187499a 100644 --- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md +++ b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md @@ -246,6 +246,9 @@ spec: caBundle: ``` +The name of an APIService object must be a valid +[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names). + #### Contacting the extension apiserver Once the Kubernetes apiserver has determined a request should be sent to a extension apiserver, diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md index f730fb3660..184e870fc3 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md @@ -502,7 +502,7 @@ to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". -Attempting to use a user or basic auth e.g. "user:password@" is not allowed. +Attempting to use a user or basic auth (for example "user:password@") is not allowed. Fragments ("#...") and query parameters ("?...") are also not allowed. Here is an example of a conversion webhook configured to call a URL diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md index b2d5703b1c..dd96f2d6d6 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md @@ -366,7 +366,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables {{< feature-state state="stable" for_kubernetes_version="1.16" >}} -CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources like e.g. a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields. +CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields. {{< tabs name="CustomResourceDefinition_pruning" >}} {{% tab name="apiextensions.k8s.io/v1" %}} diff --git a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md index 3cce9c7153..bdc871ddd9 100644 --- a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md +++ b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md @@ -37,7 +37,7 @@ The agent configuration file must be written in YAML or JSON syntax, and may con * **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges. * **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default. -* **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc... +* **resyncInterval:** A time interval at which the agent attempts to reload config from disk. For example: '30s', where 's' means seconds, 'ms' means milliseconds, etc... Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded. An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range. Any other traffic will be masqueraded by default. The below entries show the default set of rules that are applied by the ip-masq-agent: diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md index 9f341d046f..5e57c18379 100644 --- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md @@ -72,9 +72,9 @@ cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be scheduled, but will fail to launch. With the warning above in mind, the cluster admin can allow certain _unsafe_ -sysctls for very special situations like e.g. high-performance or real-time +sysctls for very special situations such as high-performance or real-time application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a -flag of the kubelet, e.g.: +flag of the kubelet; for example: ```shell kubelet --allowed-unsafe-sysctls \ diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 320d800dc9..fc31526348 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -63,7 +63,7 @@ For example, this is how to start a simple web server as a static Pod: ssh my-node1 ``` -2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`: +2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, for example `/etc/kubelet.d/static-web.yaml`: ```shell # Run this command on the node where kubelet is running diff --git a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md index 370e75f6ce..847d76f25c 100644 --- a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md +++ b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -34,13 +34,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re ```sh # Linux -curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-linux-amd64 -o kompose +curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-linux-amd64 -o kompose # macOS -curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-darwin-amd64 -o kompose +curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-darwin-amd64 -o kompose # Windows -curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-windows-amd64.exe -o kompose.exe +curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-windows-amd64.exe -o kompose.exe chmod +x kompose sudo mv ./kompose /usr/local/bin/kompose @@ -580,7 +580,7 @@ If you want to create normal pods without controllers you can use `restart` cons The controller object could be `deployment` or `replicationcontroller`, etc. {{< /note >}} -For e.g. `pival` service will become pod down here. This container calculated value of `pi`. +For example, the `pival` service will become pod down here. This container calculated value of `pi`. ```yaml version: '2' diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 2c769eb933..ed95d353ac 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -272,7 +272,7 @@ to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". -Attempting to use a user or basic auth e.g. "user:password@" is not allowed. +Attempting to use a user or basic auth (for example "user:password@") is not allowed. Fragments ("#...") and query parameters ("?...") are also not allowed. Here is an example of a webhook configured to call a URL diff --git a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md index 4e95d82905..ae56c42411 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md @@ -55,7 +55,7 @@ This is an incomplete list of things that could go wrong, and how to adjust your - Network partition within cluster, or between cluster and users - Crashes in Kubernetes software - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume) - - Operator error, e.g. misconfigured Kubernetes software or application software + - Operator error, for example misconfigured Kubernetes software or application software ### Specific scenarios: diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md index d075944516..a60ceeedfb 100644 --- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md @@ -362,7 +362,7 @@ you want to add Kafka sink for messages from a particular container for addition You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image) with minor changes: -* Change Makefile to point to your container repository, e.g. `PREFIX=gcr.io/`. +* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/`. * Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`. Then run `make build push` from this directory. After updating `DaemonSet` to pick up the diff --git a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md index 8886da28d2..25e6956403 100644 --- a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -21,9 +21,7 @@ encryption keys, into Pods. ## Convert your secret data to a base-64 representation Suppose you want to have two pieces of secret data: a username `my-app` and a password -`39528$vdg7Jb`. First, use online Base 64 Encoding Tool [Base64 encoding](https://www.base64encode.org/), [Base64 encode](https://goonlinetools.com/base64-encode/) to -convert your username and password to a base-64 representation. Here's a Linux -example: +`39528$vdg7Jb`. First, use a base64 encoding tool to convert your username and password to a base64 representation. Here's an example using the commonly available base64 program: ```shell echo -n 'my-app' | base64 diff --git a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md index 7ca0a45a0f..4b1d424066 100644 --- a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -132,7 +132,8 @@ NAME CONTROLLER REVISION AGE ``` Each `ControllerRevision` stores the annotations and template of a DaemonSet -revision. +revision. The name of a ControllerRevision object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). `kubectl rollout undo` takes a specific `ControllerRevision` and replaces DaemonSet template with the template stored in the `ControllerRevision`. diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index 0c1a5472b6..ab98f2ea4e 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -33,7 +33,7 @@ DaemonSet has two update strategy types: * RollingUpdate: This is the default update strategy. With `RollingUpdate` update strategy, after you update a DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods - will be created automatically, in a controlled fashion. + will be created automatically, in a controlled fashion. At most one pod of the DaemonSet will be running on each node during the whole update process. ## Performing a Rolling Update diff --git a/content/ko/_index.html b/content/ko/_index.html index 59188feb67..b93ac38e8f 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -45,12 +45,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준


- Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020 + Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020



- Attend KubeCon in Shanghai on July 28-30, 2020 + Attend KubeCon in Shanghai on July 28-30, 2020
diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index fb28711866..6d4e30b4ca 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -26,12 +26,12 @@ weight: 40 ## 쿠버네티스 오브젝트 -쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 문서를 참조한다. +쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 문서를 참조한다. 기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다. * [파드](/ko/docs/concepts/workloads/pods/pod-overview/) -* [서비스](/docs/concepts/services-networking/service/) +* [서비스](/ko/docs/concepts/services-networking/service/) * [볼륨](/docs/concepts/storage/volumes/) * [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 7af5863f92..e2feb1b4cf 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -26,7 +26,7 @@ weight: 30 ## 컨트롤러 패턴 컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다. -이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) +이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 는 의도한 상태를 표현하는 사양 필드를 가지고 있다. 해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 상태에 가깝게 만드는 역할을 한다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index dffd6bd2db..f9c28cee9c 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -103,7 +103,7 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll ## 관리 -[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/docs/concepts/services-networking/service/)와 달리, +[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/ko/docs/concepts/services-networking/service/)와 달리, 노드는 본래 쿠버네티스에 의해 생성되지 않는다. 구글 컴퓨트 엔진과 같은 클라우드 제공사업자에 의해 외부로부터 생성 되거나, 물리적 또는 가상 머신의 풀 내에서 존재한다. 그래서 쿠버네티스가 노드를 생성할 때, @@ -272,6 +272,12 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄 애플리케이션을 유출시키는 중이라 할지라도 머신 상에 속한 데몬으로 여긴다. {{< /note >}} +{{< caution >}} +`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는 +서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에 +사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다. +{{< /caution >}} + ### 노드 용량 노드의 용량 (cpu 수와 메모리 양) 은 노드 오브젝트의 한 부분이다. diff --git a/content/ko/docs/concepts/cluster-administration/controller-metrics.md b/content/ko/docs/concepts/cluster-administration/controller-metrics.md deleted file mode 100644 index 8a7951eb04..0000000000 --- a/content/ko/docs/concepts/cluster-administration/controller-metrics.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 컨트롤러 관리자 메트릭 -content_template: templates/concept -weight: 100 ---- - -{{% capture overview %}} -컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 -중요한 통찰을 제공한다. - -{{% /capture %}} - -{{% capture body %}} -## 컨트롤러 관리자 메트릭은 무엇인가 - -컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 통찰을 제공한다. -메트릭은 go_routine count와 같은 일반적인 Go 언어 런타임 메트릭과 -etcd 요청 대기 시간 또는 클라우드 제공자(AWS, GCE, OpenStack) API 대기 시간과 같이 클러스터 상태를 -측정할 수 있는 컨트롤러 특징적 메트릭을 포함한다. - -쿠버네티스 1.7 부터, GCE, AWS, Vsphere 그리고 OpenStack의 저장소 작업에 대한 자세한 클라우드 제공자 메트릭을 사용할 수 있다. -이 메트릭은 영구 볼륨 작업의 상태 감시에 사용될 수 있다. - -예를 들어, GCE의 경우 다음과 같은 메트릭이 호출된다: - -``` -cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} -cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} -``` - - - -## 구성 - - -클러스터에서 컨트롤러-관리자 메트릭은 컨트롤러-관리자가 실행되고 있는 호스트의 `http://localhost:10252/metrics`를 통해서 -이용 가능하다. - -메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)에서 나오고, 사람이 읽을 수 있다. - -운영 환경에서는 주기적으로 메트릭을 모으고, 일종의 시계열 데이터베이스로 만들기 위해, -프로메테우스 설정이나 다른 메트릭 수집기를 구성할 것이다. - -{{% /capture %}} diff --git a/content/ko/docs/concepts/cluster-administration/proxies.md b/content/ko/docs/concepts/cluster-administration/proxies.md index fedef39322..66e29d2e40 100644 --- a/content/ko/docs/concepts/cluster-administration/proxies.md +++ b/content/ko/docs/concepts/cluster-administration/proxies.md @@ -33,7 +33,7 @@ weight: 90 - 노드, 파드, 서비스에 도달하는데 사용할 수 있다. - 서비스에 도달할 때에는 로드 밸런싱을 수행한다. -1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips): - 각 노드에서 실행한다. - UDP, TCP, SCTP를 이용하여 프락시 한다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 4dd1ffea54..794f46d079 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -37,7 +37,7 @@ weight: 10 ## 서비스 -- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. +- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. ```shell FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> @@ -51,14 +51,14 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다. - 만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다. + 만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다. - 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다. + 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다. - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. -- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless- -services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. +- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless- +서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. ## 레이블 사용하기 diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 925854f667..e0d27691ce 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -56,7 +56,7 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. {{< note >}} 런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. -이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄링](#scheduling)을 참고한다. +이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다. {{< /note >}} 해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. @@ -162,7 +162,7 @@ https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go 노드의 합집합을 취한다. 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 -[노드에 파드 할당](/docs/concepts/configuration/assign-pod-node/)을 참고한다. +[노드에 파드 할당](/ko/docs/concepts/configuration/assign-pod-node/)을 참고한다. [어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/ diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md new file mode 100644 index 0000000000..ff8525f171 --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -0,0 +1,4 @@ +--- +title: 쿠버네티스 확장하기 +weight: 110 +--- diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md new file mode 100644 index 0000000000..5701f2d0c5 --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md @@ -0,0 +1,4 @@ +--- +title: 쿠버네티스 API 확장하기 +weight: 20 +--- diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md new file mode 100644 index 0000000000..c7a2054d42 --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -0,0 +1,38 @@ +--- +title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다. + +{{% /capture %}} + +{{% capture body %}} + +## 개요 + +애그리게이션 레이어는 부가적인 쿠버네티스-스타일 API를 클러스터에 설치할 수 있게 해준다. 이는 [서비스-카탈로그](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)와 같이 사전에 구축되어 있는 서드 파티 솔루션일 수 있고, [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)로 시작해볼 수 있는 것과 같은 사용자 정의 API일 수도 있다. + +애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다. + +대개, APIService는 클러스터 내에서 구동 중인 파드(pod) 내 *extension-apiserver* 로 구현된다. 이 extension-apiserver는 일반적으로 추가된 리소스에 대한 적극적인 관리가 필요한 경우 하나 이상의 컨트롤러와 짝지어진다. 결과적으로, apiserver-builder는 실제로 그 둘 모두에 대한 스켈레톤을 제공한다. 또 다른 예로, 서비스-카탈로그가 설치된 경우에는, 제공하는 서비스에 대한 extension-apiserver와 컨트롤러를 모두 제공한다. + +Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮아야 한다. +특히, kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다. +사용자의 환경에서 달성할 수 없는 경우에는, 이를 어떻게 바꿀 수 있을지 고려해야 한다. 지금은, +`EnableAggregatedDiscoveryTimeout=false` 기능 게이트를 설정해서 타임아웃 제한을 +비활성화 할 수 있다. 이 기능은 미래의 릴리스에서는 삭제될 예정이다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/). +* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. +* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다. + +{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 30b75b82a4..a3f2a02e87 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -12,7 +12,7 @@ card: {{% /capture %}} {{% capture body %}} -## 쿠버네티스 오브젝트 이해하기 +## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects} *쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다. @@ -41,8 +41,9 @@ card: {{< codenew file="application/deployment.yaml" >}} -위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다. - +위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 +`kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다. ```shell kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record @@ -50,8 +51,7 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record 그 출력 내용은 다음과 유사하다. - -```shell +``` deployment.apps/nginx-deployment created ``` @@ -65,14 +65,15 @@ deployment.apps/nginx-deployment created * `spec` - 오브젝트에 대해 어떤 상태를 의도하는지 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. -예를 들어, `파드`에 대한 `spec` 포맷은 -[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) -에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은 -[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다. +예를 들어, 파드에 대한 `spec` 포맷은 +[PodSpec v1 Core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은 +[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다. {{% /capture %}} {{% capture whatsnext %}} +* API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index f0f56e600c..ff9a93d5d7 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -70,7 +70,7 @@ spec: image: nginx:1.7.9 ports: - containerPort: 80 - + ``` ## 레이블 셀렉터 @@ -209,7 +209,7 @@ selector: #### 세트-기반 요건을 지원하는 리소스 -[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다. +[`잡`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다. ```yaml selector: @@ -225,6 +225,6 @@ selector: #### 노드 셋 선택 레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. -자세한 내용은 [노드 선택](/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다. +자세한 내용은 [노드 선택](/ko/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다. {{% /capture %}} diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index fce55dbf8e..6c3d78a2a6 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -123,7 +123,7 @@ my-nginx 10.244.2.5:80,10.244.3.4:80 1m 이제 클러스터의 모든 노드에서 `:` 로 nginx 서비스를 curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외부에서는 절대로 연결되지 않음에 참고한다. 만약 이것이 어떻게 작동하는지 궁금하다면 -[서비스 프록시](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)에 대해 더 읽어본다. +[서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)에 대해 더 읽어본다. ## 서비스에 접근하기 diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 10da72fb2d..91fbc782d7 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -38,22 +38,24 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. ## 서비스 -### A 레코드 +### A/AAAA 레코드 -"노멀"(헤드리스가 아닌) 서비스는 +"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라 `my-svc.my-namespace.svc.cluster-domain.example` -형식의 이름을 가진 DNS A 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다. +형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터 +IP로 해석된다. -"헤드리스"(클러스터 IP가 없는) 서비스 또한 +"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라 `my-svc.my-namespace.svc.cluster-domain.example` -형식의 이름을 가진 DNS A 레코드가 할당된다. +형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. -클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다. +클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 +통해 선택할 수 있다. ### SRV 레코드 SRV 레코드는 노멀 서비스 또는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)에 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. 정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. @@ -128,22 +130,22 @@ spec: ``` 파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, -클러스터의 KubeDNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 레코드를 반환한다. +클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다. 예를 들어 호스트네임이 "`busybox-1`"이고, 서브도메인이 "`default-subdomain`"이고, 같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, 파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". -DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 레코드를 제공한다. -"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 레코드를 가지고 있다. +DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. +"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다. 엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다. {{< note >}} -A 레코드는 파드의 이름으로 생성되지 않기 때문에 -파드의 A 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. +A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 +파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. `hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 -A 레코드만 생성할 수 있다. +A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`) 또한 레코드를 가지기 위해서는 파드가 준비되어야 한다. 그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 2cdfb31028..0c52346820 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -27,7 +27,6 @@ weight: 70 * 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당) * IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.) - * Kubenet 다중 주소 패밀리 지원(IPv4와 IPv6) * IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 이그레스 라우팅(예: 인터넷) ## 필수 구성 요소 @@ -36,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 * 쿠버네티스 1.16 또는 이후 버전 * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) - * Kubenet 네트워크 플러그인 + * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인 * IPVS 모드에서 구동 중인 Kube-Proxy ## IPv4/IPv6 이중 스택 활성화 @@ -52,7 +51,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요 * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--proxy-mode=ipvs` - * `--cluster-cidrs=,` + * `--cluster-cidr=,` * `--feature-gates="IPv6DualStack=true"` {{< caution >}} diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 2a04159efd..793a1520e3 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -15,24 +15,15 @@ weight: 40 이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다. -노드(Node) -: 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. - -클러스터(Cluster) -: 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. - -에지 라우터(Edge router) -: 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. - -클러스터 네트워크(Cluster network) -: 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. - -서비스(Service) -: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. +노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. +클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. +에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. +클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. +서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. ## 인그레스란? -인그레스는 클러스터 외부에서 클러스터 내부 +[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부 {{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. @@ -47,8 +38,8 @@ weight: 40 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 -[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는 -[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. +[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는 +[Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. ## 전제 조건들 @@ -107,7 +98,7 @@ spec: * 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련 백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가 모두 수신 요청의 내용과 일치해야 한다. -* 백엔드는 [서비스 문서](/docs/concepts/services-networking/service/)에 설명된 바와 같이 +* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/)에 설명된 바와 같이 서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한 HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다. @@ -220,7 +211,7 @@ Events: {{< note >}} 사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 에 따라 default-http-backend -[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다. +[서비스](/ko/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다. {{< /note >}} ### 이름 기반의 가상 호스팅 @@ -466,12 +457,13 @@ Events: 사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다. -* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 사용. -* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 사용. +* [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용. +* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용. {{% /capture %}} {{% capture whatsnext %}} +* [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube) {{% /capture %}} diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 2001f96bd5..c3f4ee193b 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -7,16 +7,16 @@ weight: 50 {{< toc >}} {{% capture overview %}} -네트워크 정책은 파드 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. +네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. -`NetworkPolicy` 리소스는 레이블을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. +`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. {{% /capture %}} {{% capture body %}} ## 전제 조건 -네트워크 정책은 네트워크 플러그인으로 구현되므로 `NetworkPolicy` 를 지원하는 네트워킹 솔루션을 사용해야 한다. - 컨트롤러가 없이 단순하게 리소스를 생성하게 되면 아무런 효과가 없기 때문이다. +네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다. ## 격리 및 격리되지 않은 파드 @@ -26,11 +26,11 @@ weight: 50 네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다. -## `NetworkPolicy` 리소스 +## NetworkPolicy 리소스 {#networkpolicy-resource} -리소스에 대한 전체 정의는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. +리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. -`NetworkPolicy` 의 예시는 다음과 같다. +NetworkPolicy 의 예시는 다음과 같다. ```yaml apiVersion: networking.k8s.io/v1 @@ -69,23 +69,25 @@ spec: port: 5978 ``` -*선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 API 서버에 이를 POST 하더라도 효과가 없다.* +{{< note >}} +선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다. +{{< /note >}} -__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 `NetworkPolicy` 에는 +__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일 작업에 대한 일반적인 정보는 [컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), 그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다. -__spec__: `NetworkPolicy` [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. +__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. -__podSelector__: 각 `NetworkPolicy` 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. +__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. -__policyTypes__: 각 `NetworkPolicy` 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다. +__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다. -__ingress__: 각 `NetworkPolicy` 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. +__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. -__egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. +__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. 따라서 예시의 NetworkPolicy는 다음과 같이 동작한다. @@ -103,7 +105,7 @@ __egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포 `ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다. -__podSelector__: `NetworkPolicy` 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. +__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. __namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다. @@ -164,16 +166,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C 모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Ingress -``` +{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다. @@ -181,33 +174,13 @@ spec: 만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: allow-all -spec: - podSelector: {} - ingress: - - {} - policyTypes: - - Ingress -``` +{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} ### 기본적으로 모든 이그레스 트래픽 거부 모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Egress -``` +{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 기본 인그레스 격리 정책을 변경하지 않는다. @@ -216,34 +189,13 @@ spec: 만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: allow-all -spec: - podSelector: {} - egress: - - {} - policyTypes: - - Egress -``` +{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} ### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부 해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Ingress - - Egress -``` +{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다. @@ -251,9 +203,12 @@ spec: {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -쿠버네티스는 `NetworkPolicy` 정의에서 `protocol` 값으로 SCTP를 알파 기능으로 지원한다. 이 기능을 활성화하려면 클러스터 관리자가 apiserver 에서 `SCTPSupport` 기능 게이트를 활성화 할 필요가 있다. 예를 들면, `“--feature-gates=SCTPSupport=true,...”` . 기능 게이트가 활성화 되면 `NetworkPolicy` 의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. +이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. +기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. -CNI 플러그인은 SCTP를 `NetworkPolicy` 에서 `protocol` 값으로 지원해야 한다. +{{< note >}} +SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. +{{< /note >}} {{% /capture %}} diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index 7e71eee719..16f140e583 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -43,23 +43,6 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수 트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에 연결된 노드로 트래픽을 유지하는 것이 있다. -## 전제 조건 - -서비스 라우팅을 인식하는 토폴로지를 활성화 하려면 다음과 같은 전제 조건이 -필요하다. - - * 쿠버네티스 1.17 또는 이후 버전 - * Kube-proxy 가 iptables 모드 또는 IPVS 모드에서 실행 중 - * [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)의 활성화 - -## 서비스 토폴로지 활성화하기 - -서비스 토폴로지를 활성화하려면 kube-apiserver 와 kube-proxy의 -기능 게이트에서 `ServiceTopology` 를 활성화 한다. - -``` ---feature-gates="ServiceTopology=true" -``` ## 서비스 토폴로지 사용하기 @@ -114,6 +97,98 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수 한다. +## 예시들 + +다음은 서비스 토폴로지 기능을 사용하는 일반적인 예시이다. + +### 노드 로컬 엔드포인트만 + +노드 로컬 엔드포인트로만 라우팅하는 서비스이다. 만약 노드에 엔드포인트가 없으면 트레픽이 드롭된다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" +``` + +### 노드 로컬 엔드포인트 선호 + +노드 로컬 엔드포인트를 선호하지만, 노드 로컬 엔드포인트가 없는 경우 클러스터 전체 엔드포인트로 폴백 하는 서비스이다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" + - "*" +``` + + +### 영역 또는 지리적 엔드포인트만 + +영역보다는 지리적 엔드포인트를 선호하는 서비스이다. 만약 엔드포인트가 없다면, 트래픽은 드롭된다. + + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "topology.kubernetes.io/zone" + - "topology.kubernetes.io/region" +``` + +### 노드 로컬, 영역 및 지역 엔드포인트 선호 + +노드 로컬, 영역 및 지역 엔드포인트를 선호하지만, 클러스터 전체 엔드포인트로 폴백하는 서비스이다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" + - "topology.kubernetes.io/zone" + - "topology.kubernetes.io/region" + - "*" +``` + + {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index ba0d78cf2f..3048426cfc 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -847,7 +847,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스 헬스 체크에 실패하고 트래픽을 수신하지 못하게 된다. 트래픽을 균일하게 하려면, DaemonSet을 사용하거나, -[파드 안티어피니티(pod anti-affinity)](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) +[파드 안티어피니티(pod anti-affinity)](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 를 지정하여 동일한 노드에 위치하지 않도록 한다. [내부 로드 밸런서](/ko/docs/concepts/services-networking/service/#internal-load-balancer) 어노테이션과 함께 NLB 서비스를 @@ -936,7 +936,7 @@ spec: {{< note >}} ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은 정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면, -[헤드리스(headless) 서비스](#headless-services) 사용을 고려한다. +[헤드리스(headless) 서비스](#헤드리스-headless-서비스) 사용을 고려한다. {{< /note >}} `my-service.prod.svc.cluster.local` 호스트를 검색하면, 클러스터 DNS 서비스는 diff --git a/content/ko/docs/concepts/storage/_index.md b/content/ko/docs/concepts/storage/_index.md new file mode 100644 index 0000000000..1e0fb99a5d --- /dev/null +++ b/content/ko/docs/concepts/storage/_index.md @@ -0,0 +1,5 @@ +--- +title: "스토리지" +weight: 70 +--- + diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md new file mode 100644 index 0000000000..fa84c193c9 --- /dev/null +++ b/content/ko/docs/concepts/storage/volumes.md @@ -0,0 +1,1444 @@ +--- +title: 볼륨 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 +애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 첫째, 컨테이너가 충돌되면, +kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상태로 +시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때 +컨테이너 사이에 파일을 공유해야 하는 경우가 자주 발생한다. 쿠버네티스의 +`볼륨` 추상화는 이 두 가지 문제를 모두 해결한다. + +[파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 익숙해지는 것을 추천한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 배경 + +도커는 다소 느슨하고, 덜 관리되지만 +[볼륨](https://docs.docker.com/engine/admin/volumes/)이라는 +개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 +다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 +로컬 디스크 백업 볼륨만 있었다. 도커는 이제 볼륨 드라이버를 +제공하지만, 현재 기능은 매우 제한되어 있다(예: 도커 1.7부터 +컨테이너 당 하나의 볼륨 드라이버만 허용되고 매개 변수를 볼륨에 +전달할 방법이 없다). + +반면에, 쿠버네티스 볼륨은 그것을 둘러싼 파드와 +동일한 명시적인 수명을 가진다. 그 결과로, 볼륨은 파드 내에서 실행되는 모든 컨테이너보다 +수명이 길고, 컨테이너를 다시 시작해도 데이터가 보존된다. 물론 파드가 +존재하지 않으면, 볼륨도 존재하지 않는다. 이보다 더 중요한 것은 +쿠버네티스가 많은 유형의 볼륨을 지원하고, 파드는 +여러 볼륨을 동시에 사용할 수 있다. + +기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드 +내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는 +매체와 내용은 사용된 특정 볼륨의 유형에 따라 +결정된다. + +볼륨을 사용하기 위해 파드는 파드에 제공할 볼륨( +`.spec.volumes` +필드)과 컨테이너에 마운트 할 위치( +`.spec.containers[*].volumeMounts` +필드)를 지정한다. + +컨테이너 내 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 뷰를 +본다. [도커 +이미지](https://docs.docker.com/userguide/dockerimages/)는 파일 +시스템 계층의 루트에 있으며 모든 볼륨은 이미지 내에 지정된 경로에 +마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 +가질 수 없다. 파드 내 각각의 컨테이너는 각각의 볼륨을 마운트 할 위치를 독립적으로 +지정해야 한다. + +## 볼륨 유형들 + +쿠버네티스는 여러 유형의 볼륨을 지원한다. + + * [awsElasticBlockStore](#awselasticblockstore) + * [azureDisk](#azuredisk) + * [azureFile](#azurefile) + * [cephfs](#cephfs) + * [cinder](#cinder) + * [configMap](#configmap) + * [csi](#csi) + * [downwardAPI](#downwardapi) + * [emptyDir](#emptydir) + * [fc (파이버 채널))](#fc) + * [flexVolume](#flexVolume) + * [flocker](#flocker) + * [gcePersistentDisk](#gcepersistentdisk) + * [gitRepo (사용중단(deprecated))](#gitrepo) + * [glusterfs](#glusterfs) + * [hostPath](#hostpath) + * [iscsi](#iscsi) + * [local](#local) + * [nfs](#nfs) + * [persistentVolumeClaim](#persistentvolumeclaim) + * [projected](#projected) + * [portworxVolume](#portworxvolume) + * [quobyte](#quobyte) + * [rbd](#rbd) + * [scaleIO](#scaleio) + * [secret](#secret) + * [storageos](#storageos) + * [vsphereVolume](#vspherevolume) + +우리는 추가 기여를 환영한다. + +### awsElasticBlockStore {#awselasticblockstore} + +`awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS) [EBS +볼륨](http://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 +제거할 때 지워지는 `emptyDir` 와는 다르게 EBS 볼륨의 +내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에 +데이터를 미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" +할 수 있다. + +{{< caution >}} +이를 사용하려면 먼저 `aws ec2 create-volume` 또는 AWS API를 사용해서 EBS 볼륨을 생성해야 한다. +{{< /caution >}} + +`awsElasticBlockStore` 볼륨을 사용할 때 몇 가지 제한이 있다. + +* 파드가 실행 중인 노드는 AWS EC2 인스턴스여야 함 +* 이러한 인스턴스는 EBS 볼륨과 동일한 지역과 가용성 영역에 있어야 함 +* EBS는 볼륨을 마운트하는 단일 EC2 인스턴스만 지원함 + +#### EBS 볼륨 생성하기 + +파드와 함께 EBS 볼륨을 사용하려면, 먼저 EBS 볼륨을 생성해야 한다. + +```shell +aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 +``` + +클러스터를 띄운 영역과 생성하는 영역이 일치하는지 확인한다. (그리고 크기와 EBS 볼륨 유형이 +사용에 적합한지 확인한다!) + +#### AWS EBS 구성 예시 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-ebs +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-ebs + name: test-volume + volumes: + - name: test-volume + # 이 AWS EBS 볼륨은 이미 존재해야 한다. + awsElasticBlockStore: + volumeID: + fsType: ext4 +``` + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +awsElasticBlockStore 의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [AWS EBS CSI +드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) +를 설치하고 `CSIMigration` 과 `CSIMigrationAWS` +베타 기능을 활성화 해야 한다. + +#### CSI 마이그레이션 완료 +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +컨트롤러 매니저와 kubelet에 의해 로드되지 않도록 awsElasticBlockStore 스토리지 플러그인을 끄려면, 이 기능의 플래그를 true로 설정해야 한다. 이는 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다. + +### azureDisk {#azuredisk} + +`azureDisk` 는 Microsoft Azure [데이터 디스크](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/)를 파드에 마운트하는 데 사용한다. + +더 자세한 내용은 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)에서 확인할 수 있다. + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +azureDisk의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI +드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) +를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk` +알파 기능을 활성화 해야 한다. + +### azureFile {#azurefile} + +`azureFile` 은 Microsoft Azure 파일 볼륨 (SMB 2.1과 3.0)을 파드에 마운트하는데 +사용한다. + +더 자세한 내용은 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)에서 확인할 수 있다. + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +azureFile의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI +드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) +를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile` +알파 기능을 활성화 해야 한다. + +### cephfs {#cephfs} + +`cephfs` 볼륨은 기존 CephFS 볼륨을 +파드에 마운트 할 수 있다. 파드를 제거할 때 지워지는 `emptyDir` +와는 다르게 cephfs 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 +해제만 된다. 이 의미는 `cephfs` 볼륨에 데이터를 미리 채울 수 있으며, +파드 간에 데이터를 "전달(handed off)" 할 수 있다. CephFS는 여러 작성자가 +동시에 마운트할 수 있다. + +{{< caution >}} +CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다. +{{< /caution >}} + +더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다. + +### cinder {#cinder} + +{{< note >}} +전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스. 클라우드 공급자 +구성에 대해서는 [오픈스택 클라우드 공급자](/docs/concepts/cluster-administration/cloud-providers/#openstack)를 참조한다. +{{< /note >}} + +`cinder` 는 오픈스택 Cinder 볼륨을 파드에 마운트하는 데 사용한다. + +#### Cinder 볼륨 예시 구성 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-cinder +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-cinder-container + volumeMounts: + - mountPath: /test-cinder + name: test-volume + volumes: + - name: test-volume + # 이 오픈스택 볼륨은 이미 존재해야 한다. + cinder: + volumeID: + fsType: ext4 +``` + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +Cinder의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI +드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) +를 설치하고 `CSIMigration` 과 `CSIMigrationOpenStack` +알파 기능을 활성화해야 한다. + +### configMap {#configmap} + +[`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) 리소스는 +구성 데이터를 파드에 주입하는 방법을 제공한다. +`ConfigMap` 오브젝트에 저장된 데이터는 `configMap` 유형의 볼륨에서 참조되고 +그런 다음에 파드에서 실행되는 컨테이너화된 애플리케이션이 소비한다. + +`configMap` 오브젝트를 참조할 때, 간단하게 참조하기 위한 볼륨의 이름을 +제공할 수 있다. ConfigMap의 특정 항목에 사용할 경로를 +사용자 정의할 수 있다. +예를 들어, `log-config` ConfigMap을 `configmap-pod` 라 부르는 파드에 마운트하려면 +아래 YAML을 사용할 수 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: test + image: busybox + volumeMounts: + - name: config-vol + mountPath: /etc/config + volumes: + - name: config-vol + configMap: + name: log-config + items: + - key: log_level + path: log_level +``` + +`log-config` ConfigMap은 볼륨으로 마운트되며, `log_level` 항목에 +저장된 모든 컨텐츠는 파드의 "`/etc/config/log_level`" 경로에 마운트 된다. +이 경로는 볼륨의 `mountPath` 와 `log_level` 로 키가 지정된 +`path` 에서 파생된다. + +{{< caution >}} +ConfigMap 볼륨을 사용하려면 먼저 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 생성해야 한다. +{{< /caution >}} + +{{< note >}} +ConfigMap을 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 ConfigMap +업데이트를 수신하지 않는다. +{{< /note >}} + +### downwardAPI {#downwardapi} + +`downwardAPI` 볼륨은 애플리케이션에서 다운워드(downward) API 데이터를 사용할 수 있도록 하는데 사용된다. +이것은 디렉터리를 마운트하고 요청된 데이터를 일반 텍스트 파일로 작성한다. + +{{< note >}} +Downward API를 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 Downward API +업데이트를 수신하지 않는다. +{{< /note >}} + +더 자세한 내용은 [`downwardAPI` 볼륨 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참조한다. + +### emptyDir {#emptydir} + +`emptyDir` 볼륨은 파드가 노드에 할당 될 때 처음 생성되며, +해당 노드에서 파드가 실행되는 동안에만 존재한다. 이름에서 알 수 있듯이 +`emptyDir` 볼륨은 처음에는 비어있다. 파드내 모든 컨테이너는 `emptyDir` 볼륨에서 동일한 +파일을 읽고 쓸수 있지만, 볼륨은 각각의 컨테이너에서 동일하거나 +다른 경로에 마운트 될 수 있다. 어떤 이유로든 노드에서 파드를 제거하면 +`emptyDir` 의 데이터가 영구적으로 삭제된다. + +{{< note >}} +컨테이너의 충돌은 노드에서 파드를 제거하지 *않기* 때문에, `emptyDir` 볼륨의 데이터는 컨테이너 충돌에서 안전하다. +{{< /note >}} + +`emptyDir` 의 일부 용도는 다음과 같다. + +* 디스크 기반의 병합 종류와 같은 스크레치 공간 +* 충돌로부터 복구하기위해 긴 계산을 검사점으로 지정 +* 웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저 + 컨테이너가 가져오는 파일을 보관 + +기본적으로, `emptyDir` 볼륨은 노드를 지원하는 모든 매체에 +저장된다(환경에 따라 디스크, SSD 또는 네트워크 스토리지일 +수 있다). 그러나 `emptyDir.medium` 필드를 `"Memory"` 로 설정해서 +쿠버네티스에 tmpfs(RAM 기반 파일 시스템)를 마운트하도록 할 수 있다. +tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs가 지워지고, +작성하는 모든 파일이 컨테이너 메모리 +제한에 포함된다. + +#### 파드 예시 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /cache + name: cache-volume + volumes: + - name: cache-volume + emptyDir: {} +``` + +### fc (파이버 채널) {#fc} + +`fc` 볼륨은 기존 파이버 채널 볼륨을 파드에 마운트할 수 있게 한다. +볼륨 구성에서 `targetWWNs` 파라미터를 사용하여 단일 또는 +다중 대상 월드 와이드 이름을 지정할 수 있다. 만약 여러 WWN이 지정된 경우, +targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다. + +{{< caution >}} +이러한 LUN (볼륨)을 할당하고 대상 WWN에 마스킹하도록 FC SAN Zoning을 구성해야만 쿠버네티스 호스트가 해당 LUN에 접근할 수 있다. +{{< /caution >}} + +더 자세한 내용은 [FC 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) 를 참조한다. + +### flocker {#flocker} + +[Flocker](https://github.com/ClusterHQ/flocker)는 오픈소스 클러스터 컨테이너 데이터 볼륨 매니저이다. 다양한 +스토리지 백엔드가 지원하는 데이터 볼륨 관리와 오케스트레이션을 제공한다. + +`flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약 +Flocker내에 데이터셋이 없는 경우, 먼저 Flocker +CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면 +Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에 +따라 파드 간에 데이터를 "전달(handed off)" 할 수 있다는 의미이다. + +{{< caution >}} +`flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다. +{{< /caution >}} + +더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다. + +### gcePersistentDisk {#gcepersistentdisk} + +`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진 (GCE) [퍼시스턴트 +디스크](http://cloud.google.com/compute/docs/disks)를 파드에 마운트 한다. 파드를 +제거할 때 지워지는 `emptyDir` 와는 다르게 PD의 내용은 유지되고, +볼륨은 마운트 해제만 된다. 이는 PD에 데이터를 +미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" 할 수 있다는 것을 의미한다. + +{{< caution >}} +`gcePersistentDisk` 를 사용하려면 먼저 PD를 `gcloud`, GCE API 또는 UI를 사용해서 생성해야 한다. +{{< /caution >}} + +`gcePersistentDisk` 를 사용할 때 몇가지 제한이 있다. + +* 파드가 실행중인 노드는 GCE VM이어야 함 +* 이러한 VM은 PD와 동일한 GCE 프로젝트와 영역에 있어야 함 + +PD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 +있다는 것이다. 즉, 데이터셋으로 PD를 미리 채운 다음, 필요한 +만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, +PD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있으며 +동시 쓰기는 허용되지 않는다. + +ReplicationController가 제어하는 파드에서 PD를 사용하는 것은 +PD가 읽기 전용이거나 레플리카의 수가 0 또는 1이 아니라면 실패할 것이다. + +#### PD 생성하기 + +GCE PD를 파드와 함께 사용하려면 디스크를 먼저 생성해야 한다. + +```shell +gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk +``` + +#### 예시 파드 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + # 이 GCE PD는 이미 존재해야 한다. + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### 지역(Regional) 퍼시스턴트 디스크 +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +[지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. + +#### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 +[GCE PD 용 StorageClass](/docs/concepts/storage/storage-classes/#gce) 를 사용해서 동적 프로비저닝이 가능하다. +PersistentVolume을 생성하기 전에 PD를 생성해야만 한다. +```shell +gcloud beta compute disks create --size=500GB my-data-disk + --region us-central1 + --replica-zones us-central1-a,us-central1-b +``` +PersistentVolume 사양 예시 + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: test-volume + labels: + failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b +spec: + capacity: + storage: 400Gi + accessModes: + - ReadWriteOnce + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +GCE PD의 CSI 마이그레이션 기능이 활성화된 경우 기존 트리 내 플러그인에서 +`pd.csi.storage.gke.io` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI +드라이버](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) +를 설치하고 `CSIMigration` 과 `CSIMigrationGCE` +베타 기능을 활성화 해야 한다. + +### gitRepo (사용 중단(deprecated)) {#gitrepo} + +{{< warning >}} +gitRepo 볼륨 유형은 사용 중단(deprecated)되었다. git repo가 있는 컨테이너를 프로비전 하려면 초기화 컨테이너(InitContainer)에 [EmptyDir](#emptydir)을 마운트하고, 여기에 git을 사용해서 repo를 복제하고, [EmptyDir](#emptydir)을 파드 컨테이너에 마운트 한다. +{{< /warning >}} + +`gitRepo` 볼륨은 볼륨 플러그인으로 할 수 있는 예시이다. 빈 +디렉터리를 마운트하고 파드가 사용할 수 있도록 해당 디렉터리에 git 리포지트리를 +복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에 +이런 볼륨은 훨씬 더 분리된 모델로 이동될 수 있다. + +여기 gitRepo 볼륨의 예시가 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: server +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /mypath + name: git-volume + volumes: + - name: git-volume + gitRepo: + repository: "git@somewhere:me/my-git-repository.git" + revision: "22f1d8406d464b0c0874075539c1f2e96c253775" +``` + +### glusterfs {#glusterfs} + +`glusterfs` 볼륨을 사용하면 [Glusterfs](http://www.gluster.org) (오픈 +소스 네트워크 파일시스템) 볼륨을 파드에 마운트 할수 있다. 파드를 +제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs` +볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 +glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데이터를 +"전달(handed off)" 할 수 있다. GlusterFS는 여러 작성자가 동시에 +마운트할 수 있다. + +{{< caution >}} +사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다. +{{< /caution >}} + +더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다. + +### hostPath {#hostpath} + +`hostPath` 볼륨은 호스트 노드의 파일시스템에 있는 파일이나 디렉터리를 +파드에 마운트 한다. 이것은 대부분의 파드들이 필요한 것은 아니지만, 일부 +애플리케이션에 강력한 탈출구를 제공한다. + +예를 들어, `hostPath` 의 일부 용도는 다음과 같다. + +* 도커 내부에 접근할 필요가 있는 실행중인 컨테이너. `/var/lib/docker` 를 + `hostPath` 로 이용함 +* 컨테이너에서 cAdvisor의 실행. `/sys` 를 `hostPath` 로 이용함 +* 파드는 주어진 `hostPath` 를 파드가 실행되기 이전에 있어야 하거나, + 생성해야 하는지 그리고 존재해야 하는 대상을 지정할 수 있도록 허용함 + +필요한 `path` 속성 외에도, `hostPath` 볼륨에 대한 `type` 을 마음대로 지정할 수 있다. + +필드가 `type` 에 지원되는 값은 다음과 같다. + + +| 값 | 행동 | +|:------|:---------| +| | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPash 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. | +| `DirectoryOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0755로 설정한 빈 디렉터리를 생성한다. | +| `Directory` | 주어진 경로에 디렉터리가 있어야 함 | +| `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 디렉터리를 생성한다. | +| `File` | 주어진 경로에 파일이 있어야 함 | +| `Socket` | 주어진 경로에 UNIX 소캣이 있어야 함 | +| `CharDevice` | 주어진 경로에 문자 디바이스가 있어야 함 | +| `BlockDevice` | 주어진 경로에 블록 디바이스가 있어야 함 | + +다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다. + +* 동일한 구성(파드템플릿으로 생성한 것과 같은)을 + 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있음 +* 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서 + 사용되는 리소스를 설명할 수 없음 +* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를 + [특권 컨테이너](/docs/user-guide/security-context) 에서 루트로 실행하거나 + `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 함 + +#### 파드 예시 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + hostPath: + # 호스트의 디렉터리 위치 + path: /data + # 이 필드는 선택 사항이다 + type: Directory +``` + +### iscsi {#iscsi} + +`iscsi` 볼륨을 사용하면 기존 iSCSI (SCSI over IP) 볼륨을 파드에 마운트 +할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 +다르게 `iscsi` 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 +해제만 된다. 이 의미는 iscsi 볼륨에 데이터를 미리 채울 수 있으며, +파드간에 데이터를 "전달(handed off)" 할 수 있다는 것이다. + +{{< caution >}} +사용하려면 먼저 iSCSI 서버를 실행하고 볼륨을 생성해야 한다. +{{< /caution >}} + +iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수 +있다는 것이다. 즉, 데이터셋으로 사전에 볼륨을 채운다음, +필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행하게도, +iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있으며 +동시 쓰기는 허용되지 않는다. + +더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)를 본다. + +### local {#local} + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +`local` 볼륨은 디스크, 파티션 또는 디렉터리 같은 마운트된 로컬 스토리지 +장치를 나타낸다. + +로컬 볼륨은 정적으로 생성된 퍼시스턴트볼륨(PersistentVolume)으로만 사용할 수 있다. 동적으로 +프로비저닝된 것은 아직 지원되지 않는다. + +`hostPath` 볼륨에 비해 로컬 볼륨은 퍼시스턴트볼륨의 노드 어피니티를 살펴봄으로써 +볼륨의 노드 제약 조건을 인식하기 때문에 수동으로 파드를 노드에 예약하지 않고도 +내구성과 휴대성을 갖춘 방식으로 사용할 수 있다. + +그러나 로컬 볼륨은 여전히 기본 노드의 가용성을 따르며 +모든 애플리케이션에 적합하지는 않는다. 만약 노드가 비정상 상태가 +되면 로컬 볼륨도 접근할 수 없게 되고, 파드를 실행할 수 +없게 된다. 로컬 볼륨을 사용하는 애플리케이션은 기본 디스크의 +내구 특성에 따라 이러한 감소되는 가용성과 데이터 +손실 가능성도 허용할 수 있어야 한다. + +다음은 `local` 볼륨과 `nodeAffinity` 를 사용하는 퍼시스턴트볼륨 +사양 예시이다. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: example-pv +spec: + capacity: + storage: 100Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Delete + storageClassName: local-storage + local: + path: /mnt/disks/ssd1 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/hostname + operator: In + values: + - example-node +``` + +로컬 볼륨을 사용할 때는 퍼시스턴트볼륨의 `nodeAffinity` 가 필요하다. 이를 통해 +쿠버네티스 스케줄러는 올바른 노드의 로컬 볼륨을 파드가 사용할 수 있도록 올바르게 +스케줄할 수 있다. + +퍼시스턴트볼륨의 `volumeMode` 을 "Block" (기본값인 "Filesystem"을 +대신해서)으로 설정하면 로컬 볼륨을 원시 블록 장치로 노출할 수 있다. + +로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된 +스토리지클래스(StorageClass)를 생성하는 것을 권장한다. +[예시](/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 +퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터, +파드 어피니티 그리고 파드 안티 어피니티와 +같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다. + +로컬 볼륨 라이프사이클의 향상된 관리를 위해 외부 정적 +프로비저너를 별도로 실행할 수 있다. 이 프로비저너는 아직 동적 +프로비저닝을 지원하지 않는 것을 참고한다. 외부 로컬 프로비저너를 실행하는 방법에 대한 +예시는 [로컬 볼륨 프로비저너 사용자 +가이드](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)를 본다. + +{{< note >}} +로컬 정적 프로비저너를 사용해서 볼륨 라이프사이클을 관리하지 않는 +경우 로컬 퍼시스턴트볼륨을 수동으로 정리하고 삭제하는 것이 +필요하다. +{{< /note >}} + +### nfs {#nfs} + +`nfs` 볼륨을 사용하면 기존 NFS (네트워크 파일 시스템) 볼륨을 파드에 마운트 +할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 +다르게 `nfs` 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 +해제만 된다. 이 의미는 NFS 볼륨에 데이터를 미리 채울 수 있으며, +파드간에 데이터를 "전달(handed off)" 할 수 있다는 뜻이다. NFS는 여러 작성자가 +동시에 마운트할 수 있다. + +{{< caution >}} +사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다. +{{< /caution >}} + +더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다. + +### persistentVolumeClaim {#persistentvolumeclaim} + +`persistentVolumeClaim` 볼륨은 +[퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)을 파드에 마운트하는데 사용한다. 퍼시스턴트볼륨은 +사용자가 특정 클라우드 환경의 세부 내용을 몰라도 내구성이있는 스토리지 (GCE 퍼시스턴트디스크 또는 +iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다. + +더 자세한 내용은 [퍼시스턴트볼륨 예시](/docs/concepts/storage/persistent-volumes/)를 +본다. + +### projected {#projected} + +`Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. + +현재, 다음 유형의 볼륨 소스를 프로젝티드한다. + +- [`secret`](#secret) +- [`downwardAPI`](#downwardapi) +- [`configMap`](#configmap) +- `serviceAccountToken` + +모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은 +[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)를 본다. + +서비스 어카운트 토큰의 프로젝션은 쿠버네티스 1.11에 기능이 +도입되었고 1.12에서 베타로 승격되었다. +1.11에서 이 기능을 활성화 하려면 `TokenRequestProjection` +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +True로 명시적인 설정이 필요하다. + +#### 시크릿, downward API 그리고 configmap이 있는 파드 예시. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "cpu_limit" + resourceFieldRef: + containerName: container-test + resource: limits.cpu + - configMap: + name: myconfigmap + items: + - key: config + path: my-group/my-config +``` + +#### 기본값이 아닌 모드 설정과 여러 시크릿을 가진 파드 예시 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - secret: + name: mysecret2 + items: + - key: password + path: my-group/my-password + mode: 511 +``` + +각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다. +파라미터는 두 가지 예외를 제외하고 거의 동일하다. + +* 시크릿의 경우 `secretName` 필드는 ConfigMap 이름과 일치하도록 + `name` 으로 변경되었다. +* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만 + 지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode` + 를 명시적으로 설정할 수 있다. + +`TokenRequestProjection` 기능이 활성화 되면, 현재 +[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에 +대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 아래는 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: sa-token-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: token-vol + mountPath: "/service-account" + readOnly: true + volumes: + - name: token-vol + projected: + sources: + - serviceAccountToken: + audience: api + expirationSeconds: 3600 + path: token +``` + +예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이 +있다. 예를 들어 이 토큰은 파드 컨테이너에서 쿠버네티스 API 서버에 접근하는데 +사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을 +포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며, +그렇지 않으면 토큰을 거부해야 한다. 이 필드는 +선택 사항이며 기본값은 API 서버의 식별자이다. + +`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효 +기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는 +API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서 +최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한 +상대 경로를 지정한다. + +{{< note >}} +projected 볼륨 소스를 [subPath](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다. +{{< /note >}} + +### portworxVolume {#portworxvolume} + +`portworxVolume` 은 쿠버네티스와 하이퍼컨버지드(hyperconverged)를 실행하는 탄력적인 블록 스토리지 +계층이다. [Portworx](https://portworx.com/use-case/kubernetes-storage/)는 서버에 스토리지 지문을 남기고, 역량에 기반하여 계층화 하고, +그리고 여러 서버에 걸쳐 용량을 집계한다. Portworx는 가상 머신 내 게스트 또는 베어 메탈 리눅스 노드 위에서 실행된다. + +`portworxVolume` 은 쿠버네티스를 통해 동적으로 생성되거나 +사전 프로비전할 수 있으며 쿠버네티스 파드 내에서 참조할 수 있다. +여기에 사전에 프로비전 된 PortworxVolume을 참조하는 파드의 예시가 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # 이 Portworx 볼륨은 이미 존재해야 한다. + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< caution >}} +파드에서 사용하기 이전에 먼저 이름이 `pxvol` 인 PortworxVolume +이 있는지 확인한다. +{{< /caution >}} + +더 자세한 내용과 예시는 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md)에서 찾을 수 있다. + +### quobyte {#quobyte} + +`quobyte` 볼륨을 사용하면 기존 [Quobyte](http://www.quobyte.com) 볼륨을 +파드에 마운트할 수 있다. + +{{< caution >}} +사용하기 위해선 먼저 Quobyte를 설정하고 생성한 볼륨과 +함께 실행해야 한다. +{{< /caution >}} + +Quobyte는 {{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}를 지원한다. +CSI 는 쿠버네티스 내에서 Quobyte 볼륨을 사용하기 위해 권장하는 플러그인이다. Quobyte의 +깃헙 프로젝트에는 예시와 함께 CSI를 사용해서 Quobyte를 배포하기 위한 [사용 설명서](https://github.com/quobyte/quobyte-csi#quobyte-csi)가 있다. + +### rbd {#rbd} + +`rbd` 볼륨을 사용하면 [Rados Block +Device](http://ceph.com/docs/master/rbd/rbd/)를 파드에 마운트할 수 +있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 +내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 +의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를 +"전달(handed off)" 할 수 있다는 것이다. + +{{< caution >}} +RBD를 사용하기 위해선 먼저 Ceph를 설치하고 실행해야 한다. +{{< /caution >}} + +RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 +있다는 것이다. 즉, 데이터셋으로 볼륨을 미리 채운 다음, 필요한 +만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, +RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있으며 +동시 쓰기는 허용되지 않는다. + +더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를 본다. + +### scaleIO {#scaleio} + +ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를 +생성할 수 있는 소프트웨어 기반 스포티리 플랫폼이다. `scaleIO` 볼륨 +플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수 +있다(또는 퍼시스턴트 볼륨 클래임을 위한 새 볼륨을 동적 프로비전할 수 있음, +[ScaleIO 퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/#scaleio)을 본다). + +{{< caution >}} +사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고 +생성한 볼륨과 함께 실행해야 한다. +{{< /caution >}} + +다음은 파드 구성을 ScaleIO와 함께 하는 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-0 +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: pod-0 + volumeMounts: + - mountPath: /test-pd + name: vol-0 + volumes: + - name: vol-0 + scaleIO: + gateway: https://localhost:443/api + system: scaleio + protectionDomain: sd0 + storagePool: sp1 + volumeName: vol-0 + secretRef: + name: sio-secret + fsType: xfs +``` + +자세한 내용은 [ScaleIO 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio)를 본다. + +### secret {#secret} + +`secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 +사용된다. 쿠버네티스 API에 시크릿을 저장하고 쿠버네티스에 직접적으로 연결하지 않고도 +파드에서 사용할 수 있도록 파일로 마운트 할 수 있다. `secret` 볼륨은 +tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토리지에 절대 +기록되지 않는다. + +{{< caution >}} +사용하기 위해선 먼저 쿠버네티스 API에서 시크릿을 생성해야 한다. +{{< /caution >}} + +{{< note >}} +시크릿을 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 시크릿 +업데이트를 수신하지 못한다. +{{< /note >}} + +시크릿에 대해서 [여기](/docs/user-guide/secrets)에 더 자세한 설명이 있다. + +### storageOS {#storageos} + +`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) +볼륨을 파드에 마운트할 수 있다. + +StorageOS 는 쿠버네티스 환경에서 컨테이너로 실행되므로 +쿠버네티스 클러스터의 모든 노드의 로컬 또는 연결된 스토리지에 접근할 수 있다. +노드 장애로부터 보호하기 위해 데이터를 복제할 수 있다. 씬(Thin) 프로비저닝과 +압축은 활용률을 높이고 비용을 절감할 수 있게 한다. + +StorageOS의 핵심은 컨테이너에 파일시스템을 통해 접근할 수 있는 블록 스토리지를 제공하는 것이다. + +StorageOS 컨테이너는 64 비트 리눅스가 필요하고 추가적인 종속성이 없다. +무료 개발자 라이선스를 사용할 수 있다. + +{{< caution >}} +StorageOS 볼륨에 접근하거나 스토리지 용량을 +풀에 제공할 StorageOS 컨테이너를 실행해야 한다. +설치 설명서는 +[StorageOS 문서](https://docs.storageos.com)를 찾아본다. +{{< /caution >}} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + name: redis + role: master + name: test-storageos-redis +spec: + containers: + - name: master + image: kubernetes/redis:v1 + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 + volumeMounts: + - mountPath: /redis-master-data + name: redis-data + volumes: + - name: redis-data + storageos: + # `redis-vol01` 볼륨은 StorageOS에 `default` 네임스페이스로 있어야 한다. + volumeName: redis-vol01 + fsType: ext4 +``` + +동적 프로비저닝과 퍼시스턴트 볼륨 클래임을 포함한 더 많은 정보는 +[StorageOS 예시](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 본다. + +### vsphereVolume {#vspherevolume} + +{{< note >}} +전제조건: 쿠버네티스와 함께 vSphere Cloud Provider가 구성됨. 클라우드공급자 +구성에 대해선 [vSphere 시작 가이드](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)를 참조한다. +{{< /note >}} + +`vsphereVolume` 은 vSphere VMDK 볼륨을 파드에 마운트하는데 사용된다. 볼륨을 +마운트 해제해도 볼륨의 내용이 유지된다. VMFS와 VSAM 데이터스토어를 모두 지원한다. + +{{< caution >}} +파드와 함께 사용하기 위해선 먼저 다음 방법중 하나를 사용해서 VMDK를 생성해야 한다. +{{< /caution >}} + +#### VMDK 볼륨 생성하기 + +다음 중 하나를 선택해서 VMDK를 생성한다. + +{{< tabs name="tabs_volumes" >}} +{{% tab name="vmkfstools를 사용해서 생성" %}} +먼저 ESX에 ssh로 들어간 다음, 다음 명령을 사용해서 VMDK를 생성한다. + +```shell +vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk +``` +{{% /tab %}} +{{% tab name="vmware-vdiskmanager를 사용해서 생성" %}} +다음 명령을 사용해서 VMDK를 생성한다. + +```shell +vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk +``` +{{% /tab %}} + +{{< /tabs >}} + + +#### vSphere VMDK 예시 구성 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-vmdk +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-vmdk + name: test-volume + volumes: + - name: test-volume + # 이 VMDK 볼륨은 이미 있어야 한다. + vsphereVolume: + volumePath: "[DatastoreName] volumes/myDisk" + fsType: ext4 +``` + +더 많은 예시는 [여기](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)에서 확인할 수 있다. + + +## subPath 사용하기 + +때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. `volumeMounts.subPath` +속성을 사용해서 root 대신 참조하는 볼륨 내의 하위 경로를 지정할 수 있다. + +여기에 단일 공유 볼륨을 사용하는 LAMP 스택(리눅스 아파치 Mysql PHP)이 포함된 파드의 예시가 있다. +HTML 내용은 `html` 폴더에 매핑되고 데이터베이스는 `mysql` 폴더에 저장된다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-lamp-site +spec: + containers: + - name: mysql + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "rootpasswd" + volumeMounts: + - mountPath: /var/lib/mysql + name: site-data + subPath: mysql + - name: php + image: php:7.0-apache + volumeMounts: + - mountPath: /var/www/html + name: site-data + subPath: html + volumes: + - name: site-data + persistentVolumeClaim: + claimName: my-lamp-site-data +``` + +### subPath를 확장된 환경 변수와 함께 사용하기 + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} + + +`subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다. +이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다. +`subPath` 와 `subPathExpr` 속성은 상호 배타적이다. + +이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다. 호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod1 +spec: + containers: + - name: container1 + env: + - name: POD_NAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: metadata.name + image: busybox + command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] + volumeMounts: + - name: workdir1 + mountPath: /logs + subPathExpr: $(POD_NAME) + restartPolicy: Never + volumes: + - name: workdir1 + hostPath: + path: /var/log/pods +``` + +## 리소스 + +`emptyDir` 볼륨의 스토리지 매체(디스크, SSD, 등)는 kubelet root +디렉터리(보통 `/var/lib/kubelet`)를 보유한 파일시스템의 +매체에 의해 결정 된다. `emptyDir` 또는 `hostPath` 볼륨이 +사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너간 또는 파드간 +격리는 없다. + +앞으로 `emptyDir` 과 `hostPath` 볼륨이 [리소스](/docs/user-guide/compute-resources) +사양을 사용해서 일정량의 공간을 요청하고, 여러 매체 유형이 +있는 클러스터에 사용할 매체 유형을 선택할 수 +있을 것으로 기대한다. + +## 아웃 오브 트리 볼륨 플러그인 +아웃 오브 트리 볼륨 플러그인에는 컨테이너 스토리지 인터페이스 (CSI) 그리고 +FlexVolume이 포함된다. 스토리지 벤더들은 이 플러그인을 쿠버네티스 리포지터리에 +추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. + +CSI 와 FlexVolume을 도입하기 전에는 모든 볼륨 플러그인(위 +목록의 볼륨 유형과 같은)은 "인 트리(in-tree)" 로 쿠버네티스 핵심 +바이너리와 함께 빌드, 링크, 컴파일 그리고 전달되었고 쿠버네티스 +핵심 API를 확장했다. 이는 새로운 스토리지 시스템을 쿠버네티스( +볼륨 플러그인)에 추가하려면 쿠버네티스 핵심 코드 리포지토리의 코드 확인이 필요했음을 의미한다. + +CSI와 FlexVolume을 통해 쿠버네티스 코드 베이스와는 +독립적으로 볼륨 플러그인을 개발하고, 쿠버네티스 클러스터의 확장으로 배포(설치) +할 수 있다. + +아웃 오브 트리(out-of-tree) 볼륨 플러그인을 생성하려는 스토리지 벤더는 +[이 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)를 참조한다. + +### CSI + +[컨테이너 스토리지 인터페이스](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) +는 컨테이너 오케스트레이션 시스템(쿠버네티스와 같은)을 위한 표준 인터페이스를 +정의하여 임의의 스토리지 시스템을 컨테이너 워크로드에 노출시킨다. + +더 자세한 정보는 [CSI 디자인 제안](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)을 읽어본다. + +CSI 지원은 쿠버네티스 v1.9에서 알파로 도입이 되었고, 쿠버네티스 v1.10에서 +베타로 이동되고 쿠버네티스 v1.13에서 정식(GA)이 되었다. + +{{< note >}} +CSI 규격 버전 0.2와 0.3에 대한 지원은 쿠버네티스 v1.13에서 사용중단(deprecated) +되었고, 향후 릴리스에서 제거될 예정이다. +{{< /note >}} + +{{< note >}} +CSI 드라이버는 일부 쿠버네티스 릴리스에서 호환되지 않을 수 있다. +각각의 쿠버네티스 릴리스와 호환성 매트릭스에 대해 지원되는 +배포 단계는 특정 CSI 드라이버 문서를 참조한다. +{{< /note >}} + +CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 +`csi` 볼륨 유형을 사용해서 CSI 드라이버에 의해 노출된 볼륨에 연결, 마운트, +등을 할 수 있다. + +`csi` 볼륨 유형은 파드에서의 직접 참조를 지원하지 않으며 +`PersistentVolumeClaim` 오브젝트를 통해 파드에서 참조할 수 있다. + +스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을 +구성할 수 있다. + +- `driver`: 사용할 볼륨 드라이버의 이름을 지정하는 문자열 값. + 이 값은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)에 + 정의된 CSI 드라이버가 `GetPluginInfoResponse` 에 반환하는 값과 일치해야 한다. + 쿠버네티스에서 호출할 CSI 드라이버를 식별하고, CSI 드라이버 컴포넌트에서 + CSI 드라이버에 속하는 PV 오브젝트를 식별하는데 사용한다. +- `volumeHandle`: 볼륨을 식별하게 하는 고유한 문자열 값. + 이 값은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)에 + 정의된 CSI 드라이버가 `CreateVolumeResponse` 의 `volume.id` 필드에 반환하는 값과 일치해야 한다. + 이 값은 볼륨을 참조할 때 CSI 볼륨 드라이버에 대한 모든 호출에 + `volume_id` 값을 전달한다. +- `readOnly`: 볼륨을 읽기 전용으로 "ControllerPublished" (연결)할지 + 여부를 나타내는 선택적인 불리언(boolean) 값. 기본적으로 false 이다. 이 값은 + `ControllerPublishVolumeRequest` 의 `readonly` 필드를 + 통해 CSI 드라이버로 전달된다. +- `fsType`: 만약 PV의 `VolumeMode` 가 `Filesystem` 인 경우에 이 필드는 + 볼륨을 마운트하는 데 사용해야 하는 파일시스템을 지정하는 데 사용될 수 있다. 만약 + 볼륨이 포맷되지 않았고 포맷이 지원되는 경우, 이 값은 + 볼륨을 포맷하는데 사용된다. + 이 값은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest` + 그리고 `NodePublishVolumeRequest` 의 `VolumeCapability` + 필드를 통해 CSI 드라이버로 전달된다. +- `volumeAttributes`: 볼륨의 정적 속성을 지정하는 문자열과 문자열을 + 매핑한다. 이 매핑은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)에 + 정의된 대로 CSI 드라이버의 `CreateVolumeResponse` 와 `volume.attributes` + 필드에서 반환되는 매핑과 일치해야 한다. + 이 매핑은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, + 그리고 `NodePublishVolumeRequest` 의 `volume_attributes` 필드를 + 통해 CSI 드라이버로 전달된다. +- `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume` + 그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는 + 민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는 + 선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 + 둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다. +- `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해 + CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 + 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 + 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 + 모든 시크릿이 전달된다. +- `nodePublishSecretRef`: CSI의 `NodePublishVolume` 호출을 완료하기위해 + CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 + 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 + 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 + 모든 시크릿이 전달된다. + +#### CSI 원시(raw) 블록 볼륨 지원 + +{{< feature-state for_k8s_version="v1.14" state="beta" >}} + +1.11 버전부터 CSI는 이전 버전의 쿠버네티스에서 도입된 원시 +블록 볼륨 기능에 의존하는 원시 블록 볼륨에 대한 지원을 +도입했다. 이 기능을 사용하면 외부 CSI 드라이버가 있는 벤더들이 쿠버네티스 +워크로드에서 원시 블록 볼륨 지원을 구현할 수 있다. + +CSI 블록 볼륨은 기능 게이트로 지원하지만, 기본적으로 활성화되어있다. 이 +기능을 위해 활성화 되어야하는 두개의 기능 게이트는 `BlockVolume` 과 +`CSIBlockVolume` 이다. + +[원시 블록 볼륨 지원으로 PV/PVC 설정](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) +방법을 알아본다. + +#### CSI 임시(ephemeral) 볼륨 + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +이 기능을 사용하면 CSI 볼륨을 퍼시스턴트볼륨 대신에 파드 사양에 직접적으로 포함할 수 있다. +이러한 방식으로 지정된 볼륨은 임시적이고 파드 재시작시에는 유지되지 않는다. + +예시 + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: my-csi-app +spec: + containers: + - name: my-frontend + image: busybox + volumeMounts: + - mountPath: "/data" + name: my-csi-inline-vol + command: [ "sleep", "1000000" ] + volumes: + - name: my-csi-inline-vol + csi: + driver: inline.storage.kubernetes.io + volumeAttributes: + foo: bar +``` + +이 기능을 사용하려면 CSIInlineVolume 기능 게이트를 활성화 해야 한다. +쿠버네티스 1.16 시작시 기본적으로 활성화 되어있다. + +CSI 임시 볼륨은 CSI 드라이버의 하위집합에서만 지원된다. CSI 드라이버의 목록은 [여기](https://kubernetes-csi.github.io/docs/drivers.html)를 본다. + +# 개발자 리소스 +CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 [쿠버네티스-csi +문서](https://kubernetes-csi.github.io/docs/)를 참조한다. + +#### 인 트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기 + +{{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +TCSI 마이그레이션 기능이 활성화 되면 기존의 인 트리 플러그인에 +대한 작업을 해당 CSI 플러그인(설치와 구성이 될 것으로 예상한)으로 유도한다. +이 기능은 필요한 변환 논리와 심(shims)을 구현하여 작업을 완전한 +방식으로 재 라우팅 한다. 결과적으로 운영자는 인 트리 플러그인을 대체하는 +CSI 드라이버로 전환할 때 기존 스토리지 클래스, PV 또는 PVC(인 트리 +플러그인 참조)에 대한 구성을 변경할 필요가 없다. + +알파 상태에서 지원되는 작업과 기능에는 프로비저닝/삭제, +연결/분리, 마운트/마운트 해제 그리고 볼륨 크기 재조정이 포함된다. + +CSI 마이그레이션을 지원하고 해당 CSI 드라이버가 구현된 인 트리 플러그인은 +위의 "볼륨 유형" 섹션에 나열되어 있다. + +### FlexVolume {#flexVolume} + +FlexVolume은 버전 1.2 (CSI 이전) 이후 쿠버네티스에 존재하는 +아웃 오브 트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 +접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드(그리고 일부 경우에 마스터)에 +미리 정의된 볼륨 플러그인 경로에 설치해야 한다. + +파드는 `flexvolume` 인 트리 플러그인을 통해 FlexVolume 드라이버와 상호 작용 한다. +더 자세한 내용은 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)에서 찾아볼 수 있다. + +## 마운트 전파(propagation) + +마운트 전파를 통해 컨테이너가 마운트한 볼륨을 동일한 파드의 +다른 컨테이너 또는 동일한 노드의 다른 파드로 공유할 수 있다. + +볼륨 마운트 전파는 Container.volumeMounts의 `mountPropagation` 필드에 의해 제어된다. +그 값은 다음과 같다. + + * `None` - 이 볼륨 마운트는 호스트의 볼륨 또는 해당 서브디렉터리에 + 마운트된 것을 마운트 이후에 수신하지 않는다. + 비슷한 방식으로, 컨테이너가 생성 한 마운트는 호스트에서 볼 수 없다. + 이것이 기본 모드이다. + + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. + + * `HostToContainer` - 이 볼륨 마운트는 볼륨 또는 해당 + 서브디렉터리를 마운트한 정보를 수신한다. + + 다시 말하면, 만약 호스트가 볼륨 마운트 내부에 다른 것을 마운트 + 하더라도 컨테이너가 마운트 된 것을 볼 수 있다. + + 마찬가지로 `Bidirectional` 마운트 전파가 있는 파드가 동일한 마운트가 된 경우에 + 파드에 `HostToContainer` 마운트 전파가 있는 + 컨테이너가 이를 볼 수 있다. + + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. + + * `Bidirectional` - 이 볼륨 마운트는 `HostToContainer` 마운트와 동일하게 작동한다. + 추가로 컨테이너에서 생성된 모든 볼륨 마운트는 동일한 볼륨을 + 사용하는 모든 파드의 모든 컨테이너와 호스트로 다시 전파된다. + + 이 모드의 일반적인 유스 케이스로는 FlexVolume 또는 CSI 드라이버를 사용하는 파드 또는 + `hostPath` 볼륨을 사용하는 호스트에 무언가를 마운트해야 하는 파드이다. + + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. + +{{< caution >}} +`Bidirectional` 마운트 전파는 위험할 수 있다. 이것은 +호스트 운영체제를 손상시킬수 있기에 권한이 있는 컨테이너에서만 +허용된다. 리눅스 커널 동작을 숙지하는 것을 권장한다. +또한 파드내 컨테이너에 의해 생성된 볼륨 마운트는 종료시 +컨테이너에의해 파괴(마운트 해제)되어야 한다. +{{< /caution >}} + +### 구성 +일부 배포판(CoreOS, RedHat/Centos, Ubuntu)에서 마운트 전파가 +제대로 작동하려면 아래와 같이 도커에서의 마운트 공유를 +올바르게 구성해야 한다. + +도커의 `systemd` 서비스 파일을 편집한다. `MountFlags` 를 다음과 같이 설정한다. +```shell +MountFlags=shared +``` +또는 `MountFlags=slave` 가 있으면 제거한다. 이후 도커 데몬을 재시작 한다. +```shell +sudo systemctl daemon-reload +sudo systemctl restart docker +``` + + + +{{% capture whatsnext %}} +* [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index dccde89562..9309a7520f 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -13,8 +13,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도 데몬셋의 일부 대표적인 용도는 다음과 같다. - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행. -- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행. -- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행. +- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행. +- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행. 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, @@ -88,9 +88,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 오직 일부 노드에서만 파드 실행 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 -[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/#nodeselector)와 +[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/#노드-셀렉터-nodeselector)와 일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 -데몬셋 컨트롤러는 [노트 어피니티](/docs/concepts/configuration/assign-pod-node/#node-affinity)와 일치하는 노드에 파드를 생성한다. +데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/configuration/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다. ## 데몬 파드가 스케줄 되는 방법 @@ -161,7 +161,7 @@ nodeAffinity: - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 구성되어있다. 그들은 클라이언트들을 가지지 않는다. - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. -- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 만들고, +- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를 검색한다. - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서 diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 27f2dd359c..9a5d85ebe4 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -22,7 +22,7 @@ weight: 10 레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을 사용한다. -레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents) +레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent) 필드를 통해서 제공되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다. 레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다. 이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다. @@ -250,7 +250,7 @@ matchLabels: ### 레플리카셋과 해당 파드 삭제 -레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다. +레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다. REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로 설정해야 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 3b95e2b47c..0fd4c8bb1f 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -34,7 +34,7 @@ weight: 40 * 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. -* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. +* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다. * [롤링 업데이트](#롤링-업데이트)와 기본 [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를 @@ -121,7 +121,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 `$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 `web-0,web-1,web-2` 이다. 스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 사용할 수 있다. +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 사용할 수 있다. 이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, 여기서 "cluster.local"은 클러스터 도메인이다. 각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 @@ -130,7 +130,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는 파드의 네트워크 신원을 책임지는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 생성할 책임이 있다. +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다. 여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, 그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index 2f8cbc2a61..ff6cc0284f 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -9,7 +9,7 @@ weight: 65 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 -제한하는 TTL 메커니즘을 제공한다. TTL 컨트롤러는 현재 +제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재 [잡(Job)](/docs/concepts/workloads/controllers/jobs-run-to-completion/)만 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 3c8f9af995..76d9d25c36 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -67,8 +67,6 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함. * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가 성공적으로 시작 완료되었음. - * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서 - 지금 당장은 파드를 스케줄할 수 없음. * `ContainersReady`: 파드 내의 모든 컨테이너가 준비 상태임. @@ -256,12 +254,6 @@ status: 파드 준비성 평가에 대한 변경을 촉진하기 위해서, 이전 파드 조건인 `Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다. -K8s 1.11에서, 알파 특징으로서, "파드 준비++" 특징을 사용하기 위해서는 -[특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 `PodReadinessGates`를 -참으로 설정함으로써 명시적으로 활성화해야 한다. - -K8s 1.12에서는, 해당 특징이 기본으로 활성화되어 있다. - ## 재시작 정책 PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index b954a3478e..12d70b2c79 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -13,68 +13,50 @@ weight: 80 오랜 시간 동안 진행해온 누군가로서, 혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로서 기여할 수 있다. -쿠버네티스 문서 내용과 스타일에 -대해 더 많은 정보를 알고 싶다면, -[문서 스타일 개요](/docs/contribute/style/)를 참고하자. +{{% /capture %}} {{% capture body %}} -## 문서 컨트리뷰터 유형 +## 시작하기 -- 쿠버네티스 조직의 _멤버_ 는 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고, - 프로젝트에 어느 정도 시간과 노력을 바친 사람이다. - 멤버십 자격에 대한 구체적인 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 - 참고하라. -- SIG Docs _리뷰어_ 는 문서 풀 리퀘스트(pull request) 리뷰하는 일에 관심을 보여서 - SIG Docs 승인자가 적합한 - GitHub 그룹 및 저장소 내 그룹과 `OWNERS` 파일에 등록한 - 쿠버네티스 조직의 멤버이다. -- SIG Docs _승인자_ 는 지속적으로 프로젝트에 기여를 해온 좋은 입지를 가진 멤버이다. - 승인자는 풀 리퀘스트를 머지(merge)할 수 있고, - 쿠버네티스 조직을 대표하여 콘텐츠를 공개한다. - 승인자는 거대한 쿠버네티스 커뮤니티에서 SIG Docs를 대표할 수 있다. - SIG Docs 승인자의 의무 중 릴리스 조정과 같은 일은 - 상당한 시간을 필요로 한다. +누구든지 문제에 대한 설명이나, 원하는 문서의 개선사항에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)로 변경하는 기여를 할 수 있다. +일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있다. +역할과 권한에 대한 자세한 내용은 +[SIG Docs 참여](/ko/docs/contribute/participating/)를 본다. -## 문서화에 기여할 수 있는 방법 +쿠버네티스 문서는 GitHub 리포지터리에 있다. 우리는 누구나 +기여를 환경하지만, 쿠버네티스 커뮤니티에서 효과적으로 활동하려면 git과 GitHub의 +기초적인 이해가 필요하다. -이 목록은 누구나 할 수 있는 일, 쿠버네티스 조직 멤버가 할 수 있는 일, -그리고 SIG Docs 프로세스의 더 높은 레벨의 접근과 친숙함을 요구하는 일로 나누어졌다. -지속적으로 기여를 하는 것은 -이미 만들어진 도구(tooling)와 조직의 결정을 -이해하는 데 도움이 될 것이다. +문서에 참여하려면 -이것은 쿠버네티스 문서에 기여하는 완전한 방법은 아니지만, -시작하는 데에 도움이 될 것이다. +1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명한다. +2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지한다. +3. [콘텐츠 향상](https://kubernetes.io/docs/contribute/start/#improve-existing-content)과 [변경 검토](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests)의 기본 프로세스를 이해하도록 한다. -- [누구나](/docs/contribute/start/) - - 조치 가능한 이슈 열기 -- [멤버](/docs/contribute/start/) - - 기존 문서 개선 - - [Slack](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 개선을 위한 아이디어 제시 - - 문서 접근성 개선 - - PR에 대한 구속력 없는 피드백 제공 - - 블로그 포스트 또는 사례 연구 작성 -- [리뷰어](/docs/contribute/intermediate/) - - 새로운 기능 문서화 - - 이슈 선별 및 분류 - - PR 리뷰 - - 다이어그램, 그래픽 자료, 내장 스크린샷 생성 - - 현지화(Localization) - - docs 대표로 다른 저장소에 기여 - - 코드 내 사용자 대면 문자열 편집 - - 코드 주석 및 Godoc 개선 -- [승인자](/docs/contribute/advanced/) - - 승인되어 머지된 PR을 바탕으로 컨트리뷰터 콘텐츠 출시 - - docs 대표로 쿠버네티스 릴리스 팀에 참가 - - 스타일 가이드 개선 제안 - - 문서 테스트 개선 제안 - - 쿠버네티스 website 또는 기타 도구(tooling) 개선 제안 +## 기여 모범 사례 +- 명확하고, 의미있는 GIT 커밋 메시지를 작성한다. +- 이슈를 참조하고, PR이 병합될 때 이슈를 자동으로 닫는 _Github 특수 키워드_ 를 포함한다. +- 오타 수정, 스타일 변경 또는 문법 변경과 같이 변경이 적은 PR을 생성할때, 비교적으로 적은 변화로 많은 커밋 개수를 받지 않도록 반드시 커밋을 스쿼시(squash)한다. +- 변경한 코드를 묘사하고, 코드를 변경한 이유를 포함하는 멋진 PR 설명을 포함하고 있는지와 리뷰어를 위한 충분한 정보가 있는지 꼭 확인한다. +- 추가적인 읽을거리들 + - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/) + - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests ) + - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git ) -## 추가적인 기여 방법 +## 다른 방법으로 기여하기 - 트위터나 스택오버플로(Stack Overflow) 등의 온라인 포럼의 쿠버네티스 커뮤니티에 기여하거나 지역 모임과 쿠버네티스 이벤트에 관하여 알고 싶다면 [쿠버네티스 커뮤니티 사이트](/community/)를 확인한다. - 기능 개발에 기여하려면 [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 시작한다. {{% /capture %}} + +{{% capture whatsnext %}} + +- 문서에 기여하는 기본적인 사항들에 대한 자세한 내용은 [기여 시작](/docs/contribute/start/)을 본다. +- 변경을 제안할 때는 [쿠버네티스 문서 스타일가이드](/docs/contribute/style/style-guide/)를 따른다. +- SIG Docs에 대한 더 자세한 정보는 [SIG Docs에 참여하기](/ko/docs/contribute/participating/)를 본다. +- 쿠버네티스 문서 현지화에 대한 자세한 내용은 [쿠버네티스 문서 현지화](/docs/contribute/localization/)를 본다. + +{{% /capture %}} diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index 887118a157..88db56aa34 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -19,7 +19,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 누구나 풀 리퀘스트(PR)를 요청할 수 있고, 누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다. -SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수도 있다. +[멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수 있다. 이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다. 쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) @@ -34,51 +34,47 @@ SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인 ## 역할과 책임 -풀 리퀘스트가 콘텐츠를 게재하는데 사용되는 브랜치(현재는 `master`)에 머지되면, 해당 콘텐츠가 세상에 -발행되어 널리 읽힐 수 있게 된다. 발행된 콘텐츠가 높은 품질을 유지하도록, -SIG Docs 승인자만 풀 리퀘스트를 머지할 수 있도록 제한한다. -다음과 같이 진행된다. +- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다. +- 쿠버네티스 조직의 **맴버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 맴버십 기준은 [커뮤니티 맴버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다. +- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로 + 문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에 + 의해 GitHub 리포지터리에 있는 GitHub + 그룹과 `OWNER` 파일에 추가되었다. +- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준 + 좋은 맴버이다. 승인자는 쿠버네티스 조직을 대신해서 + 풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다. + 또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다. + 릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는 + 상당한 시간 투입이 필요하다. -- 풀 리퀘스트에 `lgtm`과 `approve` 레이블이 부여되고 `hold` 레이블이 없는 경우에, 해당 - 풀 리퀘스트가 자동으로 머지된다. -- 쿠버네티스 조직 멤버와 SIG Docs 승인자는 코멘트를 추가해서(`/hold` 코멘트를 추가하거나 - `/lgtm` 코멘트를 달지 않아서) 주어진 풀 리퀘스트가 - 자동으로 머지되는 것을 막을 수 있다. -- 쿠버네티스 멤버 누구나 `/lgtm` 코멘트를 달아서 `lgtm` 레이블을 추가할 수 있다. -- `/approve` 코멘트를 달아서 풀 리퀘스트를 머지할 수 있는 SIG Docs 멤버는 승인자 뿐이다. - 일부 승인자는 추가로 [PR Wrangler](#pr-wrangler) 또는 - [SIG Docs chairperson](#sig-docs-chairperson) 같이 - 특화된 역할을 수행한다. +## 모든 사람 -쿠버네티스 조직 멤버와 SIG Docs 승인자 역할 사이의 기대와 차이에 대한 보다 많은 정보는 -[컨트리뷰터 유형](/docs/contribute#types-of-contributor) 문서를 참고한다. -다음 섹션에서는 이런 역할과 SIG Docs에서 -이들이 작동하는 방식에 대해 -보다 상세한 내용을 다룬다. +누구나 다음 작업을 할 수 있다. -### 모든 사람 +- 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기. +- 풀 리퀘스트/ 에 대한 구속력 없는 피드백 제공 +- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다. +- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다. + {{< note >}} + 만약 쿠버네티스 조직의 맴버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다. + {{< /note >}} -문서를 포함해서, 쿠버네티스의 모든 부분에 대해서 누구나 이슈를 제기할 수 있다. +[CLS에 서명](/docs/contribute/start#sign-the-cla) 후에 누구나 다음을 할 수 있다. +- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. -CLA에 서명한 누구나 풀 리퀘스트를 제출할 수 있다. CLA에 서명할 수 없다면, -쿠버네티스 프로젝트는 컨트리뷰션을 수용할 수 없다. +## 맴버 -### 멤버 +맴버는 [맴버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 맴버로부터 기여를 환경하며, +기술적 정확성에 대한 다른 SIG 맴버들의 검토를 수시로 요청한다. -[쿠버네티스 조직](https://github.com/kubernetes)의 모든 멤버가 풀 리퀘스트를 리뷰할 수 있고, -기술적 정확도를 기하기 위해 SIG Docs 팀 멤버가 다른 분과회 멤버의 리뷰를 요청하는 일도 자주 -발생한다. -SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주는 리뷰와 피드백 또한 환영한다. -풀 리퀘스트에 `/lgtm` 코멘트를 달아서 찬성 의사를 표시할 수 있다. -쿠버네티스 조직의 멤버가 아니라면, -`/lgtm` 코멘트는 자동화 시스템에 유효하지는 않다. +쿠버네티스 조직의 모든 맴버는 다음 작업을 할 수 있다. -쿠버네티스 조직의 모든 멤버는 `/hold` 코멘트를 달아서 풀 리퀘스트가 머지되는 것을 막을 수 있다. -또한 모든 멤버가 `/hold` 코멘트를 삭제해서 PR이 머지될 수 있도록 할 수도 있다. -해당 PR이 이미 적임자로부터 -`/lgtm`과 `/approve`를 받은 경우라면 말이다. +- [모든 사람](#모든-사람) 하위에 나열된 모든 것 +- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다. +- 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다. +- 코멘트에 `/assgin` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다. -#### 멤버 되기 +### 멤버 되기 최소 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 경우, 쿠버네티스 조직의 [멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 @@ -108,20 +104,29 @@ SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주 해당 GitHub 이슈를 종료한다. 축하한다, 이제 멤버가 되었다! -어떤 이유에서 멤버십 요청이 즉시 수용되지 않는 경우, +만약 맴버십 요청이 받아들여지지 않으면, 멤버십 위원회에서 재지원 전에 필요한 정보나 단계를 알려준다. -### 리뷰어 +## 리뷰어 리뷰어는 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참고한다. +GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을 +제공한다. 리뷰어는 다음 작업을 수행할 수 있다. -리뷰어는 문서 풀 리퀘스트를 리뷰하고 -제안받은 변경에 대한 피드백을 제공한다. +- [모든 사람](#모든-사람)과 [맴버](#맴버)에 나열된 모든 것을 수행 +- 새 기능의 문서화 +- 이슈 해결 및 분류 +- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공 +- 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성 +- 현지화 +- 코드에서 사용자 화면 문자열 편집 +- 코드 코멘트 개선 -자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 컨트리뷰터는 해당 풀 리퀘스트에 +### 풀 리퀘스트에 대한 리뷰어 할당 + +자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 사용자는 해당 풀 리퀘스트에 `/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다. 풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로, 리뷰어는 `/lgtm` 코멘트를 @@ -136,11 +141,7 @@ GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-wit 리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다. -SIG Docs 리뷰어가 되는 방법과 -수반되는 책임과 시간 할애에 대한 보다 많은 정보는 -[리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다. - -#### 리뷰어 되기 +### 리뷰어 되기 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을 충족하면, SIG Docs 리뷰어가 될 수 있다. @@ -161,26 +162,27 @@ SIG Docs 리뷰어가 되는 방법과 GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. -### 승인자 +## 승인자 승인자는 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참조한다. -승인자는 PR을 머지할 수 있으므로, 쿠버네티스 웹사이트에 콘텐츠를 게재할 수 있다. -PR을 승인하려면, 승인자는 `/approve` 코멘트를 해당 PR에 남긴다. -승인자가 아닌 누군가가 승인 코멘트를 남기더라도, -자동화 시스템은 이를 무시한다. +승인자는 다음의 작업을 할 수 있다. + +- [모든 사람](#모든-사람), [맴버](#맴버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다. +- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다. + 만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다. +- 쿠버네티스 릴리즈팀에 문서 담당자로 참여 +- 스타일 가이드 개선 제안 +- 문서 테스트 개선 제안 +- 쿠버네티스 웹사이트 또는 다른 도구 개선 제안 PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는 해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만 `/lgtm`을 남겨야한다. -SIG Docs 승인자가 되는 방법과 -수반되는 책임과 시간 할애에 대한 보다 많은 정보는 -[리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다. - -#### 승인자 되기 +### 승인자 되기 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 충족하면, SIG Docs 승인자가 될 수 있다. @@ -201,7 +203,7 @@ SIG Docs 승인자가 되는 방법과 GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. -#### 승인자의 책임 +### 승인자의 책임 승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다. @@ -209,7 +211,7 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. -- 제안된 변경이 컨트리뷰션 가이드 라인에 적합한지 확인한다. +- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. 질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다. @@ -219,16 +221,11 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm - 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. -#### PR Wrangler - -SIG Docs 승인자는 -[PR Wrangler 회람 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 -참여하여 주 단위로 돌아가며 역할을 수행한다. -SIG Docs는 모든 승인자들이 이 회람에 참여하기를 기대한다. 보다 자세한 내용은 -[일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) +- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 +것으로 기대한다. [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 문서를 참고한다. -#### SIG Docs chairperson +## SIG Docs chairperson SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와 다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 @@ -285,6 +282,24 @@ OWNERS 파일과 마크다운 파일 내 전문의 조합은 자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를 PR 소유자에게 조언하는데 활용된다. +## 병합 작업 방식 + +풀 리퀘스트 요청이 콘텐츠(현재 `master`)를 발행하는데 사용하는 +브랜치에 병합되면 그 내용이 전 세계에 공개된다. 게시된 콘텐츠의 +품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. +작동 방식은 다음과 같다. + +- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고, + 모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다. +- 쿠버네티스 조직의 맴버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의 + 자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는 + `/lgtm` 코멘트 보류). +- 모든 쿠버네티스 맴버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. +- SIG Docs 승인자들만이 코멘트에 `/approve` 를 + 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 + [PR Wrangler](#pr-wrangler) EHsms [SIG Docs 의장](#sig-docs-chairperson)과 + 같은 특정 역할도 수행한다. + {{% /capture %}} {{% capture whatsnext %}} @@ -296,4 +311,3 @@ PR 소유자에게 조언하는데 활용된다. {{% /capture %}} - diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index d12c0a9d28..7bf1eb4579 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -17,12 +17,7 @@ content_template: templates/concept ## API 레퍼런스 * [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 -* 쿠버네티스 API 버전 - * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) - * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) - * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) - * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) - * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) +* [Kubernetes API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) ## API 클라이언트 라이브러리 @@ -37,18 +32,17 @@ content_template: templates/concept ## CLI 레퍼런스 -* [kubectl](/docs/user-guide/kubectl-overview) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. - * [JSONPath](/docs/user-guide/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. -* [kubeadm](/docs/admin/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. -* [kubefed](/docs/admin/kubefed/) - 연합된(federated) 클러스터 관리를 도와주는 CLI 도구. +* [kubectl](/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. + * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. +* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. ## 설정 레퍼런스 -* [kubelet](/docs/admin/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다. -* [kube-apiserver](/docs/admin/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API. -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬. -* [kube-proxy](/docs/admin/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다. -* [kube-scheduler](/docs/admin/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러. +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다. +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API. +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬. +* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다. +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러. ## 설계 문서 diff --git a/content/ko/docs/reference/glossary/device-plugin.md b/content/ko/docs/reference/glossary/device-plugin.md index cd850a828b..85fe177e6b 100644 --- a/content/ko/docs/reference/glossary/device-plugin.md +++ b/content/ko/docs/reference/glossary/device-plugin.md @@ -4,14 +4,26 @@ id: device-plugin date: 2019-02-02 full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > - 쿠버네티스에서 동작하는 컨테이너로, 공급 업체 고유의 리소스에 대한 액세스를 제공한다. + 파드가 공급자별 초기화 또는 설정이 필요한 장치에 접근할 수 있도록 하는 소프트웨어 확장 aka: tags: - fundamental - extension --- - 장치 플러그인은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. + 장치 플러그인은 워커\ + {{< glossary_tooltip term_id="node" text="노드">}}에서 실행되며, + 공급자별 초기화 또는 설정 단계가 필요한 로컬 하드웨어와 + 같은 리소스에 접근할 수 있는 + {{< glossary_tooltip term_id="pod" text="파드">}}. -[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로도 디플로이 가능하다. +장치 플러그인은 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}에 +리소스를 알리기에 워크로드 파드는 해당 파드가 실행중인 +노드와 관련된 하드웨어 기능에 접근할 수 있다. +장치 플러그인을 {{< glossary_tooltip term_id="daemonset" >}}으로 배포하거나, +각 대상 노드에 직접 장치 플러그인 소프트웨어를 설치할 수 있다. + +[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +의 더 자세한 정보를 +본다 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 9f641244d8..a8f7f78955 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -140,7 +140,7 @@ EOF # 기본 출력을 위한 Get 커맨드 kubectl get services # 네임스페이스 내 모든 서비스의 목록 조회 kubectl get pods --all-namespaces # 모든 네임스페이스 내 모든 파드의 목록 조회 -kubectl get pods -o wide # 네임스페이스 내 모든 파드의 상세 목록 조회 +kubectl get pods -o wide # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회 kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회 kubectl get pods # 네임스페이스 내 모든 파드의 목록 조회 kubectl get pod my-pod -o yaml # 파드의 YAML 조회 @@ -156,9 +156,8 @@ kubectl get services --sort-by=.metadata.name # 재시작 횟수로 정렬된 파드의 목록 조회 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# test 네임스페이스를 가지는 PersistentVolumes을 용량별로 정렬해서 조회 - -kubectl get pv -n test --sort-by=.spec.capacity.storage +# PersistentVolumes을 용량별로 정렬해서 조회 +kubectl get pv --sort-by=.spec.capacity.storage # app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회 kubectl get pods --selector=app=cassandra -o \ diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index f02188813b..3cc93f7c7f 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -69,6 +69,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | +| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | | Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | {{% /capture %}} diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 8e6bc5e668..4b5b87675a 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -37,7 +37,7 @@ card: |커뮤니티 |생태계 | | ------------ | -------- | | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | | [Minishift](https://docs.okd.io/latest/minishift/)| | | [MicroK8s](https://microk8s.io/)| | | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index 4c8df0c805..140bc4088d 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -199,7 +199,11 @@ minikube start --vm-driver= * hyperv ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) 다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다. * vmware ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) -* none (쿠버네티스 컴포넌트를 VM이 아닌 호스트 상에서 구동한다. 개인용 워크스테이션에서 none 드라이버를 사용하는 것을 권장하지 않는다. 이 드라이버를 사용하려면 도커와 리눅스 환경이 필요하다.([도커 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))) +* none (쿠버네티스 컴포넌트를 가상 머신이 아닌 호스트 상에서 구동한다. 리눅스를 실행중이어야 하고, {{< glossary_tooltip term_id="docker" >}}가 설치되어야 한다.) + +{{< caution >}} +`none` 드라이버를 사용한다면 일부 쿠버네티스 컴포넌트는 Minikube 환경 외부에 있는 부작용이 있는 권한을 가진 컨테이너로 실행된다. 이런 부작용은 개인용 워크스테이션에는 `none` 드라이버가 권장하지 않는 것을 의미 한다. +{{< /caution >}} #### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기 Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index b5758996af..8dd1b00d77 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -15,7 +15,7 @@ weight: 10 {{< caution >}} 컨테이너를 실행할 때 runc가 시스템 파일 디스크립터를 처리하는 방식에서 결함이 발견되었다. -악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며 +악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며 따라서 컨테이너 호스트 시스템에서 임의의 명령을 실행할 수 있다. 이 문제에 대한 자세한 내용은 @@ -34,18 +34,18 @@ weight: 10 ### Cgroup 드라이버 -Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는 -root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. -Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. -컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. +Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는 +root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. +Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. +컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. systemd와 함께`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다. -Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다. -단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고, -기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다. -관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는 -`cgroupfs`를 사용하고 나머지 프로세스는 -`systemd`를 사용하도록 노드가 설정된 경우, +Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다. +단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고, +기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다. +관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는 +`cgroupfs`를 사용하고 나머지 프로세스는 +`systemd`를 사용하도록 노드가 설정된 경우, 리소스가 부족할 때 불안정해지는 사례를 본 적이 있다. 컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면 @@ -53,7 +53,7 @@ Control group은 프로세스에 할당된 리소스를 제한하는데 사용 {{< caution >}} 클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 권장하지 않는다. -하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면, +하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면, 컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 PodSandBox를 재생성을 시도할 때, 에러가 발생할 수 있다. kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. 추천하는 방법은 워크로드에서 노드를 제거하고, 클러스터에서 제거한 다음 다시 결합시키는 것이다. @@ -62,7 +62,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. ## Docker 각 머신들에 대해서, Docker를 설치한다. -버전 19.03.4가 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. +버전 19.03.4가 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. 쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 Docker 버전의 지속적인 파악이 필요하다. 시스템에 Docker를 설치하기 위해서 아래의 커맨드들을 사용한다. @@ -72,8 +72,8 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. # Docker CE 설치 ## 리포지터리 설정 ### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치 -apt-get update && apt-get install \ - apt-transport-https ca-certificates curl software-properties-common +apt-get update && apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 ### Docker의 공식 GPG 키 추가 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - @@ -160,6 +160,11 @@ systemctl restart docker 시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다. +{{< note >}} +CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 버전이 일치해야 한다. +더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o)를 본다. +{{< /note >}} + ### 선행 조건 ```shell @@ -213,7 +218,7 @@ systemctl start crio ## Containerd -이 섹션은 `containerd`를 CRI 런타임으로써 사용하는데 필요한 단계를 담고 있다. +이 섹션은 `containerd`를 CRI 런타임으로써 사용하는데 필요한 단계를 담고 있다. Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사용한다. @@ -299,4 +304,4 @@ kubeadm을 사용하는 경우에도 마찬가지로, 수동으로 자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다. -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 0be5cfc5ce..75929ae973 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -352,7 +352,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy - 노드, 파드, 서비스에 접근하는 데 사용될 수 있다 - 서비스에 접근하는 데 사용되면 load balacing한다 -1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips): - 각 노드 상에서 실행된다 - UDP와 TCP를 proxy한다 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 index 46ca07d452..f9d87d9095 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -79,7 +79,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. -- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. +- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. 클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다. 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 9f1be04977..f563fae04b 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 @@ -8,7 +8,7 @@ title: 리소스 모니터링 도구 애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면, 애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다. 컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod), -[서비스](/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 +[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서 애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다. 이 정보는 애플리케이션의 성능을 평가하고 diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index 83f787b152..328d1d35da 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -81,7 +81,14 @@ kubectl apply -f <디렉터리>/ kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml ``` {{< note >}} -`diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. +`diff`는 `kube-apiserver`의 활성화가 필요한 +[서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. + +`diff` 는 dry-run 모드에서 서버 측 적용 요청을 수행하므로, +`PATCH`, `CREATE`, 그리고 `UPDATE` 권한을 부여해야 한다. +자세한 것은 +[Dry-Run 인증](/docs/reference/using-api/api-concepts#dry-run-authorization)을 본다. + {{< /note >}} `kubectl apply`를 사용하여 오브젝트를 생성한다. 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 27ae2c2f52..81970f5a6f 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 @@ -57,14 +57,19 @@ index.php는 CPU 과부하 연산을 수행한다. ?> ``` -첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다. +첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를 +시작하고 서비스로 노출시킨다. +{{< codenew file="application/php-apache.yaml" >}} + + +다음의 명령어를 실행한다. ```shell -kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80 +kubectl apply -f https://k8s.io/examples/application/php-apache.yaml ``` ``` -service/php-apache created deployment.apps/php-apache created +service/php-apache created ``` ## Horizontal Pod Autoscaler 생성 diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index e3ba3cf282..53c70a6714 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -154,12 +154,15 @@ HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은 큰 값이 선택된다. 이러한 메트릭 중 어떠한 것도 원하는 레플리카 수로 변환할 수 없는 경우(예 : 메트릭 API에서 메트릭을 가져오는 중 오류 발생) 스케일을 건너뛴다. +이는 하나 이상의 메트릭이 +현재 값보다 높은 `desiredReplicas` 을 제공하는 경우 +HPA가 여전히 확장할 수 있음을 의미한다. -마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는 -구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의 +마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. +컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다. -즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의 -영향을 완만하게 한다. +즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 +메트릭 값의 영향을 완만하게 한다. ## API 오브젝트 @@ -206,8 +209,8 @@ Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 평가된 메트릭의 동적인 특징 때문에 레플리카 수가 자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다. -v1.6부터 클러스터 운영자는 `kube-controller-manager` 구성 -요소의 플래그로 노출된 글로벌 HPA 설정을 조정하여 이 문제를 완화할 수 있다. +v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로 +노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다. v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한 필요성을 제거하였다. @@ -283,4 +286,4 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. * kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제. -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index e8de40ce96..b50856ff08 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -74,9 +74,17 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) -{{< note >}} -Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않는다. none 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 에서 도커를 apt로 설치하기를 사용하는 것을 권장한다. 도커의 스냅 설치는 minikube에서 작동하지 않는다. -{{< /note >}} +Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. +이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. + +데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우, +Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다. +[도커](https://www.docker.com/products/docker-desktop)에서 `.deb` 패키지를 다운로드 할 수 있다. + +{{< caution >}} +`none` VM 드라이버는 보안과 데이터 손실 이슈를 일으킬 수 있다. +`--vm-driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다. +{{< /caution >}} ### 패키지를 이용하여 Minikube 설치 diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 858bb59f58..e3f9246a4f 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -329,7 +329,7 @@ Events: 현재 쿠버네티스는 AppArmor 프로파일을 노드에 적재하기 위한 네이티브 메커니즘을 제공하지 않는다. 프로파일을 설정하는 여러 방법이 있다. 예를 들면 다음과 같다. -* 각 노드에서 파드를 실행하는 [데몬셋](/docs/concepts/workloads/controllers/daemonset/)을 통해서 +* 각 노드에서 파드를 실행하는 [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 통해서 올바른 프로파일이 적재되었는지 확인한다. 예시 구현은 [여기](https://git.k8s.io/kubernetes/test/images/apparmor-loader)에서 찾아볼 수 있다. * 노드 초기화 시간에 노드 초기화 스크립트(예를 들어 Salt, Ansible 등)나 @@ -340,7 +340,7 @@ Events: 스케줄러는 어떤 프로파일이 어떤 노드에 적재되는지 고려하지 않으니, 프로파일 전체 집합이 모든 노드에 적재되어야 한다. 대안적인 방법은 각 프로파일(혹은 프로파일의 클래스)을 위한 노드 레이블을 노드에 추가하고, -[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/)를 이용하여 +[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/)를 이용하여 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다. ### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy} diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 5c7470ef63..33a8ac05ff 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -10,12 +10,12 @@ menu:

Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.

card: name: tutorials - weight: 10 + weight: 10 --- {{% capture overview %}} -이 튜토리얼에서는 [Minikube](/ko/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 +이 튜토리얼에서는 [Minikube](/ko/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 쿠버네티스에서 Node.js 로 작성된 간단한 Hello World 애플리케이션을 어떻게 실행하는지 살펴본다. Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. @@ -69,7 +69,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/pod/)는 관리와 네트워킹 목적으로 함께 묶여 있는 하나 이상의 컨테이너 그룹이다. -이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스 +이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스 [*디플로이먼트*](/ko/docs/concepts/workloads/controllers/deployment/)는 파드의 헬스를 검사해서 파드의 컨테이너가 종료되었다면 재시작해준다. 파드의 생성 및 스케일링을 관리하는 방법으로 디플로이먼트를 권장한다. @@ -117,7 +117,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ```shell kubectl config view ``` - + {{< note >}}`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개관](/docs/user-guide/kubectl-overview/)을 살펴보자.{{< /note >}} ## 서비스 만들기 @@ -125,14 +125,14 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 기본적으로 파드는 쿠버네티스 클러스터 내부의 IP 주소로만 접근할 수 있다. `hello-node` 컨테이너를 쿠버네티스 가상 네트워크 외부에서 접근하려면 파드를 쿠버네티스 -[*서비스*](/docs/concepts/services-networking/service/)로 노출해야 한다. +[*서비스*](/ko/docs/concepts/services-networking/service/)로 노출해야 한다. 1. `kubectl expose` 명령어로 퍼블릭 인터넷에 파드 노출하기 ```shell kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - + `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기 원한다는 뜻이다. @@ -199,13 +199,13 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네 storage-provisioner: enabled storage-provisioner-gluster: disabled ``` - -2. 한 애드온을 활성화 한다. 예를 들어 `heapster` + +2. 한 애드온을 활성화 한다. 예를 들어 `metrics-server` ```shell minikube addons enable heapster ``` - + 다음과 유사하게 출력된다. ``` @@ -246,7 +246,7 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네 ```shell minikube addons disable heapster ``` - + 다음과 유사하게 출력된다. ``` @@ -279,7 +279,7 @@ minikube delete {{% capture whatsnext %}} * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다. -* [애플리케이션 배포](/docs/user-guide/deploying-applications/)에 대해서 더 배워 본다. -* [서비스 오브젝트](/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. +* [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다. +* [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 719ab6e1b7..23ba647830 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -23,8 +23,8 @@ content_template: templates/tutorial * [NAT](https://en.wikipedia.org/wiki/Network_address_translation): 네트워크 주소 변환 * [소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소 * [대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소 -* [VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은 -* [Kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다. +* [VIP](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은 +* [Kube-proxy](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다. ## 전제 조건 @@ -34,7 +34,7 @@ content_template: templates/tutorial 작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다. ```console -kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4 +kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4 ``` 출력은 다음과 같다. ``` @@ -57,7 +57,7 @@ deployment.apps/source-ip-app created ## Type=ClusterIP인 서비스에서 소스 IP 쿠버네티스 1.2부터 기본으로 제공하는 -[iptables 모드](/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우 +[iptables 모드](/ko/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우 클러스터 내에서 클러스터 IP로 패킷을 보내면 소스 NAT를 통과하지 않는다. Kube-proxy는 이 모드를 `proxyMode` 엔드포인트를 통해 노출한다. @@ -122,7 +122,7 @@ client_address는 클라이언트 파드와 서버 파드가 같은 노드 또 ## Type=NodePort인 서비스에서 소스 IP -쿠버네티스 1.5부터 [Type=NodePort](/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은 +쿠버네티스 1.5부터 [Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은 소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다. ```console @@ -221,7 +221,7 @@ client_address=104.132.1.79 ## Type=LoadBalancer인 서비스에서 소스 IP -쿠버네티스 1.5 부터 [Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)인 서비스로 +쿠버네티스 1.5 부터 [Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer)인 서비스로 보낸 패킷은 소스 NAT를 기본으로 하는데, `Ready` 상태로 모든 스케줄된 모든 쿠버네티스 노드는 로드 밸런싱 트래픽에 적합하다. 따라서 엔드포인트가 없는 노드에 패킷이 도착하면 시스템은 엔드포인트를 *포함한* 노드에 프록시를 diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 45056e8622..59fdbbc7e3 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -17,7 +17,7 @@ weight: 10 * [파드](/docs/user-guide/pods/single-container/) * [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/) -* [헤드리스 서비스(Headless Services)](/docs/concepts/services-networking/service/#headless-services) +* [헤드리스 서비스(Headless Services)](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) * [퍼시스턴트볼륨(PersistentVolumes)](/docs/concepts/storage/persistent-volumes/) * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) @@ -51,7 +51,7 @@ weight: 10 아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인 예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)인 `nginx` 를 생성한다. {{< codenew file="application/web/web.yaml" >}} diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 10c011aa3b..72c090988c 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -29,7 +29,7 @@ weight: 30 {{% /capture %}} {{% capture objectives %}} -* 카산드라 헤드리스 [*서비스*](/docs/concepts/services-networking/service/)를 생성하고 검증한다. +* 카산드라 헤드리스 [*서비스*](/ko/docs/concepts/services-networking/service/)를 생성하고 검증한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 검증한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 수정한다. @@ -37,7 +37,7 @@ weight: 30 {{% /capture %}} {{% capture prerequisites %}} -이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 +이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/ko/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 * *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자. @@ -65,7 +65,7 @@ minikube start --memory 5120 --cpus=4 {{% capture lessoncontent %}} ## 카산드라 헤드리스 서비스 생성하기 -쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. +쿠버네티스 [서비스](/ko/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. 다음의 `서비스`는 쿠버네티스 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다. 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 71919aad75..868a8e9c41 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 @@ -233,7 +233,7 @@ kubectl apply -k ./ * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자. * [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자. -* [포트 포워딩](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. +* [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. {{% /capture %}} diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 06dc81fed4..7486a7fe71 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -6,9 +6,9 @@ weight: 40 {{% capture overview %}} 이 튜토리얼은 [아파치 ZooKeeper](https://zookeeper.apache.org) -쿠버네티스에서 [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)과 -[파드디스룹선버짓(PodDisruptionBudget)](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과 -[파드안티어피니티(PodAntiAffinity)](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다. +쿠버네티스에서 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 +[파드디스룹선버짓(PodDisruptionBudget)](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과 +[파드안티어피니티(PodAntiAffinity)](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다. {{% /capture %}} {{% capture prerequisites %}} @@ -18,12 +18,12 @@ weight: 40 - [파드](/docs/user-guide/pods/single-container/) - [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) -- [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services) +- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) - [퍼시스턴트볼륨](/docs/concepts/storage/volumes/) - [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) - [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) - [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget) -- [파드안티어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) +- [파드안티어피니티](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티) - [kubectl CLI](/docs/user-guide/kubectl/) 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다. @@ -62,8 +62,8 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변 ## ZooKeeper 앙상블 생성하기 아래 메니페스트에는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services), -[서비스](/docs/concepts/services-networking/service/), +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스), +[서비스](/ko/docs/concepts/services-networking/service/), [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다. 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 78b72c9e73..0f7360273e 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 @@ -80,8 +80,17 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s - 참고: 만약 외부 IP 주소가 \으로 표시되면 잠시 기다린 다음, - 동일한 명령어를 다시 입력한다. + {{< note >}} + + `type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer를 참조한다. + + {{< /note >}} + + {{< note >}} + + 만약 외부 IP 주소가 \으로 표시되면 잠시 기다린 다음, 동일한 명령어를 다시 입력한다. + + {{< /note >}} 1. 서비스에 대한 자세한 정보를 확인한다. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index a1f24755b8..4753c83b93 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -77,7 +77,7 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다. ### Redis 마스터 서비스 생성하기 -방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. +방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. {{< codenew file="application/guestbook/redis-master-service.yaml" >}} @@ -197,7 +197,7 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 ### 프론트엔드 서비스 생성하기 -서비스의 기본 유형은 [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. +서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. 게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 통해서만 서비스를 노출할 수 있다. diff --git a/content/ko/examples/application/php-apache.yaml b/content/ko/examples/application/php-apache.yaml new file mode 100644 index 0000000000..5eb04cfb89 --- /dev/null +++ b/content/ko/examples/application/php-apache.yaml @@ -0,0 +1,39 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: php-apache +spec: + selector: + matchLabels: + run: php-apache + replicas: 1 + template: + metadata: + labels: + run: php-apache + spec: + containers: + - name: php-apache + image: k8s.gcr.io/hpa-example + ports: + - containerPort: 80 + resources: + limits: + cpu: 500m + requests: + cpu: 200m + +--- + +apiVersion: v1 +kind: Service +metadata: + name: php-apache + labels: + run: php-apache +spec: + ports: + - port: 80 + selector: + run: php-apache + diff --git a/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml b/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml new file mode 100644 index 0000000000..42b2a2a296 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-egress +spec: + podSelector: {} + egress: + - {} + policyTypes: + - Egress diff --git a/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml new file mode 100644 index 0000000000..462912dae4 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-ingress +spec: + podSelector: {} + ingress: + - {} + policyTypes: + - Ingress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-all.yaml b/content/ko/examples/service/networking/network-policy-default-deny-all.yaml new file mode 100644 index 0000000000..5c0086bd71 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-all.yaml @@ -0,0 +1,10 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all +spec: + podSelector: {} + policyTypes: + - Ingress + - Egress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml b/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml new file mode 100644 index 0000000000..a4659e1417 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-egress +spec: + podSelector: {} + policyTypes: + - Egress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml new file mode 100644 index 0000000000..e823802487 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-ingress +spec: + podSelector: {} + policyTypes: + - Ingress diff --git a/content/ru/docs/concepts/overview/what-is-kubernetes.md b/content/ru/docs/concepts/overview/what-is-kubernetes.md index 3289c8980e..0d57355d1f 100644 --- a/content/ru/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ru/docs/concepts/overview/what-is-kubernetes.md @@ -58,7 +58,7 @@ Kubernetes предоставляет вам: * **Мониторинг сервисов и распределение нагрузки** Kubernetes может обнаружить контейнер, используя имя DNS или собственный IP-адрес. Если трафик в контейнере высокий, Kubernetes может сбалансировать нагрузку и распределить сетевой трафик, чтобы развертывание было стабильным. -* **Орекстрация хранилища** +* **Оркестрация хранилища** Kubernetes позволяет вам автоматически смонтировать систему хранения по вашему выбору, такую как локальное хранилище, провайдеры общедоступного облака и многое другое. * **Автоматическое развертывание и откаты** Используя Kubernetes можно описать желаемое состояние развернутых контейнеров и изменить фактическое состояние на желаемое. Например, вы можете автоматизировать Kubernetes на создание новых контейнеров для развертывания, удаления существующих контейнеров и распределения всех их ресурсов в новый контейнер. diff --git a/content/ru/docs/contribute/advanced.md b/content/ru/docs/contribute/advanced.md new file mode 100644 index 0000000000..b450c088b5 --- /dev/null +++ b/content/ru/docs/contribute/advanced.md @@ -0,0 +1,196 @@ +--- +title: Участие для опытных +slug: advanced +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +На этой странице предполагается, что вы изучили темы [Участие для начинающих](/ru/docs/contribute/start/) и [Участие для опытных](/ru/docs/contribute/intermediate/) и теперь хотите узнать ещё больше про то, как можно помочь проекту. Для решения некоторых задач вам потребуется использовать Git из командной строки и прочие другие инструменты. + +{{% /capture %}} + +{{% capture body %}} + +## Дежурный по PR на неделю + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) группы SIG Docs регулярно по очереди становятся дежурными по PR в репозитории и поэтому участвуют в [графике ротации PR-дежурного](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) на неделю. + +В обязанности дежурного по PR входят: + +- Ежедневно проверять [открытые пулреквесты](https://github.com/kubernetes/website/pulls) для контроля качества и соблюдения рекомендаций по [оформлению](/docs/contribute/style/style-guide/) и [содержимому](/docs/contribute/style/content-guide/). + - В первую очередь просматривайте самые маленькие пулреквесты (`size/XS`), и только потом беритесь за самые большие (`size/XXL`). + - Проверяйте столько пулреквестов, сколько сможете. +- Проследить, что CLA подписан каждым участником. + - Помогайте новым участникам подписать [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). + - Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, чтобы они подписали CLA. +- Оставить свое мнение о предложенных изменениях и поспособствовать в проведении технического обзора от членов других SIG-групп. + - Предложить исправления для измененного контента в PR. + - Если вы хотите убедиться в правильности контента, прокомментируйте PR и задайте уточняющие вопросы. + - Добавьте нужны метки с `sig/`. + - Если нужно, то назначьте рецензентов из секции `reviewers:` в фронтальной части файла. + - Добавьте метки `Docs Review` и `Tech Review` для установки статуса проверки PR. + - Добавьте метку `Needs Doc Review` или `Needs Tech Review` для пулреквестов, которые ещё не были проверены. + - Добавьте метку `Doc Review: Open Issues` или `Tech Review: Open Issues` для пулреквестов, которые были проверены и требуют дополнительную информацию и выполнение действия перед слиянием. + - Добавьте метки `/lgtm` и `/approve` для пулреквестов, которые могут быть приняты. +- Объедините пулреквесты, если они готовы, либо закройте те, которые не могут быть приняты. +- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использование метаданных SIG Docs. + +### Полезные ссылки на GitHub для дежурных + +Следующие ссылки помогут при дежурстве. После обработки заявок по трём первым ссылкам, как правило, список пулреквестов для проверки сократится. По указанным ссылкам вы найдете PR только в английскую версию, предназначенные для слияния в ветку `master` (кроме последней ссылки). + +- [Нет CLA, нет права на слияние](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): напомните участнику подписать CLA. Если об этом уже напомнил и бот, и человек, то закройте PR и напишите автору, что он может открыть свой PR после подписания CLA. +**Не проверяйте PR, если их авторы не подписали CLA!** +- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужен проверка с технической точки зрения, попросите её провести одного из рецензентов, который предложил бот. Если требуется просмотр пулреквест со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста. +- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слияния, оставьте комментарий с текстом `/approve`. +- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения. (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]). +- [Вне основной ветки](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): если PR отправлен в ветку `dev-`, значит он предназначается для будущего выпуска. Убедитесь, что [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) знает об этом, добавив комментарий с `/assign @`. Если он направлен в старую ветку, помогите автору PR изменить на более подходящую ветку. + +### Когда закрывать пулреквесты + +Обзоры и одобрения — это только один из способов, позволяющих держать список PR коротким и актуальным. Закрытие пулреквестов — альтернативный метод для этого. + +- Можете закрыть любой PR, если CLA-соглашение не было подписано в течение двух недель. +Авторы PR могут повторно открыть PR после подписания CLA, так что это безопасный способ убедиться, что ничто не будет объединено без подписанного CLA. + +- Закройте любой PR, если автор не отреагировал на комментарии или проверки в течение 2 или более недель. + +Не бойтесь закрывать пулреквесты. Участники с лёгкостью открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулировать автора возобновить и закончить свой вклад. + +Чтобы закрыть пулреквест, оставьте комментарий `/close` в PR. + +{{< note >}} + +Бот [`fejta-bot`](https://github.com/fejta-bot) автоматически помечает заявки как устаревшие после 90 дней отсутствия активности, а затем закрывает их после ещё 30 дней простоя, когда они становятся тухлыми. Дежурные по PR должны закрывать заявки после 14-30 дней бездействия. + +{{< /note >}} + +## Внесение улучшений + +[Члены](/ru/docs/contribute/participating/#члены) SIG Docs могут предлагать улучшения. + +После того, как вы давно начали работать над документацией Kubernetes, у наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по оформлению](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их на канале `#sig-docs` Slack на [kubernetes.slack.com](https://kubernetes.slack.com). + +Когда обсуждение состоялось, а SIG-группа согласилась с желаемым результатом, вы можете работать над предлагаемыми изменениями наиболее приемлемым способом. Например, обновление руководства по оформлению или функциональности сайта может включать открытие пулреквеста, а изменение, связанное с тестированием документации, может предполагать взаимодействие с sig-testing. + +## Координация документации по выпуску Kubernetes + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут координировать документацию для выпуска Kubernetes. + +Каждый выпуск Kubernetes координируется командой людей, участвующих в специальной группе (Special Interest Group, SIG) sig-release. Другие члены команды в данном выпуске включают в себя общего руководителя выпуском, а также представителей sig-pm, sig-testing и др. Чтобы узнать больше о процессах выпуска версий Kubernetes, обратитесь к [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release). + +Представитель SIG Docs для данного выпуска координирует следующие задачи: + +- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивают документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск. +- Регулярное посещение встречи sig-release и обновлять информацию о статусе документации в выпуске. +- Проверка и вычитка документации по функциональности, подготовленной SIG-группой, ответственной за реализацию этой функциональности. +- Объединение связанных с выпуском пулреквестов и поддержка Git-ветки выпуска. +- Консультируйте других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing). +- Публикация изменений в документации, связанные с выпуском при размещении артефактов. + +Координация выпуска обычно занимает 3-4 месяца, а обязанности распределяются между утверждающими SIG Docs. + +## Амбассадор нового участника + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут выступать в качестве амбассадоров новых участников. + +Амбассадоры новых участников работают бок о бок, чтобы поприветствовать новых участников SIG Docs, предлагать PR новым участникам и консультировать новых участников в их собственных PR. + +Обязанности амбассадоров новых участников включают в себя: + +- Отвечать на вопросы новых участников на [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com). +- Совместно работать с дежурным по PR, чтобы определять заявки, которые подойдут для решения новыми участниками. +- Консультировать новых участников в их PR. +- Помогать новых участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes. +- [Оказывать содействие участникам](/ru/docs/contribute/advanced/#поддержка-нового-участника) на их пути становления членом в Kubernetes. + +Текущие амбассадоры новых участников объявляются на каждом собрании SIG Docs и на канале [#sig-docs в Kubernetes](https://kubernetes.slack.com). + +## Поддержка нового участника + +[Рецензенты](/ru/docs/contribute/participating/#рецензенты) SIG Docs могут содействовать новым участникам в членстве организации. + +Если участник сделал 5 значительных пулреквестов в один или несколько репозиториев Kubernetes, он имеет право на [членство](/ru/docs/contribute/participating#члены) в организации Kubernetes. Членство участника должно быть поддержано двумя спонсорами, которые уже являются рецензентами. + +Новые участники документации могут найти спонсоров в канале #sig-docs в [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes. + +## Сопредседатель SIG + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут быть сопредседателями SIG Docs. + +### Требования + +Сопредседатели должны соответствовать следующим требованиям: + +- Быть утверждающим SIG Docs не меньше 6 месяцев +- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопровождать два выпуска +- Понимание рабочих процессов и инструментов SIG Docs: git, Hugo, локализация, блог +- Понимать, как другие SIG-группы и репозитории Kubernetes влияют на рабочий процесс SIG Docs, включая: [команды в k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [процессы в k/community](https://github.com/kubernetes/community/tree/master/sig-docs), плагины в [k/test-infra](https://github.com/kubernetes/test-infra/) и роль [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). +- Уделять не менее 5 часов в неделю (но зачастую больше) в течение как минимум 6 месяцев для выполнения обязанностей. + +### Обязанности + +Роль сопредседателя посвящена в основном одной из задач: сопредседатели управляют процессом и политикой, планируют и проводят собрания, назначают дежурных по PR и, как правило, делают то, что никто больше не хочет делать, для увеличения количества участников. + +Обязанности включают в себя: + +- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию +- Быть примером соблюдения [норм поведения сообщества]https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG +- Изучение и внедрение передовых практик для SIG-группы, обновляя рекомендации по участию +- Планирование и проведение встреч SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое +- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях +- Набирать персонал и выступать в поддержку {{< glossary_tooltip text="CNCF" term_id="cncf" >}} и его платиновых партнеров, включая Google, Oracle, Azure, IBM и Huawei. +- Поддерживать нормальную работу SIG + +### Проведение продуктивных встреч + +Для планирования и проведения результативных встреч мы составили рекомендации, которые показывают и объясняют, как лучше всего их подготовить. + +**Соблюдайте [нормы поведения сообщества](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**: + +- Привлекайте самый широкий круг участников к дискуссии и уважительно общайтесь между собой, стараясь никого не обидеть. + +**Сформулируйте четкую повестку дня**: + +- Определите конкретную цель встречи +- Опубликуйте программу дня заранее + +Для еженедельных встреч скопируйте примечания из предыдущей недели в раздел "Past meetings". + +**Работайте вместе для создания точных примечания**: + +- Запишите обсуждение встречи +- Подумайте над тем, чтобы делегировать роль стенографист кому-нибудь другому + +**Определяйте решения по пунктам повестки четко и точно**: + +- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения + +**Руководите обсуждением, когда это необходимо**: + +- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему +- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей + +**Уважайте время людей**: + +- Начинайте и заканчивайте встречи своевременно + +**Используйте Zoom эффективно**: + +- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md) +- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего + +Исполнение роли ведущего в Zoom + +### Запись встреч на Zoom + +Когда вам потребуется начать запись, нажмите пункт с надписью Record to Cloud. + +Если нужно остановить запись, нажмите на кнопку Stop. + +Запись автоматически загрузится на YouTube. + +{{% /capture %}} diff --git a/content/ru/docs/contribute/intermediate.md b/content/ru/docs/contribute/intermediate.md new file mode 100644 index 0000000000..69dfa285ef --- /dev/null +++ b/content/ru/docs/contribute/intermediate.md @@ -0,0 +1,606 @@ +--- +title: Участие для продвинутых +slug: intermediate +content_template: templates/concept +weight: 20 +card: + name: contribute + weight: 50 +---1 + +{{% capture overview %}} + +На этой странице предполагается, что вы изучили и понимаете задачи на странице [Участие для начинающих](/ru/docs/contribute/start/) и теперь готовы узнать о других способах внести свой вклад. + +{{< note >}} +Некоторые задачи требуют использование Git-клиента из командной строки и других инструментов. +{{< /note >}} + +{{% /capture %}} + +{{% capture body %}} + +Теперь, когда вы уже знаете кое-что и приняли участие в документации Kubernetes, как описано в теме [Участие для начинающих](/ru/docs/contribute/start/), вы можете пойти ещё дальше. Далее пойдут задачи, предусматривающие наличие и желание получить глубокие знания по следующим темам: + +- Концепции Kubernetes +- Рабочие процессы документации Kubernetes +- Поиск нужной информации о будущих возможностях Kubernetes +- Сильные аналитические навыки в целом + +Эти задачи не такие последовательные, как задачи для начинающих. Поэтому мы не ожидаем, что кто-то в одиночку будет постоянно заниматься всеми ими. + +## Знакомство с Prow + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) — это система CI/CD, использующая Kubernetes, которая выполняет задания с пулреквестами (PR). Prow с помощью команд, похожих на те, что есть в чатботах, даёт возможность обрабатывать действия в организации Kubernetes на GitHub. Вы можете выполнять целый ряд действий, такие как добавление и удаление меток, закрытие заявок и назначение утверждающего. Введите Prow-команду в поле для комментария в формате `/`. Некоторые популярные команды: + +- `/lgtm` (looks good to me): добавляет метку `lgtm`, которая сообщает, что рецензент проверил PR +- `/approve`: одобряет PR так, чтобы он мог быть принят (эта команда работает только для утверждающих) +- `/assign`: назначает проверяющего на PR +- `/close`: закрывает ишью или PR +- `/hold`: добавляет метку `do-not-merge/hold`, которая означает, что PR не может быть автоматически принят +- `/hold cancel`: удаляет метку `do-not-merge/hold` + +{{% note %}} +Не все команды работают для каждого пользователя. Бот Prow сообщит вам, если вы пытаетесь выполнить команду, не разрешенную для вашего уровня. +{{% /note %}} + +Детально изучите [список команд Prow](https://prow.k8s.io/command-help), прежде чем начать проверять PR или сортировать ишью. + +## Проверка пулреквестов + +Каждую неделю утверждающий доброволец документации сортирует и просматривает [пулреквесты и заявки](#сортировка-и-классификация-ишью). Такой человек называется "PR Wrangler" на неделю. Расписание ведется с помощью [планировщика PR Wrangler](https://github.com/kubernetes/website/wiki/PR-Wranglers). Чтобы поучаствовать в этом списке, посетите еженедельную встречу SIG Docs. Даже если вас не выбрали дежурным по PR на текущую неделю, вы все равно можете проверять пулреквесты (PR), которые еще не были детально просмотрены. + +В дополнение к ротации автоматизированная система добавляет в каждый новый PR и предлагает рецензентов и утверждающих для него, основываясь на списке утверждающих и рецензентов в измененных файлах. Ожидается, что автор PR будет следовать указаниям бота, поэтому PR должен быть быстро проверить. + +Мы хотим, чтобы пулреквесты принимались и публиковались как можно быстрее. Чтобы документация оставалась точной и актуальной, каждый PR должен проверяться людьми, понимающие суть темы, а также теми, кто имеет опыт написания отличной документации. + +Рецензенты и утверждающие должны предоставить конкретную и конструктивную обратную связь, чтобы заинтересованные участники были вовлечены и помогали им улучшаться. Иногда, чтобы помочь новому участнику подготовить свой PR к слиянию, требуется больше времени, чем просто переписать его самостоятельно, но проект лучше в долгосрочной перспективе, когда у нас есть множество активных участников. + +Прежде чем приступить к проверке PR, убедитесь, что вы знакомы с [руководством по содержанию документации](/docs/contribute/style/content-guide/), [руководством по оформлению документации](/docs/contribute/style/style-guide/) и [нормы поведения](/community/code-of-conduct/). + +### Поиск пулреквестов для проверки + +Чтобы посмотреть все открытые пулреквесты, перейдите на вкладку **Pull Requests** в GitHub-репозитории. +PR можно проверять только, если он соответствует всем перечисленным ниже критериям: + +- Имеет метку `cncf-cla:yes` +- Не содержит надписи WIP в описании +- Не имеет тег с фразой `do-not-merge` +- Нет конфликтов для слияния +- Сделан в правильную ветку (обычно это `master`, за исключением, если PR не относится к невыпущенной ещё функциональности) +- Не проверялся ещё детально другим проверяющим документации (то же самое касается и остальных технических рецензентов), если только этот человек явно не обратился за вашей помощью. В частности, не рекомендуется добавлять много новых комментариев после других циклов рассмотрения PR. + +Если PR не имеет условия для проверки, можно оставить комментарий, чтобы сообщить автору о текущих проблемах и предложить помочь решить их. Если автор пулреквеста был оповещён о проблемах и не устранил их в течение нескольких недель или месяцев, то рано или поздно такой PR будет закрыт. + +Если вы новичок в проверке пулреквестов или у вас недостаточно времени и возможностей, попробуйте поискать PR с тегом `size/XS` или `size/S`. Размер пулреквеста автоматически определяется по количеству изменённых строк в PR. + +#### Рецензенты и утверждающие + +В репозитории сайта Kubernetes работа построена иначе, чем в других репозиториях Kubernetes, когда речь идет о роли рецензентов и утверждающих. Для получения дополнительной информации об обязанностях рецензентов и утверждающих см. [Участие в SIG Docs](/ru/docs/contribute/participating/). Ниже вы найдете краткий обзор. + +- Рецензент проверяет содержание пулреквеста для соблюдения технической точности. Рецензент даёт понять, что PR технически точен, оставляя комментарий с `/lgtm` к PR. + + {{< note >}}Не добавляйте `/lgtm`, если вы не уверены в технической точности документации, измененной или добавленной в PR.{{< /note >}} + +- Утверждающий проверяет содержание запроса на предмет качества и соответствия рекомендациям SIG Docs, приведенным в руководствах по содержанию и оформлению. Только люди, указанные в качестве утверждающих в файле [`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS), могут одобрить PR. Чтобы одобрить PR, оставьте комментарий `/approve` к PR. + +PR объединяется, когда у него есть комментарий `/lgtm` от кого-либо из организации Kubernetes и комментарий `/approve` от утверждающего в группе `sig-docs-maintainers`, если он не удерживается, а автор PR подписал CLA. + +{{< note >}} + +Раздел ["Участие"](/ru/docs/contribute/participating/#утверждающие) содержит больше информации для рецензентов и утверждающих, включая конкретные обязанности для утверждающих. + +{{< /note >}} + +### Проверка PR + +1. Изучите описание PR вместе с указанными ишью и ссылками, если они есть. Кратковременные мимолетные обзоры иногда могут наносит больше вреда, чем пользы, поэтому убедитесь, что вы обладаете нужными знаниями, чтобы сделать содержательный обзор. + +2. Если кто-то другой может лучше всего проверит определенный PR, упомяните этого человека, добавив комментарий `/assign @`. Если вы обратились за технической проверкой к человеку, который не занимается документацией, но при этом вы хотите сами посмотреть PR как участник группы документации, то не стесняйтесь это делать. + +3. Перейдите на вкладку **Files changed**. Посмотрите на все изменённые строки. Удалённый текст выделен красным, а строки с ним начинаются с символа `-`. Добавленный текст отмечен зелёным фоном, а строки с ним начинаются с символа `+`. Внутри строки фактически измененный контент имеет чуть более темный зеленый фон, чем остальная часть строки. + + - В частности, если в PR есть сложное форматирование или он изменяет CSS, JavaScript или другие элементы сайта, вы можете просмотреть сайт, сгенерированный с этими изменениями в PR. Перейдите на вкладку **Conversation** и нажмите ссылку **Details** в проверке `deploy/netlify` в нижней части страницы. По умолчанию ссылка открывается в текущей вкладке браузера, поэтому чтобы потерять частичный отзыв, откройте ссылку в новой вкладке. Вернитесь на вкладку **Files changed**, чтобы продолжить проверку пулреквеста. + - Убедитесь, что PR соответствует правилам содержания и оформления; если что-то не так, укажите на этом со ссылкой на раздел в руководстве. + - Если у вас есть вопрос или вы хотите прокомментировать определённое изменение, наведите курсор мыши на строку и кликните на появившуюся сине-белую кнопку с иконкой `+`. Напишите свой комментарий и нажмите на кнопку **Start a review**. + - Если вам нужно оставить больше одного комментария, сделайте это по аналогии с предыдущим шагом. + - По соглашению, если вы видите небольшую проблему, не имеющей отношение к основному назначению PR, например, опечатку или лишний пробел, вы можете сообщить о ней, начав комментарий с `nit:`, чтобы автор знал, что это незначительная ошибка. Хотя это не означает, что автор пулреквеста может проигнорировать такие проблемы. + - Когда вы всё проверили или у вас не осталось комментариев, прокрутите в верхнюю часть страницы и нажмите на кнопку **Review changes**. Далее кликните либо на **Comment** или **Request Changes**. Напишите краткий итог вашей проверки и добавьте соответствующие [Prow-команды](https://prow.k8s.io/command-help) по одной на каждой строке в поле Review Summary. SIG Docs следует [процессу проверки кода Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process). Все ваши комментарии будут отправлены автору PR в виде одного уведомления. + + - Если вы считаете, что PR в хорошем состоянии, чтобы его принять, добавьте команду `/approve` в резюме вашей проверки. + - Если PR не нуждается в дополнительном техническом рассмотрении, добавьте ещё команду `/lgtm`. + - Если PR *требуется* дополнительный технический обзор, добавьте команду `/assign` и после неё укажите логин человека на GitHub, который должен сделать технический анализ. Посмотрите на поле рецензентов во вступительной (фронтальной) части вверху данного Markdown-файла, чтобы выяснить, кто может провести технический разбор пулреквеста. + - Чтобы заблокировать слияние PR, используйте команду `/hold`. Она добавит метку `do-not-merge/hold`. + - Если в PR нет конфликтов и есть метки `lgtm` и `approve` (и нет метки `hold`), то он автоматически объединиться. + - Если PR имеет метки `lgtm` и/или `approve`, и появляются новые изменения, эти метки будут автоматически удалены. + + Посмотрите [список доступных команд](https://prow.k8s.io/command-help), которые можно использовать в PR. + + - Если вы ранее выбрали нажали на **Request changes** и затем автор PR решил все указанные проблемы, вы можете обновить статус проверки либо на вкладке **Files changed**, либо в нижней части вкладки **Conversation**. Обязательно укажите команду `/approve` и при необходимости выберите технических рецензентов, чтобы можно было объединить PR. + +### Редактирование PR другого человека + +Добавление комментариев в PR — полезное дело, но могут быть случаи, когда нужно сделать коммит в пулреквест другого человека, а не просто оставить свой отзыв. + +Не поддавайтесь желанию выполнить работу за другого человека, если только он явно не попросит вас об этом или вы не захотите оживить давно заброшенный PR. Хотя это может быть быстрее в краткосрочной плане, но это лишает человека возможности внести собственный вклад. + +Используемый процесс зависит от того, нужно ли вам отредактировать файл, который уже изменен в PR, либо вам нужно отредактировать файл, который в PR не участвовал. + +Вы не можете отредактировать чужой PR, если выполняется одно из условий: + +- Если автор PR отправил свою ветку непосредственно в репозиторий [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/), то только рецензент с правом отправки изменений напрямую в репозиторий может вносить изменения в PR. + Авторам следует открыть PR из ветки в своей копии репозитория. +- Если автор PR явно запретил редактирование утверждающими, вы не сможете внести изменения в его PR, пока он не изменит эту настройку. + +#### Если файл уже изменён в PR + +Этот метод использует интерфейс GitHub. Вы можете использовать командную строку, если вам комфортнее работать в ней, даже если вам нужно изменить файл, который ранее редактировался в PR. + +1. Перейдите на вкладку **Files changed**. +2. Прокрутите к блоку с файлом, который вы хотите отредактировать и нажмите на иконку с карандашом. +3. Внесите изменения, напишите сообщение коммита в соответствующем поле под текстовым редактором и нажмите **Commit changes**. + +После этого ваш коммит отправляется в ветку из PR (скорее всего, в копию репозитория автора), и теперь отображается в PR, а ваши изменения отражаются на вкладке **Files changed**. Оставьте комментарий, чтобы автор PR знал, что вы что-то сделали в PR. + +Если автор использует командную строку, а не сайт GitHub для работы с этим PR, он должен получить изменения со своей копии репозитория и перебазировать свою локальную ветку на ветку своей копии, прежде чем заниматься своим PR. + +#### Если файл ещё не был изменён в PR + +Если необходимо внести изменения в файл, который не был отредактирован в рамках конкретного PR, нужно использовать командную строку. Вам придётся по душе такой метод, если вы предпочитаете использовать терминал вместо использования сайта GitHub. + +1. Узнайте URL-адрес копии репозитория автора пулреквеста. Вы можете найти его в нижней части вкладки **Conversation**. Найдите текст **Add more commits by pushing to**. Первая ссылка после этой надписи ведет на ветку, а вторая ссылка — на саму копию репозитория. Скопируйте вторую ссылку. Запомните название ветки, пригодится впоследствии. + +2. Добавьте копию репозитория как новый удаленный репозиторий. В терминале перейдите в директорию своей копии репозитория. Придумайте имя для удаленного репозитория (например, по имени логина автора на GitHub) и добавьте его, используя следующую команду: + + ```bash + git remote add + ``` + +3. Получите информацию о добавленном удаленном репозитории. Это действие не затронет локальные файлы, а только загрузит в вашу копии репозитория информацию о другой копии (например, ветки и теги). + + ```bash + git remote fetch + ``` + +4. Перейдите в ветку, полученную с удаленного репозитория. Эта команда не получится, если у вас локально уже есть ветка с таким же именем. + + ```bash + git checkout + ``` + +5. Внесите изменения и добавьте их через `git add`, а затем зафиксируйте их. + +6. Отправьте изменения в удаленный репозиторий автора. + + ```bash + git push + ``` + +7. Откройте снова сайт GitHub и обновите страницу PR. Вы увидите ваши изменения. Добавьте комментарий для автора, чтобы он был в курсе, что вы изменили его PR. + +Если автор использует командную строку, а не интерфейс на GitHub для работы над PR, ему нужно получить новые изменения из своей копии репозитоии и перебазировать свою локальную ветку на ветку своей копии репозитории, прежде чем снова заниматься собственным PR. + +## Работа из локальной копии + +В случае изменений нескольких файлов, либо добавлением новых или перемещением старых, лучше работать из локальной копии Git-репозитория на компьютере, нежели чем использовать для этого GitHub. Следующие инструкции используют командую утилиту `git`, которая предполагается, что она уже установлена на вашем компьютере. Вы можете воспользоваться ими даже, если пользуетесь графическим Git-клиента. + +### Клонирование репозитория + +Вам нужно только один раз клонировать репозиторий на каждом компьютере, на котором вы работаете с документацией Kubernetes. + +1. Создайте копию репозитория `kubernetes/website` на GitHub. В браузере перейдите по [https://github.com/kubernetes/website](https://github.com/kubernetes/website) и нажмите на кнопку **Fork**. После нескольких секунд вы будете автоматически перенаправлены на URL-адрес вашей копии, которая будет иметь следующий вид: `https://github.com//website`. + +2. В окне термина используйте команду `git clone` для получения копии репозитория. + + ```bash + git clone git@github.com//website + ``` + + После выполнения этой команды в текущей рабочей директории появится новая директория `website` с содержимым вашего репозитория на GitHub. В данном случае удаленный репозиторий `origin` будет ссылаться на вашу копию репозитория. + +3. Перейдите в новую директорию `website`. Добавьте новый удалённый репозиторий `kubernetes/website` под именем `upstream`. + + ```bash + cd website + + git remote add upstream https://github.com/kubernetes/website.git + ``` + +4. Проверьте ваши репозитории `origin` и `upstream`. + + ```bash + git remote -v + ``` + + Output is similar to: + + ```bash + origin git@github.com:/website.git (fetch) + origin git@github.com:/website.git (push) + upstream https://github.com/kubernetes/website (fetch) + upstream https://github.com/kubernetes/website (push) + ``` + +### Работа в локальном репозитории + +Прежде чем начать работать в локальном репозитории, вам нужно выяснить, из какой ветки будет основываться ваша работа. Ответ на этот вопрос зависит от того, что хотите сделать, но можно руководствоваться следующими правилами: + +- Для общих улучшений существующего контента создайте собственную ветку от ветки `master`. +- Для добавления нового контента про функциональность, которая уже есть в текущих версиях Kubernetes, начните с ветки `master`. +- В случае большой и длительной работы, над которой будут трудиться несколько участников SIG Docs, например, реорганизация контента, создайте отдельную ветку, специально предназначенной для этого. +- Для нового контента про будущие, но ещё не выпущенные версии Kubernetes, работайте в ветке предварительного выпуска, созданной специально для этой версии Kubernetes. + +Для получения дополнительной информации обратитесь к разделу [Выбор правильной ветки](/ru/docs/contribute/start/#выбор-правильной-ветки-в-git). + +После того, как вы определили, с какой ветви начать свою работу (или на какой ветке будет _базироваться_ ваша работа, если говорить в терминологии Git), следуйте определённому ниже рабочему процессу, чтобы ваша работа оставалась актуальной. + +1. Когда вы работаете локально, есть три разные копии репозитория: `local`, `upstream` и `origin`. Получите данные по удалённым репозиториям `origin` и `upstream`. Эта команда очистит кеш удаленных репозиториях без фактического изменения каких-либо из копии. + + ```bash + git fetch origin + git fetch upstream + ``` + + Этот рабочий процесс отличается от того, который определен в [сообществе GitHub](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). Здесь вам не нужно объединять вашу локальную копию `master` из репозитория `upstream/master`, прежде чем отправлять изменения в вашу копию. Этот шаг не требуется в `kubernetes/website`, потому что ваша ветка базируется на репозитории upstream. + +2. Создайте локальную рабочую ветку из наиболее подходящей ветки upstream-репозитория: `upstream/dev-1.xx` для разработчиков в конкретных версиях или `upstream/master` для всех остальных участников. В этом примере предполагается, что вы будете работать с ветки `upstream/master`. Так как ваша локальная ветка `master` не настроена для отслеживания изменений с `upstream/master` на предыдущем шаге, поэтому вам нужно явно создать свою ветку от `upstream/master`. + + ```bash + git checkout -b upstream/master + ``` + +3. После переключения на новую ветку можно начать в ней работать в текстовом редакторе. Используйте команду `git status` , чтобы посмотреть измененные файлы. + +4. Когда вы закончите работу, зафиксируйте изменения. Сначала выполните команду `git status`, чтобы увидеть, какие изменения будут добавлены в коммит. В выводе этой команды есть две важные секции: `Changes staged for commit` и `Changes not staged for commit`. Файлы в последней секции, рядом с которыми есть надпись `modified` или `untracked`, необходимо добавить, если вы хотите, чтобы они попали в коммит. Для каждого файла, который нужно добавить, используйте команду `git add`. + + ```bash + git add example-file.md + ``` + + Когда все изменённые файлы добавлены, зафиксируйте их с помощью команды `git commit`: + + ```bash + git commit -m "Your commit message" + ``` + + {{< note >}} + В сообщении коммита не указывайте идентификатор или URL-адрес ишью или пулреквеста на GitHub. Если вы это сделаете, на странице ишью или пулреквеста будет показана информация о коммите всякий раз, когда коммит будет появляться в новой Git-ветке. Вы можете сослаться на ишью и пулреквесты позже на сайте GitHub. + {{< /note >}} + +5. При желании вы можете посмотреть, как ваши изменения будут выглядеть на сайте, если запустите сайт на вашей машине с помощью команды `hugo`. Посмотрите раздел [Просмотр ваших изменений локально](#просмотр-изменений-локально). Кроме этого, вы увидите свои изменения после создания пулреквеста. + +6. Перед тем, как открывать пулреквест с вашими изменениями вам для начала отправить в ветку удаленного репозитория, чем в данном случае является `origin`. + + ```bash + git push origin + ``` + + Технически вы можете не указать имя ветки в команде `push`, но корректное выполнение команды в таком случае зависит от используемой версии Git. Результаты будут более ожидаемыми, если вы напишите название ветки. + +7. Перейдите по адресу https://github.com/kubernetes/website в вашем браузере. GitHub определит и укажет вам, что вы загрузили новую ветку в свою копию, и поэтому предложит создать пулреквест. Заполните шаблон запроса. + + - Название должно быть не длиннее 50 символов и отражать краткий итог изменений. + - Подробное описание должно содержать больше информации про исправление, включая строку типа `Fixes #12345`, если пулреквест решает проблему на GitHub. Это приведет к автоматическому закрытию указанной ишью после принятия пулреквеста. + - Вы можете добавить метки или другие метаданные и назначить рецензентов. Смотрите страницу [Сортировка и классификация ишью](#сортировка-и-классификация-ишью). + + Нажмите на кнопку **Create pull request**. + +8. Начнут выполняться автоматические тесты в зависимости от состояния сайта с вашими изменениями. Если какой-либо из тестов завершился неудачно, нажмите на ссылку **Details** для получения дополнительной информации. Если тест Netlify прошёл успешно, по ссылке **Details** вы можете найти предварительную версию сайта Kubernetes с внесенными вашими изменениями. Именно на ней рецензенты будут проверять ваши изменения. + +9. Если вам необходимо что-то дополнить, изменить пулреквест в соответствии с выполненной проверкой, либо изменить текст коммита, вы можете использовать команду ниже. + + ```bash + git commit -a --amend + ``` + + - `-a`: зафиксировать все изменения + - `--amend`: изменить предыдущий коммит вместо создания нового + + Откроется текстовый редактор, чтобы вы могли отредактировать сообщение коммита, если это нужно. + + Если вы используете `git commit -m`, как в шаге 4, вы сделаете новый коммит, а не измените исходный (предыдущий) коммит. Создание нового коммита означает, что вам нужно объединить свои коммиты до того, прежде чем пулреквест может быть объединен. + + Следуйте инструкциям в шаге 6, чтобы отправить новый коммит в удаленный репозиторий. После этого новое изменение отобразится в пулреквесте, а дальше снова запустятся тесты, а также произойдет новая сборка предварительной версии сайта на Netlify с последними изменениями. + +10. Если рецензент изменяет файлы в вашем пулреквесте, вам нужно получить новые изменения в вашей локальной копии, до того как снова начать что-то делать. Используйте команды ниже, чтобы обновить свою ветку (предполагается, что ветка уже получена с вашей копии репозитория). + + ```bash + git fetch origin + git rebase origin/ + ``` + + После перебазирования вам нужно добавить флаг `--force-with-lease`, чтобы принудительно отправить новые изменения в ветке на вашу копию. + + ```bash + git push --force-with-lease origin + ``` + +11. Может возникнуть конфликт, если кто-то, как и вы, изменил те же части файла в ветке, из которой была создана ваша ветка. Если пулреквест показывает, что есть конфликты, которые нужно разрешить, вы можете сделать это либо на сайте GitHub, либо исправить их локально. + + Сначала выполните шаг 10, чтобы актуализировать локальную ветку в соответствии с веткой в удаленном репозитории. + + Затем обновите репозиторий `upstream` и перебазируйте вашу ветку на ту, с которой она была создана, в данном случае это `upstream/master`. + + ```bash + git fetch upstream + git rebase upstream/master + ``` + + Если есть конфликты, которые Git не может разрешить автоматически, вы можете увидеть конфликтующие файлы с помощью команды `git status`. Отредактируйте каждый конфликтующий файл: найдите в них маркеры конфликта `>>>`, `<<<` и `===`. Разрешение конфликта происходит путём удаления указанных маркеров конфликта. После это нужно добавить измененные файлы с помощью команды `git add ` и продолжить перебазирование ветки, используя команду `git rebase --continue`. Когда всё зафиксировано в репозитории и не осталось неразрешенных конфликтов, команда `git status` покажет, что вы вышли из состояния перебазирования ветки и нет изменений для фиксации. На этом этапе вам осталось принудительно отправить ветку в свою копию репозитория, после чего на странице пулреквеста не должны быть конфликты. + +12. Если у вашего PR отображаются несколько сделанных коммитов после редактирования предыдущих коммитов, вам следует объединить эти несколько коммитов в один коммит, чтобы PR мог быть объединен. Проверить количество коммитов можно на вкладке `Commits` на странице PR или выполнив `git log` в терминале. Объединение коммитов (Squashing commits) — это одна из форм перебазирования. + + ```bash + git rebase -i HEAD~ + ``` + + Ключ `-i` сообщает git, что вы хотите сделать перебазирование в интерактивном режиме. В этом режиме вы сможете выбрать для git, какие коммиты нужно объединить в один. Например, в вашей ветке есть 3 коммита: + + ``` + 12345 commit 4 (2 minutes ago) + 6789d commit 3 (30 minutes ago) + 456df commit 2 (1 day ago) + ``` + + Вам нужно объединить свои последние три коммита в один-единственный. + + ``` + git rebase -i HEAD~3 + ``` + + Эта команда откроет редактор с таким содержимым: + + ``` + pick 456df commit 2 + pick 6789d commit 3 + pick 12345 commit 4 + ``` + + Измените `pick` на `squash` у тех коммитов, которые вы хотите объединить, и проверьте, что коммит с выбранным `pick` находится сверху. + + ``` + pick 456df commit 2 + squash 6789d commit 3 + squash 12345 commit 4 + ``` + + Сохраните и закройте редактор. Затем отправьте объединённый коммит в репозитории с помощью команды `git push --force-with-lease origin `. + +Если у вас возникли проблемы с разрешением конфликтов или вы долго не можете что-то разрешить, что связано с вашим пулреквестом, обратитесь за помощью в Slack-канал `#sig-docs` или в [список рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +### Просмотр изменений локально + +{{< tabs name="tab_with_hugo" >}} +{{% tab name="Hugo в контейнере" %}} + +Если вы ещё не готовы создать пулреквесты, но при этом хотите посмотреть, как будет выглядеть сайт с вашими изменениями, то можете собрать и запустить образ Docker, чтобы сгенерировать всю документацию и открыть ее на своем компьютере. + +1. Соберите образ локально: + + ```bash + make docker-image + ``` + +2. После того. как образ `kubernetes-hugo` собран, вы можете использовать его для запуска сайта: + + ```bash + make docker-serve + ``` + +3. В адресной строке браузера введите вставьте адрес `localhost:1313`. Hugo будет следить за изменениями файловой системы и пересобирать сайт по мере необходимости. + +4. Чтобы остановить локальный сайт Hugo, откройте снова терминал и введите `Ctrl+C` или просто закройте окно с терминалом. + +{{% /tab %}} +{{% tab name="Hugo на локальном компьютере" %}} + +1. Установите версию [Hugo](https://gohugo.io/getting-started/installing/), которая указана в файле [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml). + +2. В терминале перейдите в корневую директорию вашей копии документации Kubernetes и введите следующую команду: + + ```bash + hugo server + ``` + +3. В адресной строке браузера скопируйте `localhost:1313`. + +4. Чтобы остановить локальный сайт Hugo, откройте снова терминал и введите `Ctrl+C` или просто закройте окно с терминалом. +{{% /tab %}} +{{< /tabs >}} + +## Сортировка и классификация ишью + +Люди в SIG Docs отвечают только за сортировку и классификацию ишью, связанных с документацией. Вопросы и проблемы общего характера также хранятся в репозитории `kubernetes/website`. + +Что вы делаете, когда сортируете ишью: + +- Проверить ишью + - Убедитесь, что ишью связана с документацией сайта. Некоторые заявки можно быстро закрыть, ответив на вопрос или указав автору на ресурс. Подробности смотрите в разделе [Заявки с помощью или отчёты об ошибке в коде](#заявки-с-помощью-или-отчёты-об-ошибке-в-коде). + - Рассмотрите, насколько обоснованной является заявка. Добавьте метку `triage/needs-information`, если в ишью описано мало подробностей, чтобы ее можно было начать решать, либо если шаблон был неправильно заполнен. + Закройте заявку, если она имеет метки `lifecycle/stale` и `triage/needs-information`. +- Добавьте метку с приоритетом (см. [руководство по сортировке заявок](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority), где подробно определены метки) + - `priority/critical-urgent` - заниматься нужно прямо сейчас + - `priority/important-soon` - нужно выполнить в течение 3 months + - `priority/important-longterm` - нужно сделать в течение 6 months + - `priority/backlog` - решение можно быть отложено на неопределенный срок indefinitely; самый низкий приоритет; делать, когда будут свободны ресурсы + - `priority/awaiting-more-evidence` - указание, что это возможно хорошая задача, которую нужно иметь на виду +- Дополнительно вы можете добавить метку `help` или `good first issue`, если определенная заявка может быть решена человеком, мало знакомым с Kubernetes или SIG Docs. В качестве руководства обратитесь к файлу [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md). +- При желании примите сами участие в ишью и отправьте PR для ее решения (в частности если она может быстро разрешена или вы ранее выполняли нечто подобное). + +С помощью [этого фильтра](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc) можно найти заявки, которые необходимо отсортировать. + +Если у вас есть вопросы о про сортировку, спросите в Slack-канале `#sig-docs` или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +### Добавление и удаление меток + +Для добавления метки нужен комментарий, содержащий что-то вроде `/` или `/ `. Метка уже должна быть создана в репозитории. Если вы попытаетесь добавить несуществующую метку, команда проигнорируется. + +Примеры: + +- `/triage needs-information` +- `/priority important-soon` +- `/language ja` +- `/help` +- `/good-first-issue` +- `/lifecycle frozen` + +Для удаления метки нужен комментарий с `/remove-` или `/remove- `. + +Примеры: + +- `/remove-triage needs-information` +- `/remove-priority important-soon` +- `/remove-language ja` +- `/remove-help` +- `/remove-good-first-issue` +- `/remove-lifecycle frozen` + +Список всех меток, используемых в Kubernetes, находится [здесь](https://github.com/kubernetes/kubernetes/labels). Не все метки используются группой SIG Docs. + +### Дополнительные сведения о метках + +- Ишью может иметь несколько ярлыков. +- Некоторые метки в своём имени содержат слеш для группировки, это своего рода "подметки". Например, существует множество меток `sig/`, например, `sig/cli` и `sig/api-machinery` ([полный список](https://github.com/kubernetes/website/labels?utf8=%E2%9C%93&q=sig%2F)). +- Некоторые метки добавляются автоматически, в зависимости от метаданных файлов из ишью, либо от используемых в комментариях команд со слешем, а также от указанной информации в описании. +- Новые метки могут добавляться вручную человеком, который сортировкой ишью (либо тем, кто создает ишью). + - `kind/bug`, `kind/feature` и `kind/documentation`: баг (bug) — это проблема в текущем контенте или в функциональности, а возможность (feature) — запрос на добавление нового контента или функциональности. + Метка `kind/documentation` используется редко. + - Метки `language/ja`, `language/ko` и похожие [языковые метки](https://github.com/kubernetes/website/labels?utf8=%E2%9C%93&q=language) добавляются, если ишью относится к локализованному контенту. + +### Жизненный цикл ишью + +Ишью обычно открываются и закрываются в течение относительно короткого промежутка времени. Однако иногда решение заявки после ее создания может и не быть. Иногда ишью может оставаться открытой гораздо дольше, чем 90 дней. + +`lifecycle/stale`: после 90 дней бездействия ишью автоматически помечается как устаревшая (stale). Такая заявка будет автоматически закрыта, если эта метка не будет удалена с помощью команды `/remove-lifecycle stale`. + +`lifecycle/frozen`: заявка с данной меткой не будет считаться устаревшей после 90 дней отсутствия активности. Пользователь вручную добавляет эту метку к заявкам, которые должны оставаться открытыми значительно дольше 90 дней, например, у ишью с меткой `priority/important-longterm`. + +### Обработка специальных типов ишью + +Мы встречаем перечисленные ниже типы заявкой достаточно часто, поэтому расписали, как их обрабатывать. + +#### Дублирование заявок + +Если для какой-нибудь проблемы есть одна или несколько открытых заявок, решение этой проблемы должно быть вынесено в одну заявку. Вам нужно решить, какую заявку оставить открытой (либо вовсе открыть новую ишью), перенести всю соответствующую информацию и указать связанные заявки. Затем для всех остальных похожих заявок добавьте метку с `triage/duplicate` и закройте их. Наличие только одной-единственной заявки поможет уменьшить путаницу и избежать дублирования работы над одной и той же проблемой. + +#### Заявки про неработающие ссылки + +В зависимости от того, где сообщается о неработающей ссылке, для решения этой проблемы требуются различные действия. Неработающие ссылки в API и документации Kubectl — это заявки, связанные с автоматизацией и поэтому их нужно отмечать меткой `/priority critical-urgent`, пока проблема не будет полностью проанализирована. Все остальные неработающие ссылки — это ишью, которым нужно заниматься вручную, поэтому им нужно добавить метку `/priority important-longterm`. + +#### Заявки, связанные с блогом + +Записи в [блоге Kubernetes](https://kubernetes.io/blog/) будут терять актуальность со временем, поэтому мы поддерживаем записи, опубликованные в течение года. Если заявка сообщает о проблеме в записи блога, которой более одного года, ее следует закрыть без какого-либо исправления. + +#### Заявки с помощью или отчёты об ошибке в коде + +Некоторые открытые заявки — это проблемы с основным кодом или просьбы с помощью, когда что-то (например, учебное руководство) не работает. Для заявок, не имеющих отношение к документации, закройте её, проставив метку `triage/support` и добавив комментарий с ресурсами, где можно найти помощь (Slack, Stack Overflow) и при необходимости укажите, где нужно открыть заявку, чтобы сообщить об ошибке в функциональности (вероятно, репозиторий kubernetes/kubernetes отлично подойдет для этого). + +Пример ответа на запрос о помощи: + +```none +This issue sounds more like a request for support and less +like an issue specifically for docs. I encourage you to bring +your question to the `#kubernetes-users` channel in +[Kubernetes slack](http://slack.k8s.io/). You can also search +resources like +[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +for answers to similar questions. + +You can also open issues for Kubernetes functionality in + https://github.com/kubernetes/kubernetes. + +If this is a documentation issue, please re-open this issue. +``` + +Пример ответа на сообщение об ошибке в коде: + +```none +This sounds more like an issue with the code than an issue with +the documentation. Please open an issue at +https://github.com/kubernetes/kubernetes/issues. + +If this is a documentation issue, please re-open this issue. +``` + +## Добавление документации для новой функциональности + +Каждый мажорный выпуск Kubernetes несет в себе новую функциональность, для большей части из которой нужно написать хоть краткую документацию, чтобы показать людям, как её использовать. + +Зачастую SIG-группа, ответственная за новую функциональность, представляют черновик документацию в виде пулреквеста в соответствующую ветку выпуска в репозитории `kubernetes/website`, а кто-то из команды SIG Docs могут сделать вычитку или отредактировать черновик напрямую. + +### Поиск информации о новой функциональности + +Чтобы узнать о будущей функциональности, посетите еженедельную встречу sig-release (см. страницу [Сообщество](https://kubernetes.io/community/), чтобы быть в курсе предстоящих собраний) и отслеживайте документацию к новому релизу в репозитории [kubernetes/sig-release](https://github.com/kubernetes/sig-release/). Каждый выпуск имеет поддиректорию в директории [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases). Каждая директорию содержит график выхода новой версии, черновик с примечаниями к выпуску, а также документ, в котором перечислена команда, занимающаяся новым выпуском. + +- График выпуска содержит ссылки на все другие документы, встречи, протоколы собраний и этапы, связанные с выпуском. Он также содержит информацию о целях и сроках выпуска, а также о любых специальных процессах, используемых этом выпуске. В нижней части документа определены несколько терминов, связанных с выпуском. + + Этот документ также содержит ссылку на **лист отслеживания функциональности** — это "официальный" способ узнать про новую функциональность, запланированной в выпуске. + +- В документе команды выпуска указано, кто какую роль занимает. Если непонятно, с кем можно поговорить об определенной функциональности или вы хотите что-то спросить, то либо посетите встречу по этому выпуску, чтобы задать свой вопрос, либо обратитесь к руководителю. + +- Черновик примечаний к выпуску — хорошая отправная точка, где можно узнать чуть больше о конкретной функциональности, изменениях, устаревших возможностях и в целом что-то ещё о выпуске. Содержимое может обновляться до конца цикла выпуска, поэтому будьте начеку. + +#### Лист отслеживания функциональности + +В списке отслеживания функциональности [для данного выпуска Kubernetes](https://github.com/kubernetes/sig-release/tree/master/releases) перечислена вся функциональность, запланированная для выпуска. Каждая строка содержит название возможности, ссылку на основную заявку GitHub, уровень стабильности (Alpha, Beta или Stable), группу SIG и ответственного лица за её реализацию, информацию про документацию, черновик примечания для выпуска, а также указание, была ли функциональность уже принята. Имейте в виду следующее: + +- Функциональность в состоянии Beta и Stable обычно имеет более высокий приоритет по сравнению с версией Alpha. +- Трудно протестировать (и, следовательно, написать документацию) функциональности, которая не ещё принята или,по крайней мере, считается полнофункциональной в своем PR. +- Определение, нужна ли документировать функциональности, производится вручную, и даже если у функциональности нет метки, что ей нужна документация, это не означает, это действительно так. + +### Документирование функциональности + +Как отмечалось выше, черновик документации для новой функциональности обычно предлагается SIG-группой, ответственной за реализацию новой функциональности. Это означает, вы в данном случае будете больше наблюдающим (куратором) в данной функциональности, нежели чем полноценным автором документации для неё. + +После того, как вы выбрали функциональность для документирования/наблюдения, заявите об этом в Slack-канале `#sig-docs`, на еженедельной встрече sig-docs или напрямую в PR, отправленном SIG. Если вам дали добро, вы можете редактировать PR, используя один из способов, указанных в разделе [Редактирование PR другого человека](#редактирование-PR-другого-человека). + +Если вам нужно написать новую тему, полезны следующие ссылки: + +- [Написание новых тем](/docs/contribute/style/write-new-topic/) +- [Использование шаблонов страниц](/docs/contribute/style/page-templates/) +- [Руководство по оформлению документации](/docs/contribute/style/style-guide/) +- [Руководство по содержанию документации](/docs/contribute/style/content-guide/) + +### Члены SIG, участвующие в документировании новой функциональности + +Если вы участник SIG-группы, кто разрабатывает новую функциональность для Kubernetes, вам нужно работать с документацией SIG, чтобы убедиться, что на момент новой версии написана документация для этой функциональности. Проверьте [электронную таблицу с отслеживанием функциональности](https://github.com/kubernetes/sig-release/tree/master/releases) или присоединитесь в Slack-канал #sig-release, чтобы узнать информацию о сроках выхода. Некоторые крайние сроки касательно документации: + +- **Docs deadline - Open placeholder PRs**: откройте пулреквест в ветку `release-X.Y` в репозитории `kubernetes/website` с небольшим коммитом, который вы позже измените. Используйте команду Prow `/milestone X.Y`, чтобы назначить PR соответствующему этапу. Это уведомляет человека, который занимается документацией и ответственный за этот выпуск, что выходит документация для новой функциональности. Если функциональность не нуждается в каких-либо изменениях документации, убедитесь, что команда sig-release знает об этом, написав им сообщение в Slack-канале #sig-release. Если для функциональности нужна документация, но PR для этого ещё не создан, функциональность может быть удалена из этапа. +- **Docs deadline - PRs ready for review**: теперь ваш PR должен содержать первый черновик документации для вашей функциональности. Не беспокойтесь о форматировании или всяких улучшениях. Просто опишите, что делает эта функциональность и как ее использовать. Участник из группы документации, управляющий выпуском новой версии, будет работать вместе с вами, чтобы подготовить контент для публикации. Если вашей функциональности нужна документация и первого черновика с документацией до сих пор нет, эта функциональность может быть удалена из этапа. +- **Docs complete - All PRs reviewed and ready to merge**: если ваш PR еще не был объединен в ветку `release-X.Y` к заданному крайнему сроку, обратитесь за помощью к человеку, ответственному за выпуск новой версии. Если вашей функциональности требуется документация, но она ещё не сделана, функциональность может быть удалена из этапа. + +Если ваша функциональность находится в альфа-версии и ее не нельзя отключить, убедитесь, что вы добавили ее к [переключателем возможностей](/docs/reference/command-line-tools-reference/feature-gates/) в вашем пулреквесте. Если ваша функциональность переходит из альфа-версии, обязательно удалите ее из этого файла. + +## Участие к других репозиториях + +В [проекте Kubernetes](https://github.com/kubernetes) более 50 самостоятельных репозиториев. Многие из этих репозиториев хранят код или контент, который можно рассматривать как документацию, например, справочный текст для пользователях, сообщения об ошибках, пользовательский текст в справочниках API или даже комментарии кода. + +Если вы видите текст и не знаете, откуда он берётся, вы можете использовать поиск GitHub по репозиториям организации Kubernetes, чтобы выяснить, где встречается этот текст. Это поможет вам определиться с тем, куда создать заявку или PR. + +У каждого репозитория могут быть определены собственные процессы и правила. До того как открыть проблему или отправить PR, изучите файлы `README.md`, `CONTRIBUTING.md` и `code-of-conduct.md` в репозитории, если они есть. + +Большинство репозиториев используют шаблоны для заявок и PR. Просмотрите некоторые открытые заявки и PR, чтобы понять, как устроена работа. Обязательно как можно более подробно заполните шаблоны при открытии заявок или PR. + +## Локализация контента + +Английский является основным языком документации Kubernetes, однако мы хотим, чтобы у людей была возможность читать документацию на своём родном языке. Если вам комфортно писать на другом языке, особенно в теме программного обеспечения, вы можете помочь перевести документацию Kubernetes или помочь с существующим переводом. Посмотрите страницу [Локализация](/ru/docs/contribute/localization/) и задайте вопрос в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) или в канале `#sig-docs` на Slack, если вы хотите помочь. + +### Работа с локализованным контентом + +Старайтесь соблюдать эти рекомендации по работе с переведенным контентом: + +- В PR должны быть изменения касающиеся только одного языка. + + В каждом языке есть собственные рецензенты и утверждающие. + +- Рецензентам: убедитесь, что PR содержат изменения только на одном языке. + + Если PR изменяет файлы на нескольких языках, попросите автора открыть отдельные PR для каждого языка. + +{{% /capture %}} + +{{% capture whatsnext %}} + +Если вы хорошо осознали все задачи, затронутые в этом разделе, и хотите более тесно работать с командой документации Kubernetes, переходите к изучению [руководства для опытного участника](/ru/docs/contribute/advanced/). + +{{% /capture %}} diff --git a/content/ru/docs/contribute/localization.md b/content/ru/docs/contribute/localization.md new file mode 100644 index 0000000000..4706ff4e90 --- /dev/null +++ b/content/ru/docs/contribute/localization.md @@ -0,0 +1,286 @@ +--- +title: Локализация документации Kubernetes +content_template: templates/concept +card: + name: contribute + weight: 30 + title: Перевод документации +--- + +{{% capture overview %}} + +На этой странице рассказывается, как [локализовать](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) документацию на разные языки. + +{{% /capture %}} + +{{% capture body %}} + +## Начало работы + +Из-за того, что участники не могут одобрять собственные пулреквесты, нужно как минимум два участника для инициализации локализацию. + +Все команды по локализации должны быть самодостаточными. Это означает, что мы с радостью разместим вашу работу, но мы не можем сделать перевод за вас. + +### Определение двухбуквенного кода языка + +Первым делом ознакомьтесь со [стандартом ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php), чтобы найти двухбуквенный код страны для вашей локализации. Например, двухбуквенный код для корейского языка будет `ko`. + +### Создание копии репозитория + +Для начала [создайте собственную копию репозитория](/ru/docs/contribute/start/#улучшение-существующего-текста) оригинального репозитория [kubernetes/website](https://github.com/kubernetes/website). + +Затем клонируйте свою копию репозитория и перейдите в неё с помощью команды `cd`: + +```shell +git clone https://github.com//website +cd website +``` + +### Создание пулреквеста + +Далее [откройте пулреквест](/ru/docs/contribute/start/#отправка-пулреквеста) (PR) с локализацией в репозиторий `kubernetes/website`. + +Для того, чтобы ваш пулреквест был одобрен, он должен содержать [необходимый минимум контента](#необходимый-минимум-контента). + +В качестве примера добавления новой локализации, изучите PR, который добавляет [документацию на французском](https://github.com/kubernetes/website/pull/12548). + +### Вступление в GitHub-организацию Kubernetes + +Как только, как вы открыли PR с локализацией, вы можете стать членом организации Kubernetes на GitHub. Каждый член команды должен подать [запрос на членство в организации](https://github.com/kubernetes/org/issues/new/choose) в репозитории `kubernetes/org`. + +### Добавление команды локализации на GitHub + +Теперь нужно добавить вашу команду локализации Kubernetes в файл [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). Для примера добавления команды локализации можете посмотреть PR, добавляющий [испанскую команду локализации](https://github.com/kubernetes/org/pull/685). + +Члены `@kubernetes/sig-docs-**-owners` — могут одобрять PR, которые изменяют файлы внутри (и только там) директории с локализацией: `/content/**/`. + +Для каждой локализации группа `@kubernetes/sig-docs-**-reviews` служит для автоматизации выбора проверяющих новых PR. + +Члены `@kubernetes/website-maintainers` могут создавать новые ветки для координации работ по переводу. + +Члены `@kubernetes/website-milestone-maintainers` могут использовать [Prow-команду](https://prow.k8s.io/command-help) `/milestone` для контрольных точек для ишью или PR. + +### Настройка рабочего процесса + +Затем добавьте собственную GitHub-метку для вашей локализации в репозиторий `kubernetes/test-infra`. Метка позволяет фильтровать ишью и пулреквесты по конкретному языку. + +Смотрите пример добавления [метки для итальянского языка](https://github.com/kubernetes/test-infra/pull/11316). + +### Поиск сообщества + +Сообщите участниками группы Kubernetes SIG Docs о вашем намерении перевода документации! Подключайтесь к [Slack-каналу SIG Docs](https://kubernetes.slack.com/messages/C1J0BPD2M/). Остальные команды по локализации с радостью помогут вам начать и ответят на любые вопросы. + +Вы также можете создать Slack-канал для своей локализации в репозитории `kubernetes/community`. Для примера посмотрите PR с [добавлением Slack-канала для индонезийского и португальского языков](https://github.com/kubernetes/community/pull/3605). + +## Необходимый минимум контента + +### Изменение конфигурации сайта + +Сайт Kubernetes использует использует фреймворк Hugo. Конфигурация сайта у Hugo находится в файле [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml). Для поддержки новой локализации вам нужно отредактировать файл `config.toml`. + +Добавьте блок с конфигурацией для нового языка в `config.toml` после существующего блока `[languages]`. Например, конфигурация для немецкой локализации будет выглядить так: + +```toml +[languages.de] +title = "Kubernetes" +description = "Produktionsreife Container-Verwaltung" +languageName = "Deutsch" +contentDir = "content/de" +weight = 3 +``` + +При выбора значения для параметра `weight` в блока найдите языковой блок с наибольшим значением и прибавьте к нему 1. + +Для получения дополнительной информации о многоязычной поддержке в Hugo посмотрите страницу "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)". + +### Добавление директории для локализации + +Добавьте директорию для вашего языка в директорию [`content`](https://github.com/kubernetes/website/tree/master/content) репозитория. Например, двухбуквенный код для немецкого будет `de`: + +```shell +mkdir content/de +``` + +### Перевод норм поведения сообщества + +Откройте PR в репозитории [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) и добавьте перевод норм поведения на своём языке. + +### Добавление перевода для файла README + +Чтобы помочь другим участников локализации добавьте новый файл [`README-**.md`](https://help.github.com/articles/about-readmes/) в корневую директорию k/website, где `**` означает двухбуквенный код языка. Например, немецкий файл README будет именоваться как `README-de.md`. + +Подготовьте рекомендации для участников в файле для конкретной локализации `README-**.md`. В этом файле должна быть точно такая же информация, что и в оригинальном README.md ту же информацию, включая также: + +- Контактное лицо проекта локализации +- Любая другая информация, относящаяся к локализации + +После создания перевода файла README добавьте ссылку на файл в основной английский файл `README.md` и добавьте контактную информацию на английском языке. Вы можете указать логин на GitHub, адрес электронной почты, Slack-канал или какой-нибудь способ связи. Вам также нужно добавить ссылку на перевод норм поведения в сообществе. + +### Настройка файлов OWNERS + +Для определения роли каждого пользователя, участвующего в локализации, создайте файл `OWNERS` в директории языка, указав в нём следующие секции: + +- **reviewers**: список Kubernetes-команд с ролями рецензентов, в данном случае команда `sig-docs-**-reviews` будет создана в разделе [Добавление команды локализации на GitHub](#добавление-команды-локализации-на-github). +- **approvers**: список Kubernetes-команд с ролями утверждающих, в данном случае команда `sig-docs-**-owners` будет создана в разделе [Добавление команды локализации на GitHub](#добавление-команды-локализации-на-github). +- **labels**: список GitHub-меток, которые будут автоматически добавляться к PR, в данном случае метка языка будет создана в разделе [Настройка рабочего процесса](#настройка-рабочего-процесса). + +Дополнительную информацию о файле `OWNERS` вы можете получить по ссылке [go.k8s.io/owners](https://go.k8s.io/owners). + +[Испанский файл OWNERS](https://git.k8s.io/website/content/es/OWNERS) с кодом языка `es` выглядит следующим образом: + +```yaml +# See the OWNERS docs at https://go.k8s.io/owners + +# This is the localization project for Spanish. +# Teams and members are visible at https://github.com/orgs/kubernetes/teams. + +reviewers: +- sig-docs-es-reviews + +approvers: +- sig-docs-es-owners + +labels: +- language/es +``` + +После добавления файла `OWNERS` в определенном языке нужно обновить [корневой файл `OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES), добавив новые команды локализации Kubernetes — `sig-docs-**-owners` и `sig-docs-**-reviews`. + +Для каждой команды добавьте список GitHub-пользователей из раздела [Добавление команды локализации на GitHub](#добавление-команды-локализации-на-github), перечислите их в алфавитном порядке. + +```diff +--- a/OWNERS_ALIASES ++++ b/OWNERS_ALIASES +@@ -48,6 +48,14 @@ aliases: + - stewart-yu + - xiangpengzhao + - zhangxiaoyu-zidif ++ sig-docs-es-owners: # Admins for Spanish content ++ - alexbrand ++ - raelga ++ sig-docs-es-reviews: # PR reviews for Spanish content ++ - alexbrand ++ - electrocucaracha ++ - glo-pena ++ - raelga + sig-docs-fr-owners: # Admins for French content + - perriea + - remyleone +``` + +## Перевод контента + +Локализация *всей* документации Kubernetes — колоссальная задача. Вполне нормально начать переводить что-то небольшое, а затем со временем делать перевод больших страниц. + +Как минимум, все локализации должны включать: + +Описание | URL-адреса +-----|----- +Главная | [Все заголовки и подзаголовки URL-адресов](/ru/docs/home/) +Установка | [Все заголовки и подзаголовки URL-адресов](/ru/docs/setup/) +Руководства | [Основы Kubernetes](/ru/docs/tutorials/kubernetes-basics/), [Привет, Minikube](/ru/docs/tutorials/stateless-application/hello-minikube/) +Надписи на сайте | [Все надписи сайта в собственном TOML-файле](https://github.com/kubernetes/website/tree/master/i18n) + +Переведенные файлы должны находиться в собственной директории `content/**/`, но в во всём остальном должны быть такие, как и оригинал на английском. Например, чтобы подготовить [Основы Kubernetes](/ru/docs/tutorials/kubernetes-basics/) для перевода на немецкий язык, создайте поддиректорию в директории `content/de/` и скопируйте туда оригинальный английский файл: + +```shell +mkdir -p content/de/docs/tutorials +cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md +``` + +С помощью соответствующих инструментов можно ускорить процесс перевода. Например, у некоторых редакторов есть плагины для быстрого перевода текста. + +{{< caution >}} +Использование только машинного перевода не будет соответствовать минимальному уровню качества и поэтому такой перевод требует тщательного ручного рассмотрения для соблюдения стандарта качества. +{{< /caution >}} + +To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing. + +### Исходные файлы + +Локализация должна исходить из самой последней версии оригинальной документации — {{< latest-version >}}. + +Для того, чтобы получить исходные файлы последней версии: + +1. Перейдите в репозиторий сайта Kubernetes по адресу https://github.com/kubernetes/website. +2. Выберите ветку `release-1.X` самой последней версии. + +Текущая последняя версия {{< latest-version >}}, поэтому веткой для этого релиза будет [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}). + +### Сообщения на сайте в i18n/ + +Локализации должны включать содержимое файла [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) в новый языковой файл. В качестве примера рассмотрим немецкую локализацию: `i18n/de.toml`. + +Добавьте новый файл локализации в `i18n/`. Например, для немецкой локализации (`de`): + +```shell +cp i18n/en.toml i18n/de.toml +``` + +Затем переведите значение каждого сообщения: + +```TOML +[docs_label_i_am] +other = "ICH BIN..." +``` + +Локализация сообщений сайта позволяет изменить сообщения, используемые на всём сайте, к примеру, текст авторских прав в футере на каждой странице. + +### Глоссарий и руководство по оформления для языка + +У некоторых языковых команд есть собственные руководства по оформлению и глоссарий. Например, посмотрите [руководство корейской локализации](/ko/docs/contribute/localization_ko/). + +## Стратегия работы с ветками + +Работа в проектах локализации осуществляется посредством совместных усилий, поэтому мы приветствуем решение команды работать в общих ветках разработки. + +Совместная работа в рабочих ветках может быть организована следующим образом: + +1. Член команды [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) создает ветку из оригинальной ветки на https://github.com/kubernetes/website. + + После того, как вы [добавите свою команду локализации](#добавление-команды-локализации-на-github) в репозиторий [`kubernetes/org`](https://github.com/kubernetes/org), ваши утверждающие из группы будет присоединены к команде `@kubernetes/website-maintainers`. + + Мы рекомендуем следующую схему именования веток: + + `dev-<оригинальная версия>-<код языка>.<контрольная точка команды>` + + Например, утверждающий в немецкой группе локализации открывает рабочую ветку `dev-1.12-de.1` непосредственно в репозитории kubernetes/website из ветки для Kubernetes v1.12. + +2. Остальные участники создают новые ветки с изменениями на основе рабочей ветки. + + Например, участник немецкой группы локализации открывает пулреквест с изменениями в `kubernetes:dev-1.12-de.1` из `username:local-branch-name`. + +3. Утверждающий проверяет изменения и объединяют ветки в рабочую веткой. + +4. Периодически утверждающий объединяет рабочую ветку в оригинальную ветку, открывая и принимая новый пулреквест. Не забудьте объединить (squash) коммиты перед слиянием пулреквеста. + +Повторяйте шаги 1-4 до тех пор, пока не будет завершена локализация. Например, по мере работы над немецким переводом, рабочие ветки будут меняться: `dev-1.12-de.2`, `dev-1.12-de.3` и т.д. + +Команды должны объединять переведённый контент в ту же ветку выпуска, из которой она была создана. Например, рабочая ветка, созданная из версии {{< release-branch >}}, должна сливаться с веткой версии 1.17. + +Утверждающему следует поддерживать рабочую веку в актуальном состоянии в соответствии с оригинальной веткой, разрешая конфликты при слиянии. Чем дольше существует рабочая ветки, тем больше потребуется сил для ее поддержки. Поэтому лучше как можно быстрее сливать рабочую ветку и открывать новую, а не поддерживать только одну-единственную в течение длительного времени. + +В начале каждой контрольной точки команды полезно открыть ишью для сравнения изменений между предыдущей веткой и текущей рабочей веткой. + +Хотя только утверждающие могут открывать новую рабочую ветку и сливать пулреквесты, но любой может открыть пулреквест с новой веткой, которая может быть рабочей для команды. Никаких специальных разрешений для этого не требуется. + +Для получения дополнительной информации о работе с копиями или непосредственно с оригинальным репозиторией смотрите раздел по [созданию и клонированию копии репозитория](#создание-копии-репозитория). + +## Участие в работе над оригинальным контентом + +SIG Docs приветствует [участие и дополнения](/ru/docs/contribute/intermediate#локализация-контента) в английскую документацию. + +## Помощь для существующей локализации + +Вы также можете добавлять или улучшать контент в уже существующей локализации. Обратитесь к соответствующему [Slack-каналу](https://kubernetes.slack.com/messages/C1J0BPD2M/) для этого и начинайте помогать через PR. + +{{% /capture %}} + +{{% capture whatsnext %}} + +Как только локализация будет соответствовать требованиям установленного рабочего процесса и содержать требуемый минимум контента, группа SIG Docs: + +- Добавит язык на сайт +- Сообщит о новой локализации на каналах [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF), включая [блог Kubernetes](https://kubernetes.io/blog/). + +{{% /capture %}} diff --git a/content/ru/docs/contribute/participating.md b/content/ru/docs/contribute/participating.md new file mode 100644 index 0000000000..b0f1a743ba --- /dev/null +++ b/content/ru/docs/contribute/participating.md @@ -0,0 +1,208 @@ +--- +title: Участие в SIG Docs +content_template: templates/concept +card: + name: contribute + weight: 40 +--- + +{{% capture overview %}} + +SIG Docs — это одна из [специальных групп](https://github.com/kubernetes/community/blob/master/sig-list.md) в проекте Kubernetes, которая занимается написанием, обновлением и поддержкой документации Kubernetes в целом. Перейдите на страницу про [SIG Docs в GitHub-репозитории](https://github.com/kubernetes/community/tree/master/sig-docs), чтобы узнать подробную информацию об этой группе. + +SIG Docs активно принимает правки и дополнения в документацию, так и отзывы от всех участников. Любой может открыть пулреквест (PR), либо сообщить про ошибки в тексте или просто прокомментировать выполняемые пулреквесты. + +Вы также можете стать [членом](#члены), [рецензентом](#рецензенты) или [утверждающим](#утверждающие). Эти роли расширяют ваши возможности, но и предлагают выполнение определенных обязанностей по рассмотрению и принятию изменений. Изучите содержимого файла [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) в директории сообщества репозитория, чтобы узнать про членство в сообществе Kubernetes. В остальной части этой страницы кратко рассматривается функционирование ролей в группе SIG Docs, которая в совокупности отвечает за поддержание одного из самой публичной части Kubernetes — сайта и документации Kubernetes. + +{{% /capture %}} + +{{% capture body %}} + +## Роли и обязанности + +- **Любой** может поучаствовать в документацию Kubernetes. Для этого вам нужно только [подписать CLA](/ru/docs/contribute/start#sign-the-cla) и иметь аккаунт на GitHub. +- **Члены** организации Kubernetes — участники, которые активно занимаются пректом Kubernetes, как правило, открывая пулреквесты с принятыми изменениями. Посмотрите файл [Членство в сообществе](https://github.com/kubernetes/community/blob/master/community-membership.md), чтобы узнать про необходимые условия для членства. +- **Рецензент** SIG Docs — член организации Kubernetes, который занимается проверкой пулреквестов и поэтому был добавлен в соответствующую группу на GitHub и в файлы `OWNERS` в GitHub-репозитории. +- **Утверждающий** SIG Docs — член организации с хорошей репутацией, который подтвердил неизменную приверженность проекту. Утверждающий может принимать пулреквесты и публиковаться от имени организации Kubernetes. Утверждающие также могут представлять группу SIG Docs в более крупном сообществе Kubernetes. Некоторые из задач утверждающего SIG Docs, например, координация новой версии, требуют значительных затрат по времени. + +## Любой + +Кто угодно может сделать следующее: + +- Открыть ишью на GitHub в любую часть Kubernetes, включая документацию. +- Дать рекомендацию или предложить улучшение в пулреквесте. +- Предложить идею по улучшению в Slack](http://slack.k8s.io/) или в [список рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +- Использовать команду `/lgtm` (сокращение от "looks good to me") бота Prow, чтобы одобрить изменения в пулреквесте. + {{< note >}} + Если вы не входите в организацию Kubernetes, то команда `/lgtm` не проставил автоматически соответствующую метку. + {{< /note >}} + +После [подписания CLA](/ru/docs/contribute/start#sign-the-cla) каждый также может: +- Открыть пулреквест, чтобы улучшить существующий текст, либо что-то новое, или написать запись в блоге или описать пример использования. + +## Члены + +Члены — это участники проекта Kubernetes, которые удовлетворяют [критериям членства](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs ценит участие всех членов сообщества Kubernetes и часто просит дать обратную связь от членов других SIG-групп для соблюдения технической точности. + +Любой член [организации Kubernetes](https://github.com/kubernetes) может сделать следующее: + +- Всё то же самое, что и [любой другой участник](#любой) +- Использовать команду `/lgtm` в комментарии для автоматического добавления метки LGTM (looks good to me) для пулреквеста. +- Использовать команду `/hold` в комментарии для блокировки слияния пулреквеста, если он имеет метку LGTM и другие утверждающие метки. +- Использовать команду `/assign` в комментарии, чтобы назначить рецензента, который будет проверят пулреквест. + +### Членство + +После того, как вы успешно отправили не менее 5 содержательных пулреквестов, вы можете стать [членом](https://github.com/kubernetes/community/blob/master/community-membership.md#member) организации Kubernetes. Следуйте нижеперечисленным шагам: + +1. Найдите двух рецензентов или утверждающих, которые [поддержат](/ru/docs/contribute/advanced#поддержка-нового-участника) ваше членство. + + Запросите спонсорство в канале [#sig-docs Kubernetes Slack](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + + {{< note >}} + Не отправляйте электронное письмо и не пишите личное сообщение в Slack кому-либо из участников SIG Docs. + {{< /note >}} + +2. Создайте ишью в репозитории `kubernetes/org`, чтобы запросить членство. + Заполните шаблон, предварительно изучив правила [членства в сообществе](https://github.com/kubernetes/community/blob/master/community-membership.md). + +3. Сообщите вашим спонсорам про вашу заявку на GitHub, упомянув их в ней на GitHub (добавив комментарий в форме `@`), либо отправив им ссылку напрямую, чтобы они могли добавить проголосовать ( `+1`). + +4. Когда ваше членство будет одобрено, член административной команды на GitHub, назначенный для обработки вашего пулреквеста, обновит ишью на GitHub, чтобы показать одобрение, а затем закроет проблему GitHub. + Поздравляем, теперь вы член организации! + +Если ваша заявка на членство не была одобрена, членский комитет даст уточнения или перечислит шаги, которые необходимо выполнить, прежде чем снова подать заявку. + +## Рецензенты + +Рецензенты — это члены GitHub-группы [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews). Рецензенты проверяют пулреквесты документации и оставлять обратную связь по предлагаемым изменениях. Рецензенты могут: + +- Делать всё то, что и [любой участник](#любой) и [члены](#члены) +- Писать документацию для новой функциональности +- Назначать метки и классифицировать ишью +- Проверять пулреквесты и оставлять обязательные для выполнения рекомендации +- Создавайте диаграммы, графику и встраиваемые скринкасты и видеоролики +- Заниматься локализацией +- Редактировать строки в коде, относящиеся к интерфейсу пользователя +- Улучшать комментарии к коду + +### Выбор рецензентов для проверки пулреквестов + +Процесс выбора рецензентов для проверки пулреквестов автоматизирован. Вы можете попросить проверку у определенного рецензента, написав комментарий в пулреквесте: `/assign [@_github_handle]`. Чтобы показать, что пулреквест является правильным с технической точки зрения и не требует дополнительных изменений, рецензент добавляет комментарий с командой `/lgtm`. + +Если назначенный рецензент еще не просмотрел содержимое пулреквеста, может присоединиться другой проверяющий. Кроме того, вы можете назначить технических рецензентов и подождать их одобрение через комментарий с `/lgtm`. + +Также для совсем небольшого изменения, или такого, которое не требует технического рассмотрения, [утверждающие](#утверждающие) SIG Docs одобрить его через комментарий с `/lgtm`. + +Комментарий с `/approve` от рецензента игнорируется ботом и поэтому соответствующая метка не добавится к пулреквесту. + +### Как стать рецензентом + +Если вы соответствуете [требованием](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), то можете стать рецензентом SIG Docs. Рецензенты в других SIG-группах должны подать новую заявку для получения статуса рецензента в SIG Docs. + +Для отправки заявки откройте пулреквест с добавлением самого себя в секцию `reviewers` [корневого файла OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) в репозитории `kubernetes/website`. Запросите проверку вашего пулреквеста одному или нескольким текущим утверждающим в группе SIG Docs. + +Если ваш пулреквест одобрен, вы становитесь рецензентом SIG Docs. Теперь бот [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) будет назначать и предлагать вас в качестве рецензента для проверки новых пулреквестов. + +После того, как ваша кандидатура будет одобрена, попросите текущего утверждающего SIG Docs добавить вас в GitHub-группу [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews). Только члены GitHub-группы `kubernetes-website-admins` могут добавлять новых членов в какую-либо другую группу. + +## Утверждающие + +Утверждающие — члены GitHub-группы [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers). Перейдите в раздел [Команды и группы в SIG Docs](#teams-and-groups-within-sig-docs) для получения дополнительной информации. + +Утверждающие могут делать следующее: + +- Все то же, что и [обычные участники](#любой), [члены](#члены) и [рецензенты](#рецензенты) +- Публиковать изменения от других участников путём одобрения и слияния пулреквестов с помощью комментария с командой `/approve`. + Если кто-то оставляет комментарий, не являясь при этом официальным рецензентом, бот проигнорирует такой одобряющий комментарий. +- Примите участие в работе команды выпуска новых версий Kubernetes как представитель документации +- Предлагать улучшения в руководстве по оформлению +- Предлагать улучшения для тестов документации +- Предлагать улучшения для сайта Kubernetes или других инструментов + +Если у PR есть метка `/lgtm`, или если утверждающий оставляет комментарий с командной с `/lgtm`, PR автоматически сливается. Утверждающий SIG Docs должен оставлять комментарий с `/lgtm` только для тех изменений, которые не нуждаются в дополнительном техническом обзоре. + +### Как стать утверждающим + +Если вы соответствуете [требованием](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), вы можете стать утверждающим SIG Docs. Утверждающие в других SIG-группах должны подать новую заявку для получения статуса утверждающего в SIG Docs. + +Для отправки заявки откройте пулреквест с добавлением самого себя в секцию `approvers` [корневого файла OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) в репозитории `kubernetes/website`. Запросите проверку вашего пулреквеста одному или нескольким текущим утверждающим в группе SIG Docs. + +Если ваш пулреквест одобрен, вы становитесь утверждающим SIG Docs. Теперь бот [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) будет назначать и предлагать вас в качестве рецензента для проверки новых пулреквестов. + +После того, как ваша кандидатура будет одобрена, попросите текущего утверждающего SIG Docs добавить вас в GitHub-группу[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers). Только члены GitHub-группы `kubernetes-website-admins` могут добавлять новых членов в какую-либо другую группу. + +### Обязанности утверждающего + +Утверждающие улучшают документацию, проверяя и сливая пулреквесты в репозитории сайта. Из-за того, эта роль предусматривает дополнительные привилегии, на утверждающих возлагаются дополнительные обязанности: + +- Утверждающие могут использовать команду `/approve`, которая сливает PR в репозиторий. + + Невнимательное слияние может нарушить работу сайта, поэтому имейте это в виду, когда объединяете какой-либо пулреквест. + +- Убедитесь, что предлагаемые изменения соответствуют [правилам по содержанию](/docs/contribute/style/content-guide/#contributing-content). + + Если вы сомневаетесь или вы не уверены в чем-либо, не стесняйтесь обращаться для дополнительной проверки. + +- Проверьте, что тесты на Netlify пройдены успешно, перед тем как написать комментарий с `/approve` в PR. + + Netlify tests must pass before approving + +- Перед одобрением пулреквеста перейдите на предварительный просмотр сайта на Netlify для сделанных изменений в PR, и убедитесь, что всё содержимое выглядит хорошо. + +- Участвуйте в [графике дежурства смотрителя PR](https://github.com/kubernetes/website/wiki/PR-Wranglers), чтобы вас назначили дежурным проверяющим на неделю. SIG Docs ожидает, что все утверждающие примут участие в этом графике. За подробностям обратитесь к странице [Be the PR Wrangler for a week](/ru/docs/contribute/advanced#дежурный-по-pr-на-неделю). + +## Председатель SIG Docs + +Каждая SIG-группа, включая SIG Docs, выбирает одного или нескольких членов из своей SIG-группы в качестве председателей. Это координаторы между SIG Docs и другими подразделениями в организации Kubernetes. От таких людей требуются обширные знания о структуре проекта Kubernetes в целом и как функционирует группа SIG Docs внутри неё. Смотрите раздел [Руководство](https://github.com/kubernetes/community/tree/master/sig-docs#leadership), чтобы узнать текущий список председателей. + +## Команды SIG Docs и автоматизация + +Автоматизация в SIG Docs основывается на двух разных механизмах: +группы GitHub и файлы OWNERS. + +### GitHub-группы + +Группа SIG Docs представлена двумя командами на 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) + +На каждую из них можно сослаться по имени (`@name`) в комментариях на GitHub, чтобы общаться со всеми участниками в этой группе. + +Эти команды пересекаются, но назначение у них разное. Для назначения людей на ишью, пулреквестов и поддержки одобрений в PR бот использует информацию из файлов OWNERS. + +### Файлы OWNERS и вступительная часть + +Проект Kubernetes использует инструмент автоматизации под названием prow, чтобы автоматизировать процесс, связанный с ишью и пулреквестами на GitHub. [Репозиторий сайта Kubernetes](https://github.com/kubernetes/website) использует два [плагина prow](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): + +- blunderbuss +- approve + +Все эти плагины используют файлы [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) и [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) в корневой директории GitHub-репозитория `kubernetes/website`, чтобы контролировать работу prow по всему репозиторию. + +Файл OWNERS содержит список людей, которые являются рецензентами и утверждающими в SIG Docs. Файлы OWNERS также может быть в поддиректориях и могут переопределять тех, кто может выступать в качестве рецензента или утверждающего в изменениях файлов этой директории и её поддиректорий. Для получения дополнительной информации о файлах OWNERS в целом, перейдите в [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). + +Кроме того, в каждом Markdown-файле могут быть указаны рецензенты и утверждающие в так называемой вступительной части (front-matter) в виде логинов участников или имён групп на GitHub. + +Таким образом файлы OWNERS и вступительная часть в Markdown-файлах определяет своего рода рекомендацию для бота, чтобы он знал, к кому обращаться за технической и редакционной проверкой каждого PR. + +## Как происходит слияние + +Когда пулреквест сливается в действующую ветку сайта (в данный момент это `master`), содержимое публикуется и становится общедоступным. Для обеспечения высокого качества публикуемого нами контента, мы доверяем слияние пулреквестов утверждающим SIG Docs. Ниже описан этот процесс. + +- Когда пулреквест имеет метки `lgtm` и `approve`, при этом у него нет метки `hold`, и то же время все тесты успешно проходят, то пулреквест автоматически сливается. +- Члены организации Kubernetes и утверждающие SIG Docs могут оставлять комментарии со специальными командами, которые блокирует автоматическое объединение пулреквеста (добавление комментарий с текстом `/hold` или удаление ранее установленной метки `/lgtm`). +- Любой участник Kubernetes может добавить метку `lgtm`, добавив комментарий, включающий в себя `/lgtm`. +- Только утверждающие SIG Docs могут слить пулреквест путём добавления комментария с `/approve`. Некоторые утверждающие также играют дополнительные роли, например, [дежурного по PR](#pr-wrangler) или [председателя SIG Docs](#председатель-sig-docs). + +{{% /capture %}} + +{{% capture whatsnext %}} + +Для получения дополнительной информации про участие в документации Kubernetes, посмотрите следующие страницы: + +- [Участие для начинающих](/ru/docs/contribute/start/) +- [Правила оформления документации](/ru/docs/contribute/style/) + +{{% /capture %}} diff --git a/content/ru/docs/contribute/start.md b/content/ru/docs/contribute/start.md new file mode 100644 index 0000000000..da0af7eb22 --- /dev/null +++ b/content/ru/docs/contribute/start.md @@ -0,0 +1,233 @@ +--- +title: Участие для начинающих +slug: start +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 10 +--- + +{{% capture overview %}} + +Если вы хотите поучаствовать в работе над документацией Kubernetes, эта страница и связанные с ней темы могут помочь вам начать работу. Вам не нужно быть разработчиком или техническим писателем, чтобы внести вклад в документацию или улучшить сайт Kubernetes! Все, что вам нужно для тем на этой странице, это учетная запись на GitHub и браузер. + +Если вы ищете информацию про участие в репозиториях, связанным с кодом Kubernetes, обратитесь к [руководству сообщества Kubernetes](https://github.com/kubernetes/community/blob/master/governance.md). + +{{% /capture %}} + + +{{% capture body %}} + +## Основные сведения про документацию + +Документация Kubernetes написана на Markdown, обработана и развернута при помощи Hugo. Исходные файлы находятся на GitHub по адресу https://github.com/kubernetes/website. Основная часть документации хранится в директории `/content/en/docs/`. Часть справочной документации автоматически генерируется из скриптов в директории `update-imported-docs/`. + +Вы можете создавать новые задачи, редактировать содержимое и проверять изменения от других участников, — всё это доступно с сайта GitHub. Вы также можете использовать встроенный в GitHub поиск и историю коммитов. + +Не все задачи могут быть выполнены с помощью интерфейса GitHub, но некоторые из них обсуждаются в руководствах для [продвинутых](/ru/docs/contribute/intermediate/) и +[опытных](/ru/docs/contribute/advanced/) участников. + +### Участие в документации SIG + +Документация Kubernetes поддерживается {{< glossary_tooltip text="специальной группой" term_id="sig" >}} (Special Interest Group, SIG) под названием SIG Docs. Мы [общаемся](#participate-in-sig-docs-discussions) с помощью канала Slack, списка рассылки и еженедельных видеозвонков. Будем рады новым участникам. Для получения дополнительной информации обратитесь к странице [Участие в SIG Docs](ru/docs/contribute/participating/). + +### Руководящие принципы по содержанию + +Сообщество SIG Docs разработало правила, которые касаются разрешенных видов контента в документации Kubernetes. Посмотрите [руководство по содержанию документации](/docs/contribute/style/content-guide/) для определения того, допустим ли контент, который вы хотите добавить. Задать вопросы про допустимый контент можно в Slack-канале [#sig-docs](#participate-in-sig-docs-discussions). + +### Правила оформления + +Мы поддерживаем [руководство по оформлению](/docs/contribute/style/style-guide/) с информацией о выборе, сделанном сообществом SIG Docs в отношении грамматики, синтаксиса, исходного форматирования и типографских соглашений. Прежде чем сделать свой первый вклад, просмотрите руководство по стилю и используйте его, когда у вас есть вопросы. + +SIG Docs совместными усилиями вносит изменения в руководство по оформлению. Чтобы предложить изменение или дополнение, добавьте его в повестку дня предстоящей встречи SIG Docs и посетите её, чтобы принять участие в обсуждении. Смотрите руководство для [продвинутых участников](/docs/contribute/advanced/), чтобы получить дополнительную информацию. + +### Шаблоны страниц + +Мы используем шаблоны страниц, чтобы управлять представление наших страниц документации. Разберитесь как работают эти шаблоны, ознакомившись с разделом [Использование шаблонов страниц](/docs/contribute/style/page-templates/). + +### Макрокоды Hugo + +Документация Kubernetes с помощью Hugo конвертируется из формата разметки Markdown в HTML. Мы используем встроенные макрокоды Hugo, а также некоторые из своих собственных, созданных специально для документации Kubernetes. Посетите страницу [Нестандартные макрокоды Hugo](/docs/contribute/style/hugo-shortcodes/), чтобы узнать, как их использовать. + +### Мультиязычность + +Исходные файлы документации доступны на нескольких языках в директории `/content/`. Каждый язык имеет свою собственную директорию с двухбуквенным кодом, определенным стандартом[ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). Например, исходники документации для английского языка хранится в директории `/content/en/docs/`. + +Более подробную информацию про участие в работе над документацией на нескольких языках ["Localize content"](/docs/contribute/intermediate#localize-content) в промежуточном руководстве по добавлению. + +Если вы заинтересованы в переводе документации на новый язык, посмотрите раздел ["Локализация"](/ru/docs/contribute/localization/). + +## Создание хороших заявок + +Любой, у кого есть аккаунт на GitHub, может создать заявку (issue, или отчет об ошибке) в документации Kubernetes. Если вы заметили какую-либо какую-либо ошибку, даже если вы не знаете, как её исправить, [откройте ишью](#how-to-file-an-issue). Но не делайте этого, если нашли небольшую ошибку, например, опечатку, которую вы при желании можете исправить самостоятельно. В этом случае можете [исправить ее](#improve-existing-content) вместо того, чтобы писать об этом. + +### Как создать заявку + +- **Для существующей страницы** + + Если заметили проблему на существующей странице в [документации Kubernetes](/ru/docs/), перейдите в конец страницы и нажмите кнопку **Create an Issue**. Если вы ещё не авторизованы в GitHub, сделайте это. После этого откроется страница с форма для создания нового запроса в GitHub с уже предварительно заполненным полями. + + При помощи разметки Markdown опишите как можно подробнее, что хотите. Там, где вы видите пустые квадратные скобки (`[ ]`), проставьте `x` между скобками. Если у вас есть предлагаемое решение проблемы, напишите его. + +- **Запросить новую страницу** + + Если вы хотите добавить что-то новое, но вы не уверены, на какую страницу документации это сделать или считаете, что новая информация не вписывается в существующие страницы, всё равно создайте ишью. Вы можете либо перейти на страницу документации, куда, по вашему мнению, нужно добавить новую информацию и создать заявку прямо с этой страницы, либо перейти по адресу [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) и написать что вы хотите там. + +### Как заполнить хорошую заявку + +Чтобы нам самим убедиться, что понимаем вас правильно, помните следующее: + +- Используйте шаблон ишью и заполните его как можно подробнее. +- Четко изложите суть вашего проблемы, как она сказывается на пользователях. +- Как можно меньше ограничьте охват изменений в вашей заявке. Задачи с большим объемом работы разбейте на более мелкие. + Например, "Fix the security docs" не является проблемой, требующей немедленного решения, зато заявка с заголовком "Add details to the 'Restricting network access' topic", вероятно, такой является. +- Если проблема связана с другой заявкой или пулреквестом, вы можете указать сослаться на них, либо по его полному URL-адресу, либо по их номеру с `#`. Например, `Introduced by #987654`. +- Будьте уважительны и избегайте жалоб. Например, заголовок ишью "The docs about X suck" явно не несёт ничего полезного или чтобы на него реагировали. + [Нормы поведения](/community/code-of-conduct/) также применяется к общению в GitHub-репозиториях Kubernetes. + +## Участие в дискуссиях SIG Docs + +Команда SIG Docs общается следующими способами: + +- [Зарегистрируйтесь в Slack-канале Kubernetes](http://slack.k8s.io/), а затем присоединитесь к каналу `#sig-docs`, где мы в режиме реального времени обсуждаем всё, что связано с документацией. И не забудьте представиться! +- [Подпишитесь на список рассылки `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), где проходят более общие дискуссии и принимаются официальные решения. +- Участвуйте в [еженедельной видеовстрече IG Docs](https://github.com/kubernetes/community/tree/master/sig-docs), которая анонсируется в Slack-канале и списке рассылки. В данный момент эти встречи проводятся в Zoom, поэтому вам необходимо загрузить клиент Zoom или позвонить по телефону. + +{{< note >}} +Вы всегда можете узнать когда будет очередное еженедельное собрание SIG Docs в [календаре собраний сообщества Kubernetes](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). +{{< /note >}} + +## Улучшение существующего текста + +Чтобы улучшить текущее содержимое документации, вам нужно открыть _пулреквест (pull request, PR)_ после того, как вы сделаете _копию (fork)_ оригинального репозитория. Эти два термина [относятся к GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/). +Для начала работы, которая показана в этом разделе, вам не нужно знать всё про эти понятия, так как вы всё можете делать в своём браузере. Когда вы перейдете к продвинутому руководству участника документации, тогда вам понадобиться пополнить свои знания Git. + +Примечание. Разработчики кода Kubernetes. Если вы документируете новую функцию для предстоящего выпуска Kubernetes, ваш процесс будет немного другим. См. Документирование функции для руководства по процессу и информации о сроках. + +{{< note >}} +**Для разработчиков кода Kubernetes**: если вы документируете новую функциональность для новой версии Kubernetes, то процесс рассмотрения будет немного другим. Посетите страницу [Документирование функциональности](/ru/docs/contribute/intermediate/#добавление-документации-для-новой-функциональности), чтобы узнать про процесс и информацию о крайних сроках. +{{< /note >}} + +### Подписание CLA-соглашения CNCF {#sign-the-cla} + +Прежде чем внести вклад в код или документацию Kubernetes, вам **обязательно** следует прочитать [руководство для участников](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) и [подписать лицензионное соглашение участника (Contributor License Agreement, CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). +Не переживайте — подписание не займет много времени! + +### Поиск задач для работы + +Если вы уже нашли что исправить, просто следуйте инструкциям ниже. Для этого вам не обязательно [создавать ишью](#создание-хороших-заявок) (хотя вы, безусловно, пойти этим путём). + +Если вы хотите ещё не определились с тем, над чем хотите поработать, перейдите по адресу [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) и найдите ишью с меткой `good first issue` (вы можете использовать [эту](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) ссылку для быстрого поиска). Прочитайте комментарии, чтобы убедиться что нет открытого пулреквеста для решения текущей ишью, а также, что никто другой не оставил комментарий, что он работает над этой задачей в последнее время (как правило, 3 дня). Добавьте комментарий, что вы хотели бы заняться решением этой задачи. + +### Выбор правильной ветки в Git + +Самым важный момент в создании пулреквестов — это выбор нужной ветки для вашей работы. Используйте эти рекомендации, чтобы принять верное решение: + +- Используйте ветку `master` для исправления ошибок в текущей документации, либо чтобы улучшить существующий текст. +- Используйте ветку `master` для документирования функциональности в текущей версии Kubernetes, для которой отсутствовала документация. Прежде всего вам нужно написать документацию на английском языке, а затем команды по переводам подхватят это изменение, чтобы актуализировать перевод. +- Если вы работаете над переводом, вам нужно следовать соглашению в этой конкретной локализации. Чтобы понять это, вы можете другие пулреквесты (подсказка: `is:pr is:merged label:language/xx`) + {{< comment >}}Localization note: when localizing that tip, replace `xx` + with the actual ISO3166 two-letter code for your target locale.{{< /comment >}} + - Некоторые команды локализации работают с пулреквестами, которые ориентированы на ветку `master` + - Другие команды локализации работают с рядом долговечных веток, периодически сливая их в ветку `master`. Такая ветка именуется как dev-\-\.\, например, `dev-{{< release-branch >}}-ja.1`. +- Если вы пишете или обновляете документацию к выпуску грядущего изменения, то вам необходимо знать мажорную и минорную версию Kubernetes, в которой это изменение впервые появится. + - Например, если переключатель возможностей (feature gates) JustAnExample должен измениться с альфа-версии на бета-версию в следующей минорной версии, вам необходимо знать номер этой версии. + - Найдите ветку выпуска, названную для этой версии. Например, функциональность, которая изменились в выпуске v{{< release-branch >}}, будет документирована в ветке `dev-{{< release-branch >}}`. + +Если вы все еще не уверены, какую ветку выбрать, спросите в Slack-канале `#sig-docs` или посетите еженедельную встречу SIG Docs, чтобы внести ясность. + +### Отправка пулреквеста + +Следуйте описанным ниже шагам, чтобы создать пулреквест для улучшения документации Kubernetes. + +1. На странице, которую вы хотите отредактировать, щелкните на иконку карандаша в правом верхнем углу. Откроется новая страница на GitHub с небольшой подсказкой. +2. Если вы ранее не делали копию репозитория документации Kubernetes, вам будет предложено это сделать. Создайте копию репозитория под своим логином GitHub, а не в организации, в которой вы состоите. URL-адрес копии репозитория будет выглядит как `https://github.com//website`, в случае у вас нет репозитория с таким же названием. + + Поскольку у вас нет доступа к оригинальному репозиторию и соответственно вы не можете отправлять напрямую изменения в основную ветку, вам нужно сделать копию репозитория Kubernetes. + +3. Откроется редактор GitHub для редактирования исходного файла в формате Markdown. Внесите свои изменения. Под редактором заполните форму **Propose file change**. Первое поле — краткое содержание вашего сообщения коммита, оно должно содержать не более 50 символов. Второе поле является необязательным, в нём вы можете подробно расписать суть ваших изменений. + + {{< note >}} + Не ссылайте на другие ишью или пулреквесты на GitHub в сообщении коммита. Вы можете сослаться на них в тексте пулреквеста. +{{< /note >}} + + Нажмите на кнопку **Propose file change**. Изменения в файле записываются в виде коммита в новой ветке вашей копии репозитория, которая автоматически будет иметь имя что-то вроде `patch-1`. + +4. На следующей странице вам будут показаны различия в вашей ветке (поля выбора **head fork** и **compare**) с текущим состоянием **оригинального репозитория (base fork)** в **основной ветке (base)** (по умолчанию ветка `master` в репозитории `kubernetes/website`). Вы можете выбрать другое значение в полях выбора, но не делайте этого сейчас. Сравните различия и если всё верно, нажмите кнопку **Create pull request**. + + {{< note >}} + Если вы не хотите создавать пулреквест в данный момент, это можно сделать позже, если перейти на страницу репозитория сайта Kubernetes или вашей копии репозитория. На сайте GitHub вам предложит открыть пулреквест, если он обнаружит новую ветку в вашей копии репозитория. +{{< /note >}} + +5. Отобразится форма с заголовком **Open a pull request**. Название пулреквеста будет содержать краткое описание из сообщения коммита, хотя вы можете изменить его при необходимости. В описании пулреквеста будет остальная информация из сообщения коммита (если оно есть) и небольшой шаблон с текстом. Прочитайте текст шаблона и сделайте то, что там описано, а затем удалите этот шаблонный текст. Если вы добавите в описание пулреквест `fixes #<000000>` или `closes #<000000>`, где `#<000000>` - номер связанной заявки, то GitHub автоматически закроет указанную заявку при слиянии пулреквеста. Оставьте флажок **Allow edits from maintainers** отмеченным. Нажмите на кнопку **Create pull request**. + + Поздравляем! Ваш пулреквест добавлен в список [пулреквестов](https://github.com/kubernetes/website/pulls). + + Через несколько минут вы сможете просмотреть версию сайта с изменениями в вашем пулреквесте. Перейдите в низ страницы пулреквеста на вкладке **Conversation** и там нажмите на ссылку **Details** рядом с проверкой `deploy/netlify`. По умолчанию она откроется в текущей вкладке. + + {{< note >}} + Пожалуйста, открывайте пулреквест, изменения которого затрагивают только один язык. Например, если вам нужно одинаково изменить один и тот же пример кода в нескольких языках, откройте по отдельному пулреквесту для каждого языка. + {{< /note >}} + +6. Ожидайте, когда проверят ваш пулреквест. Как правило, рецензенты выбираются авматоматически ботом `k8s-ci-robot`. Если рецензент попросил изменить пулреквест, вы можете сделать это, если перейдёте на вкладку **Files changed** и щёлкните на иконку с карандашом на любом изменённом файле в вашем пулреквесте. Сохранение измененного файла оформляется в виде нового коммита в ветке, указанной в пулреквесте. Если вы ожидаете новую проверку изменений от рецензента, заранее попросите его об этом не более одного раза в 7 дней. Вы также можете зайти в Slack-канал #sig-docs — это хорошее место, где можно попросить проверку пулреквеста. + +7. Если ваши изменения одобрены, то рецензент объединяет соответствующий пулреквест. Через несколько минут вы сможете сможете увидеть его в действии на сайте Kubernetes. + +Это только один из способов отправить пулреквест. Если вы уже опытный пользователь Git и GitHub, вы можете вносить изменения, используя локальный GUI-клиент или Git из терминала вместо того, чтобы использовать интерфейс GitHub для этого. Некоторые основы использования Git-клиента из командной строки обсуждаются в руководстве для [продвинутого участника](/ru/docs/contribute/intermediate/). + +## Просмотр пулреквестов в документацию + +Новички документации могут обозревать пулреквесты. Вы можете изучить кодовую базу и завоевать доверие к себе со стороны коллег-участников. Документация на английском — это первоисточник содержимого. Мы общаемся на английском языке во время еженедельных встреч и в объявлениях сообщества. Владение английским языком может быть разным, поэтому используйте простой и прямой язык в своих обзорах пулреквестов. Полезные обзоры фокусируются как на мелких деталях, так и на потенциальном влиянии изменений. + +Обзоры не носят «обязательный характер», это означает, что только ваша проверка не приведет к слиянию пулреквеста. Тем не менее, это не делает ваши обзоры бесполезными. Даже только просмотр изменений в пулреквеста поможет вам понять как происходит рабочий процесс, какие могут быть трудности и проблемы. Перед проверкой пулреквестов ознакомьтесь с [руководством по содержанию](/docs/contribute/style/content-guide/) и [руководством по оформлению](/docs/contribute/style/style-guide/), чтобы узнать, каким должен быть содержимое и как оно должно быть оформлено.. + +### Рекомендации + +- Будьте вежливы, внимательны и помогайте другим +- Не забывайте отмечать также положительные стороны пулреквеста +- Будьте чутким и думайте, как ваши комментарии могут быть восприняты +- Проявите добрые намерения и задавайте уточняющие вопросы +- Опытным участникам: помогайте новым участникам, их работа требует глаз да глаз + +### Поиск и проверка пулреквеста + +1. Перейдите по URL-адресу [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). Вы увидите список всех пулреквестов в репозиторий сайта Kubernetes и его документации. + +2. По умолчанию открываются открытые пулреквесты (статус `open`), поэтому вы не увидите закрытых или принятых пулреквестов. Рекомендуется добавить дополнительный фильтр `cncf-cla: yes`, а также для вашей первой проверки пулреквеста неплохо применить ещё и `size/S` и `size/XS`. Метка с размером назначается автоматически в зависимости от количества изменённых строк кода в пулреквесте. Вы можете применить фильтры, используя поля выбора в верхней части страницы, либо воспользоваться [этой ссылкой](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) для просмотра небольших пулреквестов. Все фильтры объединены в логическое `AND`, поэтому у вас не получиться искать по меткам `size/XS` и `size/S` одновременно. + +3. Перейдите на вкладку **Files changed**. Посмотрите изменения, внесенные в PR, а также изучите любые связанные задачи (если есть). Если вы видите ошибку, неточность или хотите внести улучшение, то наведите курсор на строку и щелкните на появившийся символ `+`. + + Вы можете написать комментарий, после чего нажать на кнопку **Add single comment** или **Start a review**. Как правило, лучше начать проверку (review), поскольку тогда вы сможете оставить несколько комментариев и уведомить автора PR только после завершения рецензирования, вместо того, чтобы упоминать его в каждом комментарии. + +4. После окончания разбора пулреквеста, нажмите на кнопку **Review changes** вверху страницы. Вы можете подвести краткий итог своей проверки и выполнить одно из действий: просто прокомментировать, одобрить или запросить изменения. Новым участникам нужно всегда только комментировать (кнопка **Comment**) пулреквесты. + + +Спасибо за обзор пулреквеста! Если вы новенький в проекте, рекомендуется попросить кого-нибудь оценить ваш обзор пулреквеста. Slack-канал `#sig-docs` — отличное место для этого. + +## Написание постов в блоге + +Любой может написать пост в блоге и отправить его на рассмотрение. Посты блога не должны носит коммерческий характер и должны отражать опыт, который может широко применён в сообществе Kubernetes. + +Чтобы заявить о посте вы можете отправить его, используя [форму блога Kubernetes](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform), либо же выполнить следующие действия. + +1. [Подпишите CLA](#sign-the-cla), если вы еще этого не сделали. +2. Изучите разметку Markdown у текущих постов блога в репозитории сайта. +3. Напишите свою статью в вашем любимом текстовом редакторе. +4. По ссылке из второго шага нажмите на кнопку **Create new file**. Скопируйте из своего редактора текст и вставьте в многострочное поле. Назовите файл так, чтобы он соответствовал предлагаемому заголовку статьи в блоге, но не указывайте дату в имени файла. Рецензенты блога будут работать с вами над окончательным именем файла и датой публикации записи. +5. Когда вы сохраните файл, начнётся описанный выше процесс принятия пулреквеста в GitHub. +6. Рецензент блога рассмотрит вашу статью и вместе с вами будет работать над ее улучшением. Когда запись в блоге будет одобрена, будет известна дата публикации вашей статьи. + +## Отправка примеров использования + +В примерах использования показывается, как организации используют Kubernetes для решения собственных реальных проблем. Они написаны в сотрудничестве с маркетинговой командой Kubernetes, которой занимается {{< glossary_tooltip text="CNCF" term_id="cncf" >}}. + +Ознакомьтесь с [существующими примерами использования](https://github.com/kubernetes/website/tree/master/content/en/case-studies). Воспользуйтесь [формой добавления нового примера использования Kubernetes](https://www.cncf.io/people/end-user-community/), чтобы поделиться своим опытом. + +{{% /capture %}} + +{{% capture whatsnext %}} + +Если вы хорошо поняли темы, затронутые в этом разделе, но хотите глубже взаимодействовать с командой документации Kubernetes, прочитайте [расширенное руководство по участию в документации](/docs/contribute/intermediate/). + +{{% /capture %}} diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md index f3bdc03e1f..f313808371 100644 --- a/content/zh/docs/concepts/architecture/cloud-controller.md +++ b/content/zh/docs/concepts/architecture/cloud-controller.md @@ -235,19 +235,19 @@ The Service controller is responsible for listening to service create, update, a The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM. --> -节点控制器包含 kubelet 中依赖于云的功能，在引入 CCM 之前，kubelet 负责使用特定于云的详细信息（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。 +节点控制器包含 kubelet 中云依赖的功能，在引入 CCM 之前，kubelet 负责使用特定于云平台的功能特性（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。 -在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。 +在这个新模型中，kubelet 初始化一个没有特定于云平台的功能特性的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用云的规格信息初始化节点后，才会清除这种污点，便得该节点可被调度。 -在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。 +在这个新模型中，kubelet 初始化一个没有特定于云平台的功能特性的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用云的规格信息初始化节点后，才会清除这种污点，便得该节点可被调度。 - -为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 - -与其他类型的控制器不同，它们是作为 `kube-controller-manager` 二进制文件的一部分运行的，而 Ingress 控制器不是随集群自动启动的。 -通过此页面可选择最适合您的集群的 ingress 控制器实现。 - -Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 和 - [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 - -{{% /capture %}} - -{{% capture body %}} - - -## 其他控制器 - -* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress - 控制器，有着来自 [Datawire](https://www.datawire.io/) [社区](https://www.getambassador.io/docs)或[商业](https://www.getambassador.io/pro/)的支持。 -* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护. -* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 ingress 控制器，它由 VMware 提供和支持。 -* Citrix 为其硬件（MPX），虚拟化（VPX）和 [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。 -* F5 Networks 为 [用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供[支持和维护](https://support.f5.com/csp/article/K86859508)。 -* [Gloo](https://gloo.solo.io) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。 -* [HAProxy Technologies](https://www.haproxy.com/) 为 [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/) 提供支持和运维服务。 -* 基于 [Istio](https://istio.io/) 的 ingress 控制器[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。 -* [Kong](https://konghq.com/) 为[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) 提供[社区](https://discuss.konghq.com/c/kubernetes)或[商业](https://konghq.com/kong-enterprise/)支持和维护。 -* [NGINX, Inc.](https://www.nginx.com/) 为[用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)提供支持和维护。 -* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP路由器和反向代理，用于服务组合，包括诸如Kubernetes Ingress之类的用例，被设计为用于构建自定义代理的库。 -* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器 - （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 - - -## 使用多个 Ingress 控制器 - -你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 -创建 ingress 时，应该使用适当的 -[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress -以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。 - -如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。 - -理想情况下，所有 ingress 控制器都应满足此规范，但各种 ingress 控制器的操作略有不同。 - -{{< note >}} - -确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 -{{< /note >}} - -{{% /capture %}} - -{{% capture whatsnext %}} - -* 了解更多关于 [Ingress](/docs/concepts/services-networking/ingress/)。 -* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。 -{{% /capture %}} +--- +title: Ingress 控制器 +content_template: templates/concept +weight: 40 +--- + + + +{{% capture overview %}} + + + +为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 + +与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。 +基于此页面，您可选择最适合您的集群的 ingress 控制器实现。 + +Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) +和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 + +{{% /capture %}} + +{{% capture body %}} + + +## 其他控制器 + + +* [AKS 应用程序网关 Ingress 控制器]使用 [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview)启用[AKS 集群](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) ingress。 +* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress + 控制器，有着来自[社区](https://www.getambassador.io/docs) 的支持和来自 [Datawire](https://www.datawire.io/) 的[商业](https://www.getambassador.io/pro/) 支持。 +* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护。 +* [AWS ALB Ingress 控制器](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)通过 [AWS 应用 Load Balancer](https://aws.amazon.com/elasticloadbalancing/) 启用 ingress。 +* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 ingress 控制器，它由 VMware 提供和支持。 +* Citrix 为其硬件（MPX），虚拟化（VPX）和 [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。 +* F5 Networks 为 [用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供[支持和维护](https://support.f5.com/csp/article/K86859508)。 +* [Gloo](https://gloo.solo.io) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。 +* [HAProxy Ingress](https://haproxy-ingress.github.io) 是 HAProxy 高度可定制的、由社区驱动的 Ingress 控制器。 +* [HAProxy Technologies](https://www.haproxy.com/) 为[用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress) 提供支持和维护。具体信息请参考[官方文档](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)。 +* 基于 [Istio](https://istio.io/) 的 ingress 控制器[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。 +* [Kong](https://konghq.com/) 为[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) 提供[社区](https://discuss.konghq.com/c/kubernetes)或[商业](https://konghq.com/kong-enterprise/)支持和维护。 +* [NGINX, Inc.](https://www.nginx.com/) 为[用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)提供支持和维护。 +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。 +* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器 + （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 + + +## 使用多个 Ingress 控制器 + + + +你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 +创建 ingress 时，应该使用适当的 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress +以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。 + +如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。 + +理想情况下，所有 ingress 控制器都应满足此规范，但各种 ingress 控制器的操作略有不同。 + + +{{< note >}} +确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 +{{< /note >}} + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 进一步了解 [Ingress](/docs/concepts/services-networking/ingress/)。 +* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。 +{{% /capture %}} diff --git a/content/zh/docs/concepts/storage/volume-pvc-datasource.md b/content/zh/docs/concepts/storage/volume-pvc-datasource.md index d39e7128eb..c740f56a5f 100644 --- a/content/zh/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/zh/docs/concepts/storage/volume-pvc-datasource.md @@ -121,6 +121,14 @@ spec: name: pvc-1 ``` + + +{{< note >}} +你必须为 `spec.resources.requests.storage` 指定一个值，并且你指定的值必须大于或等于源卷的值。 +{{< /note >}} + diff --git a/content/zh/docs/tutorials/clusters/apparmor.md b/content/zh/docs/tutorials/clusters/apparmor.md index 8bb34517f5..627a52ede9 100644 --- a/content/zh/docs/tutorials/clusters/apparmor.md +++ b/content/zh/docs/tutorials/clusters/apparmor.md @@ -424,7 +424,7 @@ Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载 * By copying the profiles to each node and loading them through SSH, as demonstrated in the [Example](#example). --> * 通过在每个节点上运行 Pod 的[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)确保加载了正确的配置文件。可以找到一个示例实现[这里](https://git.k8s.io/kubernetes/test/images/apparmor-loader)。 -* 在节点初始化时，使用节点初始化脚本(例如 Salt 、Ansible 等)或图像。 +* 在节点初始化时，使用节点初始化脚本(例如 Salt 、Ansible 等)或镜像。 * 通过将配置文件复制到每个节点并通过 SSH 加载它们，如[示例](#example)。 ## 创建 Deployment -Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) 是由一个或多个容器为了管理和联网的目的而绑定在一起构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。 +Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。 1. 使用 `kubectl create` 命令创建管理 Pod 的 Deployment。该 Pod 根据提供的 Docker 镜像运行 Container。 diff --git a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md index b661ea9601..2586d8600a 100644 --- a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md @@ -1527,7 +1527,7 @@ storage configuration, and provisioning method, to ensure that all storage is reclaimed. --> -你需要删除本教程中用到的 PersistentVolumes 的持久化存储媒体。基于你的环境、存储配置和提供方式，按照必须的步骤保证回收所有的存储。 +你需要删除本教程中用到的 PersistentVolumes 的持久化存储介质。基于你的环境、存储配置和提供方式，按照必须的步骤保证回收所有的存储。 {{% /capture %}} diff --git a/i18n/en.toml b/i18n/en.toml index b829bc87da..48c0c5f469 100644 --- a/i18n/en.toml +++ b/i18n/en.toml @@ -189,3 +189,6 @@ other = "Warning:" [whatsnext_heading] other = "What's next" + +[input_placeholder_email_address] +other = "email address" \ No newline at end of file diff --git a/i18n/zh.toml b/i18n/zh.toml index 41a6f0c045..c42cb6c230 100644 --- a/i18n/zh.toml +++ b/i18n/zh.toml @@ -186,3 +186,6 @@ other = "警告：" [whatsnext_heading] other = "接下来" + +[input_placeholder_email_address] +other = "电子邮件地址" \ No newline at end of file diff --git a/layouts/index.html b/layouts/index.html index d3fd401d78..955bd6a934 100644 --- a/layouts/index.html +++ b/layouts/index.html @@ -25,7 +25,7 @@

{{ T "main_kubeweekly_baseline" }}


- +
diff --git a/layouts/shortcodes/codenew.html b/layouts/shortcodes/codenew.html index 426baf3d7a..0b4a34e571 100644 --- a/layouts/shortcodes/codenew.html +++ b/layouts/shortcodes/codenew.html @@ -25,7 +25,7 @@ {{ with $ghlink }}{{ end }} {{ $file }} {{ if $ghlink }}{{ end }} - +