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

Eighth Korean I10n work for release-1.13 (#13250)

Browse Source 
* ko-trans: Update outdated contents in dev-1.13-ko.8 branch partly (#12986)

* ko: Update outdated files in dev-1.13-ko.8 (#13000)

* ko: add tutorials/stateful-application/basic-stateful-set #12449  (#13073)

* Add missing word. (#13249)

* Fixed wrong word. (#13246)

* Translate concepts/cluster-administration/federation.md in Korean (#13159)

* Translate concepts/overview/object-management-kubectl/imperative-comm… (#13076)

Co-authored-by:    June Yi <june.yi@samsung.com>
Co-authored-by:    Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by:    Yoon <learder@gmail.com>
Co-authored-by:    Thomas Sungjin Kang <ujuc@ujuc.kr>
Co-authored-by:    Seokho <shsongist@gmail.com>
Co-authored-by:    zerobig <zerobig.kim@gmail.com>
This commit is contained in:
Claudia J.Kang
2019-03-19 23:20:30 +09:00
committed by Kubernetes Prow Robot
parent 2918bc57ac
commit 3bc455b2d9
26 changed files with 1708 additions and 67 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/master-node-communication.md
+1 -1
View File
@@ -68,7 +68,7 @@ apiserver는 kubelet의 제공 인증서를 확인하지 않는데,
루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다
그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
apiserver와 kubelet 사이에 [SSH 터널링](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)을
apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)을
사용한다.
마지막으로, kubelet API를 안전하게 하기 위해
content/ko/docs/concepts/cluster-administration/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
title: "클러스터 관리"
weight: 100
---
content/ko/docs/concepts/cluster-administration/federation.md
+187
View File
@@ -0,0 +1,187 @@
---
title: 페더레이션
content_template: templates/concept
weight: 80
---
{{% capture overview %}}
{{< include "federation-current-state.md" >}}
이 페이지는 여러 쿠버네티스 클러스터를 페더레이션을 통해서 관리해야 하는 이유와 방법을
설명한다.
{{% /capture %}}
{{% capture body %}}
## 페더레이션 이유
페더레이션을 사용하면 여러 클러스터를 쉽게 관리할 수 있다. 이는 2가지 주요 빌딩 블록을
제공함으로써 이루어진다.
* 클러스터 간의 리소스 동기화: 페더레이션은 여러 클러스터 내의 리소스를
동기화하는 능력을 제공한다. 예를 들면, 여러 클러스터에 동일한 디플로이먼트가 존재하는 것을 확인 할 수 있다.
* 클러스터 간의 디스커버리: 페더레이션은 모든 클러스터의 백엔드에 DNS 서버 및 로드벨런서를 자동 구성하는 능력을 제공한다. 예를 들면, 글로벌 VIP 또는 DNS 기록이 여러 클러스터의 백엔드 엑세스에 사용될 수 있는 것을 확인할 수 있다.
페더레이션이 가능하게 하는 다른 사례는 다음과 같다.
* 고가용성: 클러스터에 걸쳐서 부하를 분산하고 DNS
서버와 로드벨런서를 자동 구성함으로써, 페더레이션은 클러스터 장애의 영향을
최소화한다.
* 공급자 락인(lock-in) 회피: 애플리케이션의 클러스터 간 마이그레이션을 쉽게
만듦으로써, 페더레이션은 클러스터 공급자의 락인을 방지한다.
여러 클러스터를 운영하는 경우가 아니면 페더레이션은 필요 없다. 여러 클러스터가 필요한
이유의 일부는 다음과 같다.
* 짧은 지연시간: 클러스터가 여러 지역(region)에 있으면 사용자에게 가장 가까운 클러스터로부터
서비스함으로써 지연시간을 최소화한다.
* 결함 격리: 하나의 큰 클러스터보다 여러 개의 작은 클러스터를 사용하는 것이
결함을 격리하는데 더 효과적이다(예를 들면, 클라우드
공급자의 다른 가용 영역(availability zone)에 있는 여러 클러스터).
* 확장성: 단일 쿠버네티스 클러스터는 확장성에 한계가 있다(일반적인
사용자에게 해당되는 사항은 아니다. 더 자세한 내용:
[쿠버네티스 스케일링 및 성능 목표](https://git.k8s.io/community/sig-scalability/goals.md)).
* [하이브리드 클라우드](#하이브리드-클라우드-역량): 다른 클라우드 공급자나 온-프레미스 데이터 센터에 있는 여러 클러스터를
운영할 수 있다.
### 주의 사항
페더레이션에는 매력적인 사례가 많지만, 다소 주의 해야 할
사항도 있다.
* 네트워크 대역폭과 비용 증가: 페더레이션 컨트롤 플레인은 모든 클러스터를
감시하여 현재 상태가 예정된 상태와 같은지 확인한다. 이것은 클러스터들이
한 클라우드 제공자의 여러 다른 지역에서 또는 클라우드 제공자 간에 걸쳐 동작하는
경우 상당한 네트워크 비용을 초래할 수 있다.
* 클러스터 간 격리 수준 감소: 페더레이션 컨트롤 플레인에서의 오류는 모든 클러스터에
영향을 줄 수 있다. 이것은 페더레이션 컨트롤 플레인의 논리를 최소한으로
유지함으로써 완화된다. 페더레이션은 가능한 경우 언제라도
쿠버네티스 클러스터에 컨트롤 플레인을 위임한다. 페더레이션은 안전성을 제공하고
여러 클러스터의 중단을 방지할 수 있도록 민감하게 설계 및 구현되었다.
* 성숙도: 페더레이션 프로젝트는 상대적으로 신규 프로젝트이고 성숙도가 높지 않다.
모든 리소스가 이용 가능한 상태는 아니며 많은 리소스가 아직 알파 상태이다. [이슈
88](https://github.com/kubernetes/federation/issues/88)은 팀이 해결
중에 있는 시스템의 알려진 이슈를 열거하고 있다.
### 하이브리드 클라우드 역량
쿠버네티스 클러스터의 페더레이션은 다른 클라우드 제공자(예를 들어, Google 클라우드, AWS),
그리고 온-프레미스(예를 들어, OpenStack)에서 동작 중인 클러스터를 포함할 수
있다. [Kubefed](https://kubernetes.io/docs/tasks/federation/set-up-cluster-federation-kubefed/)는 연합된 클러스터 배치에 권장되는 방법이다.
그 후에, [API 리소스](#api-리소스)는 서로 다른 클러스터와 클라우드
제공자에 걸쳐 확장될 수 있다.
## 페더레이션 설치
여러 클러스터의 페더레이션 구성을 위해서는, 페더레이션 컨트롤 플레인을 우선적으로
설치해야 한다.
페더레이션 컨트롤 플레인의 설치를 위해서는 [설치 가이드](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)
를 따른다.
## API 리소스
컨트롤 플레인이 설치되고 나면, 페더레이션 API 리소스 생성을 시작할 수
있다.
다음의 가이드는 일부 리소스에 대해서 자세히 설명한다.
* [클러스터](/docs/tasks/administer-federation/cluster/)
* [컨피그 맵](/docs/tasks/administer-federation/configmap/)
* [데몬 셋](/docs/tasks/administer-federation/daemonset/)
* [디플로이먼트](/docs/tasks/administer-federation/deployment/)
* [이벤트](/docs/tasks/administer-federation/events/)
* [Hpa](/docs/tasks/administer-federation/hpa/)
* [인그레스](/docs/tasks/administer-federation/ingress/)
* [잡](/docs/tasks/administer-federation/job/)
* [네임스페이스](/docs/tasks/administer-federation/namespaces/)
* [레플리카 셋](/docs/tasks/administer-federation/replicaset/)
* [시크릿](/docs/tasks/administer-federation/secret/)
* [서비스](/docs/concepts/cluster-administration/federation-service-discovery/)
[API 참조 문서](/docs/reference/federation/)는 페더레이션
apiserver가 지원하는 모든 리소스를 열거한다.
## 삭제 캐스케이딩(cascading)
쿠버네티스 버전 1.6은 연합된 리소스에 대한 삭제 캐스케이딩을
지원한다. 삭제 케스케이딩이 적용된 경우, 페더레이션 컨트롤 플레인에서
리소스를 삭제하면, 모든 클러스터에서 상응하는 리소스가 삭제된다.
REST API 사용하는 경우 삭제 캐스케이딩이 기본으로 활성화되지 않는다. 그것을
활성화하려면, REST API를 사용하여 페더레이션 컨트롤 플레인에서 리소스를 삭제할 때
`DeleteOptions.orphanDependents=false` 옵션을 설정한다. `kubectl
delete`를 사용하면
삭제 캐스케이딩이 기본으로 활성화된다. `kubectl
delete --cascade=false`를 실행하여 비활성화할 수 있다.
참고: 쿠버네티스 버전 1.5는 페더레이션 리소스의 부분 집합에 대한 삭제
캐스케이딩을 지원하였다.
## 단일 클러스터의 범위
Google Compute Engine 또는 Amazon Web Services와 같은 IaaS 제공자에서는, VM이
[영역(zone)](https://cloud.google.com/compute/docs/zones) 또는 [가용 영역(availability
zone)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)에 존재한다.
다음과 같은 이유로, 쿠버네티스 클러스터의 모든 VM을 동일한 가용 영역에 두는 것을 추천한다.
- 단일 글로벌 쿠버네티스 클러스터에 비해서, 장애에 대한 단일-포인트가 더 적다.
- 여러 가용 영역에 걸친 클러스터에 비해서, 단일-영역 클러스터의 가용성 속성에 대한 추론이
더 쉽다.
- 쿠버네티스 개발자가 시스템을 디자인할 때(예를 들어, 지연 시간, 대역폭, 연관된 장애를
고려할 때) 모든 기계가 단일 데이터 센터에 있거나 밀접하게 연결되어 있다고 가정하고 있다.
가용 영역당 더 많은 VM이 포함되는 적은 수의 클러스터 실행을 추천한다. 다만, 여러 가용 영역 마다 여러 클러스터의 실행도 가능하다.
가용 영역당 더 적은 수의 클러스터가 선호되는 이유는 다음과 같다.
- 한 클러스터에 많은 노드가 있는 일부의 경우 파드의 빈 패킹(bin packing)이 향상됨(리소스 단편화 감소).
- 운영 오버헤드 감소(운영 툴과 프로세스의 성숙도에 의해 해당 장점은 반감되는 측면이 있음).
- apiserver VMs와 같이, 클러스터당 비용이 고정된 리소스의 비용을 감소(그러나 중간 규모 부터 큰 규모에 이르는 클러스터의
전체 클러스터 비용에 비하면 상대적으로 적은 비용).
여러 클러스터가 필요한 이유는 다음을 포함한다.
- 다른 업무의 계층으로부터 특정 계층의 격리가 요구되는 엄격한 보안 정책(다만, 아래의 클러스터 분할하기 정보를 확인하기
바람).
- 새로운 쿠버네티스 릴리스 또는 다른 클러스터 소프트웨어를 카나리아(canary) 방식으로 릴리스하기 위해서 클러스터를 테스트.
## 적절한 클러스터 수 선택하기
쿠버네티스 클러스터의 수를 선택하는 것은 상대적으로 고정적인 선택이며, 가끔식만 재고된다.
대조적으로, 클러스터의 노드 수와 서비스 내의 파드 수는 부하와 규모 증가에 따라
빈번하게 변경될 수 있다.
클러스터의 수를 선택하기 위해서, 첫 번째로, 쿠버네티스에서 동작할 서비스의 모든 최종 사용자에게 적절한 지연 시간을 제공할 수 있는 지역들을 선택할
필요가 있다(만약 콘텐츠 전송 네트워크를 사용한다면, CDN-호스트된 콘텐츠의 지연 시간 요구사항
고려할 필요가 없음). 법적인 이슈 또한 이것에 영향을 줄 수 있다. 예를 들면, 어떤 글로벌 고객 기반의 회사는 US, AP, SA 지역 등 특정 지역에서 클러스터를 운영하도록 결정할 수도 있다.
지역의 수를 `R`이라 부르자.
두 번째로, 여전히 사용 가능한 상태에서, 얼마나 많은 클러스터가 동시에 사용할 수 없는 상태가 될 수 있는지 결정한다.
사용하지 않는 상태가 될 수 있는 수를 `U`라고 하자. 만약이 값에 확신이 없다면, 1이 괜찮은 선택이다.
클러스터 장애 상황에서 어느 지역으로든지 직접적인 트래픽에 대한 로드밸런싱이 허용된다면, `R`
또는 적어도 `U + 1` 이상의 클러스터가 있으면 된다. 만약 그렇지 않다면(예를 들어, 클러스터 장애 상황에서 모든
사용자에 대한 낮은 지연 시간을 유지하고 싶다면), `R * (U + 1)`(각 `R` 지역 내에 `U + 1`)
클러스터가 필요하다. 어느 경우든지, 각 클러스터는 다른 영역에 배치하도록 노력하는 것이 좋다.
마지막으로, 클러스터 중 어느 클러스터라도 쿠버네티스 클러스터에서 추천되는 최대 노드 수 보다 더 많은 노드가 필요하다면,
더 많은 클러스터가 필요할 것이다. 쿠버네티스 v1.3은 클러스터를 최대 1000노드까지 지원한다. 쿠버네티스 v1.8은
클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/cluster-large/)에서 확인 가능하다.
{{% /capture %}}
{{% capture whatsnext %}}
* [페더레이션
제안](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)에 대해 더 학습하기.
* 클러스터 페더레이션 [설치 가이드](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 보기.
* [Kubecon2016 페더레이션 발표](https://www.youtube.com/watch?v=pq9lbkmxpS8) 보기
* [Kubecon2017 유럽 페더레이션 업데이트 내용](https://www.youtube.com/watch?v=kwOvOLnFYck) 보기
* [Kubecon2018 유럽 sig-multicluster 업데이트 내용](https://www.youtube.com/watch?v=vGZo5DaThQU) 보기
* [Kubecon2018 유럽 Federation-v2 프로토타입 발표](https://youtu.be/q27rbaX5Jis?t=7m20s) 보기
* [Federation-v2 사용자 가이드](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) 보기
{{% /capture %}}
content/ko/docs/concepts/containers/images.md
+11 -34
View File
@@ -279,43 +279,17 @@ kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGIS
secret/myregistrykey created.
```
만약 다중 레지스트리에 접근이 필요하다면, 각 레지스트리에 대한 하나의 시크릿을 생성할 수 있다.
Kubelet은 파드를 위한 이미지를 풀링할 때 `imagePullSecrets`를 단일의 가상 `.docker/config.json`
에 병합할 것이다.
만약 Docer 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고,
자격 증명 파일을 쿠버네티스 시크릿으로 가져올 수 있다.
[기존 Docker 자격 증명으로 시크릿 생성](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다.
`kubectl create secret docker-registry`는
하나의 개인 레지스트리에서만 작동하는 시크릿을 생성하기 때문에,
여러 개인 컨테이너 레지스트리를 사용하는 경우 특히 유용하다.
{{< note >}}
파드는 이미지 풀 시크릿을 자신의 네임스페이스에서만 참조할 수 있다.
따라서 이 과정은 네임스페이스 당 한 번만 수행될 필요가 있다.
##### kubectl create secrets 우회
어떤 이유에서 단일 `.docker/config.json`에 여러 항목이 필요하거나
위의 커맨드를 통해서는 주어지지 않는 제어가 필요한 경우, [json 또는 yaml로
시크릿 생성](/docs/user-guide/secrets/#creating-a-secret-manually)을 수행할 수 있다.
다음 사항을 준수해야 한다.
- `.dockerconfigjson`에 해당 데이터 항목의 이름을 설정
- Docker 파일을 base64로 인코딩하여 해당 문자열을 붙여넣을 때,
`data[".dockerconfigjson"]` 필드의 값으로써 깨짐 방지
- `kubernetes.io/dockerconfigjson`에 `type`을 설정
예:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: myregistrykey
namespace: awesomeapps
data:
.dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson
```
`error: no objects passed to create`라는 에러 메시지가 나오면, 그것은 base64 인코딩된 문자열이 유효하지 않다는 것을 뜻한다.
`Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`와 유사한 에러 메시지가 나오면, 그것은
base64 인코딩 된 데이터가 성공적으로 디코딩되었지만, `.docker/config.json` 파일로는 파싱될 수 없었음을 의미한다.
{{< /note >}}
#### 파드의 imagePullSecrets 참조
@@ -374,3 +348,6 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
- 테넌트는 해당 시크릿을 각 네임스페이스의 imagePullSecrets에 추가한다.
{{% /capture %}}
다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다.
content/ko/docs/concepts/overview/components.md
+3
View File
@@ -2,6 +2,9 @@
title: 쿠버네티스 컴포넌트
content_template: templates/concept
weight: 20
card:
name: concepts
weight: 20
---
{{% capture overview %}}
content/ko/docs/concepts/overview/kubernetes-api.md
+3
View File
@@ -2,6 +2,9 @@
title: 쿠버네티스 API
content_template: templates/concept
weight: 30
card:
name: concepts
weight: 30
---
{{% capture overview %}}
content/ko/docs/concepts/overview/object-management-kubectl/imperative-command.md
+162
View File
@@ -0,0 +1,162 @@
---
title: 명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
쿠버네티스 오브젝트는 `kubectl` 커맨드 라인 툴 속에 내장된 명령형 커맨드를 이용함으로써
바로 신속하게 생성, 업데이트 및 삭제할 수 있다. 이 문서는 어떻게 커맨드가 구성되어 있으며,
이를 사용하여 활성 오브젝트를 어떻게 관리하는 지에 대해 설명한다.
{{% /capture %}}
{{% capture body %}}
## 트레이드 오프
`kubectl`툴은 3가지 종류의 오브젝트 관리를 지원한다.
* 명령형 커맨드
* 명령형 오브젝트 구성
* 선언형 오브젝트 구성
각 종류별 오브젝트 관리의 장점과 단점에 대한 논의는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/object-management-kubectl/overview/)
를 참고한다.
## 오브젝트 생성 방법
`kubectl` 툴은 가장 일반적인 오브젝트 타입을 생성하는데 동사 형태 기반의 커맨드를
지원한다. 쿠버네티스 오브젝트 타입에 익숙하지 않은 사용자가 인지할 수 있도록 커맨드
이름이 지어졌다.
- `run`: 하나 이상의 파드 내 컨테이너를 실행하도록 새로운 디플로이먼트 오브젝트를 생성한다.
- `expose`: 파드에 걸쳐 트래픽을 로드 밸런스하도록 새로운 서비스 오브젝트를 생성한다.
- `autoscale`: 디플로이먼트와 같이, 하나의 컨트롤러에 대해 자동으로 수평적 스케일이 이루어 지도록 새로운 Autoscaler 오브젝트를 생성한다.
또한 `kubectl` 툴은 오브젝트 타입에 의해 구동되는 생성 커맨드를 지원한다.
이러한 커맨드는 더 많은 오브젝트 타입을 지원해주며 그 의도하는 바에 대해
보다 명확하게 해주지만, 사용자가 생성하고자 하는 오브젝트 타입에 대해
알 수 있도록 해야 한다.
- `create <오브젝트 타입> [<서브 타입>] <인스턴스명>`
일부 오브젝트 타입은 `create` 커맨드 내 정의할 수 있는 서브 타입을 가진다.
예를 들어, 서비스 오브젝트는 ClusterIP, LoadBalancer 및 NodePort 등을
포함하는 여러 서브 타입을 가진다, 다음은 NodePort 서브 타입을 통해 서비스를
생성하는 예제이다.
```shell
kubectl create service nodeport <사용자 서비스 명칭>
```
이전 예제에서, `create service nodeport` 커맨드는
`create service` 커맨드의 서브 커맨드라고 칭한다.
`-h` 플래그를 사용하여 서브 커맨드에 의해 지원되는 인수 및 플래그를
찾아 볼 수 있다.
```shell
kubectl create service nodeport -h
```
## 오브젝트 업데이트 방법
`kubectl` 커맨드는 일반적인 몇몇의 업데이트 작업을 위해 동사 형태 기반의 커맨드를 지원한다.
이 커맨드는 쿠버네티스 오브젝트에 익숙하지 않은 사용자가 설정되어야
하는 특정 필드를 모르는 상태에서도 업데이트를 수행할 수 있도록
이름 지어졌다.
- `scale`: 컨트롤러의 레플리카 수를 업데이트 함으로써 파드를 추가 또는 제거하는 컨트롤러를 수평적으로 스케일한다.
- `annotate`: 오브젝트로부터 어노테이션을 추가 또는 제거한다.
- `label`: 오브젝트에서 레이블을 추가 또는 제거한다.
`kubectl` 커맨드는 또한 오브젝트 측면에서 구동되는 업데이트 커맨드를 지원한다.
이 측면의 설정은 다른 오브젝트 타입에 대한 다른 필드를 설정 할 수도 있다.
- `set` `<field>`: 오브젝트의 측면을 설정한다.
{{< note >}}
쿠버네티스 1.5 버전에서는 모든 동사 형태 기반의 커맨드가 관련된 측면 중심의 커맨드를 가지는 것은 아니다.
{{< /note >}}
`kubectl` 툴은 활성 오브젝트를 직접 업데이트하기 위해 추가적인 방법을 지원하지만,
쿠버네티스 오브젝트 스키마에 대한 추가적인 이해를 요구한다.
- `edit`: 편집기에서 구성을 열어 활성 오브젝트에 대한 원래 그대로의 구성을 바로 편집한다.
- `patch`: 패치 문자열를 사용하여 활성 오브젝트를 바로 편집한다.
패치 문자열에 대한 보다 자세한 정보를 보려면
[API 규정](https://git.k8s.io/community/contributors/devel/api-conventions.md#patch-operations)에서 패치 섹션을 참고한다.
## 오브젝트 삭제 방법
클러스터에서 오브젝트를 삭제하기 위해 `delete` 커맨드을 사용할 수 있다.
- `delete <타입>/<이름>`
{{< note >}}
명령형 커맨드와 명령형 오브젝트 구성 모두 `kubectl delete`를 사용할 수
있다. 차이점은 커맨드에 전해지는 인수에 있다. 명령형 커맨드로
`kubectl delete`을 사용하기 위해, 삭제할 오브젝트를 인수로 전한다.
다음은 nginx라는 디플로이먼트 오브젝트를 전하는 예제이다.
{{< /note >}}
```shell
kubectl delete deployment/nginx
```
## 오브젝트 확인 방법
{{< comment >}}
TODO(pwittrock): 구현이 이루어지면 주석을 해제한다.
오브젝트의 특정 필드를 출력하기 위해 `kubectl view`를 사용할 수 있다.
- `view`: 오브젝트의 특정 필드의 값을 출력한다.
{{< /comment >}}
오브젝트에 대한 정보를 출력하는 몇 가지 커맨드가 있다.
- `get`: 일치하는 오브젝트에 대한 기본 정보를 출력한다. 옵션 리스트를 확인하기 위해 `get -h`를 사용한다.
- `describe`: 일치하는 오브젝트에 대해 수집한 상세한 정보를 출력한다.
- `logs`: 파드에서 실행 중인 컨테이너에 대한 stdout과 stderr를 출력한다.
## 생성 전 오브젝트 수정을 위해 `set` 커맨드 사용하기
`create` 커맨드에 사용할 수 있는 플래그가 없는 몇 가지 오브젝트
필드가 있다. 이러한 경우, 오브젝트 생성 전에 필드에 대한 값을
정의하기 위해 `set`과 `create`을 조합해서 사용할 수 있다.
이는 `set` 커맨드에 `create` 커맨드의 출력을 파이프 함으로써 수행할 수 있다.
다음은 관련 예제이다.
```sh
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
```
1. `kubectl create service -o yaml --dry-run` 커맨드는 서비스에 대한 구성을 생성하지만, 이를 쿠버네티스 API 서버에 전송하는 대신 YAML 형식으로 stdout에 출력한다.
1. `kubectl set selector --local -f - -o yaml` 커맨드는 stdin으로부터 구성을 읽어, YAML 형식으로 stdout에 업데이트된 구성을 기록한다.
1. `kubectl create -f -` 커맨드는 stdin을 통해 제공된 구성을 사용하여 오브젝트를 생성한다.
## 생성 전 오브젝트 수정을 위해 `--edit` 사용하기
생성 전에 오브젝트에 임의의 변경을 가하기 위해 `kubectl create --edit` 을 사용할 수 있다.
다음은 관련 예제이다.
```sh
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run > /tmp/srv.yaml
kubectl create --edit -f /tmp/srv.yaml
```
1. `kubectl create service` 커맨드는 서비스에 대한 구성을 생성하고 이를 `/tmp/srv.yaml`에 저장한다.
1. `kubectl create --edit` 커맨드는 오브젝트를 생성하기 전에 편집을 위해 구성파일을 열어준다.
{{% /capture %}}
{{% capture whatsnext %}}
- [오브젝트 구성을 이용하여 쿠베네티스 관리하기(명령형)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/)
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}
content/ko/docs/concepts/overview/what-is-kubernetes.md
+4 -1
View File
@@ -2,6 +2,9 @@
title: 쿠버네티스란 무엇인가?
content_template: templates/concept
weight: 10
card:
name: concepts
weight: 10
---
{{% capture overview %}}
@@ -104,7 +107,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
![Why Containers?](/images/docs/why_containers.svg)
애플리케이션을 배포하는 *구식의 방법* 은 운영 체제의 패키지 관리자를
애플리케이션을 배포하는 *옛 방식* 은 운영 체제의 패키지 관리자를
사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은
애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과
호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을
content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+4 -1
View File
@@ -2,6 +2,9 @@
title: 쿠버네티스 오브젝트 이해하기
content_template: templates/concept
weight: 10
card:
name: concepts
weight: 40
---
{{% capture overview %}}
@@ -21,7 +24,7 @@ weight: 10
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [Kubernetes API](/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [Client Libraries](/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
### 오브젝트 (spec)과 상태(status)
### 오브젝트 스펙(spec)과 상태(status)
모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 *의도한 상태* 를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
content/ko/docs/concepts/workloads/pods/pod-overview.md
+3
View File
@@ -2,6 +2,9 @@
title: 파드(Pod) 개요
content_template: templates/concept
weight: 10
card:
name: concepts
weight: 60
---
{{% capture overview %}}