Update to Outdated files in the dev-1.20-ko.7 branch part. 1.
Yuk, Yongsu
parent
ca2219f567
commit
b59a32dfbc
|
|
@ -21,7 +21,7 @@ aliases:
|
|||
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
|
||||
|
||||
API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다.
|
||||
`kubernetes` 서비스(모든 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
|
||||
`kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
|
||||
|
||||
컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ weight: 10
|
|||
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 노드를 추가하는 두가지 주요 방법이 있다.
|
||||
|
||||
1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
|
||||
2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가
|
||||
2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가
|
||||
|
||||
노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후
|
||||
컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
|
||||
|
|
@ -48,8 +48,8 @@ weight: 10
|
|||
|
||||
쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
|
||||
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
|
||||
노드가 정상이면(필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
|
||||
그렇지 않으면, 해당 노드는 정상이 될때까지 모든 클러스터 활동에
|
||||
노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
|
||||
그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에
|
||||
대해 무시된다.
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -226,13 +226,14 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
|
|||
노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
|
||||
|
||||
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
|
||||
노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트
|
||||
수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.)
|
||||
NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고,
|
||||
노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다.
|
||||
(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
|
||||
파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
|
||||
매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
|
||||
다음을 담당한다.
|
||||
- 노드 다운과 같은 어떤 이유로 노드 컨트롤러가
|
||||
하트비트 수신이 중단되는 경우 NodeStatus의 NodeReady
|
||||
컨디션을 ConditionUnknown으로 업데이트 한다.
|
||||
- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
|
||||
ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
|
||||
파드를 축출하기 시작하는 값은 5분이다.
|
||||
노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
|
||||
|
||||
#### 하트비트
|
||||
|
||||
|
|
@ -250,11 +251,12 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
|
|||
|
||||
- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우,
|
||||
`NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트
|
||||
주기는 5분이다(연결할 수 없는 노드의 시간 제한인 40초
|
||||
보다 훨씬 길다).
|
||||
주기는 5분으로, 연결할 수 없는 노드의 시간 제한인 40초
|
||||
보다 훨씬 길다.
|
||||
- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
|
||||
리스 업데이트는 `NodeStatus` 업데이트와는
|
||||
독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
|
||||
독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며
|
||||
7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
|
||||
|
||||
#### 안정성
|
||||
|
||||
|
|
@ -264,13 +266,13 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
|
|||
|
||||
노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
|
||||
경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
|
||||
체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.).
|
||||
상태가 불량한 노드의 일부가 최소
|
||||
`--unhealthy-zone-threshold` 기본값 0.55) 가
|
||||
되면 축출 비율은 감소한다. 클러스터가 작으면 (즉
|
||||
`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고,
|
||||
그렇지 않으면 축출 비율은 초당
|
||||
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
|
||||
체크한다(NodeReady 컨디션은 ConditionUnknown 또는
|
||||
ConditionFalse 다.).
|
||||
- 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold`
|
||||
(기본값 0.55)가 되면 축출 비율은 감소한다.
|
||||
- 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
|
||||
노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
|
||||
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
|
||||
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
|
||||
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
|
||||
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
|
||||
|
|
@ -299,8 +301,8 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
|
|||
|
||||
### 노드 용량
|
||||
|
||||
노드 오브젝트는 노드 리소스 용량에 대한 정보(예: 사용 가능한 메모리의
|
||||
양과 CPU의 수)를 추적한다.
|
||||
노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의
|
||||
양과 CPU의 수를 추적한다.
|
||||
노드의 [자체 등록](#노드에-대한-자체-등록)은 등록하는 중에 용량을 보고한다.
|
||||
[수동](#수동-노드-관리)으로 노드를 추가하는 경우 추가할 때
|
||||
노드의 용량 정보를 설정해야 한다.
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/
|
|||
|
||||
동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다.
|
||||
|
||||
URL을 구성 소스로 지정할 수도 있다. 이는 github에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
|
||||
URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
|
||||
|
|
|
|||
|
|
@ -42,8 +42,8 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob
|
|||
`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 `data` 및 `binaryData`
|
||||
필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. `data` 필드와
|
||||
`binaryData` 는 모두 선택 사항이다. `data` 필드는
|
||||
UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리 데이터를
|
||||
포함하도록 설계되었다.
|
||||
UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리
|
||||
데이터를 base64로 인코딩된 문자열로 포함하도록 설계되었다.
|
||||
|
||||
컨피그맵의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
|
|
|
|||
|
|
@ -81,9 +81,9 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
|
|||
|
||||
- `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다.
|
||||
|
||||
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다.
|
||||
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `imagePullPolicy`는 자동으로 `Always`가 적용된다. 태그 값을 변경하더라도 이 값은 `IfNotPresent`로 업데이트 되지 _않는다_.
|
||||
|
||||
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `IfNotPresent`가 적용된다.
|
||||
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `imagePullPolicy`는 자동으로 `IfNotPresent`가 적용된다. 태그가 나중에 제거되거나 `:latest`로 변경되더라도 `Always`로 업데이트 되지 _않는다_.
|
||||
|
||||
- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
|
|||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
기반이 되는 이미지 제공자의 캐시 방법은 `imagePullPolicy: Always`를 효율적으로 만든다. 예를 들어, 도커에서는 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
|
||||
레지스트리가 안정적으로 동작하는 상황에서는, `imagePullPolicy: Always`로 설정되어 있더라도 기반 이미지 관리 도구의 캐싱 정책을 통해 이미지 풀(pull) 작업의 효율성을 높일 수 있다. 예를 들어, 도커를 사용하는 경우 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
|
||||
{{< /note >}}
|
||||
|
||||
## kubectl 사용하기
|
||||
|
|
|
|||
|
|
@ -49,16 +49,32 @@ weight: 10
|
|||
|
||||
## 이미지 업데이트
|
||||
|
||||
기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미
|
||||
존재하는 이미지에 대한 풀을 생략하게 한다. 만약 항상 풀을 강제하고 싶다면,
|
||||
다음 중 하나를 수행하면 된다.
|
||||
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}},
|
||||
{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}, 파드 또는 파드
|
||||
템플릿은 포함하는 다른 오브젝트를 처음 만들 때 특별히 명시하지 않은 경우
|
||||
기본적으로 해당 파드에 있는 모든 컨테이너의 풀(pull)
|
||||
정책은 `IfNotPresent`로 설정된다. 이 정책은
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는
|
||||
이미지에 대한 풀을 생략하게 한다.
|
||||
|
||||
만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다.
|
||||
|
||||
- 컨테이너의 `imagePullPolicy`를 `Always`로 설정.
|
||||
- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용.
|
||||
- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용,
|
||||
쿠버네티스는 정책을 `Always`로 설정한다.
|
||||
- `imagePullPolicy`와 사용할 이미지의 태그를 생략.
|
||||
- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화.
|
||||
|
||||
{{< note >}}
|
||||
컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상
|
||||
설정되고 나중에 이미지 태그가 변경되더라도 업데이트되지 않는다.
|
||||
|
||||
예를 들어, 태그가 `:latest`가 아닌 이미지로 디플로이먼트를 생성하고,
|
||||
나중에 해당 디플로이먼트의 이미지를 `:latest` 태그로 업데이트하면
|
||||
`imagePullPolicy` 필드가 `Always` 로 변경되지 않는다. 오브젝트를
|
||||
처음 생성 한 후 모든 오브젝트의 풀 정책을 수동으로 변경해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다.
|
||||
|
||||
## 이미지 인덱스가 있는 다중 아키텍처 이미지
|
||||
|
|
|
|||
|
|
@ -102,27 +102,28 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
|
|||
|
||||
## 자신만의 오퍼레이터 작성 {#writing-operator}
|
||||
|
||||
에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면 직접 코딩할 수 있다.
|
||||
[다음 내용](#다음-내용)에서는 클라우드 네이티브 오퍼레이터를 작성하는 데
|
||||
사용할 수 있는 라이브러리 및 도구에 대한 몇 가지 링크를
|
||||
찾을 수 있다.
|
||||
에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면
|
||||
직접 코딩할 수 있다.
|
||||
|
||||
또한 [쿠버네티스 API의 클라이언트](/ko/docs/reference/using-api/client-libraries/)
|
||||
역할을 할 수 있는 모든 언어 / 런타임을 사용하여 오퍼레이터(즉, 컨트롤러)를 구현한다.
|
||||
|
||||
다음은 클라우드 네이티브 오퍼레이터를 작성하는 데 사용할 수 있는
|
||||
몇 가지 라이브러리와 도구들이다.
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
|
||||
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
|
||||
* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
|
||||
사용하여 직접 구현하기
|
||||
* [오퍼레이터 프레임워크](https://operatorframework.io)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
|
||||
* [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기
|
||||
* 기존 도구를 사용하여 자신만의 오퍼레이터를 작성해보자. 다음은 예시이다.
|
||||
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) 사용하기
|
||||
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
|
||||
* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
|
||||
사용하여 직접 구현하기
|
||||
* [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기
|
||||
* 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
|
||||
* 오퍼레이터 패턴을 소개한 [CoreOS 원본 글](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) 읽기 (이 링크는 원본 글에 대한 보관 버전임)
|
||||
* 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
title: 노드에 파드 할당하기
|
||||
content_type: concept
|
||||
weight: 50
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
|
||||
content_type: concept
|
||||
weight: 50
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -75,8 +75,8 @@ parameters:
|
|||
사용자는 `PersistentVolumeClaim` 에 스토리지 클래스를 포함시켜 동적으로 프로비전된
|
||||
스토리지를 요청한다. 쿠버네티스 v1.6 이전에는 `volume.beta.kubernetes.io/storage-class`
|
||||
어노테이션을 통해 수행되었다. 그러나 이 어노테이션은
|
||||
v1.6부터 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의
|
||||
`storageClassName` 필드를 사용할 수 있기에 대신하여 사용해야 한다. 이 필드의 값은
|
||||
v1.9부터는 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의
|
||||
`storageClassName` 필드를 사용해야 한다. 이 필드의 값은
|
||||
관리자가 구성한 `StorageClass` 의 이름과
|
||||
일치해야 한다. ([아래](#동적-프로비저닝-활성화하기)를 참고)
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,8 @@ weight: 10
|
|||
임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은
|
||||
파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서
|
||||
실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가
|
||||
더 이상 존재하지 않으면, 볼륨은 삭제된다.
|
||||
더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
|
||||
퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.
|
||||
|
||||
기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드
|
||||
내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는
|
||||
|
|
|
|||
|
|
@ -51,8 +51,8 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
|
|||
|
||||
{{< note >}}
|
||||
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된
|
||||
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며
|
||||
값 배열은 "value"만 포함한다.
|
||||
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, `key` 필드는 "key"에 그리고 `operator`는 "In"에 대응되며
|
||||
`value` 배열은 "value"만 포함한다.
|
||||
매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ linkTitle: "레퍼런스"
|
|||
main_menu: true
|
||||
weight: 70
|
||||
content_type: concept
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -18,11 +19,17 @@ content_type: concept
|
|||
|
||||
## API 레퍼런스
|
||||
|
||||
* [표준 용어집](/ko/docs/reference/glossary/) - 포괄적이고, 표준화 된 쿠버네티스 용어 목록
|
||||
|
||||
|
||||
|
||||
* [쿠버네티스 API 레퍼런스](/docs/reference/kubernetes-api/)
|
||||
* [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
|
||||
* [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항
|
||||
* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)
|
||||
|
||||
## API 클라이언트 라이브러리
|
||||
## 공식적으로 지원되는 클라이언트 라이브러리
|
||||
|
||||
프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서,
|
||||
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용할 수 있다.
|
||||
|
|
@ -32,22 +39,27 @@ content_type: concept
|
|||
- [쿠버네티스 Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python)
|
||||
- [쿠버네티스 Java 클라이언트 라이브러리](https://github.com/kubernetes-client/java)
|
||||
- [쿠버네티스 JavaScript 클라이언트 라이브러리](https://github.com/kubernetes-client/javascript)
|
||||
- [쿠버네티스 Dotnet 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp)
|
||||
- [쿠버네티스 Haskell 클라이언트 라이브러리](https://github.com/kubernetes-client/haskell)
|
||||
|
||||
## CLI 레퍼런스
|
||||
## CLI
|
||||
|
||||
* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
|
||||
* [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
|
||||
* [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
|
||||
|
||||
## 컴포넌트 레퍼런스
|
||||
## 컴포넌트
|
||||
|
||||
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
|
||||
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API.
|
||||
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
|
||||
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
|
||||
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
|
||||
* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
|
||||
* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
|
||||
|
||||
## 스케줄링
|
||||
|
||||
* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
|
||||
* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
|
||||
|
||||
## 설계 문서
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: API 접근 제어
|
||||
weight: 20
|
||||
weight: 15
|
||||
no_list: true
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: 커맨드 라인 도구 레퍼런스
|
||||
title: 컴포넌트 도구
|
||||
weight: 60
|
||||
---
|
||||
|
|
|
|||
|
|
@ -242,6 +242,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - |
|
||||
| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
|
||||
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
|
||||
| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - |
|
||||
| `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 |
|
||||
| `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 표준 용어집
|
||||
title: 용어집
|
||||
layout: glossary
|
||||
noedit: true
|
||||
default_active_tag: fundamental
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: 쿠버네티스 이슈와 보안
|
||||
weight: 10
|
||||
weight: 40
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "kubectl CLI"
|
||||
title: "kubectl"
|
||||
weight: 60
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/c
|
|||
이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
|
||||
지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
|
||||
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다.
|
||||
설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다.
|
||||
설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
|
|||
|
|
@ -185,8 +185,6 @@ profiles:
|
|||
- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를
|
||||
선호한다.
|
||||
익스텐션 포인트: `Score`.
|
||||
- `NodeResourceLimits`: 파드 리소스 제한을 충족하는 노드를 선호한다.
|
||||
익스텐션 포인트: `PreScore`, `Score`.
|
||||
- `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지
|
||||
확인한다.
|
||||
익스텐션 포인트: `Filter`.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: 설치 도구 레퍼런스
|
||||
title: 설치 도구
|
||||
weight: 50
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: 쿠버네티스 API 개요
|
||||
title: API 개요
|
||||
content_type: concept
|
||||
weight: 10
|
||||
no_list: true
|
||||
card:
|
||||
name: 레퍼런스
|
||||
weight: 50
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ weight: 40
|
|||
<!-- overview -->
|
||||
|
||||
쿠버네티스는 TLS 위에 인증을 위해 PKI 인증서가 필요하다.
|
||||
만약 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)으로 쿠버네티스를 설치했다면, 클러스터에 필요한 인증서는 자동으로 생성된다.
|
||||
만약 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 쿠버네티스를 설치했다면, 클러스터에 필요한 인증서는 자동으로 생성된다.
|
||||
또한 더 안전하게 자신이 소유한 인증서를 생성할 수 있다. 이를 테면, 개인키를 API 서버에 저장하지 않으므로 더 안전하게 보관할 수 있다.
|
||||
이 페이지는 클러스터에 필요한 인증서를 설명한다.
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
|
|||
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
|
||||
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
|
||||
|
||||
[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
|
||||
[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm](/ko/docs/reference/setup-tools/kubeadm/) 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
|
||||
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
|
||||
|
||||
`kind`는 하나 이상의 [x509 키 사용](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다.
|
||||
|
|
@ -97,7 +97,7 @@ kubeadm 사용자만 해당:
|
|||
|
||||
### 인증서 파일 경로
|
||||
|
||||
인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다.
|
||||
인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm](/ko/docs/reference/setup-tools/kubeadm/)에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정해야 한다.
|
||||
|
||||
| 기본 CN | 권고되는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 |
|
||||
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ content_type: concept
|
|||
특정 kubelet을 나타내는 노드 오브젝트에
|
||||
{{< glossary_tooltip text="레이블" term_id="label" >}}을 자동으로 추가한다.
|
||||
이러한 레이블에는
|
||||
[영역 정보](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
|
||||
[영역 정보](/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
|
||||
|
||||
클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
|
|||
|
||||
### containerd
|
||||
|
||||
이 섹션에는 `containerd` 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
|
||||
이 섹션에는 containerd 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
|
||||
|
||||
필수 구성 요소를 설치 및 구성한다.
|
||||
|
||||
|
|
@ -90,170 +90,63 @@ sudo sysctl --system
|
|||
containerd를 설치한다.
|
||||
|
||||
{{< tabs name="tab-cri-containerd-installation" >}}
|
||||
{{% tab name="Ubuntu 16.04" %}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
```shell
|
||||
# 도커의 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
|
||||
# (containerd 설치)
|
||||
## 리포지터리 설정
|
||||
### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
```
|
||||
1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. 각 리눅스 배포한에 대한 도커 리포지터리를 설정하고 `containerd.io` 패키지를 설치하는 방법은 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다.
|
||||
|
||||
```shell
|
||||
## 도커의 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
|
||||
```
|
||||
2. containerd 설정
|
||||
|
||||
```shell
|
||||
## 도커 apt 리포지터리 추가
|
||||
sudo add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
```
|
||||
```shell
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
## containerd 설치
|
||||
sudo apt-get update && sudo apt-get install -y containerd.io
|
||||
```
|
||||
3. containerd 재시작
|
||||
|
||||
```shell
|
||||
# containerd 구성
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Ubuntu 18.04/20.04" %}}
|
||||
|
||||
```shell
|
||||
# (containerd 설치)
|
||||
sudo apt-get update && sudo apt-get install -y containerd
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 구성
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Debian 9+" %}}
|
||||
|
||||
```shell
|
||||
# (containerd 설치)
|
||||
## 리포지터리 설정
|
||||
### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커의 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 apt 리포지터리 추가
|
||||
sudo add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/debian \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
```
|
||||
|
||||
```shell
|
||||
## containerd 설치
|
||||
sudo apt-get update && sudo apt-get install -y containerd.io
|
||||
```
|
||||
|
||||
```shell
|
||||
# 기본 containerd 구성 설정
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS/RHEL 7.4+" %}}
|
||||
|
||||
```shell
|
||||
# (containerd 설치)
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치
|
||||
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 리포지터리 추가
|
||||
sudo yum-config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 설치
|
||||
sudo yum update -y && sudo yum install -y containerd.io
|
||||
```
|
||||
|
||||
```shell
|
||||
## containerd 구성
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows (PowerShell)" %}}
|
||||
|
||||
<br />
|
||||
Powershell 세션을 띄우고, `$Version` 환경 변수를 원하는 버전으로 설정(예: `$Version=1.4.3`)한 뒤, 다음 명령어를 실행한다.
|
||||
<br />
|
||||
PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로 설정한 후 다음 명령을 실행한다.
|
||||
|
||||
```powershell
|
||||
# (containerd 설치)
|
||||
# containerd 다운로드
|
||||
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
|
||||
tar.exe xvf .\containerd-windows-amd64.tar.gz
|
||||
```
|
||||
1. containerd 다운로드
|
||||
|
||||
```powershell
|
||||
# 추출 및 구성
|
||||
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
|
||||
cd $Env:ProgramFiles\containerd\
|
||||
.\containerd.exe config default | Out-File config.toml -Encoding ascii
|
||||
```powershell
|
||||
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.
|
||||
gz
|
||||
tar.exe xvf .\containerd-windows-amd64.tar.gz
|
||||
```
|
||||
|
||||
# 구성을 검토한다. 설정에 따라 조정할 수 있다.
|
||||
# - sandbox_image (쿠버네티스 pause 이미지)
|
||||
# - cni bin_dir 및 conf_dir locations
|
||||
Get-Content config.toml
|
||||
2. 추출과 설정
|
||||
|
||||
# (선택 사항이지만, 강력히 권장됨) containerd를 Windows Defender 검사 예외에 추가
|
||||
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" ```
|
||||
```powershell
|
||||
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
|
||||
cd $Env:ProgramFiles\containerd\
|
||||
.\containerd.exe config default | Out-File config.toml -Encoding ascii
|
||||
|
||||
# 설정을 검토한다. 설정에 따라 다음을 조정할 수 있다.
|
||||
# - sandbox_image (쿠버네티스 일시중지 이미지)
|
||||
# - cni bin 폴더와 conf 폴더 위치
|
||||
Get-Content config.toml
|
||||
|
||||
# (선택사항 - 그러나 적극 권장함) Windows 디펜더 검사에서 containerd 제외
|
||||
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
|
||||
```
|
||||
|
||||
3. containerd 실행
|
||||
|
||||
```powershell
|
||||
.\containerd.exe --register-service
|
||||
Start-Service containerd
|
||||
```
|
||||
|
||||
```powershell
|
||||
# containerd 시작
|
||||
.\containerd.exe --register-service
|
||||
Start-Service containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
#### systemd {#containerd-systemd}
|
||||
#### `systemd` cgroup 드라이버의 사용 {#containerd-systemd}
|
||||
|
||||
`/etc/containerd/config.toml` 의 `systemd` cgroup 드라이버를 `runc` 에서 사용하려면, 다음과 같이 설정한다.
|
||||
|
||||
|
|
@ -264,6 +157,12 @@ Start-Service containerd
|
|||
SystemdCgroup = true
|
||||
```
|
||||
|
||||
이 변경 사항을 적용하는 경우 containerd를 재시작한다.
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
|
||||
kubeadm을 사용하는 경우,
|
||||
[kubelet용 cgroup 드라이버](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#컨트롤-플레인-노드에서-kubelet이-사용하는-cgroup-드라이버-구성)를 수동으로 구성한다.
|
||||
|
||||
|
|
@ -453,138 +352,38 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
|
|||
|
||||
### 도커
|
||||
|
||||
각 노드에 도커 CE를 설치한다.
|
||||
1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 리눅스 배포판용 도커를 설치한다. 이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 검증된 최신 버전의 도커를 찾을 수 있다.
|
||||
|
||||
쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는
|
||||
도커 버전을 찾을 수 있다.
|
||||
2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다.
|
||||
|
||||
사용자의 시스템에서 다음의 명령을 이용해 도커를 설치한다.
|
||||
```shell
|
||||
sudo mkdir /etc/docker
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
"log-opts": {
|
||||
"max-size": "100m"
|
||||
},
|
||||
"storage-driver": "overlay2"
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
{{< tabs name="tab-cri-docker-installation" >}}
|
||||
{{% tab name="Ubuntu 16.04+" %}}
|
||||
{{< note >}}
|
||||
`overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다.
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
# (도커 CE 설치)
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치
|
||||
sudo apt-get update && sudo apt-get install -y \
|
||||
apt-transport-https ca-certificates curl software-properties-common gnupg2
|
||||
```
|
||||
3. 도커 재시작과 부팅시 실행되게 설정
|
||||
|
||||
```shell
|
||||
# 도커 공식 GPG 키 추가:
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
|
||||
```
|
||||
```shell
|
||||
sudo systemctl enable docker
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 apt 리포지터리 추가:
|
||||
sudo add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 CE 설치
|
||||
sudo apt-get update && sudo apt-get install -y \
|
||||
containerd.io=1.2.13-2 \
|
||||
docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
|
||||
docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
|
||||
```
|
||||
|
||||
```shell
|
||||
## /etc/docker 생성
|
||||
sudo mkdir /etc/docker
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 데몬 설정
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
"log-opts": {
|
||||
"max-size": "100m"
|
||||
},
|
||||
"storage-driver": "overlay2"
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
```shell
|
||||
# /etc/systemd/system/docker.service.d 생성
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 재시작
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS/RHEL 7.4+" %}}
|
||||
|
||||
```shell
|
||||
# (도커 CE 설치)
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치
|
||||
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 리포지터리 추가
|
||||
sudo yum-config-manager --add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 CE 설치
|
||||
sudo yum update -y && sudo yum install -y \
|
||||
containerd.io-1.2.13 \
|
||||
docker-ce-19.03.11 \
|
||||
docker-ce-cli-19.03.11
|
||||
```
|
||||
|
||||
```shell
|
||||
## /etc/docker 생성
|
||||
sudo mkdir /etc/docker
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 데몬 설정
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
"log-opts": {
|
||||
"max-size": "100m"
|
||||
},
|
||||
"storage-driver": "overlay2",
|
||||
"storage-opts": [
|
||||
"overlay2.override_kernel_check=true"
|
||||
]
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
```shell
|
||||
# /etc/systemd/system/docker.service.d 생성
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 재시작
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
부팅 시 `docker` 서비스를 시작하려면, 다음 명령을 실행한다.
|
||||
|
||||
```shell
|
||||
sudo systemctl enable docker
|
||||
```
|
||||
|
||||
자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/)를
|
||||
참조한다.
|
||||
{{< note >}}
|
||||
더 자세한 내용은
|
||||
- [도커 데몬 설정](https://docs.docker.com/config/daemon/)
|
||||
- [systemd로 도커 제어](https://docs.docker.com/config/daemon/systemd/)
|
||||
{{< /note >}}
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ kops는 자동화된 프로비저닝 시스템인데,
|
|||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 반드시 설치해야 한다.
|
||||
* [kubectl](/ko/docs/tasks/tools/)을 반드시 설치해야 한다.
|
||||
|
||||
* 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 `kops` 를 [설치](https://github.com/kubernetes/kops#installing) 한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으
|
|||
높을 수 없다. 예를 들어, 1.7.0 버전의 kubelet은 1.8.0 API 서버와 완전히 호환되어야 하지만,
|
||||
그 반대의 경우는 아니다.
|
||||
|
||||
`kubectl` 설치에 대한 정보는 [kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다.
|
||||
`kubectl` 설치에 대한 정보는 [kubectl 설치 및 설정](/ko/docs/tasks/tools/)을 참고한다.
|
||||
|
||||
{{< warning >}}
|
||||
이 지침은 모든 시스템 업그레이드에서 모든 쿠버네티스 패키지를 제외한다.
|
||||
|
|
@ -174,16 +174,34 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으
|
|||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{% tab name="데비안 기반 배포판" %}}
|
||||
```bash
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
|
||||
deb https://apt.kubernetes.io/ kubernetes-xenial main
|
||||
EOF
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y kubelet kubeadm kubectl
|
||||
sudo apt-mark hold kubelet kubeadm kubectl
|
||||
```
|
||||
|
||||
1. `apt` 패키지 색인을 업데이트하고, 쿠버네티스 `apt` 리포지터리를 사용하는 데 필요한 패키지를 설치한다.
|
||||
|
||||
```shell
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y apt-transport-https ca-certificates curl
|
||||
```
|
||||
|
||||
2. 구글 클라우드의 공개 사이닝 키를 다운로드 한다.
|
||||
|
||||
```shell
|
||||
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
|
||||
```
|
||||
|
||||
3. 쿠버네티스 `apt` 리포지터리를 추가한다.
|
||||
|
||||
```shell
|
||||
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
|
||||
```
|
||||
|
||||
4. `apt` 패키지 색인을 업데이트하고, kubelet, kubeadm, kubectl을 설치하고 해당 버전을 고정한다.
|
||||
|
||||
```shell
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y kubelet kubeadm kubectl
|
||||
sudo apt-mark hold kubelet kubeadm kubectl
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="레드햇 기반 배포판" %}}
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h
|
|||
* Flatcar Container Linux by Kinvolk
|
||||
* 지속적인 통합 (CI) 테스트
|
||||
|
||||
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
|
||||
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
|
|||
|
|
@ -218,7 +218,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
|||
|
||||
#### IPv4/IPv6 이중 스택
|
||||
|
||||
`IPv6DualStack` [기능 게이트](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)을 참조한다.
|
||||
`IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)를 참조한다.
|
||||
|
||||
{{< note >}}
|
||||
윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 (커널 버전 10.0.19041.610) 이상이 필요하다.
|
||||
|
|
@ -234,7 +234,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
|||
|
||||
윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다.
|
||||
|
||||
#### 컴퓨트
|
||||
#### 컴퓨트 {#컴퓨트-제한}
|
||||
|
||||
##### 리소스 관리 및 프로세스 격리
|
||||
|
||||
|
|
@ -294,7 +294,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
|||
* NFS 기반 스토리지/볼륨 지원
|
||||
* 마운트된 볼륨 확장(resizefs)
|
||||
|
||||
#### 네트워킹
|
||||
#### 네트워킹 {#네트워킹-제한}
|
||||
|
||||
윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 추가 세부 정보와 배경이 포함되어 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1906,7 +1906,7 @@ filename | sha512 hash
|
|||
- Promote SupportNodePidsLimit to GA to provide node to pod pid isolation
|
||||
Promote SupportPodPidsLimit to GA to provide ability to limit pids per pod ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node and Testing]
|
||||
- Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling]
|
||||
- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](https://kubernetes.io/docs/reference/using-api/api-concepts/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
|
||||
- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
|
||||
- Set CSIMigrationvSphere feature gates to beta.
|
||||
Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver.
|
||||
|
||||
|
|
|
|||
|
|
@ -193,7 +193,7 @@ func main() {
|
|||
}
|
||||
```
|
||||
|
||||
애플리케이션이 클러스터에서 파드로 배치된 경우, [파드 내에서 API 접근](#accessing-the-api-from-within-a-pod)을 참고한다.
|
||||
애플리케이션이 클러스터 내의 파드로 배치된 경우, [파드 내에서 API 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#파드에서-api-접근)을 참고한다.
|
||||
|
||||
#### Python 클라이언트 {#python-client}
|
||||
|
||||
|
|
|
|||
|
|
@ -168,36 +168,7 @@ controllerManager:
|
|||
|
||||
### 인증서 서명 요청(CSR) 생성
|
||||
|
||||
`kubeadm certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.
|
||||
|
||||
[cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
|
||||
그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다.
|
||||
다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다.
|
||||
|
||||
```shell
|
||||
sudo kubeadm certs renew apiserver --use-api &
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
```
|
||||
[1] 2890
|
||||
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
|
||||
```
|
||||
|
||||
### 인증서 서명 요청(CSR) 승인
|
||||
|
||||
외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
|
||||
|
||||
그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
```shell
|
||||
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
|
||||
```
|
||||
|
||||
`kubectl get csr` 명령으로 보류 중인 인증서 목록을 볼 수 있다.
|
||||
쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다.
|
||||
|
||||
## 외부 CA로 인증서 갱신
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ weight: 10
|
|||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)를 설치한다.
|
||||
[`kubectl`](/ko/docs/tasks/tools/)를 설치한다.
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ weight: 30
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
|
||||
[`kubectl`](/ko/docs/tasks/tools/)을 설치한다.
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ weight: 40
|
|||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
|
||||
[`kubectl`](/ko/docs/tasks/tools/)을 설치한다.
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ kubectl apply -k <kustomization_directory>
|
|||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
|
||||
[`kubectl`](/ko/docs/tasks/tools/)을 설치한다.
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -20,10 +20,16 @@ card:
|
|||
|
||||
다음과 같은 방법으로 리눅스에 kubectl을 설치할 수 있다.
|
||||
|
||||
- [리눅스에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-linux)
|
||||
- [기본 패키지 관리 도구를 사용하여 설치](#install-using-native-package-management)
|
||||
- [다른 패키지 관리 도구를 사용하여 설치](#install-using-other-package-management)
|
||||
- [Google Cloud SDK를 사용하여 설치](#install-on-linux-as-part-of-the-google-cloud-sdk)
|
||||
- [{{% heading "prerequisites" %}}](#시작하기-전에)
|
||||
- [리눅스에 kubectl 설치](#리눅스에-kubectl-설치)
|
||||
- [리눅스에서 curl을 사용하여 kubectl 바이너리 설치]{#install-kubectl-binary-with-curl-on-linux}
|
||||
- [기본 패키지 관리 도구를 사용하여 설치]{#install-using-native-package-management}
|
||||
- [다른 패키지 관리 도구를 사용하여 설치]{#install-using-other-package-management}
|
||||
- [Google Cloud SDK를 사용하여 설치]{#install-on-linux-as-part-of-the-google-cloud-sdk}
|
||||
- [kubectl 구성 확인](#kubectl-구성-확인)
|
||||
- [선택적 kubectl 구성](#선택적-kubectl-구성)
|
||||
- [셸 자동 완성 활성화](#셸-자동-완성-활성화)
|
||||
- [{{% heading "whatsnext" %}}](#다음-내용)
|
||||
|
||||
### 리눅스에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-linux}
|
||||
|
||||
|
|
@ -100,15 +106,38 @@ card:
|
|||
### 기본 패키지 관리 도구를 사용하여 설치 {#install-using-native-package-management}
|
||||
|
||||
{{< tabs name="kubectl_install" >}}
|
||||
{{< tab name="Ubuntu, Debian 또는 HypriotOS" codelang="bash" >}}
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
|
||||
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y kubectl
|
||||
{{< /tab >}}
|
||||
{{% tab name="데비안 기반의 배포판" %}}
|
||||
|
||||
{{< tab name="CentOS, RHEL 또는 Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
|
||||
1. `apt` 패키지 색인을 업데이트하고 쿠버네티스 `apt` 리포지터리를 사용하는 데 필요한 패키지들을 설치한다.
|
||||
|
||||
```shell
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y apt-transport-https ca-certificates curl
|
||||
```
|
||||
|
||||
2. 구글 클라우드 공개 사이닝 키를 다운로드한다.
|
||||
|
||||
```shell
|
||||
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
|
||||
```
|
||||
|
||||
3. 쿠버네티스 `apt` 리포지터리를 추가한다.
|
||||
|
||||
```shell
|
||||
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
|
||||
```
|
||||
|
||||
4. 새 리포지터리의 `apt` 패키지 색인을 업데이트하고 kubectl을 설치한다.
|
||||
|
||||
```shell
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y kubectl
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{< tab name="레드햇 기반의 배포판" codelang="bash" >}}
|
||||
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
name=Kubernetes
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ card:
|
|||
- [macOS에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-macos)
|
||||
- [macOS에서 Homebrew를 사용하여 설치](#install-with-homebrew-on-macos)
|
||||
- [macOS에서 Macports를 사용하여 설치](#install-with-macports-on-macos)
|
||||
- [Google Cloud SDK를 사용하여 설치](#install-on-macos-as-part-of-the-google-cloud-sdk)
|
||||
- [macOS에서 Google Cloud SDK를 사용하여 설치](#install-on-macos-as-part-of-the-google-cloud-sdk)
|
||||
|
||||
### macOS에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-macos}
|
||||
|
||||
|
|
@ -157,4 +157,4 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
|
|
|||
Loading…
Reference in New Issue