[ko] Update outdated in dev-1.21-ko.8 (M13-M40)
Jihoon Seo
parent
1e35724ca0
commit
29e8f27983
|
|
@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
|
|||
마찬가지로, 서비스 정의를 API 서버에 `POST`하여
|
||||
새 인스턴스를 생성할 수 있다.
|
||||
서비스 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-레이블-이름)이어야 한다.
|
||||
|
||||
예를 들어, 각각 TCP 포트 9376에서 수신하고
|
||||
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
|
||||
|
|
@ -188,7 +188,7 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
|
|||
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
|
||||
|
||||
### 초과 용량 엔드포인트
|
||||
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
|
||||
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21
|
||||
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
|
||||
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
|
||||
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ volumeBindingMode: Immediate
|
|||
| Glusterfs | ✓ | [Glusterfs](#glusterfs) |
|
||||
| iSCSI | - | - |
|
||||
| Quobyte | ✓ | [Quobyte](#quobyte) |
|
||||
| NFS | - | - |
|
||||
| NFS | - | [NFS](#nfs) |
|
||||
| RBD | ✓ | [Ceph RBD](#ceph-rbd) |
|
||||
| VsphereVolume | ✓ | [vSphere](#vsphere) |
|
||||
| PortworxVolume | ✓ | [Portworx 볼륨](#portworx-볼륨) |
|
||||
|
|
@ -423,6 +423,29 @@ parameters:
|
|||
헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을
|
||||
삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다.
|
||||
|
||||
### NFS
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
kind: StorageClass
|
||||
metadata:
|
||||
name: example-nfs
|
||||
provisioner: example.com/external-nfs
|
||||
parameters:
|
||||
server: nfs-server.example.com
|
||||
path: /share
|
||||
readOnly: false
|
||||
```
|
||||
|
||||
* `server`: NFS 서버의 호스트네임 또는 IP 주소.
|
||||
* `path`: NFS 서버가 익스포트(export)한 경로.
|
||||
* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false).
|
||||
|
||||
쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다.
|
||||
예시는 다음과 같다.
|
||||
* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
|
||||
* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
|
||||
|
||||
### OpenStack Cinder
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -255,7 +255,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
|
|||
|
||||
## 잡의 종료와 정리
|
||||
|
||||
잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다. 이를 유지하면
|
||||
잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다.
|
||||
이를 유지하면
|
||||
완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
|
||||
잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
|
||||
`kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.
|
||||
|
|
|
|||
|
|
@ -282,6 +282,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
|
|||
즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
|
||||
여기에서 제어할 수는 없다는 의미이다.
|
||||
|
||||
## 컨테이너 프로브
|
||||
|
||||
_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
|
||||
|
||||
- `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
|
||||
- `TCPSocketAction` (kubelet에 의해 직접 검사)
|
||||
- `HTTPGetAction` (kubelet에 의해 직접 검사)
|
||||
|
||||
[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은
|
||||
파드 라이프사이클 문서를 참고한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ weight: 60
|
|||
- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
|
||||
- 커널 패닉
|
||||
- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
|
||||
- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
|
||||
- 노드의 [리소스 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
|
||||
|
||||
리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
|
||||
왜냐하면
|
||||
|
|
|
|||
|
|
@ -290,8 +290,9 @@ myapp-pod 1/1 Running 0 9m
|
|||
초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
|
||||
다음의 규칙이 적용된다.
|
||||
|
||||
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
|
||||
높은 것은 *유효한 초기화 요청량/상한* 이다.
|
||||
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중
|
||||
가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는
|
||||
이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
|
||||
* 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
|
||||
* 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
|
||||
* 리소스에 대한 유효한 초기화 요청량/상한
|
||||
|
|
|
|||
|
|
@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다.
|
|||
확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
|
||||
프로세스를 시작한다.
|
||||
1. 파드의 컨테이너 중 하나가 `preStop`
|
||||
[훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은
|
||||
[훅](/ko/docs/concepts/containers/container-lifecycle-hooks/)을 정의한 경우, kubelet은
|
||||
컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이
|
||||
계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
|
||||
요청한다.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 40
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
이 문서에서는 `update-imported-docs` 스크립트를 사용하여
|
||||
이 문서에서는 `update-imported-docs.py` 스크립트를 사용하여
|
||||
쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다.
|
||||
이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ git clone git@github.com:<your_github_username>/website.git
|
|||
|
||||
## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs}
|
||||
|
||||
`update-imported-docs` 스크립트는 `<web-base>/update-imported-docs/`
|
||||
`update-imported-docs.py` 스크립트는 `<web-base>/update-imported-docs/`
|
||||
디렉터리에 존재한다.
|
||||
|
||||
이 스크립트는 다음 레퍼런스를 생성한다.
|
||||
|
|
@ -48,7 +48,7 @@ git clone git@github.com:<your_github_username>/website.git
|
|||
* `kubectl` 명령어 레퍼런스
|
||||
* 쿠버네티스 API 레퍼런스
|
||||
|
||||
`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
|
||||
`update-imported-docs.py` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
|
||||
생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를
|
||||
생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와
|
||||
`kubernetes-sigs/reference-docs` 저장소를 클론하며,
|
||||
|
|
@ -69,7 +69,7 @@ git clone git@github.com:<your_github_username>/website.git
|
|||
`kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다.
|
||||
`K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다.
|
||||
|
||||
`update-imported-docs` 스크립트는 다음의 과정을 수행한다.
|
||||
`update-imported-docs.py` 스크립트는 다음의 과정을 수행한다.
|
||||
|
||||
1. 환경설정 파일에 있는 관련 저장소를 클론한다.
|
||||
레퍼런스 문서 생성을 위해
|
||||
|
|
@ -152,17 +152,17 @@ repos:
|
|||
|
||||
## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool}
|
||||
|
||||
다음과 같이 `update-imported-docs` 도구를 실행할 수 있다.
|
||||
다음과 같이 `update-imported-docs.py` 도구를 실행할 수 있다.
|
||||
|
||||
```shell
|
||||
cd <web-base>/update-imported-docs
|
||||
./update-imported-docs <configuration-file.yml> <release-version>
|
||||
./update-imported-docs.py <configuration-file.yml> <release-version>
|
||||
```
|
||||
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
```shell
|
||||
./update-imported-docs reference.yml 1.17
|
||||
./update-imported-docs.py reference.yml 1.17
|
||||
```
|
||||
|
||||
<!-- Revisit: is the release configuration used -->
|
||||
|
|
@ -254,4 +254,3 @@ static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fon
|
|||
* [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/)
|
||||
* [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
---
|
||||
weight: 10
|
||||
title: 기능 게이트
|
||||
weight: 10
|
||||
content_type: concept
|
||||
card:
|
||||
name: reference
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: API를 이용한 축출(Eviction)
|
||||
id: api-eviction
|
||||
date: 2021-04-27
|
||||
full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction
|
||||
full_link: /ko/docs/concepts/scheduling-eviction/api-eviction/
|
||||
short_description: >
|
||||
API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는
|
||||
축출 오브젝트를 만드는 프로세스이다
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
|
||||
`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
|
||||
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
|
||||
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다.
|
||||
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
|
||||
`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
|
||||
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
|
||||
`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
|
||||
|
|
|
|||
|
|
@ -200,7 +200,7 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo
|
|||
|
||||
kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다.
|
||||
|
||||
## experimental.windows.kubernetes.io/isolation-type
|
||||
## experimental.windows.kubernetes.io/isolation-type (사용 중단됨) {#experimental-windows-kubernetes-io-isolation-type}
|
||||
|
||||
예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
|
||||
|
||||
|
|
@ -210,6 +210,7 @@ Hyper-V 격리(isolation)를 사용하여 윈도우 컨테이너를 실행하려
|
|||
|
||||
{{< note >}}
|
||||
이 어노테이션은 하나의 컨테이너로 구성된 파드에만 설정할 수 있다.
|
||||
v1.20부터 이 어노테이션은 더이상 사용되지 않는다. 실험적인 Hyper-V 지원은 1.21버전에서 제거되었다.
|
||||
{{< /note >}}
|
||||
|
||||
## ingressclass.kubernetes.io/is-default-class
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ no_list: true
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이되는 몇 가지 기본 제공 도구를 포함한다.
|
||||
쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 필요한 공통적으로 사용되거나 관련성 있는 여러 내장 도구와 외부 도구를 포함한다.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: 쿠버네티스 API 헬스(health) 엔드포인트
|
||||
|
||||
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
|
@ -91,7 +93,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
|
|||
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
|
||||
각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
|
||||
개별 체크를 위한 스키마는 `/livez/<healthcheck-name>` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
|
||||
`<healthcheck-name>` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
|
||||
이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: 대형 클러스터에 대한 고려 사항
|
||||
weight: 20
|
||||
---
|
||||
|
|
@ -121,3 +124,6 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일
|
|||
[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는
|
||||
여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
|
||||
노드 수를 실행할 수 있도록 도와준다.
|
||||
|
||||
[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)는
|
||||
클러스터 스케일이 변경될 때 자동으로 애드온 크기를 조정할 수 있도록 도와준다.
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@ card:
|
|||
<!-- steps -->
|
||||
|
||||
## MAC 주소 및 product_uuid가 모든 노드에 대해 고유한지 확인 {#verify-mac-address}
|
||||
|
||||
* 사용자는 `ip link` 또는 `ifconfig -a` 명령을 사용하여 네트워크 인터페이스의 MAC 주소를 확인할 수 있다.
|
||||
* product_uuid는 `sudo cat /sys/class/dmi/id/product_uuid` 명령을 사용하여 확인할 수 있다.
|
||||
|
||||
|
|
@ -239,8 +240,9 @@ CNI 플러그인 설치(대부분의 파드 네트워크에 필요)
|
|||
|
||||
```bash
|
||||
CNI_VERSION="v0.8.2"
|
||||
ARCH="amd64"
|
||||
sudo mkdir -p /opt/cni/bin
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
|
||||
```
|
||||
|
||||
명령어 파일을 다운로드할 디렉터리 정의
|
||||
|
|
@ -259,15 +261,17 @@ crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에
|
|||
|
||||
```bash
|
||||
CRICTL_VERSION="v1.17.0"
|
||||
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
|
||||
ARCH="amd64"
|
||||
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
|
||||
```
|
||||
|
||||
`kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가
|
||||
|
||||
```bash
|
||||
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
|
||||
ARCH="amd64"
|
||||
cd $DOWNLOAD_DIR
|
||||
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
|
||||
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
|
||||
sudo chmod +x {kubeadm,kubelet,kubectl}
|
||||
|
||||
RELEASE_VERSION="v0.4.0"
|
||||
|
|
|
|||
|
|
@ -1,4 +1,9 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
|
||||
content_type: concept
|
||||
weight: 75
|
||||
|
|
@ -20,8 +25,8 @@ weight: 75
|
|||
|
||||
## 시작하기 전에
|
||||
|
||||
* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를
|
||||
포함한 쿠버네티스 클러스터를 생성한다.
|
||||
* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)를
|
||||
포함하는 쿠버네티스 클러스터를 생성한다.
|
||||
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
|
||||
모두 비슷한 방식이라는 것이 중요하다.
|
||||
[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
|
||||
|
|
@ -100,15 +105,15 @@ spec:
|
|||
1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
|
||||
|
||||
* 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
|
||||
* 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
|
||||
* 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을
|
||||
* 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
|
||||
* 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 `curl`을
|
||||
파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
|
||||
* 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
|
||||
핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
|
||||
* 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
|
||||
* 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드와 독립 파드에서 `curl`을 가상 서비스
|
||||
IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다.
|
||||
* 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
|
||||
* 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
|
||||
* 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 컨트롤 플레인 노드에서 NodePort로 `curl`을 실행한다.
|
||||
* 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -178,8 +183,8 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
|
|||
예를 들면, `--register-with-taints='os=windows:NoSchedule'`
|
||||
|
||||
모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여).
|
||||
윈도우 파드가 윈도우 노드에 스케줄링되려면,
|
||||
윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
|
||||
윈도우 파드가 윈도우 노드에 스케줄링되도록 하려면,
|
||||
윈도우 노드가 선택되도록 하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ min-kubernetes-server-version: v1.10
|
|||
1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
|
||||
```
|
||||
|
||||
성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
|
||||
|
|
@ -84,7 +84,7 @@ min-kubernetes-server-version: v1.10
|
|||
2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
|
||||
```
|
||||
|
||||
성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,9 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
title: 윈도우 노드 추가
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_type: tutorial
|
||||
|
|
@ -158,7 +163,7 @@ Install-WindowsFeature -Name containers
|
|||
#### wins, kubelet 및 kubeadm 설치
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
|
||||
```
|
||||
|
||||
|
|
@ -201,7 +206,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates
|
|||
#### wins, kubelet 및 kubeadm 설치
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -128,6 +128,17 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
|
|||
|
||||
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
|
||||
|
||||
명령을 실행한 후에는 컨트롤 플레인 파드를 재시작해야 한다.
|
||||
이는 현재 일부 구성 요소 및 인증서에 대해 인증서를 동적으로 다시 로드하는 것이 지원되지 않기 때문이다.
|
||||
[스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)는 API 서버가 아닌 로컬 kubelet에서 관리되므로
|
||||
kubectl을 사용하여 삭제 및 재시작할 수 없다.
|
||||
스태틱 파드를 다시 시작하려면 `/etc/kubernetes/manifests/`에서 매니페스트 파일을 일시적으로 제거하고
|
||||
20초를 기다리면 된다 ([KubeletConfiguration struct](/docs/
|
||||
reference/config-api/kubelet-config.v1beta1/)의 `fileCheckFrequency` 값을 참고한다).
|
||||
파드가 매니페스트 디렉터리에 더 이상 없는 경우 kubelet은 파드를 종료한다.
|
||||
그런 다음 파일을 다시 이동할 수 있으며 또 다른 `fileCheckFrequency` 기간이 지나면,
|
||||
kubelet은 파드를 생성하고 구성 요소에 대한 인증서 갱신을 완료할 수 있다.
|
||||
|
||||
{{< warning >}}
|
||||
HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다.
|
||||
{{< /warning >}}
|
||||
|
|
|
|||
|
|
@ -9,17 +9,17 @@ weight: 20
|
|||
<!-- overview -->
|
||||
|
||||
이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
|
||||
{{< skew latestVersionAddMinor -1 >}}.x 버전에서 {{< skew latestVersion >}}.x 버전으로,
|
||||
{{< skew latestVersion >}}.x 버전에서 {{< skew latestVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는 경우
|
||||
{{< skew currentVersionAddMinor -1 >}}.x 버전에서 {{< skew currentVersion >}}.x 버전으로,
|
||||
{{< skew currentVersion >}}.x 버전에서 {{< skew currentVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는 경우
|
||||
마이너 버전을 건너뛴다.
|
||||
|
||||
이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
|
||||
이 페이지 대신 다음의 페이지들을 참고한다.
|
||||
|
||||
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -2 >}}에서 {{< skew latestVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -3 >}}에서 {{< skew latestVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -4 >}}에서 {{< skew latestVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -5 >}}에서 {{< skew latestVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
|
||||
추상적인 업그레이드 작업 절차는 다음과 같다.
|
||||
|
||||
|
|
@ -45,19 +45,19 @@ weight: 20
|
|||
|
||||
## 업그레이드할 버전 결정
|
||||
|
||||
OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVersion >}})을 찾는다.
|
||||
OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew currentVersion >}})을 찾는다.
|
||||
|
||||
{{< tabs name="k8s_install_versions" >}}
|
||||
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
|
||||
apt update
|
||||
apt-cache madison kubeadm
|
||||
# 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
|
||||
# {{< skew latestVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
|
||||
# 목록에서 최신 버전({{< skew currentVersion >}})을 찾는다
|
||||
# {{< skew currentVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
|
||||
yum list --showduplicates kubeadm --disableexcludes=kubernetes
|
||||
# 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
|
||||
# {{< skew latestVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
|
||||
# 목록에서 최신 버전({{< skew currentVersion >}})을 찾는다
|
||||
# {{< skew currentVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
|
@ -74,18 +74,18 @@ OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVe
|
|||
|
||||
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
|
||||
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
|
||||
# {{< skew latestVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다.
|
||||
# {{< skew currentVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다.
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
-
|
||||
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
|
||||
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
|
||||
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
|
||||
yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
|
||||
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
|
@ -120,13 +120,13 @@ OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVe
|
|||
|
||||
```shell
|
||||
# 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
|
||||
sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x
|
||||
sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x
|
||||
```
|
||||
|
||||
명령이 완료되면 다음을 확인해야 한다.
|
||||
|
||||
```
|
||||
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy!
|
||||
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy!
|
||||
|
||||
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
|
||||
```
|
||||
|
|
@ -171,20 +171,20 @@ sudo kubeadm upgrade apply
|
|||
{{< tabs name="k8s_install_kubelet" >}}
|
||||
{{< tab name="Ubuntu, Debian 또는 HypriotOS" >}}
|
||||
<pre>>
|
||||
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
|
||||
# {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
-
|
||||
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
|
||||
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
|
||||
</pre>
|
||||
{{< /tab >}}
|
||||
{{< tab name="CentOS, RHEL 또는 Fedora" >}}
|
||||
<pre>
|
||||
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
|
||||
yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
|
||||
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
</pre>
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
|
@ -216,18 +216,18 @@ sudo systemctl restart kubelet
|
|||
|
||||
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
|
||||
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
|
||||
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
|
||||
# {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
-
|
||||
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
|
||||
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
|
||||
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
|
||||
yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
|
||||
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
|
@ -254,18 +254,18 @@ sudo systemctl restart kubelet
|
|||
|
||||
{{< tabs name="k8s_kubelet_and_kubectl" >}}
|
||||
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
|
||||
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
|
||||
# {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
-
|
||||
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
|
||||
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
|
||||
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
|
||||
yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
|
||||
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: 네트워크 폴리시로 실리움(Cilium) 사용하기
|
||||
content_type: task
|
||||
weight: 20
|
||||
|
|
@ -22,44 +25,59 @@ weight: 20
|
|||
|
||||
실리움에 쉽게 친숙해지기 위해
|
||||
Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
|
||||
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
|
||||
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)를 따라 해볼 수 있다.
|
||||
|
||||
Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고,
|
||||
Minikube를 시작하려면 최소 버전으로 >= v1.5.2 가 필요하고,
|
||||
다음의 실행 파라미터로 실행한다.
|
||||
|
||||
```shell
|
||||
minikube version
|
||||
```
|
||||
```
|
||||
minikube version: v1.3.1
|
||||
minikube version: v1.5.2
|
||||
```
|
||||
|
||||
```shell
|
||||
minikube start --network-plugin=cni --memory=4096
|
||||
minikube start --network-plugin=cni
|
||||
```
|
||||
|
||||
BPF 파일시스템을 마운트한다
|
||||
minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다.
|
||||
실리움은 클러스터 구성을 자동으로 감지하고
|
||||
성공적인 설치를 위해 적절한 구성 요소를 설치한다.
|
||||
|
||||
```shell
|
||||
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
|
||||
curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
|
||||
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
|
||||
rm cilium-linux-amd64.tar.gz
|
||||
cilium install
|
||||
```
|
||||
|
||||
Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을
|
||||
간단한 ``올인원`` YAML 파일로 배포할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
|
||||
```
|
||||
```
|
||||
configmap/cilium-config created
|
||||
serviceaccount/cilium created
|
||||
serviceaccount/cilium-operator created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium-operator created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
|
||||
daemonset.apps/cilium create
|
||||
deployment.apps/cilium-operator created
|
||||
🔮 Auto-detected Kubernetes kind: minikube
|
||||
✨ Running "minikube" validation checks
|
||||
✅ Detected minikube version "1.20.0"
|
||||
ℹ️ Cilium version not set, using default version "v1.10.0"
|
||||
🔮 Auto-detected cluster name: minikube
|
||||
🔮 Auto-detected IPAM mode: cluster-pool
|
||||
🔮 Auto-detected datapath mode: tunnel
|
||||
🔑 Generating CA...
|
||||
2021/05/27 02:54:44 [INFO] generate received request
|
||||
2021/05/27 02:54:44 [INFO] received CSR
|
||||
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
|
||||
2021/05/27 02:54:44 [INFO] encoded CSR
|
||||
2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
|
||||
🔑 Generating certificates for Hubble...
|
||||
2021/05/27 02:54:44 [INFO] generate received request
|
||||
2021/05/27 02:54:44 [INFO] received CSR
|
||||
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
|
||||
2021/05/27 02:54:44 [INFO] encoded CSR
|
||||
2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
|
||||
🚀 Creating Service accounts...
|
||||
🚀 Creating Cluster roles...
|
||||
🚀 Creating ConfigMap...
|
||||
🚀 Creating Agent DaemonSet...
|
||||
🚀 Creating Operator Deployment...
|
||||
⌛ Waiting for Cilium to be installed...
|
||||
```
|
||||
|
||||
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
|
||||
|
|
@ -82,14 +100,14 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, H
|
|||
파드의 목록을 보려면 다음을 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
kubectl get pods --namespace=kube-system -l k8s-app=cilium
|
||||
```
|
||||
|
||||
다음과 유사한 파드의 목록을 볼 것이다.
|
||||
|
||||
```console
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-6rxbd 1/1 Running 0 1m
|
||||
cilium-kkdhz 1/1 Running 0 3m23s
|
||||
...
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ kubectl create secret generic db-user-pass \
|
|||
다음 커맨드를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic dev-db-secret \
|
||||
kubectl create secret generic db-user-pass \
|
||||
--from-literal=username=devuser \
|
||||
--from-literal=password='S!B\*d$zDsb='
|
||||
```
|
||||
|
|
|
|||
|
|
@ -11,6 +11,8 @@ weight: 10
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 데몬셋 업데이트 전략
|
||||
|
|
|
|||
Loading…
Reference in New Issue