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

Merge pull request #15823 from simplytunde/dev-1.16-merge-master

Browse Source 
merge master into dev-1.16
This commit is contained in:
Kubernetes Prow Robot
2019-08-13 10:11:42 -07:00
committed by GitHub
parent 6daa99cdd8 5e8cf9b8a5
commit 59757291e1
99 changed files with 1827 additions and 706 deletions
Download Patch File Download Diff File Expand all files Collapse all files
OWNERS_ALIASES
+1
View File
@@ -41,6 +41,7 @@ aliases:
- bradtopol
- chenopis
- cody-clark
- gochist
- jaredbhatti
- jimangel
- kbarnard10
content/de/docs/concepts/cluster-administration/controller-metrics.md
+41
View File
@@ -0,0 +1,41 @@
---
title: Controller Manager Metriken
content_template: templates/concept
weight: 100
---
{{% capture overview %}}
Controller Manager Metriken liefern wichtige Erkenntnisse über die Leistung und den Zustand von den Controller Managern.
{{% /capture %}}
{{% capture body %}}
## Was sind Controller Manager Metriken
Die Kennzahlen des Controller Managers liefert wichtige Erkenntnisse über die Leistung und den Zustand des Controller Managers.
Diese Metriken beinhalten gängige Go Language Laufzeitmetriken wie go_routine count und controller-spezifische Metriken wie z.B.
etcd Request Latenzen oder Cloud Provider (AWS, GCE, OpenStack) API Latenzen, die verwendet werden können um den Zustand eines Clusters zu messen.
Ab Kubernetes 1.7 stehen detaillierte Cloud Provider Metriken für den Speicherbetrieb für GCE, AWS, Vsphere und OpenStack zur Verfügung.
Diese Metriken können verwendet werden, um den Zustand persistenter Datenträgeroperationen zu überwachen.
Für GCE werden diese Metriken beispielsweise wie folgt aufgerufen:
```
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
```
## Konfiguration
In einem Cluster sind die Controller Manager Metriken unter `http://localhost:10252/metrics` auf dem Host verfügbar, auf dem der Controller Manager läuft.
Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrumenting/exposition_formats/) ausgegeben.
In einer Produktionsumgebung können Sie Prometheus oder einen anderen Metrik Scraper konfigurieren, um diese Metriken regelmäßig zu sammeln und in einer Art Zeitreihen Datenbank verfügbar zu machen.
{{% /capture %}}
content/de/docs/concepts/cluster-administration/proxies.md
+64
View File
@@ -0,0 +1,64 @@
---
title: Proxies in Kubernetes
content_template: templates/concept
weight: 90
---
{{% capture overview %}}
Auf dieser Seite werden die im Kubernetes verwendeten Proxies erläutert.
{{% /capture %}}
{{% capture body %}}
## Proxies
Es gibt mehrere verschiedene Proxies, die die bei der Verwendung von Kubernetes begegnen können:
1. Der [kubectl Proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
- läuft auf dem Desktop eines Benutzers oder in einem Pod
- Proxy von einer lokalen Host-Adresse zum Kubernetes API Server
- Client zu Proxy verwendet HTTP
- Proxy zu API Server verwendet HTTPS
- lokalisiert den API Server
- fügt Authentifizierungs-Header hinzu
1. Der [API Server Proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
- ist eine Bastion, die in den API Server eingebaut ist
- verbindet einen Benutzer außerhalb des Clusters mit Cluster IPs, die sonst möglicherweise nicht erreichbar wären
- läuft im API Server Prozess
- Client zu Proxy verwendet HTTPS (oder http, wenn API Server so konfiguriert ist)
- Proxy zum Ziel kann HTTP oder HTTPS verwenden, der Proxy wählt dies unter Verwendung der verfügbaren Informationen aus
- kann verwendet werden, um einen Knoten, Pod oder Service zu erreichen
- führt einen Lastausgleich durch um einen Service zu erreichen, wenn dieser verwendet wird
1. Der [kube Proxy](/docs/concepts/services-networking/service/#ips-and-vips):
- läuft auf jedem Knoten
- Proxy unterstüzt UDP, TCP und SCTP
- versteht kein HTTP
- stellt Lastausgleich zur Verfügung
- wird nur zum erreichen von Services verwendet
1. Ein Proxy/Load-balancer vor dem API Server:
- Existenz und Implementierung variieren von Cluster zu Cluster (z.B. nginx)
- sitzt zwischen allen Clients und einem oder mehreren API Servern
- fungiert als Load Balancer, wenn es mehrere API Server gibt
1. Cloud Load Balancer für externe Services:
- wird von einigen Cloud Anbietern angeboten (z.B. AWS ELB, Google Cloud Load Balancer)
- werden automatisch erstellt, wenn der Kubernetes Service den Typ `LoadBalancer` hat
- unterstützt normalerweiße nur UDP/TCP
- Die SCTP-Unterstützung hängt von der Load Balancer Implementierung des Cloud Providers ab
- die Implementierung variiert je nach Cloud Anbieter
Kubernetes Benutzer müssen sich in der Regel um nichts anderes als die ersten beiden Typen kümmern. Der Cluster Administrator stellt in der Regel sicher, dass die letztgenannten Typen korrekt eingerichtet sind.
## Anforderung an Umleitungen
Proxies haben die Möglichkeit der Umleitung (redirect) ersetzt. Umleitungen sind veraltet.
{{% /capture %}}
content/de/docs/reference/kubectl/cheatsheet.md
+1 -1
View File
@@ -322,7 +322,7 @@ Ausgabeformat | Beschreibung
### Kubectl Ausgabe Ausführlichkeit und Debugging
Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v ` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md) beschrieben.
Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v ` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) beschrieben.
Ausführlichkeit | Beschreibung
--------------| -----------
content/en/blog/OWNERS
-3
View File
@@ -2,9 +2,6 @@
# Owned by Kubernetes Blog reviewers
options:
no_parent_owners: false
approvers:
- sig-docs-blog-owners # Defined in OWNERS_ALIASES
content/en/blog/_posts/2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md
+194
View File
@@ -0,0 +1,194 @@
---
layout: blog
title: "OPA Gatekeeper: Policy and Governance for Kubernetes"
date: 2019-08-06
slug: OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes
---
**Authors:** Rita Zhang (Microsoft), Max Smythe (Google), Craig Hooper (Commonwealth Bank AU), Tim Hinrichs (Styra), Lachie Evenson (Microsoft), Torin Sandall (Styra)
The [Open Policy Agent Gatekeeper](https://github.com/open-policy-agent/gatekeeper) project can be leveraged to help enforce policies and strengthen governance in your Kubernetes environment. In this post, we will walk through the goals, history, and current state of the project.
The following recordings from the Kubecon EU 2019 sessions are a great starting place in working with Gatekeeper:
* [Intro: Open Policy Agent Gatekeeper](https://youtu.be/Yup1FUc2Qn0)
* [Deep Dive: Open Policy Agent](https://youtu.be/n94_FNhuzy4)
## Motivations
If your organization has been operating Kubernetes, you probably have been looking for ways to control what end-users can do on the cluster and ways to ensure that clusters are in compliance with company policies. These policies may be there to meet governance and legal requirements or to enforce best practices and organizational conventions. With Kubernetes, how do you ensure compliance without sacrificing development agility and operational independence?
For example, you can enforce policies like:
* All images must be from approved repositories
* All ingress hostnames must be globally unique
* All pods must have resource limits
* All namespaces must have a label that lists a point-of-contact
Kubernetes allows decoupling policy decisions from the API server by means of [admission controller webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) to intercept admission requests before they are persisted as objects in Kubernetes. [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) was created to enable users to customize admission control via configuration, not code and to bring awareness of the cluster’s state, not just the single object under evaluation at admission time. Gatekeeper is a customizable admission webhook for Kubernetes that enforces policies executed by the [Open Policy Agent (OPA)](https://www.openpolicyagent.org), a policy engine for Cloud Native environments hosted by CNCF.
## Evolution
Before we dive into the current state of Gatekeeper, let’s take a look at how the Gatekeeper project has evolved.
* Gatekeeper v1.0 - Uses OPA as the admission controller with the kube-mgmt sidecar enforcing configmap-based policies. It provides validating and mutating admission control. Donated by Styra.
* Gatekeeper v2.0 - Uses Kubernetes policy controller as the admission controller with OPA and kube-mgmt sidecars enforcing configmap-based policies. It provides validating and mutating admission control and audit functionality. Donated by Microsoft.
* Gatekeeper v3.0 - The admission controller is integrated with the [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) to enforce CRD-based policies and allow declaratively configured policies to be reliably shareable. Built with kubebuilder, it provides validating and, eventually, mutating (to be implemented) admission control and audit functionality. This enables the creation of policy templates for [Rego](https://www.openpolicyagent.org/docs/latest/how-do-i-write-policies/) policies, creation of policies as CRDs, and storage of audit results on policy CRDs. This project is a collaboration between Google, Microsoft, Red Hat, and Styra.
![](/images/blog/2019-08-06-opa-gatekeeper/v3.png)
## Gatekeeper v3.0 Features
Now let’s take a closer look at the current state of Gatekeeper and how you can leverage all the latest features. Consider an organization that wants to ensure all objects in a cluster have departmental information provided as part of the object’s labels. How can you do this with Gatekeeper?
### Validating Admission Control
Once all the Gatekeeper components have been [installed](https://github.com/open-policy-agent/gatekeeper) in your cluster, the API server will trigger the Gatekeeper admission webhook to process the admission request whenever a resource in the cluster is created, updated, or deleted.
During the validation process, Gatekeeper acts as a bridge between the API server and OPA. The API server will enforce all policies executed by OPA.
### Policies and Constraints
With the integration of the OPA Constraint Framework, a Constraint is a declaration that its author wants a system to meet a given set of requirements. Each Constraint is written with Rego, a declarative query language used by OPA to enumerate instances of data that violate the expected state of the system. All Constraints are evaluated as a logical AND. If one Constraint is not satisfied, then the whole request is rejected.
Before defining a Constraint, you need to create a Constraint Template that allows people to declare new Constraints. Each template describes both the Rego logic that enforces the Constraint and the schema for the Constraint, which includes the schema of the CRD and the parameters that can be passed into a Constraint, much like arguments to a function.
For example, here is a Constraint template CRD that requires certain labels to be present on an arbitrary object.
```yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8srequiredlabels
spec:
crd:
spec:
names:
kind: K8sRequiredLabels
listKind: K8sRequiredLabelsList
plural: k8srequiredlabels
singular: k8srequiredlabels
validation:
# Schema for the `parameters` field
openAPIV3Schema:
properties:
labels:
type: array
items: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8srequiredlabels
deny[{"msg": msg, "details": {"missing_labels": missing}}] {
provided := {label | input.review.object.metadata.labels[label]}
required := {label | label := input.parameters.labels[_]}
missing := required - provided
count(missing) > 0
msg := sprintf("you must provide labels: %v", [missing])
}
```
Once a Constraint template has been deployed in the cluster, an admin can now create individual Constraint CRDs as defined by the Constraint template. For example, here is a Constraint CRD that requires the label `hr` to be present on all namespaces.
```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-hr
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Namespace"]
parameters:
labels: ["hr"]
```
Similarly, another Constraint CRD that requires the label `finance` to be present on all namespaces can easily be created from the same Constraint template.
```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-finance
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Namespace"]
parameters:
labels: ["finance"]
```
As you can see, with the Constraint framework, we can reliably share Regos via the Constraint templates, define the scope of enforcement with the match field, and provide user-defined parameters to the Constraints to create customized behavior for each Constraint.
### Audit
The audit functionality enables periodic evaluations of replicated resources against the Constraints enforced in the cluster to detect pre-existing misconfigurations. Gatekeeper stores audit results as `violations` listed in the `status` field of the relevant Constraint.
```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-hr
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Namespace"]
parameters:
labels: ["hr"]
status:
auditTimestamp: "2019-08-06T01:46:13Z"
byPod:
- enforced: true
id: gatekeeper-controller-manager-0
violations:
- enforcementAction: deny
kind: Namespace
message: 'you must provide labels: {"hr"}'
name: default
- enforcementAction: deny
kind: Namespace
message: 'you must provide labels: {"hr"}'
name: gatekeeper-system
- enforcementAction: deny
kind: Namespace
message: 'you must provide labels: {"hr"}'
name: kube-public
- enforcementAction: deny
kind: Namespace
message: 'you must provide labels: {"hr"}'
name: kube-system
```
### Data Replication
Audit requires replication of Kubernetes resources into OPA before they can be evaluated against the enforced Constraints. Data replication is also required by Constraints that need access to objects in the cluster other than the object under evaluation. For example, a Constraint that enforces uniqueness of ingress hostname must have access to all other ingresses in the cluster.
To configure Kubernetes data to be replicated, create a sync config resource with the resources to be replicated into OPA. For example, the below configuration replicates all namespace and pod resources to OPA.
```yaml
apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
name: config
namespace: "gatekeeper-system"
spec:
sync:
syncOnly:
- group: ""
version: "v1"
kind: "Namespace"
- group: ""
version: "v1"
kind: "Pod"
```
## Planned for Future
The community behind the Gatekeeper project will be focusing on providing mutating admission control to support mutation scenarios (for example: annotate objects automatically with departmental information when creating a new resource), support external data to inject context external to the cluster into the admission decisions, support dry run to see impact of a policy on existing resources in the cluster before enforcing it, and more audit functionalities.
If you are interested in learning more about the project, check out the [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) repo. If you are interested in helping define the direction of Gatekeeper, join the [#kubernetes-policy](https://openpolicyagent.slack.com/messages/CDTN970AX) channel on OPA Slack, and join our [weekly meetings](https://docs.google.com/document/d/1A1-Q-1OMw3QODs1wT6eqfLTagcGmgzAJAjJihiO3T48/edit) to discuss development, issues, use cases, etc.
content/en/case-studies/spotify/index.html
+1 -1
View File
@@ -1,5 +1,5 @@
---
title: Spotify study Case Study
title: Spotify Case Study
linkTitle: Spotify
case_study_styles: true
cid: caseStudies
content/en/docs/concepts/architecture/nodes.md
+2 -3
View File
@@ -111,9 +111,8 @@ on a Node.
### Info
General information about the node, such as kernel version, Kubernetes version
(kubelet and kube-proxy version), Docker version (if used), OS name.
The information is gathered by Kubelet from the node.
Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name.
This information is gathered by Kubelet from the node.
## Management
content/en/docs/concepts/containers/images.md
+2 -2
View File
@@ -70,7 +70,7 @@ Credentials can be provided in several ways:
- Configuring Nodes to Authenticate to a Private Registry
- all pods can read any configured private registries
- requires node configuration by cluster administrator
- Pre-pulling Images
- Pre-pulled Images
- all pods can use any images cached on a node
- requires root access to all nodes to setup
- Specifying ImagePullSecrets on a Pod
@@ -243,7 +243,7 @@ template needs to include the `.docker/config.json` or mount a drive that contai
All pods will have read access to images in any private registry once private
registry keys are added to the `.docker/config.json`.
### Pre-pulling Images
### Pre-pulled Images
{{< note >}}
If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+75 -51
View File
@@ -6,31 +6,33 @@ content_template: templates/concept
weight: 20
---
{{< feature-state state="beta" >}}
{{% capture overview %}}
Starting in version 1.8, Kubernetes provides a
[device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
for vendors to advertise their resources to the kubelet without changing Kubernetes core code.
Instead of writing custom Kubernetes code, vendors can implement a device plugin that can
be deployed manually or as a DaemonSet. The targeted devices include GPUs,
High-performance NICs, FPGAs, InfiniBand, and other similar computing resources
that may require vendor specific initialization and setup.
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
that you can use to advertise system hardware resources to the
{{< glossary_tooltip term_id="kubelet" >}}.
Instead of customising the code for Kubernetes itself, vendors can implement a
device plugin that you deploy either manually or as a {{< glossary_tooltip term_id="daemonset" >}}.
The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adapters,
and other similar computing resources that may require vendor specific initialization
and setup.
{{% /capture %}}
{{% capture body %}}
## Device plugin registration
The device plugins feature is gated by the `DevicePlugins` feature gate which
is disabled by default before 1.10. When the device plugins feature is enabled,
the kubelet exports a `Registration` gRPC service:
The kubelet exports a `Registration` gRPC service:
```gRPC
service Registration {
rpc Register(RegisterRequest) returns (Empty) {}
}
```
A device plugin can register itself with the kubelet through this gRPC service.
During the registration, the device plugin needs to send:
@@ -38,15 +40,15 @@ During the registration, the device plugin needs to send:
* The Device Plugin API version against which it was built.
* The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
[extended resource naming scheme](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
as `vendor-domain/resource`.
For example, an Nvidia GPU is advertised as `nvidia.com/gpu`.
as `vendor-domain/resourcetype`.
(For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)
Following a successful registration, the device plugin sends the kubelet the
list of devices it manages, and the kubelet is then in charge of advertising those
resources to the API server as part of the kubelet node status update.
For example, after a device plugin registers `vendor-domain/foo` with the kubelet
For example, after a device plugin registers `hardware-vendor.example/foo` with the kubelet
and reports two healthy devices on a node, the node status is updated
to advertise 2 `vendor-domain/foo`.
to advertise that the node has 2 “Foo” devices installed and available.
Then, users can request devices in a
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
@@ -55,10 +57,11 @@ specification as they request other types of resources, with the following limit
* Extended resources are only supported as integer resources and cannot be overcommitted.
* Devices cannot be shared among Containers.
Suppose a Kubernetes cluster is running a device plugin that advertises resource `vendor-domain/resource`
on certain nodes, here is an example user pod requesting this resource:
Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo`
on certain nodes. Here is an example of a pod requesting this resource to run a demo workload:
```yaml
---
apiVersion: v1
kind: Pod
metadata:
@@ -69,7 +72,14 @@ spec:
image: k8s.gcr.io/pause:2.0
resources:
limits:
vendor-domain/resource: 2 # requesting 2 vendor-domain/resource
hardware-vendor.example/foo: 2
#
# This Pod needs 2 of the hardware-vendor.example/foo devices
# and can only schedule onto a Node that's able to satisfy
# that need.
#
# If the Node has more than 2 of those devices available, the
# remainder would be available for other Pods to use.
```
## Device plugin implementation
@@ -107,6 +117,8 @@ If the operations succeed, the device plugin returns an `AllocateResponse` that
runtime configurations for accessing the allocated devices. The kubelet passes this information
to the container runtime.
### Handling kubelet restarts
A device plugin is expected to detect kubelet restarts and re-register itself with the new
kubelet instance. In the current implementation, a new kubelet instance deletes all the existing Unix sockets
under `/var/lib/kubelet/device-plugins` when it starts. A device plugin can monitor the deletion
@@ -114,37 +126,44 @@ of its Unix socket and re-register itself upon such an event.
## Device plugin deployment
A device plugin can be deployed manually or as a DaemonSet. Being deployed as a DaemonSet has
the benefit that Kubernetes can restart the device plugin if it fails.
Otherwise, an extra mechanism is needed to recover from device plugin failures.
You can deploy a device plugin as a DaemonSet, as a package for your node's operating system,
or manually.
The canonical directory `/var/lib/kubelet/device-plugins` requires privileged access,
so a device plugin must run in a privileged security context.
If a device plugin is running as a DaemonSet, `/var/lib/kubelet/device-plugins`
must be mounted as a
[Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
If you're deploying a device plugin as a DaemonSet, `/var/lib/kubelet/device-plugins`
must be mounted as a {{< glossary_tooltip term_id="volume" >}}
in the plugin's
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
Kubernetes device plugin support is in beta. As development continues, its API version can
change. We recommend that device plugin developers do the following:
If you choose the DaemonSet approach you can rely on Kubernetes to: place the device plugin's
Pod onto Nodes, to restart the daemon Pod after failure, and to help automate upgrades.
## API compatibility
Kubernetes device plugin support is in beta. The API may change before stabilization,
in incompatible ways. As a project, Kubernetes recommends that device plugin developers:
* Watch for changes in future releases.
* Support multiple versions of the device plugin API for backward/forward compatibility.
If you enable the DevicePlugins feature and run device plugins on nodes that need to be upgraded to
a Kubernetes release with a newer device plugin API version, upgrade your device plugins
to support both versions before upgrading these nodes to
to support both versions before upgrading these nodes. Taking that approach will
ensure the continuous functioning of the device allocations during the upgrade.
## Monitoring Device Plugin Resources
In order to monitor resources provided by device plugins, monitoring agents need to be able to
discover the set of devices that are in-use on the node and obtain metadata to describe which
container the metric should be associated with. Prometheus metrics exposed by device monitoring
agents should follow the
[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md),
which requires identifying containers using `pod`, `namespace`, and `container` prometheus labels.
The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata
{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
In order to monitor resources provided by device plugins, monitoring agents need to be able to
discover the set of devices that are in-use on the node and obtain metadata to describe which
container the metric should be associated with. [Prometheus](https://prometheus.io/) metrics
exposed by device monitoring agents should follow the
[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md),
identifying containers using `pod`, `namespace`, and `container` prometheus labels.
The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata
for these devices:
```gRPC
@@ -155,31 +174,36 @@ service PodResourcesLister {
}
```
The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.
Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet.
The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
agents must run in a privileged security context. If a device monitoring agent is running as a
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
[Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
in the plugin's
The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.
Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet.
The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
agents must run in a privileged security context. If a device monitoring agent is running as a
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
{{< glossary_tooltip term_id="volume" >}} in the plugin's
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
Support for the "PodResources service" is in beta, and is enabled by default.
## Examples
## Device plugin examples {#examples}
For examples of device plugin implementations, see:
Here are some examples of device plugin implementations:
* The official [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
* Requires [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker) which allows you to run GPU enabled docker containers.
* A detailed guide on how to [schedule NVIDIA GPUs](/docs/tasks/manage-gpus/scheduling-gpus) on k8s.
* The [NVIDIA GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for Intel GPU, FPGA and QuickAssist devices
* The [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) for hardware-assisted virtualization
* The [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
* Requires [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0, which allows you to run GPU-enabled Docker containers.
* The [NVIDIA GPU device plugin for Container-Optimized OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
* The [SRIOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for GPU, FPGA and QuickAssist devices
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
{{% /capture %}}
{{% capture whatsnext %}}
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl-tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
{{% /capture %}}
content/en/docs/concepts/policy/pod-security-policy.md
+5
View File
@@ -420,6 +420,11 @@ The **recommended minimum set** of allowed volumes for new PSPs are:
- secret
- projected
{{< warning >}}
PodSecurityPolicy does not limit the types of `PersistentVolume` objects that may be referenced by a `PersistentVolumeClaim`.
Only trusted users should be granted permission to create `PersistentVolume` objects.
{{< /warning >}}
**FSGroup** - Controls the supplemental group applied to some volumes.
- *MustRunAs* - Requires at least one `range` to be specified. Uses the
content/en/docs/concepts/services-networking/connect-applications-service.md
+6
View File
@@ -134,6 +134,12 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
Kubernetes supports 2 primary modes of finding a Service - environment variables
and DNS. The former works out of the box while the latter requires the
[CoreDNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
{{< note >}}
If the service environment variables are not desired (because possible clashing with expected program ones,
too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks`
flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
{{< /note >}}
### Environment Variables
content/en/docs/concepts/services-networking/ingress.md
+8 -8
View File
@@ -215,7 +215,7 @@ Events:
```
The Ingress controller provisions an implementation-specific load balancer
that satisfies the Ingress, as long as the Services (`s1`, `s2`) exist.
that satisfies the Ingress, as long as the Services (`service1`, `service2`) exist.
When it has done so, you can see the address of the load balancer at the
Address field.
@@ -230,9 +230,9 @@ you are using, you may need to create a default-http-backend
Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
```none
foo.bar.com --| |-> foo.bar.com s1:80
foo.bar.com --| |-> foo.bar.com service1:80
| 178.91.123.132 |
bar.foo.com --| |-> bar.foo.com s2:80
bar.foo.com --| |-> bar.foo.com service2:80
```
The following Ingress tells the backing load balancer to route requests based on
@@ -384,7 +384,7 @@ Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo s1:80 (10.8.0.90:80)
/foo service1:80 (10.8.0.90:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
@@ -407,14 +407,14 @@ spec:
http:
paths:
- backend:
serviceName: s1
serviceName: service1
servicePort: 80
path: /foo
- host: bar.baz.com
http:
paths:
- backend:
serviceName: s2
serviceName: service2
servicePort: 80
path: /foo
..
@@ -438,9 +438,9 @@ Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo s1:80 (10.8.0.90:80)
/foo service1:80 (10.8.0.90:80)
bar.baz.com
/foo s2:80 (10.8.0.91:80)
/foo service2:80 (10.8.0.91:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
content/en/docs/concepts/storage/volumes.md
+8 -8
View File
@@ -149,7 +149,7 @@ spec:
fsType: ext4
```
#### CSI Migration
#### CSI Migration
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
@@ -241,7 +241,7 @@ spec:
fsType: ext4
```
#### CSI Migration
#### CSI Migration
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
@@ -1359,16 +1359,16 @@ documentation](https://kubernetes-csi.github.io/docs/)
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
The CSI Migration feature, when enabled, directs operations against existing in-tree
plugins to corresponding CSI plugins (which are expected to be installed and configured).
The feature implements the necessary translation logic and shims to re-route the
operations in a seamless fashion. As a result, operators do not have to make any
configuration changes to existing Storage Classes, PVs or PVCs (referring to
plugins to corresponding CSI plugins (which are expected to be installed and configured).
The feature implements the necessary translation logic and shims to re-route the
operations in a seamless fashion. As a result, operators do not have to make any
configuration changes to existing Storage Classes, PVs or PVCs (referring to
in-tree plugins) when transitioning to a CSI driver that supersedes an in-tree plugin.
In the alpha state, the operations and features that are supported include
In the alpha state, the operations and features that are supported include
provisioning/delete, attach/detach, mount/unmount and resizing of volumes.
In-tree plugins that support CSI Migration and have a corresponding CSI driver implemented
In-tree plugins that support CSI Migration and have a corresponding CSI driver implemented
are listed in the "Types of Volumes" section above.
### Flexvolume {#flexVolume}
content/en/docs/concepts/workloads/pods/disruptions.md
+2 -2
View File
@@ -169,8 +169,8 @@ The deployment notices that one of the pods is terminating, so it creates a repl
called `pod-d`. Since `node-1` is cordoned, it lands on another node. Something has
also created `pod-y` as a replacement for `pod-x`.
(Note: for a StatefulSet, `pod-a`, which would be called something like `pod-1`, would need
to terminate completely before its replacement, which is also called `pod-1` but has a
(Note: for a StatefulSet, `pod-a`, which would be called something like `pod-0`, would need
to terminate completely before its replacement, which is also called `pod-0` but has a
different UID, could be created. Otherwise, the example applies to a StatefulSet as well.)
Now the cluster is in this state:
content/en/docs/concepts/workloads/pods/pod.md
+1 -1
View File
@@ -154,7 +154,7 @@ and rollout management.
Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
can also provide support to stateful Pods.
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [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), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [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), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
Pod is exposed as a primitive in order to facilitate:
content/en/docs/contribute/start.md
+6 -4
View File
@@ -40,7 +40,7 @@ Not all tasks can be done in the GitHub UI, but these are discussed in the
The Kubernetes documentation is maintained by a
{{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG)
called SIG Docs. We communicate using a Slack channel, a mailing list, and
called SIG Docs. We [communicate](#participate-in-sig-docs-discussions) using a Slack channel, a mailing list, and
weekly video meetings. New participants are welcome. For more information, see
[Participating in SIG Docs](/docs/contribute/participating/).
@@ -52,7 +52,7 @@ formatting, and typographic conventions. Look over the style guide before you
make your first contribution, and use it when you have questions.
Changes to the style guide are made by SIG Docs as a group. To propose a change
or addition, [add it to the agenda](https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/edit#) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
or addition, [add it to the agenda](https://docs.google.com/document/d/1zg6By77SGg90EVUrhDIhopjZlSDg2jCebU-Ks9cYx0w/edit#) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
discussion. See the [advanced contribution](/docs/contribute/advanced/) topic for more
information.
@@ -247,8 +247,10 @@ pull request if it detects that you pushed a new branch to your fork.
is the same as the commit summary, but you can change it if needed. The
body is populated by your extended commit message (if present) and some
template text. Read the template text and fill out the details it asks for,
then delete the extra template text. Leave the
**Allow edits from maintainers** checkbox selected. Click
then delete the extra template text. If you add to the description `fixes #<000000>`
or `closes #<000000>`, where `#<000000>` is the number of an associated issue,
GitHub will automatically close the issue when the PR merges.
Leave the **Allow edits from maintainers** checkbox selected. Click
**Create pull request**.
Congratulations! Your pull request is available in
content/en/docs/reference/access-authn-authz/authentication.md
+1 -1
View File
@@ -71,7 +71,7 @@ can be accomplished using an [authenticating proxy](#authenticating-proxy) or th
### X509 Client Certs
Client certificate authentication is enabled by passing the `--client-ca-file=SOMEFILE`
option to API server. The referenced file must contain one or more certificates authorities
option to API server. The referenced file must contain one or more certificate authorities
to use to validate client certificates presented to the API server. If a client certificate
is presented and verified, the common name of the subject is used as the user name for the
request. As of Kubernetes 1.4, client certificates can also indicate a user's group memberships
content/en/docs/reference/glossary/admission-controller.md
+22
View File
@@ -0,0 +1,22 @@
---
title: Admission Controller
id: admission-controller
date: 2019-06-28
full_link: /docs/reference/access-authn-authz/admission-controllers/
short_description: >
A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object.
aka:
tags:
- extension
- security
---
A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object.
<!--more-->
Admission controllers are configurable for the Kubernetes API server and may be “validating”, “mutating”, or
both. Any admission controller may reject the request. Mutating controllers may modify the objects they admit;
validating controllers may not.
* [Admission controllers in the Kubernetes documentation](/docs/reference/access-authn-authz/admission-controllers/)
content/en/docs/reference/glossary/device-plugin.md
+2 -2
View File
@@ -4,7 +4,7 @@ id: device-plugin
date: 2019-02-02
full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
short_description: >
Device Plugins are containers running in Kubernetes that provide access to a vendor specific resource.
Containers running in Kubernetes that provide access to a vendor specific resource.
aka:
tags:
- fundamental
@@ -14,4 +14,4 @@ tags:
<!--more-->
[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) are containers running in Kubernetes that provide access to a vendor specific resource. Device Plugins advertise these resources to kubelet and can be deployed manually or as a DeamonSet, rather than writing custom Kubernetes code.
[Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) are containers running in Kubernetes that provide access to a vendor-specific resource. Device Plugins advertise these resources to {{< glossary_tooltip term_id="kubelet" >}}. They can be deployed manually or as a {{< glossary_tooltip term_id="daemonset" >}}, rather than writing custom Kubernetes code.
content/en/docs/reference/glossary/mirror-pod.md
+1 -2
View File
@@ -1,8 +1,7 @@
---
title: Mirror Pod
id: mirror-pod
date: 2091-02-12
full_link:
date: 2019-08-06
short_description: >
An object in the API server that tracks a static pod on a kubelet.
content/en/docs/reference/glossary/static-pod.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: Static Pod
id: static-pod
date: 2091-02-12
date: 2019-02-12
full_link: /docs/tasks/administer-cluster/static-pod/
short_description: >
A pod managed directly by kubelet daemon on a specific node
content/en/docs/reference/kubectl/cheatsheet.md
+5 -1
View File
@@ -158,6 +158,10 @@ kubectl get services --sort-by=.metadata.name # List Services Sorted by Name
# List pods Sorted by Restart Count
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
# List pods in test namespace sorted by capacity
kubectl get pods -n test --sort-by=.spec.capacity.storage
# Get the version label of all pods with label app=cassandra
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'
@@ -344,7 +348,7 @@ Output format | Description
### Kubectl output verbosity and debugging
Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md).
Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
Verbosity | Description
--------------| -----------
content/en/docs/reference/kubectl/jsonpath.md
+13 -13
View File
@@ -65,18 +65,18 @@ Given the JSON input:
}
```
Function | Description | Example | Result
------------------|---------------------------|---------------------------------------------------------------|------------------
text | the plain text | kind is {.kind} | kind is List
@ | the current object | {@} | the same as input
. or [] | child operator | {.kind} or {['kind']} | List
.. | recursive descent | {..name} | 127.0.0.1 127.0.0.2 myself e2e
\* | wildcard. Get all objects | {.items[*].metadata.name} | [127.0.0.1 127.0.0.2]
[start:end :step] | subscript operator | {.users[0].name} | myself
[,] | union operator | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
?() | filter | {.users[?(@.name=="e2e")].user.password} | secret
range, end | iterate list | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
'' | quote interpreted string | {range .items[*]}{.metadata.name}{'\t'}{end} | 127.0.0.1 127.0.0.2
Function | Description | Example | Result
--------------------|---------------------------|-----------------------------------------------------------------|------------------
`text` | the plain text | `kind is {.kind}` | `kind is List`
`@` | the current object | `{@}` | the same as input
`.` or `[]` | child operator | `{.kind}` or `{['kind']}` | `List`
`..` | recursive descent | `{..name}` | `127.0.0.1 127.0.0.2 myself e2e`
`*` | wildcard. Get all objects | `{.items[*].metadata.name}` | `[127.0.0.1 127.0.0.2]`
`[start:end :step]` | subscript operator | `{.users[0].name}` | `myself`
`[,]` | union operator | `{.items[*]['metadata.name', 'status.capacity']}` | `127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]`
`?()` | filter | `{.users[?(@.name=="e2e")].user.password}` | `secret`
`range`, `end` | iterate list | `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}` | `[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]`
`''` | quote interpreted string | `{range .items[*]}{.metadata.name}{'\t'}{end}` | `127.0.0.1 127.0.0.2`
Examples using `kubectl` and JSONPath expressions:
@@ -95,4 +95,4 @@ C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.stat
C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
```
{{% /capture %}}
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
+3 -3
View File
@@ -14,7 +14,7 @@ weight: 90
## kubeadm alpha certs renew {#cmd-certs-renew}
You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.
For more details about certificate expiration and renewal see the [certificate management documentation](docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
For more details about certificate expiration and renewal see the [certificate management documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/).
{{< tabs name="tab-certs-renew" >}}
{{< tab name="renew" include="generated/kubeadm_alpha_certs_renew.md" />}}
@@ -44,7 +44,7 @@ to enable the automatic copy of certificates when joining additional control-pla
## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration}
This command checks expiration for the certificates in the local PKI managed by kubeadm.
For more details about certificate expiration and renewal see the [certificate management documentation](docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
For more details about certificate expiration and renewal see the [certificate management documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/).
{{< tabs name="tab-certs-check-expiration" >}}
{{< tab name="check-expiration" include="generated/kubeadm_alpha_certs_check-expiration.md" />}}
@@ -75,7 +75,7 @@ to enable the DynamicKubeletConfiguration feature.
The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one.
[Documentation](/docs/setup/independent/self-hosting)
[Documentation](/docs/setup/production-environment/tools/kubeadm/self-hosting/)
{{< tabs name="selfhosting" >}}
{{< tab name="selfhosting" include="generated/kubeadm_alpha_selfhosting.md" />}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
+3 -4
View File
@@ -16,10 +16,9 @@ You can execute `kubeadm config view` to view the ConfigMap. If you initialized
kubeadm v1.7.x or lower, you must use `kubeadm config upload` to create the ConfigMap before you
may use `kubeadm upgrade`.
In Kubernetes v1.11.0, some new commands were added. You can use `kubeadm config print-default`
to print the default configuration and `kubeadm config migrate` to convert your old configuration
files to a newer version. `kubeadm config images list` and `kubeadm config images pull` can be used
to list and pull the images that kubeadm requires.
You can use `kubeadm config print` to print the default configuration and `kubeadm config migrate` to
convert your old configuration files to a newer version. `kubeadm config images list` and
`kubeadm config images pull` can be used to list and pull the images that kubeadm requires.
In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image
the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
content/en/docs/setup/_index.md
+1 -1
View File
@@ -75,7 +75,7 @@ The following production environment solutions table lists the providers and the
| [Cisco Container Platform](https://cisco.com/go/containers) | | | &#x2714; | | |
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | &#x2714; |&#x2714; |
| [CloudStack](https://cloudstack.apache.org/) | | | | | &#x2714;|
| [Canonical](https://www.ubuntu.com/kubernetes/docs/quickstart) | | &#x2714; | | &#x2714; |&#x2714; | &#x2714;
| [Canonical](https://ubuntu.com/kubernetes) | &#x2714; | &#x2714; | &#x2714; | &#x2714; |&#x2714; | &#x2714;
| [Containership](https://containership.io/containership-platform) | &#x2714; |&#x2714; | | | |
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | &#x2714;
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | &#x2714; | | | | |
content/en/docs/setup/production-environment/container-runtimes.md
+1 -1
View File
@@ -189,7 +189,7 @@ apt-get install cri-o-1.13
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
# Install prerequisites
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
# Install CRI-O
yum install --nogpgcheck cri-o
content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+6 -2
View File
@@ -157,15 +157,19 @@ has finished performing the TLS Bootstrap.
## The kubelet drop-in file for systemd
The configuration file installed by the kubeadm DEB or RPM package is written to
kubeadm ships with configuration for how systemd should run the kubelet.
Note that the kubeadm CLI command never touches this drop-in file.
This configuration file installed by the `kubeadm` [DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf) or [RPM package](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf) is written to
`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd.
It augments the basic [`kubelet.service` for RPM](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/kubelet.service) (resp. [`kubelet.service` for DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/kubelet.service))):
```none
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+1
View File
@@ -170,6 +170,7 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
```sh
mv $HOME/.kube $HOME/.kube.bak
mkdir $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
content/en/docs/setup/release/notes.md
+2 -3
View File
@@ -279,14 +279,12 @@ Configure each cluster with a different cluster name using `kube-controller-mana
### Stable
- You can now create a non-preempting Pod priority. If set on a class, the pod will continue to be prioritized above queued pods of a lesser class, but will not preempt running pods. ([#74614](https://github.com/kubernetes/kubernetes/pull/74614), [@denkensk](https://github.com/denkensk))
- Third party device monitoring is now enabled by default (KubeletPodResources). ([#77274](https://github.com/kubernetes/kubernetes/pull/77274), [@RenaudWasTaken](https://github.com/RenaudWasTaken))
- The kube-apiserver’s `watch` can now be enabled for events using the `--watch-cache-sizes` flag. ([#74321](https://github.com/kubernetes/kubernetes/pull/74321), [@yastij](https://github.com/yastij))
### Beta
- Admission webhooks can now register for a single version of a resource (for example, `apps/v1 deployments`) and be called when any other version of that resource is modified (for example `extensions/v1beta1 deployments`). This allows new versions of a resource to be handled by admission webhooks without needing to update every webhook to understand the new version. See the API documentation for the `matchPolicy: Equivalent` option in MutatingWebhookConfiguration and ValidatingWebhookConfiguration types. ([#78135](https://github.com/kubernetes/kubernetes/pull/78135), [@liggitt](https://github.com/liggitt))
- Third party device monitoring is now enabled by default (KubeletPodResources). ([#77274](https://github.com/kubernetes/kubernetes/pull/77274), [@RenaudWasTaken](https://github.com/RenaudWasTaken))
- The CustomResourcePublishOpenAPI feature is now beta and enabled by default. CustomResourceDefinitions with [structural schemas](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190425-structural-openapi.md) now publish schemas in the OpenAPI document served at `/openapi/v2`. CustomResourceDefinitions with non-structural schemas have a `NonStructuralSchema` condition added with details about what needs to be corrected in the validation schema. ([#77825](https://github.com/kubernetes/kubernetes/pull/77825), [@roycaihw](https://github.com/roycaihw))
- Online volume expansion (ExpandInUsePersistentVolumes) is now a beta feature. As such, it is enabled by default. ([#77755](https://github.com/kubernetes/kubernetes/pull/77755), [@gnufied](https://github.com/gnufied))
- The `SupportNodePidsLimit` feature is now beta, and enabled by default. It is no longer necessary to set the feature gate `SupportNodePidsLimit=true`. ([#76221](https://github.com/kubernetes/kubernetes/pull/76221), [@RobertKrawitz](https://github.com/RobertKrawitz))
@@ -301,6 +299,7 @@ Configure each cluster with a different cluster name using `kube-controller-mana
### Alpha
- You can now create a non-preempting Pod priority. If set on a class, the pod will continue to be prioritized above queued pods of a lesser class, but will not preempt running pods. ([#74614](https://github.com/kubernetes/kubernetes/pull/74614), [@denkensk](https://github.com/denkensk))
- kubelet now allows the use of XFS quotas (on XFS and suitably configured ext4fs filesystems) to monitor storage consumption for ephemeral storage. This method of monitoring consumption, which is currently available only for `emptyDir` volumes, is faster and more accurate than the old method of walking the filesystem tree. Note that it does not enforce limits, it only monitors consumption. To utilize this functionality, set the feature gate `LocalStorageCapacityIsolationFSQuotaMonitoring=true`. For ext4fs filesystems, create the filesystem with `mkfs.ext4 -O project <block_device>` and run `tune2fs -Q prjquota `block device`; XFS filesystems need no additional preparation. The filesystem must be mounted with option `project` in `/etc/fstab`. If the primary partition is the root filesystem, add `rootflags=pquota` to the GRUB config file. ([#66928](https://github.com/kubernetes/kubernetes/pull/66928), [@RobertKrawitz](https://github.com/RobertKrawitz))
- Finalizer Protection for Service LoadBalancers (ServiceLoadBalancerFinalizer) has been added as an Alpha feature, which is disabled by default. This feature ensures the Service resource is not fully deleted until the correlating load balancer resources are deleted. ([#78262](https://github.com/kubernetes/kubernetes/pull/78262), [@MrHohn](https://github.com/MrHohn))
- Inline CSI ephemeral volumes can now be controlled with PodSecurityPolicy when the CSIInlineVolume alpha feature is enabled. ([#76915](https://github.com/kubernetes/kubernetes/pull/76915), [@vladimirvivien](https://github.com/vladimirvivien))
content/en/docs/tasks/administer-cluster/extended-resource-node.md
+5 -5
View File
@@ -10,8 +10,6 @@ This page shows how to specify extended resources for a Node.
Extended resources allow cluster administrators to advertise node-level
resources that would otherwise be unknown to Kubernetes.
{{< feature-state state="stable" >}}
{{% /capture %}}
@@ -60,7 +58,7 @@ you call dongles.
Start a proxy, so that you can easily send requests to the Kubernetes API server:
```
```shell
kubectl proxy
```
@@ -153,7 +151,7 @@ Then a Container could request any number of bytes of special storage, up to 800
Here is a PATCH request that removes the dongle advertisement from a Node.
```shell
```
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
Accept: application/json
Content-Type: application/json-patch+json
@@ -169,7 +167,7 @@ Host: k8s-master:8080
Start a proxy, so that you can easily send requests to the Kubernetes API server:
```
```shell
kubectl proxy
```
@@ -189,6 +187,8 @@ Verify that the dongle advertisement has been removed:
kubectl describe node <your-node-name> | grep dongle
```
(you should not see any output)
{{% /capture %}}
content/en/docs/tasks/administer-cluster/securing-a-cluster.md
+1 -1
View File
@@ -28,7 +28,7 @@ and provides recommendations on overall security.
As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions
they are allowed to perform is the first line of defense.
### Use Transport Level Security (TLS) for all API traffic
### Use Transport Layer Security (TLS) for all API traffic
Kubernetes expects that all API communication in the cluster is encrypted by default with TLS, and the
majority of installation methods will allow the necessary certificates to be created and distributed to
content/en/docs/tasks/administer-cluster/static-pod.md
-143
View File
@@ -1,143 +0,0 @@
---
reviewers:
- jsafrane
title: Static Pods
content_template: templates/concept
---
{{% capture overview %}}
**If you are running clustered Kubernetes and are using static pods to run a pod on every node, you should probably be using a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)!**
*Static pods* are managed directly by kubelet daemon on a specific node, without the API server observing it. It does not have an associated replication controller, and kubelet daemon itself watches it and restarts it when it crashes. There is no health check. Static pods are always bound to one kubelet daemon and always run on the same node with it.
Kubelet automatically tries to create a *mirror pod* on the Kubernetes API server for each static pod.
This means that the pods are visible on the API server but cannot be controlled from there.
{{% /capture %}}
{{% capture body %}}
## Static pod creation
Static pod can be created in two ways: either by using configuration file(s) or by HTTP.
### Configuration files
The configuration files are just standard pod definitions in json or yaml format in a specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start kubelet daemon or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file), which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
Note that kubelet will ignore files starting with dots when scanning the specified directory.
For example, this is how to start a simple web server as a static pod:
1. Choose a node where we want to run the static pod. In this example, it's `my-node1`.
```
[joe@host ~] $ ssh my-node1
```
2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:
```shell
[root@my-node1 ~] $ mkdir /etc/kubelet.d/
[root@my-node1 ~] $ cat <<EOF >/etc/kubelet.d/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
EOF
```
3. Configure your kubelet daemon on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file).
On Fedora edit `/etc/kubernetes/kubelet` to include this line:
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
Instructions for other distributions or Kubernetes installations may vary.
4. Restart kubelet. On Fedora, this is:
```
[root@my-node1 ~] $ systemctl restart kubelet
```
### Pods created via HTTP
Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--pod-manifest-path=<directory>`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below).
## Behavior of static pods
When kubelet starts, it automatically starts all pods defined in directory specified in `--pod-manifest-path=` or `--manifest-url=` arguments or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file), i.e. our static-web. (It may take some time to pull nginx image, be patient…):
```shell
[joe@my-node1 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
```
If we look at our Kubernetes API server (running on host `my-master`), we see that a new mirror-pod was created there too:
```shell
[joe@host ~] $ ssh my-master
[joe@my-master ~] $ kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
```
Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering.
Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/) command), kubelet simply won't remove it.
{{< note >}}
Make sure the kubelet has permission to create the mirror pod in the API server. If not, the creation request is rejected by the API server. See
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
{{< /note >}}
```shell
[joe@my-master ~] $ kubectl delete pod static-web-my-node1
pod "static-web-my-node1" deleted
[joe@my-master ~] $ kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 12s
```
Back to our `my-node1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while:
```none
[joe@host ~] $ ssh my-node1
[joe@my-node1 ~] $ docker stop f6d05272b57e
[joe@my-node1 ~] $ sleep 20
[joe@my-node1 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
```
## Dynamic addition and removal of static pods
Running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes pods as files appear/disappear in this directory.
```shell
[joe@my-node1 ~] $ mv /etc/kubelet.d/static-web.yaml /tmp
[joe@my-node1 ~] $ sleep 20
[joe@my-node1 ~] $ docker ps
// no nginx container is running
[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubelet.d/
[joe@my-node1 ~] $ sleep 20
[joe@my-node1 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
```
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/extended-resource.md
+2 -8
View File
@@ -6,10 +6,10 @@ weight: 40
{{% capture overview %}}
This page shows how to assign extended resources to a Container.
{{< feature-state state="stable" >}}
This page shows how to assign extended resources to a Container.
{{% /capture %}}
@@ -141,9 +141,3 @@ kubectl delete pod extended-resource-demo-2
* [Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/)
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/static-pod.md
+244
View File
@@ -0,0 +1,244 @@
---
reviewers:
- jsafrane
title: Create static Pods
weight: 170
content_template: templates/task
---
{{% capture overview %}}
*Static Pods* are managed directly by the kubelet daemon on a specific node,
without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
observing them.
Unlike Pods that are managed by the control plane (eg, a
{{< glossary_tooltip text="Deployment" term_id="deployment" >}};
instead, the kubelet watches each static Pod (and restarts it if it crashes).
There are no health checks for the containers in a static Pod.
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
Kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
on the Kubernetes API server for each static Pod.
This means that the Pods running on a node are visible on the API server,
but cannot be controlled from there.
{{< note >}}
If you are running clustered Kubernetes and are using static
Pods to run a Pod on every node, you should probably be using a
{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
instead.
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run Pods,
and that your nodes are running the Fedora operating system.
Instructions for other distributions or Kubernetes installations may vary.
{{% /capture %}}
{{% capture steps %}}
## Create a static pod {#static-pod-creation}
You can configure a static Pod two different ways: either by using configuration file(s) or by HTTP.
### Filesystem-hosted static Pod manifest {#configuration-files}
The configuration files are just standard Pod definitions in JSON or YAML format in a specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start the kubelet or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file), which periodically scans the directory and creates/deletes static Pods as YAML/JSON files appear/disappear there.
Note that the kubelet will ignore files starting with dots when scanning the specified directory.
For example, this is how to start a simple web server as a static Pod:
1. Choose a node where you want to run the static Pod. In this example, it's `my-node1`.
```shell
ssh my-node1
```
2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:
```shell
# Run this command on the node where kubelet is running
mkdir /etc/kubelet.d/
cat <<EOF >/etc/kubelet.d/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
EOF
```
3. Configure your kubelet on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file).
On Fedora edit `/etc/kubernetes/kubelet` to include this line:
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
4. Restart the kubelet. On Fedora, you would run:
```shell
# Run this command on the node where the kubelet is running
systemctl restart kubelet
```
### Web-hosted static pod manifest {#pods-created-via-http}
Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument
and interprets it as a JSON/YAML file that contains Pod definitions.
Similar to how [filesystem-hosted manifests](#configuration-files) work, the kubelet
refetches the manifest on a schedule. If there are changes to the list of static
Pods, the kubelet applies them.
If you want to use this approach, create a YAML file:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
```
and store it on a web server so that you can pass the URL of that file to the kubelet.
Configure the kubelet on your selected node to use this web manifest by running it with `--manifest-url=<manifest-url>`
On Fedora, edit `/etc/kubernetes/kubelet` to include this line:
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>`
```
Now, restart the kubelet. On Fedora, you would run:
```shell
# Run this command on the node where the kubelet is running
systemctl restart kubelet
```
## Observe static pod behavior {#behavior-of-static-pods}
When the kubelet starts, it automatically starts all defined static Pods. As you have
defined a static Pod and restarted the kubelet, the new static Pod should
already be running.
You can view running containers (including static Pods) by running (on the node):
```shell
# Run this command on the node where kubelet is running
docker ps
```
The output might be something like:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
```
You can see the mirror Pod on the API server:
```shell
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
```
{{< note >}}
Make sure the kubelet has permission to create the mirror Pod in the API server. If not, the creation request is rejected by the API server. See
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
{{< /note >}}
{{< glossary_tooltip term_id="label" text="Labels" >}} from the static Pod are
propagated into the mirror Pod. You can use those labels as normal via
{{< glossary_tooltip term_id="selector" text="selectors" >}}, etc.
If you try to use `kubectl` to delete the mirror Pod from the API server,
the kubelet _doesn't_ remove the static Pod:
```shell
kubectl delete pod static-web-my-node1
```
```
pod "static-web-my-node1" deleted
```
You can see that the Pod is still running:
```shell
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 12s
```
Back on your node where the kubelet is running, you can try to stop the Docker
container manually.
You'll see that, after a time, the kubelet will notice and will restart the Pod
automatically:
```shell
# Run these commands on the node where the kubelet is running
docker stop f6d05272b57e # replace with the ID of your container
sleep 20
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
```
## Dynamic addition and removal of static pods
The running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes Pods as files appear/disappear in this directory.
```shell
# This assumes you are using filesystem-hosted static Pod configuration
# Run these commands on the node where the kubelet is running
#
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
docker ps
# You see that no nginx container is running
mv /tmp/static-web.yaml /etc/kubelet.d/
sleep 20
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
```
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
+1 -1
View File
@@ -3,7 +3,7 @@ reviewers:
- cdrage
title: Translate a Docker Compose File to Kubernetes Resources
content_template: templates/task
weight: 170
weight: 200
---
{{% capture overview %}}
content/en/docs/tasks/debug-application-cluster/crictl.md
+1 -1
View File
@@ -295,7 +295,7 @@ deleted by the Kubelet.
"command": [
"top"
],
"log_path":"busybox/0.log",
"log_path":"busybox.log",
"linux": {
}
}
content/en/docs/tasks/manage-gpus/scheduling-gpus.md
+49 -47
View File
@@ -7,10 +7,10 @@ title: Schedule GPUs
{{% capture overview %}}
Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs spread
across nodes. The support for NVIDIA GPUs was added in v1.6 and has gone through
multiple backwards incompatible iterations. The support for AMD GPUs was added in
v1.9 via [device plugin](#deploying-amd-gpu-device-plugin).
{{< feature-state state="beta" for_k8s_version="1.10" >}}
Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs
(graphical processing units) across several nodes.
This page describes how users can consume GPUs across different Kubernetes versions
and the current limitations.
@@ -20,22 +20,20 @@ and the current limitations.
{{% capture body %}}
## v1.8 onwards
## Using device plugins
**From 1.8 onwards, the recommended way to consume GPUs is to use [device
plugins](/docs/concepts/cluster-administration/device-plugins).**
Kubernetes implements {{< glossary_tooltip text="Device Plugins" term_id="device-plugin" >}}
to let Pods access specialized hardware features such as GPUs.
To enable GPU support through device plugins before 1.10, the `DevicePlugins`
feature gate has to be explicitly set to true across the system:
`--feature-gates="DevicePlugins=true"`. This is no longer required starting
from 1.10.
As an administrator, you have to install GPU drivers from the corresponding
hardware vendor on the nodes and run the corresponding device plugin from the
GPU vendor:
Then you have to install GPU drivers from the corresponding vendor on the nodes
and run the corresponding device plugin from the GPU vendor
([AMD](#deploying-amd-gpu-device-plugin), [NVIDIA](#deploying-nvidia-gpu-device-plugin)).
* [AMD](#deploying-amd-gpu-device-plugin)
* [NVIDIA](#deploying-nvidia-gpu-device-plugin)
When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` or
`amd.com/gpu` as a schedulable resource.
When the above conditions are true, Kubernetes will expose `amd.com/gpu` or
`nvidia.com/gpu` as a schedulable resource.
You can consume these GPUs from your containers by requesting
`<vendor>.com/gpu` just like you request `cpu` or `memory`.
@@ -48,7 +46,7 @@ when using GPUs:
* You can specify GPU in both `limits` and `requests` but these two values
must be equal.
* You cannot specify GPU `requests` without specifying `limits`.
- Containers (and pods) do not share GPUs. There's no overcommitting of GPUs.
- Containers (and Pods) do not share GPUs. There's no overcommitting of GPUs.
- Each container can request one or more GPUs. It is not possible to request a
fraction of a GPU.
@@ -79,14 +77,12 @@ has the following requirements:
To deploy the AMD device plugin once your cluster is running and the above
requirements are satisfied:
```shell
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/v1.10/k8s-ds-amdgpu-dp.yaml
```
# For Kubernetes v1.9
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.9/k8s-ds-amdgpu-dp.yaml
# For Kubernetes v1.10
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.10/k8s-ds-amdgpu-dp.yaml
```
Report issues with this device plugin to [RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin).
You can report issues with this third-party device plugin by logging an issue in
[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin).
### Deploying NVIDIA GPU device plugin
@@ -99,22 +95,20 @@ has the following requirements:
- Kubernetes nodes have to be pre-installed with NVIDIA drivers.
- Kubernetes nodes have to be pre-installed with [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)
- nvidia-container-runtime must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)
for docker instead of runc.
- NVIDIA drivers ~= 361.93
- Kubelet must use Docker as its container runtime
- `nvidia-container-runtime` must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)
for Docker, instead of runc.
- The version of the NVIDIA drivers must match the constraint ~= 361.93
To deploy the NVIDIA device plugin once your cluster is running and the above
requirements are satisfied:
```
# For Kubernetes v1.8
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.8/nvidia-device-plugin.yml
# For Kubernetes v1.9
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.9/nvidia-device-plugin.yml
```shell
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta/nvidia-device-plugin.yml
```
Report issues with this device plugin to [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
You can report issues with this third-party device plugin by logging an issue in
[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
#### NVIDIA GPU device plugin used by GCE
@@ -124,9 +118,9 @@ that is compatible with the Kubernetes Container Runtime Interface (CRI). It's t
on [Container-Optimized OS](https://cloud.google.com/container-optimized-os/)
and has experimental code for Ubuntu from 1.9 onwards.
On your 1.12 cluster, you can use the following commands to install the NVIDIA drivers and device plugin:
You can use the following commands to install the NVIDIA drivers and device plugin:
```
```shell
# Install NVIDIA drivers on Container-Optimized OS:
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml
@@ -134,13 +128,13 @@ kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/containe
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml
# Install the device plugin:
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.12/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.14/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
```
Report issues with this device plugin and installation method to [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
You can report issues with using or deploying this third-party device plugin by logging an issue in
[GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
Instructions for using NVIDIA GPUs on GKE are
[here](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)
Google publishes its own [instructions](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus) for using NVIDIA GPUs on GKE .
## Clusters containing different types of GPUs
@@ -156,7 +150,14 @@ kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
```
For AMD GPUs, you can deploy [Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller), which automatically labels your nodes with GPU properties. Currently supported properties:
## Automatic node labelling {#node-labeller}
If you're using AMD GPU devices, you can deploy
[Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller).
Node Labeller is a {{< glossary_tooltip text="controller" term_id="controller" >}} that automatically
labels your nodes with GPU device properties.
At the moment, that controller can add labels for:
* Device ID (-device-id)
* VRAM Size (-vram)
@@ -172,13 +173,11 @@ For AMD GPUs, you can deploy [Node Labeller](https://github.com/RadeonOpenComput
* AI - Arctic Islands
* RV - Raven
Example result:
```console
```shell
kubectl describe node cluster-node-23
```
The output is similar to:
```
Name: cluster-node-23
Roles: <none>
Labels: beta.amd.com/gpu.cu-count.64=1
@@ -191,9 +190,10 @@ The output is similar to:
kubernetes.io/hostname=cluster-node-23
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: 0
......
…
```
Specify the GPU type in the pod spec:
With the Node Labeller in use, you can specify the GPU type in the Pod spec:
```yaml
apiVersion: v1
@@ -213,5 +213,7 @@ spec:
accelerator: nvidia-tesla-p100 # or nvidia-tesla-k80 etc.
```
This will ensure that the pod will be scheduled to a node that has the GPU type
This will ensure that the Pod will be scheduled to a node that has the GPU type
you specified.
{{% /capture %}}
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -65,7 +65,7 @@ It defines an index.php page which performs some CPU intensive computations:
First, we will start a deployment running the image and expose it as a service:
```shell
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80
```
```
service/php-apache created
content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md
+7 -2
View File
@@ -69,9 +69,14 @@ spec:
Patch your Deployment:
```shell
{{< tabs name="kubectl_patch_example" >}}
{{{< tab name="Bash" codelang="bash" >}}
kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)"
```
{{< /tab >}}
{{< tab name="PowerShell" codelang="posh" >}}
kubectl patch deployment patch-demo --patch $(cat patch-file-containers.yaml)
{{< /tab >}}}
{{< /tabs >}}
View the patched Deployment:
content/en/docs/tasks/tools/install-minikube.md
+8 -6
View File
@@ -18,17 +18,19 @@ This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a
{{< tabs name="minikube_before_you_begin" >}}
{{% tab name="Linux" %}}
To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty:
```shell
egrep --color 'vmx|svm' /proc/cpuinfo
```
grep -E --color 'vmx|svm' /proc/cpuinfo
```
{{% /tab %}}
{{% tab name="macOS" %}}
To check if virtualization is supported on macOS, run the following command on your terminal.
```
sysctl -a | grep machdep.cpu.features
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
```
If you see `VMX` in the output, the VT-x feature is supported on your OS.
If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine.
{{% /tab %}}
{{% tab name="Windows" %}}
To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt.
```
@@ -73,7 +75,7 @@ If you do not already have a hypervisor installed, install one of these now:
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
{{< note >}}
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor.
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor. It is recommended to use the apt installation of docker from ([Docker](https://www.docker.com/products/docker-desktop), when using the none driver. The snap installation of docker does not work with minikube.
{{< /note >}}
### Install Minikube using a package
@@ -158,7 +160,7 @@ Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows
The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator):
```shell
choco install minikube kubernetes-cli
choco install minikube
```
After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically.
content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
+5
View File
@@ -99,6 +99,11 @@ kubectl exec -it redis redis-cli
2) "allkeys-lru"
```
Delete the created pod:
```shell
kubectl delete pod redis
```
{{% /capture %}}
{{% capture whatsnext %}}
content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
+1 -1
View File
@@ -92,7 +92,7 @@ weight: 10
<div class="col-md-8">
<p>
For your first Deployment, you'll use a Node.js application packaged in a Docker container. (If you didn't already try creating a
Node.js application and deploying a Node.js application and deploying it using a container, you can do that first by following the
Node.js application and deploying it using a container, you can do that first by following the
instructions from the <a href="/docs/tutorials/hello-minikube/">Hello Minikube tutorial</a>).
<p>
content/en/examples/admin/resource/pvc-limit-greater.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-limit-greater
spec:
content/en/examples/admin/resource/pvc-limit-lower.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-limit-lower
spec:
content/en/examples/application/job/redis/worker.py
+1 -1
View File
@@ -14,7 +14,7 @@ print("Initial queue state: empty=" + str(q.empty()))
while not q.empty():
item = q.lease(lease_secs=10, block=True, timeout=2)
if item is not None:
itemstr = item.decode("utf=8")
itemstr = item.decode("utf-8")
print("Working on " + itemstr)
time.sleep(10) # Put your actual work here instead of sleep.
q.complete(item)
content/en/examples/application/mysql/mysql-pv.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv-volume
labels:
content/en/examples/debug/fluentd-gcp-configmap.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: ConfigMap
apiVersion: v1
kind: ConfigMap
data:
containers.input.conf: |-
# This configuration file for Fluentd is used
content/en/examples/federation/policy-engine-service.yaml
+2 -2
View File
@@ -1,5 +1,5 @@
kind: Service
apiVersion: v1
kind: Service
metadata:
name: opa
namespace: federation-system
@@ -10,4 +10,4 @@ spec:
- name: http
protocol: TCP
port: 8181
targetPort: 8181
targetPort: 8181
content/en/examples/pods/pod-projected-svc-token.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: Pod
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
content/en/examples/pods/storage/pv-claim.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
content/en/examples/pods/storage/pv-pod.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: Pod
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
content/en/examples/pods/storage/pv-volume.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
content/en/examples/service/access/hello-service.yaml
+1 -1
View File
@@ -1,5 +1,5 @@
kind: Service
apiVersion: v1
kind: Service
metadata:
name: hello
spec:
content/es/docs/reference/glossary/pod-priority.md
+17
View File
@@ -0,0 +1,17 @@
---
title: Pod Priority
id: pod-priority
date: 2019-01-31
full_link: /docs/concepts/configuration/pod-priority-preemption/#pod-priority
short_description: >
Pod Priority indica la importancia de un {{< glossary_tooltip text="Pod" term_id="pod" >}} con relación a otros {{< glossary_tooltip text="Pods" term_id="pod" >}}.
aka:
tags:
- operation
---
Pod Priority indica la importancia de un {{< glossary_tooltip text="Pod" term_id="pod" >}} con relación a otros {{< glossary_tooltip text="Pods" term_id="pod" >}}.
<!--more-->
[Pod Priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) da la habilidad de configurar prioridades del programador de un {{< glossary_tooltip text="Pod" term_id="pod" >}} más altas o bajas que otros {{< glossary_tooltip text="Pods" term_id="pod" >}} - lo cual es una característica importante para cargas de trabajo en producción.
content/fr/docs/reference/kubectl/cheatsheet.md
+1 -1
View File
@@ -315,7 +315,7 @@ Pour afficher les détails sur votre terminal dans un format spécifique, vous p
| `-o=yaml` | Affiche un objet de l'API formaté en YAML |
### Verbosité de l'affichage de Kubectl et débogage
La verbosité de Kubectl est contrôlée par une des options `-v` ou `--v` suivie d'un entier représentant le niveau de log. Les conventions générales de logging de Kubernetes et les niveaux de log associés sont décrits [ici](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md).
La verbosité de Kubectl est contrôlée par une des options `-v` ou `--v` suivie d'un entier représentant le niveau de log. Les conventions générales de logging de Kubernetes et les niveaux de log associés sont décrits [ici](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
| Verbosité | Description |
|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
content/fr/docs/reference/kubectl/jsonpath.md
+13 -13
View File
@@ -67,18 +67,18 @@ En plus de la syntaxe de modèle JSONPath originale, les fonctions et syntaxes s
}
```
Fonction | Description | Exemple | Résultat
------------------|----------------------------|---------------------------------------------------------------|------------------
text | le texte en clair | le type est {.kind} | le type est List
@ | l'objet courant | {@} | identique à l'entrée
. or [] | opérateur fils | {.kind} ou {['kind']} | List
.. | descente récursive | {..name} | 127.0.0.1 127.0.0.2 myself e2e
\* | joker. Tous les objets | {.items[*].metadata.name} | [127.0.0.1 127.0.0.2]
[start:end :step] | opérateur d'indice | {.users[0].name} | myself
[,] | opérateur d'union | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
?() | filtre | {.users[?(@.name=="e2e")].user.password} | secret
range, end | itération de liste | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
'' | protège chaîne interprétée | {range .items[*]}{.metadata.name}{'\t'}{end} | 127.0.0.1 127.0.0.2
Fonction | Description | Exemple | Résultat
--------------------|----------------------------|-----------------------------------------------------------------|------------------
`text` | le texte en clair | `le type est {.kind}` | `le type est List`
`@` | l'objet courant | `{@}` | identique à l'entrée
`.` ou `[]` | opérateur fils | `{.kind}` ou `{['kind']}` | `List`
`..` | descente récursive | `{..name}` | `127.0.0.1 127.0.0.2 myself e2e`
`*` | joker. Tous les objets | `{.items[*].metadata.name}` | `[127.0.0.1 127.0.0.2]`
`[start:end :step]` | opérateur d'indice | `{.users[0].name}` | `myself`
`[,]` | opérateur d'union | `{.items[*]['metadata.name', 'status.capacity']}` | `127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]`
`?()` | filtre | `{.users[?(@.name=="e2e")].user.password}` | `secret`
`range`, `end` | itération de liste | `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}` | `[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]`
`''` | protège chaîne interprétée | `{range .items[*]}{.metadata.name}{'\t'}{end}` | `127.0.0.1 127.0.0.2`
Exemples utilisant `kubectl` et des expressions JSONPath :
@@ -97,4 +97,4 @@ C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.stat
C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
```
{{% /capture %}}
{{% /capture %}}
content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md
+1 -1
View File
@@ -49,7 +49,7 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc
cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
[Service]
ExecStart=
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests
Restart=always
EOF
content/id/docs/concepts/storage/dynamic-provisioning.md
+128
View File
@@ -0,0 +1,128 @@
---
title: Penyediaan Volume Dinamis
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_).
Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin kluster secara manual harus
memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/)
sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin kluster untuk menyediakan
penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis
ketika diminta oleh pengguna.
{{% /capture %}}
{{% capture body %}}
## Latar Belakang
Penyediaan volume dinamis diimplementasi berdasarkan objek API StorageClass dari
grup API `storage.k8s.io`. Seorang admin kluster dapat mendefinisikan berbagai macam
objek StorageClass sesuai kebutuhan, masing-masing menentukan *plugin volume* (disebut
juga *provisioner*) yang menyediakan sebuah volume beserta kumpulan parameter untuk
diteruskan oleh _provisioner_ ketika proses penyediaan.
Seorang kluster admin dapat mendefinisikan dan mengekspos berbagai templat penyimpanan
(dari sistem penyimpanan yang sama maupun berbeda) di dalam kluster, masing-masing dengan
kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu khawatir betapa
rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk
memilih berbagai macam pilihan penyimpanan.
Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concepts/storage/storage-classes/).
## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_)
Untuk mengaktifkan penyediaan dinamis, seorang admin kluster perlu untuk
terlebih dahulu membuat (_pre-create_) satu atau beberapa objek StorageClass
untuk pengguna.
Objek StorageClass mendefinisikan _provisioner_ mana yang seharusnya digunakan
dan parameter apa yang seharusnya diberikan pada _provisioner_ tersebut saat
penyediaan dinamis dipanggil.
Manifestasi berikut ini membuat sebuah StorageClass "slow" yang
menyediakan _persistent_ disk standar.
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
```
Manifestasi berikut ini membuat sebuah StorageClass "fast" yang menyediakan
SSD _persistent_ disk.
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
```
## Menggunakan Penyediaan Dinamis
Pengguna dapat melakukan permintaan untuk penyediaan penyimpanan dinamis dengan
memasukkan StorageClass di dalam PersistentVolumeClaim. Sebelum Kubernetes v1.6,
ini dapat dilakukan melalui anotasi `volume.beta.kubernetes.io/storage-class`.
Hanya saja, anotasi ini sudah usang sejak v1.6. Pengguna sekarang dapat dan seharusnya
menggunakan _field_ `storageClassName` dari objek PersistentVolumeClaim. Nilai
dari _field_ ini haruslah sesuai dengan nama StorageClass yang dikonfigurasi oleh
admin (lihat bagian [di bawah](#enabling-dynamic-provisioning)).
Untuk memilih StorageClass "fast", sebagai contoh, pengguna dapat membuat
PersistentVolumeClaim seperti ini:
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: claim1
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast
resources:
requests:
storage: 30Gi
```
Klaim ini menghasilkan _persistent_ disk SSD yang disediakan secara otomatis.
Ketika klaim dihilangkan, volume akan musnah.
## Perilaku _Default_
Penyediaan dinamis dapat diaktifkan pada setiap kluster supaya semua klaim
dapat disediakan secara dinamis jika tidak ada StorageClass yang dispesifikasikan.
Seorang kluster admin dapat mengaktifkan perilaku ini dengan cara:
- Menandai satu objek StorageClass sebagai _default_;
- Memastikan bahwa [_admission controller_ `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
telah aktif pada API server.
Seorang admin dapat menandai StorageClass yang spesifik sebagai _default_ dengan menambahkan
anotasi `storageclass.kubernetes.io/is-default-class`.
Ketika StorageClass default tersebut ada pada kluster dan pengguna membuat PersistentVolumeClaim
tanpa menspesifikasikan `storageClassName`, _admission controller_ `DefaultStorageClass` secara
otomatis menambahkan _field_ `storageClassName` dengan StorageClass _default_.
Perhatikan bahwa hanya bisa ada satu _default_ StorageClass pada sebuah kluster,
atau PersistentVolumeClaim tanpa menspesifikasikan `storageClassName` secara eksplisit
tidak bisa terbuat.
## Kesadaran (_Awareness_) Topologi
Pada kluster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona
pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada
Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur
[Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
{{% /capture %}}
content/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm.md
+1 -1
View File
@@ -51,7 +51,7 @@ this example.
cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
[Service]
ExecStart=
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests
Restart=always
EOF
content/ko/docs/concepts/_index.md
+1 -1
View File
@@ -7,7 +7,7 @@ weight: 40
{{% capture overview %}}
개념 섹션을 통해 쿠버네티스 시스템을 구성하는 요소와 클러스터를 표현하는데 사용되는 추상 개념에 대해 배우고 쿠버네티스가 작동하는 방식에 대해 보다 깊이 이해할 수 있다.
개념 섹션을 통해 쿠버네티스 시스템을 구성하는 요소와 {{< glossary_tooltip text="클러스터" term_id="cluster" length="all" >}}를 표현하는데 사용되는 추상 개념에 대해 배우고 쿠버네티스가 작동하는 방식에 대해 보다 깊이 이해할 수 있다.
{{% /capture %}}
content/ko/docs/concepts/overview/components.md
+6 -4
View File
@@ -80,11 +80,13 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
## 애드온
애드온은 클러스터 기능을 이행하는 파드와 서비스다.
이 파드는 디플로이먼트, 레플리케이션 컨트롤러, 기타 등등에 의해 관리될 수도 있다.
네임스페이스를 갖는 애드온 오브젝트는 `kube-system` 네임스페이스 내에서 생성되어 진다.
애드온은 쿠버네티스 리소스({{< glossary_tooltip text="데몬셋" term_id="daemonset" >}},
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 등)를
이용하여 클러스터 기능을 구현한다. 이들은 클러스터 단위의 기능을 제공하기 때문에
애드온에 대한 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다.
선택된 일부 애드온이 아래에 설명되었으며, 사용가능한 전체 확장 애드온 리스트는 [애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
선택된 일부 애드온은 아래에 설명하였고, 사용가능한 전체 확장 애드온 리스트는
[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
### DNS
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+2 -2
View File
@@ -108,8 +108,8 @@ echo $pods
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
```
여기서 셀렉터는 레플리케이션 컨트롤러의 셀렉터와 같다 (
`kubectl describe` 의 출력에서 볼 수 있는 것과, 다른 형식의 파일인 `replication.yaml` 의 것). `--output=jsonpath` 옵션은
여기서 셀렉터는 레플리케이션 컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고,
다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은
반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다.
content/ko/docs/concepts/workloads/pods/init-containers.md
+127 -125
View File
@@ -5,126 +5,104 @@ weight: 40
---
{{% capture overview %}}
이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는
앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는
이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는
{{< glossary_tooltip text="파드" term_id="pod" >}}의 앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는
유틸리티 또는 설정 스크립트 등을 포함할 수 있다.
초기화 컨테이너는 `containers` 배열(앱 컨테이너를 기술하는)과 나란히
파드 스펙에 명시할 수 있다.
{{% /capture %}}
이 특징은 1.6에서 베타를 빠져나왔다. 초기화 컨테이너는 앱 `containers` 배열과 나란히
파드 스펙에 명시될 수 있다. 베타 어노테이션의 값은 여전히 존중되며 파드 스펙 필드 값을 덮어쓴다.
하지만, 베타 어노테이션은 1.6과 1.7에서 사용 중단(deprecated)되었다.
1.8에서 어노테이션은 더는 지원되지 않으므로 파드 스펙 필드로 변환되어야 한다.
{{% capture body %}}
## 초기화 컨테이너 이해하기
[파드](/ko/docs/concepts/workloads/pods/pod-overview/)는 앱들을 실행하는 다수의 컨테이너를
포함할 수 있다. 또한, 파드는 앱 컨테이너 실행 전에 동작되는 하나 이상의
초기화 컨테이너도 포함할 수 있다.
{{< glossary_tooltip text="파드" term_id="pod" >}}는 앱들을 실행하는 다수의 컨테이너를
포함할 수 있고, 또한 앱 컨테이너 실행 전에 동작되는 하나 이상의
초기화 컨테이너도 포함할 수 있다.
다음의 경우를 제외하면, 초기화 컨테이너는 일반적인 컨테이너와 매우 유사하다.
다음의 경우를 제외하면, 초기화 컨테이너는 일반적인 컨테이너와 매우 유사하다.
* 초기화 컨테이너는 항상 완료를 목표로 실행된다.
* 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
* 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를
반복적으로 재시작한다. 그러나, 만약 파드가 `restartPolicy`을 절대 하지 않음(Never)으로 설정한다면, 파드는 재시작되지 않는다.
만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를
반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy`을 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다.
컨테이너를 초기화 컨테이너로 지정하기 위해서는, 파드 스펙에 앱 `containers` 배열과 나란히
`initContainers` 필드를
컨테이너를 초기화 컨테이너로 지정하기 위해서는,
파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를
[컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
타입 오브젝트들의 JSON 배열로서 추가한다.
초기화 컨테이너의 상태는 `.status.initContainerStatuses` 필드를
통해서 컨테이너 상태 배열로 반환된다 (`.status.containerStatuses`와
유사하게).
초기화 컨테이너의 상태는 `.status.initContainerStatuses` 필드를
통해서 컨테이너 상태 배열로 반환된다
(`.status.containerStatuses` 필드와 유사하게).
### 일반적인 컨테이너와의 차이점
초기화 컨테이너는 앱 컨테이너의 리소스 상한, 볼륨, 보안 세팅을 포함한
모든 필드와 특징을 지원한다. 그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은
약간 다르게 처리된다. 이것에 대해서는 아래 [리소스](#리소스)에 문서화되어 있다. 또한, 초기화 컨테이너는
준비성 프로브(readiness probe)를 지원하지 않는다. 왜냐하면 초기화 컨테이너는
파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기
때문이다.
초기화 컨테이너는 앱 컨테이너의 리소스 상한(limit), 볼륨, 보안 세팅을 포함한
모든 필드와 기능을 지원한다.
그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은
[리소스](#리소스)에 문서화된 것처럼 다르게 처리된다.
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, 해당 초기화 컨테이너들은 순차적으로
한 번에 하나씩 실행된다. 각 초기화 컨테이너들은 다음 초기화 컨테이너가 실행되기 전에 성공되어야 한다.
모든 초기화 컨테이너들이 실행 완료되었을 때, 쿠버네티스는 파드를 초기화하고
애플리케이션 컨테이너를 평소와 같이 실행한다.
또한, 초기화 컨테이너는 준비성 프로브(readiness probe)를 지원하지 않는다. 왜냐하면 초기화 컨테이너는
파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
## 초기화 컨테이너는 무엇을 위해서 사용될 수 있는가?
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을
한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다.
모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을
초기화하고 평소와 같이 실행한다.
초기화 컨테이너는 앱 컨테이너와는 별도의 이미지를 가지고 있기 때문에, 시동(start-up)에
관련된 코드에 몇 가지 이점을 가진다.
## 초기화 컨테이너 사용하기
* 보안 상 앱 컨테이너 이미지에서는 바람직하지 않은 유틸리티를 포함하고
실행시킬 수 있다.
* 앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함한다.
초기화 컨테이너는 앱 컨테이너와는 별도의 이미지를 가지고 있기 때문에, 시동(start-up)에
관련된 코드로서 몇 가지 이점을 가진다.
* 앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함할 수 있다.
예를 들어, 셋업 중에 단지 `sed`, `awk`, `python`, 또는 `dig`와 같은 도구를 사용하기 위해서
다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다.
* 앱 컨테이너 이미지의 보안성을 떨어뜨릴 수도 있는 유틸리티를 안전하게 실행할 수 있다.
* 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서
공동의 단일 앱 이미지 형태로 빌드될 필요가 없다.
* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다.
결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 시크릿에 접근 권한이 주어질 수 있다.
* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱
컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이
결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는
{{< glossary_tooltip text="시크릿" term_id="secret" >}}에 접근 권한이 주어질 수 있다.
* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱
컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이
충족될 때까지 앱 컨테이너가 시동되는 것을 막거나 지연시키는 간편한 방법을 제공한다.
### 예제
초기화 컨테이너를 사용하는 방법에 대한 몇 가지 아이디어는 다음과 같다.
* 다음과 같은 셀 커맨드로, 서비스가 생성될 때까지 기다리기.
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
* 다음과 같은 셸 커맨드로,
{{< glossary_tooltip text="서비스" term_id="service">}}가 생성될 때까지 기다리기.
```shell
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
```
* 다음과 같은 커맨드로, 다운워드 API(Downward API)를 통한 원격 서버에 해당 파드를 등록하기.
```shell
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
```
`curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'`
* 다음과 같은 커맨드로 앱 컨테이너가 시작되기 전에 일정 시간 기다리기.
```shell
sleep 60
```
* `sleep 60`와 같은 커맨드로 앱 컨테이너가 시작되기 전에 일정 시간 기다리기.
* git 저장소를 볼륨 안에 클론하기.
* 설정 파일에 값을 지정하고 메인 앱 컨테이너를 위한 설정 파일을 동적으로 생성하기 위한 템플릿 도구를 실행하기.
예를 들어, 설정에 POD_IP 값을 지정하고 메인 앱 설정 파일을 Jinja를 통해서 생성.
* Git 저장소를 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 안에 클론하기.
더 자세한 사용 예제는 [스테이트풀 셋 문서](/docs/concepts/workloads/controllers/statefulset/)
과 [프로덕션 파드 가이드](/docs/tasks/configure-pod-container/configure-pod-initialization/)에서 확인한다.
* 설정 파일에 값을 지정하고
메인 앱 컨테이너를 위한 설정 파일을 동적으로 생성하기 위한 템플릿 도구를 실행하기.
예를 들어, 설정에 `POD_IP` 값을 지정하고
메인 앱 설정 파일을 Jinja를 통해서 생성.
### 사용되고 있는 초기화 컨테이너
### 사용 중인 초기화 컨테이너
쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다.
첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이
쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다.
첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이
완료되면, 파드가 시작될 것이다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
annotations:
pod.beta.kubernetes.io/init-containers: '[
{
"name": "init-myservice",
"image": "busybox:1.28",
"command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"]
},
{
"name": "init-mydb",
"image": "busybox:1.28",
"command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"]
}
]'
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
```
쿠버네티스 1.6에는 새로운 구문이 있다. 다만, 예전 어노테이션 구문도 1.6과 1.7에서는 여전히 동작한다. 새로운 구문은
1.8 또는 더 높은 버전에서 사용되어야 한다. 초기화에 대한 선언은 `spec`으로 옮겨졌다.
```yaml
apiVersion: v1
kind: Pod
@@ -146,8 +124,6 @@ spec:
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
```
1.5 구문도 1.6에서 여전히 동작하지만, 1.6 구문 사용을 추천한다. 쿠버네티스 1.6에서는, 초기화 컨테이너가 API에서 필드로
만들어졌었다. 베타 어노테이션은 1.6과 1.7에서 여전히 지원되지만, 1.8이나 더 높은 버전에서는 지원되지 않는다.
아래의 yaml file은 `mydb`와 `myservice` 서비스의 개요를 보여준다.
@@ -182,6 +158,7 @@ kubectl apply -f myapp.yaml
pod/myapp-pod created
```
그리고 파드의 상태를 확인한다.
```shell
kubectl get -f myapp.yaml
```
@@ -190,6 +167,7 @@ NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 6m
```
혹은 좀 더 자세히 살펴본다.
```shell
kubectl describe -f myapp.yaml
```
@@ -227,14 +205,43 @@ Events:
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
```
파드의 초기화 컨테이너의 상태를 보기 위해, 다음을 실행한다.
```shell
kubectl logs myapp-pod -c init-myservice # Inspect the first init container
kubectl logs myapp-pod -c init-mydb # Inspect the second init container
```
`mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고
`mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고
`myapp-pod`가 생성된 것을 볼 수 있다.
여기에 이 서비스를 보이기 위해 사용할 수 있는 구성이 있다.
```yaml
---
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9377
```
`mydb`와 `myservice` 서비스 생성하기.
```shell
kubectl apply -f services.yaml
```
@@ -243,26 +250,31 @@ service/myservice created
service/mydb created
```
초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Runnning 상태로
변경되는 것을 볼 것이다.
```shell
kubectl get -f myapp.yaml
```
```
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 9m
```
이 예제는 매우 단순하지만 사용자만의 초기화 컨테이너를 생성하는데
영감을 줄 것이다.
이 간단한 예제는 사용자만의 초기화 컨테이너를 생성하는데
영감을 줄 것이다. [다음 순서](#what-s-next)에는 더 자세한 예제의 링크가 있다.
## 자세한 동작
파드 시동 시, 네트워크와 볼륨이 초기화되고 나면, 초기화 컨테이너가
순서대로 시작된다. 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로
종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이
실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만,
파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는
파드 시동 시, 네트워크와 볼륨이 초기화되고 나면, 초기화 컨테이너가
순서대로 시작된다. 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로
종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이
실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만,
파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는
`restartPolicy`을 실패 시(OnFailure)로 사용한다.
파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready`될 수 없다. 초기화 컨테이너의 포트는
서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만
서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만
`Initializing`이 참이 되는 조건을 가져야 한다.
만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는
@@ -275,69 +287,59 @@ myapp-pod 1/1 Running 0 9m
코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는
출력 파일이 이미 존재할 가능성에 대비해야 한다.
초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는
`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을
초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는
`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을
구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다.
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를
사용한다.
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를 사용한다.
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다.
### 리소스
초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
다음의 규칙이 적용된다.
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
높은 것은 *유효한 초기화 요청량/상한* 이다.
* 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
* 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
* 리소스에 대한 유효한 초기화 요청량/상한
* 스케줄링은 유효한 요청/상한에 따라 이루어진다. 즉,
초기화 컨테이너는 파드의 삶에서는 사용되지 않는 초기화를 위한 리소스를
예약할 수 있다.
* 파드의 *유효한 QoS 계층* 에서 QoS 계층은 초기화 컨테이너들과
* 스케줄링은 유효한 요청/상한에 따라 이루어진다. 즉,
초기화 컨테이너는 파드의 삶에서는 사용되지 않는 초기화를 위한 리소스를
예약할 수 있다.
* 파드의 *유효한 QoS 계층* 에서 QoS(서비스의 품질) 계층은 초기화 컨테이너들과
앱 컨테이너들의 QoS 계층과 같다.
쿼터 및 상한은 유효한 파드의 요청량 및 상한에 따라
쿼터 및 상한은 유효한 파드의 요청량 및 상한에 따라
적용된다.
파드 레벨 cgroup은 유효한 파드 요청량 및 상한을 기반으로 한다. 이는 스케줄러와 같다.
파드 레벨 cgroup은 유효한 파드 요청량 및 상한을 기반으로 한다.
이는 스케줄러와 같다.
### 파드 재시작 이유
파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수
파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수
있다.
* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다.
Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너
이미지의 변경은 앱 컨테이너만 재시작시킨다.
* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다.
Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너
이미지의 변경은 앱 컨테이너만 재시작시킨다.
* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는,
동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는,
동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
때문에 유실되었다.
## 지원 및 호환성
Api서버 버전 1.6.0 또는 더 높은 버전으로 구성된 클러스터는 `.spec.initContainers`
필드를 사용하여 초기화 컨테이너를 지원한다. 이전 버전들은 초기화 컨테이너를 알파 또는
베타 어노테이션을 사용하여 지원한다. `.spec.initContainers` 필드는 알파 또는 베타
어노테이션에도 반영되어 있어서 버전 1.3.0 이상의 Kubelet이 초기화 컨테이너를 실행할 수
있도록 한다. 따라서, 버전 1.6 api서버가 기존에 생성된 파드들의 초기화 컨테이너 기능 손실 없이
안전하게 버전 1.5.x로 롤백할 수 있게 한다.
Api서버 및 Kubelet 버전 1.8.0 이상에서는, 사용 중단된 어노테이션을
`.spec.initContainers` 필드로 변환하는 것이 필요한, 알파 및 베타 어노테이션의 지원이 중단되었다.
{{% /capture %}}
{{% capture whatsnext %}}
* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기
{{% /capture %}}
content/ko/docs/concepts/workloads/pods/podpreset.md
+1 -2
View File
@@ -69,8 +69,7 @@ weight: 50
minikube에서는 클러스터가 시작할 때
`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
플래그를 추가한다.
1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다.
이것을 이루는 방법 중 하나는
1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
minikube에서는 클러스터가 시작할 때
content/ko/docs/contribute/participating.md
+18 -10
View File
@@ -201,22 +201,30 @@ SIG Docs 승인자가 되는 방법과
GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.
#### 웹사이트 관리자 되기
#### 승인자의 책임
`kubernetes-website-admins` GitHub 그룹의 멤버는 GitHub 그룹의 멤버십을 관리할 수 있고
리포지터리를 세팅하거나 웹훅(webhook)을 추가, 삭제하고 트러블슈팅하는 것을 포함한
모든 관리 권한을 가질 수 있다.
모든 SIG Docs 승인자가 이 수준의 액세스를 할 필요는 없다.
승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다.
만약 이 수준의 접근 권한이 필요하다면, 현재 웹사이트 관리자나
[쿠버네티스 Slack](https://kubernetes.slack.com) #sig-docs 채널에서 말한다.
- 승인자는 PR들을 리포에 머지하는 `/approve` 명령을 사용할 수 있다.
부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다.
- 제안된 변경이 컨트리뷰션 가이드 라인에 적합한지 확인한다.
질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다.
- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다.
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="승인 전에 반드시 Netlify 테스트를 통과해야 한다" />
- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다.
#### PR Wrangler
SIG Docs 승인자는
[PR Wrangler 로테이션 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에
올라서 주 단위로 돌아가며 역할을 수행한다.
모든 SIG Docs 승인자는 이 로테이션에 참여하게 된다. 보다 자세한 내용은
[PR Wrangler 회람 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에
참여하여 주 단위로 돌아가며 역할을 수행한다.
SIG Docs는 모든 승인자들이 이 회람에 참여하기를 기대한다. 보다 자세한 내용은
[일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
문서를 참고한다.
content/ko/docs/home/supported-doc-versions.md
+28
View File
@@ -0,0 +1,28 @@
---
title: 쿠버네티스 문서의 버전 지원
content_template: templates/concept
card:
name: about
weight: 10
title: 문서의 버전 지원
---
{{% capture overview %}}
이 웹 사이트에는 현재 버전의 쿠버네티스와 이전 4개 버전의
쿠버네티스에 대한 문서가 포함되어 있습니다.
{{% /capture %}}
{{% capture body %}}
## 현재 버전
현재 버전은
[{{< param "version" >}}](/).
## 이전 버전
{{< versions-other >}}
{{% /capture %}}
content/ko/docs/reference/_index.md
+2 -2
View File
@@ -16,13 +16,13 @@ content_template: templates/concept
## API 레퍼런스
* [쿠버네티스 API 개요](/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
* [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
* 쿠버네티스 API 버전
* [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
* [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
* [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
* [1.10](/docs/reference/generated/kubernetes-api/v1.10/)
## API 클라이언트 라이브러리
content/ko/docs/reference/glossary/cloud-provider.md
+17
View File
@@ -0,0 +1,17 @@
---
title: 클라우드 공급자
id: cloud-provider
date: 2018-04-12
full_link: /docs/concepts/cluster-administration/cloud-providers
short_description: >
클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사.
aka:
tags:
- community
---
클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사.
<!--more-->
클라우드 컴퓨팅 플랫폼을 제공하는 클라우드 공급자 또는 클라우드 서비스 공급자(CSP)라고 한다. 이들은 인프라 서비스(IaaS) 또는 플랫폼 서비스(PaaS)를 제공할 수 있다. 클라우드 공급자는 쿠버네티스 클러스터를 호스트 하며 클러스터와 상호작용하는 로드밸런서, 스토리지 클래스 등의 서비스도 제공한다.
content/ko/docs/reference/glossary/cluster.md
+5 -7
View File
@@ -1,19 +1,17 @@
---
title: 클러스터(Cluster)
id: cluster
date: 2018-04-12
date: 2019-06-15
full_link:
short_description: >
쿠버네티스를 통해 관리되는 컨테이너화 된 애플리케이션을 실행하는, 노드라고 불리는 기계의 집합.
쿠버네티스에서 관리하는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 기계의 집합. 클러스터는 최소 1개의 워커 노드와 최소 1개의 마스터 노드를 가진다.
aka:
aka:
tags:
- fundamental
- operation
---
쿠버네티스를 통해 관리되는 컨테이너화 된 애플리케이션을 실행하는, 노드라고 불리는 기계의 집합.
쿠버네티스에서 관리하는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 기계의 집합. 클러스터는 최소 1개의 워커 노드와 최소 1개의 마스터 노드를 가진다.
<!--more-->
클러스터는 여러 개의 워커 노드와 적어도 하나의 마스터를 가진다.
워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다. 마스터 노드는 워커 노드와 클러스터 내 파드를 관리한다. 다수의 마스터 노드는 장애극복(failover)과 고가용성의 클러스터에서 사용한다.
content/ko/docs/reference/glossary/container-runtime.md
+1 -1
View File
@@ -15,7 +15,7 @@ tags:
<!--more-->
쿠버네티스느 여러 컨테이너 런타임을 지원한다. [Docker](http://www.docker.com),
쿠버네티스는 여러 컨테이너 런타임을 지원한다. [Docker](http://www.docker.com),
[containerd](https://containerd.io), [cri-o](https://cri-o.io/),
[rktlet](https://github.com/kubernetes-incubator/rktlet)과
[Kubernetes CRI (컨테이너 런타임 인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 소프트웨어.
content/ko/docs/reference/glossary/daemonset.md
+6 -6
View File
@@ -1,20 +1,20 @@
---
title: 데몬 셋(DaemonSet)
title: 데몬셋(DaemonSet)
id: daemonset
date: 2018-04-12
full_link: /docs/concepts/workloads/controllers/daemonset
short_description: >
파드의 복제품이 클러스터의 노드 집합에 걸쳐 동작하는 것을 확실히 한다.
파드의 복제본을 클러스터 노드 집합에서 동작하게 한다.
aka:
aka:
tags:
- fundamental
- core-object
- workload
---
{{< glossary_tooltip text="파드" term_id="pod" >}}의 복제품이 {{< glossary_tooltip text="클러스터" term_id="cluster" >}}의 노드 집합에 걸쳐 동작하는 것을 확실히 한다.
{{< glossary_tooltip text="파드" term_id="pod" >}} 복제본을 {{< glossary_tooltip text="클러스터" term_id="cluster" >}} 노드 집합에서 동작하게 한다.
<!--more-->
<!--more-->
일반적으로 모든 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행돼야 하는 로그 수집기 및 모니터링 에이전트 등의 시스템 데몬을 디플로이하기 위해서 사용된다.
일반적으로 모든 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행돼야 하는 로그 수집기 및 모니터링 에이전트 등의 시스템 데몬을 배포하기 위해서 사용된다.
content/ko/docs/reference/glossary/deployment.md
+5 -5
View File
@@ -4,17 +4,17 @@ id: deployment
date: 2018-04-12
full_link: /docs/concepts/workloads/controllers/deployment/
short_description: >
레플리케이션 된 애플리케이션을 관리하는 API 오브젝트.
복제된(replicated) 애플리케이션을 관리하는 API 오브젝트.
aka:
aka:
tags:
- fundamental
- core-object
- workload
---
레플리케이션 된 애플리케이션을 관리하는 API 오브젝트.
복제된 애플리케이션을 관리하는 API 오브젝트.
<!--more-->
<!--more-->
각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 각 파드는 클러스터의 노드에 분산된다.
각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 파드는 클러스터의 노드에 분산된다.
content/ko/docs/reference/glossary/init-container.md
+5 -5
View File
@@ -2,17 +2,17 @@
title: 초기화 컨테이너(Init Container)
id: init-container
date: 2018-04-12
full_link:
full_link:
short_description: >
앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너.
앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너.
aka:
aka:
tags:
- fundamental
---
앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너.
앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너.
<!--more-->
<!--more-->
한 가지 차이점을 제외하면, 초기화 컨테이너는 일반적인 앱 컨테이너와 동일하다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 완료되는 것을 목표로 실행되어야 한다. 초기화 컨테이너는 연달아 실행된다. 다시말해, 각 초기화 컨테이너의 실행은 다음 초기화 컨테이너가 시작되기 전에 완료되어야 한다.
content/ko/docs/reference/glossary/limitrange.md
+4 -4
View File
@@ -4,7 +4,7 @@ id: limitrange
date: 2019-04-15
full_link: /docs/concepts/policy/limit-range/
short_description: >
네임스페이스 안의 컨테이너나 파드의 리소스 사용량을 제한하는 제약을 제공한다.
네임스페이스 내에 컨테이너나 파드당 리소스 소비를 한정하는 제약 조건을 제공한다.
aka:
tags:
@@ -16,8 +16,8 @@ related:
- container
---
네임스페이스 안의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}의 리소스 사용량을 제한하는 제약을 제공한다.
네임스페이스 내에 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}당 리소스 소비를 한정하는 제약 조건을 제공한다.
<!--more-->
범위 제한은 타입별로 만들 수 있는 객체의 수와
네임스페이스 안의 개별 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}가 요청하거나 소비한 컴퓨팅 리소스의 양을 제한한다.
범위 제한은 타입별로 만들 수 있는 오브젝트의 개수와
네임스페이스 안에 개별 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}가 요청하거나 소비할 컴퓨팅 리소스의 양을 제한한다.
content/ko/docs/reference/glossary/static-pod.md
+2 -2
View File
@@ -4,11 +4,11 @@ id: static-pod
date: 2091-02-12
full_link: /docs/tasks/administer-cluster/static-pod/
short_description: >
특정 노드의 kubelet 데몬이 직접 관리하는 파드
특정 노드의 Kubelet 데몬이 직접 관리하는 파드
aka:
tags:
- fundamental
---
API 서버가 관찰하지 않고, 특정 노드의 kubelet 데몬이
API 서버가 관찰하지 않고, 특정 노드의 Kubelet 데몬이
직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}.
content/ko/docs/reference/kubectl/cheatsheet.md
+2 -2
View File
@@ -340,11 +340,11 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든
### Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅
Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 레벨을 나타내는 정수로 제어된다. 일반적인 쿠버네티스 로깅 규칙과 관련 로그 레벨이 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md)에 설명되어 있다.
Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 레벨을 나타내는 정수로 제어된다. 일반적인 쿠버네티스 로깅 규칙과 관련 로그 레벨이 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에 설명되어 있다.
로그 레벨 | 세부 사항
--------------| -----------
`--v=0` | 일반적으로 운영자에게 유용함.
`--v=0` | 일반적으로 클러스터 운영자(operator)에게 *항상* 보여지게 하기에는 유용함.
`--v=1` | 자세한 정보를 원하지 않는 경우, 적절한 기본 로그 수준.
`--v=2` | 서비스와 시스템의 중요한 변화와 관련이있는 중요한 로그 메시지에 대한 유용한 정상 상태 정보. 이는 대부분의 시스템에서 권장되는 기본 로그 수준이다.
`--v=3` | 변경 사항에 대한 확장 정보.
content/ko/docs/reference/using-api/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: 쿠버네티스 API 사용하기
weight: 10
toc-hide: true
---
content/ko/docs/reference/using-api/api-overview.md
+111
View File
@@ -0,0 +1,111 @@
---
title: 쿠버네티스 API 개요
content_template: templates/concept
weight: 10
card:
name: 레퍼런스
weight: 50
title: API 개요
---
{{% capture overview %}}
이 페이지는 쿠버네티스 API에 대한 개요를 제공한다.
{{% /capture %}}
{{% capture body %}}
REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
API 오브젝트로 취급되고,
[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다.
대부분의 작업은 API에 의존하고 있는
[kubectl](/docs/reference/kubectl/overview/) 커맨드라인 인터페이스 또는
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 같은 다른 커맨드라인 툴을 통해 수행할 수 있다.
그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다.
쿠버네티스 API를 사용하는 애플리케이션을 작성하는 경우
[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)중 하나의 사용을 고려한다.
## API 버전 규칙
필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이
각각 다른 API 경로에서 복수의 API 버전을 지원한다.
아래를 위해 버전은 리소스나 필드 수준보다는 API 수준에서 설정된다.
- API가 시스템 리소스와 동작에 대해 명확하고 일관성 있게 표현하는 것을 보장
- 수명 종료(end-of-life) 또는 실험적인 API 접근 제어 활성화
JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
{{< note >}}
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
{{< /note >}}
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [API 변경 문서](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
아래는 각 수준의 기준에 대한 요약이다.
- 알파(Alpha) 수준:
- 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
- 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
- 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
- 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
- 베타(Beta) 수준:
- 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 이때 API 오브젝트의 삭제, 편집 또는 재생성이
필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
- 이후 여러 버전에서 잠재적으로 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 안심이 될 수도 있겠다.
{{< note >}}
베타 기능을 사용해보고 피드백을 제공하자. 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.
{{< /note >}}
- 안정화(stable) 수준:
- 버전 이름이 `vX`이고 `X` 는 정수다.
- 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.
## API 그룹
[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 쿠버네티스 API를 더 쉽게 확장하게 해준다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
현재 다음과 같은 다양한 API 그룹이 사용되고 있다:
* *핵심* (또는 *레거시*라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다.
* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
(예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/docs/reference/)에서 확인할 수 있다.
[사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다.
- 기본적인 CRUD 요구에는
[CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
- 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
## API 그룹 활성화 시키기
특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어:
- batch/v1을 비활성화하려면 `--runtime-config=batch/v1=false`로 설정
- batch/v2alpha1을 활성화하려면 `--runtime-config=batch/v2alpha1`로 설정
이 플래그는 apiserver의 런타임 구성을 설명하는 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
{{< note >}}
그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여
`--runtime-config` 변경을 반영해야 한다.
{{< /note >}}
## 그룹 내 리소스 활성화 시키기
데몬셋, 디플로이먼트, HorizontalPodAutoscaler, 인그레스, 잡 및 레플리카셋이 기본적으로 활성화되어 있다.
다른 확장 리소스는 apiserver의 `--runtime-config`를 설정해서
활성화할 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어 디플로이먼트와 잡을 비활성화하려면,
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`와 같이 설정한다.
{{% /capture %}}
content/ko/docs/setup/_index.md
+3
View File
@@ -66,6 +66,7 @@ card:
| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | |
| [AppsCode](https://appscode.com/products/pharmer/) | &#x2714; | | | | |
| [APPUiO](https://appuio.ch/)  | &#x2714; | &#x2714; | &#x2714; | | | |
| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | &#x2714; | | &#x2714; | &#x2714; | &#x2714; |
| [CenturyLink Cloud](https://www.ctl.io/) | | &#x2714; | | | |
| [Cisco Container Platform](https://cisco.com/go/containers) | | | &#x2714; | | |
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | &#x2714; |&#x2714; |
@@ -81,6 +82,7 @@ card:
| [Giant Swarm](https://giantswarm.io/) | &#x2714; | &#x2714; | &#x2714; | |
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
| [Kontena Pharos](https://www.kontena.io/pharos/) | |&#x2714;| &#x2714; | | |
| [Kubermatic](https://www.loodse.com/) | &#x2714; | &#x2714; | &#x2714; | | |
| [KubeSail](https://kubesail.com/) | &#x2714; | | | | |
@@ -100,6 +102,7 @@ card:
| [Supergiant](https://supergiant.io/) | |&#x2714; | | | |
| [SUSE](https://www.suse.com/) | | &#x2714; | | | |
| [SysEleven](https://www.syseleven.io/) | &#x2714; | | | | |
| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | &#x2714; | &#x2714; | | | &#x2714; |
| [VEXXHOST](https://vexxhost.com/) | &#x2714; | &#x2714; | | | |
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
content/ko/docs/tasks/debug-application-cluster/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
title: "모니터링, 로깅, 그리고 디버깅"
weight: 80
---
content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+53
View File
@@ -0,0 +1,53 @@
---
title: 리소스 메트릭 파이프라인
content_template: templates/concept
---
{{% capture overview %}}
쿠버네티스 1.8 부터 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
쿠버네티스의 Metrics API를 통해 사용할 수 있다. 이 메트릭은
`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
{{% /capture %}}
{{% capture body %}}
## Metrics API
Metrics API를 통해 주어진 노드나 파드에서 현재 사용중인
리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을
가져오는 것과 같은 일을 할 수는 없다.
이 API와 다른 API는 차이가 없다.
- 다른 쿠버네티스 API의 엔드포인트와 같이 `/apis/metrics.k8s.io/` 하위 경로에서 발견될 수 있다
- 동일한 보안, 확장성 및 신뢰성 보장을 제공한다
[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다.
{{< note >}}
이 API를 사용하려면 Metrics server를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다.
{{< /note >}}
## Metrics Server
[Metrics server](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 Metrics server가
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
[배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 Metrics server를 배포할 수 있다.
이 방식은 쿠버네티스 1.7 이상에서 지원된다. (상세 사항은 아래를 참조)
Metric server는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
Metrics server는 쿠버네티스 1.7에서 도입된
[쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를
통해 메인 API 서버에 등록된다.
[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 Metrics server에 대해 자세하게 배울 수 있다.
{{% /capture %}}
content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+116
View File
@@ -0,0 +1,116 @@
---
content_template: templates/concept
title: 리소스 모니터링 도구
---
{{% capture overview %}}
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod),
[서비스](/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을
검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다.
이 정보는 애플리케이션의 성능을 평가하고
병목 현상을 제거하여 전체 성능을 향상할 수 있게 해준다.
{{% /capture %}}
{{% capture body %}}
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다.
신규 클러스터에서는 기본적으로 두 개의 개별 파이프라인을 사용하여 모니터링 통계를
수집할 수 있다.
- [**리소스 메트릭 파이프라인**](#리소스-메트릭-파이프라인)은 HorizontalPodAutoscaler
컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로
제한된 집합을 제공한다. 이 메트릭은
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
에 의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. `metrics-server`는 클러스터
상의 모든 노드를 발견하고 각 노드의
[Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리
사용량을 질의한다. Kubelet은 [cAdvisor](https://github.com/google/cadvisor)에서
데이터를 가져온다. `metrics-server`는 경량의 단기 인메모리 저장소이다.
- 프로메테우스 같이 [**완전한 메트릭 파이프라인**](#완전한-메트릭-파이프라인)은 보다 풍부한
메트릭에 액세스할 수 있게 해준다. 추가적으로 쿠버네티스는 Horizontal Pod Autoscaler와
같은 메커니즘을 사용하여 현재 상태를 기반으로 클러스터를 자동으로 확장 또는
조정함으로써 이런 메트릭에 응답할 수 있다. 모니터링 파이프라인은 Kubelet에서
메트릭을 가져온 다음 `custom.metrics.k8s.io` 이나
`external.metrics.k8s.io` API로 구현된 어댑터를 통해
이들을 쿠버네티스에 노출한다.
## 리소스 메트릭 파이프라인
### Kubelet
Kubelet은 쿠버네티스 마스터와 노드들 사이의 다리 역할을 한다. 이는 머신 상에서 실행되는 파드들과 컨테이너들을 관리한다. Kubelet은 각 파드를 이를 구성하는 컨테이너들로 변환하며 컨테이너 런타임 인터페이스를 통해 컨테이너 런타임에서 개별 컨테이너의 사용량 통계를 가져온다. 레거시 도커 통합에서는 cAdvisor에서 이 정보를 가져온다. 그런 다음 Kubelet 리소스 메트릭 API를 통해 집계된 파드 리소스 사용량 통계를 노출한다. 이 API는 Kubelet의 인증되고 읽기 전용의 포트들 상에서 `/metrics/resource/v1alpha1`으로 제공된다.
### cAdvisor
cAdvisor는 오픈 소스 컨테이너 자원 사용률/성능 분석 에이전트이다. 이는 컨테이너 전용으로 설계되었으며 도커 컨테이너를 기본적으로 지원한다. 쿠버네티스에서 cAdvisor는 Kubelet 바이너리와 통합된다. cAdvisor는 머신 내 모든 컨테이너를 자동으로 발견하며 CPU, 메모리, 파일시스템, 네트워크 사용량 통계를 수집한다. cAdvisor는 또한 machine 상의 'root' 컨테이너 분석에 의한 전체 머신 사용량도 제공한다.
Kubelet은 기본 포트 4194를 통해 머신의 컨테이너에 대한 단순한 cAdvisor UI를 노출한다.
아래 그림은 전체 머신의 사용량을 예제로 보여준다. 하지만, 이 기능은 v1.10에서는 사용 중단(deprecated)으로
표시되었으며, v1.12에서는 완전히 제거되었다.
![cAdvisor](/images/docs/cadvisor.png)
v1.13부터, [cAdvisor를 데몬셋으로 배포](https://github.com/google/cadvisor/tree/master/deploy/kubernetes)하여 cAdvisor UI에 액세스할 수 있다.
## 완전한 메트릭 파이프라인
쿠버네티스를 위한 많은 완전한 메트릭 솔루션들이 존재한다.
### 프로메테우스
[프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다.
[Prometheus Operator](https://coreos.com/operators/prometheus/docs/latest/)는
쿠버네티스에서 프로메테우스 설정을 단순화하고,
[Prometheus adapter](https://github.com/directxman12/k8s-prometheus-adapter)를
사용하여 커스텀 메트릭 API를 제공할 수 있게 해준다.
프로메테우스는 강력한 쿼리 언어와 데이터 쿼리와 시각화를 위한 내장 대시보드를 제공한다.
또한 [Grafana](https://prometheus.io/docs/visualization/grafana/)에서는
데이터 소스로 프로메테우스가 지원된다.
### Sysdig
[Sysdig](http://sysdig.com)는 완전한 스펙트럼 컨테이너와 플랫폼 인텔리전스를 제공하며,
진정한 컨테이너 네이티브 솔루션이다. Sysdig는 시스템 호출, 쿠버네티스 이벤트, 프로메테우스 메트릭,
statsD, JMX 등의 데이터를 하나의 창으로 통합하여 환경에 대한 포괄적인 그림을 제공한다.
또한 Sysdig는 강력하고 사용자 정의가 가능한 솔루션을 제공하기 위해 쿼리를 실행할 수 있는 API를 제공한다.
Sysdig는 오픈 소스로 만들어졌다. [Sysdig와 Sysdig Inspect](https://sysdig.com/opensource/inspect/)는
자유롭게 트러블슈팅, 분석, 포렌식을 수행할 수 있는 기능을 제공한다.
### 구글 클라우드 모니터링
구글 클라우드 모니터링은 호스팅 모니터링 서비스로 애플리케이션의
중요한 메트릭을 시각화하고 경고하는데 사용할 수 있으며,
쿠버네티스에서 메트릭을 수집하고
[Cloud Monitoring Console](https://app.google.stackdriver.com/)을
통해 이 메트릭들에 접근할 수 있다. 대시보드를 만들고 사용자 정의하여 쿠버네티스 클러스터에서
수집한 데이터를 시각화할 수 있다.
이 동영상은 힙스터(Heapster)를 기반으로 구글 클라우드 모니터링을 구성하고 실행하는 방법을 보여준다.
[![힙스터를 기반으로 구글 클라우드 모니터링을 구성하고 실행하는 방법](https://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](https://www.youtube.com/watch?v=xSMNR2fcoLs)
{{< figure src="/images/docs/gcm.png" alt="구글 클라우드 모니터링 대시보드 예제" title="구글 클라우드 모니터링 대시보드 예제" caption="대시보드는 클러스터 전역의 리소스 사용량을 보여준다." >}}
## 크론잡 모니터링
### Kubernetes Job Monitor
[Kubernetes Job Monitor](https://github.com/pietervogelaar/kubernetes-job-monitor) 대시보드를 사용하여 클러스터 관리자는 실행되고 있는 잡들과 완료된 잡의 상태를 볼 수 있다.
### New Relic 쿠버네티스 모니터링 통합
[New Relic 쿠버네티스](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration) 통합은 쿠버네티스 환경의 성능에 대한 가시성을 향상시킨다. New Relic의 쿠버네티스 통합은 쿠버네티스 오브젝트의 메트릭을 리포팅하는 것으로 컨테이너 오케스트레이션 계층을 측정한다. 통합을 통해 쿠버네티스 노드, 네임스페이스, 디플로이먼트, 레플리카 셋, 파드, 컨테이너에 대한 인사이트를 얻을 수 있다.
중요 기능:
사전 구축된 대시보드에서 데이터를 확인하여 쿠버네티스 환경에 대한 즉각적인 인사이트를 확인한다.
자동으로 보고되는 데이터의 인사이트로 커스텀 쿼리와 차트를 생성한다.
쿠버네티스 데이터에 대해 경고 조건을 생성한다.
이 [페이지](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration)에서 더 알아볼 수 있다.
{{% /capture %}}
content/ko/docs/tasks/inject-data-application/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "애플리케이션에 데이터 주입하기"
weight: 30
---
content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md
+120
View File
@@ -0,0 +1,120 @@
---
title: 컨테이너를 위한 환경 변수 정의하기
content_template: templates/task
weight: 20
---
{{% capture overview %}}
본 페이지는 쿠버네티스 파드의 컨테이너를 위한 환경 변수를
정의하는 방법에 대해 설명한다.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 컨테이너를 위한 환경 변수 정의하기
파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 환경 변수를 설정할
수 있다. 환경 변수를 설정하려면, 구성 파일에 `env`나 `envFrom` 필드를
포함시켜야 한다.
이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는
값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 파일
예시이다.
{{< codenew file="pods/inject/envars.yaml" >}}
1. YAML 구성 파일을 활용해 파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
```
1. 실행 중인 파드들의 목록을 조회한다.
```shell
kubectl get pods -l purpose=demonstrate-envars
```
출력은 아래와 비슷할 것이다.
```
NAME READY STATUS RESTARTS AGE
envar-demo 1/1 Running 0 9s
```
1. 파드 안에 실행되고 있는 컨테이너의 셸에 접근한다.
```shell
kubectl exec -it envar-demo -- /bin/bash
```
1. 셸 안에서, 환경 변수를 나열하기 위해 `printenv` 커맨드를 실행한다.
```shell
root@envar-demo:/# printenv
```
출력은 아래와 비슷할 것이다.
```
NODE_VERSION=4.4.2
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
HOSTNAME=envar-demo
...
DEMO_GREETING=Hello from the environment
DEMO_FAREWELL=Such a sweet sorrow
```
1. 셸에서 빠져나오기 위해, `exit`을 입력한다.
{{< note >}}
`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지
안에서 명시된 어떠한 환경 변수들보다 더 우선시된다.
{{< /note >}}
## 설정 안에서 환경 변수 사용하기
파드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드들과 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 `NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, 그리고 `Kubernetes`로 설정되어 있다. 이들 환경 변수들은 이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 사용된다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: print-greeting
spec:
containers:
- name: env-print-demo
image: bash
env:
- name: GREETING
value: "Warm greetings to"
- name: HONORIFIC
value: "The Most Honorable"
- name: NAME
value: "Kubernetes"
command: ["echo"]
args: ["$(GREETING) $(HONORIFIC) $(NAME)"]
```
컨테이너가 생성되면, `echo Warm greetings to The Most Honorable Kubernetes` 커맨드가 컨테이너에서 실행된다.
{{% /capture %}}
{{% capture whatsnext %}}
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
* [시크릿을 환경 변수로 사용하기](/docs/user-guide/secrets/#using-secrets-as-environment-variables)에 대해 알아본다.
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
{{% /capture %}}
content/ko/docs/tutorials/kubernetes-basics/_index.html
+2
View File
@@ -42,6 +42,8 @@ card:
</div>
</div>
<br>
<div id="basics-modules" class="content__modules">
<h2>쿠버네티스 기초 모듈</h2>
<div class="row">
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
+153 -153
View File
@@ -6,13 +6,13 @@ weight: 10
---
{{% capture overview %}}
이 튜토리얼은 스테이트풀셋([StatefulSets](/docs/concepts/workloads/controllers/statefulset/))을 이용하여
애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며
이 튜토리얼은 스테이트풀셋([StatefulSets](/docs/concepts/workloads/controllers/statefulset/))을 이용하여
애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며
스케일링하고 업데이트하는지 시연한다.
{{% /capture %}}
{{% capture prerequisites %}}
튜토리얼을 시작하기 전에 다음의 쿠버네티스 컨셉에 대해
튜토리얼을 시작하기 전에 다음의 쿠버네티스 컨셉에 대해
익숙해야 한다.
* [파드](/docs/user-guide/pods/single-container/)
@@ -23,17 +23,17 @@ weight: 10
* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)
* [kubectl CLI](/docs/user-guide/kubectl/)
이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록
설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면,
튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을
이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록
설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면,
튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을
프로비저닝해야 한다.
{{% /capture %}}
{{% capture objectives %}}
스테이트풀셋은 상태 유지가 필요한(stateful) 애플리케이션과 분산시스템에서
이용하도록 의도했다. 그러나 쿠버네티스 상에 스테이트풀 애플리케이션과
분산시스템을 관리하는 것은 광범위하고 복잡한 주제이다. 스테이트풀셋의 기본 기능을 보여주기 위해
이 둘을 결합하지 않고, 스테이트풀셋을 사용한
스테이트풀셋은 상태 유지가 필요한(stateful) 애플리케이션과 분산시스템에서
이용하도록 의도했다. 그러나 쿠버네티스 상에 스테이트풀 애플리케이션과
분산시스템을 관리하는 것은 광범위하고 복잡한 주제이다. 스테이트풀셋의 기본 기능을 보여주기 위해
이 둘을 결합하지 않고, 스테이트풀셋을 사용한
단순 웹 애플리케이션을 배포할 것이다.
이 튜토리얼을 마치면 다음 항목에 대해 익숙해질 것이다.
@@ -48,26 +48,26 @@ weight: 10
{{% capture lessoncontent %}}
## 스테이트풀셋 생성하기
아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는
[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인
예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인
아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는
[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인
예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인
`nginx` 를 생성한다.
{{< codenew file="application/web/web.yaml" >}}
위에 예제를 다운로드 받아서 파일이름을 `web.yaml`으로 저장하자.
2개의 터미널창을 사용한다. 첫째 터미널에서
[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)을 이용해서
2개의 터미널창을 사용한다. 첫째 터미널에서
[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)을 이용해서
스테이트풀셋의 파드가 생성되는지 감시하자.
```shell
kubectl get pods -w -l app=nginx
```
두번째 터미널에서
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)로
두번째 터미널에서
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)로
`web.yaml`에 정의된 헤드리스 서비스와 스테이트풀셋을 생성한다.
```shell
@@ -76,8 +76,8 @@ service/nginx created
statefulset.apps/web created
```
상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를
실행하는 2개의 파드를 생성한다. `nginx` 서비스와
상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를
실행하는 2개의 파드를 생성한다. `nginx` 서비스와
`web` 스테이트풀셋이 성공적으로 생성되었는지 알아보자.
```shell
@@ -92,9 +92,9 @@ web 2 1 20s
### 차례대로 파드 생성하기
N개의 레플리카를 가진 스테이트풀셋은 배포시에
순차적으로 {0..N-1} 순으로 생성된다.
첫째 터미널에서 `kubectl get` 명령의 출력 내용을 살펴보자.
N개의 레플리카를 가진 스테이트풀셋은 배포시에
순차적으로 {0..N-1} 순으로 생성된다.
첫째 터미널에서 `kubectl get` 명령의 출력 내용을 살펴보자.
결국 그 내용은 아래 예와 비슷할 것이다.
```shell
@@ -110,7 +110,7 @@ web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 18s
```
`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/docs/user-guide/pod-states) 상태가 되기 전에
`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/docs/user-guide/pod-states) 상태가 되기 전에
시작하지 않음을 주의하자.
## 스테이트풀셋 안에 파드
@@ -129,17 +129,17 @@ web-1 1/1 Running 0 1m
```
[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서
언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다.
이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는
고유한 순번에 기인한다. 파드의 이름의 형식은
`<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은
[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서
언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다.
이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는
고유한 순번에 기인한다. 파드의 이름의 형식은
`<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은
2개의 레플리카를 가졌으므로 `web-0` 과 `web-1` 2개 파드를 생성한다.
### 안정적인 네트워크 신원 사용하기
각 파드는 각 순번에 따른 안정적인 호스트네임을 갖는다. 각 파드에서
`hostname` 명령어를 실행하도록
각 파드는 각 순번에 따른 안정적인 호스트네임을 갖는다. 각 파드에서
`hostname` 명령어를 실행하도록
[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 이용하자.
```shell
@@ -148,13 +148,13 @@ web-0
web-1
```
`dnsutils` 패키지에서 `nslookup` 명령을 제공하는 컨테이너를
실행하도록 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)을 이용하자.
파드의 호스트네임에 `nslookup`을 이용하면 클러스터 내부 DNS 주소를
`dnsutils` 패키지에서 `nslookup` 명령을 제공하는 컨테이너를
실행하도록 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)을 이용하자.
파드의 호스트네임에 `nslookup`을 이용하면 클러스터 내부 DNS 주소를
확인할 수 있다.
```shell
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
nslookup web-0.nginx
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
@@ -171,7 +171,7 @@ Address 1: 10.244.2.6
```
헤드리스 서비스의 CNAME은 SRV 레코드를 지칭한다
(Running과 Ready 상태의 각 파드마다 1개).
(Running과 Ready 상태의 각 파드마다 1개).
SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지칭한다.
첫째 터미널에서 스테이트풀셋의 파드를 가져오자.
@@ -179,8 +179,8 @@ SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지
```shell
kubectl get pod -w -l app=nginx
```
두번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기위해
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)를
두번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기위해
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)를
이용하자.
```shell
@@ -189,7 +189,7 @@ pod "web-0" deleted
pod "web-1" deleted
```
스테이트풀셋이 재시작되고 두 파드가 Running과 Ready 상태로
스테이트풀셋이 재시작되고 두 파드가 Running과 Ready 상태로
전환되도록 기다리자.
```shell
@@ -204,7 +204,7 @@ web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 34s
```
파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해
파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해
`kubectl exec`과 `kubectl run`을 이용하자.
```shell
@@ -212,7 +212,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
web-0
web-1
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh
nslookup web-0.nginx
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
@@ -228,23 +228,23 @@ Name: web-1.nginx
Address 1: 10.244.2.8
```
파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만
파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나
다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로
파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만
파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나
다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로
스테이트풀셋의 파드에 접속하지 않도록 하는 것이 중요하다.
스테이트풀셋의 활성 맴버를 찾아 연결할 경우
헤드리스 서비스(`nginx.default.svc.cluster.local`)의 CNAME을 쿼리해야 한다.
CNAME과 연관된 SRV 레코드는 스테이트풀셋의
Running과 Ready 상태의 모든 파드들을
스테이트풀셋의 활성 맴버를 찾아 연결할 경우
헤드리스 서비스(`nginx.default.svc.cluster.local`)의 CNAME을 쿼리해야 한다.
CNAME과 연관된 SRV 레코드는 스테이트풀셋의
Running과 Ready 상태의 모든 파드들을
담고 있다.
애플리케이션에서 이미 활성상태(liveness)와 준비성(readiness) 테스트하는
연결 로직을 구현되어 있다면
애플리케이션에서 이미 활성상태(liveness)와 준비성(readiness) 테스트하는
연결 로직을 구현되어 있다면
파드`web-0.nginx.default.svc.cluster.local`,
`web-1.nginx.default.svc.cluster.local`)의 SRV레코드를 안정적으로 사용할 수 있어
애플리케이션은 파드가 Running과 Ready 상태로 전환할 때
`web-1.nginx.default.svc.cluster.local`)의 SRV레코드를 안정적으로 사용할 수 있어
애플리케이션은 파드가 Running과 Ready 상태로 전환할 때
파드의 주소를 검색할 수 있다.
### 안정적인 스토리지에 쓰기 {#writing-to-stable-storage}
@@ -257,16 +257,16 @@ NAME STATUS VOLUME CAPACITY ACCE
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
```
스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)에
묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로
스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)에
묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로
프로비저닝하도록 설정되었으므로 생성된 퍼시스턴트볼륨도 자동으로 묶인다.
NGINX 웹서버는 기본 색인 파일로
`/usr/share/nginx/html/index.html`을 이용합니다.
스테이트풀셋 `spec`내의 `volumeMounts` 필드는 `/usr/share/nginx/html` 디렉터리가
NGINX 웹서버는 기본 색인 파일로
`/usr/share/nginx/html/index.html`을 이용합니다.
스테이트풀셋 `spec`내의 `volumeMounts` 필드는 `/usr/share/nginx/html` 디렉터리가
퍼시스턴트볼륨으로 제공되는지 보증합니다.
파드의 호스트네임을 `index.html` 파일에 작성하고
파드의 호스트네임을 `index.html` 파일에 작성하고
NGINX 웹서버가 해당 호스트네임을 제공하는지 확인해보자.
```shell
@@ -278,7 +278,7 @@ web-1
```
{{< note >}}
위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면
위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면
`volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다
([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함).
@@ -302,7 +302,7 @@ kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
```
첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고,
첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고,
모든 파드가 Running과 Ready 상태로 전환될때까지 기다리자.
```shell
@@ -325,16 +325,16 @@ web-0
web-1
```
비록 `web-0`과 `web-1`이 재스케줄링되어도 계속해서
자신의 호스트네임을 제공하는데 이는 각 퍼시스턴트볼륨클레임에
연관된 퍼시스턴트볼륨이 해당 `volumeMounts`로 재마운트되기 때문이다.
`web-0`과 `web-1`의 스케줄링에 관계없이
비록 `web-0`과 `web-1`이 재스케줄링되어도 계속해서
자신의 호스트네임을 제공하는데 이는 각 퍼시스턴트볼륨클레임에
연관된 퍼시스턴트볼륨이 해당 `volumeMounts`로 재마운트되기 때문이다.
`web-0`과 `web-1`의 스케줄링에 관계없이
각각의 퍼시스턴트볼륨은 적절하게 마운트된다.
## 스테이트풀셋 스케일링
스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다.
[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나
[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을
스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다.
[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나
[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을
이용해서 스테이트풀셋을 스케일링할 수 있다.
### 스케일 업
@@ -345,7 +345,7 @@ web-1
kubectl get pods -w -l app=nginx
```
다른 터미널창에서 `kubectl scale`을 이용하여 레플리카 개수를
다른 터미널창에서 `kubectl scale`을 이용하여 레플리카 개수를
5로 스케일링하자.
```shell
@@ -353,7 +353,7 @@ kubectl scale sts web --replicas=5
statefulset.apps/web scaled
```
첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고,
첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고,
3개의 추가 파드가 Running과 Ready 상태로 전환될때까지 기다리자.
```shell
@@ -376,10 +376,10 @@ web-4 0/1 ContainerCreating 0 0s
web-4 1/1 Running 0 19s
```
스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다.
[스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는
각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에
이전 파드가 Running과 Ready 상태가 될때까지
스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다.
[스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는
각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에
이전 파드가 Running과 Ready 상태가 될때까지
기다린다.
### 스케일 다운 {#scaling-down}
@@ -418,8 +418,8 @@ web-3 1/1 Terminating 0 42s
### 순차 파드 종료
컨트롤러는 순번의 역순으로 한번에 1개 파드를 삭제하고
다음 파드를 삭제하기 전에
컨트롤러는 순번의 역순으로 한번에 1개 파드를 삭제하고
다음 파드를 삭제하기 전에
각각이 완전하게 종료되기까지 기다린다.
스테이트풀셋의 퍼시스턴트볼륨클레임을 가져오자.
@@ -435,23 +435,23 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO
```
여전히 5개의 퍼시스턴트볼륨클레임과 5개의 퍼시스턴트볼륨이 있다.
여전히 5개의 퍼시스턴트볼륨클레임과 5개의 퍼시스턴트볼륨이 있다.
파드의 [안전한 스토리지](#writing-to-stable-storage)를 탐색하면서 스테이트풀셋의 파드가 삭제될 때에 파드에 마운트된 스테이트풀셋의 퍼시스턴트볼륨이 삭제되지 않은 것을 보았다. 스테이트풀셋 스케일 다운으로 파드 삭제할 때에도 여전히 사실이다.
## 스테이트풀셋 업데이트하기
쿠버네티스 1.7 이상에서 스테이트풀셋 컨트롤러는 자동 업데이트를 지원한다.
전략은 스테이트풀셋 API 오브젝트의 `spec.updateStrategy` 필드로 결정된다.
이 기능은 컨테이너 이미지, 스테이트풀셋의 리소스 요청이나
혹은 한계와 레이블과 파드의 어노테이션을 업그레이드하기 위해 사용될 수 있다.
`RollingUpdate`과 `OnDelete`의 2개의
쿠버네티스 1.7 이상에서 스테이트풀셋 컨트롤러는 자동 업데이트를 지원한다.
전략은 스테이트풀셋 API 오브젝트의 `spec.updateStrategy` 필드로 결정된다.
이 기능은 컨테이너 이미지, 스테이트풀셋의 리소스 요청이나
혹은 한계와 레이블과 파드의 어노테이션을 업그레이드하기 위해 사용될 수 있다.
`RollingUpdate`과 `OnDelete`의 2개의
유효한 업데이트 전략이 있다.
`RollingUpdate` 업데이트 전략은 스테이트풀셋에서 기본 값이다.
### 롤링 업데이트
`RollingUpdate` 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다.
`RollingUpdate` 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다.
스테이트풀셋 `web`의 업데이트 전략을 `RollingUpdate`으로 패치하자.
@@ -460,7 +460,7 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda
statefulset.apps/web patched
```
터미널 창에서 스테이트풀셋 `web`의 컨테이너 이미지를 바꾸도록
터미널 창에서 스테이트풀셋 `web`의 컨테이너 이미지를 바꾸도록
또 패치하자.
```shell
@@ -506,15 +506,15 @@ web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 10s
```
스테이트풀셋 내에 파드는 순번의 역순으로 업데이트된다.
이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에
그것이 Running과 Ready 상태로 전환될때까지 기다린다.
알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지
다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다.
업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는
이전 버전으로 복원한다.
이런 식으로 컨트롤러는 간헐적인 오류가 발생해도
애플리케이션을 계속 건강하게 유지하고
스테이트풀셋 내에 파드는 순번의 역순으로 업데이트된다.
이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에
그것이 Running과 Ready 상태로 전환될때까지 기다린다.
알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지
다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다.
업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는
이전 버전으로 복원한다.
이런 식으로 컨트롤러는 간헐적인 오류가 발생해도
애플리케이션을 계속 건강하게 유지하고
업데이트도 일관되게 유지하려 한다.
컨테이너 이미지를 살펴보기 위해 파드를 가져오자.
@@ -529,13 +529,13 @@ k8s.gcr.io/nginx-slim:0.8
스테이트풀셋의 모든 파드가 지금은 이전 컨테이너 이미지를 실행 중이이다.
**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/<name>`
**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/<name>`
명령어도 사용할 수 있다.
#### 단계적으로 업데이트 하기 {#staging-an-update}
`RollingUpdate` 업데이트 전략의 파라미터인 `partition`를 이용하여
스테이트풀셋의 단계적으로 업데이트할 수 있다.
단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서
단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서
스테이트풀셋의 `.spec.template`에 변경을 허용한다.
스테이트풀셋 `web`의 `updateStrategy` 필드에 partition을 추가하자.
@@ -579,12 +579,12 @@ k8s.gcr.io/nginx-slim:0.8
```
비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은
파드를 그것의 원래 컨테이너로 복원한다.
파드의 순번이 `updateStrategy`에서 지정된
파드를 그것의 원래 컨테이너로 복원한다.
파드의 순번이 `updateStrategy`에서 지정된
`파티션`보다 작기 때문이다.
#### 카나리(Canary) 롤링 아웃
[위에서](#staging-an-update) 지정한 `partition`값을 차감시키면
[위에서](#staging-an-update) 지정한 `partition`값을 차감시키면
변경사항을 테스트하기 위해 카나리 롤아웃을 할 수 있다.
스테이트풀셋에 partition을 차감하도록 패치하자.
@@ -614,7 +614,7 @@ k8s.gcr.io/nginx-slim:0.7
```
`partition`을 바꾸면 스테이트풀셋 컨트롤러는 자동으로
`web-2` 파드를 업데이트하는데
`web-2` 파드를 업데이트하는데
이는 해당 파드의 순번이 `partition` 이상이기 때문이다.
`web-1` 파드를 삭제하자.
@@ -649,17 +649,17 @@ k8s.gcr.io/nginx-slim:0.8
```
`web-1` 는 원래 환경설정으로 복원되었는데
이는 파드의 순번이 partition보다 작기 때문이다.
스테이트풀셋의 `.spec.template`이 갱신되면, 지정된 partition 이상의 순번을
가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나
`web-1` 는 원래 환경설정으로 복원되었는데
이는 파드의 순번이 partition보다 작기 때문이다.
스테이트풀셋의 `.spec.template`이 갱신되면, 지정된 partition 이상의 순번을
가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나
종료되어 원래 환경설정으로 복원된다.
#### 단계적 롤아웃
[카나리 롤아웃](#rolling-out-a-canary)에서 했던 방법과 비슷하게
분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을
수행할 수 있다. 단계적 롤아웃을 수행하려면
컨트롤러가 업데이트를 일시 중지할 순번으로
[카나리 롤아웃](#rolling-out-a-canary)에서 했던 방법과 비슷하게
분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을
수행할 수 있다. 단계적 롤아웃을 수행하려면
컨트롤러가 업데이트를 일시 중지할 순번으로
`partition`를 정하자.
partition은 현재 `2`이다. partition을 `0`으로 바꾸자.
@@ -700,20 +700,20 @@ k8s.gcr.io/nginx-slim:0.7
```
`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서
`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서
업데이트 처리를 하도록 허용하였다.
### 삭제시 동작
`OnDelete` 업데이트 전략은 예전 동작(1.6 이하)으로,
이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의
`.spec.template` 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다.
`.spec.template` 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다.
이 전략은 `.spec.template.updateStrategy.type`을 `OnDelete`로 설정하여 선택할 수 있다.
## 스테이트풀셋 삭제하기
스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다.
비종속적 삭제에서는 스테이트풀셋이 지워질 때에 스테이트풀셋의 파드는 지워지지 않는다.
스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다.
비종속적 삭제에서는 스테이트풀셋이 지워질 때에 스테이트풀셋의 파드는 지워지지 않는다.
종속적 삭제에서는 스테이트풀셋과 그에 속한 파드가 모두 지워진다.
### 비종속적 삭제
@@ -724,9 +724,9 @@ k8s.gcr.io/nginx-slim:0.7
kubectl get pods -w -l app=nginx
```
다른 터미널에서는 스테이트풀셋을 지우기 위해
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령어를 이용하자.
이 명령어에 `--cascade=false` 파라미터가 추가되었다.
다른 터미널에서는 스테이트풀셋을 지우기 위해
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령어를 이용하자.
이 명령어에 `--cascade=false` 파라미터가 추가되었다.
이 파라미터는 쿠버네티스에 스테이트풀셋만 삭제하고 그에 속한 파드는 지우지 않도록 요청한다.
```shell
@@ -744,7 +744,7 @@ web-1 1/1 Running 0 7m
web-2 1/1 Running 0 5m
```
비록 `web`이 삭제되고 있어도, 모든 파드는 여전히 Running과 Ready 상태이다.
비록 `web`이 삭제되고 있어도, 모든 파드는 여전히 Running과 Ready 상태이다.
`web-0`을 삭제하자.
```shell
@@ -769,17 +769,17 @@ web-2 1/1 Running 0 7m
kubectl get pods -w -l app=nginx
```
두번째 터미널에서 스테이트풀셋을 다시 생성하자.
`nginx` 서비스(가지지 말았어야 하는)를 삭제하기 전까지는 그 서비스가 이미 존재한다는 에러를
두번째 터미널에서 스테이트풀셋을 다시 생성하자.
`nginx` 서비스(가지지 말았어야 하는)를 삭제하기 전까지는 그 서비스가 이미 존재한다는 에러를
볼 것이라는 것을 명심하자.
```shell
kubectl apply -f web.yaml
statefulset.apps/web created
Error from server (AlreadyExists): error when creating "web.yaml": services "nginx" already exists
service/nginx unchanged
```
이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도
이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도
nginx 헤드리스 서비스를 생성하려고 했음을 뜻한다.
첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보자.
@@ -800,14 +800,14 @@ web-2 0/1 Terminating 0 3m
web-2 0/1 Terminating 0 3m
```
`web` 스테이트풀셋이 다시 생성될때 먼저 `web-0` 시작한다.
`web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로
전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고
`web-0`을 재생성했다면 `web-1`이
이미 Running과 Ready 상태이고,
`web` 스테이트풀셋이 다시 생성될때 먼저 `web-0` 시작한다.
`web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로
전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고
`web-0`을 재생성했다면 `web-1`이
이미 Running과 Ready 상태이고,
`web-2`은 종료되었을 것이다.
파드의 웹서버에서 제공한 `index.html` 파일 내용을
파드의 웹서버에서 제공한 `index.html` 파일 내용을
다른 관점으로 살펴보자.
```shell
@@ -816,10 +816,10 @@ web-0
web-1
```
스테이트풀셋과 `web-0` 파드를 둘다 삭제했으나 여전히 `index.html` 파일에 입력했던
원래 호스트네임을 제공한다. 스테이트풀셋은
파드에 할당된 퍼시스턴트볼륨을 결코 삭제하지 않기때문이다.
다시 스테이트풀셋을 생성하면 `web-0`을 시작하며
스테이트풀셋과 `web-0` 파드를 둘다 삭제했으나 여전히 `index.html` 파일에 입력했던
원래 호스트네임을 제공한다. 스테이트풀셋은
파드에 할당된 퍼시스턴트볼륨을 결코 삭제하지 않기때문이다.
다시 스테이트풀셋을 생성하면 `web-0`을 시작하며
원래 퍼시스턴트볼륨을 다시 마운트한다.
### 단계식 삭제
@@ -830,14 +830,14 @@ web-1
kubectl get pods -w -l app=nginx
```
다른 터미널창에서 스테이트풀셋을 다시 지우자. 이번에는
다른 터미널창에서 스테이트풀셋을 다시 지우자. 이번에는
`--cascade=false` 파라미터를 생략하자.
```shell
kubectl delete statefulset web
statefulset.apps "web" deleted
```
첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고
첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고
모든 파드가 Terminating 상태로 전환될때까지 기다리자.
```shell
@@ -857,13 +857,13 @@ web-1 0/1 Terminating 0 29m
```
[스케일 다운](#scaling-down) 섹션에서 보았듯 파드는
각 순번의 역순으로 하나씩 종료된다. 파드가 종료될 때
스테이트풀 컨트롤러는 이전 파드가
[스케일 다운](#scaling-down) 섹션에서 보았듯 파드는
각 순번의 역순으로 하나씩 종료된다. 파드가 종료될 때
스테이트풀 컨트롤러는 이전 파드가
완전히 종료되기까지 기다린다.
스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를
삭제하지 않음을 주의하자.
스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를
삭제하지 않음을 주의하자.
꼭 `nginx` 서비스를 수동으로 삭제해라.
```shell
@@ -879,7 +879,7 @@ service/nginx created
statefulset.apps/web created
```
스테이트풀셋의 모든 파드가 Running과 Ready 상태로 전환될 때
스테이트풀셋의 모든 파드가 Running과 Ready 상태로 전환될 때
`index.html` 파일 내용을 검색하자.
```shell
@@ -888,8 +888,8 @@ web-0
web-1
```
스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로
다시 생성되고 `web-0`과 `web-1`은 여전히
스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로
다시 생성되고 `web-0`과 `web-1`은 여전히
각 호스트네임을 제공한다.
최종적으로 `web` 스테이트풀셋과`nginx` 서비스를 삭제한다.
@@ -904,29 +904,29 @@ statefulset "web" deleted
## 파드 관리 정책
일부 분산 시스템의 경우 스테이트풀셋의 순서 보증은
불필요하거나 바람직하지 않다. 이러한 시스템은 고유성과 신원만 필요하다.
이를 해결하기 위해 쿠버네티스 1.7에서 `.spec.podManagementPolicy`를
일부 분산 시스템의 경우 스테이트풀셋의 순서 보증은
불필요하거나 바람직하지 않다. 이러한 시스템은 고유성과 신원만 필요하다.
이를 해결하기 위해 쿠버네티스 1.7에서 `.spec.podManagementPolicy`를
스테이트풀셋 API 오브젝트에 도입했다.
### OrderedReady 파드 관리
`OrderedReady` 파드 관리는 스테이트풀셋에서는 기본이다.
이는 스테이트풀셋 컨트롤러가 지금까지 위에서 설명했던 순서를
`OrderedReady` 파드 관리는 스테이트풀셋에서는 기본이다.
이는 스테이트풀셋 컨트롤러가 지금까지 위에서 설명했던 순서를
보증함을 뜻한다.
### Parallel 파드 관리
`Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를
병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에
파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지
`Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를
병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에
파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지
기다리지 않음을 뜻한다.
{{< codenew file="application/web/web-parallel.yaml" >}}
상기 예제를 다운로드받아 파일 이름을 `web-parallel.yaml`로 저장하자.
이 매니페스트는 `web` 스테이트풀셋의 `.spec.podManagementPolicy`이
이 매니페스트는 `web` 스테이트풀셋의 `.spec.podManagementPolicy`이
`Parallel`인 것 말고는 이전에 다운로드 받았던 것과 동일하다.
터미널에서 스테이트풀셋의 파드를 감시하자.
@@ -960,7 +960,7 @@ web-1 1/1 Running 0 10s
스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘다 동시에 시작했다.
두번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을
두번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을
스케일링 하자.
```shell
@@ -980,7 +980,7 @@ web-3 1/1 Running 0 26s
```
스테이트풀 컨트롤러는 두개의 새 파드를 시작하였다.
스테이트풀 컨트롤러는 두개의 새 파드를 시작하였다.
두번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 떄까지 기다리지 않는다.
이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자.
@@ -1017,10 +1017,10 @@ web-3 0/1 Terminating 0 9m
web-3 0/1 Terminating 0 9m
```
스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에
스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에
그 파드의 순서상 후계자를 기다리지 않는다.
`kubectl get` 명령어가 실행된 터미널을 닫고
`kubectl get` 명령어가 실행된 터미널을 닫고
`nginx` 서비스를 삭제하자.
```shell
@@ -1029,9 +1029,9 @@ kubectl delete svc nginx
{{% /capture %}}
{{% capture cleanup %}}
이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한
이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한
퍼시스턴트 스토리지 미디어를 삭제해야 한다.
모든 스토리지를 반환하도록 환경, 스토리지 설정과
모든 스토리지를 반환하도록 환경, 스토리지 설정과
프로비저닝 방법에 따른 단계를 따르자.
{{% /capture %}}
content/ko/examples/pods/inject/envars.yaml
+15
View File
@@ -0,0 +1,15 @@
apiVersion: v1
kind: Pod
metadata:
name: envar-demo
labels:
purpose: demonstrate-envars
spec:
containers:
- name: envar-demo-container
image: gcr.io/google-samples/node-hello:1.0
env:
- name: DEMO_GREETING
value: "Hello from the environment"
- name: DEMO_FAREWELL
value: "Such a sweet sorrow"
content/zh/docs/concepts/overview/_index.md
Executable
+4
View File
@@ -0,0 +1,4 @@
---
title: "概述"
weight: 20
---
content/zh/docs/concepts/overview/components.md
+1
View File
@@ -6,6 +6,7 @@ redirect_from:
- "/docs/admin/cluster-components/"
- "/docs/admin/cluster-components.html"
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
本文档概述了 Kubernetes 所需的各种二进制组件, 用于提供齐全的功能。
content/zh/docs/concepts/overview/kubernetes-api.md
+5
View File
@@ -1,3 +1,8 @@
---
title: Kubernetes API
weight: 30
---
# Kubernetes API 概述
[API协议文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)描述了主系统和API概念。
content/zh/docs/concepts/overview/what-is-kubernetes.md
+1
View File
@@ -3,6 +3,7 @@ approvers:
- k8s-merge-robot
title: 认识 Kubernetes?
weight: 10
---
Kubernetes 是一个跨主机集群的 [开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作](http://www.slideshare.net/BrianGrant11/wso2con-us-2015-kubernetes-a-platform-for-automating-deployment-scaling-and-operations) , 提供以容器为中心的基础架构。
content/zh/docs/concepts/overview/working-with-objects/_index.md
Executable
+4
View File
@@ -0,0 +1,4 @@
---
title: "使用 Kubernetes 对象"
weight: 40
---
content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+1
View File
@@ -5,6 +5,7 @@ redirect_from:
- "/docs/concepts/abstractions/overview/"
- "/docs/concepts/abstractions/overview.html"
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
content/zh/docs/reference/kubectl/jsonpath.md
+12 -12
View File
@@ -49,15 +49,15 @@ JSONPath 模板由 {} 包起来的 JSONPath 表达式组成。
]
}
```
| 函数 | 描述 | 示例 | 结果 |
| ----------------- | ---------- | ---------------------------------------- | ---------------------------------------- |
| text | 纯文本 | kind is {.kind} | kind is List |
| @ | 当前对象 | {@} | 与输入相同 |
| . or [] | 子运算符 | {.kind} 或者 {['kind']} | List |
| .. | 递归下降 | {..name} | 127.0.0.1 127.0.0.2 myself e2e |
| * | 通配符，获取所有对象 | {.items[*].metadata.name} | [127.0.0.1 127.0.0.2] |
| [start:end :step] | 下标运算符 | {.users[0].name} | myself |
| [,] | 并集运算符 | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8] |
| ?() | 过滤 | {.users[?(@.name=="e2e")].user.password} | secret |
| range, end | 迭代列表 | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] |
| "" | 引用解释执行字符串 | {range .items[*]}{.metadata.name}{"\t"}{end} | 127.0.0.1 127.0.0.2 |
| 函数 | 描述 | 示例 | 结果 |
| ------------------- | ---------- | ------------------------------------------ | ------------------------------------------ |
| `text` | 纯文本 | `kind is {.kind}` | `kind is List` |
| `@` | 当前对象 | `{@}` | 与输入相同 |
| `.` 或者 `[]` | 子运算符 | `{.kind}` 或者 `{['kind']}` | `List` |
| `..` | 递归下降 | `{..name}` | `127.0.0.1 127.0.0.2 myself e2e` |
| `*` | 通配符，获取所有对象 | `{.items[*].metadata.name}` | `[127.0.0.1 127.0.0.2]` |
| `[start:end :step]` | 下标运算符 | `{.users[0].name}` | `myself` |
| `[,]` | 并集运算符 | `{.items[*]['metadata.name', 'status.capacity']}` | `127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]` |
| `?()` | 过滤 | `{.users[?(@.name=="e2e")].user.password}` | `secret` |
| `range`, `end` | 迭代列表 | `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}` | `[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]` |
| `''` | 引用解释执行字符串 | `{range .items[*]}{.metadata.name}{'\t'}{end}` | `127.0.0.1 127.0.0.2` |
layouts/shortcodes/kat-button
+1 -1
View File
@@ -1,3 +1,3 @@
<div id="my-panel" data-katacoda-ondemand="true" data-katacoda-env="minikube" data-katacoda-command="minikube version; minikube start" data-katacoda-ui="panel"></div>
<div id="my-panel" data-katacoda-ondemand="true" data-katacoda-port="30000" data-katacoda-env="minikube" data-katacoda-command="start.sh" data-katacoda-ui="panel"></div>
<script src="https://katacoda.com/embed.js"></script>
<button class="button" onclick="window.katacoda.init(); ">Launch Terminal</button>
static/_redirects
+1
View File
@@ -296,6 +296,7 @@
/docs/tasks/administer-cluster/romana-network-policy/ /docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/ 301
/docs/tasks/administer-cluster/running-cloud-controller.md /docs/tasks/administer-cluster/running-cloud-controller/ 301
/docs/tasks/administer-cluster/share-configuration/ /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ 301
/docs/tasks/administer-cluster/static-pod/ /docs/tasks/configure-pod-container/static-pod/ 301
/docs/tasks/administer-cluster/upgrade-1-6/ /docs/tasks/administer-cluster/upgrade-downgrade/upgrade-1-6/ 301
/docs/tasks/administer-cluster/weave-network-policy/ /docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/ 301
/docs/tasks/configure-pod-container/apply-resource-quota-limit/ /docs/tasks/administer-cluster/apply-resource-quota-limit/ 301
static/images/blog/2019-08-06-opa-gatekeeper/v3.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB