diff --git a/content/en/blog/_posts/2020-12-02-dockershim-faq.md b/content/en/blog/_posts/2020-12-02-dockershim-faq.md index f8dbe7f7c7..918a969e51 100644 --- a/content/en/blog/_posts/2020-12-02-dockershim-faq.md +++ b/content/en/blog/_posts/2020-12-02-dockershim-faq.md @@ -114,7 +114,7 @@ will have strictly better performance and less overhead. However, we encourage y to explore all the options from the [CNCF landscape] in case another would be an even better fit for your environment. -[CNCF landscape]: https://landscape.cncf.io/category=container-runtime&format=card-mode&grouping=category +[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category ### What should I look out for when changing CRI implementations? diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md index cac156b53b..7d5aec5078 100644 --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -45,7 +45,7 @@ Before choosing a guide, here are some considerations: ## Securing a cluster -* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. +* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains. * [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node. diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md index 6314420c01..6cce47f13c 100644 --- a/content/en/docs/concepts/cluster-administration/certificates.md +++ b/content/en/docs/concepts/cluster-administration/certificates.md @@ -4,249 +4,6 @@ content_type: concept weight: 20 --- - -When using client certificate authentication, you can generate certificates -manually through `easyrsa`, `openssl` or `cfssl`. - - - - - - -### easyrsa - -**easyrsa** can manually generate certificates for your cluster. - -1. Download, unpack, and initialize the patched version of easyrsa3. - - curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz - tar xzf easy-rsa.tar.gz - cd easy-rsa-master/easyrsa3 - ./easyrsa init-pki -1. Generate a new certificate authority (CA). `--batch` sets automatic mode; - `--req-cn` specifies the Common Name (CN) for the CA's new root certificate. - - ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass -1. Generate server certificate and key. - The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will - be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR - that is specified as the `--service-cluster-ip-range` argument for both the API server and - the controller manager component. The argument `--days` is used to set the number of days - after which the certificate expires. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ - "IP:${MASTER_CLUSTER_IP},"\ - "DNS:kubernetes,"\ - "DNS:kubernetes.default,"\ - "DNS:kubernetes.default.svc,"\ - "DNS:kubernetes.default.svc.cluster,"\ - "DNS:kubernetes.default.svc.cluster.local" \ - --days=10000 \ - build-server-full server nopass -1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. -1. Fill in and add the following parameters into the API server start parameters: - - --client-ca-file=/yourdirectory/ca.crt - --tls-cert-file=/yourdirectory/server.crt - --tls-private-key-file=/yourdirectory/server.key - -### openssl - -**openssl** can manually generate certificates for your cluster. - -1. Generate a ca.key with 2048bit: - - openssl genrsa -out ca.key 2048 -1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time): - - openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt -1. Generate a server.key with 2048bit: - - openssl genrsa -out server.key 2048 -1. Create a config file for generating a Certificate Signing Request (CSR). - Be sure to substitute the values marked with angle brackets (e.g. ``) - with real values before saving this to a file (e.g. `csr.conf`). - Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the - API server as described in previous subsection. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - [ req ] - default_bits = 2048 - prompt = no - default_md = sha256 - req_extensions = req_ext - distinguished_name = dn - - [ dn ] - C = - ST = - L = - O = - OU = - CN = - - [ req_ext ] - subjectAltName = @alt_names - - [ alt_names ] - DNS.1 = kubernetes - DNS.2 = kubernetes.default - DNS.3 = kubernetes.default.svc - DNS.4 = kubernetes.default.svc.cluster - DNS.5 = kubernetes.default.svc.cluster.local - IP.1 = - IP.2 = - - [ v3_ext ] - authorityKeyIdentifier=keyid,issuer:always - basicConstraints=CA:FALSE - keyUsage=keyEncipherment,dataEncipherment - extendedKeyUsage=serverAuth,clientAuth - subjectAltName=@alt_names -1. Generate the certificate signing request based on the config file: - - openssl req -new -key server.key -out server.csr -config csr.conf -1. Generate the server certificate using the ca.key, ca.crt and server.csr: - - openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ - -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf -1. View the certificate: - - openssl x509 -noout -text -in ./server.crt - -Finally, add the same parameters into the API server start parameters. - -### cfssl - -**cfssl** is another tool for certificate generation. - -1. Download, unpack and prepare the command line tools as shown below. - 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.5.0/cfssl_1.5.0_linux_amd64 -o cfssl - chmod +x cfssl - 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.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: - - mkdir cert - cd cert - ../cfssl print-defaults config > config.json - ../cfssl print-defaults csr > csr.json -1. Create a JSON config file for generating the CA file, for example, `ca-config.json`: - - { - "signing": { - "default": { - "expiry": "8760h" - }, - "profiles": { - "kubernetes": { - "usages": [ - "signing", - "key encipherment", - "server auth", - "client auth" - ], - "expiry": "8760h" - } - } - } - } -1. Create a JSON config file for CA certificate signing request (CSR), for example, - `ca-csr.json`. Be sure to replace the values marked with angle brackets with - real values you want to use. - - { - "CN": "kubernetes", - "key": { - "algo": "rsa", - "size": 2048 - }, - "names":[{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): - - ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca -1. Create a JSON config file for generating keys and certificates for the API - server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with - real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster - IP for the API server as described in previous subsection. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - { - "CN": "kubernetes", - "hosts": [ - "127.0.0.1", - "", - "", - "kubernetes", - "kubernetes.default", - "kubernetes.default.svc", - "kubernetes.default.svc.cluster", - "kubernetes.default.svc.cluster.local" - ], - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -1. Generate the key and certificate for the API server, which are by default - saved into file `server-key.pem` and `server.pem` respectively: - - ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ - --config=ca-config.json -profile=kubernetes \ - server-csr.json | ../cfssljson -bare server - - -## Distributing Self-Signed CA Certificate - -A client node may refuse to recognize a self-signed CA certificate as valid. -For a non-production deployment, or for a deployment that runs behind a company -firewall, you can distribute a self-signed CA certificate to all clients and -refresh the local list for valid certificates. - -On each client, perform the following operations: - -```bash -sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt -sudo update-ca-certificates -``` - -``` -Updating certificates in /etc/ssl/certs... -1 added, 0 removed; done. -Running hooks in /etc/ca-certificates/update.d.... -done. -``` - -## Certificates API - -You can use the `certificates.k8s.io` API to provision -x509 certificates to use for authentication as documented -[here](/docs/tasks/tls/managing-tls-in-a-cluster). - - +To learn how to generate certificates for your cluster, see [Certificates](/docs/tasks/administer-cluster/certificates/). diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index fa31fbd35f..40320e4285 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md @@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/ It is a recommended practice to put resources related to the same microservice or application tier into the same file, and to group all of the files associated with your application in the same directory. If the tiers of your application bind to each other using DNS, you can deploy all of the components of your stack together. -A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into github: +A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into GitHub: ```shell kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index 9d14423816..e011ad37b0 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -718,7 +718,7 @@ spec: #### Consuming Secret Values from environment variables -Inside a container that consumes a secret in an environment variables, the secret keys appear as +Inside a container that consumes a secret in the environment variables, the secret keys appear as normal environment variables containing the base64 decoded values of the secret data. This is the result of commands executed inside the container from the example above: diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index 7ec28e97b4..a1eba4d96d 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -40,6 +40,7 @@ as are any environment variables specified statically in the Docker image. ### Cluster information A list of all services that were running when a Container was created is available to that Container as environment variables. +This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services. Those environment variables match the syntax of Docker links. For a service named *foo* that maps to a Container named *bar*, diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 74147624f5..d9fe184f85 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -28,9 +28,7 @@ The most common way to implement the APIService is to run an *extension API serv Extension API servers should have low latency networking to and from the kube-apiserver. Discovery requests are required to round-trip from the kube-apiserver in five seconds or less. -If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it. You can also set the -`EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver -to disable the timeout restriction. This deprecated feature gate will be removed in a future release. +If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index eb17e2dd7e..763308887d 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -51,11 +51,11 @@ the same machine, and do not run user containers on this machine. See {{< glossary_definition term_id="kube-controller-manager" length="all" >}} -These controllers include: +Some types of these controllers are: * Node controller: Responsible for noticing and responding when nodes go down. - * Replication controller: Responsible for maintaining the correct number of pods for every replication - controller object in the system. + * Job controller: Watches for Job objects that represent one-off tasks, then creates + Pods to run those tasks to completion. * Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods). * Service Account & Token controllers: Create default accounts and API access tokens for new namespaces. diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index f02aede0e1..2888064c2e 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -7,8 +7,8 @@ content_type: concept weight: 20 --- -This page provides an overview of DNS support by Kubernetes. - +Kubernetes creates DNS records for services and pods. You can contact +services with consistent DNS names instead of IP addresses. @@ -18,19 +18,47 @@ Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures the kubelets to tell individual containers to use the DNS Service's IP to resolve DNS names. -### What things get DNS names? - Every Service defined in the cluster (including the DNS server itself) is -assigned a DNS name. By default, a client Pod's DNS search list will -include the Pod's own namespace and the cluster's default domain. This is best -illustrated by example: +assigned a DNS name. By default, a client Pod's DNS search list includes the +Pod's own namespace and the cluster's default domain. -Assume a Service named `foo` in the Kubernetes namespace `bar`. A Pod running -in namespace `bar` can look up this service by querying a DNS service for -`foo`. A Pod running in namespace `quux` can look up this service by doing a -DNS query for `foo.bar`. +### Namespaces of Services -The following sections detail the supported record types and layout that is +A DNS query may return different results based on the namespace of the pod making +it. DNS queries that don't specify a namespace are limited to the pod's +namespace. Access services in other namespaces by specifying it in the DNS query. + +For example, consider a pod in a `test` namespace. A `data` service is in +the `prod` namespace. + +A query for `data` returns no results, because it uses the pod's `test` namespace. + +A query for `data.prod` returns the intended result, because it specifies the +namespace. + +DNS queries may be expanded using the pod's `/etc/resolv.conf`. Kubelet +sets this file for each pod. For example, a query for just `data` may be +expanded to `data.test.cluster.local`. The values of the `search` option +are used to expand queries. To learn more about DNS queries, see +[the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) + +``` +nameserver 10.32.0.10 +search .svc.cluster.local svc.cluster.local cluster.local +options ndots:5 +``` + +In summary, a pod in the _test_ namespace can successfully resolve either +`data.prod` or `data.prod.cluster.local`. + +### DNS Records + +What objects get DNS records? + +1. Services +2. Pods + +The following sections detail the supported DNS record types and layout that is supported. Any other layout or names or queries that happen to work are considered implementation details and are subject to change without warning. For more up-to-date specification, see diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index bcbf7d7f75..b7a7edcd38 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -74,8 +74,8 @@ a new instance. The name of a Service object must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names). -For example, suppose you have a set of Pods that each listen on TCP port 9376 -and carry a label `app=MyApp`: +For example, suppose you have a set of Pods where each listens on TCP port 9376 +and contains a label `app=MyApp`: ```yaml apiVersion: v1 diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 3d4248443d..d0a8bbf5a9 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -75,7 +75,7 @@ Here are some ways to mitigate involuntary disruptions: and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.) - For even higher availability when running replicated applications, spread applications across racks (using - [anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)) + [anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)) or across zones (if using a [multi-zone cluster](/docs/setup/multiple-zones).) @@ -104,7 +104,7 @@ ensure that the number of replicas serving load never falls below a certain percentage of the total. Cluster managers and hosting providers should use tools which -respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) +respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) instead of directly deleting pods or deployments. For example, the `kubectl drain` subcommand lets you mark a node as going out of diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 2d89ee7e74..ad0b9420c5 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -61,7 +61,7 @@ Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs. -Members of `@kubernetes/website-maintainers` can create new development branches to coordinate translation efforts. +Members of `@kubernetes/website-maintainers` can create new localization branches to coordinate translation efforts. Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. @@ -205,14 +205,20 @@ To ensure accuracy in grammar and meaning, members of your localization team sho ### Source files -Localizations must be based on the English files from the most recent release, {{< latest-version >}}. +Localizations must be based on the English files from a specific release targeted by the localization team. +Each localization team can decide which release to target which is referred to as the _target version_ below. -To find source files for the most recent release: +To find source files for your target version: 1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website. -2. Select the `release-1.X` branch for the most recent version. +2. Select a branch for your target version from the following table: + Target version | Branch + -----|----- + Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}}) + Latest version | [`master`](https://github.com/kubernetes/website/tree/master) + Previous version | `release-*.**` -The latest version is {{< latest-version >}}, so the most recent release branch is [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}). +The `master` branch holds content for the current release `{{< latest-version >}}`. The release team will create `{{< release-branch >}}` branch shortly before the next release: v{{< skew nextMinorVersion >}}. ### Site strings in i18n @@ -239,11 +245,11 @@ Some language teams have their own language-specific style guide and glossary. F ## Branching strategy -Because localization projects are highly collaborative efforts, we encourage teams to work in shared development branches. +Because localization projects are highly collaborative efforts, we encourage teams to work in shared localization branches. -To collaborate on a development branch: +To collaborate on a localization branch: -1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a development branch from a source branch on https://github.com/kubernetes/website. +1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a localization branch from a source branch on https://github.com/kubernetes/website. Your team approvers joined the `@kubernetes/website-maintainers` team when you [added your localization team](#add-your-localization-team-in-github) to the [`kubernetes/org`](https://github.com/kubernetes/org) repository. @@ -251,25 +257,31 @@ To collaborate on a development branch: `dev--.` - For example, an approver on a German localization team opens the development branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. + For example, an approver on a German localization team opens the localization branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. -2. Individual contributors open feature branches based on the development branch. +2. Individual contributors open feature branches based on the localization branch. For example, a German contributor opens a pull request with changes to `kubernetes:dev-1.12-de.1` from `username:local-branch-name`. -3. Approvers review and merge feature branches into the development branch. +3. Approvers review and merge feature branches into the localization branch. -4. Periodically, an approver merges the development branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. +4. Periodically, an approver merges the localization branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. -Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. +Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. -Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from {{< release-branch >}} must be based on {{< release-branch >}}. +Teams must merge localized content into the same branch from which the content was sourced. -An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch. +For example: +- a localization branch sourced from `master` must be merged into `master`. +- a localization branch sourced from `release-1.19` must be merged into `release-1.19`. -At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. +{{< note >}} +If your localization branch was created from `master` branch but it is not merged into `master` before new release branch `{{< release-branch >}}` created, merge it into both `master` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`. +{{< /note >}} - While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required. +At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. + +While only approvers can open a new localization branch and merge pull requests, anyone can open a pull request for a new localization branch. No special permissions are required. For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo). @@ -290,5 +302,3 @@ Once a localization meets requirements for workflow and minimum output, SIG docs - Enable language selection on the website - Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/). - - diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md index 5885618102..a261b8a947 100644 --- a/content/en/docs/reference/_index.md +++ b/content/en/docs/reference/_index.md @@ -6,8 +6,10 @@ linkTitle: "Reference" main_menu: true weight: 70 content_type: concept +no_list: true --- + This section of the Kubernetes documentation contains references. @@ -18,11 +20,17 @@ This section of the Kubernetes documentation contains references. ## API Reference +* [Glossary](/docs/reference/glossary/) - a comprehensive, standardized list of Kubernetes terminology + + + * [Kubernetes API Reference](/docs/reference/kubernetes-api/) * [One-page API Reference for Kubernetes {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [Using The Kubernetes API](/docs/reference/using-api/) - overview of the API for Kubernetes. +* [API access control](/docs/reference/access-authn-authz/) - details on how Kubernetes controls API access +* [Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/) -## API Client Libraries +## Officially supported client libraries To call the Kubernetes API from a programming language, you can use [client libraries](/docs/reference/using-api/client-libraries/). Officially supported @@ -32,22 +40,28 @@ client libraries: - [Kubernetes Python client library](https://github.com/kubernetes-client/python) - [Kubernetes Java client library](https://github.com/kubernetes-client/java) - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) +- [Kubernetes Dotnet client library](https://github.com/kubernetes-client/csharp) +- [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell) -## CLI Reference +## CLI * [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters. * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl. * [kubeadm](/docs/reference/setup-tools/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster. -## Components Reference +## Components * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy. * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API that validates and configures data for API objects such as pods, services, replication controllers. * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes. * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends. -* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity. - * [kube-scheduler Policies](/docs/reference/scheduling/policies) - * [kube-scheduler Profiles](/docs/reference/scheduling/config#profiles) +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity. + +## Scheduling + +* [Scheduler Policies](/docs/reference/scheduling/policies) +* [Scheduler Profiles](/docs/reference/scheduling/config#profiles) + ## Design Docs diff --git a/content/en/docs/reference/access-authn-authz/_index.md b/content/en/docs/reference/access-authn-authz/_index.md index d999e52bf5..86d06488a8 100644 --- a/content/en/docs/reference/access-authn-authz/_index.md +++ b/content/en/docs/reference/access-authn-authz/_index.md @@ -1,6 +1,6 @@ --- title: API Access Control -weight: 20 +weight: 15 no_list: 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 f972a0184e..f66f72eaab 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -625,6 +625,8 @@ Starting from 1.11, this admission controller is disabled by default. ### PodNodeSelector {#podnodeselector} +{{< feature-state for_k8s_version="v1.5" state="alpha" >}} + This admission controller defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration. #### Configuration File Format @@ -704,6 +706,8 @@ for more information. ### PodTolerationRestriction {#podtolerationrestriction} +{{< feature-state for_k8s_version="v1.7" state="alpha" >}} + The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace. It rejects the pod request if there is a conflict. It then merges the tolerations annotated on the namespace into the tolerations of the pod. diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index fc76cbb2f4..17702520e4 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -99,7 +99,7 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2". -See [Managing Certificates](/docs/concepts/cluster-administration/certificates/) for how to generate a client cert. +See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for how to generate a client cert. ### Static Token File @@ -328,7 +328,7 @@ Since all of the data needed to validate who you are is in the `id_token`, Kuber 1. Kubernetes has no "web interface" to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first. 2. The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes. -3. To authenticate to the Kubernetes dashboard, you must the `kubectl proxy` command or a reverse proxy that injects the `id_token`. +3. To authenticate to the Kubernetes dashboard, you must use the `kubectl proxy` command or a reverse proxy that injects the `id_token`. #### Configuring the API Server diff --git a/content/en/docs/reference/command-line-tools-reference/_index.md b/content/en/docs/reference/command-line-tools-reference/_index.md index 6698fe66c0..8f9cf74a0e 100644 --- a/content/en/docs/reference/command-line-tools-reference/_index.md +++ b/content/en/docs/reference/command-line-tools-reference/_index.md @@ -1,4 +1,4 @@ --- -title: Command line tools reference +title: Component tools weight: 60 --- diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 81ffda981d..51c13f528f 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -239,6 +239,7 @@ different Kubernetes components. | `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - | | `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 | | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | +| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - | | `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 | | `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - | | `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 | diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index b569177dda..fdd85997eb 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -302,7 +302,7 @@ kubelet [flags] --enable-cadvisor-json-endpoints     Default: `false` -Enable cAdvisor json `/spec` and `/stats/*` endpoints. (DEPRECATED: will be removed in a future version) +Enable cAdvisor json `/spec` and `/stats/*` endpoints. This flag has no effect on the /stats/summary endpoint. (DEPRECATED: will be removed in a future version) diff --git a/content/en/docs/reference/glossary/index.md b/content/en/docs/reference/glossary/index.md index 1fb8799a16..29bd54bd21 100755 --- a/content/en/docs/reference/glossary/index.md +++ b/content/en/docs/reference/glossary/index.md @@ -2,7 +2,7 @@ approvers: - chenopis - abiogenesis-now -title: Standardized Glossary +title: Glossary layout: glossary noedit: true default_active_tag: fundamental diff --git a/content/en/docs/reference/issues-security/_index.md b/content/en/docs/reference/issues-security/_index.md index 530e98bf61..50c3f29333 100644 --- a/content/en/docs/reference/issues-security/_index.md +++ b/content/en/docs/reference/issues-security/_index.md @@ -1,4 +1,4 @@ --- title: Kubernetes Issues and Security -weight: 10 +weight: 40 --- \ No newline at end of file diff --git a/content/en/docs/reference/kubectl/_index.md b/content/en/docs/reference/kubectl/_index.md index 7b6c2d720b..765adb6fe8 100755 --- a/content/en/docs/reference/kubectl/_index.md +++ b/content/en/docs/reference/kubectl/_index.md @@ -1,5 +1,5 @@ --- -title: "kubectl CLI" +title: "kubectl" weight: 60 --- diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 79ca330bd5..cbb579908b 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -320,6 +320,18 @@ kubectl top pod POD_NAME --containers # Show metrics for a given p kubectl top pod POD_NAME --sort-by=cpu # Show metrics for a given pod and sort it by 'cpu' or 'memory' ``` +## Interacting with Deployments and Services +```bash +kubectl logs deploy/my-deployment # dump Pod logs for a Deployment (single-container case) +kubectl logs deploy/my-deployment -c my-container # dump Pod logs for a Deployment (multi-container case) + +kubectl port-forward svc/my-service 5000 # listen on local port 5000 and forward to port 5000 on Service backend +kubectl port-forward svc/my-service 5000:my-service-port # listen on local port 5000 and forward to Service target port with name + +kubectl port-forward deploy/my-deployment 5000:6000 # listen on local port 5000 and forward to port 6000 on a Pod created by +kubectl exec deploy/my-deployment -- ls # run command in first Pod and first container in Deployment (single- or multi-container cases) +``` + ## Interacting with Nodes and cluster ```bash diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md index 6c214513a0..ac7b7a49f9 100644 --- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -7,7 +7,7 @@ reviewers: --- -You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command. +You can use the Kubernetes command line tool `kubectl` to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the Docker commands and the kubectl commands. The following sections show a Docker sub-command and describe the equivalent `kubectl` command. diff --git a/content/en/docs/reference/setup-tools/_index.md b/content/en/docs/reference/setup-tools/_index.md index 3988d6485e..c97758fe6e 100644 --- a/content/en/docs/reference/setup-tools/_index.md +++ b/content/en/docs/reference/setup-tools/_index.md @@ -1,4 +1,4 @@ --- -title: Setup tools reference +title: Setup tools weight: 50 --- diff --git a/content/en/docs/reference/tools.md b/content/en/docs/reference/tools/_index.md similarity index 78% rename from content/en/docs/reference/tools.md rename to content/en/docs/reference/tools/_index.md index 41d8ef4d1c..7194ab83bd 100644 --- a/content/en/docs/reference/tools.md +++ b/content/en/docs/reference/tools/_index.md @@ -1,8 +1,10 @@ --- +title: Other Tools reviewers: - janetkuo -title: Tools content_type: concept +weight: 80 +no_list: true --- @@ -10,13 +12,6 @@ Kubernetes contains several built-in tools to help you work with the Kubernetes -## Kubectl - -[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager. - -## Kubeadm - -[`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha). ## Minikube diff --git a/content/en/docs/reference/using-api/_index.md b/content/en/docs/reference/using-api/_index.md index df9e00758e..2039e33e28 100644 --- a/content/en/docs/reference/using-api/_index.md +++ b/content/en/docs/reference/using-api/_index.md @@ -1,11 +1,12 @@ --- -title: Kubernetes API Overview +title: API Overview reviewers: - erictune - lavalamp - jbeda content_type: concept weight: 10 +no_list: true card: name: reference weight: 50 diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index 96589c6a55..a484c8e74f 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -67,12 +67,13 @@ their authors, not the Kubernetes team. | Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | +| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | -| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | +| Scala | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | | Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) | | DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 5aa4ac894e..e59b497302 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -219,30 +219,39 @@ sudo systemctl restart containerd ``` {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} + +
+Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands: +
+ ```powershell # (Install containerd) -# download containerd -cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.1/containerd-1.4.1-windows-amd64.tar.gz -cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz +# Download containerd +curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz +tar.exe xvf .\containerd-windows-amd64.tar.gz ``` ```powershell -# extract and configure +# Extract and configure Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force cd $Env:ProgramFiles\containerd\ .\containerd.exe config default | Out-File config.toml -Encoding ascii -# review the configuration. depending on setup you may want to adjust: -# - the sandbox_image (kubernetes pause image) +# Review the configuration. Depending on setup you may want to adjust: +# - the sandbox_image (Kubernetes pause image) # - cni bin_dir and conf_dir locations Get-Content config.toml + +# (Optional - but highly recommended) Exclude containerd form Windows Defender Scans +Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" ``` ```powershell -# start containerd +# Start containerd .\containerd.exe --register-service Start-Service containerd ``` + {{% /tab %}} {{< /tabs >}} 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 394820324d..3f6e991eac 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 @@ -18,14 +18,7 @@ For information how to create a cluster with kubeadm once you have performed thi ## {{% heading "prerequisites" %}} -* One or more machines running one of: - - Ubuntu 16.04+ - - Debian 9+ - - CentOS 7+ - - Red Hat Enterprise Linux (RHEL) 7+ - - Fedora 25+ - - HypriotOS v1.0.1+ - - Flatcar Container Linux (tested with 2512.3.0) +* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions based on Debian and Red Hat, and those distributions without a package manager. * 2 GB or more of RAM per machine (any less will leave little room for your apps). * 2 CPUs or more. * Full network connectivity between all machines in the cluster (public or private network is fine). @@ -122,7 +115,7 @@ The following table lists container runtimes and their associated socket paths: {{< table caption = "Container runtimes and their socket paths" >}} | Runtime | Path to Unix domain socket | |------------|-----------------------------------| -| Docker | `/var/run/docker.sock` | +| Docker | `/var/run/dockershim.sock` | | containerd | `/run/containerd/containerd.sock` | | CRI-O | `/var/run/crio/crio.sock` | {{< /table >}} @@ -181,7 +174,7 @@ For more information on version skews, see: * Kubeadm-specific [version skew policy](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) {{< tabs name="k8s_install" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{% tab name="Debian-based distributions" %}} ```bash sudo apt-get update && sudo apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - @@ -193,7 +186,7 @@ sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` {{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} +{{% tab name="Red Hat-based distributions" %}} ```bash cat <>= print ``` +## {{% heading "whatsnext" %}} -### Accessing the API from within a Pod - -When accessing the API from within a Pod, locating and authenticating -to the API server are slightly different to the external client case described above. - -The easiest way to use the Kubernetes API from a Pod is to use -one of the official [client libraries](/docs/reference/using-api/client-libraries/). These -libraries can automatically discover the API server and authenticate. - -#### Using Official Client Libraries - -From within a Pod, the recommended ways to connect to the Kubernetes API are: - - - For a Go client, use the official [Go client library](https://github.com/kubernetes/client-go/). - The `rest.InClusterConfig()` function handles API host discovery and authentication automatically. - See [an example here](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go). - - - For a Python client, use the official [Python client library](https://github.com/kubernetes-client/python/). - The `config.load_incluster_config()` function handles API host discovery and authentication automatically. - See [an example here](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py). - - - There are a number of other libraries available, please refer to the [Client Libraries](/docs/reference/using-api/client-libraries/) page. - -In each case, the service account credentials of the Pod are used to communicate -securely with the API server. - -#### Directly accessing the REST API - -While running in a Pod, the Kubernetes apiserver is accessible via a Service named -`kubernetes` in the `default` namespace. Therefore, Pods can use the -`kubernetes.default.svc` hostname to query the API server. Official client libraries -do this automatically. - -The recommended way to authenticate to the API server is with a -[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By default, a Pod -is associated with a service account, and a credential (token) for that -service account is placed into the filesystem tree of each container in that Pod, -at `/var/run/secrets/kubernetes.io/serviceaccount/token`. - -If available, a certificate bundle is placed into the filesystem tree of each -container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be -used to verify the serving certificate of the API server. - -Finally, the default namespace to be used for namespaced API operations is placed in a file -at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container. - -#### Using kubectl proxy - -If you would like to query the API without an official client library, you can run `kubectl proxy` -as the [command](/docs/tasks/inject-data-application/define-command-argument-container/) -of a new sidecar container in the Pod. This way, `kubectl proxy` will authenticate -to the API and expose it on the `localhost` interface of the Pod, so that other containers -in the Pod can use it directly. - -#### Without using a proxy - -It is possible to avoid using the kubectl proxy by passing the authentication token -directly to the API server. The internal certificate secures the connection. - -```shell -# Point to the internal API server hostname -APISERVER=https://kubernetes.default.svc - -# Path to ServiceAccount token -SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount - -# Read this Pod's namespace -NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace) - -# Read the ServiceAccount bearer token -TOKEN=$(cat ${SERVICEACCOUNT}/token) - -# Reference the internal certificate authority (CA) -CACERT=${SERVICEACCOUNT}/ca.crt - -# Explore the API with TOKEN -curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api -``` - -The output will be similar to this: - -```json -{ - "kind": "APIVersions", - "versions": [ - "v1" - ], - "serverAddressByClientCIDRs": [ - { - "clientCIDR": "0.0.0.0/0", - "serverAddress": "10.0.1.149:443" - } - ] -} -``` - - - +* [Accessing the Kubernetes API from a Pod](/docs/tasks/run-application/access-api-from-pod/) diff --git a/content/en/docs/tasks/administer-cluster/certificates.md b/content/en/docs/tasks/administer-cluster/certificates.md new file mode 100644 index 0000000000..6361b20d16 --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/certificates.md @@ -0,0 +1,252 @@ +--- +title: Certificates +content_type: task +weight: 20 +--- + + + + +When using client certificate authentication, you can generate certificates +manually through `easyrsa`, `openssl` or `cfssl`. + + + + + + +### easyrsa + +**easyrsa** can manually generate certificates for your cluster. + +1. Download, unpack, and initialize the patched version of easyrsa3. + + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki +1. Generate a new certificate authority (CA). `--batch` sets automatic mode; + `--req-cn` specifies the Common Name (CN) for the CA's new root certificate. + + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass +1. Generate server certificate and key. + The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will + be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR + that is specified as the `--service-cluster-ip-range` argument for both the API server and + the controller manager component. The argument `--days` is used to set the number of days + after which the certificate expires. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass +1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. +1. Fill in and add the following parameters into the API server start parameters: + + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + +### openssl + +**openssl** can manually generate certificates for your cluster. + +1. Generate a ca.key with 2048bit: + + openssl genrsa -out ca.key 2048 +1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time): + + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt +1. Generate a server.key with 2048bit: + + openssl genrsa -out server.key 2048 +1. Create a config file for generating a Certificate Signing Request (CSR). + Be sure to substitute the values marked with angle brackets (e.g. ``) + with real values before saving this to a file (e.g. `csr.conf`). + Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the + API server as described in previous subsection. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn + + [ dn ] + C = + ST = + L = + O = + OU = + CN = + + [ req_ext ] + subjectAltName = @alt_names + + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = + + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names +1. Generate the certificate signing request based on the config file: + + openssl req -new -key server.key -out server.csr -config csr.conf +1. Generate the server certificate using the ca.key, ca.crt and server.csr: + + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf +1. View the certificate: + + openssl x509 -noout -text -in ./server.crt + +Finally, add the same parameters into the API server start parameters. + +### cfssl + +**cfssl** is another tool for certificate generation. + +1. Download, unpack and prepare the command line tools as shown below. + 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.5.0/cfssl_1.5.0_linux_amd64 -o cfssl + chmod +x cfssl + 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.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: + + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json +1. Create a JSON config file for generating the CA file, for example, `ca-config.json`: + + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } +1. Create a JSON config file for CA certificate signing request (CSR), for example, + `ca-csr.json`. Be sure to replace the values marked with angle brackets with + real values you want to use. + + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): + + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca +1. Create a JSON config file for generating keys and certificates for the API + server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with + real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster + IP for the API server as described in previous subsection. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Generate the key and certificate for the API server, which are by default + saved into file `server-key.pem` and `server.pem` respectively: + + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ + --config=ca-config.json -profile=kubernetes \ + server-csr.json | ../cfssljson -bare server + + +## Distributing Self-Signed CA Certificate + +A client node may refuse to recognize a self-signed CA certificate as valid. +For a non-production deployment, or for a deployment that runs behind a company +firewall, you can distribute a self-signed CA certificate to all clients and +refresh the local list for valid certificates. + +On each client, perform the following operations: + +```bash +sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt +sudo update-ca-certificates +``` + +``` +Updating certificates in /etc/ssl/certs... +1 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d.... +done. +``` + +## Certificates API + +You can use the `certificates.k8s.io` API to provision +x509 certificates to use for authentication as documented +[here](/docs/tasks/tls/managing-tls-in-a-cluster). + + diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md index 8680abad43..faed4e1cb1 100644 --- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md +++ b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md @@ -25,6 +25,12 @@ kube-dns. {{< codenew file="admin/dns/dnsutils.yaml" >}} +{{< note >}} +This example creates a pod in the `default` namespace. DNS name resolution for +services depends on the namespace of the pod. For more information, review +[DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/#what-things-get-dns-names). +{{< /note >}} + Use that manifest to create a Pod: ```shell @@ -247,6 +253,27 @@ linux/amd64, go1.10.3, 2e322f6 172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s ``` +### Are you in the right namespace for the service? + +DNS queries that don't specify a namespace are limited to the pod's +namespace. + +If the namespace of the pod and service differ, the DNS query must include +the namespace of the service. + +This query is limited to the pod's namespace: +```shell +kubectl exec -i -t dnsutils -- nslookup +``` + +This query specifies the namespace: +```shell +kubectl exec -i -t dnsutils -- nslookup . +``` + +To learn more about name resolution, see +[DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/#what-things-get-dns-names). + ## Known issues Some Linux distributions (e.g. Ubuntu) use a local DNS resolver by default (systemd-resolved). diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md index d7b1f48a4a..5cbb30b99b 100644 --- a/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md +++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md @@ -92,7 +92,7 @@ kubectl describe secrets/db-user-pass-96mffmfh4k The output is similar to: ``` -Name: db-user-pass +Name: db-user-pass-96mffmfh4k Namespace: default Labels: Annotations: diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 45d56531f2..0cdfd28258 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -293,6 +293,10 @@ Services. Readiness probes runs on the container during its whole lifecycle. {{< /note >}} +{{< caution >}} +Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe. +{{< /caution >}} + Readiness probes are configured similarly to liveness probes. The only difference is that you use the `readinessProbe` field instead of the `livenessProbe` field. diff --git a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md index 54e474429c..59a83e87c7 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -99,7 +99,7 @@ kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never ``` The examples in this section use the `pause` container image because it does not -contain userland debugging utilities, but this method works with all container +contain debugging utilities, but this method works with all container images. If you attempt to use `kubectl exec` to create a shell you will see an error diff --git a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md index 9cefdca03d..02677d6204 100644 --- a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -70,8 +70,9 @@ override any environment variables specified in the container image. {{< /note >}} {{< note >}} -The environment variables can reference each other, and cycles are possible, -pay attention to the order before using +Environment variables may reference each other, however ordering is important. +Variables making use of others defined in the same context must come later in +the list. Similarly, avoid circular references. {{< /note >}} ## Using environment variables inside of your config diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md index c1722f694a..7c59052ffa 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -8,7 +8,7 @@ weight: 20 [Kustomize](https://github.com/kubernetes-sigs/kustomize) is a standalone tool to customize Kubernetes objects -through a [kustomization file](https://kubernetes-sigs.github.io/kustomize/api-reference/glossary/#kustomization). +through a [kustomization file](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#kustomization). Since 1.14, Kubectl also supports the management of Kubernetes objects using a kustomization file. diff --git a/content/en/docs/tasks/run-application/access-api-from-pod.md b/content/en/docs/tasks/run-application/access-api-from-pod.md new file mode 100644 index 0000000000..9eb2521f7f --- /dev/null +++ b/content/en/docs/tasks/run-application/access-api-from-pod.md @@ -0,0 +1,111 @@ +--- +title: Accessing the Kubernetes API from a Pod +content_type: task +weight: 120 +--- + + + +This guide demonstrates how to access the Kubernetes API from within a pod. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## Accessing the API from within a Pod + +When accessing the API from within a Pod, locating and authenticating +to the API server are slightly different to the external client case. + +The easiest way to use the Kubernetes API from a Pod is to use +one of the official [client libraries](/docs/reference/using-api/client-libraries/). These +libraries can automatically discover the API server and authenticate. + +### Using Official Client Libraries + +From within a Pod, the recommended ways to connect to the Kubernetes API are: + + - For a Go client, use the official [Go client library](https://github.com/kubernetes/client-go/). + The `rest.InClusterConfig()` function handles API host discovery and authentication automatically. + See [an example here](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go). + + - For a Python client, use the official [Python client library](https://github.com/kubernetes-client/python/). + The `config.load_incluster_config()` function handles API host discovery and authentication automatically. + See [an example here](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py). + + - There are a number of other libraries available, please refer to the [Client Libraries](/docs/reference/using-api/client-libraries/) page. + +In each case, the service account credentials of the Pod are used to communicate +securely with the API server. + +### Directly accessing the REST API + +While running in a Pod, the Kubernetes apiserver is accessible via a Service named +`kubernetes` in the `default` namespace. Therefore, Pods can use the +`kubernetes.default.svc` hostname to query the API server. Official client libraries +do this automatically. + +The recommended way to authenticate to the API server is with a +[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By default, a Pod +is associated with a service account, and a credential (token) for that +service account is placed into the filesystem tree of each container in that Pod, +at `/var/run/secrets/kubernetes.io/serviceaccount/token`. + +If available, a certificate bundle is placed into the filesystem tree of each +container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be +used to verify the serving certificate of the API server. + +Finally, the default namespace to be used for namespaced API operations is placed in a file +at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container. + +### Using kubectl proxy + +If you would like to query the API without an official client library, you can run `kubectl proxy` +as the [command](/docs/tasks/inject-data-application/define-command-argument-container/) +of a new sidecar container in the Pod. This way, `kubectl proxy` will authenticate +to the API and expose it on the `localhost` interface of the Pod, so that other containers +in the Pod can use it directly. + +### Without using a proxy + +It is possible to avoid using the kubectl proxy by passing the authentication token +directly to the API server. The internal certificate secures the connection. + +```shell +# Point to the internal API server hostname +APISERVER=https://kubernetes.default.svc + +# Path to ServiceAccount token +SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount + +# Read this Pod's namespace +NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace) + +# Read the ServiceAccount bearer token +TOKEN=$(cat ${SERVICEACCOUNT}/token) + +# Reference the internal certificate authority (CA) +CACERT=${SERVICEACCOUNT}/ca.crt + +# Explore the API with TOKEN +curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api +``` + +The output will be similar to this: + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` diff --git a/content/en/docs/tasks/tls/certificate-rotation.md b/content/en/docs/tasks/tls/certificate-rotation.md index ea3602fbb0..5dd9b85714 100644 --- a/content/en/docs/tasks/tls/certificate-rotation.md +++ b/content/en/docs/tasks/tls/certificate-rotation.md @@ -69,8 +69,9 @@ write that to disk, in the location specified by `--cert-dir`. Then the kubelet will use the new certificate to connect to the Kubernetes API. As the expiration of the signed certificate approaches, the kubelet will -automatically issue a new certificate signing request, using the Kubernetes -API. Again, the controller manager will automatically approve the certificate +automatically issue a new certificate signing request, using the Kubernetes API. +This can happen at any point between 30% and 10% of the time remaining on the +certificate. Again, the controller manager will automatically approve the certificate request and attach a signed certificate to the certificate signing request. The kubelet will retrieve the new signed certificate from the Kubernetes API and write that to disk. Then it will update the connections it has to the diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md index 1720ab34a2..e56322cbec 100644 --- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -105,8 +105,8 @@ Configurations with a single API server will experience unavailability while the * Make sure control plane components logs no TLS errors. {{< note >}} - To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl). - You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl). + To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl). + You can also use [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl). {{< /note >}} 1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion. diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md index 7bbb2161ec..4f43a92af7 100755 --- a/content/en/docs/tasks/tools/_index.md +++ b/content/en/docs/tasks/tools/_index.md @@ -7,19 +7,20 @@ no_list: true ## kubectl -The Kubernetes command-line tool, `kubectl`, allows you to run commands against -Kubernetes clusters. You can use `kubectl` to deploy applications, inspect and -manage cluster resources, and view logs. - -See [Install and Set Up `kubectl`](/docs/tasks/tools/install-kubectl/) for -information about how to download and install `kubectl` and set it up for -accessing your cluster. - -View kubectl Install and Set Up Guide - -You can also read the + +The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows +you to run commands against Kubernetes clusters. +You can use kubectl to deploy applications, inspect and manage cluster resources, +and view logs. For more information including a complete list of kubectl operations, see the [`kubectl` reference documentation](/docs/reference/kubectl/). +kubectl is installable on a variety of Linux platforms, macOS and Windows. +Find your preferred operating system below. + +- [Install kubectl on Linux](install-kubectl-linux) +- [Install kubectl on macOS](install-kubectl-macos) +- [Install kubectl on Windows](install-kubectl-windows) + ## kind [`kind`](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on diff --git a/content/en/docs/tasks/tools/included/_index.md b/content/en/docs/tasks/tools/included/_index.md new file mode 100644 index 0000000000..2da0437b82 --- /dev/null +++ b/content/en/docs/tasks/tools/included/_index.md @@ -0,0 +1,6 @@ +--- +title: "Tools Included" +description: "Snippets to be included in the main kubectl-installs-*.md pages." +headless: true +toc_hide: true +--- \ No newline at end of file diff --git a/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md b/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md new file mode 100644 index 0000000000..dcf8572618 --- /dev/null +++ b/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md @@ -0,0 +1,21 @@ +--- +title: "gcloud kubectl install" +description: "How to install kubectl with gcloud snippet for inclusion in each OS-specific tab." +headless: true +--- + +You can install kubectl as part of the Google Cloud SDK. + +1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/). + +1. Run the `kubectl` installation command: + + ```shell + gcloud components install kubectl + ``` + +1. Test to ensure the version you installed is up-to-date: + + ```shell + kubectl version --client + ``` \ No newline at end of file diff --git a/content/en/docs/tasks/tools/included/kubectl-whats-next.md b/content/en/docs/tasks/tools/included/kubectl-whats-next.md new file mode 100644 index 0000000000..4b0da49bbc --- /dev/null +++ b/content/en/docs/tasks/tools/included/kubectl-whats-next.md @@ -0,0 +1,12 @@ +--- +title: "What's next?" +description: "What's next after installing kubectl." +headless: true +--- + +* [Install Minikube](https://minikube.sigs.k8s.io/docs/start/) +* See the [getting started guides](/docs/setup/) for more about creating clusters. +* [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/) +* If you need access to a cluster you didn't create, see the + [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). +* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/) diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md new file mode 100644 index 0000000000..949f1922c4 --- /dev/null +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -0,0 +1,54 @@ +--- +title: "bash auto-completion on Linux" +description: "Some optional configuration for bash auto-completion on Linux." +headless: true +--- + +### Introduction + +The kubectl completion script for Bash can be generated with the command `kubectl completion bash`. Sourcing the completion script in your shell enables kubectl autocompletion. + +However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`). + +### Install bash-completion + +bash-completion is provided by many package managers (see [here](https://github.com/scop/bash-completion#installation)). You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc. + +The above commands create `/usr/share/bash-completion/bash_completion`, which is the main script of bash-completion. Depending on your package manager, you have to manually source this file in your `~/.bashrc` file. + +To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file: + +```bash +source /usr/share/bash-completion/bash_completion +``` + +Reload your shell and verify that bash-completion is correctly installed by typing `type _init_completion`. + +### Enable kubectl autocompletion + +You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this: + +- Source the completion script in your `~/.bashrc` file: + + ```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 +echo 'alias k=kubectl' >>~/.bashrc +echo 'complete -F __start_kubectl k' >>~/.bashrc +``` + +{{< note >}} +bash-completion sources all completion scripts in `/etc/bash_completion.d`. +{{< /note >}} + +Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working. diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md new file mode 100644 index 0000000000..4f4a1771fe --- /dev/null +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md @@ -0,0 +1,89 @@ +--- +title: "bash auto-completion on macOS" +description: "Some optional configuration for bash auto-completion on macOS." +headless: true +--- + +### Introduction + +The kubectl completion script for Bash can be generated with `kubectl completion bash`. Sourcing this script in your shell enables kubectl completion. + +However, the kubectl completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install. + +{{< warning>}} +There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which is the default on macOS), and v2 is for Bash 4.1+. The kubectl completion script **doesn't work** correctly with bash-completion v1 and Bash 3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to correctly use kubectl completion on macOS, you have to install and use Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The following instructions assume that you use Bash 4.1+ (that is, any Bash version of 4.1 or newer). +{{< /warning >}} + +### Upgrade Bash + +The instructions here assume you use Bash 4.1+. You can check your Bash's version by running: + +```bash +echo $BASH_VERSION +``` + +If it is too old, you can install/upgrade it using Homebrew: + +```bash +brew install bash +``` + +Reload your shell and verify that the desired version is being used: + +```bash +echo $BASH_VERSION $SHELL +``` + +Homebrew usually installs it at `/usr/local/bin/bash`. + +### Install bash-completion + +{{< note >}} +As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work). +{{< /note >}} + +You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew: + +```bash +brew install bash-completion@2 +``` + +As stated in the output of this command, add the following to your `~/.bash_profile` file: + +```bash +export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" +[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" +``` + +Reload your shell and verify that bash-completion v2 is correctly installed with `type _init_completion`. + +### Enable kubectl autocompletion + +You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this: + +- Source the completion script in your `~/.bash_profile` file: + + ```bash + echo 'source <(kubectl completion bash)' >>~/.bash_profile + ``` + +- Add the completion script to the `/usr/local/etc/bash_completion.d` directory: + + ```bash + kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl + ``` + +- If you have an alias for kubectl, you can extend shell completion to work with that alias: + + ```bash + echo 'alias k=kubectl' >>~/.bash_profile + echo 'complete -F __start_kubectl k' >>~/.bash_profile + ``` + +- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything. + + {{< note >}} + The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work. + {{< /note >}} + +In any case, after reloading your shell, kubectl completion should be working. \ No newline at end of file diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-zsh.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-zsh.md new file mode 100644 index 0000000000..95c8c0aa71 --- /dev/null +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-zsh.md @@ -0,0 +1,29 @@ +--- +title: "zsh auto-completion" +description: "Some optional configuration for zsh auto-completion." +headless: true +--- + +The kubectl completion script for Zsh can be generated with the command `kubectl completion zsh`. Sourcing the completion script in your shell enables kubectl autocompletion. + +To do so in all your shell sessions, add the following to your `~/.zshrc` file: + +```zsh +source <(kubectl completion zsh) +``` + +If you have an alias for kubectl, you can extend shell completion to work with that alias: + +```zsh +echo 'alias k=kubectl' >>~/.zshrc +echo 'complete -F __start_kubectl k' >>~/.zshrc +``` + +After reloading your shell, kubectl autocompletion should be working. + +If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file: + +```zsh +autoload -Uz compinit +compinit +``` \ No newline at end of file diff --git a/content/en/docs/tasks/tools/included/verify-kubectl.md b/content/en/docs/tasks/tools/included/verify-kubectl.md new file mode 100644 index 0000000000..fbd92e4cb6 --- /dev/null +++ b/content/en/docs/tasks/tools/included/verify-kubectl.md @@ -0,0 +1,34 @@ +--- +title: "verify kubectl install" +description: "How to verify kubectl." +headless: true +--- + +In order for kubectl to find and access a Kubernetes cluster, it needs a +[kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), +which is created automatically when you create a cluster using +[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) +or successfully deploy a Minikube cluster. +By default, kubectl configuration is located at `~/.kube/config`. + +Check that kubectl is properly configured by getting the cluster state: + +```shell +kubectl cluster-info +``` + +If you see a URL response, kubectl is correctly configured to access your cluster. + +If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster. + +``` +The connection to the server was refused - did you specify the right host or port? +``` + +For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like Minikube to be installed first and then re-run the commands stated above. + +If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use: + +```shell +kubectl cluster-info dump +``` \ No newline at end of file diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md new file mode 100644 index 0000000000..12a8d641d8 --- /dev/null +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -0,0 +1,172 @@ +--- +reviewers: +- mikedanese +title: Install and Set Up kubectl on Linux +content_type: task +weight: 10 +card: + name: tasks + weight: 20 + title: Install kubectl on Linux +--- + +## {{% heading "prerequisites" %}} + +You must use a kubectl version that is within one minor version difference of your cluster. +For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. +Using the latest version of kubectl helps avoid unforeseen issues. + +## Install kubectl on Linux + +The following methods exist for installing kubectl on Linux: + +- [Install kubectl binary with curl on Linux](#install-kubectl-binary-with-curl-on-linux) +- [Install using native package management](#install-using-native-package-management) +- [Install using other package management](#install-using-other-package-management) +- [Install on Linux as part of the Google Cloud SDK](#install-on-linux-as-part-of-the-google-cloud-sdk) + +### Install kubectl binary with curl on Linux + +1. Download the latest release with the command: + + ```bash + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" + ``` + + {{< 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: + + ```bash + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl + ``` + {{< /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/linux/amd64/kubectl.sha256" + ``` + + 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 + +{{< tabs name="kubectl_install" >}} +{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}} +sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl +curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - +echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list +sudo apt-get update +sudo apt-get install -y kubectl +{{< /tab >}} + +{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat < /etc/yum.repos.d/kubernetes.repo +[kubernetes] +name=Kubernetes +baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 +enabled=1 +gpgcheck=1 +repo_gpgcheck=1 +gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +EOF +yum install -y kubectl +{{< /tab >}} +{{< /tabs >}} + +### Install using other package management + +{{< tabs name="other_kubectl_install" >}} +{{% tab name="Snap" %}} +If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application. + +```shell +snap install kubectl --classic +kubectl version --client +``` + +{{% /tab %}} + +{{% tab name="Homebrew" %}} +If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install). + +```shell +brew install kubectl +kubectl version --client +``` + +{{% /tab %}} + +{{< /tabs >}} + +### Install on Linux as part of the Google Cloud SDK + +{{< include "included/install-kubectl-gcloud.md" >}} + +## Verify kubectl configuration + +{{< include "included/verify-kubectl.md" >}} + +## Optional kubectl configurations + +### Enable shell autocompletion + +kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing. + +Below are the procedures to set up autocompletion for Bash and Zsh. + +{{< tabs name="kubectl_autocompletion" >}} +{{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}} +{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}} +{{< /tabs >}} + +## {{% heading "whatsnext" %}} + +{{< include "included/kubectl-whats-next.md" >}} diff --git a/content/en/docs/tasks/tools/install-kubectl-macos.md b/content/en/docs/tasks/tools/install-kubectl-macos.md new file mode 100644 index 0000000000..605745c630 --- /dev/null +++ b/content/en/docs/tasks/tools/install-kubectl-macos.md @@ -0,0 +1,160 @@ +--- +reviewers: +- mikedanese +title: Install and Set Up kubectl on macOS +content_type: task +weight: 10 +card: + name: tasks + weight: 20 + title: Install kubectl on macOS +--- + +## {{% heading "prerequisites" %}} + +You must use a kubectl version that is within one minor version difference of your cluster. +For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. +Using the latest version of kubectl helps avoid unforeseen issues. + +## Install kubectl on macOS + +The following methods exist for installing kubectl on macOS: + +- [Install kubectl binary with curl on macOS](#install-kubectl-binary-with-curl-on-macos) +- [Install with Homebrew on macOS](#install-with-homebrew-on-macos) +- [Install with Macports on macOS](#install-with-macports-on-macos) +- [Install on Linux as part of the Google Cloud SDK](#install-on-linux-as-part-of-the-google-cloud-sdk) + +### Install kubectl binary with curl on macOS + +1. Download the latest release: + + ```bash + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" + ``` + + {{< 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://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl + ``` + + {{< /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 + ``` + +1. Move the kubectl binary to a file location on your system `PATH`. + + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl + sudo chown root: /usr/local/bin/kubectl + ``` + +1. Test to ensure the version you installed is up-to-date: + + ```bash + kubectl version --client + ``` + +### Install with Homebrew on macOS + +If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew. + +1. Run the installation command: + + ```bash + brew install kubectl + ``` + + or + + ```bash + brew install kubernetes-cli + ``` + +1. Test to ensure the version you installed is up-to-date: + + ```bash + kubectl version --client + ``` + +### Install with Macports on macOS + +If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports. + +1. Run the installation command: + + ```bash + sudo port selfupdate + sudo port install kubectl + ``` + +1. Test to ensure the version you installed is up-to-date: + + ```bash + kubectl version --client + ``` + + +### Install on macOS as part of the Google Cloud SDK + +{{< include "included/install-kubectl-gcloud.md" >}} + +## Verify kubectl configuration + +{{< include "included/verify-kubectl.md" >}} + +## Optional kubectl configurations + +### Enable shell autocompletion + +kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing. + +Below are the procedures to set up autocompletion for Bash and Zsh. + +{{< tabs name="kubectl_autocompletion" >}} +{{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}} +{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}} +{{< /tabs >}} + +## {{% heading "whatsnext" %}} + +{{< include "included/kubectl-whats-next.md" >}} \ No newline at end of file diff --git a/content/en/docs/tasks/tools/install-kubectl-windows.md b/content/en/docs/tasks/tools/install-kubectl-windows.md new file mode 100644 index 0000000000..09e8217626 --- /dev/null +++ b/content/en/docs/tasks/tools/install-kubectl-windows.md @@ -0,0 +1,179 @@ +--- +reviewers: +- mikedanese +title: Install and Set Up kubectl on Windows +content_type: task +weight: 10 +card: + name: tasks + weight: 20 + title: Install kubectl on Windows +--- + +## {{% heading "prerequisites" %}} + +You must use a kubectl version that is within one minor version difference of your cluster. +For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. +Using the latest version of kubectl helps avoid unforeseen issues. + +## Install kubectl on Windows + +The following methods exist for installing kubectl on Windows: + +- [Install kubectl binary with curl on Windows](#install-kubectl-binary-with-curl-on-windows) +- [Install with PowerShell from PSGallery](#install-with-powershell-from-psgallery) +- [Install on Windows using Chocolatey or Scoop](#install-on-windows-using-chocolatey-or-scoop) +- [Install on Windows as part of the Google Cloud SDK](#install-on-windows-as-part-of-the-google-cloud-sdk) + + +### Install kubectl binary with curl on Windows + +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: + + ```powershell + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` + + {{< 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 >}} + +1. Validate the binary (optional) + + Download the kubectl checksum file: + + ```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`. +{{< /note >}} + +### Install with PowerShell from PSGallery + +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. + {{< /note >}} + + The installer creates `$HOME/.kube` and instructs it to create a config file. + +1. Test to ensure the version you installed is up-to-date: + + ```powershell + kubectl version --client + ``` + +{{< note >}} +Updating the installation is performed by rerunning the two commands listed in step 1. +{{< /note >}} + +### Install on Windows using Chocolatey or Scoop + +1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer. + + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell + choco install kubernetes-cli + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell + scoop install kubectl + ``` + {{% /tab %}} + {{< /tabs >}} + + +1. Test to ensure the version you installed is up-to-date: + + ```powershell + kubectl version --client + ``` + +1. Navigate to your home directory: + + ```powershell + # If you're using cmd.exe, run: cd %USERPROFILE% + cd ~ + ``` + +1. Create the `.kube` directory: + + ```powershell + mkdir .kube + ``` + +1. Change to the `.kube` directory you just created: + + ```powershell + cd .kube + ``` + +1. Configure kubectl to use a remote Kubernetes cluster: + + ```powershell + New-Item config -type file + ``` + +{{< note >}} +Edit the config file with a text editor of your choice, such as Notepad. +{{< /note >}} + +### Install on Windows as part of the Google Cloud SDK + +{{< include "included/install-kubectl-gcloud.md" >}} + +## Verify kubectl configuration + +{{< include "included/verify-kubectl.md" >}} + +## Optional kubectl configurations + +### Enable shell autocompletion + +kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing. + +Below are the procedures to set up autocompletion for Zsh, if you are running that on Windows. + +{{< include "included/optional-kubectl-configs-zsh.md" >}} + +## {{% heading "whatsnext" %}} + +{{< include "included/kubectl-whats-next.md" >}} \ No newline at end of file diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md deleted file mode 100644 index 54f1e7e123..0000000000 --- a/content/en/docs/tasks/tools/install-kubectl.md +++ /dev/null @@ -1,634 +0,0 @@ ---- -reviewers: -- mikedanese -title: Install and Set Up kubectl -content_type: task -weight: 10 -card: - name: tasks - weight: 20 - title: Install kubectl ---- - - -The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows -you to run commands against Kubernetes clusters. -You can use kubectl to deploy applications, inspect and manage cluster resources, -and view logs. For a complete list of kubectl operations, see -[Overview of kubectl](/docs/reference/kubectl/overview/). - - -## {{% heading "prerequisites" %}} - -You must use a kubectl version that is within one minor version difference of your cluster. -For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. -Using the latest version of kubectl helps avoid unforeseen issues. - - - -## Install kubectl on Linux - -### Install kubectl binary with curl on Linux - -1. Download the latest release with the command: - - ```bash - curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" - ``` - - {{< 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: - - ```bash - curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl - ``` - {{< /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/linux/amd64/kubectl.sha256" - ``` - - 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 - -{{< tabs name="kubectl_install" >}} -{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}} -sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl -curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - -echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list -sudo apt-get update -sudo apt-get install -y kubectl -{{< /tab >}} - -{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat < /etc/yum.repos.d/kubernetes.repo -[kubernetes] -name=Kubernetes -baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 -enabled=1 -gpgcheck=1 -repo_gpgcheck=1 -gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg -EOF -yum install -y kubectl -{{< /tab >}} -{{< /tabs >}} - -### Install using other package management - -{{< tabs name="other_kubectl_install" >}} -{{% tab name="Snap" %}} -If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application. - -```shell -snap install kubectl --classic - -kubectl version --client -``` - -{{% /tab %}} - -{{% tab name="Homebrew" %}} -If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install). - -```shell -brew install kubectl - -kubectl version --client -``` - -{{% /tab %}} - -{{< /tabs >}} - - -## Install kubectl on macOS - -### Install kubectl binary with curl on macOS - -1. Download the latest release: - - ```bash - curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" - ``` - - {{< 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://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl - ``` - - {{< /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 - ``` - -1. Move the kubectl binary to a file location on your system `PATH`. - - ```bash - sudo mv ./kubectl /usr/local/bin/kubectl && \ - sudo chown root: /usr/local/bin/kubectl - ``` - -1. Test to ensure the version you installed is up-to-date: - - ```bash - kubectl version --client - ``` - -### Install with Homebrew on macOS - -If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew. - -1. Run the installation command: - - ```bash - brew install kubectl - ``` - - or - - ```bash - brew install kubernetes-cli - ``` - -1. Test to ensure the version you installed is up-to-date: - - ```bash - kubectl version --client - ``` - -### Install with Macports on macOS - -If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports. - -1. Run the installation command: - - ```bash - sudo port selfupdate - sudo port install kubectl - ``` - -1. Test to ensure the version you installed is up-to-date: - - ```bash - kubectl version --client - ``` - -## Install kubectl on Windows - -### Install kubectl binary with curl on Windows - -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: - - ```powershell - curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe - ``` - - {{< 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 >}} - -1. Validate the binary (optional) - - Download the kubectl checksum file: - - ```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`. -{{< /note >}} - -### Install with PowerShell from PSGallery - -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. - {{< /note >}} - - The installer creates `$HOME/.kube` and instructs it to create a config file. - -1. Test to ensure the version you installed is up-to-date: - - ```powershell - kubectl version --client - ``` - -{{< note >}} -Updating the installation is performed by rerunning the two commands listed in step 1. -{{< /note >}} - -### Install on Windows using Chocolatey or Scoop - -1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer. - - {{< tabs name="kubectl_win_install" >}} - {{% tab name="choco" %}} - ```powershell - choco install kubernetes-cli - ``` - {{% /tab %}} - {{% tab name="scoop" %}} - ```powershell - scoop install kubectl - ``` - {{% /tab %}} - {{< /tabs >}} - - -1. Test to ensure the version you installed is up-to-date: - - ```powershell - kubectl version --client - ``` - -1. Navigate to your home directory: - - ```powershell - # If you're using cmd.exe, run: cd %USERPROFILE% - cd ~ - ``` - -1. Create the `.kube` directory: - - ```powershell - mkdir .kube - ``` - -1. Change to the `.kube` directory you just created: - - ```powershell - cd .kube - ``` - -1. Configure kubectl to use a remote Kubernetes cluster: - - ```powershell - New-Item config -type file - ``` - -{{< note >}} -Edit the config file with a text editor of your choice, such as Notepad. -{{< /note >}} - -## Download as part of the Google Cloud SDK - -You can install kubectl as part of the Google Cloud SDK. - -1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/). - -1. Run the `kubectl` installation command: - - ```shell - gcloud components install kubectl - ``` - -1. Test to ensure the version you installed is up-to-date: - - ```shell - kubectl version --client - ``` - -## Verifying kubectl configuration - -In order for kubectl to find and access a Kubernetes cluster, it needs a -[kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), -which is created automatically when you create a cluster using -[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) -or successfully deploy a Minikube cluster. -By default, kubectl configuration is located at `~/.kube/config`. - -Check that kubectl is properly configured by getting the cluster state: - -```shell -kubectl cluster-info -``` - -If you see a URL response, kubectl is correctly configured to access your cluster. - -If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster. - -``` -The connection to the server was refused - did you specify the right host or port? -``` - -For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like Minikube to be installed first and then re-run the commands stated above. - -If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use: - -```shell -kubectl cluster-info dump -``` - -## Optional kubectl configurations - -### Enabling shell autocompletion - -kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing. - -Below are the procedures to set up autocompletion for Bash (including the difference between Linux and macOS) and Zsh. - -{{< tabs name="kubectl_autocompletion" >}} - -{{% tab name="Bash on Linux" %}} - -### Introduction - -The kubectl completion script for Bash can be generated with the command `kubectl completion bash`. Sourcing the completion script in your shell enables kubectl autocompletion. - -However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`). - -### Install bash-completion - -bash-completion is provided by many package managers (see [here](https://github.com/scop/bash-completion#installation)). You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc. - -The above commands create `/usr/share/bash-completion/bash_completion`, which is the main script of bash-completion. Depending on your package manager, you have to manually source this file in your `~/.bashrc` file. - -To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file: - -```bash -source /usr/share/bash-completion/bash_completion -``` - -Reload your shell and verify that bash-completion is correctly installed by typing `type _init_completion`. - -### Enable kubectl autocompletion - -You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this: - -- Source the completion script in your `~/.bashrc` file: - - ```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 -echo 'alias k=kubectl' >>~/.bashrc -echo 'complete -F __start_kubectl k' >>~/.bashrc -``` - -{{< note >}} -bash-completion sources all completion scripts in `/etc/bash_completion.d`. -{{< /note >}} - -Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working. - -{{% /tab %}} - - -{{% tab name="Bash on macOS" %}} - - -### Introduction - -The kubectl completion script for Bash can be generated with `kubectl completion bash`. Sourcing this script in your shell enables kubectl completion. - -However, the kubectl completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install. - -{{< warning>}} -There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which is the default on macOS), and v2 is for Bash 4.1+. The kubectl completion script **doesn't work** correctly with bash-completion v1 and Bash 3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to correctly use kubectl completion on macOS, you have to install and use Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The following instructions assume that you use Bash 4.1+ (that is, any Bash version of 4.1 or newer). -{{< /warning >}} - -### Upgrade Bash - -The instructions here assume you use Bash 4.1+. You can check your Bash's version by running: - -```bash -echo $BASH_VERSION -``` - -If it is too old, you can install/upgrade it using Homebrew: - -```bash -brew install bash -``` - -Reload your shell and verify that the desired version is being used: - -```bash -echo $BASH_VERSION $SHELL -``` - -Homebrew usually installs it at `/usr/local/bin/bash`. - -### Install bash-completion - -{{< note >}} -As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work). -{{< /note >}} - -You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew: - -```bash -brew install bash-completion@2 -``` - -As stated in the output of this command, add the following to your `~/.bash_profile` file: - -```bash -export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" -[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" -``` - -Reload your shell and verify that bash-completion v2 is correctly installed with `type _init_completion`. - -### Enable kubectl autocompletion - -You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this: - -- Source the completion script in your `~/.bash_profile` file: - - ```bash - echo 'source <(kubectl completion bash)' >>~/.bash_profile - ``` - -- Add the completion script to the `/usr/local/etc/bash_completion.d` directory: - - ```bash - kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl - ``` - -- If you have an alias for kubectl, you can extend shell completion to work with that alias: - - ```bash - echo 'alias k=kubectl' >>~/.bash_profile - echo 'complete -F __start_kubectl k' >>~/.bash_profile - ``` - -- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything. - - {{< note >}} - The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work. - {{< /note >}} - -In any case, after reloading your shell, kubectl completion should be working. -{{% /tab %}} - -{{% tab name="Zsh" %}} - -The kubectl completion script for Zsh can be generated with the command `kubectl completion zsh`. Sourcing the completion script in your shell enables kubectl autocompletion. - -To do so in all your shell sessions, add the following to your `~/.zshrc` file: - -```zsh -source <(kubectl completion zsh) -``` - -If you have an alias for kubectl, you can extend shell completion to work with that alias: - -```zsh -echo 'alias k=kubectl' >>~/.zshrc -echo 'complete -F __start_kubectl k' >>~/.zshrc -``` - -After reloading your shell, kubectl autocompletion should be working. - -If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file: - -```zsh -autoload -Uz compinit -compinit -``` -{{% /tab %}} -{{< /tabs >}} - -## {{% heading "whatsnext" %}} - -* [Install Minikube](https://minikube.sigs.k8s.io/docs/start/) -* See the [getting started guides](/docs/setup/) for more about creating clusters. -* [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/) -* If you need access to a cluster you didn't create, see the - [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). -* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/) - diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md index ba115b601c..4bd6a9a82c 100644 --- a/content/en/docs/tutorials/hello-minikube.md +++ b/content/en/docs/tutorials/hello-minikube.md @@ -59,6 +59,22 @@ If you installed minikube locally, run `minikube start`. 4. Katacoda environment only: Type `30000`, and then click **Display Port**. +{{< note >}} +The `dashboard` command enables the dashboard add-on and opens the proxy in the default web browser. You can create Kubernetes resources on the dashboard such as Deployment and Service. + +If you are running in an environment as root, see [Open Dashboard with URL](/docs/tutorials/hello-minikube#open-dashboard-with-url). + +To stop the proxy, run `Ctrl+C` to exit the process. The dashboard remains running. +{{< /note >}} + +## Open Dashboard with URL + +If you don't want to open a web browser, run the dashboard command with the url flag to emit a URL: + +```shell +minikube dashboard --url +``` + ## Create a Deployment A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers, diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 2ee67382fd..15b6d00a6c 100644 --- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -31,7 +31,7 @@ weight: 10 Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it. To do so, you create a Kubernetes Deployment configuration. The Deployment instructs Kubernetes how to create and update instances of your application. Once you've created a Deployment, the Kubernetes - master schedules the application instances included in that Deployment to run on individual Nodes in the + control plane schedules the application instances included in that Deployment to run on individual Nodes in the cluster.

diff --git a/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg b/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg index e0ae8fa504..cf8c922916 100644 --- a/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg +++ b/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg @@ -1,5 +1,32 @@ - -
+そして、`$VERSION`にKubernetesのバージョンに合わせたCRI-Oのバージョンを設定します。例えば、CRI-O 1.18をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3をインストールするには、`VERSION=1.18:1.18.3` を設定します。 +
+ +以下を実行します。 ```shell -# Debian Unstable/Sid -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list + +curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add - +curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add - + +apt-get update +apt-get install cri-o cri-o-runc ``` -```shell -# Debian Testing -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - -``` -```shell -# Debian 10 -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - -``` +{{% /tab %}} -```shell -# Raspbian 10 -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - -``` +{{% tab name="Ubuntu" %}} -それでは、CRI-Oをインストールします: + CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。 + +| Operating system | $OS | +| ---------------- | ----------------- | +| Ubuntu 20.04 | `xUbuntu_20.04` | +| Ubuntu 19.10 | `xUbuntu_19.10` | +| Ubuntu 19.04 | `xUbuntu_19.04` | +| Ubuntu 18.04 | `xUbuntu_18.04` | + +
+次に、`$VERSION`をKubernetesのバージョンと一致するCRI-Oのバージョンに設定します。例えば、CRI-O 1.18をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3 をインストールするには、`VERSION=1.18:1.18.3` を設定します。 +
+ +以下を実行します。 ```shell -sudo apt-get install cri-o-1.17 +echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list + +curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add - +curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add - + +apt-get update +apt-get install cri-o cri-o-runc ``` {{% /tab %}} -{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} +{{% tab name="CentOS" %}} + CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。 + +| Operating system | $OS | +| ---------------- | ----------------- | +| Centos 8 | `CentOS_8` | +| Centos 8 Stream | `CentOS_8_Stream` | +| Centos 7 | `CentOS_7` | + +
+次に、`$VERSION`をKubernetesのバージョンと一致するCRI-Oのバージョンに設定します。例えば、CRI-O 1.18 をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3 をインストールするには、`VERSION=1.18:1.18.3` を設定します。 +
+ +以下を実行します。 ```shell -# パッケージレポジトリを設定する -. /etc/os-release -sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - -sudo apt-get update +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo +yum install cri-o ``` -```shell -# CRI-Oのインストール -sudo apt-get install cri-o-1.17 -``` -{{% /tab %}} - -{{% tab name="CentOS/RHEL 7.4+" %}} - -```shell -# 必要なパッケージのインストール -curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo -curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo -``` - -```shell -# CRI-Oのインストール -yum install -y cri-o -``` {{% /tab %}} {{% tab name="openSUSE Tumbleweed" %}} ```shell -sudo zypper install cri-o + sudo zypper install cri-o ``` +{{% /tab %}} +{{% tab name="Fedora" %}} + +$VERSIONには、Kubernetesのバージョンと一致するCRI-Oのバージョンを設定します。例えば、CRI-O 1.18をインストールしたい場合は、$VERSION=1.18を設定します。 +以下のコマンドで、利用可能なバージョンを見つけることができます。 +```shell +dnf module list cri-o +``` +CRI-OはFedoraの特定のリリースにピン留めすることをサポートしていません。 + +以下を実行します。 +```shell +dnf module enable cri-o:$VERSION +dnf install cri-o +``` + {{% /tab %}} {{< /tabs >}} + ### CRI-Oの起動 ```shell @@ -321,7 +355,7 @@ sysctl --system ### containerdのインストール {{< tabs name="tab-cri-containerd-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{% tab name="Ubuntu 16.04" %}} ```shell # (containerdのインストール) @@ -335,7 +369,7 @@ apt-get update && apt-get install -y apt-transport-https ca-certificates curl so curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - ``` -``` +```shell ## Dockerのaptリポジトリの追加 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ diff --git a/content/ja/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/ja/docs/setup/production-environment/on-premises-vm/cloudstack.md index 1177bcdd94..296e105683 100644 --- a/content/ja/docs/setup/production-environment/on-premises-vm/cloudstack.md +++ b/content/ja/docs/setup/production-environment/on-premises-vm/cloudstack.md @@ -7,7 +7,7 @@ content_type: concept [CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes. -[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions. +[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions. This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init. diff --git a/content/ja/docs/setup/production-environment/tools/kops.md b/content/ja/docs/setup/production-environment/tools/kops.md index 92899a300a..dfd2eec406 100644 --- a/content/ja/docs/setup/production-environment/tools/kops.md +++ b/content/ja/docs/setup/production-environment/tools/kops.md @@ -27,7 +27,7 @@ kops is an automated provisioning system: * You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture. -* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. +* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user). @@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde but not under `example.com`). Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using -the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or +the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`. You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here, @@ -231,7 +231,7 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl ## {{% heading "whatsnext" %}} -* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/). +* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/). * Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options. * Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) * Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 9c096a6698..9a47644bf6 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -1,12 +1,12 @@ --- -title: kubeadmを使用したシングルコントロールプレーンクラスターの作成 +title: kubeadmを使用したクラスターの作成 content_type: task weight: 30 --- -`kubeadm`ツールは、ベストプラクティスに準拠した実用最小限のKubernetesクラスターをブートストラップする手助けをします。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。 +ベストプラクティスに準拠した実用最小限のKubernetesクラスターを作成します。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。 `kubeadm`ツールは、次のようなときに適しています。 @@ -41,7 +41,7 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。 ## 目的 -* シングルコントロールプレーンのKubernetesクラスターまたは[高可用性クラスター](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)をインストールする +* シングルコントロールプレーンのKubernetesクラスターをインストールする * クラスター上にPodネットワークをインストールして、Podがお互いに通信できるようにする ## 手順 @@ -76,7 +76,7 @@ kubeadm init `--apiserver-advertise-address`は、この特定のコントロールプレーンノードのAPIサーバーへのadvertise addressを設定するために使えますが、`--control-plane-endpoint`は、すべてのコントロールプレーンノード共有のエンドポイントを設定するために使えます。 -`--control-plane-endpoint`はIPアドレスを受け付けますが、IPアドレスへマッピングされるDNSネームも使用できます。利用可能なソリューションをそうしたマッピングの観点から評価するには、ネットワーク管理者に相談してください。 +`--control-plane-endpoint`はIPアドレスと、IPアドレスへマッピングできるDNS名を使用できます。利用可能なソリューションをそうしたマッピングの観点から評価するには、ネットワーク管理者に相談してください。 以下にマッピングの例を示します。 @@ -203,9 +203,14 @@ export KUBECONFIG=/etc/kubernetes/admin.conf {{< /caution >}} -CNIを使用するKubernetes Podネットワークを提供する外部のプロジェクトがいくつかあります。一部のプロジェクトでは、[ネットワークポリシー](/docs/concepts/services-networking/networkpolicies/)もサポートしています。 +{{< note >}} +現在、Calicoはkubeadmプロジェクトがe2eテストを実施している唯一のCNIプラグインです。 +もしCNIプラグインに関する問題を見つけた場合、kubeadmやkubernetesではなく、そのCNIプラグインの課題管理システムへ問題を報告してください。 +{{< /note >}} -利用できる[ネットワークアドオンとネットワークポリシーアドオン](/docs/concepts/cluster-administration/addons/#networking-and-network-policy)のリストを確認してください。 +CNIを使用するKubernetes Podネットワークを提供する外部のプロジェクトがいくつかあります。一部のプロジェクトでは、[ネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/)もサポートしています。 + +[Kubernetesのネットワークモデル](/ja/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model)を実装したアドオンの一覧も確認してください。 Podネットワークアドオンをインストールするには、コントロールプレーンノード上またはkubeconfigクレデンシャルを持っているノード上で、次のコマンドを実行します。 @@ -213,91 +218,7 @@ Podネットワークアドオンをインストールするには、コント kubectl apply -f ``` -インストールできるPodネットワークは、クラスターごとに1つだけです。以下の手順で、いくつかのよく使われるPodネットワークプラグインをインストールできます。 - -{{< tabs name="tabs-pod-install" >}} - -{{% tab name="Calico" %}} -[Calico](https://docs.projectcalico.org/latest/introduction/)は、ネットワークとネットワークポリシーのプロバイダーです。Calicoは柔軟なさまざまなネットワークオプションをサポートするため、自分の状況に適した最も効果的なオプションを選択できます。たとえば、ネットワークのオーバーレイの有無や、BGPの有無が選べます。Calicoは、ホスト、Pod、(もしIstioとEnvoyを使っている場合)サービスメッシュレイヤー上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用しています。Calicoは、`amd64`、`arm64`、`ppc64le`を含む複数のアーキテクチャで動作します。 - -デフォルトでは、Calicoは`192.168.0.0/16`をPodネットワークのCIDRとして使いますが、このCIDRはcalico.yamlファイルで設定できます。Calicoを正しく動作させるためには、これと同じCIDRを`--pod-network-cidr=192.168.0.0/16`フラグまたはkubeadmの設定を使って、`kubeadm init`コマンドに渡す必要があります。 - -```shell -kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml -``` - -{{% /tab %}} - -{{% tab name="Cilium" %}} -Ciliumを正しく動作させるためには、`kubeadm init`に `--pod-network-cidr=10.217.0.0/16`を渡さなければなりません。 - -Ciliumのデプロイは、次のコマンドを実行するだけでできます。 - -```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml -``` - -すべてのCilium Podが`READY`とマークされたら、クラスターを使い始められます。 - -```shell -kubectl get pods -n kube-system --selector=k8s-app=cilium -``` - -出力は次のようになります。 - -``` -NAME READY STATUS RESTARTS AGE -cilium-drxkl 1/1 Running 0 18m -``` - -Ciliumはkube-proxyの代わりに利用することもできます。詳しくは[Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free)を読んでください。 - -KubernetesでのCiliumの使い方に関するより詳しい情報は、[Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/)を参照してください。 -{{% /tab %}} - -{{% tab name="Contiv-VPP" %}} -[Contiv-VPP](https://contivpp.io/)は、[FD.io VPP](https://fd.io/)をベースとするプログラマブルなCNF vSwitchを採用し、機能豊富で高性能なクラウドネイティブなネットワーキングとサービスを提供します。 - -Contiv-VPPは、k8sサービスとネットワークポリシーを(VPP上の)ユーザースペースで実装しています。 - -こちらのインストールガイドを参照してください: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md) -{{% /tab %}} - -{{% tab name="Flannel" %}} -`flannel`を正しく動作させるためには、`--pod-network-cidr=10.244.0.0/16`を`kubeadm init`に渡す必要があります。 - -オーバーレイネットワークに参加しているすべてのホスト上で、ファイアウォールのルールが、UDPポート8285と8472のトラフィックを許可するように設定されていることを確認してください。この設定に関するより詳しい情報は、Flannelのトラブルシューティングガイドの[Firewall](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls)のセクションを参照してください。 - -Flannelは、Linux下の`amd64`、`arm`、`arm64`、`ppc64le`、`s390x`アーキテクチャ上で動作します。Windows(`amd64`)はv0.11.0でサポートされたとされていますが、使用方法はドキュメントに書かれていません。 - -```shell -kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml -``` - -`flannel`に関するより詳しい情報は、[GitHub上のCoreOSのflannelリポジトリ](https://github.com/coreos/flannel)を参照してください。 -{{% /tab %}} - -{{% tab name="Kube-router" %}} -Kube-routerは、ノードへのPod CIDRの割り当てをkube-controller-managerに依存しています。そのため、`kubeadm init`時に`--pod-network-cidr`フラグを使用する必要があります。 - -Kube-routerは、Podネットワーク、ネットワークポリシー、および高性能なIP Virtual Server(IPVS)/Linux Virtual Server(LVS)ベースのサービスプロキシーを提供します。 - -Kube-routerを有効にしたKubernetesクラスターをセットアップするために`kubeadm`ツールを使用する方法については、公式の[セットアップガイド](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md)を参照してください。 -{{% /tab %}} - -{{% tab name="Weave Net" %}} -Weave Netを使用してKubernetesクラスターをセットアップするより詳しい情報は、[アドオンを使用してKubernetesを統合する](https://www.weave.works/docs/net/latest/kube-addon/)を読んでください。 - -Weave Netは、`amd64`、`arm`、`arm64`、`ppc64le`プラットフォームで追加の操作なしで動作します。Weave Netはデフォルトでharipinモードをセットします。このモードでは、Pod同士はPodIPを知らなくても、Service IPアドレス経由でアクセスできます。 - -```shell -kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" -``` - -{{% /tab %}} - -{{< /tabs >}} - +インストールできるPodネットワークは、クラスターごとに1つだけです。 Podネットワークがインストールされたら、`kubectl get pods --all-namespaces`の出力結果でCoreDNS Podが`Running`状態であることをチェックすることで、ネットワークが動作していることを確認できます。そして、一度CoreDNS Podが動作すれば、続けてノードを追加できます。 @@ -375,7 +296,7 @@ openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outfor ``` {{< note >}} -IPv6タプルを`:`に指定するためには、IPv6アドレスをブラケットで囲みます。たとえば、`[fd00::101]:2073`のように書きます。 +IPv6タプルを`:`と指定するためには、IPv6アドレスを角括弧で囲みます。たとえば、`[fd00::101]:2073`のように書きます。 {{< /note >}} 出力は次のようになります。 @@ -407,7 +328,7 @@ kubectl --kubeconfig ./admin.conf get nodes {{< note >}} 上の例では、rootユーザーに対するSSH接続が有効であることを仮定しています。もしそうでない場合は、`admin.conf`ファイルを誰か他のユーザーからアクセスできるようにコピーした上で、代わりにそのユーザーを使って`scp`してください。 -`admin.conf`ファイルはユーザーにクラスターに対する _特権ユーザー_ の権限を与えます。そのため、このファイルを使うのは控えめにしなければなりません。通常のユーザーには、一部の権限をホワイトリストに加えたユニークなクレデンシャルを生成することを推奨します。これには、`kubeadm alpha kubeconfig user --client-name `コマンドが使えます。このコマンドを実行すると、KubeConfigファイルがSTDOUTに出力されるので、ファイルに保存してユーザーに配布します。その後、`kubectl create (cluster)rolebinding`コマンドを使って権限をホワイトリストに加えます。 +`admin.conf`ファイルはユーザーにクラスターに対する _特権ユーザー_ の権限を与えます。そのため、このファイルを使うのは控えめにしなければなりません。通常のユーザーには、明示的に許可した権限を持つユニークなクレデンシャルを生成することを推奨します。これには、`kubeadm alpha kubeconfig user --client-name `コマンドが使えます。このコマンドを実行すると、KubeConfigファイルがSTDOUTに出力されるので、ファイルに保存してユーザーに配布します。その後、`kubectl create (cluster)rolebinding`コマンドを使って権限を付与します。 {{< /note >}} ### (オプション)APIサーバーをlocalhostへプロキシする @@ -433,10 +354,9 @@ kubectl --kubeconfig ./admin.conf proxy ```bash kubectl drain --delete-local-data --force --ignore-daemonsets -kubectl delete node ``` -その後、ノードが削除されたら、`kubeadm`のインストール状態をすべてリセットします。 +ノードが削除される前に、`kubeadm`によってインストールされた状態をリセットします。 ```bash kubeadm reset @@ -454,6 +374,11 @@ IPVS tablesをリセットしたい場合は、次のコマンドを実行する ipvsadm -C ``` +ノードを削除します。 +```bash +kubectl delete node +``` + クラスターのセットアップを最初から始めたいときは、`kubeadm init`や`kubeadm join`を適切な引数を付けて実行すればいいだけです。 ### コントロールプレーンのクリーンアップ @@ -469,7 +394,7 @@ ipvsadm -C * [Sonobuoy](https://github.com/heptio/sonobuoy)を使用してクラスターが適切に動作しているか検証する。 * `kubeadm`を使用したクラスターをアップグレードする方法について、[kubeadmクラスターをアップグレードする](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を読む。 * `kubeadm`の高度な利用方法について[kubeadmリファレンスドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm)で学ぶ。 -* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/docs/user-guide/kubectl-overview/)についてもっと学ぶ。 +* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/ja/docs/reference/kubectl/overview/)についてもっと学ぶ。 * Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/docs/concepts/cluster-administration/networking/)で確認する。 * ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/docs/concepts/cluster-administration/addons/)で確認する。 * クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。 @@ -486,9 +411,9 @@ ipvsadm -C ## バージョン互換ポリシー {#version-skew-policy} -バージョンvX.Yの`kubeadm`ツールは、バージョンvX.YまたはvX.(Y-1)のコントロールプレーンを持つクラスターをデプロイできます。また、`kubeadm` vX.Yは、kubeadmで構築された既存のvX.(Y-1)のクラスターをアップグレートできます。 +バージョンv{{< skew latestVersion >}}の`kubeadm`ツールは、バージョンv{{< skew latestVersion >}}またはv{{< skew prevMinorVersion >}}のコントロールプレーンを持つクラスターをデプロイできます。また、バージョンv{{< skew latestVersion >}}の`kubeadm`は、バージョンv{{< skew prevMinorVersion >}}のkubeadmで構築されたクラスターをアップグレートできます。 -未来を見ることはできないため、kubeadm CLI vX.YはvX.(Y+1)をデプロイすることはできません。 +未来を見ることはできないため、kubeadm CLI v{{< skew latestVersion >}}はv{{< skew nextMinorVersion >}}をデプロイできないかもしれません。 例: `kubeadm` v1.8は、v1.7とv1.8のクラスターをデプロイでき、v1.7のkubeadmで構築されたクラスターをv1.8にアップグレートできます。 @@ -507,7 +432,7 @@ kubeletとコントロールプレーンの間や、他のKubernetesコンポー * 定期的に[etcdをバックアップ](https://coreos.com/etcd/docs/latest/admin_guide.html)する。kubeadmが設定するetcdのデータディレクトリは、コントロールプレーンノードの`/var/lib/etcd`にあります。 -* 複数のコントロールプレーンノードを使用する。[高可用性トポロジーのオプション](/docs/setup/production-environment/tools/kubeadm/ha-topology/)では、より高い可用性を提供するクラスターのトポロジーの選択について説明してます。 +* 複数のコントロールプレーンノードを使用する。[高可用性トポロジーのオプション](/ja/docs/setup/production-environment/tools/kubeadm/ha-topology/)では、[より高い可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)を提供するクラスターのトポロジーの選択について説明してます。 ### プラットフォームの互換性 {#multi-platform} @@ -520,4 +445,3 @@ kubeadmのdeb/rpmパッケージおよびバイナリは、[multi-platform propo ## トラブルシューティング {#troubleshooting} kubeadmに関する問題が起きたときは、[トラブルシューティングドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)を確認してください。 - diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md index fa3468e1d1..f06a8142a3 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -15,7 +15,10 @@ HAクラスターは次の方法で設定できます。 HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。 - +{{< note >}} +kubeadmは、etcdクラスターを静的にブートストラップします。 +詳細については、etcd[クラスタリングガイド](https://github.com/etcd-io/etcd/blob/release-3.4/Documentation/op-guide/clustering.md#static)をご覧ください。 +{{< /note >}} diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md index 6b7cb8b610..1d5e3f9aaf 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -57,10 +57,10 @@ weight: 60 - ロードバランサーは、apiserverポートで、全てのコントロールプレーンノードと通信できなければなりません。また、リスニングポートに対する流入トラフィックも許可されていなければなりません。 - - [HAProxy](http://www.haproxy.org/)をロードバランサーとして使用することができます。 - - ロードバランサーのアドレスは、常にkubeadmの`ControlPlaneEndpoint`のアドレスと一致することを確認してください。 + - 詳細は[Options for Software Load Balancing](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)をご覧ください。 + 1. ロードバランサーに、最初のコントロールプレーンノードを追加し、接続をテストする: ```sh @@ -87,7 +87,7 @@ weight: 60 {{< note >}}`kubeadm init`の`--config`フラグと`--certificate-key`フラグは混在させることはできないため、[kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用する場合は`certificateKey`フィールドを適切な場所に追加する必要があります(`InitConfiguration`と`JoinConfiguration: controlPlane`の配下)。{{< /note >}} - {{< note >}}CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。{{< /note >}} + {{< note >}}いくつかのCNIネットワークプラグインはPodのIPのCIDRの指定など追加の設定を必要としますが、必要としないプラグインもあります。[CNIネットワークドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。{{< /note >}} - このような出力がされます: diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index e061315381..27dd20b1bf 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -64,7 +64,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub ### `kubeadm init`実行時の流れ -`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`.X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。 +`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。 二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。 @@ -99,7 +99,7 @@ kubeletが新たな設定を読み込むと、kubeadmは、KubeConfigファイ `kubeadm`には、systemdがどのようにkubeletを実行するかを指定した設定ファイルが同梱されています。 kubeadm CLIコマンドは決してこのsystemdファイルには触れないことに注意してください。 -kubeadmの[DEBパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。 +kubeadmの[DEBパッケージ](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubeadm/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。 ```none [Service] @@ -134,6 +134,5 @@ Kubernetesに同梱されるDEB、RPMのパッケージは以下の通りです | `kubeadm` | `/usr/bin/kubeadm`CLIツールと、[kubelet用のsystemdファイル](#the-kubelet-drop-in-file-for-systemd)をインストールします。 | | `kubelet` | kubeletバイナリを`/usr/bin`に、CNIバイナリを`/opt/cni/bin`にインストールします。 | | `kubectl` | `/usr/bin/kubectl`バイナリをインストールします。 | -| `kubernetes-cni` | 公式のCNIバイナリを`/opt/cni/bin`ディレクトリにインストールします。 | | `cri-tools` | `/usr/bin/crictl`バイナリを[cri-tools gitリポジトリ](https://github.com/kubernetes-incubator/cri-tools)からインストールします。 | diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md index a7bee37727..9a6ceccb25 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/self-hosting.md @@ -1,68 +1,48 @@ --- -title: Configuring your kubernetes cluster to self-host the control plane +title: コントロールプレーンをセルフホストするようにkubernetesクラスターを構成する content_type: concept weight: 100 --- -### Self-hosting the Kubernetes control plane {#self-hosting} +### コントロールプレーンのセルフホスティング {#self-hosting} -kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control -plane. This means that key components such as the API server, controller -manager, and scheduler run as [DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/) -configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/) -configured in the kubelet via static files. +kubeadmを使用すると、セルフホスト型のKubernetesコントロールプレーンを実験的に作成できます。これはAPIサーバー、コントローラーマネージャー、スケジューラーなどの主要コンポーネントは、静的ファイルを介してkubeletで構成された[static pods](/docs/tasks/configure-pod-container/static-pod/)ではなく、Kubernetes APIを介して構成された[DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/)として実行されることを意味します。 -To create a self-hosted cluster see the -[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command. +セルフホスト型クラスターを作成する場合は[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)を参照してください。 -#### Caveats +#### 警告 {{< caution >}} -This feature pivots your cluster into an unsupported state, rendering kubeadm unable -to manage you cluster any longer. This includes `kubeadm upgrade`. +この機能により、クラスターがサポートされていない状態になり、kubeadmがクラスターを管理できなくなります。これには`kubeadm upgrade`が含まれます。 {{< /caution >}} -1. Self-hosting in 1.8 and later has some important limitations. In particular, a - self-hosted cluster _cannot recover from a reboot of the control-plane node_ - without manual intervention. +1. 1.8以降のセルフホスティングには、いくつかの重要な制限があります。特に、セルフホスト型クラスターは、手動の介入なしにコントロールプレーンのNode再起動から回復することはできません。 -1. By default, self-hosted control plane Pods rely on credentials loaded from - [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - volumes. Except for initial creation, these credentials are not managed by - kubeadm. +1. デフォルトでは、セルフホスト型のコントロールプレーンのPodは、[`hostPath`](/docs/concepts/storage/volumes/#hostpath)ボリュームからロードされた資格情報に依存しています。最初の作成を除いて、これらの資格情報はkubeadmによって管理されません。 -1. The self-hosted portion of the control plane does not include etcd, - which still runs as a static Pod. +1. コントロールプレーンのセルフホストされた部分にはetcdが含まれていませんが、etcdは静的Podとして実行されます。 -#### Process +#### プロセス -The self-hosting bootstrap process is documented in the [kubeadm design -document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting). +セルフホスティングのブートストラッププロセスは、[kubeadm design +document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)に記載されています。 -In summary, `kubeadm alpha selfhosting` works as follows: +要約すると、`kubeadm alpha selfhosting`は次のように機能します。 - 1. Waits for this bootstrap static control plane to be running and - healthy. This is identical to the `kubeadm init` process without self-hosting. + 1. 静的コントロールプレーンのブートストラップが起動し、正常になるのを待ちます。これは`kubeadm init`のセルフホスティングを使用しないプロセスと同じです。 - 1. Uses the static control plane Pod manifests to construct a set of - DaemonSet manifests that will run the self-hosted control plane. - It also modifies these manifests where necessary, for example adding new volumes - for secrets. + 1. 静的コントロールプレーンのPodのマニフェストを使用して、セルフホスト型コントロールプレーンを実行する一連のDaemonSetのマニフェストを構築します。また、必要に応じてこれらのマニフェストを変更します。たとえば、シークレット用の新しいボリュームを追加します。 - 1. Creates DaemonSets in the `kube-system` namespace and waits for the - resulting Pods to be running. + 1. `kube-system`のネームスペースにDaemonSetを作成し、Podの結果が起動されるのを待ちます。 - 1. Once self-hosted Pods are operational, their associated static Pods are deleted - and kubeadm moves on to install the next component. This triggers kubelet to - stop those static Pods. + 1. セルフホスト型のPodが操作可能になると、関連する静的Podが削除され、kubeadmは次のコンポーネントのインストールに進みます。これによりkubeletがトリガーされて静的Podが停止します。 - 1. When the original static control plane stops, the new self-hosted control - plane is able to bind to listening ports and become active. + 1. 元の静的なコントロールプレーンが停止すると、新しいセルフホスト型コントロールプレーンはリスニングポートにバインドしてアクティブになります。 diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 0d73dc2df6..356101574d 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -29,7 +29,8 @@ when using kubeadm to set up a kubernetes cluster. * Three hosts that can talk to each other over ports 2379 and 2380. This document assumes these default ports. However, they are configurable through the kubeadm config file. -* Each host must [have docker, kubelet, and kubeadm installed][toolbox]. +* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). +* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using `kubeadm config images list/pull`. This guide will setup etcd instances as [static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet. * Some infrastructure to copy files between hosts. For example `ssh` and `scp` can satisfy this requirement. diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 8e9067a4eb..b6911ba298 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -6,68 +6,100 @@ weight: 20 -As with any program, you might run into an error installing or running kubeadm. -This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem. +どのプログラムでもそうですが、kubeadmのインストールや実行でエラーが発生することがあります。このページでは、一般的な失敗例をいくつか挙げ、問題を理解して解決するための手順を示しています。 -If your problem is not listed below, please follow the following steps: - -- If you think your problem is a bug with kubeadm: - - Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues. - - If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template. - -- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include - relevant tags like `#kubernetes` and `#kubeadm` so folks can help you. +本ページに問題が記載されていない場合は、以下の手順を行ってください: +- 問題がkubeadmのバグによるものと思った場合: + - [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues)にアクセスして、既存のIssueを探してください。 + - Issueがない場合は、テンプレートにしたがって[新しくIssueを立ててください](https://github.com/kubernetes/kubeadm/issues/new)。 +- kubeadmがどのように動作するかわからない場合は、[Slack](http://slack.k8s.io/)の#kubeadmチャンネルで質問するか、[StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes)で質問をあげてください。その際は、他の方が助けを出しやすいように`#kubernetes`や`#kubeadm`といったタグをつけてください。 +## RBACがないため、v1.18ノードをv1.17クラスタに結合できない +v1.18では、同名のノードが既に存在する場合にクラスタ内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。 + +しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスタに参加できないという問題が発生します。 + +この問題を回避するには、次の2つの方法があります。 +- kubeadm v1.18を用いて、コントロールプレーンノード上で`kubeadm init phase bootstrap-token`を実行します。 +これには、ブートストラップトークンの残りのパーミッションも同様に有効にすることに注意してください。 + +- `kubectl apply -f ...`を使って以下のRBACを手動で適用します。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: kubeadm:get-nodes +rules: +- apiGroups: + - "" + resources: + - nodes + verbs: + - get +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: kubeadm:get-nodes +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: kubeadm:get-nodes +subjects: +- apiGroup: rbac.authorization.k8s.io + kind: Group + name: system:bootstrappers:kubeadm:default-node-token +``` + ## インストール中に`ebtables`もしくは他の似たような実行プログラムが見つからない -If you see the following warnings while running `kubeadm init` +`kubeadm init`の実行中に以下のような警告が表示された場合は、以降に記載するやり方を行ってください。 ```sh [preflight] WARNING: ebtables not found in system path [preflight] WARNING: ethtool not found in system path ``` -Then you may be missing `ebtables`, `ethtool` or a similar executable on your node. You can install them with the following commands: +このような場合、ノード上に`ebtables`, `ethtool`などの実行ファイルがない可能性があります。これらをインストールするには、以下のコマンドを実行します。 -- For Ubuntu/Debian users, run `apt install ebtables ethtool`. -- For CentOS/Fedora users, run `yum install ebtables ethtool`. +- Ubuntu/Debianユーザーは、`apt install ebtables ethtool`を実行してください。 +- CentOS/Fedoraユーザーは、`yum install ebtables ethtool`を実行してください。 ## インストール中にkubeadmがコントロールプレーンを待ち続けて止まる -If you notice that `kubeadm init` hangs after printing out the following line: +以下のを出力した後に`kubeadm init`が止まる場合は、`kubeadm init`を実行してください: ```sh [apiclient] Created API client, waiting for the control plane to become ready ``` -This may be caused by a number of problems. The most common are: +これはいくつかの問題が原因となっている可能性があります。最も一般的なのは: -- network connection problems. Check that your machine has full network connectivity before continuing. -- the default cgroup driver configuration for the kubelet differs from that used by Docker. - Check the system log file (e.g. `/var/log/message`) or examine the output from `journalctl -u kubelet`. If you see something like the following: +- ネットワーク接続の問題が挙げられます。続行する前に、お使いのマシンがネットワークに完全に接続されていることを確認してください。 +- kubeletのデフォルトのcgroupドライバの設定がDockerで使用されているものとは異なっている場合も考えられます。 + システムログファイル(例: `/var/log/message`)をチェックするか、`journalctl -u kubelet`の出力を調べてください: ```shell error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs" ``` - There are two common ways to fix the cgroup driver problem: + 以上のようなエラーが現れていた場合、cgroupドライバの問題を解決するには、以下の2つの方法があります: - 1. Install Docker again following instructions - [here](/ja/docs/setup/independent/install-kubeadm/#installing-docker). + 1. [ここ](/ja/docs/setup/independent/install-kubeadm/#installing-docker)の指示に従ってDockerを再度インストールします。 - 1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to - [Configure cgroup driver used by kubelet on Master Node](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node) + 1. Dockerのcgroupドライバに合わせてkubeletの設定を手動で変更します。その際は、[マスターノード上でkubeletが使用するcgroupドライバを設定する](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)を参照してください。 -- control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`. +- control plane Dockerコンテナがクラッシュループしたり、ハングしたりしています。これは`docker ps`を実行し、`docker logs`を実行して各コンテナを調査することで確認できます。 ## 管理コンテナを削除する時にkubeadmが止まる -The following could happen if Docker halts and does not remove any Kubernetes-managed containers: +Dockerが停止して、Kubernetesで管理されているコンテナを削除しないと、以下のようなことが起こる可能性があります: ```bash sudo kubeadm reset @@ -78,95 +110,70 @@ sudo kubeadm reset (block) ``` -A possible solution is to restart the Docker service and then re-run `kubeadm reset`: +考えられる解決策は、Dockerサービスを再起動してから`kubeadm reset`を再実行することです: ```bash sudo systemctl restart docker.service sudo kubeadm reset ``` -Inspecting the logs for docker may also be useful: +dockerのログを調べるのも有効な場合があります: ```sh -journalctl -ul docker +journalctl -u docker ``` -## Podの状態が`RunContainerError`、`CrashLoopBackOff`、または`Error` +## Podの状態が`RunContainerError`、`CrashLoopBackOff`、または`Error`となる -Right after `kubeadm init` there should not be any pods in these states. +`kubeadm init`の直後には、これらの状態ではPodは存在しないはずです。 -- If there are pods in one of these states _right after_ `kubeadm init`, please open an - issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state - until you have deployed the network solution. -- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state - after deploying the network solution and nothing happens to `coredns` (or `kube-dns`), - it's very likely that the Pod Network solution that you installed is somehow broken. - You might have to grant it more RBAC privileges or use a newer version. Please file - an issue in the Pod Network providers' issue tracker and get the issue triaged there. -- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option - when booting `dockerd` with `systemd` and restart `docker`. You can see the MountFlags in `/usr/lib/systemd/system/docker.service`. - MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state. - The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files. +- `kubeadm init`の _直後_ にこれらの状態のいずれかにPodがある場合は、kubeadmのリポジトリにIssueを立ててください。ネットワークソリューションをデプロイするまでは`coredns`(または`kube-dns`)は`Pending`状態でなければなりません。 +- ネットワークソリューションをデプロイしても`coredns`(または`kube-dns`)に何も起こらない場合にRunContainerError`、`CrashLoopBackOff`、`Error`の状態でPodが表示された場合は、インストールしたPodネットワークソリューションが壊れている可能性が高いです。より多くのRBACの特権を付与するか、新しいバージョンを使用する必要があるかもしれません。PodネットワークプロバイダのイシュートラッカーにIssueを出して、そこで問題をトリアージしてください。 +- 1.12.1よりも古いバージョンのDockerをインストールした場合は、`systemd`で`dockerd`を起動する際に`MountFlags=slave`オプションを削除して`docker`を再起動してください。マウントフラグは`/usr/lib/systemd/system/docker.service`で確認できます。MountFlagsはKubernetesがマウントしたボリュームに干渉し、Podsを`CrashLoopBackOff`状態にすることがあります。このエラーは、Kubernetesが`var/run/secrets/kubernetes.io/serviceaccount`ファイルを見つけられない場合に発生します。 ## `coredns`(もしくは`kube-dns`)が`Pending`状態でスタックする -This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin -should [install the pod network solution](/docs/concepts/cluster-administration/addons/) -of choice. You have to install a Pod Network -before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up. +kubeadmはネットワークプロバイダに依存しないため、管理者は選択した[Podネットワークソリューションをインストール](/docs/concepts/cluster-administration/addons/)をする必要があります。CoreDNSを完全にデプロイする前にPodネットワークをインストールする必要があります。したがって、ネットワークがセットアップされる前の `Pending`状態になります。 ## `HostPort`サービスが動かない -The `HostPort` and `HostIP` functionality is available depending on your Pod Network -provider. Please contact the author of the Pod Network solution to find out whether -`HostPort` and `HostIP` functionality are available. +`HostPort`と`HostIP`の機能は、ご使用のPodネットワークプロバイダによって利用可能です。Podネットワークソリューションの作者に連絡して、`HostPort`と`HostIP`機能が利用可能かどうかを確認してください。 -Calico, Canal, and Flannel CNI providers are verified to support HostPort. +Calico、Canal、FlannelのCNIプロバイダは、HostPortをサポートしていることが確認されています。 -For more information, see the [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md). +詳細については、[CNI portmap documentation] (https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md) を参照してください。 -If your network provider does not support the portmap CNI plugin, you may need to use the [NodePort feature of -services](/ja/docs/concepts/services-networking/service/#nodeport) or use `HostNetwork=true`. +ネットワークプロバイダが portmap CNI プラグインをサポートしていない場合は、[NodePortサービス](/ja/docs/concepts/services-networking/service/#nodeport)を使用するか、`HostNetwork=true`を使用してください。 ## サービスIP経由でPodにアクセスすることができない -- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip) - which allows pods to access themselves via their Service IP. This is an issue related to - [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network - add-on provider to get the latest status of their support for hairpin mode. +- 多くのネットワークアドオンは、PodがサービスIPを介して自分自身にアクセスできるようにする[ヘアピンモード](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)を有効にしていません。これは[CNI](https://github.com/containernetworking/cni/issues/476)に関連する問題です。ヘアピンモードのサポート状況については、ネットワークアドオンプロバイダにお問い合わせください。 -- If you are using VirtualBox (directly or via Vagrant), you will need to - ensure that `hostname -i` returns a routable IP address. By default the first - interface is connected to a non-routable host-only network. A work around - is to modify `/etc/hosts`, see this [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11) - for an example. +- VirtualBoxを使用している場合(直接またはVagrant経由)は、`hostname -i`がルーティング可能なIPアドレスを返すことを確認する必要があります。デフォルトでは、最初のインターフェースはルーティング可能でないホスト専用のネットワークに接続されています。これを回避するには`/etc/hosts`を修正する必要があります。例としてはこの[Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)を参照してください。 ## TLS証明書のエラー -The following error indicates a possible certificate mismatch. +以下のエラーは、証明書の不一致の可能性を示しています。 ```none # kubectl get pods Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") ``` -- Verify that the `$HOME/.kube/config` file contains a valid certificate, and - regenerate a certificate if necessary. The certificates in a kubeconfig file - are base64 encoded. The `base64 --decode` command can be used to decode the certificate - and `openssl x509 -text -noout` can be used for viewing the certificate information. -- Unset the `KUBECONFIG` environment variable using: +- `HOME/.kube/config`ファイルに有効な証明書が含まれていることを確認し、必要に応じて証明書を再生成します。kubeconfigファイル内の証明書はbase64でエンコードされています。証明書をデコードするには`base64 --decode`コマンドを、証明書情報を表示するには`openssl x509 -text -noout`コマンドを用いてください。 +- 環境変数`KUBECONFIG`の設定を解除するには以下のコマンドを実行するか: ```sh unset KUBECONFIG ``` - Or set it to the default `KUBECONFIG` location: + 設定をデフォルトの`KUBECONFIG`の場所に設定します: ```sh export KUBECONFIG=/etc/kubernetes/admin.conf ``` -- Another workaround is to overwrite the existing `kubeconfig` for the "admin" user: +- もう一つの回避策は、既存の`kubeconfig`を"admin"ユーザに上書きすることです: ```sh mv $HOME/.kube $HOME/.kube.bak @@ -177,38 +184,38 @@ Unable to connect to the server: x509: certificate signed by unknown authority ( ## Vagrant内でPodネットワークとしてflannelを使用する時のデフォルトNIC -The following error might indicate that something was wrong in the pod network: +以下のエラーは、Podネットワークに何か問題があったことを示している可能性を示しています: ```sh Error from server (NotFound): the server could not find the requested resource ``` -- If you're using flannel as the pod network inside Vagrant, then you will have to specify the default interface name for flannel. +- Vagrant内のPodネットワークとしてflannelを使用している場合は、flannelのデフォルトのインターフェース名を指定する必要があります。 - Vagrant typically assigns two interfaces to all VMs. The first, for which all hosts are assigned the IP address `10.0.2.15`, is for external traffic that gets NATed. + Vagrantは通常、2つのインターフェースを全てのVMに割り当てます。1つ目は全てのホストにIPアドレス`10.0.2.15`が割り当てられており、NATされる外部トラフィックのためのものです。 - This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `--iface eth1` flag to flannel so that the second interface is chosen. + これは、ホストの最初のインターフェイスをデフォルトにしているflannelの問題につながるかもしれません。これは、すべてのホストが同じパブリックIPアドレスを持っていると考えます。これを防ぐには、2番目のインターフェイスが選択されるように `--iface eth1`フラグをflannelに渡してください。 ## 公開されていないIPがコンテナに使われている -In some situations `kubectl logs` and `kubectl run` commands may return with the following errors in an otherwise functional cluster: +状況によっては、`kubectl logs`や`kubectl run`コマンドが以下のようなエラーを返すことがあります: ```sh Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host ``` -- This may be due to Kubernetes using an IP that can not communicate with other IPs on the seemingly same subnet, possibly by policy of the machine provider. -- DigitalOcean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one. +- これには、おそらくマシンプロバイダのポリシーによって、一見同じサブネット上の他のIPと通信できないIPをKubernetesが使用している可能性があります。 +- DigitalOceanはパブリックIPとプライベートIPを`eth0`に割り当てていますが、`kubelet`はパブリックIPではなく、ノードの`InternalIP`として後者を選択します。 - Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to DigitalOcean allows to query for the anchor IP from the droplet: + `ifconfig`ではエイリアスIPアドレスが表示されないため、`ifconfig`の代わりに`ip addr show`を使用してこのシナリオをチェックしてください。あるいは、DigitalOcean専用のAPIエンドポイントを使用して、ドロップレットからアンカーIPを取得することもできます: ```sh curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address ``` - The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using DigitalOcean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this. + 回避策としては、`--node-ip`を使ってどのIPを使うかを`kubelet`に伝えることです。DigitalOceanを使用する場合、オプションのプライベートネットワークを使用したい場合は、パブリックIP（`eth0`に割り当てられている）かプライベートIP（`eth1`に割り当てられている）のどちらかを指定します。これにはkubeadm `NodeRegistrationOptions`構造体の [`KubeletExtraArgs`セクション](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) が利用できます。 - Then restart `kubelet`: + `kubelet`を再起動してください: ```sh systemctl daemon-reload @@ -217,13 +224,12 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6 ## `coredns`のPodが`CrashLoopBackOff`もしくは`Error`状態になる -If you have nodes that are running SELinux with an older version of Docker you might experience a scenario -where the `coredns` pods are not starting. To solve that you can try one of the following options: +SELinuxを実行しているノードで古いバージョンのDockerを使用している場合、`coredns` Podが起動しないということが起きるかもしれません。この問題を解決するには、以下のオプションのいずれかを試してみてください: -- Upgrade to a [newer version of Docker](/ja/docs/setup/independent/install-kubeadm/#installing-docker). +- [新しいDockerのバージョン](/ja/docs/setup/independent/install-kubeadm/#installing-docker)にアップグレードする。 -- [Disable SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux). -- Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`: +- [SELinuxを無効化する](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux)。 +- `coredns`を変更して、`allowPrivilegeEscalation`を`true`に設定: ```bash kubectl -n kube-system get deployment coredns -o yaml | \ @@ -231,108 +237,84 @@ kubectl -n kube-system get deployment coredns -o yaml | \ kubectl apply -f - ``` -Another cause for CoreDNS to have `CrashLoopBackOff` is when a CoreDNS Pod deployed in Kubernetes detects a loop. [A number of workarounds](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters) -are available to avoid Kubernetes trying to restart the CoreDNS Pod every time CoreDNS detects the loop and exits. +CoreDNSに`CrashLoopBackOff`が発生する別の原因は、KubernetesにデプロイされたCoreDNS Podがループを検出したときに発生します。CoreDNSがループを検出して終了するたびに、KubernetesがCoreDNS Podを再起動しようとするのを避けるために、[いくつかの回避策](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)が用意されています。 {{< warning >}} -Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise -the security of your cluster. +SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスタのセキュリティが損なわれる可能性があります。 {{< /warning >}} ## etcdのpodが継続的に再起動する -If you encounter the following error: +以下のエラーが発生した場合は: ``` rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\"" ``` -this issue appears if you run CentOS 7 with Docker 1.13.1.84. -This version of Docker can prevent the kubelet from executing into the etcd container. +この問題は、CentOS 7をDocker 1.13.1.84で実行した場合に表示されます。このバージョンのDockerでは、kubeletがetcdコンテナに実行されないようにすることができます。 -To work around the issue, choose one of these options: +この問題を回避するには、以下のいずれかのオプションを選択します: -- Roll back to an earlier version of Docker, such as 1.13.1-75 +- 1.13.1-75のような以前のバージョンのDockerにロールバックする ``` yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64 ``` -- Install one of the more recent recommended versions, such as 18.06: +- 18.06のような最新の推奨バージョンをインストールする: ```bash sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install docker-ce-18.06.1.ce-3.el7.x86_64 ``` -## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag +## コンマで区切られた値のリストを`--component-extra-args`フラグ内の引数に渡すことができない -`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane -component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing -the values (`mapStringString`). +`-component-extra-args`のような`kubeadm init`フラグを使うと、kube-apiserverのようなコントロールプレーンコンポーネントにカスタム引数を渡すことができます。しかし、このメカニズムは値の解析に使われる基本的な型 (`mapStringString`) のために制限されています。 -If you decide to pass an argument that supports multiple, comma-separated values such as -`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with -`flag: malformed pair, expect string=string`. This happens because the list of arguments for -`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered -as a key that is missing a value. +もし、`--apiserver-extra-args "enable-admission plugins=LimitRanger,NamespaceExists"`のようにカンマで区切られた複数の値をサポートする引数を渡した場合、このフラグは`flag: malformed pair, expect string=string`で失敗します。これは`--apiserver-extra-args`の引数リストが`key=value`のペアを期待しており、この場合`NamespacesExists`は値を欠いたキーとみなされるためです。 -Alternatively, you can try separating the `key=value` pairs like so: -`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"` -but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`. +別の方法として、`key=value`のペアを以下のように分離してみることもできます: +`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`しかし、この場合は、キー`enable-admission-plugins`は`NamespaceExists`の値しか持ちません。既知の回避策としては、kubeadm[設定ファイル](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)を使用することが挙げられます。 -A known workaround is to use the kubeadm [configuration file](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags). +## cloud-controller-managerによってノードが初期化される前にkube-proxyがスケジューリングされる -## kube-proxy scheduled before node is initialized by cloud-controller-manager +クラウドプロバイダのシナリオでは、クラウドコントローラマネージャがノードアドレスを初期化する前に、kube-proxyが新しいワーカーノードでスケジューリングされてしまうことがあります。これにより、kube-proxyがノードのIPアドレスを正しく拾えず、ロードバランサを管理するプロキシ機能に悪影響を及ぼします。 -In cloud provider scenarios, kube-proxy can end up being scheduled on new worker nodes before -the cloud-controller-manager has initialized the node addresses. This causes kube-proxy to fail -to pick up the node's IP address properly and has knock-on effects to the proxy function managing -load balancers. - -The following error can be seen in kube-proxy Pods: +kube-proxy Podsでは以下のようなエラーが発生します: ``` server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: [] proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP ``` -A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on control-plane -nodes regardless of their conditions, keeping it off of other nodes until their initial guarding -conditions abate: +既知の解決策は、初期のガード条件が緩和されるまで他のノードから離しておき、条件に関係なくコントロールプレーンノード上でスケジューリングできるように、キューブプロキシDaemonSetにパッチを当てることです: + ``` kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }' ``` -The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027). +Tこの問題のトラッキング問題は[こちら](https://github.com/kubernetes/kubeadm/issues/1027)。 -## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration +## kubeadmの設定をマーシャリングする際、NodeRegistration.Taintsフィールドが省略される -*Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.* +*注意: この[Issue](https://github.com/kubernetes/kubeadm/issues/1358)は、kubeadmタイプをマーシャルするツール(YAML設定ファイルなど)にのみ適用されます。これはkubeadm API v1beta2で修正される予定です。* -By default, kubeadm applies the `node-role.kubernetes.io/master:NoSchedule` taint to control-plane nodes. -If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice, -the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint. +デフォルトでは、kubeadmはコントロールプレーンノードに`node-role.kubernetes.io/master:NoSchedule`のテイントを適用します。kubeadmがコントロールプレーンノードに影響を与えないようにし、`InitConfiguration.NodeRegistration.Taints`を空のスライスに設定すると、マーシャリング時にこのフィールドは省略されます。フィールドが省略された場合、kubeadmはデフォルトのテイントを適用します。 -There are at least two workarounds: +少なくとも2つの回避策があります: -1. Use the `node-role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity. +1. 空のスライスの代わりに`node-role.kubernetes.io/master:PreferNoSchedule`テイントを使用します。他のノードに容量がない限り、[Podsはマスター上でスケジュールされます](/docs/concepts/scheduling-eviction/taint-and-toleration/)。 -2. Remove the taint after kubeadm init exits: +2. kubeadm init終了後のテイントの除去: ```bash kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule- ``` -## `/usr` is mounted read-only on nodes {#usr-mounted-read-only} +## ノード{#usr-mounted-read-only}に`/usr`が読み取り専用でマウントされる -On Linux distributions such as Fedora CoreOS, the directory `/usr` is mounted as a read-only filesystem. -For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md), -Kubernetes components like the kubelet and kube-controller-manager use the default path of -`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_ -for the feature to work. +Fedora CoreOSなどのLinuxディストリビューションでは、ディレクトリ`/usr`が読み取り専用のファイルシステムとしてマウントされます。 [flex-volumeサポート](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md)では、kubeletやkube-controller-managerのようなKubernetesコンポーネントはデフォルトで`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`のパスを使用していますが、この機能を動作させるためにはflex-volumeディレクトリは _書き込み可能_ な状態でなければなりません。 -To workaround this issue you can configure the flex-volume directory using the kubeadm -[configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2). +この問題を回避するには、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用してflex-volumeディレクトリを設定します。 -On the primary control-plane Node (created using `kubeadm init`) pass the following -file using `--config`: +プライマリコントロールプレーンノード（`kubeadm init`で作成されたもの）上で、`--config`で以下のファイルを渡します: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 @@ -348,7 +330,7 @@ controllerManager: flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" ``` -On joining Nodes: +ノードをジョインするには: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 @@ -358,5 +340,9 @@ nodeRegistration: volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" ``` -Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please -be advised that this is modifying a design principle of the Linux distribution. +あるいは、`/usr`マウントを書き込み可能にするために `/etc/fstab`を変更することもできますが、これはLinuxディストリビューションの設計原理を変更していることに注意してください。 + +## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する +このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。 + +この問題はバージョン1.19で修正されます。 \ No newline at end of file diff --git a/content/ja/docs/setup/production-environment/tools/kubespray.md b/content/ja/docs/setup/production-environment/tools/kubespray.md index 6c02ca5374..e8c49078fd 100644 --- a/content/ja/docs/setup/production-environment/tools/kubespray.md +++ b/content/ja/docs/setup/production-environment/tools/kubespray.md @@ -8,7 +8,7 @@ weight: 30 This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). -Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: +Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: * a highly available cluster * composable attributes @@ -21,7 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in * openSUSE Leap 15 * continuous integration tests -To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to +[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). @@ -50,7 +51,7 @@ Kubespray provides the following utilities to help provision your environment: ### (2/5) インベントリファイルの用意 -After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) クラスタ作成の計画 @@ -68,7 +69,7 @@ Kubespray provides the ability to customize many aspects of the deployment: * {{< glossary_tooltip term_id="cri-o" >}} * Certificate generation methods -Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. +Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. ### (4/5) クラスタのデプロイ @@ -110,7 +111,7 @@ When running the reset playbook, be sure not to accidentally target your product ## フィードバック -* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/)) +* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/)) * [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues) diff --git a/content/ja/docs/setup/production-environment/turnkey/aws.md b/content/ja/docs/setup/production-environment/turnkey/aws.md index 1fc53a1f28..03246c1b06 100644 --- a/content/ja/docs/setup/production-environment/turnkey/aws.md +++ b/content/ja/docs/setup/production-environment/turnkey/aws.md @@ -20,9 +20,7 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス * [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。 -* [CoreOS Tectonic](https://coreos.com/tectonic/)はAWS上のContainer Linuxノードを含むKubernetesクラスターを作成できる、オープンソースの[Tectonic Installer](https://github.com/coreos/tectonic-installer)を含みます。 - -* CoreOSから生まれ、Kubernetes IncubatorがメンテナンスしているCLIツール[kube-aws](https://github.com/kubernetes-incubator/kube-aws)は、[Container Linux](https://coreos.com/why/)ノードを使用したAWSツール(EC2、CloudFormation、Auto Scaling)によるKubernetesクラスターを作成および管理できます。 +* [kube-aws](https://github.com/kubernetes-incubator/kube-aws) EC2、CloudFormation、Auto Scalingを使用して、[Flatcar Linux](https://www.flatcar-linux.org/)ノードでKubernetesクラスターを作成および管理します。 * [KubeOne](https://github.com/kubermatic/kubeone)は可用性の高いKubernetesクラスターを作成、アップグレード、管理するための、オープンソースのライフサイクル管理ツールです。 @@ -46,10 +44,10 @@ export PATH=/platforms/darwin/amd64:$PATH export PATH=/platforms/linux/amd64:$PATH ``` -ツールに関する最新のドキュメントページはこちらです: [kubectl manual](/docs/user-guide/kubectl/) +ツールに関する最新のドキュメントページはこちらです: [kubectl manual](/docs/reference/kubectl/kubectl/) デフォルトでは、`kubectl`はクラスターの起動中に生成された`kubeconfig`ファイルをAPIに対する認証に使用します。 -詳細な情報は、[kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。 +詳細な情報は、[kubeconfig files](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。 ### 例 @@ -61,7 +59,7 @@ export PATH=/platforms/linux/amd64:$PATH ## クラスターのスケーリング -`kubectl`を使用したノードの追加および削除はサポートしていません。インストール中に作成された[Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html)内の'Desired'および'Max'プロパティを手動で調整することで、ノード数をスケールさせることができます。 +`kubectl`を使用したノードの追加および削除はサポートしていません。インストール中に作成された[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html)内の'Desired'および'Max'プロパティを手動で調整することで、ノード数をスケールさせることができます。 ## クラスターの解体 @@ -77,12 +75,8 @@ cluster/kube-down.sh IaaS プロバイダー | 構成管理 | OS | ネットワーク | ドキュメント | 適合 | サポートレベル -------------------- | ------------ | ------------- | ------------ | --------------------------------------------- | ---------| ---------------------------- AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb)) -AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community -AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community +AWS | CoreOS | CoreOS | flannel | - | | Community +AWS | Juju | Ubuntu | flannel, calico, canal | - | 100% | Commercial, Community AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community -## 参考文献 - -Kubernetesクラスターの利用と管理に関する詳細は、[Kubernetesドキュメント](/ja/docs/)を参照してください。 - diff --git a/content/ja/docs/setup/production-environment/turnkey/clc.md b/content/ja/docs/setup/production-environment/turnkey/clc.md deleted file mode 100644 index b700456b87..0000000000 --- a/content/ja/docs/setup/production-environment/turnkey/clc.md +++ /dev/null @@ -1,340 +0,0 @@ ---- -title: CenturyLink Cloud上でKubernetesを動かす ---- - - -These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud. - -You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md). - -## ヘルプの検索 - -If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways: - -- Submit a github issue -- Send an email to Kubernetes AT ctl DOT io -- Visit [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes) - -## 仮想マシンもしくは物理サーバーのクラスター、その選択 - -- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag. -- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/) -- Physical serves are only available in the VA1 and GB3 data centers. -- VMs are available in all 13 of our public cloud locations - -## 必要条件 - -The requirements to run this script are: - -- A linux administrative host (tested on ubuntu and macOS) -- python 2 (tested on 2.7.11) - - pip (installed with python as of 2.7.9) -- git -- A CenturyLink Cloud account with rights to create new hosts -- An active VPN connection to the CenturyLink Cloud from your linux host - -## スクリプトのインストール - -After you have all the requirements met, please follow these instructions to install this script. - -1) Clone this repository and cd into it. - -```shell -git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc -``` - -2) Install all requirements, including - - * Ansible - * CenturyLink Cloud SDK - * Ansible Modules - -```shell -sudo pip install -r ansible/requirements.txt -``` - -3) Create the credentials file from the template and use it to set your ENV variables - -```shell -cp ansible/credentials.sh.template ansible/credentials.sh -vi ansible/credentials.sh -source ansible/credentials.sh - -``` - -4) Grant your machine access to the CenturyLink Cloud network by using a VM inside the network or [ configuring a VPN connection to the CenturyLink Cloud network.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/) - - -#### スクリプトのインストールの例: Ububtu 14の手順 - -If you use an ubuntu 14, for your convenience we have provided a step by step -guide to install the requirements and install the script. - -```shell -# system -apt-get update -apt-get install -y git python python-crypto -curl -O https://bootstrap.pypa.io/get-pip.py -python get-pip.py - -# installing this repository -mkdir -p ~home/k8s-on-clc -cd ~home/k8s-on-clc -git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git -cd adm-kubernetes-on-clc/ -pip install -r requirements.txt - -# getting started -cd ansible -cp credentials.sh.template credentials.sh; vi credentials.sh -source credentials.sh -``` - - - -## クラスターの作成 - -To create a new Kubernetes cluster, simply run the ```kube-up.sh``` script. A complete -list of script options and some examples are listed below. - -```shell -CLC_CLUSTER_NAME=[name of kubernetes cluster] -cd ./adm-kubernetes-on-clc -bash kube-up.sh -c="$CLC_CLUSTER_NAME" -``` - -It takes about 15 minutes to create the cluster. Once the script completes, it -will output some commands that will help you setup kubectl on your machine to -point to the new cluster. - -When the cluster creation is complete, the configuration files for it are stored -locally on your administrative host, in the following directory - -```shell -> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/ -``` - - -#### クラスターの作成: スクリプトのオプション - -```shell -Usage: kube-up.sh [OPTIONS] -Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster -Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in -order to access the CenturyLinkCloud API - -All options (both short and long form) require arguments, and must include "=" -between option name and option value. - - -h (--help) display this help and exit - -c= (--clc_cluster_name=) set the name of the cluster, as used in CLC group names - -t= (--minion_type=) standard -> VM (default), bareMetal -> physical] - -d= (--datacenter=) VA1 (default) - -m= (--minion_count=) number of kubernetes minion nodes - -mem= (--vm_memory=) number of GB ram for each minion - -cpu= (--vm_cpu=) number of virtual cps for each minion node - -phyid= (--server_conf_id=) physical server configuration id, one of - physical_server_20_core_conf_id - physical_server_12_core_conf_id - physical_server_4_core_conf_id (default) - -etcd_separate_cluster=yes create a separate cluster of three etcd nodes, - otherwise run etcd on the master node -``` - -## クラスターの拡張 - -To expand an existing Kubernetes cluster, run the ```add-kube-node.sh``` -script. A complete list of script options and some examples are listed [below](#cluster-expansion-script-options). -This script must be run from the same host that created the cluster (or a host -that has the cluster artifact files stored in ```~/.clc_kube/$cluster_name```). - -```shell -cd ./adm-kubernetes-on-clc -bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2 -``` - -#### クラスターの拡張: スクリプトのオプション - -```shell -Usage: add-kube-node.sh [OPTIONS] -Create servers in the CenturyLinkCloud environment and add to an -existing CLC kubernetes cluster - -Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in -order to access the CenturyLinkCloud API - - -h (--help) display this help and exit - -c= (--clc_cluster_name=) set the name of the cluster, as used in CLC group names - -m= (--minion_count=) number of kubernetes minion nodes to add -``` - -## クラスターの削除 - -There are two ways to delete an existing cluster: - -1) Use our python script: - -```shell -python delete_cluster.py --cluster=clc_cluster_name --datacenter=DC1 -``` - -2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink -Cloud control portal and delete the parent server group that contains the -Kubernetes Cluster. We hope to add a scripted option to do this soon. - -## 例 - -Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1 - -```shell -bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1 -``` - -Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1 - -```shell -bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes -``` - -Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1: - -```shell -bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4 -``` - - - -## クラスターの機能とアーキテクチャ - -We configure the Kubernetes cluster with the following features: - -* KubeDNS: DNS resolution and service discovery -* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling. -* Grafana: Kubernetes/Docker metric dashboard -* KubeUI: Simple web interface to view Kubernetes state -* Kube Dashboard: New web interface to interact with your cluster - -We use the following to create the Kubernetes cluster: - -* Kubernetes 1.1.7 -* Ubuntu 14.04 -* Flannel 0.5.4 -* Docker 1.9.1-0~trusty -* Etcd 2.2.2 - -## 任意のアドオン - -* Logging: We offer an integrated centralized logging ELK platform so that all - Kubernetes and docker logs get sent to the ELK stack. To install the ELK stack - and configure Kubernetes to send logs to it, follow [the log - aggregation documentation](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md). Note: We don't install this by default as - the footprint isn't trivial. - -## クラスターの管理 - -The most widely used tool for managing a Kubernetes cluster is the command-line -utility ```kubectl```. If you do not already have a copy of this binary on your -administrative machine, you may run the script ```install_kubectl.sh``` which will -download it and install it in ```/usr/bin/local```. - -The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary -authentication certificates for the particular cluster. The configuration file is -written to the ```${CLC_CLUSTER_HOME}/kube``` directory - - -```shell -export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config -kubectl version -kubectl cluster-info -``` - -### プログラムでクラスターへアクセス - -It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice. - -To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https: - -```shell -curl \ - --cacert ${CLC_CLUSTER_HOME}/pki/ca.crt \ - --key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \ - --cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt https://${MASTER_IP}:6443 -``` - -But please note, this *does not* work out of the box with the ```curl``` binary -distributed with macOS. - -### ブラウザーを使ったクラスターへのアクセス - -We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you -create a cluster, the script should output URLs for these interfaces like this: - -kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```. - -Note on Authentication to the UIs: - -The cluster is set up to use basic authentication for the user _admin_. -Hitting the url at ```https://${MASTER_IP}:6443``` will -require accepting the self-signed certificate -from the apiserver, and then presenting the admin -password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_``` - - -### 設定ファイル - -Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files -to access the cluster from machines other than where you created the cluster from. - -* ```config/```: Ansible variable files containing parameters describing the master and minion hosts -* ```hosts/```: hosts files listing access information for the Ansible playbooks -* ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API -* ```pki/```: public key infrastructure files enabling TLS communication in the cluster -* ```ssh/```: SSH keys for root access to the hosts - - -## ```kubectl``` usage examples - -There are a great many features of _kubectl_. Here are a few examples - -List existing nodes, pods, services and more, in all namespaces, or in just one: - -```shell -kubectl get nodes -kubectl get --all-namespaces pods -kubectl get --all-namespaces services -kubectl get --namespace=kube-system replicationcontrollers -``` - -The Kubernetes API server exposes services on web URLs, which are protected by requiring -client certificates. If you run a kubectl proxy locally, ```kubectl``` will provide -the necessary certificates and serve locally over http. - -```shell -kubectl proxy -p 8001 -``` - -Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser. - - -## どのKubernetesの機能がCenturyLink Cloud上で動かないのか - -These are the known items that don't work on CenturyLink cloud but do work on other cloud providers: - -- At this time, there is no support services of the type [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/). We are actively working on this and hope to publish the changes sometime around April 2016. - -- At this time, there is no support for persistent storage volumes provided by - CenturyLink Cloud. However, customers can bring their own persistent storage - offering. We ourselves use Gluster. - - -## Ansibleのファイル - -If you want more information about our Ansible files, please [read this file](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md) - -## 参考文献 - -Please see the [Kubernetes docs](/ja/docs/) for more details on administering -and using a Kubernetes cluster. - - - diff --git a/content/ja/docs/setup/production-environment/turnkey/gce.md b/content/ja/docs/setup/production-environment/turnkey/gce.md index b00d34ade6..dcd269446a 100644 --- a/content/ja/docs/setup/production-environment/turnkey/gce.md +++ b/content/ja/docs/setup/production-environment/turnkey/gce.md @@ -67,7 +67,7 @@ cluster/kube-up.sh If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster. If you run into trouble, please see the section on [troubleshooting](/ja/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the -[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack). +[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel. The next few steps will show you: @@ -80,7 +80,7 @@ The next few steps will show you: The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation. -The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster +The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster manager. It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps. @@ -93,7 +93,7 @@ gcloud components install kubectl {{< note >}} The kubectl version bundled with `gcloud` may be older than the one -downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/) +The [kubectl](/ja/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster document to see how you can set up the latest `kubectl` on your workstation. {{< /note >}} @@ -107,7 +107,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru kubectl get --all-namespaces services ``` -should show a set of [services](/docs/user-guide/services) that look something like this: +should show a set of [services](/docs/concepts/services-networking/service/) that look something like this: ```shell NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE @@ -117,7 +117,7 @@ kube-system kube-ui ClusterIP 10.0.0.3 ... ``` -Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup. +Similarly, you can take a look at the set of [pods](/ja/docs/concepts/workloads/pods/) that were created during cluster startup. You can do this via the ```shell @@ -144,7 +144,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh ### いくつかの例の実行 -Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster. +Then, see [a simple nginx example](/ja/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster. For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough. @@ -215,10 +215,3 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- GCE | Saltstack | Debian | GCE | [docs](/ja/docs/setup/production-environment/turnkey/gce/) | | Project - -## 参考文献 - -Please see the [Kubernetes docs](/ja/docs/) for more details on administering -and using a Kubernetes cluster. - - diff --git a/content/ja/docs/setup/production-environment/turnkey/icp.md b/content/ja/docs/setup/production-environment/turnkey/icp.md index 9d1a0a17b3..1313f37ff0 100644 --- a/content/ja/docs/setup/production-environment/turnkey/icp.md +++ b/content/ja/docs/setup/production-environment/turnkey/icp.md @@ -25,13 +25,9 @@ The following modules are available where you can deploy IBM Cloud Private by us ## AWS上でのIBM Cloud Private -You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform. +You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) using Terraform. -IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide. - -This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/). - -IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md). +IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws). ## Azure上でのIBM Cloud Private @@ -64,4 +60,4 @@ You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. F The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud. -For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/services/vmwaresolutions/vmonic?topic=vmware-solutions-prod_overview#ibm-cloud-private-hosted). +For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icp_overview). diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 676f7f8a48..fec66df50a 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -14,7 +14,7 @@ Windowsアプリケーションは、多くの組織で実行されているサ ## KubernetesのWindowsコンテナ -KubernetesでWindowsコンテナのオーケストレーションを有効にする方法は、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。 +KubernetesでWindowsコンテナのオーケストレーションを有効にする方法は、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの{{< glossary_tooltip text="Pod" term_id="pod" >}}でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。 Windowsコンテナを実行するには、Kubernetesクラスターに複数のオペレーティングシステムを含める必要があります。コントロールプレーンノードはLinux、ワーカーノードはワークロードのニーズに応じてWindowsまたはLinuxで実行します。Windows Server 2019は、サポートされている唯一のWindowsオペレーティングシステムであり、Windows (kubelet、[コンテナランタイム](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd)、kube-proxyを含む)で[Kubernetesノード](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)を有効にします。Windowsディストリビューションチャンネルの詳細については、[Microsoftのドキュメント](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19)を参照してください。 @@ -52,7 +52,7 @@ Windows Serverホストオペレーティングシステムには、[Windows Ser Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能します。このセクションでは、主要なワークロードイネーブラーのいくつかと、それらがWindowsにどのようにマップされるかについて説明します。 -* [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) +* [Pods](/ja/docs/concepts/workloads/pods/) Podは、Kubernetesにおける最も基本的な構成要素です。人間が作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最もシンプルな単位です。WindowsとLinuxのコンテナを同じPodにデプロイすることはできません。Pod内のすべてのコンテナは、各ノードが特定のプラットフォームとアーキテクチャを表す単一のノードにスケジュールされます。次のPod機能、プロパティ、およびイベントがWindowsコンテナでサポートされています。: @@ -96,7 +96,27 @@ Pod、Controller、Serviceは、KubernetesでWindowsワークロードを管理 #### コンテナランタイム -KubernetesのWindows Server 2019/1809ノードでは、Docker EE-basic 18.09が必要です。これは、kubeletに含まれているdockershimコードで動作します。CRI-ContainerDなどの追加のランタイムは、Kubernetesの以降のバージョンでサポートされる可能性があります。 +##### Docker EE + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +Docker EE-basic 18.09+は、Kubernetesを実行しているWindows Server 2019 / 1809ノードに推奨されるコンテナランタイムです。kubeletに含まれるdockershimコードで動作します。 + +##### CRI-ContainerD + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +ContainerDはLinux上のKubernetesで動作するOCI準拠のランタイムです。Kubernetes v1.18では、Windows上での{{< glossary_tooltip term_id="containerd" text="ContainerD" >}}のサポートが追加されています。Windows上でのContainerDの進捗状況は[enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001)で確認できます。 + +{{< caution >}} + +Kubernetes v1.18におけるWindows上でのContainerDは以下の既知の欠点があります: + +* ContainerDは公式リリースではWindowsをサポートしていません。すなわち、Kubernetesでのすべての開発はアクティブなContainerD開発ブランチに対して行われています。本番環境へのデプロイは常に、完全にテストされセキュリティ修正をサポートした公式リリースを利用するべきです。 +* ContainerDを利用した場合、Group Managed Service Accountsは実装されていません。詳細は[containerd/cri#1276](https://github.com/containerd/cri/issues/1276)を参照してください。 + +{{< /caution >}} + #### 永続ストレージ @@ -404,7 +424,6 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ # kubelet.exeを登録 # マイクロソフトは、mcr.microsoft.com/k8s/core/pause:1.2.0としてポーズインフラストラクチャコンテナをリリース - # 詳細については、「KubernetesにWindowsノードを追加するためのガイド」で「pause」を検索してください nssm install kubelet C:\k\kubelet.exe nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config nssm set kubelet AppDirectory C:\k @@ -516,7 +535,7 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ PauseイメージがOSバージョンと互換性があることを確認してください。[説明](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)では、OSとコンテナの両方がバージョン1803であると想定しています。それ以降のバージョンのWindowsを使用している場合は、Insiderビルドなどでは、それに応じてイメージを調整する必要があります。イメージについては、Microsoftの[Dockerレジストリ](https://hub.docker.com/u/microsoft/)を参照してください。いずれにしても、PauseイメージのDockerfileとサンプルサービスの両方で、イメージに:latestのタグが付けられていると想定しています。 - Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。詳細については、[KubernetesにWindowsノードを追加するためのガイド](../user-guide-windows-nodes)で「Pause」を検索してください。 + Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。 1. DNS名前解決が正しく機能していない @@ -568,18 +587,16 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ ロードマップには多くの機能があります。高レベルの簡略リストを以下に示しますが、[ロードマッププロジェクト](https://github.com/orgs/kubernetes/projects/8)を見て、[貢献すること](https://github.com/kubernetes/community/blob/master/sig-windows/)によってWindowsサポートを改善することをお勧めします。 -### CRI-ContainerD -{{< glossary_tooltip term_id="containerd" >}}は、最近{{< glossary_tooltip text="CNCF" term_id="cncf" >}}プロジェクトとして卒業した、もう1つのOCI準拠ランタイムです。現在Linuxでテストされていますが、1.3はWindowsとHyper-Vをサポートします。[[リファレンス](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)] +### Hyper-V分離 -CRI-ContainerDインターフェイスは、Hyper-Vに基づいてサンドボックスを管理できるようになります。これにより、RuntimeClassを次のような新しいユースケースに実装できる基盤が提供されます: +Hyper-V分離はKubernetesで以下のWindowsコンテナのユースケースを実現するために必要です。 * Pod間のハイパーバイザーベースの分離により、セキュリティを強化 * 下位互換性により、コンテナの再構築を必要とせずにノードで新しいWindows Serverバージョンを実行 * Podの特定のCPU/NUMA設定 * メモリの分離と予約 -### Hyper-V分離 既存のHyper-V分離サポートは、v1.10の試験的な機能であり、上記のCRI-ContainerD機能とRuntimeClass機能を優先して将来廃止される予定です。現在の機能を使用してHyper-V分離コンテナを作成するには、kubeletのフィーチャーゲートを`HyperVContainer=true`で開始し、Podにアノテーション`experimental.windows.kubernetes.io/isolation-type=hyperv`を含める必要があります。実験的リリースでは、この機能はPodごとに1つのコンテナに制限されています。 @@ -609,7 +626,7 @@ spec: ### kubeadmとクラスターAPIを使用したデプロイ -Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。 +Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは進行中ですが、ガイドはすでに[ここ](/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)で利用可能です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。 ### その他の主な機能 * グループ管理サービスアカウントのベータサポート diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif deleted file mode 100644 index e3d94b9b54..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-install.gif and /dev/null differ diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif deleted file mode 100644 index 828417d685..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-join.gif and /dev/null differ diff --git a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif b/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif deleted file mode 100644 index e71d40d6df..0000000000 Binary files a/content/ja/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif and /dev/null differ diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index 9e218fae53..e1a23cadfd 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -19,7 +19,7 @@ Windowsアプリケーションは、多くの組織で実行されるサービ ## 始める前に -* [Windows Serverを実行するマスターノードとワーカーノード](/ja/docs/setup/production-environment/windows/user-guide-windows-nodes/)を含むKubernetesクラスターを作成します +* [Windows Serverを実行するマスターノードとワーカーノード](/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)を含むKubernetesクラスターを作成します * Kubernetes上にServiceとワークロードを作成してデプロイすることは、LinuxコンテナとWindowsコンテナ共に、ほぼ同じように動作することに注意してください。クラスターとのインタフェースとなる[Kubectlコマンド](/docs/reference/kubectl/overview/)も同じです。Windowsコンテナをすぐに体験できる例を以下セクションに用意しています。 ## はじめに:Windowsコンテナのデプロイ diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md deleted file mode 100644 index 9f54861a94..0000000000 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md +++ /dev/null @@ -1,306 +0,0 @@ ---- -title: Guide for adding Windows Nodes in Kubernetes -content_type: concept -weight: 70 ---- - - - -The Kubernetes platform can now be used to run both Linux and Windows containers. One or more Windows nodes can be registered to a cluster. This guide shows how to: - -* Register a Windows node to the cluster -* Configure networking so pods on Linux and Windows can communicate - - - - - -## Before you begin - -* Obtain a [Windows Server license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) in order to configure the Windows node that hosts Windows containers. You can use your organization's licenses for the cluster, or acquire one from Microsoft, a reseller, or via the major cloud providers such as GCP, AWS, and Azure by provisioning a virtual machine running Windows Server through their marketplaces. A [time-limited trial](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial) is also available. - -* Build a Linux-based Kubernetes cluster in which you have access to the control plane (some examples include [Creating a single control-plane cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/ja/docs/setup/production-environment/turnkey/azure/), [GCE](/ja/docs/setup/production-environment/turnkey/gce/), [AWS](/ja/docs/setup/production-environment/turnkey/aws/). - -## Getting Started: Adding a Windows Node to Your Cluster - -### Plan IP Addressing - -Kubernetes cluster management requires careful planning of your IP addresses so that you do not inadvertently cause network collision. This guide assumes that you are familiar with the [Kubernetes networking concepts](/docs/concepts/cluster-administration/networking/). - -In order to deploy your cluster you need the following address spaces: - -| Subnet / address range | Description | Default value | -| --- | --- | --- | -| Service Subnet | A non-routable, purely virtual subnet that is used by pods to uniformly access services without caring about the network topology. It is translated to/from routable address space by `kube-proxy` running on the nodes. | 10.96.0.0/12 | -| Cluster Subnet | This is a global subnet that is used by all pods in the cluster. Each node is assigned a smaller /24 subnet from this for their pods to use. It must be large enough to accommodate all pods used in your cluster. To calculate *minimumsubnet* size: `(number of nodes) + (number of nodes * maximum pods per node that you configure)`. Example: for a 5 node cluster for 100 pods per node: `(5) + (5 * 100) = 505.` | 10.244.0.0/16 | -| Kubernetes DNS Service IP | IP address of `kube-dns` service that is used for DNS resolution & cluster service discovery. | 10.96.0.10 | - -Review the networking options supported in 'Intro to Windows containers in Kubernetes: Supported Functionality: Networking' to determine how you need to allocate IP addresses for your cluster. - -### Components that run on Windows - -While the Kubernetes control plane runs on your Linux node(s), the following components are configured and run on your Windows node(s). - -1. kubelet -2. kube-proxy -3. kubectl (optional) -4. Container runtime - -Get the latest binaries from [https://github.com/kubernetes/kubernetes/releases](https://github.com/kubernetes/kubernetes/releases), starting with v1.14 or later. The Windows-amd64 binaries for kubeadm, kubectl, kubelet, and kube-proxy can be found under the CHANGELOG link. - -### Networking Configuration - -Once you have a Linux-based Kubernetes master node you are ready to choose a networking solution. This guide illustrates using Flannel in VXLAN mode for simplicity. - -#### Configuring Flannel in VXLAN mode on the Linux controller - -1. Prepare Kubernetes master for Flannel - - Some minor preparation is recommended on the Kubernetes master in our cluster. It is recommended to enable bridged IPv4 traffic to iptables chains when using Flannel. This can be done using the following command: - - ```bash - sudo sysctl net.bridge.bridge-nf-call-iptables=1 - ``` - -1. Download & configure Flannel - - Download the most recent Flannel manifest: - - ```bash - wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml - ``` - - There are two sections you should modify to enable the vxlan networking backend: - - After applying the steps below, the `net-conf.json` section of `kube-flannel.yml` should look as follows: - - ```json - net-conf.json: | - { - "Network": "10.244.0.0/16", - "Backend": { - "Type": "vxlan", - "VNI" : 4096, - "Port": 4789 - } - } - ``` - - {{< note >}}The VNI must be set to 4096 and port 4789 for Flannel on Linux to interoperate with Flannel on Windows. Support for other VNIs is coming soon. See the [VXLAN documentation](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) - for an explanation of these fields.{{< /note >}} - -1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check: - 1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan. - * VNI 4096 is set in the backend - * Port 4789 is set in the backend - 1. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`. - - - Your `cni-conf.json` should look as follows: - - ```json - cni-conf.json: | - { - "name": "vxlan0", - "plugins": [ - { - "type": "flannel", - "delegate": { - "hairpinMode": true, - "isDefaultGateway": true - } - }, - { - "type": "portmap", - "capabilities": { - "portMappings": true - } - } - ] - } - ``` - -1. Apply the Flannel yaml and Validate - - Let's apply the Flannel configuration: - - ```bash - kubectl apply -f kube-flannel.yml - ``` - - After a few minutes, you should see all the pods as running if the Flannel pod network was deployed. - - ```bash - kubectl get pods --all-namespaces - ``` - - The output looks like as follows: - - ``` - NAMESPACE NAME READY STATUS RESTARTS AGE - kube-system etcd-flannel-master 1/1 Running 0 1m - kube-system kube-apiserver-flannel-master 1/1 Running 0 1m - kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m - kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m - kube-system kube-flannel-ds-54954 1/1 Running 0 1m - kube-system kube-proxy-Zjlxz 1/1 Running 0 1m - kube-system kube-scheduler-flannel-master 1/1 Running 0 1m - ``` - - Verify that the Flannel DaemonSet has the NodeSelector applied. - - ```bash - kubectl get ds -n kube-system - ``` - - The output looks like as follows. The NodeSelector `beta.kubernetes.io/os=linux` is applied. - - ``` - NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE - kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d - kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d - ``` - -#### Join Windows Worker - -In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section. - -#### Preparing a Windows Node - -{{< note >}} -All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin). -{{< /note >}} - -1. Install Docker (requires a system reboot) - - Kubernetes uses [Docker](https://www.docker.com/) as its container engine, so we need to install it. You can follow the [official Docs instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#install-docker), the [Docker instructions](https://store.docker.com/editions/enterprise/docker-ee-server-windows), or try the following *recommended* steps: - - ```PowerShell - Enable-WindowsOptionalFeature -FeatureName Containers - Restart-Computer -Force - Install-Module -Name DockerMsftProvider -Repository PSGallery -Force - Install-Package -Name Docker -ProviderName DockerMsftProvider - ``` - - If you are behind a proxy, the following PowerShell environment variables must be defined: - - ```PowerShell - [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) - [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) - ``` - - After reboot, you can verify that the docker service is ready with the command below. - - ```PowerShell - docker version - ``` - - If you see error message like the following, you need to start the docker service manually. - - ``` - Client: - Version: 17.06.2-ee-11 - API version: 1.30 - Go version: go1.8.7 - Git commit: 06fc007 - Built: Thu May 17 06:14:39 2018 - OS/Arch: windows / amd64 - error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c - annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to - connect. This error may also indicate that the docker daemon is not running. - ``` - - You can start the docker service manually like below. - - ```PowerShell - Start-Service docker - ``` - - {{< note >}} - The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using "docker pull mcr.microsoft.com/k8s/core/pause:1.2.0". The DOCKERFILE is available at https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile. - {{< /note >}} - -1. Prepare a Windows directory for Kubernetes - - Create a "Kubernetes for Windows" directory to store Kubernetes binaries as well as any deployment scripts and config files. - - ```PowerShell - mkdir c:\k - ``` - -1. Copy Kubernetes certificate - - Copy the Kubernetes certificate file `$HOME/.kube/config` [from the Linux controller](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/creating-a-linux-master#collect-cluster-information) to this new `C:\k` directory on your Windows node. - - Tip: You can use tools such as [xcopy](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy), [WinSCP](https://winscp.net/eng/download.php), or this [PowerShell wrapper for WinSCP](https://www.powershellgallery.com/packages/WinSCP/5.13.2.0) to transfer the config file between nodes. - -1. Download Kubernetes binaries - - To be able to run Kubernetes, you first need to download the `kubelet` and `kube-proxy` binaries. You download these from the Node Binaries links in the CHANGELOG.md file of the [latest releases](https://github.com/kubernetes/kubernetes/releases/). For example 'kubernetes-node-windows-amd64.tar.gz'. You may also optionally download `kubectl` to run on Windows which you can find under Client Binaries. - - Use the [Expand-Archive](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.archive/expand-archive?view=powershell-6) PowerShell command to extract the archive and place the binaries into `C:\k`. - -#### Join the Windows node to the Flannel cluster - -The Flannel overlay deployment scripts and documentation are available in [this repository](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/overlay). The following steps are a simple walkthrough of the more comprehensive instructions available there. - -Download the [Flannel start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) script, the contents of which should be extracted to `C:\k`: - -```PowerShell -cd c:\k -[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/start.ps1 -o c:\k\start.ps1 -``` - -{{< note >}} -[start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) references [install.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/install.ps1), which downloads additional files such as the `flanneld` executable and the [Dockerfile for infrastructure pod](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/Dockerfile) and install those for you. For overlay networking mode, the [firewall](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/helper.psm1#L111) is opened for local UDP port 4789. There may be multiple powershell windows being opened/closed as well as a few seconds of network outage while the new external vSwitch for the pod network is being created the first time. Run the script using the arguments as specified below: -{{< /note >}} - -```PowerShell -cd c:\k -.\start.ps1 -ManagementIP ` - -NetworkMode overlay ` - -ClusterCIDR ` - -ServiceCIDR ` - -KubeDnsServiceIP ` - -LogDir -``` - -| Parameter | Default Value | Notes | -| --- | --- | --- | -| -ManagementIP | N/A (required) | The IP address assigned to the Windows node. You can use `ipconfig` to find this. | -| -NetworkMode | l2bridge | We're using `overlay` here | -| -ClusterCIDR | 10.244.0.0/16 | Refer to your cluster IP plan | -| -ServiceCIDR | 10.96.0.0/12 | Refer to your cluster IP plan | -| -KubeDnsServiceIP | 10.96.0.10 | | -| -InterfaceName | Ethernet | The name of the network interface of the Windows host. You can use ipconfig to find this. | -| -LogDir | C:\k | The directory where kubelet and kube-proxy logs are redirected into their respective output files. | - -Now you can view the Windows nodes in your cluster by running the following: - -```bash -kubectl get nodes -``` - -{{< note >}} -You may want to configure your Windows node components like kubelet and kube-proxy to run as services. View the services and background processes section under [troubleshooting](#troubleshooting) for additional instructions. Once you are running the node components as services, collecting logs becomes an important part of troubleshooting. View the [gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) section of the contributing guide for further instructions. -{{< /note >}} - -### Public Cloud Providers - -#### Azure - -AKS-Engine can deploy a complete, customizable Kubernetes cluster with both Linux & Windows nodes. There is a step-by-step walkthrough available in the [docs on GitHub](https://github.com/Azure/aks-engine/blob/master/docs/topics/windows.md). - -#### GCP - -Users can easily deploy a complete Kubernetes cluster on GCE following this step-by-step walkthrough on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/windows/README-GCE-Windows-kube-up.md) - -#### Deployment with kubeadm and cluster API - -Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned. - -### Next Steps - -Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster. - diff --git a/content/ja/docs/setup/release/version-skew-policy.md b/content/ja/docs/setup/release/version-skew-policy.md index 5c1a18b8ee..eb0764bcc3 100644 --- a/content/ja/docs/setup/release/version-skew-policy.md +++ b/content/ja/docs/setup/release/version-skew-policy.md @@ -12,14 +12,16 @@ weight: 30 ## サポートされるバージョン {#supported-versions} -Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメジャーバージョン、**y**はマイナーバージョン、**z**はパッチバージョンを指します。これは[セマンティック バージョニング](http://semver.org/)に従っています。詳細は、[Kubernetesのリリースバージョニング](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)を参照してください。 +Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメジャーバージョン、**y**はマイナーバージョン、**z**はパッチバージョンを指します。これは[セマンティック バージョニング](https://semver.org/)に従っています。詳細は、[Kubernetesのリリースバージョニング](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)を参照してください。 -Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。 +Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}})。 + +セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、これらのブランチから [定期的に](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence) 切り出され、必要に応じて追加の緊急リリースも行われます。 + + [リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。 -セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースチーム](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing)がこれを決定しています。パッチリリースチームは[リリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)の一部です。 詳細は、[Kubernetesパッチリリース](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)ページを参照してください。 -マイナーリリースは約3ヶ月ごとに行われるため、マイナーリリースのブランチはそれぞれ約9ヶ月保守されます。 ## サポートされるバージョンの差異 @@ -29,8 +31,8 @@ Kubernetesプロジェクトでは、最新の3つのマイナーリリースに 例: -* 最新の`kube-apiserver`が**1.13**であるとします -* ほかの`kube-apiserver`インスタンスは**1.13**および**1.12**がサポートされます +* 最新の`kube-apiserver`が**{{< skew latestVersion >}}**であるとします +* ほかの`kube-apiserver`インスタンスは**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**がサポートされます ### kubelet @@ -38,8 +40,8 @@ Kubernetesプロジェクトでは、最新の3つのマイナーリリースに 例: -* `kube-apiserver`が**1.13**であるとします -* `kubelet`は**1.13**、**1.12**および**1.11**がサポートされます +* `kube-apiserver`が**{{< skew latestVersion >}}**であるとします +* `kubelet`は**{{< skew latestVersion >}}**、**{{< skew prevMinorVersion >}}**および**{{< skew oldestMinorVersion >}}**がサポートされます {{< note >}} HAクラスター内の`kube-apiserver`間にバージョンの差異がある場合、有効な`kubelet`のバージョンは少なくなります。 @@ -47,8 +49,8 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 例: -* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします -* `kubelet`は**1.12**および**1.11**がサポートされます（**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません) +* `kube-apiserver`インスタンスが**{{< skew latestVersion >}}**および**1.12**であるとします +* `kubelet`は**{{< skew prevMinorVersion >}}**および**{{< skew oldestMinorVersion >}}**がサポートされます（**{{< skew latestVersion >}}**はバージョン**{{< skew prevMinorVersion >}}**の`kube-apiserver`よりも新しくなるためサポートされません) ### kube-controller-manager、kube-scheduler、およびcloud-controller-manager @@ -56,8 +58,8 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 例: -* `kube-apiserver`が**1.13**であるとします -* `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.13**および**1.12**がサポートされます +* `kube-apiserver`が**{{< skew latestVersion >}}**であるとします +* `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**がサポートされます {{< note >}} HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。 @@ -65,8 +67,8 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異があり 例: -* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします -* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます(**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません) +* `kube-apiserver`インスタンスが**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**であるとします +* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**{{< skew prevMinorVersion >}}**がサポートされます(**{{< skew latestVersion >}}**はバージョン**{{< skew prevMinorVersion >}}**の`kube-apiserver`よりも新しくなるためサポートされません) ### kubectl @@ -74,8 +76,8 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異があり 例: -* `kube-apiserver`が**1.13**であるとします -* `kubectl`は**1.14**、**1.13**および**1.12**がサポートされます +* `kube-apiserver`が**{{< skew latestVersion >}}**であるとします +* `kubectl`は**{{< skew nextMinorVersion >}}**、**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**がサポートされます {{< note >}} HAクラスター内の`kube-apiserver`間にバージョンの差異がある場合、有効な`kubectl`バージョンは少なくなります。 @@ -83,26 +85,26 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 例: -* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします -* `kubectl`は**1.13**および**1.12**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります) +* `kube-apiserver`インスタンスが**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**であるとします +* `kubectl`は**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります) ## サポートされるコンポーネントのアップグレード順序 -コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)** へ移行するために、コンポーネントをアップグレードする順序を説明します。 +コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**{{< skew prevMinorVersion >}}**から**{{< skew latestVersion >}}** へ移行するために、コンポーネントをアップグレードする順序を説明します。 ### kube-apiserver 前提条件: -* シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします -* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります) -* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります) -* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります) +* シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**{{< skew prevMinorVersion >}}**とします +* HAクラスターにおいて、既存の`kube-apiserver`は**{{< skew prevMinorVersion >}}**または**{{< skew latestVersion >}}** とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります) +* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**{{< skew prevMinorVersion >}}**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります) +* すべてのノードの`kubelet`インスタンスはバージョン**{{< skew prevMinorVersion >}}**または**{{< skew oldestMinorVersion >}}** とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります) * 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます: - * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください) - * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)** のバージョンで追加された新しいフィールドを扱うことができます + * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**{{< skew latestVersion >}}** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください) + * Webhookは送信されたRESTリソースの新しいバージョン、および**{{< skew latestVersion >}}** のバージョンで追加された新しいフィールドを扱うことができます -`kube-apiserver`を**1.(n+1)** にアップグレードしてください。 +`kube-apiserver`を**{{< skew latestVersion >}}** にアップグレードしてください。 {{< note >}} [非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。 @@ -112,17 +114,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある 前提条件: -* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること(これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません) +* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**{{< skew latestVersion >}}** であること(これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません) -`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)** にアップグレードしてください。 +`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**{{< skew latestVersion >}}** にアップグレードしてください。 ### kubelet 前提条件: -* `kubelet`と通信する`kube-apiserver`が**1.(n+1)** であること +* `kubelet`と通信する`kube-apiserver`が**{{< skew latestVersion >}}** であること -必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください(**1.n**や**1.(n-1)** のままにすることもできます)。 +必要に応じて、`kubelet`インスタンスを**{{< skew latestVersion >}}** にアップグレードしてください(**{{< skew prevMinorVersion >}}**や**{{< skew oldestMinorVersion >}}** のままにすることもできます)。 {{< warning >}} `kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません: @@ -130,3 +132,18 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある * コントロールプレーンをアップグレードする前に、インスタンスを`kube-apiserver`の1つのマイナーバージョン内にアップグレードさせる必要があります * メンテナンスされている3つのマイナーリリースよりも古いバージョンの`kubelet`を実行する可能性が高まります {{}} + + + +### kube-proxy + +* `kube-proxy`のマイナーバージョンはノード上の`kubelet`と同じマイナーバージョンでなければなりません +* `kube-proxy`は`kube-apiserver`よりも新しいものであってはなりません +* `kube-proxy`のマイナーバージョンは`kube-apiserver`のマイナーバージョンよりも2つ以上古いものでなければなりません + +例: + +`kube-proxy`のバージョンが**{{< skew oldestMinorVersion >}}**の場合: + +* `kubelet`のバージョンは**{{< skew oldestMinorVersion >}}**でなければなりません +* `kube-apiserver`のバージョンは**{{< skew oldestMinorVersion >}}**と**{{< skew latestVersion >}}**の間でなければなりません diff --git a/content/ja/docs/tasks/tools/_index.md b/content/ja/docs/tasks/tools/_index.md index ac97313bb8..72a8c1361f 100755 --- a/content/ja/docs/tasks/tools/_index.md +++ b/content/ja/docs/tasks/tools/_index.md @@ -17,7 +17,7 @@ Kubernetesのコマンドラインツール`kubectl`を使用すると、Kuberne [Minikube](https://minikube.sigs.k8s.io/)は、Kubernetesをローカルで実行するツールです。MinikubeはシングルノードのKubernetesクラスターをパーソナルコンピューター上(Windows、macOS、Linux PCを含む)で実行することで、Kubernetesを試したり、日常的な開発作業のために利用できます。 -ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従うか、[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を読んでください。 +ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従ってください。 Minikubeが起動したら、[サンプルアプリケーションの実行](/ja/docs/tutorials/hello-minikube/)を試すことができます。 diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 2ab3ca50f7..a33b475671 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -502,7 +502,7 @@ compinit ## {{% heading "whatsnext" %}} -* [Minikubeをインストールする](/ja/docs/tasks/tools/install-minikube/) +* [Minikubeをインストールする](https://minikube.sigs.k8s.io/docs/start/) * クラスターの作成に関する詳細を[スタートガイド](/ja/docs/setup/)で確認する * [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/) * あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md deleted file mode 100644 index 730145740c..0000000000 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ /dev/null @@ -1,267 +0,0 @@ ---- -title: Minikubeのインストール -content_type: task -weight: 20 -card: - name: tasks - weight: 10 ---- - - - -このページでは[Minikube](/ja/docs/tutorials/hello-minikube)のインストール方法を説明し、コンピューターの仮想マシン上で単一ノードのKubernetesクラスターを実行します。 - - - -## {{% heading "prerequisites" %}} - - -{{< tabs name="minikube_before_you_begin" >}} -{{% tab name="Linux" %}} -Linuxで仮想化がサポートされているかどうかを確認するには、次のコマンドを実行して、出力が空でないことを確認します: -``` -grep -E --color 'vmx|svm' /proc/cpuinfo -``` -{{% /tab %}} - -{{% tab name="macOS" %}} -仮想化がmacOSでサポートされているかどうかを確認するには、ターミナルで次のコマンドを実行します。 -``` -sysctl -a | grep -E --color 'machdep.cpu.features|VMX' -``` -出力に`VMX`が表示されている場合(色付けされているはずです)、VT-x機能がマシンで有効になっています。 -{{% /tab %}} - -{{% tab name="Windows" %}} -Windows 8以降で仮想化がサポートされているかどうかを確認するには、Windowsターミナルまたはコマンドプロンプトで次のコマンドを実行します。 -``` -systeminfo -``` -次の出力が表示される場合、仮想化はWindowsでサポートされています。 -``` -Hyper-V Requirements: VM Monitor Mode Extensions: Yes - Virtualization Enabled In Firmware: Yes - Second Level Address Translation: Yes - Data Execution Prevention Available: Yes -``` - -次の出力が表示される場合、システムにはすでにHypervisorがインストールされており、次の手順をスキップできます。 -``` -Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed. -``` - - -{{% /tab %}} -{{< /tabs >}} - - - - - -## minikubeのインストール - -{{< tabs name="tab_with_md" >}} -{{% tab name="Linux" %}} - -### kubectlのインストール - -kubectlがインストールされていることを確認してください。 -[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)の指示に従ってkubectlをインストールできます。 - -### ハイパーバイザーのインストール - -ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください: - -• [KVM](https://www.linux-kvm.org/)、ただしQEMUも使っているもの - -• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - -Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--driver=none`オプションもサポートしています。 -このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 - -Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。 -[Docker](https://www.docker.com/products/docker-desktop)から`.deb`パッケージをダウンロードできます。 - -{{< caution >}} -`none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 -`--driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 -{{< /caution >}} - -MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。 - -{{< caution >}} -`podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常のユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。 -{{< /caution >}} - -### パッケージを利用したMinikubeのインストール - -Minikubeの*Experimental*パッケージが利用可能です。 -GitHubのMinikubeの[リリース](https://github.com/kubernetes/minikube/releases)ページからLinux(AMD64)パッケージを見つけることができます。 - -Linuxのディストリビューションのパッケージツールを使用して、適切なパッケージをインストールしてください。 - -### 直接ダウンロードによるMinikubeのインストール - -パッケージ経由でインストールしない場合は、スタンドアロンバイナリをダウンロードして使用できます。 - -```shell -curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \ - && chmod +x minikube -``` - -Minikube実行可能バイナリをパスに追加する簡単な方法を次に示します: - -```shell -sudo mkdir -p /usr/local/bin/ -sudo install minikube /usr/local/bin/ -``` - -### Homebrewを利用したMinikubeのインストール - -別の選択肢として、Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)を利用してインストールできます。 - -```shell -brew install minikube -``` - -{{% /tab %}} -{{% tab name="macOS" %}} -### kubectlのインストール - -kubectlがインストールされていることを確認してください。 -[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)の指示に従ってkubectlをインストールできます。 - -### ハイパーバイザーのインストール - -ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください: - -• [HyperKit](https://github.com/moby/hyperkit) - -• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - -• [VMware Fusion](https://www.vmware.com/products/fusion) - -### Minikubeのインストール -[Homebrew](https://brew.sh)を使うことでmacOSにMinikubeを簡単にインストールできます: - -```shell -brew install minikube -``` - -スタンドアロンのバイナリをダウンロードして、macOSにインストールすることもできます: - -```shell -curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ - && chmod +x minikube -``` - -Minikube実行可能バイナリをパスに追加する簡単な方法を次に示します: - -```shell -sudo mv minikube /usr/local/bin -``` - -{{% /tab %}} -{{% tab name="Windows" %}} -### kubectlのインストール - -kubectlがインストールされていることを確認してください。 -[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)の指示に従ってkubectlをインストールできます。 - -### ハイパーバイザーのインストール - -ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください: - -• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) - -• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - -{{< note >}} -Hyper-Vは、Windows 10 Enterprise、Windows 10 Professional、Windows 10 Educationの3つのバージョンのWindows 10で実行できます。 -{{< /note >}} - -### Chocolateyを使用したMinikubeのインストール - -[Chocolatey](https://chocolatey.org/)を使うことでWindowsにMinikubeを簡単にインストールできます(管理者権限で実行する必要があります)。 - -```shell -choco install minikube -``` - -Minikubeのインストールが終わったら、現在のCLIのセッションを終了して再起動します。Minikubeは自動的にパスに追加されます。 - -### インストーラーを使用したMinikubeのインストール - -[Windowsインストーラー](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)を使用してWindowsにMinikubeを手動でインストールするには、[`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)をダウンロードしてインストーラーを実行します。 - -### 直接ダウンロードによるMinikubeのインストール - -WindowsにMinikubeを手動でインストールするには、[`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)をダウンロードし、名前を`minikube.exe`に変更して、パスに追加します。 - -{{% /tab %}} -{{< /tabs >}} - - - -## インストールの確認 - -ハイパーバイザーとMinikube両方のインストール成功を確認するため、以下のコマンドをローカルKubernetesクラスターを起動するために実行してください: - -{{< note >}} - -`minikube start`で`--driver`の設定をするため、次の``の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--driver`値のすべてのリストは、[specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。 - -{{< /note >}} - -{{< caution >}} -KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu:///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu:///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。 -{{< /caution >}} - -```shell -minikube start --driver= -``` - -`minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。 - -```shell -minikube status -``` - -クラスターが起動していると、`minikube status`の出力はこのようになります。 - -``` -host: Running -kubelet: Running -apiserver: Running -kubeconfig: Configured -``` - -選択したハイパーバイザーでMinikubeが動作しているか確認した後は、そのままMinikubeを使い続けることもできます。また、クラスターを停止することもできます。クラスターを停止するためには、次を実行してください。 - -```shell -minikube stop -``` - -## ローカル状態のクリーンアップ {#cleanup-local-state} - -もし以前に　Minikubeをインストールしていたら、以下のコマンドを実行します。 -```shell -minikube start -``` - -`minikube start`はエラーを返します。 -```shell -machine does not exist -``` - -minikubeのローカル状態をクリアする必要があります: -```shell -minikube delete -``` - - -## {{% heading "whatsnext" %}} - - -* [Minikubeを使ってローカルでKubernetesを実行する](/ja/docs/setup/learning-environment/minikube/) - diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 530e53ffd5..35192a8ca9 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -18,7 +18,7 @@ card: このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でサンプルアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 {{< note >}} -[Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。 +[Minikubeをローカルにインストール](https://minikube.sigs.k8s.io/docs/start/)している場合もこのチュートリアルを進めることが可能です。 {{< /note >}} diff --git a/content/ja/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/ja/docs/tutorials/kubernetes-basics/explore/explore-intro.html index 63b3d503b2..47f9954a15 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -29,7 +29,7 @@ weight: 10

Kubernetes Pod

-

モジュール2でDeploymentを作成したときに、KubernetesはアプリケーションインスタンスをホストするためのPodを作成しました。Podは、1つ以上のアプリケーションコンテナ(Dockerやrktなど)のグループとそれらのコンテナの共有リソースを表すKubernetesの抽象概念です。 Podには以下のものが含まれます:

+

モジュール2でDeploymentを作成したときに、KubernetesはアプリケーションインスタンスをホストするためのPodを作成しました。Podは、1つ以上のアプリケーションコンテナ(Dockerなど)のグループとそれらのコンテナの共有リソースを表すKubernetesの抽象概念です。 Podには以下のものが含まれます:

  • 共有ストレージ(ボリューム)
  • ネットワーキング(クラスターに固有のIPアドレス)
    • @@ -49,7 +49,7 @@ weight: 10

- Podは1つ以上のアプリケーションコンテナ(Dockerやrktなど)のグループであり、共有ストレージ(ボリューム)、IPアドレス、それらの実行方法に関する情報が含まれています。 + Podは1つ以上のアプリケーションコンテナ(Dockerなど)のグループであり、共有ストレージ(ボリューム)、IPアドレス、それらの実行方法に関する情報が含まれています。

@@ -77,7 +77,7 @@ weight: 10

すべてのKubernetesノードでは少なくとも以下のものが動作します。

  • Kubelet: Kubernetesマスターとノード間の通信を担当するプロセス。マシン上で実行されているPodとコンテナを管理します。
    • -
  • レジストリからコンテナイメージを取得し、コンテナを解凍し、アプリケーションを実行することを担当する、Docker、rktのようなコンテナランタイム。
    • +
  • レジストリからコンテナイメージを取得し、コンテナを解凍し、アプリケーションを実行することを担当する、Dockerのようなコンテナランタイム。
diff --git a/content/ja/examples/application/job/cronjob.yaml b/content/ja/examples/application/job/cronjob.yaml index c9d3893027..2ce31233c3 100644 --- a/content/ja/examples/application/job/cronjob.yaml +++ b/content/ja/examples/application/job/cronjob.yaml @@ -11,7 +11,7 @@ spec: containers: - name: hello image: busybox - args: + command: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 39d17396ff..40bea7b523 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -19,6 +19,7 @@ cid: community
+커뮤니티 가치      행동 강령       비디오      토론      @@ -41,10 +42,28 @@ cid: community 쿠버네티스 컨퍼런스 갤러리
쿠버네티스 컨퍼런스 갤러리 - - + +
+
+
+

+

+

커뮤니티 가치

+쿠버네티스 커뮤니티가 추구하는 가치는 프로젝트의 지속적인 성공의 핵심입니다.
+이러한 원칙은 쿠버네티스 프로젝트의 모든 측면을 이끌어 갑니다. +
+ +

+ + 더 읽어 보기 + + +
+
+
+
diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 784ad2ac58..29926d1435 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -102,7 +102,7 @@ weight: 30 온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가 서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는 [쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해 -IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자 APIS 및 +IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API들 및 기타 서비스 등과 간접적으로 연동하여 이를 구현한다. ## 의도한 상태와 현재 상태 {#desired-vs-current} diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index c951d60ca8..2bcdd9faaf 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -10,7 +10,7 @@ weight: 10 노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 의해 관리되며 {{< glossary_tooltip text="파드" term_id="pod" >}}를 -실행하는데 필요한 서비스를 포함한다. +실행하는 데 필요한 서비스를 포함한다. 일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는 환경에서는 하나만 있을 수도 있다. diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index 1442a5da01..3ec34e9eac 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -22,12 +22,12 @@ no_list: true 가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다. - - 컴퓨터에서 쿠버네티스를 그냥 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다. + - 컴퓨터에서 쿠버네티스를 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다. - [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가? - 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다. - **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다. - 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가? - - **단지 클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약 + - **클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약 후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만, 더 다양한 선택을 제공한다. - 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자. diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 48044b0460..695c747a5d 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -1,4 +1,7 @@ --- + + + title: 로깅 아키텍처 content_type: concept weight: 60 @@ -6,23 +9,22 @@ weight: 60 -애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. +애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. -그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다. +그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. +예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것이다. +클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. -클러스터-레벨 로깅 아키텍처는 로깅 백엔드가 -클러스터 내부 또는 외부에 존재한다고 가정하여 설명한다. 클러스터-레벨 -로깅에 관심이 없는 경우에도, 노드에서 로그를 저장하고 -처리하는 방법에 대한 설명이 여전히 유용할 수 있다. +클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 +로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, +쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다. ## 쿠버네티스의 기본 로깅 -이 섹션에서는, 쿠버네티스에서 표준 출력 스트림으로 데이터를 -출력하는 기본 로깅의 예시를 볼 수 있다. 이 데모에서는 -일부 텍스트를 초당 한 번씩 표준 출력에 쓰는 컨테이너와 함께 -파드 명세를 사용한다. +이 예시는 텍스트를 초당 한 번씩 표준 출력에 쓰는 +컨테이너에 대한 `Pod` 명세를 사용한다. {{< codenew file="debug/counter-pod.yaml" >}} @@ -31,8 +33,10 @@ weight: 60 ```shell kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml ``` + 출력은 다음과 같다. -``` + +```console pod/counter created ``` @@ -41,69 +45,69 @@ pod/counter created ```shell kubectl logs counter ``` + 출력은 다음과 같다. -``` + +```console 0: Mon Jan 1 00:00:00 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001 ... ``` -컨테이너가 크래시된 경우, `kubectl logs` 의 `--previous` 플래그를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다. 파드에 여러 컨테이너가 있는 경우, 명령에 컨테이너 이름을 추가하여 접근하려는 컨테이너 로그를 지정해야 한다. 자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다. +`kubectl logs --previous` 를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다. 파드에 여러 컨테이너가 있는 경우, 명령에 컨테이너 이름을 추가하여 접근하려는 컨테이너 로그를 지정해야 한다. 자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다. ## 노드 레벨에서의 로깅 ![노드 레벨 로깅](/images/docs/user-guide/logging/logging-node-level.png) -컨테이너화된 애플리케이션이 `stdout(표준 출력)` 및 `stderr(표준 에러)` 에 쓰는 모든 것은 컨테이너 엔진에 의해 어딘가에서 처리와 리디렉션 된다. 예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 json 형식의 파일에 작성하도록 구성된다. +컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 엔진이 처리 및 리디렉션 한다. +예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 JSON 형식의 파일에 작성하도록 구성된다. {{< note >}} -도커 json 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다. +도커 JSON 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다. {{< /note >}} 기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다. 노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여, 로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는 -현재 로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로 +로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로 이를 해결하기 위한 솔루션을 설정해야 한다. 예를 들어, `kube-up.sh` 스크립트에 의해 배포된 쿠버네티스 클러스터에는, 매시간 실행되도록 구성된 [`logrotate`](https://linux.die.net/man/8/logrotate) -도구가 있다. 예를 들어, 도커의 `log-opt` 를 사용하여 애플리케이션의 로그를 -자동으로 로테이션을 하도록 컨테이너 런타임을 설정할 수도 있다. -`kube-up.sh` 스크립트에서, 후자의 접근 방식은 GCP의 COS 이미지에 사용되며, -전자의 접근 방식은 다른 환경에서 사용된다. 두 경우 모두, -기본적으로 로그 파일이 10MB를 초과하면 로테이션이 되도록 구성된다. +도구가 있다. 애플리케이션의 로그를 자동으로 +로테이션하도록 컨테이너 런타임을 설정할 수도 있다. -예를 들어, `kube-up.sh` 가 해당 -[스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)에서 -GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 찾을 수 있다. +예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은 +[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해 +자세히 알 수 있다. 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를 실행하면, 노드의 kubelet이 요청을 처리하고 -로그 파일에서 직접 읽은 다음, 응답의 내용을 반환한다. +로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다. {{< note >}} -현재, 일부 외부 시스템에서 로테이션을 수행한 경우, +만약, 일부 외부 시스템이 로테이션을 수행한 경우, `kubectl logs` 를 통해 최신 로그 파일의 내용만 사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가 -로테이션을 수행하고 두 개의 파일이 생긴다(크기가 10MB인 파일 하나와 비어있는 파일). -그 후 `kubectl logs` 는 빈 응답을 반환한다. +로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일) +`kubectl logs` 는 이 예시에서는 빈 응답에 해당하는 최신 로그 파일을 반환한다. {{< /note >}} -[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh ### 시스템 컴포넌트 로그 시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. 예를 들면 다음과 같다. * 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다. -* Kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다. +* Kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다. -systemd를 사용하는 시스템에서, kubelet과 컨테이너 런타임은 journald에 작성한다. -systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 작성한다. -컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고, -항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog](https://github.com/kubernetes/klog) +systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 journald에 작성한다. +systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/log` 디렉터리의 +`.log` 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고, +항상 `/var/log` 디렉터리에 기록한다. +시스템 컴포넌트는 [klog](https://github.com/kubernetes/klog) 로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서 해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다. @@ -126,13 +130,14 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 각 노드에 _노드-레벨 로깅 에이전트_ 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다. 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다. 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다. -로깅 에이전트는 모든 노드에서 실행해야 하므로, 이를 데몬셋 레플리카, 매니페스트 파드 또는 노드의 전용 네이티브 프로세스로 구현하는 것이 일반적이다. 그러나 후자의 두 가지 접근법은 더 이상 사용되지 않으며 절대 권장하지 않는다. +로깅 에이전트는 모든 노드에서 실행해야 하므로, 에이전트는 +`DaemonSet` 으로 동작시키는 것을 추천한다. -쿠버네티스 클러스터는 노드-레벨 로깅 에이전트를 사용하는 것이 가장 일반적이며 권장되는 방법으로, 이는 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션을 변경할 필요가 없기 때문이다. 그러나, 노드-레벨 로깅은 _애플리케이션의 표준 출력과 표준 에러에 대해서만 작동한다_ . +노드-레벨 로깅은 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션에 대한 변경은 필요로 하지 않는다. -쿠버네티스는 로깅 에이전트를 지정하지 않지만, 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트(Google 클라우드 플랫폼과 함께 사용하기 위한 [스택드라이버(Stackdriver) 로깅](/docs/tasks/debug-application-cluster/logging-stackdriver/)과 [엘라스틱서치(Elasticsearch)](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/))가 패키지로 함께 제공된다. 전용 문서에서 자세한 정보와 지침을 찾을 수 있다. 두 가지 다 사용자 정의 구성이 된 [fluentd](http://www.fluentd.org/)를 에이전트로써 노드에서 사용한다. +컨테이너는 stdout과 stderr를 동의되지 않은 포맷으로 작성한다. 노드-레벨 에이전트는 이러한 로그를 수집하고 취합을 위해 전달한다. -### 로깅 에이전트와 함께 사이드카 컨테이너 사용 +### 로깅 에이전트와 함께 사이드카 컨테이너 사용 {#sidecar-container-with-logging-agent} 다음 중 한 가지 방법으로 사이드카 컨테이너를 사용할 수 있다. @@ -143,28 +148,27 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 ![스트리밍 컨테이너가 있는 사이드카 컨테이너](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) -사이드카 컨테이너를 자체 `stdout` 및 `stderr` 스트림으로 -스트리밍하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를 -활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 -또는 journald에서 로그를 읽는다. 각 개별 사이드카 컨테이너는 자체 `stdout` -또는 `stderr` 스트림에 로그를 출력한다. +사이드카 컨테이너가 자체 `stdout` 및 `stderr` 스트림으로 +쓰도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를 +활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 또는 journald에서 로그를 읽는다. +각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다. 이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을 분리할 수 ​​있고, 이 중 일부는 `stdout` 또는 `stderr` 에 작성하기 위한 지원이 부족할 수 있다. 로그를 리디렉션하는 로직은 -미미하기 때문에, 큰 오버헤드가 거의 없다. 또한, +최소화되어 있기 때문에, 심각한 오버헤드가 아니다. 또한, `stdout` 및 `stderr` 가 kubelet에서 처리되므로, `kubectl logs` 와 같은 빌트인 도구를 사용할 수 있다. -다음의 예를 고려해보자. 파드는 단일 컨테이너를 실행하고, 컨테이너는 -서로 다른 두 가지 형식을 사용하여, 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한 +예를 들어, 파드는 단일 컨테이너를 실행하고, 컨테이너는 +서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한 구성 파일은 다음과 같다. {{< codenew file="admin/logging/two-files-counter-pod.yaml" >}} 두 컴포넌트를 컨테이너의 `stdout` 스트림으로 리디렉션한 경우에도, 동일한 로그 -스트림에 서로 다른 형식의 로그 항목을 갖는 것은 -알아보기 힘들다. 대신, 두 개의 사이드카 컨테이너를 도입할 수 있다. 각 사이드카 +스트림에 서로 다른 형식의 로그 항목을 작성하는 것은 +추천하지 않는다. 대신, 두 개의 사이드카 컨테이너를 생성할 수 있다. 각 사이드카 컨테이너는 공유 볼륨에서 특정 로그 파일을 테일(tail)한 다음 로그를 자체 `stdout` 스트림으로 리디렉션할 수 있다. @@ -178,7 +182,10 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 ```shell kubectl logs counter count-log-1 ``` -``` + +출력은 다음과 같다. + +```console 0: Mon Jan 1 00:00:00 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001 @@ -188,7 +195,10 @@ kubectl logs counter count-log-1 ```shell kubectl logs counter count-log-2 ``` -``` + +출력은 다음과 같다. + +```console Mon Jan 1 00:00:00 UTC 2001 INFO 0 Mon Jan 1 00:00:01 UTC 2001 INFO 1 Mon Jan 1 00:00:02 UTC 2001 INFO 2 @@ -204,11 +214,10 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2 `stdout` 으로 스트리밍하면 디스크 사용량은 두 배가 될 수 있다. 단일 파일에 쓰는 애플리케이션이 있는 경우, 일반적으로 스트리밍 사이드카 컨테이너 방식을 구현하는 대신 `/dev/stdout` 을 대상으로 -설정하는 것이 더 낫다. +설정하는 것을 추천한다. 사이드카 컨테이너를 사용하여 애플리케이션 자체에서 로테이션할 수 없는 -로그 파일을 로테이션할 수도 있다. 이 방법의 예로는 -정기적으로 logrotate를 실행하는 작은 컨테이너를 두는 것이다. +로그 파일을 로테이션할 수도 있다. 이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다. 그러나, `stdout` 및 `stderr` 을 직접 사용하고 로테이션과 유지 정책을 kubelet에 두는 것이 권장된다. @@ -223,21 +232,17 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2 {{< note >}} 사이드카 컨테이너에서 로깅 에이전트를 사용하면 상당한 리소스 소비로 이어질 수 있다. 게다가, kubelet에 의해 -제어되지 않기 때문에, `kubectl logs` 명령을 사용하여 해당 로그에 +제어되지 않기 때문에, `kubectl logs` 를 사용하여 해당 로그에 접근할 수 없다. {{< /note >}} -예를 들어, 로깅 에이전트로 fluentd를 사용하는 [스택드라이버](/docs/tasks/debug-application-cluster/logging-stackdriver/)를 -사용할 수 있다. 여기에 이 방법을 구현하는 데 사용할 수 있는 -두 가지 구성 파일이 있다. 첫 번째 파일에는 -fluentd를 구성하기 위한 [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다. +여기에 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 구성 파일이 있다. 첫 번째 파일에는 +fluentd를 구성하기 위한 [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다. {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} {{< note >}} -fluentd의 구성은 이 문서의 범위를 벗어난다. -fluentd를 구성하는 것에 대한 자세한 내용은, -[공식 fluentd 문서](https://docs.fluentd.org/)를 참고한다. +fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](https://docs.fluentd.org/)를 참고한다. {{< /note >}} 두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다. @@ -245,16 +250,10 @@ fluentd를 구성하는 것에 대한 자세한 내용은, {{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} -얼마 후 스택드라이버 인터페이스에서 로그 메시지를 찾을 수 있다. - -이것은 단지 예시일 뿐이며 실제로 애플리케이션 컨테이너 내의 -모든 소스에서 읽은 fluentd를 로깅 에이전트로 대체할 수 있다는 것을 -기억한다. +이 예시 구성에서, 사용자는 애플리케이션 컨테이너 내의 모든 소스을 읽는 fluentd를 다른 로깅 에이전트로 대체할 수 있다. ### 애플리케이션에서 직접 로그 노출 ![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png) -모든 애플리케이션에서 직접 로그를 노출하거나 푸시하여 클러스터-레벨 로깅을 -구현할 수 있다. 그러나, 이러한 로깅 메커니즘의 구현은 -쿠버네티스의 범위를 벗어난다. +모든 애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다. diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index be5befdbd3..9893c76548 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -1,4 +1,6 @@ --- + + title: 리소스 관리 content_type: concept weight: 40 @@ -43,7 +45,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/ `kubectl` 은 접미사가 `.yaml`, `.yml` 또는 `.json` 인 파일을 읽는다. -동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 일괄로 배포할 수 있다. +동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다. URL을 구성 소스로 지정할 수도 있다. 이는 github에 체크인된 구성 파일에서 직접 배포하는 데 편리하다. @@ -68,7 +70,7 @@ deployment.apps "my-nginx" deleted service "my-nginx-svc" deleted ``` -두 개의 리소스만 있는 경우, 리소스/이름 구문을 사용하여 커맨드 라인에서 둘다 모두 쉽게 지정할 수도 있다. +두 개의 리소스가 있는 경우, 리소스/이름 구문을 사용하여 커맨드 라인에서 둘다 모두 지정할 수도 있다. ```shell kubectl delete deployments/my-nginx services/my-nginx-svc @@ -85,10 +87,11 @@ deployment.apps "my-nginx" deleted service "my-nginx-svc" deleted ``` -`kubectl` 은 입력을 받아들이는 것과 동일한 구문으로 리소스 이름을 출력하므로, `$()` 또는 `xargs` 를 사용하여 작업을 쉽게 연결할 수 있다. +`kubectl` 은 입력을 받아들이는 것과 동일한 구문으로 리소스 이름을 출력하므로, `$()` 또는 `xargs` 를 사용하여 작업을 연결할 수 있다. ```shell kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service) +kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {} ``` ```shell @@ -262,7 +265,7 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m ## 레이블 업데이트 새로운 리소스를 만들기 전에 기존 파드 및 기타 리소스의 레이블을 다시 지정해야 하는 경우가 있다. 이것은 `kubectl label` 로 수행할 수 있다. -예를 들어, 모든 nginx 파드에 프론트엔드 티어로 레이블을 지정하려면, 간단히 다음과 같이 실행한다. +예를 들어, 모든 nginx 파드에 프론트엔드 티어로 레이블을 지정하려면, 다음과 같이 실행한다. ```shell kubectl label pods -l app=nginx tier=fe @@ -299,6 +302,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' kubectl get pods my-nginx-v4-9gw19 -o yaml ``` + ```shell apiVersion: v1 kind: pod @@ -312,11 +316,12 @@ metadata: ## 애플리케이션 스케일링 -애플리케이션의 로드가 증가하거나 축소되면, `kubectl` 을 사용하여 쉽게 스케일링할 수 있다. 예를 들어, nginx 레플리카 수를 3에서 1로 줄이려면, 다음을 수행한다. +애플리케이션의 로드가 증가하거나 축소되면, `kubectl` 을 사용하여 애플리케이션을 스케일링한다. 예를 들어, nginx 레플리카 수를 3에서 1로 줄이려면, 다음을 수행한다. ```shell kubectl scale deployment/my-nginx --replicas=1 ``` + ```shell deployment.apps/my-nginx scaled ``` @@ -326,6 +331,7 @@ deployment.apps/my-nginx scaled ```shell kubectl get pods -l app=nginx ``` + ```shell NAME READY STATUS RESTARTS AGE my-nginx-2035384211-j5fhi 1/1 Running 0 30m @@ -336,6 +342,7 @@ my-nginx-2035384211-j5fhi 1/1 Running 0 30m ```shell kubectl autoscale deployment/my-nginx --min=1 --max=3 ``` + ```shell horizontalpodautoscaler.autoscaling/my-nginx autoscaled ``` @@ -404,11 +411,12 @@ JSON 병합 패치 그리고 전략적 병합 패치를 지원한다. ## 파괴적(disruptive) 업데이트 -경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을 즉시 원할 수도 있다. 이러한 필드를 변경하려면, `replace --force` 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 간단히 수정할 수 있다. +경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을 즉시 원할 수도 있다. 이러한 필드를 변경하려면, `replace --force` 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 수정할 수 있다. ```shell kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force ``` + ```shell deployment.apps/my-nginx deleted deployment.apps/my-nginx replaced @@ -425,19 +433,22 @@ nginx 1.14.2 버전을 실행한다고 가정해 보겠다. ```shell kubectl create deployment my-nginx --image=nginx:1.14.2 ``` + ```shell deployment.apps/my-nginx created ``` 3개의 레플리카를 포함한다(이전과 새 개정판이 공존할 수 있음). + ```shell kubectl scale deployment my-nginx --current-replicas=1 --replicas=3 ``` + ``` deployment.apps/my-nginx scaled ``` -1.16.1 버전으로 업데이트하려면, 위에서 배운 kubectl 명령을 사용하여 `.spec.template.spec.containers[0].image` 를 `nginx:1.14.2` 에서 `nginx:1.16.1` 로 간단히 변경한다. +1.16.1 버전으로 업데이트하려면, 위에서 배운 kubectl 명령을 사용하여 `.spec.template.spec.containers[0].image` 를 `nginx:1.14.2` 에서 `nginx:1.16.1` 로 변경한다. ```shell kubectl edit deployment/my-nginx @@ -452,5 +463,3 @@ kubectl edit deployment/my-nginx - [애플리케이션 검사 및 디버깅에 `kubectl` 을 사용하는 방법](/docs/tasks/debug-application-cluster/debug-application-introspection/)에 대해 알아본다. - [구성 모범 사례 및 팁](/ko/docs/concepts/configuration/overview/)을 참고한다. - - diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 6bcec1d6c0..def34dd231 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -59,13 +59,13 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. -- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. +- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. ## 레이블 사용하기 - `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. -릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다. +릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다. 오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 073eb2ff4a..4637c1a63d 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -1,4 +1,6 @@ --- + + title: 시크릿(Secret) content_type: concept feature: @@ -24,8 +26,8 @@ weight: 30 {{< caution >}} 쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다. -기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에 -액세스할 수 있는 모든 사용자가 일반 텍스트로 검색 할 수 있다. +기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에 +액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다. 시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다. 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/). @@ -280,9 +282,9 @@ API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 검증도 한다. {{< caution >}} -SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버간에 신뢰할 수있는 통신을 -설정하지 않는다. ConfigMap에 추가된 `known_hosts` 파일과 같은 -"중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는 +SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버 간에 신뢰할 수 있는 통신을 +설정하지 않는다. 컨피그맵(ConfigMap)에 추가된 `known_hosts` 파일과 같은 +"중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는 2차 수단이 필요하다. {{< /caution >}} @@ -667,7 +669,7 @@ kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다. 캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다. -시크릿은 watch(기본값), ttl 기반 또는 단순히 API 서버로 모든 요청을 직접 +시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접 리디렉션하여 전파할 수 있다. 결과적으로, 시크릿이 업데이트된 순간부터 새로운 키가 파드에 투영되는 순간까지의 총 지연 시간은 kubelet 동기화 시간 + 캐시 @@ -799,11 +801,6 @@ immutable: true 해당 프로세스에 대한 자세한 설명은 [서비스 어카운트에 ImagePullSecrets 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 참고한다. -### 수동으로 생성된 시크릿의 자동 마운트 - -수동으로 생성된 시크릿(예: GitHub 계정에 접근하기 위한 토큰이 포함된 시크릿)은 -시크릿의 서비스 어카운트를 기반한 파드에 자동으로 연결될 수 있다. - ## 상세 내용 ### 제약 사항 @@ -1249,4 +1246,3 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다. - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 - [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 - [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 - diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md index d4bdc17403..d9a1137024 100644 --- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md @@ -1,4 +1,7 @@ --- + + + title: 컨테이너 라이프사이클 훅(Hook) content_type: concept weight: 30 @@ -33,10 +36,13 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로 `PreStop` -이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다. -그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로, -컨테이너를 중지하기 위한 신호가 전송되기 전에 완료되어야 한다. -파라미터는 핸들러에 전달되지 않는다. +이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 +등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 +terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실패하며, +훅은 컨테이너를 중지하기 위한 TERM 신호가 보내지기 이전에 완료되어야 한다. 파드의 그레이스 종료 +기간(termination grace period)의 초읽기는 `PreStop` 훅이 실행되기 전에 시작되어, +핸들러의 결과에 상관없이 컨테이너가 파드의 그레이스 종료 기간 내에 결국 종료되도록 한다. +어떠한 파라미터도 핸들러에게 전달되지 않는다. 종료 동작에 더 자세한 대한 설명은 [파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다. @@ -62,17 +68,13 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로 그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면, 컨테이너는 `running` 상태에 이르지 못한다. -`PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로 -실행되지 않는다. 훅은 신호를 보내기 전에 실행을 -완료해야 한다. -실행 중에 `PreStop` 훅이 중단되면, +`PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로 실행되지 않는다. 훅은 +TERM 신호를 보내기 전에 실행을 완료해야 한다. 실행 중에 `PreStop` 훅이 중단되면, 파드의 단계는 `Terminating` 이며 `terminationGracePeriodSeconds` 가 -만료된 후 파드가 종료될 때까지 남아 있다. -이 유예 기간은 `PreStop` 훅이 실행되고 컨테이너가 -정상적으로 중지되는 데 걸리는 총 시간에 적용된다. -예를 들어, `terminationGracePeriodSeconds` 가 60이고, 훅이 -완료되는 데 55초가 걸리고, 컨테이너가 신호를 수신한 후 -정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후 +만료된 후 파드가 종료될 때까지 남아 있다. 이 유예 기간은 `PreStop` 훅이 +실행되고 컨테이너가 정상적으로 중지되는 데 걸리는 총 시간에 적용된다. 예를 들어, +`terminationGracePeriodSeconds` 가 60이고, 훅이 완료되는 데 55초가 걸리고, +컨테이너가 신호를 수신한 후 정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후 컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데 걸리는 총 시간(55+10)보다 적다. diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 68e529549b..d549060108 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -1,5 +1,8 @@ --- title: 커스텀 리소스 + + + content_type: concept weight: 10 --- @@ -117,7 +120,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트 쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않는다. -애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것과 같다. +애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다. CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 애그리게이션을 이해할 필요는 없다. diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 7542ac0add..359284b357 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -1,4 +1,8 @@ --- + + + + title: 네트워크 플러그인 content_type: concept weight: 10 @@ -20,7 +24,7 @@ weight: 10 kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다. * `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다. -* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 단순히 "cni"이다. +* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다. ## 네트워크 플러그인 요구 사항 diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md index 3ac6a2df7d..cc387c2f02 100644 --- a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md @@ -1,5 +1,7 @@ --- title: 서비스 카탈로그 + + content_type: concept weight: 40 --- @@ -24,7 +26,7 @@ weight: 40 클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다. 따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다. -애플리케이션은 그것을 서비스로 간단하게 사용할 수 있다. +애플리케이션은 메시지 큐에 서비스로 접속할 수 있다. ## 아키텍처 @@ -229,8 +231,3 @@ spec: * [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 * [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 * [svc-cat.io](https://svc-cat.io/docs/) 살펴보기 - - - - - diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 449cae4393..4086e27cda 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -1,4 +1,7 @@ --- + + + title: 쿠버네티스란 무엇인가? description: > 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다. @@ -40,7 +43,7 @@ sitemap: 컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다. * 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임. -* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다. +* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다. * 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다. * 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다. * 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 1e0d86a97b..12f02ccee4 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -1,4 +1,6 @@ --- + + title: 레이블과 셀렉터 content_type: concept weight: 40 @@ -40,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이 * `"partition" : "customerA"`, `"partition" : "customerB"` * `"track" : "daily"`, `"track" : "weekly"` -레이블 예시는 일반적으로 사용하는 상황에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다. +이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다. ## 구문과 캐릭터 셋 @@ -90,14 +92,13 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 {{< /note >}} {{< caution >}} -일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. -필터 구문이 적절히 구성되어있는지 확인해야 한다. +일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다. {{< /caution >}} ### _일치성 기준_ 요건 _일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다. -`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_ 를 의미한다. 예를 들면, +`=`,`==`,`!=` 이 세 가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 동의어), 나머지는 _불일치_ 를 의미한다. 예를 들면, ``` environment = production @@ -108,8 +109,9 @@ tier != frontend 후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다. `environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다. -균등-기반 레이블의 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다. -예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다. +일치성 기준 레이블 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다. +예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" +레이블을 가진 노드를 선택한다. ```yaml apiVersion: v1 @@ -148,16 +150,17 @@ _집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=productio _집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa` + ## API ### LIST와 WATCH 필터링 -LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함). +LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 두 가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함). - * _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` + * _일치성 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` * _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` -두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `apiserver`를 대상으로 _불일치 기준_ 으로 하는 셀렉터를 다음과 같이 이용할 수 있다. +두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `apiserver`를 대상으로 _일치성 기준_ 으로 하는 셀렉터를 다음과 같이 이용할 수 있다. ```shell kubectl get pods -l environment=production,tier=frontend @@ -192,7 +195,7 @@ kubectl get pods -l 'environment,environment notin (frontend)' `services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다. -서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다. +서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _일치성 기준_ 요구사항의 셀렉터만 지원한다. ```json "selector": { @@ -208,7 +211,6 @@ selector: `json` 또는 `yaml` 서식에서 셀렉터는 `component=redis` 또는 `component in (redis)` 모두 같은 것이다. - #### 세트-기반 요건을 지원하는 리소스 [`Job`](/ko/docs/concepts/workloads/controllers/job/), @@ -232,4 +234,3 @@ selector: 레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. 자세한 내용은 [노드 선택](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) 문서를 참조한다. - diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index 4c1570c458..575def2256 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -32,7 +32,7 @@ weight: 15 지정한다. 이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한 -가장 단순한 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인 +추천 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인 영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다. ### 예시 @@ -47,7 +47,7 @@ kubectl create deployment nginx --image nginx 오브젝트 구성에 비해 장점은 다음과 같다. -- 커맨드는 간단해서 배우기 쉽고, 기억하기 쉽다. +- 커맨드는 하나의 동작을 나타내는 단어로 표현된다. - 커맨드는 클러스터를 수정하기 위해 단 하나의 단계만을 필요로 한다. 오브젝트 구성에 비해 단점은 다음과 같다. @@ -125,7 +125,7 @@ kubectl replace -f nginx.yaml 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 -`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 +`kubectl`에 의해 오브젝트마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다. {{< note >}} diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index a6e6208d76..ff1f4a75c8 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -1,4 +1,6 @@ --- + + title: 리소스 쿼터 content_type: concept weight: 20 @@ -608,17 +610,28 @@ plugins: values: ["cluster-services"] ``` -이제 "cluster-services" 파드는 `scopeSelector`와 일치하는 쿼터 오브젝트가 있는 네임스페이스에서만 허용된다. -예를 들면 다음과 같다. +그리고, `kube-system` 네임스페이스에 리소스 쿼터 오브젝트를 생성한다. -```yaml - scopeSelector: - matchExpressions: - - scopeName: PriorityClass - operator: In - values: ["cluster-services"] +{{< codenew file="policy/priority-class-resourcequota.yaml" >}} + +```shell +$ kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system ``` +``` +resourcequota/pods-cluster-services created +``` + +이 경우, 파드 생성은 다음의 조건을 만족해야 허용될 것이다. + +1. 파드의 `priorityClassName` 가 명시되지 않음. +1. 파드의 `priorityClassName` 가 `cluster-services` 이외의 다른 값으로 명시됨. +1. 파드의 `priorityClassName` 가 `cluster-services` 로 설정되고, 파드가 `kube-system` + 네임스페이스에 생성되었으며 리소스 쿼터 검증을 통과함. + +파드 생성 요청은 `priorityClassName` 가 `cluster-services` 로 명시되고 +`kube-system` 이외의 다른 네임스페이스에 생성되는 경우, 거절된다. + ## {{% heading "whatsnext" %}} - 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index ebbc00f91e..f9e739d7a1 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -261,7 +261,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다. `topologyKey` 의 빈 값을 허용하지 않는다. 2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 `topologyKey` 의 빈 값을 허용하지 않는다. -3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 간단히 이를 비활성화해야 한다. +3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 이를 비활성화해야 한다. 4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다. `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를 diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 4ed5c58a63..03eec40fae 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -1,4 +1,6 @@ --- + + title: 스케줄러 성능 튜닝 content_type: concept weight: 80 diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index 0b4bb6e2cc..3b45be648c 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -132,7 +132,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre 이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다. API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다. -기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다. +기본적으로, 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다. 1. `로컬호스트 포트`: diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index 86240a4116..9cd48a172c 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -119,6 +119,7 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r 컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다. 이미지 서명 및 시행 | 컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다. 권한있는 사용자의 비허용 | 컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다. +더 강력한 격리로 컨테이너 런타임 사용 | 더 강력한 격리를 제공하는 [컨테이너 런타임 클래스](/ko/docs/concepts/containers/runtime-class/)를 선택한다. ## 코드 @@ -151,3 +152,4 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/) +* [런타임 클래스](/ko/docs/concepts/containers/runtime-class) diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index cae986bb5d..dcfb818650 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -35,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 * 쿠버네티스 1.20 이상 이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보 - 쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 + 쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 문서 참조 * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인 @@ -69,9 +69,9 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다. -서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-controller-manager에 구성) +서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성) -서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를 +서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를 다음 값 중 하나로 설정한다. * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. @@ -158,7 +158,7 @@ status: loadBalancer: {} ``` -1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-controller-manager에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다. +1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다. {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 06340143a0..8554d9a87d 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -23,7 +23,7 @@ weight: 40 {{% thirdparty-content %}} -* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다. +* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다. * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. @@ -31,13 +31,14 @@ weight: 40 * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는 Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. +* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다. * F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를 이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다. * [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈소스 인그레스 컨트롤러다. -* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의 +* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](https://www.haproxy.org/#desc)의 인그레스 컨트롤러다. -* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용 +* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](https://www.haproxy.org/#desc) 용 인그레스 컨트롤러이기도 하다. * [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/) 기반 인그레스 컨트롤러다. @@ -48,8 +49,9 @@ weight: 40 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다. * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는 [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다. +* [Tyk 오퍼레이터](https://github.com/TykTechnologies/tyk-operator)는 사용자 지정 리소스로 인그레스를 확장하여 API 관리 기능을 인그레스로 가져온다. Tyk 오퍼레이터는 오픈 소스 Tyk 게이트웨이 및 Tyk 클라우드 컨트롤 플레인과 함께 작동한다. * [Voyager](https://appscode.com/products/voyager)는 - [HAProxy](http://www.haproxy.org/#desc)의 인그레스 컨트롤러다. + [HAProxy](https://www.haproxy.org/#desc)의 인그레스 컨트롤러다. ## 여러 인그레스 컨트롤러 사용 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 5d1acf5392..be1f3ecaae 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -430,8 +430,8 @@ CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위 예를 들면, 쿠버네티스 네임스페이스 `my-ns`에 `my-service`라는 서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여 `my-service.my-ns`에 대한 DNS 레코드를 만든다. `my-ns` 네임 스페이스의 파드들은 -간단히 `my-service`에 대한 이름 조회를 수행하여 찾을 수 있어야 한다 -(`my-service.my-ns` 역시 동작함). +`my-service`(`my-service.my-ns` 역시 동작함)에 대한 이름 조회를 +수행하여 서비스를 찾을 수 있어야 한다. 다른 네임스페이스의 파드들은 이름을 `my-service.my-ns`으로 사용해야 한다. 이 이름은 서비스에 할당된 클러스터 IP로 변환된다. @@ -463,7 +463,7 @@ DNS SRV 쿼리를 수행할 수 있다. 셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는 API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하여 -`서비스` 를 지원하는 `파드` 를 직접 가리키는 레코드 (주소)를 반환한다. +`서비스` 를 지원하는 `파드` 를 직접 가리키는 A 레코드(IP 주소)를 반환한다. ### 셀렉터가 없는 경우 @@ -1164,7 +1164,7 @@ IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정 이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을 의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에 -간단히 연결할 수 있다. +연결할 수 있다. #### iptables diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 9ce1eba6cf..05997eb0f3 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -487,7 +487,7 @@ PV는 `storageClassName` 속성을 * VsphereVolume * iSCSI -마운트 옵션의 유효성이 검사되지 않으므로 마운트 옵션이 유효하지 않으면 마운트가 실패한다. +마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다. 이전에는 `mountOptions` 속성 대신 `volume.beta.kubernetes.io/mount-options` 어노테이션이 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만, @@ -629,6 +629,11 @@ spec: 퍼시스턴트볼륨 바인딩은 배타적이며, 퍼시스턴트볼륨클레임은 네임스페이스 오브젝트이므로 "다중" 모드(`ROX`, `RWX`)를 사용한 클레임은 하나의 네임스페이스 내에서만 가능하다. +### `hostPath` 유형의 퍼시스턴트볼륨 + +`hostPath` 퍼시스턴트볼륨은 노드의 파일이나 디렉터리를 사용하여 네트워크 연결 스토리지를 에뮬레이션한다. +[`hostPath` 유형 볼륨의 예](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)를 참고한다. + ## 원시 블록 볼륨 지원 {{< feature-state for_k8s_version="v1.18" state="stable" >}} diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 8bc6f7b1bf..94577ca182 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -143,8 +143,8 @@ CSI | 1.14 (alpha), 1.16 (beta) 클래스의 `mountOptions` 필드에 지정된 마운트 옵션을 가진다. 만약 볼륨 플러그인이 마운트 옵션을 지원하지 않는데, 마운트 -옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV 에서 -검증되지 않으므로 PV 마운트가 유효하지 않으면 마운트가 실패하게 된다. +옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV에서 +검증되지 않는다. PV 마운트가 유효하지 않으면, 마운트가 실패하게 된다. ### 볼륨 바인딩 모드 diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index e6ff2caa38..e9857885d7 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -19,7 +19,7 @@ weight: 30 복제는 표준 볼륨처럼 소비할 수 있는 쿠버네티스 볼륨의 복제본으로 정의된다. 유일한 차이점은 프로비저닝할 때 "새" 빈 볼륨을 생성하는 대신에 백엔드 장치가 지정된 볼륨의 정확한 복제본을 생성한다는 것이다. -쿠버네티스 API의 관점에서 복제를 구현하면 새로운 PVC 생성 중에 기존 PVC를 데이터 소스로 지정할 수 있는 기능이 추가된다. 소스 PVC는 바인딩되어있고, 사용가능해야 한다(사용 중이 아니어야함). +쿠버네티스 API의 관점에서 복제를 구현하면 새로운 PVC 생성 중에 기존 PVC를 데이터 소스로 지정할 수 있는 기능이 추가된다. 소스 PVC는 바인딩되어 있고, 사용 가능해야 한다(사용 중이 아니어야 함). 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다. @@ -64,5 +64,3 @@ spec: ## 사용 새 PVC를 사용할 수 있게 되면, 복제된 PVC는 다른 PVC와 동일하게 소비된다. 또한, 이 시점에서 새롭게 생성된 PVC는 독립된 오브젝트이다. 원본 dataSource PVC와는 무관하게 독립적으로 소비하고, 복제하고, 스냅샷의 생성 또는 삭제를 할 수 있다. 이는 소스가 새롭게 생성된 복제본에 어떤 방식으로든 연결되어 있지 않으며, 새롭게 생성된 복제본에 영향 없이 수정하거나, 삭제할 수도 있는 것을 의미한다. - - diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 2e37dc0a67..7e1646820e 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -103,6 +103,8 @@ spec: fsType: ext4 ``` +EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: ""` 를 제공하여 마운트할 파티션을 지정할 수 있다. + #### AWS EBS CSI 마이그레이션 {{< feature-state for_k8s_version="v1.17" state="beta" >}} @@ -207,8 +209,8 @@ spec: Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI -드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) -를 설치하고 `CSIMigration` 과 `CSIMigrationOpenStack` +드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)를 +설치하고 `CSIMigration` 과 `CSIMigrationOpenStack` 베타 기능을 활성화해야 한다. ### 컨피그맵(configMap) {#configmap} @@ -534,7 +536,7 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데 | 값 | 행동 | |:------|:---------| -| | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPash 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. | +| | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPath 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. | | `DirectoryOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0755로 설정한 빈 디렉터리를 생성한다. | | `Directory` | 주어진 경로에 디렉터리가 있어야 함 | | `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 디렉터리를 생성한다. | diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index ed29659a7e..7756c93cb0 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -89,6 +89,11 @@ kube-controller-manager 컨테이너에 설정된 시간대는 `concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은 실행될 것이다. +{{< caution >}} +`startingDeadlineSeconds` 가 10초 미만의 값으로 설정되면, 크론잡이 스케줄되지 않을 수 있다. 이는 크론잡 컨트롤러가 10초마다 항목을 확인하기 때문이다. +{{< /caution >}} + + 모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. ```` diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 589fe7c1dd..d7d583d142 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -141,8 +141,8 @@ nodeAffinity: | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | | `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | | `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | 데몬셋 파드는 기본 스케줄러에서 디스크-압박(disk-pressure) 속성을 허용한다. | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | 데몬셋 파드는 기본 스케줄러에서 메모리-압박(memory-pressure) 속성을 허용한다. | | `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 779fcfbe34..1407bb28f0 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -45,7 +45,7 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id= * `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다. * `.spec.replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다. * `.spec.selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다. - 이 사례에서는 간단하게 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다. + 이 사례에서는 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다. 그러나 파드 템플릿 자체의 규칙이 만족되는 한, 보다 정교한 선택 규칙의 적용이 가능하다. @@ -169,13 +169,15 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ```shell kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 ``` - 또는 간단하게 다음의 명령어를 사용한다. + + 또는 다음의 명령어를 사용한다. ```shell kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record ``` - 이와 유사하게 출력된다. + 다음과 유사하게 출력된다. + ``` deployment.apps/nginx-deployment image updated ``` @@ -186,7 +188,8 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml kubectl edit deployment.v1.apps/nginx-deployment ``` - 이와 유사하게 출력된다. + 다음과 유사하게 출력된다. + ``` deployment.apps/nginx-deployment edited ``` @@ -198,10 +201,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ``` 이와 유사하게 출력된다. + ``` Waiting for rollout to finish: 2 out of 3 new replicas have been updated... ``` + 또는 + ``` deployment "nginx-deployment" successfully rolled out ``` @@ -210,10 +216,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml * 롤아웃이 성공하면 `kubectl get deployments` 를 실행해서 디플로이먼트를 볼 수 있다. 이와 유사하게 출력된다. - ``` - NAME READY UP-TO-DATE AVAILABLE AGE - nginx-deployment 3/3 3 3 36s - ``` + + ```ini + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 36s + ``` * `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, 새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 9c3450851a..ff48730a13 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -180,7 +180,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용 Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를 삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다. -REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다 (레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, +REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, 레플리케이션 컨트롤러를 삭제). ### 레플리케이션 컨트롤러만 삭제 @@ -189,7 +189,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적 kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라. -REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 레플리케이션 컨트롤러 오브젝트를 삭제하라. +REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라. 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면, 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를 @@ -208,7 +208,8 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 ### 스케일링 -레플리케이션 컨트롤러는 `replicas` 필드를 업데이트함으로써 수동으로 또는 오토 스케일링 제어 에이전트로 레플리카의 수를 쉽게 스케일 업하거나 스케일 다운할 수 있다. +레플리케이션컨트롤러는 `replicas` 필드를 설정하여 레플리카의 수를 늘리거나 줄인다. +레플리카를 수동으로 또는 오토 스케일링 제어 에이전트로 관리하도록 레플리케이션컨트롤러를 구성할 수 있다. ### 롤링 업데이트 @@ -239,7 +240,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 ## 레플리케이션 컨트롤러의 책임 -레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다. +레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 셀렉터와 일치하고 동작하는지를 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다. 레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된)가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019))을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170))까지도 고려해야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 27e48b192f..9aa9e9bf51 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -76,7 +76,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 임시 컨테이너를 사용해서 문제를 해결하는 예시는 [임시 디버깅 컨테이너로 디버깅하기] -(/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)를 참조한다. +(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다. ## 임시 컨테이너 API @@ -100,7 +100,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 "apiVersion": "v1", "kind": "EphemeralContainers", "metadata": { - "name": "example-pod" + "name": "example-pod" }, "ephemeralContainers": [{ "command": [ diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index 354e9d669f..448502c0c3 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md @@ -51,7 +51,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D - 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다. {{< note >}} - `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다! + `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, "LGTM" 코멘트를 남기는 것도 좋다! {{< /note >}} - `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다. diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md index b34f68e392..a9370ea74b 100644 --- a/content/ko/docs/reference/access-authn-authz/authorization.md +++ b/content/ko/docs/reference/access-authn-authz/authorization.md @@ -99,6 +99,9 @@ DELETE | delete(개별 리소스), deletecollection(리소스 모음) ```bash kubectl auth can-i create deployments --namespace dev ``` + +다음과 유사하게 출력된다. + ``` yes ``` @@ -106,6 +109,9 @@ yes ```shell kubectl auth can-i create deployments --namespace prod ``` + +다음과 유사하게 출력된다. + ``` no ``` @@ -116,6 +122,9 @@ no ```bash kubectl auth can-i list secrets --namespace dev --as dave ``` + +다음과 유사하게 출력된다. + ``` no ``` @@ -145,7 +154,7 @@ EOF ``` 생성된 `SelfSubjectAccessReview` 는 다음과 같다. -``` +```yaml apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview metadata: 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 715dbf4801..cece4022ef 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 @@ -634,8 +634,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다. - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. -- `KubeletPodResources`: kubelet의 파드 리소스 GPRC 엔드포인트를 활성화한다. 자세한 내용은 - [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 +- `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은 + [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을 참고한다. - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 2ac5f6076c..0020d7b574 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -191,7 +191,7 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" # 외부 도구 없이 디코딩된 시크릿 출력 -kubectl get secret ${secret_name} -o go-template='{{range $k,$v := .data}}{{$k}}={{$v|base64decode}}{{"\n"}}{{end}}' +kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}' # 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회 kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq @@ -334,7 +334,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule ### 리소스 타입 -단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-그룹)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열: +단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-그룹과-버전-규칙)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열: ```bash kubectl api-resources diff --git a/content/ko/docs/reference/tools.md b/content/ko/docs/reference/tools.md index ac0a5fb6c5..97206f3be7 100644 --- a/content/ko/docs/reference/tools.md +++ b/content/ko/docs/reference/tools.md @@ -20,9 +20,9 @@ content_type: concept ## Minikube -[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로 하는 +[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로 단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서 -쉽게 구동시키는 도구이다. +실행하는 도구이다. ## 대시보드 diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index f51b5f5eef..42c8bd8095 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -420,7 +420,7 @@ CRI-O를 시작한다. ```shell sudo systemctl daemon-reload -sudo systemctl start crio +sudo systemctl enable crio --now ``` 자세한 사항은 [CRI-O 설치 가이드](https://github.com/cri-o/cri-o/blob/master/install.md)를 diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index 4ec5386d2f..05fc21f32a 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -39,7 +39,7 @@ kops는 자동화된 프로비저닝 시스템인데, #### 설치 -[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스코드로부터 빌드하는것도 역시 어렵지 않다). +[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스 코드로부터 빌드하는 것도 역시 편리하다). {{< tabs name="kops_installation" >}} {{% tab name="macOS" %}} @@ -51,7 +51,7 @@ curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https:// | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64 ``` -특정 버전을 다운로드 받는다면 명령의 다음부분을 특정 kops 버전으로 변경한다. +특정 버전을 다운로드 받는다면 명령의 다음 부분을 특정 kops 버전으로 변경한다. ```shell $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) @@ -147,8 +147,8 @@ Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone `dev` NS 레코드를 `example.com`에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은 도메인 등록기관을 통해서 생성해야 한다(예를 들어, `example.com`는 `example.com`를 구매한 곳에서 설정 할 수 있다). -이 단계에서 문제가 되기 쉽다.(문제를 만드는 가장 큰 이유이다!) dig 툴을 실행해서 -클러스터 설정이 정확한지 한번 더 확인 한다. +route53 도메인 설정을 확인한다(문제를 만드는 가장 큰 이유이다!). dig 툴을 실행해서 +클러스터 설정이 정확한지 한번 더 확인한다. `dig NS dev.example.com` diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index 2e6252bf80..358274d143 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -76,9 +76,7 @@ kind: ClusterConfiguration kubernetesVersion: v1.16.0 scheduler: extraArgs: - address: 0.0.0.0 + bind-address: 0.0.0.0 config: /home/johndoe/schedconfig.yaml kubeconfig: /home/johndoe/kubeconfig.yaml ``` - - diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md new file mode 100644 index 0000000000..9e28b5b509 --- /dev/null +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -0,0 +1,321 @@ +--- +title: kubeadm 설치하기 +content_type: task +weight: 10 +card: + name: setup + weight: 20 + title: kubeadm 설정 도구 설치 +--- + + + +이 페이지에서는 `kubeadm` 툴박스를 설치하는 방법을 보여준다. +이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm을 사용하여 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다. + + + +## {{% heading "prerequisites" %}} + + +* 다음 중 하나를 실행하는 하나 이상의 머신이 필요하다. + - Ubuntu 16.04+ + - Debian 9+ + - CentOS 7+ + - Red Hat Enterprise Linux (RHEL) 7+ + - Fedora 25+ + - HypriotOS v1.0.1+ + - Flatcar Container Linux (2512.3.0으로 테스트됨) +* 2 GB 이상의 램을 장착한 머신. (이 보다 작으면 사용자의 앱을 위한 공간이 거의 남지 않음) +* 2 이상의 CPU. +* 클러스터의 모든 머신에 걸친 전체 네트워크 연결. (공용 또는 사설 네트워크면 괜찮음) +* 모든 노드에 대해 고유한 호스트 이름, MAC 주소 및 product_uuid. 자세한 내용은 [여기](#verify-mac-address)를 참고한다. +* 컴퓨터의 특정 포트들 개방. 자세한 내용은 [여기](#check-required-ports)를 참고한다. +* 스왑의 비활성화. kubelet이 제대로 작동하게 하려면 **반드시** 스왑을 사용하지 않도록 설정한다. + + + + + +## MAC 주소 및 product_uuid가 모든 노드에 대해 고유한지 확인 {#verify-mac-address} +* 사용자는 `ip link` 또는 `ifconfig -a` 명령을 사용하여 네트워크 인터페이스의 MAC 주소를 확인할 수 있다. +* product_uuid는 `sudo cat /sys/class/dmi/id/product_uuid` 명령을 사용하여 확인할 수 있다. + +일부 가상 머신은 동일한 값을 가질 수 있지만 하드웨어 장치는 고유한 주소를 가질 +가능성이 높다. 쿠버네티스는 이러한 값을 사용하여 클러스터의 노드를 고유하게 식별한다. +이러한 값이 각 노드에 고유하지 않으면 설치 프로세스가 +[실패](https://github.com/kubernetes/kubeadm/issues/31)할 수 있다. + +## 네트워크 어댑터 확인 + +네트워크 어댑터가 두 개 이상이고, 쿠버네티스 컴포넌트가 디폴트 라우트(default route)에서 도달할 수 없는 +경우, 쿠버네티스 클러스터 주소가 적절한 어댑터를 통해 이동하도록 IP 경로를 추가하는 것이 좋다. + +## iptables가 브리지된 트래픽을 보게 하기 + +`br_netfilter` 모듈이 로드되었는지 확인한다. `lsmod | grep br_netfilter` 를 실행하면 된다. 명시적으로 로드하려면 `sudo modprobe br_netfilter` 를 실행한다. + +리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables` 가 1로 설정되어 있는지 확인해야 한다. 다음은 예시이다. + +```bash +cat <}}을 사용한다. + +{{< tabs name="container_runtime" >}} +{{% tab name="리눅스 노드" %}} + +기본적으로, 쿠버네티스는 +{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를 +사용하여 사용자가 선택한 컨테이너 런타임과 인터페이스한다. + +런타임을 지정하지 않으면, kubeadm은 잘 알려진 유닉스 도메인 소켓 목록을 검색하여 +설치된 컨테이너 런타임을 자동으로 감지하려고 한다. +다음 표에는 컨테이너 런타임 및 관련 소켓 경로가 나열되어 있다. + +{{< table caption = "컨테이너 런타임과 소켓 경로" >}} +| 런타임 | 유닉스 도메인 소켓 경로 | +|------------|-----------------------------------| +| 도커 | `/var/run/docker.sock` | +| containerd | `/run/containerd/containerd.sock` | +| CRI-O | `/var/run/crio/crio.sock` | +{{< /table >}} + +
+도커와 containerd가 모두 감지되면 도커가 우선시된다. 이것이 필요한 이유는 도커 18.09에서 +도커만 설치한 경우에도 containerd와 함께 제공되므로 둘 다 감지될 수 있기 +때문이다. +다른 두 개 이상의 런타임이 감지되면, kubeadm은 오류와 함께 종료된다. + +kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다. + +자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 +참고한다. +{{% /tab %}} +{{% tab name="다른 운영 체제" %}} +기본적으로, kubeadm은 컨테이너 런타임으로 {{< glossary_tooltip term_id="docker" >}}를 사용한다. +kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다. + +자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 +참고한다. +{{% /tab %}} +{{< /tabs >}} + + +## kubeadm, kubelet 및 kubectl 설치 + +모든 머신에 다음 패키지들을 설치한다. + +* `kubeadm`: 클러스터를 부트스트랩하는 명령이다. + +* `kubelet`: 클러스터의 모든 머신에서 실행되는 파드와 컨테이너 시작과 + 같은 작업을 수행하는 컴포넌트이다. + +* `kubectl`: 클러스터와 통신하기 위한 커맨드 라인 유틸리티이다. + +kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으므로**, kubeadm이 +설치하려는 쿠버네티스 컨트롤 플레인의 버전과 일치하는지 +확인해야 한다. 그렇지 않으면, 예상치 못한 버그 동작으로 이어질 수 있는 +버전 차이(skew)가 발생할 위험이 있다. 그러나, kubelet과 컨트롤 플레인 사이에 _하나의_ +마이너 버전 차이가 지원되지만, kubelet 버전은 API 서버 버전 보다 +높을 수 없다. 예를 들어, 1.7.0 버전의 kubelet은 1.8.0 API 서버와 완전히 호환되어야 하지만, +그 반대의 경우는 아니다. + +`kubectl` 설치에 대한 정보는 [kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다. + +{{< warning >}} +이 지침은 모든 시스템 업그레이드에서 모든 쿠버네티스 패키지를 제외한다. +이는 kubeadm 및 쿠버네티스를 +[업그레이드 하는 데 특별한 주의](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)가 필요하기 때문이다. +{{}} + +버전 차이에 대한 자세한 내용은 다음을 참고한다. + +* 쿠버네티스 [버전 및 버전-차이 정책](/docs/setup/release/version-skew-policy/) +* Kubeadm 관련 [버전 차이 정책](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) + +{{< tabs name="k8s_install" >}} +{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} +```bash +sudo apt-get update && sudo apt-get install -y apt-transport-https curl +curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - +cat <}} +`DOWNLOAD_DIR` 변수는 쓰기 가능한 디렉터리로 설정되어야 한다. +Flatcar Container Linux를 실행 중인 경우, `DOWNLOAD_DIR=/opt/bin` 을 설정한다. +{{< /note >}} + +```bash +DOWNLOAD_DIR=/usr/local/bin +sudo mkdir -p $DOWNLOAD_DIR +``` + +crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요) + +```bash +CRICTL_VERSION="v1.17.0" +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz +``` + +`kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가 + +```bash +RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" +cd $DOWNLOAD_DIR +sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +sudo chmod +x {kubeadm,kubelet,kubectl} + +RELEASE_VERSION="v0.4.0" +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service +sudo mkdir -p /etc/systemd/system/kubelet.service.d +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf +``` + +`kubelet` 활성화 및 시작 + +```bash +systemctl enable --now kubelet +``` + +{{< note >}} +Flatcar Container Linux 배포판은 `/usr` 디렉터리를 읽기 전용 파일시스템으로 마운트한다. +클러스터를 부트스트랩하기 전에, 쓰기 가능한 디렉터리를 구성하기 위한 추가 단계를 수행해야 한다. +쓰기 가능한 디렉터리를 설정하는 방법을 알아 보려면 [Kubeadm 문제 해결 가이드](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#usr-mounted-read-only/)를 참고한다. +{{< /note >}} +{{% /tab %}} +{{< /tabs >}} + + +kubelet은 이제 kubeadm이 수행할 작업을 알려 줄 때까지 크래시루프(crashloop) 상태로 +기다려야 하므로 몇 초마다 다시 시작된다. + +## 컨트롤 플레인 노드에서 kubelet이 사용하는 cgroup 드라이버 구성 + +도커를 사용할 때, kubeadm은 kubelet 용 cgroup 드라이버를 자동으로 감지하여 +런타임 중에 `/var/lib/kubelet/config.yaml` 파일에 설정한다. + +다른 CRI를 사용하는 경우, 다음과 같이 `cgroupDriver` 값을 `kubeadm init` 에 전달해야 한다. + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +cgroupDriver: +``` + +자세한 내용은 [구성 파일과 함께 kubeadm init 사용](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)을 참고한다. + +`cgroupfs` 가 이미 kubelet의 기본값이기 때문에, 사용자의 +CRI cgroup 드라이버가 `cgroupfs` 가 아닌 **경우에만** 위와 같이 설정해야 한다. + +{{< note >}} +`--cgroup-driver` 플래그가 kubelet에 의해 사용 중단되었으므로, `/var/lib/kubelet/kubeadm-flags.env` +또는 `/etc/default/kubelet`(RPM에 대해서는 `/etc/sysconfig/kubelet`)에 있는 경우, 그것을 제거하고 대신 KubeletConfiguration을 +사용한다(기본적으로 `/var/lib/kubelet/config.yaml` 에 저장됨). +{{< /note >}} + +CRI-O 및 containerd와 같은 다른 컨테이너 런타임에 대한 cgroup 드라이버의 +자동 감지에 대한 작업이 진행 중이다. + + +## 문제 해결 + +kubeadm에 문제가 있는 경우, [문제 해결 문서](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)를 참고한다. + +## {{% heading "whatsnext" %}} + + +* [kubeadm을 사용하여 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) diff --git a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 0ea3dc0ce9..67283774af 100644 --- a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -12,7 +12,7 @@ weight: 65 ## 쿠버네티스의 윈도우 컨테이너 -쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함하기만 하면 된다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것만큼 간단하고 쉽다. +쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함한다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다. 윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다. @@ -544,7 +544,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 1. `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network to be created"에서 멈춘다. - 이 [조사 중인 이슈](https://github.com/coreos/flannel/issues/1066)에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때 타이밍 이슈일 가능성이 높다. 해결 방법은 간단히 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다. + 이 [이슈](https://github.com/coreos/flannel/issues/1066)에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때의 타이밍 이슈일 가능성이 높다. 해결 방법은 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다. ```powershell PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md index f833d27094..7bcbb39489 100644 --- a/content/ko/docs/setup/release/notes.md +++ b/content/ko/docs/setup/release/notes.md @@ -92,7 +92,7 @@ We expect this implementation to progress from alpha to beta and GA in coming re ### go1.15.5 -go1.15.5 has been integrated to Kubernets project as of this release, [including other infrastructure related updates on this effort](https://github.com/kubernetes/kubernetes/pull/95776). +go1.15.5 has been integrated to Kubernetes project as of this release, [including other infrastructure related updates on this effort](https://github.com/kubernetes/kubernetes/pull/95776). ### CSI 볼륨 스냅샷(CSI Volume Snapshot)이 안정 기능으로 전환 @@ -190,7 +190,7 @@ Currently, cadvisor_stats_provider provides AcceleratorStats but cri_stats_provi PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible. kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly. Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. ([#95723](https://github.com/kubernetes/kubernetes/pull/95723), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle] -- The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration infromation available in --help description for --exprimental-patches. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123)) +- The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration information available in --help description for --experimental-patches. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123)) - Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 ([#95505](https://github.com/kubernetes/kubernetes/pull/95505), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] - The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags `--address` and `--insecure-bind-address` have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags `--port` and `--insecure-port` may only be set to 0 and will be removed in v1.24. ([#95856](https://github.com/kubernetes/kubernetes/pull/95856), [@knight42](https://github.com/knight42), [SIG API Machinery, Node, Testing]) - Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API. diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index e78046f0ee..43a6a82343 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -280,7 +280,7 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi #### 수작업으로 apiserver proxy URL을 구축 -위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에 +위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. 당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md index 123c09d2d2..d6e567e674 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -216,7 +216,7 @@ for i in ret.items: #### Java 클라이언트 {#java-client} -* [Java 클라이언트](https://github.com/kubernetes-client/java)를 설치하려면, 다음을 실행한다. +[Java 클라이언트](https://github.com/kubernetes-client/java)를 설치하려면, 다음을 실행한다. ```shell # java 라이브러리를 클론한다 diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md index f8f707eb33..5dd7a627d0 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -83,7 +83,7 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi #### apiserver 프록시 URL 수동 구성 -위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 단순히 서비스의 프록시 URL에 추가하면 된다. +위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 서비스의 프록시 URL에 추가하면 된다. `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy` 포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. diff --git a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md index 8fd7445fb7..08c2e2cef4 100644 --- a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md +++ b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md @@ -32,7 +32,7 @@ content_type: task 수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 하여 스토리지의 동적 프로비저닝을 방지할 수 있다. -단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 +기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동 중인 애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index 34cb102f83..5a8295aff2 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -9,18 +9,13 @@ weight: 100 이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 사용하는 파드를 생성하는 방법을 보여준다. - - ## {{% heading "prerequisites" %}} - * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * 이 실습을 수행하기 위해, [도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다. - - ## 도커 로그인 @@ -106,7 +101,8 @@ kubectl create secret docker-registry regcred --docker-server=` 은 프라이빗 도커 저장소의 FQDN 주소이다. (도커허브(DockerHub)의 경우, https://index.docker.io/v1/) +* `` 은 프라이빗 도커 저장소의 FQDN 주소이다. + 도커허브(DockerHub)는 `https://index.docker.io/v2/` 를 사용한다. * `` 은 도커 사용자의 계정이다. * `` 은 도커 사용자의 비밀번호이다. * `` 은 도커 사용자의 이메일 주소이다. @@ -192,7 +188,8 @@ your.private.registry.example.com/janedoe/jdoe-private:v1 ``` 프라이빗 저장소에서 이미지를 받아오기 위하여, 쿠버네티스에서 자격 증명이 필요하다. -구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가 `regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다. +구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가 +`regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다. 시크릿을 사용해서 파드를 생성하고, 파드가 실행되는지 확인하자. @@ -201,16 +198,11 @@ kubectl apply -f my-private-reg-pod.yaml kubectl get pod private-reg ``` - - ## {{% heading "whatsnext" %}} - * [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기. * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기. * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기. * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기. * [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기. * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기. - - diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md index 41e1f6f7b0..4daf739c2f 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -22,6 +22,7 @@ Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버 생성하려고 자동으로 시도한다. 즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, API 서버에서 제어될 수는 없다. +파드 이름에는 노드 호스트 이름 앞에 하이픈을 붙여 접미사로 추가된다. {{< note >}} 만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 diff --git a/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md deleted file mode 100644 index 54a2ae61b0..0000000000 --- a/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -content_type: concept -title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로깅 ---- - - - -Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은 -[스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는 -[스택드라이버 로깅으로 로깅하기](/docs/tasks/debug-application-cluster/logging-stackdriver)에 자세히 설명되어 있다. - -이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로, -[엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고 -[키바나](https://www.elastic.co/products/kibana)를 사용하여 볼 수 있도록 -클러스터를 설정하는 방법에 대해 설명한다. - -{{< note >}} -Google 쿠버네티스 엔진(Kubernetes Engine)에서 호스팅되는 쿠버네티스 클러스터에는 엘라스틱서치 및 키바나를 자동으로 배포할 수 없다. 수동으로 배포해야 한다. -{{< /note >}} - - - - - -클러스터 로깅에 엘라스틱서치, 키바나를 사용하려면 kube-up.sh를 사용하여 -클러스터를 생성할 때 아래와 같이 다음의 환경 변수를 -설정해야 한다. - -```shell -KUBE_LOGGING_DESTINATION=elasticsearch -``` - -또한 `KUBE_ENABLE_NODE_LOGGING=true`(GCE 플랫폼의 기본값)인지 확인해야 한다. - -이제, 클러스터를 만들 때, 각 노드에서 실행되는 Fluentd 로그 수집 데몬이 -엘라스틱서치를 대상으로 한다는 메시지가 나타난다. - -```shell -cluster/kube-up.sh -``` -``` -... -Project: kubernetes-satnam -Zone: us-central1-b -... calling kube-up -Project: kubernetes-satnam -Zone: us-central1-b -+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel -+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d) -+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0) -Looking for already existing resources -Starting master and configuring firewalls -Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd]. -NAME ZONE SIZE_GB TYPE STATUS -kubernetes-master-pd us-central1-b 20 pd-ssd READY -Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip]. -+++ Logging using Fluentd to elasticsearch -``` - -노드별 Fluentd 파드, 엘라스틱서치 파드 및 키바나 파드는 -클러스터가 활성화된 직후 kube-system 네임스페이스에서 모두 실행되어야 -한다. - -```shell -kubectl get pods --namespace=kube-system -``` -``` -NAME READY STATUS RESTARTS AGE -elasticsearch-logging-v1-78nog 1/1 Running 0 2h -elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h -fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h -fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h -fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h -fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h -kibana-logging-v1-bhpo8 1/1 Running 0 2h -kube-dns-v3-7r1l9 3/3 Running 0 2h -monitoring-heapster-v4-yl332 1/1 Running 1 2h -monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h -``` - -`fluentd-elasticsearch` 파드는 각 노드에서 로그를 수집하여 -`elasticsearch-logging` 파드로 전송한다. 이 로그는 `elasticsearch-logging` 이라는 -[서비스](/ko/docs/concepts/services-networking/service/)의 일부이다. 이 -엘라스틱서치 파드는 로그를 저장하고 REST API를 통해 노출한다. -`kibana-logging` 파드는 엘라스틱서치에 저장된 로그를 읽기 위한 웹 UI를 -제공하며, `kibana-logging` 이라는 서비스의 일부이다. - -엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에 -있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해, -[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에 -대한 지침을 참고한다. - -브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면, -다음과 같은 상태 페이지가 표시된다. - -![엘라스틱서치 상태](/images/docs/es-browser.png) - -원할 경우, 이제 엘라스틱서치 쿼리를 브라우저에 직접 입력할 수 -있다. 수행 방법에 대한 자세한 내용은 [엘라스틱서치의 문서](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)를 -참조한다. - -또는, 키바나를 사용하여 클러스터의 로그를 볼 수도 있다(다시 -[클러스터에서 실행되는 서비스에 접근하기 위한 지침](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)을 참고). -키바나 URL을 처음 방문하면 수집된 로그 보기를 -구성하도록 요청하는 페이지가 표시된다. 시계열 값에 -대한 옵션을 선택하고 `@timestamp` 를 선택한다. 다음 페이지에서 -`Discover` 탭을 선택하면 수집된 로그를 볼 수 있다. -로그를 정기적으로 새로 고치려면 새로 고침 간격을 5초로 -설정할 수 있다. - -키바나 뷰어에서 수집된 로그의 일반적인 보기는 다음과 같다. - -![키바나 로그](/images/docs/kibana-logs.png) - - - -## {{% heading "whatsnext" %}} - - -키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한 -아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다. diff --git a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md index f46df1e511..77081a82f3 100644 --- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -22,7 +22,7 @@ content_type: task ## kubectl 플러그인 설치 -플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 간단히 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다. +플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다. [Krew](https://krew.dev/)를 사용하여 오픈소스에서 사용 가능한 kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네티스 SIG CLI 커뮤니티에서 관리하는 @@ -57,9 +57,9 @@ Krew [플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 통해 사 플러그인 설치 또는 사전 로딩이 필요하지 않다. 플러그인 실행 파일은 `kubectl` 바이너리에서 상속된 환경을 받는다. -플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다. 예를 -들어, 새로운 명령인 `kubectl foo` 를 제공하려는 플러그인은 단순히 이름이 -`kubectl-foo` 이고, `PATH` 의 어딘가에 있다. +플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다. +예를 들어, `kubectl-foo` 라는 플러그인은 `kubectl foo` 명령을 제공한다. +`PATH` 어딘가에 플러그인 실행 파일을 설치해야 한다. ### 플러그인 예제 @@ -85,30 +85,31 @@ echo "I am a plugin named kubectl-foo" ### 플러그인 사용 -위의 플러그인을 사용하려면, 간단히 실행 가능하게 만든다. +플러그인을 사용하려면, 실행 가능하게 만든다. -``` +```shell sudo chmod +x ./kubectl-foo ``` 그리고 `PATH` 의 어느 곳에나 옮겨 놓는다. -``` +```shell sudo mv ./kubectl-foo /usr/local/bin ``` 이제 플러그인을 `kubectl` 명령으로 호출할 수 있다. -``` +```shell kubectl foo ``` + ``` I am a plugin named kubectl-foo ``` 모든 인수와 플래그는 그대로 실행 파일로 전달된다. -``` +```shell kubectl foo version ``` ``` @@ -120,6 +121,7 @@ kubectl foo version ```bash export KUBECONFIG=~/.kube/config kubectl foo config + ``` ``` /home//.kube/config @@ -128,6 +130,7 @@ kubectl foo config ```shell KUBECONFIG=/etc/kube/config kubectl foo config ``` + ``` /etc/kube/config ``` @@ -373,11 +376,8 @@ kubectl 플러그인의 배포 패키지를 컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가 더 쉬워진다. - - ## {{% heading "whatsnext" %}} - * Go로 작성된 플러그인의 [자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는 샘플 CLI 플러그인 리포지터리를 확인한다. diff --git a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md index aeaac4803d..fa765a7005 100644 --- a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md +++ b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -35,7 +35,7 @@ weight: 30 ## 메시지 대기열 서비스 시작 -이 문서의 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 타입의 메시지 서비스에 적용하는데 문제가 없을 것이다. +이 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 유형의 메시지 서비스를 사용하도록 예시를 조정할 수 있다. 실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번 구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다. diff --git a/content/ko/docs/tasks/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md index 341739ba62..ef02dac61b 100644 --- a/content/ko/docs/tasks/job/parallel-processing-expansion.md +++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md @@ -12,7 +12,7 @@ weight: 20 있다. 이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다. -샘플 잡들은 단순히 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다. +샘플 잡들은 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다. 이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면 [실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다. diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md index 8bb7ab89f2..1ef9220d65 100644 --- a/content/ko/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -60,7 +60,7 @@ PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자. ### 스테이트풀셋의 완벽한 삭제 -연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다. +연결된 파드를 포함해서 스테이트풀셋의 모든 것을 삭제하기 위해 다음과 같이 일련의 명령을 실행한다. ```shell grace=$(kubectl get pods --template '{{.spec.terminationGracePeriodSeconds}}') diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 42172a463e..f762357603 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -190,7 +190,7 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl` `kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다. 마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다. -또한 Horizontal Pod Autoscaler를 쉽게 생성 할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다. +또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다. 예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을 실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`, 그리고 2와 5 사이의 레플리카 개수로 설정된다. @@ -220,9 +220,10 @@ v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한 필요성을 제거하였다. -- `--horizontal-pod-autoscaler-downscale-delay` : 이 옵션 값은 - 오토스케일러가 현재의 작업이 완료된 후에 다른 다운스케일 작업을 - 수행하기까지 기다려야 하는 시간을 지정하는 지속 시간이다. +- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이 + 안정화되기까지의 시간 간격을 지정한다. + Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고, + 이 시간 간격에서의 가장 큰 크기에서만 작동한다. 기본값은 5분(`5m0s`)이다. {{< note >}} @@ -382,7 +383,12 @@ behavior: periodSeconds: 60 ``` -파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다. +`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다. +첫 번째 정책은 _(파드들)_ 이 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다. +두 번째 정책은 _비율_ 로 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다. + +기본적으로 가장 많은 변경을 허용하는 정책이 선택되기에 두 번째 정책은 +파드의 레플리카 수가 40개를 초과하는 경우에만 사용된다. 레플리카가 40개 이하인 경우 첫 번째 정책이 적용된다. 예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는 경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때 다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의 @@ -390,10 +396,6 @@ behavior: 미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에 4개의 레플리카가 줄어든다. -`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다. -첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다. -두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다. - 확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다. 레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다. 값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히 @@ -440,7 +442,7 @@ behavior: periodSeconds: 15 selectPolicy: Max ``` -안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된 +안정화 윈도우의 스케일링 다운의 경우 _300_ 초 (또는 제공된 경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재 실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링 대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다. diff --git a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md index f3debe8781..cf6c3188b7 100644 --- a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -65,6 +65,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로 kubectl describe deployment mysql + 출력은 다음과 유사하다. + Name: mysql Namespace: default CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700 @@ -105,6 +107,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로 kubectl get pods -l app=mysql + 출력은 다음과 유사하다. + NAME READY STATUS RESTARTS AGE mysql-63082529-2z3ki 1/1 Running 0 3m @@ -112,6 +116,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로 kubectl describe pvc mysql-pv-claim + 출력은 다음과 유사하다. + Name: mysql-pv-claim Namespace: default StorageClass: diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index a0af5ff5b5..7c1216c5fd 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -33,7 +33,7 @@ content_type: concept * [외부 IP 주소를 노출하여 클러스터의 애플리케이션에 접속하기](/ko/docs/tutorials/stateless-application/expose-external-ip-address/) -* [예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기](/ko/docs/tutorials/stateless-application/guestbook/) +* [예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기](/ko/docs/tutorials/stateless-application/guestbook/) ## 상태 유지가 필요한(stateful) 애플리케이션 diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 74008f9961..c28f41a7cc 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -168,8 +168,7 @@ k8s-apparmor-example-deny-write (enforce) *이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.* -먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 단순히 -파일 쓰기를 거부할 것이다. +먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 파일 쓰기를 거부한다. ```shell #include diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html index 4be0e94231..f1ab593581 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html @@ -41,7 +41,7 @@ card:

쿠버네티스가 어떤 도움이 될까?

-

오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 쉽고 빠르게 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.

+

오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.

diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html index ebc880dbdd..e44e68df85 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -64,12 +64,6 @@ weight: 10
-
-
-

-
-
-

서비스는 파드 셋에 걸쳐서 트래픽을 라우트한다. 여러분의 애플리케이션에 영향을 주지 않으면서 쿠버네티스에서 파드들이 죽게도 하고, 복제가 되게도 해주는 추상적 개념이다. 종속적인 파드들 사이에서의 디스커버리와 라우팅은 (하나의 애플리케이션에서 프로트엔드와 백엔드 컴포넌트와 같은) 쿠버네티스 서비스들에 의해 처리된다.

diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 35eb540724..a2df8806a8 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -921,7 +921,7 @@ web-2 0/1 Terminating 0 3m `web` 스테이트풀셋이 다시 생성될 때 먼저 `web-0` 시작한다. `web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로 -전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고 +전환될 때는 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고 `web-0`을 재생성했다면 `web-1`이 이미 Running과 Ready 상태이고, `web-2`은 종료되었을 것이다. @@ -932,6 +932,7 @@ web-2 0/1 Terminating 0 3m ```shell for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done ``` + ``` web-0 web-1 @@ -957,6 +958,7 @@ kubectl get pods -w -l app=nginx ```shell kubectl delete statefulset web ``` + ``` statefulset.apps "web" deleted ``` @@ -966,6 +968,7 @@ statefulset.apps "web" deleted ```shell kubectl get pods -w -l app=nginx ``` + ``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 11m @@ -997,6 +1000,7 @@ web-1 0/1 Terminating 0 29m ```shell kubectl delete service nginx ``` + ``` service "nginx" deleted ``` @@ -1006,6 +1010,7 @@ service "nginx" deleted ```shell kubectl apply -f web.yaml ``` + ``` service/nginx created statefulset.apps/web created @@ -1017,6 +1022,7 @@ statefulset.apps/web created ```shell for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done ``` + ``` web-0 web-1 @@ -1031,13 +1037,16 @@ web-1 ```shell kubectl delete service nginx ``` + ``` service "nginx" deleted ``` + 그리고 `web` 스테이트풀셋을 삭제한다. ```shell kubectl delete statefulset web ``` + ``` statefulset "web" deleted ``` diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index b1e6dbe523..3fca0a6749 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -15,17 +15,17 @@ weight: 40 이 튜토리얼을 시작하기 전에 다음 쿠버네티스 개념에 친숙해야 한다. -- [파드](/ko/docs/concepts/workloads/pods/) -- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) -- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) -- [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/) -- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) -- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) -- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets) -- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) -- [kubectl CLI](/ko/docs/reference/kubectl/kubectl/) +- [파드](/ko/docs/concepts/workloads/pods/) +- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) +- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) +- [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/) +- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) +- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets) +- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) +- [kubectl CLI](/ko/docs/reference/kubectl/kubectl/) -최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다. +반드시 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 축출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다. 이 튜토리얼은 클러스터가 동적으로 퍼시스턴트볼륨을 프로비저닝하도록 구성한다고 가정한다. 그렇게 설정되어 있지 않다면 @@ -37,15 +37,15 @@ weight: 40 이 튜토리얼을 마치면 다음에 대해 알게 된다. -- 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가. -- 어떻게 앙상블을 일관되게 설정하는가. -- 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. -- 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. +- 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가. +- 어떻게 앙상블을 일관되게 설정하는가. +- 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. +- 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. -### ZooKeeper 기본 {#zookeeper-basics} +### ZooKeeper [아파치 ZooKeeper](https://zookeeper.apache.org/doc/current/)는 분산 애플리케이션을 위한 분산 오픈 소스 코디네이션 서비스이다. @@ -438,8 +438,8 @@ datadir-zk-2 Bound pvc-bee0817e-bcb1-11e6-994f-42010a800002 20Gi R ```shell volumeMounts: - - name: datadir - mountPath: /var/lib/zookeeper +- name: datadir + mountPath: /var/lib/zookeeper ``` `zk` 스테이트풀셋이 (재)스케줄링될 때 항상 동일한 `퍼시스턴트볼륨`을 @@ -462,6 +462,7 @@ ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 ```shell kubectl get sts zk -o yaml ``` + ``` … command: @@ -551,11 +552,9 @@ kubectl logs zk-0 --tail 20 2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client) ``` -쿠버네티스는 더 강력하지만 조금 복잡한 로그 통합을 -[스택드라이버](/docs/tasks/debug-application-cluster/logging-stackdriver/)와 -[Elasticsearch와 Kibana](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)를 지원한다. -클러스터 수준의 로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해 -[사이드카](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 컨테이너를 배포하는 것을 고려한다. +쿠버네티스는 많은 로그 솔루션과 통합된다. 클러스터와 애플리케이션에 +가장 적합한 로그 솔루션을 선택할 수 있다. 클러스터 수준의 +로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해 [사이드카 컨테이너](/ko/docs/concepts/cluster-administration/logging/#로깅-에이전트와-함께-사이드카-컨테이너-사용)를 배포하는 것을 고려한다. ### 권한 없는 사용자를 위해 구성하기 @@ -623,6 +622,7 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data ```shell kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]' ``` + ``` statefulset.apps/zk patched ``` @@ -632,6 +632,7 @@ statefulset.apps/zk patched ```shell kubectl rollout status sts/zk ``` + ``` waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664... Waiting for 1 pods to be ready... @@ -872,8 +873,8 @@ kubernetes-node-2g2d ## 생존 유지 -**이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면, -다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다.** +이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면, +다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다. 이전 섹션은 계획되지 않은 노드 실패에서 살아남도록 어떻게 파드를 확산할 것인가에 대해 알아보았다. @@ -1008,6 +1009,7 @@ zk-1 0/1 Pending 0 0s ```shell kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data ``` + ``` node "kubernetes-node-i4c4" cordoned @@ -1051,6 +1053,7 @@ numChildren = 0 ```shell kubectl uncordon kubernetes-node-pb41 ``` + ``` node "kubernetes-node-pb41" uncordoned ``` @@ -1060,6 +1063,7 @@ node "kubernetes-node-pb41" uncordoned ```shell kubectl get pods -w -l app=zk ``` + ``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h @@ -1125,7 +1129,6 @@ drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인 - `kubectl uncordon`은 클러스터 내에 모든 노드를 통제 해제한다. -- 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한 - 퍼시스턴트 스토리지 미디어를 삭제하자. +- 반드시 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한 퍼시스턴트 스토리지 미디어를 삭제하자. 귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서 모든 스토리지가 재확보되도록 하자. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md deleted file mode 100644 index faf5fd5303..0000000000 --- a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ /dev/null @@ -1,457 +0,0 @@ ---- -title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가" -content_type: tutorial -weight: 21 -card: - name: tutorials - weight: 31 - title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가" ---- - - -이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼을 기반으로 한다. Elastic의 경량 로그, 메트릭, 네트워크 데이터 오픈소스 배송기인 *Beats* 를 방명록과 동일한 쿠버네티스 클러스터에 배포한다. Beats는 데이터를 수집하고 구문분석하여 Elasticsearch에 색인화하므로, Kibana에서 동작 정보를 결과로 보며 분석할 수 있다. 이 예시는 다음과 같이 구성되어 있다. - -* [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 실행한 인스턴스 -* Elasticsearch와 Kibana -* Filebeat -* Metricbeat -* Packetbeat - -## {{% heading "objectives" %}} - -* Redis를 이용한 PHP 방명록 시작. -* kube-state-metrics 설치. -* 쿠버네티스 시크릿 생성. -* Beats 배포. -* 로그와 메트릭의 대시보드 보기. - -## {{% heading "prerequisites" %}} - - -{{< include "task-tutorial-prereqs.md" >}} -{{< version-check >}} - -추가로 다음이 필요하다. - -* 실행 중인 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼의 배포본. - -* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나, - [파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) - 워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다. - - - - - -## Redis를 이용한 PHP 방명록 시작 - -이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자. - -## 클러스터 롤 바인딩 추가 - -[클러스터 단위 롤 바인딩](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다. - -```shell -kubectl create clusterrolebinding cluster-admin-binding \ - --clusterrole=cluster-admin --user= -``` - -## kube-state-metrics 설치 - -[*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다. - -```shell -git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics -kubectl apply -f kube-state-metrics/examples/standard -``` - -### kube-state-metrics 실행 여부 확인 - -```shell -kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics -``` - -출력 - -``` -NAME READY STATUS RESTARTS AGE -kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s -``` - -## Elastic의 예제를 GitHub 리포지터리에 클론한다. - -```shell -git clone https://github.com/elastic/examples.git -``` - -나머지 커맨드는 `examples/beats-k8s-send-anywhere` 디렉터리의 파일을 참조할 것이라서, 그쪽으로 현재 디렉터리를 변경한다. - -```shell -cd examples/beats-k8s-send-anywhere -``` - -## 쿠버네티스 시크릿 만들기 - -쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}은 암호나 토큰, 키 같이 소량의 민감한 데이터를 포함하는 오브젝트이다. 이러한 정보는 다른 방식으로도 파드 스펙이나 이미지에 넣을 수 있을 것이다. 시크릿 오브젝트에 넣으면 이것이 어떻게 사용되는지 다양하게 제어할 수 있고, 우발적인 노출 사고의 위험이 줄일 수 있다. - -{{< note >}} -여기에는 방식이 나뉘는데, 하나는 *자체 관리(Self managed)* 로 Elasticsearch와 Kibana(Elastic의 Helm 차트를 이용하여 사용자 서버를 구동하는)를 사용하는 경우이고 다른 경우는 Elastic Cloud의 Elasticsearch 서비스의 *관리 서비스(Managed service)* 를 사용하는 방식이다. 이 튜토리얼에서는 사용할 Elasticsearch와 Kibana 시스템의 종류에 따라 시크릿을 만들어야 한다. -{{< /note >}} - -{{< tabs name="tab_with_md" >}} -{{% tab name="자체 관리(Self Managed)" %}} - -### 자체 관리 - -Elastic Cloud의 Elasticsearch 서비스로 연결한다면 **관리 서비스** 탭으로 전환한다. - -### 자격증명(credentials) 설정 - -자체 관리 Elasticsearch와 Kibana(자체 관리는 사실상 Elastic Cloud의 관리 서비스 Elasticsearch와 다르다) 서비스에 접속할 때에 4개 파일을 수정하여 쿠버네티스 시크릿을 생성한다. 파일은 다음과 같다. - -1. `ELASTICSEARCH_HOSTS` -1. `ELASTICSEARCH_PASSWORD` -1. `ELASTICSEARCH_USERNAME` -1. `KIBANA_HOST` - -이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시(또는 [*이 구성*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)을 본다)가 있다. - -#### `ELASTICSEARCH_HOSTS` - -1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup). - - ``` - ["http://elasticsearch-master.default.svc.cluster.local:9200"] - ``` - -1. Mac을 위한 Docker에서 Beats를 운영 중인 Mac에서 운영하는 단일 Elasticsearch 노드. - - ``` - ["http://host.docker.internal:9200"] - ``` - -1. VM이나 물리 장비에서 운영 중인 두 개의 ELASTICSEARCH 노드. - - ``` - ["http://host1.example.com:9200", "http://host2.example.com:9200"] - ``` - -`ELASTICSEARCH_HOSTS` 를 수정한다. - -```shell -vi ELASTICSEARCH_HOSTS -``` - -#### `ELASTICSEARCH_PASSWORD` -화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 암호이다. - -``` -<사용자시크릿암호> -``` - -`ELASTICSEARCH_PASSWORD` 를 수정한다. - -```shell -vi ELASTICSEARCH_PASSWORD -``` - -#### `ELASTICSEARCH_USERNAME` -화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 이름이다. - -``` - -``` - -`ELASTICSEARCH_USERNAME` 을 수정한다. - -```shell -vi ELASTICSEARCH_USERNAME -``` - -#### `KIBANA_HOST` - -1.Elastic의 Kibana Helm 차트의 인스턴스이다. 하위 도메인 `default`는 기본 네임스페이스를 참조한다. 다른 네임스페이스를 사용하여 Helm 차트를 배포한 경우 하위 도메인이 다릅니다. - - ``` - "kibana-kibana.default.svc.cluster.local:5601" - ``` - -1. Mac 용 Docker에서 실행하는 Beats가 있는 Mac에서 실행하는 Kibana 인스턴스 - - ``` - "host.docker.internal:5601" - ``` -1. 가상머신이나 물리적 하드웨어에서 실행 중인 두 개의 Elasticsearch 노드 - - ``` - "host1.example.com:5601" - ``` - -`KIBANA_HOST` 를 편집한다. - -```shell -vi KIBANA_HOST -``` - -### 쿠버네티스 시크릿 만들기 - -이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 만든다. - -```shell -kubectl create secret generic dynamic-logging \ - --from-file=./ELASTICSEARCH_HOSTS \ - --from-file=./ELASTICSEARCH_PASSWORD \ - --from-file=./ELASTICSEARCH_USERNAME \ - --from-file=./KIBANA_HOST \ - --namespace=kube-system -``` - -{{% /tab %}} -{{% tab name="관리 서비스(Managed service)" %}} - -## 관리 서비스 - -이 탭은 Elastic Cloud에서 Elasticsearch 서비스 만에 대한 것으로, 이미 자체 관리 Elasticsearch와 Kibana 배포로 시크릿을 생성했다면, [Beats 배포](#deploy-the-beats)를 계속한다. - -### 자격증명(credentials) 설정 - -Elastic Cloud에서 관리되는 Elastic 서비스에 연결할 때, 쿠버네티스 시크릿을 생성하기 위해 편집할 두 파일이 있다. 파일은 다음과 같다. - -1. `ELASTIC_CLOUD_AUTH` -1. `ELASTIC_CLOUD_ID` - -디플로이먼트를 생성할 때에 Elasticsearch 콘솔에서 제공한 정보로 이를 설정한다. 여기 예시들이 있다. - -#### `ELASTIC_CLOUD_ID` - -``` -devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ== -``` - -#### `ELASTIC_CLOUD_AUTH` - -사용자 이름, 콜론(`:`) 및 비밀번호인데, 공백 또는 따옴표는 없다. - -``` -elastic:VFxJJf9Tjwer90wnfTghsn8w -``` - -### 필요 파일 편집하기 - -```shell -vi ELASTIC_CLOUD_ID -vi ELASTIC_CLOUD_AUTH -``` - -### 쿠버네티스 시크릿 생성하기 - -이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 생성한다. - -```shell -kubectl create secret generic dynamic-logging \ - --from-file=./ELASTIC_CLOUD_ID \ - --from-file=./ELASTIC_CLOUD_AUTH \ - --namespace=kube-system -``` - -{{% /tab %}} -{{< /tabs >}} - -## Beats 배포하기 {#deploy-the-beats} - -각 Beat마다 메니페스트 파일을 제공한다. 이 메니페스트 파일은 앞서 생성한 시크릿을 사용하여, Elasticsearch 및 Kibana 서버에 연결하도록 Beats를 구성한다. - -### Filebeat에 대해 - -Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파드에서 실행되는 컨테이너의 로그를 수집한다. Filebeat는 {{< glossary_tooltip text="데몬 셋" term_id="daemonset" >}}으로 배포한다. Filebeat는 쿠버네티스 클러스터에서 실행 중인 애플리케이션을 자동 검색할 수 있다. 시작시에 Filebeat는 기존 컨테이너를 검색하고 이에 적절한 구성을 시작하고 새 시작/종료 이벤트를 감시한다. - -아래 내용은 Filebeat가 방명록 애플리케이션과 함께 배포된 Redis 컨테이너에서 Redis 로그를 찾아 구문분석할 수 있게 하는 자동 검색 구성이다. 이 구성은 `filebeat-kubernetes.yaml`파일에 있다. - -```yaml -- condition.contains: - kubernetes.labels.app: redis - config: - - module: redis - log: - input: - type: docker - containers.ids: - - ${data.kubernetes.container.id} - slowlog: - enabled: true - var.hosts: ["${data.host}:${data.port}"] -``` - -이것은 `redis` 컨테이너가 `app` 문자열을 포함하는 레이블로 감지될 때에 Filebeat 모듈 `redis`를 적용하도록 Filebeat를 구성한다. Redis 모듈은 Docker 입력 유형을 사용하여 컨테이너에서 `로그` 스트림을 수집할 수 있다(이 Redis 컨테이너의 STDOUT 스트림과 연관된 쿠버네티스 노드에서 파일 읽기). 또한 이 모듈은 컨테이너 메타 데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 Redis의 `slowlog` 항목을 수집할 수 있다. - -### Filebeat 배포 - -```shell -kubectl create -f filebeat-kubernetes.yaml -``` - -#### 확인 - -```shell -kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic -``` - -### Metricbeat에 대해 - -Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음은 Redis 컨테이너에 대한 Metricbeat의 자동 검색 구성이다. 이 구성은 `metricbeat-kubernetes.yaml`에 있다. - -```yaml -- condition.equals: - kubernetes.labels.tier: backend - config: - - module: redis - metricsets: ["info", "keyspace"] - period: 10s - - # Redis hosts - hosts: ["${data.host}:${data.port}"] -``` - -이것은 컨테이너가 `tier` 레이블이 `backend` 문자열과 같은 레이블로 감지될 때에 Metricbeat 모듈 `redis`를 적용하도록 Metricbeat를 구성한다. `redis` 모듈은 컨테이너 메타데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 컨테이너에서 `info` 및 `keyspace` 메트릭을 수집할 수 있다. - -### Metricbeat 배포 - -```shell -kubectl create -f metricbeat-kubernetes.yaml -``` - -#### 확인 - -```shell -kubectl get pods -n kube-system -l k8s-app=metricbeat -``` - -### Packetbeat에 대해 - -Packetbeat 구성은 Filebeat와 Metricbeat와는 다르다. 컨테이너 레이블과 일치시킬 패턴을 지정하지 않고, 구성은 관련 프로토콜 및 포트 번호를 기반으로 한다. 아래는 포트 번호의 하위 집합이다. - -{{< note >}} -비표준 포트로 서비스를 실행했다면 해당 포트를 `filebeat.yaml`에 적절한 유형에 추가하고, Packetbeat 데몬 셋을 삭제하고 생성한다. -{{< /note >}} - -```yaml -packetbeat.interfaces.device: any - -packetbeat.protocols: -- type: dns - ports: [53] - include_authorities: true - include_additionals: true - -- type: http - ports: [80, 8000, 8080, 9200] - -- type: mysql - ports: [3306] - -- type: redis - ports: [6379] - -packetbeat.flows: - timeout: 30s - period: 10s -``` - -#### Packetbeat 배포하기 - -```shell -kubectl create -f packetbeat-kubernetes.yaml -``` - -#### 확인하기 - -```shell -kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic -``` - -## Kibana에서 보기 - -브라우저에서 Kibana를 열고, **대시보드** 애플리케이션을 열어보자. 검색창에 kubernetes를 입력하고 쿠버네티스를 위한 Metricbeat 대시보드를 클릭한다. 이 대시보드에는 노드 상태, 배포 등의 보고 내용이 있다. - -대시보드 페이지에 Packetbeat를 검색하고 Packetbeat의 개요 페이지를 살펴보자. - -마찬가지로 Apache와 Redis를 위한 대시보드를 확인한다. 각 로그와 메트릭에 대한 대시보드가 표시된다. 이 Apache Metricbeat 대시보드는 비어 있다. Apache Filebeat 대시보드를 보고, 맨 아래로 스크롤하여 Apache 오류 로그를 확인한다. Apache에서 보여줄 메트릭이 없는 이유를 알려줄 것이다. - -Metricbeat에서 Apache 메트릭을 가져올 수 있게 하려면, mod-status 구성 파일을 포함한 컨피그맵을 추가하고 방명록을 재배포하여 서버 상태를 활성화해야 한다. - - -## 디플로이먼트를 확장하고 모니터링중인 새 파드를 확인하기 - -기존 디플로이먼트를 확인한다. - -```shell -kubectl get deployments -``` - -출력 - -``` -NAME READY UP-TO-DATE AVAILABLE AGE -frontend 3/3 3 3 3h27m -redis-master 1/1 1 1 3h27m -redis-slave 2/2 2 2 3h27m -``` - -front의 디플로이먼트를 두 개의 파드로 축소한다. - -```shell -kubectl scale --replicas=2 deployment/frontend -``` - -출력 - -``` -deployment.extensions/frontend scaled -``` - -frontend의 파드를 최대 3개의 파드로 확장한다. - -```shell -kubectl scale --replicas=3 deployment/frontend -``` - -## Kibana에서 변화 확인하기 - -스크린 캡처를 확인하여, 표시된 필터를 추가하고 해당 열을 뷰에 추가한다. ScalingReplicaSet 항목이 표시되고, 여기에서 이벤트 목록의 맨 위에 풀링되는 이미지, 마운트된 볼륨, 파드 시작 등을 보여준다. -![Kibana 디스커버리](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png) - -## {{% heading "cleanup" %}} - -디플로이먼트와 서비스를 삭제하면 실행중인 파드도 삭제된다. 한 커맨드로 여러 개의 리소스를 삭제하기 위해 레이블을 이용한다. - -1. 다음 커맨드를 실행하여 모든 파드, 디플로이먼트, 서비스를 삭제한다. - - ```shell - kubectl delete deployment -l app=redis - kubectl delete service -l app=redis - kubectl delete deployment -l app=guestbook - kubectl delete service -l app=guestbook - kubectl delete -f filebeat-kubernetes.yaml - kubectl delete -f metricbeat-kubernetes.yaml - kubectl delete -f packetbeat-kubernetes.yaml - kubectl delete secret dynamic-logging -n kube-system - ``` - -1. 실행 중인 파드가 없음을 확인하기 위해 파드 목록을 조회한다. - - ```shell - kubectl get pods - ``` - - 출력은 다음과 같아야 한다. - - ``` - No resources found. - ``` - -## {{% heading "whatsnext" %}} - -* [리소스 모니터링 도구](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다. -* [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 더 읽어본다. -* [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다. -* [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index cce67800a6..c91ecd2e1b 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -1,26 +1,25 @@ --- -title: "예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기" +title: "예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기" content_type: tutorial weight: 20 card: name: tutorials weight: 30 - title: "상태를 유지하지 않는 예제: Redis를 사용한 PHP 방명록" + title: "상태를 유지하지 않는 예제: MongoDB를 사용한 PHP 방명록" +min-kubernetes-server-version: v1.14 --- -이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다. +이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 _(운영 준비가 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다. -* 방명록을 저장하는 단일 인스턴스 [Redis](https://redis.io/) 마스터 -* 읽기를 제공하는 여러 개의 [복제된 Redis](https://redis.io/topics/replication) 인스턴스 +* 방명록을 저장하는 단일 인스턴스 [MongoDB](https://www.mongodb.com/) * 여러 개의 웹 프론트엔드 인스턴스 ## {{% heading "objectives" %}} -* Redis 마스터를 시작 -* Redis 슬레이브를 시작 +* Mongo 데이터베이스를 시작 * 방명록 프론트엔드를 시작 * 프론트엔드 서비스를 노출하고 확인 * 정리 하기 @@ -37,24 +36,28 @@ card: -## Redis 마스터를 실행하기 +## Mongo 데이터베이스를 실행 -방명록 애플리케이션은 Redis를 사용하여 데이터를 저장한다. Redis 마스터 인스턴스에 데이터를 기록하고 여러 Redis 슬레이브 인스턴스에서 데이터를 읽는다. +방명록 애플리케이션은 MongoDB를 사용해서 데이터를 저장한다. -### Redis 마스터의 디플로이먼트를 생성하기 +### Mongo 디플로이먼트를 생성하기 -아래의 매니페스트 파일은 단일 복제본 Redis 마스터 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다. +아래의 매니페스트 파일은 단일 복제본 Mongo 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다. -{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} +{{< codenew file="application/guestbook/mongo-deployment.yaml" >}} 1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다. -1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용한다. +1. `mongo-deployment.yaml` 파일을 통해 MongoDB 디플로이먼트에 적용한다. ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml + kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml ``` + -1. 파드의 목록을 질의하여 Redis 마스터 파드가 실행 중인지 확인한다. +1. 파드의 목록을 질의하여 MongoDB 파드가 실행 중인지 확인한다. ```shell kubectl get pods @@ -64,32 +67,32 @@ card: ```shell NAME READY STATUS RESTARTS AGE - redis-master-1068406935-3lswp 1/1 Running 0 28s + mongo-5cfd459dd4-lrcjb 1/1 Running 0 28s ``` -1. Redis 마스터 파드에서 로그를 보려면 다음 명령어를 실행한다. +2. MongoDB 파드에서 로그를 보려면 다음 명령어를 실행한다. ```shell - kubectl logs -f POD-NAME + kubectl logs -f deployment/mongo ``` -{{< note >}} -POD-NAME을 해당 파드 이름으로 수정해야 한다. -{{< /note >}} +### MongoDB 서비스 생성하기 -### Redis 마스터 서비스 생성하기 +방명록 애플리케이션에서 데이터를 쓰려면 MongoDB와 통신해야 한다. MongoDB 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. -방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. +{{< codenew file="application/guestbook/mongo-service.yaml" >}} -{{< codenew file="application/guestbook/redis-master-service.yaml" >}} - -1. `redis-master-service.yaml` 파일을 통해 Redis 마스터 서비스에 적용한다. +1. `mongo-service.yaml` 파일을 통해 MongoDB 서비스에 적용한다. ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml + kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml ``` + -1. 서비스의 목록을 질의하여 Redis 마스터 서비스가 실행 중인지 확인한다. +1. 서비스의 목록을 질의하여 MongoDB 서비스가 실행 중인지 확인한다. ```shell kubectl get service @@ -100,77 +103,17 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다. ```shell NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.0.0.1 443/TCP 1m - redis-master ClusterIP 10.0.0.151 6379/TCP 8s + mongo ClusterIP 10.0.0.151 6379/TCP 8s ``` {{< note >}} -이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `redis-master`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 Redis 마스터 파드로 라우팅한다. +이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `mongo`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 MongoDB 파드로 라우팅한다. {{< /note >}} -## Redis 슬레이브 실행하기 - -Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추가하여 트래픽 요구 사항을 충족시킬 수 있다. - -### Redis 슬레이브의 디플로이먼트 생성하기 - -디플로이먼트는 매니페스트 파일에 설정된 구성에 따라 확장된다. 이 경우, 디플로이먼트 오브젝트는 두 개의 복제본을 지정한다. - -실행 중인 복제본이 없으면, 이 디플로이먼트는 컨테이너 클러스터에 있는 두 개의 복제본을 시작한다. 반대로 두 개 이상의 복제본이 실행 중이면, 두 개의 복제본이 실행될 때까지 축소된다. - -{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}} - -1. `redis-slave-deployment.yaml` 파일을 통해 Redis 슬레이브의 디플로이먼트에 적용한다. - - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml - ``` - -1. 파드의 목록을 질의하여 Redis 슬레이브 파드가 실행 중인지 확인한다. - - ```shell - kubectl get pods - ``` - - 결과는 아래와 같은 형태로 나타난다. - - ```shell - NAME READY STATUS RESTARTS AGE - redis-master-1068406935-3lswp 1/1 Running 0 1m - redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s - redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s - ``` - -### Redis 슬레이브 서비스 생성하기 - -방명록 애플리케이션은 Redis 슬레이브와 통신하여 데이터를 읽는다. Redis 슬레이브를 확인할 수 있도록 하기 위해 서비스를 설정해야 한다. 서비스는 파드 집합에 투명한 로드 밸런싱을 제공한다. - -{{< codenew file="application/guestbook/redis-slave-service.yaml" >}} - -1. `redis-slave-service.yaml` 파일을 통해 Redis 슬레이브 서비스에 적용한다. - - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml - ``` - -1. 서비스의 목록을 질의하여 Redis 슬레이브 서비스가 실행 중인지 확인한다. - - ```shell - kubectl get services - ``` - - 결과는 아래와 같은 형태로 나타난다. - - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.0.0.1 443/TCP 2m - redis-master ClusterIP 10.0.0.151 6379/TCP 1m - redis-slave ClusterIP 10.0.0.223 6379/TCP 6s - ``` - ## 방명록 프론트엔드를 설정하고 노출하기 -방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 쓰기 요청을 위한 `redis-master` 서비스와 읽기 요청을 위한 `redis-slave` 서비스에 연결하도록 설정된다. +방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 방명록 항목들을 저장하기 위해 `mongo` 서비스에 연결하도록 구성 한다. ### 방명록 프론트엔드의 디플로이먼트 생성하기 @@ -182,6 +125,11 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml ``` + + 1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다. ```shell @@ -199,12 +147,12 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 ### 프론트엔드 서비스 생성하기 -서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. +서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 `mongo` 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. -게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 통해서만 서비스를 노출할 수 있다. +게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 쿠버네티스 클러스터 외부에서 서비스를 요청할 수 있다. 그러나 쿠버네티스 사용자는 `ClusterIP`를 사용하더라도 `kubectl port-forward`를 사용해서 서비스에 접근할 수 있다. {{< note >}} -Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : NodePort`를 삭제하거나 주석 처리하고 `type : LoadBalancer`의 주석을 제거해야 한다. +Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : LoadBalancer`의 주석을 제거해야 한다. {{< /note >}} {{< codenew file="application/guestbook/frontend-service.yaml" >}} @@ -215,6 +163,11 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml ``` + + 1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다. ```shell @@ -225,29 +178,27 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - frontend NodePort 10.0.0.112 80:31323/TCP 6s + frontend ClusterIP 10.0.0.112 80/TCP 6s kubernetes ClusterIP 10.0.0.1 443/TCP 4m - redis-master ClusterIP 10.0.0.151 6379/TCP 2m - redis-slave ClusterIP 10.0.0.223 6379/TCP 1m + mongo ClusterIP 10.0.0.151 6379/TCP 2m ``` -### `NodePort`를 통해 프론트엔드 서비스 확인하기 +### `kubectl port-forward`를 통해 프론트엔드 서비스 확인하기 -애플리케이션을 Minikube 또는 로컬 클러스터에 배포한 경우, 방명록을 보려면 IP 주소를 찾아야 한다. - -1. 프론트엔드 서비스의 IP 주소를 얻기 위해 아래 명령어를 실행한다. +1. 다음 명령어를 실행해서 로컬 머신의 `8080` 포트를 서비스의 `80` 포트로 전달한다. ```shell - minikube service frontend --url + kubectl port-forward svc/frontend 8080:80 ``` 결과는 아래와 같은 형태로 나타난다. ``` - http://192.168.99.100:31323 + Forwarding from 127.0.0.1:8080 -> 80 + Forwarding from [::1]:8080 -> 80 ``` -1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다. +1. 방명록을 보기위해 브라우저에서 [http://localhost:8080](http://localhost:8080) 페이지를 로드한다. ### `LoadBalancer`를 통해 프론트엔드 서비스 확인하기 @@ -270,7 +221,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 ## 웹 프론트엔드 확장하기 -서버가 디플로이먼트 컨트롤러를 사용하는 서비스로 정의되어 있기 때문에 확장 또는 축소가 쉽다. +서버가 디플로이먼트 컨르롤러를 사용하는 서비스로 정의되어 있기에 필요에 따라 확장 또는 축소할 수 있다. 1. 프론트엔드 파드의 수를 확장하기 위해 아래 명령어를 실행한다. @@ -293,9 +244,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 frontend-3823415956-k22zn 1/1 Running 0 54m frontend-3823415956-w9gbt 1/1 Running 0 54m frontend-3823415956-x2pld 1/1 Running 0 5s - redis-master-1068406935-3lswp 1/1 Running 0 56m - redis-slave-2005841000-fpvqc 1/1 Running 0 55m - redis-slave-2005841000-phfv9 1/1 Running 0 55m + mongo-1068406935-3lswp 1/1 Running 0 56m ``` 1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다. @@ -316,9 +265,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 NAME READY STATUS RESTARTS AGE frontend-3823415956-k22zn 1/1 Running 0 1h frontend-3823415956-w9gbt 1/1 Running 0 1h - redis-master-1068406935-3lswp 1/1 Running 0 1h - redis-slave-2005841000-fpvqc 1/1 Running 0 1h - redis-slave-2005841000-phfv9 1/1 Running 0 1h + mongo-1068406935-3lswp 1/1 Running 0 1h ``` @@ -330,19 +277,18 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 1. 모든 파드, 디플로이먼트, 서비스를 삭제하기 위해 아래 명령어를 실행한다. ```shell - kubectl delete deployment -l app=redis - kubectl delete service -l app=redis - kubectl delete deployment -l app=guestbook - kubectl delete service -l app=guestbook + kubectl delete deployment -l app.kubernetes.io/name=mongo + kubectl delete service -l app.kubernetes.io/name=mongo + kubectl delete deployment -l app.kubernetes.io/name=guestbook + kubectl delete service -l app.kubernetes.io/name=guestbook ``` 결과는 아래와 같은 형태로 나타난다. ``` - deployment.apps "redis-master" deleted - deployment.apps "redis-slave" deleted - service "redis-master" deleted - service "redis-slave" deleted + deployment.apps "mongo" deleted + service "mongo" deleted + deployment.apps "frontend" deleted deployment.apps "frontend" deleted service "frontend" deleted ``` @@ -363,7 +309,6 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 ## {{% heading "whatsnext" %}} -* [ELK 로깅과 모니터링](/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)을 방명록 애플리케이션에 추가하기 * [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료 * [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기 * [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기 diff --git a/content/ko/examples/application/guestbook/frontend-deployment.yaml b/content/ko/examples/application/guestbook/frontend-deployment.yaml index 23d64be644..613c654aa9 100644 --- a/content/ko/examples/application/guestbook/frontend-deployment.yaml +++ b/content/ko/examples/application/guestbook/frontend-deployment.yaml @@ -3,22 +3,24 @@ kind: Deployment metadata: name: frontend labels: - app: guestbook + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend spec: selector: matchLabels: - app: guestbook - tier: frontend + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend replicas: 3 template: metadata: labels: - app: guestbook - tier: frontend + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend spec: containers: - - name: php-redis - image: gcr.io/google-samples/gb-frontend:v4 + - name: guestbook + image: paulczar/gb-frontend:v5 + # image: gcr.io/google-samples/gb-frontend:v4 resources: requests: cpu: 100m @@ -26,13 +28,5 @@ spec: env: - name: GET_HOSTS_FROM value: dns - # Using `GET_HOSTS_FROM=dns` requires your cluster to - # provide a dns service. As of Kubernetes 1.3, DNS is a built-in - # service launched automatically. However, if the cluster you are using - # does not have a built-in DNS service, you can instead - # access an environment variable to find the master - # service's host. To do so, comment out the 'value: dns' line above, and - # uncomment the line below: - # value: env ports: - containerPort: 80 diff --git a/content/ko/examples/application/guestbook/frontend-service.yaml b/content/ko/examples/application/guestbook/frontend-service.yaml index 6f283f347b..34ad3771d7 100644 --- a/content/ko/examples/application/guestbook/frontend-service.yaml +++ b/content/ko/examples/application/guestbook/frontend-service.yaml @@ -3,16 +3,14 @@ kind: Service metadata: name: frontend labels: - app: guestbook - tier: frontend + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend spec: - # comment or delete the following line if you want to use a LoadBalancer - type: NodePort # if your cluster supports it, uncomment the following to automatically create # an external load-balanced IP for the frontend service. # type: LoadBalancer ports: - port: 80 selector: - app: guestbook - tier: frontend + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend diff --git a/content/ko/examples/application/guestbook/mongo-deployment.yaml b/content/ko/examples/application/guestbook/mongo-deployment.yaml new file mode 100644 index 0000000000..04908ce25b --- /dev/null +++ b/content/ko/examples/application/guestbook/mongo-deployment.yaml @@ -0,0 +1,31 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + selector: + matchLabels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + replicas: 1 + template: + metadata: + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + spec: + containers: + - name: mongo + image: mongo:4.2 + args: + - --bind_ip + - 0.0.0.0 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 27017 diff --git a/content/ko/examples/application/guestbook/mongo-service.yaml b/content/ko/examples/application/guestbook/mongo-service.yaml new file mode 100644 index 0000000000..b9cef607bc --- /dev/null +++ b/content/ko/examples/application/guestbook/mongo-service.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Service +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + ports: + - port: 27017 + targetPort: 27017 + selector: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend diff --git a/content/ko/examples/application/guestbook/redis-master-deployment.yaml b/content/ko/examples/application/guestbook/redis-master-deployment.yaml deleted file mode 100644 index 478216d1ac..0000000000 --- a/content/ko/examples/application/guestbook/redis-master-deployment.yaml +++ /dev/null @@ -1,29 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: redis-master - labels: - app: redis -spec: - selector: - matchLabels: - app: redis - role: master - tier: backend - replicas: 1 - template: - metadata: - labels: - app: redis - role: master - tier: backend - spec: - containers: - - name: master - image: k8s.gcr.io/redis:e2e # or just image: redis - resources: - requests: - cpu: 100m - memory: 100Mi - ports: - - containerPort: 6379 diff --git a/content/ko/examples/application/guestbook/redis-master-service.yaml b/content/ko/examples/application/guestbook/redis-master-service.yaml deleted file mode 100644 index 65cef2191c..0000000000 --- a/content/ko/examples/application/guestbook/redis-master-service.yaml +++ /dev/null @@ -1,17 +0,0 @@ -apiVersion: v1 -kind: Service -metadata: - name: redis-master - labels: - app: redis - role: master - tier: backend -spec: - ports: - - name: redis - port: 6379 - targetPort: 6379 - selector: - app: redis - role: master - tier: backend diff --git a/content/ko/examples/application/guestbook/redis-slave-deployment.yaml b/content/ko/examples/application/guestbook/redis-slave-deployment.yaml deleted file mode 100644 index 1a7b04386a..0000000000 --- a/content/ko/examples/application/guestbook/redis-slave-deployment.yaml +++ /dev/null @@ -1,40 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: redis-slave - labels: - app: redis -spec: - selector: - matchLabels: - app: redis - role: slave - tier: backend - replicas: 2 - template: - metadata: - labels: - app: redis - role: slave - tier: backend - spec: - containers: - - name: slave - image: gcr.io/google_samples/gb-redisslave:v3 - resources: - requests: - cpu: 100m - memory: 100Mi - env: - - name: GET_HOSTS_FROM - value: dns - # Using `GET_HOSTS_FROM=dns` requires your cluster to - # provide a dns service. As of Kubernetes 1.3, DNS is a built-in - # service launched automatically. However, if the cluster you are using - # does not have a built-in DNS service, you can instead - # access an environment variable to find the master - # service's host. To do so, comment out the 'value: dns' line above, and - # uncomment the line below: - # value: env - ports: - - containerPort: 6379 diff --git a/content/ko/examples/application/guestbook/redis-slave-service.yaml b/content/ko/examples/application/guestbook/redis-slave-service.yaml deleted file mode 100644 index 238fd63fb6..0000000000 --- a/content/ko/examples/application/guestbook/redis-slave-service.yaml +++ /dev/null @@ -1,15 +0,0 @@ -apiVersion: v1 -kind: Service -metadata: - name: redis-slave - labels: - app: redis - role: slave - tier: backend -spec: - ports: - - port: 6379 - selector: - app: redis - role: slave - tier: backend diff --git a/content/ko/examples/application/job/cronjob.yaml b/content/ko/examples/application/job/cronjob.yaml index 3ca130289e..816d682f28 100644 --- a/content/ko/examples/application/job/cronjob.yaml +++ b/content/ko/examples/application/job/cronjob.yaml @@ -12,7 +12,7 @@ spec: - name: hello image: busybox imagePullPolicy: IfNotPresent - args: + command: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster diff --git a/content/ko/examples/policy/priority-class-resourcequota.yaml b/content/ko/examples/policy/priority-class-resourcequota.yaml new file mode 100644 index 0000000000..7350d00c8f --- /dev/null +++ b/content/ko/examples/policy/priority-class-resourcequota.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: pods-cluster-services +spec: + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["cluster-services"] \ No newline at end of file diff --git a/content/pt/docs/concepts/security/_index.md b/content/pt/docs/concepts/security/_index.md new file mode 100644 index 0000000000..63fca06b9a --- /dev/null +++ b/content/pt/docs/concepts/security/_index.md @@ -0,0 +1,5 @@ +--- +title: "Segurança" +weight: 81 +--- + diff --git a/content/pt/docs/concepts/security/overview.md b/content/pt/docs/concepts/security/overview.md new file mode 100644 index 0000000000..1f75e051ae --- /dev/null +++ b/content/pt/docs/concepts/security/overview.md @@ -0,0 +1,153 @@ +--- +title: Visão Geral da Segurança Cloud Native +content_type: concept +weight: 10 +--- + + + +Esta visão geral define um modelo para pensar sobre a segurança em Kubernetes no contexto da Segurança em Cloud Native. + +{{< warning >}} +Este modelo de segurança no contêiner fornece sugestões, não prova políticas de segurança da informação. +{{< /warning >}} + + + +## Os 4C da Segurança Cloud Native + +Você pode pensar na segurança em camadas. Os 4C da segurança Cloud Native são a Cloud, +Clusters, Contêineres e Código. + +{{< note >}} +Esta abordagem em camadas aumenta a [defesa em profundidade](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) +para segurança, que é amplamente considerada como uma boa prática de segurança para software de sistemas. +{{< /note >}} + +{{< figure src="/images/docs/4c.png" title="Os 4C da Segurança Cloud Native" >}} + +Cada camada do modelo de segurança Cloud Native é construída sobre a próxima camada mais externa. +A camada de código se beneficia de uma base forte (Cloud, Cluster, Contêiner) de camadas seguras. +Você não pode proteger contra padrões ruins de segurança nas camadas de base através de +segurança no nível do Código. + +## Cloud + +De muitas maneiras, a Cloud (ou servidores co-localizados, ou o datacenter corporativo) é a +[base de computação confiável](https://en.wikipedia.org/wiki/Trusted_computing_base) +de um cluster Kubernetes. Se a camada de Cloud é vulnerável (ou +configurado de alguma maneira vulnerável), então não há garantia de que os componentes construídos +em cima desta base estejam seguros. Cada provedor de Cloud faz recomendações de segurança +para executar as cargas de trabalho com segurança nos ambientes. + +### Segurança no provedor da Cloud + +Se você estiver executando um cluster Kubernetes em seu próprio hardware ou em um provedor de nuvem diferente, +consulte sua documentação para melhores práticas de segurança. +Aqui estão os links para as documentações de segurança dos provedores mais populares de nuvem: + +{{< table caption="Cloud provider security" >}} + +Provedor IaaS | Link | +-------------------- | ------------ | +Alibaba Cloud | https://www.alibabacloud.com/trust-center | +Amazon Web Services | https://aws.amazon.com/security/ | +Google Cloud Platform | https://cloud.google.com/security/ | +IBM Cloud | https://www.ibm.com/cloud/security | +Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | +VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | + +{{< /table >}} + +### Segurança de Infraestrutura {#infrastructure-security} + +Sugestões para proteger sua infraestrutura em um cluster Kubernetes: + +{{< table caption="Infrastructure security" >}} + +Área de Interesse para Infraestrutura Kubernetes | Recomendação | +--------------------------------------------- | -------------- | +Acesso de rede ao servidor API (Control plane) | Todo o acesso ao control plane do Kubernetes publicamente na Internet não é permitido e é controlado por listas de controle de acesso à rede restritas ao conjunto de endereços IP necessários para administrar o cluster.| +Acesso de rede aos Nós (nodes) | Os nós devem ser configurados para _só_ aceitar conexões (por meio de listas de controle de acesso à rede) do control plane nas portas especificadas e aceitar conexões para serviços no Kubernetes do tipo NodePort e LoadBalancer. Se possível, esses nós não devem ser expostos inteiramente na Internet pública. +Acesso do Kubernetes à API do provedor de Cloud | Cada provedor de nuvem precisa conceder um conjunto diferente de permissões para o control plane e nós do Kubernetes. É melhor fornecer ao cluster permissão de acesso ao provedor de nuvem que segue o [princípio do menor privilégio](https://en.wikipedia.org/wiki/Principle_of_least_privilege) para os recursos que ele precisa administrar. A [documentação do Kops](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) fornece informações sobre as políticas e roles do IAM. +Acesso ao etcd | O acesso ao etcd (o armazenamento de dados do Kubernetes) deve ser limitado apenas ao control plane. Dependendo de sua configuração, você deve tentar usar etcd sobre TLS. Mais informações podem ser encontradas na [documentação do etcd](https://github.com/etcd-io/etcd/tree/master/Documentation). +Encriptação etcd | Sempre que possível, é uma boa prática encriptar todas as unidades de armazenamento, mas como o etcd mantém o estado de todo o cluster (incluindo os Secrets), seu disco deve ser criptografado. + +{{< /table >}} + +## Cluster + +Existem duas áreas de preocupação para proteger o Kubernetes: + +* Protegendo os componentes do cluster que são configuráveis. +* Protegendo as aplicações que correm no cluster. + +### Componentes do Cluster {#cluster-components} + +Se você deseja proteger seu cluster de acesso acidental ou malicioso e adotar +boas práticas de informação, leia e siga os conselhos sobre +[protegendo seu cluster](/docs/tasks/administer-cluster/securing-a-cluster/). + +### Componentes no cluster (sua aplicação) {#cluster-applications} + +Dependendo da superfície de ataque de sua aplicação, você pode querer se concentrar em +tópicos específicos de segurança. Por exemplo: se você estiver executando um serviço (Serviço A) que é crítico +numa cadeia de outros recursos e outra carga de trabalho separada (Serviço B) que é +vulnerável a um ataque de exaustão de recursos e, por consequência, o risco de comprometer o Serviço A +é alto se você não limitar os recursos do Serviço B. A tabela a seguir lista +áreas de atenção na segurança e recomendações para proteger cargas de trabalho em execução no Kubernetes: + +Área de interesse para a segurança do Workload | Recomendação | +------------------------------ | --------------------- | +Autorização RBAC (acesso à API Kubernetes) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ +Autenticação | https://kubernetes.io/docs/concepts/security/controlling-access/ +Gerenciamento de segredos na aplicação (e encriptando-os no etcd em repouso) | https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ +Políticas de segurança do Pod | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ +Qualidade de serviço (e gerenciamento de recursos de cluster) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/ +Políticas de Rede | https://kubernetes.io/docs/concepts/services-networking/network-policies/ +TLS para Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls + +## Contêiner + +A segurança do contêiner está fora do escopo deste guia. Aqui estão recomendações gerais e +links para explorar este tópico: + +Área de Interesse para Contêineres | Recomendação | +------------------------------ | -------------- | +Scanners de Vulnerabilidade de Contêiner e Segurança de Dependência de SO | Como parte da etapa de construção de imagem, você deve usar algum scanner em seus contêineres em busca de vulnerabilidades. +Assinatura Imagem e Enforcement | Assinatura de imagens de contêineres para manter um sistema de confiança para o conteúdo de seus contêineres. +Proibir Usuários Privilegiados | Ao construir contêineres, consulte a documentação para criar usuários dentro dos contêineres que tenham o menor nível de privilégio no sistema operacional necessário para cumprir o objetivo do contêiner. +Use o Contêiner em Runtime com Isolamento mais Forte | Selecione [classes de contêiner runtime](/docs/concepts/containers/runtime-class/) com o provedor de isolamento mais forte. + +## Código + +O código da aplicação é uma das principais superfícies de ataque sobre a qual você tem maior controle. +Embora a proteção do código do aplicativo esteja fora do tópico de segurança do Kubernetes, aqui +são recomendações para proteger o código do aplicativo: + +### Segurança de código + +{{< table caption="Code security" >}} + +Área de Atenção para o Código | Recomendação | +-------------------------| -------------- | +Acesso só através de TLS | Se seu código precisar se comunicar por TCP, execute um handshake TLS com o cliente antecipadamente. Com exceção de alguns casos, encripte tudo em trânsito. Indo um passo adiante, é uma boa ideia encriptar o tráfego de rede entre os serviços. Isso pode ser feito por meio de um processo conhecido como mutual ou [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication), que realiza uma verificação bilateral da comunicação mediante os certificados nos serviços. | +Limitando intervalos de porta de comunicação | Essa recomendação pode ser um pouco autoexplicativa, mas, sempre que possível, você só deve expor as portas em seu serviço que são absolutamente essenciais para a comunicação ou coleta de métricas. | +Segurança na Dependência de Terceiros | É uma boa prática verificar regularmente as bibliotecas de terceiros de sua aplicação em busca de vulnerabilidades de segurança. Cada linguagem de programação possui uma ferramenta para realizar essa verificação automaticamente. | +Análise de Código Estático | A maioria das linguagens fornece uma maneira para analisar um extrato do código referente a quaisquer práticas de codificação potencialmente inseguras. Sempre que possível, você deve automatizar verificações usando ferramentas que podem verificar as bases de código em busca de erros de segurança comuns. Algumas das ferramentas podem ser encontradas em [OWASP Source Code Analysis Tools](https://owasp.org/www-community/Source_Code_Analysis_Tools). | +Ataques de sondagem dinâmica | Existem algumas ferramentas automatizadas que você pode executar contra seu serviço para tentar alguns dos ataques mais conhecidos. Isso inclui injeção de SQL, CSRF e XSS. Uma das ferramentas de análise dinâmica mais populares é o [OWASP Zed Attack proxy](https://owasp.org/www-project-zap/). | + +{{< /table >}} + +## {{% heading "whatsnext" %}} + +Saiba mais sobre os tópicos de segurança do Kubernetes: + +* [Padrões de segurança do Pod](/docs/concepts/security/pod-security-standards/) +* [Políticas de rede para Pods](/docs/concepts/services-networking/network-policies/) +* [Controle de acesso à API Kubernetes](/docs/concepts/security/controlling-access) +* [Protegendo seu cluster](/docs/tasks/administer-cluster/securing-a-cluster/) +* [Criptografia de dados em trânsito](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane +* [Criptografia de dados em repouso](/docs/tasks/administer-cluster/encrypt-data/) +* [Secrets no Kubernetes](/docs/concepts/configuration/secret/) +* [Runtime class](/docs/concepts/containers/runtime-class) \ No newline at end of file diff --git a/content/zh/blog/_posts/2020-12-02-dockershim-faq.md b/content/zh/blog/_posts/2020-12-02-dockershim-faq.md index b169eea610..8552f9fd48 100644 --- a/content/zh/blog/_posts/2020-12-02-dockershim-faq.md +++ b/content/zh/blog/_posts/2020-12-02-dockershim-faq.md @@ -3,7 +3,6 @@ layout: blog title: "弃用 Dockershim 的常见问题" date: 2020-12-02 slug: dockershim-faq -aliases: [ '/dockershim' ] --- 这是一个复杂的问题，依赖于许多因素。 在 Docker 工作良好的情况下，迁移到 containerd 是一个相对容易的转换，并将获得更好的性能和更少的开销。 -然而，我们建议你先探索 [CNCF 全景图](https://landscape.cncf.io/category=container-runtime&format=card-mode&grouping=category) +然而，我们建议你先探索 [CNCF 全景图](https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category) 提供的所有选项，以做出更适合你的环境的选择。 或者，你也可以通过 -`--runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=true` +`--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true` 启用 API 组的 v1alpha1 版本。 集群级日志架构需要一个独立的后端用来存储、分析和查询日志。 Kubernetes 并不为日志数据提供原生的存储解决方案。 -相反，有很多现成的日志方案可以集成到 Kubernetes 中. +相反，有很多现成的日志方案可以集成到 Kubernetes 中。 下面各节描述如何在节点上处理和存储日志。 -要进一步了解如何配置 fluentd，请参考 [fluentd 官方文档](https://docs.fluentd.org/). +要进一步了解如何配置 fluentd，请参考 [fluentd 官方文档](https://docs.fluentd.org/)。 {{< /note >}} @@ -82,9 +82,9 @@ Linux): Kubernetes 对所有网络设施的实施，都需要满足以下的基本要求（除非有设置一些特定的网络分段策略）： * 节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信 -* 节点上的代理（比如：系统守护进程、kubelet） 可以和节点上的所有Pod通信 +* 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有Pod通信 -备注：仅针对那些支持 `Pods` 在主机网络中运行的平台(比如：Linux) ： +备注：仅针对那些支持 `Pods` 在主机网络中运行的平台（比如：Linux）： * 那些运行在节点的主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信 @@ -107,7 +107,7 @@ usage, but this is no different from processes in a VM. This is called the Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。 这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达各个端口。 这也意味着 `Pod` 内的容器都需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同， -这也被称为“一个 Pod 一个 IP” 模型。 +这也被称为“一个 Pod 一个 IP”模型。 如何实现这一点是正在使用的容器运行时的特定信息。 -也可以在 `node` 本身通过端口去请求你的 `Pod` （称之为主机端口）， +也可以在 `node` 本身通过端口去请求你的 `Pod`（称之为主机端口）， 但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。 `Pod` 自己并不知道这些主机端口是否存在。 @@ -196,7 +196,7 @@ AOS 具有一组丰富的 REST API 端点，这些端点使 Kubernetes 能够根 从而为私有云和公共云提供端到端管理系统。 AOS 支持使用包括 Cisco、Arista、Dell、Mellanox、HPE 在内的制造商提供的通用供应商设备， -以及大量白盒系统和开放网络操作系统，例如 Microsoft SONiC、Dell OPX 和 Cumulus Linux 。 +以及大量白盒系统和开放网络操作系统，例如 Microsoft SONiC、Dell OPX 和 Cumulus Linux。 想要更详细地了解 AOS 系统是如何工作的可以点击这里：https://www.apstra.com/products/how-it-works/ @@ -218,10 +218,10 @@ AWS 虚拟私有云（VPC）网络。该 CNI 插件提供了高吞吐量和可 使用该 CNI 插件，可使 Kubernetes Pod 拥有与在 VPC 网络上相同的 IP 地址。 CNI 将 AWS 弹性网络接口（ENI）分配给每个 Kubernetes 节点，并将每个 ENI 的辅助 IP 范围用于该节点上的 Pod 。 -CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的启动时间，并且能够支持多达2000个节点的大型集群。 +CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的启动时间，并且能够支持多达 2000 个节点的大型集群。 此外，CNI 可以与 -[用于执行网络策略的 Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)一起运行。 +[用于执行网络策略的 Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html) 一起运行。 AWS VPC CNI 项目是开源的，请查看 [GitHub 上的文档](https://github.com/aws/amazon-vpc-cni-k8s)。 kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。 -命令行上的文件引用是相当对于当前工作目录的。 +命令行上的文件引用是相对于当前工作目录的。 在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。 ## {{% heading "whatsnext" %}} diff --git a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md index aa38076e44..1169ac9ecf 100644 --- a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md @@ -167,11 +167,11 @@ kind: ClusterServiceBroker metadata: name: cloud-broker spec: - # 指向服务代理的末端。(这里的 URL 是无法使用的) + # 指向服务代理的末端。(这里的 URL 是无法使用的。) url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default ##### # 这里可以添加额外的用来与服务代理通信的属性值, - # 例如持有者令牌信息或者 TLS 的 CA 包 + # 例如持有者令牌信息或者 TLS 的 CA 包。 ##### ``` diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md index 86d5ac24e7..9ea3577de8 100644 --- a/content/zh/docs/concepts/policy/pod-security-policy.md +++ b/content/zh/docs/concepts/policy/pod-security-policy.md @@ -253,7 +253,7 @@ paired with system groups to grant access to all pods run in the namespace: 可以考虑将这种授权模式和系统组结合，对名字空间中的所有 Pod 授予访问权限。 ```yaml -# 授权该某名字空间中所有服务账号 +# 授权某名字空间中所有服务账号 - kind: Group apiGroup: rbac.authorization.k8s.io name: system:serviceaccounts diff --git a/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md index d8659b4c9f..d5b7cdc5c3 100644 --- a/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -148,13 +148,13 @@ one of these at random. 最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。 如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。 - 支持以下两种方式配置调度器的过滤和打分行为： - -1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ +1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_ 和打分的 _优先级(Priorities)_ 。 2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件， 包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。 你也可以配置 kube-scheduler 运行不同的配置文件。 ## {{% heading "whatsnext" %}} - 节点亲和性（详见[这里](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)） @@ -140,7 +140,7 @@ This is a "preference" or "soft" version of `NoSchedule` - the system will *try* pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is `NoExecute`, described later. --> -上述例子使用到的 `effect` 的一个值 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。 +上述例子中 `effect` 使用的值为 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。 这是“优化”或“软”版本的 `NoSchedule` —— 系统会 *尽量* 避免将 Pod 调度到存在其不能容忍污点的节点上， 但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。 @@ -438,7 +438,7 @@ by the user already has a toleration for `node.kubernetes.io/unreachable`. {{< note >}} Kubernetes 会自动给 Pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的容忍度 -并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为 +并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为 `node.kubernetes.io/not-ready` 的容忍度。 同样，Kubernetes 会给 Pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的容忍度 @@ -517,5 +517,3 @@ arbitrary tolerations to DaemonSets. --> * 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为 * 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/) - - diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md index bf54a0f2d0..236c03f910 100644 --- a/content/zh/docs/concepts/services-networking/connect-applications-service.md +++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md @@ -363,7 +363,7 @@ You can acquire all these from the [nginx https example](https://github.com/kube * 使用证书配置的 Nginx 服务器 * 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/) -你可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/staging/https-nginx/) +你可以从 [Nginx https 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/) 获取所有上述内容。你需要安装 go 和 make 工具。如果你不想安装这些软件，可以按照 后文所述的手动执行步骤执行操作。简要过程如下： diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md index e79bf11dc1..06853f27b7 100644 --- a/content/zh/docs/concepts/workloads/controllers/job.md +++ b/content/zh/docs/concepts/workloads/controllers/job.md @@ -349,7 +349,7 @@ caused by previous runs. `.spec.template.spec.restartPolicy = "Never"`。 当 Pod 失败时，Job 控制器会启动一个新的 Pod。 这意味着，你的应用需要处理在一个新 Pod 中被重启的情况。 -尤其是应用需要处理之前运行所触碰或产生的临时文件、锁、不完整的输出等问题。 +尤其是应用需要处理之前运行所产生的临时文件、锁、不完整的输出等问题。 - -本页面将介绍定制 Hugo 短代码，可以用于 Kubernetes markdown 文档书写。 + +本页面将介绍 Hugo 自定义短代码，可以用于 Kubernetes Markdown 文档书写。 关于短代码的更多信息可参见 [Hugo 文档](https://gohugo.io/content-management/shortcodes)。 @@ -20,31 +20,31 @@ content_type: concept ## 功能状态 -在本站的 markdown 页面中，你可以加入短代码来展示所描述的功能特性的版本和状态。 +在本站的 Markdown 页面中，你可以加入短代码来展示所描述的功能特性的版本和状态。 ### 功能状态示例 -下面是一个功能状态代码段的演示，表明这个功能已经在 Kubernetes v1.10 时就已经稳定了。 +下面是一个功能状态代码段的演示，表明这个功能已经在最新版 Kubernetes 中稳定了。 ``` -{{}} +{{}} ``` - + 会转换为： -{{< feature-state for_k8s_version="v1.10" state="stable" >}} +{{< feature-state state="stable" >}} `state` 的可选值如下： @@ -57,91 +57,42 @@ in Kubernetes version 1.10. ### 功能状态代码 所显示的 Kubernetes 默认为该页或站点版本。 -可以通过修改 for_k8s_version 短代码参数来调整要显示的版本。 +修改 for_k8s_version 短代码参数可以调整要显示的版本。例如 ``` -{{}} +{{}} ``` 会转换为： -{{< feature-state for_k8s_version="v1.11" state="stable" >}} - - -#### Alpha 功能 - -``` -{{}} -``` - - -会转换为： - -{{< feature-state state="alpha" >}} - - -#### Beta 功能 - -``` -{{}} -``` - - -会转换为： - -{{< feature-state state="beta" >}} - - -#### 稳定功能 - -``` -{{}} -``` - - -会转换为： - -{{< feature-state state="stable" >}} - - -#### 废弃功能 - -``` -{{}} -``` - - -会转换为： - -{{< feature-state state="deprecated" >}} +{{< feature-state for_k8s_version="v1.10" state="beta" >}} ## 词汇 -有两种词汇表提示。 +有两种词汇表提示：`glossary_tooltip` 和 `glossary_definition`。 你可以通过加入术语词汇的短代码，来自动更新和替换相应链接中的内容 （[我们的词汇库](/zh/docs/reference/glossary/)） -这样，在浏览在线文档，鼠标移到术语上时，术语解释就会显示在提示框中。 +在浏览在线文档时，术语会显示为超链接的样式，当鼠标移到术语上时，其解释就会显示在提示框中。 除了包含工具提示外，你还可以重用页面内容中词汇表中的定义。 ### 词汇演示 -例如，下面的代码在 markdown 中将会转换为 `{{< glossary_tooltip text="cluster" term_id="cluster" >}}`， +例如，下面的代码在 Markdown 中将会转换为 `{{< glossary_tooltip text="cluster" term_id="cluster" >}}`， 然后在提示框中显示。 ``` @@ -191,7 +142,6 @@ You can also include a full definition: 呈现为： {{< glossary_definition term_id="cluster" length="all" >}} @@ -236,7 +186,7 @@ Parameter | Description | Default {{< /table >}} --> -​```go-html-template +```go-html-template {{}} 参数 | 描述 | 默认值 :---------|:------------|:------- @@ -278,7 +228,7 @@ The `tabs` shortcode takes these parameters: --> ## 标签页 -在本站的 markdown 页面（`.md` 文件）中，你可以加入一个标签页集来显示 +在本站的 Markdown 页面（`.md` 文件）中，你可以加入一个标签页集来显示 某解决方案的不同形式。 标签页的短代码包含以下参数： @@ -398,6 +348,120 @@ println "This is tab 2." {{< tab name="JSON File" include="podtemplate.json" />}} {{< /tabs >}} + +## 版本号信息 + +要在文档中生成版本号信息，可以从以下几种短代码中选择。每个短代码可以基于站点配置文件 +`config.toml` 中的版本参数生成一个版本号取值。最常用的参数为 `latest` 和 `version`。 + + +### `{{}}` + +`{{}}` 短代码可以基于站点参数 `version` 生成 Kubernetes +文档的当前版本号取值。短代码 `param` 允许传入一个站点参数名称，在这里是 `version`。 + + +{{< note >}} +在先前已经发布的文档中，`latest` 和 `version` 参数值并不完全等价。新版本文档发布后，参数 +`latest` 会增加，而 `version` 则保持不变。例如，在上一版本的文档中使用 `version` 会得到 +`v1.19`，而使用 `latest` 则会得到 `v1.20`。 +{{< /note >}} + + +转换为： + +{{< param "version" >}} + + +### `{{}}` + +`{{}}` 返回站点参数 `latest` 的取值。每当新版本文档发布时，该参数均会被更新。 +因此，参数 `latest` 与 `version` 并不总是相同。 + +转换为： + +{{< latest-version >}} + + +### `{{}}` + +`{{}}` 短代码可以生成站点参数 `latest` 不含前缀 `v` 的版本号取值。 + +转换为： + +{{< latest-semver >}} + + +### `{{}}` + +`{{}}` 会检查是否设置了页面参数 `min-kubernetes-server-version` +并将其与 `version` 进行比较。 + +转换为： + +{{< version-check >}} + + +### `{{}}` + +`{{}}` 短代码基于站点参数 `latest` 生成不含前缀 `v` +的版本号取值，并输出该版本更新日志的超链接地址。 + +转换为： + +{{< latest-release-notes >}} + ## {{% heading "whatsnext" %}} -* 了解 [Hugo](https://gohugo.io/)。 +* 了解[Hugo](https://gohugo.io/)。 * 了解[撰写新的话题](/zh/docs/contribute/style/write-new-topic/)。 * 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/)。 * 了解[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)。 * 了解[高级贡献](/zh/docs/contribute/advanced/)。 - diff --git a/content/zh/docs/reference/issues-security/issues.md b/content/zh/docs/reference/issues-security/issues.md index d2ac9ae7be..23a015a519 100644 --- a/content/zh/docs/reference/issues-security/issues.md +++ b/content/zh/docs/reference/issues-security/issues.md @@ -1,7 +1,6 @@ --- title: Kubernetes 问题追踪 weight: 10 -aliases: [cve/,cves/] --- {{< feature-state for_k8s_version="v1.19" state="beta" >}} - 你可以通过编写配置文件，并将其路径传给 `kube-scheduler` 的命令行参数，定制 `kube-scheduler` 的行为。 @@ -82,14 +82,14 @@ extension points: --> 1. `QueueSort`：这些插件对调度队列中的悬决的 Pod 排序。 一次只能启用一个队列排序插件。 - 2. `PreFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 它们可以将 Pod 标记为不可调度。 - @@ -127,13 +127,13 @@ extension points: least one bind plugin is required. --> 9. `Bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。 - 10. `PostBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。 - @@ -154,18 +154,18 @@ profiles: weight: 1 ``` - 你可以在 `disabled` 数组中使用 `*` 禁用该扩展点的所有默认插件。 如果需要，这个字段也可以用来对插件重新顺序。 - + ### 调度插件 {#scheduling-plugin} - @@ -190,7 +190,7 @@ extension points: - `SelectorSpread`：对于属于 {{< glossary_tooltip text="Services" term_id="service" >}}、 {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和 {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod，偏好跨多个节点部署。 - + 实现的扩展点：`PreScore`，`Score`。 - `ImageLocality`：选择已经存在 Pod 运行所需容器镜像的节点。 - + 实现的扩展点：`Score`。 - `TaintToleration`：实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 - + 实现的扩展点：`Filter`，`Prescore`，`Score`。 - `NodeName`：检查 Pod 指定的节点名称与当前节点是否匹配。 - + 实现的扩展点：`Filter`。 - `NodePorts`：检查 Pod 请求的端口在节点上是否可用。 - + 实现的扩展点：`PreFilter`，`Filter`。 -- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}} +- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}} `scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。 - + 实现的扩展点：`Score`。 - `NodeAffinity`：实现了[节点选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) 和[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)。 - + 实现的扩展点：`Filter`，`Score`. - `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。 - + 实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。 - `NodeUnschedulable`：过滤 `.spec.unschedulable` 值为 true 的节点。 - + 实现的扩展点：`Filter`。 - `NodeResourcesFit`：检查节点是否拥有 Pod 请求的所有资源。 - + 实现的扩展点：`PreFilter`，`Filter`。 - `NodeResourcesBalancedAllocation`：调度 Pod 时，选择资源使用更为均衡的节点。 - + 实现的扩展点：`Score`。 - `NodeResourcesLeastAllocated`：选择资源分配较少的节点。 - + 实现的扩展点：`Score`。 - `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的卷。 - + 实现的扩展点: `PreFilter`，`Filter`，`Reserve`，`PreBind`。 - - `VolumeRestrictions`：检查挂载到节点上的卷是否满足卷提供程序的限制。 - + 实现的扩展点：`Filter`。 - `VolumeZone`：检查请求的卷是否在任何区域都满足。 - + 实现的扩展点：`Filter`。 - - `NodeVolumeLimits`：检查该节点是否满足 CSI 卷限制。 - + 实现的扩展点：`Filter`。 - `EBSLimits`：检查节点是否满足 AWS EBS 卷限制。 - + 实现的扩展点：`Filter`。 - `GCEPDLimits`：检查该节点是否满足 GCP-PD 卷限制。 - + 实现的扩展点：`Filter`。 - `AzureDiskLimits`：检查该节点是否满足 Azure 卷限制。 - + 实现的扩展点：`Filter`。 - `InterPodAffinity`：实现 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。 - + 实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。 - `PrioritySort`：提供默认的基于优先级的排序。 - + 实现的扩展点：`QueueSort`。 - `DefaultBinder`：提供默认的绑定机制。 - + 实现的扩展点：`Bind`。 - `DefaultPreemption`：提供默认的抢占机制。 - + 实现的扩展点：`PostFilter`。 - `NodeResourcesMostAllocated`：选择已分配资源多的节点。 - + 实现的扩展点：`Score`。 - `RequestedToCapacityRatio`：根据已分配资源的某函数设置选择节点。 - + 实现的扩展点：`Score`。 - `NodeResourceLimits`：选择满足 Pod 资源限制的节点。 - + 实现的扩展点：`PreScore`，`Score`。 - `CinderVolume`：检查该节点是否满足 OpenStack Cinder 卷限制。 - + 实现的扩展点：`Filter`。 -- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}} +- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}} 过滤节点和/或给节点打分。 - + 实现的扩展点：`Filter`，`Score`。 @@ -462,14 +462,14 @@ profiles: Pods that want to be scheduled according to a specific profile can include the corresponding scheduler name in its `.spec.schedulerName`. --> -希望根据特定配置文件调度的 Pod，可以在 `.spec.schedulerName` 字段指定相应的调度器名称。 +对于那些希望根据特定配置文件来进行调度的 Pod，可以在 `.spec.schedulerName` 字段指定相应的调度器名称。 -默认情况下，将创建一个名为 `default-scheduler` 的配置文件。 +默认情况下，将创建一个调度器名为 `default-scheduler` 的配置文件。 这个配置文件包括上面描述的所有默认插件。 声明多个配置文件时，每个配置文件中调度器名称必须唯一。 @@ -478,8 +478,8 @@ If a Pod doesn't specify a scheduler name, kube-apiserver will set it to `default-scheduler`. Therefore, a profile with this scheduler name should exist to get those pods scheduled. --> -如果 Pod 未指定调度器名称，kube-apiserver 将会把它设置为 `default-scheduler`。 -因此，应该存在一个名为 `default-scheduler` 的配置文件来调度这些 Pod。 +如果 Pod 未指定调度器名称，kube-apiserver 将会把调度器名设置为 `default-scheduler`。 +因此，应该存在一个调度器名为 `default-scheduler` 的配置文件来调度这些 Pod。 {{< note >}} Pod 的调度事件把 `.spec.schedulerName` 字段值作为 ReportingController。 -领导者选择事件使用列表中第一个配置文件的调度器名称。 +领导者选举事件使用列表中第一个配置文件的调度器名称。 {{< /note >}} {{< note >}} @@ -498,7 +498,7 @@ the same configuration parameters (if applicable). This is because the scheduler only has one pending pods queue. --> 所有配置文件必须在 QueueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。 -这是因为调度器只有一个的队列保存悬决的 Pod。 +这是因为调度器只有一个保存 pending 状态 Pod 的队列。 {{< /note >}} @@ -509,4 +509,4 @@ only has one pending pods queue. * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) --> * 阅读 [kube-scheduler 参考](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) -* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) \ No newline at end of file +* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) diff --git a/content/zh/docs/reference/using-api/client-libraries.md b/content/zh/docs/reference/using-api/client-libraries.md index 599b1bf6df..cf01bcc56e 100644 --- a/content/zh/docs/reference/using-api/client-libraries.md +++ b/content/zh/docs/reference/using-api/client-libraries.md @@ -111,12 +111,13 @@ their authors, not the Kubernetes team. | Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | +| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | -| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | +| Scala | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | | Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | @@ -145,12 +146,13 @@ their authors, not the Kubernetes team. | Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | +| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | -| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | +| Scala | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | | Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) | | DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | diff --git a/content/zh/docs/tutorials/_index.md b/content/zh/docs/tutorials/_index.md index f283d60ea6..42415cafe2 100644 --- a/content/zh/docs/tutorials/_index.md +++ b/content/zh/docs/tutorials/_index.md @@ -62,13 +62,13 @@ Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成 * [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) -* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/) +* [Example: Deploying PHP Guestbook application with MongoDB](/docs/tutorials/stateless-application/guestbook/) --> ## 无状态应用程序 * [公开外部 IP 地址访问集群中的应用程序](/zh/docs/tutorials/stateless-application/expose-external-ip-address/) -* [示例：使用 Redis 部署 PHP 留言板应用程序](/zh/docs/tutorials/stateless-application/guestbook/) +* [示例：使用 MongoDB 部署 PHP 留言板应用程序](/zh/docs/tutorials/stateless-application/guestbook/) 为了完成本教程中的所有步骤，你必须安装 [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) -和 [kubectl](/zh/doc/tasks/tools/install-kubectl/)。本教程将显示同时具有 alpha（v1.19 之前的版本） +和 [kubectl](/zh/docs/tasks/tools/install-kubectl/)。本教程将显示同时具有 alpha（v1.19 之前的版本） 和通常可用的 seccomp 功能的示例，因此请确保为所使用的版本[正确配置](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)了集群。 diff --git a/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md index b6357ed284..b7c99d0e8e 100644 --- a/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md +++ b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md @@ -34,7 +34,7 @@ Dockerfile、kubernetes.yml、Kubernetes ConfigMaps、和 Kubernetes Secrets。 比如赋值给不同的容器中的不同环境变量。 @@ -90,4 +90,4 @@ CDI & MicroProfile 都会被用在互动教程中， ### [Start Interactive Tutorial](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) --> ## 示例：使用 MicroProfile、ConfigMaps、Secrets 实现外部化应用配置 -### [启动互动教程](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) +### [启动互动教程](/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) diff --git a/content/zh/docs/tutorials/services/source-ip.md b/content/zh/docs/tutorials/services/source-ip.md index bd0fdc9629..93c4711363 100644 --- a/content/zh/docs/tutorials/services/source-ip.md +++ b/content/zh/docs/tutorials/services/source-ip.md @@ -103,15 +103,23 @@ clusterip ClusterIP 10.0.170.92 80/TCP 51s 从相同集群中的一个 pod 访问这个 `ClusterIP`： -```console +```shell kubectl run busybox -it --image=busybox --restart=Never --rm ``` 输出结果与以下结果类似： ``` Waiting for pod default/busybox to be running, status is Pending, pod ready: false If you don't see a command prompt, try pressing enter. +``` -# ip addr +然后你可以在 Pod 内运行命令： + +```shell +# 在终端内使用"kubectl run"执行 + +ip addr +``` +``` 1: lo: mtu 65536 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo @@ -124,8 +132,15 @@ If you don't see a command prompt, try pressing enter. valid_lft forever preferred_lft forever inet6 fe80::188a:84ff:feb0:26a5/64 scope link valid_lft forever preferred_lft forever +``` -# wget -qO - 10.0.170.92 +然后使用 `wget` 去请求本地 Web 服务器 +```shell +# 用名为 "clusterip" 的服务的 IPv4 地址替换 "10.0.170.92" + +wget -qO - 10.0.170.92 +``` +``` CLIENT VALUES: client_address=10.244.3.8 command=GET @@ -178,17 +193,19 @@ client_address=10.240.0.3 用图表示： -``` - client - \ ^ - \ \ - v \ - node 1 <--- node 2 - | ^ SNAT - | | ---> - v | - endpoint -``` +{{< mermaid >}} +graph LR; + client(client)-->node2[节点 2]; + node2-->client; + node2-. SNAT .->node1[节点 1]; + node1-. SNAT .->node2; + node1-->endpoint(端点); + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{}} 为了防止这种情况发生，Kubernetes 提供了一个特性来保留客户端的源 IP 地址[(点击此处查看可用特性)](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)。设置 `service.spec.externalTrafficPolicy` 的值为 `Local`，请求就只会被代理到本地 endpoints 而不会被转发到其它节点。这样就保留了最初的源 IP 地址。如果没有本地 endpoints，发送到这个节点的数据包将会被丢弃。这样在应用到数据包的任何包处理规则下，你都能依赖这个正确的 source-ip 使数据包通过并到达 endpoint。 @@ -229,17 +246,18 @@ client_address=104.132.1.79 用图表示： -``` - client - ^ / \ - / / \ - / v X - node 1 node 2 - ^ | - | | - | v - endpoint -``` +{{< mermaid >}} +graph TD; + client --> node1[节点 1]; + client(client) --x node2[节点 2]; + node1 --> endpoint(端点); + endpoint --> node1; + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{}} @@ -285,17 +303,7 @@ client_address=10.240.0.5 用图表示： -``` - client - | - lb VIP - / ^ - v / -health check ---> node 1 node 2 <--- health check - 200 <--- ^ | ---> 500 - | V - endpoint -``` +![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg) 你可以设置 annotation 来进行测试： @@ -367,7 +375,7 @@ __跨平台支持__ 2. 使用一个包转发器，因此从客户端发送到负载均衡器 VIP 的请求在拥有客户端源 IP 地址的节点终止，而不被中间代理。 -第一类负载均衡器必须使用一种它和后端之间约定的协议来和真实的客户端 IP 通信，例如 HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 头，或者 [proxy 协议](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)。 +第一类负载均衡器必须使用一种它和后端之间约定的协议来和真实的客户端 IP 通信，例如 HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 头，或者 [proxy 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。 第二类负载均衡器可以通过简单的在保存于 Service 的 `service.spec.healthCheckNodePort` 字段上创建一个 HTTP 健康检查点来使用上面描述的特性。 @@ -394,6 +402,4 @@ $ kubectl delete deployment source-ip-app ## {{% heading "whatsnext" %}} -* 学习更多关于 [通过 services 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/) -* 学习更多关于 [负载均衡](/zh/docs/user-guide/load-balancer) - +* 进一步学习 [通过 services 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md deleted file mode 100644 index fb264dbeba..0000000000 --- a/content/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ /dev/null @@ -1,723 +0,0 @@ ---- -title: "示例: 添加日志和指标到 PHP / Redis Guestbook 案例" -content_type: tutorial -weight: 21 -card: - name: tutorials - weight: 31 - title: "示例: 添加日志和指标到 PHP / Redis Guestbook 案例" ---- - - - - -本教程建立在 -[使用 Redis 部署 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook) 教程之上。 -*Beats*，是 Elastic 出品的开源的轻量级日志、指标和网络数据采集器， -将和 Guestbook 一同部署在 Kubernetes 集群中。 -Beats 收集、分析、索引数据到 Elasticsearch，使你可以用 Kibana 查看并分析得到的运营信息。 -本示例由以下内容组成： -* [带 Redis 的 PHP Guestbook 教程](/zh/docs/tutorials/stateless-application/guestbook) - 的一个实例部署 -* Elasticsearch 和 Kibana -* Filebeat -* Metricbeat -* Packetbeat - -## {{% heading "objectives" %}} - - -* 启动用 Redis 部署的 PHP Guestbook。 -* 安装 kube-state-metrics。 -* 创建 Kubernetes secret。 -* 部署 Beats。 -* 用仪表板查看日志和指标。 - -## {{% heading "prerequisites" %}} - - -{{< include "task-tutorial-prereqs.md" >}} -{{< version-check >}} - - -此外，你还需要: - -* 依照教程[使用 Redis 的 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook)得到的一套运行中的部署环境。 -* 一套运行中的 Elasticsearch 和 Kibana 部署环境。你可以使用 [Elastic 云中的Elasticsearch 服务](https://cloud.elastic.co)、在工作站或者服务器上运行此[下载文件](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)、或运行 [Elastic Helm Charts](https://github.com/elastic/helm-charts)。 - - - - -## 启动用 Redis 部署的 PHP Guestbook {#start-up-the-php-guestbook-with-redis} - -本教程建立在 -[使用 Redis 部署 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook) 之上。 -如果你已经有一个运行的 Guestbook 应用程序，那就监控它。 -如果还没有，那就按照说明先部署 Guestbook ，但不要执行**清理**的步骤。 -当 Guestbook 运行起来后，再返回本页。 - - -## 添加一个集群角色绑定 {#add-a-cluster-role-binding} - -创建一个[集群范围的角色绑定](/zh/docs/reference/access-authn-authz/rbac/#rolebinding-和-clusterrolebinding)， -以便你可以在集群范围（在 kube-system 中）部署 kube-state-metrics 和 Beats。 - -```shell -kubectl create clusterrolebinding cluster-admin-binding \ - --clusterrole=cluster-admin --user= -``` - - -### 安装 kube-state-metrics {#install-kube-state-metrics} - -Kubernetes [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics) -是一个简单的服务，它侦听 Kubernetes API 服务器并生成对象状态的指标。 -Metricbeat 报告这些指标。 -添加 kube-state-metrics 到运行 Guestbook 的 Kubernetes 集群。 - -```shell -git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics -kubectl apply -f kube-state-metrics/examples/standard -``` - - -### 检查 kube-state-metrics 是否正在运行 {#check-to-see-if-kube-state-metrics-is-running} - -```shell -kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics -``` - - -输出： - -``` -NAME READY STATUS RESTARTS AGE -kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s -``` - - -## 从 GitHub 克隆 Elastic examples 库 {#clone-the-elastic-examples-github-repo} - -```shell -git clone https://github.com/elastic/examples.git -``` - - -后续命令将引用目录 `examples/beats-k8s-send-anywhere` 中的文件， -所以把目录切换过去。 - -```shell -cd examples/beats-k8s-send-anywhere -``` - - -## 创建 Kubernetes Secret {#create-a-kubernetes-secret} - -Kubernetes {{< glossary_tooltip text="Secret" term_id="secret" >}} -是包含少量敏感数据（类似密码、令牌、秘钥等）的对象。 -这类信息也可以放在 Pod 规格定义或者镜像中； -但放在 Secret 对象中，能更好的控制它的使用方式，也能减少意外泄露的风险。 - -{{< note >}} -这里有两套步骤，一套用于*自管理*的 Elasticsearch 和 Kibana（运行在你的服务器上或使用 Helm Charts）， -另一套用于在 Elastic 云服务中 *Managed service* 的 Elasticsearch 服务。 -在本教程中，只需要为 Elasticsearch 和 Kibana 系统创建 secret。 -{{< /note >}} - -{{< tabs name="tab_with_md" >}} -{{% tab name="自管理" %}} - - -### 自管理系统 {#self-managed} - -如果你使用 Elastic 云中的 Elasticsearch 服务，切换到 **Managed service** 标签页。 - -### 设置凭据 {#set-the-credentials} - -当你使用自管理的 Elasticsearch 和 Kibana （对比托管于 Elastic 云中的 Elasticsearch 服务，自管理更有效率）， -创建 k8s secret 需要准备四个文件。这些文件是： - -1. `ELASTICSEARCH_HOSTS` -1. `ELASTICSEARCH_PASSWORD` -1. `ELASTICSEARCH_USERNAME` -1. `KIBANA_HOST` - - -为你的 Elasticsearch 集群和 Kibana 主机设置这些信息。这里是一些例子 -（另见[*此配置*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)） - -#### `ELASTICSEARCH_HOSTS` {#elasticsearch-hosts} - - -1. 来自于 Elastic Elasticsearch Helm Chart 的节点组： - - ``` - ["http://elasticsearch-master.default.svc.cluster.local:9200"] - ``` - - -1. Mac 上的单节点的 Elasticsearch，Beats 运行在 Mac 的容器中： - - ``` - ["http://host.docker.internal:9200"] - ``` - - -1. 运行在虚拟机或物理机上的两个 Elasticsearch 节点 - - ``` - ["http://host1.example.com:9200", "http://host2.example.com:9200"] - ``` - - -编辑 `ELASTICSEARCH_HOSTS` -```shell -vi ELASTICSEARCH_HOSTS -``` - -#### `ELASTICSEARCH_PASSWORD` {#elasticsearch-password} - - -只有密码；没有空格、引号、< 和 >： - -``` - -``` - - -编辑 `ELASTICSEARCH_PASSWORD`： - -```shell -vi ELASTICSEARCH_PASSWORD -``` - -#### `ELASTICSEARCH_USERNAME` {#elasticsearch-username} - - -只有用名；没有空格、引号、< 和 >： - - -``` -<为 Elasticsearch 注入的用户名> -``` - - -编辑 `ELASTICSEARCH_USERNAME`： - -```shell -vi ELASTICSEARCH_USERNAME -``` - -#### `KIBANA_HOST` {#kibana-host} - - -1. 从 Elastic Kibana Helm Chart 安装的 Kibana 实例。子域 `default` 指默认的命名空间。如果你把 Helm Chart 指定部署到不同的命名空间，那子域会不同： - - ``` - "kibana-kibana.default.svc.cluster.local:5601" - ``` - - -1. Mac 上的 Kibana 实例，Beats 运行于 Mac 的容器： - - ``` - "host.docker.internal:5601" - ``` - - -1. 运行于虚拟机或物理机上的两个 Elasticsearch 节点： - - ``` - "host1.example.com:5601" - ``` - - -编辑 `KIBANA_HOST`： - -```shell -vi KIBANA_HOST -``` - - -### 创建 Kubernetes secret {#create-a-kubernetes-secret} - -在上面编辑完的文件的基础上，本命令在 Kubernetes 系统范围的命名空间（kube-system）创建一个 secret。 - -``` - kubectl create secret generic dynamic-logging \ - --from-file=./ELASTICSEARCH_HOSTS \ - --from-file=./ELASTICSEARCH_PASSWORD \ - --from-file=./ELASTICSEARCH_USERNAME \ - --from-file=./KIBANA_HOST \ - --namespace=kube-system -``` - -{{% /tab %}} -{{% tab name="Managed service" %}} - - -## Managed service {#managed-service} - -本标签页只用于 Elastic 云 的 Elasticsearch 服务，如果你已经为自管理的 Elasticsearch 和 Kibana 创建了secret，请继续[部署 Beats](#deploy-the-beats)并继续。 - -### 设置凭据 {#set-the-credentials} - -在 Elastic 云中的托管 Elasticsearch 服务中，为了创建 k8s secret，你需要先编辑两个文件。它们是： - -1. `ELASTIC_CLOUD_AUTH` -1. `ELASTIC_CLOUD_ID` - - -当你完成部署的时候，Elasticsearch 服务控制台会提供给你一些信息，用这些信息完成设置。 -这里是一些示例： - -#### ELASTIC_CLOUD_ID {#elastic-cloud-id} - -``` -devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ== -``` - -#### ELASTIC_CLOUD_AUTH {#elastic-cloud-auth} - - -只要用户名；没有空格、引号、< 和 >： - -``` -elastic:VFxJJf9Tjwer90wnfTghsn8w -``` - - -### 编辑要求的文件 {#edit-the-required-files} -```shell -vi ELASTIC_CLOUD_ID -vi ELASTIC_CLOUD_AUTH -``` - - -### 创建 Kubernetes secret {#create-a-kubernetes-secret} - -基于上面刚编辑过的文件，在 Kubernetes 系统范围命名空间（kube-system）中，用下面命令创建一个的secret： - - kubectl create secret generic dynamic-logging \ - --from-file=./ELASTIC_CLOUD_ID \ - --from-file=./ELASTIC_CLOUD_AUTH \ - --namespace=kube-system - - {{% /tab %}} -{{< /tabs >}} - - -## 部署 Beats {#deploy-the-beats} - -为每一个 Beat 提供 清单文件。清单文件使用已创建的 secret 接入 Elasticsearch 和 Kibana 服务器。 - -### 关于 Filebeat {#about-filebeat} - -Filebeat 收集日志，日志来源于 Kubernetes 节点以及这些节点上每一个 Pod 中的容器。Filebeat 部署为 -{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}。 -Filebeat 支持自动发现 Kubernetes 集群中的应用。 -在启动时，Filebeat 扫描存量的容器，并为它们提供适当的配置， -然后开始监听新的启动/中止信号。 - -下面是一个自动发现的配置，它支持 Filebeat 定位并分析来自于 Guestbook 应用部署的 Redis 容器的日志文件。 -下面的配置片段来自文件 `filebeat-kubernetes.yaml`： - -```yaml -- condition.contains: - kubernetes.labels.app: redis - config: - - module: redis - log: - input: - type: docker - containers.ids: - - ${data.kubernetes.container.id} - slowlog: - enabled: true - var.hosts: ["${data.host}:${data.port}"] -``` - - - -这样配置 Filebeat，当探测到容器拥有 `app` 标签，且值为 `redis`，那就启用 Filebeat 的 `redis` 模块。 -`redis` 模块可以根据 docker 的输入类型（在 Kubernetes 节点上读取和 Redis 容器的标准输出流关联的文件） ，从容器收集 `log` 流。 -另外，此模块还可以使用容器元数据中提供的配置信息，连到 Pod 适当的主机和端口，收集 Redis 的 `slowlog` 。 - -### 部署 Filebeat {#deploy-filebeat} - -```shell -kubectl create -f filebeat-kubernetes.yaml -``` - - -#### 验证 {#verify} - -```shell -kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic -``` - - -### 关于 Metricbeat {#about-metricbeat} - -Metricbeat 自动发现的配置方式与 Filebeat 完全相同。 -这里是针对 Redis 容器的 Metricbeat 自动发现配置。 -此配置片段来自于文件 `metricbeat-kubernetes.yaml`： - -```yaml -- condition.equals: - kubernetes.labels.tier: backend - config: - - module: redis - metricsets: ["info", "keyspace"] - period: 10s - - # Redis hosts - hosts: ["${data.host}:${data.port}"] -``` - -配置 Metricbeat，在探测到标签 `tier` 的值等于 `backend` 时，应用 Metricbeat 模块 `redis`。 -`redis` 模块可以获取容器元数据，连接到 Pod 适当的主机和端口，从 Pod 中收集指标 `info` 和 `keyspace`。 - -### 部署 Metricbeat {#deploy-metricbeat} - -```shell -kubectl create -f metricbeat-kubernetes.yaml -``` - - -#### 验证 {#verify2} - -```shell -kubectl get pods -n kube-system -l k8s-app=metricbeat -``` - - -### 关于 Packetbeat {#about-packetbeat} - -Packetbeat 的配置方式不同于 Filebeat 和 Metricbeat。 -相比于匹配容器标签的模式，它的配置基于相关协议和端口号。 -下面展示的是端口号的一个子集： - -{{< note >}} -如果你的服务运行在非标准的端口上，那就打开文件 `filebeat.yaml`，把这个端口号添加到合适的类型中，然后删除/启动 Packetbeat 的守护进程。 -{{< /note >}} - -```yaml -packetbeat.interfaces.device: any - -packetbeat.protocols: -- type: dns - ports: [53] - include_authorities: true - include_additionals: true - -- type: http - ports: [80, 8000, 8080, 9200] - -- type: mysql - ports: [3306] - -- type: redis - ports: [6379] - -packetbeat.flows: - timeout: 30s - period: 10s -``` - - -### 部署 Packetbeat {#deploy-packetbeat} - -```shell -kubectl create -f packetbeat-kubernetes.yaml -``` - - -#### 验证 {#verify3} - -```shell -kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic -``` - - -## 在 kibana 中浏览 {#view-in-kibana} - -在浏览器中打开 kibana，再打开 **Dashboard**。 -在搜索栏中键入 Kubernetes，再点击 Metricbeat 的 Kubernetes Dashboard。 -此 Dashboard 展示节点状态、应用部署等。 - -在 Dashboard 页面，搜索 Packetbeat，并浏览 Packetbeat 概览信息。 - -同样地，浏览 Apache 和 Redis 的 Dashboard。 -可以看到日志和指标各自独立 Dashboard。 -Apache Metricbeat Dashboard 是空的。 -找到 Apache Filebeat Dashboard，拉到最下面，查看 Apache 的错误日志。 -日志会揭示出没有 Apache 指标的原因。 - -要让 metricbeat 得到 Apache 的指标，需要添加一个包含模块状态配置文件的 ConfigMap，并重新部署 Guestbook。 - -## 缩放部署规模，查看新 Pod 已被监控 {#scale-your-deployments-and-see-new-pods-being-monitored} - -列出现有的 deployments： - -```shell -kubectl get deployments -``` - - -输出： - -``` -NAME READY UP-TO-DATE AVAILABLE AGE -frontend 3/3 3 3 3h27m -redis-master 1/1 1 1 3h27m -redis-slave 2/2 2 2 3h27m -``` - - -缩放前端到两个 Pod： - -```shell -kubectl scale --replicas=2 deployment/frontend -``` - - -输出： - -``` -deployment.extensions/frontend scaled -``` - - -将前端应用缩放回三个 Pod： - -```shell -kubectl scale --replicas=3 deployment/frontend -``` - - -## 在 Kibana 中查看变化 {#view-the-chagnes-in-kibana} - -参见屏幕截图，添加指定的过滤器，然后将列添加到视图。 -你可以看到，ScalingReplicaSet 被做了标记，从标记的点开始，到消息列表的顶部，展示了拉取的镜像、挂载的卷、启动的 Pod 等。 -![Kibana 发现](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png) - -## {{% heading "cleanup" %}} - - -删除 Deployments 和 Services， 删除运行的 Pod。 -用标签功能在一个命令中删除多个资源。 - -1. 执行下列命令，删除所有的 Pod、Deployment 和 Services。 - - ```shell - kubectl delete deployment -l app=redis - kubectl delete service -l app=redis - kubectl delete deployment -l app=guestbook - kubectl delete service -l app=guestbook - kubectl delete -f filebeat-kubernetes.yaml - kubectl delete -f metricbeat-kubernetes.yaml - kubectl delete -f packetbeat-kubernetes.yaml - kubectl delete secret dynamic-logging -n kube-system - ``` - -2. 查询 Pod，以核实没有 Pod 还在运行： - - ```shell - kubectl get pods - ``` - - - 响应应该是这样： - - ``` - No resources found. - ``` - - -## {{% heading "whatsnext" %}} - - -* 了解[监控资源的工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/) -* 进一步阅读[日志体系架构](/zh/docs/concepts/cluster-administration/logging/) -* 进一步阅读[应用内省和调试](/zh/docs/tasks/debug-application-cluster/) -* 进一步阅读[应用程序的故障排除](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/) diff --git a/content/zh/docs/tutorials/stateless-application/guestbook.md b/content/zh/docs/tutorials/stateless-application/guestbook.md index 0343c58f44..b7ef978490 100644 --- a/content/zh/docs/tutorials/stateless-application/guestbook.md +++ b/content/zh/docs/tutorials/stateless-application/guestbook.md @@ -1,15 +1,16 @@ --- -title: "示例：使用 Redis 部署 PHP 留言板应用程序" +title: "示例：使用 MongoDB 部署 PHP 留言板应用程序" content_type: tutorial weight: 20 card: name: tutorials weight: 30 - title: "无状态应用示例：基于 Redis 的 PHP Guestbook" + title: "无状态应用示例：基于 MongoDB 的 PHP Guestbook" +min-kubernetes-server-version: v1.14 --- 本教程向您展示如何使用 Kubernetes 和 [Docker](https://www.docker.com/) 构建和部署 -一个简单的多层 web 应用程序。本例由以下组件组成： +一个简单的_(非面向生产)的_多层 web 应用程序。本例由以下组件组成： -* 单实例 [Redis](https://redis.io/) 主节点保存留言板条目 -* 多个[从 Redis](https://redis.io/topics/replication) 节点用来读取数据 +* 单实例 [MongoDB](https://www.mongodb.com/) 以保存留言板条目 * 多个 web 前端实例 @@ -45,15 +45,13 @@ This tutorial shows you how to build and deploy a simple, multi-tier web applica -* 启动 Redis 主节点。 -* 启动 Redis 从节点。 +* 启动 Mongo 数据库。 * 启动留言板前端。 * 公开并查看前端服务。 * 清理。 @@ -72,44 +70,50 @@ This tutorial shows you how to build and deploy a simple, multi-tier web applica -## 启动 Redis 主节点 +## 启动 Mongo 数据库 -留言板应用程序使用 Redis 存储数据。它将数据写入一个 Redis 主实例，并从多个 Redis 读取数据。 +留言板应用程序使用 MongoDB 存储数据。 -### 创建 Redis 主节点的 Deployment +### 创建 Mongo 的 Deployment -下面包含的清单文件指定了一个 Deployment 控制器，该控制器运行一个 Redis 主节点 Pod 副本。 +下面包含的清单文件指定了一个 Deployment 控制器，该控制器运行一个 MongoDB Pod 副本。 -{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} +{{< codenew file="application/guestbook/mongo-deployment.yaml" >}} 1. 在下载清单文件的目录中启动终端窗口。 -2. 从 `redis-master-deployment.yaml` 文件中应用 Redis 主 Deployment： +2. 从 `mongo-deployment.yaml` 文件中应用 MongoDB Deployment： ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml + kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml ``` - -3. 查询 Pod 列表以验证 Redis 主节点 Pod 是否正在运行： + + + +3. 查询 Pod 列表以验证 MongoDB Pod 是否正在运行： ```shell kubectl get pods @@ -122,53 +126,49 @@ The manifest file, included below, specifies a Deployment controller that runs a ```shell NAME READY STATUS RESTARTS AGE - redis-master-1068406935-3lswp 1/1 Running 0 28s + mongo-5cfd459dd4-lrcjb 1/1 Running 0 28s ``` -4. 运行以下命令查看 Redis 主节点 Pod 中的日志： +4. 运行以下命令查看 MongoDB Deployment 中的日志： ```shell - kubectl logs -f POD-NAME + kubectl logs -f deployment/mongo ``` -{{< note >}} - -将 POD-NAME 替换为您的 Pod 名称。 - -{{< /note >}} - - -### 创建 Redis 主节点的服务 +### 创建 MongoDB 服务 -留言板应用程序需要往 Redis 主节点中写数据。因此，需要创建 [Service](/zh/docs/concepts/services-networking/service/) 来代理 Redis 主节点 Pod 的流量。Service 定义了访问 Pod 的策略。 +留言板应用程序需要往 MongoDB 中写数据。因此，需要创建 [Service](/zh/docs/concepts/services-networking/service/) 来代理 MongoDB Pod 的流量。Service 定义了访问 Pod 的策略。 -{{< codenew file="application/guestbook/redis-master-service.yaml" >}} +{{< codenew file="application/guestbook/mongo-service.yaml" >}} -1. 使用下面的 `redis-master-service.yaml` 文件创建 Redis 主节点的服务： +1. 使用下面的 `mongo-service.yaml` 文件创建 MongoDB 的服务： ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml + kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml ``` - -2. 查询服务列表验证 Redis 主节点服务是否正在运行： + + +2. 查询服务列表验证 MongoDB 服务是否正在运行： ```shell kubectl get service @@ -182,134 +182,26 @@ The guestbook application needs to communicate to the Redis master to write its ```shell NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.0.0.1 443/TCP 1m - redis-master ClusterIP 10.0.0.151 6379/TCP 8s + mongo ClusterIP 10.0.0.151 6379/TCP 8s ``` + {{< note >}} - - -这个清单文件创建了一个名为 `Redis-master` 的 Service，其中包含一组与前面定义的标签匹配的标签，因此服务将网络流量路由到 Redis 主节点 Pod 上。 - +这个清单文件创建了一个名为 `mongo` 的 Service，其中包含一组与前面定义的标签匹配的标签，因此服务将网络流量路由到 MongoDB Pod 上。 {{< /note >}} - - -## 启动 Redis 从节点 - - -尽管 Redis 主节点是一个单独的 pod，但是您可以通过添加 Redis 从节点的方式来使其高可用性，以满足流量需求。 - - - -### 创建 Redis 从节点 Deployment - - -Deployments 根据清单文件中设置的配置进行伸缩。在这种情况下，Deployment 对象指定两个副本。 - - -如果没有任何副本正在运行，则此 Deployment 将启动容器集群上的两个副本。相反， -如果有两个以上的副本在运行，那么它的规模就会缩小，直到运行两个副本为止。 - -{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}} - - -1. 从 `redis-slave-deployment.yaml` 文件中应用 Redis Slave Deployment： - - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml - ``` - - -2. 查询 Pod 列表以验证 Redis Slave Pod 正在运行： - - ```shell - kubectl get pods - ``` - - - 响应应该与此类似： - - ```shell - NAME READY STATUS RESTARTS AGE - redis-master-1068406935-3lswp 1/1 Running 0 1m - redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s - redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s - ``` - - - -### 创建 Redis 从节点的 Service - - -留言板应用程序需要从 Redis 从节点中读取数据。 -为了便于 Redis 从节点可发现， -您需要设置一个 Service。Service 为一组 Pod 提供负载均衡。 - -{{< codenew file="application/guestbook/redis-slave-service.yaml" >}} - - -1. 从以下 `redis-slave-service.yaml` 文件应用 Redis Slave 服务： - - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml - ``` - - -2. 查询服务列表以验证 Redis 在服务是否正在运行： - - ```shell - kubectl get services - ``` - - - 响应应该与此类似： - - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.0.0.1 443/TCP 2m - redis-master ClusterIP 10.0.0.151 6379/TCP 1m - redis-slave ClusterIP 10.0.0.223 6379/TCP 6s - ``` - - ## 设置并公开留言板前端 - + 留言板应用程序有一个 web 前端，服务于用 PHP 编写的 HTTP 请求。 -它被配置为连接到写请求的 `redis-master` 服务和读请求的 `redis-slave` 服务。 +它被配置为连接到 `mongo` 服务以存储留言版条目。 + 2. 查询 Pod 列表，验证三个前端副本是否正在运行： ```shell - kubectl get pods -l app=guestbook -l tier=frontend + kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend ``` -应用的 `redis-slave` 和 `redis-master` 服务只能在容器集群中访问，因为服务的默认类型是 -[ClusterIP](/zh/docs/concepts/Services-networking/Service/#publishingservices-Service-types)。`ClusterIP` 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。 +应用的 `mongo` 服务只能在 Kubernetes 集群中访问，因为服务的默认类型是 +[ClusterIP](/zh/docs/concepts/services-networking/service/#publishing-services---service-types)。`ClusterIP` 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。 -如果您希望客人能够访问您的留言板，您必须将前端服务配置为外部可见的，以便客户机可以从容器集群之外请求服务。Minikube 只能通过 `NodePort` 公开服务。 +如果您希望访客能够访问您的留言板，您必须将前端服务配置为外部可见的，以便客户端可以从 Kubernetes 集群之外请求服务。然而即便使用了 `ClusterIP` Kubernets 用户仍可以通过 `kubectl port-forwart` 访问服务。 + {{< note >}} - - 一些云提供商，如 Google Compute Engine 或 Google Kubernetes Engine，支持外部负载均衡器。如果您的云提供商支持负载均衡器，并且您希望使用它， -只需删除或注释掉 `type: NodePort`，并取消注释 `type: LoadBalancer` 即可。 - +只需取消注释 `type: LoadBalancer` 即可。 {{< /note >}} {{< codenew file="application/guestbook/frontend-service.yaml" >}} @@ -387,6 +282,11 @@ Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, su kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml ``` + + @@ -403,30 +303,24 @@ Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, su ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - frontend NodePort 10.0.0.112 80:31323/TCP 6s + frontend ClusterIP 10.0.0.112 80/TCP 6s kubernetes ClusterIP 10.0.0.1 443/TCP 4m - redis-master ClusterIP 10.0.0.151 6379/TCP 2m - redis-slave ClusterIP 10.0.0.223 6379/TCP 1m + mongo ClusterIP 10.0.0.151 6379/TCP 2m ``` -### 通过 `NodePort` 查看前端服务 +### 通过 `kubectl port-forward` 查看前端服务 -如果您将此应用程序部署到 Minikube 或本地集群，您需要找到 IP 地址来查看您的留言板。 - - -1. 运行以下命令获取前端服务的 IP 地址。 +1. 运行以下命令将本机的 `8080` 端口转发到服务的 `80` 端口。 ```shell - minikube service frontend --url + kubectl port-forward svc/frontend 8080:80 ``` -2. 复制 IP 地址，然后在浏览器中加载页面以查看留言板。 +2. 在浏览器中加载 [http://localhost:8080](http://localhost:8080) 页面以查看留言板。 -5. 运行以下命令以删除所有 Pod，Deployments 和 Services。 +1. 运行以下命令以删除所有 Pod，Deployments 和 Services。 ```shell - kubectl delete deployment -l app=redis - kubectl delete service -l app=redis - kubectl delete deployment -l app=guestbook - kubectl delete service -l app=guestbook + kubectl delete deployment -l app.kubernetes.io/name=mongo + kubectl delete service -l app.kubernetes.io/name=mongo + kubectl delete deployment -l app.kubernetes.io/name=guestbook + kubectl delete service -l app.kubernetes.io/name=guestbook ``` -6. 查询 Pod 列表，确认没有 Pod 在运行： +2. 查询 Pod 列表，确认没有 Pod 在运行： ```shell kubectl get pods @@ -616,15 +505,12 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels -* 为 Guestbook 应用添加 - [ELK 日志与监控](/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/) * 完成 [Kubernetes Basics](/zh/docs/tutorials/kubernetes-basics/) 交互式教程 * 使用 Kubernetes 创建一个博客，使用 [MySQL 和 Wordpress 的持久卷](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) * 阅读更多关于[连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh/examples/application/guestbook/frontend-deployment.yaml b/content/zh/examples/application/guestbook/frontend-deployment.yaml index 23d64be644..613c654aa9 100644 --- a/content/zh/examples/application/guestbook/frontend-deployment.yaml +++ b/content/zh/examples/application/guestbook/frontend-deployment.yaml @@ -3,22 +3,24 @@ kind: Deployment metadata: name: frontend labels: - app: guestbook + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend spec: selector: matchLabels: - app: guestbook - tier: frontend + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend replicas: 3 template: metadata: labels: - app: guestbook - tier: frontend + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend spec: containers: - - name: php-redis - image: gcr.io/google-samples/gb-frontend:v4 + - name: guestbook + image: paulczar/gb-frontend:v5 + # image: gcr.io/google-samples/gb-frontend:v4 resources: requests: cpu: 100m @@ -26,13 +28,5 @@ spec: env: - name: GET_HOSTS_FROM value: dns - # Using `GET_HOSTS_FROM=dns` requires your cluster to - # provide a dns service. As of Kubernetes 1.3, DNS is a built-in - # service launched automatically. However, if the cluster you are using - # does not have a built-in DNS service, you can instead - # access an environment variable to find the master - # service's host. To do so, comment out the 'value: dns' line above, and - # uncomment the line below: - # value: env ports: - containerPort: 80 diff --git a/content/zh/examples/application/guestbook/frontend-service.yaml b/content/zh/examples/application/guestbook/frontend-service.yaml index 6f283f347b..34ad3771d7 100644 --- a/content/zh/examples/application/guestbook/frontend-service.yaml +++ b/content/zh/examples/application/guestbook/frontend-service.yaml @@ -3,16 +3,14 @@ kind: Service metadata: name: frontend labels: - app: guestbook - tier: frontend + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend spec: - # comment or delete the following line if you want to use a LoadBalancer - type: NodePort # if your cluster supports it, uncomment the following to automatically create # an external load-balanced IP for the frontend service. # type: LoadBalancer ports: - port: 80 selector: - app: guestbook - tier: frontend + app.kubernetes.io/name: guestbook + app.kubernetes.io/component: frontend diff --git a/content/zh/examples/application/guestbook/mongo-deployment.yaml b/content/zh/examples/application/guestbook/mongo-deployment.yaml new file mode 100644 index 0000000000..04908ce25b --- /dev/null +++ b/content/zh/examples/application/guestbook/mongo-deployment.yaml @@ -0,0 +1,31 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + selector: + matchLabels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + replicas: 1 + template: + metadata: + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + spec: + containers: + - name: mongo + image: mongo:4.2 + args: + - --bind_ip + - 0.0.0.0 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 27017 diff --git a/content/zh/examples/application/guestbook/mongo-service.yaml b/content/zh/examples/application/guestbook/mongo-service.yaml new file mode 100644 index 0000000000..b9cef607bc --- /dev/null +++ b/content/zh/examples/application/guestbook/mongo-service.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Service +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + ports: + - port: 27017 + targetPort: 27017 + selector: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend diff --git a/content/zh/examples/application/guestbook/redis-master-deployment.yaml b/content/zh/examples/application/guestbook/redis-master-deployment.yaml deleted file mode 100644 index 478216d1ac..0000000000 --- a/content/zh/examples/application/guestbook/redis-master-deployment.yaml +++ /dev/null @@ -1,29 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: redis-master - labels: - app: redis -spec: - selector: - matchLabels: - app: redis - role: master - tier: backend - replicas: 1 - template: - metadata: - labels: - app: redis - role: master - tier: backend - spec: - containers: - - name: master - image: k8s.gcr.io/redis:e2e # or just image: redis - resources: - requests: - cpu: 100m - memory: 100Mi - ports: - - containerPort: 6379 diff --git a/content/zh/examples/application/guestbook/redis-master-service.yaml b/content/zh/examples/application/guestbook/redis-master-service.yaml deleted file mode 100644 index a484014f1f..0000000000 --- a/content/zh/examples/application/guestbook/redis-master-service.yaml +++ /dev/null @@ -1,16 +0,0 @@ -apiVersion: v1 -kind: Service -metadata: - name: redis-master - labels: - app: redis - role: master - tier: backend -spec: - ports: - - port: 6379 - targetPort: 6379 - selector: - app: redis - role: master - tier: backend diff --git a/content/zh/examples/application/guestbook/redis-slave-deployment.yaml b/content/zh/examples/application/guestbook/redis-slave-deployment.yaml deleted file mode 100644 index 1a7b04386a..0000000000 --- a/content/zh/examples/application/guestbook/redis-slave-deployment.yaml +++ /dev/null @@ -1,40 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: redis-slave - labels: - app: redis -spec: - selector: - matchLabels: - app: redis - role: slave - tier: backend - replicas: 2 - template: - metadata: - labels: - app: redis - role: slave - tier: backend - spec: - containers: - - name: slave - image: gcr.io/google_samples/gb-redisslave:v3 - resources: - requests: - cpu: 100m - memory: 100Mi - env: - - name: GET_HOSTS_FROM - value: dns - # Using `GET_HOSTS_FROM=dns` requires your cluster to - # provide a dns service. As of Kubernetes 1.3, DNS is a built-in - # service launched automatically. However, if the cluster you are using - # does not have a built-in DNS service, you can instead - # access an environment variable to find the master - # service's host. To do so, comment out the 'value: dns' line above, and - # uncomment the line below: - # value: env - ports: - - containerPort: 6379 diff --git a/content/zh/examples/application/guestbook/redis-slave-service.yaml b/content/zh/examples/application/guestbook/redis-slave-service.yaml deleted file mode 100644 index 238fd63fb6..0000000000 --- a/content/zh/examples/application/guestbook/redis-slave-service.yaml +++ /dev/null @@ -1,15 +0,0 @@ -apiVersion: v1 -kind: Service -metadata: - name: redis-slave - labels: - app: redis - role: slave - tier: backend -spec: - ports: - - port: 6379 - selector: - app: redis - role: slave - tier: backend diff --git a/content/zh/examples/application/job/cronjob.yaml b/content/zh/examples/application/job/cronjob.yaml index 3ca130289e..816d682f28 100644 --- a/content/zh/examples/application/job/cronjob.yaml +++ b/content/zh/examples/application/job/cronjob.yaml @@ -12,7 +12,7 @@ spec: - name: hello image: busybox imagePullPolicy: IfNotPresent - args: + command: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster diff --git a/layouts/shortcodes/cncf-landscape.html b/layouts/shortcodes/cncf-landscape.html index a97d4f9f8a..22b05d3ff0 100644 --- a/layouts/shortcodes/cncf-landscape.html +++ b/layouts/shortcodes/cncf-landscape.html @@ -15,7 +15,7 @@ function updateLandscapeSource(button,shouldUpdateFragment) { } else { var landscapeElements = document.querySelectorAll("#landscape"); let categories=button.dataset.landscapeTypes; - let link = "https://landscape.cncf.io/category="+encodeURIComponent(categories)+"&format=card-mode&grouping=category&embed=yes"; + let link = "https://landscape.cncf.io/card-mode?category="+encodeURIComponent(categories)+"&grouping=category&embed=yes"; landscapeElements[0].src = link; } } @@ -58,9 +58,9 @@ document.addEventListener("DOMContentLoaded", function () { {{- end -}}
{{ if ( .Get "category" ) }} - + {{ else }} - + {{ end }}
diff --git a/static/_redirects b/static/_redirects index fd7eba2713..4186c547b2 100644 --- a/static/_redirects +++ b/static/_redirects @@ -275,7 +275,8 @@ /docs/tasks/job/work-queue-1/ /docs/concepts/workloads/controllers/job/ 301 /docs/tasks/setup-konnectivity/setup-konnectivity/ /docs/tasks/extend-kubernetes/setup-konnectivity/ 301 /docs/tasks/kubectl/get-shell-running-container/ /docs/tasks/debug-application-cluster/get-shell-running-container/ 301 -/docs/tasks/kubectl/install/ /docs/tasks/tools/install-kubectl/ 301 +/docs/tasks/kubectl/install/ /docs/tasks/tools/ 301 +/docs/tasks/tools/install-kubectl/ /docs/tasks/tools/ 301 /docs/tasks/kubectl/list-all-running-container-images/ /docs/tasks/access-application-cluster/list-all-running-container-images/ 301 /docs/tasks/manage-stateful-set/debugging-a-statefulset/ /docs/tasks/debug-application-cluster/debug-stateful-set/ 301 /docs/tasks/manage-stateful-set/delete-pods/ /docs/tasks/run-application/delete-stateful-set/ 301 @@ -284,6 +285,7 @@ /docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/ /docs/tasks/run-application/upgrade-pet-set-to-stateful-set/ 301 /docs/tasks/run-application/update-api-object-kubectl-patch/ /docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/ 301 /docs/tasks/stateful-sets/deleting-pods/ /docs/tasks/run-application/force-delete-stateful-set-pod/ 301 +/ja/docs/tasks/tools/install-minikube/ https://minikube.sigs.k8s.io/docs/start/ 302 /docs/tasks/troubleshoot/debug-init-containers/ /docs/tasks/debug-application-cluster/debug-init-containers/ 301 /docs/tasks/web-ui-dashboard/ /docs/tasks/access-application-cluster/web-ui-dashboard/ 301