diff --git a/Makefile b/Makefile index 58babc3627..ea1c4797af 100644 --- a/Makefile +++ b/Makefile @@ -58,7 +58,7 @@ docker-serve: @echo -e "$(CCRED)**** The use of docker-serve is deprecated. Use container-serve instead. ****$(CCEND)" $(MAKE) container-serve -container-image: +container-image: ## Build a container image for the preview of the website $(CONTAINER_ENGINE) build . \ --network=host \ --tag $(CONTAINER_IMAGE) \ @@ -67,7 +67,7 @@ container-image: container-build: module-check $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" -container-serve: module-check +container-serve: module-check ## Boot the development server using container. Run `make container-image` before this. $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir test-examples: diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 61228e592e..978be7ca33 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -27,6 +27,7 @@ aliases: - kbarnard10 - kbhawkey - onlydole + - reylejano - savitharaghunathan - sftim - steveperry-53 @@ -136,6 +137,7 @@ aliases: - seokho-son - ysyukr - pjhwa + - yoonian sig-docs-leads: # Website chairs and tech leads - irvifa - jimangel diff --git a/README-uk.md b/README-uk.md index f437535353..2872b406d1 100644 --- a/README-uk.md +++ b/README-uk.md @@ -18,7 +18,8 @@ ```bash git clone https://github.com/kubernetes/website.git cd website -hugo server --buildFuture +git submodule update --init --recursive --depth 1 +make serve ``` @@ -82,4 +83,4 @@ hugo server --buildFuture ## Дякуємо! -Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію! \ No newline at end of file +Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію! diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md index 8cc45252ec..6314420c01 100644 --- a/content/en/docs/concepts/cluster-administration/certificates.md +++ b/content/en/docs/concepts/cluster-administration/certificates.md @@ -130,11 +130,11 @@ Finally, add the same parameters into the API server start parameters. Note that you may need to adapt the sample commands based on the hardware architecture and cfssl version you are using. - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl_1.4.1_linux_amd64 -o cfssl + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl chmod +x cfssl - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssljson_1.4.1_linux_amd64 -o cfssljson + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson chmod +x cfssljson - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl-certinfo_1.4.1_linux_amd64 -o cfssl-certinfo + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo chmod +x cfssl-certinfo 1. Create a directory to hold the artifacts and initialize cfssl: diff --git a/content/en/docs/concepts/cluster-administration/system-metrics.md b/content/en/docs/concepts/cluster-administration/system-metrics.md index bbfdf0cc0c..3c7e137ded 100644 --- a/content/en/docs/concepts/cluster-administration/system-metrics.md +++ b/content/en/docs/concepts/cluster-administration/system-metrics.md @@ -156,5 +156,4 @@ endpoint on the scheduler. You must use the `--show-hidden-metrics-for-version=1 ## {{% heading "whatsnext" %}} * Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics -* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) * Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index fbaf0c1a29..e0512f8b9b 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -24,6 +24,16 @@ a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image. Users can create Secrets and the system also creates some Secrets. +{{< caution >}} +Kubernetes Secrets are, by default, stored as unencrypted base64-encoded +strings. By default they can be retrieved - as plain text - by anyone with API +access, or anyone with access to Kubernetes' underlying data store, etcd. In +order to safely use Secrets, we recommend you (at a minimum): + +1. [Enable Encryption at Rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) for Secrets. +2. [Enable RBAC rules that restrict reading and writing the Secret](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod. +{{< /caution >}} + ## Overview of Secrets @@ -795,7 +805,6 @@ See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-contai Manually created secrets (for example, one containing a token for accessing a GitHub account) can be automatically attached to pods based on their service account. -See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset/) for a detailed explanation of that process. ## Details diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md index 3f04bfa009..25f7f43639 100644 --- a/content/en/docs/concepts/services-networking/ingress-controllers.md +++ b/content/en/docs/concepts/services-networking/ingress-controllers.md @@ -26,6 +26,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet * [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress controller. +* [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller. * [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) provides L4-L7 load-balancing using [VMware NSX Advanced Load Balancer](https://avinetworks.com/). * The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with Citrix Application Delivery Controller. @@ -42,7 +43,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet is an [Istio](https://istio.io/) based ingress controller. * The [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme) is an ingress controller driving [Kong Gateway](https://konghq.com/kong/). -* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) +* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/) works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy). * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy. * The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 58d9bb9a2d..368bf02fb1 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -134,7 +134,7 @@ For example: * You want to point your Service to a Service in a different {{< glossary_tooltip term_id="namespace" >}} or on another cluster. * You are migrating a workload to Kubernetes. While evaluating the approach, - you run only a proportion of your backends in Kubernetes. + you run only a portion of your backends in Kubernetes. In any of these scenarios you can define a Service _without_ a Pod selector. For example: @@ -238,7 +238,7 @@ There are a few reasons for using proxying for Services: ### User space proxy mode {#proxy-mode-userspace} -In this mode, kube-proxy watches the Kubernetes master for the addition and +In this mode, kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service it opens a port (randomly chosen) on the local node. Any connections to this "proxy port" are proxied to one of the Service's backend Pods (as reported via diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 5cf08f7ffc..971939d882 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -231,7 +231,7 @@ the following types of volumes: * Azure Disk * Portworx * FlexVolumes -* CSI +* {{< glossary_tooltip text="CSI" term_id="csi" >}} You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true. 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 8d01b1d20c..0cdcbf2f36 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -669,13 +669,6 @@ allowVolumeExpansion: true For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). -### PodPreset {#podpreset} - -This admission controller injects a pod with the fields specified in a matching PodPreset. -See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and -[Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset) -for more information. - ### PodSecurityPolicy {#podsecuritypolicy} This admission controller acts on creation and modification of the pod and determines if it should be admitted diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 783f25621f..4bc2b86dd6 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -86,6 +86,7 @@ Because ClusterRoles are cluster-scoped, you can also use them to grant access t * cluster-scoped resources (like {{< glossary_tooltip text="nodes" term_id="node" >}}) * non-resource endpoints (like `/healthz`) * namespaced resources (like Pods), across all namespaces + For example: you can use a ClusterRole to allow a particular user to run `kubectl get pods --all-namespaces` diff --git a/content/en/docs/reference/glossary/podpreset.md b/content/en/docs/reference/glossary/podpreset.md deleted file mode 100755 index f63187ff71..0000000000 --- a/content/en/docs/reference/glossary/podpreset.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: PodPreset -id: podpreset -date: 2018-04-12 -full_link: -short_description: > - An API object that injects information such as secrets, volume mounts, and environment variables into pods at creation time. - -aka: -tags: -- operation ---- - An API object that injects information such as secrets, volume mounts, and environment variables into {{< glossary_tooltip text="Pods" term_id="pod" >}} at creation time. - - - -This object chooses the Pods to inject information into using standard selectors. This allows the podspec definitions to be nonspecific, decoupling the podspec from environment specific configuration. - diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 4c69e0b9b2..15bd4a131d 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -210,7 +210,7 @@ sudo yum update -y && sudo yum install -y containerd.io ```shell ## Configure containerd sudo mkdir -p /etc/containerd -sudo containerd config default > /etc/containerd/config.toml +sudo containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell @@ -268,13 +268,12 @@ Use the following commands to install CRI-O on your system: {{< note >}} The CRI-O major and minor versions must match the Kubernetes major and minor versions. -For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o). +For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes). {{< /note >}} Install and configure prerequisites: ```shell - # Create the .conf file to load the modules at bootup cat < Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version. -For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`. +For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`. You can pin your installation to a specific release. -To install version 1.18.3, set `VERSION=1.18:1.18.3`. +To install version 1.20.0, set `VERSION=1.20:1.20.0`.
Then run @@ -343,9 +342,9 @@ To install on the following operating systems, set the environment variable `OS`
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version. -For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`. +For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`. You can pin your installation to a specific release. -To install version 1.18.3, set `VERSION=1.18:1.18.3`. +To install version 1.20.0, set `VERSION=1.20:1.20.0`.
Then run @@ -377,9 +376,9 @@ To install on the following operating systems, set the environment variable `OS`
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version. -For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`. +For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`. You can pin your installation to a specific release. -To install version 1.18.3, set `VERSION=1.18:1.18.3`. +To install version 1.20.0, set `VERSION=1.20:1.20.0`.
Then run @@ -400,7 +399,7 @@ sudo zypper install cri-o {{% tab name="Fedora" %}} Set `$VERSION` to the CRI-O version that matches your Kubernetes version. -For instance, if you want to install CRI-O 1.18, `VERSION=1.18`. +For instance, if you want to install CRI-O 1.20, `VERSION=1.20`. You can find available versions with: ```shell @@ -424,10 +423,26 @@ sudo systemctl daemon-reload sudo systemctl start crio ``` -Refer to the [CRI-O installation guide](https://github.com/kubernetes-sigs/cri-o#getting-started) +Refer to the [CRI-O installation guide](https://github.com/cri-o/cri-o/blob/master/install.md) for more information. +#### cgroup driver + +CRI-O uses the systemd cgroup driver per default. To switch to the `cgroupfs` +cgroup driver, either edit `/etc/crio/crio.conf` or place a drop-in +configuration in `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example: + +```toml +[crio.runtime] +conmon_cgroup = "pod" +cgroup_manager = "cgroupfs" +``` + +Please also note the changed `conmon_cgroup`, which has to be set to the value +`pod` when using CRI-O with `cgroupfs`. It is generally necessary to keep the +cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O +in sync. ### Docker diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 9d0853b824..7c44f6e689 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -21,8 +21,8 @@ For information how to create a cluster with kubeadm once you have performed thi * One or more machines running one of: - Ubuntu 16.04+ - Debian 9+ - - CentOS 7 - - Red Hat Enterprise Linux (RHEL) 7 + - CentOS 7+ + - Red Hat Enterprise Linux (RHEL) 7+ - Fedora 25+ - HypriotOS v1.0.1+ - Flatcar Container Linux (tested with 2512.3.0) diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md index 0cd1ab597d..68ea7aef8a 100644 --- a/content/en/docs/setup/release/version-skew-policy.md +++ b/content/en/docs/setup/release/version-skew-policy.md @@ -140,6 +140,11 @@ Pre-requisites: Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**) +{{< note >}} +Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node. +In-place minor version `kubelet` upgrades are not supported. +{{}} + {{< warning >}} Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended: diff --git a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md index bd54c71cf6..9573a1a68d 100644 --- a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -1,22 +1,24 @@ --- -title: Connect a Front End to a Back End Using a Service +title: Connect a Frontend to a Backend Using Services content_type: tutorial weight: 70 --- -This task shows how to create a frontend and a backend -microservice. The backend microservice is a hello greeter. The -frontend and backend are connected using a Kubernetes -{{< glossary_tooltip term_id="service" >}} object. +This task shows how to create a _frontend_ and a _backend_ microservice. The backend +microservice is a hello greeter. The frontend exposes the backend using nginx and a +Kubernetes {{< glossary_tooltip term_id="service" >}} object. ## {{% heading "objectives" %}} -* Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object. -* Route traffic to the backend using a frontend. -* Use a Service object to connect the frontend application to the - backend application. +* Create and run a sample `hello` backend microservice using a + {{< glossary_tooltip term_id="deployment" >}} object. +* Use a Service object to send traffic to the backend microservice's multiple replicas. +* Create and run a `nginx` frontend microservice, also using a Deployment object. +* Configure the frontend microservice to send traffic to the backend microservice. +* Use a Service object of `type=LoadBalancer` to expose the frontend microservice + outside the cluster. ## {{% heading "prerequisites" %}} @@ -34,24 +36,24 @@ require a supported environment. If your environment does not support this, you The backend is a simple hello greeter microservice. Here is the configuration file for the backend Deployment: -{{< codenew file="service/access/hello.yaml" >}} +{{< codenew file="service/access/backend-deployment.yaml" >}} Create the backend Deployment: ```shell -kubectl apply -f https://k8s.io/examples/service/access/hello.yaml +kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml ``` View information about the backend Deployment: ```shell -kubectl describe deployment hello +kubectl describe deployment backend ``` The output is similar to this: ``` -Name: hello +Name: backend Namespace: default CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700 Labels: app=hello @@ -59,7 +61,7 @@ Labels: app=hello track=stable Annotations: deployment.kubernetes.io/revision=1 Selector: app=hello,tier=backend,track=stable -Replicas: 7 desired | 7 updated | 7 total | 7 available | 0 unavailable +Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 1 max unavailable, 1 max surge @@ -80,14 +82,14 @@ Conditions: Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: -NewReplicaSet: hello-3621623197 (7/7 replicas created) +NewReplicaSet: hello-3621623197 (3/3 replicas created) Events: ... ``` -## Creating the backend Service object +## Creating the `hello` Service object -The key to connecting a frontend to a backend is the backend +The key to sending requests from a frontend to a backend is the backend Service. A Service creates a persistent IP address and DNS name entry so that the backend microservice can always be reached. A Service uses {{< glossary_tooltip text="selectors" term_id="selector" >}} to find @@ -95,42 +97,51 @@ the Pods that it routes traffic to. First, explore the Service configuration file: -{{< codenew file="service/access/hello-service.yaml" >}} +{{< codenew file="service/access/backend-service.yaml" >}} -In the configuration file, you can see that the Service routes traffic to Pods -that have the labels `app: hello` and `tier: backend`. +In the configuration file, you can see that the Service, named `hello` routes +traffic to Pods that have the labels `app: hello` and `tier: backend`. -Create the `hello` Service: +Create the backend Service: ```shell -kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml +kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml ``` -At this point, you have a backend Deployment running, and you have a -Service that can route traffic to it. +At this point, you have a `backend` Deployment running three replicas of your `hello` +application, and you have a Service that can route traffic to them. However, this +service is neither available nor resolvable outside the cluster. ## Creating the frontend -Now that you have your backend, you can create a frontend that connects to the backend. -The frontend connects to the backend worker Pods by using the DNS name -given to the backend Service. The DNS name is "hello", which is the value -of the `name` field in the preceding Service configuration file. +Now that you have your backend running, you can create a frontend that is accessible +outside the cluster, and connects to the backend by proxying requests to it. -The Pods in the frontend Deployment run an nginx image that is configured -to find the hello backend Service. Here is the nginx configuration file: +The frontend sends requests to the backend worker Pods by using the DNS name +given to the backend Service. The DNS name is `hello`, which is the value +of the `name` field in the `examples/service/access/backend-service.yaml` +configuration file. -{{< codenew file="service/access/frontend.conf" >}} +The Pods in the frontend Deployment run a nginx image that is configured +to proxy requests to the `hello` backend Service. Here is the nginx configuration file: -Similar to the backend, the frontend has a Deployment and a Service. The -configuration for the Service has `type: LoadBalancer`, which means that -the Service uses the default load balancer of your cloud provider. +{{< codenew file="service/access/frontend-nginx.conf" >}} -{{< codenew file="service/access/frontend.yaml" >}} +Similar to the backend, the frontend has a Deployment and a Service. An important +difference to notice between the backend and frontend services, is that the +configuration for the frontend Service has `type: LoadBalancer`, which means that +the Service uses a load balancer provisioned by your cloud provider and will be +accessible from outside the cluster. + +{{< codenew file="service/access/frontend-service.yaml" >}} + +{{< codenew file="service/access/frontend-deployment.yaml" >}} Create the frontend Deployment and Service: ```shell -kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml +kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml +kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml ``` The output verifies that both resources were created: @@ -178,7 +189,7 @@ cluster. ## Send traffic through the frontend -The frontend and backends are now connected. You can hit the endpoint +The frontend and backend are now connected. You can hit the endpoint by using the curl command on the external IP of your frontend Service. ```shell @@ -196,17 +207,17 @@ The output shows the message generated by the backend: To delete the Services, enter this command: ```shell -kubectl delete services frontend hello +kubectl delete services frontend backend ``` To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command: ```shell -kubectl delete deployment frontend hello +kubectl delete deployment frontend backend ``` ## {{% heading "whatsnext" %}} * Learn more about [Services](/docs/concepts/services-networking/service/) * Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) - +* Learn more about [DNS for Service and Pods](/docs/concepts/services-networking/dns-pod-service/) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index f69859eb2d..de9ab8181c 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -314,7 +314,18 @@ CustomResourceDefinitions store validated resource data in the cluster's persist {{< note >}} CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`. -For migrated CustomResourceDefinitions where `spec.preserveUnknownFields` is set, pruning is _not_ enabled and you can store arbitrary data. For best compatibility, you should update your custom resources to meet an OpenAPI schema, and you should set `spec.preserveUnknownFields` to true for the CustomResourceDefinition itself. +For legacy CustomResourceDefinition objects created as +`apiextensions.k8s.io/v1beta1` with `spec.preserveUnknownFields` set to +`true`, the following is also true: + +* Pruning is not enabled. +* You can store arbitrary data. + +For compatibility with `apiextensions.k8s.io/v1`, update your custom +resource definitions to: + +1. Use a structural OpenAPI schema. +2. Set `spec.preserveUnknownFields` to `false`. {{< /note >}} If you save the following YAML to `my-crontab.yaml`: diff --git a/content/en/docs/tasks/inject-data-application/podpreset.md b/content/en/docs/tasks/inject-data-application/podpreset.md deleted file mode 100644 index 91c3c7beb6..0000000000 --- a/content/en/docs/tasks/inject-data-application/podpreset.md +++ /dev/null @@ -1,323 +0,0 @@ ---- -reviewers: -- jessfraz -title: Inject Information into Pods Using a PodPreset -min-kubernetes-server-version: v1.6 -content_type: task -weight: 60 ---- - - - -{{< feature-state for_k8s_version="v1.6" state="alpha" >}} - -This page shows how to use PodPreset objects to inject information like {{< glossary_tooltip text="Secrets" term_id="secret" >}}, volume mounts, and {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} into Pods at creation time. - - - -## {{% heading "prerequisites" %}} - - -You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](https://minikube.sigs.k8s.io/docs/). -Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster. - - - - - - -## Use Pod presets to inject environment variables and volumes - -In this step, you create a preset that has a volume mount and one environment variable. -Here is the manifest for the PodPreset: - -{{< codenew file="podpreset/preset.yaml" >}} - -The name of a PodPreset object must be a valid -[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). - -In the manifest, you can see that the preset has an environment variable definition called `DB_PORT` -and a volume mount definition called `cache-volume` which is mounted under `/cache`. The {{< glossary_tooltip text="selector" term_id="selector" >}} specifies that -the preset will act upon any Pod that is labeled `role:frontend`. - -Create the PodPreset: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml -``` - -Verify that the PodPreset has been created: - -```shell -kubectl get podpreset -``` -``` -NAME CREATED AT -allow-database 2020-01-24T08:54:29Z -``` - -This manifest defines a Pod labelled `role: frontend` (matching the PodPreset's selector): - -{{< codenew file="podpreset/pod.yaml" >}} - -Create the Pod: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/pod.yaml -``` - -Verify that the Pod is running: - -```shell -kubectl get pods -``` - -The output shows that the Pod is running: - -``` -NAME READY STATUS RESTARTS AGE -website 1/1 Running 0 4m -``` - -View the Pod spec altered by the admission controller in order to see the effects of the preset -having been applied: - -```shell -kubectl get pod website -o yaml -``` - -{{< codenew file="podpreset/merged.yaml" >}} - -The `DB_PORT` environment variable, the `volumeMount` and the `podpreset.admission.kubernetes.io` annotation -of the Pod verify that the preset has been applied. - -## Pod spec with ConfigMap example - -This is an example to show how a Pod spec is modified by a Pod preset -that references a ConfigMap containing environment variables. - -Here is the manifest containing the definition of the ConfigMap: - -{{< codenew file="podpreset/configmap.yaml" >}} - -Create the ConfigMap: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/configmap.yaml -``` - -Here is a PodPreset manifest referencing that ConfigMap: - -{{< codenew file="podpreset/allow-db.yaml" >}} - -Create the preset that references the ConfigMap: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/allow-db.yaml -``` - -The following manifest defines a Pod matching the PodPreset for this example: - -{{< codenew file="podpreset/pod.yaml" >}} - -Create the Pod: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/pod.yaml -``` - -View the Pod spec altered by the admission controller in order to see the effects of the preset -having been applied: - -```shell -kubectl get pod website -o yaml -``` - -{{< codenew file="podpreset/allow-db-merged.yaml" >}} - -The `DB_PORT` environment variable and the `podpreset.admission.kubernetes.io` annotation of the Pod -verify that the preset has been applied. - -## ReplicaSet with Pod spec example - -This is an example to show that only Pod specs are modified by Pod presets. Other workload types -like ReplicaSets or Deployments are unaffected. - -Here is the manifest for the PodPreset for this example: - -{{< codenew file="podpreset/preset.yaml" >}} - -Create the preset: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml -``` - -This manifest defines a ReplicaSet that manages three application Pods: - -{{< codenew file="podpreset/replicaset.yaml" >}} - -Create the ReplicaSet: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/replicaset.yaml -``` - -Verify that the Pods created by the ReplicaSet are running: - -```shell -kubectl get pods -``` - -The output shows that the Pods are running: - -``` -NAME READY STATUS RESTARTS AGE -frontend-2l94q 1/1 Running 0 2m18s -frontend-6vdgn 1/1 Running 0 2m18s -frontend-jzt4p 1/1 Running 0 2m18s -``` - -View the `spec` of the ReplicaSet: - -```shell -kubectl get replicasets frontend -o yaml -``` - -{{< note >}} -The ReplicaSet object's `spec` was not changed, nor does the ReplicaSet contain a -`podpreset.admission.kubernetes.io` annotation. This is because a PodPreset only -applies to Pod objects. - -To see the effects of the preset having been applied, you need to look at individual Pods. -{{< /note >}} - -The command to view the specs of the affected Pods is: - -```shell -kubectl get pod --selector=role=frontend -o yaml -``` - -{{< codenew file="podpreset/replicaset-merged.yaml" >}} - -Again the `podpreset.admission.kubernetes.io` annotation of the Pods -verifies that the preset has been applied. - -## Multiple Pod presets example - -This is an example to show how a Pod spec is modified by multiple Pod presets. - - -Here is the manifest for the first PodPreset: - -{{< codenew file="podpreset/preset.yaml" >}} - -Create the first PodPreset for this example: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml -``` - -Here is the manifest for the second PodPreset: - -{{< codenew file="podpreset/proxy.yaml" >}} - -Create the second preset: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/proxy.yaml -``` - -Here's a manifest containing the definition of an applicable Pod (matched by two PodPresets): - -{{< codenew file="podpreset/pod.yaml" >}} - -Create the Pod: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/pod.yaml -``` - -View the Pod spec altered by the admission controller in order to see the effects of both presets -having been applied: - -```shell -kubectl get pod website -o yaml -``` - -{{< codenew file="podpreset/multi-merged.yaml" >}} - -The `DB_PORT` environment variable, the `proxy-volume` VolumeMount and the two `podpreset.admission.kubernetes.io` -annotations of the Pod verify that both presets have been applied. - -## Conflict example - -This is an example to show how a Pod spec is not modified by a Pod preset when there is a conflict. -The conflict in this example consists of a `VolumeMount` in the PodPreset conflicting with a Pod that defines the same `mountPath`. - -Here is the manifest for the PodPreset: - -{{< codenew file="podpreset/conflict-preset.yaml" >}} - -Note the `mountPath` value of `/cache`. - -Create the preset: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/conflict-preset.yaml -``` - -Here is the manifest for the Pod: - -{{< codenew file="podpreset/conflict-pod.yaml" >}} - -Note the volumeMount element with the same path as in the PodPreset. - -Create the Pod: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/conflict-pod.yaml -``` - -View the Pod spec: - -```shell -kubectl get pod website -o yaml -``` - -{{< codenew file="podpreset/conflict-pod.yaml" >}} - -You can see there is no preset annotation (`podpreset.admission.kubernetes.io`). Seeing no annotation tells you that no preset has not been applied to the Pod. - -However, the -[PodPreset admission controller](/docs/reference/access-authn-authz/admission-controllers/#podpreset) -logs a warning containing details of the conflict. -You can view the warning using `kubectl`: - -```shell -kubectl -n kube-system logs -l=component=kube-apiserver -``` - -The output should look similar to: - -``` -W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache: -v1.VolumeMount{Name:"other-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil), SubPathExpr:""} -does not match -core.VolumeMount{Name:"cache-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*core.MountPropagationMode)(nil), SubPathExpr:""} - in container -``` - -Note the conflict message on the path for the VolumeMount. - -## Deleting a PodPreset - -Once you don't need a PodPreset anymore, you can delete it with `kubectl`: - -```shell -kubectl delete podpreset allow-database -``` -The output shows that the PodPreset was deleted: -``` -podpreset "allow-database" deleted -``` diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md index d655d39be9..c1722f694a 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -392,8 +392,8 @@ spec: containers: - name: my-nginx resources: - limits: - memory: 512Mi + limits: + memory: 512Mi EOF cat <./kustomization.yaml @@ -424,11 +424,12 @@ spec: spec: containers: - image: nginx - limits: - memory: 512Mi name: my-nginx ports: - containerPort: 80 + resources: + limits: + memory: 512Mi ``` Not all Resources or fields support strategic merge patches. To support modifying arbitrary fields in arbitrary Resources, diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md index 62e5cfc9cf..6ea02a06af 100644 --- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -60,7 +60,7 @@ This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https:// ## Download and install CFSSL The cfssl tools used in this example can be downloaded at -[https://pkg.cfssl.org/](https://pkg.cfssl.org/). +[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases). ## Create a Certificate Signing Request diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md index 5bfebd226b..54f1e7e123 100644 --- a/content/en/docs/tasks/tools/install-kubectl.md +++ b/content/en/docs/tasks/tools/install-kubectl.md @@ -32,34 +32,73 @@ Using the latest version of kubectl helps avoid unforeseen issues. 1. Download the latest release with the command: - ``` - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" - ``` + ```bash + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" + ``` - To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version. + {{< note >}} +To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. - For example, to download version {{< param "fullversion" >}} on Linux, type: - - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl - ``` +For example, to download version {{< param "fullversion" >}} on Linux, type: -2. Make the kubectl binary executable. + ```bash + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl + ``` + {{< /note >}} - ``` - chmod +x ./kubectl - ``` +1. Validate the binary (optional) -3. Move the binary in to your PATH. + Download the kubectl checksum file: - ``` - sudo mv ./kubectl /usr/local/bin/kubectl - ``` -4. Test to ensure the version you installed is up-to-date: + ```bash + curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256" + ``` - ``` - kubectl version --client - ``` + Validate the kubectl binary against the checksum file: + + ```bash + echo "$(}} + Download the same version of the binary and checksum. + {{< /note >}} + +1. Install kubectl + + ```bash + sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl + ``` + + {{< note >}} + If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory: + + ```bash + mkdir -p ~/.local/bin/kubectl + mv ./kubectl ~/.local/bin/kubectl + # and then add ~/.local/bin/kubectl to $PATH + ``` + + {{< /note >}} + +1. Test to ensure the version you installed is up-to-date: + + ```bash + kubectl version --client + ``` ### Install using native package management @@ -120,30 +159,65 @@ kubectl version --client 1. Download the latest release: ```bash - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" ``` - To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version. + {{< note >}} + To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. For example, to download version {{< param "fullversion" >}} on macOS, type: ```bash - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` - Make the kubectl binary executable. + {{< /note >}} + +1. Validate the binary (optional) + + Download the kubectl checksum file: + + ```bash + curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" + ``` + + Validate the kubectl binary against the checksum file: + + ```bash + echo "$(}} + Download the same version of the binary and checksum. + {{< /note >}} + +1. Make the kubectl binary executable. ```bash chmod +x ./kubectl ``` -3. Move the binary in to your PATH. +1. Move the kubectl binary to a file location on your system `PATH`. ```bash - sudo mv ./kubectl /usr/local/bin/kubectl + sudo mv ./kubectl /usr/local/bin/kubectl && \ + sudo chown root: /usr/local/bin/kubectl ``` -4. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```bash kubectl version --client @@ -165,7 +239,7 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you brew install kubernetes-cli ``` -2. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```bash kubectl version --client @@ -182,7 +256,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, sudo port install kubectl ``` -2. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```bash kubectl version --client @@ -192,47 +266,72 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, ### Install kubectl binary with curl on Windows -1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). +1. Download the [latest release {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). Or if you have `curl` installed, use this command: - ```bash - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ```powershell + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe ``` - To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt). + {{< note >}} + To find out the latest stable version (for example, for scripting), take a look at [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt). + {{< /note >}} -2. Add the binary in to your PATH. +1. Validate the binary (optional) -3. Test to ensure the version of `kubectl` is the same as downloaded: + Download the kubectl checksum file: - ```bash + ```powershell + curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256 + ``` + + Validate the kubectl binary against the checksum file: + + - Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded: + + ```cmd + CertUtil -hashfile kubectl.exe SHA256 + type kubectl.exe.sha256 + ``` + + - Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result: + + ```powershell + $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256) + ``` + +1. Add the binary in to your `PATH`. + +1. Test to ensure the version of `kubectl` is the same as downloaded: + + ```cmd kubectl version --client ``` {{< note >}} -[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH. -If you have installed Docker Desktop before, you may need to place your PATH entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`. +[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to `PATH`. +If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`. {{< /note >}} -### Install with Powershell from PSGallery +### Install with PowerShell from PSGallery -If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with Powershell. +If you are on Windows and using the [PowerShell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with PowerShell. 1. Run the installation commands (making sure to specify a `DownloadLocation`): ```powershell Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force install-kubectl.ps1 [-DownloadLocation ] - ``` + ``` {{< note >}} - If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory. + If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's `temp` Directory. {{< /note >}} The installer creates `$HOME/.kube` and instructs it to create a config file. -2. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```powershell kubectl version --client @@ -260,32 +359,32 @@ Updating the installation is performed by rerunning the two commands listed in s {{< /tabs >}} -2. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```powershell kubectl version --client ``` -3. Navigate to your home directory: +1. Navigate to your home directory: ```powershell # If you're using cmd.exe, run: cd %USERPROFILE% cd ~ ``` -4. Create the `.kube` directory: +1. Create the `.kube` directory: ```powershell mkdir .kube ``` -5. Change to the `.kube` directory you just created: +1. Change to the `.kube` directory you just created: ```powershell cd .kube ``` -6. Configure kubectl to use a remote Kubernetes cluster: +1. Configure kubectl to use a remote Kubernetes cluster: ```powershell New-Item config -type file @@ -301,13 +400,13 @@ You can install kubectl as part of the Google Cloud SDK. 1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/). -2. Run the `kubectl` installation command: +1. Run the `kubectl` installation command: ```shell gcloud components install kubectl ``` -3. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```shell kubectl version --client @@ -385,11 +484,13 @@ You now need to ensure that the kubectl completion script gets sourced in all yo ```bash echo 'source <(kubectl completion bash)' >>~/.bashrc ``` + - Add the completion script to the `/etc/bash_completion.d` directory: ```bash kubectl completion bash >/etc/bash_completion.d/kubectl ``` + If you have an alias for kubectl, you can extend shell completion to work with that alias: ```bash @@ -470,7 +571,6 @@ You now have to ensure that the kubectl completion script gets sourced in all yo ```bash echo 'source <(kubectl completion bash)' >>~/.bash_profile - ``` - Add the completion script to the `/usr/local/etc/bash_completion.d` directory: diff --git a/content/en/examples/examples_test.go b/content/en/examples/examples_test.go index d653d8303e..012a2acaa7 100644 --- a/content/en/examples/examples_test.go +++ b/content/en/examples/examples_test.go @@ -32,7 +32,6 @@ import ( "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/validation/field" "k8s.io/apimachinery/pkg/util/yaml" - // "k8s.io/apiserver/pkg/util/feature" "k8s.io/kubernetes/pkg/api/legacyscheme" "k8s.io/kubernetes/pkg/apis/apps" @@ -56,9 +55,6 @@ import ( "k8s.io/kubernetes/pkg/apis/rbac" rbac_validation "k8s.io/kubernetes/pkg/apis/rbac/validation" - "k8s.io/kubernetes/pkg/apis/settings" - settings_validation "k8s.io/kubernetes/pkg/apis/settings/validation" - "k8s.io/kubernetes/pkg/apis/storage" storage_validation "k8s.io/kubernetes/pkg/apis/storage/validation" @@ -73,7 +69,6 @@ import ( _ "k8s.io/kubernetes/pkg/apis/networking/install" _ "k8s.io/kubernetes/pkg/apis/policy/install" _ "k8s.io/kubernetes/pkg/apis/rbac/install" - _ "k8s.io/kubernetes/pkg/apis/settings/install" _ "k8s.io/kubernetes/pkg/apis/storage/install" ) @@ -111,7 +106,6 @@ func initGroups() { networking.GroupName, policy.GroupName, rbac.GroupName, - settings.GroupName, storage.GroupName, } @@ -296,11 +290,6 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { case *rbac.ClusterRoleBinding: // clusterolebinding does not accept namespace errors = rbac_validation.ValidateClusterRoleBinding(t) - case *settings.PodPreset: - if t.Namespace == "" { - t.Namespace = api.NamespaceDefault - } - errors = settings_validation.ValidatePodPreset(t) case *storage.StorageClass: // storageclass does not accept namespace errors = storage_validation.ValidateStorageClass(t) @@ -518,20 +507,6 @@ func TestExampleObjectSchemas(t *testing.T) { "node-problem-detector-configmap": {&apps.DaemonSet{}}, "termination": {&api.Pod{}}, }, - "podpreset": { - "allow-db": {&settings.PodPreset{}}, - "allow-db-merged": {&api.Pod{}}, - "configmap": {&api.ConfigMap{}}, - "conflict-pod": {&api.Pod{}}, - "conflict-preset": {&settings.PodPreset{}}, - "merged": {&api.Pod{}}, - "multi-merged": {&api.Pod{}}, - "pod": {&api.Pod{}}, - "preset": {&settings.PodPreset{}}, - "proxy": {&settings.PodPreset{}}, - "replicaset-merged": {&api.Pod{}}, - "replicaset": {&apps.ReplicaSet{}}, - }, "pods": { "commands": {&api.Pod{}}, "init-containers": {&api.Pod{}}, diff --git a/content/en/examples/podpreset/allow-db-merged.yaml b/content/en/examples/podpreset/allow-db-merged.yaml deleted file mode 100644 index 7f52cc1fa4..0000000000 --- a/content/en/examples/podpreset/allow-db-merged.yaml +++ /dev/null @@ -1,31 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend - annotations: - podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version" -spec: - containers: - - name: website - image: nginx - volumeMounts: - - mountPath: /cache - name: cache-volume - ports: - - containerPort: 80 - env: - - name: DB_PORT - value: "6379" - - name: duplicate_key - value: FROM_ENV - - name: expansion - value: $(REPLACE_ME) - envFrom: - - configMapRef: - name: etcd-env-config - volumes: - - name: cache-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/allow-db.yaml b/content/en/examples/podpreset/allow-db.yaml deleted file mode 100644 index 2c511e650d..0000000000 --- a/content/en/examples/podpreset/allow-db.yaml +++ /dev/null @@ -1,24 +0,0 @@ -apiVersion: settings.k8s.io/v1alpha1 -kind: PodPreset -metadata: - name: allow-database -spec: - selector: - matchLabels: - role: frontend - env: - - name: DB_PORT - value: "6379" - - name: duplicate_key - value: FROM_ENV - - name: expansion - value: $(REPLACE_ME) - envFrom: - - configMapRef: - name: etcd-env-config - volumeMounts: - - mountPath: /cache - name: cache-volume - volumes: - - name: cache-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/configmap.yaml b/content/en/examples/podpreset/configmap.yaml deleted file mode 100644 index 806a880bff..0000000000 --- a/content/en/examples/podpreset/configmap.yaml +++ /dev/null @@ -1,14 +0,0 @@ -apiVersion: v1 -kind: ConfigMap -metadata: - name: etcd-env-config -data: - number_of_members: "1" - initial_cluster_state: new - initial_cluster_token: DUMMY_ETCD_INITIAL_CLUSTER_TOKEN - discovery_token: DUMMY_ETCD_DISCOVERY_TOKEN - discovery_url: http://etcd_discovery:2379 - etcdctl_peers: http://etcd:2379 - duplicate_key: FROM_CONFIG_MAP - REPLACE_ME: "a value" - diff --git a/content/en/examples/podpreset/conflict-pod.yaml b/content/en/examples/podpreset/conflict-pod.yaml deleted file mode 100644 index 6949f7e162..0000000000 --- a/content/en/examples/podpreset/conflict-pod.yaml +++ /dev/null @@ -1,19 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend -spec: - containers: - - name: website - image: nginx - volumeMounts: - - mountPath: /cache - name: cache-volume - ports: - - containerPort: 80 - volumes: - - name: cache-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/conflict-preset.yaml b/content/en/examples/podpreset/conflict-preset.yaml deleted file mode 100644 index a2ad96c48a..0000000000 --- a/content/en/examples/podpreset/conflict-preset.yaml +++ /dev/null @@ -1,18 +0,0 @@ -apiVersion: settings.k8s.io/v1alpha1 -kind: PodPreset -metadata: - name: allow-database -spec: - selector: - matchLabels: - role: frontend - env: - - name: DB_PORT - value: "6379" - volumeMounts: - - mountPath: /cache - name: other-volume - volumes: - - name: other-volume - emptyDir: {} - diff --git a/content/en/examples/podpreset/merged.yaml b/content/en/examples/podpreset/merged.yaml deleted file mode 100644 index 97c022c86c..0000000000 --- a/content/en/examples/podpreset/merged.yaml +++ /dev/null @@ -1,25 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend - annotations: - podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version" -spec: - containers: - - name: website - image: nginx - volumeMounts: - - mountPath: /cache - name: cache-volume - ports: - - containerPort: 80 - env: - - name: DB_PORT - value: "6379" - volumes: - - name: cache-volume - emptyDir: {} - diff --git a/content/en/examples/podpreset/multi-merged.yaml b/content/en/examples/podpreset/multi-merged.yaml deleted file mode 100644 index 7fcaae62e3..0000000000 --- a/content/en/examples/podpreset/multi-merged.yaml +++ /dev/null @@ -1,29 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend - annotations: - podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version" - podpreset.admission.kubernetes.io/podpreset-proxy: "resource version" -spec: - containers: - - name: website - image: nginx - volumeMounts: - - mountPath: /cache - name: cache-volume - - mountPath: /etc/proxy/configs - name: proxy-volume - ports: - - containerPort: 80 - env: - - name: DB_PORT - value: "6379" - volumes: - - name: cache-volume - emptyDir: {} - - name: proxy-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/pod.yaml b/content/en/examples/podpreset/pod.yaml deleted file mode 100644 index b6b4e60d6e..0000000000 --- a/content/en/examples/podpreset/pod.yaml +++ /dev/null @@ -1,14 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend -spec: - containers: - - name: website - image: nginx - ports: - - containerPort: 80 - diff --git a/content/en/examples/podpreset/preset.yaml b/content/en/examples/podpreset/preset.yaml deleted file mode 100644 index f300289c82..0000000000 --- a/content/en/examples/podpreset/preset.yaml +++ /dev/null @@ -1,17 +0,0 @@ -apiVersion: settings.k8s.io/v1alpha1 -kind: PodPreset -metadata: - name: allow-database -spec: - selector: - matchLabels: - role: frontend - env: - - name: DB_PORT - value: "6379" - volumeMounts: - - mountPath: /cache - name: cache-volume - volumes: - - name: cache-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/proxy.yaml b/content/en/examples/podpreset/proxy.yaml deleted file mode 100644 index d854475ac2..0000000000 --- a/content/en/examples/podpreset/proxy.yaml +++ /dev/null @@ -1,14 +0,0 @@ -apiVersion: settings.k8s.io/v1alpha1 -kind: PodPreset -metadata: - name: proxy -spec: - selector: - matchLabels: - role: frontend - volumeMounts: - - mountPath: /etc/proxy/configs - name: proxy-volume - volumes: - - name: proxy-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/replicaset-merged.yaml b/content/en/examples/podpreset/replicaset-merged.yaml deleted file mode 100644 index 95cf846ebc..0000000000 --- a/content/en/examples/podpreset/replicaset-merged.yaml +++ /dev/null @@ -1,31 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: frontend - labels: - app: guestbook - role: frontend - annotations: - podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version" -spec: - containers: - - name: php-redis - image: gcr.io/google_samples/gb-frontend:v3 - resources: - requests: - cpu: 100m - memory: 100Mi - volumeMounts: - - mountPath: /cache - name: cache-volume - env: - - name: GET_HOSTS_FROM - value: dns - - name: DB_PORT - value: "6379" - ports: - - containerPort: 80 - volumes: - - name: cache-volume - emptyDir: {} - diff --git a/content/en/examples/podpreset/replicaset.yaml b/content/en/examples/podpreset/replicaset.yaml deleted file mode 100644 index e9d49a9d1d..0000000000 --- a/content/en/examples/podpreset/replicaset.yaml +++ /dev/null @@ -1,29 +0,0 @@ -apiVersion: apps/v1 -kind: ReplicaSet -metadata: - name: frontend -spec: - replicas: 3 - selector: - matchLabels: - role: frontend - matchExpressions: - - {key: role, operator: In, values: [frontend]} - template: - metadata: - labels: - app: guestbook - role: frontend - spec: - containers: - - name: php-redis - image: gcr.io/google_samples/gb-frontend:v3 - resources: - requests: - cpu: 100m - memory: 100Mi - env: - - name: GET_HOSTS_FROM - value: dns - ports: - - containerPort: 80 diff --git a/content/en/examples/service/access/Dockerfile b/content/en/examples/service/access/Dockerfile index b7b09d492a..61c8ce2831 100644 --- a/content/en/examples/service/access/Dockerfile +++ b/content/en/examples/service/access/Dockerfile @@ -1,4 +1,4 @@ FROM nginx:1.17.3 RUN rm /etc/nginx/conf.d/default.conf -COPY frontend.conf /etc/nginx/conf.d +COPY frontend-nginx.conf /etc/nginx/conf.d diff --git a/content/en/examples/service/access/hello.yaml b/content/en/examples/service/access/backend-deployment.yaml similarity index 91% rename from content/en/examples/service/access/hello.yaml rename to content/en/examples/service/access/backend-deployment.yaml index 85dff18ee1..5c95e38a3b 100644 --- a/content/en/examples/service/access/hello.yaml +++ b/content/en/examples/service/access/backend-deployment.yaml @@ -1,14 +1,15 @@ +--- apiVersion: apps/v1 kind: Deployment metadata: - name: hello + name: backend spec: selector: matchLabels: app: hello tier: backend track: stable - replicas: 7 + replicas: 3 template: metadata: labels: @@ -22,3 +23,4 @@ spec: ports: - name: http containerPort: 80 +... \ No newline at end of file diff --git a/content/en/examples/service/access/hello-service.yaml b/content/en/examples/service/access/backend-service.yaml similarity index 95% rename from content/en/examples/service/access/hello-service.yaml rename to content/en/examples/service/access/backend-service.yaml index 71344ecb8b..9262d29bb8 100644 --- a/content/en/examples/service/access/hello-service.yaml +++ b/content/en/examples/service/access/backend-service.yaml @@ -1,3 +1,4 @@ +--- apiVersion: v1 kind: Service metadata: @@ -10,3 +11,4 @@ spec: - protocol: TCP port: 80 targetPort: http +... \ No newline at end of file diff --git a/content/en/examples/service/access/frontend-deployment.yaml b/content/en/examples/service/access/frontend-deployment.yaml new file mode 100644 index 0000000000..182b0e708e --- /dev/null +++ b/content/en/examples/service/access/frontend-deployment.yaml @@ -0,0 +1,27 @@ +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: frontend +spec: + selector: + matchLabels: + app: hello + tier: frontend + track: stable + replicas: 1 + template: + metadata: + labels: + app: hello + tier: frontend + track: stable + spec: + containers: + - name: nginx + image: "gcr.io/google-samples/hello-frontend:1.0" + lifecycle: + preStop: + exec: + command: ["/usr/sbin/nginx","-s","quit"] +... \ No newline at end of file diff --git a/content/en/examples/service/access/frontend-nginx.conf b/content/en/examples/service/access/frontend-nginx.conf new file mode 100644 index 0000000000..39a911a09a --- /dev/null +++ b/content/en/examples/service/access/frontend-nginx.conf @@ -0,0 +1,14 @@ +# The identifier Backend is internal to nginx, and used to name this specific upstream +upstream Backend { + # hello is the internal DNS name used by the backend Service inside Kubernetes + server hello; +} + +server { + listen 80; + + location / { + # The following statement will proxy traffic to the upstream named Backend + proxy_pass http://Backend; + } +} diff --git a/content/en/examples/service/access/frontend-service.yaml b/content/en/examples/service/access/frontend-service.yaml new file mode 100644 index 0000000000..898a5ed51b --- /dev/null +++ b/content/en/examples/service/access/frontend-service.yaml @@ -0,0 +1,15 @@ +--- +apiVersion: v1 +kind: Service +metadata: + name: frontend +spec: + selector: + app: hello + tier: frontend + ports: + - protocol: "TCP" + port: 80 + targetPort: 80 + type: LoadBalancer +... \ No newline at end of file diff --git a/content/en/examples/service/access/frontend.conf b/content/en/examples/service/access/frontend.conf deleted file mode 100644 index 9a1f5a0ed6..0000000000 --- a/content/en/examples/service/access/frontend.conf +++ /dev/null @@ -1,11 +0,0 @@ -upstream hello { - server hello; -} - -server { - listen 80; - - location / { - proxy_pass http://hello; - } -} diff --git a/content/en/examples/service/access/frontend.yaml b/content/en/examples/service/access/frontend.yaml deleted file mode 100644 index 9f5b6b757f..0000000000 --- a/content/en/examples/service/access/frontend.yaml +++ /dev/null @@ -1,39 +0,0 @@ -apiVersion: v1 -kind: Service -metadata: - name: frontend -spec: - selector: - app: hello - tier: frontend - ports: - - protocol: "TCP" - port: 80 - targetPort: 80 - type: LoadBalancer ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - name: frontend -spec: - selector: - matchLabels: - app: hello - tier: frontend - track: stable - replicas: 1 - template: - metadata: - labels: - app: hello - tier: frontend - track: stable - spec: - containers: - - name: nginx - image: "gcr.io/google-samples/hello-frontend:1.0" - lifecycle: - preStop: - exec: - command: ["/usr/sbin/nginx","-s","quit"] diff --git a/content/fr/examples/application/guestbook/frontend-deployment.yaml b/content/fr/examples/application/guestbook/frontend-deployment.yaml index 50d6e1f0d4..23d64be644 100644 --- a/content/fr/examples/application/guestbook/frontend-deployment.yaml +++ b/content/fr/examples/application/guestbook/frontend-deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: frontend diff --git a/content/fr/examples/application/guestbook/redis-master-deployment.yaml b/content/fr/examples/application/guestbook/redis-master-deployment.yaml index fc6f418c39..478216d1ac 100644 --- a/content/fr/examples/application/guestbook/redis-master-deployment.yaml +++ b/content/fr/examples/application/guestbook/redis-master-deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: redis-master diff --git a/content/fr/examples/application/guestbook/redis-slave-deployment.yaml b/content/fr/examples/application/guestbook/redis-slave-deployment.yaml index 7dcfb6c263..1a7b04386a 100644 --- a/content/fr/examples/application/guestbook/redis-slave-deployment.yaml +++ b/content/fr/examples/application/guestbook/redis-slave-deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: redis-slave diff --git a/content/id/docs/reference/glossary/kuantitas.md b/content/id/docs/reference/glossary/kuantitas.md deleted file mode 100644 index ddac5a5ded..0000000000 --- a/content/id/docs/reference/glossary/kuantitas.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Kuantitas -id: kuantitas -date: 2018-08-07 -full_link: -short_description: > - Representasi bilangan bulat dari bilangan kecil atau bilangan besar menggunakan sufiks SI. - -aka: -tags: -- core-object ---- - Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI. - - - -Kuantitas adalah representasi dari bilangan kecil atau besar menggunakan notasi -bilangan bulat kompak dengan sufiks SI. Bilangan pecahan direpresentasikan dengan satuan mili, -sedangkan bilangan besar direpresentasikan dengan satuan kilo, mega, atau giga. - -Misalnya, angka `1,5` direpresentasikan sebagai` 1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai` 1k`, dan `1000000` sebagai` 1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat -ditulis sebagai `2Ki`. - -Satuan desimal yang diterima (pangkat 10) adalah `m` (mili),` k` (kilo, -sengaja huruf kecil), `M` (mega),` G` (giga), `T` (tera),` P` (peta), -`E` (exa). - -Unit biner (pangkat-2) yang diterima adalah `Ki` (kibi),` Mi` (mebi), `Gi` (gibi),` Ti` (tebi), `Pi` (pebi),` Ei` (exbi). diff --git a/content/id/docs/reference/glossary/kube-controller-manager.md b/content/id/docs/reference/glossary/kube-controller-manager.md index 436927afc7..2d0d5d0d9a 100644 --- a/content/id/docs/reference/glossary/kube-controller-manager.md +++ b/content/id/docs/reference/glossary/kube-controller-manager.md @@ -4,16 +4,15 @@ id: kube-controller-manager date: 2019-04-21 full_link: /docs/reference/generated/kube-controller-manager/ short_description: > - Komponen di master yang menjalankan kontroler. + Komponen _control plane_ yang menjalankan pengontrol. aka: tags: - architecture - fundamental --- - Komponen di master yang menjalankan kontroler. +Komponen _control plane_ yang menjalankan pengontrol. -Secara logis, setiap kontroler adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kontroler-kontroler ini dikompilasi menjadi sebuah binary yang dijalankan sebagai satu proses. - +Secara logis, setiap pengontrol adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kesemuanya dikompilasi menjadi sebuah biner (_binary_) yang dijalankan sebagai satu proses. diff --git a/content/id/docs/reference/glossary/kube-proxy.md b/content/id/docs/reference/glossary/kube-proxy.md new file mode 100644 index 0000000000..e842c98386 --- /dev/null +++ b/content/id/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,20 @@ +--- +title: kube-proxy +id: kube-proxy +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-proxy/ +short_description: > + `kube-proxy` merupakan proksi jaringan yang berjalan pada setiap node di dalam klaster. + +aka: +tags: +- fundamental +- networking +--- +kube-proxy merupakan proksi jaringan yang berjalan pada setiap {{< glossary_tooltip term_id="node" >}} di dalam klastermu, yang mengimplementasikan bagian dari konsep {{< glossary_tooltip text="layanan" term_id="service">}} Kubernetes. + + + +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) mengelola aturan jaringan pada node. Aturan jaringan tersebut memungkinkan komunikasi jaringan ke Pod-mu melalui sesi jaringan dari dalam ataupun luar klaster. + +kube-proxy menggunakan lapisan pemfilteran paket sistem operasi jika ada dan tersedia. Jika tidak, maka kube-proxy akan meneruskan lalu lintas jaringan itu sendiri. diff --git a/content/id/docs/reference/glossary/kube-scheduler.md b/content/id/docs/reference/glossary/kube-scheduler.md index e1bf37a36b..f61e99a8b8 100644 --- a/content/id/docs/reference/glossary/kube-scheduler.md +++ b/content/id/docs/reference/glossary/kube-scheduler.md @@ -4,15 +4,14 @@ id: kube-scheduler date: 2019-04-21 full_link: /docs/reference/generated/kube-scheduler/ short_description: > - Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-assign ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan. + Komponen _control plane_ yang bertugas mengamati Pod baru yang belum ditempatkan di node manapun dan kemudian memilihkan node di mana Pod baru tersebut akan dijalankan. aka: tags: - architecture --- - Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-assign ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan. +Komponen _control plane_ yang bertugas mengamati {{< glossary_tooltip term_id="pod" >}} baru yang belum ditempatkan di node manapun dan kemudian memilihkan {{< glossary_tooltip term_id="node" >}} di mana Pod baru tersebut akan dijalankan. -Faktor-faktor yang diperhatikan dalam proses ini adalah kebutuhan resource secara individual dan kolektif, konstrain perangkat keras/perangkat lunak/peraturan, spesifikasi afinitas dan non-afinitas, lokalisasi data, interferensi inter-workload dan deadlines. - +Faktor-faktor yang dipertimbangkan untuk keputusan penjadwalan termasuk: kebutuhan sumber daya secara individual dan kolektif, batasan perangkat keras/perangkat lunak/peraturan, spesifikasi afinitas dan nonafinitas, lokalisasi data, interferensi antar beban kerja dan tenggat waktu. diff --git a/content/id/docs/reference/glossary/kubectl.md b/content/id/docs/reference/glossary/kubectl.md index 579a4003c2..059cd29b59 100644 --- a/content/id/docs/reference/glossary/kubectl.md +++ b/content/id/docs/reference/glossary/kubectl.md @@ -11,7 +11,7 @@ tags: - tool - fundamental --- -Sebuah utilitas baris perintah untuk berkomunikasi dengan suatu server {{< glossary_tooltip text="API Kubernetes" term_id="kubernetes-api" >}}. +Sebuah utilitas baris perintah untuk berkomunikasi dengan suatu server {{< glossary_tooltip term_id="kubernetes-api" >}}. diff --git a/content/id/docs/reference/glossary/kubelet.md b/content/id/docs/reference/glossary/kubelet.md index 10cc51ea07..ee0e239616 100644 --- a/content/id/docs/reference/glossary/kubelet.md +++ b/content/id/docs/reference/glossary/kubelet.md @@ -4,12 +4,11 @@ id: kubelet date: 2019-04-21 full_link: /docs/reference/generated/kubelet short_description: > - Agen yang dijalankan pada setiap node di klaster dan bertugas memastikan kontainer dijalankan di dalam pod. + Agen yang dijalankan pada setiap node di klaster yang bertugas untuk memastikan kontainer dijalankan di dalam Pod. aka: tags: - fundamental - core-object --- - Agen yang dijalankan pada setiap node di klaster dan bertugas memastikan kontainer dijalankan di dalam pod. - +Agen yang dijalankan pada setiap node di klaster yang bertugas untuk memastikan kontainer dijalankan di dalam Pod. diff --git a/content/id/docs/reference/glossary/quantity.md b/content/id/docs/reference/glossary/quantity.md new file mode 100644 index 0000000000..7369fc20dc --- /dev/null +++ b/content/id/docs/reference/glossary/quantity.md @@ -0,0 +1,22 @@ +--- +title: Kuantitas +id: quantity +date: 2018-08-07 +full_link: +short_description: > + Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI. +aka: +tags: +- core-object +--- +Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI. + + + +Kuantitas adalah representasi dari bilangan kecil atau besar menggunakan notasi bilangan bulat kompak dengan sufiks SI. Bilangan pecahan direpresentasikan dengan satuan mili, sedangkan bilangan besar direpresentasikan dengan satuan kilo, mega, atau giga. + +Misalnya, angka `1,5` direpresentasikan sebagai` 1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai `1k`, dan `1000000` sebagai `1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat ditulis sebagai `2Ki`. + +Satuan desimal yang diterima (pangkat 10) adalah `m` (mili), `k` (kilo, sengaja huruf kecil), `M` (mega), `G` (giga), `T` (tera), `P` (peta), `E` (exa). + +Unit biner (pangkat 2) yang diterima adalah `Ki` (kibi), `Mi` (mebi), `Gi` (gibi), `Ti` (tebi), `Pi` (pebi), `Ei` (exbi). diff --git a/content/id/docs/setup/production-environment/container-runtimes.md b/content/id/docs/setup/production-environment/container-runtimes.md index bca967593c..39db9c9ed3 100644 --- a/content/id/docs/setup/production-environment/container-runtimes.md +++ b/content/id/docs/setup/production-environment/container-runtimes.md @@ -359,7 +359,7 @@ apt-get update && apt-get install -y containerd.io ```shell # Mengonfigure containerd mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml +containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell @@ -391,7 +391,7 @@ yum update -y && yum install -y containerd.io ```shell ## Mengonfigurasi containerd mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml +containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell diff --git a/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index da873c4373..442e3178ec 100644 --- a/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -426,7 +426,7 @@ pengambilan metrik. Terakhir, kondisi terakhir, `ScalingLimited`, menunjukkan ba ## Lampiran: Kuantitas -Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="kuantitas" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti Anda mungkin melihat nilai metrik Anda berfluktuasi antara `1` dan` 1500m`, atau `1` dan` 1,5` ketika ditulis dalam notasi desimal. +Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="quantity" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti kamu mungkin melihat nilai metrik berfluktuasi antara `1` dan `1500m`, atau `1` dan` 1,5` ketika ditulis dalam notasi desimal. ## Lampiran: Skenario lain yang memungkinkan diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md index 26ce98ab50..9ae7c55067 100644 --- a/content/ja/docs/concepts/configuration/secret.md +++ b/content/ja/docs/concepts/configuration/secret.md @@ -457,7 +457,7 @@ Secretは直接Podが参照できるようにはされず、システムの別 PodのボリュームとしてSecretを使うには、 1. Secretを作成するか既存のものを使用します。複数のPodが同一のSecretを参照することができます。 -1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下をを書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。 +1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下を書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。 1. Secretを必要とするそれぞれのコンテナに`.spec.containers[].volumeMounts[]`を追加します。`.spec.containers[].volumeMounts[].readOnly = true`を指定して`.spec.containers[].volumeMounts[].mountPath`をSecretをマウントする未使用のディレクトリ名にします。 1. イメージやコマンドラインを変更し、プログラムがそのディレクトリを参照するようにします。連想配列`data`のキーは`mountPath`以下のファイル名になります。 diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 3f713636f3..14875c8229 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -105,19 +105,6 @@ APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。 -### 静的なパスワードファイル - -APIサーバーに`--basic-auth-file=SOMEFILE`オプションを渡すことで、Basic認証を有効にすることができます。現在のところ、Basic認証の認証情報は有効期限が無く、APIサーバーを再起動しない限りパスワードを変更することはできません。よりセキュアなモードをさらに使いやすくするための改良が完了するまでの間、現時点では利便性のためにBasic認証がサポートされていることに注意してください。 - -Basic認証ファイルは、トークン、ユーザー名、ユーザーIDの少なくとも3つの列を持つcsvファイルです。 -Kubernetesのバージョン1.6以降では、オプションとしてカンマ区切りのグループ名を含む4列目を指定することができます。複数のグループがある場合は、4列目の値をダブルクォート(")で囲む必要があります。以下の例を参照してください。 - -```conf -password,user,uid,"group1,group2,group3" -``` - -HTTPクライアントからBasic認証を利用する場合、APIサーバーは`Basic BASE64ENCODED(USER:PASSWORD)`の値を持つ`Authorization`ヘッダーを待ち受けます。 - ### サービスアカウントトークン サービスアカウントは、自動的に有効化される認証機能で、署名されたBearerトークンを使ってリクエストを検証します。このプラグインは、オプションとして2つのフラグを取ります。 diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index 372523091a..8629e2f102 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -351,7 +351,7 @@ apt-get update && apt-get install -y containerd.io ```shell # containerdの設定 mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml +containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell @@ -383,7 +383,7 @@ yum update -y && yum install -y containerd.io ```shell ## containerdの設定 mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml +containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell diff --git a/content/ko/community/static/cncf-code-of-conduct.md b/content/ko/community/static/cncf-code-of-conduct.md index 6e3c838fe8..804c5632fd 100644 --- a/content/ko/community/static/cncf-code-of-conduct.md +++ b/content/ko/community/static/cncf-code-of-conduct.md @@ -2,44 +2,44 @@ https://github.com/cncf/foundation/blob/master/code-of-conduct.md --> ## CNCF 커뮤니티 행동 강령 v1.0 -### 참여자 행동 강령 +### 기여자 행동 강령 -본 프로젝트의 기여자 및 유지 관리자로서, 환영하는 분위기의 공개 커뮤니티를 -육성하기 위하여, 저희는 이슈를 보고하고, 기술 요청을 작성하며, 문서를 업데이트하며, -pull 요청 또는 패치를 제출하고, 다른 활동에 참여하는 -모든 분들을 존중하겠다고 약속드립니다. +본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의 +커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트, +풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는 +모든 분들을 존중할 것을 약속합니다. -저희는 경험 수준, 성별, 성 정체성과 표현, 성적 지향, -장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, 또는 -국적에 상관 없이 모두가 괴롭힘 없는 환경에서 -본 프로젝트에 참여하도록 최선을 다하고 있습니다. +우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression), +성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, +또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에 +참여할 수 있도록 최선을 다하고 있습니다. -참여자에게 금지하는 행동의 예는 다음과 같습니다.: +참여자에게 금지하는 행위의 예시는 다음과 같습니다. -* 성적 언어 또는 이미지 사용 -* 개인적인 공격 -* 시비 걸기 또는 모욕/경멸적인 코멘트 -* 공적 및 사적 괴롭힘 -* 분명한 허락을 받지 않은 타인의 사적 정보 출판, - 예를 들어 물리적 또는 전자 주소 -* 다른 비윤리적 또는 비전문적인 행동 +- 성적인 언어 또는 이미지 사용 +- 인신 공격 +- 도발적이거나 모욕/경멸적인 코멘트 +- 공개적이거나 사적인 괴롭힘 +- 타인의 주소 및 전자주소와 같은 개인 정보의 + 동의 없는 공개 +- 기타 비윤리적이거나 비전문적인 행동 -프로젝트 유지 관리자는 본 행동 강령을 위반하는 코멘트, 협약, 강령, -위키 수정, 이슈와 다른 참여자를 제거, 수정, 삭제할 권한과 -책임을 가집니다. 본 행동 강령을 적용하여, 프로젝트 유지 관리자는 본 -프로젝트를 유지하는 모든 상황에 공정하고 일관적으로 이러한 원칙들을 -적용하기 위해 헌신해야 합니다. 프로젝트 유지 관리자는 -행동 강령이 프로젝트 팀에서 영구적으로 사라지도록 하거나 강요해서는 안됩니다. +프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit), +코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정, +거부할 수 있는 권한과 책임이 있습니다. 프로젝트 메인테이너는 프로젝트 관리의 +모든 관점에서 이러한 행동 강령 원칙을 공정하고 일관되게 적용할 것을 약속해야 합니다. +행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서 +영구적으로 제적될 수 있습니다. -본 행동 강령은 프로젝트 공간과 개인이 프로젝트 또는 -그 커뮤니티를 대표하는 공적 공간에 모두 적용됩니다. +본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트 +또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다. -Kubernetes에서의 폭력, 학대 또는 기타 허용되지 않는 행동 사례는 이메일 주소 를 통해 [Kubernetes 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)로 신고하실 수 있습니다. 다른 프로젝트는 CNCF 프로젝트 관리자 또는 저희 중재자인 Mishi Choudhary에게 이메일 으로 연락하십시오. +쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 으로 문의해 주시기 바랍니다. -본 행동강령은 참여자 Contributor Covenant (http://contributor-covenant.org)의 -버전 1.2.0을 적용하였으며, -해당 내용은 여기 http://contributor-covenant.org/version/1/2/0/에서 확인할 수 있습니다. +본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서 +제공하는 버전 1.2.0을 적용하였으며, 해당 내용은 +https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다. -### CNCF 커뮤니티 행동 강령 +### CNCF 이벤트 행동 강령 -CNCF 이벤트는 리눅스 재단의 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/) 을 따르며, 해당 내용은 이벤트 페이지에서 확인할 수 있습니다. 본 강령은 위 정책과 호환할 수 있도록 설계되었으며, 또한 사건에 따라 더 많은 세부 내용을 포함합니다. \ No newline at end of file +CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/)을 준수합니다. 이 행동 강령은 위의 정책과 호환되도록 설계되었으며, 사고 대응에 대한 세부 내용도 포함하고 있습니다. diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index 2fdaf7599c..36ece0d6d2 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -46,7 +46,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. 이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을 사용한다. -마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다. +마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다. ### API 서버에서 노드, 파드 및 서비스로의 통신 diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index 5ca2ce5aca..1442a5da01 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -60,7 +60,7 @@ no_list: true ### kubelet 보안 * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/) * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) + * [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) ## 선택적 클러스터 서비스 diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 228e0af585..95ea899cbb 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -1,4 +1,5 @@ --- + title: kubelet 가비지(Garbage) 수집 설정하기 content_type: concept weight: 70 @@ -6,7 +7,7 @@ weight: 70 -가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. +가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. 별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다. @@ -20,7 +21,7 @@ weight: 70 쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의 라이프사이클을 관리한다. -이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다: +이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다. `HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는 디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한 이미지들을 삭제한다. diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index b897a0e79a..03eb904ee3 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -1,18 +1,19 @@ --- title: 쿠버네티스 컨트롤 플레인에 대한 메트릭 + + + + content_type: concept weight: 60 -aliases: -- controller-metrics.md --- 시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다. -쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다. - - +쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다. +이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다. @@ -49,18 +50,20 @@ rules: ## 메트릭 라이프사이클 -알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제 +알파(Alpha) 메트릭 → 안정적인(Stable) 메트릭 → 사용 중단된(Deprecated) 메트릭 → 히든(Hidden) 메트릭 → 삭제된(Deleted) 메트릭 알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다. -안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다. +안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다. +* 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다. +* 안정적인 메트릭의 유형(type)은 수정되지 않는다. -* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다 -* 메트릭 유형은 수정되지 않는다 +사용 중단된 메트릭은 해당 메트릭이 결국 삭제된다는 것을 나타내지만, 아직은 사용 가능하다는 뜻이다. +이 메트릭은 어느 버전에서부터 사용 중단된 것인지를 표시하는 어노테이션을 포함한다. -사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다. +예를 들면, -사용 중단되기 전에는 아래와 같다. +* 사용 중단 이전에는 다음과 같다. ``` # HELP some_counter this counts things @@ -68,7 +71,7 @@ rules: some_counter 0 ``` -사용 중단된 이후에는 아래와 같다. +* 사용 중단 이후에는 다음과 같다. ``` # HELP some_counter (Deprecated since 1.15.0) this counts things @@ -76,9 +79,9 @@ some_counter 0 some_counter 0 ``` -메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다. +히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다. -메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다. +삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다. ## 히든 메트릭 표시 @@ -128,6 +131,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ``` + ### kube-scheduler 메트릭 {{< feature-state for_k8s_version="v1.20" state="alpha" >}} diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index fc67ab2f82..73fcf62b98 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -225,7 +225,6 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최 그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다. 캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다. - 컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접 모든 요청을 리디렉션할 수 있다. 따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의 @@ -262,12 +261,10 @@ data: immutable: true ``` -{{< note >}} 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나 `data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다. -{{< /note >}} ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 557fb50397..f120b0002d 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -349,7 +349,7 @@ data: 부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다. -- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. +- `token-id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. - `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 문자열. 선택 사항. diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 854147597b..026e0e007c 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -17,8 +17,8 @@ card: 최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 수 있도록 HTTP API를 제공한다. -쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예: -파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다. +쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예: +파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다. 대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/) 커맨드 라인 인터페이스 또는 API를 사용하는 diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index b67a524a7f..09f70af30c 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -58,14 +58,14 @@ metadata: ## 애플리케이션과 애플리케이션 인스턴스 -애플리케이션은 동일한 쿠버네티스 클러스터에, +애플리케이션은 동일한 쿠버네티스 클러스터에, 심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에 -워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다. +WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다. -애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. -예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, -애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 -`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 +애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. +예를 들어 WordPress는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, +애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 +`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다. ## 예시 @@ -169,4 +169,3 @@ metadata: ``` MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다. - diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index 0ea3f087e3..e3c67a4ff9 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -1,4 +1,7 @@ --- + + + title: 파드 시큐리티 폴리시 content_type: concept weight: 30 @@ -213,12 +216,17 @@ kubectl-user create -f- <}} 워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 -[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다. -쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}} +[_파드_](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다. +쿠버네티스에서 `Pod` 는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 집합을 나타낸다. -파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고 -해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서 -심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를 -최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다. +쿠버네티스 파드에는 [정의된 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)이 있다. +예를 들어, 일단 파드가 클러스터에서 실행되고 나서 +해당 파드가 동작 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에 +심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를 +최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 `Pod` 를 새로 생성해야 한다. -그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다. +그러나, 작업이 훨씬 쉽도록, 각 `Pod` 를 직접 관리할 필요는 없도록 만들었다. 대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다. 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이 실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를 구성한다. -이러한 워크로드 리소스에는 다음이 포함된다. +쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다. -* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 및 [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) - (레거시 리소스 {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체); -* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/); -* 스토리지 드라이버 또는 네트워크 플러그인과 같은 노드-로컬 기능을 제공하는 - 파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) -* 완료될 때까지 실행되는 작업에 대한 - [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및 - [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/) +* [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 및 [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) + (레거시 리소스 + {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체). + `Deployment` 는 `Deployment` 의 모든 `Pod` 가 필요 시 교체 또는 상호 교체 가능한 경우, + 클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다. +* [`StatefulSet`](/ko/docs/concepts/workloads/controllers/statefulset/)는 + 어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가 + 데이터를 지속적으로 기록하는 경우, 사용자는 `Pod` 와 + [`PersistentVolume`](/ko/docs/concepts/storage/persistent-volumes/)을 연계하는 `StatefulSet` 을 실행할 수 있다. + 전체적인 회복력 향상을 위해서, `StatefulSet` 의 `Pods` 에서 동작 중인 코드는 동일한 `StatefulSet` 의 + 다른 `Pods` 로 데이터를 복제할 수 있다. +* [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)은 노드-로컬 기능(node-local facilities)을 제공하는 `Pods` 를 정의한다. + 이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다. + 예를 들면, 네트워킹 지원 도구 또는 + {{< glossary_tooltip text="add-on" term_id="addons" >}} 등이 있다. + `DaemonSet` 의 명세에 맞는 노드를 클러스터에 추가할 때마다, + 컨트롤 플레인은 해당 신규 노드에 `DaemonSet` 을 위한 `Pod` 를 스케줄한다. +* [`Job`](/ko/docs/concepts/workloads/controllers/job/) 및 + [`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)은 + 실행 완료 후 중단되는 작업을 정의한다. `CronJobs` 이 스케줄에 따라 반복되는 반면, + 잡은 단 한 번의 작업을 나타낸다. -관련성을 찾을 수 있는 두 가지 지원 개념도 있다. -* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가 - 제거된 후 클러스터에서 오브젝트를 정리한다. -* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 - 완료된 이후 정의된 시간이 경과되면 잡을 제거한다. +더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드 +리소스도 찾을 수 있다. +[커스텀 리소스 데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)을 사용하면, +쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를 +추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 `Pods` 의 그룹을 실행하되 +_모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은), +사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다. ## {{% heading "whatsnext" %}} 각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다. -* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/) +* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/) * 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/) 또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행 -* [크론잡을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/) +* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/) + +코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는, +[구성](/ko/docs/concepts/configuration/)을 참고하길 바란다. + +다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는 +두 가지 개념이다. +* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가 + 제거된 후 클러스터에서 오브젝트를 정리한다. +* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는 + 잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다. 일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로 사용하거나, 웹 애플리케이션의 경우에만 [인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다. - -[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의 -메커니즘에 대해 알아볼 수도 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 19995d83ce..ed29659a7e 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -1,4 +1,8 @@ --- + + + + title: 크론잡 content_type: concept weight: 80 @@ -45,6 +49,36 @@ kube-controller-manager 컨테이너에 설정된 시간대는 ([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는 이 예시를 더 자세히 설명한다.) +### 크론 스케줄 문법 + +``` +# ┌───────────── 분 (0 - 59) +# │ ┌───────────── 시 (0 - 23) +# │ │ ┌───────────── 일 (1 - 31) +# │ │ │ ┌───────────── 월 (1 - 12) +# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지; +# │ │ │ │ │ 특정 시스템에서는 7도 일요일) +# │ │ │ │ │ +# │ │ │ │ │ +# * * * * * +``` + + +| 항목 | 설명 | 상응 표현 | +| ------------- | ------------- |------------- | +| @yearly (or @annually) | 매년 1월 1일 자정에 실행 | 0 0 1 1 * | +| @monthly | 매월 1일 자정에 실행 | 0 0 1 * * | +| @weekly | 매주 일요일 자정에 실행 | 0 0 * * 0 | +| @daily (or @midnight) | 매일 자정에 실행 | 0 0 * * * | +| @hourly | 매시 0분에 시작 | 0 * * * * | + + +예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다. + +`0 0 13 * 5` + +크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다. + ## 크론잡의 한계 {#cron-job-limitations} 크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는 diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 5c505a3286..0f04051ff1 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -1,4 +1,7 @@ --- + + + title: 잡 content_type: concept feature: @@ -35,6 +38,7 @@ weight: 50 ```shell kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml ``` +출력 결과는 다음과 같다. ``` job.batch/pi created ``` @@ -44,6 +48,7 @@ job.batch/pi created ```shell kubectl describe jobs/pi ``` +출력 결과는 다음과 같다. ``` Name: pi Namespace: default @@ -88,6 +93,7 @@ Events: pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') echo $pods ``` +출력 결과는 다음과 같다. ``` pi-5rwd7 ``` @@ -100,7 +106,7 @@ pi-5rwd7 ```shell kubectl logs $pods ``` -다음과 유사하게 출력된다. +출력 결과는 다음과 같다. ```shell 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 ``` @@ -395,10 +401,11 @@ spec: 잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_. 삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다. -``` +```shell kubectl get job old -o yaml ``` -``` +출력 결과는 다음과 같다. +```yaml kind: Job metadata: name: old @@ -417,7 +424,7 @@ spec: 시스템이 일반적으로 자동 생성하는 셀렉터를 사용하지 않도록 하기 위해 새 잡에서 `manualSelector: true` 를 지정해야 한다. -``` +```yaml kind: Job metadata: name: new diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 6dce0bfcee..265f971816 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -1,4 +1,6 @@ --- + + title: 파드 content_type: concept weight: 10 @@ -189,6 +191,34 @@ spec: 시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을 확장할 수 있게 한다. +## 파드 갱신 및 교체 + +이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드 +템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신 +갱신된 템플릿을 기반으로 신규 파드를 생성한다. + +쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다. +동작 중인 파드의 필드를 갱신하는 것도 가능하다. +그러나, +[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 및 +[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)와 같은 +파드 갱신 작업에는 다음과 같은 제약이 있다. + +- 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는 + `namespace`, `name`, `uid`, 또는 `creationTimestamp` 필드를 변경할 수 없다. + 그리고 `generation` 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는 + 갱신만 허용한다. +- `metadata.deletionTimestamp` 가 설정된 경우, + `metadata.finalizers` 리스트에 새로운 항목이 추가될 수 없다. +- 파드 갱신은 `spec.containers[*].image`, `spec.initContainers[*].image`, + `spec.activeDeadlineSeconds`, 또는 `spec.tolerations` 이외의 필드는 + 변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다. +- `spec.activeDeadlineSeconds` 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만 + 허용한다. + + 1. 지정되지 않은 필드를 양수로 설정; + 1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신. + ## 리소스 공유와 통신 파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을 diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 3267f5b04d..c1e3943178 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -1,4 +1,6 @@ --- + + title: 초기화 컨테이너 content_type: concept weight: 40 @@ -47,9 +49,9 @@ weight: 40 또한, 초기화 컨테이너는 `lifecycle`, `livenessProbe`, `readinessProbe` 또는 `startupProbe` 를 지원하지 않는다. 왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다. -만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을 +만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을 한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다. -모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을 +모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을 초기화하고 평소와 같이 실행한다. ## 초기화 컨테이너 사용하기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 2cd28660d0..b927895575 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -66,7 +66,7 @@ graph TB API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다. -``` +```yaml apiVersion: v1 kind: Pod metadata: @@ -290,7 +290,7 @@ graph BT - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우. - 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우. -기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서 +기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)에서 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다. 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, @@ -315,7 +315,7 @@ profiles: {{< note >}} 기본 스케줄링 제약 조건에 의해 생성된 점수는 -[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에 +[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에 의해 생성된 점수와 충돌 할 수 있다. `PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서 이 플러그인을 비활성화 하는 것을 권장한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 8f2f5c48a6..14fee6ee9c 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -1,5 +1,7 @@ --- title: 레퍼런스 + + linkTitle: "레퍼런스" main_menu: true weight: 70 @@ -16,7 +18,7 @@ content_type: concept ## API 레퍼런스 -* [쿠버네티스 API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [쿠버네티스 API 레퍼런스 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요 ## API 클라이언트 라이브러리 @@ -33,7 +35,7 @@ content_type: concept ## CLI 레퍼런스 * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. - * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. + * [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. ## 컴포넌트 레퍼런스 diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 78d54badce..ad9c9a45de 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -419,10 +419,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 참고한다. - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 - 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 - 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 + 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 + 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. - 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 + 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. - `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. -`CronJobControllerV2` : {{< glossary_tooltip text="크론잡" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면 동일한 컨트롤러의 버전 1이 선택된다. 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다. @@ -508,7 +508,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다. --`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown)을 참조한다. +-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을 참조한다. - `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다. - `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다. - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. @@ -582,7 +582,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. 자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다. - `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다. -- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. +- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. - `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. 자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. - `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다. diff --git a/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md b/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md new file mode 100644 index 0000000000..ad5f3f2691 --- /dev/null +++ b/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md @@ -0,0 +1,19 @@ +--- +title: 동적 볼륨 프로비저닝(Dynamic Volume Provisioning) +id: dynamicvolumeprovisioning +date: 2018-04-12 +full_link: /ko/docs/concepts/storage/dynamic-provisioning +short_description: > + 사용자가 스토리지 볼륨의 자동 생성을 요청할 수 있게 해준다. + +aka: +tags: +- core-object +- storage +--- + 사용자가 스토리지 {{< glossary_tooltip text="볼륨" term_id="volume" >}}의 자동 생성을 요청할 수 있게 해준다. + + + +동적 프로비저닝은 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없다. 대신 사용자 요청에 따라 자동으로 스토리지를 프로비저닝한다. 동적 볼륨 프로비저닝은 API 오브젝트인 {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 기반으로 한다. 이 스토리지클래스는 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 및 {{< glossary_tooltip text="볼륨 플러그인" term_id="volume-plugin" >}}에 전달할 파라미터 세트를 프로비저닝하는 볼륨 플러그인을 참조한다. + diff --git a/content/ko/docs/reference/glossary/kube-proxy.md b/content/ko/docs/reference/glossary/kube-proxy.md index 7281e6f4c5..c82ef7d968 100755 --- a/content/ko/docs/reference/glossary/kube-proxy.md +++ b/content/ko/docs/reference/glossary/kube-proxy.md @@ -18,10 +18,10 @@ tags: -[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는 +[kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. -kube-proxy는 운영 체제에 가용한 패킷 +kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 1613791ddf..7db5ce3bdb 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -356,8 +356,8 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 `-o=custom-columns=<명세>` | 쉼표로 구분된 사용자 정의 열 목록을 사용하여 테이블 출력 `-o=custom-columns-file=<파일명>` | `<파일명>`파일에서 사용자 정의 열 템플릿을 사용하여 테이블 출력 `-o=json` | JSON 형식의 API 오브젝트 출력 -`-o=jsonpath=<템플릿>` | [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 -`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 +`-o=jsonpath=<템플릿>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 +`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 `-o=name` | 리소스 명만 출력하고 그 외에는 출력하지 않음 `-o=wide` | 추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함 `-o=yaml` | YAML 형식의 API 오브젝트 출력 @@ -395,10 +395,10 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 ## {{% heading "whatsnext" %}} -* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/docs/reference/kubectl/jsonpath)에 대해 배워보자. +* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자. -* [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다. +* [kubectl](/ko/docs/reference/kubectl/kubectl/) 옵션을 참고한다. -* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다. +* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/ko/docs/reference/kubectl/conventions/)을 참고한다. * 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다. diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index e86a5579b7..7ddfe5b095 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -119,7 +119,7 @@ kubectl [command] [TYPE] [NAME] [flags] `version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. `wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. -명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. +명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ## 리소스 타입 @@ -188,7 +188,7 @@ kubectl [command] [TYPE] [NAME] [flags] ## 출력 옵션 -특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ### 출력 서식화 @@ -207,8 +207,8 @@ kubectl [command] [TYPE] [NAME] -o `-o custom-columns=` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다. `-o custom-columns-file=` | `` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다. `-o json` | JSON 형식의 API 오브젝트를 출력한다. -`-o jsonpath=