DNS

우리는 인터넷 브라우저를 사용하여 웹페이지에 접근 할 때 문자열을 가진 도메인으로 접근을 하는데, 이러한 도메인은 각각의 고유 주소인 IP를 가지고 있습니다.

이때 도메인을 통해 해당 고유주소인 IP로 접근 할 수 있게 끔 도와주는 기능이 DNS 입니다.

DNS는 Domain Name System 약자로 간단하게 풀어나가면

치킨(웹페이지)을(를) 시키고(접속하고)싶은데 가게이름(도메인)은 알고 있지만, 전화번호(IP)를 알 수 없어서 114(DNS Server)에 물어봐서 전화번호(IP)를 알아낸다고 보면 됩니다.

DNS Server에 질의하여 IP를 알아내는 전체적인 과정은 아래와 같습니다.

www.asdfzxcv.site 이라는 A레코드 타입의 도메인에 접근을 예로 들겠습니다.

1. 사용자가 웹 브라우저에서 www.asdfzxcv.site 라는 도메인으로 접근

2. 웹 브라우저는 받은 도메인을 DNS 클라이언트에게 전달
3. DNS 클라이언트가 로컬(공용) DNS 서버로 요청을 보냄

4. 로컬(공용) DNS 서버가 캐시 확인
5. 캐시에 없으면 루트 네임서버로 요청을 보냄
6. 루트 네임서버가 TLD 네임서버의 주소를 반환
7. TLD 네임서버가 SLD 네임서버의 주소를 반환
8. SLD 네임서버가 요청된 도메인의 IP 주소를 반환
9. IP 주소가 로컬(공용) DNS 서버로 리턴
10. 로컬(공용) DNS 서버가 IP 주소를 캐시에 저장한 후 DNS 클라이언트로 반환
11. DNS 클라이언트가 IP 주소를 사용자의 브라우저로 제공
12. 사용자의 브라우저가 IP 주소를 사용해 원하는 웹사이트로 접근

* 로컬 DNS :  KT,SK,LG 같은 ISP 혹은 사내망 등에서 운영하는 DNS 서버로서, 전체가 아닌 특정 사용자들만 사용 가능

* 공용 DNS : 모든 사용자들이 사용이 가능한 도메인 서버로, 대표적으로 구글 (8.8.8.8), Cloudflare (1.1.1.1) 등

* SLD 네임서버 : DNS 레코드 관리 및 DNS 응답

* TLD 네임서버 : SLD 네임 서버의 정보 제공

* 루트 네임서버 : TLD 네임 서버의 정보 제공 

직접적으로 확인을 해보고 싶다면, 아래처럼 진행해봅시다.

#Windows에서는 별도 설치가 필요
$ dig www.asdfzxcv.site +trace

1. 구글 DNS가 루트 네임 서버에게(*.root-servers.net.) 질의합니다.

2. l.root-servers.net. 라는 루트 네임 서버에서 .site 라는 도메인을 관리하는 TLD 네임 서버(*.nic.site.)로 다시 질의를 합니다. 

3. b.nic.site 라는 TLD 네임 서버에서 asdfzxcv.site를 관리하는 SLD 네임 서버(*.gabia.*.)로 다시 질의를 합니다.

4. ns.gabia.net 라는 네임 서버에서 해당 URL에 대한 IP를 반환합니다.

위 같은 과정을 거친 이후 해당 도메인으로 접근을 하게 됩니다.

DNS 레코드

전화번호에는 일반 유선도 있고, 팩스용 번호도 있고, 인터넷 전화도 있고 종류가 다양합니다.

DNS 레코드 또한 이러한 목적성을 가진 도메인을 저장하는 데이터베이스들의 종류입니다.

대표적으로 사용되는 레코드 타입이 A, CNAME, MX 정도 입니다.

1. A 레코드 (Address Record):

도메인 이름을 IPv4 주소로 매핑합니다.

2. AAAA 레코드 (IPv6 Address Record):

도메인 이름을 IPv6 주소로 매핑합니다.

3. CNAME 레코드 (Canonical Name Record):

도메인 이름을 별칭으로 다른 도메인 이름에 매핑합니다.

4. MX 레코드 (Mail Exchange Record):

도메인 이름에 대한 이메일 서버를 지정합니다.

5. TXT 레코드 (Text Record):

도메인 이름에 대한 텍스트 정보를 저장합니다. SPF(Sender Policy Framework)와 같은 인증 메커니즘에 사용됩니다.

NS 레코드 (Name Server Record):

도메인 이름의 네임 서버를 지정합니다.

PTR 레코드 (Pointer Record):

IP 주소를 도메인 이름으로 매핑합니다. 주로 역방향 DNS 조회에 사용됩니다.

SRV 레코드 (Service Record):

특정 서비스를 제공하는 서버의 위치를 지정합니다.
예: _sip._tcp.example.com → sipserver.example.com:5060

SOA 레코드 (Start of Authority Record):

도메인 존 파일의 시작을 나타내며, 관리자 이메일 주소, 도메인 기본 네임 서버, 존 파일의 시리얼 번호 등을 포함합니다.

1. 설치

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod +x get_helm.sh
$ ./get_helm.sh

# 심볼릭
$ ln -s /usr/local/bin/helm /usr/bin/helm

# 혹은 /etc/profile에 path 추가
$ echo "export PATH=\$PATH:/usr/local/bin" >> /etc/profile
$ source /etc/profile

명령어 자동 완성 추가하기

# 현재 사용중인 세션
$ source <(helm completion bash)

# 새로운 세션 연결시
$ helm completion bash > /etc/bash_completion.d/helm

설치를 완료했으니, 필요한 패키지를 설치하기 위한 저장소가 필요합니다.

https://artifacthub.io/

페이지에서 설치가 필요한 패키지를 검색합시다.

저는 예시로 nginx 를 사용할거고, bitnami 저장소를 이용하겠습니다.

박스 모양에 커서를 갖다대면 repo URL이 나오는데 복사합시다.

해당 URL로 repo 추가를 합시다.

# Repo 추가
$ helm repo add bitnami https://charts.bitnami.com/bitnami

# Repo 패키지 리스트 업데이트
# yum 혹은 apt 같은 패키지 관리자의 update 기능이라고 생각하시면 편합니다.
$ helm repo update

저장소 추가 후에 검색해보면 잘 나옵니다.

설치 방법은 이전의 사이트에서 install 를 클릭하면 확인 할 수 있고, 하단의 See all을 누르면 배포 패키지의 버전 리스트를 확인 할 수 있습니다.

해당 페이지에서 안내하는 install 방법은 아래와 같습니다.

helm install은 helm install [NAME] [CHART] [flags] 순이며, 차트를 참조하거나 디렉토리를 직접적으로 참조 할 수도 있습니다.

$ helm install my-nginx bitnami/nginx --version 18.1.7

# ex 예시
# 차트 참조 : helm install $(my-nginx) nginx/nginx
# 패키지 차트 경로 : helm install $(my-nginx) ./nginx-1.2.3.tgz
# 압축을 푼 차트 디렉토리 경로 : helm install $(my-nginx) ./nginx
# 절대 URL : helm install $(my-nginx) https://example.com/charts/nginx-1.2.3.tgz
# 차트 참조 및 저장소 URL : helm install --repo https://example.com/charts/ mynginx nginx

해당 명령어로 생성 후에 조회해보면 정상적으로 생성되는 것을 확인 할 수 있습니다.

근데 우리는 values 값에 대한 수정이 필요하기 때문에 이걸로 설치 할 수 없습니다, 따라서 helm pull을 통해 패키지를 직접적으로 가져와야 합니다.

$ mkdir nginx
$ cd nginx
$ helm pull bitnami/nginx
$ tar -xvf nginx-*.tgz
$ cd nginx

압축을 푼 디렉토리로 이동하면 여러개의 yaml과 디렉토리가 존재하는 걸 볼 수 있습니다.

여기서 패키지를 설치할 때 차트의 기본 구조는 아래와 같습니다.

values.yaml을 통해 해당 인스턴스를 값을 정의하고, templates가 정의된 값을 통해 인스턴스를 구성합니다.

nginx-chart/
├── Chart.yaml
├── values.yaml
├── crds/
│   └── mycustomresource.yaml # 필요시 작성하는 커스텀 yaml
└── templates/
    ├── deployment.yaml
    ├── svc.yaml
    └── ingress.yaml
    └── ....

pull하여 가져온 chart에서 업로더가 제공한 README 등을 통해 양식에 맞게 values.yaml을 수정하고,

helm install을 통해 설치하면 되겠습니다.

$ helm install my-nginx . # 현재 디렉토리를 참조하여 my-nginx 패키지 설치

2. 여담

명령어 

helm list : helm chart 조회

helm uninstall $(charts) [...]  [flags] : charts 삭제

helm status $(charts) : charts 상태 조회

1. 개요

WSA(Windows Subsystem for Android)는 윈도우 OS에서 네이티브하게 안드로이드 애플리케이션을 실행하는 도구입니다.

각 레이어의 역할은 다음과 같습니다.

Windows OS
기본 운영체제로, 전체 시스템을 운영하는 바탕입니다.

Hyper-V (하이퍼바이저)
가상화 기술로, 가상 머신을 실행할 수 있게 합니다.

Linux Kernel
실제 Linux 커널로, Linux 운영체제의 핵심입니다.

WSL (Windows Subsystem for Linux)
Windows에서 Linux 프로그램을 실행할 수 있게 합니다.

WSA (Windows Subsystem for Android)
Windows에서 Android 앱을 실행할 수 있게 합니다.

작동 방식
1. Windows OS가 Hyper-V를 사용해 가상 환경을 만듭니다.
2. Hyper-V가 Linux 커널을 실행합니다.
3. Linux 커널이 WSL을 통해 Windows에서 Linux 프로그램을 실행합니다.
4. WSL이 WSA를 실행하여 Android 앱을 실행합니다.

2. 설치

일단 설치에 앞서서 하이퍼바이저 기능을 켜야 하는데 시작 - 검색 - Windows 기능 켜기/끄기를 실행하고

Hyper-V, 가상 머신 플랫폼을 체크한 후에 확인을 눌러주세요.

https://learn.microsoft.com/ko-kr/windows/wsl/install

Docs에서는 빌드 19041 이상일 경우 wsl --install로 간편하게 설치 할 수 있다고 하는데, 저는 안됩니다.

여튼 수동 설치란을 참고하면 WSL 최초 설치 프로세스부터 기술되어 있습니다.

# x64 시스템의 경우: 버전 1903 이상, 빌드 18362.1049 이상.
# ARM64 시스템의 경우: 버전 2004 이상, 빌드 19041 이상
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
wsl --update
wsl --install # OS 미지정시 기본적으로 우분투로 설치, 굳이 설치 할 필요는 없을 것 같습니다.

wsl --set-default-version 2 # WSL 기본 버전을 2버전으로 지정

얘는 기본적으로 윈도우 10을 공식 지원하지 않습니다..

그래서 아래 URL에 들어가서 윈도우 10용 안드로이드를 받아줍시다.

https://github.com/MustardChef/WSABuilds

들어가서 하단에 내려보면 ONEDRIVE가 있습니다.

저는 아마존 스토어는 필요없기 때문에 RemovedAmazon 버전으로 받았습니다.

해당 파일을 다운로드 받고 나면 설치하기 전에 압축을 풀어야하는데, 반디집이나 알집은 오류가 있으니 7z으로 풀어주세요.

https://www.7-zip.org/download.html

압축을 푼 폴더의 이름을 알아보기 편하게 변경하고 폴더를 옮겨줍시다. (저는 편하게 바탕화면에 뒀습니다.)

그 다음 관리자 권한으로 PowerShell을 실행합시다.

옮겨두었던 wsa 폴더로 이동하고 아래 명령어로 설치합시다.

cd C:\Users\${사용자명}\Desktop\wsa
PowerShell.exe -ExecutionPolicy Bypass -File .\Install.ps1

그러면 알아서 설치하고 프로세스가 올라옵니다.

플레이 스토어도 정상적으로 됩니다.

근데 메모리를 더럽게 쳐먹습니다. (메모리를 미리 VM에 할당 해놓는 방식이어서 많이 먹습니다, 설정에서 변경 가능)

스토어에서 앱 설치시 알림바로 알려줘서 확인하기 편합니다.

게임이나 앱도 정상적으로 실행됩니다. (안되는 앱도 종종 있긴 합니다. 가상화니 그러려니 합니다.)

제어판에서 보면 설치된 앱들도 확인 할 수 있습니다. 

런처가 기본적으로 내장되어 있지 않기 때문에 별도로 설치해서 구성하면 익숙하게 사용하실 수 있습니다.

3. 그래픽 설정

검색 - Android용 Windows 하위 시스템 실행

고급 설정 - 그래픽 기본 설정에서 특정 GPU 선택 후, GPU 선택

아마존에서 제공하는 프리티어로 간단하게 OpenVPN 서버를 구축하면 요긴하게 자주 쓰입니다.

매월 트래픽 100GB로 제공되기 때문에, 사용량을 고려하며 사용합시다. (넘으면 돈나옵니다.)

접근하려는 서비스에서 아마존 IP를 막는 경우도 잦아서,  VPN을 백퍼센트 사용 할 수 있는건 아닙니다.

1. 인스턴스 생성

이미지는 저는 페도라쪽을 주로 다루다 보니, Amazon Linux를 그냥 사용했는데, 우분투나 SUSE Linux를 사용하시는것도 상관 없습니다만, Amazon Linux는 2023이 아닌 2로 선택해주세요.

2. 탄력적 IP(공인 IP) 생성

좌측 스크롤 내리다 보시면 네트워크 및 보안 탭에서 탄력적 IP로 들어갑시다.

탄력적 IP(공인 IP)는 사용하지 않을 때 과금이 되므로 생성 후에, 반드시 인스턴스에 연결합시다.

3.  서버 접근

Port가 정상적으로 접근이 되는지 보통 텔넷을 주로 사용하는데, Windows 기능 켜기/끄기에서 텔넷 클라이언트를 설치합시다. (굳이 할 필요는 없습니다.)

잘 접근됩니다.

접근하기에 앞서 로그인하는 ID를 알아야 하는데, 아마존 메뉴얼에 명시되어 있습니다.

저는 Amazon Linux로 생성하였으니, ec2-user로 로그인하게 되겠습니다.

이후 SSH 접근 툴을 사용해야하는데 일반적으로 Putty를 사용합니다만, 모바텀이나 mremote건 서드파티 SSH 툴을 사용하는건 본인 자유입니다.

Putty를 사용할때는 Connection - SSH - Auth - Credentials 에서 키를 등록해주세요.

이후 Host Name에 ec2-user@탄력적 IP, Port는 별도로 설정한게 없으니 기본 포트인 22 로 입력하고, 해당 세션 값을 저장하기 위해 Saved Sessions에 이름 지정 후 저장을 누르시면 다음에도 해당 이름을 Load하여 재사용 할 수 있습니다.

해당 세션으로 Putty Configuration에서 Open을 누르게 되면 아래와 같이 SSH 세션에 접근 하게 됩니다.

4. 설치

일반적으로 OpenVPN을 설치하게 되면 조금 복잡스럽니다, 그냥 github에서 사람들이 배포하는걸로 사용하면 편하니 그걸로 사용합시다.

https://github.com/angristan/openvpn-install

호환성에서 지원을 잘하는 걸로 보이네요

이제 호환성도 확인했으니 설치 해봅시다.

[ec2-user@ovpn ~]$ sudo -i
[root@ovpn ~]# yum install -y git

# 위에 설치 끝나고
[root@ovpn ~]# git clone https://github.com/angristan/openvpn-install.git
[root@ovpn ~]# cd openvpn-install
[root@ovpn ~]# ./openvpn-install.sh 

# openvpn-install.sh 가 실행안될 때
[root@ovpn ~]# chmod +x openvpn-install

위 같이 설정하고 나면 스크립트가 알아서 설치를 하는데 중간에 한번 ID를 기입하는 설정이 있습니다.

아래와 같이 나오니 지정하면 끝입니다.

설치가 끝나면 하단에 *.ovpn 이라는 파일이 생성이 되는데 이게 패스워들 대신 할 인증서 입니다.

(나중에 쓰이니 꼭 기억합시다.)

열어보면 conf 값과 인증서가 같이 들어있는 걸 보실 수 있을겁니다.

설치는 끝났으니 실행합시다.

[root@vpn ~]# systemctl start openvpn-server@server

는 실행이 안됩니다.

로그(/var/log/message)를 까봅시다.

설정 값이 있는지 확인해봐야하니 설치 경로에 들어가서 확인해봅시다.

[root@vpn ~]# cd /etc/openvpn/

웬걸 온전히 다 있습니다.

보통 이럴 땐 systemd 설정이 잘못 된 경우가 많기 때문에 확인해봐야 할 것 같습니다.

[root@vpn ~]# systemctl status openvpn-server@server.service

systemd unit 위치를 확인 했으니 까봅시다.

역시나 WorkingDirectory 값이 잘못 되었습니다.

키보드 i를 누르고 입력모드로 들어간 후에 /etc/openvpn 으로 수정한 후 ESC - :wq - Enter

이제 잘 됩니다.

네트워크 인터페이스 잘 생성 되었습니다.

포트도 잘 올라왔습니다.

5. 접속

클라이언트용 OpenVPN을 설치합시다. 

https://openvpn.net/client/

다운로드 받고 실행합시다.

설정 할 내역은 딱히 없고 Next 만 누르세요.

이제 *.ovpn 파일(4. 설치 내역 참고)을 SFTP던 FTP던 VPN을 접속할 PC로 가져와야합니다.

그냥 cat 으로 vpn 설정값을 열어준다음 아래처럼 클릭해서 긁어서 메모장에 열어서 Ctrl+v 하면 값을 가져 올 수도 있습니다.

만약에 메모장에 값을 복사한 경우라면 확장자를 ovpn으로 꼭 바꿔주세요.

UPLOAD FILE 클릭

이 상태에서 아까 저장한 *.ovpn 파일을 넣어줍시다.

파일을 Import 하였으면 Connect를 눌러주세요.

이렇게 CONNECTED가 나오면 접속 된겁니다.

- VPN Off

- VPN On

이렇게 구축이 완료되었습니다.

하지만 맨 처음에도 말했던 것 처럼 이런 AWS 공인 IP는 웹서비스에서 자체적으로 막는 경우가 잦으니 안되는 경우도 많습니다.

6. 여담

인증서는 하나당 하나의 사용자를 처리할 수 있습니다.

따라서 여러 사용자가 사용하기 위해서는 추가를 해야하는데, 이때 설치 때 사용하였던 스크립트로 사용자를 간편하게 추가 할 수 있습니다.

이렇게 추가된 *.ovpn 파일을 다른 사용자에게 주면 됩니다.

타르코프를 하시는 분은 SPT(singleplayer Tarkov Project)를 잘 알고 있을 것입니다.

PVP 기반의 FPS를 싱글플레이 게임으로 변경하여 즐기는 모드입니다.

이 SPT라는 모드에 fika 모드를 추가하게 되면 멀티플레이를 지원하는데 그러면 PVE로 친구들과 같이 즐길 수 있습니다.

이전의 sitcoop라는 모드도 있었지만 매우 불안정하고, 기존의 SPT 모드를 별도로 포팅해야 할 수 있어서 매우 불편했습니다. (지금은 사실상 사장된 모드)

필자는 개인 서버 겸, NAS 겸 24/7 굴려먹는 맥미니가 있는데 이 SPT AKI는 exe,dll 을 사용을 하다보니 리눅스 기반에서는 어떻게 올릴 수 있을까 고민하다 도커로 사용하기로 했고, SPT를 Mac에 도커로 구성하고 FIKA를 설치하였습니다.

이런 컨테이너 방식이 아닌 a to z 하게 구성을 하면, 와인부터 시작하여 구성을 전부 다시하여야 하고.. 버전업이 되면 관리하기가 너무 어려워 저는 도커로 진행하는 것을 추천드립니다.

궁금하신 분은 하기 링크 읽어보시면 될 것 같습니다.

https://dev.sp-tarkov.com/MadByte/Linux-Guide/src/branch/main/README.md

1. SIT 설치

참고한 GIT은 아래의 링크입니다.

https://github.com/umbraprior/SPT.Docker

git clone https://github.com/umbraprior/SPT.Docker.git
cd SPT.Docker

Dockerfile을 열어보면 SPT_BRANCH라고 버전을 지정하는 부분이 있는데, 여기서 사용할 버전을 기입하면 됩니다.

작성일 기준으로 최신 버전은 3.9.1 이지만

https://hub.sp-tarkov.com/

필요한 모드를 설치할 때 버전이 높으면 호환이 안되는 부분이 있으니 반드시 확인하고 버전을 선택하세요.

docker build --no-cache  --label fikaa -t ${저장할 이미지 이름 (예: fika)}

빌드가 완료 된 후에 image를 조회 해보시면 빌드된 이미지를 확인 할 수 있습니다.

docker run 으로 해당 이미지를 실행합시다.

docker run --pull=never -v /${SPT 설치 경로}/SPT.Docker/server:/opt/server -p 6869:6969 -p 6870:6970 -p 6871:6971 -p 6872:6972 -it --name ${컨테이너명} ${이미지명}

# 저는 기존 서버가 존재하므로 6869:6969로 포트포워딩이 지정되어있습니다.
# 별도로 다른 포트 (예: 8080포트를 서버 접근 포트로 지정하고 싶으면 8080:6969) 로 지정해주세요.

run 실행 후에 mount 된 가상 경로에 리얼 데이터를 copy하는데, 해당 작업 이후로 컨테이너가 종료됩니다.

이후 server 디렉토리에 접근하게 되면 각 데이터들이 있는데 delete_me 를 삭제 한 후에 docker run 이 아닌, docker start로 종료된 컨테이너를 다시 시작해주세요.

이후 정상적으로 실행이 되었는지 확인하기 위해 docker logs -f ${컨테이너명}로 확인합시다.

이후 fika 모드를 넣으시면 됩니다.

https://github.com/project-fika/Fika-Server

모드를 다운로드 받아서 ftp로 직접 넣거나, wget을 통해서 서버에서 직접 받아 압축을 풀어 넣거나 해당 부분은 본인의 자유 입니다.

/${설치경로}/SPT.Docker/server/user/mods/fika-server

파일 업로드 후에 docker rm -f ${컨테이너명} 으로 완전히 컨테이너를 삭제하고, 다시 재기동 합시다.

(delete_me는 시작할때마다 새로이 생성되므로, 삭제 후에 docker start로 다시 기동해주세요.)

그럼 이제 카파컨 따러갑시다.

해당 게시글은 기록과 자료 공유를 위해 작성합니다.

NKS로 구성된 쿠버네티스 시스템에서 워커노드를 재부팅 이후로 시스템이 무너지는 현상이 발생했는데, 조회를 해보니 calico, CSI, kube-proxy 같은 코어 이미지들이 워커노드에 존재하지 않아 컨테이너가 올라오지 못해 발생하였습니다.

이는 k8s에서 노드의 디스크 용량이 부족하게 될 경우에 가비지 컬렉션이 동작하여 특정 기간 동안 사용되지 않은 이미지들을 삭제하여 용량을 확보를 하는데, 해당 코어 이미지가 삭제가 되고 난 이후로 레지스트리에서 자동으로 받아오지 못하여 워커노드가 무너지는 현상이었습니다.

https://kubernetes.io/ko/docs/concepts/architecture/garbage-collection/

이는 특히 폐쇄망 환경으로 이루어진 쿠버네티스 클러스터에서 발생하기 쉬운데, 이는 Habor 같은 사설 레지스트리에 이

미지 파일을 별도 관리하거나 Proxy 등을 통해 해결하여야 합니다.

https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

또는 워커노드에 nerdctl 등을 통해 ImagePullBackOff가 발생하는 이미지를 직접적으로 받아 온 후에 컨테이너를 살리는 방법이 있습니다.

이미지를 받아오는 방법은 두가지 정도로 제안될 수 있는데, 공식 레포지토리에서 받아오거나, NHN 레지스트리에서 받아오는 방법입니다.

1. 공식 레포지토리

# 공식 레포지토리
kubernetesui/dashboard
k8s.gcr.io/pause
k8s.gcr.io/kube-proxy
kubernetesui/dashboard
kubernetesui/metrics-scraper
quay.io/coreos/flannel
quay.io/coreos/flannel-cni
calico-kube-controllers
calico-typha
calico-cni
calico-node
coredns/coredns
k8s.gcr.io/metrics-server-amd64
....

# Kube-proxy 이미지를 복구하고 싶은 경우
nerdctl pull k8s.gcr.io/kube-proxy/[$Failed Image]
nerdctl tag k8s.gcr.io/kube-proxy/[$Failed Image]
nerdctl rmi k8s.gcr.io/kube-proxy/[$Failed Image]

2. NHN 레지스트리

nerdctl pull harbor-kr1.cloud.toastoven.net/container_service/[$Failed Image] # 이미지를 가져옴
nerdctl tag harbor-kr1.cloud.toastoven.net/container_service/[$Failed Image] # 가져온 이미지명을 Yaml에서 요구하는 이미지로 변경
nerdctl rmi harbor-kr1.cloud.toastoven.net/container_service/[$Failed Image] # 변경전 이미지 삭제

이미지 장애 상태 구현하기 위해 coredns의 yaml을 수정하여 불능 상태로 만들었습니다.

복구 과정은 아래와 같습니다.

공홈에서는 파일을 내리고 마소 스토어로 배포하고 있어서 공유드립니다.

해당 게시글은 기록과 자료 공유를 위해 작성합니다.

NHN Cloud의 프라이빗 레지트스트리(NCR)의 PULL, PUSH 의 가이드는 공식 문서에도 잘 적혀있으니
참고 하도록 합시다.

https://docs.nhncloud.com/ko/Container/NCR/ko/user-guide/

프라이빗 레지스트리를 이용하기에 앞서 NCR 생성 후, 접근을 위하여

계정 -> API 보안 설정 탭에 들어가서 Access Key ID 생성을 합니다.

생성된 레지스트리를 클릭하여 주소 확인을 합시다.

레지스트리에 로그인합니다.

Username과 Password는 이전에 생성하였던 API 보안 설정에서 생성한 User Access Key 입니다.

$ docker login {사용자 레지스트리 주소}

테스트용 이미지를 받아줍니다. (본인이 필요한 이미지가 있을 경우, 해당 이미지로 pull 하여 수정 후 commit 합시다.)

[root@ysh-kube-mgmt test3]# docker pull nginx:stable

작동 확인을 위해 간단히 실행만 하였습니다.

[root@ysh-kube-mgmt test3]# docker run -itd -p 80:80 --name=web nginx:stable
9ee7f649badf5818ab6380be6ead2b4825b9a8e2d610fd4f691027464a6a4550

[root@ysh-kube-mgmt test3]# docker ps -a
CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS                               NAMES
9ee7f649badf   nginx:stable   "/docker-entrypoint.…"   3 seconds ago   Up 2 seconds   0.0.0.0:80->80/tcp, :::80->80/tcp   web


[root@ysh-kube-mgmt test3]# curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

이후 업로드 할 이미지를 tag 명령어를 사용해 레지스트리 주소/이미지 이름:태그로 변경 후, 업로드 합시다.

# 이미지 태그 변경
$ docker tag $이미지 이름:$태그 $사용자 레지스트리 주소/$이미지 이름:$태그

# 업로드
$ docker push $이미지 이름:$태그 $사용자 레지스트리 주소/$이미지 이름:$태그

NCR 에서 확인하였을 때, 정상적으로 업로드 된 것을 확인 할 수 있습니다.

해당 프라이빗 레지스트리에 업로드 된 이미지를 쿠버네티스에 활용하기 위해선 시크릿을 생성하여 자격증명을 해야합니다.

자세한 내용은 쿠버네티스 공식 문서에도 기술되어 있습니다.

https://kubernetes.io/ko/docs/tasks/configure-pod-container/pull-image-private-registry/

문서를 인용하였을 때, 도커 로그인 시 자격증명을 저장하는 config.json의 위치를 기재하도록 명시되어있는데, 이는 이전에 API로 NCR에 로그인 하였을 때, 경로를 표기하여 줬을 것입니다.

kubectl create secret generic regcred \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

저는 루트를 활용하여 사용하였기 때문에 루트 홈 디렉토리의 .docker에 작성된 것을 확인 할 수 있습니다.

[root@ysh-kube-mgmt test3]# docker login {저장소명}-kr1-registry.container.nhncloud.com/{저장소명}
Username: 
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

해당 경로의 파일을 출력해보면, 자격 증명을 저장하는 설정 값이 들어가있습니다.

이 컨픽값이 저장된 json으로 secret을 생성하여 줍니다.

[root@ysh-kube-mgmt .docker]# kubectl create secret generic regcred --from-file=.dockerconfigjson=/root/.docker/config.json  --type=kubernetes.io/dockerconfigjson
secret/regcred created

secret가 잘 생성되었는지 확인합시다.

[root@ysh-kube-mgmt ~]# kubectl get secrets regcred
NAME      TYPE                             DATA   AGE
regcred   kubernetes.io/dockerconfigjson   1      3h45m

아까 업로드한 이미지를 테스트하기 위한 간단한 YAML 예시입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: web
        image: {저장소명}-kr1-registry.container.nhncloud.com/{저장소명}/web:1.0
        ports:
        - containerPort: 80
      imagePullSecrets:
      - name: regcred

작성된 YAML로 프로비저닝 합시다.

[root@ysh-kube-mgmt test3]# kubectl apply -f web.yaml
deployment.apps/web created

이후 POD의 이미지를 조회하였을 때, 정상적으로 프라이빗 레지스트리에서 가져오는 것을 확인 할 수 있습니다.