whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Revert "Repair and sync the dev-1.18 branch" (#19228)

Browse Source
This commit is contained in:
Zach Corleissen
2020-02-21 12:16:47 -08:00
committed by GitHub
parent 6ea6519b8f
commit e66e21ab7b
117 changed files with 3577 additions and 2899 deletions
Download Patch File Download Diff File Expand all files Collapse all files
OWNERS_ALIASES
+3
View File
@@ -40,6 +40,7 @@ aliases:
- mkorbi
- rlenferink
sig-docs-en-owners: # Admins for English content
- bradamant3
- bradtopol
- daminisatya
- gochist
@@ -57,6 +58,7 @@ aliases:
- zacharysarah
- zparnold
sig-docs-en-reviews: # PR reviews for English content
- bradamant3
- bradtopol
- daminisatya
- gochist
@@ -157,6 +159,7 @@ aliases:
- ianychoi
- seokho-son
sig-docs-maintainers: # Website maintainers
- bradamant3
- jimangel
- kbarnard10
- pwittrock
README-ru.md
+1 -1
View File
@@ -34,7 +34,7 @@
> Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make`
> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#запуск-сайта-с-помощью-hugo) ниже на этой странице.
> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#running-the-site-locally-using-hugo) ниже на этой странице.
Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли:
README.md
+1 -1
View File
@@ -37,7 +37,7 @@ The recommended way to run the Kubernetes website locally is to run a specialize
> If you are running on Windows, you'll need a few more tools which you can install with [Chocolatey](https://chocolatey.org). `choco install make`
> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-website-locally-using-hugo) below.
> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-site-locally-using-hugo) below.
If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:
content/de/docs/tasks/tools/install-minikube.md
+1 -1
View File
@@ -49,7 +49,7 @@ Minikube unterstützt auch die Option `--vm-driver=none`, mit der die Kubernetes
Die einfachste Möglichkeit, Minikube unter macOS zu installieren, ist die Verwendung von [Homebrew](https://brew.sh):
```shell
brew install minikube
brew cask install minikube
```
Sie können es auch auf macOS installieren, indem Sie eine statische Binärdatei herunterladen:
content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md
-45
View File
@@ -1,45 +0,0 @@
---
layout: blog
title: "Contributor Summit Amsterdam Schedule Announced"
date: 2020-02-18
slug: Contributor-Summit-Amsterdam-Schedule-Announced
---
**Authors:** Jeffrey Sica (Red Hat), Amanda Katona (VMware)
tl;dr [Registration is open](https://events.linuxfoundation.org/kubernetes-contributor-summit-europe/) and the [schedule is live](https://kcseu2020.sched.com/) so register now and we’ll see you in Amsterdam!
## Kubernetes Contributor Summit
**Sunday, March 29, 2020**
- Evening Contributor Celebration:
[ZuidPool](https://www.zuid-pool.nl/en/)
- Address: [Europaplein 22, 1078 GZ Amsterdam, Netherlands](https://www.google.com/search?q=KubeCon+Amsterdam+2020&ie=UTF-8&ibp=htl;events&rciv=evn&sa=X&ved=2ahUKEwiZoLvQ0dvnAhVST6wKHScBBZ8Q5bwDMAB6BAgSEAE#)
- Time: 18:00 - 21:00
**Monday, March 30, 2020**
- All Day Contributor Summit:
- [Amsterdam RAI](https://www.rai.nl/en/)
- Address: [Europaplein 24, 1078 GZ Amsterdam, Netherlands](https://www.google.com/search?q=kubecon+amsterdam+2020&oq=kubecon+amste&aqs=chrome.0.35i39j69i57j0l4j69i61l2.3957j1j4&sourceid=chrome&ie=UTF-8&ibp=htl;events&rciv=evn&sa=X&ved=2ahUKEwiZoLvQ0dvnAhVST6wKHScBBZ8Q5bwDMAB6BAgSEAE#)
- Time: 09:00 - 17:00 (Breakfast at 08:00)
![Contributor Summit](/images/blog/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced/contribsummit.jpg)
Hello everyone and Happy 2020! It’s hard to believe that KubeCon EU 2020 is less than six weeks away, and with that another contributor summit! This year we have the pleasure of being in Amsterdam in early spring, so be sure to pack some warmer clothing. This summit looks to be exciting with a lot of fantastic community-driven content. We received **26** submissions from the CFP. From that, the events team selected **12** sessions. Each of the sessions falls into one of four categories:
* Community
* Contributor Improvement
* Sustainability
* In-depth Technical
On top of the presentations, there will be a dedicated Docs Sprint as well as the New Contributor Workshop 101 and 201 Sessions. All told, we will have five separate rooms of content throughout the day on Monday. Please **[see the full schedule](https://kcseu2020.sched.com/)** to see what sessions you’d be interested in. We hope between the content provided and the inevitable hallway track, everyone has a fun and enriching experience.
Speaking of fun, the social Sunday night should be a blast! We’re hosting this summit’s social close to the conference center, at [ZuidPool](https://www.zuid-pool.nl/en/). There will be games, bingo, and unconference sign-up throughout the evening. It should be a relaxed way to kick off the week.
[Registration is open](https://events.linuxfoundation.org/kubernetes-contributor-summit-europe/)! Space is limited so it’s always a good idea to register early.
If you have any questions, reach out to the [Amsterdam Team](https://github.com/kubernetes/community/tree/master/events/2020/03-contributor-summit#team) on Slack in the [#contributor-summit](https://kubernetes.slack.com/archives/C7J893413) channel.
Hope to see you there!
content/en/docs/concepts/architecture/nodes.md
+5 -5
View File
@@ -30,7 +30,7 @@ A node's status contains the following information:
* [Capacity and Allocatable](#capacity)
* [Info](#info)
Node status and other details about a node can be displayed using the following command:
Node status and other details about a node can be displayed using below command:
```shell
kubectl describe node <insert-node-name-here>
```
@@ -188,7 +188,7 @@ a Lease object.
In Kubernetes 1.4, we updated the logic of the node controller to better handle
cases when a large number of nodes have problems with reaching the master
(e.g. because the master has networking problems). Starting with 1.4, the node
(e.g. because the master has networking problem). Starting with 1.4, the node
controller looks at the state of all nodes in the cluster when making a
decision about pod eviction.
@@ -212,9 +212,9 @@ there is only one availability zone (the whole cluster).
A key reason for spreading your nodes across availability zones is so that the
workload can be shifted to healthy zones when one entire zone goes down.
Therefore, if all nodes in a zone are unhealthy then the node controller evicts at
the normal rate of `--node-eviction-rate`. The corner case is when all zones are
completely unhealthy (i.e. there are no healthy nodes in the cluster). In such a
Therefore, if all nodes in a zone are unhealthy then node controller evicts at
the normal rate `--node-eviction-rate`. The corner case is when all zones are
completely unhealthy (i.e. there are no healthy nodes in the cluster). In such
case, the node controller assumes that there's some problem with master
connectivity and stops all evictions until some connectivity is restored.
content/en/docs/concepts/configuration/overview.md
+2 -1
View File
@@ -30,7 +30,7 @@ This is a living document. If you think of something that is not on this list bu
- Put object descriptions in annotations, to allow better introspection.
## "Naked" Pods versus ReplicaSets, Deployments, and Jobs {#naked-pods-vs-replicasets-deployments-and-jobs}
## "Naked" Pods vs ReplicaSets, Deployments, and Jobs
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
@@ -108,3 +108,4 @@ The caching semantics of the underlying image provider make even `imagePullPolic
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+1 -1
View File
@@ -202,7 +202,7 @@ When you create a custom resource, either via a CRDs or an AA, you get many feat
| Finalizers | Block deletion of extension resources until external cleanup happens. |
| Admission Webhooks | Set default values and validate extension resources during any create/update/delete operation. |
| UI/CLI Display | Kubectl, dashboard can display extension resources. |
| Unset versus Empty | Clients can distinguish unset fields from zero-valued fields. |
| Unset vs Empty | Clients can distinguish unset fields from zero-valued fields. |
| Client Libraries Generation | Kubernetes provides generic client libraries, as well as tools to generate type-specific client libraries. |
| Labels and annotations | Common metadata across objects that tools know how to edit for core and custom resources. |
content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+1 -1
View File
@@ -12,7 +12,7 @@ weight: 10
{{% capture overview %}}
{{< feature-state state="alpha" >}}
{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
{{< warning >}}Alpha features change rapidly. {{< /warning >}}
Network plugins in Kubernetes come in a few flavors:
content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+1 -1
View File
@@ -67,7 +67,7 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) can help you find the spec format for all of the objects you can create using Kubernetes.
For example, the `spec` format for a Pod can be found in
[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
and the `spec` format for a Deployment can be found in
and the `spec` format for a Deployment can be found
[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
{{% /capture %}}
content/en/docs/concepts/overview/working-with-objects/names.md
+3 -31
View File
@@ -2,7 +2,7 @@
reviewers:
- mikedanese
- thockin
title: Object Names and IDs
title: Names
content_template: templates/concept
weight: 20
---
@@ -18,41 +18,14 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/conc
{{% /capture %}}
{{% capture body %}}
## Names
{{< glossary_definition term_id="name" length="all" >}}
Below are three types of commonly used name constraints for resources.
### DNS Subdomain Names
Most resource types require a name that can be used as a DNS subdomain name
as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123).
This means the name must:
- contain no more than 253 characters
- contain only lowercase alphanumeric characters, '-' or '.'
- start with an alphanumeric character
- end with an alphanumeric character
### DNS Label Names
Some resource types require their names to follow the DNS
label standard as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123).
This means the name must:
- contain at most 63 characters
- contain only lowercase alphanumeric characters or '-'
- start with an alphanumeric character
- end with an alphanumeric character
### Path Segment Names
Some resource types require their names to be able to be safely encoded as a
path segment. In other words, the name may not be "." or ".." and the name may
not contain "/" or "%".
Kubernetes resources can have names up to 253 characters long. The characters allowed in names are: digits (0-9), lower case letters (a-z), `-`, and `.`.
Here’s an example manifest for a Pod named `nginx-demo`.
@@ -69,7 +42,6 @@ spec:
- containerPort: 80
```
{{< note >}}
Some resource types have additional restrictions on their names.
{{< /note >}}
content/en/docs/concepts/policy/resource-quotas.md
+1 -1
View File
@@ -376,7 +376,7 @@ pods 0 10
* `Exist`
* `DoesNotExist`
## Requests compared to Limits {#requests-vs-limits}
## Requests vs Limits
When allocating compute resources, each container may specify a request and a limit value for either CPU or memory.
The quota can be configured to quota either value.
content/en/docs/concepts/storage/persistent-volumes.md
+1 -1
View File
@@ -71,7 +71,7 @@ check [kube-apiserver](/docs/admin/kube-apiserver/) documentation.
### Binding
A user creates, or in the case of dynamic provisioning, has already created, a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, PersistentVolumeClaim binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping, using a ClaimRef which is a bi-directional binding between the PersistentVolume and the PersistentVolumeClaim.
A user creates, or in the case of dynamic provisioning, has already created, a `PersistentVolumeClaim` with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, `PersistentVolumeClaim` binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping.
Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
content/en/docs/concepts/workloads/controllers/cron-jobs.md
+1 -1
View File
@@ -18,7 +18,7 @@ One CronJob object is like one line of a _crontab_ (cron table) file. It runs a
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
{{< note >}}
All **CronJob** `schedule:` times are denoted in UTC.
All **CronJob** `schedule:` times are based on the timezone of the master where the job is initiated.
{{< /note >}}
When creating the manifest for a CronJob resource, make sure the name you provide
content/en/docs/concepts/workloads/controllers/replicaset.md
+42 -40
View File
@@ -75,50 +75,53 @@ kubectl describe rs/frontend
And you will see output similar to:
```shell
Name: frontend
Namespace: default
Selector: tier=frontend
Labels: app=guestbook
tier=frontend
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",...
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Name: frontend
Namespace: default
Selector: tier=frontend
Labels: app=guestbook
tier=frontend
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: tier=frontend
Labels: app=guestbook
tier=frontend
Containers:
php-redis:
Image: gcr.io/google_samples/gb-frontend:v3
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Image: gcr.io/google_samples/gb-frontend:v3
Port: 80/TCP
Requests:
cpu: 100m
memory: 100Mi
Environment:
GET_HOSTS_FROM: dns
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 117s replicaset-controller Created pod: frontend-wtsmm
Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-b2zdv
Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-vcmts
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
```
And lastly you can check for the Pods brought up:
```shell
kubectl get pods
kubectl get Pods
```
You should see Pod information similar to:
```shell
NAME READY STATUS RESTARTS AGE
frontend-b2zdv 1/1 Running 0 6m36s
frontend-vcmts 1/1 Running 0 6m36s
frontend-wtsmm 1/1 Running 0 6m36s
NAME READY STATUS RESTARTS AGE
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
```
You can also verify that the owner reference of these pods is set to the frontend ReplicaSet.
To do this, get the yaml of one of the Pods running:
```shell
kubectl get pods frontend-b2zdv -o yaml
kubectl get pods frontend-9si5l -o yaml
```
The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field:
@@ -126,11 +129,11 @@ The output will look similar to this, with the frontend ReplicaSet's info set in
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-02-12T07:06:16Z"
creationTimestamp: 2019-01-31T17:20:41Z
generateName: frontend-
labels:
tier: frontend
name: frontend-b2zdv
name: frontend-9si5l
namespace: default
ownerReferences:
- apiVersion: apps/v1
@@ -138,7 +141,7 @@ metadata:
controller: true
kind: ReplicaSet
name: frontend
uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
uid: 892a2330-257c-11e9-aecd-025000000001
...
```
@@ -167,17 +170,16 @@ its desired count.
Fetching the Pods:
```shell
kubectl get pods
kubectl get Pods
```
The output shows that the new Pods are either already terminated, or in the process of being terminated:
```shell
NAME READY STATUS RESTARTS AGE
frontend-b2zdv 1/1 Running 0 10m
frontend-vcmts 1/1 Running 0 10m
frontend-wtsmm 1/1 Running 0 10m
pod1 0/1 Terminating 0 1s
pod2 0/1 Terminating 0 1s
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
pod2 0/1 Terminating 0 4s
```
If you create the Pods first:
@@ -193,15 +195,15 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the
number of its new Pods and the original matches its desired count. As fetching the Pods:
```shell
kubectl get pods
kubectl get Pods
```
Will reveal in its output:
```shell
NAME READY STATUS RESTARTS AGE
frontend-hmmj2 1/1 Running 0 9s
pod1 1/1 Running 0 36s
pod2 1/1 Running 0 36s
frontend-pxj4r 1/1 Running 0 5s
pod1 1/1 Running 0 13s
pod2 1/1 Running 0 13s
```
In this manner, a ReplicaSet can own a non-homogenous set of Pods
content/en/docs/contribute/participating.md
+3 -4
View File
@@ -24,7 +24,6 @@ You can also become a [member](#members),
access and entail certain responsibilities for approving and committing changes.
See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
for more information on how membership works within the Kubernetes community.
The rest of this document outlines some unique ways these roles function within
SIG Docs, which is responsible for maintaining one of the most public-facing
aspects of Kubernetes -- the Kubernetes website and documentation.
@@ -53,8 +52,7 @@ aspects of Kubernetes -- the Kubernetes website and documentation.
Anyone can do the following:
- Open a GitHub issue against any part of Kubernetes, including documentation.
- Provide non-binding feedback on a pull request.
- Help to localize existing content
- Provide non-binding feedback on a pull request/
- Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
- Use the `/lgtm` Prow command (short for "looks good to me") to recommend the changes in a pull request for merging.
{{< note >}}
@@ -122,6 +120,7 @@ changes. Reviewers can:
- Triage and categorize issues
- Review pull requests and provide binding feedback
- Create diagrams, graphics assets, and embeddable screencasts and videos
- Localization
- Edit user-facing strings in code
- Improve code comments
@@ -167,7 +166,7 @@ add new members to a GitHub group.
Approvers are members of the
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
GitHub group. See [SIG Docs teams and automation](#sig-docs-teams-and-automation) for details.
GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
Approvers can do the following:
content/en/docs/reference/access-authn-authz/admission-controllers.md
+1 -1
View File
@@ -737,7 +737,7 @@ phase, and therefore is the last admission controller to run.
`MutatingAdmissionWebhook` appears before it in this list, because it runs
in the mutating phase.
For earlier versions, there was no concept of validating versus mutating and the
For earlier versions, there was no concept of validating vs mutating and the
admission controllers ran in the exact order specified.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
-2
View File
@@ -631,8 +631,6 @@ So a webhook response to add that label would be:
## Webhook configuration
To register admission webhooks, create `MutatingWebhookConfiguration` or `ValidatingWebhookConfiguration` API objects.
The name of a `MutatingWebhookConfiguration` or a `ValidatingWebhookConfiguration` object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
Each configuration can contain one or more webhooks.
If multiple webhooks are specified in a single configuration, each should be given a unique name.
content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+1 -1
View File
@@ -18,7 +18,7 @@ incomplete features are referred to in order to better describe service accounts
{{% /capture %}}
{{% capture body %}}
## User accounts versus service accounts
## User accounts vs service accounts
Kubernetes distinguishes between the concept of a user account and a service account
for a number of reasons:
content/en/docs/reference/command-line-tools-reference/feature-gates.md
+1 -1
View File
@@ -146,7 +146,7 @@ different Kubernetes components.
| `TokenRequestProjection` | `true` | Beta | 1.12 | |
| `TTLAfterFinished` | `false` | Alpha | 1.12 | |
| `TopologyManager` | `false` | Alpha | 1.16 | |
| `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 |
| `ValidateProxyRedirects` | `false` | Alpha | 1.10 | 1.13 |
| `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
| `VolumePVCDataSource` | `true` | Beta | 1.16 | |
content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
+1 -1
View File
@@ -281,7 +281,7 @@ kubectl get po -l run=nginx-app
```
{{< note >}}
When you use kubectl, you don't delete the pod directly. You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
{{< /note >}}
## docker login
content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+132 -158
View File
@@ -8,50 +8,63 @@ weight: 30
{{% capture overview %}}
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">**kubeadm** helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. With kubeadm, your cluster should pass [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). Kubeadm also supports other cluster
lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/).
The `kubeadm` tool is good if you need:
Because you can install kubeadm on various types of machine (e.g. laptop, server,
Raspberry Pi, etc.), it's well suited for integration with provisioning systems
such as Terraform or Ansible.
- A simple way for you to try out Kubernetes, possibly for the first time.
- A way for existing users to automate setting up a cluster and test their application.
- A building block in other ecosystem and/or installer tools with a larger
scope.
kubeadm's simplicity means it can serve a wide range of use cases:
You can install and use `kubeadm` on various machines: your laptop, a set
of cloud servers, a Raspberry Pi, and more. Whether you're deploying into the
cloud or on-premises, you can integrate `kubeadm` into provisioning systems such
as Ansible or Terraform.
- New users can start with kubeadm to try Kubernetes out for the first time.
- Users familiar with Kubernetes can spin up clusters with kubeadm and test their applications.
- Larger projects can include kubeadm as a building block in a more complex system that can also include other installer tools.
kubeadm is designed to be a simple way for new users to start trying
Kubernetes out, possibly for the first time, a way for existing users to
test their application on and stitch together a cluster easily, and also to be
a building block in other ecosystem and/or installer tool with a larger
scope.
You can install _kubeadm_ very easily on operating systems that support
installing deb or rpm packages. The responsible SIG for kubeadm,
[SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle), provides these packages pre-built for you,
but you may also build them from source for other OSes.
### kubeadm maturity
kubeadm's overall feature state is **GA**. Some sub-features, like the configuration
file API are still under active development. The implementation of creating the cluster
may change slightly as the tool evolves, but the overall implementation should be pretty stable.
Any commands under `kubeadm alpha` are by definition, supported on an alpha level.
### Support timeframes
Kubernetes releases are generally supported for nine months, and during that
period a patch release may be issued from the release branch if a severe bug or
security issue is found. Here are the latest Kubernetes releases and the support
timeframe; which also applies to `kubeadm`.
| Kubernetes version | Release month | End-of-life-month |
|--------------------|----------------|-------------------|
| v1.13.x | December 2018 | September 2019   |
| v1.14.x | March 2019 | December 2019   |
| v1.15.x | June 2019 | March 2020   |
| v1.16.x | September 2019 | June 2020   |
{{% /capture %}}
{{% capture prerequisites %}}
To follow this guide, you need:
- One or more machines running a deb/rpm-compatible Linux OS; for example: Ubuntu or CentOS.
- 2 GiB or more of RAM per machine--any less leaves little room for your
- One or more machines running a deb/rpm-compatible OS, for example Ubuntu or CentOS
- 2 GB or more of RAM per machine. Any less leaves little room for your
apps.
- At least 2 CPUs on the machine that you use as a control-plane node.
- Full network connectivity among all machines in the cluster. You can use either a
public or a private network.
You also need to use a version of `kubeadm` that can deploy the version
of Kubernetes that you want to use in your new cluster.
[Kubernetes' version and version skew support policy](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall.
Check that policy to learn about what versions of Kubernetes and `kubeadm`
are supported. This page is written for Kubernetes {{< param "version" >}}.
The `kubeadm` tool's overall feature state is General Availability (GA). Some sub-features are
still under active development. The implementation of creating the cluster may change
slightly as the tool evolves, but the overall implementation should be pretty stable.
{{< note >}}
Any commands under `kubeadm alpha` are, by definition, supported on an alpha level.
{{< /note >}}
- 2 CPUs or more on the control-plane node
- Full network connectivity among all machines in the cluster. A public or
private network is fine.
{{% /capture %}}
@@ -81,29 +94,27 @@ After you initialize your control-plane, the kubelet runs normally.
### Initializing your control-plane node
The control-plane node is the machine where the control plane components run, including
{{< glossary_tooltip term_id="etcd" >}} (the cluster database) and the
{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
(which the {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} command line tool
etcd (the cluster database) and the API server (which the kubectl CLI
communicates with).
1. (Recommended) If you have plans to upgrade this single control-plane `kubeadm` cluster
1. (Recommended) If you have plans to upgrade this single control-plane kubeadm cluster
to high availability you should specify the `--control-plane-endpoint` to set the shared endpoint
for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer.
1. Choose a Pod network add-on, and verify whether it requires any arguments to
be passed to `kubeadm init`. Depending on which
be passed to kubeadm initialization. Depending on which
third-party provider you choose, you might need to set the `--pod-network-cidr` to
a provider-specific value. See [Installing a Pod network add-on](#pod-network).
1. (Optional) Since version 1.14, `kubeadm` tries to detect the container runtime on Linux
1. (Optional) Since version 1.14, kubeadm will try to detect the container runtime on Linux
by using a list of well known domain socket paths. To use different container runtime or
if there are more than one installed on the provisioned node, specify the `--cri-socket`
argument to `kubeadm init`. See [Installing runtime](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
1. (Optional) Unless otherwise specified, `kubeadm` uses the network interface associated
1. (Optional) Unless otherwise specified, kubeadm uses the network interface associated
with the default gateway to set the advertise address for this particular control-plane node's API server.
To use a different network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
must specify an IPv6 address, for example `--apiserver-advertise-address=fd00::101`
1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
connectivity to the gcr.io container image registry.
connectivity to gcr.io registries.
To initialize the control-plane node run:
@@ -247,43 +258,26 @@ created, and deleted with the `kubeadm token` command. See the
### Installing a Pod network add-on {#pod-network}
{{< caution >}}
This section contains important information about networking setup and
deployment order.
Read all of this advice carefully before proceeding.
**You must deploy a
{{< glossary_tooltip text="Container Network Interface" term_id="cni" >}}
(CNI) based Pod network add-on so that your Pods can communicate with each other.
Cluster DNS (CoreDNS) will not start up before a network is installed.**
- Take care that your Pod network must not overlap with any of the host
networks: you are likely to see problems if there is any overlap.
(If you find a collision between your network plugin’s preferred Pod
network and some of your host networks, you should think of a suitable
CIDR block to use instead, then use that during `kubeadm init` with
`--pod-network-cidr` and as a replacement in your network plugin’s YAML).
- By default, `kubeadm` sets up your cluster to use and enforce use of
[RBAC](/docs/reference/access-authn-authz/rbac/) (role based access
control).
Make sure that your Pod network plugin supports RBAC, and so do any manifests
that you use to deploy it.
- If you want to use IPv6--either dual-stack, or single-stack IPv6 only
networking--for your cluster, make sure that your Pod network plugin
supports IPv6.
IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
This section contains important information about installation and deployment order. Read it carefully before proceeding.
{{< /caution >}}
Several external projects provide Kubernetes Pod networks using CNI, some of which also
support [Network Policy](/docs/concepts/services-networking/networkpolicies/).
You must install a Pod network add-on so that your Pods can communicate with
each other.
See the list of available
[networking and network policy add-ons](https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
**The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed.
kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).**
You can install a Pod network add-on with the following command on the
control-plane node or a node that has the kubeconfig credentials:
Several projects provide Kubernetes Pod networks using CNI, some of which also
support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). See each plugin's documentation to see if it supports IPv6.
Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/docs/reference/access-authn-authz/rbac/).
Make sure that your network manifest supports RBAC.
Also, beware, that your Pod network must not overlap with any of the host networks as this can cause issues.
If you find a collision between your network plugin’s preferred Pod network and some of your host networks, you should think of a suitable CIDR replacement and use that during `kubeadm init` with `--pod-network-cidr` and as a replacement in your network plugin’s YAML.
You can install a Pod network add-on with the following command on the control-plane node or a node that has the kubeconfig credentials:
```bash
kubectl apply -f <add-on.yaml>
@@ -297,7 +291,7 @@ Below you can find installation instructions for some popular Pod network plugin
{{% tab name="Calico" %}}
[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`.
By default, Calico uses `192.168.0.0/16` as the Pod network CIDR, though this can be configured in the calico.yaml file. For Calico to work correctly, you need to pass this same CIDR to the `kubeadm init` command using the `--pod-network-cidr=192.168.0.0/16` flag or via kubeadm's configuration.
By default, Calico uses `192.168.0.0/16` as the Pod network CIDR, though this can be configured in the calico.yaml file. For Calico to work correctly, you need to pass this same CIDR to the kubeadm init command using the `--pod-network-cidr=192.168.0.0/16` flag or via the kubeadm configuration.
```shell
kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml
@@ -346,11 +340,13 @@ For `flannel` to work correctly, you must pass `--pod-network-cidr=10.244.0.0/16
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
please see [Network Plugin Requirements](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Make sure that your firewall rules allow UDP ports 8285 and 8472 traffic for all hosts participating in the overlay network. The [Firewall](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls) section of Flannel's troubleshooting guide explains about this in more detail.
Make sure that your firewall rules allow UDP ports 8285 and 8472 traffic for all hosts participating in the overlay network.
see [here
](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls).
Flannel works on `amd64`, `arm`, `arm64`, `ppc64le` and `s390x` architectures under Linux.
Note that `flannel` works on `amd64`, `arm`, `arm64`, `ppc64le` and `s390x` under Linux.
Windows (`amd64`) is claimed as supported in v0.11.0 but the usage is undocumented.
```shell
@@ -364,23 +360,23 @@ For more information about `flannel`, see [the CoreOS flannel repository on GitH
{{% tab name="Kube-router" %}}
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
please see [Network Plugin Requirements](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
For information on using the `kubeadm` tool to set up a Kubernetes cluster with Kube-router, please see the official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
For information on setting up Kubernetes cluster with Kube-router using kubeadm, please see official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
{{% /tab %}}
{{% tab name="Weave Net" %}}
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
please see [Network Plugin Requirements](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon]((https://www.weave.works/docs/net/latest/kube-addon/).
The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/).
Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` platforms without any extra action required.
Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` without any extra action required.
Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
if they don't know their PodIP.
@@ -393,12 +389,10 @@ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl versio
Once a Pod network has been installed, you can confirm that it is working by
checking that the CoreDNS Pod is `Running` in the output of `kubectl get pods --all-namespaces`.
checking that the CoreDNS Pod is Running in the output of `kubectl get pods --all-namespaces`.
And once the CoreDNS Pod is up and running, you can continue by joining your nodes.
If your network is not working or CoreDNS is not in the `Running` state, check out the
[troubleshooting guide](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)
for `kubeadm`.
If your network is not working or CoreDNS is not in the Running state, checkout our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
### Control plane node isolation
@@ -430,19 +424,19 @@ The nodes are where your workloads (containers and Pods, etc) run. To add new no
* Become root (e.g. `sudo su -`)
* Run the command that was output by `kubeadm init`. For example:
```bash
``` bash
kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>
```
If you do not have the token, you can get it by running the following command on the control-plane node:
```bash
``` bash
kubeadm token list
```
The output is similar to this:
```console
``` console
TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi 23h 2018-06-12T02:51:28Z authentication, The default bootstrap system:
signing token generated by bootstrappers:
@@ -453,26 +447,26 @@ TOKEN TTL EXPIRES USAGES DESCRIPTION
By default, tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired,
you can create a new token by running the following command on the control-plane node:
```bash
``` bash
kubeadm token create
```
The output is similar to this:
```console
``` console
5didvk.d09sbcov8ph2amjw
```
If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the control-plane node:
```bash
``` bash
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
openssl dgst -sha256 -hex | sed 's/^.* //'
```
The output is similar to:
The output is similar to this:
```console
``` console
8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
```
@@ -504,7 +498,7 @@ In order to get a kubectl on some other computer (e.g. laptop) to talk to your
cluster, you need to copy the administrator kubeconfig file from your control-plane node
to your workstation like this:
```bash
``` bash
scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes
```
@@ -535,18 +529,11 @@ kubectl --kubeconfig ./admin.conf proxy
You can now access the API Server locally at `http://localhost:8001/api/v1`
## Clean up {#tear-down}
## Tear down {#tear-down}
If you used disposable servers for your cluster, for testing, you can
switch those off and do no further clean up. You can use
`kubectl config delete-cluster` to delete your local references to the
cluster.
However, if you want to deprovision your cluster more cleanly, you should
first [drain the node](/docs/reference/generated/kubectl/kubectl-commands#drain)
and make sure that the node is empty, then deconfigure the node.
### Remove the node
To undo what kubeadm did, you should first [drain the
node](/docs/reference/generated/kubectl/kubectl-commands#drain) and make
sure that the node is empty before shutting it down.
Talking to the control-plane node with the appropriate credentials, run:
@@ -555,7 +542,7 @@ kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
kubectl delete node <node name>
```
Then, on the node being removed, reset all `kubeadm` installed state:
Then, on the node being removed, reset all kubeadm installed state:
```bash
kubeadm reset
@@ -576,55 +563,47 @@ ipvsadm -C
If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
appropriate arguments.
### Clean up the control plane
More options and information about the
[`kubeadm reset command`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
You can use `kubeadm reset` on the control plane host to trigger a best-effort
clean up.
## Maintaining a cluster {#lifecycle}
See the [`kubeadm reset`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/)
reference documentation for more information about this subcommand and its
options.
Instructions for maintaining kubeadm clusters (e.g. upgrades,downgrades, etc.) can be found [here.](/docs/tasks/administer-cluster/kubeadm)
{{% /capture %}}
## Explore other add-ons {#other-addons}
{{% capture discussion %}}
See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons,
including tools for logging, monitoring, network policy, visualization &amp;
control of your Kubernetes cluster.
## What's next {#whats-next}
* Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy)
* <a id="lifecycle" />See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
for details about upgrading your cluster using `kubeadm`.
* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
* Learn about kubeadm's advanced usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
* Configure log rotation. You can use **logrotate** for that. When using Docker, you can specify log rotation options for Docker daemon, for example `--log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5`. See [Configure and troubleshoot the Docker daemon](https://docs.docker.com/engine/admin/) for more details.
* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
of Pod network add-ons.
* <a id="other-addons" />See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to
explore other add-ons, including tools for logging, monitoring, network policy, visualization &amp;
control of your Kubernetes cluster.
* Configure how your cluster handles logs for cluster events and from
applications running in Pods.
See [Logging Architecture](/docs/concepts/cluster-administration/logging/) for
an overview of what is involved.
### Feedback {#feedback}
## Feedback {#feedback}
* For bugs, visit the [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
* For support, visit the
[#kubeadm](https://kubernetes.slack.com/messages/kubeadm/) Slack channel
* General SIG Cluster Lifecycle development Slack channel:
* For bugs, visit [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
* For support, visit kubeadm Slack Channel:
[#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
* General SIG Cluster Lifecycle Development Slack Channel:
[#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
* SIG Cluster Lifecycle [SIG information](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle#readme)
* SIG Cluster Lifecycle mailing list:
* SIG Cluster Lifecycle [SIG information](#TODO)
* SIG Cluster Lifecycle Mailing List:
[kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)
## Version skew policy {#version-skew-policy}
The `kubeadm` tool of version vX.Y may deploy clusters with a control plane of version vX.Y or vX.(Y-1).
`kubeadm` vX.Y can also upgrade an existing kubeadm-created cluster of version vX.(Y-1).
The kubeadm CLI tool of version vX.Y may deploy clusters with a control plane of version vX.Y or vX.(Y-1).
kubeadm CLI vX.Y can also upgrade an existing kubeadm-created cluster of version vX.(Y-1).
Due to that we can't see into the future, kubeadm CLI vX.Y may or may not be able to deploy vX.(Y+1) clusters.
Example: `kubeadm` v1.8 can deploy both v1.7 and v1.8 clusters and upgrade v1.7 kubeadm-created clusters to
Example: kubeadm v1.8 can deploy both v1.7 and v1.8 clusters and upgrade v1.7 kubeadm-created clusters to
v1.8.
These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
@@ -632,24 +611,7 @@ These resources provide more information on supported version skew between kubel
* Kubernetes [version and version-skew policy](/docs/setup/release/version-skew-policy/)
* Kubeadm-specific [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
## Limitations {#limitations}
### Cluster resilience {#resilience}
The cluster created here has a single control-plane node, with a single etcd database
running on it. This means that if the control-plane node fails, your cluster may lose
data and may need to be recreated from scratch.
Workarounds:
* Regularly [back up etcd](https://coreos.com/etcd/docs/latest/admin_guide.html). The
etcd data directory configured by kubeadm is at `/var/lib/etcd` on the control-plane node.
* Use multiple control-plane nodes. You can read
[Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/) to pick a cluster
topology that provides higher availabilty.
### Platform compatibility {#multi-platform}
## kubeadm works on multiple platforms {#multi-platform}
kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64, ppc64le, and s390x
following the [multi-platform
@@ -661,8 +623,20 @@ Only some of the network providers offer solutions for all platforms. Please con
network providers above or the documentation from each provider to figure out whether the provider
supports your chosen platform.
## Limitations {#limitations}
The cluster created here has a single control-plane node, with a single etcd database
running on it. This means that if the control-plane node fails, your cluster may lose
data and may need to be recreated from scratch.
Workarounds:
* Regularly [back up etcd](https://coreos.com/etcd/docs/latest/admin_guide.html). The
etcd data directory configured by kubeadm is at `/var/lib/etcd` on the control-plane node.
* Use multiple control-plane nodes by completing the
[HA setup](/docs/setup/independent/ha-topology) instead.
## Troubleshooting {#troubleshooting}
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
{{% /capture %}}
content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
-42
View File
@@ -319,46 +319,4 @@ There are at least two workarounds:
```bash
kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule-
```
## `/usr` is mounted read-only on nodes {#usr-mounted-read-only}
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.
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).
On the primary control-plane Node (created using `kubeadm init`) pass the following
file using `--config`:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: InitConfiguration
nodeRegistration:
kubeletExtraArgs:
volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
---
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
controllerManager:
extraArgs:
flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
```
On joining Nodes:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: JoinConfiguration
nodeRegistration:
kubeletExtraArgs:
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.
{{% /capture %}}
content/en/docs/tasks/_index.md
+4
View File
@@ -57,6 +57,10 @@ Configure your application to trust and use the cluster root Certificate Authori
Learn common tasks for administering a cluster.
## Administering Federation
Configure components in a cluster federation.
## Managing Stateful Applications
Perform common tasks for managing Stateful applications, including scaling, deleting, and debugging StatefulSets.
content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+1 -3
View File
@@ -86,9 +86,7 @@ kubectl config --kubeconfig=config-demo set-credentials experimenter --username=
```
{{< note >}}
- To delete a user you can run `kubectl --kubeconfig=config-demo config unset users.<name>`
- To remove a cluster, you can run `kubectl --kubeconfig=config-demo config unset clusters.<name>`
- To remove a context, you can run `kubectl --kubeconfig=config-demo config unset contexts.<name>`
To delete a user you can run `kubectl config unset users.<name>`
{{< /note >}}
Add context details to your configuration file:
content/en/docs/tasks/federation/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
title: "Federation"
weight: 120
---
content/en/docs/tasks/federation/administer-federation/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
title: "Administer Federation Control Plane"
weight: 160
---
content/en/docs/tasks/federation/administer-federation/cluster.md
+119
View File
@@ -0,0 +1,119 @@
---
title: Federated Cluster
content_template: templates/task
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use Clusters API resource in a Federation control plane.
Different than other Kubernetes resources, such as Deployments, Services and ConfigMaps,
clusters only exist in the federation context, i.e. those requests must be submitted to the
federation api-server.
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic [working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general.
{{% /capture %}}
{{% capture steps %}}
## Listing Clusters
To list the clusters available in your federation, you can use [kubectl](/docs/user-guide/kubectl/) by
running:
``` shell
kubectl --context=federation get clusters
```
The `--context=federation` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster. If you submit it to a k8s cluster, you will receive an error saying
```the server doesn't have a resource type "clusters"```
If you passed the correct Federation context but received a message error saying
```No resources found.```
it means that you haven't
added any cluster to the Federation yet.
## Creating a Federated Cluster
Creating a `cluster` resource in federation means joining it to the federation. To do so, you can use
`kubefed join`. Basically, you need to give the new cluster a name and say what is the name of the
context that corresponds to a cluster that hosts the federation. The following example command adds
the cluster `gondor` to the federation running on host cluster `rivendell`:
``` shell
kubefed join gondor --host-cluster-context=rivendell
```
You can find more details on how to do that in the respective section in the
[kubefed guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#adding-a-cluster-to-a-federation).
## Deleting a Federated Cluster
Converse to creating a cluster, deleting a cluster means unjoining this cluster from the
federation. This can be done with `kubefed unjoin` command. To remove the `gondor` cluster, just do:
``` shell
kubefed unjoin gondor --host-cluster-context=rivendell
```
You can find more details on unjoin in the
[kubefed guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#removing-a-cluster-from-a-federation).
## Labeling Clusters
You can label clusters the same way as any other Kubernetes object, which can help with grouping clusters and can also be leveraged by the ClusterSelector.
``` shell
kubectl --context=rivendell label cluster gondor key1=value1 key2=value2
```
## ClusterSelector Annotation
You can use a (deprecated) annotation for directing objects across the federated clusters: `federation.alpha.kubernetes.io/cluster-selector`. The *ClusterSelector* is conceptually similar to `nodeSelector`, but instead of selecting against labels on nodes, it selects against labels on federated clusters.
The annotation value must be JSON formatted and must be parsable into the [ClusterSelector API type](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector). For example: `[{"key": "load", "operator": "Lt", "values": ["10"]}]`. Content that doesn't parse correctly will throw an error and prevent distribution of the object to any federated clusters. Objects of type ConfigMap, Secret, Daemonset, Service and Ingress are included in the alpha implementation.
Here is an example ClusterSelector annotation, which will only select clusters WITH the label `pci=true` and WITHOUT the label `environment=test`:
``` yaml
metadata:
annotations:
federation.alpha.kubernetes.io/cluster-selector: '[{"key": "pci", "operator":
"In", "values": ["true"]}, {"key": "environment", "operator": "NotIn", "values":
["test"]}]'
```
The *key* is matched against label names on the federated clusters.
The *values* are matched against the label values on the federated clusters.
The possible *operators* are: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
The *values* field is expected to be empty when `Exists` or `DoesNotExist` is specified and may include more than one string when `In` or `NotIn` are used.
Currently, only integers are supported with `Gt` or `Lt`.
## Clusters API reference
The full clusters API reference is currently in `federation/v1beta1` and more details can be found in the
[Federation API reference page](/docs/reference/federation/).
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/configmap.md
+89
View File
@@ -0,0 +1,89 @@
---
title: Federated ConfigMap
content_template: templates/task
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use ConfigMaps in a Federation control plane.
Federated ConfigMaps are very similar to the traditional [Kubernetes
ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) and provide the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) in particular.
{{% /capture %}}
{{% capture steps %}}
## Creating a Federated ConfigMap
The API for Federated ConfigMap is 100% compatible with the
API for traditional Kubernetes ConfigMap. You can create a ConfigMap by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f myconfigmap.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a Federated ConfigMap is created, the federation control plane will create
a matching ConfigMap in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get configmap myconfigmap
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
These ConfigMaps in underlying clusters will match the Federated ConfigMap.
## Updating a Federated ConfigMap
You can update a Federated ConfigMap as you would update a Kubernetes
ConfigMap; however, for a Federated ConfigMap, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The federation control plane ensures that whenever the Federated ConfigMap is
updated, it updates the corresponding ConfigMaps in all underlying clusters to
match it.
## Deleting a Federated ConfigMap
You can delete a Federated ConfigMap as you would delete a Kubernetes
ConfigMap; however, for a Federated ConfigMap, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete configmap
```
{{< note >}}
Deleting a Federated ConfigMap does not delete the corresponding ConfigMaps from underlying clusters. You must delete the underlying ConfigMaps manually.
{{< /note >}}
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/daemonset.md
+83
View File
@@ -0,0 +1,83 @@
---
title: Federated DaemonSet
content_template: templates/task
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use DaemonSets in a federation control plane.
DaemonSets in the federation control plane ("Federated Daemonsets" in
this guide) are very similar to the traditional Kubernetes
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/) and provide the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [DaemonSets](/docs/concepts/workloads/controllers/daemonset/) in particular.
{{% /capture %}}
{{% capture steps %}}
## Creating a Federated Daemonset
The API for Federated Daemonset is 100% compatible with the
API for traditional Kubernetes DaemonSet. You can create a DaemonSet by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f mydaemonset.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a Federated Daemonset is created, the federation control plane will create
a matching DaemonSet in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get daemonset mydaemonset
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
## Updating a Federated Daemonset
You can update a Federated Daemonset as you would update a Kubernetes
DaemonSet; however, for a Federated Daemonset, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The federation control plane ensures that whenever the Federated Daemonset is
updated, it updates the corresponding DaemonSets in all underlying clusters to
match it.
## Deleting a Federated Daemonset
You can delete a Federated Daemonset as you would delete a Kubernetes
DaemonSet; however, for a Federated Daemonset, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete daemonset mydaemonset
```
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/deployment.md
+111
View File
@@ -0,0 +1,111 @@
---
title: Federated Deployment
content_template: templates/task
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use Deployments in the Federation control plane.
Deployments in the federation control plane (referred to as "Federated Deployments" in
this guide) are very similar to the traditional [Kubernetes
Deployment](/docs/concepts/workloads/controllers/deployment/) and provide the same functionality.
Creating them in the federation control plane ensures that the desired number of
replicas exist across the registered clusters.
{{< feature-state for_k8s_version="1.5" state="alpha" >}}
Some features
(such as full rollout compatibility) are still in development.
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Deployments](/docs/concepts/workloads/controllers/deployment/) in particular.
{{% /capture %}}
{{% capture steps %}}
## Creating a Federated Deployment
The API for Federated Deployment is compatible with the
API for traditional Kubernetes Deployment. You can create a Deployment by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f mydeployment.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a Federated Deployment is created, the federation control plane will create
a Deployment in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get deployment mydep
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
These Deployments in underlying clusters will match the federation Deployment
_except_ in the number of replicas and revision-related annotations.
Federation control plane ensures that the
sum of replicas in each cluster combined matches the desired number of replicas in the
Federated Deployment.
### Spreading Replicas in Underlying Clusters
By default, replicas are spread equally in all the underlying clusters. For example:
if you have 3 registered clusters and you create a Federated Deployment with
`spec.replicas = 9`, then each Deployment in the 3 clusters will have
`spec.replicas=3`.
To modify the number of replicas in each cluster, you can specify
[FederatedReplicaSetPreference](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go)
as an annotation with key `federation.kubernetes.io/deployment-preferences`
on Federated Deployment.
## Updating a Federated Deployment
You can update a Federated Deployment as you would update a Kubernetes
Deployment; however, for a Federated Deployment, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The federation control plane ensures that whenever the Federated Deployment is
updated, it updates the corresponding Deployments in all underlying clusters to
match it. So if the rolling update strategy was chosen then the underlying
cluster will do the rolling update independently and `maxSurge` and `maxUnavailable`
will apply only to individual clusters. This behavior may change in the future.
If your update includes a change in number of replicas, the federation
control plane will change the number of replicas in underlying clusters to
ensure that their sum remains equal to the number of desired replicas in
Federated Deployment.
## Deleting a Federated Deployment
You can delete a Federated Deployment as you would delete a Kubernetes
Deployment; however, for a Federated Deployment, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete deployment mydep
```
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/events.md
+50
View File
@@ -0,0 +1,50 @@
---
title: Federated Events
content_template: templates/concept
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use events in federation control plane to help in debugging.
{{% /capture %}}
{{% capture body %}}
## Prerequisites
This guide assumes that you have a running Kubernetes Cluster
Federation installation. If not, then head over to the
[federation admin guide](/docs/concepts/cluster-administration/federation/) to learn how to
bring up a cluster federation (or have your cluster administrator do
this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general.
## View federation events
Events in federation control plane (referred to as "federation events" in
this guide) are very similar to the traditional Kubernetes
Events providing the same functionality.
Federation Events are stored only in federation control plane and are not passed on to the underlying Kubernetes clusters.
Federation controllers create events as they process API resources to surface to the
user, the state that they are in.
You can get all events from federation apiserver by running:
```shell
kubectl --context=federation-cluster get events
```
The standard kubectl get, update, delete commands will all work.
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/hpa.md
+184
View File
@@ -0,0 +1,184 @@
---
title: Federated Horizontal Pod Autoscalers (HPA)
content_template: templates/task
---
{{% capture overview %}}
{{< feature-state state="alpha" >}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use federated horizontal pod autoscalers (HPAs) in the federation control plane.
HPAs in the federation control plane are similar to the traditional [Kubernetes
HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/), and provide the same functionality.
Creating an HPA targeting a federated object in the federation control plane ensures that the
desired number of replicas of the target object are scaled across the registered clusters,
instead of a single cluster. Also, the control plane keeps monitoring the status of each
individual HPA in the federated clusters and ensures the workload replicas move where they are
needed most by manipulating the min and max limits of the HPA objects in the federated clusters.
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/) in particular.
The federated HPA is an alpha feature. The API is not enabled by default on the
federated API server. To use this feature, the user or the admin deploying the federation control
plane needs to run the federated API server with option `--runtime-config=api/all=true` to
enable all APIs, including alpha APIs. Additionally, the federated HPA only works
when used with CPU utilization metrics.
{{% /capture %}}
{{% capture steps %}}
## Creating a federated HPA
The API for federated HPAs is 100% compatible with the
API for traditional Kubernetes HPA. You can create an HPA by sending
a request to the federation API server.
You can do that with [kubectl](/docs/user-guide/kubectl/) by running:
```shell
cat <<EOF | kubectl --context=federation-cluster create -f -
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1beta1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50
EOF
```
The `--context=federation-cluster` flag tells `kubectl` to submit the
request to the federation API server instead of sending it to a Kubernetes
cluster.
Once a federated HPA is created, the federation control plane partitions and
creates the HPA in all underlying Kubernetes clusters. As of Kubernetes V1.7,
[cluster selectors](/docs/tasks/administer-federation/cluster/#clusterselector-annotation)
can also be used to restrict any federated object, including the HPAs in a subset
of clusters.
You can verify the creation by checking each of the underlying clusters. For example, with a context named `gce-asia-east1a`
configured in your client for your cluster in that zone:
```shell
kubectl --context=gce-asia-east1a get HPA php-apache
```
The HPA in the underlying clusters will match the federation HPA
except in the number of min and max replicas. The federation control plane ensures that the sum of max replicas in each cluster matches the specified
max replicas on the federated HPA object, and the sum of minimum replicas will be greater
than or equal to the minimum specified on the federated HPA object.
{{< note >}}
A particular cluster cannot have a minimum replica sum of 0.
{{< /note >}}
### Spreading HPA min and max replicas in underlying clusters
By default, first max replicas are spread equally in all the underlying clusters, then min replicas are distributed to those clusters that received their maximum value. This means
that each cluster will get an HPA if the specified max replicas are greater than
the total clusters participating in this federation, and some clusters will be
skipped if specified max replicas are less than the total clusters participating
in the federation.
For example: if you have 3 registered clusters and you create a federated HPA with
`spec.maxReplicas = 9`, and `spec.minReplicas = 2`, then each HPA in the 3 clusters
will get `spec.maxReplicas=3` and `spec.minReplicas = 1`.
Currently the default distribution is only available on the federated HPA, but in the
future, users preferences could also be specified to control and/or restrict this
distribution.
## Updating a federated HPA
You can update a federated HPA as you would update a Kubernetes
HPA; however, for a federated HPA, you must send the request to
the federation API server instead of sending it to a specific Kubernetes cluster.
The Federation control plane ensures that whenever the federated HPA is
updated, it updates the corresponding HPA in all underlying clusters to
match it.
If your update includes a change in the number of replicas, the federation
control plane will change the number of replicas in underlying clusters to
ensure that the sum of the max and min replicas remains matched as specified
in the previous section.
## Deleting a federated HPA
You can delete a federated HPA as you would delete a Kubernetes
HPA; however, for a federated HPA, you must send the request to
the federation API server instead of to a specific Kubernetes cluster.
{{< note >}}
For the federated resource to be deleted from all underlying clusters, [cascading deletion](/docs/concepts/cluster-administration/federation/#cascading-deletion) should be used.
{{< /note >}}
For example, you can do that using `kubectl` by running:
```shell
kubectl --context=federation-cluster delete HPA php-apache
```
## Alternative ways to use federated HPA
To a federation user interacting with federated control plane (or simply federation),
the interaction is almost identical to interacting with a normal Kubernetes cluster (but
with a limited set of APIs that are federated). As both Deployments and
HorizontalPodAutoscalers are now federated, `kubectl` commands like `kubectl run`
and `kubectl autoscale` work on federation. Given this fact, the mechanism specified in
[horizontal pod autoscaler walkthrough](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
will also work when used with federation.
Care however will need to be taken that when
[generating load on a target deployment](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#step-three-increase-load),
it should be done against a specific federated cluster (or multiple clusters) not the federation.
## Conclusion
The use of federated HPA is to ensure workload replicas move to the cluster(s) where
they are needed most, or in other words where the load is beyond expected threshold.
The federated HPA feature achieves this by manipulating the min and max replicas on the
HPAs it creates in the federated clusters. It does not directly monitor the target
object metrics from the federated clusters. It actually relies on the in-cluster HPA
controllers to monitor the metrics and update relevant fields. The in-cluster HPA
controller monitors the target pod metrics and updates the fields like desired
replicas (after metrics based calculations) and current replicas (observing the
current status of in cluster pods). The federated HPA controller, on the other hand,
monitors only the cluster-specific HPA object fields and updates the min replica and
max replica fields of those in cluster HPA objects, which have replicas matching thresholds.
For example, if a cluster has both desired replicas and current replicas the same as the max replicas,
and averaged current CPU utilization still higher than the target CPU utilization (all of which
are fields on local HPA object), then the target app in this cluster
needs more replicas, and the scaling is currently restricted by max replicas set on this local
HPA object. In such a scenario, the federated HPA controller scans all clusters and tries to
find clusters which do not have such a condition (meaning the desired replicas are less
than the max, and current averaged CPU utilization is lower then the threshold). If it finds such
a cluster, it reduces the max replica on the HPA in this cluster and increases the max replicas
on the HPA in the cluster which needed the replicas.
There are many other similar conditions which the federated HPA controller checks and moves the max
replicas and min replicas around the local HPAs in federated clusters to eventually ensure that
the replicas move (or remain) in the cluster(s) which need them.
For more information, see ["federated HPA design proposal"](https://github.com/kubernetes/community/pull/593).
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/ingress.md
+311
View File
@@ -0,0 +1,311 @@
---
title: Federated Ingress
content_template: templates/task
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This page explains how to use Kubernetes Federated Ingress to deploy
a common HTTP(S) virtual IP load balancer across a federated service running in
multiple Kubernetes clusters. As of v1.4, clusters hosted in Google
Cloud (both Google Kubernetes Engine and GCE, or both) are supported. This makes it
easy to deploy a service that reliably serves HTTP(S) traffic
originating from web clients around the globe on a single, static IP
address. Low network latency, high fault tolerance and easy administration are
ensured through intelligent request routing and automatic replica
relocation (using [Federated ReplicaSets](/docs/tasks/administer-federation/replicaset/).
Clients are automatically routed, via the shortest network path, to
the cluster closest to them with available capacity (despite the fact
that all clients use exactly the same static IP address). The load balancer
automatically checks the health of the pods comprising the service,
and avoids sending requests to unresponsive or slow pods (or entire
unresponsive clusters).
Federated Ingress is released as an alpha feature, and supports Google Cloud Platform (Google Kubernetes Engine,
GCE and hybrid scenarios involving both) in Kubernetes v1.4. Work is under way to support other cloud
providers such as AWS, and other hybrid cloud scenarios (e.g. services
spanning private on-premises as well as public cloud Kubernetes
clusters).
You create Federated Ingresses in much that same way as traditional
[Kubernetes Ingresses](/docs/concepts/services-networking/ingress/): by making an API
call which specifies the desired properties of your logical ingress point. In the
case of Federated Ingress, this API call is directed to the
Federation API endpoint, rather than a Kubernetes cluster API
endpoint. The API for Federated Ingress is 100% compatible with the
API for traditional Kubernetes Services.
Once created, the Federated Ingress automatically:
* Creates matching Kubernetes Ingress objects in every cluster underlying your Cluster Federation
* Ensures that all of these in-cluster ingress objects share the same
logical global L7 (that is, HTTP(S)) load balancer and IP address
* Monitors the health and capacity of the service shards (that is, your pods) behind this ingress in each cluster
* Ensures that all client connections are routed to an appropriate healthy backend service endpoint at all times, even in the event of pod, cluster, availability zone or regional outages
Note that in the case of Google Cloud, the logical L7 load balancer is
not a single physical device (which would present both a single point
of failure, and a single global network routing choke point), but
rather a
[truly global, highly available load balancing managed service](https://cloud.google.com/load-balancing/),
globally reachable via a single, static IP address.
Clients inside your federated Kubernetes clusters (Pods) will be
automatically routed to the cluster-local shard of the Federated Service
backing the Ingress in their cluster if it exists and is healthy, or the closest healthy shard in a
different cluster if it does not. Note that this involves a network
trip to the HTTP(s) load balancer, which resides outside your local
Kubernetes cluster but inside the same GCP region.
{{% /capture %}}
{{% capture prerequisites %}}
This document assumes that you have a running Kubernetes Cluster
Federation installation. If not, then see the
[federation admin guide](/docs/tasks/federation/set-up-cluster-federation-kubefed/) to learn how to
bring up a cluster federation (or have your cluster administrator do
this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general, and [Ingress](/docs/concepts/services-networking/ingress/) in particular.
{{% /capture %}}
{{% capture steps %}}
## Creating a federated ingress
You can create a federated ingress in any of the usual ways, for example, using kubectl:
``` shell
kubectl --context=federation-cluster create -f myingress.yaml
```
For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/).
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation API endpoint, with the appropriate
credentials. If you have not yet configured such a context, see the
[federation admin guide](/docs/admin/federation/) or one of the
[administration tutorials](https://github.com/kelseyhightower/kubernetes-cluster-federation)
to find out how to do so.
The Federated Ingress automatically creates
and maintains matching Kubernetes ingresses in all of the clusters
underlying your federation. These cluster-specific ingresses (and
their associated ingress controllers) configure and manage the load
balancing and health checking infrastructure that ensures that traffic
is load balanced to each cluster appropriately.
You can verify this by checking in each of the underlying clusters. For example:
``` shell
kubectl --context=gce-asia-east1a get ingress myingress
NAME HOSTS ADDRESS PORTS AGE
myingress * 130.211.5.194 80, 443 1m
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone. The name and
namespace of the underlying ingress automatically matches those of
the Federated Ingress that you created above (and if you happen to
have had ingresses of the same name and namespace already existing in
any of those clusters, they will be automatically adopted by the
Federation and updated to conform with the specification of your
Federated Ingress. Either way, the end result will be the same).
The status of your Federated Ingress automatically reflects the
real-time status of the underlying Kubernetes ingresses. For example:
``` shell
kubectl --context=federation-cluster describe ingress myingress
Name: myingress
Namespace: default
Address: 130.211.5.194
TLS:
tls-secret terminates
Rules:
Host Path Backends
---- ---- --------
* * echoheaders-https:80 (10.152.1.3:8080,10.152.2.4:8080)
Annotations:
https-target-proxy: k8s-tps-default-myingress--ff1107f83ed600c0
target-proxy: k8s-tp-default-myingress--ff1107f83ed600c0
url-map: k8s-um-default-myingress--ff1107f83ed600c0
backends: {"k8s-be-30301--ff1107f83ed600c0":"Unknown"}
forwarding-rule: k8s-fw-default-myingress--ff1107f83ed600c0
https-forwarding-rule: k8s-fws-default-myingress--ff1107f83ed600c0
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
3m 3m 1 {loadbalancer-controller } Normal ADD default/myingress
2m 2m 1 {loadbalancer-controller } Normal CREATE ip: 130.211.5.194
```
Note that:
* The address of your Federated Ingress
corresponds with the address of all of the
underlying Kubernetes ingresses (once these have been allocated - this
may take up to a few minutes).
* You have not yet provisioned any backend Pods to receive
the network traffic directed to this ingress (that is, 'Service
Endpoints' behind the service backing the Ingress), so the Federated Ingress does not yet consider these to
be healthy shards and will not direct traffic to any of these clusters.
* The federation control system
automatically reconfigures the load balancer controllers in all of the
clusters in your federation to make them consistent, and allows
them to share global load balancers. But this reconfiguration can
only complete successfully if there are no pre-existing Ingresses in
those clusters (this is a safety feature to prevent accidental
breakage of existing ingresses). So, to ensure that your federated
ingresses function correctly, either start with new, empty clusters, or make
sure that you delete (and recreate if necessary) all pre-existing
Ingresses in the clusters comprising your federation.
## Adding backend services and pods
To render the underlying ingress shards healthy, you need to add
backend Pods behind the service upon which the Ingress is based. There are several ways to achieve this, but
the easiest is to create a Federated Service and
Federated ReplicaSet. To
create appropriately labelled pods and services in the 13 underlying clusters of
your federation:
``` shell
kubectl --context=federation-cluster create -f services/nginx.yaml
```
``` shell
kubectl --context=federation-cluster create -f myreplicaset.yaml
```
Note that in order for your federated ingress to work correctly on
Google Cloud, the node ports of all of the underlying cluster-local
services need to be identical. If you're using a federated service
this is easy to do. Simply pick a node port that is not already
being used in any of your clusters, and add that to the spec of your
federated service. If you do not specify a node port for your
federated service, each cluster will choose its own node port for
its cluster-local shard of the service, and these will probably end
up being different, which is not what you want.
You can verify this by checking in each of the underlying clusters. For example:
``` shell
kubectl --context=gce-asia-east1a get services nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP 10.63.250.98 104.199.136.89 80/TCP 9m
```
## Hybrid cloud capabilities
Federations of Kubernetes Clusters can include clusters running in
different cloud providers (for example, Google Cloud, AWS), and on-premises
(for example, on OpenStack). However, in Kubernetes v1.4, Federated Ingress is only
supported across Google Cloud clusters.
## Discovering a federated ingress
Ingress objects (in both plain Kubernetes clusters, and in federations
of clusters) expose one or more IP addresses (via
the Status.Loadbalancer.Ingress field) that remains static for the lifetime
of the Ingress object (in future, automatically managed DNS names
might also be added). All clients (whether internal to your cluster,
or on the external network or internet) should connect to one of these IP
or DNS addresses. All client requests are automatically
routed, via the shortest network path, to a healthy pod in the
closest cluster to the origin of the request. So for example, HTTP(S)
requests from internet
users in Europe will be routed directly to the closest cluster in
Europe that has available capacity. If there are no such clusters in
Europe, the request will be routed to the next closest cluster
(typically in the U.S.).
## Handling failures of backend pods and whole clusters
Ingresses are backed by Services, which are typically (but not always)
backed by one or more ReplicaSets. For Federated Ingresses, it is
common practise to use the federated variants of Services and
ReplicaSets for this purpose.
In particular, Federated ReplicaSets ensure that the desired number of
pods are kept running in each cluster, even in the event of node
failures. In the event of entire cluster or availability zone
failures, Federated ReplicaSets automatically place additional
replicas in the other available clusters in the federation to accommodate the
traffic which was previously being served by the now unavailable
cluster. While the Federated ReplicaSet ensures that sufficient replicas are
kept running, the Federated Ingress ensures that user traffic is
automatically redirected away from the failed cluster to other
available clusters.
## Troubleshooting
#### I cannot connect to my cluster federation API.
Check that your:
1. Client (typically `kubectl`) is correctly configured (including API endpoints and login credentials).
2. Cluster Federation API server is running and network-reachable.
See the [federation admin guide](/docs/admin/federation/) to learn
how to bring up a cluster federation correctly (or have your cluster administrator do this for you), and how to correctly configure your client.
#### I can create a Federated Ingress/service/replicaset successfully against the cluster federation API, but no matching ingresses/services/replicasets are created in my underlying clusters.
Check that:
1. Your clusters are correctly registered in the Cluster Federation API. (`kubectl describe clusters`)
2. Your clusters are all 'Active'. This means that the cluster
Federation system was able to connect and authenticate against the
clusters' endpoints. If not, consult the event logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name`)
3. That the login credentials provided to the Cluster Federation API
for the clusters have the correct authorization and quota to create
ingresses/services/replicasets in the relevant namespace in the
clusters. Again you should see associated error messages providing
more detail in the above event log file if this is not the case.
4. Whether any other error is preventing the service creation
operation from succeeding (look for `ingress-controller`,
`service-controller` or `replicaset-controller`,
errors in the output of `kubectl logs federation-controller-manager --namespace federation`).
#### I can create a federated ingress successfully, but request load is not correctly distributed across the underlying clusters.
Check that:
1. The services underlying your federated ingress in each cluster have
identical node ports. See [above](#creating_a_federated_ingress) for further explanation.
2. The load balancer controllers in each of your clusters are of the
correct type ("GLBC") and have been correctly reconfigured by the
federation control plane to share a global GCE load balancer (this
should happen automatically). If they are of the correct type, and
have been correctly reconfigured, the UID data item in the GLBC
configmap in each cluster will be identical across all clusters.
See
[the GLBC docs](https://github.com/kubernetes/ingress/blob/7dcb4ae17d5def23d3e9c878f3146ac6df61b09d/controllers/gce/README.md)
for further details.
If this is not the case, check the logs of your federation
controller manager to determine why this automated reconfiguration
might be failing.
3. No ingresses have been manually created in any of your clusters before the above
reconfiguration of the load balancer controller completed
successfully. Ingresses created before the reconfiguration of
your GLBC will interfere with the behavior of your federated
ingresses created after the reconfiguration (see
[the GLBC docs](https://github.com/kubernetes/ingress/blob/7dcb4ae17d5def23d3e9c878f3146ac6df61b09d/controllers/gce/README.md)
for further information). To remedy this,
delete any ingresses created before the cluster joined the
federation (and had its GLBC reconfigured), and recreate them if
necessary.
{{% /capture %}}
{{% capture whatsnext %}}
* If you need assistance, use one of the [support channels](/docs/tasks/debug-application-cluster/troubleshooting/) to seek assistance.
* For details about use cases that motivated this work, see
[Federation proposal](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md).
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/job.md
+109
View File
@@ -0,0 +1,109 @@
---
title: Federated Jobs
content_template: templates/task
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use jobs in the federation control plane.
Jobs in the federation control plane (referred to as "federated jobs" in
this guide) are similar to the traditional [Kubernetes
jobs](/docs/concepts/workloads/controllers/job/), and provide the same functionality.
Creating jobs in the federation control plane ensures that the desired number of
parallelism and completions exist across the registered clusters.
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) in particular.
{{% /capture %}}
{{% capture steps %}}
## Creating a federated job
The API for federated jobs is fully compatible with the
API for traditional Kubernetes jobs. You can create a job by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f myjob.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the federation API server instead of sending it to a Kubernetes
cluster.
Once a federated job is created, the federation control plane creates
a job in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get job myjob
```
The previous example assumes that you have a context named `gce-asia-east1a`
configured in your client for your cluster in that zone.
The jobs in the underlying clusters match the federated job
except in the number of parallelism and completions. The federation control plane ensures that the
sum of the parallelism and completions in each cluster matches the desired number of parallelism and completions in the
federated job.
### Spreading job tasks in underlying clusters
By default, parallelism and completions are spread equally in all underlying clusters. For example:
if you have 3 registered clusters and you create a federated job with
`spec.parallelism = 9` and `spec.completions = 18`, then each job in the 3 clusters has
`spec.parallelism = 3` and `spec.completions = 6`.
To modify the number of parallelism and completions in each cluster, you can specify
[ReplicaAllocationPreferences](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go)
as an annotation with key `federation.kubernetes.io/job-preferences`
on the federated job.
## Updating a federated job
You can update a federated job as you would update a Kubernetes
job; however, for a federated job, you must send the request to
the federation API server instead of sending it to a specific Kubernetes cluster.
The federation control plane ensures that whenever the federated job is
updated, it updates the corresponding job in all underlying clusters to
match it.
If your update includes a change in number of parallelism and completions, the federation
control plane changes the number of parallelism and completions in underlying clusters to
ensure that their sum remains equal to the number of desired parallelism and completions in
federated job.
## Deleting a federated job
You can delete a federated job as you would delete a Kubernetes
job; however, for a federated job, you must send the request to
the federation API server instead of sending it to a specific Kubernetes cluster.
For example, with kubectl:
```shell
kubectl --context=federation-cluster delete job myjob
```
{{< note >}}
Deleting a federated job will not delete the
corresponding jobs from underlying clusters.
You must delete the underlying jobs manually.
{{< /note >}}
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/namespaces.md
+92
View File
@@ -0,0 +1,92 @@
---
title: Federated Namespaces
content_template: templates/task
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use Namespaces in Federation control plane.
Namespaces in federation control plane (referred to as "federated Namespaces" in
this guide) are very similar to the traditional [Kubernetes
Namespaces](/docs/concepts/overview/working-with-objects/namespaces/) providing the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You are also expected to have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/) in particular.
{{% /capture %}}
{{% capture steps %}}
## Creating a Federated Namespace
The API for Federated Namespaces is 100% compatible with the
API for traditional Kubernetes Namespaces. You can create a Namespace by sending
a request to the federation apiserver.
You can do that using kubectl by running:
``` shell
kubectl --context=federation-cluster create -f myns.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a federated Namespace is created, the federation control plane will create
a matching Namespace in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get namespaces myns
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone. The name and
spec of the underlying Namespace will match those of
the Federated Namespace that you created above.
## Updating a Federated Namespace
You can update a federated Namespace as you would update a Kubernetes
Namespace, just send the request to federation apiserver instead of sending it
to a specific Kubernetes cluster.
Federation control plane will ensure that whenever the federated Namespace is
updated, it updates the corresponding Namespaces in all underlying clusters to
match it.
## Deleting a Federated Namespace
You can delete a federated Namespace as you would delete a Kubernetes
Namespace, just send the request to federation apiserver instead of sending it
to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete ns myns
```
As in Kubernetes, deleting a federated Namespace will delete all resources in that
Namespace from the federation control plane.
{{< note >}}
At this point, deleting a federated Namespace will not delete the corresponding Namespace, or resources in those Namespaces, from underlying clusters. Users must delete them manually. We intend to fix this in the future.
{{< /note >}}
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/replicaset.md
+132
View File
@@ -0,0 +1,132 @@
---
title: Federated ReplicaSets
content_template: templates/task
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use ReplicaSets in the Federation control plane.
ReplicaSets in the federation control plane (referred to as "federated ReplicaSets" in
this guide) are very similar to the traditional [Kubernetes
ReplicaSets](/docs/concepts/workloads/controllers/replicaset/), and provide the same functionality.
Creating them in the federation control plane ensures that the desired number of
replicas exist across the registered clusters.
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) in particular.
{{% /capture %}}
{{% capture steps %}}
## Creating a Federated ReplicaSet
The API for Federated ReplicaSet is 100% compatible with the
API for traditional Kubernetes ReplicaSet. You can create a ReplicaSet by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f myrs.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a federated ReplicaSet is created, the federation control plane will create
a ReplicaSet in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get rs myrs
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
The ReplicaSets in the underlying clusters will match the federation ReplicaSet
except in the number of replicas. The federation control plane will ensure that the
sum of the replicas in each cluster match the desired number of replicas in the
federation ReplicaSet.
### Spreading Replicas in Underlying Clusters
By default, replicas are spread equally in all the underlying clusters. For example:
if you have 3 registered clusters and you create a federated ReplicaSet with
`spec.replicas = 9`, then each ReplicaSet in the 3 clusters will have
`spec.replicas=3`.
To modify the number of replicas in each cluster, you can add an annotation with
key `federation.kubernetes.io/replica-set-preferences` to the federated ReplicaSet.
The value of the annoation is a serialized JSON that contains fields shown in
the following example:
```
{
"rebalance": true,
"clusters": {
"foo": {
"minReplicas": 10,
"maxReplicas": 50,
"weight": 100
},
"bar": {
"minReplicas": 10,
"maxReplicas": 100,
"weight": 200
}
}
}
```
The `rebalance` boolean field specifies whether replicas already scheduled and running
may be moved in order to match current state to the specified preferences.
The `clusters` object field contains a map where users can specify the constraints
for replica placement across the clusters (`foo` and `bar` in the example).
For each cluster, you can specify the minimum number of replicas that should be
assigned to it (default is zero), the maximum number of replicas the cluster can
accept (default is unbounded) and a number expressing the relative weight of
preferences to place additional replicas to that cluster.
## Updating a Federated ReplicaSet
You can update a federated ReplicaSet as you would update a Kubernetes
ReplicaSet; however, for a federated ReplicaSet, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The Federation control plane ensures that whenever the federated ReplicaSet is
updated, it updates the corresponding ReplicaSet in all underlying clusters to
match it.
If your update includes a change in number of replicas, the federation
control plane will change the number of replicas in underlying clusters to
ensure that their sum remains equal to the number of desired replicas in
federated ReplicaSet.
## Deleting a Federated ReplicaSet
You can delete a federated ReplicaSet as you would delete a Kubernetes
ReplicaSet; however, for a federated ReplicaSet, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete rs myrs
```
{{< note >}}
At this point, deleting a federated ReplicaSet will not delete the corresponding ReplicaSets from underlying clusters. You must delete the underlying ReplicaSets manually. We intend to fix this in the future.
{{< /note >}}
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/secret.md
+93
View File
@@ -0,0 +1,93 @@
---
title: Federated Secrets
content_template: templates/concept
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use secrets in Federation control plane.
Secrets in federation control plane (referred to as "federated secrets" in
this guide) are very similar to the traditional [Kubernetes
Secrets](/docs/concepts/configuration/secret/) providing the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
{{% /capture %}}
{{% capture body %}}
## Prerequisites
This guide assumes that you have a running Kubernetes Cluster
Federation installation. If not, then head over to the
[federation admin guide](/docs/admin/federation/) to learn how to
bring up a cluster federation (or have your cluster administrator do
this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Secrets](/docs/concepts/configuration/secret/) in particular.
## Creating a Federated Secret
The API for Federated Secret is 100% compatible with the
API for traditional Kubernetes Secret. You can create a secret by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f mysecret.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a federated secret is created, the federation control plane will create
a matching secret in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get secret mysecret
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
These secrets in underlying clusters will match the federated secret.
## Updating a Federated Secret
You can update a federated secret as you would update a Kubernetes
secret; however, for a federated secret, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The Federation control plane ensures that whenever the federated secret is
updated, it updates the corresponding secrets in all underlying clusters to
match it.
## Deleting a Federated Secret
You can delete a federated secret as you would delete a Kubernetes
secret; however, for a federated secret, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete secret mysecret
```
{{< note >}}
At this point, deleting a federated secret will not delete the corresponding secrets from underlying clusters. You must delete the underlying secrets manually. We intend to fix this in the future.
{{< /note >}}
{{% /capture %}}
content/en/docs/tasks/federation/federation-service-discovery.md
+416
View File
@@ -0,0 +1,416 @@
---
title: Cross-cluster Service Discovery using Federated Services
reviewers:
- bprashanth
- quinton-hoole
content_template: templates/task
weight: 140
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This guide explains how to use Kubernetes Federated Services to deploy
a common Service across multiple Kubernetes clusters. This makes it
easy to achieve cross-cluster service discovery and availability zone
fault tolerance for your Kubernetes applications.
Federated Services are created in much that same way as traditional
[Kubernetes Services](/docs/concepts/services-networking/service/) by making an API
call which specifies the desired properties of your service. In the
case of Federated Services, this API call is directed to the
Federation API endpoint, rather than a Kubernetes cluster API
endpoint. The API for Federated Services is 100% compatible with the
API for traditional Kubernetes Services.
Once created, the Federated Service automatically:
1. Creates matching Kubernetes Services in every cluster underlying your Cluster Federation,
2. Monitors the health of those service "shards" (and the clusters in which they reside), and
3. Manages a set of DNS records in a public DNS provider (like Google Cloud DNS, or AWS Route 53), thus ensuring that clients
of your federated service can seamlessly locate an appropriate healthy service endpoint at all times, even in the event of cluster,
availability zone or regional outages.
Clients inside your federated Kubernetes clusters (that is Pods) will
automatically find the local shard of the Federated Service in their
cluster if it exists and is healthy, or the closest healthy shard in a
different cluster if it does not.
{{% /capture %}}
{{< toc >}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## Prerequisites
This guide assumes that you have a running Kubernetes Cluster
Federation installation. If not, then head over to the
[federation admin guide](/docs/admin/federation/) to learn how to
bring up a cluster federation (or have your cluster administrator do
this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general, and [Services](/docs/concepts/services-networking/service/) in particular.
## Hybrid cloud capabilities
Federations of Kubernetes Clusters can include clusters running in
different cloud providers (such as Google Cloud or AWS), and on-premises
(such as on OpenStack). Simply create all of the clusters that you
require, in the appropriate cloud providers and/or locations, and
register each cluster's API endpoint and credentials with your
Federation API Server (See the
[federation admin guide](/docs/admin/federation/) for details).
Thereafter, your applications and services can span different clusters
and cloud providers as described in more detail below.
## Creating a federated service
This is done in the usual way, for example:
``` shell
kubectl --context=federation-cluster create -f services/nginx.yaml
```
The '--context=federation-cluster' flag tells kubectl to submit the
request to the Federation API endpoint, with the appropriate
credentials. If you have not yet configured such a context, visit the
[federation admin guide](/docs/admin/federation/) or one of the
[administration tutorials](https://github.com/kelseyhightower/kubernetes-cluster-federation)
to find out how to do so.
As described above, the Federated Service will automatically create
and maintain matching Kubernetes services in all of the clusters
underlying your federation.
You can verify this by checking in each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get services nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP 10.63.250.98 104.199.136.89 80/TCP 9m
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone. The name and
namespace of the underlying services will automatically match those of
the Federated Service that you created above (and if you happen to
have had services of the same name and namespace already existing in
any of those clusters, they will be automatically adopted by the
Federation and updated to conform with the specification of your
Federated Service - either way, the end result will be the same).
The status of your Federated Service will automatically reflect the
real-time status of the underlying Kubernetes services, for example:
``` shell
kubectl --context=federation-cluster describe services nginx
```
```
Name: nginx
Namespace: default
Labels: run=nginx
Annotations: <none>
Selector: run=nginx
Type: LoadBalancer
IP: 10.63.250.98
LoadBalancer Ingress: 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199.136.89, ...
Port: http 80/TCP
Endpoints: <none>
Session Affinity: None
Events: <none>
```
{{< note >}}
The 'LoadBalancer Ingress' addresses of your Federated Service
correspond with the 'LoadBalancer Ingress' addresses of all of the
underlying Kubernetes services (once these have been allocated - this
may take a few seconds). For inter-cluster and inter-cloud-provider
networking between service shards to work correctly, your services
need to have an externally visible IP address. [Service Type:
Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)
is typically used for this, although other options
(for example [External IPs](/docs/concepts/services-networking/service/#external-ips)) exist.
{{< /note >}}
Note also that we have not yet provisioned any backend Pods to receive
the network traffic directed to these addresses (that is 'Service
Endpoints'), so the Federated Service does not yet consider these to
be healthy service shards, and has accordingly not yet added their
addresses to the DNS records for this Federated Service (more on this
aspect later).
## Adding backend pods
To render the underlying service shards healthy, we need to add
backend Pods behind them. This is currently done directly against the
API endpoints of the underlying clusters (although in future the
Federation server will be able to do all this for you with a single
command, to save you the trouble). For example, to create backend Pods
in 13 underlying clusters:
``` shell
for CLUSTER in asia-east1-c asia-east1-a asia-east1-b \
europe-west1-d europe-west1-c europe-west1-b \
us-central1-f us-central1-a us-central1-b us-central1-c \
us-east1-d us-east1-c us-east1-b
do
kubectl --context=$CLUSTER run nginx --image=nginx:1.11.1-alpine --port=80
done
```
Note that `kubectl run` automatically adds the `run=nginx` labels required to associate the backend pods with their services.
## Verifying public DNS records
Once the above Pods have successfully started and have begun listening
for connections, Kubernetes will report them as healthy endpoints of
the service in that cluster (through automatic health checks). The Cluster
Federation will in turn consider each of these
service 'shards' to be healthy, and place them in serving by
automatically configuring corresponding public DNS records. You can
use your preferred interface to your configured DNS provider to verify
this. For example, if your Federation is configured to use Google
Cloud DNS, and a managed DNS domain 'example.com':
``` shell
gcloud dns managed-zones describe example-dot-com
```
```
creationTime: '2016-06-26T18:18:39.229Z'
description: Example domain for Kubernetes Cluster Federation
dnsName: example.com.
id: '3229332181334243121'
kind: dns#managedZone
name: example-dot-com
nameServers:
- ns-cloud-a1.googledomains.com.
- ns-cloud-a2.googledomains.com.
- ns-cloud-a3.googledomains.com.
- ns-cloud-a4.googledomains.com.
```
```shell
gcloud dns record-sets list --zone example-dot-com
```
```
NAME TYPE TTL DATA
example.com. NS 21600 ns-cloud-e1.googledomains.com., ns-cloud-e2.googledomains.com.
example.com. OA 21600 ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 1209600 300
nginx.mynamespace.myfederation.svc.example.com. A 180 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199.136.89,...
nginx.mynamespace.myfederation.svc.us-central1-a.example.com. A 180 104.197.247.191
nginx.mynamespace.myfederation.svc.us-central1-b.example.com. A 180 104.197.244.180
nginx.mynamespace.myfederation.svc.us-central1-c.example.com. A 180 104.197.245.170
nginx.mynamespace.myfederation.svc.us-central1-f.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.us-central1.example.com.
nginx.mynamespace.myfederation.svc.us-central1.example.com. A 180 104.197.247.191, 104.197.244.180, 104.197.245.170
nginx.mynamespace.myfederation.svc.asia-east1-a.example.com. A 180 130.211.57.243
nginx.mynamespace.myfederation.svc.asia-east1-b.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.asia-east1.example.com.
nginx.mynamespace.myfederation.svc.asia-east1-c.example.com. A 180 130.211.56.221
nginx.mynamespace.myfederation.svc.asia-east1.example.com. A 180 130.211.57.243, 130.211.56.221
nginx.mynamespace.myfederation.svc.europe-west1.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.example.com.
nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.europe-west1.example.com.
... etc.
```
{{< note >}}
If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example:
``` shell
aws route53 list-hosted-zones
```
and
``` shell
aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX
```
{{< /note >}}
Whatever DNS provider you use, any DNS query tool (for example 'dig'
or 'nslookup') will of course also allow you to see the records
created by the Federation for you. Note that you should either point
these tools directly at your DNS provider (such as `dig
@ns-cloud-e1.googledomains.com...`) or expect delays in the order of
your configured TTL (180 seconds, by default) before seeing updates,
due to caching by intermediate DNS servers.
### Some notes about the above example
1. Notice that there is a normal ('A') record for each service shard that has at least one healthy backend endpoint. For example, in us-central1-a, 104.197.247.191 is the external IP address of the service shard in that zone, and in asia-east1-a the address is 130.211.56.221.
2. Similarly, there are regional 'A' records which include all healthy shards in that region. For example, 'us-central1'. These regional records are useful for clients which do not have a particular zone preference, and as a building block for the automated locality and failover mechanism described below.
3. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone. In the example, the service shard in us-central1-f currently has no healthy backend endpoints (that is Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
4. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.').
The above set of DNS records is automatically kept in sync with the
current state of health of all service shards globally by the
Federated Service system. DNS resolver libraries (which are invoked by
all clients) automatically traverse the hierarchy of 'CNAME' and 'A'
records to return the correct set of healthy IP addresses. Clients can
then select any one of the returned addresses to initiate a network
connection (and fail over automatically to one of the other equivalent
addresses if required).
## Discovering a federated service
### From pods inside your federated clusters
By default, Kubernetes clusters come pre-configured with a
cluster-local DNS server ('KubeDNS'), as well as an intelligently
constructed DNS search path which together ensure that DNS queries
like "myservice", "myservice.mynamespace",
"bobsservice.othernamespace" etc issued by your software running
inside Pods are automatically expanded and resolved correctly to the
appropriate service IP of services running in the local cluster.
With the introduction of Federated Services and Cross-Cluster Service
Discovery, this concept is extended to cover Kubernetes services
running in any other cluster across your Cluster Federation, globally.
To take advantage of this extended range, you use a slightly different
DNS name of the form ```"<servicename>.<namespace>.<federationname>"```
to resolve Federated Services. For example, you might use
`myservice.mynamespace.myfederation`. Using a different DNS name also
avoids having your existing applications accidentally traversing
cross-zone or cross-region networks and you incurring perhaps unwanted
network charges or latency, without you explicitly opting in to this
behavior.
So, using our NGINX example service above, and the Federated Service
DNS name form just described, let's consider an example: A Pod in a
cluster in the `us-central1-f` availability zone needs to contact our
NGINX service. Rather than use the service's traditional cluster-local
DNS name (`"nginx.mynamespace"`, which is automatically expanded
to `"nginx.mynamespace.svc.cluster.local"`) it can now use the
service's Federated DNS name, which is
`"nginx.mynamespace.myfederation"`. This will be automatically
expanded and resolved to the closest healthy shard of my NGINX
service, wherever in the world that may be. If a healthy shard exists
in the local cluster, that service's cluster-local (typically
10.x.y.z) IP address will be returned (by the cluster-local KubeDNS).
This is almost exactly equivalent to non-federated service resolution
(almost because KubeDNS actually returns both a CNAME and an A record
for local federated services, but applications will be oblivious
to this minor technical difference).
But if the service does not exist in the local cluster (or it exists
but has no healthy backend pods), the DNS query is automatically
expanded to ```"nginx.mynamespace.myfederation.svc.us-central1-f.example.com"```
(that is, logically "find the external IP of one of the shards closest to
my availability zone"). This expansion is performed automatically by
KubeDNS, which returns the associated CNAME record. This results in
automatic traversal of the hierarchy of DNS records in the above
example, and ends up at one of the external IPs of the Federated
Service in the local us-central1 region (that is 104.197.247.191,
104.197.244.180 or 104.197.245.170).
It is of course possible to explicitly target service shards in
availability zones and regions other than the ones local to a Pod by
specifying the appropriate DNS names explicitly, and not relying on
automatic DNS expansion. For example,
"nginx.mynamespace.myfederation.svc.europe-west1.example.com" will
resolve to all of the currently healthy service shards in Europe, even
if the Pod issuing the lookup is located in the U.S., and irrespective
of whether or not there are healthy shards of the service in the U.S.
This is useful for remote monitoring and other similar applications.
### From other clients outside your federated clusters
Much of the above discussion applies equally to external clients,
except that the automatic DNS expansion described is no longer
possible. So external clients need to specify one of the fully
qualified DNS names of the Federated Service, be that a zonal,
regional or global name. For convenience reasons, it is often a good
idea to manually configure additional static CNAME records in your
service, for example:
``` shell
eu.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.europe-west1.example.com.
us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.example.com.
nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com.
```
That way your clients can always use the short form on the left, and
always be automatically routed to the closest healthy shard on their
home continent. All of the required failover is handled for you
automatically by Kubernetes Cluster Federation. Future releases will
improve upon this even further.
## Handling failures of backend pods and whole clusters
Standard Kubernetes service cluster-IP's already ensure that
non-responsive individual Pod endpoints are automatically taken out of
service with low latency (a few seconds). In addition, as alluded
above, the Kubernetes Cluster Federation system automatically monitors
the health of clusters and the endpoints behind all of the shards of
your Federated Service, taking shards in and out of service as
required (for example, when all of the endpoints behind a service, or perhaps
the entire cluster or availability zone go down, or conversely recover
from an outage). Due to the latency inherent in DNS caching (the cache
timeout, or TTL for Federated Service DNS records is configured to 3
minutes, by default, but can be adjusted), it may take up to that long
for all clients to completely fail over to an alternative cluster in
the case of catastrophic failure. However, given the number of
discrete IP addresses which can be returned for each regional service
endpoint (such as us-central1 above, which has three alternatives)
many clients will fail over automatically to one of the alternative
IP's in less time than that given appropriate configuration.
{{% /capture %}}
{{% capture discussion %}}
## Troubleshooting
### I cannot connect to my cluster federation API
Check that your
1. Client (typically kubectl) is correctly configured (including API endpoints and login credentials).
2. Cluster Federation API server is running and network-reachable.
See the [federation admin guide](/docs/admin/federation/) to learn
how to bring up a cluster federation correctly (or have your cluster administrator do this for you), and how to correctly configure your client.
### I can create a federated service successfully against the cluster federation API, but no matching services are created in my underlying clusters
Check that:
1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`).
2. Your clusters are all 'Active'. This means that the cluster Federation system was able to connect and authenticate against the clusters' endpoints. If not, consult the logs of the federation-controller-manager pod to ascertain what the failure might be.
```
kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name)
```
3. That the login credentials provided to the Cluster Federation API for the clusters have the correct authorization and quota to create services in the relevant namespace in the clusters. Again you should see associated error messages providing more detail in the above log file if this is not the case.
4. Whether any other error is preventing the service creation operation from succeeding (look for `service-controller` errors in the output of `kubectl logs federation-controller-manager --namespace federation`).
### I can create a federated service successfully, but no matching DNS records are created in my DNS provider.
Check that:
1. Your federation name, DNS provider, DNS domain name are configured correctly. Consult the [federation admin guide](/docs/admin/federation/) or [tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation) to learn
how to configure your Cluster Federation system's DNS provider (or have your cluster administrator do this for you).
2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`).
3. Confirm that the Cluster Federation's service-controller is successfully creating DNS records in your DNS provider (or outputting errors in its logs explaining in more detail what's failing).
### Matching DNS records are created in my DNS provider, but clients are unable to resolve against those names
Check that:
1. The DNS registrar that manages your federation DNS domain has been correctly configured to point to your configured DNS provider's nameservers. See for example [Google Domains Documentation](https://support.google.com/domains/answer/3290309?hl=en&ref_topic=3251230) and [Google Cloud DNS Documentation](https://cloud.google.com/dns/update-name-servers), or equivalent guidance from your domain registrar and DNS provider.
### This troubleshooting guide did not help me solve my problem
1. Please use one of our [support channels](/docs/tasks/debug-application-cluster/troubleshooting/) to seek assistance.
## For more information
* [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md) details use cases that motivated this work.
{{% /capture %}}
content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md
+564
View File
@@ -0,0 +1,564 @@
---
title: Set up Cluster Federation with Kubefed
reviewers:
- madhusudancs
content_template: templates/task
weight: 125
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
Kubernetes version 1.5 and above includes a new command line tool called
[`kubefed`](/docs/admin/kubefed/) to help you administrate your federated
clusters. `kubefed` helps you to deploy a new Kubernetes cluster federation
control plane, and to add clusters to or remove clusters from an existing
federation control plane.
This guide explains how to administer a Kubernetes Cluster Federation
using `kubefed`.
> Note: `kubefed` is a beta feature in Kubernetes 1.6.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## Prerequisites
This guide assumes that you have a running Kubernetes cluster. Please
see one of the [getting started](/docs/setup/) guides
for installation instructions for your platform.
## Getting `kubefed`
Download the client tarball corresponding to the particular release and
extract the binaries in the tarball:
{{< note >}}
Until Kubernetes version `1.8.x` the federation project was
maintained as part of the [core kubernetes repo](https://github.com/kubernetes/kubernetes).
Between Kubernetes releases `1.8` and `1.9`, the federation project moved into
a separate [federation repo](https://github.com/kubernetes/federation), where it is
now maintained. Consequently, the federation release information is available on the
[release page](https://github.com/kubernetes/federation/releases).
{{< /note >}}
### For Kubernetes versions 1.8.x and earlier:
```shell
curl -LO https://storage.googleapis.com/kubernetes-release/release/${RELEASE-VERSION}/kubernetes-client-linux-amd64.tar.gz
tar -xzvf kubernetes-client-linux-amd64.tar.gz
```
{{< note >}}
The `RELEASE-VERSION` variable should either be set to or replaced with the actual version needed.
{{< /note >}}
Copy the extracted binary to one of the directories in your `$PATH`
and set the executable permission on the binary.
```shell
sudo cp kubernetes/client/bin/kubefed /usr/local/bin
sudo chmod +x /usr/local/bin/kubefed
```
### For Kubernetes versions 1.9.x and above:
```shell
curl -LO https://storage.cloud.google.com/kubernetes-federation-release/release/${RELEASE-VERSION}/federation-client-linux-amd64.tar.gz
tar -xzvf federation-client-linux-amd64.tar.gz
```
{{< note >}}
The `RELEASE-VERSION` variable should be replaced with one of the release versions available at [federation release page](https://github.com/kubernetes/federation/releases).
{{< /note >}}
Copy the extracted binary to one of the directories in your `$PATH`
and set the executable permission on the binary.
```shell
sudo cp federation/client/bin/kubefed /usr/local/bin
sudo chmod +x /usr/local/bin/kubefed
```
### Install kubectl
You can install a matching version of kubectl using the instructions on
the [kubectl install page](/docs/tasks/tools/install-kubectl/).
## Choosing a host cluster.
You'll need to choose one of your Kubernetes clusters to be the
*host cluster*. The host cluster hosts the components that make up
your federation control plane. Ensure that you have a `kubeconfig`
entry in your local `kubeconfig` that corresponds to the host cluster.
You can verify that you have the required `kubeconfig` entry by
running:
```shell
kubectl config get-contexts
```
The output should contain an entry corresponding to your host cluster,
similar to the following:
```
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1
```
You'll need to provide the `kubeconfig` context (called name in the
entry above) for your host cluster when you deploy your federation
control plane.
## Deploying a federation control plane
To deploy a federation control plane on your host cluster, run
[`kubefed init`](/docs/admin/kubefed_init/) command. When you use
`kubefed init`, you must provide the following:
* Federation name
* `--host-cluster-context`, the `kubeconfig` context for the host cluster
* `--dns-provider`, one of `'google-clouddns'`, `aws-route53` or `coredns`
* `--dns-zone-name`, a domain name suffix for your federated services
If your host cluster is running in a non-cloud environment or an
environment that doesn't support common cloud primitives such as
load balancers, you might need additional flags. Please see the
[on-premises host clusters](#on-premises-host-clusters) section below.
The following example command deploys a federation control plane with
the name `fellowship`, a host cluster context `rivendell`, and the
domain suffix `example.com.`:
```shell
kubefed init fellowship \
--host-cluster-context=rivendell \
--dns-provider="google-clouddns" \
--dns-zone-name="example.com."
```
The domain suffix specified in `--dns-zone-name` must be an existing
domain that you control, and that is programmable by your DNS provider.
It must also end with a trailing dot.
Once the federation control plane is initialized, query the namespaces:
```shell
kubectl get namespace --context=fellowship
```
If you do not see the `default` namespace listed (this is due to a
[bug](https://github.com/kubernetes/kubernetes/issues/33292)). Create it
yourself with the following command:
```shell
kubectl create namespace default --context=fellowship
```
The machines in your host cluster must have the appropriate permissions
to program the DNS service that you are using. For example, if your
cluster is running on Google Compute Engine, you must enable the
Google Cloud DNS API for your project.
The machines in Google Kubernetes Engine clusters are created
without the Google Cloud DNS API scope by default. If you want to use a
Google Kubernetes Engine cluster as a Federation host, you must create it using the `gcloud`
command with the appropriate value in the `--scopes` field. You cannot
modify a Google Kubernetes Engine cluster directly to add this scope, but you can create a
new node pool for your cluster and delete the old one.
{{< note >}}
This will cause pods in the cluster to be rescheduled.
{{< /note >}}
To add the new node pool, run:
```shell
scopes="$(gcloud container node-pools describe --cluster=gke-cluster default-pool --format='value[delimiter=","](config.oauthScopes)')"
gcloud container node-pools create new-np \
--cluster=gke-cluster \
--scopes="${scopes},https://www.googleapis.com/auth/ndev.clouddns.readwrite"
```
To delete the old node pool, run:
```shell
gcloud container node-pools delete default-pool --cluster gke-cluster
```
`kubefed init` sets up the federation control plane in the host
cluster and also adds an entry for the federation API server in your
local kubeconfig.
{{< note >}}
In the beta release of Kubernetes 1.6, `kubefed init` does not automatically set the current context to the
newly deployed federation. You can set the current context manually by running:
```shell
kubectl config use-context fellowship
```
where `fellowship` is the name of your federation.
{{< /note >}}
### Basic and token authentication support
`kubefed init` by default only generates TLS certificates and keys
to authenticate with the federation API server and writes them to
your local kubeconfig file. If you wish to enable basic authentication
or token authentication for debugging purposes, you can enable them by
passing the `--apiserver-enable-basic-auth` flag or the
`--apiserver-enable-token-auth` flag.
```shell
kubefed init fellowship \
--host-cluster-context=rivendell \
--dns-provider="google-clouddns" \
--dns-zone-name="example.com." \
--apiserver-enable-basic-auth=true \
--apiserver-enable-token-auth=true
```
### Passing command line arguments to federation components
`kubefed init` bootstraps a federation control plane with default
arguments to federation API server and federation controller manager.
Some of these arguments are derived from `kubefed init`'s flags.
However, you can override these command line arguments by passing
them via the appropriate override flags.
You can override the federation API server arguments by passing them
to `--apiserver-arg-overrides` and override the federation controller
manager arguments by passing them to
`--controllermanager-arg-overrides`.
```shell
kubefed init fellowship \
--host-cluster-context=rivendell \
--dns-provider="google-clouddns" \
--dns-zone-name="example.com." \
--apiserver-arg-overrides="--anonymous-auth=false,--v=4" \
--controllermanager-arg-overrides="--controllers=services=false"
```
### Configuring a DNS provider
The Federated service controller programs a DNS provider to expose
federated services via DNS names. Certain cloud providers
automatically provide the configuration required to program the
DNS provider if the host cluster's cloud provider is same as the DNS
provider. In all other cases, you have to provide the DNS provider
configuration to your federation controller manager which will in-turn
be passed to the federated service controller. You can provide this
configuration to federation controller manager by storing it in a file
and passing the file's local filesystem path to `kubefed init`'s
`--dns-provider-config` flag. For example, save the config below in
`$HOME/coredns-provider.conf`.
```ini
[Global]
etcd-endpoints = http://etcd-cluster.ns:2379
zones = example.com.
```
And then pass this file to `kubefed init`:
```shell
kubefed init fellowship \
--host-cluster-context=rivendell \
--dns-provider="coredns" \
--dns-zone-name="example.com." \
--dns-provider-config="$HOME/coredns-provider.conf"
```
### On-premises host clusters
#### API server service type
`kubefed init` exposes the federation API server as a Kubernetes
[service](/docs/concepts/services-networking/service/) on the host cluster. By default,
this service is exposed as a
[load balanced service](/docs/concepts/services-networking/service/#loadbalancer).
Most on-premises and bare-metal environments, and some cloud
environments lack support for load balanced services. `kubefed init`
allows exposing the federation API server as a
[`NodePort` service](/docs/concepts/services-networking/service/#nodeport) on
such environments. This can be accomplished by passing
the `--api-server-service-type=NodePort` flag. You can also specify
the preferred address to advertise the federation API server by
passing the `--api-server-advertise-address=<IP-address>`
flag. Otherwise, one of the host cluster's node address is chosen as
the default.
```shell
kubefed init fellowship \
--host-cluster-context=rivendell \
--dns-provider="google-clouddns" \
--dns-zone-name="example.com." \
--api-server-service-type="NodePort" \
--api-server-advertise-address="10.0.10.20"
```
#### Provisioning storage for etcd
Federation control plane stores its state in
[`etcd`](https://coreos.com/etcd/docs/latest/).
[`etcd`](https://coreos.com/etcd/docs/latest/) data must be stored in
a persistent storage volume to ensure correct operation across
federation control plane restarts. On host clusters that support
[dynamic provisioning of storage volumes](/docs/concepts/storage/persistent-volumes/#dynamic),
`kubefed init` dynamically provisions a
[`PersistentVolume`](/docs/concepts/storage/persistent-volumes/#persistent-volumes)
and binds it to a
[`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
to store [`etcd`](https://coreos.com/etcd/docs/latest/) data. If your
host cluster doesn't support dynamic provisioning, you can also
statically provision a
[`PersistentVolume`](/docs/concepts/storage/persistent-volumes/#persistent-volumes).
`kubefed init` creates a
[`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
that has the following configuration:
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
volume.alpha.kubernetes.io/storage-class: "yes"
labels:
app: federated-cluster
name: fellowship-federation-apiserver-etcd-claim
namespace: federation-system
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
```
To statically provision a
[`PersistentVolume`](/docs/concepts/storage/persistent-volumes/#persistent-volumes),
you must ensure that the
[`PersistentVolume`](/docs/concepts/storage/persistent-volumes/#persistent-volumes)
that you create has the matching storage class, access mode and
at least as much capacity as the requested
[`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
Alternatively, you can disable persistent storage completely
by passing `--etcd-persistent-storage=false` to `kubefed init`.
However, we do not recommended this because your federation control
plane cannot survive restarts in this mode.
```shell
kubefed init fellowship \
--host-cluster-context=rivendell \
--dns-provider="google-clouddns" \
--dns-zone-name="example.com." \
--etcd-persistent-storage=false
```
`kubefed init` still doesn't support attaching an existing
[`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
to the federation control plane that it bootstraps. We are planning to
support this in a future version of `kubefed`.
#### CoreDNS support
Federated services now support [CoreDNS](https://coredns.io/) as one
of the DNS providers. If you are running your clusters and federation
in an environment that does not have access to cloud-based DNS
providers, then you can run your own [CoreDNS](https://coredns.io/)
instance and publish the federated service DNS names to that server.
You can configure your federation to use
[CoreDNS](https://coredns.io/), by passing appropriate values to
`kubefed init`'s `--dns-provider` and `--dns-provider-config` flags.
```shell
kubefed init fellowship \
--host-cluster-context=rivendell \
--dns-provider="coredns" \
--dns-zone-name="example.com." \
--dns-provider-config="$HOME/coredns-provider.conf"
```
For more information see
[Setting up CoreDNS as DNS provider for Cluster Federation](/docs/tasks/federation/set-up-coredns-provider-federation/).
#### AWS Route53 support
It is possible to utilize AWS Route53 as a cloud DNS provider when the
federation controller-manager is run on-premise. The controller-manager
Deployment must be configured with AWS credentials since it cannot implicitly
gather them from a VM running on AWS.
Currently, `kubefed init` does not read AWS Route53 credentials from the
`--dns-provider-config` flag, so a patch must be applied.
Specify AWS Route53 as your DNS provider when initializing your on-premise
federation controller-manager by passing the flag `--dns-provider="aws-route53"`
to `kubefed init`.
Create a patch file with your AWS credentials:
```yaml
spec:
template:
spec:
containers:
- name: controller-manager
env:
- name: AWS_ACCESS_KEY_ID
value: "ABCDEFG1234567890"
- name: AWS_SECRET_ACCESS_KEY
value: "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"
```
Patch the Deployment:
```shell
kubectl -n federation-system patch deployment controller-manager --patch "$(cat <patch-file-name>.yml)"
```
Where `<patch-file-name>` is the name of the file you created above.
## Adding a cluster to a federation
After you've deployed a federation control plane, you'll need to make that control plane aware of the clusters it should manage.
To join clusters into the federation:
1. Change the context:
```shell
kubectl config use-context fellowship
```
1. If you are using a managed cluster service, allow the service to access the cluster. To do this, create a `clusterrolebinding` for the account associated with your cluster service:
```shell
kubectl create clusterrolebinding <your_user>-cluster-admin-binding --clusterrole=cluster-admin --user=<your_user>@example.org --context=<joining_cluster_context>
```
1. Join the cluster to the federation, using `kubefed join`, and make sure you provide the following:
* The name of the cluster that you are joining to the federation
* `--host-cluster-context`, the kubeconfig context for the host cluster
For example, this command adds the cluster `gondor` to the federation running on host cluster `rivendell`:
```shell
kubefed join gondor --host-cluster-context=rivendell
```
A new context has now been added to your kubeconfig named `fellowship` (after the name of your federation).
{{< note >}}
The name that you provide to the `join` command is used as the joining cluster's identity in federation. This name should adhere to the rules described in the [identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
corresponding to your joining cluster conforms to these rules, you can use the same name in the join command. Otherwise, you must choose a different name for your cluster's identity.
{{< /note >}}
### Naming rules and customization
The cluster name you supply to `kubefed join` must be a valid
[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label and are
enumerated in the [Identifiers doc](/docs/concepts/overview/working-with-objects/names/).
Furthermore, federation control plane requires credentials of the
joined clusters to operate on them. These credentials are obtained
from the local kubeconfig. `kubefed join` uses the cluster name
specified as the argument to look for the cluster's context in the
local kubeconfig. If it fails to find a matching context, it exits
with an error.
This might cause issues in cases where context names for each cluster
in the federation don't follow
[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules.
In such cases, you can specify a cluster name that conforms to the
[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules
and specify the cluster context using the `--cluster-context` flag.
For example, if context of the cluster you are joining is
`gondor_needs-no_king`, then you can join the cluster by running:
```shell
kubefed join gondor --host-cluster-context=rivendell --cluster-context=gondor_needs-no_king
```
#### Secret name
Cluster credentials required by the federation control plane as
described above are stored as a secret in the host cluster. The name
of the secret is also derived from the cluster name.
However, the name of a secret object in Kubernetes should conform
to the DNS subdomain name specification described in
[RFC 1123](https://tools.ietf.org/html/rfc1123). If this isn't the
case, you can pass the secret name to `kubefed join` using the
`--secret-name` flag. For example, if the cluster name is `noldor` and
the secret name is `11kingdom`, you can join the cluster by
running:
```shell
kubefed join noldor --host-cluster-context=rivendell --secret-name=11kingdom
```
{{< note >}}
If your cluster name does not conform to the DNS subdomain name specification, all you need to do is supply the secret name using the `--secret-name` flag. `kubefed join` automatically creates the secret for you.
{{< /note >}}
### `kube-dns` configuration
`kube-dns` configuration must be updated in each joining cluster to
enable federated service discovery. If the joining Kubernetes cluster
is version 1.5 or newer and your `kubefed` is version 1.6 or newer,
then this configuration is automatically managed for you when the
clusters are joined or unjoined using `kubefed join` or `unjoin`
commands.
In all other cases, you must update `kube-dns` configuration manually
as described in the
[Updating KubeDNS section of the admin guide](/docs/admin/federation/).
## Removing a cluster from a federation
To remove a cluster from a federation, run the [`kubefed unjoin`](/docs/reference/setup-tools/kubefed/kubefed_unjoin/)
command with the cluster name and the federation's
`--host-cluster-context`:
```shell
kubefed unjoin gondor --host-cluster-context=rivendell
```
## Turning down the federation control plane
Proper cleanup of federation control plane is not fully implemented in
this beta release of `kubefed`. However, for the time being, deleting
the federation system namespace should remove all the resources except
the persistent storage volume dynamically provisioned for the
federation control plane's etcd. You can delete the federation
namespace by running the following command:
```shell
kubectl delete ns federation-system --context=rivendell
```
{{< note >}}
`rivendell` is the host cluster name. Replace that name with the appropriate name in your configuration.
{{< /note >}}
{{% /capture %}}
content/en/docs/tasks/federation/set-up-coredns-provider-federation.md
+152
View File
@@ -0,0 +1,152 @@
---
title: Set up CoreDNS as DNS provider for Cluster Federation
content_template: templates/tutorial
weight: 130
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This page shows how to configure and deploy CoreDNS to be used as the
DNS provider for Cluster Federation.
{{% /capture %}}
{{% capture objectives %}}
* Configure and deploy CoreDNS server
* Bring up federation with CoreDNS as dns provider
* Setup CoreDNS server in nameserver lookup chain
{{% /capture %}}
{{% capture prerequisites %}}
* You need to have a running Kubernetes cluster (which is
referenced as host cluster). Please see one of the
[getting started](/docs/setup/) guides for
installation instructions for your platform.
* Support for `LoadBalancer` services in member clusters of federation is
mandatory to enable `CoreDNS` for service discovery across federated clusters.
{{% /capture %}}
{{% capture lessoncontent %}}
## Deploying CoreDNS and etcd charts
CoreDNS can be deployed in various configurations. Explained below is a
reference and can be tweaked to suit the needs of the platform and the
cluster federation.
To deploy CoreDNS, we shall make use of helm charts. CoreDNS will be
deployed with [etcd](https://coreos.com/etcd) as the backend and should
be pre-installed. etcd can also be deployed using helm charts. Shown
below are the instructions to deploy etcd.
helm install --namespace my-namespace --name etcd-operator stable/etcd-operator
helm upgrade --namespace my-namespace --set cluster.enabled=true etcd-operator stable/etcd-operator
*Note: etcd default deployment configurations can be overridden, suiting the
host cluster.*
After deployment succeeds, etcd can be accessed with the
[http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379) endpoint within the host cluster.
The CoreDNS default configuration should be customized to suit the federation.
Shown below is the Values.yaml, which overrides the default
configuration parameters on the CoreDNS chart.
```yaml
isClusterService: false
serviceType: "LoadBalancer"
plugins:
kubernetes:
enabled: false
etcd:
enabled: true
zones:
- "example.com."
endpoint: "http://etcd-cluster.my-namespace:2379"
```
The above configuration file needs some explanation:
- `isClusterService` specifies whether CoreDNS should be deployed as a
cluster-service, which is the default. You need to set it to false, so
that CoreDNS is deployed as a Kubernetes application service.
- `serviceType` specifies the type of Kubernetes service to be created
for CoreDNS. You need to choose either "LoadBalancer" or "NodePort" to
make the CoreDNS service accessible outside the Kubernetes cluster.
- Disable `plugins.kubernetes`, which is enabled by default by
setting `plugins.kubernetes.enabled` to false.
- Enable `plugins.etcd` by setting `plugins.etcd.enabled` to
true.
- Configure the DNS zone (federation domain) for which CoreDNS is
authoritative by setting `plugins.etcd.zones` as shown above.
- Configure the etcd endpoint which was deployed earlier by setting
`plugins.etcd.endpoint`
Now deploy CoreDNS by running
helm install --namespace my-namespace --name coredns -f Values.yaml stable/coredns
Verify that both etcd and CoreDNS pods are running as expected.
## Deploying Federation with CoreDNS as DNS provider
The Federation control plane can be deployed using `kubefed init`. CoreDNS
can be chosen as the DNS provider by specifying two additional parameters.
--dns-provider=coredns
--dns-provider-config=coredns-provider.conf
coredns-provider.conf has below format:
[Global]
etcd-endpoints = http://etcd-cluster.my-namespace:2379
zones = example.com.
coredns-endpoints = <coredns-server-ip>:<port>
- `etcd-endpoints` is the endpoint to access etcd.
- `zones` is the federation domain for which CoreDNS is authoritative and is same as --dns-zone-name flag of `kubefed init`.
- `coredns-endpoints` is the endpoint to access CoreDNS server. This is an optional parameter introduced from v1.7 onwards.
{{< note >}}
`plugins.etcd.zones` in the CoreDNS configuration and the `--dns-zone-name` flag to `kubefed init` should match.
{{< /note >}}
## Setup CoreDNS server in nameserver resolv.conf chain
{{< note >}}
The following section applies only to versions prior to v1.7
and will be automatically taken care of if the `coredns-endpoints`
parameter is configured in `coredns-provider.conf` as described in
section above.
{{< /note >}}
Once the federation control plane is deployed and federated clusters
are joined to the federation, you need to add the CoreDNS server to the
pod's nameserver resolv.conf chain in all the federated clusters as this
self hosted CoreDNS server is not discoverable publicly. This can be
achieved by adding the below line to `dnsmasq` container's arg in
`kube-dns` deployment.
--server=/example.com./<CoreDNS endpoint>
Replace `example.com` above with federation domain.
Now the federated cluster is ready for cross-cluster service discovery!
{{% /capture %}}
content/en/docs/tasks/federation/set-up-placement-policies-federation.md
+221
View File
@@ -0,0 +1,221 @@
---
title: Set up placement policies in Federation
content_template: templates/task
weight: 135
---
{{% capture overview %}}
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
This page shows how to enforce policy-based placement decisions over Federated
resources using an external policy engine.
{{% /capture %}}
{{% capture prerequisites %}}
You need to have a running Kubernetes cluster (which is referenced as host
cluster). Please see one of the [getting started](/docs/setup/)
guides for installation instructions for your platform.
{{% /capture %}}
{{% capture steps %}}
## Deploying Federation and configuring an external policy engine
The Federation control plane can be deployed using `kubefed init`.
After deploying the Federation control plane, you must configure an Admission
Controller in the Federation API server that enforces placement decisions
received from the external policy engine.
kubectl apply -f scheduling-policy-admission.yaml
Shown below is an example ConfigMap for the Admission Controller:
{{< codenew file="federation/scheduling-policy-admission.yaml" >}}
The ConfigMap contains three files:
* `config.yml` specifies the location of the `SchedulingPolicy` Admission
Controller config file.
* `scheduling-policy-config.yml` specifies the location of the kubeconfig file
required to contact the external policy engine. This file can also include a
`retryBackoff` value that controls the initial retry backoff delay in
milliseconds.
* `opa-kubeconfig` is a standard kubeconfig containing the URL and credentials
needed to contact the external policy engine.
Edit the Federation API server deployment to enable the `SchedulingPolicy`
Admission Controller.
kubectl -n federation-system edit deployment federation-apiserver
Update the Federation API server command line arguments to enable the Admission
Controller and mount the ConfigMap into the container. If there's an existing
`--enable-admission-plugins` flag, append `,SchedulingPolicy` instead of adding
another line.
--enable-admission-plugins=SchedulingPolicy
--admission-control-config-file=/etc/kubernetes/admission/config.yml
Add the following volume to the Federation API server pod:
- name: admission-config
configMap:
name: admission
Add the following volume mount the Federation API server `apiserver` container:
volumeMounts:
- name: admission-config
mountPath: /etc/kubernetes/admission
## Deploying an external policy engine
The [Open Policy Agent (OPA)](http://openpolicyagent.org) is an open source,
general-purpose policy engine that you can use to enforce policy-based placement
decisions in the Federation control plane.
Create a Service in the host cluster to contact the external policy engine:
kubectl apply -f policy-engine-service.yaml
Shown below is an example Service for OPA.
{{< codenew file="federation/policy-engine-service.yaml" >}}
Create a Deployment in the host cluster with the Federation control plane:
kubectl apply -f policy-engine-deployment.yaml
Shown below is an example Deployment for OPA.
{{< codenew file="federation/policy-engine-deployment.yaml" >}}
## Configuring placement policies via ConfigMaps
The external policy engine will discover placement policies created in the
`kube-federation-scheduling-policy` namespace in the Federation API server.
Create the namespace if it does not already exist:
kubectl --context=federation create namespace kube-federation-scheduling-policy
Configure a sample policy to test the external policy engine:
```
# OPA supports a high-level declarative language named Rego for authoring and
# enforcing policies. For more information on Rego, visit
# http://openpolicyagent.org.
# Rego policies are namespaced by the "package" directive.
package kubernetes.placement
# Imports provide aliases for data inside the policy engine. In this case, the
# policy simply refers to "clusters" below.
import data.kubernetes.clusters
# The "annotations" rule generates a JSON object containing the key
# "federation.kubernetes.io/replica-set-preferences" mapped to <preferences>.
# The preferences values is generated dynamically by OPA when it evaluates the
# rule.
#
# The SchedulingPolicy Admission Controller running inside the Federation API
# server will merge these annotations into incoming Federated resources. By
# setting replica-set-preferences, we can control the placement of Federated
# ReplicaSets.
#
# Rules are defined to generate JSON values (booleans, strings, objects, etc.)
# When OPA evaluates a rule, it generates a value IF all of the expressions in
# the body evaluate successfully. All rules can be understood intuitively as
# <head> if <body> where <body> is true if <expr-1> AND <expr-2> AND ...
# <expr-N> is true (for some set of data.)
annotations["federation.kubernetes.io/replica-set-preferences"] = preferences {
input.kind = "ReplicaSet"
value = {"clusters": cluster_map, "rebalance": true}
json.marshal(value, preferences)
}
# This "annotations" rule generates a value for the "federation.alpha.kubernetes.io/cluster-selector"
# annotation.
#
# In English, the policy asserts that resources in the "production" namespace
# that are not annotated with "criticality=low" MUST be placed on clusters
# labelled with "on-premises=true".
annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector {
input.metadata.namespace = "production"
not input.metadata.annotations.criticality = "low"
json.marshal([{
"operator": "=",
"key": "on-premises",
"values": "[true]",
}], selector)
}
# Generates a set of cluster names that satisfy the incoming Federated
# ReplicaSet's requirements. In this case, just PCI compliance.
replica_set_clusters[cluster_name] {
clusters[cluster_name]
not insufficient_pci[cluster_name]
}
# Generates a set of clusters that must not be used for Federated ReplicaSets
# that request PCI compliance.
insufficient_pci[cluster_name] {
clusters[cluster_name]
input.metadata.annotations["requires-pci"] = "true"
not pci_clusters[cluster_name]
}
# Generates a set of clusters that are PCI certified. In this case, we assume
# clusters are annotated to indicate if they have passed PCI compliance audits.
pci_clusters[cluster_name] {
clusters[cluster_name].metadata.annotations["pci-certified"] = "true"
}
# Helper rule to generate a mapping of desired clusters to weights. In this
# case, weights are static.
cluster_map[cluster_name] = {"weight": 1} {
replica_set_clusters[cluster_name]
}
```
Shown below is the command to create the sample policy:
kubectl --context=federation -n kube-federation-scheduling-policy create configmap scheduling-policy --from-file=policy.rego
This sample policy illustrates a few key ideas:
* Placement policies can refer to any field in Federated resources.
* Placement policies can leverage external context (for example, Cluster
metadata) to make decisions.
* Administrative policy can be managed centrally.
* Policies can define simple interfaces (such as the `requires-pci` annotation) to
avoid duplicating logic in manifests.
## Testing placement policies
Annotate one of the clusters to indicate that it is PCI certified.
kubectl --context=federation annotate clusters cluster-name-1 pci-certified=true
Deploy a Federated ReplicaSet to test the placement policy.
{{< codenew file="federation/replicaset-example-policy.yaml" >}}
Shown below is the command to deploy a ReplicaSet that *does* match the policy.
kubectl --context=federation create -f replicaset-example-policy.yaml
Inspect the ReplicaSet to confirm the appropriate annotations have been applied:
kubectl --context=federation get rs nginx-pci -o jsonpath='{.metadata.annotations}'
{{% /capture %}}
content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+2 -2
View File
@@ -18,10 +18,10 @@ This page shows how to run a replicated stateful application using a
The example is a MySQL single-master topology with multiple slaves running
asynchronous replication.
{{< note >}}
{{ < note > }}
**This is not a production configuration**. MySQL settings remain on insecure defaults to keep the focus
on general patterns for running stateful applications in Kubernetes.
{{< /note >}}
{{ < /note > }}
{{% /capture %}}
content/es/docs/tasks/tools/install-minikube.md
+1 -1
View File
@@ -49,7 +49,7 @@ Minikube también soporta una opción `--vm-driver=none` que ejecuta los compone
La forma más fácil de instalar Minikube en macOS es usar [Homebrew](https://brew.sh):
```shell
brew install minikube
brew cask install minikube
```
También puedes instalarlo en macOS descargando un ejecutable autocontenido:
content/id/docs/concepts/configuration/assign-pod-node.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
title: Menetapkan Pod ke Node
title: Menetapkan Pod ke Kontainer
content_template: templates/concept
weight: 30
---
content/ja/docs/concepts/architecture/cloud-controller.md
+2 -2
View File
@@ -8,7 +8,7 @@ weight: 30
クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
クラウドコントローラーマネージャーの設計は「プラグイン機構」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。
@@ -91,7 +91,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション
この新しいモデルでは、kubeletはクラウド特有の情報無しでノードを初期化します。しかし、新しく作成されたノードにtaintを付けて、CCMがクラウド特有の情報でノードを初期化するまで、コンテナがスケジュールされないようにします。その後、taintを削除します。
## プラグインメカニズム
## プラグイン機構
クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+1 -1
View File
@@ -170,7 +170,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ
| merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート |
| HTTPS | 新しいエンドポイントがHTTPSを利用 |
| ビルトイン認証 | 拡張機能へのアクセスに認証のため、コアAPIサーバー(アグリゲーションレイヤー)を利用 |
| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用(例、RBAC) |
| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可機構を再利用(例、RBAC) |
| ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック |
| Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 |
| UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 |
content/ja/docs/concepts/extend-kubernetes/extend-cluster.md
+1 -1
View File
@@ -121,7 +121,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
### 認可
[認可](/docs/reference/access-authn-authz/webhook/)は特定のユーザーがAPIリソースに対して、読み込み、書き込み、そしてその他の操作が可能かどうかを決定します。それはオブジェクト全体のレベルで機能し、任意のオブジェクトフィールドに基づいての区別は行いません。もしビルトインの認可メカニズムが要件に合わない場合、[認可Webhook](/docs/reference/access-authn-authz/webhook/)が、ユーザー提供のコードを呼び出し認可の決定を行うことを可能にします。
[認可](/docs/reference/access-authn-authz/webhook/)は特定のユーザーがAPIリソースに対して、読み込み、書き込み、そしてその他の操作が可能かどうかを決定します。それはオブジェクト全体のレベルで機能し、任意のオブジェクトフィールドに基づいての区別は行いません。もしビルトインの認可機構が要件に合わない場合、[認可Webhook](/docs/reference/access-authn-authz/webhook/)が、ユーザー提供のコードを呼び出し認可の決定を行うことを可能にします。
### 動的Admission Control
content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md
+1 -1
View File
@@ -20,7 +20,7 @@ weight: 70
## スコア付けするノードの割合
Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのノードに対して割り当て可能かをチェックし、実際に割り当て可能なノードのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なノードが見つかった時点で、割り当て可能なノードの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするノードの割合をクラスターのサイズに基づいて決定するためのメカニズムがあります。このメカニズムでは100ノードのクラスターに対しては50%の割合とするような線形な式を使用します。5000ノードのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のノードをスコア付けすることになります。
Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのノードに対して割り当て可能かをチェックし、実際に割り当て可能なノードのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なノードが見つかった時点で、割り当て可能なノードの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするノードの割合をクラスターのサイズに基づいて決定するための機構があります。この機構では100ノードのクラスターに対しては50%の割合とするような線形な式を使用します。5000ノードのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のノードをスコア付けすることになります。
`percentageOfNodesToScore`の値を50%に設定する例は下記のとおりです。
content/ja/docs/concepts/services-networking/service.md
+2 -2
View File
@@ -3,7 +3,7 @@ title: Service
feature:
title: サービスディスカバリーと負荷分散
description: >
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
Kubernetesでは、なじみのないサービスディスカバリーの機構を使用するためにユーザーがアプリケーションの修正をする必要はありません。KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
content_template: templates/concept
weight: 10
@@ -14,7 +14,7 @@ weight: 10
{{< glossary_definition term_id="service" length="short" >}}
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。
Kubernetesでは、なじみのないサービスディスカバリーの機構を使用するためにユーザーがアプリケーションの修正をする必要はありません。
KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
+1 -1
View File
@@ -9,7 +9,7 @@ weight: 65
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTLメカニズムを提供します。
TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL機構を提供します。
TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。
α版の免責事項: この機能は現在α版の機能で、[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
content/ja/docs/reference/command-line-tools-reference/feature-gates.md
+1 -1
View File
@@ -139,7 +139,7 @@ content_template: templates/concept
| `TokenRequestProjection` | `true` | Beta | 1.12 | |
| `TTLAfterFinished` | `false` | Alpha | 1.12 | |
| `TopologyManager` | `false` | Alpha | 1.16 | |
| `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 |
| `ValidateProxyRedirects` | `false` | Alpha | 1.10 | 1.13 |
| `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
| `VolumePVCDataSource` | `true` | Beta | 1.16 | |
content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+5 -10
View File
@@ -17,16 +17,11 @@ kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManag
`extraArgs` の項目は `キー: 値` のペアです。コントロールプレーンの構成要素のフラグを上書きするには:
1. 設定内容に適切な項目を追加
2. フラグを追加して項目を上書き
3. `--config <任意の設定YAMLファイル>`で`kubeadm init`を実行
1. 設定内容に適切な項目を追加
2. フラグを追加して項目を上書き
各設定項目のより詳細な情報は[APIリファレンスのページ](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#ClusterConfiguration)を参照してください。
{{< note >}}
`kubeadm config print init-defaults`を実行し、選択したファイルに出力を保存することで、デフォルト値で`ClusterConfiguration`オブジェクトを生成できます。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
@@ -39,7 +34,7 @@ Example usage:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
kubernetesVersion: v1.13.0
apiServer:
extraArgs:
advertise-address: 192.168.0.103
@@ -56,7 +51,7 @@ Example usage:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
kubernetesVersion: v1.13.0
controllerManager:
extraArgs:
cluster-signing-key-file: /home/johndoe/keys/ca.key
@@ -72,7 +67,7 @@ Example usage:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
kubernetesVersion: v1.13.0
scheduler:
extraArgs:
address: 0.0.0.0
content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+126 -87
View File
@@ -1,5 +1,5 @@
---
title: kubeadmを使用したシングルコントロールプレーンクラスターの作成
title: kubeadmを使用したシングルマスタークラスターの作成
content_template: templates/task
weight: 30
---
@@ -33,6 +33,17 @@ but you may also build them from source for other OSes.
### kubeadmの成熟度
| Area | Maturity Level |
|---------------------------|--------------- |
| Command line UX | GA |
| Implementation | GA |
| Config file API | Beta |
| CoreDNS | GA |
| kubeadm alpha subcommands | Alpha |
| High availability | Beta |
| DynamicKubeletConfig | Alpha |
kubeadm's overall feature state is **GA**. Some sub-features, like the configuration
file API are still under active development. The implementation of creating the cluster
may change slightly as the tool evolves, but the overall implementation should be pretty stable.
@@ -48,10 +59,16 @@ timeframe; which also applies to `kubeadm`.
| Kubernetes version | Release month | End-of-life-month |
|--------------------|----------------|-------------------|
| v1.13.x | December 2018 | September 2019 |
| v1.14.x | March 2019 | December 2019 |
| v1.15.x | June 2019 | March 2020 |
| v1.16.x | September 2019 | June 2020 |
| v1.6.x | March 2017 | December 2017 |
| v1.7.x | June 2017 | March 2018 |
| v1.8.x | September 2017 | June 2018 |
| v1.9.x | December 2017 | September 2018   |
| v1.10.x | March 2018 | December 2018   |
| v1.11.x | June 2018 | March 2019   |
| v1.12.x | September 2018 | June 2019   |
| v1.13.x | December 2018 | September 2019   |
| v1.14.x | March 2019 | December 2019   |
| v1.15.x | June 2019 | March 2020   |
{{% /capture %}}
@@ -70,7 +87,7 @@ timeframe; which also applies to `kubeadm`.
## 目的
* Install a single control-plane Kubernetes cluster or [high availability cluster](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
* Install a single master Kubernetes cluster or [high availability cluster](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
* Install a Pod network on the cluster so that your Pods can
talk to each other
@@ -86,75 +103,50 @@ apt-get upgrade` or `yum update` to get the latest version of kubeadm.
When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for
kubeadm to tell it what to do. This crashloop is expected and normal.
After you initialize your control-plane, the kubelet runs normally.
After you initialize your master, the kubelet runs normally.
{{< /note >}}
### コントロールプレーンノードの初期化
### マスターの初期化
The control-plane node is the machine where the control plane components run, including
etcd (the cluster database) and the API server (which the kubectl CLI
communicates with).
1. (Recommended) If you have plans to upgrade this single control-plane kubeadm cluster
to high availability you should specify the `--control-plane-endpoint` to set the shared endpoint
for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer.
1. Choose a Pod network add-on, and verify whether it requires any arguments to
1. Choose a pod network add-on, and verify whether it requires any arguments to
be passed to kubeadm initialization. Depending on which
third-party provider you choose, you might need to set the `--pod-network-cidr` to
a provider-specific value. See [Installing a Pod network add-on](#pod-network).
a provider-specific value. See [Installing a pod network add-on](#pod-network).
1. (Optional) Since version 1.14, kubeadm will try to detect the container runtime on Linux
by using a list of well known domain socket paths. To use different container runtime or
if there are more than one installed on the provisioned node, specify the `--cri-socket`
argument to `kubeadm init`. See [Installing runtime](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
1. (Optional) Unless otherwise specified, kubeadm uses the network interface associated
with the default gateway to set the advertise address for this particular control-plane node's API server.
To use a different network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
with the default gateway to advertise the master's IP. To use a different
network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
must specify an IPv6 address, for example `--apiserver-advertise-address=fd00::101`
1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
connectivity to gcr.io registries.
To initialize the control-plane node run:
Now run:
```bash
kubeadm init <args>
```
### Considerations about apiserver-advertise-address and ControlPlaneEndpoint
While `--apiserver-advertise-address` can be used to set the advertise address for this particular
control-plane node's API server, `--control-plane-endpoint` can be used to set the shared endpoint
for all control-plane nodes.
`--control-plane-endpoint` allows IP addresses but also DNS names that can map to IP addresses.
Please contact your network administrator to evaluate possible solutions with respect to such mapping.
Here is an example mapping:
```
192.168.0.102 cluster-endpoint
```
Where `192.168.0.102` is the IP address of this node and `cluster-endpoint` is a custom DNS name that maps to this IP.
This will allow you to pass `--control-plane-endpoint=cluster-endpoint` to `kubeadm init` and pass the same DNS name to
`kubeadm join`. Later you can modify `cluster-endpoint` to point to the address of your load-balancer in an
high availability scenario.
Turning a single control plane cluster created without `--control-plane-endpoint` into a highly available cluster
is not supported by kubeadm.
### 詳細
For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/ja/docs/reference/setup-tools/kubeadm/kubeadm/).
For a complete list of configuration options, see the [configuration file documentation](/ja/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).
To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/ja/docs/admin/kubeadm#custom-args).
To run `kubeadm init` again, you must first [tear down the cluster](#tear-down).
If you join a node with a different architecture to your cluster, make sure that your deployed DaemonSets
have container image support for this architecture.
If you join a node with a different architecture to your cluster, create a separate
Deployment or DaemonSet for `kube-proxy` and `kube-dns` on the node. This is because the Docker images for these
components do not currently support multi-architecture.
`kubeadm init` first runs a series of prechecks to ensure that the machine
is ready to run Kubernetes. These prechecks expose warnings and exit on errors. `kubeadm init`
@@ -173,14 +165,14 @@ The output should look like:
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [kubeadm-cp localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] etcd/server serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [kubeadm-cp localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] etcd/peer serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubeadm-cp kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
[certs] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
@@ -199,9 +191,9 @@ The output should look like:
[apiclient] All control plane components are healthy after 31.501735 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-X.Y" in namespace kube-system with the configuration for the kubelets in the cluster
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kubeadm-cp" as an annotation
[mark-control-plane] Marking the node kubeadm-cp as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node kubeadm-cp as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kubeadm-master" as an annotation
[mark-control-plane] Marking the node kubeadm-master as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node kubeadm-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: <token>
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
@@ -211,7 +203,7 @@ The output should look like:
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
Your Kubernetes control-plane has initialized successfully!
Your Kubernetes master has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
@@ -219,14 +211,14 @@ To start using your cluster, you need to run the following as a regular user:
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a Pod network to the cluster.
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
/docs/concepts/cluster-administration/addons/
You can now join any number of machines by running the following on each node
as root:
kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
kubeadm join <master-ip>:<master-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
```
To make kubectl work for your non-root user, run these commands, which are
@@ -259,13 +251,13 @@ created, and deleted with the `kubeadm token` command. See the
This section contains important information about installation and deployment order. Read it carefully before proceeding.
{{< /caution >}}
You must install a Pod network add-on so that your Pods can communicate with
You must install a pod network add-on so that your pods can communicate with
each other.
**The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed.
kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).**
Several projects provide Kubernetes Pod networks using CNI, some of which also
Several projects provide Kubernetes pod networks using CNI, some of which also
support [Network Policy](/ja/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/ja/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
- [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9.
@@ -276,16 +268,24 @@ Make sure that your network manifest supports RBAC.
Also, beware, that your Pod network must not overlap with any of the host networks as this can cause issues.
If you find a collision between your network plugin’s preferred Pod network and some of your host networks, you should think of a suitable CIDR replacement and use that during `kubeadm init` with `--pod-network-cidr` and as a replacement in your network plugin’s YAML.
You can install a Pod network add-on with the following command on the control-plane node or a node that has the kubeconfig credentials:
You can install a pod network add-on with the following command:
```bash
kubectl apply -f <add-on.yaml>
```
You can install only one Pod network per cluster.
Below you can find installation instructions for some popular Pod network plugins:
You can install only one pod network per cluster.
{{< tabs name="tabs-pod-install" >}}
{{% tab name="Choose one..." %}}
Please select one of the tabs to see installation instructions for the respective third-party Pod Network Provider.
{{% /tab %}}
{{% tab name="AWS VPC" %}}
AWS VPC CNI provides native AWS VPC networking to Kubernetes clusters.
For installation, please refer to the [AWS VPC CNI setup guide](https://github.com/aws/amazon-vpc-cni-k8s#setup).
{{% /tab %}}
{{% tab name="Calico" %}}
For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources.
@@ -296,18 +296,39 @@ For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/1
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
```
{{% /tab %}}
{{% tab name="Canal" %}}
Canal uses Calico for policy and Flannel for networking. Refer to the Calico documentation for the [official getting started guide](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/flannel).
For Canal to work correctly, `--pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`. Note that Canal works on `amd64` only.
```shell
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
```
{{% /tab %}}
{{% tab name="Cilium" %}}
For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`.
These commands will deploy Cilium with its own etcd managed by etcd operator.
_Note_: If you are running kubeadm in a single node please untaint it so that
etcd-operator pods can be scheduled in the control-plane node.
```shell
kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
```
To deploy Cilium you just need to run:
```shell
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium.yaml
```
Once all Cilium Pods are marked as `READY`, you start using your cluster.
Once all Cilium pods are marked as `READY`, you start using your cluster.
```shell
kubectl get pods -n kube-system --selector=k8s-app=cilium
@@ -318,10 +339,6 @@ NAME READY STATUS RESTARTS AGE
cilium-drxkl 1/1 Running 0 18m
```
Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free).
For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
{{% /tab %}}
{{% tab name="Contiv-VPP" %}}
@@ -349,25 +366,49 @@ Note that `flannel` works on `amd64`, `arm`, `arm64`, `ppc64le` and `s390x` unde
Windows (`amd64`) is claimed as supported in v0.11.0 but the usage is undocumented.
```shell
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml
```
For more information about `flannel`, see [the CoreOS flannel repository on GitHub
](https://github.com/coreos/flannel).
{{% /tab %}}
{{% tab name="JuniperContrail/TungstenFabric" %}}
Provides overlay SDN solution, delivering multicloud networking, hybrid cloud networking,
simultaneous overlay-underlay support, network policy enforcement, network isolation,
service chaining and flexible load balancing.
There are multiple, flexible ways to install JuniperContrail/TungstenFabric CNI.
Kindly refer to this quickstart: [TungstenFabric](https://tungstenfabric.github.io/website/)
{{% /tab %}}
{{% tab name="Kube-router" %}}
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
Kube-router relies on kube-controller-manager to allocate pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
Kube-router provides pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
For information on setting up Kubernetes cluster with Kube-router using kubeadm, please see official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
{{% /tab %}}
{{% tab name="Romana" %}}
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm).
Romana works on `amd64` only.
```shell
kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml
```
{{% /tab %}}
{{% tab name="Weave Net" %}}
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
@@ -387,16 +428,16 @@ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl versio
{{< /tabs >}}
Once a Pod network has been installed, you can confirm that it is working by
checking that the CoreDNS Pod is Running in the output of `kubectl get pods --all-namespaces`.
And once the CoreDNS Pod is up and running, you can continue by joining your nodes.
Once a pod network has been installed, you can confirm that it is working by
checking that the CoreDNS pod is Running in the output of `kubectl get pods --all-namespaces`.
And once the CoreDNS pod is up and running, you can continue by joining your nodes.
If your network is not working or CoreDNS is not in the Running state, checkout our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
### コントロールプレーンノードの隔離
By default, your cluster will not schedule Pods on the control-plane node for security
reasons. If you want to be able to schedule Pods on the control-plane node, e.g. for a
By default, your cluster will not schedule pods on the control-plane node for security
reasons. If you want to be able to schedule pods on the control-plane node, e.g. for a
single-machine Kubernetes cluster for development, run:
```bash
@@ -413,21 +454,21 @@ taint "node-role.kubernetes.io/master:" not found
This will remove the `node-role.kubernetes.io/master` taint from any nodes that
have it, including the control-plane node, meaning that the scheduler will then be able
to schedule Pods everywhere.
to schedule pods everywhere.
### ノードの追加 {#join-nodes}
The nodes are where your workloads (containers and Pods, etc) run. To add new nodes to your cluster do the following for each machine:
The nodes are where your workloads (containers and pods, etc) run. To add new nodes to your cluster do the following for each machine:
* SSH to the machine
* Become root (e.g. `sudo su -`)
* Run the command that was output by `kubeadm init`. For example:
``` bash
kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>
kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
```
If you do not have the token, you can get it by running the following command on the control-plane node:
If you do not have the token, you can get it by running the following command on the master node:
``` bash
kubeadm token list
@@ -444,7 +485,7 @@ TOKEN TTL EXPIRES USAGES DESCRIPTION
```
By default, tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired,
you can create a new token by running the following command on the control-plane node:
you can create a new token by running the following command on the master node:
``` bash
kubeadm token create
@@ -456,7 +497,7 @@ The output is similar to this:
5didvk.d09sbcov8ph2amjw
```
If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the control-plane node:
If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the master node:
``` bash
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
@@ -470,7 +511,7 @@ The output is similar to this:
```
{{< note >}}
To specify an IPv6 tuple for `<control-plane-host>:<control-plane-ip>`, IPv6 address must be enclosed in square brackets, for example: `[fd00::101]:2073`.
To specify an IPv6 tuple for `<master-ip>:<master-port>`, IPv6 address must be enclosed in square brackets, for example: `[fd00::101]:2073`.
{{< /note >}}
The output should look something like:
@@ -481,24 +522,24 @@ The output should look something like:
... (log output of join workflow) ...
Node join complete:
* Certificate signing request sent to control-plane and response
* Certificate signing request sent to master and response
received.
* Kubelet informed of new secure connection details.
Run 'kubectl get nodes' on control-plane to see this machine join.
Run 'kubectl get nodes' on the master to see this machine join.
```
A few seconds later, you should notice this node in the output from `kubectl get
nodes` when run on the control-plane node.
nodes` when run on the master.
### (任意)コントロールプレーンノード以外のマシンからのクラスター操作
### (任意) マスター以外のマシンからのクラスター操作
In order to get a kubectl on some other computer (e.g. laptop) to talk to your
cluster, you need to copy the administrator kubeconfig file from your control-plane node
cluster, you need to copy the administrator kubeconfig file from your master
to your workstation like this:
``` bash
scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes
```
@@ -522,7 +563,7 @@ If you want to connect to the API Server from outside the cluster you can use
`kubectl proxy`:
```bash
scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy
```
@@ -534,7 +575,7 @@ To undo what kubeadm did, you should first [drain the
node](/ja/docs/reference/generated/kubectl/kubectl-commands#drain) and make
sure that the node is empty before shutting it down.
Talking to the control-plane node with the appropriate credentials, run:
Talking to the master with the appropriate credentials, run:
```bash
kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
@@ -581,8 +622,6 @@ control of your Kubernetes cluster.
* Learn about kubeadm's advanced usage in the [kubeadm reference documentation](/ja/docs/reference/setup-tools/kubeadm/kubeadm)
* Learn more about Kubernetes [concepts](/ja/docs/concepts/) and [`kubectl`](/ja/docs/user-guide/kubectl-overview/).
* Configure log rotation. You can use **logrotate** for that. When using Docker, you can specify log rotation options for Docker daemon, for example `--log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5`. See [Configure and troubleshoot the Docker daemon](https://docs.docker.com/engine/admin/) for more details.
* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
of Pod network add-ons.
## フィードバック {#feedback}
content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+2 -5
View File
@@ -56,9 +56,6 @@ Linuxでは、カーネルのiptablesサブシステムの最新の代替品と
{{< tabs name="iptables_legacy" >}}
{{% tab name="Debian or Ubuntu" %}}
```bash
# レガシーバイナリがインストールされていることを確認してください
sudo apt-get install -y iptables arptables ebtables
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
sudo update-alternatives --set arptables /usr/sbin/arptables-legacy
@@ -192,7 +189,7 @@ systemctl enable --now kubelet
`net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g.
```bash
cat <<EOF > /etc/sysctl.d/k8s.conf
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
@@ -271,6 +268,6 @@ kubeadmで問題が発生した場合は、[トラブルシューティング](/
{{% capture whatsnext %}}
* [kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
* [kubeadmを使用したシングルマスタークラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
{{% /capture %}}
content/ko/docs/concepts/architecture/cloud-controller.md
-2
View File
@@ -223,13 +223,11 @@ rules:
다음은 클라우드 제공사업자들이 구현한 CCM들이다.
* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager)
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
content/ko/docs/concepts/configuration/assign-pod-node.md
-399
View File
@@ -1,399 +0,0 @@
---
title: 노드에 파드 할당하기
content_template: templates/concept
weight: 30
---
{{% capture overview %}}
{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나,
특정 노드들을 선호하도록 제한할 수 있다.
이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다.
보통 스케줄러가 자동으로 합리적인 배치(예: 노드들에 걸쳐 파드를 분배하거나,
자원이 부족한 노드에 파드를 배치하지 않는 등)를 수행하기에 이런 제약 조건은 필요하지 않지만
간혹 파드가 배치되는 노드에 대해 더 많은 제어를 원할 수 있는 상황이 있다.
예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서
많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다.
{{% /capture %}}
{{% capture body %}}
## 노드 셀렉터(nodeSelector)
`nodeSelector` 는 가장 간단하고 권장되는 노드 선택 제약 조건의 형태이다.
`nodeSelector` 는 PodSpec의 필드이다. 이는 키-값 쌍의 매핑으로 지정한다. 파드가 노드에서 동작할 수 있으려면,
노드는 키-값의 쌍으로 표시되는 레이블을 각자 가지고 있어야 한다(이는 추가 레이블을 가지고 있을 수 있다).
일반적으로 하나의 키-값 쌍이 사용된다.
`nodeSelector` 를 어떻게 사용하는지 예시를 통해 알아보도록 하자.
### 0 단계: 사전 준비
이 예시는 쿠버네티스 파드에 대한 기본적인 이해를 하고 있고 [쿠버네티스 클러스터가 설정](/ko/docs/setup/)되어 있다고 가정한다.
### 1 단계: 노드에 레이블 붙이기
`kubectl get nodes` 를 실행해서 클러스터 노드 이름을 가져온다. 이 중에 레이블을 추가하기 원하는 것 하나를 선택한 다음에 `kubectl label nodes <노드 이름> <레이블 키>=<레이블 값>` 을 실행해서 선택한 노드에 레이블을 추가한다. 예를 들어 노드의 이름이 'kubernetes-foo-node-1.c.a-robinson.internal' 이고, 원하는 레이블이 'disktype=ssd' 라면, `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 를 실행한다.
`kubectl get nodes --show-labels` 를 다시 실행해서 노드가 현재 가진 레이블을 확인하여, 이 작업을 검증할 수 있다. 또한 `kubectl describe node "노드 이름"` 을 사용해서 노드에 주어진 레이블의 전체 목록을 확인할 수 있다.
### 2 단계: 파드 설정에 nodeSelector 필드 추가하기
실행하고자 하는 파드의 설정 파일을 가져오고, 이처럼 nodeSelector 섹션을 추가한다. 예를 들어 이것이 파드 설정이라면,
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
```
이 다음에 nodeSelector 를 다음과 같이 추가한다.
{{< codenew file="pods/pod-nginx.yaml" >}}
그런 다음에 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 을
실행하면, 레이블이 붙여진 노드에 파드가 스케줄 된다.
`kubectl get pods -o wide` 를 실행해서 파드가 할당된
"NODE" 를 보면 작동하는지 검증할 수 있다.
## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels}
[붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는
표준 레이블 셋이 미리 채워져 있다. 이 레이블들은 다음과 같다.
* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
{{< note >}}
이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.
예를 들어 `kubernetes.io/hostname` 은 어떤 환경에서는 노드 이름과 같지만,
다른 환경에서는 다른 값일 수 있다.
{{< /note >}}
## 노드 격리(isolation)/제한(restriction)
노드 오브젝트에 레이블을 추가하면 파드가 특정 노드 또는 노드 그룹을 목표 대상으로 할 수 있게 된다.
이는 특정 파드가 어떤 격리, 보안, 또는 규제 속성이 있는 노드에서만 실행되도록 사용할 수 있다.
이 목적으로 레이블을 사용하는 경우, 노드에서 kubelet 프로세스로 수정할 수 없는 레이블 키를 선택하는 것을 권장한다.
이렇게 하면 손상된 노드가 해당 kubelet 자격 증명을 사용해서 해당 레이블을 자체 노드 오브젝트에 설정하고,
스케줄러가 손상된 노드로 워크로드를 스케줄 하는 것을 방지할 수 있다.
`NodeRestriction` 어드미션 플러그인은 kubelet이 `node-restriction.kubernetes.io/` 접두사로 레이블을 설정 또는 수정하지 못하게 한다.
노드 격리에 해당 레이블 접두사를 사용하려면 다음과 같이 한다.
1. [노드 권한부여자](/docs/reference/access-authn-authz/node/)를 사용하고 있고, [NodeRestriction 어드미션 플러그인](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)을 _활성화_ 해야 한다.
2. 노드 오브젝트의 `node-restriction.kubernetes.io/` 접두사 아래에 레이블을 추가하고, 해당 레이블을 노드 셀렉터에서 사용한다.
예를 들어, `example.com.node-restriction.kubernetes.io/fips=true` 또는 `example.com.node-restriction.kubernetes.io/pci-dss=true` 이다.
## 어피니티(affinity)와 안티-어피니티(anti-affinity)
`nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 매우 간단한 방법을 제공한다.
어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다.
1. 언어가 보다 표현적이다("AND 또는 정확한 일치" 만이 아니다).
2. 규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도,
파드가 계속 스케줄 되도록 한다.
3. 노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다.
이를 통해 어떤 파드가 함께 위치할 수 있는지와 없는지에 대한 규칙을 적용할 수 있다.
어피니티 기능은 "노드 어피니티" 와 "파드 간 어피니티/안티-어피니티" 두 종류의 어피니티로 구성된다.
노드 어피니티는 기존 `nodeSelector` 와 비슷하지만(그러나 위에서 나열된 첫째와 두 번째 이점이 있다.),
파드 간 어피니티/안티-어피니티는 위에서 나열된 세번째 항목에 설명된 대로
노드 레이블이 아닌 파드 레이블에 대해 제한되고 위에서 나열된 첫 번째와 두 번째 속성을 가진다.
### 노드 어피니티
노드 어피니티는 개념적으로 `nodeSelector` 와 비슷하다 -- 이는 노드의 레이블을 기반으로 파드를
스케줄할 수 있는 노드를 제한할 수 있다.
여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는
두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄 되도록 *반드시*
규칙을 만족해야 하는 것(`nodeSelector` 와 같으나 보다 표현적인 구문을 사용해서)을 지정하고,
후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서
이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의
레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 여전히 그 노드에서
동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는
점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 같은 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이
될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고
하지만, 불가능하다면 다른 곳에서 일부를 실행하도록 허용"이 있을 것이다.
노드 어피니티는 PodSpec의 `affinity` 필드의 `nodeAffinity` 필드에서 지정된다.
여기에 노드 어피니티를 사용하는 파드 예시가 있다.
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
이 노드 어피니티 규칙은 키가 `kubernetes.io/e2e-az-name` 이고 값이 `e2e-az1` 또는 `e2e-az2` 인
레이블이 있는 노드에만 파드를 배치할 수 있다고 말한다. 또한, 이 기준을 충족하는 노드들
중에서 키가 `another-node-label-key` 이고 값이 `another-node-label-value` 인 레이블이 있는 노드를
선호하도록 한다.
예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
`NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나,
특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/docs/concepts/configuration/taint-and-toleration/)를 설정할 수 있다.
`nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는
*둘 다* 반드시 만족해야 한다.
`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, 파드를 `nodeSelectorTerms` 가 지정된 것 중 **한 가지**라도 만족하는 노드에 스케줄할 수 있다.
`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 를 **모두** 만족하는 노드에만 스케줄할 수 있다.
파드가 스케줄 된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다.
`preferredDuringSchedulingIgnoredDuringExecution` 의 `weight` 필드의 범위는 1-100이다. 모든 스케줄링 요구 사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해 스케줄러는 이 필드의 요소들을 반복해서 합계를 계산하고 노드가 MatchExpressions 에 일치하는 경우 합계에 "가중치(weight)"를 추가한다. 이후에 이 점수는 노드에 대한 다른 우선순위 함수의 점수와 합쳐진다. 전체 점수가 가장 높은 노드를 가장 선호한다.
### 파드간 어피니티와 안티-어피니티
파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기반으로 하지 않고, *노드에서 이미 실행 중인 파드 레이블을 기반으로*
파드가 스케줄될 수 있는 노드를 제한할 수 있다. 규칙은 "X가 규칙 Y를 충족하는 하나 이상의 파드를 이미 실행중인 경우
이 파드는 X에서 실행해야 한다(또는 안티-어피니티가 없는 경우에는 동작하면 안된다)"는 형태이다. Y는
선택적으로 연관된 네임스페이스 목록을 가진 LabelSelector로 표현된다. 노드와는 다르게 파드는 네임스페이스이기에
(그리고 따라서 파드의 레이블은 암암리에 네임스페이스이다) 파드 레이블위의 레이블 셀렉터는 반드시
셀렉터가 적용될 네임스페이스를 지정해야만 한다. 개념적으로 X는 노드, 랙,
클라우드 공급자 영역, 클라우드 공급자 지역 등과 같은 토폴로지 도메인이다. 시스템이 이런 토폴로지
도메인을 나타내는 데 사용하는 노드 레이블 키인 `topologyKey` 를 사용하여 이를 표현한다.
예: [넘어가기 전에: 빌트인 노드 레이블](#built-in-node-labels) 섹션 위에 나열된 레이블 키를 본다.
{{< note >}}
파드간 어피니티와 안티-어피니티에는 상당한 양의 프로세싱이 필요하기에
대규모 클러스터에서는 스케줄링 속도가 크게 느려질 수 있다.
수백 개의 노드를 넘어가는 클러스터에서 이를 사용하는 것은 추천하지 않는다.
{{< /note >}}
{{< note >}}
파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. 즉, 클러스터의 모든 노드는 `topologyKey` 와 매칭되는 적절한 레이블을 가지고 있어야 한다. 일부 또는 모든 노드에 지정된 `topologyKey` 레이블이 없는 경우에는 의도하지 않은 동작이 발생할 수 있다.
{{< /note >}}
노드 어피니티와 마찬가지로 현재 파드 어피니티와 안티-어피니티로 부르는 "엄격함" 대 "유연함"의 요구사항을 나타내는 `requiredDuringSchedulingIgnoredDuringExecution` 와
`preferredDuringSchedulingIgnoredDuringExecution` 두 가지 종류가 있다.
앞의 노드 어피니티 섹션의 설명을 본다.
`requiredDuringSchedulingIgnoredDuringExecution` 어피니티의 예시는
"서로 많은 통신을 하기 때문에 서비스 A와 서비스 B를 같은 영역에 함께 위치시키는 것"이고,
`preferredDuringSchedulingIgnoredDuringExecution` 안티-어피니티의 예시는 "서비스를 여러 영역에 걸쳐서 분배하는 것"이다
(엄격한 요구사항은 영역보다 파드가 더 많을 수 있기 때문에 엄격한 요구사항은 의미가 없다).
파드간 어피니티는 PodSpec에서 `affinity` 필드 중 `podAffinity` 필드로 지정한다.
그리고 파드간 안티-어피니티는 PodSpec에서 `affinity` 필드 중 `podAntiAffinity` 필드로 지정한다.
#### 파드 어피니티를 사용하는 파드의 예시
{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
이 파드의 어피니티는 하나의 파드 어피니티 규칙과 하나의 파드 안티-어피니티 규칙을 정의한다.
이 예시에서 `podAffinity` 는 `requiredDuringSchedulingIgnoredDuringExecution` 이고 `podAntiAffinity` 는
`preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값
"S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다.
(보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키
`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, 노드 N이 키
`failure-domain.beta.kubernetes.io/zone` 와 일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.)
파드 안티-어피니티 규칙에 의하면 노드가 이미 키 "security"와 값 "S2"인 레이블을 가진 파드를
실행하고 있는 파드는 노드에 스케줄되는 것을 선호하지 않는다.
(만약 `topologyKey` 가 `failure-domain.beta.kubernetes.io/zone` 라면 노드가 키
"security"와 값 "S2"를 레이블로 가진 파드와
동일한 영역에 있는 경우, 노드에 파드를 예약할 수 없음을 의미한다.)
[디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)를 통해
`requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 의
파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다.
파드 어피니티와 안티-어피니티의 적합한 연산자는 `In`, `NotIn`, `Exists`, `DoesNotExist` 이다.
원칙적으로, `topologyKey` 는 적법한 어느 레이블-키도 될 수 있다.
하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다.
1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해
`topologyKey` 가 비어있는 것을 허용하지 않는다.
2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다.
3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티의 경우 빈 `topologyKey` 는 "all topology"("all topology"는 현재 `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` 그리고 `failure-domain.beta.kubernetes.io/region` 의 조합으로 제한된다)로 해석한다.
4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다.
`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
선택적으로 지정할 수 있다(이것은 `labelSelector` 와 `topologyKey` 와 같은 수준의 정의이다).
생략되어있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와
연관된 `matchExpressions` 가 모두 충족되어야 한다.
#### 더 실용적인 유스케이스
파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은
상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다. 워크로드 집합이 동일한 노드와 같이
동일하게 정의된 토폴로지와 같은 위치에 배치되도록 쉽게 구성할 수 있다.
##### 항상 같은 노드에 위치시키기
세 개의 노드가 있는 클러스터에서 웹 애플리케이션에는 redis와 같은 인-메모리 캐시가 있다. 웹 서버가 가능한 캐시와 함께 위치하기를 원한다.
다음은 세 개의 레플리카와 셀렉터 레이블이 `app=store` 가 있는 간단한 redis 디플로이먼트의 yaml 스니펫이다. 디플로이먼트에는 스케줄러가 단일 노드에서 레플리카를 함께 배치하지 않도록 `PodAntiAffinity` 가 구성되어 있다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-cache
spec:
selector:
matchLabels:
app: store
replicas: 3
template:
metadata:
labels:
app: store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: redis-server
image: redis:3.2-alpine
```
아래 yaml 스니펫의 웹서버 디플로이먼트는 `podAntiAffinity` 와 `podAffinity` 설정을 가지고 있다. 이렇게 하면 스케줄러에 모든 레플리카는 셀렉터 레이블이 `app=store` 인 파드와 함께 위치해야 한다. 또한 각 웹 서버 레플리카가 단일 노드의 같은 위치에 있지 않도록 한다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
selector:
matchLabels:
app: web-store
replicas: 3
template:
metadata:
labels:
app: web-store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-store
topologyKey: "kubernetes.io/hostname"
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: web-app
image: nginx:1.12-alpine
```
만약 위의 두 디플로이먼트를 생성하면 세 개의 노드가 있는 클러스터는 다음과 같아야 한다.
| node-1 | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| *webserver-1* | *webserver-2* | *webserver-3* |
| *cache-1* | *cache-2* | *cache-3* |
여기서 볼 수 있듯이 `web-server` 의 세 레플리카들이 기대했던 것처럼 자동으로 캐시와 함께 위치하게 된다.
```
kubectl get pods -o wide
```
출력은 다음과 유사할 것이다.
```
NAME READY STATUS RESTARTS AGE IP NODE
redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3
redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1
redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2
web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1
web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3
web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2
```
##### 절대 동일한 노드에 위치시키지 않게 하기
위의 예시에서 `topologyKey:"kubernetes.io/hostname"` 과 함께 `PodAntiAffinity` 규칙을 사용해서
두 개의 인스터스가 동일한 호스트에 있지 않도록 redis 클러스터를 배포한다.
같은 기술을 사용해서 고 가용성을 위해 안티-어피니티로 구성된 스테이트풀셋의 예시는
[ZooKeeper 튜토리얼](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)을 본다.
## nodeName
`nodeName` 은 가장 간단한 형태의 노트 선택 제약 조건이지만,
한계로 인해 일반적으로는 사용하지 않는다.
`nodeName` 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는
파드를 무시하고 명명된 노드에서 실행 중인 kubelet이
파드를 실행하려고 한다. 따라서 만약 PodSpec에 `nodeName` 가
제공된 경우, 노드 선텍을 위해 위의 방법보다 우선한다.
`nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.
- 만약 명명된 노드가 없으면, 파드가 실행되지 않고
따라서 자동으로 삭제될 수 있다.
- 만약 명명된 노드에 파드를 수용할 수 있는
리소스가 없는 경우 파드가 실패하고, 그 이유는 다음과 같이 표시된다.
예: OutOfmemory 또는 OutOfcpu.
- 클라우드 환경의 노드 이름은 항상 예측 가능하거나
안정적인 것은 아니다.
여기에 `nodeName` 필드를 사용하는 파드 설정 파일 예시가 있다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
nodeName: kube-01
```
위 파드는 kube-01 노드에서 실행될 것이다.
{{% /capture %}}
{{% capture whatsnext %}}
[테인트](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다.
[노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와
[파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는
이러한 기능에 대한 추가 배경 정보가 있다.
파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.
[토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는
노드 수준의 리소스 할당 결정에 참여할 수 있다.
{{% /capture %}}
content/ko/docs/concepts/containers/images.md
+9 -18
View File
@@ -120,9 +120,9 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다
- 위의 모든 요구 사항을 확인한다.
- 워크스테이션에서 $REGION (예: `us-west-2`)의 자격 증명을 얻는다. 그 자격 증명을 사용하여 해당 호스트로 SSH를 하고 Docker를 수동으로 실행한다. 작동하는가?
- kubelet이 `--cloud-provider=aws`로 실행 중인지 확인한다.
- kubelet 로그 수준을 최소 3 이상으로 늘리고 kubelet 로그에서 (예: `journalctl -u kubelet`) 다음과 같은 로그 라인을 확인한다.
- `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API`
- `aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com`
- kubelet 로그에서 (예: `journalctl -u kubelet`) 다음과 같은 로그 라인을 확인한다.
- `plugins.go:56] Registering credential provider: aws-ecr-key`
- `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
### Azure 컨테이너 레지스트리(ACR) 사용
[Azure 컨테이너 레지스트리](https://azure.microsoft.com/en-us/services/container-registry/)를 사용하는 경우
@@ -202,7 +202,7 @@ Docker는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또
프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다.
```shell
```yaml
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
@@ -215,27 +215,20 @@ spec:
imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
EOF
```
```
pod/private-image-test-1 created
```
만약 모든 것이 잘 작동한다면, 잠시 후에, 다음을 실행할 수 있다.
만약 모든 것이 잘 작동한다면, 잠시 후에, 다음 메시지를 볼 것이다.
```shell
kubectl logs private-image-test-1
```
그리고 커맨드 출력을 본다.
```
SUCCESS
```
명령이 실패한 것으로 의심되는 경우 다음을 실행할 수 있다.
만약 실패했다면, 다음 메시지를 볼 것이다.
```shell
kubectl describe pods/private-image-test-1 | grep 'Failed'
```
실패하는 케이스에는 출력이 다음과 유사하다.
```
kubectl describe pods/private-image-test-1 | grep "Failed"
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
```
@@ -361,9 +354,7 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
- 각 테넌트에 대한 레지스트리 자격 증명을 생성하고, 시크릿에 넣고, 각 테넌트 네임스페이스에 시크릿을 채운다.
- 테넌트는 해당 시크릿을 각 네임스페이스의 imagePullSecrets에 추가한다.
{{% /capture %}}
다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다.
{{% /capture %}}
content/ko/docs/concepts/containers/runtime-class.md
+6 -7
View File
@@ -117,7 +117,7 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/prod
쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다.
#### {{< glossary_tooltip term_id="containerd" >}}
#### [containerd](https://containerd.io/)
런타임 핸들러는 containerd의 구성 파일인 `/etc/containerd/config.toml` 통해 설정한다.
유효한 핸들러는 runtimes 단락 아래에서 설정한다.
@@ -129,10 +129,10 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/prod
더 자세한 containerd의 구성 문서를 살펴본다.
https://github.com/containerd/cri/blob/master/docs/config.md
#### {{< glossary_tooltip term_id="cri-o" >}}
#### [cri-o](https://cri-o.io/)
런타임 핸들러는 CRI-O의 구성파일인 `/etc/crio/crio.conf`을 통해 설정한다.
[crio.runtime 테이블](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) 아래에
런타임 핸들러는 cri-o의 구성파일인 `/etc/crio/crio.conf`을 통해 설정한다.
[crio.runtime 테이블](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) 아래에
유효한 핸들러를 설정한다.
```
@@ -140,9 +140,8 @@ https://github.com/containerd/cri/blob/master/docs/config.md
runtime_path = "${PATH_TO_BINARY}"
```
더 자세한 것은 CRI-O의 [설정 문서][100]를 본다.
[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
더 자세한 cri-o의 구성 문서를 살펴본다.
https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
### 스케줄
content/ko/docs/concepts/overview/components.md
+6 -5
View File
@@ -9,7 +9,7 @@ card:
{{% capture overview %}}
쿠버네티스를 배포하면 클러스터를 얻는다.
{{< glossary_definition term_id="cluster" length="all" prepend="쿠버네티스 클러스터는">}}
{{< glossary_definition term_id="cluster" length="all" prepend="클러스터는">}}
이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한
다양한 컴포넌트들에 대해 요약하고 정리한다.
@@ -21,12 +21,13 @@ card:
{{% /capture %}}
{{% capture body %}}
## 컨트롤 플래인 컴포넌트
## 마스터 컴포넌트
컨트롤 플래인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드에 대한 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동시키는 것)를 감지하고 반응한다.
마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동시키는 것)를 감지하고 반응한다.
컨트롤 플래인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플래인 컴포넌트를 구동시키고,
마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면
[고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다.
content/ko/docs/concepts/overview/kubernetes-api.md
+1 -1
View File
@@ -59,7 +59,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/)
쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다.
이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거되었다.
이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거될 예정이다.
## API 버전 규칙
content/ko/docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -13,7 +13,7 @@ weight: 30
기본적으로 도커는 호스트-프라이빗 네트워킹을 사용하기에 컨테이너는 동일한 머신에 있는 경우에만 다른 컨테이너와 통신 할 수 있다. 도커 컨테이너가 노드를 통해 통신하려면 머신 포트에 IP 주소가 할당되어야 컨테이너에 전달되거나 프록시된다. 이것은 컨테이너가 사용하는 포트를 매우 신중하게 조정하거나 포트를 동적으로 할당해야 한다는 의미이다.
컨테이너를 제공하는 여러 개발자 또는 팀에서 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
여러 개발자에 걸쳐있는 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 모든 파드에게 자체 클러스터-프라이빗-IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다. 동일한 원칙이 보다 완전한 [Jenkins CI 애플리케이션](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)에서 구현된다.
content/ko/docs/concepts/services-networking/endpoint-slices.md
+15 -104
View File
@@ -1,7 +1,7 @@
---
title: 엔드포인트슬라이스
title: 엔드포인트 슬라이스
feature:
title: 엔드포인트슬라이스
title: 엔드포인트 슬라이스
description: >
쿠버네티스 클러스터에서 확장 가능한 네트워크 엔드포인트 추적.
@@ -14,7 +14,7 @@ weight: 10
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
_엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
_엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
대안을 제안한다.
@@ -22,14 +22,13 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
{{% capture body %}}
## 엔드포인트슬라이스 리소스 {#endpointslice-resource}
## 엔드포인트 슬라이스 리소스 {#endpointslice-resource}
쿠버네티스에서 EndpointSlice는 일련의 네트워크 엔드 포인트에 대한
참조를 포함한다. 쿠버네티스 서비스에 {{< glossary_tooltip text="셀렉터"
term_id="selector" >}} 가 지정되면 EndpointSlice
컨트롤러는 자동으로 엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다.
참조를 포함한다. 쿠버네티스 서비스에 셀렉터가 지정되면 EndpointSlice
컨트롤러는 자동으로 엔드포인트 슬라이스를 생성한다. 이 엔드포인트 슬라이스는
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트
슬라이스는 고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다.
예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice
리소스 샘플이 있다.
@@ -48,7 +47,7 @@ ports:
port: 80
endpoints:
- addresses:
- "10.1.2.3"
- "10.1.2.3"
conditions:
ready: true
hostname: pod-1
@@ -57,15 +56,15 @@ endpoints:
topology.kubernetes.io/zone: us-west2-a
```
기본적으로, EndpointSlice 컨트롤러가 관리하는 엔드포인트슬라이스에는
각각 100개 이하의 엔드포인트를 가지고 있다. 이 스케일 아래에서 엔드포인트슬라이스는
기본적으로, EndpointSlice 컨트롤러가 관리하는 엔드포인트 슬라이스에는
각각 100개 이하의 엔드포인트를 가지고 있다. 이 스케일 아래에서 엔드포인트 슬라이스는
엔드포인트 및 서비스와 1:1로 매핑해야하며, 유사한 성능을 가져야 한다.
엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해 kube-proxy에
엔드포인트 슬라이스는 내부 트래픽을 라우트하는 방법에 대해 kube-proxy에
신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
서비스에 대해 성능 향상을 제공해야 한다.
### 주소 유형
## 주소 유형
EndpointSlice는 다음 주소 유형을 지원한다.
@@ -73,94 +72,6 @@ EndpointSlice는 다음 주소 유형을 지원한다.
* IPv6
* FQDN (Fully Qualified Domain Name)
### 토폴로지
엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면
다음의 토폴로지 레이블이 엔드포인트슬라이스 컨트롤러에 의해 설정된다.
* `kubernetes.io/hostname` - 이 엔드포인트가 있는 노드의 이름.
* `topology.kubernetes.io/zone` - 이 엔드포인트가 있는 영역의 이름.
* `topology.kubernetes.io/region` - 이 엔드포인트가 있는 지역의 이름.
이런 레이블 값은 슬라이스의 각 엔드포인트와 연관된 리소스에서
파생된다. 호스트 이름 레이블은 해당 파드의
NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당
노드에서 이름이 같은 값을 나타낸다.
### 관리
기본적으로 엔드포인트슬라이스는 엔드포인트슬라이스 컨트롤러에의해
생성되고 관리된다. 서비스 메시 구현과 같은 다른 엔드포인트슬라이스
유스 케이스는 다른 엔터티나 컨트롤러가 추가 엔드포인트슬라이스
집합을 관리할 수 있게 할 수 있다. 여러 엔티티가 서로 간섭하지 않고
엔드포인트슬라이스를 관리할 수 있도록 엔드포인트슬라이스를 관리하는
엔티티를 나타내는데 `endpointslice.kubernetes.io/managed-by` 레이블이 사용된다.
엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트
슬라이스에 레이블의 값으로 `endpointslice-controller.k8s.io` 를 설정한다.
엔드포인트슬라이스를 관리하는 다른 엔티티도 이 레이블에
고유한 값을 설정해야 한다.
### 소유권
대부분의 유스 케이스에서 엔드포인트를 추적하는 서비스가 엔드포인트슬라이스를
소유한다. 이는 각 엔드포인트슬라이스의 참조와 서비스에 속하는 모든
엔드포인트슬라이스를 간단하게 조회할 수 있는 `kubernetes.io/service-name`
레이블로 표시된다.
## 엔드포인트슬라이스 컨트롤러
엔드포인트슬라이스 컨트롤러는 해당 엔드포인트슬라이스가 최신 상태인지
확인하기 위해 서비스와 파드를 감시한다. 컨트롤러가 셀렉터로 지정한 모든
서비스에 대해 엔드포인트슬라이스를 관리한다. 이는 서비스 셀렉터와
일치하는 파드의 IP를 나타내게 된다.
### 엔드포인트슬라이스의 크기
기본적으로 엔드포인트슬라이스는 각각 100개의 엔드포인트 크기로 제한된다.
최대 1000개까지 `--max-endpoints-per-slice` {{< glossary_tooltip
text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그를
사용해서 구성할 수 있다.
### 엔드포인트슬라이스의 배포
각 엔드포인트슬라이스에는 리소스 내에 모든 엔드포인트가 적용되는
포트 집합이 있다. 서비스에 알려진 포트를 사용하는 경우 파드는
동일하게 알려진 포트에 대해 다른 대상 포트 번호로 끝날 수 있으며 다른
엔드포인트슬라이스가 필요하다. 이는 하위 집합이 엔드포인트와 그룹화하는
방식의 논리와 유사하다.
컨트롤러는 엔드포인트슬라이스를 최대한 채우려고 노력하지만,
적극적으로 재조정하지는 않는다. 컨트롤러의 동작은 매우 직관적이다.
1. 기존 엔드포인트슬라이스에 대해 반복적으로, 더 이상 필요하지 않는 엔드포인트를
제거하고 변경에 의해 일치하는 엔드포인트를 업데이트 한다.
2. 첫 번째 단계에서 수정된 엔드포인트슬라이스를 반복해서
필요한 새 엔드포인트로 채운다.
3. 추가할 새 엔드포인트가 여전히 남아있으면, 이전에 변경되지 않은
슬라이스에 엔드포인트를 맞추거나 새로운 것을 생성한다.
중요한 것은, 세 번째 단계는 엔드포인트슬라이스를 완벽하게 전부 배포하는 것보다
엔드포인트슬라이스 업데이트 제한을 우선시한다. 예를 들어, 추가할 새 엔드포인트가
10개이고 각각 5개의 공간을 사용할 수 있는 엔드포인트 공간이 있는 2개의
엔드포인트슬라이스가 있는 경우, 이 방법은 기존 엔드포인트슬라이스
2개를 채우는 대신에 새 엔드포인트슬라이스를 생성한다. 다른 말로, 단일
엔드포인트슬라이스를 생성하는 것이 여러 엔드포인트슬라이스를 업데이트하는 것 보다 더 선호된다.
각 노드에서 kube-proxy를 실행하고 엔드포인트슬라이스를 관찰하면,
엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기
때문에 상대적으로 비용이 많이 소요된다. 이 방법은 여러 엔드포인트슬라이스가
가득 차지 않은 결과가 발생할지라도, 모든 노드에 전송해야 하는
변경 횟수를 의도적으로 제한하기 위한 것이다.
실제로는, 이러한 이상적이지 않은 분배는 드물 것이다. 엔드포인트슬라이스
컨트롤러에서 처리하는 대부분의 변경 내용은 기존 엔드포인트슬라이스에
적합할 정도로 적고, 그렇지 않은 경우 새 엔드포인트슬라이스가
필요할 수 있다. 디플로이먼트의 롤링 업데이트도 모든 파드와 해당
교체되는 엔드포인트에 대해서 엔드포인트슬라이스를
자연스럽게 재포장한다.
## 사용동기
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
@@ -173,14 +84,14 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
리소스에 저장되기 때문에 엔드포인트 리소스가 상당히 커질 수 있다. 이것은 쿠버네티스
구성요소 (특히 마스터 컨트롤 플레인)의 성능에 영향을 미쳤고
엔드포인트가 변경될 때 상당한 양의 네트워크 트래픽과 처리를 초래했다.
엔드포인트슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과
엔드포인트 슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과
같은 추가 기능을 위한 확장 가능한 플랫폼을 제공한다.
{{% /capture %}}
{{% capture whatsnext %}}
* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)
* [엔드포인트 슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)
* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 를 읽는다.
{{% /capture %}}
content/ko/docs/concepts/services-networking/ingress-controllers.md
-1
View File
@@ -21,7 +21,6 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
## 추가 컨트롤러
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
[커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
[Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
content/ko/docs/concepts/services-networking/service.md
+16 -11
View File
@@ -184,17 +184,17 @@ ExternalName 서비스는 셀렉터가 없고
DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
### 엔드포인트슬라이스
### 엔드포인트 슬라이스
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스를
엔드포인트 슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트 슬라이스를
사용하면 여러 리소스에 네트워크 엔드포인트를 분산시킬 수 있다. 기본적으로,
엔드포인트슬라이스는 100개의 엔드포인트에 도달하면 "가득찬 것"로 간주되며,
추가 엔드포인트를 저장하기 위해서는 추가 엔드포인트슬라이스가
엔드포인트 슬라이스는 100개의 엔드포인트에 도달하면 "가득찬 것"로 간주되며,
추가 엔드포인트를 저장하기 위해서는 추가 엔드포인트 슬라이스가
생성된다.
엔드포인트슬라이스는 [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에서
엔드포인트 슬라이스는 [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에서
자세하게 설명된 추가적인 속성 및 기능을 제공한다.
## 가상 IP와 서비스 프록시
@@ -484,7 +484,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
`externalName` 필드의 컨텐츠 (예:`foo.bar.example.com`)에
맵핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
{{< note >}}
`ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다.
`ExternalName` 유형을 사용하려면 CoreDNS 버전 1.7 이상이 필요하다.
{{< /note >}}
[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
@@ -548,9 +548,6 @@ status:
외부 로드 밸런서의 트래픽은 백엔드 파드로 전달된다. 클라우드 공급자는 로드 밸런싱 방식을 결정한다.
로드 밸런서 서비스 유형의 경우 두 개 이상의 포트가 정의된 경우,
모든 포트의 프로토콜이 동일해야 하고, 프로토콜은 `TCP`, `UDP` 그리고
`SCTP` 중 하나여야 한다.
일부 클라우드 공급자는 `loadBalancerIP`를 지정할 수 있도록 허용한다. 이 경우, 로드 밸런서는
사용자 지정 `loadBalancerIP`로 생성된다. `loadBalancerIP` 필드가 지정되지 않으면,
@@ -1103,15 +1100,21 @@ IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이
### TCP
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
모든 종류의 서비스에 TCP를 사용할 수 있으며, 이는 기본 네트워크 프로토콜이다.
### UDP
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
대부분의 서비스에 UDP를 사용할 수 있다. type=LoadBalancer 서비스의 경우, UDP 지원은
이 기능을 제공하는 클라우드 공급자에 따라 다르다.
### HTTP
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
클라우드 공급자가 이를 지원하는 경우, LoadBalancer 모드의
서비스를 사용하여 서비스의 엔드포인트로 전달하는 외부 HTTP / HTTPS 리버스 프록시를
설정할 수 있다.
@@ -1123,6 +1126,8 @@ HTTP / HTTPS 서비스를 노출할 수도 있다.
### PROXY 프로토콜
{{< feature-state for_k8s_version="v1.1" state="stable" >}}
클라우드 공급자가 지원하는 경우에 (예: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)),
LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부에
로드 밸런서를 구성할 수 있으며, 이때 접두사가
@@ -1191,6 +1196,6 @@ kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지
* [서비스와 애플리케이션 연결](/docs/concepts/services-networking/connect-applications-service/) 알아보기
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기
* [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
* [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
{{% /capture %}}
content/ko/docs/concepts/workloads/controllers/replicaset.md
+4 -4
View File
@@ -73,7 +73,7 @@ kubectl describe rs/frontend
```shell
Name: frontend
Namespace: default
Selector: tier=frontend
Selector: tier=frontend,tier in (frontend)
Labels: app=guestbook
tier=frontend
Annotations: <none>
@@ -132,7 +132,7 @@ metadata:
name: frontend-9si5l
namespace: default
ownerReferences:
- apiVersion: apps/v1
- apiVersion: extensions/v1beta1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
@@ -257,7 +257,7 @@ REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `
예시:
```shell
kubectl proxy --port=8080
curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
> -H "Content-Type: application/json"
```
@@ -269,7 +269,7 @@ REST API 또는 `client-go` 라이브러리를 이용할 때는 `propagationPoli
예시:
```shell
kubectl proxy --port=8080
curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
> -H "Content-Type: application/json"
```
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
+1 -2
View File
@@ -6,7 +6,7 @@ weight: 80
{{% capture overview %}}
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
{{< feature-state state="alpha" >}}
이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip term_id="pod" >}} 에서
@@ -187,7 +187,6 @@ kubectl attach -it example-pod -c debugger
예를 들어, 임시 컨테이너에 붙은 이후에 디버거 컨테이너에서 `ps` 를 실행한다.
```shell
# "디버거" 임시 컨테이너 내부 쉘에서 이것을 실행한다.
ps auxww
```
다음과 유사하게 출력된다.
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
View File
@@ -186,7 +186,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
...
```
* `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. `postStart` 훅(있는 경우)은 컨테이너가 Running 상태가 되기 전에 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다.
* `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. 컨테이너가 Running 상태가 되면, `postStart` 훅이 (존재한다면) 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다.
```yaml
...
content/ko/docs/contribute/localization_ko.md
+2 -16
View File
@@ -150,15 +150,14 @@ Active Job | 액티브 잡 |
Addons | 애드온 |
admission controller | 어드미션 컨트롤러 |
Age | 기간 |
Allocation | 할당량 |
alphanumeric | 영숫자 |
Allocation | 할당량
Annotation | 어노테이션 |
App | 앱 |
Appendix | 부록 |
Application | 애플리케이션 |
Args | Args | 약어의 형태이므로 한글화하지 않고 영문 표기
array | 배열 |
autoscaler | 오토스케일러 |
autoscaler | 오토스케일러
availability zone | 가용성 영역(availability zone) |
bare pod | 베어(bare) 파드 |
beta | 베타 |
@@ -201,8 +200,6 @@ distros | 배포판 |
Docker | 도커 |
Dockerfile | Dockerfile |
Downward API | 다운워드(Downward) API |
draining | 드레이닝(draining) |
egress | 이그레스, 송신(egress) |
Endpoint | 엔드포인트 |
entry point | 진입점 |
Event | 이벤트 |
@@ -244,7 +241,6 @@ lifecycle | 라이프사이클 |
Linux | 리눅스 |
load | 부하 |
Log | 로그 |
loopback | 루프백(loopback) |
Lost | Lost | 클레임의 상태에 한함
Machine | 머신 |
manifest | 매니페스트 |
@@ -252,14 +248,11 @@ Master | 마스터 |
max limit/request ratio | 최대 상한/요청량 비율 |
metadata | 메타데이터 |
metric | 메트릭 |
masquerading | 마스커레이딩 |
Minikube | Minikube |
Mirror pod | 미러 파드(mirror pod) |
monitoring | 모니터링 |
multihomed | 멀티홈드(multihomed) |
naked pod | 네이키드(naked) 파드 |
Namespace | 네임스페이스 |
netfilter | 넷필터(netfilter) |
Network Policy | 네트워크 폴리시 |
Node | 노드 |
node lease | 노드 리스(lease)
@@ -286,12 +279,8 @@ Pull Request | 풀 리퀘스트 |
Pull Secret Credentials | 풀(Pull) 시크릿 자격증명 |
QoS Class | QoS 클래스 |
Quota | 쿼터 |
readiness gate | 준비성 게이트(readiness gate) |
readiness probe | 준비성 프로브(readiness probe) |
Ready | Ready |
Reclaim Policy | 반환 정책 |
redirect | 리다이렉트(redirect) |
redirection | 리다이렉션 |
Registry | 레지스트리 |
Release | 릴리스 |
Replica Set | 레플리카 셋 |
@@ -325,8 +314,6 @@ Shell | 셸 |
Sign In | 로그인 |
Sign Out | 로그아웃 |
skew | 차이(skew) |
spec | 명세, 스펙, 사양 |
specification | 명세 |
Stateful Set | 스테이트풀 셋 |
stateless | 스테이트리스 |
Static pod | 스태틱(static) 파드 |
@@ -345,7 +332,6 @@ traffic | 트래픽 |
Type | 타입 |
ubuntu | 우분투 |
use case | 유스케이스 |
userspace | 유저스페이스(userspace) |
Utilization | 사용량, 사용률 |
verbosity | 로그 상세 레벨(verbosity) |
virtualization | 가상화 |
content/ko/docs/contribute/style/write-new-topic.md
+2 -3
View File
@@ -115,9 +115,8 @@ YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때
`<LANG>/examples/` 의 하위 디렉토리 중 하나에 코드를 배치하자. 여기서 `<LANG>`은
주제에 관한 언어이다. 문서 파일에서 `codenew` 단축 코드(shortcode)를 사용하자.
```none
{{</* codenew file="<RELPATH>/my-example-yaml>" */>}}
```
<pre>&#123;&#123;&lt; codenew file="&lt;RELPATH&gt;/my-example-yaml&gt;" &gt;&#125;&#125;</pre>
여기서 `<RELPATH>` 는 `examples` 디렉토리와 관련하여 포함될
파일의 경로이다. 다음 Hugo 단축 코드(shortcode)는 `/content/en/examples/pods/storage/gce-volume.yaml`
에 있는 YAML 파일을 참조한다.
content/ko/docs/reference/glossary/cluster.md
+3 -3
View File
@@ -4,14 +4,14 @@ id: cluster
date: 2019-06-15
full_link:
short_description: >
컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.
쿠버네티스에서 관리하는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 기계의 집합. 클러스터는 최소 1개의 워커 노드와 최소 1개의 마스터 노드를 가진다.
aka:
tags:
- fundamental
- operation
---
컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.
쿠버네티스에서 관리하는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 기계의 집합. 클러스터는 최소 1개의 워커 노드와 최소 1개의 마스터 노드를 가진다.
<!--more-->
워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다. 컨트롤 플레인은 워커 노드와 클러스터 내 파드를 관리한다. 프로덕션 환경에서는 일반적으로 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를 실행하므로 내결함성과 고가용성이 제공된다.
워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다. 마스터 노드는 워커 노드와 클러스터 내 파드를 관리한다. 다수의 마스터 노드는 장애극복(failover)과 고가용성의 클러스터에서 사용한다.
content/ko/docs/reference/glossary/container-runtime.md
+4 -4
View File
@@ -15,7 +15,7 @@ tags:
<!--more-->
쿠버네티스는 여러 컨테이너 런타임을 지원한다. {{< glossary_tooltip term_id="docker">}},
{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}
그리고 [Kubernetes CRI (컨테이너 런타임
인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 소프트웨어.
쿠버네티스는 여러 컨테이너 런타임을 지원한다. [Docker](http://www.docker.com),
[containerd](https://containerd.io), [cri-o](https://cri-o.io/),
[rktlet](https://github.com/kubernetes-incubator/rktlet)과
[Kubernetes CRI (컨테이너 런타임 인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 소프트웨어.
content/ko/docs/reference/glossary/kube-controller-manager.md
+1 -1
View File
@@ -4,7 +4,7 @@ id: kube-controller-manager
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
short_description: >
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 프로세스를 실행하는 컨트롤 플레인 컴포넌트.
컨트롤러를 구동하는 마스터 상의 컴포넌트.
aka:
tags:
content/ko/docs/reference/glossary/kube-scheduler.md
+2 -2
View File
@@ -4,13 +4,13 @@ id: kube-scheduler
date: 2018-04-12
full_link: /docs/reference/generated/kube-scheduler/
short_description: >
노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.
노드가 배정되지 않은 새로 생성된 파드를 감지하고 그것이 구동될 노드를 선택하는 마스터 상의 컴포넌트.
aka:
tags:
- architecture
---
노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.
노드가 배정되지 않은 새로 생성된 파드를 감지하고 그것이 구동될 노드를 선택하는 마스터 상의 컴포넌트.
<!--more-->
content/ko/docs/reference/glossary/pod-lifecycle.md
+3 -3
View File
@@ -9,11 +9,11 @@ related:
tags:
- fundamental
short-description: >
파드가 수명(lifetime) 동안 통과하는 상태의 순서이다.
파드가 라이프사이클 중 어느 단계(phase)에 있는지 표현하는 고수준의 요약이다.
---
파드가 수명(lifetime) 동안 통과하는 상태의 순서이다.
파드가 라이프사이클 중 어느 단계(phase)에 있는지 표현하는 고수준의 요약이다.
<!--more-->
[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드의 라이프사이클에 대한 고수준의 요약이다. 다섯 가지 파드 단계가 있다: Pending, Running, Succeeded, Failed, 그리고 Unknown. [파드 스테이터스](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core)의 `phase` 필드에 파드 상태에 대한 자세한 설명이 요약되어 있다.
[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드가 라이프사이클 중 어느 단계에 있는지 표현하는 고수준의 요약이다. 파드의 `status` 필드는 [파드 스테이터스](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) 오브젝트이다. 그것은 `phase` 필드를 가지며, Running, Pending, Succeeded, Failed, Unknown, Completed, CrashLoopBackOff 중 하나의 단계(phase)를 보여준다.
content/ko/docs/reference/issues-security/security.md
+1 -1
View File
@@ -19,7 +19,7 @@ weight: 20
우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다.
보고서를 작성하려면, [쿠버네티스 버그 현상금 프로그램](https://hackerone.com/kubernetes)에 취약점을 제출한다. 이를 통해 표준화된 응답시간으로 취약점을 분류하고 처리할 수 있다. 또한, 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)로 부터 예상되는 세부사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다.
보고서를 작성하기 위해서는 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)로부터 예상되는 세부 사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다.
[제품 보안 위원회 구성원](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc)의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다.
content/ko/docs/reference/kubectl/cheatsheet.md
-3
View File
@@ -191,9 +191,6 @@ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secre
# 타임스탬프로 정렬된 이벤트 목록 조회
kubectl get events --sort-by=.metadata.creationTimestamp
# 매니페스트가 적용된 경우 클러스터의 현재 상태와 클러스터의 상태를 비교한다.
kubectl diff -f ./my-manifest.yaml
```
## 리소스 업데이트
content/ko/docs/setup/_index.md
+1 -1
View File
@@ -79,7 +79,7 @@ card:
| [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | [사용자 정의 확장](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
| [Giant Swarm](https://www.giantswarm.io/) | &#x2714; | &#x2714; | &#x2714; | |
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
| [Hidora](https://hidora.com/) | &#x2714; | &#x2714;| &#x2714; | | | | | | | |
| [Hidora](https:/hidora.com/) | &#x2714; | &#x2714;| &#x2714; | | | | | | | |
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
| [Kontena Pharos](https://www.kontena.io/pharos/) | |&#x2714;| &#x2714; | | |
content/ko/docs/setup/best-practices/node-conformance.md
+1 -1
View File
@@ -73,7 +73,7 @@ sudo docker run -it --rm --privileged --net=host \
k8s.gcr.io/node-test:0.2
```
노드 적합성 테스트는 [노드 e2e 테스트](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md)를 컨테이너화한 버전이다.
노드 적합성 테스트는 [노드 e2e 테스트](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/sig-node/e2e-node-tests.md)를 컨테이너화한 버전이다.
기본적으로, 모든 적합성 테스트를 실행한다.
이론적으로, 컨테이너와 필요한 볼륨을 적절히 설정했다면 어떤 노드 e2e 테스트도 수행할 수 있다.
content/ko/docs/setup/learning-environment/minikube.md
+6 -3
View File
@@ -1,6 +1,5 @@
---
title: Minikube로 쿠버네티스 설치
weight: 30
content_template: templates/concept
---
@@ -258,7 +257,11 @@ minikube start \
Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. 혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, 만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다.
{{< /note >}}
맥이나 리눅스 호스트에서 해당 Docker 데몬을 사용하려면 `minikube docker-env` 에서 마지막 줄을 실행한다.
맥이나 리눅스 호스트에서 해당 Docker 데몬을 사용하려면 `docker-env command`를 쉘에서 사용해야 한다.
```shell
eval $(minikube docker-env)
```
이제 개인의 맥/리눅스 머신 내 커멘드 라인에서 도커를 사용해서 Minikube VM 안의 도커 데몬과 통신할 수 있다.
@@ -401,7 +404,7 @@ spec:
| VirtualBox | Linux | /home | /hosthome |
| VirtualBox | macOS | /Users | /Users |
| VirtualBox | Windows | C://Users | /c/Users |
| VMware Fusion | macOS | /Users | /mnt/hgfs/Users |
| VMware Fusion | macOS | /Users | /Users |
| Xhyve | macOS | /Users | /Users |
## 프라이빗 컨테이너 레지스트리
content/ko/docs/setup/production-environment/container-runtimes.md
+9 -9
View File
@@ -72,7 +72,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
# Docker CE 설치
## 리포지터리 설정
### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치
apt-get update && apt-get install -y \
apt-get update && apt-get install \
apt-transport-https ca-certificates curl software-properties-common
### Docker의 공식 GPG 키 추가
@@ -85,7 +85,7 @@ add-apt-repository \
stable"
## Docker CE 설치.
apt-get update && apt-get install -y \
apt-get update && apt-get install \
containerd.io=1.2.10-3 \
docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
@@ -113,14 +113,14 @@ systemctl restart docker
# Docker CE 설치
## 리포지터리 설정
### 필요한 패키지 설치.
yum install -y yum-utils device-mapper-persistent-data lvm2
yum install yum-utils device-mapper-persistent-data lvm2
### Docker 리포지터리 추가
yum-config-manager --add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
## Docker CE 설치.
yum update -y && yum install -y \
yum update && yum install \
containerd.io-1.2.10 \
docker-ce-19.03.4 \
docker-ce-cli-19.03.4
@@ -181,13 +181,13 @@ sysctl --system
# 선행 조건 설치
apt-get update
apt-get install -y software-properties-common
apt-get install software-properties-common
add-apt-repository ppa:projectatomic/ppa
apt-get update
# CRI-O 설치
apt-get install -y cri-o-1.15
apt-get install cri-o-1.15
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
@@ -196,7 +196,7 @@ apt-get install -y cri-o-1.15
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
# CRI-O 설치
yum install --nogpgcheck -y cri-o
yum install --nogpgcheck cri-o
{{< /tab >}}
{{< /tabs >}}
@@ -270,7 +270,7 @@ systemctl restart containerd
# containerd 설치
## 리포지터리 설정
### 필요한 패키지 설치
yum install -y yum-utils device-mapper-persistent-data lvm2
yum install yum-utils device-mapper-persistent-data lvm2
### Docker 리포지터리 추가리
yum-config-manager \
@@ -278,7 +278,7 @@ yum-config-manager \
https://download.docker.com/linux/centos/docker-ce.repo
## containerd 설치
yum update -y && yum install -y containerd.io
yum update && yum install containerd.io
# containerd 설정
mkdir -p /etc/containerd
content/ko/docs/setup/production-environment/tools/kops.md
+38 -68
View File
@@ -1,6 +1,6 @@
---
title: Kops로 쿠버네티스 설치하기
content_template: templates/task
content_template: templates/concept
weight: 20
---
@@ -9,7 +9,7 @@ weight: 20
이곳 빠른 시작에서는 사용자가 얼마나 쉽게 AWS에 쿠버네티스 클러스터를 설치할 수 있는지 보여준다.
[`kops`](https://github.com/kubernetes/kops)라는 이름의 툴을 이용할 것이다.
kops는 자동화된 프로비저닝 시스템인데,
kops는 강력한 프로비저닝 시스템인데,
* 완전 자동화된 설치
* DNS를 통해 클러스터들의 신원 확인
@@ -18,30 +18,26 @@ kops는 자동화된 프로비저닝 시스템인데,
* 고가용성 지원 - [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/operations/high_availability.md) 보기
* 직접 프로비저닝 하거나 또는 할 수 있도록 terraform 매니페스트를 생성 - [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md) 보기
{{% /capture %}}
{{% capture prerequisites %}}
* [kubectl](/docs/tasks/tools/install-kubectl/)을 반드시 설치해야 한다.
* 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 `kops` 를 [설치](https://github.com/kubernetes/kops#installing) 한다.
* [AWS 계정](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)이 있고 [IAM 키](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)를 생성하고 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) 해야 한다.
만약 클러스터를 구축하는데 있어 이런 방법이 사용자의 생각과 다르다면 일종의 블록처럼 [kubeadm](/docs/admin/kubeadm/)를 이용할 수도 있다.
kops는 kubeadmin 위에서도 잘 동작한다.
{{% /capture %}}
{{% capture steps %}}
{{% capture body %}}
## 클러스터 구축
### (1/5) kops 설치
#### 요구사항
kops를 이용하기 위해서는 [kubectl](/docs/tasks/tools/install-kubectl/)이 설치되어 있어야 한다.
#### 설치
[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스코드로부터 빌드하는것도 역시 어렵지 않다).
{{< tabs name="kops_installation" >}}
{{% tab name="macOS" %}}
MacOS에서:
최신 버전의 릴리즈를 다운받는 명령어:
@@ -82,19 +78,19 @@ sudo mv kops-darwin-amd64 /usr/local/bin/kops
brew update && brew install kops
```
{{% /tab %}}
{{% tab name="Linux" %}}
Linux에서:
최신 릴리즈를 다운로드 받는 명령어:
```shell
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
```
특정 버전의 kops를 다운로드하려면 명령의 다음 부분을 특정 kops 버전으로 변경한다.
특정 버전을 다운로드 받는다면 다음을 변경한다.
```shell
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
```
특정 버전의 명령 부분이다.
예를 들어 kops 버전을 v1.15.0을 다운로드 하려면 다음을 입력한다.
```shell
@@ -119,58 +115,38 @@ sudo mv kops-linux-amd64 /usr/local/bin/kops
brew update && brew install kops
```
{{% /tab %}}
{{< /tabs >}}
### (2/5) 클러스터에 사용할 route53 domain 생성
kops는 클러스터 내부와 외부 모두에서 검색을 위해 DNS을 사용하기에 클라이언트에서 쿠버네티스 API 서버에 연결할
수 있다.
kops는 디스커버리를 위해 클러스터 내외부에서 DNS를 이용하고 이를 통해 사용자는 쿠버네티스 API서버에 도달할 수 있다.
이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써
사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며,
IP를 기억할 필요없이 접근할 수 있다.
사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며, IP를 기억할 필요없이 접근할 수 있다.
그렇게 하고 있겠지만, 클러스터를 구분하기 위해 서브도메인을 활용할 수 있다. 예를 들어
`useast1.dev.example.com`을 이용한다면, API 서버 엔드포인트는 `api.useast1.dev.example.com`가 될 것이다.
그렇게 하고 있겠지만, 클러스터를 구분하기 위해 서브도메인을 활용할 수 있다. 예를 들어 `useast1.dev.example.com`을 이용한다면, API 서버 엔드포인트는 `api.useast1.dev.example.com`가 될 것이다.
Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone은 `useast1.dev.example.com`,
`dev.example.com` 그리고 `example.com` 같은 것도 될 수 있다. kops는 이것들 모두와 잘 동작하며,
사용자는 보통 조직적인 부분을 고려해 결정한다(예를 들어, 사용자가 `dev.example.com`하위에 레코드를 생성하는것은 허용되지만,
Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone은 `useast1.dev.example.com`, `dev.example.com` 그리고 `example.com` 같은 것도 될 수 있다.
kops는 이것들 모두와 잘 동작하며, 사용자는 보통 조직적인 부분을 고려해 결정한다(예를 들어, 사용자가 `dev.example.com`하위에 레코드를 생성하는것은 허용되지만,
`example.com`하위에는 그렇지 않을 수 있다).
`dev.example.com`을 hosted zone으로 사용하고 있다고 가정해보자.
보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나
`aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 와 같은 커맨드를 이용한다.
그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는, `dev` NS 레코드를 `example.com`에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은 도메인 등록기관을 통해서 생성해야 한다(예를 들어, `example.com`는 `example.com`를 구매한 곳에서 설정 할 수 있다).
그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는,
`dev` NS 레코드를 `example.com`에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은
도메인 등록기관을 통해서 생성해야 한다(예를 들어, `example.com`는 `example.com`를 구매한 곳에서 설정 할 수 있다).
이 단계에서 문제가 되기 쉽다.(문제를 만드는 가장 큰 이유이다!) dig 툴을 실행해서
클러스터 설정이 정확한지 한번 더 확인 한다.
이 단계에서 문제가 되기 쉽다.(문제를 만드는 가장 큰 이유이다!) dig 툴을 실행해서 클러스터 설정이 정확한지 한번 더 확인 한다.
`dig NS dev.example.com`
당신의 hosted zone용으로 할당된 3~4개의 NS 레코드를 Route53에서 확인할 수 있어야 한다.
### (3/5) 클러스터 상태 저장용 S3 버킷 생성
kops는 설치 이후에도 클러스터를 관리할 수 있다. 이를 위해 사용자가 생성한 클러스터의 상태나
사용하는 키 정보들을 지속적으로 추적해야 한다. 이 정보가 S3에 저장된다.
kops는 설치 이후에도 클러스터를 관리할 수 있다. 이를 위해 사용자가 생성한 클러스터의 상태나 사용하는 키 정보들을 지속적으로 추적해야 한다. 이 정보가 S3에 저장된다.
이 버킷의 접근은 S3 권한으로 제어한다.
다수의 클러스터는 동일한 S3 버킷을 이용할 수 있고, 사용자는 이 S3 버킷을 같은 클러스트를
운영하는 동료에게 공유할 수 있다. 하지만 이 S3 버킷에 접근 가능한 사람은 사용자의
모든 클러스터에 관리자 접근이 가능하게 되니, 운영팀 이외로
공유되지 않도록 해야 한다.
다수의 클러스터는 동일한 S3 버킷을 이용할 수 있고, 사용자는 이 S3 버킷을 같은 클러스트를 운영하는 동료에게 공유할 수 있다. 하지만 이 S3 버킷에 접근 가능한 사람은 사용자의 모든 클러스터에 관리자 접근이 가능하게 되니, 운영팀 이외로 공유되지 않도록 해야 한다.
그래서 보통 한 운영팀 당 하나의 S3 버킷을 가지도록 하기도 한다.(그리고 종종 운영팀
이름은 위에서 언급한 hosted zone과 동일하게 짓기도 한다!)
그래서 보통 한 운영팀 당 하나의 S3 버킷을 가지도록 하기도 한다.(그리고 종종 운영팀 이름은 위에서 언급한 hosted zone과 동일하게 짓기도 한다!)
우리 예제에서는, `dev.example.com`를 hosted zone으로 했으니 `clusters.dev.example.com`를
S3 버킷 이름으로 정하자.
우리 예제에서는, `dev.example.com`를 hosted zone으로 했으니 `clusters.dev.example.com`를 S3 버킷 이름으로 정하자.
* `AWS_PROFILE`를 선언한다. (AWS CLI 동작을 위해 다른 profile을 선택해야 할 경우)
@@ -179,16 +155,12 @@ S3 버킷 이름으로 정하자.
* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다.
이 부분을 bash profile등에 넣어두는것을 권장한다.
### (4/5) 클러스터 설정 구성
클러스터 설정하려면, `kops create cluster` 를 실행한다:
`kops create cluster --zones=us-east-1c useast1.dev.example.com`
kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_
만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 `kops update cluster` 으로
구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다.
kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_ 만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 `kops update cluster` 으로 구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다.
더 자세한 내용을 알아보기 위한 커맨드가 출력된다.
@@ -197,10 +169,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의
* 인스턴스 그룹 수정: `kops edit ig --name=useast1.dev.example.com nodes`
* 마스터 인스턴스 그룹 수정: `kops edit ig --name=useast1.dev.example.com master-us-east-1c`
만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은
쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를
통해 만들어진다. 사용자는 여러개의 인스턴스 그룹을 관리할 수 있는데,
예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다.
만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은 쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를 통해 만들어진다. 사용자는 여러개의 인스턴스 그룹을 관리할 수 있는데, 예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다.
### (5/5) AWS에 클러스터 생성
@@ -210,30 +179,31 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의
`kops update cluster useast1.dev.example.com --yes`
실행은 수 초 만에 되지만, 실제로 클러스터가 준비되기 전까지 수 분이 걸릴 수 있다.
언제든 `kops update cluster`로 클러스터 설정을 변경할 수 있다. 사용자가
변경한 클러스터 설정을 그대로 반영해 줄 것이며, 필요다하면 AWS 나 쿠버네티스를 재설정 해 줄것이다.
언제든 `kops update cluster`로 클러스트 설정을 변경할 수 있다. 사용자가 변경한 클러스트 설정을 그대로 반영해 줄 것이며, 필요다하면 AWS 나 쿠버네티스를 재설정 해 줄것이다.
예를 들면, `kops edit ig nodes` 뒤에 `kops update cluster --yes`를 실행해 설정을 반영한다.
그리고 `kops rolling-update cluster`로 설정을 즉시 원복시킬 수 있다.
예를 들면, `kops edit ig nodes` 뒤에 `kops update cluster --yes`를 실행해 설정을 반영한다. 그리고 `kops rolling-update cluster`로 설정을 즉시 원복시킬 수 있다.
`--yes`를 명시하지 않으면 `kops update cluster` 커맨드 후 어떤 설정이 변경될지가 표시된다. 운영계 클러스터 관리할 때 사용하기 좋다!
`--yes`를 명시하지 않으면 `kops update cluster` 커맨드 후 어떤 설정이 변경될지가 표시된다.
운영계 클러스터 관리할 때 사용하기 좋다!
### 다른 애드온 탐험
[애드온 리스트](/docs/concepts/cluster-administration/addons/) 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 &amp; 제어 등을 포함한 다른 애드온을 확인해본다.
## 정리하기
* `kops delete cluster useast1.dev.example.com --yes` 로 클러스터를 삭제한다.
## Feedback
* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
{{% /capture %}}
{{% capture whatsnext %}}
* 쿠버네티스 [개념](/docs/concepts/) 과 [`kubectl`](/docs/user-guide/kubectl-overview/)에 대해 더 알아보기.
* 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 `kops` [고급 사용법](https://kops.sigs.k8s.io/)에 대해 더 자세히 알아본다.
* 슬랙(Slack)에서 `kops` 커뮤니티 토론을 할 수 있다: [커뮤니티 토론](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
* 문제를 해결하거나 이슈를 제기하여 `kops` 에 기여한다. [깃헙 이슈](https://github.com/kubernetes/kops/issues)
* `kops` [고급 사용법](https://github.com/kubernetes/kops) 알아보기.
* 튜토리얼, 모범사례, 고급 설정 옵션을 위해 `kops` [문서](https://github.com/kubernetes/kops) 부분 보기.
{{% /capture %}}
content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+21 -23
View File
@@ -1,4 +1,5 @@
---
reviewers:
title: 네트워크 폴리시로 실리움(Cilium) 사용하기
content_template: templates/task
weight: 20
@@ -7,7 +8,7 @@ weight: 20
{{% capture overview %}}
이 페이지는 어떻게 네트워크 폴리시(NetworkPolicy)로 실리움(Cilium)를 사용하는지 살펴본다.
실리움의 배경에 대해서는 [실리움 소개](https://docs.cilium.io/en/stable/intro)를 읽어보자.
실리움의 배경에 대해서는 [실리움 소개](https://cilium.readthedocs.io/en/stable/intro)를 읽어보자.
{{% /capture %}}
{{% capture prerequisites %}}
@@ -21,44 +22,35 @@ weight: 20
실리움에 쉽게 친숙해지기 위해
Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
[실리움 쿠버네티스 시작하기 안내](https://cilium.readthedocs.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고,
Minikube를 시작하려면 최소 버전으로 >= v0.33.1 이 필요하고,
다음의 실행 파라미터로 실행한다.
```shell
minikube version
```
```
minikube version: v1.3.1
minikube version: v0.33.1
```
```shell
minikube start --network-plugin=cni --memory=4096
```
BPF 파일시스템을 마운트한다
Minikube에서 실리움의 데몬셋 구성과 Minikube에 배포된 etcd 인스턴스로 접속하는데 필요한 구성 뿐만 아니라
RBAC 설정을 포함하는 필요한 구성을
이 간단한 ``올인원`` YAML 파일로 배포할 수 있다.
```shell
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
```
Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을
간단한 ``올인원`` YAML 파일로 배포할 수 있다.
```shell
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium-minikube.yaml
```
```
configmap/cilium-config created
serviceaccount/cilium created
serviceaccount/cilium-operator created
clusterrole.rbac.authorization.k8s.io/cilium created
clusterrole.rbac.authorization.k8s.io/cilium-operator created
daemonset.apps/cilium created
clusterrolebinding.rbac.authorization.k8s.io/cilium created
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
daemonset.apps/cilium create
deployment.apps/cilium-operator created
clusterrole.rbac.authorization.k8s.io/cilium created
serviceaccount/cilium created
```
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
@@ -68,7 +60,7 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예,
## 실리움을 실 서비스 용도로 배포하기
실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은
[실리움 쿠버네티스 설치 안내](https://docs.cilium.io/en/stable/kubernetes/intro/)를 살펴본다.
[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)를 살펴본다.
이 문서는 자세한 요구사항, 방법과
실제 데몬셋 예시를 포함한다.
@@ -92,8 +84,14 @@ cilium-6rxbd 1/1 Running 0 1m
...
```
`cilium` 파드는 클러스터 각 노드에서 실행되며, 리눅스 BPF를 사용해서
해당 노드의 파드에 대한 트래픽 네트워크 폴리시를 적용한다.
알고 있어야 할 두 가지 주요 구성요소는 다음과 같다.
- 먼저는 `cilium` 파드가 클러스터의 각 노드에서 운영되고,
노드의 파드로 보내고/받는 트래픽을 리눅스 BPF를 이용하여 네트워크 폴리시를 적용한다.
- 실 서비스에 배포하는 경우 실리움은 키-값 저장소(예, etcd)를 활용해야 한다.
[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)에서
키-값 저장소를 설치하는 방법과 실리움에서 이를 구성하는 필수 단계를
제공할 것이다.
{{% /capture %}}
content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
-10
View File
@@ -34,16 +34,6 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
이 API를 사용하려면 메트릭 서버를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다.
{{< /note >}}
## 리소스 사용량 측정
### CPU
CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.
### 메모리
메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다. 이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다. 그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다. 쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다. 호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
## 메트릭 서버
[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
+2 -2
View File
@@ -983,11 +983,11 @@ TODO(pwittrock): Why doesn't export remove the status field? Seems like it shou
```yaml
selector:
matchLabels:
controller-selector: "apps/v1/deployment/nginx"
controller-selector: "extensions/v1beta1/deployment/nginx"
template:
metadata:
labels:
controller-selector: "apps/v1/deployment/nginx"
controller-selector: "extensions/v1beta1/deployment/nginx"
```
{{% capture whatsnext %}}
content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
+2 -2
View File
@@ -135,11 +135,11 @@ kubectl create -f <url> --edit
```yaml
selector:
matchLabels:
controller-selector: "apps/v1/deployment/nginx"
controller-selector: "extensions/v1beta1/deployment/nginx"
template:
metadata:
labels:
controller-selector: "apps/v1/deployment/nginx"
controller-selector: "extensions/v1beta1/deployment/nginx"
```
{{% /capture %}}
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -74,7 +74,7 @@ deployment.apps/php-apache created
다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를
1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다.
(kubectl run으로 각 파드는 200 밀리코어까지 요청할 수 있고,
[kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)으로 각 파드는 200 밀리코어까지 요청할 수 있고,
따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다).
이에 대한 자세한 알고리즘은 [여기](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)를 참고하기 바란다.
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+23 -180
View File
@@ -41,28 +41,28 @@ Horizontal Pod Autoscaler는 컨트롤러
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
사용되는 비율을 생성한다.
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
사용되는 비율을 생성한다.
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보)
섹션을 참조하기 바란다.
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보)
섹션을 참조하기 바란다.
* 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을
제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
* 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
선택적으로 나눌 수 있다.
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
선택적으로 나눌 수 있다.
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
@@ -154,17 +154,10 @@ HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
큰 값이 선택된다. 이러한 메트릭 중 어떠한 것도 원하는
레플리카 수로 변환할 수 없는 경우(예 : 메트릭 API에서 메트릭을
가져오는 중 오류 발생) 스케일을 건너뛴다.
이는 하나 이상의 메트릭이
현재 값보다 높은 `desiredReplicas` 을 제공하는 경우
HPA가 여전히 확장할 수 있음을 의미한다.
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이
기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장
사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은
`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트
동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한
스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을
사용하여 설정할 수 있고, 기본 값은 5분이다.
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는
구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
영향을 완만하게 한다.
@@ -213,6 +206,9 @@ Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.
v1.6부터 클러스터 운영자는 `kube-controller-manager` 구성
요소의 플래그로 노출된 글로벌 HPA 설정을 조정하여 이 문제를 완화할 수 있다.
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
필요성을 제거하였다.
@@ -229,11 +225,6 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
있다.
{{< /note >}}
v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds`
를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다.
[구성가능한 스케일링
동작 지원](#구성가능한-스케일링-동작-지원)을 본다.
## 멀티 메트릭을 위한 지원
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
@@ -284,154 +275,6 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)과
[외부 메트릭스 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)을 참조한다.
## 구성가능한 스케일링 동작 지원
[v1.17](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
부터 `v2beta2` API는 HPA `behavior` 필드를 통해
스케일링 동작을 구성할 수 있다.
동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`
섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는
스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는
양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면
스케일링 중 레플리카 변경 속도를 제어할 수 있다.
### 스케일링 정책
스펙의 `behavior` 섹션에 하나 이상의 스케일링 폴리시를 지정할 수 있다.
폴리시가 여러 개 지정된 경우 가장 많은 양의 변경을
허용하는 정책이 기본적으로 선택된 폴리시이다. 다음 예시는 스케일 다운 중 이
동작을 보여준다.
```yaml
behavior:
scaleDown:
policies:
- type: Pods
value: 4
periodSeconds: 60
- type: Percent
value: 10
periodSeconds: 60
```
파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다.
예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는
경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때
다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의
각 루프에서 변경될 파드의 수는 현재 레플리카의 수에 따라 재계산된다. 레플리카의 수가 40
미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에
4개의 레플리카가 줄어든다.
`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
비활성화 된다.
### 안정화 윈도우
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다.
```yaml
scaleDown:
stabilizationWindowSeconds: 300
```
메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은
이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다.
위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다.
### 기본 동작
사용자 지정 스케일링을 사용하려면 일부 필드를 지정해야 한다. 사용자 정의해야
하는 값만 지정할 수 있다. 이러한 사용자 지정 값은 기본값과 병합된다. 기본값은 HPA
알고리즘의 기존 동작과 일치한다.
```yaml
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 100
periodSeconds: 15
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Percent
value: 100
periodSeconds: 15
- type: Pods
value: 4
periodSeconds: 15
selectPolicy: Max
```
안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된
경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재
실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링
대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다.
스케일링 업에는 안정화 윈도우가 없다. 메트릭이 대상을 스케일 업해야 한다고 표시된다면 대상이 즉시 스케일 업된다.
두 가지 폴리시가 있다. HPA가 정상 상태에 도달 할 때까지 15초 마다
4개의 파드 또는 현재 실행 중인 레플리카의 100% 가 추가된다.
### 예시: 다운스케일 안정화 윈도우 변경
사용자 지정 다운스케일 안정화 윈도우를 1분 동안 제공하기 위해
다음 동작이 HPA에 추가된다.
```yaml
behavior:
scaleDown:
stabilizationWindowSeconds: 60
```
### 예시: 스케일 다운 비율 제한
HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해
다음 동작이 HPA에 추가된다.
```yaml
behavior:
scaleDown:
policies:
- type: Percent
value: 10
periodSeconds: 60
```
마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
전략을 추가할 수 있다.
```yaml
behavior:
scaleDown:
policies:
- type: Percent
value: 10
periodSeconds: 60
- type: Pods
value: 5
periodSeconds: 60
selectPolicy: Max
```
### 예시: 스케일 다운 비활성화
`selectPolicy` 의 `Disabled` 값은 주어진 방향으로의 스케일링을 끈다.
따라서 다운 스케일링을 방지하기 위해 다음 폴리시가 사용된다.
```yaml
behavior:
scaleDown:
selectPolicy: Disabled
```
{{% /capture %}}
{{% capture whatsnext %}}
content/ko/docs/tutorials/hello-minikube.md
+10 -9
View File
@@ -169,7 +169,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
## 애드온 사용하기
Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 {{< glossary_tooltip text="애드온" term_id="addons" >}} 셋이 있다.
Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 애드온 셋이 있다.
1. 현재 지원하는 애드온 목록을 확인한다.
@@ -186,6 +186,7 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
efk: disabled
freshpod: disabled
gvisor: disabled
heapster: disabled
helm-tiller: disabled
ingress: disabled
ingress-dns: disabled
@@ -199,16 +200,16 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
storage-provisioner-gluster: disabled
```
2. 한 애드온을 활성화 한다. 예를 들어 `metrics-server`
2. 한 애드온을 활성화 한다. 예를 들어 `heapster`
```shell
minikube addons enable metrics-server
minikube addons enable heapster
```
다음과 유사하게 출력된다.
```
metrics-server was successfully enabled
heapster was successfully enabled
```
3. 방금 생성한 파드와 서비스를 확인한다.
@@ -223,7 +224,7 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
NAME READY STATUS RESTARTS AGE
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/heapster-9jttx 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
@@ -234,22 +235,22 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/heapster ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
```
4. `metrics-server` 비활성화
4. `heapster` 비활성화
```shell
minikube addons disable metrics-server
minikube addons disable heapster
```
다음과 유사하게 출력된다.
```
metrics-server was successfully disabled
heapster was successfully disabled
```
## 제거하기
content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+1 -1
View File
@@ -99,7 +99,7 @@ weight: 10
<div class="col-md-8">
<p>애플리케이션을 쿠버네티스에 배포한다는 것은, 마스터에 애플리케이션 컨테이너를 구동하라고 지시하는
것이다. 마스터는 컨테이너를 클러스터의 어느 노드에 구동시킬지를 스케줄한다. <b>노드는 마스터가
제공하는 <a href="/docs/concepts/overview/kubernetes-api/">쿠버네티스 API</a>를 통해서 마스터와 통신한다.</b> 최종 사용자도 쿠버네티스 API를 직접
제공하는 쿠버네티스 API를 통해서 마스터와 통신한다.</b> 최종 사용자도 쿠버네티스 API를 직접
사용해서 클러스터와 상호작용할 수 있다.</p>
<p>쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면
content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+1 -1
View File
@@ -35,7 +35,7 @@ weight: 10
<p>비록 각 파드들이 고유의 IP를 갖고 있기는 하지만, 그 IP들은 서비스의 도움없이 클러스터 외부로 노출되어질 수 없다. 서비스들은 여러분의 애플리케이션들에게 트래픽이 실릴 수 있도록 허용해준다. 서비스들은 ServiceSpec에서 <code>type</code>을 지정함으로써 다양한 방식들로 노출시킬 수 있다:</p>
<ul>
<li><i>ClusterIP</i> (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.</li>
<li><i>NodePort</i> - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다.</li>
<li><i>NodePort</i> - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. CluserIP의 상위 집합이다.</li>
<li><i>LoadBalancer</i> - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다. </li>
<li><i>ExternalName</i> - 이름으로 CNAME 레코드를 반환함으로써 임의의 이름(스펙에서 <code>externalName</code>으로 명시)을 이용하여 서비스를 노출시켜준다. 프록시는 사용되지 않는다. 이 방식은 <code>kube-dns</code> 버전 1.7 이상에서 지원 가능하다.</li>
</ul>
content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+7 -7
View File
@@ -113,13 +113,13 @@ EOF
3. 두 파일을 `kustomization.yaml`에 추가하자.
```shell
cat <<EOF >>./kustomization.yaml
resources:
- mysql-deployment.yaml
- wordpress-deployment.yaml
EOF
```
```shell
cat <<EOF >>./kustomization.yaml
resources:
- mysql-deployment.yaml
- wordpress-deployment.yaml
EOF
```
## 적용하고 확인하기
`kustomization.yaml`은 WordPress 사이트와 MySQL 데이터베이스를 배포하는 모든 리소스를 포함한다.
content/ko/examples/minikube/Dockerfile
+1 -1
View File
@@ -1,4 +1,4 @@
FROM node:6.14.2
EXPOSE 8080
COPY server.js .
CMD [ "node", "server.js" ]
CMD node server.js
content/ko/examples/pods/pod-nginx.yaml
-13
View File
@@ -1,13 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd
content/ko/examples/pods/pod-with-node-affinity.yaml
-26
View File
@@ -1,26 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0
content/ko/examples/pods/pod-with-pod-affinity.yaml
-29
View File
@@ -1,29 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: failure-domain.beta.kubernetes.io/zone
containers:
- name: with-pod-affinity
image: k8s.gcr.io/pause:2.0
content/ko/includes/task-tutorial-prereqs.md
+2 -4
View File
@@ -1,7 +1,5 @@
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 합니다.
만약, 아직 클러스터를 가지고 있지 않다면,
[Minikube](/docs/setup/learning-environment/minikube/)를 사용해서 만들거나,
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 합니다.
만약, 클러스터를 이미 가지고 있지 않다면, [Minikube](/docs/setup/minikube)를 사용해서 만들거나,
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있습니다:
* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
content/pl/docs/contribute/localization-pl.md
-55
View File
@@ -1,55 +0,0 @@
---
title: Tłumaczenie dokumentacji na język polski
content_template: templates/concept
card:
name: contribute
weight: 35
title: Tłumaczenie dokumentacji na język polski
---
{{% capture overview %}}
Na tej stronie znajdziesz wskazówki i wytyczne przydatne przy tłumaczeniu dokumentacji Kubernetesa na język polski.
Dokumentem nadrzędnym jest angielski [opis stylu dokumentacji](/docs/contribute/style/style-guide).
{{% /capture %}}
{{% capture body %}}
## Wskazówki ogólne
Staramy się, aby styl tłumaczenia był jak najbardziej naturalny. W przypadku dokumentacji technicznej może być to trudne zadanie,
szczególnie gdy chcemy utrzymać precyzję tłumaczenia.
Zależy nam na unikaniu sytuacji, kiedy tekst zaczyna sprawiać wrażenie przetłumaczonego maszynowo.
Pamiętajmy też, że oficjalna wykładnia zawsze znajduje się w tekście angielskim. Polskie tłumaczenie ma ułatwić pierwsze kroki osobom,
które zaczynają swoją przygodę z Kubernetesem.
## Wytyczne szczegółowe
### Odmiana terminu Kubernetes
Kubernetes jest nazwą własną, liczba pojedyncza, rodzaj męski. Odmieniamy: Kubernetesa, Kubernetesem itp.
W uzasadnionych przypadkach można stosować też "system Kubernetes".
### Odmiana terminów Pod, Deployment
Odmieniamy zgodnie z ogólnymi zasadami - poda, deploymentu itp.
### Ujednolicony słownik
W sieci dostępne są słowniki terminów informatycznych. Poniższa tabela zawiera słowa specyficzne dla Kubernetesa i inne często używane wyrażenia.
Termin angielski | Tłumaczenie
-----|-----
container | kontener
control plane | warstwa sterowania
Deployment | Deployment
horizontal scaling | skalowanie horyzontalne
Pod | Pod
rolling update | aktualizacje stopniowe
volume | volume (opcjonalnie: wolumin)
worker node | węzeł roboczy
{{% /capture %}}
content/ru/docs/contribute/participating.md
-208
View File
@@ -1,208 +0,0 @@
---
title: Участие в SIG Docs
content_template: templates/concept
card:
name: contribute
weight: 40
---
{{% capture overview %}}
SIG Docs — это одна из [специальных групп](https://github.com/kubernetes/community/blob/master/sig-list.md) в проекте Kubernetes, которая занимается написанием, обновлением и поддержкой документации Kubernetes в целом. Перейдите на страницу про [SIG Docs в GitHub-репозитории](https://github.com/kubernetes/community/tree/master/sig-docs), чтобы узнать подробную информацию об этой группе.
SIG Docs активно принимает правки и дополнения в документацию, так и отзывы от всех участников. Любой может открыть пулреквест (PR), либо сообщить про ошибки в тексте или просто прокомментировать выполняемые пулреквесты.
Вы также можете стать [членом](#члены), [рецензентом](#рецензенты) или [утверждающим](#утверждающие). Эти роли расширяют ваши возможности, но и предлагают выполнение определенных обязанностей по рассмотрению и принятию изменений. Изучите содержимого файла [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) в директории сообщества репозитория, чтобы узнать про членство в сообществе Kubernetes. В остальной части этой страницы кратко рассматривается функционирование ролей в группе SIG Docs, которая в совокупности отвечает за поддержание одного из самой публичной части Kubernetes — сайта и документации Kubernetes.
{{% /capture %}}
{{% capture body %}}
## Роли и обязанности
- **Любой** может поучаствовать в документацию Kubernetes. Для этого вам нужно только [подписать CLA](/docs/contribute/start#sign-the-cla) и иметь аккаунт на GitHub.
- **Члены** организации Kubernetes — участники, которые активно занимаются пректом Kubernetes, как правило, открывая пулреквесты с принятыми изменениями. Посмотрите файл [Членство в сообществе](https://github.com/kubernetes/community/blob/master/community-membership.md), чтобы узнать про необходимые условия для членства.
- **Рецензент** SIG Docs — член организации Kubernetes, который занимается проверкой пулреквестов и поэтому был добавлен в соответствующую группу на GitHub и в файлы `OWNERS` в GitHub-репозитории.
- **Утверждающий** SIG Docs — член организации с хорошей репутацией, который подтвердил неизменную приверженность проекту. Утверждающий может принимать пулреквесты и публиковаться от имени организации Kubernetes. Утверждающие также могут представлять группу SIG Docs в более крупном сообществе Kubernetes. Некоторые из задач утверждающего SIG Docs, например, координация новой версии, требуют значительных затрат по времени.
## Любой
Кто угодно может сделать следующее:
- Открыть ишью на GitHub в любую часть Kubernetes, включая документацию.
- Дать рекомендацию или предложить улучшение в пулреквесте.
- Предложить идею по улучшению в Slack](http://slack.k8s.io/) или в [список рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
- Использовать команду `/lgtm` (сокращение от "looks good to me") бота Prow, чтобы одобрить изменения в пулреквесте.
{{< note >}}
Если вы не входите в организацию Kubernetes, то команда `/lgtm` не проставил автоматически соответствующую метку.
{{< /note >}}
После [подписания CLA](/docs/contribute/start#sign-the-cla) каждый также может:
- Открыть пулреквест, чтобы улучшить существующий текст, либо что-то новое, или написать запись в блоге или описать пример использования.
## Члены
Члены — это участники проекта Kubernetes, которые удовлетворяют [критериям членства](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs ценит участие всех членов сообщества Kubernetes и часто просит дать обратную связь от членов других SIG-групп для соблюдения технической точности.
Любой член [организации Kubernetes](https://github.com/kubernetes) может сделать следующее:
- Всё то же самое, что и [любой другой участник](#любой)
- Использовать команду `/lgtm` в комментарии для автоматического добавления метки LGTM (looks good to me) для пулреквеста.
- Использовать команду `/hold` в комментарии для блокировки слияния пулреквеста, если он имеет метку LGTM и другие утверждающие метки.
- Использовать команду `/assign` в комментарии, чтобы назначить рецензента, который будет проверят пулреквест.
### Членство
После того, как вы успешно отправили не менее 5 содержательных пулреквестов, вы можете стать [членом](https://github.com/kubernetes/community/blob/master/community-membership.md#member) организации Kubernetes. Следуйте нижеперечисленным шагам:
1. Найдите двух рецензентов или утверждающих, которые [поддержат](/docs/contribute/advanced#sponsor-a-new-contributor) ваше членство.
Запросите спонсорство в канале [#sig-docs Kubernetes Slack](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
{{< note >}}
Не отправляйте электронное письмо и не пишите личное сообщение в Slack кому-либо из участников SIG Docs.
{{< /note >}}
2. Создайте ишью в репозитории `kubernetes/org`, чтобы запросить членство.
Заполните шаблон, предварительно изучив правила [членства в сообществе](https://github.com/kubernetes/community/blob/master/community-membership.md).
3. Сообщите вашим спонсорам про вашу заявку на GitHub, упомянув их в ней на GitHub (добавив комментарий в форме `@<GitHub-username>`), либо отправив им ссылку напрямую, чтобы они могли добавить проголосовать ( `+1`).
4. Когда ваше членство будет одобрено, член административной команды на GitHub, назначенный для обработки вашего пулреквеста, обновит ишью на GitHub, чтобы показать одобрение, а затем закроет проблему GitHub.
Поздравляем, теперь вы член организации!
Если ваша заявка на членство не была одобрена, членский комитет даст уточнения или перечислит шаги, которые необходимо выполнить, прежде чем снова подать заявку.
## Рецензенты
Рецензенты — это члены GitHub-группы [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews). Рецензенты проверяют пулреквесты документации и оставлять обратную связь по предлагаемым изменениях. Рецензенты могут:
- Делать всё то, что и [любой участник](#любой) и [члены](#члены)
- Писать документацию для новой функциональности
- Назначать метки и классифицировать ишью
- Проверять пулреквесты и оставлять обязательные для выполнения рекомендации
- Создавайте диаграммы, графику и встраиваемые скринкасты и видеоролики
- Заниматься локализацией
- Редактировать строки в коде, относящиеся к интерфейсу пользователя
- Улучшать комментарии к коду
### Выбор рецензентов для проверки пулреквестов
Процесс выбора рецензентов для проверки пулреквестов автоматизирован. Вы можете попросить проверку у определенного рецензента, написав комментарий в пулреквесте: `/assign [@_github_handle]`. Чтобы показать, что пулреквест является правильным с технической точки зрения и не требует дополнительных изменений, рецензент добавляет комментарий с командой `/lgtm`.
Если назначенный рецензент еще не просмотрел содержимое пулреквеста, может присоединиться другой проверяющий. Кроме того, вы можете назначить технических рецензентов и подождать их одобрение через комментарий с `/lgtm`.
Также для совсем небольшого изменения, или такого, которое не требует технического рассмотрения, [утверждающие](#утверждающие) SIG Docs одобрить его через комментарий с `/lgtm`.
Комментарий с `/approve` от рецензента игнорируется ботом и поэтому соответствующая метка не добавится к пулреквесту.
### Как стать рецензентом
Если вы соответствуете [требованием](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), то можете стать рецензентом SIG Docs. Рецензенты в других SIG-группах должны подать новую заявку для получения статуса рецензента в SIG Docs.
Для отправки заявки откройте пулреквест с добавлением самого себя в секцию `reviewers` [корневого файла OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) в репозитории `kubernetes/website`. Запросите проверку вашего пулреквеста одному или нескольким текущим утверждающим в группе SIG Docs.
Если ваш пулреквест одобрен, вы становитесь рецензентом SIG Docs. Теперь бот [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) будет назначать и предлагать вас в качестве рецензента для проверки новых пулреквестов.
После того, как ваша кандидатура будет одобрена, попросите текущего утверждающего SIG Docs добавить вас в GitHub-группу [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews). Только члены GitHub-группы `kubernetes-website-admins` могут добавлять новых членов в какую-либо другую группу.
## Утверждающие
Утверждающие — члены GitHub-группы [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers). Перейдите в раздел [Команды и группы в SIG Docs](#teams-and-groups-within-sig-docs) для получения дополнительной информации.
Утверждающие могут делать следующее:
- Все то же, что и [обычные участники](#любой), [члены](#члены) и [рецензенты](#рецензенты)
- Публиковать изменения от других участников путём одобрения и слияния пулреквестов с помощью комментария с командой `/approve`.
Если кто-то оставляет комментарий, не являясь при этом официальным рецензентом, бот проигнорирует такой одобряющий комментарий.
- Примите участие в работе команды выпуска новых версий Kubernetes как представитель документации
- Предлагать улучшения в руководстве по оформлению
- Предлагать улучшения для тестов документации
- Предлагать улучшения для сайта Kubernetes или других инструментов
Если у PR есть метка `/lgtm`, или если утверждающий оставляет комментарий с командной с `/lgtm`, PR автоматически сливается. Утверждающий SIG Docs должен оставлять комментарий с `/lgtm` только для тех изменений, которые не нуждаются в дополнительном техническом обзоре.
### Как стать утверждающим
Если вы соответствуете [требованием](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), вы можете стать утверждающим SIG Docs. Утверждающие в других SIG-группах должны подать новую заявку для получения статуса утверждающего в SIG Docs.
Для отправки заявки откройте пулреквест с добавлением самого себя в секцию `approvers` [корневого файла OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) в репозитории `kubernetes/website`. Запросите проверку вашего пулреквеста одному или нескольким текущим утверждающим в группе SIG Docs.
Если ваш пулреквест одобрен, вы становитесь утверждающим SIG Docs. Теперь бот [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) будет назначать и предлагать вас в качестве рецензента для проверки новых пулреквестов.
После того, как ваша кандидатура будет одобрена, попросите текущего утверждающего SIG Docs добавить вас в GitHub-группу[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers). Только члены GitHub-группы `kubernetes-website-admins` могут добавлять новых членов в какую-либо другую группу.
### Обязанности утверждающего
Утверждающие улучшают документацию, проверяя и сливая пулреквесты в репозитории сайта. Из-за того, эта роль предусматривает дополнительные привилегии, на утверждающих возлагаются дополнительные обязанности:
- Утверждающие могут использовать команду `/approve`, которая сливает PR в репозиторий.
Невнимательное слияние может нарушить работу сайта, поэтому имейте это в виду, когда объединяете какой-либо пулреквест.
- Убедитесь, что предлагаемые изменения соответствуют [правилам по содержанию](/docs/contribute/style/content-guide/#contributing-content).
Если вы сомневаетесь или вы не уверены в чем-либо, не стесняйтесь обращаться для дополнительной проверки.
- Проверьте, что тесты на Netlify пройдены успешно, перед тем как написать комментарий с `/approve` в PR.
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" />
- Перед одобрением пулреквеста перейдите на предварительный просмотр сайта на Netlify для сделанных изменений в PR, и убедитесь, что всё содержимое выглядит хорошо.
- Участвуйте в [графике дежурства смотрителя PR](https://github.com/kubernetes/website/wiki/PR-Wranglers), чтобы вас назначили дежурным проверяющим на неделю. SIG Docs ожидает, что все утверждающие примут участие в этом графике. За подробностям обратитесь к странице [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week).
## Председатель SIG Docs
Каждая SIG-группа, включая SIG Docs, выбирает одного или нескольких членов из своей SIG-группы в качестве председателей. Это координаторы между SIG Docs и другими подразделениями в организации Kubernetes. От таких людей требуются обширные знания о структуре проекта Kubernetes в целом и как функционирует группа SIG Docs внутри неё. Смотрите раздел [Руководство](https://github.com/kubernetes/community/tree/master/sig-docs#leadership), чтобы узнать текущий список председателей.
## Команды SIG Docs и автоматизация
Автоматизация в SIG Docs основывается на двух разных механизмах:
группы GitHub и файлы OWNERS.
### GitHub-группы
Группа SIG Docs представлена двумя командами на GitHub:
- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
На каждую из них можно сослаться по имени (`@name`) в комментариях на GitHub, чтобы общаться со всеми участниками в этой группе.
Эти команды пересекаются, но назначение у них разное. Для назначения людей на ишью, пулреквестов и поддержки одобрений в PR бот использует информацию из файлов OWNERS.
### Файлы OWNERS и вступительная часть
Проект Kubernetes использует инструмент автоматизации под названием prow, чтобы автоматизировать процесс, связанный с ишью и пулреквестами на GitHub. [Репозиторий сайта Kubernetes](https://github.com/kubernetes/website) использует два [плагина prow](https://github.com/kubernetes/test-infra/tree/master/prow/plugins):
- blunderbuss
- approve
Все эти плагины используют файлы [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) и [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) в корневой директории GitHub-репозитория `kubernetes/website`, чтобы контролировать работу prow по всему репозиторию.
Файл OWNERS содержит список людей, которые являются рецензентами и утверждающими в SIG Docs. Файлы OWNERS также может быть в поддиректориях и могут переопределять тех, кто может выступать в качестве рецензента или утверждающего в изменениях файлов этой директории и её поддиректорий. Для получения дополнительной информации о файлах OWNERS в целом, перейдите в [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
Кроме того, в каждом Markdown-файле могут быть указаны рецензенты и утверждающие в так называемой вступительной части (front-matter) в виде логинов участников или имён групп на GitHub.
Таким образом файлы OWNERS и вступительная часть в Markdown-файлах определяет своего рода рекомендацию для бота, чтобы он знал, к кому обращаться за технической и редакционной проверкой каждого PR.
## Как происходит слияние
Когда пулреквест сливается в действующую ветку сайта (в данный момент это `master`), содержимое публикуется и становится общедоступным. Для обеспечения высокого качества публикуемого нами контента, мы доверяем слияние пулреквестов утверждающим SIG Docs. Ниже описан этот процесс.
- Когда пулреквест имеет метки `lgtm` и `approve`, при этом у него нет метки `hold`, и то же время все тесты успешно проходят, то пулреквест автоматически сливается.
- Члены организации Kubernetes и утверждающие SIG Docs могут оставлять комментарии со специальными командами, которые блокирует автоматическое объединение пулреквеста (добавление комментарий с текстом `/hold` или удаление ранее установленной метки `/lgtm`).
- Любой участник Kubernetes может добавить метку `lgtm`, добавив комментарий, включающий в себя `/lgtm`.
- Только утверждающие SIG Docs могут слить пулреквест путём добавления комментария с `/approve`. Некоторые утверждающие также играют дополнительные роли, например, [смотрителя PR](#pr-wrangler) или [председателя SIG Docs](#председатель-sig-docs).
{{% /capture %}}
{{% capture whatsnext %}}
Для получения дополнительной информации про участие в документации Kubernetes, посмотрите следующие страницы:
- [Начало участия](/ru/docs/contribute/start/)
- [Правила оформления документации](/ru/docs/contribute/style/)
{{% /capture %}}
content/ru/docs/contribute/start.md
-233
View File
@@ -1,233 +0,0 @@
---
title: Start contributing
slug: start
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 10
---
{{% capture overview %}}
Если вы хотите поучаствовать в работе над документацией Kubernetes, эта страница и связанные с ней темы могут помочь вам начать работу. Вам не нужно быть разработчиком или техническим писателем, чтобы внести вклад в документацию или улучшить сайт Kubernetes! Все, что вам нужно для тем на этой странице, это учетная запись на GitHub и браузер.
Если вы ищете информацию про участие в репозиториях, связанным с кодом Kubernetes, обратитесь к [руководству сообщества Kubernetes](https://github.com/kubernetes/community/blob/master/governance.md).
{{% /capture %}}
{{% capture body %}}
## Основные сведения про документацию
Документация Kubernetes написана на Markdown, обработана и развернута при помощи Hugo. Исходные файлы находятся на GitHub по адресу https://github.com/kubernetes/website. Основная часть документации хранится в директории `/content/en/docs/`. Часть справочной документации автоматически генерируется из скриптов в директории `update-imported-docs/`.
Вы можете создавать новые задачи, редактировать содержимое и проверять изменения от других участников, — всё это доступно с сайта GitHub. Вы также можете использовать встроенный в GitHub поиск и историю коммитов.
Не все задачи могут быть выполнены на GitHub, поэтому они обсуждаются в [intermediate](/docs/contribute/intermediate/) and
[advanced](/docs/contribute/advanced/) docs contribution guides.
### Участие в документации SIG
Документация Kubernetes поддерживается {{< glossary_tooltip text="специальной группой" term_id="sig" >}} (Special Interest Group, SIG) под названием SIG Docs. Мы [общаемся](#participate-in-sig-docs-discussions) с помощью канала Slack, списка рассылки и еженедельных видеозвонков. Будем рады новым участникам. Для получения дополнительной информации обратитесь к странице [Participating in SIG Docs](/docs/contribute/participating/).
### Руководящие принципы по содержанию
Сообщество SIG Docs разработало правила, которые касаются разрешенных видов контента в документации Kubernetes. Посмотрите [руководство по содержанию документации](/docs/contribute/style/content-guide/) для определения того, допустим ли контент, который вы хотите добавить. Задать вопросы про допустимый контент можно в Slack-канале [#sig-docs](#participate-in-sig-docs-discussions).
### Правила оформления
Мы поддерживаем [руководство по оформлению](/docs/contribute/style/style-guide/) с информацией о выборе, сделанном сообществом SIG Docs в отношении грамматики, синтаксиса, исходного форматирования и типографских соглашений. Прежде чем сделать свой первый вклад, просмотрите руководство по стилю и используйте его, когда у вас есть вопросы.
SIG Docs совместными усилиями вносит изменения в руководство по оформлению. Чтобы предложить изменение или дополнение, добавьте его в повестку дня предстоящей встречи SIG Docs и посетите её, чтобы принять участие в обсуждении. Смотрите страницу с [продвинутым руководством](/docs/contribute/advanced/) для получения дополнительной информации.
### Шаблоны страниц
Мы используем шаблоны страниц, чтобы управлять представление наших страниц документации. Разберитесь как работают эти шаблоны, ознакомившись с разделом [Использование шаблонов страниц](/docs/contribute/style/page-templates/).
### Макрокоды Hugo
Документация Kubernetes с помощью Hugo конвертируется из формата разметки Markdown в HTML. Мы используем встроенные макрокоды Hugo, а также некоторые из своих собственных, созданных специально для документации Kubernetes. Посетите страницу [Нестандартные макрокоды Hugo](/docs/contribute/style/hugo-shortcodes/), чтобы узнать, как их использовать.
### Мультиязычность
Исходные файлы документации доступны на нескольких языках в директории `/content/`. Каждый язык имеет свою собственную директорию с двухбуквенным кодом, определенным стандартом[ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). Например, исходники документации для английского языка хранится в директории `/content/en/docs/`.
Более подробную информацию про участие в работе над документацией на нескольких языках ["Localize content"](/docs/contribute/intermediate#localize-content) в промежуточном руководстве по добавлению.
Если вы заинтересованы в переводе документации на новый язык, посмотрите раздел ["Локализация"](/docs/contribute/localization/).
## Создание хороших заявок
Любой, у кого есть аккаунт на GitHub, может создать заявку (issue, или отчет об ошибке) в документации Kubernetes. Если вы заметили какую-либо какую-либо ошибку, даже если вы не знаете, как её исправить, [откройте ишью](#how-to-file-an-issue). Но не делайте этого, если нашли небольшую ошибку, например, опечатку, которую вы при желании можете исправить самостоятельно. В этом случае можете [исправить ее](#improve-existing-content) вместо того, чтобы писать об этом.
### Как создать заявку
- **Для существующей страницы**
Если заметили проблему на существующей странице в [документации Kubernetes](/docs/), перейдите в конец страницы и нажмите кнопку **Create an Issue**. Если вы ещё не авторизованы в GitHub, сделайте это. После этого откроется страница с форма для создания нового запроса в GitHub с уже предварительно заполненным полями.
При помощи разметки Markdown опишите как можно подробнее, что хотите. Там, где вы видите пустые квадратные скобки (`[ ]`), проставьте `x` между скобками. Если у вас есть предлагаемое решение проблемы, напишите его.
- **Запросить новую страницу**
Если вы хотите добавить что-то новое, но вы не уверены, на какую страницу документации это сделать или считаете, что новая информация не вписывается в существующие страницы, всё равно создайте ишью. Вы можете либо перейти на страницу документации, куда, по вашему мнению, нужно добавить новую информацию и создать заявку прямо с этой страницы, либо перейти по адресу [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) и написать что вы хотите там.
### Как заполнить хорошую заявку
Чтобы нам самим убедиться, что понимаем вас правильно, помните следующее:
- Используйте шаблон ишью и заполните его как можно подробнее.
- Четко изложите суть вашего проблемы, как она сказывается на пользователях.
- Как можно меньше ограничьте охват изменений в вашей заявке. Задачи с большим объемом работы разбейте на более мелкие.
Например, "Fix the security docs" не является проблемой, требующей немедленного решения, зато заявка с заголовком "Add details to the 'Restricting network access' topic", вероятно, такой является.
- Если проблема связана с другой заявкой или пулреквестом, вы можете указать сослаться на них, либо по его полному URL-адресу, либо по их номеру с `#`. Например, `Introduced by #987654`.
- Будьте уважительны и избегайте жалоб. Например, заголовок ишью "The docs about X suck" явно не несёт ничего полезного или чтобы на него реагировали.
[Нормы поведения](/community/code-of-conduct/) также применяется к общению в GitHub-репозиториях Kubernetes.
## Участие в дискуссиях SIG Docs
Команда SIG Docs общается следующими способами:
- [Зарегистрируйтесь в Slack-канале Kubernetes](http://slack.k8s.io/), а затем присоединитесь к каналу `#sig-docs`, где мы в режиме реального времени обсуждаем всё, что связано с документацией. И не забудьте представиться!
- [Подпишитесь на список рассылки `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), где проходят более общие дискуссии и принимаются официальные решения.
- Участвуйте в [еженедельной видеовстрече IG Docs](https://github.com/kubernetes/community/tree/master/sig-docs), которая анонсируется в Slack-канале и списке рассылки. В данный момент эти встречи проводятся в Zoom, поэтому вам необходимо загрузить клиент Zoom или позвонить по телефону.
{{< note >}}
Вы всегда можете узнать когда будет очередное еженедельное собрание SIG Docs в [календаре собраний сообщества Kubernetes](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles).
{{< /note >}}
## Улучшение существующего текста
Чтобы улучшить текущее содержимое документации, вам нужно открыть _пулреквест (pull request, PR)_ после того, как вы сделаете _копию (fork)_ оригинального репозитория. Эти два термина [относятся к GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
Для начала работы, которая показана в этом разделе, вам не нужно знать всё про эти понятия, так как вы всё можете делать в своём браузере. Когда вы перейдете к продвинутому руководству участника документации, тогда вам понадобиться пополнить свои знания Git.
Примечание. Разработчики кода Kubernetes. Если вы документируете новую функцию для предстоящего выпуска Kubernetes, ваш процесс будет немного другим. См. Документирование функции для руководства по процессу и информации о сроках.
{{< note >}}
**Для разработчиков кода Kubernetes**: если вы документируете новую функциональность для новой версии Kubernetes, то процесс рассмотрения будет немного другим. Посетите страницу [Документирование функциональности](/docs/contribute/intermediate/#sig-members-documenting-new-features), чтобы узнать про процесс и информацию о крайних сроках.
{{< /note >}}
### Подписание CLA-соглашения CNCF {#sign-the-cla}
Прежде чем внести вклад в код или документацию Kubernetes, вам **обязательно** следует прочитать [руководство для участников](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) и [подписать лицензионное соглашение участника (Contributor License Agreement, CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
Не переживайте — подписание не займет много времени!
### Поиск задач для работы
Если вы уже нашли что исправить, просто следуйте инструкциям ниже. Для этого вам не обязательно [создавать ишью](#file-actionable-issues) (хотя вы, безусловно, пойти этим путём).
Если вы хотите ещё не определились с тем, над чем хотите поработать, перейдите по адресу [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) и найдите ишью с меткой `good first issue` (вы можете использовать [эту](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) ссылку для быстрого поиска). Прочитайте комментарии, чтобы убедиться что нет открытого пулреквеста для решения текущей ишью, а также, что никто другой не оставил комментарий, что он работает над этой задачей в последнее время (как правило, 3 дня). Добавьте комментарий, что вы хотели бы заняться решением этой задачи.
### Выбор правильной ветки в Git
Самым важный момент в создании пулреквестов — это выбор нужной ветки для вашей работы. Используйте эти рекомендации, чтобы принять верное решение:
- Используйте ветку `master` для исправления ошибок в текущей документации, либо чтобы улучшить существующий текст.
- Используйте ветку `master` для документирования функциональности в текущей версии Kubernetes, для которой отсутствовала документация. Прежде всего вам нужно написать документацию на английском языке, а затем команды по переводам подхватят это изменение, чтобы актуализировать перевод.
- Если вы работаете над переводом, вам нужно следовать соглашению в этой конкретной локализации. Чтобы понять это, вы можете другие пулреквесты (подсказка: `is:pr is:merged label:language/xx`)
{{< comment >}}Localization note: when localizing that tip, replace `xx`
with the actual ISO3166 two-letter code for your target locale.{{< /comment >}}
- Некоторые команды локализации работают с пулреквестами, которые ориентированы на ветку `master`
- Другие команды локализации работают с рядом долговечных веток, периодически сливая их в ветку `master`. Такая ветка именуется как dev-\<version>-\<language code>.\<team milestone>, например, `dev-{{< release-branch >}}-ja.1`.
- Если вы пишете или обновляете документацию к выпуску грядущего изменения, то вам необходимо знать мажорную и минорную версию Kubernetes, в которой это изменение впервые появится.
- Например, если переключатель возможностей (feature gates) JustAnExample должен измениться с альфа-версии на бета-версию в следующей минорной версии, вам необходимо знать номер этой версии.
- Найдите ветку выпуска, названную для этой версии. Например, функциональность, которая изменились в выпуске v{{< release-branch >}}, будет документирована в ветке `dev-{{< release-branch >}}`.
Если вы все еще не уверены, какую ветку выбрать, спросите в Slack-канале `#sig-docs` или посетите еженедельную встречу SIG Docs, чтобы внести ясность.
### Отправка пулреквеста
Следуйте описанным ниже шагам, чтобы создать пулреквест для улучшения документации Kubernetes.
1. На странице, которую вы хотите отредактировать, щелкните на иконку карандаша в правом верхнем углу. Откроется новая страница на GitHub с небольшой подсказкой.
2. Если вы ранее не делали копию репозитория документации Kubernetes, вам будет предложено это сделать. Создайте копию репозитория под своим логином GitHub, а не в организации, в которой вы состоите. URL-адрес копии репозитория будет выглядит как `https://github.com/<username>/website`, в случае у вас нет репозитория с таким же названием.
Поскольку у вас нет доступа к оригинальному репозиторию и соответственно вы не можете отправлять напрямую изменения в основную ветку, вам нужно сделать копию репозитория Kubernetes.
3. Откроется редактор GitHub для редактирования исходного файла в формате Markdown. Внесите свои изменения. Под редактором заполните форму **Propose file change**. Первое поле — краткое содержание вашего сообщения коммита, оно должно содержать не более 50 символов. Второе поле является необязательным, в нём вы можете подробно расписать суть ваших изменений.
{{< note >}}
Не ссылайте на другие ишью или пулреквесты на GitHub в сообщении коммита. Вы можете сослаться на них в тексте пулреквеста.
{{< /note >}}
Нажмите на кнопку **Propose file change**. Изменения в файле записываются в виде коммита в новой ветке вашей копии репозитория, которая автоматически будет иметь имя что-то вроде `patch-1`.
4. На следующей странице вам будут показаны различия в вашей ветке (поля выбора **head fork** и **compare**) с текущим состоянием **оригинального репозитория (base fork)** в **основной ветке (base)** (по умолчанию ветка `master` в репозитории `kubernetes/website`). Вы можете выбрать другое значение в полях выбора, но не делайте этого сейчас. Сравните различия и если всё верно, нажмите кнопку **Create pull request**.
{{< note >}}
Если вы не хотите создавать пулреквест в данный момент, это можно сделать позже, если перейти на страницу репозитория сайта Kubernetes или вашей копии репозитория. На сайте GitHub вам предложит открыть пулреквест, если он обнаружит новую ветку в вашей копии репозитория.
{{< /note >}}
5. Отобразится форма с заголовком **Open a pull request**. Название пулреквеста будет содержать краткое описание из сообщения коммита, хотя вы можете изменить его при необходимости. В описании пулреквеста будет остальная информация из сообщения коммита (если оно есть) и небольшой шаблон с текстом. Прочитайте текст шаблона и сделайте то, что там описано, а затем удалите этот шаблонный текст. Если вы добавите в описание пулреквест `fixes #<000000>` или `closes #<000000>`, где `#<000000>` - номер связанной заявки, то GitHub автоматически закроет указанную заявку при слиянии пулреквеста. Оставьте флажок **Allow edits from maintainers** отмеченным. Нажмите на кнопку **Create pull request**.
Поздравляем! Ваш пулреквест добавлен в список [пулреквестов](https://github.com/kubernetes/website/pulls).
Через несколько минут вы сможете просмотреть версию сайта с изменениями в вашем пулреквесте. Перейдите в низ страницы пулреквеста на вкладке **Conversation** и там нажмите на ссылку **Details** рядом с проверкой `deploy/netlify`. По умолчанию она откроется в текущей вкладке.
{{< note >}}
Пожалуйста, открывайте пулреквест, изменения которого затрагивают только один язык. Например, если вам нужно одинаково изменить один и тот же пример кода в нескольких языках, откройте по отдельному пулреквесту для каждого языка.
{{< /note >}}
6. Ожидайте, когда проверят ваш пулреквест. Как правило, рецензенты выбираются авматоматически ботом `k8s-ci-robot`. Если рецензент попросил изменить пулреквест, вы можете сделать это, если перейдёте на вкладку **Files changed** и щёлкните на иконку с карандашом на любом изменённом файле в вашем пулреквесте. Сохранение измененного файла оформляется в виде нового коммита в ветке, указанной в пулреквесте. Если вы ожидаете новую проверку изменений от рецензента, заранее попросите его об этом не более одного раза в 7 дней. Вы также можете зайти в Slack-канал #sig-docs — это хорошее место, где можно попросить проверку пулреквеста.
7. Если ваши изменения одобрены, то рецензент объединяет соответствующий пулреквест. Через несколько минут вы сможете сможете увидеть его в действии на сайте Kubernetes.
Это только один из способов отправить пулреквест. Если вы уже опытный пользователь Git и GitHub, вы можете вносить изменения, используя локальный GUI-клиент или Git из терминала вместо того, чтобы использовать интерфейс GitHub для этого. Некоторые основы использования Git-клиента из командной строки обсуждаются в [продвинутом](/docs/contribute/intermediate/) руководстве участника.
## Просмотр пулреквестов в документацию
Новички документации могут обозревать пулреквесты. Вы можете изучить кодовую базу и завоевать доверие к себе со стороны коллег-участников. Документация на английском — это первоисточник содержимого. Мы общаемся на английском языке во время еженедельных встреч и в объявлениях сообщества. Владение английским языком может быть разным, поэтому используйте простой и прямой язык в своих обзорах пулреквестов. Полезные обзоры фокусируются как на мелких деталях, так и на потенциальном влиянии изменений.
Обзоры не носят «обязательный характер», это означает, что только ваша проверка не приведет к слиянию пулреквеста. Тем не менее, это не делает ваши обзоры бесполезными. Даже только просмотр изменений в пулреквеста поможет вам понять как происходит рабочий процесс, какие могут быть трудности и проблемы. Перед проверкой пулреквестов ознакомьтесь с [руководством по содержанию](/docs/contribute/style/content-guide/) и [руководством по оформлению](/docs/contribute/style/style-guide/), чтобы узнать, каким должен быть содержимое и как оно должно быть оформлено..
### Рекомендации
- Будьте вежливы, внимательны и помогайте другим
- Не забывайте отмечать также положительные стороны пулреквеста
- Будьте чутким и думайте, как ваши комментарии могут быть восприняты
- Проявите добрые намерения и задавайте уточняющие вопросы
- Опытным участникам: помогайте новым участникам, их работа требует глаз да глаз
### Поиск и проверка пулреквеста
1. Перейдите по URL-адресу [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). Вы увидите список всех пулреквестов в репозиторий сайта Kubernetes и его документации.
2. По умолчанию открываются открытые пулреквесты (статус `open`), поэтому вы не увидите закрытых или принятых пулреквестов. Рекомендуется добавить дополнительный фильтр `cncf-cla: yes`, а также для вашей первой проверки пулреквеста неплохо применить ещё и `size/S` и `size/XS`. Метка с размером назначается автоматически в зависимости от количества изменённых строк кода в пулреквесте. Вы можете применить фильтры, используя поля выбора в верхней части страницы, либо воспользоваться [этой ссылкой](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) для просмотра небольших пулреквестов. Все фильтры объединены в логическое `AND`, поэтому у вас не получиться искать по меткам `size/XS` и `size/S` одновременно.
3. Перейдите на вкладку **Files changed**. Посмотрите изменения, внесенные в PR, а также изучите любые связанные задачи (если есть). Если вы видите ошибку, неточность или хотите внести улучшение, то наведите курсор на строку и щелкните на появившийся символ `+`.
Вы можете написать комментарий, после чего нажать на кнопку **Add single comment** или **Start a review**. Как правило, лучше начать проверку (review), поскольку тогда вы сможете оставить несколько комментариев и уведомить автора PR только после завершения рецензирования, вместо того, чтобы упоминать его в каждом комментарии.
4. После окончания разбора пулреквеста, нажмите на кнопку **Review changes** вверху страницы. Вы можете подвести краткий итог своей проверки и выполнить одно из действий: просто прокомментировать, одобрить или запросить изменения. Новым участникам нужно всегда только комментировать (кнопка **Comment**) пулреквесты.
Спасибо за обзор пулреквеста! Если вы новенький в проекте, рекомендуется попросить кого-нибудь оценить ваш обзор пулреквеста. Slack-канал `#sig-docs` — отличное место для этого.
## Написание постов в блоге
Любой может написать пост в блоге и отправить его на рассмотрение. Посты блога не должны носит коммерческий характер и должны отражать опыт, который может широко применён в сообществе Kubernetes.
Чтобы заявить о посте вы можете отправить его, используя [форму блога Kubernetes](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform), либо же выполнить следующие действия.
1. [Подпишите CLA](#sign-the-cla), если вы еще этого не сделали.
2. Изучите разметку Markdown у текущих постов блога в репозитории сайта.
3. Напишите свою статью в вашем любимом текстовом редакторе.
4. По ссылке из второго шага нажмите на кнопку **Create new file**. Скопируйте из своего редактора текст и вставьте в многострочное поле. Назовите файл так, чтобы он соответствовал предлагаемому заголовку статьи в блоге, но не указывайте дату в имени файла. Рецензенты блога будут работать с вами над окончательным именем файла и датой публикации записи.
5. Когда вы сохраните файл, начнётся описанный выше процесс принятия пулреквеста в GitHub.
6. Рецензент блога рассмотрит вашу статью и вместе с вами будет работать над ее улучшением. Когда запись в блоге будет одобрена, будет известна дата публикации вашей статьи.
## Отправка примеров использования
В примерах использования показывается, как организации используют Kubernetes для решения собственных реальных проблем. Они написаны в сотрудничестве с маркетинговой командой Kubernetes, которой занимается {{< glossary_tooltip text="CNCF" term_id="cncf" >}}.
Ознакомьтесь с [существующими примерами использования](https://github.com/kubernetes/website/tree/master/content/en/case-studies). Воспользуйтесь [формой добавления нового примера использования Kubernetes](https://www.cncf.io/people/end-user-community/), чтобы поделиться своим опытом.
{{% /capture %}}
{{% capture whatsnext %}}
Если вы хорошо поняли темы, затронутые в этом разделе, но хотите глубже взаимодействовать с командой документации Kubernetes, прочитайте [расширенное руководство по участию в документации](/docs/contribute/intermediate/).
{{% /capture %}}

Some files were not shown because too many files have changed in this diff Show More