kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #36922 from Seo-yul/dev-1.25-ko.1-Outdated-M90-M126 

[ko] Update outdated files dev-1.25-ko.1 (M90-M126)
pull/37120/head
Kubernetes Prow Robot 2022-09-26 23:23:50 -07:00 committed by GitHub
parent 06c42c8e7b 7aef2a2e8d
commit 48d48fa038
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
35 changed files with 132 additions and 194 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
View File

@ -9,12 +9,9 @@ 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) 작업처럼 실행된다.
{{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용하여
{{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 시간 기반의 스케줄에 따라 실행할 수 있다.
이러한 자동화된 잡은 리눅스 또는 유닉스 시스템의 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
크론 잡은 백업을 수행하거나 이메일을 보내는 것과 같이 주기적이고 반복적인 작업들을 생성하는 데 유용하다.
크론 잡은 시스템 사용이 적은 시간에 잡을 스케줄하려는 경우처럼 특정 시간에 개별 작업을 스케줄할 수도 있다.
@ -25,15 +22,10 @@ weight: 10
제한 사항에 대한 자세한 내용은 [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## 크론잡(CronJob) 생성 {#creating-a-cron-job}
@ -96,8 +88,7 @@ NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 50s 75s
```
크론 잡 `hello` 가 지정된 시간에 성공적으로 잡을 스케줄했는지
`LAST SCHEDULE`에서 확인해야 한다.
크론 잡 `hello` 가 `LAST SCHEDULE` 열에 명시된 시간에 잡을 성공적으로 스케줄링한 것을 볼 수 있다.
현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다.
@ -135,19 +126,25 @@ kubectl delete cronjob hello
## 크론잡(CronJob) 명세 작성 {#writing-a-cron-job-spec}
다른 모든 쿠버네티스 오브젝트들과 마찬가지로, 크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다. Kubernetes 개체 작업과 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 대한 자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와
다른 모든 쿠버네티스 오브젝트들과 마찬가지로,
크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다.
쿠버네티스 오브젝트 및 그 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 다루기에 대한
자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와
[kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
크론잡(CronJob)의 각 매니페스트에는 [`.spec`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status) 섹션도 필요하다.
{{< note >}}
크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다.
이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다.
즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
{{< /note >}}
### 스케줄
`.spec.schedule` 은 `.spec` 의 필수 필드이다.
이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
이 필드는 `0 * * * *` 또는 `@hourly`와 같은 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아,
해당 잡이 생성 및 실행될 스케줄 시간으로 설정한다.
이 형식은 확장된 "Vixie cron" 스텝(step) 값도 포함한다. 이 내용은
[FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
@ -160,13 +157,15 @@ kubectl delete cronjob hello
> "2시간마다"라고 지정하고 싶으면, 간단히 `*/2` 를 사용하면 된다.
{{< note >}}
스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며,
주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
{{< /note >}}
### 잡 템플릿
`.spec.jobTemplate` 은 잡에 대한 템플릿이며, 이것은 필수 필드다.
이것은 중첩되고 `apiVersion` 이나 `kind` 가 없는 것을 제외하고 [잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
이것은 중첩되어(nested) 있고 `apiVersion` 이나 `kind` 가 없다는 것을 제외하면,
[잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
잡 `.spec` 을 작성하는 것에 대한 내용은 [잡 명세 작성하기](/ko/docs/concepts/workloads/controllers/job/#잡-사양-작성하기)를 참고한다.
### 시작 기한
@ -178,10 +177,11 @@ kubectl delete cronjob hello
이 필드를 지정하지 않으면, 잡에 기한이 없다.
`.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면,
크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고,
크론잡 컨트롤러는 예상 잡 생성 시각과 현재 시각의 차이를 측정하고,
시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다.
예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다.
예를 들어, `200` 으로 설정되었다면,
예상 잡 생성 시각으로부터 200초까지는 잡이 생성될 수 있다.
### 동시성 정책
@ -190,8 +190,10 @@ kubectl delete cronjob hello
명세는 다음의 동시성 정책 중 하나만 지정할 수 있다.
* `Allow`(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다.
* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다.
새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우,
크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다.
크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다.
@ -205,11 +207,13 @@ kubectl delete cronjob hello
{{< caution >}}
스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다.
[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, 누락된 잡들이 즉시 스케줄된다.
[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면,
누락된 잡들이 즉시 스케줄된다.
{{< /caution >}}
### 잡 히스토리 한도
`.spec.successfulJobsHistoryLimit` 와 `.spec.failedJobsHistoryLimit` 필드는 선택 사항이다.
이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다.
기본적으로, 각각 3과 1로 설정된다. 한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.
기본적으로, 각각 3과 1로 설정된다.
한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.

2
content/ko/docs/tasks/job/indexed-parallel-processing-static.md
View File

@ -19,7 +19,7 @@ weight: 30
파드 인덱스는 10진수 값을 문자열로 표현한 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}}
`batch.kubernetes.io/job-completion-index` 를 통해
사용할 수 있다. 컨테이너화된 태스크 프로세스가 이 인덱스 정보를 가져갈 수 있도록,
[downward API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
[다운워드(downward) API](/ko/docs/concepts/workloads/pods/downward-api/)
메커니즘을 사용하여 어노테이션의 값을 발행할 수 있다.
편의상, 컨트롤 플레인은 downward API를 자동 설정하여
`JOB_COMPLETION_INDEX` 환경변수에 인덱스를 노출할 수 있도록 한다.

2
content/ko/docs/tasks/manage-daemon/update-daemon-set.md
View File

@ -39,7 +39,7 @@ weight: 10
[`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(기본값은 0),
[`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(베타 기능, 기본값은 0)를
(기본값은 0)를
설정할 수도 있다.
### `RollingUpdate` 업데이트 전략으로 데몬셋 생성

6
content/ko/docs/tasks/manage-gpus/scheduling-gpus.md
View File

@ -6,8 +6,6 @@ title: GPU 스케줄링
description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다.
---
<!-- overview -->
{{< feature-state state="beta" for_k8s_version="v1.10" >}}
@ -65,7 +63,7 @@ spec:
containers:
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
image: "registry.k8s.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1 # GPU 1개 요청하기
@ -208,7 +206,7 @@ spec:
containers:
- name: cuda-vector-add
# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
image: "k8s.gcr.io/cuda-vector-add:v0.1"
image: "registry.k8s.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1

16
content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
View File

@ -86,20 +86,12 @@ metadata:
name: example-configmap-1-8mbdf7882g
```
env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. `=` 및 값을 생략하여 로컬 환경 변수로부터 값을 설정할 수도 있다.
{{< note >}}
로컬 환경 변수 채우기 기능은 꼭 필요한 경우에만 사용하는 것이 좋은데, 이는 패치를 할 수 있는 오버레이가 있는 편이 유지 관리에 더 유리하기 때문이다. 로컬 환경 변수 채우기 기능은 git SHA와 같이 그 값을 쉽게 예측할 수 없는 경우에 유용할 수 있다.
{{< /note >}}
다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
```shell
# .env 파일 생성
# BAZ 에는 로컬 환경 변수 $BAZ 의 값이 입력될 것이다
cat <<EOF >.env
FOO=Bar
BAZ
EOF
cat <<EOF >./kustomization.yaml
@ -113,7 +105,7 @@ EOF
생성된 컨피그맵은 다음 명령어로 검사할 수 있다.
```shell
BAZ=Qux kubectl kustomize ./
kubectl kustomize ./
```
생성된 컨피그맵은 다음과 같다.
@ -121,11 +113,10 @@ BAZ=Qux kubectl kustomize ./
```yaml
apiVersion: v1
data:
BAZ: Qux
FOO: Bar
kind: ConfigMap
metadata:
name: example-configmap-1-892ghb99c8
name: example-configmap-1-42cfbf598f
```
{{< note >}}
@ -1020,3 +1011,4 @@ deployment.apps "dev-my-nginx" deleted
* [Kubectl 문서](https://kubectl.docs.kubernetes.io)
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

24
content/ko/docs/tasks/network/validate-dual-stack.md
View File

@ -39,7 +39,7 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .
```
```
10.244.1.0/24
a00:100::/24
2001:db8::/64
```
단일 IPv4 블록과 단일 IPv6 블록이 할당되어야 한다.
@ -50,8 +50,8 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .
```
```
Hostname: k8s-linuxpool1-34450317-0
InternalIP: 10.240.0.5
InternalIP: 2001:1234:5678:9abc::5
InternalIP: 10.0.0.5
InternalIP: 2001:db8:10::5
```
### 파드 어드레싱 검증
@ -63,7 +63,7 @@ kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{prin
```
```
10.244.1.4
a00:100::4
2001:db8::4
```
`status.podIPs` fieldPath를 통한 다운워드(downward) API로 파드 IP들을 검증할 수도 있다. 다음 스니펫은 컨테이너 내 `MY_POD_IPS` 라는 환경 변수를 통해 파드 IP들을 어떻게 노출시킬 수 있는지 보여준다.
@ -82,7 +82,7 @@ a00:100::4
kubectl exec -it pod01 -- set | grep MY_POD_IPS
```
```
MY_POD_IPS=10.244.1.4,a00:100::4
MY_POD_IPS=10.244.1.4,2001:db8::4
```
파드의 IP 주소는 또한 컨테이너 내 `/etc/hosts` 에 적힐 것이다. 다음 커맨드는 이중 스택 파드의 `/etc/hosts` 에 cat을 실행시킨다. 출력 값을 통해 파드의 IPv4 및 IPv6 주소 모두 검증할 수 있다.
@ -99,7 +99,7 @@ fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.244.1.4 pod01
a00:100::4 pod01
2001:db8::4 pod01
```
## 서비스 검증
@ -161,9 +161,9 @@ metadata:
app.kubernetes.io/name: MyApp
name: my-service
spec:
clusterIP: fd00::5118
clusterIP: 2001:db8:fd00::5118
clusterIPs:
- fd00::5118
- 2001:db8:fd00::5118
ipFamilies:
- IPv6
ipFamilyPolicy: SingleStack
@ -210,7 +210,7 @@ Type: ClusterIP
IP Family Policy: PreferDualStack
IP Families: IPv4,IPv6
IP: 10.0.216.242
IPs: 10.0.216.242,fd00::af55
IPs: 10.0.216.242,2001:db8:fd00::af55
Port: <unset> 80/TCP
TargetPort: 9376/TCP
Endpoints: <none>
@ -233,6 +233,8 @@ kubectl get svc -l app.kubernetes.io/name: MyApp
서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service LoadBalancer 2001:db8:fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s
```

27
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
View File

@ -54,31 +54,8 @@ Metrics Server를 실행하는 방법을 보려면
## php-apache 서버 구동 및 노출
HorizontalPodAutoscaler 예시에서,
먼저 도커 허브의 `php-apache` 이미지를 베이스로 하는 커스텀 컨테이너 이미지를 만들어 시작점으로 삼을 것이다.
`Dockerfile`은 미리 준비되어 있으며, 내용은 다음과 같다.
```dockerfile
FROM php:5-apache
COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
아래의 코드는 CPU 과부하 연산을 수행하는 간단한 `index.php` 페이지를 정의하며,
이를 이용해 클러스터에 부하를 시뮬레이트한다.
```php
<?php
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
$x += sqrt($x);
}
echo "OK!";
?>
```
컨테이너 이미지를 만들었다면,
방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를
HorizontalPodAutoscaler 시연을 위해, `hpa-example` 이미지를 사용하여 컨테이너를 실행하는 디플로이먼트를 시작하고,
다음의 매니페스트를 사용하여 디플로이먼트를
{{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다.
{{< codenew file="application/php-apache.yaml" >}}

1
content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md
View File

@ -362,3 +362,4 @@ CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다
활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 `--cluster-signing-cert-file` 와
`--cluster-signing-key-file` 매개 변수를
컨트롤러 관리자에 전달한다.

8
content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
View File

@ -31,12 +31,12 @@ source /usr/share/bash-completion/bash_completion
이제 kubectl 자동 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다.
{{< tabs name="kubectl_bash_autocompletion" >}}
{{{< tab name="현재 사용자에만 적용" codelang="bash" >}}
{{< tab name="현재 사용자에만 적용" codelang="bash" >}}
echo 'source <(kubectl completion bash)' >>~/.bashrc
{{< /tab >}}
{{< tab name="시스템 전체에 적용" codelang="bash" >}}
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
{{< /tab >}}}
{{< /tab >}}
{{< /tabs >}}
kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.
@ -51,3 +51,7 @@ bash-completion은 `/etc/bash_completion.d` 에 있는 모든 자동 완성 스
{{< /note >}}
두 방법 모두 동일하다. 셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
셸의 현재 세션에서 bash 자동 완성을 활성화하려면 `exec bash`를 실행한다.
```bash
exec bash
```

5
content/ko/docs/tutorials/hello-minikube.md
View File

@ -94,7 +94,7 @@ minikube dashboard --url
파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다.
```shell
kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4
```
2. 디플로이먼트 보기
@ -155,7 +155,7 @@ minikube dashboard --url
`--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기
원한다는 뜻이다.
`k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
`registry.k8s.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.
2. 생성한 서비스 살펴보기
@ -303,3 +303,4 @@ minikube delete
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
* [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
* [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.

69
content/ko/docs/tutorials/security/apparmor.md
View File

@ -6,8 +6,6 @@ content_type: tutorial
weight: 10
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.4" state="beta" >}}
@ -108,7 +106,7 @@ AppArmor 지원이 포함된 Kubelet (>= v1.4)이면
노드 준비 조건 메시지를 확인하여(이후 릴리스에서는 삭제될 것 같지만) 검증할 수 있다.
```shell
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
kubectl get nodes -o=jsonpath='{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}{"\n"}{end}'
```
```
gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
@ -120,10 +118,10 @@ gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor e
<!-- lessoncontent -->
## 파드 보안 강화하기 {#securing-a-pod}
## 파드 보안 강화하기
{{< note >}}
AppArmor는 현재 베타라서 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면,
AppArmor는 현재 베타이며, 이 때문에 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면,
어노테이션은 최상위 종류의 필드로 대체될 것이다(자세한 내용은
[일반 사용자 버전으로 업그레이드 방법](#upgrade-path-to-general-availability) 참고)
{{< /note >}}
@ -166,7 +164,7 @@ kubectl exec <pod_name> cat /proc/1/attr/current
k8s-apparmor-example-deny-write (enforce)
```
## 예시 {#example}
## 예시
*이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.*
@ -327,9 +325,9 @@ Events:
파드 상태는 Pending이며, 오류 메시지는 `Pod Cannot enforce AppArmor: profile
"k8s-apparmor-example-allow-write" is not loaded`이다. 이벤트도 동일한 메시지로 기록되었다.
## 관리 {#administration}
## 관리
### 프로파일과 함께 노드 설정하기 {#setting-up-nodes-with-profiles}
### 프로파일과 함께 노드 설정하기
현재 쿠버네티스는 AppArmor 프로파일을 노드에 적재하기 위한 네이티브 메커니즘을 제공하지 않는다.
프로파일을 설정하는 여러 방법이 있다. 예를 들면 다음과 같다.
@ -348,36 +346,9 @@ Events:
[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여
파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.
### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
### AppArmor 비활성화
{{< note >}}
파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다.
더 자세한 내용은 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/) 문서를 참고한다.
{{< /note >}}
만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
```
--enable-admission-plugins=PodSecurityPolicy[,others...]
```
AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다.
```yaml
apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...]
```
기본 프로파일 이름 옵션은 프로파일을 지정하지 않았을 때에
컨테이너에 기본으로 적용하는 프로파일을 지정한다.
허용하는 프로파일 이름 옵션은 파드 컨테이너가 함께 실행하도록 허용되는 프로파일 목록을 지정한다.
두 옵션을 모두 사용하는 경우, 기본값은 반드시 필요하다.
프로파일은 컨테이너에서 같은 형식으로 지정된다. 전체 사양은 [API 참조](#api-reference)를 찾아본다.
### AppArmor 비활성화 {#disabling-apparmor}
클러스터에서 AppArmor 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다.
클러스터에서 AppArmor를 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다.
```
--feature-gates=AppArmor=false
@ -392,7 +363,7 @@ AppArmor가 general availability (GA) 상태로 바뀌면
AppArmor 기능을 비활성화하는 옵션은 제거될 것이다.
{{</note>}}
## 프로파일 제작 {#authoring-profiles}
## 프로파일 제작
AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까다로울 수 있다.
다행히 이 작업에 도움 되는 도구가 있다.
@ -409,9 +380,9 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
[AppArmor 실패](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)에서 제공한다.
## API 참조 {#api-reference}
## API 참조
### 파드 어노테이션 {#pod-annotation}
### 파드 어노테이션
컨테이너를 실행할 프로파일을 지정한다.
@ -420,7 +391,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
분리된 프로파일은 파드 내에 각 컨테이너로 지정할 수 있다.
- **값**: 아래 기술된 프로파일 참조
### 프로파일 참조 {#profile-reference}
### 프로파일 참조
- `runtime/default`: 기본 런타임 프로파일을 참조한다.
- (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
@ -434,22 +405,6 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
다른 어떤 프로파일 참조 형식도 유효하지 않다.
### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations}
아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기
* **키**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
* **값**: 프로파일 참조. 위에 기술됨.
파드 컨테이너에서 지정을 허용하는 프로파일 목록 지정하기
* **키**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
* **값**: 컴마로 구분된 참조 프로파일 목록(위에 기술함)
- 비록 이스케이프된 쉼표(%2C ',')도 프로파일 이름에서 유효한 문자이지만
여기에서 명시적으로 허용하지 않는다.
## {{% heading "whatsnext" %}}

6
content/ko/docs/tutorials/services/source-ip.md
View File

@ -48,7 +48,7 @@ min-kubernetes-server-version: v1.5
작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다.
```shell
kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4
kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.4
```
출력은 다음과 같다.
```
@ -323,10 +323,10 @@ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
```
`service.spec.healthCheckNodePort` 필드는 `/healthz`에서 헬스 체크를 제공하는
모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다.
모든 노드의 포트를 가리킨다. 이것을 테스트할 수 있다.
```shell
kubectl get pod -o wide -l run=source-ip-app
kubectl get pod -o wide -l app=source-ip-app
```
출력은 다음과 유사하다.
```

47
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
View File

@ -127,8 +127,9 @@ web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 18s
```
참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고)
및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자.
참고로 `web-1` 파드는 `web-0` 파드가
_Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고)
및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에는 시작되지 않음에 주의한다.
## 스테이트풀셋 안에 파드
@ -214,6 +215,8 @@ kubectl get pod -w -l app=nginx
```shell
kubectl delete pod -l app=nginx
```
```
pod "web-0" deleted
pod "web-1" deleted
```
@ -334,8 +337,9 @@ web-1
{{< note >}}
위에 curl 명령어로 **403 Forbidden** 아닌 응답을 보려면
다음을 실행해서 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다
([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함).
다음을 실행하여 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다
([hostPath 볼륨을 사용할 때의 버그](https://github.com/kubernetes/kubernetes/issues/2630)로
인함).
`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done`
@ -521,7 +525,8 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO
### 롤링 업데이트
`RollingUpdate` 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다.
`RollingUpdate` 업데이트 전략은 스테이트풀셋의 보장사항을 유지하면서
스테이트풀셋 내의 모든 파드를 역순으로 업데이트한다.
스테이트풀셋 `web`의 업데이트 전략을 `RollingUpdate`으로 패치하자.
@ -601,9 +606,9 @@ web-0 1/1 Running 0 10s
for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
```
```
k8s.gcr.io/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
registry.k8s.io/nginx-slim:0.8
registry.k8s.io/nginx-slim:0.8
registry.k8s.io/nginx-slim:0.8
```
@ -630,10 +635,10 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda
statefulset.apps/web patched
```
컨테이너의 이미지를 바꾸도록 스테이트풀셋을 또 패치하자.
컨테이너의 이미지를 바꾸도록 스테이트풀셋을 다시 패치한다.
```shell
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.7"}]'
```
```
statefulset.apps/web patched
@ -667,7 +672,7 @@ web-2 1/1 Running 0 18s
kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
```
```
k8s.gcr.io/nginx-slim:0.8
registry.k8s.io/nginx-slim:0.8
```
비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은
@ -708,7 +713,7 @@ web-2 1/1 Running 0 18s
kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
```
```
k8s.gcr.io/nginx-slim:0.7
registry.k8s.io/nginx-slim:0.7
```
@ -751,13 +756,14 @@ web-1 1/1 Running 0 18s
kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
```
```
k8s.gcr.io/nginx-slim:0.8
registry.k8s.io/nginx-slim:0.8
```
`web-1` 는 원래 환경설정으로 복원되었는데
이는 파드의 순번이 partition보다 작기 때문이다.
스테이트풀셋의 `.spec.template`이 갱신되면, 지정된 partition 이상의 순번을
가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나
스테이트풀셋의 `.spec.template`이 갱신되면,
지정된 partition 이상의 순번을 가진 모든 파드는 업데이트된다.
미만의 순번을 가진 파드라면 삭제되거나
종료되어 원래 환경설정으로 복원된다.
#### 단계적 롤아웃
@ -807,10 +813,9 @@ web-0 1/1 Running 0 3s
for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
```
```
k8s.gcr.io/nginx-slim:0.7
k8s.gcr.io/nginx-slim:0.7
k8s.gcr.io/nginx-slim:0.7
registry.k8s.io/nginx-slim:0.7
registry.k8s.io/nginx-slim:0.7
registry.k8s.io/nginx-slim:0.7
```
`partition`을 `0`으로 이동하여 스테이트풀셋에서 계속해서
@ -819,10 +824,12 @@ k8s.gcr.io/nginx-slim:0.7
### 삭제 시 동작
`OnDelete` 업데이트 전략은 예전 동작(1.6 이하)으로,
이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의
이 업데이트 전략을 선택하면,
스테이트풀셋 컨트롤러는 스테이트풀셋의
`.spec.template` 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다.
이 전략은 `.spec.template.updateStrategy.type`을 `OnDelete`로 설정하여 선택할 수 있다.
## 스테이트풀셋 삭제하기
스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다.

2
content/ko/examples/admin/konnectivity/konnectivity-server.yaml
View File

@ -8,7 +8,7 @@ spec:
hostNetwork: true
containers:
- name: konnectivity-server-container
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.16
image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.32
command: ["/proxy-server"]
args: [
"--logtostderr=true",

2
content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml
View File

@ -22,7 +22,7 @@ spec:
- name: varlog
mountPath: /var/log
- name: count-agent
image: k8s.gcr.io/fluentd-gcp:1.30
image: registry.k8s.io/fluentd-gcp:1.30
env:
- name: FLUENTD_ARGS
value: -c /etc/fluentd-config/fluentd.conf

2
content/ko/examples/admin/sched/pod1.yaml
View File

@ -7,4 +7,4 @@ metadata:
spec:
containers:
- name: pod-with-no-annotation-container
image: k8s.gcr.io/pause:2.0
image: registry.k8s.io/pause:2.0

2
content/ko/examples/admin/sched/pod2.yaml
View File

@ -8,4 +8,4 @@ spec:
schedulerName: default-scheduler
containers:
- name: pod-with-default-annotation-container
image: k8s.gcr.io/pause:2.0
image: registry.k8s.io/pause:2.0

2
content/ko/examples/admin/sched/pod3.yaml
View File

@ -8,4 +8,4 @@ spec:
schedulerName: my-scheduler
containers:
- name: pod-with-second-annotation-container
image: k8s.gcr.io/pause:2.0
image: registry.k8s.io/pause:2.0

5
content/ko/examples/application/php-apache.yaml
View File

@ -14,7 +14,7 @@ spec:
spec:
containers:
- name: php-apache
image: k8s.gcr.io/hpa-example
image: registry.k8s.io/hpa-example
ports:
- containerPort: 80
resources:
@ -22,9 +22,7 @@ spec:
cpu: 500m
requests:
cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
@ -36,4 +34,3 @@ spec:
- port: 80
selector:
run: php-apache

2
content/ko/examples/application/web/web-parallel.yaml
View File

@ -30,7 +30,7 @@ spec:
spec:
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
image: registry.k8s.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web

2
content/ko/examples/application/web/web.yaml
View File

@ -29,7 +29,7 @@ spec:
spec:
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
image: registry.k8s.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web

2
content/ko/examples/application/zookeeper/zookeeper.yaml
View File

@ -68,7 +68,7 @@ spec:
containers:
- name: kubernetes-zookeeper
imagePullPolicy: Always
image: "k8s.gcr.io/kubernetes-zookeeper:1.0-3.4.10"
image: "registry.k8s.io/kubernetes-zookeeper:1.0-3.4.10"
resources:
requests:
memory: "1Gi"

2
content/ko/examples/debug/node-problem-detector-configmap.yaml
View File

@ -23,7 +23,7 @@ spec:
hostNetwork: true
containers:
- name: node-problem-detector
image: k8s.gcr.io/node-problem-detector:v0.1
image: registry.k8s.io/node-problem-detector:v0.1
securityContext:
privileged: true
resources:

2
content/ko/examples/debug/node-problem-detector.yaml
View File

@ -23,7 +23,7 @@ spec:
hostNetwork: true
containers:
- name: node-problem-detector
image: k8s.gcr.io/node-problem-detector:v0.1
image: registry.k8s.io/node-problem-detector:v0.1
securityContext:
privileged: true
resources:

2
content/ko/examples/pods/inject/dapi-envars-container.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox:1.24
image: registry.k8s.io/busybox:1.24
command: [ "sh", "-c"]
args:
- while true; do

2
content/ko/examples/pods/inject/dapi-envars-pod.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
image: registry.k8s.io/busybox
command: [ "sh", "-c"]
args:
- while true; do

2
content/ko/examples/pods/inject/dapi-volume-resources.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: client-container
image: k8s.gcr.io/busybox:1.24
image: registry.k8s.io/busybox:1.24
command: ["sh", "-c"]
args:
- while true; do

2
content/ko/examples/pods/inject/dapi-volume.yaml
View File

@ -12,7 +12,7 @@ metadata:
spec:
containers:
- name: client-container
image: k8s.gcr.io/busybox
image: registry.k8s.io/busybox
command: ["sh", "-c"]
args:
- while true; do

2
content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml
View File

@ -29,4 +29,4 @@ spec:
- key-2
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0
image: registry.k8s.io/pause:2.0

2
content/ko/examples/pods/pod-with-node-affinity.yaml
View File

@ -23,4 +23,4 @@ spec:
- another-node-label-value
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0
image: registry.k8s.io/pause:2.0

2
content/ko/examples/pods/pod-with-pod-affinity.yaml
View File

@ -26,4 +26,4 @@ spec:
topologyKey: topology.kubernetes.io/zone
containers:
- name: with-pod-affinity
image: k8s.gcr.io/pause:2.0
image: registry.k8s.io/pause:2.0

2
content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml
View File

@ -23,4 +23,4 @@ spec:
- zoneC
containers:
- name: pause
image: k8s.gcr.io/pause:3.1
image: registry.k8s.io/pause:3.1

2
content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml
View File

@ -14,4 +14,4 @@ spec:
foo: bar
containers:
- name: pause
image: k8s.gcr.io/pause:3.1
image: registry.k8s.io/pause:3.1

2
content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml
View File

@ -20,4 +20,4 @@ spec:
foo: bar
containers:
- name: pause
image: k8s.gcr.io/pause:3.1
image: registry.k8s.io/pause:3.1

16
content/ko/releases/version-skew-policy.md
View File

@ -1,11 +1,11 @@
---
# reviewers:
# - sig-api-machinery
# - sig-architecture
# - sig-cli
# - sig-cluster-lifecycle
# - sig-node
# - sig-release
title: 버전 차이(skew) 정책
type: docs
description: >
@ -23,7 +23,7 @@ description: >
쿠버네티스 버전은 **x.y.z** 로 표현되는데, 여기서 **x** 는 메이저 버전, **y** 는 마이너 버전, **z** 는 패치 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/) 용어에 따른 것이다.
자세한 내용은 [쿠버네티스 릴리스 버전](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning)을 참조한다.
쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 [1년간의 패치 지원](/releases/patch-releases/#support-period)을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다.
패치 릴리스는 각 브랜치별로 [정기적인 주기](/releases/patch-releases/#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다.