[ko] Update outdated files in dev-1.24-ko.3 (M53-M62) (#35876)
* [ko] Update outdated files in dev-1.24-ko.3 (M53-M62) Signed-off-by: Nayeon Keum <rmaskdus0208@gmail.com> * Fix anchor in Ko managing-tls-in-a-cluster.md Signed-off-by: Nayeon Keum <rmaskdus0208@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com>pull/35926/head
Nayeon Keum
GitHub
parent
13f526d362
commit
80b9ccd641
|
|
@ -24,11 +24,11 @@ weight: 30
|
|||
|
||||
## 스테이트풀셋 디버깅하기
|
||||
|
||||
레이블이 `app=myapp`으로 지정된 스테이트풀셋 파드를 전부 나열하기 위해서는
|
||||
레이블이 `app.kubernetes.io/name=MyApp`으로 지정된 스테이트풀셋 파드를 전부 나열하기 위해서는
|
||||
다음의 명령을 사용할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=myapp
|
||||
kubectl get pods -l app.kubernetes.io/name=MyApp
|
||||
```
|
||||
|
||||
만약 오랜 시간동안 `Unknown`이나 `Terminating` 상태에 있는
|
||||
|
|
|
|||
|
|
@ -90,8 +90,12 @@ kubectl get pod multi-container-pod -o go-template='{{range .status.containerSta
|
|||
쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다.
|
||||
|
||||
종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다.
|
||||
kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는
|
||||
12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다.
|
||||
kubelet은 4096 바이트보다 긴 메시지를 자른다.
|
||||
|
||||
모든 컨테이너의 총 메시지 길이는 12KiB로 제한되며, 각 컨테이너에 균등하게 분할된다.
|
||||
예를 들어, 12개의 컨테이너(`initContainers` 또는 `containers`)가 있는 경우 각 컨테이너에는 1024 바이트의 사용 가능한 종료 메시지 공간이 있다.
|
||||
|
||||
기본 종료 메시지 경로는 `/dev/termination-log`이다.
|
||||
파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다.
|
||||
|
||||
다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록
|
||||
|
|
|
|||
|
|
@ -141,7 +141,7 @@ kubectl delete cronjob hello
|
|||
크론잡(CronJob)의 각 매니페스트에는 [`.spec`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status) 섹션도 필요하다.
|
||||
|
||||
{{< note >}}
|
||||
크론잡(CrontJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CrontJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
|
||||
크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
|
||||
{{< /note >}}
|
||||
|
||||
### 스케줄
|
||||
|
|
|
|||
|
|
@ -158,14 +158,14 @@ kubectl create --edit -f /tmp/srv.yaml
|
|||
```
|
||||
|
||||
1. `kubectl create service` 커맨드는 서비스에 대한 구성을 생성하고 이를 `/tmp/srv.yaml`에 저장한다.
|
||||
1. `kubectl create --edit` 커맨드는 오브젝트를 생성하기 전에 편집을 위해 구성파일을 열어준다.
|
||||
1. `kubectl create --edit` 커맨드는 오브젝트를 생성하기 전에 편집을 위해 구성 파일을 열어준다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [구성 파일을 이용한 명령형 쿠버네티스 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
* [구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
---
|
||||
title: 구성파일을 이용한 명령형 쿠버네티스 오브젝트 관리
|
||||
title: 구성 파일을 이용한 명령형 쿠버네티스 오브젝트 관리
|
||||
content_type: task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
쿠버네티스 오브젝트는 YAML 또는 JSON으로 작성된 오프젝트 구성파일과 함께 `kubectl`
|
||||
쿠버네티스 오브젝트는 YAML 또는 JSON으로 작성된 오프젝트 구성 파일과 함께 `kubectl`
|
||||
커맨드 라인 툴을 이용하여 생성, 업데이트 및 삭제할 수 있다.
|
||||
이 문서는 구성파일을 이용하여 어떻게 오브젝트를 정의하고 관리할 수 있는지에 대해 설명한다.
|
||||
이 문서는 구성 파일을 이용하여 어떻게 오브젝트를 정의하고 관리할 수 있는지에 대해 설명한다.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
@ -34,7 +34,7 @@ weight: 40
|
|||
|
||||
## 오브젝트 생성 방법
|
||||
|
||||
구성파일로부터 오브젝트를 생성하기 위해 `kubectl create -f`를 사용할 수 있다.
|
||||
구성 파일로부터 오브젝트를 생성하기 위해 `kubectl create -f`를 사용할 수 있다.
|
||||
보다 상세한 정보는 [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)를
|
||||
참조한다.
|
||||
|
||||
|
|
@ -44,22 +44,22 @@ weight: 40
|
|||
|
||||
{{< warning >}}
|
||||
`replace` 커맨드로 오브젝트를 업데이트 하게되면,
|
||||
구성파일에 정의되지 않은 스펙의 모든 부분이 삭제된다. 이는
|
||||
`externalIPs`필드가 구성파일로부터 독립적으로 관리되는
|
||||
구성 파일에 정의되지 않은 스펙의 모든 부분이 삭제된다. 이는
|
||||
`externalIPs`필드가 구성 파일로부터 독립적으로 관리되는
|
||||
`LoadBalancer`타입의 서비스와 같이, 클러스터 의해 부분적으로
|
||||
관리되는 스펙의 오브젝트와 함께 사용되어서는 안된다.
|
||||
독립적으로 관리되는 필드는 `replace`로 삭제되는 것을 방지하기 위해
|
||||
구성파일에 복사되어져야만 한다.
|
||||
구성 파일에 복사되어져야만 한다.
|
||||
{{< /warning >}}
|
||||
|
||||
구성파일에 따라 활성 오브젝트를 업데이트하기 위해 `kubectl replace -f`
|
||||
구성 파일에 따라 활성 오브젝트를 업데이트하기 위해 `kubectl replace -f`
|
||||
를 사용할 수 있다.
|
||||
|
||||
* `kubectl replace -f <파일명|url>`
|
||||
|
||||
## 오브젝트 삭제 방법
|
||||
|
||||
구성파일에 정의한 오브젝트를 삭제하기 위해 `kubectl delete -f`를
|
||||
구성 파일에 정의한 오브젝트를 삭제하기 위해 `kubectl delete -f`를
|
||||
사용할 수 있다.
|
||||
|
||||
* `kubectl delete -f <파일명|url>`
|
||||
|
|
@ -78,7 +78,7 @@ kubectl delete <type> -l <label>
|
|||
|
||||
## 오브젝트 확인 방법
|
||||
|
||||
구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
|
||||
구성 파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
|
||||
명령을 사용할 수 있다.
|
||||
|
||||
* `kubectl get -f <파일명|url> -o yaml`
|
||||
|
|
@ -89,16 +89,16 @@ kubectl delete <type> -l <label>
|
|||
## 제약사항
|
||||
|
||||
`create`, `replace`, 그리고 `delete` 명령은 각 오브젝트의 구성이
|
||||
그 구성파일 내에 완전하게 정의되고 기록되어질 경우 잘 동작한다.
|
||||
그러나 활성 오브젝트가 업데이트 되고, 구성파일 안에 병합되지 않으면,
|
||||
그 구성 파일 내에 완전하게 정의되고 기록되어질 경우 잘 동작한다.
|
||||
그러나 활성 오브젝트가 업데이트 되고, 구성 파일 안에 병합되지 않으면,
|
||||
업데이트 내용은 다음번 `replace`가 실행될 때 삭제될 것이다.
|
||||
이는 HorizontalPodAutoscaler와 같은 컨트롤러가
|
||||
활성 오브젝트를 직접적으로 업데이트하도록 할 경우 발생한다.
|
||||
여기 예시가 있다.
|
||||
|
||||
1. 구성파일로부터 오브젝트를 생성할 경우
|
||||
1. 구성 파일로부터 오브젝트를 생성할 경우
|
||||
1. 또 다른 소스가 일부 필드를 변경함으로써 오브젝트가 업데이트 되는 경우
|
||||
1. 구성파일로부터 오브젝트를 대체할 경우. 스텝 2에서의
|
||||
1. 구성 파일로부터 오브젝트를 대체할 경우. 스텝 2에서의
|
||||
다른 소스에 의해 이루어진 변경은 유실된다.
|
||||
|
||||
동일 오브젝트에 대해 여러 명의 작성자들로부터의 지원이 필요한 경우, 오브젝트를 관리하기 위해
|
||||
|
|
@ -106,9 +106,9 @@ kubectl delete <type> -l <label>
|
|||
|
||||
## 구성 저장 없이 URL로부터 오브젝트 생성과 편집하기
|
||||
|
||||
구성파일에 대한 URL을 가진다고 가정해보자.
|
||||
구성 파일에 대한 URL을 가진다고 가정해보자.
|
||||
`kubectl create --edit`을 사용하여 오브젝트가 생성되기 전에
|
||||
구성을 변경할 수 있다. 이는 독자가 수정할 수 있는 구성파일을
|
||||
구성을 변경할 수 있다. 이는 독자가 수정할 수 있는 구성 파일을
|
||||
가르키는 튜토리얼과 작업에 특히 유용하다.
|
||||
|
||||
```shell
|
||||
|
|
@ -120,13 +120,13 @@ kubectl create -f <url> --edit
|
|||
령형 커맨드에서 명령형 오브젝트 구성으로 전환하기 위해
|
||||
몇 가지 수동 단계를 포함한다.
|
||||
|
||||
1. 다음과 같이 활성 오브젝트를 로컬 오브젝트 구성파일로 내보낸다.
|
||||
1. 다음과 같이 활성 오브젝트를 로컬 오브젝트 구성 파일로 내보낸다.
|
||||
|
||||
```shell
|
||||
kubectl get <종류>/<이름> -o yaml > <종류>_<이름>.yaml
|
||||
```
|
||||
|
||||
1. 수동으로 오브젝트 구성파일에서 상태 필드를 제거한다.
|
||||
1. 수동으로 오브젝트 구성 파일에서 상태 필드를 제거한다.
|
||||
|
||||
1. 이후 오브젝트 관리를 위해, `replace`만 사용한다.
|
||||
|
||||
|
|
@ -161,6 +161,6 @@ template:
|
|||
|
||||
|
||||
* [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||
* [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ spec:
|
|||
protocol: TCP
|
||||
targetPort: 9376
|
||||
selector:
|
||||
app: MyApp
|
||||
app.kubernetes.io/name: MyApp
|
||||
sessionAffinity: None
|
||||
type: ClusterIP
|
||||
status:
|
||||
|
|
@ -158,7 +158,7 @@ apiVersion: v1
|
|||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
app.kubernetes.io/name: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: fd00::5118
|
||||
|
|
@ -172,7 +172,7 @@ spec:
|
|||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
app.kubernetes.io/name: MyApp
|
||||
sessionAffinity: None
|
||||
type: ClusterIP
|
||||
status:
|
||||
|
|
@ -187,7 +187,7 @@ status:
|
|||
`kubectl get svc` 명령어는 오직 `CLUSTER-IP` 필드에 주요 IP만 표시한다.
|
||||
|
||||
```shell
|
||||
kubectl get svc -l app=MyApp
|
||||
kubectl get svc -l app.kubernetes.io/name: MyApp
|
||||
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-service ClusterIP 10.0.216.242 <none> 80/TCP 5s
|
||||
|
|
@ -197,15 +197,15 @@ my-service ClusterIP 10.0.216.242 <none> 80/TCP 5s
|
|||
서비스가 `kubectl describe` 를 사용하여 IPv4 및 IPv6 주소 블록에서 클러스터 IP를 가져오는지 확인한다. 그런 다음 IP 및 포트를 통해 서비스에 대한 접속을 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl describe svc -l app=MyApp
|
||||
kubectl describe svc -l app.kubernetes.io/name: MyApp
|
||||
```
|
||||
|
||||
```
|
||||
Name: my-service
|
||||
Namespace: default
|
||||
Labels: app=MyApp
|
||||
Labels: app.kubernetes.io/name: MyApp
|
||||
Annotations: <none>
|
||||
Selector: app=MyApp
|
||||
Selector: app.kubernetes.io/name: MyApp
|
||||
Type: ClusterIP
|
||||
IP Family Policy: PreferDualStack
|
||||
IP Families: IPv4,IPv6
|
||||
|
|
@ -227,7 +227,7 @@ Events: <none>
|
|||
Check the Service:
|
||||
|
||||
```shell
|
||||
kubectl get svc -l app=MyApp
|
||||
kubectl get svc -l app.kubernetes.io/name: MyApp
|
||||
```
|
||||
|
||||
서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
|
||||
|
|
|
|||
|
|
@ -50,10 +50,10 @@ kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크
|
|||
kubectl delete -f <file.yaml> --cascade=orphan
|
||||
```
|
||||
|
||||
`kubectl delete` 에 `--cascade=orphan` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
|
||||
`kubectl delete` 에 `--cascade=orphan` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app.kubernetes.io/name=MyApp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl delete pods -l app=myapp
|
||||
kubectl delete pods -l app.kubernetes.io/name=MyApp
|
||||
```
|
||||
|
||||
### 퍼시스턴트볼륨(PersistentVolume)
|
||||
|
|
@ -70,13 +70,13 @@ PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
|
|||
|
||||
```shell
|
||||
grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
|
||||
kubectl delete statefulset -l app=myapp
|
||||
kubectl delete statefulset -l app.kubernetes.io/name=MyApp
|
||||
sleep $grace
|
||||
kubectl delete pvc -l app=myapp
|
||||
kubectl delete pvc -l app.kubernetes.io/name=MyApp
|
||||
|
||||
```
|
||||
|
||||
위의 예에서 파드에는 `app=myapp` 라는 레이블이 있다. 사용자에게 적절한 레이블로 대체하자.
|
||||
위의 예에서 파드에는 `app.kubernetes.io/name=MyApp` 라는 레이블이 있다. 사용자에게 적절한 레이블로 대체하자.
|
||||
|
||||
### 스테이트풀셋 파드의 강제 삭제
|
||||
|
||||
|
|
|
|||
|
|
@ -355,7 +355,7 @@ CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다
|
|||
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 레퍼런스 페이지를
|
||||
참조한다.
|
||||
|
||||
## 서명을 제공하도록 클러스터 구성하기 {#a-note-to-cluster-administrators}
|
||||
## 서명을 제공하도록 클러스터 구성하기
|
||||
|
||||
이 페이지에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스
|
||||
컨트롤러 관리자는 서명자의 기본 구현을 제공한다. 이를
|
||||
|
|
|
|||
|
|
@ -112,6 +112,10 @@ card:
|
|||
sudo apt-get update
|
||||
sudo apt-get install -y apt-transport-https ca-certificates curl
|
||||
```
|
||||
Debian 9(stretch) 또는 그 이전 버전을 사용하는 경우 `apt-transport-https`도 설치해야 한다.
|
||||
```shell
|
||||
sudo apt-get install -y apt-transport-https
|
||||
```
|
||||
|
||||
2. 구글 클라우드 공개 사이닝 키를 다운로드한다.
|
||||
|
||||
|
|
@ -134,7 +138,8 @@ card:
|
|||
|
||||
{{% /tab %}}
|
||||
|
||||
{{< tab name="레드햇 기반의 배포판" codelang="bash" >}}
|
||||
{{% tab name="레드햇 기반의 배포판" %}}
|
||||
```bash
|
||||
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
name=Kubernetes
|
||||
|
|
@ -144,7 +149,9 @@ gpgcheck=1
|
|||
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
|
||||
EOF
|
||||
sudo yum install -y kubectl
|
||||
{{< /tab >}}
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### 다른 패키지 관리 도구를 사용하여 설치 {#install-using-other-package-management}
|
||||
|
|
|
|||
Loading…
Reference in New Issue