Merge pull request #30642 from jihoon-seo/211126_Update_outdated_in_dev-1.22-ko.3_M9-M18

[ko] Update outdated files in dev-1.22-ko.3 (M9-M18)
pull/30682/head
Kubernetes Prow Robot 2021-11-26 06:16:52 -08:00 committed by GitHub
commit f3bfa4379f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
11 changed files with 336 additions and 84 deletions

View File

@ -77,6 +77,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
| @hourly | 매시 0분에 시작 | 0 * * * * |
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
`CRON_TZ=UTC 0 0 13 * 5`

View File

@ -1,4 +1,6 @@
---
title: 디플로이먼트
feature:
title: 자동화된 롤아웃과 롤백
@ -74,7 +76,6 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다.
@ -163,7 +164,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
1. `nginx:1.14.2` 이미지 대신 `nginx:1.16.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다.
```shell
kubectl deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
```
또는 다음의 명령어를 사용한다.
@ -181,7 +182,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image``nginx:1.14.2` 에서 `nginx:1.16.1` 로 변경한다.
```shell
kubectl edit deployment.v1.apps/nginx-deployment
kubectl edit deployment/nginx-deployment
```
다음과 유사하게 출력된다.
@ -364,7 +365,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
* 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.16.1` 이 아닌 `nginx:1.161` 로 입력해서 오타를 냈다고 가정한다.
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
이와 유사하게 출력된다.
@ -473,25 +474,25 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
1. 먼저 이 디플로이먼트의 수정 사항을 확인한다.
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment
kubectl rollout history deployment/nginx-deployment
```
이와 유사하게 출력된다.
```
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
`CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다.
* 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
* 디플로이먼트에 `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
* 수동으로 리소스 매니페스트 편집.
2. 각 수정 버전의 세부 정보를 보려면 다음을 실행한다.
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
kubectl rollout history deployment/nginx-deployment --revision=2
```
이와 유사하게 출력된다.
@ -499,7 +500,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Containers:
nginx:
Image: nginx:1.16.1
@ -516,7 +517,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
1. 이제 현재 롤아웃의 실행 취소 및 이전 수정 버전으로 롤백 하기로 결정했다.
```shell
kubectl rollout undo deployment.v1.apps/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
```
이와 유사하게 출력된다.
@ -526,7 +527,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
```shell
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
kubectl rollout undo deployment/nginx-deployment --to-revision=2
```
이와 유사하게 출력된다.
@ -560,7 +561,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
@ -603,7 +604,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
다음 명령어를 사용해서 디플로이먼트의 스케일을 할 수 있다.
```shell
kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
kubectl scale deployment/nginx-deployment --replicas=10
```
이와 유사하게 출력된다.
```
@ -615,7 +616,7 @@ deployment.apps/nginx-deployment scaled
실행할 최소 파드 및 최대 파드의 수를 선택할 수 있다.
```shell
kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
```
이와 유사하게 출력된다.
```
@ -644,7 +645,7 @@ deployment.apps/nginx-deployment scaled
* 클러스터 내부에서 확인할 수 없는 새 이미지로 업데이트 된다.
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
kubectl set image deployment/nginx-deployment nginx=nginx:sometag
```
이와 유사하게 출력된다.
@ -723,7 +724,7 @@ nginx-deployment-618515232 11 11 11 7m
* 다음 명령을 사용해서 일시 중지한다.
```shell
kubectl rollout pause deployment.v1.apps/nginx-deployment
kubectl rollout pause deployment/nginx-deployment
```
이와 유사하게 출력된다.
@ -733,7 +734,7 @@ nginx-deployment-618515232 11 11 11 7m
* 그런 다음 디플로이먼트의 이미지를 업데이트 한다.
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
이와 유사하게 출력된다.
@ -743,7 +744,7 @@ nginx-deployment-618515232 11 11 11 7m
* 새로운 롤아웃이 시작되지 않는다.
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment
kubectl rollout history deployment/nginx-deployment
```
이와 유사하게 출력된다.
@ -765,7 +766,7 @@ nginx-deployment-618515232 11 11 11 7m
* 예를 들어 사용할 리소스를 업데이트하는 것처럼 원하는 만큼 업데이트할 수 있다.
```shell
kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
```
이와 유사하게 출력된다.
@ -778,7 +779,7 @@ nginx-deployment-618515232 11 11 11 7m
* 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
```shell
kubectl rollout resume deployment.v1.apps/nginx-deployment
kubectl rollout resume deployment/nginx-deployment
```
이와 유사하게 출력된다.
@ -888,7 +889,7 @@ echo $?
10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
```shell
kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
```
이와 유사하게 출력된다.
```
@ -999,7 +1000,7 @@ Conditions:
`kubectl rollout status` 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다.
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
kubectl rollout status deployment/nginx-deployment
```
이와 유사하게 출력된다.
```

View File

@ -118,7 +118,6 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath`
반환된 목록의 각 파드의 이름을 출력하도록 하는 옵션이다.
## 레플리케이션 컨트롤러의 Spec 작성
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.

View File

@ -48,6 +48,21 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)
## 파드의 사용
다음은 `nginx:1.14.2` 이미지를 실행하는 컨테이너로 구성되는 파드의 예시이다.
{{< codenew file="pods/simple-pod.yaml" >}}
위에서 설명한 파드를 생성하려면, 다음 명령을 실행한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
```
일반적으로 파드는 직접 생성하지는 않으며, 대신 워크로드 리소스를 사용하여 생성한다.
[파드 작업](#파드-작업) 섹션에서 파드와 워크로드 리소스의 관계에 대한
더 많은 정보를 확인한다.
### Workload resources for managing pods
일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, {{< glossary_tooltip text="디플로이먼트(Deployment)"
term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}과 같은 워크로드 리소스를 사용하여 생성한다.
파드가 상태를 추적해야 한다면,
@ -97,7 +112,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는
별도의 "사이드카" 컨테이너가 있을 수 있다.
{{< figure src="/images/docs/pod.svg" alt="예제 파드 다이어그램" width="50%" >}}
{{< figure src="/images/docs/pod.svg" alt="파드 생성 다이어그램" class="diagram-medium" >}}
일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.

View File

@ -283,7 +283,7 @@ myapp-pod 1/1 Running 0 9m
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds`를 사용한다.
Active deadline은 초기화 컨테이너를 포함한다.
그러나 사용자가 애플리케이션을 잡(job)으로 배포한 경우 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
그러나 팀에서 애플리케이션을 잡(job)으로 배포한 경우에만 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
이미 정상적으로 동작하고 있는 파드도 `activeDeadlineSeconds`를 설정한 경우 종료(killed)될 수 있다.
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤

View File

@ -55,7 +55,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
생성되더라도, 관련된 그것(이 예에서는 볼륨)도 폐기되고
새로 생성된다.
{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
{{< figure src="/images/docs/pod.svg" title="Pod diagram" class="diagram-medium" >}}
*컨테이너 간의 공유 스토리지에 퍼시스턴트 볼륨을 사용하는 웹 서버와
파일 풀러(puller)가 포함된 다중 컨테이너 파드이다.*

View File

@ -234,43 +234,43 @@ graph BT
스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
{{<mermaid>}}
graph BT
subgraph "zoneC"
n5(Node5)
end
{{<mermaid>}}
graph BT
subgraph "zoneC"
n5(Node5)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
{{< /mermaid >}}
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
{{< /mermaid >}}
그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.
그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
스케줄러는 클러스터에 있는 모든 영역(zone) 또는 다른 토폴로지 도메인에 대한 사전 지식이 없다. 스케줄링은 클러스터의 기존 노드에서 결정된다. 노드 풀(또는 노드 그룹)이 0개의 노드로 스케일(scale)되고 사용자는 노드가 확장될 것으로 예상하는 경우, 자동 스케일되는 클러스터에서 문제가 발생할 수 있다. 이러한 토폴로지 도메인은 스케줄링에서 해당 도메인에 노드가 하나 이상 있을 때까지 고려되지 않을 것이기 때문이다.

View File

@ -29,6 +29,8 @@ card:
- 문서를 번역합니다.
- 쿠버네티스 릴리스 주기에 맞추어 문서 부분을 관리하고 발행합니다.
<!-- body -->
## 시작하기
@ -44,18 +46,98 @@ card:
문서에 참여하려면
1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다.
1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의
2. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의
[정적 사이트 생성기](https://gohugo.io)를 숙지합니다.
1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와
3. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와
[변경 검토](/ko/docs/contribute/review/reviewing-prs/)의
기본 프로세스를 이해하도록 합니다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart TB
subgraph third[PR 열기]
direction TB
U[ ] -.-
Q[컨텐츠 향상시키기] --- N[컨텐츠 생성하기]
N --- O[문서 번역하기]
O --- P[K8s 릴리스 사이클의 문서 파트<br>관리/퍼블리싱하기]
end
subgraph second[리뷰]
direction TB
T[ ] -.-
D[K8s/website<br>저장소 살펴보기] --- E[Hugo 정적 사이트<br>생성기 확인하기]
E --- F[기본 GitHub 명령어<br>이해하기]
F --- G[열려 있는 PR을 리뷰하기]
end
subgraph first[가입]
direction TB
S[ ] -.-
B[CNCF<br>Contributor<br>License Agreement<br>서명하기] --- C[sig-docs 슬랙 채널<br>가입하기]
C --- V[kubernetes-sig-docs<br>메일링 리스트 가입하기]
V --- M[주간<br>sig-docs 회의/<br>슬랙 미팅 참여하기]
end
A([fa:fa-user 신규<br>기여자]) --> first
A --> second
A --> third
A --> H[질문하세요!!!]
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
class S,T,U spacewhite
class first,second,third white
{{</ mermaid >}}
***그림 - 신규 기여자를 위한 시작 가이드***
위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입``리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!
일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다.
역할과 권한에 대한 자세한 내용은
[SIG Docs 참여](/ko/docs/contribute/participate/)를 봅니다.
## 첫 번째 기여
몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph second[첫 기여]
direction TB
S[ ] -.-
G[다른 K8s 멤버의 PR 리뷰하기] -->
A[K8s/website 이슈 리스트에서<br>good first issue 확인하기] --> B[PR을 여세요!!]
end
subgraph first[추천 준비 사항]
direction TB
T[ ] -.-
D[기여 개요 읽기] -->E[K8s 컨텐츠 및 <br>스타일 가이드 읽기]
E --> F[Hugo 페이지 컨텐츠 종류와<br>shortcode 숙지하기]
end
first ----> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,D,E,F,G grey
class S,T spacewhite
class first,second white
{{</ mermaid >}}
***그림 - 첫 기여를 위한 준비***
- [기여 개요](/ko/docs/contribute/new-content/)를 읽고
기여할 수 있는 다양한 방법에 대해 알아봅니다.
- [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을
@ -92,10 +174,13 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다.
자신을 소개하세요!
- 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는
[`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요.
- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다.
- 2주마다 열리는 [SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 공지되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다.
- 줌 화상 회의가 열리지 않은 경우, SIG Docs 비실시간 슬랙 스탠드업 회의에 참여하세요. 회의는 항상 `#sig-docs` 에 공지됩니다. 회의 공지 후 24시간까지 어느 스레드에나 기여할 수 있습니다.
## 다른 기여 방법들
- [쿠버네티스 커뮤니티 사이트](/ko/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다.
- [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다.
- [기여자 치트시트](https://www.kubernetes.dev/docs/contributor-cheatsheet/)를 읽고 쿠버네티스 기능 개발에 참여합니다.
- 쿠버네티스 기여자 사이트에서 [쿠버네티스 기여자](https://www.kubernetes.dev/)와 [추가적인 기여자 리소스](https://www.kubernetes.dev/resources/)에 대해 더 알아봅니다.
- [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다.

View File

@ -5,10 +5,48 @@ main_menu: true
weight: 20
---
<!-- overview -->
이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다.
이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가
있다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph second[시작하기 전에]
direction TB
S[ ] -.-
A[CNCF CLA 서명하기] --> B[Git 브랜치 선택하기]
B --> C[한 PR에는 한 언어에 대한 변경사항만]
C --> F[기여자 도구 확인하기]
end
subgraph first[기여 기초]
direction TB
T[ ] -.-
D[문서를 마크다운으로 작성하고<br>Hugo로 사이트 빌드] --- E[GitHub에 있는 소스]
E --- G['/content/../docs' 폴더에<br>각 언어 컨텐츠가 있음]
G --- H[Hugo 페이지 컨텐츠 종류와<br>shortcode 숙지하기]
end
first ----> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,C,D,E,F,G,H grey
class S,T spacewhite
class first,second white
{{</ mermaid >}}
***Figure - Contributing new content preparation***
The figure above depicts the information you should know
prior to submitting new content. The information details follow.
@ -16,28 +54,43 @@ weight: 20
## 기여에 대한 기본 사항
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고
[Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다.
쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다.
일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트를 이용하여
자동으로 생성된다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은
Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러
[사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다.
[사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여
콘텐츠 표시를 제어한다.
- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각
언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에
의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어,
한글 문서의 소스는 `/content/ko/docs/` 에 저장된다.
- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
- 여러 언어로 문서화에 기여하거나
새로운 번역을 시작하는 방법에 대한 자세한 내용은
[현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
## 시작하기 전에 {#before-you-begin}
### CNCF CLA 서명 {#sign-the-cla}
모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다.
모든 쿠버네티스 기여자는 **반드시**
[기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고
[기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다
.
CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다.
CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다.
제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며,
git 이름과 이메일은 CNCF CLA에 사용된 것과
일치해야 한다.
### 사용할 Git 브랜치를 선택한다
풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다.
풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를
미리 알아야 한다.
시나리오 | 브랜치
:---------|:------------
@ -45,20 +98,21 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동
기능 변경 릴리스의 콘텐츠 | `dev-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다.
다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다.
어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다.
{{< note >}}
풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
{{< note >}} 풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
제출자(제출자인 여러분만)가 이를 변경할 수 있다.
{{< /note >}}
### PR 당 언어
PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다.
PR 당 하나의 언어로 풀 리퀘스트를 제한한다.
여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우
각 언어마다 별도의 PR을 연다.
## 기여자를 위한 도구들
`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다.
`kubernetes/website` 리포지터리의
[문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools)
디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다.

View File

@ -28,7 +28,40 @@ card:
## GitHub을 사용하여 변경하기
git 워크플로에 익숙하지 않은 경우, 풀 리퀘스트를
여는 쉬운 방법이 있다.
여는 쉬운 방법이 있다. 아래의 그림은 각 단계를 보여주며, 상세사항은 그 아래에 나온다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
A([fa:fa-user 신규<br>기여자]) --- id1[(K8s/Website<br>GitHub)]
subgraph tasks[GitHub 상에서 변경하기]
direction TB
0[ ] -.-
1[1. '페이지 편집' 누르기] --> 2[2. GitHub 마크다운<br>편집기로 편집하기]
2 --> 3[3. 'Propose file change'에<br>추가 내용 기재하기]
end
subgraph tasks2[ ]
direction TB
4[4. 'Propose changes' 누르기] --> 5[5. 'Create pull request' 누르기] --> 6[6. 'Open a pull request'에<br>추가 내용 기재하기]
6 --> 7[7. 'Create pull request' 누르기]
end
id1 --> tasks --> tasks2
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,1,2,3,4,5,6,7 grey
class 0 spacewhite
class tasks,tasks2 white
class id1 k8s
{{</ mermaid >}}
***그림 - GitHub 상에서 PR을 여는 단계***
1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다.
페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다.
@ -89,6 +122,37 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다.
아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
1[K8s/website<br>저장소 포크하기] --> 2[로컬 클론 생성<br>및 upstream 설정]
subgraph changes[당신의 변경사항]
direction TB
S[ ] -.-
3[브랜치 생성<br>예: my_new_branch] --> 3a[텍스트 편집기로<br>변경사항 만들기] --> 4["Hugo (localhost:1313)<br>를 이용하거나<br>컨테이너 이미지를 빌드하여<br>변경사항을 로컬에서 미리보기"]
end
subgraph changes2[커밋 / 푸시]
direction TB
T[ ] -.-
5[변경사항 커밋하기] --> 6[커밋을<br>origin/my_new_branch<br>로 푸시하기]
end
2 --> changes --> changes2
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class 1,2,3,3a,4,5,6 grey
class S,T spacewhite
class changes,changes2 white
{{</ mermaid >}}
***그림 - 로컬 포크에서 변경 사항 작업하기***
### kubernetes/website 리포지터리 포크하기
1. [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
@ -230,7 +294,6 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
1. 로컬에서 이미지를 빌드한다.
```bash
make docker-image
# docker 사용(기본값)
make container-image
@ -243,7 +306,6 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다.
```bash
make docker-serve
# docker 사용(기본값)
make container-serve
@ -291,6 +353,34 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr}
아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph first[ ]
direction TB
1[1. K8s/website 저장소로 이동] --> 2[2. 'New Pull Request' 클릭]
2 --> 3[3. 'Compare across forks' 클릭]
3 --> 4[4. 'head repository' 드롭다운 메뉴에서<br>당신의 포크 선택]
end
subgraph second [ ]
direction TB
5[5. 'compare' 드롭다운 메뉴에서<br>당신의 브랜치 선택] --> 6[6. 'Create Pull Request' 클릭]
6 --> 7[7. PR 본문에 상세 설명 기재]
7 --> 8[8. 'Create pull request' 클릭]
end
first --> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
class 1,2,3,4,5,6,7,8 grey
class first,second white
{{</ mermaid >}}
***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계***
1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
2. **New Pull Request** 를 선택한다.
3. **compare across forks** 를 선택한다.
@ -305,7 +395,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
8. **Create pull request** 버튼을 선택한다.
축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다.
축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다.
PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
@ -416,7 +506,6 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
풀 리퀘스트에 더 이상 충돌이 표시되지 않는다.
### 커밋 스쿼시하기
{{< note >}}
@ -502,8 +591,6 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때
가능한 한 상세하게 템플릿의 내용을 작성한다.
## {{% heading "whatsnext" %}}

View File

@ -0,0 +1,10 @@
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80