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

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

Browse Source 
[ko] Update outdated files in dev-1.22-ko.3 (M9-M18)
This commit is contained in:
Kubernetes Prow Robot
2021-11-26 06:16:52 -08:00
committed by GitHub
parent b69f55a27b abc7aa0e8b
commit f3bfa4379f
11 changed files with 336 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+1
View File
@@ -77,6 +77,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
| @hourly | 매시 0분에 시작 | 0 * * * * |
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
`CRON_TZ=UTC 0 0 13 * 5`
content/ko/docs/concepts/workloads/controllers/deployment.md
+24 -23
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
```
이와 유사하게 출력된다.
```
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
-1
View File
@@ -118,7 +118,6 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은
반환된 목록의 각 파드의 이름을 출력하도록 하는 옵션이다.
## 레플리케이션 컨트롤러의 Spec 작성
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
content/ko/docs/concepts/workloads/pods/_index.md
+16 -1
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" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.
content/ko/docs/concepts/workloads/pods/init-containers.md
+1 -1
View File
@@ -283,7 +283,7 @@ myapp-pod 1/1 Running 0 9m
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds`를 사용한다.
Active deadline은 초기화 컨테이너를 포함한다.
그러나 사용자가 애플리케이션을 잡(job)으로 배포한 경우 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
그러나 팀에서 애플리케이션을 잡(job)으로 배포한 경우에만 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
이미 정상적으로 동작하고 있는 파드도 `activeDeadlineSeconds`를 설정한 경우 종료(killed)될 수 있다.
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
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)가 포함된 다중 컨테이너 파드이다.*
content/ko/docs/contribute/_index.md
+89 -4
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/)를 제출합니다.
content/ko/docs/contribute/new-content/_index.md
+69 -15
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)
디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다.
content/ko/docs/contribute/new-content/open-a-pr.md
+93 -6
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** 를 선택한다.
@@ -416,7 +506,6 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
풀 리퀘스트에 더 이상 충돌이 표시되지 않는다.
### 커밋 스쿼시하기
{{< note >}}
@@ -502,8 +591,6 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때
가능한 한 상세하게 템플릿의 내용을 작성한다.
## {{% heading "whatsnext" %}}
content/ko/examples/pods/simple-pod.yaml
+10
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