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

Merge branch 'master' into hyq-0427

Browse Source
This commit is contained in:
Cria Hu
2021-04-30 15:48:11 +08:00
committed by GitHub
parent af1879144e 43fcebde32
commit 493dae7a2c
125 changed files with 5935 additions and 4254 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/configuration/pod-priority-preemption.md
+9 -8
View File
@@ -353,13 +353,15 @@ the removal of the lowest priority Pods is not sufficient to allow the scheduler
to schedule the preemptor Pod, or if the lowest priority Pods are protected by
`PodDisruptionBudget`.
The only component that considers both QoS and Pod priority is
[kubelet out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/).
The kubelet ranks Pods for eviction first by whether or not their usage of the
starved resource exceeds requests, then by Priority, and then by the consumption
of the starved compute resource relative to the Pods' scheduling requests.
See
[evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)
The kubelet uses Priority to determine pod order for [out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/).
You can use the QoS class to estimate the order in which pods are most likely
to get evicted. The kubelet ranks pods for eviction based on the following factors:
1. Whether the starved resource usage exceeds requests
1. Pod Priority
1. Amount of resource usage relative to requests
See [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)
for more details.
kubelet out-of-resource eviction does not evict Pods when their
@@ -367,7 +369,6 @@ usage does not exceed their requests. If a Pod with lower priority is not
exceeding its requests, it won't be evicted. Another Pod with higher priority
that exceeds its requests may be evicted.
## {{% heading "whatsnext" %}}
* Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
content/en/docs/reference/access-authn-authz/authentication.md
+3 -5
View File
@@ -205,12 +205,10 @@ spec:
```
Service account bearer tokens are perfectly valid to use outside the cluster and
can be used to create identities for long standing jobs that wish to talk to the
Kubernetes API. To manually create a service account, simply use the `kubectl`
create serviceaccount (NAME)` command. This creates a service account in the
current namespace and an associated secret.
Kubernetes API. To manually create a service account, use the `kubectl create
serviceaccount (NAME)` command. This creates a service account in the current
namespace and an associated secret.
```bash
kubectl create serviceaccount jenkins
content/fr/docs/tasks/configure-pod-container/configure-pod-configmap.md
+684
View File
@@ -0,0 +1,684 @@
---
title: Configurer un pod pour utiliser une ConfigMap
content_template: templates/task
weight: 150
card:
name: tasks
weight: 50
---
<!-- overview -->
Les ConfigMaps vous permettent de découpler les artefacts de configuration du contenu de l'image pour garder les applications conteneurisées portables.
Cette page fournit une série d'exemples d'utilisation montrant comment créer des ConfigMaps et configurer des pods à l'aide des données stockées dans des ConfigMaps.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## Créer un ConfigMap
Vous pouvez utiliser soit `kubectl create configmap` ou un générateur ConfigMap dans `kustomization.yaml` pour créer un ConfigMap.
Notez que `kubectl` prends en charge `kustomization.yaml` à partir de la version 1.14.
### Créer un ConfigMap à l'aide de kubectl create configmap
Utilisez la commande `kubectl create configmap` pour créer des Configmaps depuis des [dossiers](#create-configmaps-from-directories), [fichiers](#create-configmaps-from-files), ou des [valeurs littérales](#create-configmaps-from-literal-values):
```shell
kubectl create configmap <map-name> <data-source>
```
où \<map-name> est le nom que vous souhaitez attribuer à ConfigMap et \<data-source> est le répertoire, le fichier ou la valeur littérale à partir de laquelle récupérer les données.
La source de données correspond à une paire clé-valeur dans ConfigMap, où
* clé = le nom du fichier ou la clé que vous avez fournie sur la ligne de commande, et
* valeur = le contenu du fichier ou la valeur littérale que vous avez fournie sur la ligne de commande.
Vous pouvez utiliser [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) ou [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) pour récupérer des informations sur un ConfigMap.
#### Créer des ConfigMaps à partir de répertoires
Vous pouvez utiliser `kubectl create configmap` pour créer un ConfigMap à partir de plusieurs fichiers dans le même répertoire.
Par exemple:
```shell
# Créez le répertoire local
mkdir -p configure-pod-container/configmap/
# Téléchargez les exemples de fichiers dans le répertoire `configure-pod-container/configmap/`
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
# Créer la configmap
kubectl create configmap game-config --from-file=configure-pod-container/configmap/
```
combine le contenu du répertoire `configure-pod-container/configmap/`
```shell
game.properties
ui.properties
```
dans le ConfigMap suivant:
```shell
kubectl describe configmaps game-config
```
où la sortie est similaire à ceci:
```text
Name: game-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
ui.properties: 83 bytes
```
Les fichiers `game.properties` et `ui.properties` dans le répertoire `configure-pod-container/configmap/` sont représentés dans la section `data` de la ConfigMap.
```shell
kubectl get configmaps game-config -o yaml
```
La sortie est similaire à ceci:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:52:05Z
name: game-config
namespace: default
resourceVersion: "516"
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
data:
game.properties: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
```
#### Créer des ConfigMaps à partir de fichiers
Vous pouvez utiliser `kubectl create configmap` pour créer un ConfigMap à partir d'un fichier individuel ou de plusieurs fichiers.
Par exemple,
```shell
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties
```
produirait le ConfigMap suivant:
```shell
kubectl describe configmaps game-config-2
```
où la sortie est similaire à ceci:
```text
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
```
Vous pouvez passer l'argument `--from-file` plusieurs fois pour créer un ConfigMap à partir de plusieurs sources de données.
```shell
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties
```
Décrivez la ConfigMap crée `game-config-2`:
```shell
kubectl describe configmaps game-config-2
```
La sortie est similaire à ceci:
```text
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: 158 bytes
ui.properties: 83 bytes
```
Utilisez l'option `--from-env-file` pour créer un ConfigMap à partir d'un fichier env, par exemple:
```shell
# Les fichiers env contiennent une liste de variables d'environnement.
# Ces règles de syntaxe s'appliquent:
# Chaque ligne d'un fichier env doit être au format VAR=VAL.
# Les lignes commençant par # (c'est-à-dire les commentaires) sont ignorées.
# Les lignes vides sont ignorées.
# Il n'y a pas de traitement spécial des guillemets (c'est-à-dire qu'ils feront partie de la valeur ConfigMap)).
# Téléchargez les exemples de fichiers dans le dossier `configure-pod-container/configmap/`
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
# Le fichier env `game-env-file.properties` ressemble à ceci
cat configure-pod-container/configmap/game-env-file.properties
enemies=aliens
lives=3
allowed="true"
# Ce commentaire et la ligne vide au-dessus sont ignorés
```
```shell
kubectl create configmap game-config-env-file \
--from-env-file=configure-pod-container/configmap/game-env-file.properties
```
produirait le ConfigMap suivant:
```shell
kubectl get configmap game-config-env-file -o yaml
```
où la sortie est similaire à ceci:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2017-12-27T18:36:28Z
name: game-config-env-file
namespace: default
resourceVersion: "809965"
uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
data:
allowed: '"true"'
enemies: aliens
lives: "3"
```
{{< caution >}}
Lorsque vous passez plusieurs fois `--from-env-file` pour créer un ConfigMap à partir de plusieurs sources de données, seul le dernier fichier env est utilisé.
{{< /caution >}}
Le comportement consistant à passer plusieurs fois `--from-env-file` est démontré par:
```shell
# Téléchargez les exemples de fichiers dans le répertoire `configure-pod-container/configmap/`
wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
# Créez le configmap
kubectl create configmap config-multi-env-files \
--from-env-file=configure-pod-container/configmap/game-env-file.properties \
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
```
produirait le ConfigMap suivant:
```shell
kubectl get configmap config-multi-env-files -o yaml
```
où la sortie est similaire à ceci:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2017-12-27T18:38:34Z
name: config-multi-env-files
namespace: default
resourceVersion: "810136"
uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
color: purple
how: fairlyNice
textmode: "true"
```
#### Définissez la clé à utiliser lors de la création d'un ConfigMap à partir d'un fichier
Vous pouvez définir une clé autre que le nom de fichier à utiliser dans la section `data` de votre ConfigMap lorsque vous utilisez l'argument `--from-file`:
```shell
kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
```
où `<my-key-name>` est la clé que vous souhaitez utiliser dans la ConfigMap et `<path-to-file>` est l'emplacement du fichier de source de données que vous souhaitez que la clé représente.
Par exemple:
```shell
kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties
```
produirait la ConfigMap suivante:
```shell
kubectl get configmaps game-config-3 -o yaml
```
où la sortie est similaire à ceci:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:54:22Z
name: game-config-3
namespace: default
resourceVersion: "530"
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
data:
game-special-key: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
```
#### Créer des ConfigMaps à partir de valeurs littérales
Vous pouvez utiliser `kubectl create configmap` avec l'argument `--from-literal` définir une valeur littérale à partir de la ligne de commande:
```shell
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
```
Vous pouvez transmettre plusieurs paires clé-valeur.
Chaque paire fournie sur la ligne de commande est représentée comme une entrée distincte dans la section `data` de la ConfigMap.
```shell
kubectl get configmaps special-config -o yaml
```
La sortie est similaire à ceci:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: special-config
namespace: default
resourceVersion: "651"
uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
special.how: very
special.type: charm
```
### Créer un ConfigMap à partir du générateur
`kubectl` supporte `kustomization.yaml` depuis 1.14.
Vous pouvez également créer un ConfigMap à partir de générateurs, puis l'appliquer pour créer l'objet sur l'Apiserver.
Les générateurs doivent être spécifiés dans un `kustomization.yaml` à l'intérieur d'un répertoire.
#### Générer des ConfigMaps à partir de fichiers
Par exemple, pour générer un ConfigMap à partir de fichiers `configure-pod-container/configmap/game.properties`
```shell
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
files:
- configure-pod-container/configmap/game.properties
EOF
```
Appliquer le dossier kustomization pour créer l'objet ConfigMap.
```shell
kubectl apply -k .
configmap/game-config-4-m9dm2f92bt created
```
Vous pouvez vérifier que le ConfigMap a été créé comme ceci:
```text
kubectl get configmap
NAME DATA AGE
game-config-4-m9dm2f92bt 1 37s
kubectl describe configmaps/game-config-4-m9dm2f92bt
Name: game-config-4-m9dm2f92bt
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events: <none>
```
Notez que le nom ConfigMap généré a un suffixe obtenu par hachage de son contenu.
Cela garantit qu'un nouveau ConfigMap est généré chaque fois que le contenu est modifié.
#### Définissez la clé à utiliser lors de la génération d'un ConfigMap à partir d'un fichier
Vous pouvez définir une clé autre que le nom de fichier à utiliser dans le générateur ConfigMap.
Par exemple, pour générer un ConfigMap à partir du fichier `configure-pod-container/configmap/game.properties`
avec la clé `game-special-key`
```shell
# Créer un fichier kustomization.yaml avec ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
files:
- game-special-key=configure-pod-container/configmap/game.properties
EOF
```
Appliquer le dossier kustomization pour créer l'objet ConfigMap.
```text
kubectl apply -k .
configmap/game-config-5-m67dt67794 created
```
#### Générer des ConfigMaps à partir de littéraux
Pour générer un ConfigMap à partir de littéraux `special.type=charm` et `special.how=very`, vous pouvez spécifier le générateur ConfigMap dans `kustomization.yaml` comme
```shell
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: special-config-2
literals:
- special.how=very
- special.type=charm
EOF
```
Appliquez le dossier kustomization pour créer l'objet ConfigMap.
```text
kubectl apply -k .
configmap/special-config-2-c92b5mmcf2 created
```
## Définir des variables d'environnement de conteneur à l'aide des données ConfigMap
### Définissez une variable d'environnement de conteneur avec les données d'une seule ConfigMap
1. Définissez une variable d'environnement comme paire clé-valeur dans un ConfigMap:
```shell
kubectl create configmap special-config --from-literal=special.how=very
```
1. Attribuez la valeur `special.how` défini dans ConfigMap à la variable d'environnement `SPECIAL_LEVEL_KEY` dans la spécification du Pod.
{{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}}
Créez le pod:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
```
Maintenant, la sortie du Pod comprend une variable d'environnement `SPECIAL_LEVEL_KEY=very`.
### Définir des variables d'environnement de conteneur avec des données de plusieurs ConfigMaps
* Comme avec l'exemple précédent, créez d'abord les ConfigMaps.
{{< codenew file="configmap/configmaps.yaml" >}}
Créez le ConfigMap:
```shell
kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
```
* Définissez les variables d'environnement dans la spécification Pod.
{{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}}
Créez le pod:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
```
Maintenant, la sortie du Pod comprend des variables d'environnement `SPECIAL_LEVEL_KEY=very` et `LOG_LEVEL=INFO`.
## Configurer toutes les paires clé-valeur dans un ConfigMap en tant que variables d'environnement de conteneur
{{< note >}}
Cette fonctionnalité est disponible dans Kubernetes v1.6 et versions ultérieures.
{{< /note >}}
* Créez un ConfigMap contenant plusieurs paires clé-valeur.
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
Créez le ConfigMap:
```shell
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
```
* Utilisez `envFrom` pour définir toutes les données du ConfigMap en tant que variables d'environnement du conteneur.
La clé de ConfigMap devient le nom de la variable d'environnement dans le pod.
{{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
Créez le pod:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
```
Maintenant, la sortie du Pod comprend les variables d'environnement `SPECIAL_LEVEL=very` et `SPECIAL_TYPE=charm`.
## Utiliser des variables d'environnement définies par ConfigMap dans les commandes du Pod
Vous pouvez utiliser des variables d'environnement définies par ConfigMap dans la section `command` de la spécification du Pod en utilisant la syntaxe de substitution Kubernetes `$(VAR_NAME)`.
Par exemple, la spécification de pod suivante
{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}}
créé en exécutant
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml
```
produit la sortie suivante dans le conteneur `test-container`:
```shell
very charm
```
## Ajouter des données ConfigMap à un volume
Comme expliqué dans [Créer des ConfigMaps à partir de fichiers](#create-configmaps-from-files), lorsque vous créez un ConfigMap à l'aide `--from-file`, le nom de fichier devient une clé stockée dans la section `data` du ConfigMap.
Le contenu du fichier devient la valeur de la clé.
Les exemples de cette section se réfèrent à un ConfigMap nommé special-config, illustré ci-dessous.
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
Créez le ConfigMap:
```shell
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
```
### Remplissez un volume avec des données stockées dans un ConfigMap
Ajoutez le nom ConfigMap sous la section `volumes` de la spécification Pod.
Ceci ajoute les données ConfigMap au répertoire spécifié comme `volumeMounts.mountPath` (dans ce cas, `/etc/config`).
La section `command` répertorie les fichiers de répertoire dont les noms correspondent aux clés de ConfigMap.
{{< codenew file="pods/pod-configmap-volume.yaml" >}}
Créez le pod:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml
```
Lorsque le pod s'exécute, la commande `ls /etc/config/` produit la sortie ci-dessous:
```shell
SPECIAL_LEVEL
SPECIAL_TYPE
```
{{< caution >}}
S'il y a des fichiers dans le dossier `/etc/config/`, ils seront supprimés.
{{< /caution >}}
### Ajouter un configmap à un chemin spécifique dans un volume
Utilisez le champ `path` pour spécifier le chemin de fichier souhaité pour les éléments de configmap spécifiques.
Dans ce cas, le `SPECIAL_LEVEL` sera monté dans le volume `config-volume` au chemin `/etc/config/keys`.
{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}}
Créez le Pod :
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml
```
Lorsque le pod fonctionne, la commande `cat /etc/config/keys` produit la sortie ci-dessous :
```shell
very
```
{{< caution >}}
Comme avant, tous les fichiers précédents dans le répertoire `/etc/config/` seront supprimés.
{{< /caution >}}
### Projections de clés pour des chemins et des autorisations de fichiers spécifiques
Vous pouvez projeter des clés vers des chemins spécifiques avec des autorisations spécifiques fichiers par fichiers.
Le guide de l'utilisateur [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) explique la syntaxe.
### Les ConfigMaps montées sont mises à jour automatiquement
Lorsqu'une ConfigMap déjà consommée dans un volume est mise à jour, les clés projetées sont éventuellement mises à jour elles aussi.
Kubelet vérifie si la ConfigMap montée est fraîche à chaque synchronisation périodique.
Cependant, il utilise son cache local basé sur le ttl pour obtenir la valeur actuelle de la ConfigMap.
Par conséquent, le délai total entre le moment où la ConfigMap est mise à jour et le moment où les nouvelles clés sont projetées vers le pod peut être aussi long que la période de synchronisation de kubelet (1 minute par défaut) + le ttl du cache ConfigMaps (1 minute par défaut) dans kubelet.
Vous pouvez déclencher un rafraîchissement immédiat en mettant à jour l'une des annotations du pod.
{{< note >}}
Un conteneur utilisant un ConfigMap comme volume [subPath](/docs/concepts/storage/volumes/#using-subpath) ne recevra pas les mises à jour de ConfigMap.
{{< /note >}}
<!-- discussion -->
## Comprendre le lien entre les ConfigMaps et les Pods
La ressource API ConfigMap stocke les données de configuration sous forme de paires clé-valeur.
Les données peuvent être consommées dans des pods ou fournir les configurations des composants du système tels que les contrôleurs.
ConfigMap est similaire à [Secrets](/docs/concepts/configuration/secret/), mais fournit un moyen de travailler avec des chaînes de caractères qui ne contiennent pas d'informations sensibles.
Les utilisateurs comme les composants du système peuvent stocker des données de configuration dans un ConfigMap.
{{< note >}}
Les ConfigMaps doivent faire référence aux fichiers de propriétés, et non les remplacer.
Pensez à la ConfigMap comme représentant quelque chose de similaire au répertoire `/etc` de Linux et à son contenu.
Par exemple, si vous créez un [volume Kubernetes](/docs/concepts/storage/volumes/) à partir d'une ConfigMap, chaque élément de données de la ConfigMap est représenté par un fichier individuel dans le volume.
{{< /note >}}
Le champ `data` de la ConfigMap contient les données de configuration.
Comme le montre l'exemple ci-dessous, cela peut être simple -- comme des propriétés individuelles définies à l'aide de `--from-literal` -- ou complexe -- comme des fichiers de configuration ou des blobs JSON définis à l'aide de `--from-file`.
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: example-config
namespace: default
data:
# example of a simple property defined using --from-literal
example.property.1: hello
example.property.2: world
# example of a complex property defined using --from-file
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3
```
### Restrictions
* Vous devez créer un ConfigMap avant de le référencer dans une spécification de Pod (sauf si vous marquez le ConfigMap comme "facultatif").
Si vous faites référence à un ConfigMap qui n'existe pas, le Pod ne démarrera pas.
De même, les références à des clés qui n'existent pas dans la ConfigMap empêcheront le pod de démarrer.
* Si vous utilisez `envFrom` pour définir des variables d'environnement à partir de ConfigMaps, les clés considérées comme invalides seront ignorées.
Le pod sera autorisé à démarrer, mais les noms invalides seront enregistrés dans le journal des événements (`InvalidVariableNames`).
Le message du journal énumère chaque clé sautée.
Par exemple :
```shell
kubectl get events
```
Le résultat est similaire à celui-ci :
```text
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
```
* Les ConfigMaps résident dans un {{< glossary_tooltip term_id="namespace" >}}.
Un ConfigMap ne peut être référencé que par des pods résidant dans le même namespace.
* Vous ne pouvez pas utiliser des ConfigMaps pour {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, car le Kubelet ne le supporte pas.
{{% heading "whatsnext" %}}
* Suivez un exemple concret de [Configurer Redis en utilisant un ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
content/fr/examples/configmap/configmap-multikeys.yaml
+8
View File
@@ -0,0 +1,8 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
content/fr/examples/configmap/configmaps.yaml
+15
View File
@@ -0,0 +1,15 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
---
apiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFO
content/fr/examples/pods/pod-configmap-env-var-valueFrom.yaml
+21
View File
@@ -0,0 +1,21 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: SPECIAL_LEVEL
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: SPECIAL_TYPE
restartPolicy: Never
content/fr/examples/pods/pod-configmap-envFrom.yaml
+13
View File
@@ -0,0 +1,13 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
name: special-config
restartPolicy: Never
content/fr/examples/pods/pod-configmap-volume-specific-key.yaml
+20
View File
@@ -0,0 +1,20 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh","-c","cat /etc/config/keys" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config
items:
- key: SPECIAL_LEVEL
path: keys
restartPolicy: Never
content/fr/examples/pods/pod-configmap-volume.yaml
+18
View File
@@ -0,0 +1,18 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "ls /etc/config/" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
# Indiquez le nom de la ConfigMap contenant les fichiers que vous souhaitez ajouter au conteneur
name: special-config
restartPolicy: Never
content/fr/examples/pods/pod-multiple-configmap-env-variable.yaml
+21
View File
@@ -0,0 +1,21 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: env-config
key: log_level
restartPolicy: Never
content/fr/examples/pods/pod-single-configmap-env-variable.yaml
+19
View File
@@ -0,0 +1,19 @@
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
# Définie la variable d'environnement
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
# La ConfigMap contenant la valeur que vous voulez attribuer à SPECIAL_LEVEL_KEY
name: special-config
# Spécifier la clé associée à la valeur
key: special.how
restartPolicy: Never
content/id/docs/concepts/configuration/resource-bin-packing.md → content/id/docs/concepts/scheduling-eviction/resource-bin-packing.md
View File
content/ko/docs/concepts/architecture/cloud-controller.md
+2
View File
@@ -206,6 +206,8 @@ rules:
[클라우드 컨트롤러 매니저 관리](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)에는
클라우드 컨트롤러 매니저의 실행과 관리에 대한 지침이 있다.
클라우드 컨트롤러 매니저를 사용하기 위해 HA 컨트롤 플레인을 업그레이드하려면, [클라우드 컨트롤러 매니저를 사용하기 위해 복제된 컨트롤 플레인 마이그레이션 하기](/docs/tasks/administer-cluster/controller-manager-leader-migration/)를 참고한다.
자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가?
클라우드 컨트롤러 매니저는 Go 인터페이스를 사용해서 모든 클라우드 플러그인을 구현할 수 있다. 구체적으로, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)에 정의된 `CloudProvider` 인터페이스를 사용한다.
content/ko/docs/concepts/architecture/control-plane-node-communication.md
+6 -5
View File
@@ -8,14 +8,15 @@ aliases:
<!-- overview -->
이 문서는 컨트롤 플레인(실제로는 API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
<!-- body -->
## 노드에서 컨트롤 플레인으로의 통신
쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
@@ -50,20 +51,20 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
### API 서버에서 노드, 파드 및 서비스로의 통신
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않으므로 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
### SSH 터널
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.
SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
### Konnectivity 서비스
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
content/ko/docs/concepts/architecture/nodes.md
+35 -6
View File
@@ -63,6 +63,16 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
노드 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
### 노드 이름 고유성
[이름](/ko/docs/concepts/overview/working-with-objects/names#names)은 노드를 식별한다. 두 노드는
동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가
동일한 객체라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한
상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가
이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나
업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고
업데이트 후 다시 추가해야 한다.
### 노드에 대한 자체-등록
kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
@@ -233,6 +243,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
파드를 축출하기 시작하는 값은 5분이다.
노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
#### 하트비트
@@ -273,6 +284,7 @@ ConditionFalse 다.).
- 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
@@ -329,14 +341,27 @@ ConditionFalse 다.).
자세한 내용은
[노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
## 그레이스풀(Graceful) 노드 셧다운
## 그레이스풀(Graceful) 노드 셧다운 {#graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
{{< feature-state state="beta" for_k8s_version="v1.21" >}}
kubelet은 노드 시스템 셧다운을 감지하고 노드에서 실행 중인 파드를 종료하려고 시도한다.
`GracefulNodeShutdown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한 경우 kubelet은 노드 시스템 종료를 감지하고 노드에서 실행 중인 파드를 종료한다.
Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다.
`GracefulNodeShutdown` 기능 게이트가 활성화되면 kubelet은 [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를 사용하여 주어진 기간 동안 노드 종료를 지연시킨다. 종료 중에 kubelet은 두 단계로 파드를 종료시킨다.
그레이스풀 노드 셧다운 기능은
[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를
사용하여 주어진 기간 동안 노드 종료를 지연시키므로 systemd에 의존한다.
그레이스풀 노드 셧다운은 1.21에서 기본적으로 활성화된 `GracefulNodeShutdown`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 제어된다.
기본적으로, 아래 설명된 두 구성 옵션,
`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
그레이스풀 노드 셧다운 기능이 활성화되지 않는다.
기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다.
그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.
1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
@@ -345,9 +370,13 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
* `ShutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* `ShutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이는 `ShutdownGracePeriod`보다 작아야 한다.
* 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
예를 들어 `ShutdownGracePeriod=30s`, `ShutdownGracePeriodCriticalPods=10s` 인 경우 kubelet은 노드 종료를 30 초까지 지연시킨다. 종료하는 동안 처음 20(30-10) 초는 일반 파드의 유예 종료에 할당되고, 마지막 10 초는 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
예를 들어, `ShutdownGracePeriod=30s`,
`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의
유예 종료에 할당되고, 마지막 10초는
[중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/cluster-administration/addons.md
+1
View File
@@ -16,6 +16,7 @@ content_type: concept
## 네트워킹과 네트워크 폴리시
* [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
* [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
* [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
content/ko/docs/concepts/cluster-administration/logging.md
+4 -1
View File
@@ -83,12 +83,15 @@ kubectl logs counter
[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
자세히 알 수 있다.
**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다. kubelet은
이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다. 두 개의 kubelet 플래그 `container-log-max-size` 및 `container-log-max-files` 를 사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
실행하면, 노드의 kubelet이 요청을 처리하고
로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다.
{{< note >}}
만약, 일부 외부 시스템이 로테이션을 수행한 경우,
만약, 일부 외부 시스템이 로테이션을 수행했거나 CRI 컨테이너 런타임이 사용된 경우,
`kubectl logs` 를 통해 최신 로그 파일의 내용만
사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가
로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일)
content/ko/docs/concepts/cluster-administration/manage-deployment.md
+1 -1
View File
@@ -278,7 +278,7 @@ pod/my-nginx-2035384211-u3t6x labeled
```
먼저 "app=nginx" 레이블이 있는 모든 파드를 필터링한 다음, "tier=fe" 레이블을 지정한다.
방금 레이블을 지정한 파드를 보려면, 다음을 실행한다.
레이블을 지정한 파드를 보려면, 다음을 실행한다.
```shell
kubectl get pods -l app=nginx -L tier
content/ko/docs/concepts/cluster-administration/proxies.md
+1 -5
View File
@@ -39,7 +39,7 @@ weight: 90
- UDP, TCP, SCTP를 이용하여 프락시 한다.
- HTTP는 이해하지 못한다.
- 로드 밸런싱을 제공한다.
- 단지 서비스에 도달하는데 사용한다.
- 서비스에 도달하는데만 사용한다.
1. API 서버 앞단의 프락시/로드밸런서
@@ -61,7 +61,3 @@ weight: 90
## 요청을 리다이렉트하기
프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다.
content/ko/docs/concepts/cluster-administration/system-metrics.md
+19 -1
View File
@@ -130,7 +130,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
### kube-scheduler 메트릭
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
@@ -148,6 +148,24 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트
와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.
## 메트릭 비활성화
커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. 이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. 입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`).
## 메트릭 카디널리티(cardinality) 적용
제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. 리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다.
알파 단계에서, 플래그는 메트릭 레이블 허용 목록으로 일련의 매핑만 가져올 수 있다.
각 매핑은 `<metric_name>,<label_name>=<allowed_labels>` 형식이다. 여기서
`<allowed_labels>` 는 허용되는 레이블 이름의 쉼표로 구분된 목록이다.
전체 형식은 다음과 같다.
`--allow-label-value <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...`.
예시는 다음과 같다.
`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'`
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/configuration/configmap.md
+4 -3
View File
@@ -223,7 +223,7 @@ spec:
현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다.
kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다.
그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
캐시 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
모든 요청을 리디렉션할 수 있다.
@@ -233,11 +233,12 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과
쿠버네티스 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과
컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게
사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우
데이터 변경을 방지하면 다음과 같은 이점이 있다.
content/ko/docs/concepts/configuration/manage-resources-containers.md
+8 -19
View File
@@ -21,9 +21,6 @@ feature:
컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 _요청_ 량을
예약한다.
<!-- body -->
## 요청 및 제한
@@ -72,7 +69,7 @@ Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리
이것은 `memory` 및 `cpu` 리소스와는 다르다.
{{< /note >}}
CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 그냥 *리소스* 라고 한다. 컴퓨트
CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 한다. 컴퓨트
리소스는 요청, 할당 및 소비될 수 있는 측정 가능한
수량이다. 이것은
[API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및
@@ -441,7 +438,9 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다.
* kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
* [kubelet 구성](/docs/reference/config-api/kubelet-config.v1beta1/)의
`featureGates` 필드 또는 `--feature-gates` 커맨드 라인 플래그를 사용하여
`LocalStorageCapacityIsolationFSQuotaMonitoring=true`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화한다.
@@ -449,6 +448,7 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
프로젝트 쿼터가 활성화되어 있는지 확인한다. 모든 XFS 파일시스템은 프로젝트 쿼터를 지원한다.
ext4 파일시스템의 경우, 파일시스템이 마운트되지 않은 상태에서 프로젝트 쿼터
추적 기능을 활성화해야 한다.
```bash
# ext4인 /dev/block-device가 마운트되지 않은 경우
sudo tune2fs -O project -Q prjquota /dev/block-device
@@ -518,9 +518,8 @@ JSON-Pointer로 해석된다. 더 자세한 내용은,
클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로
리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다.
[스케줄러 정책 구성](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)에서
스케줄러 익스텐더가
처리하는 확장된 리소스를 지정할 수 있다.
[스케줄러 정책 구성](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에서
스케줄러 익스텐더가 처리하는 확장된 리소스를 지정할 수 있다.
**예제:**
@@ -743,23 +742,13 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0
컨테이너가 `reason:OOM Killed`(`OOM` 은 메모리 부족(Out Of Memory)의 약자) 때문에 종료된 것을 알 수 있다.
## {{% heading "whatsnext" %}}
* [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자.
* [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
* 요청과 제한의 차이점에 대한 자세한 내용은,
[리소스 QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)를 참조한다.
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API 레퍼런스 읽어보기
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기
* XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에 대해 더 읽어보기
content/ko/docs/concepts/configuration/secret.md
+10 -10
View File
@@ -109,7 +109,7 @@ empty-secret Opaque 0 2m6s
```
해당 `DATA` 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다.
이 경우, `0` 은 비어 있는 시크릿을 방금 하나 생성하였다는 것을 의미한다.
이 경우, `0` 은 비어 있는 시크릿을 하나 생성하였다는 것을 의미한다.
### 서비스 어카운트 토큰 시크릿
@@ -667,7 +667,7 @@ cat /etc/foo/password
볼륨에서 현재 사용되는 시크릿이 업데이트되면, 투영된 키도 결국 업데이트된다.
kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 상태인지 여부를 확인한다.
그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다.
캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
캐시의 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다.
시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접
리디렉션하여 전파할 수 있다.
@@ -749,9 +749,9 @@ echo $SECRET_PASSWORD
## 변경할 수 없는(immutable) 시크릿 {#secret-immutable}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은
쿠버네티스 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은
개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
다음과 같은 이점이 있다.
@@ -760,8 +760,8 @@ echo $SECRET_PASSWORD
- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
크게 줄임으로써 클러스터의 성능을 향상시킴
이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
의해 제어된다. `immutable` 필드를 `true` 로 설정하여
변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다.
```yaml
@@ -865,6 +865,7 @@ LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT
### 사용 사례: 컨테이너 환경 변수로 사용하기
시크릿 정의를 작성한다.
```yaml
apiVersion: v1
kind: Secret
@@ -877,6 +878,7 @@ data:
```
시크릿을 생성한다.
```shell
kubectl apply -f mysecret.yaml
```
@@ -1173,14 +1175,12 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,
시크릿 API에 접근해야 하는 애플리케이션은 필요한 시크릿에 대한 `get` 요청을
수행해야 한다. 이를 통해 관리자는 앱에 필요한
[개별 인스턴스에 대한 접근을 허용 목록에 추가](
/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
[개별 인스턴스에 대한 접근을 허용 목록에 추가](/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
제한할 수 있다.
`get` 반복을 통한 성능 향상을 위해, 클라이언트는 시크릿을
참조한 다음 리소스를 감시(`watch`)하고, 참조가 변경되면 시크릿을 다시 요청하는 리소스를
설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
제안되었으며, 쿠버네티스의 후속 릴리스에서 사용할 수
있을 것이다.
content/ko/docs/concepts/containers/container-lifecycle-hooks.md
+2 -1
View File
@@ -50,10 +50,11 @@ terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실
### 훅 핸들러 구현
컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.
구현될 수 있는 컨테이너의 훅 핸들러에는 세 가지 유형이 있다.
* Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
* TCP - 컨테이너의 특정 포트에 대한 TCP 연결을 연다.
* HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.
### 훅 핸들러 실행
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+1 -1
View File
@@ -44,7 +44,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트
클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고
업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만
커스텀 리소스와 결합할 때 특히 효과적이다.
[오퍼레이터 패턴](https://coreos.com/blog/introducing-operators.html)은 사용자 정의
[오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)은 사용자 정의
리소스와 커스텀 컨트롤러를 결합한다. 커스텀 컨트롤러를 사용하여 특정 애플리케이션에 대한 도메인 지식을
쿠버네티스 API의 익스텐션으로 인코딩할 수 있다.
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+61 -2
View File
@@ -192,10 +192,69 @@ kubelet은 gRPC 서비스를 제공하여 사용 중인 장치를 검색하고,
// PodResourcesLister는 kubelet에서 제공하는 서비스로, 노드의 포드 및 컨테이너가
// 사용한 노드 리소스에 대한 정보를 제공한다.
service PodResourcesLister {
rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}
}
```
`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께
실행 중인 파드의 리소스에 대한 정보를 제공한다.
```gRPC
// ListPodResourcesResponse는 List 함수가 반환하는 응답이다
message ListPodResourcesResponse {
repeated PodResources pod_resources = 1;
}
// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다
message PodResources {
string name = 1;
string namespace = 2;
repeated ContainerResources containers = 3;
}
// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다
message ContainerResources {
string name = 1;
repeated ContainerDevices devices = 2;
repeated int64 cpu_ids = 3;
}
// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다
message TopologyInfo {
repeated NUMANode nodes = 1;
}
// NUMA 노드의 NUMA 표현
message NUMANode {
int64 ID = 1;
}
// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다
message ContainerDevices {
string resource_name = 1;
repeated string device_ids = 2;
TopologyInfo topology = 3;
}
```
GetAllocatableResources는 워커 노드에서 처음 사용할 수 있는 리소스에 대한 정보를 제공한다.
kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다.
```gRPC
// AllocatableResourcesResponses에는 kubelet이 알고 있는 모든 장치에 대한 정보가 포함된다.
message AllocatableResourcesResponse {
repeated ContainerDevices devices = 1;
repeated int64 cpu_ids = 2;
}
```
`ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다.
NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은
[kubelet에 등록할 때](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) 장치 플러그인이 보고하는 것과 일치한다.
gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다.
장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다.
표준 디렉터리 `/var/lib/kubelet/pod-resources` 에는 특권을 가진 접근이 필요하므로, 모니터링
@@ -204,7 +263,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스
`/var/lib/kubelet/pod-resources` 를
{{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
`PodResourcesLister service` 를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
## 토폴로지 관리자와 장치 플러그인 통합
content/ko/docs/concepts/overview/components.md
+3 -2
View File
@@ -30,8 +30,9 @@ card:
컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면
[고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다.
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서
실행되는 컨트롤 플레인 설정의 예제를 보려면
[kubeadm을 사용하여 고가용성 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/high-availability/)를 확인해본다.
### kube-apiserver
content/ko/docs/concepts/overview/working-with-objects/names.md
+5 -2
View File
@@ -21,11 +21,15 @@ weight: 20
{{< glossary_definition term_id="name" length="all" >}}
{{< note >}}
물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
{{< /note >}}
다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
### DNS 서브도메인 이름
대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
이것은 이름이 다음을 충족해야 한다는 것을 의미한다.
@@ -83,4 +87,3 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.
* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
* [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
+11 -1
View File
@@ -26,7 +26,7 @@ weight: 30
동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를
구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을
구별하기 위해 {{< glossary_tooltip text="레이블" term_id="label" >}}을
사용한다.
## 네임스페이스 다루기
@@ -109,6 +109,16 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
## 자동 레이블링
{{< feature-state state="beta" for_k8s_version="1.21" >}}
쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
활성화된 경우 모든 네임스페이스에 변경할 수 없는(immutable) {{< glossary_tooltip text="레이블" term_id="label" >}}
`kubernetes.io / metadata.name` 을 설정한다.
레이블 값은 네임스페이스 이름이다.
## {{% heading "whatsnext" %}}
* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
content/ko/docs/concepts/policy/pod-security-policy.md
+3 -1
View File
@@ -9,7 +9,9 @@ weight: 30
<!-- overview -->
{{< feature-state state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다.
파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
부여할 수 있다.
content/ko/docs/concepts/policy/resource-quotas.md
+63 -1
View File
@@ -124,6 +124,10 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음. |
| `ephemeral-storage` | `requests.ephemeral-storage` 와 같음. |
{{< note >}}
CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스토리지 쿼터에 포함된다. 이로 인해 스토리지 쿼터를 소진한 파드가 예기치 않게 축출될 수 있다. 자세한 내용은 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참조한다.
{{< /note >}}
## 오브젝트 수 쿼터
다음 구문을 사용하여 모든 표준 네임스페이스 처리된(namespaced) 리소스 유형에 대한
@@ -188,7 +192,8 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
| `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
| `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
| `NotBestEffort` | 서비스 품질이 나쁜 파드 |
| `PriorityClass` | 지정된 [프라이올리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
| `PriorityClass` | 지정된 [프라이어리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
| `CrossNamespacePodAffinity` | 크로스-네임스페이스 파드 [(안티)어피니티 용어]가 있는 파드 |
`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.
@@ -429,6 +434,63 @@ memory 0 20Gi
pods 0 10
```
### 네임스페이스 간 파드 어피니티 쿼터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
`namespaces` 또는 `namespaceSelector` 필드를 설정할 수 있는 파드를 제어한다.
안티-어피니티 제약 조건이 있는 파드는 장애 도메인에서 다른 모든 네임스페이스의 파드가 예약되지 않도록
차단할 수 있으므로 사용자가 네임스페이스 간 어피니티 용어를
사용하지 못하도록 하는 것이 바람직할 수 있다.
이 범위 오퍼레이터를 사용하면 `CrossNamespaceAffinity` 범위와 하드(hard) 제한이 0인
네임스페이스에 리소스 쿼터 오브젝트를 생성하여 특정 네임스페이스(아래 예에서 `foo-ns`)가 네임스페이스 간 파드 어피니티를
사용하는 파드를 사용하지 못하도록 방지할 수 있다.
```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: disable-cross-namespace-affinity
namespace: foo-ns
spec:
hard:
pods: "0"
scopeSelector:
matchExpressions:
- scopeName: CrossNamespaceAffinity
```
오퍼레이터가 기본적으로 `namespaces` 및 `namespaceSelector` 사용을 허용하지 않고,
특정 네임스페이스에만 허용하려는 경우, kube-apiserver 플래그 --admission-control-config-file를
다음의 구성 파일의 경로로 설정하여 `CrossNamespaceAffinity` 를
제한된 리소스로 구성할 수 있다.
```yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: ResourceQuotaConfiguration
limitedResources:
- resource: pods
matchScopes:
- scopeName: CrossNamespaceAffinity
```
위의 구성을 사용하면, 파드는 생성된 네임스페이스에 `CrossNamespaceAffinity` 범위가 있는 리소스 쿼터 오브젝트가 있고,
해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.
이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
## 요청과 제한의 비교 {#requests-vs-limits}
컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다.
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
+22 -11
View File
@@ -11,18 +11,17 @@ weight: 20
<!-- overview -->
{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나,
특정 노드들을 선호하도록 제한할 수 있다.
이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다.
보통 스케줄러가 자동으로 합리적인 배치(예: 노드들에 걸쳐 파드를 분배하거나,
자원이 부족한 노드에 파드를 배치하지 않는 등)를 수행하기에 이런 제약 조건은 필요하지 않지만
간혹 파드가 배치되는 노드에 대해 더 많은 제어를 원할 수 있는 상황이 있다.
특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하도록
{{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다.
이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다.
보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록
노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만
간혹 파드가 배포할 노드를 제어해야 하는 경우가 있다.
예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서
많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다.
<!-- body -->
## 노드 셀렉터(nodeSelector)
@@ -120,13 +119,13 @@ spec:
여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는
두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시*
규칙을 만족해야 하는 것(`nodeSelector` 와 같으나 보다 표현적인 구문을 사용해서)을 지정하고,
규칙을 만족해야 하는 것(`nodeSelector` 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고,
후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서
이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의
레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 여전히 그 노드에서
레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서
동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는
점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 같은 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이
될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고
@@ -271,6 +270,18 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와
연관된 `matchExpressions` 가 모두 충족되어야 한다.
#### 네임스페이스 셀렉터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다.
어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다.
빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과
null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다.
이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
#### 더 실용적인 유스케이스
파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은
content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
+1
View File
@@ -86,6 +86,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
* kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+8 -5
View File
@@ -24,8 +24,6 @@ API 서버에 해당 결정을 통지한다.
본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝
최적화에 대해 설명한다.
<!-- body -->
큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간
@@ -44,8 +42,10 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
`percentageOfNodesToScore` 를 100 보다 높게 설정해도 kube-scheduler는
마치 100을 설정한 것처럼 작동한다.
값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml`
일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.
값을 변경하려면,
[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
편집한 다음 스케줄러를 재시작한다.
대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.
이를 변경한 후에 다음을 실행해서
@@ -99,7 +99,6 @@ algorithmSource:
percentageOfNodesToScore: 50
```
### percentageOfNodesToScore 튜닝
`percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며
@@ -159,3 +158,7 @@ percentageOfNodesToScore: 50
```
모든 노드를 검토한 후, 노드 1로 돌아간다.
## {{% heading "whatsnext" %}}
* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인
content/ko/docs/concepts/security/controlling-access.md
+1 -1
View File
@@ -38,7 +38,7 @@ API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.
인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
content/ko/docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -383,7 +383,7 @@ $ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
<h1>Welcome to nginx!</h1>
```
이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성하고, `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다.
이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성한다. `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다.
```shell
kubectl edit svc my-nginx
content/ko/docs/concepts/services-networking/dual-stack.md
+16 -16
View File
@@ -11,11 +11,11 @@ weight: 70
<!-- overview -->
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
IPv4/IPv6 이중 스택을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}} 와 {{< glossary_tooltip text="서비스" term_id="service" >}} 에 IPv4와 IPv6 주소를 모두 할당 할 수 있다.
IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.
만약 쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택 네트워킹을 활성화하면, 클러스터는 IPv4와 IPv6 주소의 동시 할당을 지원하게 된다.
IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다.
@@ -23,7 +23,7 @@ weight: 70
## 지원되는 기능
쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택을 활성화하면 다음의 기능을 제공한다.
쿠버네티스 클러스터의 IPv4/IPv6 이중 스택은 다음의 기능을 제공한다.
* 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
* IPv4와 IPv6 지원 서비스
@@ -40,34 +40,34 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
* 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
## IPv4/IPv6 이중 스택 활성화
## IPv4/IPv6 이중 스택 구성
IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다.
IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.)
IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다.
* kube-apiserver:
* `--feature-gates="IPv6DualStack=true"`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* kube-controller-manager:
* `--feature-gates="IPv6DualStack=true"`
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
* kubelet:
* `--feature-gates="IPv6DualStack=true"`
* kube-proxy:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--feature-gates="IPv6DualStack=true"`
{{< note >}}
IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)
IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.)
1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다.
필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에
`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다.
{{< /note >}}
## 서비스
클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다.
IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다.
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
@@ -76,11 +76,9 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만,
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
* `PreferDualStack`:
* 클러스터에 이중 스택이 활성화된 경우에만 사용된다. 서비스에 대해 IPv4 및 IPv6 클러스터 IP를 할당한다.
* 클러스터에 이중 스택이 활성화되지 않은 경우, 이 설정은 `SingleStack`과 동일한 동작을 따른다.
* 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.)
* `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
* 클러스터에는 이중 스택 네트워킹이 구성되어 있어야 한다.
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.
@@ -121,7 +119,7 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만,
#### 기존 서비스의 이중 스택 기본값
이 예제는 서비스가 이미있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다.
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.)
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.
@@ -237,3 +235,5 @@ spec:
* [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
* [kubeadm을 사용하여 이중 스택 네트워킹 활성화
](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
content/ko/docs/concepts/services-networking/endpoint-slices.md
+29 -34
View File
@@ -1,13 +1,13 @@
---
title: 엔드포인트슬라이스
content_type: concept
weight: 35
weight: 45
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
_엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
@@ -50,7 +50,7 @@ term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로
리소스 샘플이 있다.
```yaml
apiVersion: discovery.k8s.io/v1beta1
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: example-abc
@@ -67,13 +67,12 @@ endpoints:
conditions:
ready: true
hostname: pod-1
topology:
kubernetes.io/hostname: node-1
topology.kubernetes.io/zone: us-west2-a
nodeName: node-1
zone: us-west2-a
```
기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
갖도록 엔드포인트슬라이스를
갖도록 엔드포인트슬라이스를
생성하고 관리한다. `--max-endpoints-per-slice`
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
플래그를 사용하여, 최대 1000개까지 구성할 수 있다.
@@ -98,9 +97,9 @@ endpoints:
#### 준비
`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는
이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의
이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여
`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는
이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의
이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여
파드 종료 준비 상태(readiness)를 검사해야 한다.
이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다.
이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다.
@@ -110,16 +109,16 @@ endpoints:
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
`serving`은 종료 상태를 고려하지 않는다는 점을 제외하면 `ready` 조건과 동일하다.
엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면
엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면
이 조건을 확인해야 한다.
{{< note >}}
`serving`은 `ready`와 거의 동일하지만 `ready`의 기존 의미가 깨지는 것을 방지하기 위해 추가되었다.
엔드포인트를 종료하기 위해 `ready`가 `true` 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다.
엔드포인트를 종료하기 위해 `ready`가 `true` 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다.
역사적으로 종료된 엔드포인트는 처음부터 엔드포인트 또는 엔드포인트슬라이스 API에 포함되지 않았기 때문이다.
이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며,
클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를
이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며,
클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를
추적 할 수 있도록 v1.20에 새로운 조건 `serving`이 추가되었다.
{{< /note >}}
@@ -133,30 +132,26 @@ endpoints:
### 토폴로지 정보 {#토폴로지}
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
엔드포인트슬라이스 내의 각 엔드 포인트는 관련 토폴로지 정보를 포함할 수 있다.
토폴로지 정보에는 엔드 포인트의 위치와 해당 노드 및
영역에 대한 정보가 포함된다. 엔드포인트슬라이스의 다음의 엔드 포인트별
필드에서 사용할 수 있다.
*`nodeName` - 이 엔드 포인트가 있는 노드의 이름이다.
*`zone` - 이 엔드 포인트가 있는 영역이다.
{{< note >}}
엔드포인트슬라이스의 토폴로지 필드는 사용 중단되었으며 향후 릴리스에서 제거된다.
토폴로지에서 `kubernetes.io/hostname`을 설정하는 대신 새로운 `nodeName` 필드가
사용된다. 영역 및 리전을 커버하는 다른 토폴로지 필드는
엔드포인트슬라이스 내의 모든 엔드포인트에 적용되는
엔드포인트슬라이스 레이블을 이용해 더 잘 표현될 수 있다.
v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별
`topology` 가 효과적으로 제거되었다.
`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를
설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신,
v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한
필드는 API 버전 간에 자동으로 번역된다. 예를 들어,
v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
키 값은 v1 API의 `zone` 필드로 접근할 수 있다.
{{< /note >}}
엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면,
컨트롤 플레인은 엔드포인트슬라이스에 대해 다음의 토폴로지 레이블을 설정한다.
* `kubernetes.io/hostname` - 이 엔드포인트가 있는 노드의 이름.
* `topology.kubernetes.io/zone` - 이 엔드포인트가 있는 영역의 이름.
* `topology.kubernetes.io/region` - 이 엔드포인트가 있는 지역의 이름.
이런 레이블 값은 슬라이스의 각 엔드포인트와 연관된 리소스에서
파생된다. 호스트 이름 레이블은 해당 파드의
NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당
노드에서 이름이 같은 값을 나타낸다.
### 관리
대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스
content/ko/docs/concepts/services-networking/ingress.md
+14 -2
View File
@@ -218,7 +218,19 @@ Events: <none>
{{< codenew file="service/networking/external-lb.yaml" >}}
IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
추가 구성을 참조하는데 사용할 수 있다.
추가 구현 별 구성을 참조하는데 사용할 수 있다.
#### 네임스페이스 범위의 파라미터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
사용할 수 있는 `scope` 및 `namespace` 필드가 있다.
`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의
리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를
설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다.
{{< codenew file="service/networking/namespaced-params.yaml" >}}
### 사용중단(Deprecated) 어노테이션
@@ -257,7 +269,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
{{< codenew file="service/networking/test-ingress.yaml" >}}
만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의
만약 `kubectl apply -f` 를 사용해서 생성한다면 추가한 인그레스의
상태를 볼 수 있어야 한다.
```bash
content/ko/docs/concepts/services-networking/network-policies.md
+57 -3
View File
@@ -220,18 +220,72 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
{{< /note >}}
## 포트 범위 지정
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다.
다음 예와 같이 `endPort` 필드를 사용하면, 이 작업을 수행할 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: multi-port-egress
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 32000
endPort: 32768
```
위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
이 필드를 사용할 때 다음의 제한 사항이 적용된다.
* 알파 기능으로, 기본적으로 비활성화되어 있다. 클러스터 수준에서 `endPort` 필드를 활성화하려면, 사용자(또는 클러스터 관리자)가 `--feature-gates=NetworkPolicyEndPort=true,…` 가 있는 API 서버에 대해 `NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
* `endPort` 필드는 `port` 필드보다 크거나 같아야 한다.
* `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다.
* 두 포트 모두 숫자여야 한다.
{{< note >}}
클러스터는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
네트워크폴리시 명세에서 `endPort` 필드를 지원한다.
{{< /note >}}
## 이름으로 네임스페이스 지정
{{< feature-state state="beta" for_k8s_version="1.21" >}}
쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우
모든 네임스페이스에 변경할 수 없는(immutable) 레이블 `kubernetes.io/metadata.name` 을 설정한다.
레이블의 값은 네임스페이스 이름이다.
네트워크폴리시는 일부 오브젝트 필드가 있는 이름으로 네임스페이스를 대상으로 지정할 수 없지만, 표준화된 레이블을 사용하여
특정 네임스페이스를 대상으로 지정할 수 있다.
## 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다.
쿠버네티스 {{< skew latestVersion >}}부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 필요가 있다.
- 내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음).
- TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용).
- 노드별 정책(이에 대해 CIDR 표기법을 사용할 수 있지만, 특히 쿠버네티스 ID로 노드를 대상으로 지정할 수 없음).
- 이름으로 네임스페이스나 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임).
- 이름으로 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임).
- 타사 공급사가 이행한 "정책 요청"의 생성 또는 관리.
- 모든 네임스페이스나 파드에 적용되는 기본 정책(이를 수행할 수 있는 타사 공급사의 쿠버네티스 배포본 및 프로젝트가 있음).
- 고급 정책 쿼리 및 도달 가능성 도구.
- 단일 정책 선언에서 포트 범위를 대상으로 하는 기능.
- 네트워크 보안 이벤트를 기록하는 기능(예: 차단되거나 수락된 연결).
- 명시적으로 정책을 거부하는 기능(현재 네트워크폴리시 모델은 기본적으로 거부하며, 허용 규칙을 추가하는 기능만 있음).
- 루프백 또는 들어오는 호스트 트래픽을 방지하는 기능(파드는 현재 로컬 호스트 접근을 차단할 수 없으며, 상주 노드의 접근을 차단할 수 있는 기능도 없음).
content/ko/docs/concepts/services-networking/service-topology.md
+30 -25
View File
@@ -1,10 +1,8 @@
---
title: 서비스 토폴로지
feature:
title: 서비스 토폴로지
description: >
클러스터 토폴로지를 기반으로 서비스 트래픽 라우팅.
title: 토폴로지 키를 사용하여 토폴로지-인지 트래픽 라우팅
content_type: concept
weight: 10
---
@@ -12,7 +10,16 @@ weight: 10
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
{{< note >}}
이 기능, 특히 알파 `topologyKeys` API는 쿠버네티스 v1.21부터
더 이상 사용되지 않는다.
쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints/)는
유사한 기능을 제공한다.
{{</ note >}}
_서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를
기반으로 트래픽을 라우팅한다. 예를 들어, 서비스는 트래픽을
@@ -20,33 +27,33 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노
우선적으로 라우팅되도록 지정할 수 있다.
<!-- body -->
## 소개
기본적으로 `ClusterIP` 또는 `NodePort` 서비스로 전송된 트래픽은 서비스의
모든 백엔드 주소로 라우팅 될 수 있다. 쿠버네티스 1.7부터는 "외부(external)"
트래픽을 수신한 노드에서 실행중인 파드로 라우팅할 수 있었지만,
`ClusterIP` 서비스에서는 지원되지 않으며 더 복잡한
토폴로지 &mdash; 영역별 라우팅과 같은 &mdash; 에서는 불가능 했다.
_서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수신 노드에 대해서
노드 레이블에 기반한 트래픽 라우팅 정책을 정의할 수 있도록
함으로써 이 문제를 해결한다.
모든 백엔드 주소로 라우팅될 수 있다. 쿠버네티스 1.7을 사용하면 트래픽을 수신한
동일한 노드에서 실행 중인 파드로 "외부(external)" 트래픽을 라우팅할 수
있다. `ClusterIP` 서비스의 경우, 라우팅에 대한 동일한 노드 기본 설정이
불가능했다. 또한 동일한 영역 내의 엔드 포인트에 대한 라우팅을 선호하도록
클러스터를 구성할 수도 없다.
서비스에 `topologyKeys` 를 설정하면, 출발 및 대상 노드에 대한
노드 레이블을 기반으로 트래픽을 라우팅하는 정책을 정의할 수 있다.
소스와 목적지의 노드 레이블 일치를 사용하여 운영자는 운영자의 요구 사항에
적합한 메트릭에 대해서 서로 "근접(closer)" 하거나 "먼(farther)"
노드 그룹을 지정할 수 있다. 공용 클라우드의 많은 운영자들이 서비스 트래픽을
동일한 영역에서 유지하는 것을 선호하는 것을 필요성의 예제로 볼 수 있다. 그 이유는
지역간의 트래픽에는 관련 비용이 발생하지만 지역 내의 트래픽은 발생하지 않기 때문이다.
다른 일반적인 필요성으로는 DaemonSet이 관리하는 로컬 파드로
트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에
연결된 노드로 트래픽을 유지하는 것이 있다.
소스와 목적지 사이의 레이블 일치를 통해 클러스터 운영자는
서로 "근접(closer)"하거나 "먼(father)" 노드 그룹을 지정할 수 있다.
자신의 요구 사항에 맞는 메트릭을 나타내는 레이블을 정의할 수 있다.
예를 들어, 퍼블릭 클라우드에서는 지역 간의 트래픽에는 관련 비용이 발생(지역 내
트래픽은 일반적으로 그렇지 않다)하기 때문에, 네트워크 트래픽을 동일한 지역 내에 유지하는 것을
선호할 수 있다. 다른 일반적인 필요성으로는 데몬셋(DaemonSet)이 관리하는
로컬 파드로 트래픽을 라우팅하거나, 대기 시간을 최소화하기 위해
동일한 랙 상단(top-of-rack) 스위치에 연결된 노드로 트래픽을
유지하는 것이 있다.
## 서비스 토폴로지 사용하기
만약 클러스터에서 서비스 토폴로지가 활성화된 경우, 서비스 사양에서
만약 클러스터에서 `ServiceTopology` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우, 서비스 사양에서
`topologyKeys` 필드를 지정해서 서비스 트래픽 라우팅을 제어할 수 있다. 이 필드는
이 서비스에 접근할 때 엔드포인트를 정렬하는데 사용되는 노드
레이블의 우선 순위 목록이다. 트래픽은 첫 번째 레이블 값이 해당 레이블의
@@ -196,5 +203,3 @@ spec:
* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기.
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기.
content/ko/docs/concepts/services-networking/service.md
+37 -7
View File
@@ -187,9 +187,14 @@ ExternalName 서비스는 셀렉터가 없고
DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
### 초과 용량 엔드포인트
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
### 엔드포인트슬라이스
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스를
@@ -513,8 +518,12 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다.
포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10부터 지원된다.
이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한
`--nodeport-addresses` 플래그 또는
[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
동등한 `nodePortAddresses` 필드를
특정 IP 블록으로 설정할 수 있다.
이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
@@ -530,7 +539,9 @@ NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설
하나 이상의 노드 IP를 직접 노출시킬 수 있다.
이 서비스는 `<NodeIP>:spec.ports[*].nodePort`와
`.spec.clusterIP:spec.ports[*].port`로 표기된다. (kube-proxy에서 `--nodeport-addresses` 플래그가 설정되면, <NodeIP>는 NodeIP를 필터링한다.)
`.spec.clusterIP:spec.ports[*].port`로 표기된다.
kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의
동등한 필드가 설정된 경우, `<NodeIP>` 는 노드 IP를 필터링한다.
예를 들면
@@ -628,6 +639,25 @@ v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
이 필드를 사용하려면 `ServiceLBNodePortControl` 기능 게이트를 활성화해야 한다.
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer` 서비스 유형에
대한 로드 밸런서 구현 클래스를 선택적으로 지정할 수 있다.
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고 `LoadBalancer` 유형의 서비스는
클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
`spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
구현이 서비스를 감시하고 있다고 가정한다.
모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는
로드 밸런서 구현)은 이 필드가 설정된 서비스를 무시한다.
`spec.loadBalancerClass` 는 `LoadBalancer` 유형의 서비스에서만 설정할 수 있다.
한 번 설정하면 변경할 수 없다.
`spec.loadBalancerClass` 의 값은 "`internal-vip`" 또는
"`example.com/internal-vip`" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다.
접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다.
이 필드를 사용하려면 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 한다.
#### 내부 로드 밸런서
혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
@@ -785,8 +815,7 @@ TCP 및 SSL은 4 계층 프록시를 선택한다. ELB는 헤더를 수정하지
```
위의 예에서, 서비스에 `80`, `443`, `8443`의 3개 포트가 포함된 경우,
`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 단순히
프록시만 하는 HTTP이다.
`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 프록시하는 HTTP이다.
쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다.
사용 가능한 정책을 확인하려면, `aws` 커맨드라인 툴을 사용한다.
@@ -958,7 +987,8 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스
| 규칙 | 프로토콜 | 포트 | IP 범위 | IP 범위 설명 |
|------|----------|---------|------------|---------------------|
| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
| 클라이언트 트래픽 | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
| MTU 탐색 | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
content/ko/docs/concepts/storage/persistent-volumes.md
+1 -1
View File
@@ -29,7 +29,7 @@ _퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리
_퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. [AccessModes](#접근-모드) 참고).
퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.
퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.
[실습 예제와 함께 상세한 내용](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.
content/ko/docs/concepts/storage/volumes.md
+15 -10
View File
@@ -34,7 +34,7 @@ weight: 10
더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.
기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드
기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드
내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는
매체와 내용은 사용된 특정 볼륨의 유형에 따라
결정된다.
@@ -149,14 +149,16 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
#### azureFile CSI 마이그레이션
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI
드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver)
를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile`
알파 기능을 활성화해야 한다.
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다.
### cephfs
@@ -205,14 +207,17 @@ spec:
#### 오픈스택 CSI 마이그레이션
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI
드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)를
설치하고 `CSIMigration` 과 `CSIMigrationOpenStack`
베타 기능을 활성화해야 한다.
Cinder의`CSIMigration` 기능은 Kubernetes 1.21에서 기본적으로 활성화됩니다.
기존 트리 내 플러그인에서 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다.
[오픈스택 Cinder CSI 드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)가
클러스터에 설치되어 있어야 한다.
`CSIMigrationOpenStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
`false` 로 설정하여 클러스터에 대한 Cinder CSI 마이그레이션을 비활성화할 수 있다.
`CSIMigrationOpenStack` 기능을 비활성화하면, 트리 내 Cinder 볼륨 플러그인이
Cinder 볼륨 스토리지 관리의 모든 측면을 담당한다.
### 컨피그맵(configMap) {#configmap}
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+9 -4
View File
@@ -10,7 +10,7 @@ weight: 80
<!-- overview -->
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
_크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다.
@@ -115,12 +115,17 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고,
잡은 그 잡이 대표하는 파드 관리에 책임이 있다.
## 새 컨트롤러
## 컨트롤러 버전 {#new-controller}
쿠버네티스 1.20부터 알파 기능으로 사용할 수 있는 크론잡 컨트롤러의 대체 구현이 있다. 크론잡 컨트롤러의 버전 2를 선택하려면, 다음의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달한다.
쿠버네티스 v1.21부터 크론잡 컨트롤러의 두 번째 버전이
기본 구현이다. 기본 크론잡 컨트롤러를 비활성화하고
대신 원래 크론잡 컨트롤러를 사용하려면, `CronJobControllerV2`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달하고,
이 플래그를 `false` 로 설정한다. 예를 들면, 다음과 같다.
```
--feature-gates="CronJobControllerV2=true"
--feature-gates="CronJobControllerV2=false"
```
content/ko/docs/concepts/workloads/controllers/deployment.md
+1 -1
View File
@@ -706,7 +706,7 @@ nginx-deployment-618515232 11 11 11 7m
하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
* 예를 들어, 방금 생성된 디플로이먼트의 경우
* 예를 들어, 생성된 디플로이먼트의 경우
디플로이먼트 상세 정보를 가져온다.
```shell
kubectl get deploy
content/ko/docs/concepts/workloads/controllers/job.md
+150 -18
View File
@@ -16,7 +16,8 @@ weight: 50
잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다.
파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의
성공 완료에 도달하면, 작업(즉, 잡)이 완료된다. 잡을 삭제하면 잡이 생성한
파드가 정리된다.
파드가 정리된다. 작업을 일시 중지하면 작업이 다시 재개될 때까지 활성 파드가
삭제된다.
간단한 사례는 잡 오브젝트를 하나 생성해서 파드 하나를 안정적으로 실행하고 완료하는 것이다.
첫 번째 파드가 실패 또는 삭제된 경우(예로는 노드 하드웨어의 실패 또는
@@ -98,8 +99,8 @@ echo $pods
pi-5rwd7
```
여기서 셀렉터는 잡의 셀렉터와 동일하다. `--output=jsonpath` 옵션은 반환된 목록의
각각의 파드에서 이름을 가져와서 표현하는 방식을 지정한다.
여기서 셀렉터는 잡의 셀렉터와 동일하다. `--output = jsonpath` 옵션은 반환된
목록에 있는 각 파드의 이름으로 표현식을 지정한다.
파드 중 하나를 표준 출력으로 본다.
@@ -145,8 +146,8 @@ kubectl logs $pods
- 파드가 성공적으로 종료하자마자 즉시 잡이 완료된다.
1. *고정적(fixed)인 완료 횟수* 를 가진 병렬 잡:
- `.spec.completions` 에 0이 아닌 양수 값을 지정한다.
- 잡은 전체 작업을 나타내며 1에서 `.spec.completions` 까지의 범위의 각 값에 대해 한 개씩 성공한 파드가 있으면 완료된다.
- **아직 구현되지 않음:** 각 파드에게는 1부터 `.spec.completions` 까지의 범위 내의 서로 다른 인덱스가 전달된다.
- 잡은 전체 작업을 나타내며, `.spec.completions` 성공한 파드가 있을 때 완료된다.
- `.spec.completionMode="Indexed"` 를 사용할 때, 각 파드는 0에서 `.spec.completions-1` 범위 내의 서로 다른 인덱스를 가져온다.
1. *작업 큐(queue)* 가 있는 병렬 잡:
- `.spec.completions` 를 지정하지 않고, `.spec.parallelism` 를 기본으로 한다.
- 파드는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 한다. 예를 들어 파드는 작업 큐에서 최대 N 개의 항목을 일괄로 가져올(fetch) 수 있다.
@@ -166,7 +167,6 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
다른 유형의 잡을 사용하는 방법에 대한 더 자세한 정보는 [잡 패턴](#잡-패턴) 섹션을 본다.
#### 병렬 처리 제어하기
요청된 병렬 처리(`.spec.parallelism`)는 음수가 아닌 값으로 설정할 수 있다.
@@ -185,6 +185,33 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
- 잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다.
- 파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다.
### 완료 모드
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< note >}}
인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다.
{{< /note >}}
완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
`.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
- `NonIndexed` (기본값): `.spec.completions` 가 성공적으로
완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드
완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는
잡은 암시적으로 `NonIndexed` 이다.
- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index`
어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다.
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
참고로, 드물기는 하지만, 동일한 인덱스에 대해 둘 이상의 파드를 시작할 수
있지만, 그 중 하나만 완료 횟수에 포함된다.
## 파드와 컨테이너 장애 처리하기
파드내 컨테이너의 프로세스가 0이 아닌 종료 코드로 종료되었거나 컨테이너 메모리 제한을
@@ -348,12 +375,12 @@ spec:
여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
패턴 이름은 예시와 더 자세한 설명을 위한 링크이다.
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정하지 않은 앱을 사용하는가? | Kube 1.1에서 작동하는가? |
| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ |
| [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 때때로 | ✓ |
| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ |
| 정적 작업이 할당된 단일 잡 | ✓ | | ✓ | |
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? |
| ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|
| [작업 항목 당 파드가 있는 큐] | ✓ | | 때때로 |
| [가변 파드 수를 가진 큐] | ✓ | ✓ | |
| [정적 작업 할당을 사용한 인덱싱된 잡] | ✓ | | ✓ |
| [잡 템플릿 확장] | | | ✓ |
`.spec.completions` 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는
동일한 [`사양`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)을 갖는다. 이 의미는
@@ -364,16 +391,121 @@ spec:
이 표는 각 패턴에 필요한 `.spec.parallelism` 그리고 `.spec.completions` 설정을 보여준다.
여기서 `W` 는 작업 항목의 수이다.
| 패턴 | `.spec.completions` | `.spec.parallelism` |
| -------------------------------------------------------------------- |:-------------------:|:--------------------:|
| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/) | 1 | 1이어야 함 |
| [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | any |
| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | any |
| 정적 작업이 할당된 단일 잡 | W | any |
| 패턴 | `.spec.completions` | `.spec.parallelism` |
| ----------------------------------------- |:-------------------:|:--------------------:|
| [작업 항목 당 파드가 있는 큐] | W | any |
| [가변 파드 수를 가진 큐] | null | any |
| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any |
| [잡 템플릿 확장] | 1 | 1이어야 함 |
[작업 항목 당 파드가 있는 큐]: /docs/tasks/job/coarse-parallel-processing-work-queue/
[가변 파드 수를 가진 큐]: /docs/tasks/job/fine-parallel-processing-work-queue/
[정적 작업 할당을 사용한 인덱싱된 잡]: /docs/tasks/job/indexed-parallel-processing-static/
[잡 템플릿 확장]: /docs/tasks/job/parallel-processing-expansion/
## 고급 사용법
### 잡 일시 중지
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< note >}}
잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을
사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다.
{{< /note >}}
잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
즉시 파드 생성을 시작하고 잡이 완료될 때까지
계속한다. 그러나, 잡의 실행을 일시적으로 중단하고 나중에
다시 시작할 수도 있다. 잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로
업데이트할 수 있다. 나중에, 다시 재개하려면, false로 업데이트한다.
`.spec.suspend` 로 설정된 잡을 생성하면 일시 중지된 상태로
생성된다.
잡이 일시 중지에서 재개되면, 해당 `.status.startTime` 필드가
현재 시간으로 재설정된다. 즉, 잡이 일시 중지 및 재개되면 `.spec.activeDeadlineSeconds`
타이머가 중지되고 재설정된다.
잡을 일시 중지하면 모든 활성 파드가 삭제된다. 잡이
일시 중지되면, SIGTERM 시그널로 [파드가 종료된다](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
파드의 정상 종료 기간이 적용되며 사용자의 파드는 이 기간 동안에
이 시그널을 처리해야 한다. 나중에 진행 상황을 저장하거나
변경 사항을 취소하는 작업이 포함될 수 있다. 이 방법으로 종료된 파드는
잡의 `completions` 수에 포함되지 않는다.
일시 중지된 상태의 잡 정의 예시는 다음과 같다.
```shell
kubectl get job myjob -o yaml
```
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: myjob
spec:
suspend: true
parallelism: 1
completions: 5
template:
spec:
...
```
잡의 상태를 사용하여 잡이 일시 중지되었는지 또는 과거에 일시 중지되었는지
확인할 수 있다.
```shell
kubectl get jobs/myjob -o yaml
```
```json
apiVersion: batch/v1
kind: Job
# .metadata and .spec omitted
status:
conditions:
- lastProbeTime: "2021-02-05T13:14:33Z"
lastTransitionTime: "2021-02-05T13:14:33Z"
status: "True"
type: Suspended
startTime: "2021-02-05T13:13:48Z"
```
"True" 상태인 "Suspended" 유형의 잡의 컨디션은 잡이
일시 중지되었음을 의미한다. 이 `lastTransitionTime` 필드는 잡이 일시 중지된
기간을 결정하는 데 사용할 수 있다. 해당 컨디션의 상태가 "False"이면, 잡이
이전에 일시 중지되었다가 현재 실행 중이다. 이러한 컨디션이
잡의 상태에 없으면, 잡이 중지되지 않은 것이다.
잡이 일시 중지 및 재개될 때에도 이벤트가 생성된다.
```shell
kubectl describe jobs/myjob
```
```
Name: myjob
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 12m job-controller Created pod: myjob-hlrpl
Normal SuccessfulDelete 11m job-controller Deleted pod: myjob-hlrpl
Normal Suspended 11m job-controller Job suspended
Normal SuccessfulCreate 3s job-controller Created pod: myjob-jvb44
Normal Resumed 3s job-controller Job resumed
```
마지막 4개의 이벤트, 특히 "Suspended" 및 "Resumed" 이벤트는
`.spec.suspend` 필드를 전환한 결과이다. 이 두 이벤트 사이의 시간동안
파드가 생성되지 않았지만, 잡이 재개되자마자 파드 생성이 다시
시작되었음을 알 수 있다.
### 자신의 파드 셀렉터를 지정하기
일반적으로 잡 오브젝트를 생성할 때 `.spec.selector` 를 지정하지 않는다.
content/ko/docs/concepts/workloads/controllers/replicaset.md
+45 -3
View File
@@ -222,7 +222,7 @@ pod2 1/1 Running 0 36s
## 레플리카셋 매니페스트 작성하기
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
레플리카셋에 대한 kind 필드의 값은 항상 레플리카셋이다.
레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
@@ -237,7 +237,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인
템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인
`.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다.
### 파드 셀렉터
@@ -307,9 +307,51 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
### 레플리카셋의 스케일링
레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 `.spec.replicas` 필드를 업데이트 하면 된다.
레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 `.spec.replicas` 필드를 업데이트하면 된다.
레플리카셋 컨트롤러는 일치하는 레이블 셀렉터가 있는 파드가 의도한 수 만큼 가용하고 운영 가능하도록 보장한다.
스케일 다운할 때, 레플리카셋 컨트롤러는 스케일 다운할 파드의
우선순위를 정하기 위해 다음의 기준으로 가용 파드를 정렬하여 삭제할 파드를 결정한다.
1. Pending 상태인 (+ 스케줄링할 수 없는) 파드가 먼저 스케일 다운된다.
2. `controller.kubernetes.io/pod-deletion-cost` 어노테이션이 설정되어 있는
파드에 대해서는, 낮은 값을 갖는 파드가 먼저 스케일 다운된다.
3. 더 많은 레플리카가 있는 노드의 파드가 더 적은 레플리카가 있는 노드의 파드보다 먼저 스케일 다운된다.
4. 파드 생성 시간이 다르면, 더 최근에 생성된 파드가
이전에 생성된 파드보다 먼저 스케일 다운된다.
(`LogarithmicScaleDown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면 생성 시간이 정수 로그 스케일로 버킷화된다)
모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.
### 파드 삭제 비용
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여,
레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다.
이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다.
이 어노테이션은 하나의 레플리카셋에 있는 다른 파드와의 상대적 삭제 비용을 나타낸다.
삭제 비용이 낮은 파드는 삭제 비용이 높은 파드보다 삭제 우선순위가 높다.
파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다.
유효하지 않은 값은 API 서버가 거부한다.
이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다.
kube-apiserver와 kube-controller-manager에서 `PodDeletionCost`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다.
{{< note >}}
- 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.
- 이 값을 자주 바꾸는 것은 피해야 한다 (예: 메트릭 값에 따라 변경).
apiserver에서 많은 양의 파드 업데이트를 동반하기 때문이다.
{{< /note >}}
#### 사용 예시
한 애플리케이션 내의 여러 파드는 각각 사용률이 다를 수 있다. 스케일 다운 시,
애플리케이션은 사용률이 낮은 파드를 먼저 삭제하고 싶을 수 있다. 파드를 자주
업데이트하는 것을 피하기 위해, 애플리케이션은 `controller.kubernetes.io/pod-deletion-cost` 값을
스케일 다운하기 전에 1회만 업데이트해야 한다 (파드 사용률에 비례하는 값으로 설정).
이 방식은 Spark 애플리케이션의 드라이버 파드처럼 애플리케이션이 스스로 다운스케일링을 수행하는 경우에 유효하다.
### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정
레플리카셋은
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+12 -9
View File
@@ -54,7 +54,9 @@ kubectl 명령에서 숏컷으로 사용된다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
```
출력 결과는 다음과 같다.
```
replicationcontroller/nginx created
```
@@ -64,7 +66,9 @@ replicationcontroller/nginx created
```shell
kubectl describe replicationcontrollers/nginx
```
출력 결과는 다음과 같다.
```
Name: nginx
Namespace: default
@@ -103,14 +107,16 @@ Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
echo $pods
```
출력 결과는 다음과 같다.
```
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
```
여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고,
다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은
반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다.
다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은
반환된 목록의 각 파드의 이름을 출력하도록 하는 옵션이다.
## 레플리케이션 컨트롤러의 Spec 작성
@@ -118,7 +124,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
레플리케이션 컨트롤러 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
환경설정 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
@@ -198,7 +204,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
### 레플리케이션 컨트롤러에서 파드 격리
파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅, 데이터 복구 등을 위해 서비스에서 파드를 제거하는데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).
파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅과 데이터 복구를 위해 서비스에서 파드를 제거하는 데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).
## 일반적인 사용법 패턴
@@ -208,8 +214,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
### 스케일링
레플리케이션컨트롤러는 `replicas` 필드를 설정하여 레플리카의 수를 늘리거나 줄인다.
레플리카를 수동으로 또는 오토 스케일링 제어 에이전트로 관리하도록 레플리케이션컨트롤러를 구성할 수 있다.
레플리케이션컨트롤러는 `replicas` 필드를 업데이트하여, 수동으로 또는 오토 스케일링 제어 에이전트를 통해, 레플리카의 수를 늘리거나 줄일 수 있다.
### 롤링 업데이트
@@ -246,7 +251,6 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
## API 오브젝트
레플리케이션 컨트롤러는 쿠버네티스 REST API의 최상위 수준의 리소스이다.
@@ -261,8 +265,7 @@ API 오브젝트에 대한 더 자세한 것은
이것은 주로 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
### 디플로이먼트 (권장되는)
### 디플로이먼트 (권장됨)
[`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
+4 -4
View File
@@ -6,7 +6,7 @@ weight: 70
<!-- overview -->
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
@@ -14,9 +14,9 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
처리하도록 확장될 수 있다.
알파(Alpha) 고지 사항: 이 기능은 현재 알파이고,
kube-apiserver와 kube-controller-manager와 함께
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다.
이 기능은 현재 베타이고 기본적으로 활성화되어 있다.
kube-apiserver와 kube-controller-manager에서 `TTLAfterFinished`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다.
<!-- body -->
content/ko/docs/concepts/workloads/pods/disruptions.md
+1 -1
View File
@@ -89,7 +89,7 @@ weight: 60
## 파드 disruption budgets
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
쿠버네티스는 자발적인 중단이 자주 발생하는 경우에도 고 가용성 애플리케이션을
실행하는 데 도움이 되는 기능을 제공한다.
content/ko/docs/concepts/workloads/pods/init-containers.md
+8 -9
View File
@@ -313,17 +313,16 @@ myapp-pod 1/1 Running 0 9m
파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수
있다.
* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다.
Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너
이미지의 변경은 앱 컨테이너만 재시작시킨다.
* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
* 파드 인프라스트럭처 컨테이너가 재시작된 상황. 이는 일반적인 상황이 아니며 노드에
대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는,
동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
때문에 유실되었다.
* 초기화 컨테이너의 완료 기록이 가비지 수집 때문에 유실된 상태에서,
`restartPolicy`가 Always로 설정된 파드의 모든 컨테이너가 종료되어
모든 컨테이너를 재시작해야 하는 상황
초기화 컨테이너 이미지가 변경되거나 초기화 컨테이너의 완료 기록이 가비지 수집
때문에 유실된 상태이면 파드는 재시작되지 않는다. 이는 쿠버네티스 버전 1.20 이상에
적용된다. 이전 버전의 쿠버네티스를 사용하는 경우 해당 쿠버네티스 버전의 문서를
참고한다.
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+2 -2
View File
@@ -312,8 +312,8 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
{{< note >}}
파드가 삭제될 때 단지 요청들을 흘려 보낼(drain) 목적으로,
준비성 프로브가 필요하지는 않다는 점을 유념해야 한다. 삭제 시에, 파드는
파드가 삭제될 때 요청들을 흘려 보내기(drain) 위해
준비성 프로브가 꼭 필요한 것은 아니다. 삭제 시에, 파드는
프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다.
파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
남아 있다.
content/ko/docs/contribute/generate-ref-docs/_index.md
+4 -4
View File
@@ -1,11 +1,11 @@
---
title: 참조 문서 개요
title: 레퍼런스 문서 개요
main_menu: true
weight: 80
---
이 섹션은 쿠버네티스 참조 가이드를 생성하는 방법에 대해 설명한다.
이 섹션은 쿠버네티스 레퍼런스 가이드를 생성하는 방법에 대해 설명한다.
참조 문서화 시스템을 빌드하려면, 다음의 가이드를 참고한다.
레퍼런스 문서를 생성하려면, 다음의 가이드를 참고한다.
* [참조 문서 생성에 대한 퀵스타트 가이드](/docs/contribute/generate-ref-docs/quickstart/)
* [레퍼런스 문서 생성에 대한 퀵스타트 가이드](/ko/docs/contribute/generate-ref-docs/quickstart/)
content/ko/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md
+22
View File
@@ -0,0 +1,22 @@
### 필요 사항: {#Requirements}
- 리눅스 또는 macOS 로 구동되는 개발 환경이 필요하다.
- 다음의 도구들이 설치되어 있어야 한다.
- [Python](https://www.python.org/downloads/) v3.7.x
- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
- [Golang](https://golang.org/doc/install) version 1.13+
- [Pip](https://pypi.org/project/pip/) (PyYAML 설치에 필요함)
- [PyYAML](https://pyyaml.org/) v5.1.2
- [make](https://www.gnu.org/software/make/)
- [gcc compiler/linker](https://gcc.gnu.org/)
- [Docker](https://docs.docker.com/engine/installation/) (`kubectl` 명령어 레퍼런스 업데이트에만 필요함)
- 위에 나열된 도구들 (예: `Go` 바이너리나 `python`) 을 사용할 수 있도록 `PATH` 환경 변수를 알맞게 설정해야 한다.
- GitHub 저장소로 풀 리퀘스트를 생성하는 방법을 알고 있어야 한다.
이를 위해 `kubernetes/website` 저장소를 개인 계정으로 포크해야 한다.
더 자세한 내용은 [로컬 포크에서 작업하기](/ko/docs/contribute/new-content/open-a-pr/#fork-the-repo)를 참조한다.
content/ko/docs/contribute/generate-ref-docs/quickstart.md
+257
View File
@@ -0,0 +1,257 @@
---
title: 퀵스타트 가이드
content_type: task
weight: 40
---
<!-- overview -->
이 문서에서는 `update-imported-docs` 스크립트를 사용하여
쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다.
이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다.
## {{% heading "prerequisites" %}}
{{< include "prerequisites-ref-docs.md" >}}
<!-- steps -->
## `website` 저장소 클론하기 {#Getting-the-docs-repository}
개인 계정에 있는 포크 버전의 `website` 저장소가 `kubernetes/website` 저장소의 master 브랜치만큼 최신인지 확인한 뒤,
개인 계정에 있는 포크 버전의 `website` 저장소를 로컬 개발 환경으로 클론한다.
```shell
mkdir github.com
cd github.com
git clone git@github.com:<your_github_username>/website.git
```
아래에서 사용될 '베이스 디렉터리'를 숙지해야 한다. 예를 들어 위에 안내된 대로
저장소를 클론했다면, 베이스 디렉터리는
`github.com/website` 가 된다. 이제 이 문서의 나머지 부분에서 `<web-base>` 라는 구문이 나오면
이 부분에 당신의 베이스 디렉터리를 대입하면 된다.
{{< note>}}
만약 쿠버네티스 구성 도구와 API 레퍼런스에 기여하고 싶다면,
[업스트림 코드에 기여하기 (영문)](/docs/contribute/generate-ref-docs/contribute-upstream) 를 참조한다.
{{< /note >}}
## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs}
`update-imported-docs` 스크립트는 `<web-base>/update-imported-docs/`
디렉터리에 존재한다.
이 스크립트는 다음 레퍼런스를 생성한다.
* 구성요소 및 도구 레퍼런스 페이지
* `kubectl` 명령어 레퍼런스
* 쿠버네티스 API 레퍼런스
`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를
생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와
`kubernetes-sigs/reference-docs` 저장소를 클론하며,
`GOPATH` 환경 변수를 이 임시 디렉터리로 지정한다.
또한 이 스크립트는 다음의 환경 변수를 설정한다.
* `K8S_RELEASE`
* `K8S_ROOT`
* `K8S_WEBROOT`
스크립트가 정상적으로 실행되려면 인자 2개를 전달해야 한다.
* 환경설정 YAML 파일 (`reference.yml`)
* 쿠버네티스 릴리스 버전 (예: `1.17`)
환경설정 파일은 `generate-command` 라는 필드를 포함하는데,
이 필드에는
`kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다.
`K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다.
`update-imported-docs` 스크립트는 다음의 과정을 수행한다.
1. 환경설정 파일에 있는 관련 저장소를 클론한다.
레퍼런스 문서 생성을 위해
기본적으로는 `kubernetes-sigs/reference-docs` 저장소를 클론하도록 되어 있다.
1. 클론한 안에서, 문서 생성에 필요한 사항을 준비하기 위한 명령어를 실행한 뒤,
HTML 파일과 마크다운 파일을 생성한다.
1. 생성된 HTML 파일과 마크다운 파일을
환경설정 파일에 명시된 규칙에 따라 `<web-base>` 로 복사한다.
1. `kubectl`.md 에 있는 `kubectl` 명령어 링크들이
`kubectl` 명령어 레퍼런스 페이지의 올바른 섹션으로 연결되도록 업데이트한다.
생성된 파일이 `<web-base>` 아래에 복사되었으면,
`kubernetes/website` 저장소로 [풀 리퀘스트를 생성](/ko/docs/contribute/new-content/open-a-pr/)
할 수 있다.
## 환경설정 파일 형식 {#Configuration-file-format}
각 환경설정 파일은 레퍼런스 생성을 위해 필요한 여러 저장소의 정보를 담을 수 있다.
필요한 경우, 환경설정 파일을 직접 수정하여 사용할 수도 있다.
또는, 다른 그룹의 문서를 임포트하기 위해 새로운 환경설정 파일을 작성할 수도 있다.
다음은 환경설정 YAML 파일의 예시이다.
```yaml
repos:
- name: community
remote: https://github.com/kubernetes/community.git
branch: master
files:
- src: contributors/devel/README.md
dst: docs/imported/community/devel.md
- src: contributors/guide/README.md
dst: docs/imported/community/guide.md
```
이 도구에 의해 처리될 단일 페이지 마크다운 문서는
[문서 스타일 가이드](/docs/contribute/style/style-guide/)의 내용을 만족해야 한다.
## reference.yml 환경설정 파일 다루기 {#Customizing-reference-yml}
`<web-base>/update-imported-docs/reference.yml` 환경설정 파일을 열어 수정할 수 있다.
레퍼런스 문서 생성을 위해 명령어들이 어떻게 사용되고 있는지 파악하지 못했다면,
`generate-command` 필드의 내용은 수정하지 말아야 한다.
대부분의 경우 `reference.yml` 을 직접 수정해야 할 필요는 없다.
때때로, 업스트림 소스코드 업데이트 때문에 이 환경설정 파일을 수정해야 할 수도 있다.
(예: Golang 버전 의존성, 서드파티 라이브러리 변경 등)
만약 스크립트 사용 시 빌드 문제가 있다면,
[쿠버네티스 슬랙의 #sig-docs 채널](https://kubernetes.slack.com/archives/C1J0BPD2M)에서 SIG-Docs 팀에 문의하면 된다.
{{< note >}}
`generate-command` 는 특정 저장소로부터 문서를 만들기 위한
명령어나 스크립트를 실행하기 위해 사용할 수 있는 선택적 필드이다.
{{< /note >}}
`reference.yml` 환경설정 파일에서, `files` 필드는 `src` 와 `dst` 필드를 포함한다.
`src` 필드에는 `kubernetes-sigs/reference-docs` 디렉터리 아래에 있는 생성된 마크다운 파일의 위치를 명시하고,
`dst` 필드에는 이 파일을
`kubernetes/website` 디렉터리 아래의 어느 위치로 복사할지를 명시한다.
예시는 다음과 같다.
```yaml
repos:
- name: reference-docs
remote: https://github.com/kubernetes-sigs/reference-docs.git
files:
- src: gen-compdocs/build/kube-apiserver.md
dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
...
```
만약 하나의 `src` 디렉터리에서 하나의 `dst` 디렉터리로 많은 파일이 복사되어야 한다면,
`src` 필드에 와일드카드를 사용할 수 있다.
이 경우, `dst` 필드에는 단일 파일의 경로가 아니라 디렉터리의 경로를 명시해야 한다.
예시는 다음과 같다.
```yaml
files:
- src: gen-compdocs/build/kubeadm*.md
dst: content/en/docs/reference/setup-tools/kubeadm/generated/
```
## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool}
다음과 같이 `update-imported-docs` 도구를 실행할 수 있다.
```shell
cd <web-base>/update-imported-docs
./update-imported-docs <configuration-file.yml> <release-version>
```
예를 들면 다음과 같다.
```shell
./update-imported-docs reference.yml 1.17
```
<!-- Revisit: is the release configuration used -->
## 링크 업데이트하기 {#Fixing-Links}
`release.yml` 환경설정 파일은 상대경로 링크를 수정하는 방법을 포함하고 있다.
임포트하는 파일 안에 있는 상대경로 링크를 수정하려면, `gen-absolute-links` 필드를
`true` 로 명시한다. 이에 대한 예시는
[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml) 에서 볼 수 있다.
## `kubernetes/website` 의 변경사항을 커밋하기 {#Adding-and-committing-changes-in-kubernetes-website}
다음의 명령을 실행하여, 스크립트에 의해 생성된 뒤 `<web-base>` 아래에 복사된 파일의 목록을 볼 수 있다.
```shell
cd <web-base>
git status
```
위의 명령을 실행하면 새로 추가된 파일과 수정된 파일의 목록을 볼 수 있다.
아래의 결과 예시는 업스트림 소스코드의 변경사항에 따라 다르게 나타날 수 있다.
### 생성된 구성요소 도구 레퍼런스 {#Generated-component-tool-files}
```
content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
content/en/docs/reference/command-line-tools-reference/kube-proxy.md
content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md
content/en/docs/reference/kubectl/kubectl.md
```
### 생성된 kubectl 명령어 레퍼런스 {#Generated-kubectl-command-reference-files}
```
static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js
static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/css/font-awesome.min.css
```
### 생성된 쿠버네티스 API 레퍼런스 와 파일 {#Generated-Kubernetes-API-reference-directories-and-files}
```
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/index.html
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/navData.js
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/scroll.js
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/query.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff2
```
`git add` 와 `git commit` 명령을 실행하여 추가/변경된 파일을 커밋한다.
## 풀 리퀘스트 만들기 {#Creating-a-pull-request}
`kubernetes/website` 저장소에 풀 리퀘스트를 등록한다.
등록한 풀 리퀘스트를 모니터하고, 리뷰 커멘트가 달리면 그에 대해 대응을 한다.
풀 리퀘스트가 머지될 때 까지 계속 모니터한다.
풀 리퀘스트가 머지된 뒤 몇 분이 지나면,
변경사항을
[쿠버네티스 문서 홈페이지](/docs/home/)에서 확인할 수 있다.
## {{% heading "whatsnext" %}}
수동으로 빌드 저장소를 설정하고 빌드 타겟을 실행하여 개별 레퍼런스 문서를 생성하려면,
다음의 가이드를 참고한다.
* [쿠버네티스 구성요소와 도구에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/)
* [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/)
content/ko/docs/reference/_index.md
+25 -8
View File
@@ -21,8 +21,6 @@ no_list: true
* [표준 용어집](/ko/docs/reference/glossary/) - 포괄적이고, 표준화 된 쿠버네티스 용어 목록
* [쿠버네티스 API 레퍼런스](/docs/reference/kubernetes-api/)
* [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
@@ -50,16 +48,35 @@ no_list: true
## 컴포넌트
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API.
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각
노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며
기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -
파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을
수행하는 REST API.
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한
TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을
할 수 있다.
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
## 스케줄링
* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
* [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)
* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
## 환경설정 API
이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
"미발표된" API를 다룬다. 이 API들은 사용자나 관리자가 클러스터를
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
제공하지 않는다.
* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
* [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)
## 설계 문서
content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
+2 -2
View File
@@ -55,9 +55,9 @@ weight: 50
1. `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
#### 바인딩된 서비스 어카운트 토큰 볼륨
{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가
`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가
시크릿 볼륨 대신 프로젝티드 서비스 어카운트 토큰 볼륨을 추가한다. 서비스 어카운트 토큰은 기본적으로 1시간 후에 만료되거나 파드가 삭제된다. [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참고한다.
이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 활성화된 `RootCAConfigMap` 기능 게이트에 따라 다르다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+97 -32
View File
@@ -59,11 +59,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
| `AppArmor` | `true` | 베타 | 1.4 | |
| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | |
| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | |
| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | |
| `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
| `CPUManager` | `true` | 베타 | 1.10 | |
| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 |
| `CRIContainerLogRotation` | `true` | 베타| 1.11 | |
| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 |
| `CSIInlineVolume` | `true` | 베타 | 1.16 | - |
| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 |
@@ -74,7 +73,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | |
| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | |
| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 |
| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | |
| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigrationGCE` | `false` | 베타 | 1.17 | |
@@ -84,13 +84,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | |
| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | |
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | |
| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 |
| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | |
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | 베타 | 1.21 | |
| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 |
| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | |
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | |
| `CronJobControllerV2` | `false` | 알파 | 1.20 | |
| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 |
| `CronJobControllerV2` | `true` | 베타 | 1.21 | |
| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | |
@@ -98,14 +101,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `DevicePlugins` | `true` | 베타 | 1.10 | |
| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 |
| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | |
| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | |
| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 |
| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | |
| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | |
| `EfficientWatchResumption` | `false` | 알파 | 1.20 | |
| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 |
| `EndpointSlice` | `false` | 베타 | 1.17 | |
| `EndpointSlice` | `true` | 베타 | 1.18 | |
| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | |
| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
| `EndpointSliceProxying` | `true` | 베타 | 1.19 | |
| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | |
@@ -117,15 +117,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 |
| `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | |
| `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | |
| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | |
| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | 1.20 |
| `GenericEphemeralVolume` | `true` | 베타 | 1.21 | |
| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 |
| `GracefulNodeShutdown` | `true` | 베타 | 1.21 | |
| `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
| `HPAScaleToZero` | `false` | 알파 | 1.16 | |
| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | |
| `IPv6DualStack` | `false` | 알파 | 1.15 | |
| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | |
| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | |
| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 |
| `IPv6DualStack` | `true` | 베타 | 1.21 | |
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
| `KubeletPodResources` | `true` | 알파 | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | 베타 | 1.15 | |
@@ -134,22 +136,25 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
| `MixedProtocolLBService` | `false` | 알파 | 1.20 | |
| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | |
| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | |
| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | |
| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
| `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
| `PodDisruptionBudget` | `true` | 베타 | 1.5 | |
| `PodDeletionCost` | `false` | 알파 | 1.21 | |
| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | |
| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
| `PodOverhead` | `true` | 베타 | 1.18 | |
| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | |
| `ProcMountType` | `false` | 알파 | 1.12 | |
| `QOSReserved` | `false` | 알파 | 1.11 | |
| `RemainingItemCount` | `false` | 알파 | 1.15 | |
| `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 |
| `RemoveSelfLink` | `true` | 베타 | 1.20 | |
| `RootCAConfigMap` | `false` | 알파 | 1.13 | 1.19 |
| `RootCAConfigMap` | `true` | 베타 | 1.20 | |
| `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
| `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
| `RunAsGroup` | `true` | 베타 | 1.14 | |
@@ -157,9 +162,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `SCTPSupport` | `true` | 베타 | 1.19 | |
| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
| `ServerSideApply` | `true` | 베타 | 1.16 | |
| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 |
| `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | |
| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | |
| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | |
| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | |
| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
| `ServiceTopology` | `false` | 알파 | 1.17 | |
@@ -169,8 +174,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `StorageVersionAPI` | `false` | 알파 | 1.20 | |
| `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | 베타 | 1.15 | |
| `Sysctls` | `true` | 베타 | 1.11 | |
| `SuspendJob` | `false` | 알파 | 1.21 | |
| `TTLAfterFinished` | `false` | 알파 | 1.12 | |
| `TopologyAwareHints` | `false` | 알파 | 1.21 | |
| `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
| `TopologyManager` | `true` | 베타 | 1.18 | |
| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
@@ -179,7 +185,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `WinDSR` | `false` | 알파 | 1.14 | |
| `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
| `WinOverlay` | `true` | 베타 | 1.20 | |
| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | |
| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 |
| `WindowsEndpointSliceProxying` | `true` | beta | 1.21 | |
{{< /table >}}
### GA 또는 사용 중단된 기능을 위한 기능 게이트
@@ -200,6 +207,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `BlockVolume` | `false` | 알파 | 1.9 | 1.12 |
| `BlockVolume` | `true` | 베타 | 1.13 | 1.17 |
| `BlockVolume` | `true` | GA | 1.18 | - |
| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 |
| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 |
| `CRIContainerLogRotation` | `true` | GA | 1.21 | - |
| `CSIBlockVolume` | `false` | 알파 | 1.11 | 1.13 |
| `CSIBlockVolume` | `true` | 베타 | 1.14 | 1.17 |
| `CSIBlockVolume` | `true` | GA | 1.18 | - |
@@ -215,6 +225,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 |
| `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 |
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
| `CSIVolumeHealth` | `false` | 알파 | 1.21 | - |
| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 |
| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 |
| `CustomPodDNS` | `true` | GA | 1.14 | - |
@@ -245,6 +256,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - |
| `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 |
| `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - |
| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 |
| `EndpointSlice` | `false` | 베타 | 1.17 | 1.17 |
| `EndpointSlice` | `true` | 베타 | 1.18 | 1.21 |
| `EndpointSlice` | `true` | GA | 1.21 | - |
| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.21 |
| `EndpointSliceNodeName` | `true` | GA | 1.21 | - |
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
@@ -258,6 +275,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `HugePages` | `true` | GA | 1.14 | - |
| `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 |
| `HyperVContainer` | `false` | 사용중단 | 1.20 | - |
| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | 1.20 |
| `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | |
| `IndexedJob` | `false` | 알파 | 1.21 | |
| `Initializers` | `false` | 알파 | 1.7 | 1.13 |
| `Initializers` | - | 사용중단 | 1.14 | - |
| `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 |
@@ -281,6 +302,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 |
| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 |
| `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
| `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 |
| `PodDisruptionBudget` | `true` | GA | 1.21 | - |
| `PodPriority` | `false` | 알파 | 1.8 | 1.10 |
| `PodPriority` | `true` | 베타 | 1.11 | 1.13 |
| `PodPriority` | `true` | GA | 1.14 | - |
@@ -296,6 +320,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 |
| `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 |
| `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
| `RootCAConfigMap` | `false` | 알파 | 1.13 | 1.19 |
| `RootCAConfigMap` | `true` | 베타 | 1.20 | 1.20 |
| `RootCAConfigMap` | `true` | GA | 1.21 | - |
| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 |
| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
| `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 |
@@ -307,6 +334,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
| `SCTPSupport` | `true` | 베타 | 1.19 | 1.19 |
| `SCTPSupport` | `true` | GA | 1.20 | - |
| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 |
| `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 |
| `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - |
| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
| `ServiceAppProtocol` | `true` | GA | 1.20 | - |
@@ -331,6 +361,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 |
| `SupportPodPidsLimit` | `true` | 베타 | 1.14 | 1.19 |
| `SupportPodPidsLimit` | `true` | GA | 1.20 | - |
| `Sysctls` | `true` | 베타 | 1.11 | 1.20 |
| `Sysctls` | `true` | GA | 1.21 | |
| `TaintBasedEvictions` | `false` | 알파 | 1.6 | 1.12 |
| `TaintBasedEvictions` | `true` | 베타 | 1.13 | 1.17 |
| `TaintBasedEvictions` | `true` | GA | 1.18 | - |
@@ -343,6 +375,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 |
| `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 |
| `TokenRequestProjection` | `true` | GA | 1.20 | - |
| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 |
| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | 1.19 |
| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - |
@@ -444,7 +477,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
확인한다.
- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
[CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다.
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다.
더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다.
자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)
문서를 참고한다.
@@ -525,6 +560,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다.
이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과
권한 수정을 지원하는지 여부를 제어한다.
- `CSIVolumeHealth`: 노드에서의 CSI 볼륨 상태 모니터링 기능을 활성화한다.
- `ConfigurableFSGroupPolicy`: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한
볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은
[파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을
@@ -546,7 +582,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다.
- `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
실행 중인 파드 문제를 해결한다.
- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
[기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
- `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
@@ -624,10 +659,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `HyperVContainer`: 윈도우 컨테이너를 위한
[Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)
기능을 활성화한다.
- `IPv6DualStack`: IPv6에 대한 [듀얼 스택](/ko/docs/concepts/services-networking/dual-stack/)
지원을 활성화한다.
- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
변경할 수 없는(immutable) 것으로 표시할 수 있다.
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다.
- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로
한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에
`Scope` 와 `Namespace` 2개의 필드를 추가한다.
- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
기능을 활성화한다.
- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서
kubelet 구성을 로드할 수 있다.
자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
@@ -638,10 +678,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은
[장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을
참고한다.
- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 `GetAllocatableResources` 기능을 활성화한다.
이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를
[자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다.
- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은
`NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여
`node-role.kubernetes.io/master` 레이블을 무시한다.
- `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와
- `LocalStorageCapacityIsolation`:
[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와
[emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의
`sizeLimit` 속성을 사용할 수 있게 한다.
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에
@@ -651,21 +695,30 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
프로젝트 쿼터를 사용하여 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)
스토리지 사용을 모니터링하여 성능과 정확성을
향상시킨다.
- `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여
축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다.
- `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
사용을 활성화한다.
- `MountContainers` (*사용 중단됨*): 호스트의 유틸리티 컨테이너를 볼륨 마운터로
사용할 수 있다.
- `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
- `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable)
{{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. (네임스페이스의 이름도 변경 불가)
- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다.
- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption`
사용을 활성화한다.
- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
삭제되지 않도록 한다.
- `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록,
[파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다.
- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다.
`local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다.
- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다.
- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과
[CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다.
- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
기능을 활성화한다.
- `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를
@@ -676,6 +729,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를
공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은
[파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다.
- `ProbeTerminationGracePeriod`: 파드의 [프로브-수준
`terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다.
더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다.
- `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여
컨테이너의 proc 타입의 마운트를 제어할 수 있다.
- `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가
@@ -715,8 +771,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
[파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을
참고한다.
- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다.
- `ServiceInternalTrafficPolicy`: 서비스에서 `InternalTrafficPolicy` 필드를 활성화한다.
- `ServiceLBNodePortControl`: 서비스에서`spec.allocateLoadBalancerNodePorts` 필드를
활성화한다.
- `ServiceLoadBalancerClass`: 서비스에서 `LoadBalancerClass` 필드를 활성화한다. 자세한 내용은 [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다.
- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를
제외할 수 있다. "`node.kubernetes.io/exclude-from-external-load-balancers`"로
@@ -725,8 +783,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
있도록 한다. 자세한 내용은
[서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를
참고한다.
- `SizeMemoryBackedVolumes`: kubelet 지원을 사용하여 메모리 백업 볼륨의 크기를 조정한다.
자세한 내용은 [volumes](/ko/docs/concepts/storage/volumes)를 참조한다.
- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로
설정하는 기능을 활성화한다.
[파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다.
@@ -750,6 +806,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
파라미터를 지정하여 지정된 수의 프로세스 ID가
시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록
할 수 있다.
- `SuspendJob`: 잡 중지/재시작 기능을 활성화한다.
자세한 내용은 [잡 문서](/ko/docs/concepts/workloads/controllers/job/)를
참고한다.
- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널
파라미터(sysctl)를 지원한다. 자세한 내용은
[sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
@@ -765,9 +824,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `TokenRequest`: 서비스 어카운트 리소스에서 `TokenRequest` 엔드포인트를 활성화한다.
- `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해
서비스 어카운트 토큰을 파드에 주입할 수 있다.
- `TopologyAwareHints`: 엔드포인트슬라이스(EndpointSlices)에서 토폴로지 힌트 기반
토폴로지-어웨어 라우팅을 활성화한다. 자세한 내용은
[토폴로지 어웨어 힌트](/docs/concepts/services-networking/topology-aware-hints/)
를 참고한다.
- `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스
할당을 조정하는 메커니즘을 활성화한다.
[노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)를 참고한다.
- `VolumeCapacityPriority`: 가용 PV 용량을 기반으로
여러 토폴로지에 있는 노드들의 우선순위를 정하는 기능을 활성화한다.
- `VolumePVCDataSource`: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다.
- `VolumeScheduling`: 볼륨 토폴로지 인식 스케줄링을 활성화하고
퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한
content/ko/docs/reference/glossary/cloud-controller-manager.md
+2 -2
View File
@@ -11,10 +11,10 @@ tags:
- architecture
- operation
---
클라우드별 컨트롤 로직을 포함하는 쿠버네티스
클라우드별 컨트롤 로직을 포함하는 쿠버네티스
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다.
클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고,
해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다.
해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.
<!--more-->
content/ko/docs/reference/kubectl/cheatsheet.md
+4 -1
View File
@@ -357,7 +357,7 @@ API 리소스를 탐색하기 위한 다른 작업:
```bash
kubectl api-resources --namespaced=true # 네임스페이스를 가지는 모든 리소스
kubectl api-resources --namespaced=false # 네임스페이스를 가지지 않는 모든 리소스
kubectl api-resources -o name # 모든 리소스의 단순한 (리소스 이름 만) 출력
kubectl api-resources -o name # 모든 리소스의 단순한 (리소스 이름만) 출력
kubectl api-resources -o wide # 모든 리소스의 확장된 ("wide"로 알려진) 출력
kubectl api-resources --verbs=list,get # "list"와 "get"의 요청 동사를 지원하는 모든 리소스 출력
kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 리소스
@@ -384,6 +384,9 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든
# 클러스터에서 실행 중인 모든 이미지
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
# `default` 네임스페이스의 모든 이미지를 파드별로 그룹지어 출력
kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"
# "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
content/ko/docs/reference/scheduling/config.md
+10 -6
View File
@@ -18,12 +18,10 @@ weight: 20
각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
컴포넌트 구성 API([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
또는 [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration))를
사용하고, `kube-scheduler --config <filename>`을 실행하여
[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
구조에 맞게 파일을 작성하고,
`kube-scheduler --config <filename>`을 실행하여
스케줄링 프로파일을 지정할 수 있다.
`v1alpha2` API를 사용하면 [여러 프로파일](#여러-프로파일)을
실행하도록 kube-scheduler를 구성할 수 있다.
최소 구성은 다음과 같다.
@@ -149,7 +147,12 @@ profiles:
익스텐션 포인트: `Score`.
- `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지
또는 바인딩할 수 있는지 확인한다.
익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`.
익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`.
{{< note >}}
`Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이
활성화되어 있어야 활성화되며,
요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다.
{{< /note >}}
- `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한
제한 사항을 충족하는지 확인한다.
익스텐션 포인트: `Filter`.
@@ -249,3 +252,4 @@ profiles:
* [kube-scheduler 레퍼런스](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
content/ko/docs/reference/scheduling/policies.md
+3 -5
View File
@@ -8,9 +8,7 @@ weight: 10
스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다.
`kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>`을 실행하고 [정책 유형](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy)을 사용하여 스케줄링 정책을 설정할 수 있다.
`kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>`을 실행하고 [정책 유형](/docs/reference/config-api/kube-scheduler-policy-config.v1/)을 사용하여 스케줄링 정책을 설정할 수 있다.
<!-- body -->
@@ -110,9 +108,9 @@ weight: 10
- `EvenPodsSpreadPriority`: 선호된
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다.
## {{% heading "whatsnext" %}}
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
* [kube-scheduler configuration 레퍼런스 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1) 읽어보기
* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기
content/ko/docs/reference/setup-tools/kubeadm/_index.md
+2
View File
@@ -26,5 +26,7 @@ kubeadm을 설치하려면, [설치 가이드](/ko/docs/setup/production-environ
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다.
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/): `kubeadm join` 을 위한 토큰을 관리한다.
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다.
* [kubeadm certs](/docs/reference/setup-tools/kubeadm/kubeadm-certs): 쿠버네티스 인증서를 관리한다.
* [kubeadm kubeconfig](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig): kubeconfig 파일을 관리한다.
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version/): kubeadm 버전을 출력한다.
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다.
content/ko/docs/setup/best-practices/cluster-large.md
+2 -3
View File
@@ -67,9 +67,8 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일
쿠버네티스 [리소스 제한](/ko/docs/concepts/configuration/manage-resources-containers/)은
파드와 컨테이너가 다른 컴포넌트에 영향을 줄 수 있는 메모리 누수 및 기타 방식의 영향을
최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용되는 것과 마찬가지로
{{< glossary_tooltip text="애드온" term_id="addons" >}}에도 적용될 수 있으며
적용되어야 한다.
최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용될 수 있는 것처럼
{{< glossary_tooltip text="애드온" term_id="addons" >}} 리소스에도 적용될 수 있다.
예를 들어, 로깅 컴포넌트에 대한 CPU 및 메모리 제한을 설정할 수 있다.
content/ko/docs/setup/production-environment/container-runtimes.md
+6 -1
View File
@@ -48,7 +48,7 @@ Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할
시스템이 안정화된다. 도커에 대해 구성하려면, `native.cgroupdriver=systemd`를 설정한다.
{{< caution >}}
클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 강력하게 권장하지 *않는다*.
클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 신중하게 수행해야 한다.
하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면,
컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 파드 샌드박스 재생성을 시도할 때, 에러가 발생할 수 있다.
kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
@@ -57,6 +57,11 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
교체하거나, 자동화를 사용하여 다시 설치한다.
{{< /caution >}}
### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기
kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
[변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
## 컨테이너 런타임
{{% thirdparty-content %}}
content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+10 -27
View File
@@ -70,7 +70,7 @@ sudo sysctl --system
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용자 |
|----------|-----------|------------|-------------------------|---------------------------|
| TCP | 인바운드 | 6443* | 쿠버네티스 API 서버 | 모두 |
| TCP | 인바운드 | 6443\* | 쿠버네티스 API 서버 | 모두 |
| TCP | 인바운드 | 2379-2380 | etcd 서버 클라이언트 API | kube-apiserver, etcd |
| TCP | 인바운드 | 10250 | kubelet API | 자체, 컨트롤 플레인 |
| TCP | 인바운드 | 10251 | kube-scheduler | 자체 |
@@ -294,33 +294,17 @@ Flatcar Container Linux 배포판은 `/usr` 디렉터리를 읽기 전용 파일
kubelet은 이제 kubeadm이 수행할 작업을 알려 줄 때까지 크래시루프(crashloop) 상태로
기다려야 하므로 몇 초마다 다시 시작된다.
## 컨트롤 플레인 노드에서 kubelet이 사용하는 cgroup 드라이버 구성
## cgroup 드라이버 구성
도커를 사용할 때, kubeadm은 kubelet 용 cgroup 드라이버를 자동으로 감지하여
런타임 중에 `/var/lib/kubelet/config.yaml` 파일에 설정한다.
다른 CRI를 사용하는 경우, 다음과 같이 `cgroupDriver` 값을 `kubeadm init` 에 전달해야 한다.
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: <value>
```
자세한 내용은 [구성 파일과 함께 kubeadm init 사용](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)을 참고한다.
`cgroupfs` 가 이미 kubelet의 기본값이기 때문에, 사용자의
CRI cgroup 드라이버가 `cgroupfs` 가 아닌 **경우에만** 위와 같이 설정해야 한다.
{{< note >}}
`--cgroup-driver` 플래그가 kubelet에 의해 사용 중단되었으므로, `/var/lib/kubelet/kubeadm-flags.env`
또는 `/etc/default/kubelet`(RPM에 대해서는 `/etc/sysconfig/kubelet`)에 있는 경우, 그것을 제거하고 대신 KubeletConfiguration을
사용한다(기본적으로 `/var/lib/kubelet/config.yaml` 에 저장됨).
{{< /note >}}
CRI-O 및 containerd와 같은 다른 컨테이너 런타임에 대한 cgroup 드라이버의
자동 감지에 대한 작업이 진행 중이다.
컨테이너 런타임과 kubelet은
["cgroup 드라이버"](/ko/docs/setup/production-environment/container-runtimes/)라는 속성을 갖고 있으며,
cgroup 드라이버는 리눅스 머신의 cgroup 관리 측면에 있어서 중요하다.
{{< warning >}}
컨테이너 런타임과 kubelet의 cgroup 드라이버를 일치시켜야 하며, 그렇지 않으면 kubelet 프로세스에 오류가 발생한다.
더 자세한 사항은 [cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
{{< /warning >}}
## 문제 해결
@@ -328,5 +312,4 @@ kubeadm에 문제가 있는 경우, [문제 해결 문서](/docs/setup/productio
## {{% heading "whatsnext" %}}
* [kubeadm을 사용하여 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md
-65
View File
@@ -1,65 +0,0 @@
---
reviewers:
title: 컨트롤 플레인을 자체 호스팅하기 위해 쿠버네티스 클러스터 구성하기
content_type: concept
weight: 100
---
<!-- overview -->
### 쿠버네티스 컨트롤 플레인 자체 호스팅하기 {#self-hosting}
kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
통해 kubelet에 구성된 [스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)
대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/ko/docs/concepts/workloads/controllers/daemonset/)
로 실행된다.
자체 호스팅된 클러스터를 만들려면 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
명령어를 확인한다.
<!-- body -->
#### 주의사항
{{< caution >}}
이 기능은 클러스터를 지원되지 않는 상태로 전환하여 더 이상 클러스터를 관리할 수 없게 만든다.
이것은 `kubeadm upgrade`를 포함한다.
{{< /caution >}}
1. 1.8 이후 버전에서 자체 호스팅은 몇 가지 중요한 한계가 있다.
특히 자체 호스팅된 클러스터는 수동 조정 없이는
_컨트롤 플레인 노드를 재부팅하고 나서 복구할 수 없다._
1. 기본적으로 자체 호스팅된 컨트롤 플레인 파드는
[`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
자격 증명에 의존한다. 초기 생성을 제외하고, 이러한 자격 증명은 kubeadm에 의해
관리되지 않는다.
1. 컨트롤 플레인의 자체 호스팅된 부분에는 스태틱 파드로 실행되는 etcd가
포함되지 않는다.
#### 프로세스
자체 호스팅 부트스트랩 프로세스는 [kubeadm 설계
문서](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)에 기록되어 있다.
요약하면 `kubeadm alpha selfhosting`은 다음과 같이 작동한다.
1. 부트스트랩 스태틱 컨트롤 플레인이 실행되고 정상 상태가 될 때까지 기다린다.
이것은 자체 호스팅이 없는 `kubeadm init` 프로세스와 동일하다.
1. 스태틱 컨트롤 플레인 파드 매니페스트를 사용하여 자체 호스팅된 컨트롤
플레인을 실행할 데몬셋 매니페스트 집합을 구성한다. 또한 필요한 경우
해당 매니페스트를 수정한다. 예를 들어, 시크릿을 위한 새로운 볼륨을
추가한다.
1. `kube-system` 네임스페이스에 데몬셋을 생성하고 결과 파드가 실행될 때까지
대기한다.
1. 일단 자체 호스팅된 파드가 동작하면 관련 스태틱 파드가 삭제되고
kubeadm은 계속해서 다음 구성 요소를 설치한다.
이것은 kubelet이 스태틱 파드를 멈추게 한다.
1. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은
리스닝 포트에 바인딩하여 활성화할 수 있다.
content/ko/docs/setup/production-environment/tools/kubespray.md
+1 -1
View File
@@ -68,7 +68,7 @@ Kubespray에서는 디플로이먼트의 많은 속성들을 사용자가 정의
* {{< glossary_tooltip term_id="cri-o" >}}
* 인증서 생성 방법
Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 막 시작한 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 처음 접하는 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
### (4/5) 클러스터 배포하기
content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+26 -20
View File
@@ -33,7 +33,7 @@ weight: 65
쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, 리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다.
| 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 |
| --- | --- | --- | --- |
| --- | --- | --- |
| *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 |
| *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 |
| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
@@ -230,23 +230,32 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
### 제한
#### 컨트롤 플레인
윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다.
#### 컴퓨트 {#컴퓨트-제한}
##### 리소스 관리 및 프로세스 격리
#### 자원 관리
리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. 컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. 반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) 오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입 될(assert) 수 없으므로 권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 매니져(Security Account Manager, SAM)가 분리되어 있으므로 컨테이너는 호스트의 ID를 가정할 수 없다.
##### 운영 체제 제한
#### 자원 예약
윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다.
##### 메모리 예약
윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다. 윈도우는 모든 사용자-모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일이 필수이다. 결과적으로 윈도우에서는 리눅스에서 발생할 수 있는 메모리 부족 상태에 도달하지 않으며, 프로세스는 메모리 부족 (out of memory, OOM) 종료를 겪는 대신 디스크로 페이징한다. 메모리가 오버프로비저닝되고 모든 물리 메모리가 고갈되면 페이징으로 인해 성능이 저하될 수 있다.
##### 기능 제한
kubelet 파라미터 `--kubelet-reserve` 를 사용하여 메모리 사용량을 합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 노드 (컨테이너 외부) 의 메모리 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다.
* TerminationGracePeriod: CRI-containerD 필요
{{< note >}}
워크로드를 배포할 때, 컨테이너에 리소스 제한을 걸어라 (제한만 설정하거나, 제한이 요청과 같아야 함). 이 또한 NodeAllocatable 에서 차감되며, 메모리가 꽉 찬 노드에 스케줄러가 파드를 할당하지 않도록 제한한다.
{{< /note >}}
오버프로비저닝을 방지하는 가장 좋은 방법은 윈도우, 도커, 그리고 쿠버네티스 프로세스를 위해 최소 2GB 이상의 시스템 예약 메모리로 kubelet을 설정하는 것이다.
##### CPU 예약
윈도우, 도커, 그리고 다른 쿠버네티스 호스트 프로세스가 이벤트에 잘 응답할 수 있도록, CPU의 일정 비율을 예약하는 것이 좋다. 이 값은 윈도우 노드에 있는 CPU 코어 수에 따라 조정해야 한다. 이 비율을 결정하려면, 각 노드의 최대 파드 밀도(density)를 관찰하고, 시스템 서비스의 CPU 사용량을 모니터링하여 워크로드 요구사항을 충족하는 값을 선택해야 한다.
kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을 합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 노드 (컨테이너 외부) 의 CPU 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다.
#### 기능 제한
* TerminationGracePeriod: 구현되지 않음
* 단일 파일 매핑: CRI-ContainerD로 구현 예정
* 종료 메시지: CRI-ContainerD로 구현 예정
* 특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음
@@ -254,15 +263,8 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
* 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다.
* 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 API 섹션 참조).
##### 메모리 예약 및 처리
윈도우에는 리눅스처럼 out-of-memory 프로세스 킬러가 없다. 윈도우는 항상 모든 사용자 모드 메모리 할당을 가상으로 처리하며 페이지 파일은 필수이다. 결과적으로 윈도우는 리눅스와 같은 방식으로 메모리 부족 상태에 도달하지 않고, 메모리 부족(OOM)으로 인한 종료 대신 페이지를 디스크로 처리한다. 메모리가 과도하게 프로비저닝되고 모든 실제 메모리가 고갈되면, 페이징으로 인해 성능이 저하될 수 있다.
2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다.
오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
플래그의 동작은 아래에 설명된 대로 다르게 동작한다.
#### 각 플래그의 리눅스와의 차이점
윈도우 노드에서의 kubelet 플래그의 동작은 아래에 설명된 대로 다르게 동작한다.
* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 Node Allocatable 업데이트
* `--enforce-node-allocable`을 사용한 축출(Eviction)은 구현되지 않았다.
@@ -362,7 +364,7 @@ SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의
* ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다. 윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다.
* 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 SID를 기반으로 하는 접근 제어 목록을 사용한다.
* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO 라이브러리는 일반적으로 두 가지를 모두 허용하고 작동하도록 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다.
* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO 라이브러리는 두 가지 파일 경로 분리자를 모두 허용한다. 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다.
* 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있다.
* UI 스레드는 WM_CLOSE를 포함하여 잘 정의된(well-defined) 메시지를 처리한다.
* 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다.
@@ -410,6 +412,10 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
* V1.PodSecurityContext.SupplementalGroups - 윈도우에서는 사용할 수 없는 GID를 제공한다.
* V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 일부이다. 윈도우에는 이에 상응하는 것이 없다.
#### 운영 체제 버전 제한
윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다.
## 도움 받기 및 트러블슈팅 {#troubleshooting}
쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 [섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 한다. SIG-Windows [로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의 지침을 따른다.
content/ko/docs/setup/release/notes.md
+1508 -1934
View File
File diff suppressed because it is too large Load Diff
content/ko/docs/tasks/access-application-cluster/access-cluster.md
+44 -44
View File
@@ -26,9 +26,9 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확
kubectl config view
```
많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서
kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는
[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 찾아볼 수 있다.
[여기](/ko/docs/reference/kubectl/cheatsheet/)에서
kubectl 사용 예시를 볼 수 있으며, 완전한 문서는
[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 확인할 수 있다.
## REST API에 직접 접근
@@ -44,12 +44,12 @@ REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는
- 앞으로는 클라이언트 측의 지능형 load balancing과 failover가 될 것이다.
- 직접적으로 http 클라이언트에 위치정보와 인증정보를 제공.
- 대안적인 접근 방식.
- proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 code들과 같이 동작한다.
- MITM로부터 보호를 위해 root 인증서를 당신의 브라우저로 import해야 한다.
- proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 코드와 같이 동작한다.
- MITM로부터 보호를 위해 root 인증서를 당신의 브라우저로 임포트해야 한다.
### kubectl proxy 사용
다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는
다음 커맨드는 kubectl을 리버스 프록시(reverse proxy)처럼 동작하는 모드를 실행한다. 이는
apiserver의 위치지정과 인증을 처리한다.
다음과 같이 실행한다.
@@ -205,7 +205,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
- 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나,
컨테이너 내부에서 백그라운드 프로세스로 실행한다.
이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여
이는 쿠버네티스 API를 파드의 localhost 인터페이스로 프록시하여
해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다.
- Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다.
이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
@@ -215,47 +215,47 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
## 클러스터에서 실행되는 서비스로 접근
이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
[노드들](/ko/docs/concepts/architecture/nodes/),
[파드들](/ko/docs/concepts/workloads/pods/),
[서비스들](/ko/docs/concepts/services-networking/service/)은
모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다.
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을
할 수 없을 것이다.
### 통신을 위한 방식들
클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다.
클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다.
- 공인 IP를 통해 서비스에 접근.
- 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다.
- 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나
인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
- 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며,
인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
해당 서비스는 자체적으로 인증을 수행하는가?
- 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다.
- 파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다.
- 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
접근할 필요는 없다.
- Proxy Verb를 사용하여 서비스, 노드, 파드에 접근.
- 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에
서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에
접근을 하려고 하거나 debugging을 하려면 이를 사용한다.
- 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다.
- 어떤 web 애플리케이션에서는 프록시가 문제를 일으킬 수 있다.
- HTTP/HTTPS에서만 동작한다.
- [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다.
- 클러스터 내 노드 또는 파드에서 접근.
- 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다.
- 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
해당 셸에서 다른 노드, 파드, 서비스에 연결한다.
- 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.
### 빌트인 서비스들의 발견
### 빌트인 서비스 검색
일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다.
`kubectl cluster-info` 커맨드로 이 서비스들의 리스트를 볼 수 있다.
일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다.
`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다.
```shell
kubectl cluster-info
@@ -280,20 +280,20 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi
#### 수작업으로 apiserver proxy URL을 구축
위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에
위에서 언급한 것처럼 서비스의 proxy URL을 검색하는 데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다.
당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다.
당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다.
기본적으로 API server는 http를 사용하여 서비스를 proxy한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다.
기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다.
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
URL의 네임 부분에 지원되는 양식은 다음과 같다.
* `<service_name>` - http를 사용하여 기본값 또는 이름이 없는 port로 proxy한다
* `<service_name>:<port_name>` - http를 사용하여 지정된 port로 proxy한다
* `https:<service_name>:` - https를 사용하여 기본값 또는 이름이 없는 port로 proxy한다(마지막 콜론:에 주의)
* `https:<service_name>:<port_name>` - https를 사용하여 지정된 port로 proxy한다
* `<service_name>` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다.
* `<service_name>:<port_name>` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
* `https:<service_name>:` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의)
* `https:<service_name>:<port_name>` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
##### 예제들
@@ -326,38 +326,38 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
## 요청 redirect
redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy를 사용하기를 바란다.
redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다.
## 다양한 Proxy들
## 다양한 프록시들
쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다.
쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 프록시들이 존재한다.
1. [kubectl proxy](#rest-api에-직접-접근):
- 사용자의 데스크탑이나 파드 내에서 실행한다
- localhost 주소에서 쿠버네티스 apiserver로 proxy한다
- proxy하는 클라이언트는 HTTP를 사용한다
- apiserver의 proxy는 HTTPS를 사용한다
- localhost 주소에서 쿠버네티스 apiserver로 프록시한다
- 프록시하는 클라이언트는 HTTP를 사용한다
- apiserver의 프록시는 HTTPS를 사용한다
- apiserver를 위치지정한다
- 인증 header들을 추가한다
1. [apiserver proxy](#빌트인-서비스들의-발견):
1. [apiserver proxy](#빌트인-서비스-검색):
- apiserver 내의 빌트인 bastion이다
- 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP들로 연결한다
- 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP로 연결한다
- apiserver process들 내에서 실행된다
- proxy하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http)
- 타겟으로의 proxy는 가용정보를 사용하는 proxy에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다
- 프록시하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http)
- 타겟으로의 프록시는 가용정보를 사용하는 프록시에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다
- 노드, 파드, 서비스에 접근하는 데 사용될 수 있다
- 서비스에 접근하는 데 사용되면 load balacing한다
1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips):
- 각 노드 상에서 실행된다
- UDP와 TCP를 proxy한다
- UDP와 TCP를 프록시한다
- HTTP를 인지하지 않는다
- load balancing을 제공한다
- 서비스에 접근하는 데만 사용된다
- 서비스에 접근하는 데에만 사용된다
1. apiserver(s) 전면의 Proxy/Load-balancer:
content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md
+109
View File
@@ -0,0 +1,109 @@
---
title: 클러스터 내 모든 컨테이너 이미지 목록 보기
content_type: task
weight: 100
---
<!-- overview -->
이 문서는 kubectl을 이용하여 클러스터 내 모든 컨테이너 이미지 목록을
조회하는 방법에 관해 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
이 작업에서는 kubectl을 사용하여 클러스터 내 모든 파드의 정보를
조회하고, 결과값의 서식을 변경하여 각 파드에 대한 컨테이너 이미지 목록으로
재구성할 것이다.
## 모든 네임스페이스의 모든 컨테이너 이미지 가져오기
- `kubectl get pods --all-namespaces` 를 사용하여 모든 네임스페이스의 모든 파드 정보를 가져온다.
- 컨테이너 이미지 이름만 출력하기 위해 `-o jsonpath={..image}` 를 사용한다.
이 명령어는 결과값으로 받은 json을 반복적으로 파싱하여,
`image` 필드만을 출력한다.
- jsonpath를 사용하는 방법에 대해 더 많은 정보를 얻고 싶다면
[Jsonpath 지원](/ko/docs/reference/kubectl/jsonpath/)을 확인한다.
- 다음의 표준 툴을 이용해서 결과값을 처리한다. `tr`, `sort`, `uniq`
- `tr` 을 사용하여 공백을 줄 바꾸기로 대체한다.
- `sort` 를 사용하여 결과값을 정렬한다.
- `uniq` 를 사용하여 이미지 개수를 합산한다.
```shell
kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c
```
이 커맨드는 결과값으로 나온 모든 아이템 중에 `image` 라고 명명된 필드를
모두 출력한다.
이와 다른 방법으로 파드 이미지 필드 값의 절대 경로를 사용할 수 있다.
이것은 필드명이 반복될 때에도
정확한 값을 출력하도록 보장한다.
예) 결과값 중에 많은 필드들이 `name`으로 명명되었을 경우,
```shell
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
```
이 jsonpath는 다음과 같이 해석할 수 있다.
- `.items[*]`: 각 결과값에 대하여
- `.spec`: spec 값을 가져온다.
- `.containers[*]`: 각 컨테이너에 대하여
- `.image`: image 값을 가져온다.
{{< note >}}
명령어로 하나의 파드를 가져올 때, 예를 들어 `kubectl get pod nginx` 라면,
jsonpath에서 `.items[*]` 부분은 생략해야 하는데, 이는 명령어가 아이템 목록이 아닌
단 한 개의 아이템(여기선 파드)으로 결과값을 주기 때문이다.
{{< /note >}}
## 각 파드의 컨테이너 이미지 보기
`range` 연산을 사용하여 명령어의 결과값에서 각각의 요소들을
반복하여 출력할 수 있다.
```shell
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort
```
## 파드 레이블로 필터링된 컨테이너 이미지 목록 보기
특정 레이블에 맞는 파드를 지정하기 위해서 -l 플래그를 사용한다. 아래의
명령어 결과값은 `app=nginx` 레이블에 일치하는 파드만 출력한다.
```shell
kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
```
## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기
특정 네임스페이스의 파드를 지정하려면, 네임스페이스 플래그를 사용한다.
아래의 명령어 결과값은 `kube-system` 네임스페이스에 있는 파드만 출력한다.
```shell
kubectl get pods --namespace kube-system -o jsonpath="{..image}"
```
## jsonpath 대신 Go 템플릿을 사용하여 컨테이너 이미지 목록 보기
jsonpath의 대안으로 Kubectl은 [Go 템플릿](https://golang.org/pkg/text/template/)을 지원한다.
다음과 같이 결과값의 서식을 지정할 수 있다.
```shell
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
```
## {{% heading "whatsnext" %}}
### 참조
* [Jsonpath](/ko/docs/reference/kubectl/jsonpath/) 참조
* [Go 템플릿](https://golang.org/pkg/text/template/) 참조
content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+45 -44
View File
@@ -8,7 +8,7 @@ min-kubernetes-server-version: v1.10
<!-- overview -->
이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서
실행중인 Redis 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스
실행중인 MongoDB 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스
디버깅에 유용할 수 있다.
@@ -19,25 +19,25 @@ min-kubernetes-server-version: v1.10
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* [redis-cli](http://redis.io/topics/rediscli)를 설치한다.
* [MongoDB Shell](https://www.mongodb.com/try/download/shell)을 설치한다.
<!-- steps -->
## Redis 디플로이먼트와 서비스 생성하기
## MongoDB 디플로이먼트와 서비스 생성하기
1. Redis를 실행하기 위해 디플로이먼트를 생성한다.
1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
```
성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
```
deployment.apps/redis-master created
deployment.apps/mongo created
```
파드 상태를 조회하여 파드가 준비되었는지 확인한다.
@@ -49,8 +49,8 @@ min-kubernetes-server-version: v1.10
출력은 파드가 생성되었다는 것을 보여준다.
```
NAME READY STATUS RESTARTS AGE
redis-master-765d459796-258hz 1/1 Running 0 50s
NAME READY STATUS RESTARTS AGE
mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s
```
디플로이먼트 상태를 조회한다.
@@ -62,64 +62,65 @@ min-kubernetes-server-version: v1.10
출력은 디플로이먼트가 생성되었다는 것을 보여준다.
```
NAME READY UP-TO-DATE AVAILABLE AGE
redis-master 1/1 1 1 55s
NAME READY UP-TO-DATE AVAILABLE AGE
mongo 1/1 1 1 2m21s
```
디플로이먼트는 자동으로 레플리카셋을 관리한다.
아래의 명령어를 사용하여 레플리카셋 상태를 조회한다.
```shell
kubectl get rs
kubectl get replicaset
```
출력은 레플리카셋이 생성되었다는 것을 보여준다.
```
NAME DESIRED CURRENT READY AGE
redis-master-765d459796 1 1 1 1m
NAME DESIRED CURRENT READY AGE
mongo-75f59d57f4 1 1 1 3m12s
```
2. Redis를 네트워크에 노출시키기 위해 서비스를 생성한다.
2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
```
성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.
```
service/redis-master created
service/mongo created
```
서비스가 생성되었는지 확인한다.
```shell
kubectl get svc | grep redis
kubectl get service mongo
```
출력은 서비스가 생성되었다는 것을 보여준다.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
redis-master ClusterIP 10.0.0.213 <none> 6379/TCP 27s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mongo ClusterIP 10.96.41.183 <none> 27017/TCP 11s
```
3. Redis 서버가 파드 안에서 실행되고 있고, 6379번 포트에서 수신하고 있는지 확인한다.
3. MongoDB 서버가 파드 안에서 실행되고 있고, 27017번 포트에서 수신하고 있는지 확인한다.
```shell
# redis-master-765d459796-258hz 를 파드 이름으로 변경한다.
kubectl get pod redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
# mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다.
kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
```
출력은 파드 내 Redis 포트 번호를 보여준다.
출력은 파드 내 MongoDB 포트 번호를 보여준다.
```
6379
27017
```
(이 TCP 포트는 Redis가 인터넷에 할당된 것이다).
(이는 인터넷 상의 MongoDB에 할당된 TCP 포트이다.)
## 파드의 포트를 로컬 포트로 포워딩하기
@@ -127,39 +128,39 @@ min-kubernetes-server-version: v1.10
```shell
# redis-master-765d459796-258hz 를 파드 이름으로 변경한다.
kubectl port-forward redis-master-765d459796-258hz 7000:6379
# mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다.
kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
```
이것은
```shell
kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
```
또는
```shell
kubectl port-forward deployment/redis-master 7000:6379
kubectl port-forward deployment/mongo 28015:27017
```
또는
```shell
kubectl port-forward rs/redis-master 7000:6379
kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
```
또는 다음과 같다.
```shell
kubectl port-forward service/redis-master 7000:redis
kubectl port-forward service/mongo 28015:27017
```
위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.
```
Forwarding from 127.0.0.1:7000 -> 6379
Forwarding from [::1]:7000 -> 6379
Forwarding from 127.0.0.1:28015 -> 27017
Forwarding from [::1]:28015 -> 27017
```
{{< note >}}
@@ -168,22 +169,22 @@ min-kubernetes-server-version: v1.10
{{< /note >}}
2. Redis 커맨드라인 인터페이스를 실행한다.
2. MongoDB 커맨드라인 인터페이스를 실행한다.
```shell
redis-cli -p 7000
mongosh --port 28015
```
3. Redis 커맨드라인 프롬프트에 `ping` 명령을 입력한다.
3. MongoDB 커맨드라인 프롬프트에 `ping` 명령을 입력한다.
```shell
ping
db.runCommand( { ping: 1 } )
```
성공적인 핑 요청을 반환한다.
```
PONG
{ ok: 1 }
```
### 선택적으로 _kubectl_ 이 로컬 포트를 선택하게 하기 {#let-kubectl-choose-local-port}
@@ -193,15 +194,15 @@ min-kubernetes-server-version: v1.10
부담을 줄일 수 있다.
```shell
kubectl port-forward deployment/redis-master :6379
kubectl port-forward deployment/mongo :27017
```
`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다. (낮은 포트 번호는
다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서) 출력은 다음과 같을 것이다.
`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다 (낮은 포트 번호는
다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서). 출력은 다음과 같을 것이다.
```
Forwarding from 127.0.0.1:62162 -> 6379
Forwarding from [::1]:62162 -> 6379
Forwarding from 127.0.0.1:63753 -> 27017
Forwarding from [::1]:63753 -> 27017
```
@@ -209,7 +210,7 @@ Forwarding from [::1]:62162 -> 6379
## 토의
로컬 7000 포트에 대한 연결은 Redis 서버가 실행중인 파드의 6379 포트로 포워딩된다.
로컬 28015 포트에 대한 연결은 MongoDB 서버가 실행중인 파드의 27017 포트로 포워딩된다.
이 연결로 로컬 워크스테이션에서 파드 안에서 실행 중인 데이터베이스를 디버깅하는데
사용할 수 있다.
content/ko/docs/tasks/administer-cluster/access-cluster-services.md
+12 -12
View File
@@ -19,22 +19,22 @@ content_type: task
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
도달할 수 없다.
고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서
접근할 수 없을 것이다.
### 연결하는 방법
클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다.
클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다.
- 퍼블릭 IP를 통해 서비스에 접근한다.
- `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서
접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와
- 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다.
- 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며,
인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다.
자체 인증을 수행하는가?
- 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면,
- 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며,
인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
해당 서비스는 자체적으로 인증을 수행하는가?
- 파드는 서비스 뒤에 위치시킨다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면,
파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다.
- 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접
접근할 필요는 없다.
@@ -54,8 +54,8 @@ content_type: task
### 빌트인 서비스 검색
일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을
사용하여 이들의 목록을 얻는다.
일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다.
`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다.
```shell
kubectl cluster-info
content/ko/docs/tasks/administer-cluster/coredns.md
+3 -24
View File
@@ -33,8 +33,8 @@ Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트
### Kubeadm을 사용해 기존 클러스터 업그레이드하기
쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여
`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은
`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의
`kubeadm` 을 사용할 때 CoreDNS로 전환할 수도 있다. 이 경우, `kubeadm` 은
`kube-dns` 컨피그맵(ConfigMap)을 기반으로 스텁 도메인(stub domain), 업스트림 네임 서버의
설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다.
@@ -44,8 +44,6 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
```
쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다.
업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에
설명된 지침 가이드를 참고하자.
1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**.
**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이
@@ -54,26 +52,7 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서,
기존의 Corefile이 유지된다.
### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기
{{< note >}}
쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며,
기본적으로 설치된다.
{{< /note >}}
{{< warning >}}
쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다.
{{< /warning >}}
1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS`
값을 `false` 로 변경해야 한다.
```
kubeadm init --feature-gates=CoreDNS=false
```
1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자.
쿠버네티스 버전 1.21에서, kubeadm 의 `kube-dns` 지원 기능이 삭제되었다.
## CoreDNS 업그레이드하기
content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
+2 -12
View File
@@ -31,7 +31,7 @@ DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io
CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
{{< note >}}
CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
CoreDNS 서비스는 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
{{< /note >}}
@@ -176,17 +176,14 @@ kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을
CoreDNS는 kube-dns 이상의 기능을 지원한다.
`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다.
마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다.
### 예시
kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다.
kube-dns에 대한 이 컨피그맵 예제는 stubDomains 및 upstreamNameservers를 지정한다.
```yaml
apiVersion: v1
data:
federations: |
{"foo" : "foo.feddomain.com"}
stubDomains: |
{"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
upstreamNameservers: |
@@ -196,13 +193,6 @@ kind: ConfigMap
CoreDNS에서는 동등한 설정으로 Corefile을 생성한다.
* federations 에 대응하는 설정:
```
federation cluster.local {
foo foo.feddomain.com
}
```
* stubDomains 에 대응하는 설정:
```yaml
abc.com:53 {
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+1 -1
View File
@@ -168,7 +168,7 @@ controllerManager:
### 인증서 서명 요청(CSR) 생성
쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다.
쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다.
## 외부 CA로 인증서 갱신
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+2 -2
View File
@@ -37,7 +37,7 @@ weight: 20
### 추가 정보
- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)이
- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](/docs/tasks/administer-cluster/safely-drain-node/)이
필요하다. 컨트롤 플레인 노드의 경우 CoreNDS 파드 또는 기타 중요한 워크로드를 실행할 수 있다.
- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
@@ -328,7 +328,7 @@ etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면,
- 컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다.
- 컴포넌트 구성에 버전 업그레이드가 필요한 경우 대체 구성을 생성하거나 사용자가 제공한 것으로 덮어 쓰기한다.
- 컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다.
- 새로운 `kube-dns` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다.
- 새로운 `CoreDNS` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다.
- API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다.
`kubeadm upgrade node` 는 추가 컨트롤 플레인 노드에서 다음을 수행한다.
content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
+1 -1
View File
@@ -18,7 +18,7 @@ weight: 10
**사전요구사항**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가하면 된다.
1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가한다.
**문법**
```shell
content/ko/docs/tasks/configure-pod-container/static-pod.md
+12 -16
View File
@@ -31,21 +31,14 @@ API 서버에서 제어될 수는 없다.
을 사용하는 것이 바람직하다.
{{< /note >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며,
노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다.
다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다.
<!-- steps -->
## 스태틱 파드 생성하기 {#static-pod-creation}
@@ -54,7 +47,9 @@ API 서버에서 제어될 수는 없다.
### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files}
매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다.
[kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)의 `staticPodPath: <the directory>` 필드를 사용하자.
명시한 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.
예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다.
@@ -90,17 +85,18 @@ Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단
3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다.
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
혹은 [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)에 `staticPodPath: <the directory>` 필드를 추가한다.
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
혹은 [kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)에
`staticPodPath: <the directory>` 필드를 추가한다.
4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
systemctl restart kubelet
```
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
systemctl restart kubelet
```
### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http}
content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+1 -1
View File
@@ -57,7 +57,7 @@ kubectl describe pods ${POD_NAME}
절대 스케줄 될 수 없다.
사용자는 `kubectl get nodes -o <format>` 명령으로 노드의
용량을 점검할 수 있다. 다음은 필요한 정보만을 추출하는 몇 가지
용량을 점검할 수 있다. 다음은 필요한 정보를 추출하는 몇 가지
명령의 예이다.
```shell
content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
+9 -7
View File
@@ -1,12 +1,16 @@
---
title: 크론잡(CronJob)으로 자동화된 작업 실행
min-kubernetes-server-version: v1.8
min-kubernetes-server-version: v1.21
content_type: task
weight: 10
---
<!-- overview -->
쿠버네티스 버전 1.21에서 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}이 GA (General Availability)로 승격되었다.
이전 버전의 쿠버네티스를 사용하고 있다면, 해당 쿠버네티스 버전의 문서를 참고하여 정확한 정보를 확인할 수 있다.
이전 버전의 쿠버네티스는 `batch/v1` 크론잡 API를 지원하지 않는다.
시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다.
이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
@@ -168,13 +172,11 @@ kubectl delete cronjob hello
이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다.
이 필드를 지정하지 않으면, 잡에 기한이 없다.
크론잡 컨트롤러는 크론 잡에 대해 얼마나 많은 스케줄이 누락되었는지를 계산한다. 누락된 스케줄이 100개를 초과 한다면, 크론 잡은 더이상 스케줄되지 않는다. `.spec.startingDeadlineSeconds` 이 설정되지 않았다면, 크론잡 컨트롤러는 `status.lastScheduleTime` 부터 지금까지 누락된 스케줄을 계산한다.
`.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면,
크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고,
시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다.
예를 들어, 하나의 크론 잡이 1분마다 실행되도록 설정되어 있고, 크론잡의 `status.lastScheduleTime` 은 새벽 5:00시이지만, 지금은 오전 7:00시라고 가정하자. 즉 120개의 스케줄이 누락되었다는 것이고, 그래서 크론 잡은 더이상 스케줄되지 않는다.
`.spec.startingDeadlineSeconds` 필드가 (null이 아닌) 값으로 설정되어 있다면, 크론잡 컨트롤러는 `.spec.startingDeadlineSeconds` 의 값으로부터 지금까지 얼마나 많은 잡이 누락되었는지를 계산한다.
예를 들어, `200` 으로 설정되었다면, 지난 200초 동안 누락된 스케줄이 몇 번 발생했는지 계산한다. 이 경우, 지난 200초 동안 누락된 스케줄이 100개가 넘으면, 크론 잡이 더이상 스케줄되지 않는다.
예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다.
### 동시성 정책
content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md
+4 -5
View File
@@ -2,7 +2,7 @@
title: 작업 대기열을 사용한 거친 병렬 처리
min-kubernetes-server-version: v1.8
content_type: task
weight: 30
weight: 20
---
@@ -19,7 +19,7 @@ weight: 30
1. **메시지 대기열 서비스를 시작한다.** 이 예에서는, RabbitMQ를 사용하지만, 다른 메시지 대기열을 이용해도
된다. 실제로 사용할 때는, 한 번 메시지 대기열 서비스를 구축하고서 이를 여러 잡을 위해 재사용하기도 한다.
1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다.
이 예제에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
이 예제에서, 메시지는 긴 계산을 수행할 정수다.
1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는
메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
@@ -141,13 +141,12 @@ root@temp-loe07:/#
```
마지막 커맨드에서, `amqp-consume` 도구는 대기열로부터 하나의 메시지를
받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터
받은 값을 바로 출력하고 있고, echo가 캐리지 리턴을 더해주어
받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터 받은 값을 출력하고, echo가 캐리지 리턴을 더해주어
출력 결과가 보여진다.
## 작업으로 대기열 채우기
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 간단히 문자열을
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 문자열을
출력하는 것이다.
실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다.
content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md
+2 -2
View File
@@ -2,7 +2,7 @@
title: 작업 대기열을 사용한 정밀 병렬 처리
content_type: task
min-kubernetes-server-version: v1.8
weight: 40
weight: 30
---
<!-- overview -->
@@ -21,7 +21,7 @@ weight: 40
않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는
Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다.
1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. 이
예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
예에서, 메시지는 긴 계산을 수행할 정수다.
1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는
메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
content/ko/docs/tasks/job/parallel-processing-expansion.md
+1 -1
View File
@@ -2,7 +2,7 @@
title: 확장을 사용한 병렬 처리
content_type: task
min-kubernetes-server-version: v1.8
weight: 20
weight: 50
---
<!-- overview -->
content/ko/docs/tasks/manage-daemon/update-daemon-set.md
+3 -3
View File
@@ -111,8 +111,8 @@ kubectl edit ds/fluentd-elasticsearch -n kube-system
##### 컨테이너 이미지만 업데이트
데몬셋 템플릿에서 컨테이너 이미지를 업데이트해야 하는
경우(예: `.spec.template.spec.containers[*].image`), `kubectl set image` 를 사용한다.
데몬셋 템플릿(예: `.spec.template.spec.containers[*].image`)에 의해 정의된 컨테이너 이미지만 업데이트하려면,
`kubectl set image` 를 사용한다.
```shell
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
@@ -168,7 +168,7 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
데몬셋 롤아웃이 진행되지 않는다.
이 문제를 해결하려면, 데몬셋 템플릿을 다시 업데이트한다. 이전의 비정상 롤아웃으로 인해
새로운 롤아웃이 차단되지 않는다.
새로운 롤아웃이 차단되지는 않는다.
#### 클럭 차이(skew)
content/ko/docs/tasks/manage-gpus/scheduling-gpus.md
+2 -2
View File
@@ -13,7 +13,7 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성
쿠버네티스는 AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 노드들에 걸쳐 관리하기 위한 **실험적인**
지원을 포함한다.
이 페이지는 다른 쿠버네티스 버전 간에 걸쳐 사용자가 GPU들을 소비할 수 있는 방법과
이 페이지는 여러 쿠버네티스 버전에서 사용자가 GPU를 활용할 수 있는 방법과
현재의 제약 사항을 설명한다.
@@ -37,7 +37,7 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성
`nvidia.com/gpu` 를 스케줄 가능한 리소스로써 노출시킨다.
사용자는 이 GPU들을 `cpu` 나 `memory` 를 요청하는 방식과 동일하게
`<vendor>.com/gpu` 를 요청함으로써 컨테이너를 통해 소비할 수 있다.
`<vendor>.com/gpu` 를 요청함으로써 컨테이너에서 활용할 수 있다.
그러나 GPU를 사용할 때는 리소스 요구 사항을 명시하는 방식에 약간의
제약이 있다.
content/ko/docs/tasks/run-application/delete-stateful-set.md
+2 -2
View File
@@ -37,8 +37,8 @@ kubectl delete statefulsets <statefulset-name>
kubectl delete service <service-name>
```
kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아지고, 스테이트풀셋에 포함된 모든 파드가 삭제된다.
파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 를 사용한다.
kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 옵션을 사용한다.
예시는 다음과 같다.
```shell
kubectl delete -f <file.yaml> --cascade=false
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -381,7 +381,7 @@ object:
외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다.
이 설치는 사용자 정의 메트릭과 유사하다.
외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다.
위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고,
위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 명시하고,
`Object` 대신에 `External` 메트릭 타입을 사용한다.
만일 여러 개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고,
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+2 -4
View File
@@ -23,9 +23,7 @@ Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(Dae
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
리소스는 컨트롤러의 동작을 결정한다.
컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 레플리케이션
컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
@@ -355,7 +353,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
## 구성가능한 스케일링 동작 지원
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
부터 `v2beta2` API는 HPA `behavior` 필드를 통해
스케일링 동작을 구성할 수 있다.
동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`
content/ko/docs/tasks/tools/_index.md
+3 -3
View File
@@ -17,9 +17,9 @@ no_list: true
`kubectl` 은 다양한 리눅스 플랫폼, macOS, 그리고 윈도우에 설치할 수 있다.
각각에 대한 설치 가이드는 다음과 같다.
- [리눅스에 `kubectl` 설치하기](install-kubectl-linux)
- [macOS에 `kubectl` 설치하기](install-kubectl-macos)
- [윈도우에 `kubectl` 설치하기](install-kubectl-windows)
- [리눅스에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-linux/)
- [macOS에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-macos/)
- [윈도우에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-windows/)
## kind
content/ko/docs/tutorials/_index.md
+2
View File
@@ -27,6 +27,8 @@ content_type: concept
## 구성
* [예제: Java 마이크로서비스 구성하기](/ko/docs/tutorials/configuration/configure-java-microservice/)
* [컨피그 맵을 사용해서 Redis 설정하기](/ko/docs/tutorials/configuration/configure-redis-using-configmap/)
## 상태 유지를 하지 않는(stateless) 애플리케이션
content/ko/docs/tutorials/clusters/apparmor.md
+1 -1
View File
@@ -322,7 +322,7 @@ Events:
23s 23s 1 {kubelet e2e-test-stclair-node-pool-t1f5} Warning AppArmor Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
```
파드 상태는 Failed이며 오류메시지는 `Pod Cannot enforce AppArmor: profile
파드 상태는 Pending이며, 오류 메시지는 `Pod Cannot enforce AppArmor: profile
"k8s-apparmor-example-allow-write" is not loaded`이다. 이벤트도 동일한 메시지로 기록되었다.
## 관리 {#administration}
content/ko/docs/tutorials/hello-minikube.md
+3 -3
View File
@@ -48,7 +48,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
{{< kat-button >}}
{{< note >}}
minikube를 로컬에 설치했다면 `minikube start`를 실행한다.
minikube를 로컬에 설치했다면 `minikube start`를 실행한다. `minikube dashboard` 명령을 실행하기 전에, 새 터미널을 열고, 그 터미널에서 `minikube dashboard` 명령을 실행한 후, 원래의 터미널로 돌아온다.
{{< /note >}}
2. 브라우저에서 쿠버네티스 대시보드를 열어보자.
@@ -154,7 +154,7 @@ minikube dashboard --url
`k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.
2. 방금 생성한 서비스 살펴보기
2. 생성한 서비스 살펴보기
```shell
kubectl get services
@@ -229,7 +229,7 @@ minikube 툴은 활성화하거나 비활성화할 수 있고 로컬 쿠버네
metrics-server was successfully enabled
```
3. 방금 생성한 파드와 서비스를 확인한다.
3. 생성한 파드와 서비스를 확인한다.
```shell
kubectl get pod,svc -n kube-system
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
+4 -3
View File
@@ -434,7 +434,7 @@ web-4 0/1 ContainerCreating 0 0s
web-4 1/1 Running 0 19s
```
스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다.
스테이트풀셋 컨트롤러는 레플리카 개수를 스케일링한다.
[스테이트풀셋 생성](#차례대로-파드-생성하기)으로 스테이트풀셋 컨트롤러는
각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에
이전 파드가 Running과 Ready 상태가 될 때까지
@@ -1067,9 +1067,10 @@ statefulset "web" deleted
### Parallel 파드 관리
`Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를
병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에
병렬로 시작하고 종료하는 것으로, 다른 파드를 시작/종료하기 전에
파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지
기다리지 않음을 뜻한다.
이 옵션은 스케일링 동작에만 영향을 미치며, 업데이트 동작에는 영향을 미치지 않는다.
{{< codenew file="application/web/web-parallel.yaml" >}}
@@ -1114,7 +1115,7 @@ web-1 1/1 Running 0 10s
스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘 다 동시에 시작했다.
두 번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을
스케일링 하자.
스케일링하자.
```shell
kubectl scale statefulset/web --replicas=4
content/ko/docs/tutorials/stateless-application/guestbook.md
+26 -21
View File
@@ -49,13 +49,15 @@ min-kubernetes-server-version: v1.14
1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다.
1. `mongo-deployment.yaml` 파일을 통해 MongoDB 디플로이먼트에 적용한다.
<!--
콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
-->
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
-->
1. 파드의 목록을 질의하여 MongoDB 파드가 실행 중인지 확인한다.
@@ -84,14 +86,15 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.ya
1. `mongo-service.yaml` 파일을 통해 MongoDB 서비스에 적용한다.
<!--
콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
-->
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
-->
1. 서비스의 목록을 질의하여 MongoDB 서비스가 실행 중인지 확인한다.
@@ -122,14 +125,15 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
1. `frontend-deployment.yaml` 파일을 통해 프론트엔드의 디플로이먼트에 적용한다.
<!--
콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
-->
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
-->
1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다.
@@ -160,14 +164,15 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
1. `frontend-service.yaml` 파일을 통해 프론트엔드 서비스에 적용시킨다.
<!--
콘텐츠에 대한 로컬 테스트는 파일의 상대 경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
-->
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
-->
1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다.
@@ -179,7 +184,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend ClusterIP 10.0.0.112 <none> 80/TCP 6s
frontend ClusterIP 10.0.0.112 <none> 80/TCP 6s
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4m
mongo ClusterIP 10.0.0.151 <none> 6379/TCP 2m
```
@@ -214,8 +219,8 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
결과는 아래와 같은 형태로 나타난다.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.51.242.136 109.197.92.229 80:32372/TCP 1m
```
1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다.
@@ -245,7 +250,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
frontend-3823415956-k22zn 1/1 Running 0 54m
frontend-3823415956-w9gbt 1/1 Running 0 54m
frontend-3823415956-x2pld 1/1 Running 0 5s
mongo-1068406935-3lswp 1/1 Running 0 56m
mongo-1068406935-3lswp 1/1 Running 0 56m
```
1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다.
@@ -266,7 +271,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
NAME READY STATUS RESTARTS AGE
frontend-3823415956-k22zn 1/1 Running 0 1h
frontend-3823415956-w9gbt 1/1 Running 0 1h
mongo-1068406935-3lswp 1/1 Running 0 1h
mongo-1068406935-3lswp 1/1 Running 0 1h
```
content/ko/examples/application/job/cronjob.yaml
+1 -1
View File
@@ -1,4 +1,4 @@
apiVersion: batch/v1beta1
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
content/ko/examples/application/zookeeper/zookeeper.yaml
+1 -1
View File
@@ -27,7 +27,7 @@ spec:
selector:
app: zk
---
apiVersion: policy/v1beta1
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
content/ko/examples/service/networking/namespaced-params.yaml
+12
View File
@@ -0,0 +1,12 @@
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: external-lb
spec:
controller: example.com/ingress-controller
parameters:
apiGroup: k8s.example.com
kind: IngressParameters
name: external-lb
namespace: external-configuration
scope: Namespace

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