Haroon DevLog

안녕하세요, 하룬입니다

매번 kubectl 커맨드를 입력할 때마다 --kubeconfig 옵션 작성이 귀찮으셨던 적 없으셨나요?

이번 글에선 --kubeconfig 옵션을 생략하고 사용하는 방법을 공유해보고자 합니다.

Kubernetes 공식 문서

https://kubernetes.io/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/

export KUBECONFIG=~/.ncloud/kubeconfig.yaml

위 커맨드를 입력하면 환경변수에 KUBECONFIG가 등록됩니다!

저는 기본으로 지정할 kubeconfig 파일이 ~/.ncloud 경로에 있어서 해당 경로로 지정했습니다.

각자 저장해놓으신 경로로 지정하시면 됩니다.

(추가) 여러개의 Profile을 사용해야하는 경우

저의 경우, 네이버 클라우드 플랫폼에서 메인 계정 여러개에 클러스터도 여러개 사용 중이라 

일부러 옵션을 생략하지 않고 사용하고 있다가 이번에 방식을 바꾸었습니다.

제가 사용하는 방식을 공유드리겠습니다.

.ncloud
├── configure (file)
├── configures
│   ├── configure_1
│   └── configure_2
├── kubeconfig.yaml
├── kubeconfigs
│   ├── kubeconfig_1.yaml
│   └── kubeconfig_1.yaml
└── temp

위 디렉토리처럼 구성하여 메인으로 사용하는 profile 들은 ~/.ncloud/configure 와 ~/.ncloud/kubeconfig.yaml 로 사용하고, 

만약 profile 변경이 필요하다면 각 디렉토리에서 복사해서 상위에 덮어씌우는 방식으로 사용하고 있습니다.

예시로, 현재 configure_1, kubeconfig_1.yaml profile을 사용중인데 2번으로 변경하는 경우,

cd ~/.ncloud/configures
cp configure_2 ../configure

cd ~/.ncloud/kubeconfigs
cp kubeconfig_2.yaml ../kubeconfig.yaml

이런 간단한 커맨드로 손쉽게 변경이 가능합니다.

저는 이런식으로 사용하는데 더 좋은 방법이 있다면 댓글로 알려주세요!

감사합니다.

(이전 글)

1. VPC& Subnet 설계 https://har00n.tistory.com/8

2. NAT Gateway와 Route https://har00n.tistory.com/9

3. Cluster & Node Pool 생성하기 https://har00n.tistory.com/10 

4. Istio 설치하기 https://har00n.tistory.com/11

5. Image Registry https://har00n.tistory.com/12

6. CI/CD - Sub Account & Source Commit https://har00n.tistory.com/13

안녕하세요, 하룬입니다.

• Source Commit
• Source Build
• Source Deploy
• Source Pipeline

이번에는 CI/CD 4단계 중 2번 째 단계인 Source Build를 해보려고합니다.

* 제가 진행하는 방식대로 진행하려면 프로젝트 레포지토리에 Dockerfile 과 관련 파일들이 모두 커밋되어있어야합니다.

Dockerfile에서 선언되는 내용들이 각자 다를 수 밖에 없는데요.

저희가 사용하는 몇 가지 예시들을 공유드리겠습니다.

아시겠지만, 이 부분은 정답은 없어요. 인프라 환경, 프로젝트 환경에 맞추어 작성하시면 됩니다.

혹시 보완할 점이 보이시면 댓글로 피드백주셔도 좋습니다.

Dockerfile

Frontend (node.js, react)

project
├── src
├── public
├── conf
│   ├── conf.def (directory)
│   │   ├── default.conf
├── conf_nginx
│   ├── nginx.conf
...
└── Dockerfile

FE 프로젝트 구조입니다.

루트 경로에 Dockerfile이 있고, npm으로 build된 파일이 public에 들어갑니다.

# Dockerfile
FROM nginx:stable-alpine

WORKDIR /usr/src/app
RUN rm -rf /etc/nginx/conf.d

RUN chmod 400 /etc/shadow

COPY conf /etc/nginx
COPY conf_nginx/nginx.conf /etc/nginx/nginx.conf

COPY public /usr/src/app

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

# conf/conf.def/default.conf
server {
    listen 80 default_server;

    location / {
        root /usr/src/app;
        index  index.html index.htm;
        try_files $uri /index.html;
    }
}

# conf/conf_nginx/nginx.conf
user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}

http {                                                                       
    include       /etc/nginx/mime.types;                                     
    default_type  application/octet-stream;                                  
    disable_symlinks on;

    add_header X-Frame-Options DENY;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
                                                
    access_log  /var/log/nginx/access.log  main;
                                     
    sendfile        on;              
    keepalive_timeout  65;           
                                                                                                                                                
    include /etc/nginx/conf.def/*.conf;
}

public 디렉토리에 build 된 파일을 nginx랑 연결하는 방식입니다.

보통 public 디렉토리는 커밋하지않지만, 저희의 경우 커밋하여 해당 빌드된 파일을 사용하는 구조입니다.

Dockerfile을 메인으로 다룰 글은 아니므로 상세한 설명은 생략하고

일반적인 방식과 제가 사용하는 방식을 비교해보겠습니다 (GPT-5 활용)

Backend (node.js, express)

project
├── src
...
└── Dockerfile

일반적인 express BE 프로젝트 구조입니다.루트 경로에 Dockerfile이 있습니다. 

FROM node:22.2.0

RUN mkdir -p /app

COPY . /app
WORKDIR /app

RUN chmod 400 /etc/shadow
RUN chmod -s /usr/bin/newgrp
RUN chmod -s /sbin/unix_chkpwd

RUN touch /etc/hosts.allow \
  && touch /etc/hosts.deny \
  && chmod 640 /etc/hosts.allow /etc/hosts.deny \
  && chown root:root /etc/hosts.allow /etc/hosts.deny

RUN mkdir -p /app/logs
RUN chmod 750 /app/logs

RUN npm install

EXPOSE 8080
CMD ["npm", "start"]

이번에도 Dockerfile을 메인으로 다룰 글은 아니므로 상세한 설명은 생략하겠습니다.

기존 Dockerfile 그대로 사용하시거나 참고하여 작성해주시면 됩니다.

Source Build

자 이제 본격적으로 Source Build에서 빌드 프로젝트를 만들어보겠습니다.

좌측 메뉴에서 Source Build에 들어가 빌드 프로젝트 생성 버튼을 눌러줍니다.

첫 페이지에 Object Storage가 필수 사항이라고 나와있는데,

지난번에 저희는 Container Registry를 생성하면서 함께 생성했으므로 이용중입니다!

• 빌드 프로젝트 이름: 자유롭게 기입합니다. 저의 경우 dev 환경용 빌드이므로 앞에 DEV 표시를 해주었습니다.
• 빌드 프로젝트 설명: 꼭! 적어줍시다.
• 빌드 대상: 사용하시는 환경에 맞추어 선택해주세요.

• 리포지토리: 빌드할 리포지토리를 선택해주세요. 저는 이번에 FE/BE 각각 하나씩 선택했습니다.
• 브랜치: 원하는 브랜치를 선택해주세요. 저의 경우 dev 환경용 빌드이므로 dev 브랜치를 선택했습니다.
• 알림: 선택에 따라 담당자에게 Email 혹은 SMS로 알림이 가는 기능입니다. 필요에 따라 추가해주세요.

• 빌드 환경 이미지: Public Registry 이미지를 선택하여 자유롭게 이미지를 선택합니다.
• 이미지: 현재 저희 BE/FE 모두 node.js 프로젝트이므로 node 이미지를 기입했습니다.
  Python 프로젝트의 경우 ubuntu 이미지를 사용합니다. 참고하여 작성해주시면 됩니다.
• 태그: 저희 프로젝트에 맞게 22.2.0 버전으로 기입했습니다.
• 도커 이미지 빌드: 저희는 Docker image 기반으로 CI/CD를 구성할거기 때문에 꼭 체크합니다.
• 컴퓨팅 유형 / 타임아웃: 최소값으로 설정해두신 뒤에 실제로 빌드해보시고
  시간이 너무 오래걸린다 하면 상향조정하시는걸 권장합니다.

• 빌드 전 명령어 / 빌드 명령어 / 빌드 후 명령어: 프로젝트에 맞추어 필요하신 경우 작성하시면 됩니다.
• 도커 이미지 빌드 설정: 사용으로 선택해주세요.
  • Dockerfile 경로: 제 프로젝트의 경우 루트 경로에 있기 때문에 Dockerfile 로 작성했습니다.
    경로에 따라 맞추어 적어주세요.
  • Container Registry: 원하는 Container Registry를 선택해주세요.
  • 이미지 이름: 저장될 이미지 이름을 작성해주세요.
  • 이미지 태그: 1.0.#-tag 양식으로 작성합니다. 1.0.#-dev 라고 작성할 경우, 1.0.1-dev 이런식으로 저장됩니다.
    tag는 필수 값이 아니니 참고해주세요.
    
    • latest 로 설정: 체크하여 1.0.# 버전과 latest 둘다 저장되도록 설정해주세요. 새롭게 빌드시 자동으로 갱신됩니다.

• 빌드 결과물: 빌드 결과물 저장 필요 시 저장에 체크해주세요.
• 빌드 이미지: 이미지 저장 안함을 선택해도 저희는 도커 이미지 빌드로 설정했기 때문에
  Container Registry에 정상적으로 저장됩니다. 이미지 저장 안함을 선택해주세요.

• Cloud Log Analytics 연동: Prod 환경은 연동하였으나 이 프로젝트는 Dev 환경이므로 연동 안함을 선택했습니다.
  필요에 따라 선택해주세요.
• 보안 상품 연동: Source Commit 에 File Safer를 연동해두어 빌드 프로젝트에는 연동하지 않았습니다.
  보안에 더 신경쓰실 경우 연동해주세요.

최종확인은? 항상 꼼꼼하게!

방금 만든 api와 web이 정상적으로 저장되었습니다!

이번엔 방금 만든 Source Build에서 실제로 빌드를 해보겠습니다.

프로젝트 이름을 클릭해서 해당 프로젝트로 이동해주세요.

저희가 빌드 프로젝트 생성시 설정했던 값들이 기본 값으로 들어가있습니다.

빌드 때 마다 상황에 맞추어 변경이 필요할 때 자유롭게 변경이 가능합니다.

빌드 시작하기 버튼을 눌러 빌드를 시작해보겠습니다.

자동으로 작업결과 탭으로 이동하고 빌드가 실행됩니다.

완료 될 때까지 기다려줍니다. 오류가 발생하면 발생한 곳에서 로그에 오류가 찍힙니다.

빌드 로그에 모두 초록불이 뜨고 상태가 Success로 변경되었습니다.

방금 빌드된 이미지는 Container Registry에서 확인이 가능합니다.

Container Registry에서 해당 레지스트리의 이미지 리스트로 이동해보겠습니다.

들어가서 방금 빌드한 이미지를 클릭해보면 이렇게 상세정보가 나오고

Tags 탭으로 이동해보면 방금 빌드된 이미지의 버전과 latest 버전이 자동으로 생성되어있습니다.

Source Commit (+ Sub Account) → Source Build → Source Deploy → Source Pipeline

이제 Source Build 까지 마쳤습니다.

다음 글에서는 여기서 빌드된 이미지를 Source Deploy에서 활용하기 전에,

K8S 매니페스트 작성과 직접 클러스터에 직접 리소스를 등록하는 과정을 먼저 진행해보도록 하겠습니다

감사합니다.

(이전 글)

1. VPC& Subnet 설계 https://har00n.tistory.com/8

2. NAT Gateway와 Route https://har00n.tistory.com/9

3. Cluster & Node Pool 생성하기 https://har00n.tistory.com/10 

4. Istio 설치하기 https://har00n.tistory.com/11

5. Image Registry https://har00n.tistory.com/12

안녕하세요, 하룬입니다.

이번 글에서는 CI/CD 를 위해 Sub Account와 Source Commit 설정을 해보려고합니다.

여기서 NCP의 Source Commit이란, NCP에서 제공하는 git remote repository 입니다. 

간단하게 얘기하면 Github 이나 Gitlab 같은 개념입니다.

> 이거 말고 Github 쓰면 안되나요?

대답은 "가능합니다" 입니다.

NCP에서 CI/CD 서비스들 중 build 하여 지난 번에 만든 Container Registry에 저장해주는

Source Build 서비스는 Source Commit / Github / Github Enterprise Server / Bitbucket 에서

소스를 가져와 빌드할 수 있습니다.

근데 문제는 배포를 담당하는 서비스인 Source Deploy 인데요,

Deployment.yaml 같은 매니페스트 파일을 Source Commit / Github Enterprise Server 두개만 지원하다보니

Github Enterprise Server 를 사용하지 않고 있다면 Source Commit 사용이 강제됩니다.

이렇다보니 Github Enterprise Server 를 사용하지 않는다면 무조건 Source Commit을 사용할 수 밖에 없고,

Source Build에서는 Gitlab을 쓰고 Source Deploy에서는 Source Commit을 쓰자니

레포지토리 관리포인트가 2개가 되니 차라리 Source Build도 Source Commit으로 옮기게 됩니다...

이어서, Source Commit을 사용하려면

메인 계정에서는 git 사용이 제한되다 보니 Sub Account를 강제로 만들어야 합니다.

결국 CI/CD를 이용하고, 그냥 이용을 넘어서 편하게 이용하려면 5개 서비스를 모두 이용해야합니다.

• Sub Account
• Source Commit
• Source Build
• Source Deploy
• Source Pipeline

Sub Account 로그인 접속키 설정

사이드 메뉴에서 Sub Account의 하위 메뉴인 Dashboard로 먼저 이동해줍니다.

서브 계정 로그인 접속키: 현재 저는 설정이 되어있는데 원하는 접속키로 설정해주세요.

저희는 회사 이름으로 되어있습니다.

위 로그인 접속키는 로그인창에서 서브 계정으로 로그인을 클릭했을 때 나오는 창의 맨 위에 들어가게 됩니다.

Sub Accounts 계정 생성

이번에는 Sub Account의 하위메뉴인 Sub Accounts로 이동해줍니다.

서브계정 생성을 눌러 서브 계정을 생성해줍니다.

이 부분은 추가적인 설명이 필요 없을 듯 하여 생략하겠습니다!

Sub Account Group 생성 및 권한 부여

이어서 Groups 메뉴로 이동해서 그룹을 생성하겠습니다.

(이 부분만 공공이 아닌 민간 Ncloud 에서 캡쳐했습니다. 양쪽 다 동일합니다)

저희는 developer 그룹을 하나 미리 만들었습니다.

그룹을 만드는 법은 너무너무 간단합니다. 일단 그룹명만 만들어주시면 됩니다.

방금 만들어주신 그룹을 선택합니다.

서브 계정에서 추가 버튼을 클릭하여 해당 그룹에 Sub Account를 할당합니다.

추가 버튼을 누르면 이런 팝업이 나오고, 어떤 유저를 추가할 지 선택하여 추가할 수 있습니다.

그 다음 정책 탭으로 넘어와 개별 권한 추가 버튼을 눌러줍니다.

해당 팝업에서는 어떤 메뉴에 어떤 기능까지 허용/제한할지 설정할 수 있는데요,

저희는 개발자들이니 깔끔하게 NCP_INFRA_MANAGER 권한을 부여했습니다.

권한의 경우 회사 방침에 따라 진행하시면 되겠습니다.

그러면 Sub Account 준비가 끝났고, 생성한 계정으로 콘솔에 접속하면

우측 상단에 이런식으로 서브계정이라고 명시됩니다.

그 다음, Source Commit 메뉴에서 다시 Git 계정/Git SSH 설정 팝업에 들어가면

계정을 설정할 수 있는 팝업이 나오고 여기에서 설정된 값으로 git 을 사용할 수 있게 됩니다.

Source Commit 레포지토리 만들기

Source Commit 메뉴에서 레포지토리 생성을 선택합니다.

보통 방식대로 레포지토리를 생성합니다. 레포지토리 이름과 설명을 입력합니다.

(개인적으로 설명칸 비우는 사람 싫어합니다...)

다음은 보안상품 연동인데 저희 회사는 그렇게 부담되지 않는 가격 선에서 보안 상품을 가입할 수 있어

왠만하면 해당 상품은 연동하는 편입니다. 요금표는 아래에 있습니다.

최종 확인은 항상 꼼꼼히! 잊지 말아주세요.

생성 버튼을 눌러 Source Commit에 레포지토리를 생성했습니다.

이 이후로는 Git에 관련된 부분이기 때문에 추후에 기회가 되면 Git에 관련된 부분들도 다뤄보겠습니다.

Source Commit (+ Sub Account) → Source Build → Source Deploy → Source Pipeline

CI/CD 설정에 첫 걸음을 마쳤습니다. 

다음 번에는 Source Build를 이용하여 프로젝트를 Docker image로 빌드해보도록 하겠습니다.

감사합니다.

(이전 글)

1. VPC& Subnet 설계 https://har00n.tistory.com/8

2. NAT Gateway와 Route https://har00n.tistory.com/9

3. Cluster & Node Pool 생성하기 https://har00n.tistory.com/10 

4. Istio 설치하기 https://har00n.tistory.com/11

안녕하세요,

이번 글에서부턴 NCP 기능들을 활용하여 CI/CD를 맛볼 차례입니다.

사용하게 될 기능들은 이정도입니다.

• image registry
• object storage
• source commit
• source build
• source deploy
• source pipeline

이번 글에서는 object storage 에 image를 저장할 버킷을 생성하고,

그 스토리지에 image registry를 연동한 뒤 image를 pull 할 수 있는 secret도 클러스터에 등록해보겠습니다.

어렵지 않으니 천천히 따라와주세요!

1. Object Storage 버킷 생성

왼쪽 메뉴에서 Object Storage 하위 메뉴인 Bucket Management로 이동해주세요.

버킷 생성 버튼을 눌러 새롭게 버킷을 생성해줍니다.

버킷의 이름을 자유롭게 입력해줍니다. 개인적으로 -images 로 끝나는게 구분하기 좋더라구요!

잠금 설정과 암호화 설정은 따로 체크하지 않고 넘어갔습니다.

운영환경이라면 암호화 설정은 권장된다고 하니 사용 환경에 맞추어 설정해주세요.

전체 공개는 공개로 선택하고 계정 설정은 마스터 계정을 넣어주신 뒤 추가 버튼을 눌러주세요.

입력한 내용을 확인 하신 뒤, 버킷 생성 버튼을 눌러주세요

2. Container Registry

좌측 메뉴에서 Container Registry 메뉴로 이동해주세요.

레지스트리 생성 버튼을 눌러서 팝업을 열어주세요.

레지스트리 이름을 자유롭게 작성해주신 뒤, 버킷은 위에서 생성한 Object Storage 버킷을 선택해주세요.

생성 버튼을 누르면 간편하게 Container Registry가 생성됩니다.

3. Secret 등록

이제 클러스터에 해당 Container Registry에서 도커 이미지를 pull 하여 배포할 수 있도록 secret을 등록해줄겁니다.

방금 생성한 Container Registry에서 Private Endpoint를 잘 복사해주세요. (Public Endpoint 아닙니다!)

# namespace 생성
kubectl --kubeconfig ~/.ncloud/kubeconfig.yaml create namespace dev

# namespace 조회
kubectl --kubeconfig ~/.ncloud/kubeconfig.yaml get namespace

위 커맨드를 입력하여 네임스페이스를 하나 생성해주세요. 저는 dev 라는 네임스페이스를 생성했습니다.

생성하신 뒤, 정상적으로 생성 되었는지 조회해주세요.

# secret 생성
kubectl -n <namespace> --kubeconfig ~/.ncloud/kubeconfig.yaml \
create secret docker-registry dev-image-pull-secret \
--docker-server=<docker registry private Endpoint> \
--docker-username="<ncloud_access_key_id>" \
--docker-password="<ncloud_secret_access_key>"  \
--docker-email="<버킷 등록 계정>"

# secret 조회
kubectl --kubeconfig ~/.ncloud/kubeconfig.yaml -n <namespace> get secret

<namespace> 부분엔 방금 생성한 namespace를 입력해주세요.

저는 dev를 생성했으니 dev를 입력하면 되겠죠?

docker username과 docker password엔

각각 ncloud_access_key와 ncloud_secret_access_key를 입력해주세요.

해당 값을 확인하는 방법은 아래 글의 configure 생성 쪽을 참고해주세요

https://har00n.tistory.com/10

생성한 뒤에, 정상적으로 생성되었는지 조회해주세요.

이제 container registry에 접근할 수 있는 secret도 등록되었으니 배포 준비는 끝났습니다.

ncp에서 어떻게 프로젝트를 빌드하고 배포하며 자동화 하는지 다음글에서부터 순서대로 진행해보겠습니다.

감사합니다.

(이전 글)

1. VPC& Subnet 설계 https://har00n.tistory.com/8

2. NAT Gateway와 Route https://har00n.tistory.com/9

3. Cluster & Node Pool 생성하기 https://har00n.tistory.com/10

안녕하세요,

이번 글에서는 Istio를 클러스터에 설치해보려고 합니다.

Istio는 k8s 환경에서 서비스 메시를 구현하기 위한 대표적인 솔루션이고,

NCP에서도 활용이 용이한 편입니다.

특히 Istio Ingress를 NCP 내의 DNS 솔루션인 Global DNS와 연동이 간편해서

클러스터 외부와 내부를 쉽게 연결할 수 있습니다. Global DNS에 관련된 부분은 추후에 다루도록 하겠습니다.

1. istioctl 설치

istio 공식문서

https://istio.io/latest/docs/setup/additional-setup/download-istio-release/

# Istio 설치
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.27.0 sh -

# PATH 등록
cd istio-1.27.0/

export PATH="$PATH:/root/istio-1.27.0/bin"

# 설치 확인
istioctl version

위 커맨드에 따라 istioctl을 설치해주세요.

2. ACG 설정

우리가 설치하고 있는 클러스터는 VPC 폐쇄망에 있기 때문에 NAT Gateway를 통해 Istio를 설치할 수 있는데요,

NCP 쪽에서는 ACG (Access Controll Group)을 통해 Inbound와 Outbound의 IP와 포트를 제한할 수 있습니다.

기본 값으로는 istio를 설치할 수 없어 일시적으로 Inbound를 개방한 뒤 다시 닫아주는 작업을 진행할겁니다.

저희가 설정할 클러스터에 적용된 ACG를 확인해주세요.

Server 하위에 있는 ACG 메뉴로 이동해 방금 저희가 찾은 ACG를 찾아 클릭하신 뒤, 

ACG 설정을 눌러주세요.

어차피 임시로 열어줄거니 모든 IP와 (0.0.0.0/0) 모든 포트를 (1-65535) 개방해주도록 하겠습니다.

까먹지 않도록 메모에도 임시용이라 적어주면 좋겠죠?

추가 버튼을 눌러 TCP와 UDP 모두 열어준 뒤 적용버튼을 눌러 적용합니다.

3. istio 설치

istioctl install --set profile=default --kubeconfig ~/.ncloud/kubeconfig.yaml

위 커맨드를 입력하여 클러스터에 istio를 설치합니다.

 kubectl --kubeconfig ~/.ncloud/kubeconfig.yaml get namespaces

설치가 완료된 뒤 namespace를 조회해보면, istio-system namespace가 추가된 것을 확인할 수 있습니다. 

잊지말고 아까 전체 허용해둔 ACG는 꼭 삭제해주세요!

이번 글은 간단하게 끝났는데요,

처음에 istio를 설치할 때 ACG를 허용해주지않아서 설치가 안되서 엄청 삽질했던 기억이 있네요...

다음 글 부터는 본격적으로 CI/CD에 관련된 내용을 다루게 될 것 같습니다.

감사합니다

(이전 글)

1. VPC& Subnet 설계 https://har00n.tistory.com/8

2. NAT Gateway와 Route https://har00n.tistory.com/9

안녕하세요,

네트워크 설정을 마치고 이번에는 본격적으로 클러스터를 생성해보려고 합니다.

클러스터를 생성하기 전에, 미리 정하고 갈 부분들 입니다.

클러스터 설정

• 하이퍼바이저: Xen
• 인증 방식: ConfigMap
• 노드: 2개

서비스 메시 적용

• ISTIO 연동

Global DNS 연동

• Ingress 연결

아무래도 공공 SaaS이고 성능도 중요하지만 보안이 더 중요한 환경이다 보니  
KVM 하이퍼바이저보다는 Xen 하이퍼바이저를 적용할 예정입니다. 

인증 방식은 기존에 사용해 오던 ConfigMap을 이어가려 합니다.  
단순하고 바로 관리가 가능하다는 점이 장점입니다.  

노드풀은 최소 2노드로 구성하여 안정성을 확보하고,  
Global DNS는 Istio Ingress와 연결해 외부 접근을 준비합니다.  

이제 정말 클러스터를 생성해 보겠습니다!

1. 클러스터 생성

Console 에서 Clusters 메뉴로 들어가줍니다.

Clusters는 Ncloud Kubernetes Service의 하위 메뉴로 있습니다.

자, 그럼 바로 생성하기 버튼을 클릭해 Cluster를 생성해보겠습니다!

클러스터 설정

클러스터 설정 부분입니다. 천천히 항목을 설정드리겠습니다.

• 클러스터 이름: 자유롭게 기입합니다
• 하이퍼바이저: 위에서 미리 정한대로 Xen 타입을 선택했습니다.시스템 성격에 따라 KVM 하이퍼바이저를 선택하셔도 됩니다.
  다만, NCP의 경우 하이퍼바이저에 따라 Nodepool에서 선택할 수 있는 Node OS의 종류가 제한되는 경우가 있어
  확인이 필요합니다.
• VPC: 생성한 VPC를 선택합니다.
• 네트워크 타입: 클러스터의 타입은 Subnet에서 생성한 대로 Private 으로 진행하겠습니다
• LB Private / Public Subnet: Subnet에서 생성한 로드밸런서 Subnet들이 자동으로 선택됩니다.
  원하는 로드밸런서 Subnet이 아닐 시 변경하시면 됩니다.
• 최대 노드 수: 저희 시스템은 대형서비스가 아니기 때문에 10개를 선택했습니다.
• 반납 보호: 실수로 클러스터를 삭제하는 일이 없도록 설정 으로 선택하시는걸 권장드립니다.
• 클러스터 인증 모드: 위에서 미리 정한대로 ConfigMap 타입으로 선택했습니다.
• 시크릿 암호화: 시크릿 암호화는 이미 스토리지 레이어에서 암호화 되어 있다고 되어있어 저희는 설정하지 않았습니다.

노드풀 설정

• 노드풀 이름: 자유롭게 기입합니다
• 서버 이미지 이름: 사용환경에 맞는 os를 선택하시면 됩니다. 현재 하이퍼바이저에선 우분투밖에 선택지가 없어,
  최신 버전의 우분투로 선택했습니다.
• 서버 타입: 필요한 서버 스펙에 맞추어 선택하시면 됩니다. Dev용 클러스터이기 때문에 최소한의 스펙을 선택했습니다.
• 노드 수: 위에서 미리 정한대로 2개를 선택했습니다. 필요한 스펙에 맞추어 갯수를 선택하시면 됩니다.
• Subnet: nodepool 용으로 만들어둔 Subnet을 선택합니다.
• k8s Label: 필요에 따라 Label을 추가합니다. 이번 클러스터에는 추가하지 않았지만, 
  LLM 관련 클러스터를 구축할 당시 GPU 서버와 아닌것을 구분하기 위해 구분자로 추가했었습니다.

* 노드풀 설정에서 값을 입력하신 뒤 꼭 추가 버튼을 누르신 뒤에 다음으로 이동하셔야 합니다!

인증키 설정

인증키는 물리 파일로 패스워드를 대신하는 개념이라고 생각하시면 됩니다.

기존에 보유하고 있는 인증키가 있다면 그대로 사용하셔도 되고, 새롭게 생성하셔도 됩니다.

서버에 접속하기 위한 관리자 패스워드를 확인하려고 할때에도 필요하니 꼭 잘 보관해주세요!

최종확인

잘 입력했는지 확인하신 뒤, 생성하기 버튼을 눌러줍니다.

(저는 캡쳐하면서 작성하는게 익숙치 않아 두번이나 다시만들었습니다...노드풀 이름에 오타가 있는데 이번엔 그냥 넘어가려고요..)

그러면 이렇게 생성중이라는 표시가 나오는데요, 다른 생성에 비해 시간이 많이 소요되니 여유롭게 기다려주세요!

기다리면서 아까 인증키 설정에서 생성한 인증키를 확인해보겠습니다.

인증키 확인

좌측 메뉴에서 서버 메뉴로 이동하면 저희가 방금 생성한 노드 서버들이 만들어지고있는데요,

서버 관리 및 설정 변경 셀렉트박스에 인증키 관리에 아까 생성해둔 인증키가 보입니다!

이 쪽은 보안 상 캡쳐사진은 생략하겠습니다.

2. ncp-iam-authenticator 설정

클러스터가 생성되었으니, 이번엔 이어서 클러스터에 접근하여 관리할 수 있도록 ncp-iam-authenticator를 설정해주겠습니다.

공공 기관용 NCP의 공식 문서

https://guide-gov.ncloud-docs.com/docs/k8s-iam-auth-ncp-iam-authenticator

크게 어렵지 않으니 순서대로만 따라오시면 됩니다!

ncp-iam-authenticator 설치

윈도우나 mac 환경으로 할까 하다가 깔끔하게 ubuntu 리눅스로 진행했습니다. (저희는 개발자니까요!)

root 계정으로 진행해주세요!

공식 문서에 기반하여 아래 커맨드들을 순서대로 입력해주겠습니다.

# ncp-iam-authenticator 설치
curl -o ncp-iam-authenticator -L https://github.com/NaverCloudPlatform/ncp-iam-authenticator/releases/latest/download/ncp-iam-authenticator_linux_amd64

# 실행권한 부여
chmod +x ./ncp-iam-authenticator

# PATH 추가
mkdir -p $HOME/bin && cp ./ncp-iam-authenticator $HOME/bin/ncp-iam-authenticator && export PATH=$PATH:$HOME/bin

제가 자꾸 ls -l 커맨드를 입력하는 이유는 설치가 잘 되었는지,

현재 디렉토리에 ncp-iam-authenticator가 잘 있는지 확인하기 위함입니다.

ncp-iam-authenticator help

설치가 다 완료되었다면 위 코드로 정상적으로 잘 설치되었는지 확인합니다.

configure 생성

공공 기관용 NCP의 공식 문서

https://guide-gov.ncloud-docs.com/docs/k8s-iam-auth-kubeconfig

이어서 사용자를 인증할 configure 파일을 생성해보겠습니다.

# home 디렉토리 이동
cd ~

# ncloud 디렉토리 생성
mkdir .ncloud

# 디렉토리 이동
cd .ncloud

# vi 편집기 열기 (+파일 생성)
vi configure

그럼 이러한 vi 편집기 창이 나오는데요,

i 를 눌러서 입력 모드로 변경해줍니다. 맨 아래에 "-- INSERT --" 표시가 생겼네요.

ncloud_access_key_id = ACCESSKEYACCESSKEYAC
ncloud_secret_access_key = SECRETKEYSECRETKEYSECRETKEYSECRETKEYSECR
ncloud_api_url = https://ncloud.apigw.gov-ntruss.com

ncloud_access_key_id 와 ncloud_secret_access_key 를 확인하려면, 

우측 상단 계정을 클릭한 뒤, 계정 관리로 이동해주세요.

다시 패스워드 입력과 2차인증을 해주세요.

(세상에서 제일 귀찮습니다...)

인증키 관리 탭으로 이동하시면 API 인증키 관리 부분이 있는데요,

저처럼 이미 있는 경우엔 해당 키를 사용해주시면 되고, 없으신 경우 신규 API 인증키 생성 버튼을 눌러 생성해주시면됩니다.

다시 커맨드 창의 vi 편집기로 돌아와 작성을 마치신 뒤,

ESC 를 눌러 입력 모드를 종료하고

: (콜론) 을 누르신 뒤 wq 를 입력하시고 엔터를 눌러주세요 (저장)

그러면 정상적으로 configure 파일이 생성됩니다

kubeconfig 생성

이제 특정 클러스터에 정보가 담겨있어 해당 클러스터에 접속할 수 있게 해주는 kubeconfig 파일을 만들어줄겁니다.

콘솔 NKS에서 클러스터를 클릭해보면 상세정보가 나오는데

괄호 안에 있는 UUID를 복사해주세요. (UUID 오른쪽에 있는 복사 버튼을 사용하셔도 됩니다)

# ncloud 디렉토리 이동
cd ~/.ncloud

# kubeconfig 파일 생성
ncp-iam-authenticator create-kubeconfig --region kr --clusterUuid <cluster-uuid> --output kubeconfig.yaml

위 코드블럭의 <cluster-uuid> 부분에 복사하신 uuid를 입력해주세요.

kubectl --kubeconfig ~/.ncloud/kubeconfig.yaml get namespaces

위 커맨드를 입력하면 방금 생성한 클러스터의 네임스페이스가 잘 나오는 것을 확인할 수 있습니다!

(번외) kubectl 설치

혹시나 kubectl이 설치되지 않아 위 커맨드가 정상적으로 작동하지 않는다면 아래대로 따라와주세요.

k8s 공식문서

https://kubernetes.io/ko/docs/tasks/tools/install-kubectl-linux/

# kubectl 설치
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

# 실행 권한 부여
chmod +x kubectl

# 시스템 경로에 이동
sudo mv kubectl /usr/local/bin/

# 확인
kubectl version --client

위 커맨드를 순서대로 입력해주시면 됩니다.

이제 클러스터 설치가 완료되었고 kubectl로 해당 클러스터에 접근하여 관리할 수 있게 되었습니다.

여기까지 되었다면 기존에 사용하시던 방식대로 클러스터를 사용하셔도 무방하고,

다음에 이어질 ISTIO 설치와 Global DNS 연동

NCP 내의 CI/CD (source commit - source build - source deploy)까지 함꼐 연동하셔도 좋을 것 같습니다.

다음 번에는 해당 클러스터에 ISTIO를 설치해보겠습니다.

감사합니다.

(지난 글 - VPC & Subnet 설계)

https://har00n.tistory.com/8

VPC와 Subnet 설계에 이어, 오늘은 NAT Gateway와 Route를 설정해보겠습니다.

지난 번과 마찬가지로 NAT Gateway에 대한 설명은 아래 유튜브에 재밋게 설명되어있습니다.

(추후에 따로 다룰 일이 있다면 링크를 수정할 수 있습니다)

https://youtu.be/LbGS7s67Rh0?si=_Q8wGBDLG-YRqdSt

운영 환경에선 보통 Private Subnet에 공인 NAT Gateway를 써서 외부 접근을 통제된 방식으로 허용하는데요.

Inbound는 차단되어있고 Outbound만 허용되니 보안적으로도 문제가 없습니다.

요약하자면, VPC 내에서 외부랑 통신을 해주는 일방통행 비밀통로 정도로 생각하시면 될 것 같습니다.

1. NAT Gateway 생성

Console에서 NAT Gateway (New) 메뉴로 들어가줍니다.

NAT Gateway는 VPC의 하위 메뉴에 있습니다.

현재 저희의 prod 환경과 staging 환경의 NAT Gateway가 이미 만들어져 있는데요,

여기에 dev 환경에서 사용할 NAT Gateway를 생성해주겠습니다.

NAT Gateway 생성을 클릭해서 생성 팝업을 띄워줍니다.

• NAT Gateway 이름: 자유롭게 기입 해주시면 됩니다.
• 유형: 저는 클러스터에 ISTIO 등 패키지를 외부에서 설치하고싶어서 공인으로 선택했습니다.
• VPC: 지난 번에 생성했던 VPC를 선택해줍니다.
• 서브넷 선택: 지난 번에 NAT Gateway 용도로 생성했던 Subnet이 자동으로 선택됩니다. 만약 여러개라면, 원하시는 Subnet을 선택해주세요.
• 공인 IP: 따로 할당된 공인 IP가 없어 새로 신청합니다.

상태가 운영중 으로 바뀌면 정상적으로 생성이 완료된 것입니다.

2. Route 설정

이번엔 Route Table 메뉴로 이동하여 Route를 설정해보겠습니다.

Private Subnet들에게 0.0.0.0/0 → NAT Gateway Route를 추가해 외부와 통신할 수 있게됩니다.

위 목록에서 봐야할 건 Subnet 지원 유형이 사설로 되어있는 wa-dev-vpc-default-private-table 인데요,

자동으로 생성되어있는 Route Table에 Route를 추가해줘야합니다.

해당 Route Table의 상세정보와 연관되어있는 Subnet들을 확인할 수 있고,

Routes 탭에는 기본적으로 VPC 내부 CIDR(10.0.0.0/16)이 목적지로 설정되어있습니다.

그러면, 해당 Route Table을 선택한 뒤에, Routes 설정을 눌러 Route를 추가해보겠습니다.

팝업 상단에 추가할 Route의 정보를 입력한 뒤 생성 버튼을 눌러줍니다.

• Destination: 0.0.0.0/0
• Target Type: NATGW
• Target Name: wac-dev-nat-gateway

설정한 값을 보면, 0.0.0.0/0 (모든 외부 요청)을 아까 생성했던 wac-dev-nat-gateway 로 보내겠다는 뜻입니다.

위와 같이 정상적으로 생성되었다면, 확인 버튼을 눌러 Route 생성을 완료합니다.

위 사진처럼 설정중에서 운영중으로 바뀌었다면, 정상적으로 생성이 된 것입니다.

자, 이로써 클러스터를 생성할 준비를 모두 마쳤습니다.

다음 번에는 본격적으로 클러스터와 노드풀을 생성해보겠습니다.

감사합니다.

안녕하세요,

오랫만에 블로그로 돌아왔습니다.

이번에 다룰 주제는 공공기관용 Naver Cloud Platform(ncp) 에서 kubernetes(k8s)로 SaaS 구축하기 입니다.

k8s에 대해 알고있어도 ncp 콘솔을 모르면 힘들다보니 이런 고민을 하시는 분들께 도움이 되었으면 좋겠습니다.

k8s 클러스터 환경을 구축하기 위한 첫번 째 단계는 VPC 및 Subnet 설정입니다.

VPC와 Subnet에 대한 설명은 아래 유튜브로 대신하겠습니다

https://youtu.be/LbGS7s67Rh0?si=_Q8wGBDLG-YRqdSt

* NCP 콘솔에 접근할 수 있는 상태라는 가정 하에 진행하겠습니다.

1. VPC 생성

https://www.gov-ncloud.com/

NCP 공공기관용 사이트에서 로그인을 한 뒤 콘솔에 접속합니다.

콘솔 메인 화면에서 플랫폼이 Classic으로 되어있다면, VPC로 변경해주세요.

Services 탭에서 VPC를 검색해 해당 메뉴로 이동해줍니다

기존에 prod와 staging용 클러스터에서 사용중인 VPC가 있는데요,

이번엔 이 대역을 피해서 dev용 VPC를 생성해보겠습니다.

저는 VPC 이름을 wa-dev-vpc로 정했고, IP 주소 범위를 10.0.0.0/16 으로 정했는데요,

저렇게 IP 주소를 작성하면 10.0.0.0 ~ 10.0.255.255 까지 사용이 가능합니다.
(10.0.0.0은 네트워크 주소, 10.0.255.255는 브로드캐스트 주소기 때문에 실제 사용은 불가합니다.)

저는 하위 subnet들을 10.0.1.0/24, 10.0.2.0/24 와 같이 설정해서

10.0.1.0 ~ 10.0.1.255, 10.0.2.0 ~ 10.0.2.255 이런식으로 사용하고싶어 대역을 이렇게 정했는데요,

사용하시는 환경에 맞추어서 설정하시면 됩니다!

2. Subnet 생성

VPC 상위 메뉴에서 Subnet Management로 이동해 Subnet을 생성해줍니다.

Subnet 이름은 원하시는 이름을 선택해주시면 되고, VPC는 아까 생성한 VPC를 선택해주시면 됩니다. 

저는 총 4가지의 Subnet을 생성하려고 합니다

1. 클러스터 Subnet
   • 이름: wa-dev-cluster-subnet (자유롭게 기입)
   • VPC: wa-dev-vpc (이하 동일)
   • IP 주소 범위: 10.0.0.0/24 (10.0.0.1 ~ 10.0.0.254)
   • 가용 Zone: KR-1 (이하 동일)
   • Network ACL: wa-dev-vpc-default-ACL (이하 동일)
   • Gateway 전용 여부: Private
   • 용도: 일반
2. 로드밸런서 Private Subnet
   • 이름: wa-dev-lb-private-subnet
   • IP 주소 범위: 10.0.1.0/24
   • Gateway 전용 여부: Private
   • 용도: LoadBalancer
3. 로드밸런서 Public Subnet
   • 이름: wa-dev-lb-public-subnet
   • IP 주소 범위: 10.0.2.0/24
   • Gateway 전용 여부: Public
   • 용도: LoadBalancer
4. NAT 게이트웨이 Subnet
   • 이름: wa-dev-nat-subnet
   • IP 주소 범위: 10.0.100.0/24 (일반적으로 100번 많이 사용)
   • Gateway 전용 여부: Public
   • 용도: NATGateway

다음 번에는 NAT Gateway와 Route를 구성해보겠습니다.

감사합니다.