Merge pull request #34056 from jihoon-seo/220531_ko_Update_outdated_dev-1.24-ko.1_M89
[ko] Update outdated files in `dev-1.24-ko.1` (M89-M98)
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
b54657cb1c
|
|
@ -8,21 +8,21 @@ weight: 20
|
|||
---
|
||||
<!-- overview -->
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
파드가 노드에서 실행될 수 있도록 클러스터의 각 노드에
|
||||
{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을
|
||||
설치해야 한다. 이 페이지에서는 관련된 항목을 설명하고
|
||||
노드 설정 관련 작업을 설명한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
쿠버네티스 {{< skew currentVersion >}}에서는
|
||||
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는
|
||||
런타임을 사용해야 한다.
|
||||
|
||||
더 자세한 정보는 [CRI 버전 지원](#cri-versions)을 참조한다.
|
||||
|
||||
이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한
|
||||
세부 정보가 있다.
|
||||
이 페이지는 쿠버네티스에서
|
||||
여러 공통 컨테이너 런타임을 사용하는 방법에 대한 개요를 제공한다.
|
||||
|
||||
- [containerd](#containerd)
|
||||
- [CRI-O](#cri-o)
|
||||
|
|
@ -30,12 +30,27 @@ weight: 20
|
|||
- [미란티스 컨테이너 런타임](#mcr)
|
||||
|
||||
{{< note >}}
|
||||
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
|
||||
쿠버네티스 v1.24 이전 릴리스는
|
||||
_dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 통합을 지원했다.
|
||||
이 특별한 직접 통합은
|
||||
더 이상 쿠버네티스에 포함되지 않는다(이 제거는
|
||||
v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다).
|
||||
이 제거가 어떻게 영향을 미치는지 알아보려면
|
||||
[Dockershim 사용 중단이 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) 문서를 확인한다.
|
||||
dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면,
|
||||
[dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다.
|
||||
|
||||
v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 있다면,
|
||||
해당 버전의 문서를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## cgroup 드라이버
|
||||
|
||||
Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다.
|
||||
리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은
|
||||
프로세스에 할당된 리소스를 제한하는데 사용된다.
|
||||
|
||||
리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인
|
||||
경우, init 프로세스는 root control group(`cgroup`)을
|
||||
|
|
@ -64,7 +79,7 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
|
|||
교체하거나, 자동화를 사용하여 다시 설치한다.
|
||||
{{< /caution >}}
|
||||
|
||||
## cgroup v2
|
||||
### Cgroup 버전 2 {#cgroup-v2}
|
||||
|
||||
cgroup v2는 cgroup Linux API의 다음 버전이다.
|
||||
cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다.
|
||||
|
|
@ -102,8 +117,8 @@ cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야
|
|||
|
||||
### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기
|
||||
|
||||
kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
|
||||
[변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
|
||||
기존에 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면,
|
||||
[cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
|
||||
|
||||
## CRI 버전 지원 {#cri-versions}
|
||||
|
||||
|
|
@ -120,95 +135,47 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
|
|||
|
||||
### containerd
|
||||
|
||||
이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
|
||||
이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계를 간략하게 설명한다.
|
||||
|
||||
다음 명령을 사용하여 시스템에 containerd를 설치한다.
|
||||
|
||||
필수 구성 요소를 설치 및 구성한다.
|
||||
1. 필수 구성 요소를 설치 및 구성한다.
|
||||
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
# 재부팅하지 않고 sysctl 파라미터 적용
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
containerd를 설치한다.
|
||||
|
||||
{{< tabs name="tab-cri-containerd-installation" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다.
|
||||
각 리눅스 배포판에 대한 도커 리포지터리를 설정하고
|
||||
`containerd.io` 패키지를 설치하는 방법은
|
||||
[도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다.
|
||||
|
||||
2. containerd 설정
|
||||
(이 지침은 리눅스 노드에만 적용된다)
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
# 재부팅하지 않고 sysctl 파라미터 적용
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
3. containerd 재시작
|
||||
1. containerd를 설치한다.
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
[containerd 시작하기](https://github.com/containerd/containerd/blob/main/docs/getting-started.md)
|
||||
문서를 확인하고,
|
||||
유효한 환경 설정 파일(`config.toml`)을 작성하는 부분까지의
|
||||
가이드를 따른다.
|
||||
리눅스에서, 이 파일은 `/etc/containerd/config.toml`에 존재한다.
|
||||
윈도우에서, 이 파일은 `C:\Program Files\containerd\config.toml`에 존재한다.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows (PowerShell)" %}}
|
||||
리눅스에서, containerd를 위한 기본 CRI 소켓은 `/run/containerd/containerd.sock`이다.
|
||||
윈도우에서, 기본 CRI 엔드포인트는 `npipe://./pipe/containerd-containerd`이다.
|
||||
|
||||
PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
|
||||
설정(예: `$Version:"1.4.3"`)한 후 다음 명령을 실행한다.
|
||||
|
||||
1. containerd 다운로드
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
2. 추출과 설정
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
#### `systemd` cgroup 드라이버의 사용 {#containerd-systemd}
|
||||
#### `systemd` cgroup 드라이버 환경 설정하기 {#containerd-systemd}
|
||||
|
||||
`/etc/containerd/config.toml` 의 `systemd` cgroup 드라이버를 `runc` 에서 사용하려면, 다음과 같이 설정한다.
|
||||
|
||||
|
|
@ -219,7 +186,7 @@ PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
|
|||
SystemdCgroup = true
|
||||
```
|
||||
|
||||
이 변경 사항을 적용하는 경우 containerd를 재시작한다.
|
||||
이 변경 사항을 적용하려면, containerd를 재시작한다.
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
|
|
@ -232,176 +199,14 @@ kubeadm을 사용하는 경우,
|
|||
|
||||
이 섹션은 CRI-O를 컨테이너 런타임으로 설치하는 필수적인 단계를 담고 있다.
|
||||
|
||||
시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다.
|
||||
|
||||
{{< note >}}
|
||||
CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 버전이 일치해야 한다.
|
||||
더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes)를 본다.
|
||||
{{< /note >}}
|
||||
|
||||
필수 구성 요소를 설치하고 구성한다.
|
||||
|
||||
```shell
|
||||
# .conf 파일을 만들어 부팅 시 모듈을 로드한다
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅 간에도 유지된다.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
{{< tabs name="tab-cri-cri-o-installation" >}}
|
||||
{{% tab name="Debian" %}}
|
||||
|
||||
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를
|
||||
아래의 표에서 적절한 필드로 설정한다.
|
||||
|
||||
| 운영 체제 | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Debian Unstable | `Debian_Unstable` |
|
||||
| Debian Testing | `Debian_Testing` |
|
||||
|
||||
<br />
|
||||
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
|
||||
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
|
||||
사용자의 설치를 특정 릴리스에 고정할 수 있다.
|
||||
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
|
||||
<br />
|
||||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
|
||||
EOF
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Ubuntu" %}}
|
||||
|
||||
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를
|
||||
아래의 표에서 적절한 필드로 설정한다.
|
||||
|
||||
| 운영 체제 | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Ubuntu 20.04 | `xUbuntu_20.04` |
|
||||
| Ubuntu 19.10 | `xUbuntu_19.10` |
|
||||
| Ubuntu 19.04 | `xUbuntu_19.04` |
|
||||
| Ubuntu 18.04 | `xUbuntu_18.04` |
|
||||
|
||||
<br />
|
||||
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
|
||||
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
|
||||
사용자의 설치를 특정 릴리스에 고정할 수 있다.
|
||||
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
|
||||
<br />
|
||||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
|
||||
EOF
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -
|
||||
|
||||
apt-get update
|
||||
apt-get install cri-o cri-o-runc
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="CentOS" %}}
|
||||
|
||||
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를
|
||||
아래의 표에서 적절한 필드로 설정한다.
|
||||
|
||||
| 운영 체제 | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Centos 8 | `CentOS_8` |
|
||||
| Centos 8 Stream | `CentOS_8_Stream` |
|
||||
| Centos 7 | `CentOS_7` |
|
||||
|
||||
<br />
|
||||
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
|
||||
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
|
||||
사용자의 설치를 특정 릴리스에 고정할 수 있다.
|
||||
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
|
||||
<br />
|
||||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
|
||||
sudo yum install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="openSUSE Tumbleweed" %}}
|
||||
|
||||
```shell
|
||||
sudo zypper install cri-o
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Fedora" %}}
|
||||
|
||||
`$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
|
||||
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
|
||||
|
||||
사용할 수 있는 버전을 찾으려면 다음을 실행한다.
|
||||
```shell
|
||||
sudo dnf module list cri-o
|
||||
```
|
||||
CRI-O는 Fedora에서 특정 릴리스를 고정하여 설치하는 방법은 지원하지 않는다.
|
||||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
sudo dnf module enable cri-o:$VERSION
|
||||
sudo dnf install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
CRI-O를 시작한다.
|
||||
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable crio --now
|
||||
```
|
||||
|
||||
자세한 사항은 [CRI-O 설치 가이드](https://github.com/cri-o/cri-o/blob/master/install.md)를
|
||||
참고한다.
|
||||
|
||||
CRI-O를 설치하려면, [CRI-O 설치 방법](https://github.com/cri-o/cri-o/blob/main/install.md#readme)을 따른다.
|
||||
|
||||
#### cgroup 드라이버
|
||||
|
||||
CRI-O는 기본적으로 systemd cgroup 드라이버를 사용한다. `cgroupfs` cgroup 드라이버로
|
||||
전환하려면, `/etc/crio/crio.conf` 를 수정하거나 `/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에
|
||||
드롭-인(drop-in) 구성을 배치한다. 예를 들면, 다음과 같다.
|
||||
CRI-O는 기본적으로 systemd cgroup 드라이버를 사용하며, 이는 대부분의 경우에 잘 동작할 것이다.
|
||||
`cgroupfs` cgroup 드라이버로 전환하려면, `/etc/crio/crio.conf` 를 수정하거나
|
||||
`/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에 드롭-인(drop-in) 구성을 배치한다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
```toml
|
||||
[crio.runtime]
|
||||
|
|
@ -410,27 +215,27 @@ cgroup_manager = "cgroupfs"
|
|||
```
|
||||
|
||||
또한 `cgroupfs` 와 함께 CRI-O를 사용할 때 `pod` 값으로 설정해야 하는
|
||||
변경된 `conmon_cgroup` 에 유의한다. 일반적으로 kubelet(일반적으로 kubeadm을 통해 수행됨)과
|
||||
변경된 `conmon_cgroup` 에 유의해야 한다. 일반적으로 kubelet(일반적으로 kubeadm을 통해 수행됨)과
|
||||
CRI-O의 cgroup 드라이버 구성을 동기화 상태로
|
||||
유지해야 한다.
|
||||
|
||||
CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
|
||||
|
||||
### 도커 엔진 {#docker}
|
||||
|
||||
도커 엔진은 모든 것을 시작한 컨테이너 런타임이다.
|
||||
이전에는 간단히 도커로 알려졌던 이 컨테이너 런타임은 다양한 형태로 사용할 수 있다.
|
||||
[도커 엔진 설치하기](https://docs.docker.com/engine/install/)에서
|
||||
이 런타임 설치의 옵션들을 확인할 수 있다.
|
||||
{{< note >}}
|
||||
아래의 지침은
|
||||
당신이 도커 엔진과 쿠버네티스를 통합하는 데
|
||||
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 어댑터를 사용하고 있다고 가정한다.
|
||||
{{< /note >}}
|
||||
|
||||
도커 엔진은 쿠버네티스 {{< skew currentVersion >}}와 직접 호환되며, 이는 사용 중단된 `dockershim` 컴포넌트를 활용하기 때문에 가능하다.
|
||||
더 많은 정보와 맥락을 보려면, [Dockershim 사용 중단 FAQ](/dockershim)를 참고한다.
|
||||
1. 각 노드에서, [도커 엔진 설치하기](https://docs.docker.com/engine/install/#server)에 따라
|
||||
리눅스 배포판에 맞게 도커를 설치한다.
|
||||
|
||||
지원되는 {{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를 통해
|
||||
쿠버네티스에서 도커 엔진을 사용할 수 있게 해 주는
|
||||
써드파티 어댑터를 찾아볼 수도 있다.
|
||||
2. [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 소스 코드 저장소의 지침대로
|
||||
`cri-dockerd`를 설치한다.
|
||||
|
||||
다음 CRI 어댑터는 도커 엔진과 함께 동작하도록 설계되었다.
|
||||
|
||||
- 미란티스의 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)
|
||||
`cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다.
|
||||
|
||||
### 미란티스 컨테이너 런타임 {#mcr}
|
||||
|
||||
|
|
@ -439,3 +244,14 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
|
|||
|
||||
오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며,
|
||||
이 컴포넌트는 MCR에 포함되어 있다.
|
||||
|
||||
미란티스 컨테이너 런타임을 설치하는 방법에 대해 더 알아보려면,
|
||||
[MCR 배포 가이드](https://docs.mirantis.com/mcr/20.10/install.html)를 참고한다.
|
||||
|
||||
CRI 소켓의 경로를 찾으려면
|
||||
`cri-docker.socket`라는 이름의 systemd 유닛을 확인한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
컨테이너 런타임과 더불어, 클러스터에는
|
||||
동작하는 [네트워크 플러그인](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)도 필요하다.
|
||||
|
|
|
|||
|
|
@ -231,7 +231,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/overview/)에 대해 더 알아보기.
|
||||
* 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/)에 대해 더 알아보기.
|
||||
* 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 `kops` [고급 사용법](https://kops.sigs.k8s.io/)에 대해 더 자세히 알아본다.
|
||||
* 슬랙(Slack)에서 `kops` 커뮤니티 토론을 할 수 있다: [커뮤니티 토론](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
|
||||
* 문제를 해결하거나 이슈를 제기하여 `kops` 에 기여한다. [깃헙 이슈](https://github.com/kubernetes/kops/issues)
|
||||
|
|
|
|||
|
|
@ -24,9 +24,12 @@ kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지
|
|||
더 자세한 사항은 [kubeadm에서 초기화 단계 사용하기](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)을 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
{{< note >}}
|
||||
이미 생성된 클러스터를 다시 구성하려면
|
||||
[kubeadm 클러스터 다시 구성하기](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="stable" >}}
|
||||
<!-- body -->
|
||||
|
||||
## `ClusterConfiguration`의 플래그로 컨트롤 플레인 사용자 정의하기
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,6 @@ card:
|
|||
이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm을 사용하여 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
|
|
@ -69,61 +68,69 @@ sudo sysctl --system
|
|||
## 필수 포트 확인 {#check-required-ports}
|
||||
[필수 포트들](/ko/docs/reference/ports-and-protocols/)은
|
||||
쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
|
||||
한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다.
|
||||
한다. 다음과 같이 netcat과 같은 도구를 이용하여 포트가 열려 있는지 확인해 볼 수 있다.
|
||||
|
||||
```shell
|
||||
telnet 127.0.0.1 6443
|
||||
nc 127.0.0.1 6443
|
||||
```
|
||||
|
||||
사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도
|
||||
있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한
|
||||
플러그인 문서를 참고한다.
|
||||
|
||||
## 런타임 설치 {#installing-runtime}
|
||||
## 컨테이너 런타임 설치 {#installing-runtime}
|
||||
|
||||
파드에서 컨테이너를 실행하기 위해, 쿠버네티스는
|
||||
{{< glossary_tooltip term_id="container-runtime" text="컨테이너 런타임" >}}을 사용한다.
|
||||
|
||||
{{< tabs name="container_runtime" >}}
|
||||
{{% tab name="리눅스 노드" %}}
|
||||
|
||||
기본적으로, 쿠버네티스는
|
||||
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를
|
||||
사용하여 사용자가 선택한 컨테이너 런타임과 인터페이스한다.
|
||||
|
||||
런타임을 지정하지 않으면, kubeadm은 잘 알려진 유닉스 도메인 소켓 목록을 검색하여
|
||||
런타임을 지정하지 않으면, kubeadm은 잘 알려진 엔드포인트를 스캐닝하여
|
||||
설치된 컨테이너 런타임을 자동으로 감지하려고 한다.
|
||||
다음 표에는 컨테이너 런타임 및 관련 소켓 경로가 나열되어 있다.
|
||||
|
||||
{{< table caption = "컨테이너 런타임과 소켓 경로" >}}
|
||||
| 런타임 | 유닉스 도메인 소켓 경로 |
|
||||
|------------|-----------------------------------|
|
||||
| 도커 | `/var/run/dockershim.sock` |
|
||||
| containerd | `/run/containerd/containerd.sock` |
|
||||
| CRI-O | `/var/run/crio/crio.sock` |
|
||||
컨테이너 런타임이 여러 개 감지되거나 하나도 감지되지 않은 경우,
|
||||
kubeadm은 에러를 반환하고 사용자가 어떤 것을 사용할지를 명시하도록 요청할 것이다.
|
||||
|
||||
더 많은 정보는
|
||||
[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 참고한다.
|
||||
|
||||
{{< note >}}
|
||||
도커 엔진은 컨테이너 런타임이 쿠버네티스와 호환되기 위한 요구 사항인
|
||||
[CRI](/docs/concepts/architecture/cri/)를 만족하지 않는다.
|
||||
이러한 이유로, 추가 서비스인 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)가 설치되어야 한다.
|
||||
cri-dockerd는 쿠버네티스 버전 1.24부터 kubelet에서 [제거](/dockershim)된
|
||||
기존 내장 도커 엔진 지원을 기반으로 한 프로젝트이다.
|
||||
{{< /note >}}
|
||||
|
||||
아래 표는 지원 운영 체제에 대한 알려진 엔드포인트를 담고 있다.
|
||||
|
||||
{{< tabs name="container_runtime" >}}
|
||||
{{% tab name="리눅스" %}}
|
||||
|
||||
{{< table >}}
|
||||
| 런타임 | 유닉스 도메인 소켓 경로 |
|
||||
|------------------------------------|----------------------------------------------|
|
||||
| containerd | `unix:///var/run/containerd/containerd.sock` |
|
||||
| CRI-O | `unix:///var/run/crio/crio.sock` |
|
||||
| 도커 엔진 (cri-dockerd 사용) | `unix:///var/run/cri-dockerd.sock` |
|
||||
{{< /table >}}
|
||||
|
||||
<br />
|
||||
도커와 containerd가 모두 감지되면 도커가 우선시된다. 이것이 필요한 이유는 도커 18.09에서
|
||||
도커만 설치한 경우에도 containerd와 함께 제공되므로 둘 다 감지될 수 있기
|
||||
때문이다.
|
||||
다른 두 개 이상의 런타임이 감지되면, kubeadm은 오류와 함께 종료된다.
|
||||
|
||||
kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다.
|
||||
|
||||
자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을
|
||||
참고한다.
|
||||
{{% /tab %}}
|
||||
{{% tab name="다른 운영 체제" %}}
|
||||
기본적으로, kubeadm은 컨테이너 런타임으로 {{< glossary_tooltip term_id="docker" >}}를 사용한다.
|
||||
kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다.
|
||||
|
||||
자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을
|
||||
참고한다.
|
||||
{{% tab name="윈도우" %}}
|
||||
|
||||
{{< table >}}
|
||||
| 런타임 | 윈도우 네임드 파이프(named pipe) 경로 |
|
||||
|------------------------------------|----------------------------------------------|
|
||||
| containerd | `npipe:////./pipe/containerd-containerd` |
|
||||
| 도커 엔진 (cri-dockerd 사용) | `npipe:////./pipe/cri-dockerd` |
|
||||
{{< /table >}}
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm, kubelet 및 kubectl 설치
|
||||
|
||||
모든 머신에 다음 패키지들을 설치한다.
|
||||
|
|
@ -217,6 +224,10 @@ sudo systemctl enable --now kubelet
|
|||
|
||||
- 구성 방법을 알고 있는 경우 SELinux를 활성화된 상태로 둘 수 있지만 kubeadm에서 지원하지 않는 설정이 필요할 수 있다.
|
||||
|
||||
- 사용 중인 레드햇 배포판이 `basearch`를 해석하지 못하여 `baseurl`이 실패하면, `\$basearch`를 당신의 컴퓨터의 아키텍처로 치환한다.
|
||||
`uname -m` 명령을 실행하여 해당 값을 확인한다.
|
||||
예를 들어, `x86_64`에 대한 `baseurl` URL은 `https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64` 이다.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="패키지 매니저를 사용하지 않는 경우" %}}
|
||||
CNI 플러그인 설치(대부분의 파드 네트워크에 필요)
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ weight: 75
|
|||
포함하는 쿠버네티스 클러스터를 생성한다.
|
||||
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
|
||||
모두 비슷한 방식이라는 것이 중요하다.
|
||||
[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
|
||||
[Kubectl 커맨드](/ko/docs/reference/kubectl/)로 클러스터에 접속하는 것은 동일하다.
|
||||
아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다.
|
||||
|
||||
## 시작하기: 윈도우 컨테이너 배포하기
|
||||
|
|
@ -160,21 +160,28 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
|
|||
노드셀렉터(nodeSelector)의 조합을 이용해야 한다.
|
||||
이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데,
|
||||
이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
|
||||
{{< note >}}
|
||||
|
||||
|
||||
`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면,
|
||||
파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다).
|
||||
리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다.
|
||||
윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을
|
||||
`windows`로 설정한다.
|
||||
|
||||
스케줄러는 파드를 노드에 할당할 때 `.spec.os.name` 필드의 값을 사용하지 않는다.
|
||||
{{< note >}}
|
||||
1.24부터, `IdentifyPodOS` 기능은 베타 단계이며 기본적으로 활성화되어 있다.
|
||||
{{< /note >}}
|
||||
|
||||
스케줄러는 파드를 노드에 할당할 때
|
||||
`.spec.os.name` 필드의 값을 사용하지 않는다.
|
||||
컨트롤 플레인이 파드를 적절한 운영 체제가 실행되고 있는 노드에 배치하도록 하려면,
|
||||
[파드를 노드에 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)하는
|
||||
일반적인 쿠버네티스 메카니즘을 사용해야 한다.
|
||||
|
||||
`.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에,
|
||||
윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트,
|
||||
톨러레이션 및 노드 셀렉터가 여전히 필요하다.
|
||||
{{< /note >}}
|
||||
|
||||
### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
|
||||
|
||||
사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다.
|
||||
|
|
|
|||
|
|
@ -27,8 +27,8 @@ kubectl config view
|
|||
```
|
||||
|
||||
[여기](/ko/docs/reference/kubectl/cheatsheet/)에서
|
||||
kubectl 사용 예시를 볼 수 있으며, 완전한 문서는
|
||||
[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 확인할 수 있다.
|
||||
`kubectl` 사용 예시를 볼 수 있으며, 완전한 문서는
|
||||
[kubectl 레퍼런스](/ko/docs/reference/kubectl/)에서 확인할 수 있다.
|
||||
|
||||
## REST API에 직접 접근
|
||||
|
||||
|
|
@ -86,12 +86,36 @@ curl http://localhost:8080/api/
|
|||
|
||||
### kubectl proxy를 사용하지 않음
|
||||
|
||||
기본 서비스 어카운트의 토큰을 얻어내려면 `kubectl describe secret...`을 grep/cut과 함께 사용한다.
|
||||
`kubectl apply` 및 `kubectl describe secret...` 명령과 grep/cut을 활용하여 기본 서비스 어카운트의 토큰을 생성한다.
|
||||
|
||||
먼저, 기본 서비스어카운트를 위한 토큰을 요청하는 시크릿을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: default-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: default
|
||||
type: kubernetes.io/service-account-token
|
||||
EOF
|
||||
```
|
||||
|
||||
다음으로, 토큰 컨트롤러가 해당 시크릿에 토큰을 채우기를 기다린다.
|
||||
|
||||
```shell
|
||||
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
|
||||
echo "waiting for token..." >&2
|
||||
sleep 1
|
||||
done
|
||||
```
|
||||
|
||||
결과를 캡처하여 생성된 토큰을 사용한다.
|
||||
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
|
||||
SECRET_NAME=$(kubectl get secrets | grep ^default | cut -f1 -d ' ')
|
||||
TOKEN=$(kubectl describe secret $SECRET_NAME | grep -E '^token' | cut -f2 -d':' | tr -d " ")
|
||||
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")
|
||||
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
```
|
||||
|
|
@ -117,8 +141,7 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
|||
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
SECRET_NAME=$(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}')
|
||||
TOKEN=$(kubectl get secret $SECRET_NAME -o jsonpath='{.data.token}' | base64 --decode)
|
||||
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
|
||||
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
```
|
||||
|
|
@ -181,40 +204,17 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와
|
|||
|
||||
## 파드에서 API 접근
|
||||
|
||||
파드에서 API를 접속한다면 apiserver의
|
||||
위치지정과 인증은 다소 다르다.
|
||||
파드에서 API에 접근하는 경우,
|
||||
API 서버를 찾고 인증하는 방식이 약간 다를 수 있다.
|
||||
|
||||
파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은
|
||||
`kubernetes.default.svc` DNS 네임을 사용하는 것이다.
|
||||
이 DNS 네임은 apiserver로 라우팅되는 서비스 IP로 resolve된다.
|
||||
|
||||
apiserver 인증에 추천되는 방식은
|
||||
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며
|
||||
해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/token`에 위치한다.
|
||||
|
||||
사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며
|
||||
apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
|
||||
|
||||
마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 파일로 존재한다.
|
||||
|
||||
파드 내에서 API에 접근하는데 권장되는 방식은 다음과 같다.
|
||||
|
||||
- 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나,
|
||||
컨테이너 내부에서 백그라운드 프로세스로 실행한다.
|
||||
이는 쿠버네티스 API를 파드의 localhost 인터페이스로 프록시하여
|
||||
해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다.
|
||||
- Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다.
|
||||
이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
|
||||
|
||||
각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다.
|
||||
더 자세한 내용은
|
||||
[파드 내에서 쿠버네티스 API에 접근](/ko/docs/tasks/run-application/access-api-from-pod/)을 참조한다.
|
||||
|
||||
## 클러스터에서 실행되는 서비스로 접근
|
||||
|
||||
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다.
|
||||
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다.
|
||||
쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은
|
||||
[클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다.
|
||||
|
||||
## redirect 요청하기
|
||||
|
||||
|
|
|
|||
|
|
@ -240,13 +240,13 @@ storage-provisioner 1/1 Running 0 2m
|
|||
하단에 다음 줄을 추가한다.
|
||||
|
||||
```yaml
|
||||
- path: /v2
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: web2
|
||||
port:
|
||||
number: 8080
|
||||
- path: /v2
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: web2
|
||||
port:
|
||||
number: 8080
|
||||
```
|
||||
|
||||
1. 변경 사항을 적용한다.
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
title: 쿠버네티스 대시보드를 배포하고 접속하기
|
||||
description: >-
|
||||
웹 UI(쿠버네티스 대시보드)를 배포하고 접속한다.
|
||||
|
|
@ -35,7 +37,7 @@ card:
|
|||
대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다.
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
## 대시보드 UI 접근
|
||||
|
|
|
|||
Loading…
Reference in New Issue