[ko] Update outdated files in dev-1.24-ko.3 [M6-7/M35-49]
Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> Co-authored-by: Sanghong Kim <58922834+bconfiden2@users.noreply.github.com>pull/35880/head
Yoon PyungHo
parent
cc2f29f21a
commit
b92b779fcb
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - mikedanese
|
||||
title: 구성 모범 사례
|
||||
content_type: concept
|
||||
weight: 10
|
||||
|
|
@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
|
|||
|
||||
## 레이블 사용하기
|
||||
|
||||
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
|
||||
- `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app.kubernetes.io/name: MyApp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
|
||||
|
||||
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - tallclair
|
||||
# - dchen1107
|
||||
title: 런타임클래스(RuntimeClass)
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: 레퍼런스
|
||||
|
||||
|
||||
# approvers:
|
||||
# - chenopis
|
||||
linkTitle: "레퍼런스"
|
||||
main_menu: true
|
||||
weight: 70
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - lavalamp
|
||||
# - deads2k
|
||||
# - liggitt
|
||||
title: 인가 개요
|
||||
content_type: concept
|
||||
weight: 60
|
||||
|
|
@ -74,6 +74,10 @@ PUT | update
|
|||
PATCH | patch
|
||||
DELETE | delete(개별 리소스), deletecollection(리소스 모음)
|
||||
|
||||
{{< caution >}}
|
||||
`get`, `list`, `watch` 요청은 모두 리소스의 전체 세부 내용을 반환할 수 있다. 반환된 데이터의 관점으론 모두 동일하다. 예를 들어 `secrets`에 대해 `list` 요청은 반환된 리소스의 `data` 속성을 여전히 드러낼 것이다.
|
||||
{{< /caution >}}
|
||||
|
||||
쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,
|
||||
|
||||
* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/)
|
||||
|
|
|
|||
|
|
@ -808,7 +808,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
데몬셋 워크로드를 사용하도록 설정한다.
|
||||
[데몬셋에서 롤링 업데이트 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)을 참고한다.
|
||||
- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
|
||||
[기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
|
||||
[기본 분배](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/#내부-기본-제약)를 수행한다.
|
||||
- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해
|
||||
`fsGroup`를 전달하여 파드의 `securityContext`에서
|
||||
`fsGroup`를 드라이브에 적용하는 역할을 위임한다.
|
||||
|
|
@ -854,7 +854,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
{{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}를
|
||||
추가할 수 있다.
|
||||
- `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다.
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 참고한다.
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)을 참고한다.
|
||||
- `ExecProbeTimeout` : kubelet이 exec 프로브 시간 초과를 준수하는지 확인한다.
|
||||
이 기능 게이트는 기존 워크로드가 쿠버네티스가 exec 프로브 제한 시간을 무시한
|
||||
현재 수정된 결함에 의존하는 경우 존재한다.
|
||||
|
|
@ -994,7 +994,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
메모리 어피니티를 설정할 수 있다.
|
||||
- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여
|
||||
파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다.
|
||||
- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/) 내의
|
||||
- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/) 내의
|
||||
`minDomains` 사용을 활성화한다.
|
||||
- `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
|
||||
사용을 활성화한다.
|
||||
|
|
|
|||
|
|
@ -22,6 +22,6 @@ API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api
|
|||
API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및
|
||||
[`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 값을 준수한다.
|
||||
|
||||
API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다.
|
||||
API를 이용한 축출은 [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 동일하지 않다.
|
||||
|
||||
* 더 많은 정보는 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -4,15 +4,18 @@ id: Extensions
|
|||
date: 2019-02-01
|
||||
full_link: /ko/docs/concepts/extend-kubernetes/#익스텐션
|
||||
short_description: >
|
||||
익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다.
|
||||
익스텐션은 새로운 종류의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고
|
||||
깊게 통합시키는 소프트웨어 컴포넌트이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- extension
|
||||
---
|
||||
익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다.
|
||||
익스텐션은 새로운 종류의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. 이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 또한 익스텐션을 새로 만들어야 하는 사용자는 거의 없을 것이다.
|
||||
많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다.
|
||||
이러한 클러스터는 익스텐션이 미리 설치되어 제공된다.
|
||||
그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 익스텐션을 새로 만들어야 하는 사용자 역시 거의 없을 것이다.
|
||||
|
|
|
|||
|
|
@ -4,19 +4,24 @@ id: garbage-collection
|
|||
date: 2022-01-14
|
||||
full_link: /ko/docs/concepts/architecture/garbage-collection/
|
||||
short_description: >
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는
|
||||
다양한 방법을 종합한 용어이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
|
||||
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는
|
||||
다양한 방법을 종합한 용어이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
쿠버네티스는 [사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images),
|
||||
쿠버네티스는 가비지 수집을 이용하여
|
||||
[사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images),
|
||||
[실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[타겟 리소스가 소유한 오브젝트](/docs/concepts/overview/working-with-objects/owners-dependents/),
|
||||
[종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/), 그리고
|
||||
만료되거나 실패한 리소스를 정리하기 위해 가비지 수집을 사용한다.
|
||||
만료되거나 실패한 리소스 같은 리소스를 정리한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: kubectl 치트 시트
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - krousey
|
||||
# - clove
|
||||
content_type: concept
|
||||
weight: 10 # highlight it
|
||||
card:
|
||||
|
|
@ -68,6 +68,11 @@ kubectl config get-contexts # 컨텍스트 리스트
|
|||
kubectl config current-context # 현재 컨텍스트 출력
|
||||
kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정
|
||||
|
||||
kubectl config set-cluster my-cluster-name # kubeconfig에 클러스터 엔트리를 설정
|
||||
|
||||
# kubeconfig에 이 클라이언트가 발생시킨 요청에 사용할 프록시 서버의 URL을 구성한다.
|
||||
kubectl config set-cluster my-cluster-name --proxy-url=my-proxy-url
|
||||
|
||||
# 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다
|
||||
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
|
||||
|
||||
|
|
@ -182,6 +187,9 @@ kubectl get pods --selector=app=cassandra -o \
|
|||
kubectl get configmap myconfig \
|
||||
-o jsonpath='{.data.ca\.crt}'
|
||||
|
||||
# 밑줄(`_`) 대신 대시(`-`)를 사용하여 base64 인코딩된 값을 조회
|
||||
kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}'
|
||||
|
||||
# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/control-plane'
|
||||
# 으로 명명된 라벨의 결과를 제외)
|
||||
kubectl get node --selector='!node-role.kubernetes.io/control-plane'
|
||||
|
|
|
|||
|
|
@ -618,6 +618,16 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
참고한다.
|
||||
|
||||
### kubernetes.io/psp (사용 중단됨) {#kubernetes-io-psp}
|
||||
|
||||
예시: `kubernetes.io/psp: restricted`
|
||||
|
||||
이 어노테이션은 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/)를 사용하는 경우에만 관련있다.
|
||||
|
||||
파드시큐리티폴리시 어드미션 컨트롤러가 파드를 승인하면,
|
||||
어드미션 컨트롤러는 파드가 이 어노테이션을 갖도록 수정한다.
|
||||
이 어노테이션 값은 유효성 검사에서 사용된 파드시큐리티폴리시의 이름이다.
|
||||
|
||||
## seccomp.security.alpha.kubernetes.io/pod (사용 중단됨) {#seccomp-security-alpha-kubernetes-io-pod}
|
||||
|
||||
이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다.
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ profiles:
|
|||
[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를
|
||||
구현한다.
|
||||
익스텐션 포인트: `filter`, `score`.
|
||||
- `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를
|
||||
- `PodTopologySpread`: [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/pod-topology-spread-constraints/)을
|
||||
구현한다.
|
||||
익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`.
|
||||
- `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: API 개요
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - lavalamp
|
||||
# - jbeda
|
||||
content_type: concept
|
||||
weight: 10
|
||||
no_list: true
|
||||
|
|
@ -39,7 +39,7 @@ JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
|
|||
동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
|
||||
|
||||
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
|
||||
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/design-proposals-archive/release/versioning.md)에는
|
||||
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/sig-release/release-engineering/versioning.md)에는
|
||||
API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
|
||||
|
||||
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,8 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - jlowdermilk
|
||||
# - justinsb
|
||||
# - quinton-hoole
|
||||
title: 여러 영역에서 실행
|
||||
weight: 20
|
||||
content_type: concept
|
||||
|
|
@ -58,7 +62,7 @@ content_type: concept
|
|||
[영역 정보](/ko/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
|
||||
|
||||
클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/pod-topology-spread-constraints/)과
|
||||
함께 노드 레이블을 사용하여
|
||||
파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에
|
||||
분산되는 방식을 제어할 수 있다.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - vincepri
|
||||
# - bart0sh
|
||||
title: 컨테이너 런타임
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -217,7 +217,7 @@ kubeadm을 사용하는 경우,
|
|||
|
||||
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-containerd}
|
||||
|
||||
[containerd 설정](https://github.com/containerd/cri/blob/master/docs/config.md)에서
|
||||
[containerd 설정](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)에서
|
||||
아래와 같이 샌드박스 이미지를 덮어쓸 수 있다.
|
||||
|
||||
```toml
|
||||
|
|
|
|||
|
|
@ -8,18 +8,23 @@ weight: 30
|
|||
|
||||
이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal(전 Packet), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
|
||||
|
||||
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
|
||||
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md#inventory), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
|
||||
|
||||
Kubespray 지원 사항
|
||||
* 고가용성을 지닌 클러스터
|
||||
* 구성할 수 있는 속성들
|
||||
* 구성 가능 (인스턴스를 위한 네트워크 플러그인 선택)
|
||||
* 대부분의 인기있는 리눅스 배포판들에 대한 지원
|
||||
* Ubuntu 16.04, 18.04, 20.04, 22.04
|
||||
* CentOS/RHEL/Oracle Linux 7, 8
|
||||
* Debian Buster, Jessie, Stretch, Wheezy
|
||||
* Fedora 34, 35
|
||||
* Fedora CoreOS
|
||||
* openSUSE Leap 15
|
||||
* Flatcar Container Linux by Kinvolk
|
||||
- Flatcar Container Linux by Kinvolk
|
||||
- Debian Bullseye, Buster, Jessie, Stretch
|
||||
- Ubuntu 16.04, 18.04, 20.04, 22.04
|
||||
- CentOS/RHEL 7, 8
|
||||
- Fedora 34, 35
|
||||
- Fedora CoreOS
|
||||
- openSUSE Leap 15.x/Tumbleweed
|
||||
- Oracle Linux 7, 8
|
||||
- Alma Linux 8
|
||||
- Rocky Linux 8
|
||||
- Amazon Linux 2
|
||||
* 지속적인 통합 (CI) 테스트
|
||||
|
||||
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, 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)을 읽어보자.
|
||||
|
|
@ -33,13 +38,13 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h
|
|||
|
||||
언더레이(underlay) [요건](https://github.com/kubernetes-sigs/kubespray#requirements)을 만족하는 프로비전 한다.
|
||||
|
||||
* **Ansible의 명령어를 실행하기 위해 Ansible v 2.11와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다**
|
||||
* **Ansible 플레이북을 실행하기 위해 2.11 (혹은 그 이상) 버전의 Jinja가 필요하다**
|
||||
* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
|
||||
* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다
|
||||
* **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다
|
||||
* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
|
||||
* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
|
||||
* **쿠버네티스는 최소한 v1.22 이상의 버전이 필요하다.**
|
||||
* **Ansible의 명령어를 실행하기 위해 Ansible v2.11+, Jinja 2.11+와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다**.
|
||||
* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 **인터넷에 접속**할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
|
||||
* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다.
|
||||
* 파드와 서비스에서 IPv6를 이용한다면, 대상 서버도 **IPv6 포워딩**이 활성화되어야 한다.
|
||||
* **방화벽은 kubespray가 관리하지 않는다**. 사용자는 기존 방식으로 자신의 규칙을 구현해야 한다. 배포 중에 만날 문제를 예방하려면 방화벽을 비활성화해야 한다.
|
||||
* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 상승 방법이 설정되어야 한다. 그 후에 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
|
||||
|
||||
Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:
|
||||
|
||||
|
|
@ -115,5 +120,5 @@ reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.
|
||||
* Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.
|
||||
* [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 더 알아보자.
|
||||
|
|
|
|||
Loading…
Reference in New Issue