Merge pull request #26949 from jihoon-seo/210308-Update-outdated-files-in-dev-1.20-ko.6
[ko] Update outdated files in dev-1.20-ko.6 (p2)
This commit is contained in:
Kubernetes Prow Robot
@@ -61,6 +61,22 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
|
||||
|
||||
4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port** 를 클릭.
|
||||
|
||||
{{< note >}}
|
||||
`minikube dashboard` 명령을 내리면 대시보드 애드온과 프록시가 활성화되고 해당 프록시로 접속하는 기본 웹 브라우저 창이 열린다. 대시보드에서 디플로이먼트나 서비스와 같은 쿠버네티스 자원을 생성할 수 있다.
|
||||
|
||||
root 환경에서 명령어를 실행하고 있다면, [URL을 이용하여 대시보드 접속하기](#open-dashboard-with-url)를 참고한다.
|
||||
|
||||
`Ctrl+C` 를 눌러 프록시를 종료할 수 있다. 대시보드는 종료되지 않고 실행 상태로 남아 있다.
|
||||
{{< /note >}}
|
||||
|
||||
## URL을 이용하여 대시보드 접속하기 {#open-dashboard-with-url}
|
||||
|
||||
자동으로 웹 브라우저가 열리는 것을 원치 않는다면, 다음과 같은 명령어를 실행하여 대시보드 접속 URL을 출력할 수 있다:
|
||||
|
||||
```shell
|
||||
minikube dashboard --url
|
||||
```
|
||||
|
||||
## 디플로이먼트 만들기
|
||||
|
||||
쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/)는 관리와
|
||||
|
||||
@@ -33,7 +33,7 @@ weight: 10
|
||||
</p>
|
||||
<p>쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.
|
||||
<ul>
|
||||
<li><b>마스터</b>는 클러스터를 조율한다.</li>
|
||||
<li><b>컨트롤 플레인</b>은 클러스터를 조율한다.</li>
|
||||
<li><b>노드</b>는 애플리케이션을 구동하는 작업자(worker)이다.</li>
|
||||
</ul>
|
||||
</p>
|
||||
@@ -71,20 +71,20 @@ weight: 10
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p><b>마스터는 클러스터 관리를 담당한다.</b> 마스터는 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.</p>
|
||||
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 마스터와 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.</p>
|
||||
<p><b>컨트롤 플레인은 클러스터 관리를 담당한다.</b> 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.</p>
|
||||
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.</p>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="content__box content__box_fill">
|
||||
<p><i>마스터는 실행 중인 애플리케이션을 호스팅하기 위해 사용되는 노드와 클러스터를 관리한다. </i></p>
|
||||
<p><i>컨트롤 플레인은 실행 중인 애플리케이션을 호스팅하기 위해 사용되는 노드와 클러스터를 관리한다. </i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p>애플리케이션을 쿠버네티스에 배포하기 위해서는, 마스터에 애플리케이션 컨테이너의 구동을 지시하면 된다. 그러면 마스터는 컨테이너를 클러스터의 어느 노드에 구동시킬지 스케줄한다. <b>노드는 마스터가 제공하는 <a href="/ko/docs/concepts/overview/kubernetes-api/">쿠버네티스 API</a>를 통해서 마스터와 통신한다.</b> 최종 사용자도 쿠버네티스 API를 사용해서 클러스터와 직접 상호작용(interact)할 수 있다.</p>
|
||||
<p>애플리케이션을 쿠버네티스에 배포하기 위해서는, 컨트롤 플레인에 애플리케이션 컨테이너의 구동을 지시하면 된다. 그러면 컨트롤 플레인은 컨테이너를 클러스터의 어느 노드에 구동시킬지 스케줄한다. <b>노드는 컨트롤 플레인이 제공하는 <a href="/ko/docs/concepts/overview/kubernetes-api/">쿠버네티스 API</a>를 통해서 컨트롤 플레인과 통신한다.</b> 최종 사용자도 쿠버네티스 API를 사용해서 클러스터와 직접 상호작용(interact)할 수 있다.</p>
|
||||
|
||||
<p>쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면 Minikube를 사용할 수 있다. Minikube는 가벼운 쿠버네티스 구현체이며, 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한 클러스터를 생성한다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서 구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인 부트스트래핑(bootstrapping) 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는 온라인 터미널을 사용할 것이다.</p>
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ weight: 10
|
||||
일단 쿠버네티스 클러스터를 구동시키면, 그 위에 컨테이너화된 애플리케이션을 배포할 수 있다.
|
||||
그러기 위해서, 쿠버네티스 <b>디플로이먼트</b> 설정을 만들어야 한다. 디플로이먼트는 쿠버네티스가
|
||||
애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다. 디플로이먼트가 만들어지면,
|
||||
쿠버네티스 마스터가 해당 디플로이먼트에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄한다.
|
||||
쿠버네티스 컨트롤 플레인이 해당 디플로이먼트에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄한다.
|
||||
</p>
|
||||
|
||||
<p>애플리케이션 인스턴스가 생성되면, 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를
|
||||
|
||||
@@ -412,7 +412,7 @@ client_address=198.51.100.79
|
||||
HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)
|
||||
또는 [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For)
|
||||
헤더 또는
|
||||
[프록시 프로토콜](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)과
|
||||
[프록시 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)과
|
||||
같은 로드밸런서와 백엔드 간에 합의된 프로토콜을 사용해야 한다.
|
||||
두 번째 범주의 로드밸런서는 서비스의 `service.spec.healthCheckNodePort` 필드의 저장된 포트를 가르키는
|
||||
HTTP 헬스 체크를 생성하여
|
||||
|
||||
@@ -114,7 +114,7 @@ cassandra ClusterIP None <none> 9042/TCP 45s
|
||||
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
|
||||
```
|
||||
|
||||
클러스터에 맞게 `cassandra-statefulset.yaml` 를 수정해야 하는 경우 다음을 다운로드 한 다음
|
||||
클러스터에 맞게 `cassandra-statefulset.yaml` 를 수정해야 하는 경우 다음을 다운로드한 다음
|
||||
수정된 버전을 저장한 폴더에서 해당 매니페스트를 적용한다.
|
||||
https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
|
||||
```shell
|
||||
|
||||
@@ -133,7 +133,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment
|
||||
1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=guestbook -l tier=frontend
|
||||
kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend
|
||||
```
|
||||
|
||||
결과는 아래와 같은 형태로 나타난다.
|
||||
|
||||
Reference in New Issue
Block a user