Merge remote-tracking branch 'upstream/master' into dev-1.20
This commit is contained in:
Anna Jung (VMware)
commit
7f43aceddb
|
|
@ -69,7 +69,7 @@ sudo mv minikube /usr/local/bin
|
|||
### Linux
|
||||
|
||||
{{< note >}}
|
||||
Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://github.com/kubernetes/minikube#other-ways-to-install) im offiziellen Minikube-GitHub-Repository.
|
||||
Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://minikube.sigs.k8s.io/docs/start/) im offiziellen Minikube-GitHub-Repository.
|
||||
{{< /note >}}
|
||||
|
||||
Sie können Minikube unter Linux installieren, indem Sie eine statische Binärdatei herunterladen:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ aliases: [ '/dockershim' ]
|
|||
---
|
||||
|
||||
This document goes over some frequently asked questions regarding the Dockershim
|
||||
depreaction announced as a part of the Kubernetes v1.20 release. For more detail
|
||||
deprecation announced as a part of the Kubernetes v1.20 release. For more detail
|
||||
on the deprecation of Docker as a container runtime for Kubernetes kubelets, and
|
||||
what that means, check out the blog post
|
||||
[Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
|
||||
|
|
@ -101,7 +101,7 @@ in the form of [runc], which is the underlying default runtime for both
|
|||
[containerd] and [CRI-O]. The CRI builds on these low-level specifications to
|
||||
provide an end-to-end standard for managing containers.
|
||||
|
||||
[Open Container Initative]: https://opencontainers.org/about/overview/
|
||||
[Open Container Initiative]: https://opencontainers.org/about/overview/
|
||||
[runc]: https://github.com/opencontainers/runc
|
||||
[containerd]: https://containerd.io/
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,92 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "GSoD 2020: Improving the API Reference Experience"
|
||||
date: 2020-12-04
|
||||
slug: gsod-2020-improving-api-reference-experience
|
||||
---
|
||||
|
||||
**Author**: [Philippe Martin](https://github.com/feloy)
|
||||
|
||||
_Editor's note: Better API references have been my goal since I joined Kubernetes docs three and a half years ago. Philippe has succeeded fantastically. More than a better API reference, though, Philippe embodied the best of the Kubernetes community in this project: excellence through collaboration, and a process that made the community itself better. Thanks, Google Season of Docs, for making Philippe's work possible. —Zach Corleissen_
|
||||
|
||||
## Introduction
|
||||
|
||||
The [Google Season of Docs](https://developers.google.com/season-of-docs) project brings open source organizations and technical writers together to work closely on a specific documentation project.
|
||||
|
||||
I was selected by the CNCF to work on Kubernetes documentation, specifically to make the API Reference documentation more accessible.
|
||||
|
||||
I'm a software developer with a great interest in documentation systems. In the late 90's I started translating Linux-HOWTO documents into French. From one thing to another, I learned about documentation systems. Eventually, I wrote a Linux-HOWTO to help documentarians learn the language used at that time for writing documents, LinuxDoc/SGML.
|
||||
|
||||
Shortly afterward, Linux documentation adopted the DocBook language. I helped some writers rewrite their documents in this format; for example, the Advanced Bash-Scripting Guide. I also worked on the GNU `makeinfo` program to add DocBook output, making it possible to transform *GNU Info* documentation into Docbook format.
|
||||
|
||||
## Background
|
||||
|
||||
The [Kubernetes website](https://kubernetes.io/docs/home/) is built with Hugo from documentation written in Markdown format in the [website repository](https://github.com/kubernetes/website), using the [Docsy Hugo theme](https://www.docsy.dev/about/).
|
||||
|
||||
The existing API reference documentation is a large HTML file generated from the Kubernetes OpenAPI specification.
|
||||
|
||||
On my side, I wanted for some time to make the API Reference more accessible, by:
|
||||
- building individual and autonomous pages for each Kubernetes resource
|
||||
- adapting the format to mobile reading
|
||||
- reusing the website's assets and theme to build, integrate, and display the reference pages
|
||||
- allowing the search engines to reference the content of the pages
|
||||
|
||||
Around one year ago, I started to work on the generator building the current unique HTML page, to add a DocBook output, so the API Reference could be generated first in DocBook format, and after that in PDF or other formats supported by DocBook processors. The first result has been some [Ebook files for the API Reference](https://github.com/feloy/kubernetes-resources-reference/releases) and an auto-edited paper book.
|
||||
|
||||
I decided later to add another output to this generator, to generate Markdown files and create [a website with the API Reference](https://web.archive.org/web/20201022201911/https://www.k8sref.io/docs/workloads/).
|
||||
|
||||
When the CNCF proposed a project for the Google Season of Docs to work on the API Reference, I applied, and the match occurred.
|
||||
|
||||
## The Project
|
||||
|
||||
### swagger-ui
|
||||
|
||||
The first idea of the CNCF members that proposed this project was to test the [`swagger-ui` tool](https://swagger.io/tools/swagger-ui/), to try and document the Kubernetes API Reference with this standard tool.
|
||||
|
||||
Because the Kubernetes API is much larger than many other APIs, it has been necessary to write a tool to split the complete API Reference by API Groups, and insert in the Documentation website several `swagger-ui` components, one for each API Group.
|
||||
|
||||
Generally, APIs are used by developers by calling endpoints with a specific HTTP verb, with specific parameters and waiting for a response. The `swagger-ui` interface is built for this usage: the interface displays a list of endpoints and their associated verbs, and for each the parameters and responses formats.
|
||||
|
||||
The Kubernetes API is most of the time used differently: users create manifest files containing resources definitions in YAML format, and use the `kubectl` CLI to *apply* these manifests to the cluster. In this case, the most important information is the description of the structures used as parameters and responses (the Kubernetes Resources).
|
||||
|
||||
Because of this specificity, we realized that it would be difficult to adapt the `swagger-ui` interface to satisfy the users of the Kubernetes API and this direction has been abandoned.
|
||||
|
||||
### Markdown pages
|
||||
|
||||
The second stage of the project has been to adapt the work I had done to create the k8sref.io website, to include it in the official documentation website.
|
||||
|
||||
The main changes have been to:
|
||||
- use go-templates to represent the output pages, so non-developers can adapt the generated pages without having to edit the generator code
|
||||
- create a new custom [shortcode](https://gohugo.io/content-management/shortcodes/), to easily create links from inside the website to specific pages of the API reference
|
||||
- improve the navigation between the sections of the API reference
|
||||
- add the code of the generator to the Kubernetes GitHub repository containing the different reference generators
|
||||
|
||||
All the discussions and work done can be found in website [pull request #23294](https://github.com/kubernetes/website/pull/23294).
|
||||
|
||||
Adding the generator code to the Kubernetes project happened in [kubernetes-sigs/reference-docs#179](https://github.com/kubernetes-sigs/reference-docs/pull/179).
|
||||
|
||||
Here are the features of the new API Reference to be included in the official documentation website:
|
||||
|
||||
- the resources are categorized, in the categories Workloads, Services, Config & Storage, Authentication, Authorization, Policies, Extend, Cluster. This structure is configurable with a simple [`toc.yaml` file](https://github.com/kubernetes-sigs/reference-docs/blob/master/gen-resourcesdocs/config/v1.20/toc.yaml)
|
||||
- each page displays associated resources at the first level ; for example: Pod, PodSpec, PodStatus, PodList
|
||||
- most resource pages inline relevant definitions ; the exceptions are when those definitions are common to several resources, or are too complex to be displayed inline. With the old approach, you had to follow a hyperlink to read each extra detail.
|
||||
- some widely used definitions, such as `ObjectMeta`, are documented in a specific page
|
||||
- required fields are indicated, and placed first
|
||||
- fields of a resource can be categorized and ordered, with the help of a [`fields.yaml` file](https://github.com/kubernetes-sigs/reference-docs/blob/master/gen-resourcesdocs/config/v1.20/fields.yaml)
|
||||
- `map` fields are indicated. For example the `.spec.nodeSelector` for a `Pod` is `map[string]string`, instead of `object`, using the value of `x-kubernetes-list-type`
|
||||
- patch strategies are indicated
|
||||
- `apiVersion` and `kind` display the value, not the `string` type
|
||||
- At the top of a reference page, the page displays the Go import necessary to use these resources from a Go program.
|
||||
|
||||
The work is currently on hold pending the 1.20 release. When the release finishes and the work is integrated, the API reference will be available at https://kubernetes.io/docs/reference/.
|
||||
|
||||
### Future Work
|
||||
|
||||
There are points to improve, particularly:
|
||||
|
||||
- Some Kubernetes resources are deeply nested. Inlining the definition of these resources makes them difficult to understand.
|
||||
- The created `shortcode` uses the URL of the page to reference a Resource page. It would be easier for documentarians if they could reference a Resource by its group and name.
|
||||
|
||||
## Appreciation
|
||||
|
||||
I would like to thank my mentor [Zach Corleissen](https://github.com/zacharysarah) and the lead writers [Karen Bradshaw](https://github.com/kbhawkey), [Celeste Horgan](https://github.com/celestehorgan), [Tim Bannister](https://github.com/sftim) and [Qiming Teng](https://github.com/tengqm) who supervised me during all the season. They all have been very encouraging and gave me tons of great advice.
|
||||
|
|
@ -80,7 +80,7 @@ default rotation is configured to take place when log file exceeds 10MB.
|
|||
|
||||
As an example, you can find detailed information about how `kube-up.sh` sets
|
||||
up logging for COS image on GCP in the corresponding
|
||||
[script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
|
||||
[script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh).
|
||||
|
||||
When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
|
||||
the basic logging example, the kubelet on the node handles the request and
|
||||
|
|
|
|||
|
|
@ -58,10 +58,11 @@ to containers. If your job previously ran in a VM, your VM had an IP and could
|
|||
talk to other VMs in your project. This is the same basic model.
|
||||
|
||||
Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod`
|
||||
share their network namespaces - including their IP address. This means that
|
||||
containers within a `Pod` can all reach each other's ports on `localhost`. This
|
||||
also means that containers within a `Pod` must coordinate port usage, but this
|
||||
is no different from processes in a VM. This is called the "IP-per-pod" model.
|
||||
share their network namespaces - including their IP address and MAC address.
|
||||
This means that containers within a `Pod` can all reach each other's ports on
|
||||
`localhost`. This also means that containers within a `Pod` must coordinate port
|
||||
usage, but this is no different from processes in a VM. This is called the
|
||||
"IP-per-pod" model.
|
||||
|
||||
How this is implemented is a detail of the particular container runtime in use.
|
||||
|
||||
|
|
|
|||
|
|
@ -308,28 +308,37 @@ If expanding underlying storage fails, the cluster administrator can manually re
|
|||
|
||||
## Types of Persistent Volumes
|
||||
|
||||
PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:
|
||||
PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:
|
||||
|
||||
* GCEPersistentDisk
|
||||
* AWSElasticBlockStore
|
||||
* AzureFile
|
||||
* AzureDisk
|
||||
* CSI
|
||||
* FC (Fibre Channel)
|
||||
* FlexVolume
|
||||
* Flocker
|
||||
* NFS
|
||||
* iSCSI
|
||||
* RBD (Ceph Block Device)
|
||||
* CephFS
|
||||
* Cinder (OpenStack block storage)
|
||||
* Glusterfs
|
||||
* VsphereVolume
|
||||
* Quobyte Volumes
|
||||
* HostPath (Single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
|
||||
* Portworx Volumes
|
||||
* ScaleIO Volumes
|
||||
* StorageOS
|
||||
* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS)
|
||||
* [`azureDisk`](/docs/concepts/sotrage/volumes/#azuredisk) - Azure Disk
|
||||
* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File
|
||||
* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume
|
||||
* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage)
|
||||
(**deprecated**)
|
||||
* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI)
|
||||
* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage
|
||||
* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
|
||||
* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage
|
||||
* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
|
||||
* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume
|
||||
* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume
|
||||
(for single node testing only; WILL NOT WORK in a multi-node cluster;
|
||||
consider using `local` volume instead)
|
||||
* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage
|
||||
* [`local`](/docs/concepts/storage/volumes/#local) - local storage devices
|
||||
mounted on nodes.
|
||||
* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage
|
||||
* `photonPersistentDisk` - Photon controller persistent disk.
|
||||
(This volume type no longer works since the removal of the corresponding
|
||||
cloud provider.)
|
||||
* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume
|
||||
* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume
|
||||
* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume
|
||||
* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume
|
||||
(**deprecated**)
|
||||
* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume
|
||||
* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume
|
||||
|
||||
## Persistent Volumes
|
||||
|
||||
|
|
|
|||
|
|
@ -87,12 +87,6 @@ When the two are specified the result is ANDed.
|
|||
|
||||
If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API.
|
||||
|
||||
Also you should not normally create any Pods whose labels match this selector, either directly, via
|
||||
another DaemonSet, or via another workload resource such as ReplicaSet. Otherwise, the DaemonSet
|
||||
{{< glossary_tooltip term_id="controller" >}} will think that those Pods were created by it.
|
||||
Kubernetes will not stop you from doing this. One case where you might want to do this is manually
|
||||
create a Pod with a different value on a node for testing.
|
||||
|
||||
### Running Pods on select Nodes
|
||||
|
||||
If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
|
||||
|
|
|
|||
|
|
@ -419,8 +419,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
|
||||
for more details.
|
||||
- `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume consisting of a
|
||||
ServiceAccountTokenVolumeProjection.
|
||||
Check [Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)
|
||||
ServiceAccountTokenVolumeProjection. Cluster admins can use metric `serviceaccount_stale_tokens_total` to
|
||||
monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off
|
||||
extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`.
|
||||
Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
|
||||
for more details.
|
||||
- `ConfigurableFSGroupPolicy`: Allows user to configure volume permission change policy for fsGroups when mounting a volume in a Pod. See [Configure volume permission and ownership change policy for Pods](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods) for more details.
|
||||
- `CronJobControllerV2`: Use an alternative implementation of the {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} controller. Otherwise, version 1 of the same controller is selected. The version 2 controller provides experimental performance improvements.
|
||||
|
|
|
|||
|
|
@ -415,6 +415,17 @@ approve node _serving_ certificates for [security
|
|||
reasons](https://github.com/kubernetes/community/pull/1982). To use
|
||||
`RotateKubeletServerCertificate` operators need to run a custom approving
|
||||
controller, or manually approve the serving certificate requests.
|
||||
|
||||
A deployment-specific approval process for kubelet serving certificates should typically only approve CSRs which:
|
||||
|
||||
1. are requested by nodes (ensure the `spec.username` field is of the form
|
||||
`system:node:<nodeName>` and `spec.groups` contains `system:nodes`)
|
||||
2. request usages for a serving certificate (ensure `spec.usages` contains `server auth`,
|
||||
optionally contains `digital signature` and `key encipherment`, and contains no other usages)
|
||||
3. only have IP and DNS subjectAltNames that belong to the requesting node,
|
||||
and have no URI and Email subjectAltNames (parse the x509 Certificate Signing Request
|
||||
in `spec.request` to verify `subjectAltNames`)
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
## Other authenticating components
|
||||
|
|
|
|||
|
|
@ -311,6 +311,7 @@ kubectl run nginx --image=nginx # Run pod nginx and write it
|
|||
kubectl attach my-pod -i # Attach to Running Container
|
||||
kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
|
||||
kubectl exec my-pod -- ls / # Run command in existing pod (1 container case)
|
||||
kubectl exec --stdin --tty my-pod -- /bin/sh # Interactive shell access to a running pod (1 container case)
|
||||
kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case)
|
||||
kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers
|
||||
```
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ sudo apt-get update && sudo apt-get install -y containerd.io
|
|||
```shell
|
||||
# Configure containerd
|
||||
sudo mkdir -p /etc/containerd
|
||||
sudo containerd config default > /etc/containerd/config.toml
|
||||
sudo containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -200,6 +200,19 @@ If the access URLs of the restored cluster is changed from the previous cluster,
|
|||
|
||||
If the majority of etcd members have permanently failed, the etcd cluster is considered failed. In this scenario, Kubernetes cannot make any changes to its current state. Although the scheduled pods might continue to run, no new pods can be scheduled. In such cases, recover the etcd cluster and potentially reconfigure Kubernetes API server to fix the issue.
|
||||
|
||||
{{< note >}}
|
||||
If any API servers are running in your cluster, you should not attempt to restore instances of etcd.
|
||||
Instead, follow these steps to restore etcd:
|
||||
|
||||
- stop *all* kube-apiserver instances
|
||||
- restore state in all etcd instances
|
||||
- restart all kube-apiserver instances
|
||||
|
||||
We also recommend restarting any components (e.g. kube-scheduler, kube-controller-manager, kubelet) to ensure that they don't
|
||||
rely on some stale data. Note that in practice, the restore takes a bit of time.
|
||||
During the restoration, critical components will lose leader lock and restart themselves.
|
||||
{{< /note >}}
|
||||
|
||||
## Upgrading and rolling back etcd clusters
|
||||
|
||||
As of Kubernetes v1.13.0, etcd2 is no longer supported as a storage backend for
|
||||
|
|
|
|||
|
|
@ -105,8 +105,8 @@ Type: Opaque
|
|||
|
||||
Data
|
||||
====
|
||||
password.txt: 12 bytes
|
||||
username.txt: 5 bytes
|
||||
password: 12 bytes
|
||||
username: 5 bytes
|
||||
```
|
||||
|
||||
The commands `kubectl get` and `kubectl describe` avoid showing the contents
|
||||
|
|
|
|||
|
|
@ -22,14 +22,14 @@ Mientras que Kubernetes soporta más {{<glossary_tooltip text="runtimes de conte
|
|||
|
||||
El contexto compartido de un Pod es un conjunto de namespaces de Linux, cgroups y, potencialmente, otras facetas de aislamiento, las mismas cosas que aíslan un contenedor Docker. Dentro del contexto de un Pod, las aplicaciones individuales pueden tener más subaislamientos aplicados.
|
||||
|
||||
Los contenedores dentro de un Pod comparten dirección IP y puerto, y pueden encontrarse a través de `localhost`. También pueden comunicarse entre sí mediante comunicaciones estándar entre procesos, como semáforos de SystemV o la memoria compartida POSIX. Los contenedores en diferentes Pods tienen direcciones IP distintas y no pueden comunicarse por IPC sin [configuración especial](/es/docs /concepts/policy/pod-security-policy/).
|
||||
Los contenedores dentro de un Pod comparten dirección IP y puerto, y pueden encontrarse a través de `localhost`. También pueden comunicarse entre sí mediante comunicaciones estándar entre procesos, como semáforos de SystemV o la memoria compartida POSIX. Los contenedores en diferentes Pods tienen direcciones IP distintas y no pueden comunicarse por IPC sin [configuración especial](/docs/concepts/policy/pod-security-policy/).
|
||||
Estos contenedores normalmente se comunican entre sí a través de las direcciones IP del Pod.
|
||||
|
||||
Las aplicaciones dentro de un Pod también tienen acceso a {{<glossary_tooltip text="volúmenes" term_id="volume">}} compartidos, que se definen como parte de un Pod y están disponibles para ser montados en el sistema de archivos de cada aplicación.
|
||||
|
||||
En términos de [Docker](https://www.docker.com/), un Pod se modela como un grupo de contenedores de Docker con namespaces y volúmenes de sistemas de archivos compartidos.
|
||||
|
||||
Al igual que los contenedores de aplicaciones individuales, los Pods se consideran entidades relativamente efímeras (en lugar de duraderas). Como se explica en [ciclo de vida del pod](/es/docs/concepts/workloads/pods/pod-lifecycle/), los Pods se crean, se les asigna un identificador único (UID) y se planifican en nodos donde permanecen hasta su finalización (según la política de reinicio) o supresión. Si un {{<glossary_tooltip text="nodo" term_id="node">}} muere, los Pods programados para ese nodo se programan para su eliminación después de un período de tiempo de espera. Un Pod dado (definido por su UID) no se "replanifica" a un nuevo nodo; en su lugar, puede reemplazarse por un Pod idéntico, con incluso el mismo nombre si lo desea, pero con un nuevo UID (consulte [controlador de replicación](/es/docs/concepts/workloads/controllers/replicationcontroller/) para obtener más detalles).
|
||||
Al igual que los contenedores de aplicaciones individuales, los Pods se consideran entidades relativamente efímeras (en lugar de duraderas). Como se explica en [ciclo de vida del pod](/docs/concepts/workloads/pods/pod-lifecycle/), los Pods se crean, se les asigna un identificador único (UID) y se planifican en nodos donde permanecen hasta su finalización (según la política de reinicio) o supresión. Si un {{<glossary_tooltip text="nodo" term_id="node">}} muere, los Pods programados para ese nodo se programan para su eliminación después de un período de tiempo de espera. Un Pod dado (definido por su UID) no se "replanifica" a un nuevo nodo; en su lugar, puede reemplazarse por un Pod idéntico, con incluso el mismo nombre si lo desea, pero con un nuevo UID (consulte [controlador de replicación](/es/docs/concepts/workloads/controllers/replicationcontroller/) para obtener más detalles).
|
||||
|
||||
Cuando se dice que algo tiene la misma vida útil que un Pod, como un volumen, significa que existe mientras exista ese Pod (con ese UID). Si ese Pod se elimina por cualquier motivo, incluso si se crea un reemplazo idéntico, el recurso relacionado (por ejemplo, el volumen) también se destruye y se crea de nuevo.
|
||||
{{< figure src="/images/docs/pod.svg" title="diagrama de Pod" width="50%" >}}
|
||||
|
|
@ -49,7 +49,7 @@ Los Pods permiten el intercambio de datos y la comunicación entre los contenedo
|
|||
Todas las aplicaciones en un Pod utilizan el mismo namespace de red (la misma IP y puerto) y, por lo tanto, pueden "encontrarse" entre sí y comunicarse utilizando `localhost`.
|
||||
Debido a esto, las aplicaciones en un Pod deben coordinar su uso de puertos. Cada Pod tiene una dirección IP en un espacio de red compartido que tiene comunicación completa con otros servidores físicos y Pods a través de la red.
|
||||
|
||||
Los contenedores dentro del Pod ven que el hostname del sistema es el mismo que el `nombre` configurado para el Pod. Hay más información sobre esto en la sección [networking](/es/docs/concepts/cluster-administration/networking/).
|
||||
Los contenedores dentro del Pod ven que el hostname del sistema es el mismo que el `nombre` configurado para el Pod. Hay más información sobre esto en la sección [networking](/docs/concepts/cluster-administration/networking/).
|
||||
|
||||
Además de definir los contenedores de aplicaciones que se ejecutan en el Pod, el Pod especifica un conjunto de volúmenes de almacenamiento compartido. Los volúmenes permiten que los datos sobrevivan a reinicios de contenedores y se compartan entre las aplicaciones dentro del Pod.
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ usar siempre controladores incluso para Pods individuales, como por ejemplo, los
|
|||
[Deployments](/es/docs/concepts/workloads/controllers/deployment/).
|
||||
Los controladores proporcionan autorecuperación con un alcance de clúster, así como replicación
|
||||
y gestión de despliegue.
|
||||
Otros controladores como los [StatefulSet](/es/docs/concepts/workloads/controllers/statefulset.md)
|
||||
Otros controladores como los [StatefulSet](/es/docs/concepts/workloads/controllers/statefulset/)
|
||||
pueden tambien proporcionar soporte para Pods que necesiten persistir el estado.
|
||||
|
||||
El uso de API colectivas como la principal primitiva de cara al usuario es relativamente común entre los sistemas de planificación de clúster, incluyendo [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), y [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
|
||||
|
|
@ -128,14 +128,14 @@ Un ejemplo del ciclo de terminación de un Pod:
|
|||
1. Cuando expira el período de gracia, todos los procesos que todavía se ejecutan en el Pod se eliminan con SIGKILL.
|
||||
1. El Kubelet terminará de eliminar el Pod en el servidor API configurando el período de gracia 0 (eliminación inmediata). El Pod desaparece de la API y ya no es visible desde el cliente.
|
||||
|
||||
Por defecto, todas las eliminaciones se realizan correctamente en 30 segundos. El comando `kubectl delete` admite la opción` --grace-period = <seconds> `que permite al usuario anular el valor predeterminado y especificar su propio valor. El valor `0` [forzar eliminación](/es/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) del Pod.
|
||||
Por defecto, todas las eliminaciones se realizan correctamente en 30 segundos. El comando `kubectl delete` admite la opción` --grace-period = <seconds> `que permite al usuario anular el valor predeterminado y especificar su propio valor. El valor `0` [forzar eliminación](/es/docs/concepts/workloads/pods/pod/#forzar-destrucción-de-pods) del Pod.
|
||||
Debe especificar un indicador adicional `--force` junto con` --grace-period = 0` para realizar eliminaciones forzadas.
|
||||
|
||||
### Forzar destrucción de Pods
|
||||
|
||||
La eliminación forzada de un Pod se define como la eliminación de un Pod del estado del clúster y etcd inmediatamente. Cuando se realiza una eliminación forzada, el apiserver no espera la confirmación del kubelet de que el Pod ha finalizado en el nodo en el que se estaba ejecutando. Elimina el Pod en la API inmediatamente para que se pueda crear un nuevo Pod con el mismo nombre. En el nodo, los Pods que están configurados para terminar de inmediato recibirán un pequeño período de gracia antes de ser forzadas a matar.
|
||||
|
||||
Estas eliminaciones pueden ser potencialmente peligrosas para algunos Pods y deben realizarse con precaución. En el caso de Pods de StatefulSets, consulte la documentación de la tarea para [eliminando Pods de un StatefulSet](/es/docs/tasks/run-application/force-delete-stateful-set-pod/).
|
||||
Estas eliminaciones pueden ser potencialmente peligrosas para algunos Pods y deben realizarse con precaución. En el caso de Pods de StatefulSets, consulte la documentación de la tarea para [eliminando Pods de un StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
|
||||
|
||||
## Modo privilegiado para Pods
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ sitemap:
|
|||
|
||||
{{< blocks/section id="oceanNodes" >}}
|
||||
{{% blocks/feature image="flower" %}}
|
||||
[쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
|
||||
K8s라고도 알려진 [쿠버네티스]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
|
||||
|
||||
애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
|
||||
{{% /blocks/feature %}}
|
||||
|
|
@ -28,7 +28,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
|
|||
{{% /blocks/feature %}}
|
||||
|
||||
{{% blocks/feature image="suitcase" %}}
|
||||
#### 어디서나 동작
|
||||
#### K8s를 어디서나 실행
|
||||
|
||||
쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다.
|
||||
|
||||
|
|
@ -44,6 +44,11 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
|
|||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon NA virtually on November 17-20, 2020</a>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Attend KubeCon EU virtually on May 4 – 7, 2021</a>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -26,9 +26,9 @@ case_study_details:
|
|||
|
||||
<p>Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.</p>
|
||||
|
||||
{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times">}}
|
||||
<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
|
||||
<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
|
||||
{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times" >}}
|
||||
{{< youtube DqS_IPw-c6o youtube-quote-sm >}}
|
||||
{{< youtube Tm4VfJtOHt8 youtube-quote-sm >}}
|
||||
<br>
|
||||
"I think once you get over the initial hump, things get a lot easier and actually a lot faster."
|
||||
{{< /case-studies/quote >}}
|
||||
|
|
|
|||
|
|
@ -93,8 +93,7 @@ weight: 30
|
|||
현재 상태를 보다 가깝게 만든다.
|
||||
|
||||
(실제로 클러스터의 노드를 수평으로 확장하는
|
||||
컨트롤러가 있다.
|
||||
[클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 본다.)
|
||||
[컨트롤러](https://github.com/kubernetes/autoscaler/)가 있다.)
|
||||
|
||||
여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고,
|
||||
현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다.
|
||||
|
|
|
|||
|
|
@ -335,4 +335,3 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
|
|||
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
|
||||
섹션을 읽어본다.
|
||||
* [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
|
||||
* [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다.
|
||||
|
|
|
|||
|
|
@ -35,8 +35,6 @@ no_list: true
|
|||
|
||||
## 클러스터 관리
|
||||
|
||||
* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터 라이프사이클과 관련된 몇 가지 주제를 설명한다. 새로운 클러스터 생성, 클러스터의 마스터 및 워커 노드 업그레이드, 노드 유지 관리 수행(예: 커널 업그레이드) 및 실행 중인 클러스터의 쿠버네티스 API 버전 업그레이드
|
||||
|
||||
* [노드 관리](/ko/docs/concepts/architecture/nodes/) 방법을 배운다.
|
||||
|
||||
* 공유 클러스터에 대한 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하고 관리하는 방법을 배운다.
|
||||
|
|
|
|||
|
|
@ -25,6 +25,7 @@ content_type: concept
|
|||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
|
||||
* [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다.
|
||||
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
|
||||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
|
||||
|
|
|
|||
|
|
@ -156,6 +156,11 @@ VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브
|
|||
수 있다. 즉, cni-ipvlan-vpc-k8s는 AWS 내에서 쿠버네티스를
|
||||
대규모로 배포하는 데 필요한 네트워크 복잡성을 크게 줄인다.
|
||||
|
||||
### Coil
|
||||
|
||||
[Coil](https://github.com/cybozu-go/coil)은 통합이 용이하도록 설계된 CNI 플러그인으로 유연한 이그레스(egress) 네트워킹을 제공한다.
|
||||
Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네트워크에 대해 임의의 이그레스 NAT 게이트웨이를 정의할 수 있다.
|
||||
|
||||
### 콘티브(Contiv)
|
||||
|
||||
[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다.
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ data:
|
|||
컨피그맵을 사용하여 파드 내부에 컨테이너를 구성할 수 있는
|
||||
네 가지 방법이 있다.
|
||||
|
||||
1. 컨테이너의 엔트리포인트에 대한 커맨드 라인 인수
|
||||
1. 컨테이너 커맨드와 인수 내에서
|
||||
1. 컨테이너에 대한 환경 변수
|
||||
1. 애플리케이션이 읽을 수 있도록 읽기 전용 볼륨에 파일 추가
|
||||
1. 쿠버네티스 API를 사용하여 컨피그맵을 읽는 파드 내에서 실행할 코드 작성
|
||||
|
|
|
|||
|
|
@ -318,9 +318,7 @@ spec:
|
|||
선점자 대신 우선순위가 높은 파드를 스케줄링한다.
|
||||
|
||||
이것은 예상된 동작이다. 우선순위가 높은 파드는 우선순위가 낮은 파드를
|
||||
대체해야 한다. [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)과
|
||||
같은 다른 컨트롤러 작업은,
|
||||
결국 보류 중인 파드를 스케줄링할 수 있는 용량을 제공할 수 있다.
|
||||
대체해야 한다.
|
||||
|
||||
### 우선순위가 높은 파드는 우선순위가 낮은 파드보다 우선함
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ card:
|
|||
<!-- body -->
|
||||
## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}
|
||||
|
||||
*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다.
|
||||
*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.
|
||||
|
||||
* 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
|
||||
* 그 애플리케이션이 이용할 수 있는 리소스
|
||||
|
|
|
|||
|
|
@ -189,7 +189,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
|
|||
|
||||
#### 서비스와 레플리케이션 컨트롤러
|
||||
|
||||
`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
|
||||
`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다.
|
||||
|
||||
서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -74,8 +74,7 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
|
|||
| `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음. |
|
||||
| `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음. |
|
||||
| `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음. |
|
||||
| `hugepages-<size>` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의
|
||||
휴즈 페이지 요청은 이 값을 초과하지 못함. |
|
||||
| `hugepages-<size>` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의 휴즈 페이지 요청은 이 값을 초과하지 못함. |
|
||||
| `cpu` | `requests.cpu` 와 같음. |
|
||||
| `memory` | `requests.memory` 와 같음. |
|
||||
|
||||
|
|
|
|||
|
|
@ -8,125 +8,146 @@ weight: 50
|
|||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라 kube-scheduler를 미세 조정할 수 있다.
|
||||
|
||||
|
||||
kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서
|
||||
확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라
|
||||
kube-scheduler를 미세 조정할 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
|
||||
|
||||
쿠버네티스 1.15 이전에는 Kube-scheduler가 CPU 및 메모리와 같은 리소스의 용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용했다. 쿠버네티스 1.16은 우선 순위 기능에 새로운 파라미터를 추가해서 사용자가 용량 대비 요청 비율을 기반으로 노드에 점수를 매기도록 각 리소스의 가중치와 함께 리소스를 지정할 수 있다. 이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들수 있어 대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 `requestedToCapacityRatioArguments`라는 구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. 셰이프(shape)는 사용자가 `utilization`과 `score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. 리소스는
|
||||
점수를 매길 때 고려할 리소스를 지정하는 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
|
||||
쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
|
||||
용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를
|
||||
통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
|
||||
대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
|
||||
`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의
|
||||
동작은 `requestedToCapacityRatioArguments`라는
|
||||
구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources`
|
||||
두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과
|
||||
`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
|
||||
조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할
|
||||
리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로
|
||||
구성된다.
|
||||
|
||||
다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 설정하는 구성의 예시이다.
|
||||
다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한
|
||||
`requestedToCapacityRatioArguments` 를 빈 패킹 동작으로
|
||||
설정하는 구성의 예시이다.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind" : "Policy",
|
||||
"apiVersion" : "v1",
|
||||
|
||||
...
|
||||
|
||||
"priorities" : [
|
||||
|
||||
...
|
||||
|
||||
{
|
||||
"name": "RequestedToCapacityRatioPriority",
|
||||
"weight": 2,
|
||||
"argument": {
|
||||
"requestedToCapacityRatioArguments": {
|
||||
"shape": [
|
||||
{"utilization": 0, "score": 0},
|
||||
{"utilization": 100, "score": 10}
|
||||
],
|
||||
"resources": [
|
||||
{"name": "intel.com/foo", "weight": 3},
|
||||
{"name": "intel.com/bar", "weight": 5}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
}
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Policy
|
||||
# ...
|
||||
priorities:
|
||||
# ...
|
||||
- name: RequestedToCapacityRatioPriority
|
||||
weight: 2
|
||||
argument:
|
||||
requestedToCapacityRatioArguments:
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 0
|
||||
- utilization: 100
|
||||
score: 10
|
||||
resources:
|
||||
- name: intel.com/foo
|
||||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 5
|
||||
```
|
||||
|
||||
**이 기능은 기본적으로 비활성화되어 있다.**
|
||||
|
||||
### RequestedToCapacityRatioResourceAllocation 우선 순위 기능 튜닝하기
|
||||
### 우선 순위 기능 튜닝하기
|
||||
|
||||
`shape` 는 `RequestedToCapacityRatioPriority` 기능의 동작을 지정하는 데 사용된다.
|
||||
`shape` 는 `RequestedToCapacityRatioPriority` 기능의
|
||||
동작을 지정하는 데 사용된다.
|
||||
|
||||
```yaml
|
||||
{"utilization": 0, "score": 0},
|
||||
{"utilization": 100, "score": 10}
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 0
|
||||
- utilization: 100
|
||||
score: 10
|
||||
```
|
||||
|
||||
위의 인수는 사용률이 0%인 경우 점수는 0, 사용률이 100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을 활성화하려면 점수 값을 다음과 같이 변경해야 한다.
|
||||
위의 인수는 `utilization` 이 0%인 경우 `score` 는 0, `utilization` 이
|
||||
100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을
|
||||
활성화하려면 점수 값을 다음과 같이 변경해야 한다.
|
||||
|
||||
```yaml
|
||||
{"utilization": 0, "score": 100},
|
||||
{"utilization": 100, "score": 0}
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 100
|
||||
- utilization: 100
|
||||
score: 0
|
||||
```
|
||||
|
||||
`resources` 는 기본적으로 다음과 같이 설정되는 선택적인 파라미터이다.
|
||||
|
||||
``` yaml
|
||||
"resources": [
|
||||
{"name": "CPU", "weight": 1},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
resources:
|
||||
- name: CPU
|
||||
weight: 1
|
||||
- name: Memory
|
||||
weight: 1
|
||||
```
|
||||
|
||||
다음과 같이 확장된 리소스를 추가하는 데 사용할 수 있다.
|
||||
|
||||
```yaml
|
||||
"resources": [
|
||||
{"name": "intel.com/foo", "weight": 5},
|
||||
{"name": "CPU", "weight": 3},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
resources:
|
||||
- name: intel.com/foo
|
||||
weight: 5
|
||||
- name: CPU
|
||||
weight: 3
|
||||
- name: Memory
|
||||
weight: 1
|
||||
```
|
||||
|
||||
가중치 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한, 가중치는 음수로 설정할 수 없다.
|
||||
`weight` 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한,
|
||||
`weight` 는 음수로 설정할 수 없다.
|
||||
|
||||
### RequestedToCapacityRatioResourceAllocation 우선 순위 기능이 노드에 점수를 매기는 방법
|
||||
### 용량 할당을 위해 노드에 점수 매기기
|
||||
|
||||
이 섹션은 이 기능 내부의 세부적인 사항을 이해하려는 사람들을
|
||||
위한 것이다.
|
||||
아래는 주어진 값의 집합에 대해 노드 점수가 계산되는 방법의 예시이다.
|
||||
|
||||
```
|
||||
Requested Resources
|
||||
요청된 리소스는 다음과 같다.
|
||||
|
||||
```
|
||||
intel.com/foo : 2
|
||||
Memory: 256MB
|
||||
CPU: 2
|
||||
```
|
||||
|
||||
Resource Weights
|
||||
리소스의 가중치는 다음과 같다.
|
||||
|
||||
```
|
||||
intel.com/foo : 5
|
||||
Memory: 1
|
||||
CPU: 3
|
||||
```
|
||||
|
||||
FunctionShapePoint {{0, 0}, {100, 10}}
|
||||
|
||||
Node 1 Spec
|
||||
노드 1의 사양은 다음과 같다.
|
||||
|
||||
```
|
||||
Available:
|
||||
intel.com/foo : 4
|
||||
Memory : 1 GB
|
||||
CPU: 8
|
||||
intel.com/foo: 4
|
||||
Memory: 1 GB
|
||||
CPU: 8
|
||||
|
||||
Used:
|
||||
intel.com/foo: 1
|
||||
Memory: 256MB
|
||||
CPU: 1
|
||||
intel.com/foo: 1
|
||||
Memory: 256MB
|
||||
CPU: 1
|
||||
```
|
||||
|
||||
노드 점수는 다음과 같다.
|
||||
|
||||
Node Score:
|
||||
|
||||
```
|
||||
intel.com/foo = resourceScoringFunction((2+1),4)
|
||||
= (100 - ((4-3)*100/4)
|
||||
= (100 - 25)
|
||||
|
|
@ -148,24 +169,24 @@ CPU = resourceScoringFunction((2+1),8)
|
|||
|
||||
NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
|
||||
= 5
|
||||
```
|
||||
|
||||
노드 2의 사양은 다음과 같다.
|
||||
|
||||
Node 2 Spec
|
||||
|
||||
```
|
||||
Available:
|
||||
intel.com/foo: 8
|
||||
Memory: 1GB
|
||||
CPU: 8
|
||||
|
||||
intel.com/foo: 8
|
||||
Memory: 1GB
|
||||
CPU: 8
|
||||
Used:
|
||||
intel.com/foo: 2
|
||||
Memory: 512MB
|
||||
CPU: 6
|
||||
```
|
||||
|
||||
intel.com/foo: 2
|
||||
Memory: 512MB
|
||||
CPU: 6
|
||||
|
||||
|
||||
Node Score:
|
||||
노드 점수는 다음과 같다.
|
||||
|
||||
```
|
||||
intel.com/foo = resourceScoringFunction((2+2),8)
|
||||
= (100 - ((8-4)*100/8)
|
||||
= (100 - 50)
|
||||
|
|
@ -189,3 +210,8 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
|
|||
= 7
|
||||
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)에 대해 더 읽어본다.
|
||||
- [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 대해 더 읽어본다.
|
||||
|
|
|
|||
|
|
@ -28,15 +28,15 @@ _톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트
|
|||
예를 들면 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl taint nodes node1 key=value:NoSchedule
|
||||
kubectl taint nodes node1 key1=value1:NoSchedule
|
||||
```
|
||||
|
||||
`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key`, 값 `value` 및 테인트 이펙트(effect) `NoSchedule` 이 있다.
|
||||
`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key1`, 값 `value1` 및 테인트 이펙트(effect) `NoSchedule` 이 있다.
|
||||
이는 일치하는 톨러레이션이 없으면 파드를 `node1` 에 스케줄할 수 없음을 의미한다.
|
||||
|
||||
위의 명령으로 추가한 테인트를 제거하려면, 다음을 실행한다.
|
||||
```shell
|
||||
kubectl taint nodes node1 key:NoSchedule-
|
||||
kubectl taint nodes node1 key1=value1:NoSchedule-
|
||||
```
|
||||
|
||||
PodSpec에서 파드에 대한 톨러레이션를 지정한다. 다음의 톨러레이션은
|
||||
|
|
@ -45,15 +45,15 @@ PodSpec에서 파드에 대한 톨러레이션를 지정한다. 다음의 톨러
|
|||
|
||||
```yaml
|
||||
tolerations:
|
||||
- key: "key"
|
||||
- key: "key1"
|
||||
operator: "Equal"
|
||||
value: "value"
|
||||
value: "value1"
|
||||
effect: "NoSchedule"
|
||||
```
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- key: "key"
|
||||
- key: "key1"
|
||||
operator: "Exists"
|
||||
effect: "NoSchedule"
|
||||
```
|
||||
|
|
@ -76,7 +76,7 @@ tolerations:
|
|||
operator `Exists` 가 있는 비어있는 `key` 는 모든 키, 값 및 이펙트와 일치하므로
|
||||
모든 것이 톨러레이션 된다.
|
||||
|
||||
비어있는 `effect` 는 모든 이펙트를 키 `key` 와 일치시킨다.
|
||||
비어있는 `effect` 는 모든 이펙트를 키 `key1` 와 일치시킨다.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
|
|||
어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.
|
||||
|
||||
어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
|
||||
어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다.
|
||||
어드미션 컨트롤러는 단순히 오브젝트를 읽는 요청에는 작동하지 않는다.
|
||||
여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.
|
||||
|
||||
이는 다이어그램에 **3**단계로 표시되어 있다.
|
||||
|
|
|
|||
|
|
@ -152,7 +152,7 @@ spec:
|
|||
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
|
||||
"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.
|
||||
|
||||
엔드포인트 객체는 `hostname` 필드를
|
||||
엔드포인트 오브젝트는 `hostname` 필드를
|
||||
임의의 엔드포인트 IP 주소로 지정할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -253,7 +253,7 @@ spec:
|
|||
값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
|
||||
병합 시 중복되는 도메인은 제거되며,
|
||||
쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
|
||||
- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다.
|
||||
- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 오브젝트들의 선택적 목록이다.
|
||||
이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
|
||||
이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
|
||||
병합 시 중복되는 항목은 제거된다.
|
||||
|
|
|
|||
|
|
@ -22,12 +22,14 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
|
|||
|
||||
## 추가 컨트롤러
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
* [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) 기반 인그레스 컨트롤러다.
|
||||
* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
|
||||
* [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다.
|
||||
* [AWS 로드 밸런서 컨트롤러](https://github.com/kubernetes-sigs/aws-load-balancer-controller)(이전의 AWS ALB 인그레스 컨트롤러)는 [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)을 사용하여 인그레스를 활성화한다.
|
||||
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
|
||||
VMware에서 제공하고 지원한다.
|
||||
* Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다.
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
|
|||
SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
# 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
|
||||
## 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
|
||||
|
||||
쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ volumeBindingMode: Immediate
|
|||
등에 대한 완전한 재량권을 가진다. [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
|
||||
리포지터리에는 대량의 사양을 구현하는 외부 프로비저너를 작성하기
|
||||
위한 라이브러리가 있다. 일부 외부 프로비저너의 목록은
|
||||
[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns) 리포지터리에 있다.
|
||||
[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 리포지터리에 있다.
|
||||
|
||||
예를 들어, NFS는 내부 프로비저너를 제공하지 않지만, 외부
|
||||
프로비저너를 사용할 수 있다. 타사 스토리지 업체가 자체 외부
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
|
|||
|
||||
사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.
|
||||
|
||||
* API 객체인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다.
|
||||
* API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다.
|
||||
* `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다.
|
||||
* 쿠버네티스 팀은 `VolumeSnapshot` 베타 버젼의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다.
|
||||
* CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다.
|
||||
|
|
@ -60,7 +60,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
|
|||
{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}
|
||||
API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에).
|
||||
|
||||
퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 객체를 삭제한다면, 퍼시스턴트볼륨클레임 객체는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 객체 삭제는 스냅샷이 준비(readyTouse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.
|
||||
퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.
|
||||
|
||||
### 삭제
|
||||
|
||||
|
|
|
|||
|
|
@ -171,13 +171,17 @@ spec:
|
|||
```
|
||||
|
||||
파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는
|
||||
파드에는 영향을 주지 않는다. 파드는 템플릿 업데이트를 직접 받지 않는다. 대신,
|
||||
수정된 파드 템플릿과 일치하는 새로운 파드가 생성된다.
|
||||
파드에는 직접적인 영향을 주지 않는다. 워크로드 리소스의 파드 템플릿을
|
||||
변경하는 경우, 해당 리소스는 수정된 템플릿을 사용하는 대체 파드를 생성해야 한다.
|
||||
|
||||
예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 각 디플로이먼트 오브젝트에 대한 현재
|
||||
파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트된 경우, 디플로이먼트는
|
||||
기존 파드를 제거하고 업데이트된 템플릿을 기반으로 새로운 파드를 생성해야 한다. 각 워크로드
|
||||
리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다.
|
||||
예를 들어, 스테이트풀셋 컨트롤러는 실행 중인 파드가 각 스테이트풀셋 오브젝트에 대한 현재
|
||||
파드 템플릿과 일치하는지 확인한다. 스테이트풀셋을 수정하여 파드 템플릿을
|
||||
변경하면, 스테이트풀셋이 업데이트된 템플릿을 기반으로 새로운 파드를 생성하기 시작한다.
|
||||
결국, 모든 이전의 파드가 새로운 파드로 교체되고, 업데이트가 완료된다.
|
||||
|
||||
각 워크로드 리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다.
|
||||
스테이트풀셋에 대해 자세히 알아 보려면,
|
||||
스테이트풀셋 기본 튜토리얼에서 [업데이트 전략](/ko/docs/tutorials/stateful-application/basic-stateful-set/#스테이트풀셋-업데이트하기)을 읽어본다.
|
||||
|
||||
노드에서 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}은
|
||||
파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않는다. 이러한
|
||||
|
|
|
|||
|
|
@ -284,8 +284,6 @@ graph BT
|
|||
|
||||
### 클러스터 수준의 기본 제약 조건
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본
|
||||
토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
content_type: concept
|
||||
title: 쿠버네티스 문서에 기여하기
|
||||
title: K8s 문서에 기여하기
|
||||
linktitle: 기여
|
||||
main_menu: true
|
||||
no_list: true
|
||||
|
|
@ -8,7 +8,7 @@ weight: 80
|
|||
card:
|
||||
name: contribute
|
||||
weight: 10
|
||||
title: 기여 시작하기
|
||||
title: K8s에 기여 시작하기
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ cards:
|
|||
button: "튜토리얼 보기"
|
||||
button_path: "/ko/docs/tutorials"
|
||||
- name: setup
|
||||
title: "클러스터 구축하기"
|
||||
title: "K8s 클러스터 구축하기"
|
||||
description: "보유한 자원과 요구에 맞게 동작하는 쿠버네티스를 구축한다."
|
||||
button: "쿠버네티스 구축하기"
|
||||
button_path: "/ko/docs/setup"
|
||||
|
|
@ -55,7 +55,7 @@ cards:
|
|||
button: 문서에 기여하기
|
||||
button_path: "/ko/docs/contribute"
|
||||
- name: release-notes
|
||||
title: 릴리스 노트
|
||||
title: K8s 릴리스 노트
|
||||
description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다.
|
||||
button: "쿠버네티스 다운로드"
|
||||
button_path: "/docs/setup/release/notes"
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ API 서버 인가를 외부 서비스에 노출시킨다.
|
|||
* `LocalSubjectAccessReview` - `SubjectAccessReview`와 비슷하지만 특정 네임스페이스로 제한된다.
|
||||
* `SelfSubjectRulesReview` - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.
|
||||
|
||||
이러한 API는 반환된 객체의 응답 "status" 필드가 쿼리의 결과인
|
||||
이러한 API는 반환된 오브젝트의 응답 "status" 필드가 쿼리의 결과인
|
||||
일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -18,95 +18,105 @@ weight: 50
|
|||
쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
|
||||
구분한다.
|
||||
|
||||
- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
|
||||
위한 것이다.
|
||||
- 사용자 어카운트는 전역을 대상으로 고려된다.
|
||||
클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 하며, 향후 사용자 리소스는 네임스페이스에 할당되지 않는다.
|
||||
서비스 어카운트는 네임스페이스에 할당된다.
|
||||
- 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
|
||||
여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
|
||||
서비스 어카운트 생성은
|
||||
클러스터 사용자가 특정 작업(즉, 최소 권한 원칙)을 위한 서비스 어카운트를 만들 수 있도록
|
||||
보다 가볍게 만들어졌다.
|
||||
- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
|
||||
- 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
|
||||
서비스 어카운트는 임시(ad-hoc)로 만들 수도 있고 네임스페이스에 할당된 이름을 가질 수도 있기 때문에
|
||||
이러한 설정은 이식성이 좋다.
|
||||
- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
|
||||
위한 것이다.
|
||||
- 사용자 어카운트는 전역을 대상으로 고려된다.
|
||||
클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다.
|
||||
- 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
|
||||
여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
|
||||
서비스 어카운트 생성은
|
||||
클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록
|
||||
보다 가볍게 만들어졌다.
|
||||
- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
|
||||
- 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
|
||||
서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에
|
||||
이러한 설정은 이식성이 좋다.
|
||||
|
||||
## 서비스 어카운트 자동화
|
||||
|
||||
서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.
|
||||
|
||||
- 서비스 어카운트 어드미션 컨트롤러
|
||||
- 토큰 컨트롤러
|
||||
- 서비스 어카운트 컨트롤러
|
||||
- `ServiceAccount` 어드미션 컨트롤러
|
||||
- 토큰 컨트롤러
|
||||
- `ServiceAccount` 컨트롤러
|
||||
|
||||
### 서비스 어카운트 어드미션 컨트롤러
|
||||
### 서비스어카운트(ServiceAccount) 어드미션 컨트롤러
|
||||
|
||||
파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
라는 플러그인을 통해 구현된다. 이것은 apiserver의 일부이다.
|
||||
파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는
|
||||
플러그인을 통해 구현된다.
|
||||
이것은 API 서버의 일부이다.
|
||||
파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
|
||||
이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
|
||||
|
||||
1. 파드에 `ServiceAccount`가 없다면 `ServiceAccount`를 `default`로 설정한다.
|
||||
1. 파드에 참조되는 `ServiceAccount`가 있도록 하고, 그렇지 않으면 이를 거부한다.
|
||||
1. 파드에 `ImagePullSecrets`이 없는 경우 `ServiceAccount`의 `ImagePullSecrets`이 파드에 추가된다.
|
||||
1. 파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
|
||||
1. `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 파드의 각 컨테이너에 `volumeSource`를 추가한다.
|
||||
1. 파드에 `serviceAccountName`가 없다면, `serviceAccountName`를
|
||||
`default`로 설정한다.
|
||||
1. 파드에 참조되는 `serviceAccountName`가 있도록 하고, 그렇지 않으면
|
||||
이를 거부한다.
|
||||
1. 파드에 `imagePullSecrets`이 없는 경우, 서비스어카운트의
|
||||
`imagePullSecrets`이 파드에 추가된다.
|
||||
1. 서비스어카운트 `automountServiceAccountToken` 또는 파드의
|
||||
`automountServiceAccountToken` 이 `false` 로 설정되지 않은 경우
|
||||
파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
|
||||
1. 이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우,
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된
|
||||
파드의 각 컨테이너에 `volumeSource`를 추가한다.
|
||||
|
||||
v1.13부터 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
|
||||
`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
|
||||
서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
|
||||
[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참조한다.
|
||||
[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한
|
||||
자세한 내용을 참조한다.
|
||||
|
||||
### 토큰 컨트롤러
|
||||
|
||||
토큰컨트롤러는 컨트롤러 매니저의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
|
||||
토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
|
||||
|
||||
- 서비스 어카운트 생성을 지켜보고 API에 접근할 수 있는 시크릿을 생성한다.
|
||||
- 서비스 어카운트 삭제를 지켜보고 해당하는 모든 서비스 어카운트 토큰 시크릿을 삭제한다.
|
||||
- 시크릿 추가를 지켜보고 참조된 서비스 어카운트가 존재하는지 확인하고 필요한 경우 시크릿에 토큰을 추가한다.
|
||||
- 시크릿 삭제를 지켜보고 필요한 경우 해당 서비스 어카운트에서 참조를 제거한다.
|
||||
- 서비스어카운트 생성을 감시하고 API에 접근할 수 있는 해당
|
||||
서비스어카운트 토큰 시크릿을 생성한다.
|
||||
- 서비스어카운트 삭제를 감시하고 해당하는 모든 서비스어카운트
|
||||
토큰 시크릿을 삭제한다.
|
||||
- 서비스어카운트 토큰 시크릿 추가를 감시하고, 참조된 서비스어카운트가
|
||||
존재하는지 확인하고, 필요한 경우 시크릿에 토큰을 추가한다.
|
||||
- 시크릿 삭제를 감시하고 필요한 경우 해당 서비스어카운트에서
|
||||
참조를 제거한다.
|
||||
|
||||
서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 옵션을 사용하여 컨트롤러 매니저의 토큰 컨트롤러에 전달해야 한다.
|
||||
개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
|
||||
마찬가지로 `--service-account-key-file` 옵션을 사용하여 해당 공개키를 쿠버네티스 API 서버에 전달해야 한다.
|
||||
공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다.
|
||||
서비스 어카운트 개인키 파일은 `--service-account-private-key-file`
|
||||
플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야
|
||||
한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
|
||||
마찬가지로 `--service-account-key-file` 플래그를 사용하여 해당 공개키를
|
||||
`kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을
|
||||
검증하는 데 사용될 것이다.
|
||||
|
||||
#### 추가적인 API 토큰 생성
|
||||
|
||||
컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스 어카운트에 존재하도록 보장한다.
|
||||
서비스 어카운트에 대한 추가적인 API 토큰을 생성하기 위해
|
||||
서비스 어카운트를 참조하는 어노테이션과 함께 `ServiceAccountToken` 유형의 시크릿을 생성하면
|
||||
컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다.
|
||||
서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해
|
||||
서비스어카운트를 참조하는 어노테이션과 함께 `kubernetes.io/service-account-token` 유형의 시크릿을 생성하면
|
||||
컨트롤러가 새로 생성된 토큰으로 갱신한다.
|
||||
|
||||
secret.json:
|
||||
다음은 시크릿에 대한 샘플 구성이다.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Secret",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "mysecretname",
|
||||
"annotations": {
|
||||
"kubernetes.io/service-account.name": "myserviceaccount"
|
||||
}
|
||||
},
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecretname
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: myserviceaccount
|
||||
type: kubernetes.io/service-account-token
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl create -f ./secret.json
|
||||
kubectl create -f ./secret.yaml
|
||||
kubectl describe secret mysecretname
|
||||
```
|
||||
|
||||
#### 서비스 어카운트 토큰 삭제/무효화
|
||||
#### 서비스 어카운트 토큰 시크릿 삭제/무효화
|
||||
|
||||
```shell
|
||||
kubectl delete secret mysecretname
|
||||
```
|
||||
|
||||
### 서비스 어카운트 컨트롤러
|
||||
### 서비스어카운트 컨트롤러
|
||||
|
||||
서비스 어카운트 컨트롤러는 네임스페이스에 있는 서비스 어카운트를 관리하고
|
||||
"default"라는 이름의 서비스 어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
|
||||
서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고
|
||||
"default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
|
||||
|
|
|
|||
|
|
@ -83,8 +83,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | |
|
||||
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | |
|
||||
| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
|
||||
| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 |
|
||||
| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | |
|
||||
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | |
|
||||
| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
|
||||
| `DevicePlugins` | `true` | 베타 | 1.10 | |
|
||||
|
|
@ -137,12 +135,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `RuntimeClass` | `true` | 베타 | 1.14 | |
|
||||
| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
|
||||
| `SCTPSupport` | `true` | 베타 | 1.19 | |
|
||||
| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
|
||||
| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
|
||||
| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
|
||||
| `ServerSideApply` | `true` | 베타 | 1.16 | |
|
||||
| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
|
||||
| `ServiceAppProtocol` | `false` | 알파 | 1.18 | |
|
||||
| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
|
||||
| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
|
||||
| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
|
||||
| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
|
||||
| `ServiceTopology` | `false` | 알파 | 1.17 | |
|
||||
|
|
@ -209,6 +206,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 |
|
||||
| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 |
|
||||
| `CustomPodDNS` | `true` | GA | 1.14 | - |
|
||||
| `CustomResourceDefaulting` | `false` | 알파 | 1.15 | 1.15 |
|
||||
| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | 1.16 |
|
||||
| `CustomResourceDefaulting` | `true` | GA | 1.17 | - |
|
||||
| `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 |
|
||||
| `CustomResourcePublishOpenAPI` | `true` | 베타| 1.15 | 1.15 |
|
||||
| `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: API 그룹(API Group)
|
||||
id: api-group
|
||||
date: 2019-09-02
|
||||
full_link: /ko/docs/concepts/overview/kubernetes-api/#api-groups
|
||||
short_description: >
|
||||
쿠버네티스 API의 연관된 경로들의 집합.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- architecture
|
||||
---
|
||||
쿠버네티스 API의 연관된 경로들의 집합.
|
||||
|
||||
<!--more-->
|
||||
API 서버의 구성을 변경하여 각 API 그룹을 활성화하거나 비활성화할 수 있다. 특정 리소스에 대한 경로를 비활성화하거나 활성화할 수도 있다. API 그룹을 사용하면 쿠버네티스 API를 더 쉽게 확장할 수 있다. API 그룹은 REST 경로 및 직렬화된 오브젝트의 `apiVersion` 필드에 지정된다.
|
||||
|
||||
* 자세한 내용은 [API 그룹(/ko/docs/concepts/overview/kubernetes-api/#api-groups)을 참조한다.
|
||||
|
|
@ -3,18 +3,18 @@ title: 미러 파드(Mirror Pod)
|
|||
id: mirror-pod
|
||||
date: 2019-08-06
|
||||
short_description: >
|
||||
Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 객체.
|
||||
Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 오브젝트.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Kubelet이 {{< glossary_tooltip text="스태틱 파드" term_id="static-pod" >}}를
|
||||
표현하는 {{< glossary_tooltip text="파드" term_id="pod" >}} 객체
|
||||
표현하는 {{< glossary_tooltip text="파드" term_id="pod" >}} 오브젝트
|
||||
|
||||
<!--more-->
|
||||
Kubelet이 설정에서 스태틱 파드를 찾으면, 자동으로 쿠버네티스
|
||||
API 서버에 파드 객체 생성을 시도한다. 이렇게 생성된 파드를
|
||||
API 서버에 파드 오브젝트 생성을 시도한다. 이렇게 생성된 파드를
|
||||
API 서버에서 확인할 수는 있지만, API 서버를 통해 제어할 수는 없다.
|
||||
|
||||
(예를 들어, 미러 파드를 제거하더라도 kubelet 데몬이 해당 파드를 멈추지 않는다.)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: 오브젝트(Object)
|
||||
id: object
|
||||
date: 2020-12-1
|
||||
full_link: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
|
||||
short_description: >
|
||||
클러스터 상태의 일부를 나타내는 쿠버네티스 시스템의 엔티티이다.
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
쿠버네티스 시스템의 엔티티이다. 쿠버네티스 API가 클러스터의 상태를 나타내기 위해
|
||||
사용하는 엔티티이다.
|
||||
<!--more-->
|
||||
쿠버네티스 오브젝트는 일반적으로 "의도를 담은 레코드"이다. 당신이 오브젝트를 생성하게 되면, 쿠버네티스
|
||||
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 그 아이템이 실제 존재함을 보장하기 위해
|
||||
지속적으로 작동한다.
|
||||
객체를 생성함으로써 당신의 클러스터의 워크로드 해당 부분이 어떻게 보이길 원하는지 쿠버네티스 시스템에 효과적으로 알리는 것이다.
|
||||
이것은 당신의 클러스터의 의도한 상태이다.
|
||||
|
|
@ -14,5 +14,5 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록 상 유사한 개체의 출현을 서로 구분하기 위함이다.
|
||||
쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록상 유사한 오브젝트의 출현을 서로 구분하기 위함이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -86,6 +86,13 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성
|
|||
kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
|
||||
kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성
|
||||
kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작
|
||||
|
||||
# "Hello World"를 출력하는 잡(Job) 생성
|
||||
kubectl create job hello --image=busybox -- echo "Hello World"
|
||||
|
||||
# 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성
|
||||
kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello World"
|
||||
|
||||
kubectl explain pods # 파드 매니페스트 문서를 조회
|
||||
|
||||
# stdin으로 다수의 YAML 오브젝트 생성
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
* 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>`
|
||||
|
||||
* YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).<br/>
|
||||
예: `kubectl get pod -f ./pod.yaml`
|
||||
예: `kubectl get -f ./pod.yaml`
|
||||
|
||||
* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.<br/>
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,101 @@
|
|||
---
|
||||
title: 쿠버네티스 API 헬스(health) 엔드포인트
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
쿠버네티스 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}는 현재 상태를 나타내는 API 엔드포인트를 제공한다.
|
||||
이 페이지에서는 API 엔드포인트들에 대해 설명하고 이를 사용하는 방법을 다룬다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 헬스를 위한 API 엔드포인트
|
||||
|
||||
쿠버네티스 API 서버는 현재 상태를 나타내는 세 가지 API 엔드포인트(`healthz`, `livez` 와 `readyz`)를 제공한다.
|
||||
`healthz` 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스 v1.16 버전 이후), 대신 보다 구체적인 `livez` 와 `readyz` 엔드포인트를 사용해야 한다.
|
||||
`livez` 엔드포인트는 `--livez-grace-period` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 시작 대기 시간을 지정할 수 있다.
|
||||
`/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다.
|
||||
API 서버의 `health`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다.
|
||||
상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다.
|
||||
아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다.
|
||||
|
||||
다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.
|
||||
|
||||
모든 엔드포인트는 `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다.
|
||||
이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.
|
||||
|
||||
```shell
|
||||
curl -k https://localhost:6443/livez?verbose
|
||||
```
|
||||
|
||||
인증을 사용하는 원격 호스트에서 사용할 경우에는 다음과 같이 수행한다.
|
||||
|
||||
```shell
|
||||
kubectl get --raw='/readyz?verbose'
|
||||
```
|
||||
|
||||
출력은 다음과 같다.
|
||||
|
||||
[+]ping ok
|
||||
[+]log ok
|
||||
[+]etcd ok
|
||||
[+]poststarthook/start-kube-apiserver-admission-initializer ok
|
||||
[+]poststarthook/generic-apiserver-start-informers ok
|
||||
[+]poststarthook/start-apiextensions-informers ok
|
||||
[+]poststarthook/start-apiextensions-controllers ok
|
||||
[+]poststarthook/crd-informer-synced ok
|
||||
[+]poststarthook/bootstrap-controller ok
|
||||
[+]poststarthook/rbac/bootstrap-roles ok
|
||||
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
|
||||
[+]poststarthook/start-cluster-authentication-info-controller ok
|
||||
[+]poststarthook/start-kube-aggregator-informers ok
|
||||
[+]poststarthook/apiservice-registration-controller ok
|
||||
[+]poststarthook/apiservice-status-available-controller ok
|
||||
[+]poststarthook/kube-apiserver-autoregistration ok
|
||||
[+]autoregister-completion ok
|
||||
[+]poststarthook/apiservice-openapi-controller ok
|
||||
healthz check passed
|
||||
|
||||
또한 쿠버네티스 API 서버는 특정 체크를 제외할 수 있다.
|
||||
쿼리 파라미터는 다음 예와 같이 조합될 수 있다.
|
||||
|
||||
```shell
|
||||
curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
|
||||
```
|
||||
|
||||
출력에서 etcd 체크가 제외된 것을 보여준다.
|
||||
|
||||
[+]ping ok
|
||||
[+]log ok
|
||||
[+]etcd excluded: ok
|
||||
[+]poststarthook/start-kube-apiserver-admission-initializer ok
|
||||
[+]poststarthook/generic-apiserver-start-informers ok
|
||||
[+]poststarthook/start-apiextensions-informers ok
|
||||
[+]poststarthook/start-apiextensions-controllers ok
|
||||
[+]poststarthook/crd-informer-synced ok
|
||||
[+]poststarthook/bootstrap-controller ok
|
||||
[+]poststarthook/rbac/bootstrap-roles ok
|
||||
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
|
||||
[+]poststarthook/start-cluster-authentication-info-controller ok
|
||||
[+]poststarthook/start-kube-aggregator-informers ok
|
||||
[+]poststarthook/apiservice-registration-controller ok
|
||||
[+]poststarthook/apiservice-status-available-controller ok
|
||||
[+]poststarthook/kube-apiserver-autoregistration ok
|
||||
[+]autoregister-completion ok
|
||||
[+]poststarthook/apiservice-openapi-controller ok
|
||||
[+]shutdown ok
|
||||
healthz check passed
|
||||
|
||||
## 개별 헬스 체크
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
|
||||
개별 체크를 위한 스키마는 `/livez/<healthcheck-name>` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
|
||||
`<healthcheck-name>` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
|
||||
이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.
|
||||
|
||||
```shell
|
||||
curl -k https://localhost:6443/livez/etcd
|
||||
```
|
||||
|
|
@ -1,122 +1,120 @@
|
|||
---
|
||||
title: 대형 클러스터 구축
|
||||
title: 대형 클러스터에 대한 고려 사항
|
||||
weight: 20
|
||||
---
|
||||
|
||||
## 지원
|
||||
|
||||
{{< param "version" >}} 버전에서, 쿠버네티스는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는, 다음 기준을 *모두* 만족하는 설정을 지원한다.
|
||||
클러스터는 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에서 관리하는
|
||||
쿠버네티스 에이전트를 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}(물리
|
||||
또는 가상 머신)의 집합이다.
|
||||
쿠버네티스 {{<param "version">}}는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는,
|
||||
쿠버네티스는 다음 기준을 *모두* 만족하는 설정을 수용하도록 설계되었다.
|
||||
|
||||
* 노드 당 파드 100 개 이하
|
||||
* 노드 5000개 이하
|
||||
* 전체 파드 150000개 이하
|
||||
* 전체 컨테이너 300000개 이하
|
||||
* 노드 당 파드 100개 이하
|
||||
|
||||
노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은
|
||||
클러스터 배포 방법에 따라 다르다.
|
||||
|
||||
## 설치
|
||||
## 클라우드 프로바이더 리소스 쿼터 {#quota-issues}
|
||||
|
||||
클러스터는 쿠버네티스 에이전트가 구동하는 노드(물리 또는 가상 머신)의 집합이며, "마스터"(클러스터-수준 컨트롤 플레인)에 의해 관리된다.
|
||||
여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해
|
||||
고려할 점은 다음과 같다.
|
||||
|
||||
보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다.
|
||||
|
||||
하지만 단순히 값만 매우 크게 바꾼다면, 클라우드 프로바이더에 따라 셋업 스크립트가 실패할 수도 있다. 예를 들어, GCE에 배포할 때 쿼터 이슈가 발생하여 클러스터 구축이 실패할 수 있다.
|
||||
|
||||
큰 쿠버네티스 클러스터를 설정할 때는 다음 이슈들을 고려해야 한다.
|
||||
|
||||
### 쿼터 문제
|
||||
|
||||
여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해 고려할 점:
|
||||
|
||||
* CPU, IP 등의 쿼터를 늘린다.
|
||||
* 예를 들어, [GCE의 경우](https://cloud.google.com/compute/docs/resource-quotas) 다음에 관한 쿼터를 늘릴 수 있다.
|
||||
* 다음과 같은 클라우드 리소스에 대한 쿼터 증가를 요청한다.
|
||||
* 컴퓨터 인스턴스
|
||||
* CPU
|
||||
* VM 인스턴스
|
||||
* 전체 영구 디스크 예약
|
||||
* 스토리지 볼륨
|
||||
* 사용 중인 IP 주소
|
||||
* 방화벽 규칙
|
||||
* 포워딩 규칙
|
||||
* 라우트
|
||||
* 대상 풀
|
||||
* 일부 클라우드 프로바이더는 VM 생성 속도에 상한이 있어, 셋업 스크립트 수행 간 새로운 노드 VM을 생성하는 사이사이에 대기시간이 추가되는 작은 배치가 걸릴 수 있다.
|
||||
* 패킷 필터링 규칙 세트
|
||||
* 로드밸런서 개수
|
||||
* 로그 스트림
|
||||
* 일부 클라우드 프로바이더는 새로운 인스턴스 생성 속도에 상한이 있어, 클러스터 확장 작업 간 새로운 노드를 일괄적으로 배치하고, 배치 간에 일시 중지한다.
|
||||
|
||||
## 컨트롤 플레인 컴포넌트
|
||||
|
||||
대규모 클러스터의 경우, 충분한 컴퓨트 및 기타 리소스가 있는 컨트롤 플레인이
|
||||
필요하다.
|
||||
|
||||
일반적으로 장애 영역 당 하나 또는 두 개의 컨트롤 플레인 인스턴스를
|
||||
실행하고, 해당 인스턴스를 수직으로(vertically) 먼저 확장한 다음 (수직) 규모로 하락하는
|
||||
지점에 도달한 후 수평으로(horizontally) 확장한다.
|
||||
|
||||
내결함성을 제공하려면 장애 영역 당 하나 이상의 인스턴스를 실행해야 한다. 쿠버네티스
|
||||
노드는 동일한 장애 영역에 있는 컨트롤 플레인 엔드포인트로 트래픽을
|
||||
자동으로 조정하지 않는다. 그러나, 클라우드 프로바이더는 이를 수행하기 위한 자체 메커니즘을 가지고 있을 수 있다.
|
||||
|
||||
예를 들어, 관리형 로드 밸런서를 사용하여 장애 영역 _A_ 의
|
||||
kubelet 및 파드에서 시작되는 트래픽을 전송하도록 로드 밸런서를 구성하고, 해당 트래픽을
|
||||
_A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일 컨트롤 플레인 호스트 또는
|
||||
엔드포인트 장애 영역 _A_ 이 오프라인이 되면, 영역 _A_ 의 노드에 대한
|
||||
모든 컨트롤 플레인 트래픽이 이제 영역간에 전송되고 있음을 의미한다. 각 영역에서 여러 컨트롤 플레인 호스트를
|
||||
실행하면 가용성이 낮아진다.
|
||||
|
||||
### etcd 저장소
|
||||
|
||||
큰 클러스터의 성능 향상을 위해, 우리는 이벤트를 각각의 전용 etcd 인스턴스에 저장한다.
|
||||
큰 클러스터의 성능 향상을 위해, 사용자는 이벤트 오브젝트를 각각의
|
||||
전용 etcd 인스턴스에 저장한다.
|
||||
|
||||
클러스터 생성시의 부가 스트립트이다.
|
||||
클러스터 생성 시에 (사용자 도구를 사용하여) 다음을 수행할 수 있다.
|
||||
|
||||
* 추가 ectd 인스턴스 시작 및 설정
|
||||
* 이벤트를 저장하기 위한 api-server 설정
|
||||
* 이벤트를 저장하기 위한 {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} 설정
|
||||
|
||||
### 마스터 크기와 마스터 구성 요소
|
||||
## 애드온 리소스
|
||||
|
||||
GCE/구글 쿠버네티스 엔진 및 AWS에서, `kube-up`은 클러스터 내 노드의 수에 따라 마스터용으로 적합한 VM 크기를 자동으로 설정한다.
|
||||
기타 다른 프로바이더의 경우, 수동으로 설정해야 한다. 참고로 GCE에 적용하는 크기는 다음과 같다.
|
||||
쿠버네티스 [리소스 제한](/ko/docs/concepts/configuration/manage-resources-containers/)은
|
||||
파드와 컨테이너가 다른 컴포넌트에 영향을 줄 수 있는 메모리 누수 및 기타 방식의 영향을
|
||||
최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용되는 것과 마찬가지로
|
||||
{{< glossary_tooltip text="애드온" term_id="addons" >}}에도 적용될 수 있으며
|
||||
적용되어야 한다.
|
||||
|
||||
* 1-5 노드: n1-standard-1
|
||||
* 6-10 노드: n1-standard-2
|
||||
* 11-100 노드: n1-standard-4
|
||||
* 101-250 노드: n1-standard-8
|
||||
* 251-500 노드: n1-standard-16
|
||||
* 500 노드 이상: n1-standard-32
|
||||
|
||||
AWS에 적용하는 크기는 다음과 같다.
|
||||
|
||||
* 1-5 노드: m3.medium
|
||||
* 6-10 노드: m3.large
|
||||
* 11-100 노드: m3.xlarge
|
||||
* 101-250 노드: m3.2xlarge
|
||||
* 251-500 노드: c4.4xlarge
|
||||
* 500 노드 이상: c4.8xlarge
|
||||
|
||||
{{< note >}}
|
||||
구글 쿠버네티스 엔진에서, 마스터 노드 크기는 클러스터의 크기에 따라 자동적으로 조절된다. 자세한 사항은 [이 블로그 글](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html)을 참고하라.
|
||||
|
||||
AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된 그대로이며 변경되지 않는다. 이후에 클러스터를 스케일 업/다운하거나 수동으로 노드를 추가/제거하거나 클러스터 오토스케일러를 사용하더라도 그렇다.
|
||||
{{< /note >}}
|
||||
|
||||
### 애드온 자원
|
||||
|
||||
[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](https://pr.k8s.io/10653/files)과 [#10778](https://pr.k8s.io/10778/files) 참고).
|
||||
|
||||
예시:
|
||||
예를 들어, 로깅 컴포넌트에 대한 CPU 및 메모리 제한을 설정할 수 있다.
|
||||
|
||||
```yaml
|
||||
...
|
||||
containers:
|
||||
- name: fluentd-cloud-logging
|
||||
image: k8s.gcr.io/fluentd-gcp:1.16
|
||||
image: fluent/fluentd-kubernetes-daemonset:v1
|
||||
resources:
|
||||
limits:
|
||||
cpu: 100m
|
||||
memory: 200Mi
|
||||
```
|
||||
|
||||
힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](https://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](https://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다.
|
||||
애드온의 기본 제한은 일반적으로 중소형 쿠버네티스 클러스터에서
|
||||
각 애드온을 실행한 경험에서 수집된 데이터를 기반으로 한다. 대규모 클러스터에서
|
||||
실행할 때, 애드온은 종종 기본 제한보다 많은 리소스를 소비한다.
|
||||
이러한 값을 조정하지 않고 대규모 클러스터를 배포하면, 애드온이
|
||||
메모리 제한에 계속 도달하기 때문에 지속적으로 종료될 수 있다.
|
||||
또는, 애드온이 실행될 수 있지만 CPU 시간 슬라이스 제한으로 인해
|
||||
성능이 저하된다.
|
||||
|
||||
많은 노드를 가진 클러스터를 생성할 때는 애드온 리소스 이슈를 피하기 위해 다음을 고려하라.
|
||||
클러스터 애드온 리소스 문제가 발생하지 않도록, 노드가 많은 클러스터를
|
||||
만들 때, 다음 사항을 고려한다.
|
||||
|
||||
* 다음 애드온을 사용한다면, 클러스터의 크기를 확장할 때 그에 맞게 메모리와 CPU 상한을 규모를 조정하라 (전체 클러스터를 담당하는 각 레플리카는, 메모리와 CPU 사용량이 대체로 클러스터의 크기/부하에 따라 비율적으로 증가할 것이다).
|
||||
* [InfluxDB와 Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
|
||||
* [kubedns, dnsmasq, 사이드카](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
|
||||
* [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
|
||||
* 다음 애드온들을 쓴다면 클러스터 크기에 따라 레플리카 수를 조절해준다(각각 레플리카가 여러 개 두면 늘어나는 부하를 처리하는 데 도움이 되지만, 레플리카 당 부하도 약간 늘어나게 되므로 CPU/메모리 상한을 높이는 것을 고려해보자):
|
||||
* [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
|
||||
* 다음의 애드온들을 쓴다면, 클러스터 크기에 따라 각각 메모리와 CPU 상한을 조금 더 높이자(노드 당 레플리카 1개만 있어도 클러스터 부하량/크기에 따라 CPU/메모리 사용율은 조금씩 증가한다).
|
||||
* [ElasticSearch 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
|
||||
* [GCP 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
|
||||
* 일부 애드온은 수직으로 확장된다. 클러스터 또는 전체 장애 영역을
|
||||
제공하는 애드온 레플리카가 하나 있다. 이러한 애드온의 경우, 클러스터를 확장할 때
|
||||
요청과 제한을 늘린다.
|
||||
* 많은 애드온은 수평으로 확장된다. 더 많은 파드를 실행하여 용량을 추가하지만,
|
||||
매우 큰 클러스터에서는 CPU 또는 메모리 제한을 약간 높여야 할 수도 있다.
|
||||
VerticalPodAutoscaler는 _recommender_ 모드에서 실행되어 요청 및 제한에 대한
|
||||
제안 수치를 제공할 수 있다.
|
||||
* 일부 애드온은 {{< glossary_tooltip text="데몬셋(DaemonSet)"
|
||||
term_id="daemonset" >}}에 의해 제어되는 노드 당 하나의 복사본으로 실행된다(예: 노드 수준 로그 수집기). 수평
|
||||
확장 애드온의 경우와 유사하게, CPU 또는 메모리 제한을 약간 높여야
|
||||
할 수도 있다.
|
||||
|
||||
힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](https://issue.k8s.io/16185)과
|
||||
[#22940](https://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면,
|
||||
힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자.
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는
|
||||
[컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라.
|
||||
`VerticalPodAutoscaler` 는 리소스 요청 및 파드 제한을 관리하는 데 도움이 되도록
|
||||
클러스터에 배포할 수 있는 사용자 정의 리소스이다.
|
||||
클러스터에 중요한 애드온을 포함하여 클러스터 컴포넌트를 확장하는 방법에 대한
|
||||
자세한 내용은 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)를
|
||||
방문하여 배워본다.
|
||||
|
||||
### 시작 시 사소한 노드 오류 허용
|
||||
|
||||
다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고
|
||||
`kube-up.sh`을 실행하면 제대로 기동되지 않은 극소수의 노드들 때문에 실패할 수 있다.
|
||||
현재로서는 두 가지 선택지가 있다. 클러스터를 재시작하거나(`kube-down.sh` 한 후 다시 `kube-up.sh` ),
|
||||
`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다.
|
||||
이렇게 하면 `NUM_NODES`에 못 미치는 경우에도 `kube-up.sh`이 성공할 수 있다.
|
||||
실패 원인에 따라 일부 노드들이 늦게 결합되거나, 클러스터가 `NUM_NODES - ALLOWED_NOTREADY_NODES`의 크기로 남을 수 있다.
|
||||
[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는
|
||||
여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
|
||||
노드 수를 실행할 수 있도록 도와준다.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,11 @@ weight: 30
|
|||
|
||||
노드 적합성 테스트는 다음 순서로 진행된다.
|
||||
|
||||
1. 테스트 프레임워크는 Kublet을 테스트하기 위해 로컬 마스터를 시작하기 때문에, Kublet이 localhost를 가르키도록 `--api-servers="http://localhost:8080"`를 사용한다. 고려해야 할 다른 Kubelet 플래그들은 다음과 같다.
|
||||
1. kubelet에 대한 `--kubeconfig` 옵션의 값을 계산한다. 예를 들면, 다음과 같다.
|
||||
`--kubeconfig = / var / lib / kubelet / config.yaml`.
|
||||
테스트 프레임워크는 kubelet을 테스트하기 위해 로컬 컨트롤 플레인을 시작하기 때문에,
|
||||
`http://localhost:8080` 을 API 서버의 URL로 사용한다.
|
||||
사용할 수 있는 kubelet 커맨드 라인 파라미터가 몇 개 있다.
|
||||
* `--pod-cidr`: `kubenet`을 사용 중이라면, 임의의 CIDR을 Kubelet에 지정해주어야 한다. 예) `--pod-cidr=10.180.0.0/24`.
|
||||
* `--cloud-provider`: `--cloud-provider=gce`를 사용 중이라면, 테스트 실행 시에는 제거해야 한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: 컨테이너 런타임
|
||||
content_type: concept
|
||||
weight: 10
|
||||
weight: 20
|
||||
---
|
||||
<!-- overview -->
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
title: 턴키 클라우드 솔루션
|
||||
weight: 30
|
||||
---
|
||||
|
|
@ -0,0 +1,154 @@
|
|||
---
|
||||
title: 쿠버네티스 버전 및 버전 차이(skew) 지원 정책
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
이 문서는 다양한 쿠버네티스 구성 요소 간에 지원되는 최대 버전 차이를 설명한다.
|
||||
특정 클러스터 배포 도구는 버전 차이에 대한 추가적인 제한을 설정할 수 있다.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 지원되는 버전
|
||||
|
||||
쿠버네티스 버전은 **x.y.z**로 표현되는데,
|
||||
여기서 **x**는 메이저 버전, **y**는 마이너 버전, **z**는 [시맨틱 버전](https://semver.org/) 용어에 따른 패치 버전이다.
|
||||
자세한 내용은 [쿠버네티스 릴리스 버전](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)을 참조한다.
|
||||
|
||||
쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
|
||||
|
||||
보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다.
|
||||
패치 릴리스는 각 브랜치별로 [정기적인 주기](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다.
|
||||
|
||||
[릴리스 관리자](https://git.k8s.io/sig-release/release-managers.md) 그룹이 이러한 결정 권한을 가진다.
|
||||
|
||||
자세한 내용은 쿠버네티스 [패치 릴리스](https://git.k8s.io/sig-release/releases/patch-releases.md) 페이지를 참조한다.
|
||||
|
||||
## 지원되는 버전 차이
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
[고가용성(HA) 클러스터](/docs/setup/production-environment/tools/kubeadm/high-availability/)에서 최신 및 가장 오래된 `kube-apiserver` 인스턴스가 각각 한 단계 마이너 버전 내에 있어야 한다.
|
||||
|
||||
예:
|
||||
|
||||
* 최신 `kube-apiserver`는 **{{< skew latestVersion >}}** 이다.
|
||||
* 다른 `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 을 지원한다.
|
||||
|
||||
### kubelet
|
||||
|
||||
`kubelet`은 `kube-apiserver`보다 최신일 수 없으며, 2단계의 낮은 마이너 버전까지 지원한다.
|
||||
|
||||
예:
|
||||
|
||||
* `kube-apiserver`가 **{{< skew latestVersion >}}** 이다.
|
||||
* `kubelet`은 **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}** 및 **{{< skew oldestMinorVersion >}}** 을 지원한다.
|
||||
|
||||
{{< note >}}
|
||||
HA 클러스터의 `kube-apiserver` 인스턴스 사이에 버전 차이가 있으면 허용되는 `kubelet` 버전의 범위도 줄어든다.
|
||||
{{</ note >}}
|
||||
|
||||
예:
|
||||
|
||||
* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다.
|
||||
* `kubelet`은 **{{< skew prevMinorVersion >}}** 및 **{{< skew oldestMinorVersion >}}** 을 지원한다(**{{< skew latestVersion >}}** 는 `kube-apiserver`의 **{{< skew prevMinorVersion >}}** 인스턴스보다 최신 버전이기 때문에 지원하지 않는다).
|
||||
|
||||
### kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager
|
||||
|
||||
`kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 그들과 통신하는 `kube-apiserver` 인스턴스보다 최신 버전이면 안 된다. `kube-apiserver` 마이너 버전과 일치할 것으로 예상하지만, 최대 한 단계 낮은 마이너 버전까지는 허용한다(실시간 업그레이드를 지원하기 위해서).
|
||||
|
||||
예:
|
||||
|
||||
* `kube-apiserver`은 **{{< skew latestVersion >}}** 이다.
|
||||
* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 **{{< skew latestVersion >}}** 과 **{{< skew prevMinorVersion >}}** 을 지원한다.
|
||||
|
||||
{{< note >}}
|
||||
HA 클러스터의 `kube-apiserver` 인스턴스 간에 버전 차이가 존재하고 이러한 구성 요소가 클러스터의 모든 `kube-apiserver` 인스턴스와 통신할 수 있는 경우(예를 들어, 로드 밸런서를 통해서)에는 구성 요소의 허용하는 버전의 범위도 줄어든다.
|
||||
{{< /note >}}
|
||||
|
||||
예:
|
||||
|
||||
* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다.
|
||||
* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 모든 `kube-apiserver` 인스턴스로 라우팅하는 로드 밸런서와 통신한다.
|
||||
* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 **{{< skew prevMinorVersion >}}** 에서 지원한다(**{{< skew latestVersion >}}** 는 `kube-apiserver` 인스턴스의 **{{< skew prevMinorVersion >}}** 버전보다 최신이기 때문에 지원하지 않는다).
|
||||
|
||||
### kubectl
|
||||
|
||||
`kubectl`은 `kube-apiserver`의 한 단계 마이너 버전(이전 또는 최신) 내에서 지원한다.
|
||||
|
||||
예:
|
||||
|
||||
* `kube-apiserver`은 **{{< skew latestVersion >}}** 이다.
|
||||
* `kubectl`은 **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 을 지원한다.
|
||||
|
||||
{{< note >}}
|
||||
HA 클러스터의 `kube-apiserver` 인스턴스 간에 버전 차이가 있으면 지원되는 `kubectl` 버전의 범위도 줄어든다.
|
||||
{{< /note >}}
|
||||
|
||||
예:
|
||||
|
||||
* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다.
|
||||
* `kubectl`은 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 에서 지원한다(다른 버전은 `kube-apiserver` 인스턴스 중에 한 단계 이상의 마이너 버전 차이가 난다).
|
||||
|
||||
## 지원되는 구성 요소 업그레이드 순서
|
||||
|
||||
구성요소 간 지원되는 버전 차이는 구성요소를 업그레이드하는 순서에 영향을 준다.
|
||||
이 섹션에서는 기존 클러스터를 버전 **{{< skew prevMinorVersion >}}** 에서 버전 **{{< skew latestVersion >}}** 로 전환하기 위해 구성 요소를 업그레이드하는 순서를 설명한다.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
사전 요구 사항:
|
||||
|
||||
* 단일 인스턴스 클러스터에서 기존 `kube-apiserver` 인스턴스는 **{{< skew prevMinorVersion >}}** 이어야 한다.
|
||||
* HA 클러스터에서 모든 `kube-apiserver` 인스턴스는 **{{< skew prevMinorVersion >}}** 또는 **{{< skew latestVersion >}}** 이어야 한다(이것은 `kube-apiserver` 인스턴스 간의 가장 최신과 오래된 버전의 차이를 최대 1개의 마이너 버전의 차이로 보장한다).
|
||||
* 이 서버와 통신하는 `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`의 버전은 **{{< skew prevMinorVersion >}}** 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니고 새로운 API서버 버전의 마이너 1개의 버전 내에 있음을 보장한다).
|
||||
* 모든 `kubelet` 인스턴스는 버전 **{{< skew prevMinorVersion >}}** 또는 **{{< skew oldestMinorVersion >}}** 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니며, 새로운 API서버 버전의 2개의 마이너 버전 내에 있음을 보장한다).
|
||||
* 등록된 어드미션 웹훅은 새로운 `kube-apiserver` 인스턴스가 전송하는 데이터를 처리할 수 있다:
|
||||
* `ValidatingWebhookConfiguration` 그리고 `MutatingWebhookConfiguration` 오브젝트는 **{{< skew latestVersion >}}** 에 추가된 REST 리소스의 새 버전을 포함하도록 업데이트한다(또는 v1.15 이상에서 사용 가능한 [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) 설정을 사용).
|
||||
* 웹훅은 자신에게 전송될 REST리소스의 새버전과 **{{< skew latestVersion >}}** 에서 기존 버전에 추가된 새로운 필드를 처리할 수 있다.
|
||||
|
||||
`kube-apiserver`를 **{{< skew latestVersion >}}** 으로 업그레이드
|
||||
|
||||
{{< note >}}
|
||||
[API 지원 중단](/docs/reference/using-api/deprecation-policy/) 및
|
||||
[API 변경 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
|
||||
에 대한 프로젝트 정책에서는 단일 클러스터일지라도 업그레이드할 때 `kube-apiserver`의 마이너 버전을 건너뛰지 않도록 요구한다.
|
||||
{{< /note >}}
|
||||
|
||||
### kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager
|
||||
|
||||
사전 요구 사항:
|
||||
|
||||
* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 이여야 한다(HA 클러스터에서 `kube-apiserver` 인스턴스와 통신할 수 있는 구성 요소를 업그레이드 전에 모든 `kube-apiserver` 인스턴스는 업그레이드되어야 한다).
|
||||
|
||||
`kube-controller-manager`, `kube-scheduler` 및 `cloud-controller-manager` 를 **{{< skew latestVersion >}}** 으로 업그레이드한다.
|
||||
|
||||
### kubelet
|
||||
|
||||
사전 요구 사항:
|
||||
|
||||
* `kubelet`과 통신하는 `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 이어야 한다.
|
||||
|
||||
필요에 따라서 `kubelet` 인스턴스를 **{{< skew latestVersion >}}** 으로 업그레이드할 수 있다(또는 **{{< skew prevMinorVersion >}}** 아니면 **{{< skew oldestMinorVersion >}}** 으로 유지할 수 있음).
|
||||
|
||||
{{< warning >}}
|
||||
클러스터 안의 `kubelet` 인스턴스를 `kube-apiserver`의 버전보다 2단계 낮은 버전으로 실행하는 것을 권장하지 않는다:
|
||||
|
||||
* `kube-apiserver`를 업그레이드한다면 한 단계 낮은 버전으로 업그레이드해야 한다.
|
||||
* 이것은 관리되고 있는 3단계의 마이너 버전보다 낮은 `kubelet`을 실행할 가능성을 높인다.
|
||||
{{</ warning >}}
|
||||
|
||||
### kube-proxy
|
||||
|
||||
* `kube-proxy`는 반드시 `kubelet`과 동일한 마이너 버전이어야 한다.
|
||||
* `kube-proxy`는 반드시 `kube-apiserver` 보다 최신 버전이면 안 된다.
|
||||
* `kube-proxy`는 `kube-apiserver` 보다 2단계 낮은 마이너 버전 이내여야 한다.
|
||||
|
||||
예:
|
||||
|
||||
`kube-proxy` 버전이 **{{< skew oldestMinorVersion >}}** 인 경우:
|
||||
|
||||
* `kubelet` 버전도 반드시 **{{< skew oldestMinorVersion >}}** 와 동일한 마이너 버전이어야 한다.
|
||||
* `kube-apiserver` 버전은 반드시 **{{< skew oldestMinorVersion >}}** 에서 **{{< skew latestVersion >}}** 사이 이어야 한다.
|
||||
|
|
@ -1,217 +0,0 @@
|
|||
---
|
||||
title: 클러스터 관리
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성,
|
||||
클러스터의 마스터와 워커 노드들의 업그레이드,
|
||||
노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
|
||||
쿠버네티스 API 버전 업그레이드.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 클러스터 생성과 설정
|
||||
|
||||
일련의 머신들에 쿠버네티스를 설치하려면, 환경에 맞게 기존의 [시작하기](/ko/docs/setup/) 안내서들 중에 하나를 선택하여 참조한다.
|
||||
|
||||
## 클러스터 업그레이드
|
||||
|
||||
클러스터 업그레이드 상태의 현황은 제공자에 따라 달라지며, 몇몇 릴리스들은 업그레이드에 각별한 주의를 요하기도 한다. 관리자들에게는 클러스터 업그레이드에 앞서 [릴리스 노트](https://git.k8s.io/kubernetes/CHANGELOG/README.md)와 버전에 맞는 업그레이드 노트 모두를 검토하도록 권장하고 있다.
|
||||
|
||||
### Azure Kubernetes Service (AKS) 클러스터 업그레이드
|
||||
|
||||
Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는
|
||||
현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다.
|
||||
|
||||
### Google Compute Engine 클러스터 업그레이드
|
||||
|
||||
Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고
|
||||
재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해
|
||||
동일한 Persistent Disk(PD)를 유지한다.
|
||||
|
||||
GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는
|
||||
순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은
|
||||
레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다.
|
||||
|
||||
open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다.
|
||||
|
||||
`cluster/gce/upgrade.sh -h`를 실행하여 사용법을 알아볼 수 있다.
|
||||
|
||||
예를 들어, 마스터만 특정 버전(v1.0.2)로 업그레이드하려고 한다면 다음과 같이 커맨드를 사용한다.
|
||||
|
||||
```shell
|
||||
cluster/gce/upgrade.sh -M v1.0.2
|
||||
```
|
||||
|
||||
이 대신에, 전체 클러스터를 최신 안정 릴리스로 업그레이드하려고 한다면 다음과 같이 커맨드를 사용한다.
|
||||
|
||||
```shell
|
||||
cluster/gce/upgrade.sh release/stable
|
||||
```
|
||||
|
||||
### Google Kubernetes Engine 클러스터 업그레이드
|
||||
|
||||
Google Kubernetes Engine은 자동으로 마스터 구성요소들(예. `kube-apiserver`, `kube-scheduler`)을 최신 버전으로 업데이트한다. 이는 운영체제와 마스터 상에서 동작하는 다른 구성요소들의 업그레이드를 처리하기도 한다.
|
||||
|
||||
노드 업그레이드 프로세스는 사용자가 직접 시작하는 방식이며 [Google Kubernetes Engine 문서](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade)에 설명되어 있다.
|
||||
|
||||
### Amazon EKS 클러스터 업그레이드
|
||||
Amazon EKS 클러스터는 eksctl, AWS 관리 콘솔, AWS CLI를 사용해서 마스터 구성요소를 업그레이드할 수 있다. 프로세스는 사용자가 시작하며 [Amazon EKS 문서](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)에 설명되어 있다.
|
||||
|
||||
### Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) 클러스터 업그레이드
|
||||
|
||||
Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레인을 가질 수 있도록 사용자를 대신하여 Oracle 컨트롤 플레인 내에 마스터 노드들의 세트를 (그리고 etcd 노드들과 같은 관련 쿠버네티스 인프라스트럭처를) 생성하고 관리한다. 또한 이 마스터 노드들을 다운타임 없이 쿠버네티스 신규 버전으로 유연하게 업그레이드할 수도 있다. 이 기능들은 [OKE 문서](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm)에 설명되어 있다.
|
||||
|
||||
### 다른 플랫폼들의 클러스터 업그레이드
|
||||
|
||||
다른 제공자들과 도구들은 업그레이드를 다른 방식으로 관리한다. 이들의 업그레이드를 위해서는 이들의 주요 문서를 참조하기를 권장한다.
|
||||
|
||||
* [kops](https://github.com/kubernetes/kops)
|
||||
* [kubespray](https://github.com/kubernetes-sigs/kubespray)
|
||||
* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
|
||||
* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
|
||||
* ...
|
||||
|
||||
위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order)
|
||||
페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다.
|
||||
|
||||
## 클러스터 크기 재조정
|
||||
|
||||
[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인
|
||||
클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다.
|
||||
GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
|
||||
[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면
|
||||
`Compute > Compute Engine > Instance groups > your group > Edit group`에서
|
||||
인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
|
||||
|
||||
```shell
|
||||
gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE
|
||||
```
|
||||
|
||||
인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에
|
||||
Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다.
|
||||
사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다.
|
||||
|
||||
다른 환경에서는 사용자가 직접 머신을 구성하고 어떤 머신에서 API 서버가 동작하는지를 Kubelet에 알려줘야 할 수도 있다.
|
||||
|
||||
### Azure Kubernetes Service (AKS) 클러스터 크기 재조정
|
||||
|
||||
Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며
|
||||
[Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서
|
||||
이를 설명하고 있다.
|
||||
|
||||
|
||||
### 클러스터 오토스케일링
|
||||
|
||||
GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
|
||||
재조정하도록 클러스터를 구성할 수 있다.
|
||||
|
||||
[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼
|
||||
사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
|
||||
이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
|
||||
여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
|
||||
다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다.
|
||||
|
||||
Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를
|
||||
추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다.
|
||||
|
||||
Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안
|
||||
더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다.
|
||||
|
||||
Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다.
|
||||
|
||||
GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다.
|
||||
cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다.
|
||||
|
||||
* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다.
|
||||
* `KUBE_AUTOSCALER_MIN_NODES` - 클러스터 노드들의 최소 개수.
|
||||
* `KUBE_AUTOSCALER_MAX_NODES` - 클러스터 노드들의 최대 개수.
|
||||
|
||||
예제:
|
||||
|
||||
```shell
|
||||
KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의
|
||||
생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을
|
||||
전달하여 cluster autoscaler를 구성할 수 있다.
|
||||
|
||||
예제:
|
||||
|
||||
```shell
|
||||
gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5
|
||||
```
|
||||
|
||||
```shell
|
||||
gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15
|
||||
```
|
||||
|
||||
**Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.**
|
||||
|
||||
cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은
|
||||
autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
|
||||
문서를 참조하기를 바란다.
|
||||
|
||||
## 노드 유지보수
|
||||
|
||||
(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면,
|
||||
Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면
|
||||
(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.)
|
||||
노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는
|
||||
레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이
|
||||
복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다.
|
||||
|
||||
만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다.
|
||||
|
||||
노드에 스케줄할 수 없도록 표시하면서 해당 노드 상의 모든 파드들을 자연스럽게 종료하기 위해 `kubectl drain`을 사용한다.
|
||||
|
||||
```shell
|
||||
kubectl drain $NODENAME
|
||||
```
|
||||
|
||||
이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다.
|
||||
|
||||
레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
|
||||
|
||||
레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
|
||||
|
||||
해당 노드에 유지보수 작업을 수행한다.
|
||||
|
||||
해당 노드가 다시 스케줄될 수 있도록 한다.
|
||||
|
||||
```shell
|
||||
kubectl uncordon $NODENAME
|
||||
```
|
||||
|
||||
해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
|
||||
자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
|
||||
이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.)
|
||||
상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
|
||||
|
||||
## 고급 주제들
|
||||
|
||||
### 클러스터에서 API 버전을 ON/OFF 하기
|
||||
|
||||
특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
|
||||
전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다.
|
||||
예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다.
|
||||
이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`)
|
||||
|
||||
### 클러스터에서 스토리지 API 버전을 변경
|
||||
|
||||
클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다.
|
||||
지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이
|
||||
쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다.
|
||||
|
||||
### 구성 파일을 신규 API 버전으로 변경
|
||||
|
||||
다른 API 버전들 간에 구성 파일을 전환하는데 `kubectl convert` 커맨드를 사용할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl convert -f pod.yaml --output-version v1
|
||||
```
|
||||
|
||||
옵션에 대한 상세 정보는 [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) 커맨드의 사용법을 참조하기를 바란다.
|
||||
|
|
@ -137,7 +137,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
|
|||
### 윈도우 워커 노드 조인(joining)
|
||||
{{< note >}}
|
||||
`Containers` 기능을 설치하고 도커를 설치해야 한다.
|
||||
[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)에서 설치에 대한 내용을 참고할 수 있다.
|
||||
[윈도우 서버에 Docker Engine - Enterprise 설치](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)에서 설치에 대한 내용을 참고할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -45,8 +45,8 @@ kubectl create namespace qos-example
|
|||
|
||||
파드에 Guaranteed QoS 클래스 할당을 위한 전제 조건은 다음과 같다.
|
||||
|
||||
* 파드 내 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
|
||||
* 파드 내 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
|
||||
* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
|
||||
* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
|
||||
|
||||
이것은 하나의 컨테이너를 갖는 파드의 구성 파일이다. 해당 컨테이너는 메모리 상한과
|
||||
메모리 요청량을 갖고 있고, 200MiB로 동일하다. 해당 컨테이너는 CPU 상한과 CPU 요청량을 가지며, 700 milliCPU로 동일하다.
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ kubectl describe pods ${POD_NAME}
|
|||
사용자 클러스터의 CPU 나 Memory의 공급이 소진되었을 수 있다. 이 경우
|
||||
몇 가지 방법을 시도할 수 있다.
|
||||
|
||||
* 클러스터에 [노드를 더 추가하기](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-크기-재조정).
|
||||
* 클러스터에 노드를 더 추가하기.
|
||||
|
||||
* pending 상태인 파드를 위한 공간을 확보하기 위해
|
||||
[불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/#pod-termination)
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네
|
|||
플러그인 관리자이다.
|
||||
|
||||
{{< caution >}}
|
||||
Krew [플러그인 인덱스](https://index.krew.dev/)를 통해 사용할 수 있는 kubectl 플러그인은
|
||||
Krew [플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 통해 사용할 수 있는 kubectl 플러그인은
|
||||
보안 감사를 받지 않는다. 써드파티 플러그인은 시스템에서 실행되는 임의의
|
||||
프로그램이므로, 사용자는 이를 인지한 상태에서 설치하고 실행해야 한다.
|
||||
{{< /caution >}}
|
||||
|
|
@ -42,7 +42,7 @@ Krew [플러그인 인덱스](https://index.krew.dev/)를 통해 사용할 수
|
|||
서로의 이름과 겹치는 유효한 플러그인 파일에 대한 경고도 포함된다.
|
||||
|
||||
[Krew](https://krew.dev/)를 사용하여 커뮤니티가 관리하는
|
||||
[플러그인 인덱스](https://index.krew.dev/)에서 `kubectl`
|
||||
[플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)에서 `kubectl`
|
||||
플러그인을 검색하고 설치할 수 있다.
|
||||
|
||||
#### 제한 사항
|
||||
|
|
@ -351,7 +351,7 @@ CLI 런타임 리포지터리에 제공된 도구 사용법의 예제는
|
|||
방식을 제공한다. 이렇게 하면, 모든 대상 플랫폼(리눅스, 윈도우, macOS 등)에
|
||||
단일 패키징 형식을 사용하고 사용자에게 업데이트를 제공한다.
|
||||
Krew는 또한 다른 사람들이 여러분의 플러그인을 검색하고 설치할 수 있도록
|
||||
[플러그인 인덱스](https://index.krew.dev/)를
|
||||
[플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를
|
||||
유지 관리한다.
|
||||
|
||||
|
||||
|
|
@ -384,5 +384,3 @@ kubectl 플러그인의 배포 패키지를
|
|||
궁금한 사항이 있으면,
|
||||
[SIG CLI 팀](https://github.com/kubernetes/community/tree/master/sig-cli)에 문의한다.
|
||||
* kubectl 플러그인 패키지 관리자인 [Krew](https://krew.dev/)에 대해 읽어본다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아
|
|||
kubectl delete -f <file.yaml> --cascade=false
|
||||
```
|
||||
|
||||
`kubectl delete` 에 `--cascade=false` 를 사용함으로써, 스테이트풀셋 객체가 삭제 된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
|
||||
`kubectl delete` 에 `--cascade=false` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl delete pods -l app=myapp
|
||||
|
|
|
|||
|
|
@ -16,29 +16,27 @@ Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다.
|
||||
[메트릭-서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다.
|
||||
Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다.
|
||||
메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다.
|
||||
[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여
|
||||
[메트릭 API](https://github.com/kubernetes/metrics)를 통해 메트릭을 제공해야 한다.
|
||||
Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 방법에 대해 배우려면,
|
||||
[메트릭-서버 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다.
|
||||
|
||||
Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우,
|
||||
버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다.
|
||||
또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다.
|
||||
버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가
|
||||
사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다.
|
||||
마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우,
|
||||
버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다.
|
||||
버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부
|
||||
메트릭 API와 통신이 가능해야 한다.
|
||||
자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## php-apache 서버 구동 및 노출
|
||||
|
||||
Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다.
|
||||
Dockerfile은 다음과 같다.
|
||||
Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다.
|
||||
|
||||
```
|
||||
```dockerfile
|
||||
FROM php:5-apache
|
||||
COPY index.php /var/www/html/index.php
|
||||
RUN chmod a+rx index.php
|
||||
|
|
@ -46,7 +44,7 @@ RUN chmod a+rx index.php
|
|||
|
||||
index.php는 CPU 과부하 연산을 수행한다.
|
||||
|
||||
```
|
||||
```php
|
||||
<?php
|
||||
$x = 0.0001;
|
||||
for ($i = 0; $i <= 1000000; $i++) {
|
||||
|
|
@ -61,11 +59,12 @@ index.php는 CPU 과부하 연산을 수행한다.
|
|||
|
||||
{{< codenew file="application/php-apache.yaml" >}}
|
||||
|
||||
|
||||
다음의 명령어를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
|
||||
```
|
||||
|
||||
```
|
||||
deployment.apps/php-apache created
|
||||
service/php-apache created
|
||||
|
|
@ -85,6 +84,7 @@ service/php-apache created
|
|||
```shell
|
||||
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache autoscaled
|
||||
```
|
||||
|
|
@ -94,10 +94,10 @@ horizontalpodautoscaler.autoscaling/php-apache autoscaled
|
|||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
|
||||
|
||||
```
|
||||
|
||||
아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다 (``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다).
|
||||
|
|
@ -116,10 +116,10 @@ kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin
|
|||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m
|
||||
|
||||
```
|
||||
|
||||
CPU 소비가 305%까지 증가하였다.
|
||||
|
|
@ -128,6 +128,7 @@ CPU 소비가 305%까지 증가하였다.
|
|||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 7/7 7 7 19m
|
||||
|
|
@ -151,6 +152,7 @@ php-apache 7/7 7 7 19m
|
|||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
|
||||
|
|
@ -159,6 +161,7 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1
|
|||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 1/1 1 1 27m
|
||||
|
|
@ -170,8 +173,6 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮
|
|||
레플리카 오토스케일링은 몇 분 정도 소요된다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링
|
||||
|
|
@ -417,7 +418,8 @@ HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl des
|
|||
```shell
|
||||
kubectl describe hpa cm-test
|
||||
```
|
||||
```shell
|
||||
|
||||
```
|
||||
Name: cm-test
|
||||
Namespace: prom
|
||||
Labels: <none>
|
||||
|
|
@ -472,6 +474,7 @@ HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를
|
|||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache created
|
||||
```
|
||||
|
|
|
|||
|
|
@ -434,7 +434,14 @@ behavior:
|
|||
selectPolicy: Disabled
|
||||
```
|
||||
|
||||
## 암시적 유지 관리 모드 비활성화
|
||||
|
||||
HPA 구성 자체를 변경할 필요없이 대상에 대한
|
||||
HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한
|
||||
레플리카 수가 0으로 설정되고, HPA의 최소 레플리카 수가 0 보다 크면, 대상의
|
||||
의도한 레플리카 수 또는 HPA의 최소 레플리카 수를 수동으로 조정하여
|
||||
다시 활성화할 때까지 HPA는 대상 조정을
|
||||
중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
title: "예제: Java 마이크로서비스 구성하기"
|
||||
weight: 10
|
||||
---
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
title: "대화형 튜토리얼 - Java 마이크로서비스 구성하기"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
||||
<body>
|
||||
|
||||
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
|
||||
<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
|
||||
<script src="https://katacoda.com/embed.js"></script>
|
||||
|
||||
<div class="layout" id="top">
|
||||
|
||||
<main class="content katacoda-content">
|
||||
<div class="katacoda">
|
||||
<div class="katacoda__alert">
|
||||
터미널 화면을 조작하려면, 데스크톱/태블릿 버전을 사용하기 바란다.
|
||||
</div>
|
||||
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/9" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
---
|
||||
title: "MicroProfile, 컨피그맵(ConfigMaps) 및 시크릿(Secrets)을 사용하여 구성 외부화(externalizing)"
|
||||
content_type: tutorial
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 튜토리얼에서는 마이크로서비스의 구성을 외부화하는 방법과 이유를 알아본다. 특히, 쿠버네티스 컨피그맵과 시크릿을 사용하여 환경 변수를 설정한 다음 MicroProfile Config를 이용한 사용 방법을 배운다.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
### 쿠버네티스 컨피그맵 및 시크릿 생성하기
|
||||
쿠버네티스에서 도커 컨테이너에 대한 환경 변수를 설정하는 방법에는 Dockerfile, kubernetes.yml, 쿠버네티스 컨피그맵 및 쿠버네티스 시크릿이 있다. 이 튜토리얼에서는 사용자의 마이크로서비스에 값을 주입하기 위한 환경 변수를 설정하기 위해 후자의 두 가지를 사용하는 방법에 대해 배운다. 컨피그맵 및 시크릿을 사용할 때의 이점 중 하나는 여러 다른 컨테이너에 대해 서로 다른 환경 변수에 할당되는 것을 포함하여, 여러 컨테이너에서 다시 사용할 수 있다는 것이다.
|
||||
|
||||
컨피그맵은 기밀이 아닌 키-값 쌍을 저장하는 API 오브젝트이다. 대화형 튜토리얼에서는 컨피그맵을 사용하여 애플리케이션의 이름을 저장하는 방법을 배운다. 컨피그맵에 대한 자세한 정보는 [여기](/docs/tasks/configure-pod-container/configure-pod-configmap/)에서 문서를 찾을 수 있다.
|
||||
|
||||
시크릿은 키-값 쌍을 저장하는 데도 사용되지만, 기밀/민감한 정보를 위한 것이며 Base64 인코딩을 사용하여 저장된다는 점에서 컨피그맵과 다르다. 따라서 시크릿은 자격 증명, 키 및 토큰과 같은 항목을 저장하는 데 적합한 선택이 된다. 이 내용은 대화형 튜토리얼에서 수행할 것이다. 시크릿에 대한 자세한 내용은 [여기](/ko/docs/concepts/configuration/secret/)에서 문서를 찾을 수 있다.
|
||||
|
||||
|
||||
### 코드로부터 구성 외부화
|
||||
구성은 일반적으로 환경에 따라 변경되기 때문에, 외부화된 애플리케이션 구성(externalized application configuration)은 유용하다. 이를 이루기 위해, Java의 CDI(콘텍스트와 의존성 주입) 및 MicroProfile Config를 사용한다. MicroProfile Config는 클라우드 네이티브 마이크로서비스를 개발하고 배포하기 위한 개방형 Java 기술 세트인 MicroProfile의 기능이다.
|
||||
|
||||
CDI는 느슨하게 결합된 협업 빈(beans)을 통해 애플리케이션을 어셈블할 수 있는 표준 종속성 주입(standard dependency injection) 기능을 제공한다. MicroProfile Config는 애플리케이션, 런타임 및 환경을 포함한 다양한 소스에서 구성 속성을 가져오는 표준 방법을 앱과 마이크로서비스에 제공한다. 소스의 정의된 우선순위에 따라 속성은 애플리케이션이 API를 통해 접근할 수 있는 단일 속성 집합으로 자동 결합된다. 대화형 튜토리얼에서는 CDI와 MicroProfile을 함께 사용하여 쿠버네티스 컨피그맵 및 시크릿을 통한 외부 제공 속성을 검색하고 애플리케이션 코드에 삽입한다.
|
||||
|
||||
많은 오픈 소스 프레임워크와 런타임이 MicroProfile Config를 구현하고 지원한다. 대화형 튜토리얼을 통해 클라우드 네이티브 앱과 마이크로서비스를 빌드하고 실행하기 위한 유연한 오픈 소스 Java 런타임인 Open Liberty를 사용하게 될 것이다. 그러나, 모든 MicroProfile 호환 런타임을 대신 사용할 수 있다.
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* 쿠버네티스 컨피그맵 및 시크릿 생성
|
||||
* MicroProfile Config를 사용하여 마이크로서비스 구성 주입
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## 예제: MicroProfile, 컨피그맵 및 시크릿를 사용하여 구성 외부화
|
||||
### [대화형 튜토리얼 시작](/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/)
|
||||
|
|
@ -65,7 +65,7 @@ resources:
|
|||
EOF
|
||||
```
|
||||
|
||||
컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉터리를 적용한다.
|
||||
컨피그 맵과 파드 오브젝트를 생성하도록 kustomization 디렉터리를 적용한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -k .
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: 쿠버네티스 기초 학습
|
||||
linkTitle: 쿠버네티스 기초 학습
|
||||
no_list: true
|
||||
weight: 10
|
||||
card:
|
||||
name: tutorials
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ MySQL과 Wordpress는 각각 데이터를 저장할 퍼시스턴트볼륨이 필
|
|||
## kustomization.yaml 생성하기
|
||||
|
||||
### 시크릿 생성자 추가
|
||||
[시크릿](/ko/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다.
|
||||
[시크릿](/ko/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 오브젝트이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 오브젝트를 관리한다. `kustomization.yaml`의 제너레이터로 시크릿을 생성할 수 있다.
|
||||
|
||||
다음 명령어로 `kustomization.yaml` 내에 시크릿 제네레이터를 추가한다. `YOUR_PASSWORD`는 사용하기 원하는 암호로 변경해야 한다.
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ EOF
|
|||
kubectl apply -k ./
|
||||
```
|
||||
|
||||
이제 모든 개체가 존재하는지 확인할 수 있다.
|
||||
이제 모든 오브젝트가 존재하는지 확인할 수 있다.
|
||||
|
||||
1. 시크릿이 존재하는지 다음 명령어를 실행하여 확인한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ weight: 40
|
|||
- [파드](/ko/docs/concepts/workloads/pods/)
|
||||
- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
|
||||
- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
|
||||
- [퍼시스턴트볼륨](/ko/docs/concepts/storage/volumes/)
|
||||
- [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)
|
||||
- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
|
||||
- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
|
||||
- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
|
||||
|
|
@ -38,7 +38,7 @@ weight: 40
|
|||
이 튜토리얼을 마치면 다음에 대해 알게 된다.
|
||||
|
||||
- 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
|
||||
- 어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가.
|
||||
- 어떻게 앙상블을 일관되게 설정하는가.
|
||||
- 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
|
||||
- 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
|
||||
|
||||
|
|
@ -761,7 +761,7 @@ fi
|
|||
kubectl get pod -w -l app=zk
|
||||
```
|
||||
|
||||
다른 창에서 `zk-0` 파드의 파일시스템에서 `zkOk.sh` 스크립트를 삭제하기 위해 다음 명령어를 이용하자.
|
||||
다른 창에서 `zk-0` 파드의 파일시스템에서 `zookeeper-ready` 스크립트를 삭제하기 위해 다음 명령어를 이용하자.
|
||||
|
||||
```shell
|
||||
kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
|
||||
|
|
|
|||
|
|
@ -10,16 +10,19 @@ class: training
|
|||
<section class="call-to-action">
|
||||
<div class="main-section">
|
||||
<div class="call-to-action" id="cta-certification">
|
||||
<div class="logo-certification cta-image cta-image-before" id="logo-cka">
|
||||
<img src="/images/training/kubernetes-cka-white.svg"/>
|
||||
</div>
|
||||
<div class="logo-certification cta-image cta-image-after" id="logo-ckad">
|
||||
<img src="/images/training/kubernetes-ckad-white.svg"/>
|
||||
</div>
|
||||
<div class="cta-text">
|
||||
<h2>클라우드 네이티브 커리어를 구축하세요</h2>
|
||||
<p>쿠버네티스는 클라우드 네이티브 무브먼트의 핵심입니다. 리눅스 재단이 제공하는 교육과 인증 프로그램을 통해 커리어에 투자하고, 쿠버네티스를 배우며, 클라우드 네이티브 프로젝트를 성공적으로 수행하세요.</p>
|
||||
</div>
|
||||
<div class="logo-certification cta-image" id="logo-cka">
|
||||
<img src="/images/training/kubernetes-cka-white.svg"/>
|
||||
</div>
|
||||
<div class="logo-certification cta-image" id="logo-ckad">
|
||||
<img src="/images/training/kubernetes-ckad-white.svg"/>
|
||||
</div>
|
||||
<div class="logo-certification cta-image" id="logo-cks">
|
||||
<img src="/images/training/kubernetes-cks-white.svg"/>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
|
@ -74,31 +77,36 @@ class: training
|
|||
</div>
|
||||
</div>
|
||||
|
||||
<section>
|
||||
<section id="get-certified">
|
||||
<div class="main-section padded">
|
||||
<center>
|
||||
<h2>쿠버네티스 공인 자격 획득하기</h2>
|
||||
</center>
|
||||
<h2>쿠버네티스 공인 자격 획득하기</h2>
|
||||
<div class="col-container">
|
||||
<div class="col-nav">
|
||||
<center>
|
||||
<h5>
|
||||
<b>공인 쿠버네티스 애플리케이션 개발자(Certified Kubernetes Application Developer, CKAD)</b>
|
||||
</h5>
|
||||
<p>공인 쿠버네티스 애플리케이션 개발자 시험은 사용자가 쿠버네티스의 클라우드 네이티브 애플리케이션을 디자인, 구축, 구성과 노출을 할 수 있음을 인증합니다.</p>
|
||||
<p>CKAD는 애플리케이션 리소스를 정의하고 핵심 기본 요소를 사용하여 쿠버네티스에서 확장 가능한 애플리케이션 및 도구를 빌드, 모니터링하고 문제를 해결합니다.</p>
|
||||
<br>
|
||||
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">인증으로 이동하기</a>
|
||||
</center>
|
||||
</div>
|
||||
<div class="col-nav">
|
||||
<center>
|
||||
<h5>
|
||||
<b>공인 쿠버네티스 관리자(Certified Kubernetes Administrator, CKA)</b>
|
||||
</h5>
|
||||
<p>공인 쿠버네티스 관리자(CKA) 프로그램은 CKA가 쿠버네티스 관리자 직무을 수행할 수 있는 기술, 지식과 역량을 갖추고 있음을 보장합니다.</p>
|
||||
<p>공인 쿠버네티스 관리자는 기본 설치를 수행하고 프로덕션 등급의 쿠버네티스 클러스터를 구성하고 관리하는 능력을 보여줍니다.</p>
|
||||
<br>
|
||||
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">인증으로 이동하기</a>
|
||||
</center>
|
||||
</div>
|
||||
<div class="col-nav">
|
||||
<h5>
|
||||
<b>공인 쿠버네티스 보안 전문가(Certified Kubernetes Security Specialist, CKS)</b>
|
||||
</h5>
|
||||
<p>공인 쿠버네티스 보안 전문가(CKS) 프로그램은 CKS가 다양한 모범 사례에 대해 능숙하고 자신감을 가지도록 보장합니다. CKS 인증은 빌드, 배포 및 런타임 중에 컨테이너 기반 애플리케이션과 쿠버네티스 플랫폼을 보호하는 기술을 다룹니다.</p>
|
||||
<p><em>CKS 지원자는 CKS에 참여하기 전에 충분한 쿠버네티스 전문 지식을 보유하고 있음을 입증하기 위해 현재 버전의 공인 쿠버네티스 관리자(CKA) 인증을 보유해야 합니다.</em></p>
|
||||
<br>
|
||||
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/" target="_blank" class="button">인증으로 이동하기</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ If you notice that this is out of date, please
|
|||
<a href="https://github.com/kubernetes/website/issues/new">file an issue</a>. -->
|
||||
|
||||
Kubernetes 遵循
|
||||
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF 行为规范</a>。
|
||||
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/zh.md">CNCF 行为规范</a>。
|
||||
CNCF 社区规范文本如下链接
|
||||
<a href="https://github.com/cncf/foundation/blob/0ce4694e5103c0c24ca90c189da81e5408a46632/code-of-conduct.md">commit 0ce4694</a>。
|
||||
如果您发现这个 CNCF 社区规范文本已经过时，请
|
||||
|
|
|
|||
|
|
@ -1,46 +1,30 @@
|
|||
<!-- Do not edit this file directly. Get the latest from
|
||||
https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
|
||||
## CNCF Community Code of Conduct v1.0
|
||||
https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/zh.md -->
|
||||
## 云原生计算基金会（CNCF）社区行为准则 1.0 版本
|
||||
|
||||
### Contributor Code of Conduct
|
||||
### 贡献者行为准则
|
||||
|
||||
As contributors and maintainers of this project, and in the interest of fostering
|
||||
an open and welcoming community, we pledge to respect all people who contribute
|
||||
through reporting issues, posting feature requests, updating documentation,
|
||||
submitting pull requests or patches, and other activities.
|
||||
作为这个项目的贡献者和维护者，为了建立一个开放和受欢迎的社区，我们保证尊重所有通过报告问题、发布功能请求、更新文档、提交拉取请求或补丁以及其他活动做出贡献的人员。
|
||||
|
||||
We are committed to making participation in this project a harassment-free experience for
|
||||
everyone, regardless of level of experience, gender, gender identity and expression,
|
||||
sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
|
||||
religion, or nationality.
|
||||
我们致力于让参与此项目的每个人都不受骚扰，无论其经验水平、性别、性别认同和表达、性取向、残疾、个人外貌、体型、人种、种族、年龄、宗教或国籍等。
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
不可接受的参与者行为包括：
|
||||
|
||||
* The use of sexualized language or imagery
|
||||
* Personal attacks
|
||||
* Trolling or insulting/derogatory comments
|
||||
* Public or private harassment
|
||||
* Publishing other's private information, such as physical or electronic addresses,
|
||||
without explicit permission
|
||||
* Other unethical or unprofessional conduct.
|
||||
- 使用性语言或图像
|
||||
- 人身攻击
|
||||
- 挑衅、侮辱或贬低性评论
|
||||
- 公开或私下骚扰
|
||||
- 未经明确许可，发布他人的私人信息，比如地址或电子邮箱
|
||||
- 其他不道德或不专业的行为
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or reject
|
||||
comments, commits, code, wiki edits, issues, and other contributions that are not
|
||||
aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
|
||||
commit themselves to fairly and consistently applying these principles to every aspect
|
||||
of managing this project. Project maintainers who do not follow or enforce the Code of
|
||||
Conduct may be permanently removed from the project team.
|
||||
项目维护者有权利和责任删除、编辑或拒绝评论、提交、代码、维基编辑、问题和其他不符合本行为准则的贡献。通过采用本行为准则，项目维护者承诺将这些原则公平且一致地应用到这个项目管理的各个方面。不遵守或不执行行为准则的项目维护者可能被永久地从项目团队中移除。
|
||||
|
||||
This code of conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
当个人代表项目或其社区时，本行为准则适用于项目空间和公共空间。
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting
|
||||
the [Kubernetes Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) <conduct@kubernetes.io>.
|
||||
如需举报侮辱、骚扰或其他不可接受的行为，您可发送邮件至 <conduct@kubernetes.io> 联系 [Kubernetes行为守则委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)。其他事务请联系CNCF项目维护专员，或发送邮件至 <mishi@linux.com> 联系我们的调解员Mishi Choudhary。
|
||||
|
||||
This Code of Conduct is adapted from the Contributor Covenant
|
||||
(http://contributor-covenant.org), version 1.2.0, available at
|
||||
http://contributor-covenant.org/version/1/2/0/
|
||||
本行为准则改编自《贡献者契约》（ http://contributor-covenant.org ）1.2.0 版本，可在 http://contributor-covenant.org/version/1/2/0/ 查看。
|
||||
|
||||
### CNCF Events Code of Conduct
|
||||
### CNCF 活动行为准则
|
||||
|
||||
CNCF events are governed by the Linux Foundation [Code of Conduct](http://events.linuxfoundation.org/events/cloudnativecon/attend/code-of-conduct) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents.
|
||||
云原生计算基金会（CNCF）活动受 Linux 基金会《[行为准则](https://events.linuxfoundation.org/code-of-conduct/)》管辖，该行为准则可在活动页面获得。其旨在与上述政策兼容，且包括更多关于事件回应的细节。
|
||||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
linktitle: Kubernetes 文档
|
||||
title: 文档
|
||||
weight: 5
|
||||
sitemap:
|
||||
priority: 1.0
|
||||
---
|
||||
|
|
|
|||
|
|
@ -32,10 +32,10 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz
|
|||
Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。
|
||||
所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。
|
||||
apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求，
|
||||
并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。
|
||||
并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。
|
||||
一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用，
|
||||
特别是在允许使用[匿名请求](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
|
||||
或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
|
||||
特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests)
|
||||
或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
|
||||
|
||||
<!--
|
||||
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
|
||||
|
|
@ -61,7 +61,8 @@ The control plane components also communicate with the cluster apiserver over th
|
|||
<!--
|
||||
As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
|
||||
-->
|
||||
这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。
|
||||
这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，
|
||||
能够在不可信的网络或公网上运行。
|
||||
|
||||
<!--
|
||||
## Control Plane to node
|
||||
|
|
@ -137,7 +138,6 @@ This tunnel ensures that the traffic is not exposed outside of the network in wh
|
|||
|
||||
SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.
|
||||
-->
|
||||
|
||||
### SSH 隧道 {#ssh-tunnels}
|
||||
|
||||
Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，apiserver
|
||||
|
|
@ -158,7 +158,6 @@ After enabling the Konnectivity service, all control plane to nodes traffic goes
|
|||
|
||||
Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster.
|
||||
-->
|
||||
|
||||
### Konnectivity 服务
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
|
@ -168,5 +167,6 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity
|
|||
控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
|
||||
启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。
|
||||
|
||||
请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/)
|
||||
请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/)
|
||||
在你的集群中配置 Konnectivity 服务。
|
||||
|
||||
|
|
|
|||
|
|
@ -139,21 +139,23 @@ Controllers that interact with external state find their desired state from
|
|||
the API server, then communicate directly with an external system to bring
|
||||
the current state closer in line.
|
||||
|
||||
(There actually is a controller that horizontally scales the
|
||||
nodes in your cluster. See
|
||||
[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)).
|
||||
(There actually is a [controller](https://github.com/kubernetes/autoscaler/)
|
||||
that horizontally scales the nodes in your cluster.)
|
||||
-->
|
||||
|
||||
### 直接控制 {#direct-control}
|
||||
|
||||
相比 Job 控制器，有些控制器需要对集群外的一些东西进行修改。
|
||||
|
||||
例如，如果你使用一个控制环来保证集群中有足够的{{< glossary_tooltip text="节点" term_id="node" >}}，那么控制就需要当前集群外的一些服务在需要时创建新节点。
|
||||
例如，如果你使用一个控制回路来保证集群中有足够的
|
||||
{{< glossary_tooltip text="节点" term_id="node" >}}，那么控制器就需要当前集群外的
|
||||
一些服务在需要时创建新节点。
|
||||
|
||||
和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信并使当前状态更接近期望状态。
|
||||
和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信
|
||||
并使当前状态更接近期望状态。
|
||||
|
||||
（实际上有一个控制器可以水平地扩展集群中的节点。请参阅
|
||||
[集群自动扩缩容](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。
|
||||
（实际上有一个[控制器](https://github.com/kubernetes/autoscaler/)
|
||||
可以水平地扩展集群中的节点。请参阅
|
||||
|
||||
<!--
|
||||
The important point here is that the controller makes some change to bring about
|
||||
|
|
@ -193,7 +195,8 @@ useful changes, it doesn't matter if the overall state is or is not stable.
|
|||
|
||||
Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。
|
||||
|
||||
在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。这意味着很可能集群永远不会达到稳定状态。
|
||||
在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。
|
||||
这意味着很可能集群永远不会达到稳定状态。
|
||||
|
||||
只要集群中控制器的在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。
|
||||
|
||||
|
|
@ -278,7 +281,9 @@ Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置
|
|||
* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
|
||||
-->
|
||||
* 阅读 [Kubernetes 控制平面组件](/zh/docs/concepts/overview/components/#control-plane-components)
|
||||
* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一些基本知识
|
||||
* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
的一些基本知识
|
||||
* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)
|
||||
* 如果你想编写自己的控制器，请看 Kubernetes 的[扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。
|
||||
* 如果你想编写自己的控制器，请看 Kubernetes 的
|
||||
[扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。
|
||||
|
||||
|
|
|
|||
|
|
@ -627,11 +627,9 @@ for more information.
|
|||
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
|
||||
section of the architecture design document.
|
||||
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
|
||||
-->
|
||||
* 了解有关节点[组件](/zh/docs/concepts/overview/components/#node-components)
|
||||
* 阅读[节点的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)
|
||||
* 阅读架构设计文档中有关[节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)的章节
|
||||
* 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
|
||||
* 了解[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ The cluster administration overview is for anyone creating or administering a Ku
|
|||
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
|
||||
-->
|
||||
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。
|
||||
我们假设你对一些核心的 Kubernetes [概念](/zh/docs/concepts/)大概了解。
|
||||
我们假设你大概了解一些核心的 Kubernetes [概念](/zh/docs/concepts/)。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -38,9 +38,10 @@ Not all distros are actively maintained. Choose distros which have been tested w
|
|||
|
||||
Before choosing a guide, here are some considerations:
|
||||
-->
|
||||
## 规划集群
|
||||
## 规划集群 {#planning-a-cluster}
|
||||
|
||||
查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。
|
||||
查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes
|
||||
集群的示例。本文所列的文章称为*发行版* 。
|
||||
|
||||
{{< note >}}
|
||||
并非所有发行版都是被积极维护的。
|
||||
|
|
@ -60,27 +61,28 @@ Before choosing a guide, here are some considerations:
|
|||
offer a greater variety of choices.
|
||||
- Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.
|
||||
-->
|
||||
- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。
|
||||
- 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的 Kubernetes 集群**, 还是**管理您自己的集群**？
|
||||
- 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
|
||||
- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。
|
||||
- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？
|
||||
请选择最适合你需求的发行版。
|
||||
- 你正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)
|
||||
这样的**被托管的 Kubernetes 集群**, 还是**管理你自己的集群**？
|
||||
- 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。
|
||||
作为代替，你可以建立多个集群。
|
||||
- **如果你在本地配置 Kubernetes**，需要考虑哪种
|
||||
[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。
|
||||
- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？
|
||||
- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？如果是后者，请选择一个处于开发状态的发行版。某些发行版只提供二进制发布版，但提供更多的选择。
|
||||
- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？
|
||||
如果是后者，请选择一个处于开发状态的发行版。
|
||||
某些发行版只提供二进制发布版，但提供更多的选择。
|
||||
- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。
|
||||
|
||||
<!--
|
||||
## Managing a cluster
|
||||
|
||||
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
|
||||
|
||||
* Learn how to [manage nodes](/docs/concepts/nodes/node/).
|
||||
|
||||
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
|
||||
-->
|
||||
## 管理集群
|
||||
|
||||
* [管理集群](/zh/docs/tasks/administer-cluster/cluster-management/)叙述了和集群生命周期相关的几个主题：
|
||||
创建新集群、升级集群的控制节点和工作节点、执行节点维护（例如内核升级）以及升级运行中的集群的 Kubernetes API 版本。
|
||||
## 管理集群 {#managing-a-cluster}
|
||||
|
||||
* 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。
|
||||
|
||||
|
|
@ -98,16 +100,24 @@ Before choosing a guide, here are some considerations:
|
|||
* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
|
||||
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
|
||||
-->
|
||||
## 保护集群
|
||||
## 保护集群 {#securing-a-cluster}
|
||||
|
||||
* [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。
|
||||
* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。
|
||||
* [认证](/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
|
||||
* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。
|
||||
* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
|
||||
* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
|
||||
* [审计](/zh/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。
|
||||
* [证书](/zh/docs/concepts/cluster-administration/certificates/)
|
||||
节描述了使用不同的工具链生成证书的步骤。
|
||||
* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)
|
||||
描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)
|
||||
描述了如何为用户和 service accounts 建立权限许可。
|
||||
* [身份认证](/zh/docs/reference/access-authn-authz/authentication/)
|
||||
节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
|
||||
* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)
|
||||
与身份认证不同，用于控制如何处理 HTTP 请求。
|
||||
* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers)
|
||||
阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
|
||||
* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)
|
||||
描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
|
||||
* [审计](/zh/docs/tasks/debug-application-cluster/audit/)
|
||||
描述了如何与 Kubernetes 的审计日志交互。
|
||||
|
||||
<!--
|
||||
### Securing the kubelet
|
||||
|
|
@ -116,7 +126,7 @@ Before choosing a guide, here are some considerations:
|
|||
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
|
||||
-->
|
||||
### 保护 kubelet
|
||||
### 保护 kubelet {#securing-the-kubelet}
|
||||
|
||||
* [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
|
|
@ -128,9 +138,10 @@ Before choosing a guide, here are some considerations:
|
|||
* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
|
||||
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
|
||||
-->
|
||||
## 可选集群服务 {#optional-cluster-services}
|
||||
|
||||
## 可选集群服务
|
||||
|
||||
* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。
|
||||
* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。
|
||||
* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)
|
||||
描述了如何将一个 DNS 名解析到一个 Kubernetes service。
|
||||
* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)
|
||||
阐述了 Kubernetes 的日志如何工作以及怎样实现。
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ things by adding the following command-line flags to your
|
|||
`kube-apiserver` invocation:
|
||||
-->
|
||||
APF 特性由特性门控控制，默认情况下不启用。有关如何启用和禁用特性门控的描述，
|
||||
请参见[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
请参见[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
APF 的特性门控叫做 `APIPriorityAndFairness` 。
|
||||
此特性要求必须启用某个 {{< glossary_tooltip term_id="api-group" text="API Group" >}}。
|
||||
你可以在启动 `kube-apiserver` 时，添加以下命令行标志来完成这些操作：
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ up logging for COS image on GCP in the corresponding [script][cosConfigureHelper
|
|||
-->
|
||||
例如，你可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息，
|
||||
相应的脚本在
|
||||
[这里](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
|
||||
[这里](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)。
|
||||
|
||||
<!--
|
||||
When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
|
||||
|
|
@ -273,7 +273,7 @@ Using a node-level logging agent is the most common and encouraged approach for
|
|||
Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node.
|
||||
-->
|
||||
Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。
|
||||
[Stackdriver 日志](/docs/tasks/debug-application-cluster/logging-stackdriver/)
|
||||
[Stackdriver 日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
|
||||
适用于 Google Cloud Platform，和
|
||||
[Elasticsearch](/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)。
|
||||
你可以在专门的文档中找到更多的信息和说明。
|
||||
|
|
@ -446,7 +446,7 @@ which uses fluentd as a logging agent. Here are two configuration files that
|
|||
you can use to implement this approach. The first file contains
|
||||
a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
|
||||
-->
|
||||
例如，你可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)，
|
||||
例如，你可以使用 [Stackdriver](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)，
|
||||
它使用 fluentd 作为日志记录代理。
|
||||
以下是两个可用于实现此方法的配置文件。
|
||||
第一个文件包含配置 fluentd 的
|
||||
|
|
|
|||
|
|
@ -115,7 +115,8 @@ service "my-nginx-svc" deleted
|
|||
<!--
|
||||
In the case of just two resources, it's also easy to specify both on the command line using the resource/name syntax:
|
||||
-->
|
||||
在仅有两种资源的情况下，可以使用"资源类型/资源名"的语法在命令行中同时指定这两个资源：
|
||||
在仅有两种资源的情况下，可以使用"资源类型/资源名"的语法在命令行中
|
||||
同时指定这两个资源：
|
||||
|
||||
```shell
|
||||
kubectl delete deployments/my-nginx services/my-nginx-svc
|
||||
|
|
@ -184,7 +185,8 @@ project/k8s/development
|
|||
<!--
|
||||
By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we had tried to create the resources in this directory using the following command, we would have encountered an error:
|
||||
-->
|
||||
默认情况下，对 `project/k8s/development` 执行的批量操作将停止在目录的第一级，而不是处理所有子目录。
|
||||
默认情况下，对 `project/k8s/development` 执行的批量操作将停止在目录的第一级，
|
||||
而不是处理所有子目录。
|
||||
如果我们试图使用以下命令在此目录中创建资源，则会遇到一个错误：
|
||||
|
||||
```shell
|
||||
|
|
@ -252,7 +254,8 @@ The examples we've used so far apply at most a single label to any resource. The
|
|||
For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
|
||||
-->
|
||||
例如，不同的应用可能会为 `app` 标签设置不同的值。
|
||||
但是，类似 [guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 这样的多层应用，还需要区分每一层。前端可以带以下标签：
|
||||
但是，类似 [guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
|
||||
这样的多层应用，还需要区分每一层。前端可以带以下标签：
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
|
|
@ -368,7 +371,8 @@ and then you can create a new release of the guestbook frontend that carries the
|
|||
<!--
|
||||
The frontend service would span both sets of replicas by selecting the common subset of their labels (i.e. omitting the `track` label), so that the traffic will be redirected to both applications:
|
||||
-->
|
||||
前端服务通过选择标签的公共子集（即忽略 `track` 标签）来覆盖两组副本，以便流量可以转发到两个应用：
|
||||
前端服务通过选择标签的公共子集（即忽略 `track` 标签）来覆盖两组副本，
|
||||
以便流量可以转发到两个应用：
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
|
|
@ -380,12 +384,16 @@ The frontend service would span both sets of replicas by selecting the common su
|
|||
You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1).
|
||||
Once you're confident, you can update the stable track to the new application release and remove the canary one.
|
||||
-->
|
||||
你可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收实时生产流量的比例(在本例中为 3:1)。一旦有信心，你就可以将新版本应用的 `track` 标签的值从 `canary` 替换为 `stable`，并且将老版本应用删除。
|
||||
你可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收
|
||||
实时生产流量的比例（在本例中为 3:1）。
|
||||
一旦有信心，你就可以将新版本应用的 `track` 标签的值从
|
||||
`canary` 替换为 `stable`，并且将老版本应用删除。
|
||||
|
||||
<!--
|
||||
For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary).
|
||||
-->
|
||||
想要了解更具体的示例，请查看 [Ghost 部署教程](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)。
|
||||
想要了解更具体的示例，请查看
|
||||
[Ghost 部署教程](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)。
|
||||
|
||||
<!--
|
||||
## Updating labels
|
||||
|
|
@ -447,7 +455,8 @@ Sometimes you would want to attach annotations to resources. Annotations are arb
|
|||
-->
|
||||
## 更新注解 {#updating-annotations}
|
||||
|
||||
有时，你可能希望将注解附加到资源中。注解是 API 客户端（如工具、库等）用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如：
|
||||
有时，你可能希望将注解附加到资源中。注解是 API 客户端（如工具、库等）
|
||||
用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如：
|
||||
|
||||
```shell
|
||||
kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
|
||||
|
|
@ -545,12 +554,14 @@ Then, you can use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-co
|
|||
建议在源代码管理中维护一组配置文件
|
||||
（参见[配置即代码](https://martinfowler.com/bliki/InfrastructureAsCode.html)），
|
||||
这样，它们就可以和应用代码一样进行维护和版本管理。
|
||||
然后，你可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 将配置变更应用到集群中。
|
||||
然后，你可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)
|
||||
将配置变更应用到集群中。
|
||||
|
||||
<!--
|
||||
This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified.
|
||||
-->
|
||||
这个命令将会把推送的版本与以前的版本进行比较，并应用你所做的更改，但是不会自动覆盖任何你没有指定更改的属性。
|
||||
这个命令将会把推送的版本与以前的版本进行比较，并应用你所做的更改，
|
||||
但是不会自动覆盖任何你没有指定更改的属性。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
|
|
@ -560,17 +571,24 @@ deployment.apps/my-nginx configured
|
|||
<!--
|
||||
Note that `kubectl apply` attaches an annotation to the resource in order to determine the changes to the configuration since the previous invocation. When it's invoked, `kubectl apply` does a three-way diff between the previous configuration, the provided input and the current configuration of the resource, in order to determine how to modify the resource.
|
||||
-->
|
||||
注意，`kubectl apply` 将为资源增加一个额外的注解，以确定自上次调用以来对配置的更改。当调用它时，`kubectl apply` 会在以前的配置、提供的输入和资源的当前配置之间找出三方差异，以确定如何修改资源。
|
||||
注意，`kubectl apply` 将为资源增加一个额外的注解，以确定自上次调用以来对配置的更改。
|
||||
执行时，`kubectl apply` 会在以前的配置、提供的输入和资源的当前配置之间
|
||||
找出三方差异，以确定如何修改资源。
|
||||
|
||||
<!--
|
||||
Currently, resources are created without this annotation, so the first invocation of `kubectl apply` will fall back to a two-way diff between the provided input and the current configuration of the resource. During this first invocation, it cannot detect the deletion of properties set when the resource was created. For this reason, it will not remove them.
|
||||
-->
|
||||
目前，新创建的资源是没有这个注解的，所以，第一次调用 `kubectl apply` 将使用提供的输入和资源的当前配置双方之间差异进行比较。在第一次调用期间，它无法检测资源创建时属性集的删除情况。因此，不会删除它们。
|
||||
目前，新创建的资源是没有这个注解的，所以，第一次调用 `kubectl apply` 时
|
||||
将使用提供的输入和资源的当前配置双方之间差异进行比较。
|
||||
在第一次调用期间，它无法检测资源创建时属性集的删除情况。
|
||||
因此，kubectl 不会删除它们。
|
||||
|
||||
<!--
|
||||
All subsequent calls to `kubectl apply`, and other commands that modify the configuration, such as `kubectl replace` and `kubectl edit`, will update the annotation, allowing subsequent calls to `kubectl apply` to detect and perform deletions using a three-way diff.
|
||||
-->
|
||||
所有后续调用 `kubectl apply` 以及其它修改配置的命令，如 `kubectl replace` 和 `kubectl edit`，都将更新注解，并允许随后调用的 `kubectl apply` 使用三方差异进行检查和执行删除。
|
||||
所有后续的 `kubectl apply` 操作以及其他修改配置的命令，如 `kubectl replace`
|
||||
和 `kubectl edit`，都将更新注解，并允许随后调用的 `kubectl apply`
|
||||
使用三方差异进行检查和执行删除。
|
||||
|
||||
<!--
|
||||
To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
|
||||
|
|
@ -611,21 +629,24 @@ This allows you to do more significant changes more easily. Note that you can sp
|
|||
|
||||
For more information, please see [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) document.
|
||||
-->
|
||||
这使你可以更加容易地进行更重大的更改。请注意，可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。
|
||||
这使你可以更加容易地进行更重大的更改。
|
||||
请注意，可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。
|
||||
|
||||
想要了解更多信息，请参考 [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 文档。
|
||||
想要了解更多信息，请参考
|
||||
[kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 文档。
|
||||
|
||||
### kubectl patch
|
||||
|
||||
<!--
|
||||
You can use `kubectl patch` to update API objects in place. This command supports JSON patch,
|
||||
JSON merge patch, and strategic merge patch. See
|
||||
[Update API Objects in Place Using kubectl patch](/docs/tasks/run-application/update-api-object-kubectl-patch/)
|
||||
[Update API Objects in Place Using kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
|
||||
and
|
||||
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
|
||||
-->
|
||||
你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch，JSON merge patch，以及 strategic merge patch。 请参考
|
||||
[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/run-application/update-api-object-kubectl-patch/)
|
||||
你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch、
|
||||
JSON merge patch、以及 strategic merge patch。 请参考
|
||||
[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
|
||||
和
|
||||
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
|
||||
|
||||
|
|
@ -636,7 +657,9 @@ In some cases, you may need to update resource fields that cannot be updated onc
|
|||
-->
|
||||
## 破坏性的更新 {#disruptive-updates}
|
||||
|
||||
在某些情况下，你可能需要更新某些初始化后无法更新的资源字段，或者你可能只想立即进行递归更改，例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段，请使用 `replace --force`，它将删除并重新创建资源。在这种情况下，你可以简单地修改原始配置文件：
|
||||
在某些情况下，你可能需要更新某些初始化后无法更新的资源字段，或者你可能只想立即进行递归更改，
|
||||
例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段，请使用 `replace --force`，
|
||||
它将删除并重新创建资源。在这种情况下，你可以简单地修改原始配置文件：
|
||||
|
||||
```shell
|
||||
kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
|
||||
|
|
@ -655,7 +678,9 @@ deployment.apps/my-nginx replaced
|
|||
<!--
|
||||
At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios.
|
||||
-->
|
||||
在某些时候，你最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签，如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作，每种更新操作都适用于不同的场景。
|
||||
在某些时候，你最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签，
|
||||
如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作，
|
||||
每种更新操作都适用于不同的场景。
|
||||
|
||||
<!--
|
||||
We'll guide you through how to create and update applications with Deployments.
|
||||
|
|
|
|||
|
|
@ -95,16 +95,16 @@ to containers. If your job previously ran in a VM, your VM had an IP and could
|
|||
talk to other VMs in your project. This is the same basic model.
|
||||
|
||||
Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod`
|
||||
share their network namespaces - including their IP address. This means that
|
||||
containers within a `Pod` can all reach each other's ports on `localhost`. This
|
||||
also means that containers within a `Pod` must coordinate port usage, but this
|
||||
is no different from processes in a VM. This is called the "IP-per-pod" model.
|
||||
share their network namespaces - including their IP address and MAC address.
|
||||
This means that containers within a `Pod` can all reach each other's ports on
|
||||
`localhost`. This also means that containers within a `Pod` must coordinate port
|
||||
usage, but this is no different from processes in a VM. This is called the
|
||||
-->
|
||||
这个模型不仅不复杂，而且还和 Kubernetes 的实现廉价的从虚拟机向容器迁移的初衷相兼容，
|
||||
如果你的工作开始是在虚拟机中运行的，你的虚拟机有一个 IP ，
|
||||
这样就可以和其他的虚拟机进行通信，这是基本相同的模型。
|
||||
|
||||
Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器分享它们的网络命名空间 - 包括它们的 IP 地址。
|
||||
Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。
|
||||
这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达各个端口。
|
||||
这也意味着 `Pod` 内的容器都需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同，
|
||||
这也被称为“一个 Pod 一个 IP” 模型。
|
||||
|
|
|
|||
|
|
@ -174,7 +174,7 @@ The kubelet collects accelerator metrics through cAdvisor. To collect these metr
|
|||
|
||||
The responsibility for collecting accelerator metrics now belongs to the vendor rather than the kubelet. Vendors must provide a container that collects metrics and exposes them to the metrics service (for example, Prometheus).
|
||||
|
||||
The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
|
||||
The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
|
||||
-->
|
||||
## 禁用加速器指标
|
||||
|
||||
|
|
@ -185,7 +185,7 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结
|
|||
现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器，
|
||||
并将其公开给指标服务（例如 Prometheus）。
|
||||
|
||||
[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gate.md#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false)
|
||||
[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gates/)
|
||||
禁止由 kubelet 收集的指标。
|
||||
关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。
|
||||
|
||||
|
|
@ -235,4 +235,4 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
|||
-->
|
||||
* 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
|
||||
* 查看 [Kubernetes 稳定指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)的列表
|
||||
* 阅读有关 [Kubernetes 弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
|
||||
* 阅读有关 [Kubernetes 弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
|
||||
|
|
|
|||
|
|
@ -17,12 +17,12 @@ weight: 70
|
|||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
<!--
|
||||
[Pods](/docs/concepts/workloads/pods/pod/) can have _priority_. Priority indicates the
|
||||
[Pods](/docs/concepts/workloads/pods/) can have _priority_. Priority indicates the
|
||||
importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
|
||||
scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
|
||||
pending Pod possible.
|
||||
-->
|
||||
[Pods](/zh/docs/concepts/workloads/pods/pod/) 可以有*优先级（Priority）*。
|
||||
[Pods](/zh/docs/concepts/workloads/pods/) 可以有*优先级（Priority）*。
|
||||
优先级体现的是当前 Pod 与其他 Pod 相比的重要程度。如果 Pod 无法被调度，则
|
||||
调度器会尝试抢占（逐出）低优先级的 Pod，从而使得悬决的 Pod 可被调度。
|
||||
|
||||
|
|
@ -460,7 +460,7 @@ despite their PDBs being violated.
|
|||
-->
|
||||
#### PodDisruptionBudget 是被支持的，但不提供保证
|
||||
|
||||
[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)
|
||||
[PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/) (PDB)
|
||||
的存在使得应用的属主能够限制多副本应用因主动干扰而同时离线的 Pod 的个数。
|
||||
Kubernetes 在抢占 Pod 时是可以支持 PDB 的，但对 PDB 的约束也仅限于尽力而为。
|
||||
调度器会尝试寻找不会因为抢占而违反其 PDB 约束的 Pod 作为牺牲品，不过如果
|
||||
|
|
@ -628,17 +628,12 @@ Pod may be created that fits on the same Node. In this case, the scheduler will
|
|||
schedule the higher priority Pod instead of the preemptor.
|
||||
|
||||
This is expected behavior: the Pod with the higher priority should take the place
|
||||
of a Pod with a lower priority. Other controller actions, such as
|
||||
[cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling),
|
||||
may eventually provide capacity to schedule the pending Pods.
|
||||
of a Pod with a lower priority.
|
||||
-->
|
||||
在抢占者 Pod 等待被牺牲的 Pod 消失期间，可能有更高优先级的 Pod 被创建，且适合
|
||||
调度到同一节点。如果是这种情况，调度器会调度优先级更高的 Pod 而不是抢占者。
|
||||
|
||||
这是期望发生的行为：优先级更高的 Pod 应该取代优先级较低的 Pod。
|
||||
其他控制器行为，例如
|
||||
[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)
|
||||
可能会最终为集群添加容量，以调度悬决 Pod。
|
||||
|
||||
<!--
|
||||
### Higher priority Pods are preempted before lower priority pods
|
||||
|
|
|
|||
|
|
@ -666,7 +666,7 @@ There are several options to create a Secret:
|
|||
|
||||
- [使用 `kubectl` 命令创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [使用配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [使用 kustomize 来创建 Secret](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- [使用 kustomize 来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
<!--
|
||||
## Editing a Secret
|
||||
|
|
|
|||
|
|
@ -307,8 +307,8 @@ Kubernetes has several built-in authentication methods that it supports. It can
|
|||
Kubernetes 提供若干内置的身份认证方法。
|
||||
它也可以运行在某中身份认证代理的后面，并且可以将来自鉴权头部的令牌发送到
|
||||
某个远程服务（Webhook）来执行验证操作。
|
||||
所有这些方法都在[身份认证文档](/docs/reference/access-authn-authz/authentication/)
|
||||
中详细论述。
|
||||
所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/)
|
||||
中有详细论述。
|
||||
|
||||
<!--
|
||||
### Authentication
|
||||
|
|
@ -405,8 +405,8 @@ Different networking fabrics can be supported via node-level [Network Plugins](/
|
|||
|
||||
The scheduler is a special type of controller that watches pods, and assigns
|
||||
pods to nodes. The default scheduler can be replaced entirely, while
|
||||
continuing to use other Kubernetes components, or [multiple
|
||||
schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
|
||||
continuing to use other Kubernetes components, or
|
||||
[multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
|
||||
can run at the same time.
|
||||
|
||||
This is a significant undertaking, and almost all Kubernetes users find they
|
||||
|
|
@ -422,14 +422,14 @@ the nodes chosen for a pod.
|
|||
调度器是一种特殊的控制器，负责监视 Pod 变化并将 Pod 分派给节点。
|
||||
默认的调度器可以被整体替换掉，同时继续使用其他 Kubernetes 组件。
|
||||
或者也可以在同一时刻使用
|
||||
[多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/)。
|
||||
[多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
|
||||
|
||||
这是一项非同小可的任务，几乎绝大多数 Kubernetes
|
||||
用户都会发现其实他们不需要修改调度器。
|
||||
|
||||
调度器也支持一种 [webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)，
|
||||
允许使用某种 Webhook 后端（调度器扩展）来为 Pod
|
||||
可选的节点执行过滤和优先排序操作。
|
||||
调度器也支持一种
|
||||
[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)，
|
||||
允许使用某种 Webhook 后端（调度器扩展）来为 Pod 可选的节点执行过滤和优先排序操作。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@ title: 通过聚合层扩展 Kubernetes API
|
|||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Extending the Kubernetes API with the aggregation layer
|
||||
reviewers:
|
||||
- lavalamp
|
||||
|
|
@ -12,7 +12,6 @@ reviewers:
|
|||
- chenopis
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -32,7 +31,7 @@ The aggregation layer is different from [Custom Resources](/docs/concepts/extend
|
|||
这类已经成熟的解决方案，也可以是你自己开发的 API。
|
||||
|
||||
聚合层不同于
|
||||
[自定义资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
[定制资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
后者的目的是让 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
|
||||
能够认识新的对象类别（Kind）。
|
||||
|
||||
|
|
@ -91,6 +90,6 @@ to disable the timeout restriction. This deprecated feature gate will be removed
|
|||
了解如何在自己的环境中启用聚合器。
|
||||
* 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)，
|
||||
开始使用聚合层。
|
||||
* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范
|
||||
|
||||
|
|
|
|||
|
|
@ -384,8 +384,8 @@ Different networking fabrics can be supported via node-level [Network Plugins](/
|
|||
|
||||
The scheduler is a special type of controller that watches pods, and assigns
|
||||
pods to nodes. The default scheduler can be replaced entirely, while
|
||||
continuing to use other Kubernetes components, or [multiple
|
||||
schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
|
||||
continuing to use other Kubernetes components, or
|
||||
[multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
|
||||
can run at the same time.
|
||||
|
||||
This is a significant undertaking, and almost all Kubernetes users find they
|
||||
|
|
@ -400,7 +400,7 @@ the nodes chosen for a pod.
|
|||
|
||||
调度器是一种特殊类型的控制器，用于监视 pod 并将其分配到节点。
|
||||
默认的调度器可以完全被替换，而继续使用其他 Kubernetes 组件，或者可以同时运行
|
||||
[多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/)。
|
||||
[多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
|
||||
|
||||
这是一个不太轻松的任务，几乎所有的 Kubernetes 用户都会意识到他们并不需要修改调度器。
|
||||
|
||||
|
|
@ -419,7 +419,7 @@ the nodes chosen for a pod.
|
|||
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
|
||||
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
|
||||
-->
|
||||
* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
* 详细了解基础设施扩展
|
||||
* [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
|
|
|
|||
|
|
@ -18,13 +18,12 @@ resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
|||
to manage applications and their components. Operators follow
|
||||
Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller/).
|
||||
-->
|
||||
|
||||
Operator 是 Kubernetes 的扩展软件，它利用
|
||||
[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
|
||||
Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/architecture/controller/)
|
||||
[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
管理应用及其组件。
|
||||
Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh/docs/concepts/architecture/controller/)
|
||||
方面。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
|
|
@ -69,7 +68,8 @@ Kubernetes 为自动化而生。无需任何修改，你即可以从 Kubernetes
|
|||
Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}}
|
||||
使你无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
|
||||
Operator 是 Kubernetes API 的客户端，充当
|
||||
[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
|
||||
[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
的控制器。
|
||||
|
||||
<!--
|
||||
## An example Operator {#example}
|
||||
|
|
@ -225,7 +225,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
|
|||
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
|
||||
-->
|
||||
|
||||
* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 详细了解[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator
|
||||
* 借助已有的工具来编写你自己的 Operator，例如：
|
||||
* [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ To make it easier to evolve and to extend its API, Kubernetes implements
|
|||
-->
|
||||
为了便于演化和扩展其 API，Kubernetes 实现了
|
||||
可被[启用或禁用](/zh/docs/reference/using-api/#enabling-or-disabling)的
|
||||
[API 组](/docs/reference/using-api/#api-groups)。
|
||||
[API 组](/zh/docs/reference/using-api/#api-groups)。
|
||||
|
||||
<!--
|
||||
API resources are distinguished by their API group, resource type, namespace
|
||||
|
|
|
|||
|
|
@ -288,7 +288,7 @@ on configuring Controller Manager authorization, see
|
|||
|
||||
- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
|
||||
必须运行在
|
||||
[安全的 API 端口](/zh/docs/reference/access-authn-authz/controlling-access/)，
|
||||
[安全的 API 端口](/zh/docs/concepts/security/controlling-access/)，
|
||||
并且一定不能具有超级用户权限。
|
||||
否则其请求会绕过身份认证和鉴权模块控制，从而导致所有 PodSecurityPolicy 对象
|
||||
都被启用，用户亦能创建特权容器。
|
||||
|
|
@ -696,7 +696,7 @@ several security mechanisms.
|
|||
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
|
||||
-->
|
||||
更多的示例可参考
|
||||
[Pod 安全标准](/docs/concepts/security/pod-security-standards/#policy-instantiation)。
|
||||
[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。
|
||||
|
||||
<!--
|
||||
## Policy Reference
|
||||
|
|
@ -1219,7 +1219,7 @@ By default, all safe sysctls are allowed.
|
|||
|
||||
- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
|
||||
-->
|
||||
- 参阅[Pod 安全标准](/docs/concepts/security/pod-security-standards/)
|
||||
- 参阅[Pod 安全标准](zh/docs/concepts/security/pod-security-standards/)
|
||||
了解策略建议。
|
||||
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。
|
||||
|
||||
|
|
|
|||
|
|
@ -178,7 +178,8 @@ with prefix `requests.` is allowed for now.
|
|||
Take the GPU resource as an example, if the resource name is `nvidia.com/gpu`, and you want to
|
||||
limit the total number of GPUs requested in a namespace to 4, you can define a quota as follows:
|
||||
-->
|
||||
以 GPU 拓展资源为例，如果资源名称为 `nvidia.com/gpu`，并且要将命名空间中请求的 GPU 资源总数限制为 4，则可以如下定义配额：
|
||||
以 GPU 拓展资源为例，如果资源名称为 `nvidia.com/gpu`，并且要将命名空间中请求的 GPU
|
||||
资源总数限制为 4，则可以如下定义配额：
|
||||
|
||||
* `requests.nvidia.com/gpu: 4`
|
||||
|
||||
|
|
@ -196,7 +197,8 @@ In addition, you can limit consumption of storage resources based on associated
|
|||
-->
|
||||
## 存储资源配额
|
||||
|
||||
用户可以对给定命名空间下的[存储资源](/docs/concepts/storage/persistent-volumes/)总量进行限制。
|
||||
用户可以对给定命名空间下的[存储资源](/zh/docs/concepts/storage/persistent-volumes/)
|
||||
总量进行限制。
|
||||
|
||||
此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。
|
||||
|
||||
|
|
@ -219,7 +221,8 @@ In addition, you can limit consumption of storage resources based on associated
|
|||
For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can
|
||||
define a quota as follows:
|
||||
-->
|
||||
例如，如果一个操作人员针对 `gold` 存储类型与 `bronze` 存储类型设置配额，操作人员可以定义如下配额：
|
||||
例如，如果一个操作人员针对 `gold` 存储类型与 `bronze` 存储类型设置配额，
|
||||
操作人员可以定义如下配额：
|
||||
|
||||
* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
|
||||
* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi`
|
||||
|
|
@ -279,7 +282,8 @@ The same syntax can be used for custom resources.
|
|||
For example, to create a quota on a `widgets` custom resource in the `example.com` API group, use `count/widgets.example.com`.
|
||||
-->
|
||||
相同语法也可用于自定义资源。
|
||||
例如，要对 `example.com` API 组中的自定义资源 `widgets` 设置配额，请使用 `count/widgets.example.com`。
|
||||
例如，要对 `example.com` API 组中的自定义资源 `widgets` 设置配额，请使用
|
||||
`count/widgets.example.com`。
|
||||
|
||||
<!--
|
||||
When using `count/*` resource quota, an object is charged against the quota if it exists in server storage.
|
||||
|
|
@ -292,7 +296,8 @@ a poorly configured CronJob. CronJobs that create too many Jobs in a namespace c
|
|||
这些类型的配额有助于防止存储资源耗尽。例如，用户可能想根据服务器的存储能力来对服务器中
|
||||
Secret 的数量进行配额限制。
|
||||
集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动。
|
||||
用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多 Job 而导致集群拒绝服务。
|
||||
用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多
|
||||
Job 而导致集群拒绝服务。
|
||||
|
||||
<!--
|
||||
It is possible to do generic object count quota on a limited set of resources.
|
||||
|
|
@ -337,7 +342,8 @@ quota on a namespace to avoid the case where a user creates many small pods and
|
|||
exhausts the cluster's supply of Pod IPs.
|
||||
-->
|
||||
例如，`pods` 配额统计某个命名空间中所创建的、非终止状态的 `Pod` 个数并确保其不超过某上限值。
|
||||
用户可能希望在某命名空间中设置 `pods` 配额，以避免有用户创建很多小的 Pod，从而耗尽集群所能提供的 Pod IP 地址。
|
||||
用户可能希望在某命名空间中设置 `pods` 配额，以避免有用户创建很多小的 Pod，
|
||||
从而耗尽集群所能提供的 Pod IP 地址。
|
||||
|
||||
<!--
|
||||
## Quota Scopes
|
||||
|
|
@ -460,7 +466,7 @@ Pods can be created at a specific [priority](/docs/concepts/configuration/pod-pr
|
|||
You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector`
|
||||
field in the quota spec.
|
||||
-->
|
||||
Pod 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
|
||||
Pod 可以创建为特定的[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
|
||||
通过使用配额规约中的 `scopeSelector` 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。
|
||||
|
||||
<!--
|
||||
|
|
@ -891,7 +897,8 @@ will be able to consume these priority classes by default.
|
|||
To enforce this, kube-apiserver flag `-admission-control-config-file` should be
|
||||
used to pass path to the following configuration file:
|
||||
-->
|
||||
要实现此目的，应使用 kube-apiserver 标志 `--admission-control-config-file` 传递如下配置文件的路径：
|
||||
要实现此目的，应设置 kube-apiserver 的标志 `--admission-control-config-file`
|
||||
指向如下配置文件：
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
|
|
@ -938,5 +945,5 @@ For example:
|
|||
- 查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。
|
||||
- 阅读[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。
|
||||
了解更多信息。
|
||||
- 参阅[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
|
||||
- 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
|
||||
|
||||
|
|
|
|||
|
|
@ -17,9 +17,8 @@ are matched to {{< glossary_tooltip text="Nodes" term_id="node" >}} so that
|
|||
{{< glossary_tooltip term_id="kubelet" >}} can run them.
|
||||
-->
|
||||
在 Kubernetes 中，_调度_ 是指将 {{< glossary_tooltip text="Pod" term_id="pod" >}} 放置到合适的
|
||||
{{< glossary_tooltip text="Node" term_id="node" >}} 上，然后对应 Node 上的 {{< glossary_tooltip term_id="kubelet" >}} 才能够运行这些 pod。
|
||||
|
||||
|
||||
{{< glossary_tooltip text="Node" term_id="node" >}} 上，然后对应 Node 上的
|
||||
{{< glossary_tooltip term_id="kubelet" >}} 才能够运行这些 pod。
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
|
|
@ -34,14 +33,17 @@ for finding the best Node for that Pod to run on. The scheduler reaches
|
|||
this placement decision taking into account the scheduling principles
|
||||
described below.
|
||||
-->
|
||||
调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。调度器会依据下文的调度原则来做出调度选择。
|
||||
调度器通过 kubernetes 的监测（Watch）机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。
|
||||
调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。
|
||||
调度器会依据下文的调度原则来做出调度选择。
|
||||
|
||||
<!--
|
||||
If you want to understand why Pods are placed onto a particular Node,
|
||||
or if you're planning to implement a custom scheduler yourself, this
|
||||
page will help you learn about scheduling.
|
||||
-->
|
||||
如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现一个自定义的调度器，这篇文章将帮助你了解调度。
|
||||
如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现
|
||||
一个自定义的调度器，这篇文章将帮助你了解调度。
|
||||
|
||||
<!--
|
||||
## kube-scheduler
|
||||
|
|
@ -55,7 +57,11 @@ is the default scheduler for Kubernetes and runs as part of the
|
|||
kube-scheduler is designed so that, if you want and need to, you can
|
||||
write your own scheduling component and use that instead.
|
||||
-->
|
||||
[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) 是 Kubernetes 集群的默认调度器，并且是集群 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。
|
||||
[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
是 Kubernetes 集群的默认调度器，并且是集群
|
||||
{{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。
|
||||
如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许
|
||||
你自己写一个调度组件并替换原有的 kube-scheduler。
|
||||
|
||||
<!--
|
||||
For every newly created pods or other unscheduled pods, kube-scheduler
|
||||
|
|
@ -64,14 +70,19 @@ pods has different requirements for resources and every pod also has
|
|||
different requirements. Therefore, existing nodes need to be filtered
|
||||
according to the specific scheduling requirements.
|
||||
-->
|
||||
对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的 Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且 Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前，根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。
|
||||
对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的
|
||||
Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且
|
||||
Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前，
|
||||
根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。
|
||||
|
||||
<!--
|
||||
In a cluster, Nodes that meet the scheduling requirements for a Pod
|
||||
are called _feasible_ nodes. If none of the nodes are suitable, the pod
|
||||
remains unscheduled until the scheduler is able to place it.
|
||||
-->
|
||||
在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node。
|
||||
在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。
|
||||
如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在
|
||||
未调度状态直到调度器能够找到合适的 Node。
|
||||
|
||||
<!--
|
||||
The scheduler finds feasible Nodes for a Pod and then runs a set of
|
||||
|
|
@ -79,7 +90,9 @@ functions to score the feasible Nodes and picks a Node with the highest
|
|||
score among the feasible ones to run the Pod. The scheduler then notifies
|
||||
the API server about this decision in a process called _binding_.
|
||||
-->
|
||||
调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，然后选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做 _绑定_。
|
||||
调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，
|
||||
选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给
|
||||
kube-apiserver，这个过程叫做 _绑定_。
|
||||
|
||||
<!--
|
||||
Factors that need taken into account for scheduling decisions include
|
||||
|
|
@ -87,7 +100,8 @@ individual and collective resource requirements, hardware / software /
|
|||
policy constraints, affinity and anti-affinity specifications, data
|
||||
locality, inter-workload interference, and so on.
|
||||
-->
|
||||
在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。
|
||||
在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、
|
||||
亲和以及反亲和要求、数据局域性、负载间的干扰等等。
|
||||
|
||||
<!--
|
||||
## Scheduling with kube-scheduler {#kube-scheduler-implementation}
|
||||
|
|
@ -113,21 +127,26 @@ resource requests. After this step, the node list contains any suitable
|
|||
Nodes; often, there will be more than one. If the list is empty, that
|
||||
Pod isn't (yet) schedulable.
|
||||
-->
|
||||
过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下，这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。
|
||||
过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。
|
||||
例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。
|
||||
在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下，
|
||||
这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。
|
||||
|
||||
<!--
|
||||
In the _scoring_ step, the scheduler ranks the remaining nodes to choose
|
||||
the most suitable Pod placement. The scheduler assigns a score to each Node
|
||||
that survived filtering, basing this score on the active scoring rules.
|
||||
-->
|
||||
在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。
|
||||
在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。
|
||||
根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。
|
||||
|
||||
<!--
|
||||
Finally, kube-scheduler assigns the Pod to the Node with the highest ranking.
|
||||
If there is more than one node with equal scores, kube-scheduler selects
|
||||
one of these at random.
|
||||
-->
|
||||
最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。
|
||||
最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。
|
||||
如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。
|
||||
|
||||
<!--
|
||||
There are two supported ways to configure the filtering and scoring behavior
|
||||
|
|
@ -143,26 +162,25 @@ of the scheduler:
|
|||
`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
|
||||
can also configure the kube-scheduler to run different profiles.
|
||||
-->
|
||||
1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_ 。
|
||||
2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。
|
||||
|
||||
1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_
|
||||
和打分的 _优先级(Priorities)_ 。
|
||||
2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，
|
||||
包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。
|
||||
你也可以配置 kube-scheduler 运行不同的配置文件。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
|
||||
* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
|
||||
* Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
|
||||
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
|
||||
* Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
|
||||
-->
|
||||
|
||||
* 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
|
||||
* 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
* 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
* 了解关于 [配置多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/) 的方式
|
||||
* 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式
|
||||
* 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
|
||||
* 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
|
||||
|
||||
|
|
|
|||
|
|
@ -448,12 +448,12 @@ type PreFilterPlugin interface {
|
|||
<!--
|
||||
You can enable or disable plugins in the scheduler configuration. If you are using
|
||||
Kubernetes v1.18 or later, most scheduling
|
||||
[plugins](/docs/reference/scheduling/profiles/#scheduling-plugins) are in use and
|
||||
[plugins](/docs/reference/scheduling/config/#scheduling-plugins) are in use and
|
||||
enabled by default.
|
||||
-->
|
||||
你可以在调度器配置中启用或禁用插件。
|
||||
如果你在使用 Kubernetes v1.18 或更高版本，大部分调度
|
||||
[插件](/zh/docs/reference/scheduling/profiles/#scheduling-plugins)
|
||||
[插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)
|
||||
都在使用中且默认启用。
|
||||
|
||||
<!--
|
||||
|
|
@ -468,9 +468,9 @@ plugins and get them configured along with default plugins. You can visit
|
|||
<!--
|
||||
If you are using Kubernetes v1.18 or later, you can configure a set of plugins as
|
||||
a scheduler profile and then define multiple profiles to fit various kinds of workload.
|
||||
Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
|
||||
Learn more at [multiple profiles](/docs/reference/scheduling/config/#multiple-profiles).
|
||||
-->
|
||||
如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为
|
||||
一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
|
||||
了解更多关于[多配置文件](/zh/docs/reference/scheduling/profiles/#multiple-profiles)。
|
||||
了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。
|
||||
|
||||
|
|
|
|||
|
|
@ -516,6 +516,6 @@ arbitrary tolerations to DaemonSets.
|
|||
* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
-->
|
||||
* 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为
|
||||
* 阅读 [Pod 优先级](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -23,10 +23,8 @@ topology of the cluster. For example, a service can specify that traffic be
|
|||
preferentially routed to endpoints that are on the same Node as the client, or
|
||||
in the same availability zone.
|
||||
-->
|
||||
|
||||
`Service` 拓扑可以让一个服务基于集群的 `Node` 拓扑进行流量路由。例如，一个服务可以指定流量是被优先路由到一个和客户端在同一个 `Node` 或者在同一可用区域的端点。
|
||||
|
||||
|
||||
服务拓扑（Service Topology）可以让一个服务基于集群的 Node 拓扑进行流量路由。
|
||||
例如，一个服务可以指定流量是被优先路由到一个和客户端在同一个 Node 或者在同一可用区域的端点。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -51,50 +49,20 @@ with it, while intrazonal traffic does not. Other common needs include being abl
|
|||
to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to
|
||||
Nodes connected to the same top-of-rack switch for the lowest latency.
|
||||
-->
|
||||
|
||||
## 介绍 {#introduction}
|
||||
|
||||
默认情况下，发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到任意一个服务后端的地址上。从 Kubernetes 1.7 开始，可以将“外部”流量路由到节点上运行的 pod 上，但不支持 `ClusterIP` 服务，更复杂的拓扑 — 比如分区路由 — 也还不支持。通过允许 `Service` 创建者根据源 `Node` 和目的 `Node` 的标签来定义流量路由策略，`Service` 拓扑特性实现了服务流量的路由。
|
||||
默认情况下，发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到任意一个服务后端的地址上。
|
||||
从 Kubernetes 1.7 开始，可以将“外部”流量路由到节点上运行的 Pod 上，但不支持 `ClusterIP` 服务，
|
||||
更复杂的拓扑 — 比如分区路由 — 也还不支持。
|
||||
通过允许 `Service` 创建者根据源 `Node` 和目的 `Node` 的标签来定义流量路由策略，
|
||||
服务拓扑特性实现了服务流量的路由。
|
||||
|
||||
通过对源 `Node` 和目的 `Node` 标签的匹配，运营者可以使用任何符合运营者要求的度量值来指定彼此“较近”和“较远”的节点组。例如，对于在公有云上的运营者来说，更偏向于把流量控制在同一区域内，因为区域间的流量是有费用成本的，而区域内的流量没有。其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上，或者把保持流量在连接同一机架交换机的 `Node` 上，以获得低延时。
|
||||
|
||||
<!--
|
||||
## Prerequisites
|
||||
|
||||
The following prerequisites are needed in order to enable topology aware service
|
||||
routing:
|
||||
|
||||
* Kubernetes 1.17 or later
|
||||
* Kube-proxy running in iptables mode or IPVS mode
|
||||
* Enable [Endpoint Slices](/zh/docs/concepts/services-networking/endpoint-slices/)
|
||||
-->
|
||||
|
||||
## 前提条件 {#prerequisites}
|
||||
|
||||
为了启用拓扑感知服务路由功能，必须要满足以下一些前提条件：
|
||||
|
||||
* Kubernetes 的版本不低于 1.17
|
||||
* Kube-proxy 运行在 iptables 模式或者 IPVS 模式
|
||||
* 启用 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/)功能
|
||||
|
||||
<!--
|
||||
## Enable Service Topology
|
||||
|
||||
To enable service topology, enable the `ServiceTopology` feature gate for
|
||||
kube-apiserver and kube-proxy:
|
||||
|
||||
```
|
||||
--feature-gates="ServiceTopology=true"
|
||||
```
|
||||
-->
|
||||
|
||||
## 启用 `Service` 拓扑 {#enable-service-topology}
|
||||
|
||||
要启用 `Service` 拓扑，就要给 kube-apiserver 和 kube-proxy 启用 `ServiceTopology` 功能：
|
||||
|
||||
```
|
||||
--feature-gates="ServiceTopology=true"
|
||||
```
|
||||
通过对源 `Node` 和目的 `Node` 标签的匹配，运营者可以使用任何符合运营者要求的度量值
|
||||
来指定彼此“较近”和“较远”的节点组。
|
||||
例如，对于在公有云上的运营者来说，更偏向于把流量控制在同一区域内，
|
||||
因为区域间的流量是有费用成本的，而区域内的流量没有。
|
||||
其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上，或者
|
||||
把保持流量在连接同一机架交换机的 `Node` 上，以获得低延时。
|
||||
|
||||
<!--
|
||||
## Using Service Topology
|
||||
|
|
@ -116,11 +84,21 @@ be used to mean "any topology". This catch-all value, if used, only makes sense
|
|||
as the last value in the list.
|
||||
-->
|
||||
|
||||
## 使用 `Service` 拓扑 {#using-service-topology}
|
||||
## 使用服务拓扑 {#using-service-topology}
|
||||
|
||||
如果集群启用了 `Service` 拓扑功能后，就可以在 `Service` 配置中指定 `topologyKeys` 字段，从而控制 `Service` 的流量路由。此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。如果这个 `Service` 没有匹配的后端 `Node`，那么第二个标签会被使用做匹配，以此类推，直到没有标签。
|
||||
如果集群启用了服务拓扑功能后，就可以在 `Service` 配置中指定 `topologyKeys` 字段，
|
||||
从而控制 `Service` 的流量路由。
|
||||
此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。
|
||||
流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。
|
||||
如果这个 `Service` 没有匹配的后端 `Node`，那么第二个标签会被使用做匹配，
|
||||
以此类推，直到没有标签。
|
||||
|
||||
如果没有匹配到，流量会被拒绝，就如同这个 `Service` 根本没有后端。这是根据有可用后端的第一个拓扑键来选择端点的。如果这个字段被配置了而没有后端可以匹配客户端拓扑，那么这个 `Service` 对那个客户端是没有后端的，链接应该是失败的。这个字段配置为 `"*"` 意味着任意拓扑。这个通配符值如果使用了，那么只有作为配置值列表中的最后一个才有用。
|
||||
如果没有匹配到，流量会被拒绝，就如同这个 `Service` 根本没有后端。
|
||||
换言之，系统根据可用后端的第一个拓扑键来选择端点。
|
||||
如果这个字段被配置了而没有后端可以匹配客户端拓扑，那么这个 `Service`
|
||||
对那个客户端是没有后端的，链接应该是失败的。
|
||||
这个字段配置为 `"*"` 意味着任意拓扑。
|
||||
这个通配符值如果使用了，那么只有作为配置值列表中的最后一个才有用。
|
||||
|
||||
<!--
|
||||
If `topologyKeys` is not specified or empty, no topology constraints will be applied.
|
||||
|
|
@ -139,14 +117,18 @@ traffic as follows.
|
|||
none are available within this zone:
|
||||
`["topology.kubernetes.io/zone", "*"]`.
|
||||
-->
|
||||
如果 `topologyKeys` 没有指定或者为空，就没有启用这个拓扑约束。
|
||||
|
||||
如果 `topologyKeys` 没有指定或者为空，就没有启用这个拓扑功能。
|
||||
一个集群中，其 `Node` 的标签被打为其主机名，区域名和地区名。
|
||||
那么就可以设置 `Service` 的 `topologyKeys` 的值，像下面的做法一样定向流量了。
|
||||
|
||||
一个集群中，其 `Node` 的标签被打为其主机名，区域名和地区名。那么就可以设置 `Service` 的 `topologyKeys` 的值，像下面的做法一样定向流量了。
|
||||
|
||||
* 只定向到同一个 `Node` 上的端点，`Node` 上没有端点存在时就失败：配置 `["kubernetes.io/hostname"]`。
|
||||
* 偏向定向到同一个 `Node` 上的端点，回退同一区域的端点上，然后是同一地区，其它情况下就失败：配置 `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。这或许很有用，例如，数据局部性很重要的情况下。
|
||||
* 偏向于同一区域，但如果此区域中没有可用的终结点，则回退到任何可用的终结点：配置 `["topology.kubernetes.io/zone", "*"]`。
|
||||
* 只定向到同一个 `Node` 上的端点，`Node` 上没有端点存在时就失败：
|
||||
配置 `["kubernetes.io/hostname"]`。
|
||||
* 偏向定向到同一个 `Node` 上的端点，回退同一区域的端点上，然后是同一地区，
|
||||
其它情况下就失败：配置 `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。
|
||||
这或许很有用，例如，数据局部性很重要的情况下。
|
||||
* 偏向于同一区域，但如果此区域中没有可用的终结点，则回退到任何可用的终结点：
|
||||
配置 `["topology.kubernetes.io/zone", "*"]`。
|
||||
|
||||
<!--
|
||||
## Constraints
|
||||
|
|
@ -168,25 +150,22 @@ traffic as follows.
|
|||
|
||||
## 约束条件 {#constraints}
|
||||
|
||||
* `Service` 拓扑和 `externalTrafficPolicy=Local` 是不兼容的，所以 `Service` 不能同时使用这两种特性。但是在同一个集群的不同 `Service` 上是可以分别使用这两种特性的，只要不在同一个 `Service` 上就可以。
|
||||
* 服务拓扑和 `externalTrafficPolicy=Local` 是不兼容的，所以 `Service` 不能同时使用这两种特性。
|
||||
但是在同一个集群的不同 `Service` 上是可以分别使用这两种特性的，只要不在同一个 `Service` 上就可以。
|
||||
|
||||
* 有效的拓扑键目前只有：`kubernetes.io/hostname`，`topology.kubernetes.io/zone` 和 `topology.kubernetes.io/region`，但是未来会推广到其它的 `Node` 标签。
|
||||
* 有效的拓扑键目前只有：`kubernetes.io/hostname`、`topology.kubernetes.io/zone` 和
|
||||
`topology.kubernetes.io/region`，但是未来会推广到其它的 `Node` 标签。
|
||||
|
||||
* 拓扑键必须是有效的标签，并且最多指定16个。
|
||||
|
||||
* 通配符：`"*"`，如果要用，那必须是拓扑键值的最后一个值。
|
||||
|
||||
|
||||
* 通配符：`"*"`，如果要用，则必须是拓扑键值的最后一个值。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
|
||||
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
|
||||
-->
|
||||
|
||||
* 阅读关于[启用服务拓扑](/docs/tasks/administer-cluster/enabling-service-topology)
|
||||
* 阅读[用 `Services` 连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
* 阅读关于[启用服务拓扑](/zh/docs/tasks/administer-cluster/enabling-service-topology/)
|
||||
* 阅读[用服务连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,10 @@ title: 持久卷
|
|||
feature:
|
||||
title: 存储编排
|
||||
description: >
|
||||
自动挂载所选存储系统，包括本地存储、诸如 <a href="https://cloud.google.com/storage/">GCP</a> 或 <a href="https://aws.amazon.com/products/storage/">AWS</a> 之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder 或 Flocker 这类网络存储系统。
|
||||
自动挂载所选存储系统，包括本地存储、诸如 <a href="https://cloud.google.com/storage/">GCP</a>
|
||||
或 <a href="https://aws.amazon.com/products/storage/">AWS</a>
|
||||
之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder
|
||||
或 Flocker 这类网络存储系统。
|
||||
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -1053,7 +1056,7 @@ be bound to the PVC.
|
|||
### 类 {#class}
|
||||
|
||||
申领可以通过为 `storageClassName` 属性设置
|
||||
[StorageClass](/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。
|
||||
[StorageClass](/zh/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。
|
||||
只有所请求的类的 PV 卷，即 `storageClassName` 值与 PVC 设置相同的 PV 卷，
|
||||
才能绑定到 PVC 申领。
|
||||
|
||||
|
|
|
|||
|
|
@ -23,11 +23,13 @@ Tracking storage capacity is supported for {{< glossary_tooltip
|
|||
text="Container Storage Interface" term_id="csi" >}} (CSI) drivers and
|
||||
[needs to be enabled](#enabling-storage-capacity-tracking) when installing a CSI driver.
|
||||
-->
|
||||
存储容量是有限的，并且会因为运行 pod 的节点不同而变化：网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。
|
||||
存储容量是有限的，并且会因为运行 Pod 的节点不同而变化：
|
||||
网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
|
||||
|
||||
本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将 Pod 调度到能够访问到足够存储容量的节点上。
|
||||
本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将
|
||||
Pod 调度到能够访问到足够存储容量的节点上。
|
||||
如果没有跟踪存储容量，调度程序可能会选择一个没有足够容量来提供卷的节点，并且需要多次调度重试。
|
||||
|
||||
{{< glossary_tooltip text="容器存储接口" term_id="csi" >}}（CSI）驱动程序支持跟踪存储容量，
|
||||
|
|
@ -51,9 +53,10 @@ There are two API extensions for this feature:
|
|||
|
||||
这个特性有两个 API 扩展接口：
|
||||
- [CSIStorageCapacity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csistoragecapacity-v1alpha1-storage-k8s-io)
|
||||
对象：这些对象由 CSI 驱动程序在安装驱动程序的命名空间中产生。每个对象都包含一个存储类的容量信息，并定义哪些节点可以访问该存储。
|
||||
对象：这些对象由 CSI 驱动程序在安装驱动程序的命名空间中产生。
|
||||
每个对象都包含一个存储类的容量信息，并定义哪些节点可以访问该存储。
|
||||
- [`CSIDriverSpec.StorageCapacity` 字段](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io)：
|
||||
设置为 true 时，Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。
|
||||
设置为 true 时，Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。
|
||||
|
||||
<!--
|
||||
## Scheduling
|
||||
|
|
@ -163,9 +166,11 @@ parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
|
|||
-->
|
||||
## 开启存储容量跟踪
|
||||
|
||||
存储容量跟踪是一个 *alpha 特性*，只有当 `CSIStorageCapacity` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
存储容量跟踪是一个 *alpha 特性*，只有当 `CSIStorageCapacity`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
和 `storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API 组" term_id="api-group" >}}启用时才能启用。
|
||||
更多详细信息，可以查看`--feature-gates` 和 `--runtime-config` [kube-apiserver 参数](/docs/reference/command-line-tools-reference/kube-apiserver/)。
|
||||
更多详细信息，可以查看`--feature-gates` 和 `--runtime-config`
|
||||
[kube-apiserver 参数](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)。
|
||||
|
||||
<!--
|
||||
A quick check
|
||||
|
|
@ -203,6 +208,7 @@ support it. Please refer to the driver's documentation for
|
|||
details.
|
||||
-->
|
||||
如果不支持，下面这个错误就会被打印出来：
|
||||
|
||||
```
|
||||
error: the server doesn't have a resource type "csistoragecapacities"
|
||||
```
|
||||
|
|
@ -218,6 +224,8 @@ error: the server doesn't have a resource type "csistoragecapacities"
|
|||
- For more information on further development of this feature, see the [enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472).
|
||||
- Learn about [Kubernetes Scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
-->
|
||||
- 想要获得更多该设计的信息，查看 [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)。
|
||||
- 有关此功能的进一步开发信息，查看[enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472)。
|
||||
- 学习 [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)。
|
||||
- 想要获得更多该设计的信息，查看
|
||||
[Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)。
|
||||
- 有关此功能的进一步开发信息，查看
|
||||
[enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472)。
|
||||
- 学习 [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)。
|
||||
|
|
|
|||
|
|
@ -1190,7 +1190,7 @@ iSCSI volume) without knowing the details of the particular cloud environment.
|
|||
See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/) for more
|
||||
details.
|
||||
-->
|
||||
更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/)。
|
||||
更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/)。
|
||||
|
||||
### portworxVolume {#portworxvolume}
|
||||
|
||||
|
|
@ -1371,7 +1371,9 @@ for the current [service account](/docs/reference/access-authn-authz/authenticat
|
|||
into a Pod at a specified path. Below is an example:
|
||||
-->
|
||||
|
||||
当开启 `TokenRequestProjection` 功能时，可以将当前 [服务帐户](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的令牌注入 Pod 中的指定路径。
|
||||
当开启 `TokenRequestProjection` 功能时，可以将当前
|
||||
[服务帐号](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)
|
||||
的令牌注入 Pod 中的指定路径。
|
||||
下面是一个例子：
|
||||
|
||||
```yaml
|
||||
|
|
@ -1455,7 +1457,8 @@ GitHub project has [instructions](https://github.com/quobyte/quobyte-csi#quobyte
|
|||
-->
|
||||
Quobyte 支持{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}。
|
||||
推荐使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。
|
||||
Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi)
|
||||
Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的
|
||||
[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi)
|
||||
及使用示例。
|
||||
|
||||
### rbd
|
||||
|
|
@ -1748,7 +1751,8 @@ spec:
|
|||
<!--
|
||||
For more information, see the [vSphere volume](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) examples.
|
||||
-->
|
||||
进一步信息可参考[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。
|
||||
进一步信息可参考
|
||||
[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。
|
||||
|
||||
<!--
|
||||
#### vSphere CSI migration {#vsphere-csi-migration}
|
||||
|
|
@ -1766,7 +1770,8 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationvSphere
|
|||
-->
|
||||
当 `vsphereVolume` 的 `CSIMigration` 特性被启用时，所有插件操作都被从树内插件重定向到
|
||||
`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。
|
||||
为了使用此功能特性，必须在集群中安装[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)，
|
||||
为了使用此功能特性，必须在集群中安装
|
||||
[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)，
|
||||
并启用 `CSIMigration` 和 `CSIMigrationvSphere`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -114,5 +114,5 @@ mechanisms for separating code from configuration.
|
|||
一旦你的应用处于运行状态，你就可能想要
|
||||
以[服务](/zh/docs/concepts/services-networking/service/)
|
||||
使之在互联网上可访问；或者对于 Web 应用而言，使用
|
||||
[Ingress](/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。
|
||||
[Ingress](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。
|
||||
|
||||
|
|
|
|||
|
|
@ -174,20 +174,6 @@ If the `.spec.selector` is specified, it must match the `.spec.template.metadata
|
|||
如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。
|
||||
如果与后者不匹配，则 DeamonSet 会被 API 拒绝。
|
||||
|
||||
<!--
|
||||
Also you should not normally create any Pods whose labels match this selector, either directly, via
|
||||
another DaemonSet, or via another workload resource such as ReplicaSet. Otherwise, the DaemonSet
|
||||
{{< glossary_tooltip term_id="controller" >}} will think that those Pods were created by it.
|
||||
Kubernetes will not stop you from doing this. One case where you might want to do this is manually
|
||||
create a Pod with a different value on a node for testing.
|
||||
-->
|
||||
另外，通常不应直接通过另一个 DaemonSet 或另一个工作负载资源（例如 ReplicaSet）
|
||||
来创建其标签与该选择器匹配的任何 Pod。否则，DaemonSet
|
||||
{{< glossary_tooltip term_text="控制器" term_id="controller" >}}
|
||||
会认为这些 Pod 是由它创建的。
|
||||
Kubernetes 不会阻止你这样做。
|
||||
你可能要执行此操作的一种情况是，手动在节点上创建具有不同值的 Pod 进行测试。
|
||||
|
||||
<!--
|
||||
### Running Pods on Only Some Nodes
|
||||
|
||||
|
|
@ -236,7 +222,7 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。
|
|||
|
||||
* Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态，
|
||||
DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。
|
||||
* [Pod 抢占](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/)
|
||||
由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占
|
||||
的情况下制定调度决策。
|
||||
|
||||
|
|
|
|||
|
|
@ -405,7 +405,7 @@ be rejected by the API.
|
|||
### Pod 选择算符 {#pod-selector}
|
||||
|
||||
`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。
|
||||
如前文中[所讨论的](how-a-replicaset-works)，这些是用来标识要被获取的 Pods
|
||||
如前文中[所讨论的](#how-a-replicaset-works)，这些是用来标识要被获取的 Pods
|
||||
的标签。在签名的 `frontend.yaml` 示例中，选择算符为：
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue