AKS로 쿠버네티스 시작하기 : 사용한 명령어

broccoli 23.08.31

6,621 11 0

facebook twitter kakao link

11 0

facebook twitter kakao link

DEVOTEE 요약: IT 시스템을 시작하게 되면 처음으로 해당 시스템을 생성하거나 동작시키는 명령어를 사용하게 된다. AKS로 구축 진행한 경험을 토대로 AKS 클러스터 생성과정, AKS 환경 구성, kubectl 명령어 사용, 리소스 생성 및 삭제, namespace 사용, ingress-controller 설치, SSL 접속 방식 구성 등의 명령어 사용 방법을 설명한 글이다.

DEVOTEE 추천 블로그

IT 시스템을 시작하면 접하는 명령어

새로운 IT시스템을 시작하게 되면 처음 만나는 것 중에 해당 시스템을 생성하거나 동작시키는 명령어가 있다.

실제 구축과정에서 사용한 명령어를 정리해 보기로 하였다. AKS로 구축 진행했던 과정에서 인상에 남는 내용들로 정리를 하였다.

AKS는 물론 쿠버네티스 기반이므로 쿠버네티스 명령어가 주로 사용되었다. azure portal UI 나 azure cli도 사용이 되었다.

구축과정의 명령어를 위주로 정리하였고, 운영과정에서의 사용성이 높은 명령어도 추가할 것이다.

AKS 클러스터를 처음 생성하고 확인하기

azure portal UI로 진행가능하지만, 아래의 azure cli 로 클러스터를 생성할 수 있다.

# 1. 구독 설정
$ az account set --subscription <구독명>
# 2. 클러스터 생성
$ az aks create \
    --resource-group <리소스그룹명> \
    --name <클러스터명> \
    --node-count 3 \
    --generate-ssh-keys

실행 결과]

아래의 명령어로 Azure CNI 플러그인 사용, 서브넷 지정 등 추가로 설정하여 생성할 수 있다.

$ az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \ 
  --network-plugin azure \
  --vnet-subnet-id <subnet-id> \
  --docker-bridge-address 172.17.0.1/16 \
  --dns-service-ip 10.2.0.10 \
  --service-cidr 10.2.0.0/24

AKS를 다루기 위한 환경 구성하기

쿠버네티스를 로컬PC에서 접속해서 관리를 손쉽게 할 수 있다. 그리고, 자주 쓰는 명령어를 편리하게 사용할 수 있도록 준비하여 사용하자.

1. AKS를 로컬PC에서 접속하기 환경 구성

azure portal에서 생성한 aks리소스에 대해 아래의 azure portal에서 config 파일을 준비하는 환경 설정으로 이후부터는 자신의 PC에서 자유롭게 구성을 진행할 수 있다.

Kubernetes 클러스터에 접속하기 위한 Credential 설정 과정은 아래와 같다.

# 1. 구독 설정
$ az account set --subscription <구독명>
  
# 2. 지정한 AKS 클러스터의 접속 정보(credentials)를 가져와 kubeconfig 파일에 저장
$ az aks get-credentials --resource-group <리소스그룹명> --name <클러스터명>
  
# 3. 특정 컨텍스트를 기본 컨텍스트로 설정
$ kubectl config use-context <클러스터명>
  
# 4. kubeconfig에 저장된 모든 컨텍스트 정보를 확인
$ kubectl config get-contexts
  
# 5. 모든 컨텍스트 정보를 저장하는 kubeconfig 파일 위치
$ cd ~/.kube/config

2. kubectl을 편하게 사용 '자동완성과 alias'

자동완성과 alias 를 사용해서 자주 이용하게 되는 kubectl을 편리하게 사용 가능하자

# BASH
source <(kubectl completion bash) # set up autocomplete in bash into the current shell, bash-completion package should be installed first.
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.

alias k=kubectl
complete -o default -F __start_kubectl k


# ZSH
source <(kubectl completion zsh)  # set up autocomplete in zsh into the current shell
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # add autocomplete permanently to your zsh shell

AKS로 구축하기

1. 클러스터의 구성 정보 확인

aks를 구성하면 노드를 중심으로 정보를 확인하게 된다. 여기서 노는 control plane을 제외한 워커노드를 의미한다.

# 노드 정보 보기 
$ kubectl get nodes
# 노드 정보 상세 보기
$ kubectl describe node <노드이름>
# 클러스터 정보 보기 
$ kubectl cluster-info
# 클러스터 정보 상세 보기 
$ kubectl cluster-info dump

노드의 상세 정보는 descirbe 명령으로 확인한다.

$ kubectl describe node <노드이름>

ㅇ 아래의 예시를 참조해 볼 수 있다. 찾아 보게 되는 정보는 용량, 수용 가능 pod 개수, 서브넷 정도였다.

2. 가장 많이 사용한 'k9s'툴

k9s를 사용하면 클러스터의 기본 정보 부터 pod의 내용까지 편리하게 정보를 확인해 낼 수 있다.

위 k9s툴을 볼 때, 처음 설치하고 나서 라인들이 깨지는 경우가 있을 땐, 아래의 내용을 추가하면 된다.

.zshrc 에 아래의 내용 추가하면 해소
# zshrc
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"

3. Default 컨텍스트 변경

mgmt/dev/stg/prd별로 클러스터를 생성해서 구축을 하다보니 컨텍스트를 변경해야 할 일이 많아졌다.

아래의 명령어로 수행이 가능하지만 확인과 변경에 번거로움이 있어 kubectx를 자주 사용하게 되었다.

- 컨텍스트의 정의 : context는 kubeconfig 파일에서 클러스터, 사용자, 네임스페이스에 대한 정보를 그룹화한 설정 단위

$ kubectl config get-contexts
$ kubectl config use-context <클러스터명>

$ kubectx

kubectx 는 brew install kubectx 로 간편하게 설치하여 사용 가능하다.

- 노란색이 현재 상태에서 지정된 기본 컨텍스트

4. namespace를 항상 명시

처음 리소스 생성 후 확인하는 과정에서 당황하는 경우가 있다. 조회시 네임스페이스를 꼭 기입해야 확인이 된다. 하지만, 여러 번 빼먹고 당황하고 했다.

$ kubectl get svc ingress-nginx-controller
Error from server (NotFound): services "ingress-nginx-controller" not found
# 분명히 설치를 했는데 안 보이니 처음에는 당황한다. 

# 네임스페이스를 명시하면 리소스 확인이 가능하다. 
$ kubectl get svc ingress-nginx-controller  -n ingress-nginx
NAME                       TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller   LoadBalancer   10.0.7.81    10.26.0.5     80:30684/TCP,443:31840/TCP   76d

5. 리소스 생성과 삭제

yaml파일을 준비하고 kubectl apply 명령과 kubectl delete 명령으로 간단히 가능하다.

$ kubectl apply -f <yaml 파일명>
$ kubectl delete -f <yaml 파일명>

6. 단순 설정 오류 시 빠르게 삭제

초기라서 단순한 yaml 설정 오류로 삭제하는 경우가 빈번하게 일어났다. 많은 시간을 대기하는 경우가 많았으나 시간 낭비만 발생했다. 이미 오류를 눈치채고 빠르게 바꾸는 것이 현명하므로 강제로 삭제하는 것이 효율적이다.

$ kubectl delete pod <파드명> --grace-period=0 --force -n <네임스페이스명>

신속하게 삭제가 되어 업무 효율에 도움이 많이 되었다.

7. 삭제 후 생성

리소스의 yaml을 변경하고 재적용할 경우 반영이 안되는 경우들을 만났다.

깔끔하게 삭제후에 생성하는 편이 더 좋은 경우가 많으니 삭제하고 진행하는 것을 권한다.

8. 생성한 리소스 한 번에 파악

helm등으로 설치된 리소스를 한 번에 파악하기에는 kubectl get all 명령어를 활용했다.

$ kubectl get all -n datadog
NAME                                         READY   STATUS    RESTARTS   AGE
pod/datadog-cluster-agent-56684b85bd-5zp6q   1/1     Running   0          2d2h
pod/datadog-f7glf                            3/3     Running   0          8d
pod/datadog-j259t                            3/3     Running   0          2d2h
pod/datadog-nn5mw                            3/3     Running   0          8d
pod/datadog-z2km2                            3/3     Running   0          17h

NAME                                                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/datadog                                      ClusterIP   10.0.150.173   <none>        8125/UDP   8d
service/datadog-cluster-agent                        ClusterIP   10.0.239.145   <none>        5005/TCP   8d
service/datadog-cluster-agent-admission-controller   ClusterIP   10.0.110.163   <none>        443/TCP    8d

NAME                     DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/datadog   4         4         4       4            4           kubernetes.io/os=linux   8d

NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/datadog-cluster-agent   1/1     1            1           8d

NAME                                               DESIRED   CURRENT   READY   AGE
replicaset.apps/datadog-cluster-agent-56684b85bd   1         1         1       8d

9. ingress-controller를 설치

도메인 기반으로 pulic 접속을 위해 ingress-controller 설치와 ingress 설정이 필요하다.

yaml 파일을 이용해서 ingress-controller 를 손쉽게 설치할 수 있다.

참고로 FD등 앞 단에 게이트웨이들 둔 상태에서 ingress-controller를 설치하는 경우에는 아래의 yaml 파일에서 internal LB에 대한 설정과 네트워크 설계에 따라 도출된 internal IP 정보를 기입하여 설치하면 된다.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/cloud/deploy.yaml

10. SSL 접속 방식 구성

argocd와 같은 툴을 도메인 접속을 통해 SSL 방식으로 구성하려는 경우에는 secret 리소스를 생성하여 수행한다.

확보한 인증서로 아래의 명령어로 secret을 생성하면 되고, 사용자 접속은 https를 지원하게 된다.

$ kubectl create secret tls <tls명칭> \
   --cert {__dir__}/<인증서 파일 경로> \
   --key {__dir__}/<개인키 파일 경로> -n <네임스페이스명>

11. 생성 AKS에 acr(azure container registry)을 attach

프라이빗 이미지 저장소인 acr을 aks와 연결할 필요가 있다. az cli로 간단히 attach할 수 있어 편리하게 사용하였다.

$ az account set --subscription <구독명>
$ az aks update -n <클러스터명> -g <리소스그룹명> --attach-acr <acr명>

12. 배포하기 argocd 명령어

argocd를 배포하는 툴로 사용하고 있다. UI에서 배포할 수 있지만 구축과정에서 다수 배포시에는 argocd cli를 사용하면 편리하다.

# argocd 설치 후 패스워드 확인이 필요하며 아래의 명령으로 가능하다. 
$ kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d && echo

# 우선 클러스터로 서비스를 구성한 argocd를 LB로 일시적으로 변경한다. 해당 argocd로 로컬에서 로그인하기 위함이다. 
$ kubectl patch svc argocd-server -n <argocd 네임스페이스명> -p '{"spec": {"type": "LoadBalancer"}}' 
# 위의 LB IP로 로그인
$ argocd login <LB IP>
# 배포 명령어 수행 
$ argocd app create d-admin-portal \
  --repo <repo주소> \  
  --path <repo내 패키지의 설치 경로> \  
  --dest-server <배포할 타겟 클러스터> \
  --dest-namespace <네임스페이스명>

디버그 하기

k8s 리소스를 생성하고 나면 정상 동작하지 않는 경우들이 있다. 이 때 디버그하는 명령어를 사용하게 되는데, kubectl describe, kubectl log, stern을 사용하게 되었다.

서비스 라우팅 흐름을 확인하기 위해서는 ingress 정보를 봐야 한다.

1. 서비스 정보 흐름 확인 ingress

인그레스 라우딩이 어떤 호스트로 향하는지 확인이 가능하다.


$ kubectl get ingress p-ingress-aop -n aop
NAME            CLASS   HOSTS                                                                     ADDRESS     PORTS   AGE
p-ingress-aop   nginx   studio.ifland.io,studiocdn.ifland.io,oavataradmin.treal.xyz + 1 more...   10.27.0.5   80      19dd

2. 이벤트 확인 'kubectl describe'

ㅇ pod가 동작하지 않을 때, 발생 이벤트에 대한 내용도 알려 줘서 제일 먼저 보게 되었다.

아래에서는 'kubectl describe pod' 명령어로 pod의 yaml 구성정보, 볼륨 권한(여기서는 rw), Event, 상태, 기동시간, 재기동 횟수 등을 알 수 있다.

$ kubectl describe pod unitybuild-base -n unitybuild-base

Name:             unitybuild-base
Namespace:        unitybuild-base
Priority:         0
Service Account:  default
Node:             aks-agentpool2-12810365-vmss000001/10.26.1.39
Start Time:       Tue, 29 Aug 2023 10:06:42 +0900
Labels:           <none>
Annotations:      <none>
Status:           Running
IP:               10.26.1.118
IPs:
  IP:  10.26.1.118
Containers:
  unitybuild-base:
    Container ID:  containerd://569116547b0f6bbd2c19bb99ec2d5b78416eed2e3d22864aa2d031ce7cd57db9
    Image:         ubuntu:22.04
    Image ID:      docker.io/library/ubuntu@sha256:ec050c32e4a6085b423d36ecd025c0d3ff00c38ab93a3d71a460ff1c44fa6d77
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -c
      apt-get update
      apt-get install -y ca-certificates curl gnupg lsb-release
      curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
      echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null
      apt-get update
      apt-get install -y docker-ce docker-ce-cli containerd.io
      sleep 3600

    State:          Running
      Started:      Wed, 30 Aug 2023 06:08:33 +0900
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Tue, 29 Aug 2023 20:07:31 +0900
      Finished:     Wed, 30 Aug 2023 06:08:31 +0900
    Ready:          True
    Restart Count:  2
    Environment:    <none>
    Mounts:
      /scripts from script-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-nzfc9 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  script-volume:
    Type:          HostPath (bare host directory volume)
    Path:          /scripts
    HostPathType:
  kube-api-access-nzfc9:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              kubernetes.io/hostname=aks-agentpool2-12810365-vmss000001
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

kubectl describe를 잘 활용하면 Kubernetes 리소스 구성과 상태를 자세히 파악할 수 있다.

- Pod: Pod의 상태, 이벤트 로그, 컨테이너 로그 등 POD의 자세한 정보 확인

- Node: 노드의 자원 할당 상태, 조건 등 노드 정보 확인

- Deployment: 디플로이먼트 상태, 업데이트 기록, 이벤트 로그 등 배포 관련 정보 확인

- Service: 서비스의 선택자, 엔드포인트, 세션 어피니티 등 서비스 구성 정보 확인

- Ingress: 인그레스 규칙, 백엔드, 이벤트 로그 등 인그레스 정보 확인

- ConfigMap: 컨피그맵의 데이터, 볼륨 마운트 정보 등 확인

- Secret: 시크릿 데이터, 타입, 볼륨 마운트 정보 등 확인

- PersistentVolume: PV의 용량, 접근 모드, 상태 등 범용 볼륨 정보 확인

- Namespace: 네임스페이스의 리소스 할당 및 제한 범위 관련 정보 확인

3. 실시간 컨테이너 로그 확인 'stern'

모든 pod의 컨테이너 로그를 실시간으로 보여 준다.

# 1. 설치
$ brew install stern
  
# 2. 사용
$ stern <파드명> -n <네임스페이스명>

아래와 같이 실시간으로 pod가 구성되고, 동작하는 상태를 로그로 모니터링 할 수 있다.

운영하기

운영 초기 단계라서 아직 많은 명령이 활용되고 있지는 않다. k9s 많이 활용하고, argocd에서도 운영에 필요한 정보를 쉽게 찾아볼 수 있어 유용하게 사용하고 있다.

1. aks 버전 업그레이드

UI로 일반적으로 수행하지만 동작하지 않을 경우가 있다. az cli로 아래와 같이 간단히 수행할 수 있다.

az account set --subscription <구독명>
az aks upgrade   --name <클러스터명>    --resource-group <리소스그룹명>    --kubernetes-version <버전명>

2. 운영 pod의 QoS 확인

배포한 pod가 의도한 QoS(일반적으로 Gauranteed로 배포) 인지 확인

$ kubectl describe pods <파드명> | grep "QoS Class"

3. 로컬로 파일 복사

시스템에 있는 데이터 분석이 필요하여 NAS 저장된 파일을 로컬로 복사해야 했다.

pod로 NAS를 마운트해서 NAS에 있는 파일을 kubectl cp 명령어로 로컬로 복사할 수 있다.

$ kubectl cp <파드명>:/mnt/특정파일 .

정리

AKS로 쿠버네티스 시작하기에서 실제 시스템 구축을 진행하면서 사용한 명령어를 알아 보았다.

쿠버네티스 기반이라 다양한 클라우드 환경에서도 사용이 가능할 것이다.

AKS 환경에서 쿠버네티스를 구축하기 이전의 엔지니어라면 사전에 학습용으로 또는 실무 작업에 직접적인 도움이 될 만한 내용들도 될 것이다.

#Kubernetes #Azure

등록

DEVOTEE를 활성화 시키면
지금 작성한 댓글에 AI가 댓글을 달아줍니다.

익명

broccoli 님의 최신 블로그

LLM과 Reveal.js로 슬라이드를 쉽게 만들고 공유하기

블로그를 운영하다 보면 작성한 글을 슬라이드와 같은 형식으로 효과적으로 공유해야 할 때가 있습니다. 이럴 때마다 슬라이드를 처음부터 새로 만드는 것은 상당한 시간과 노력이 필요한 작업입니다. 하지만, LLM과 Reveal.js를 활용하면 작성한 글을 효율적으로 슬라이드로 변환하고, GitHub Pages를 통해 쉽게 게시하여 함께 볼 수 있습니다. 이 글에서는 그 과정에 대한 아이디어를 나누어 보도록 하겠습니다. 블로그 글을 슬라이드로 변환해야 하는 이유 블로그 글은 상세한 설명과 깊이 있는 내용을 담기에 적합한 형식이지만, 발표나 강연에서는 핵심 내용을 시각적으로 전달할 수 있는 슬라이드가 더 효과적입니다. 블로그 글을 슬라이드로 변환하면 유용한 상황들이 있습니...
빠르게 실행해 볼 수 있는 AI 시대 - 프로젝트에 투입해야 하는 서버

들어가는 말 빠르게 실행해볼 수 있는 AI 시대의 글로 이번에는 하드웨어 분야 서버에 관한 내용으로 공유해 보도록 하겠습니다. AI 기술의 발전은 우리 사회의 많은 영역에 변화를 가져오고 있으며, 특히 엔지니어링 전문 분야에서의 역할과 접근 방식에도 깊은 영향을 미치고 있습니다. 과거에는 특정 분야의 깊이 있는 전문성이 중요했지만, 이제는 AI를 통해 새로운 지식을 빠르게 습득하고 다양한 문제에 유연하게 대처하는 능력이 점차 중요해지고 있다고 말할 수 있을 것입니다. 온프레미스 환경에 노출된 개발자가 하드웨어를 다루는 과정의 내용을 통해 AI시대 엔지니어의 역할에 대해 생각해 볼 수 있는 기회가 되었으면 합니다. 예상치 못한 온프레미스 도전 풍부한 클라우드 환경에...
진짜 AI 에이전트형 코딩 툴 ＇Claude-Code＇

Claude Code 왜 지금 핫한가? Claude Code란? Claude Code는 Anthropic에서 개발한 AI 기반 코딩 에이전트입니다. 단순한 코드 자동 완성 기능을 넘어 자율적(agentic) 코딩을 지원하는 강력한 도구입니다. 2025년 현재, Claude Code는 개발자가 복잡한 소프트웨어 프로젝트를 계획하고, 작성하며, 디버깅하고, 배포하는 전 과정을 자동화하거나 간소화할 수 있도록 설계되었습니다. 기존 AI 코딩 도구(예: Copilot, Cursor)는 코드 자동완성‧스니펫 제안에 초점이 있지만, Claude Code는 전체 코드베이스를 실제로 탐색, 분석, 수정, 커밋, 푸시까지 ‘엔지니어처럼’ 처리하는 AI 도구입니다. 예를 들어, 사...
KVM 기반 VM의 외부 접근성 향상을 위한 브리지 네트워크 구성

들어가는 말 올해 프로젝트는 온프레미스 환경에서의 도전 과제들이 많이 발생되고 있습니다. 그 중의 하나로 외부 네트워크를 통해서 호스트에 접속한 후에 호스트에 구성된 KVM 기반의 VM에 접속하는 불편을 해결하는 요구사항에 대한 과제입니다. 즉, 외부에서도 VM(가상머신)에 직접 접속할 수 있는 방법의 제시가 필요합니다. 브리지 네트워크 구성 방식의 특징 브리지 네트워크는 KVM 기반 VM에 외부에서 접근할 때 일반적으로 선호되는 방식입니다. 직접적인 IP 할당 : 브리지 네트워크를 사용하면 VM이 호스트와 동일한 네트워크에 존재하게 되어, VM에 IP를 직접 할당할 수 있습니다. 이는 NAT(Network Address Translation) 방식과 달리, VM...

DEVOTEE 추천 블로그

On-premise에 Kubernetes 구축하기(with Netapp Storage)

안녕하세요. SK텔레콤 플랫폼개발팀 장규승입니다. 최근 Kubernetes 을 이용하기 위해서는 Public Cloud 에서 제공하는 PaaS 상품을 이용하는게 일반적이지만, 기존 On-premise 데이터센터에 여유있는 리소스를 활용 할 수 있는 경우와 또한 Private한 Kubernetes를 환경을 구축해야하는 경우는 여전히 On-premise 환경에서의 Kubernetes 구성에 대한 요구가 존재 합니다. 아래 작성된 내용은 현재 On-premise 환경에서 운영하고 있는 Kubernetes 구축 내용을 command (kubeadm 활용) 단위로 정리 하였습니다. 안타깝게 최신버전이 아닌 Kubernetes 1.26 기반으로 작성되어 있으나, 1.26 ...
External Cloud Provider 사용하여 Kubernetes와 AWS 인프라 연동하기

이 글은 EKS와 같은 퍼블릭 클라우드에서 제공되는 매니지드 쿠버네티스가 아닌 EC2 인스턴스 위에 직접 쿠버네티스 클러스터를 구축하고 이를 AWS 인프라와 연동하는 내용을 다루고 있습니다. seungkyua님이 쓰신 글 에서 Legacy Cloud Provider를 사용하여 AWS Loadbalancer 서비스를 사용하는 방법에 대해 소개를 하신 적이 있습니다. 해당 글에서 언급된 것처럼 퍼블릭/프라이빗 클라우드 인프라와 연동하기 위한 Cloud Provider들이 Kubernetes 에 내장되었다가 현재는 독립적인 형태로 제공되고 사용되고 있습니다. AWS in-tree Cloud Provider는 v1.27 버전에서 삭제 되었고 이후 버전부터는 Externa...
AKS 상용 서비스 적용기 (1) - Jenkins를 활용한 CI 구성

시작하는 글 안녕하세요, dragonpipe입니다. 이 번 게시글 부터 5~6차례에 거쳐서 AKS(Azure Kubernetes Service)를 활용하여 상용 서비스에 API 서버를 띄운 경험에 대해 공유드리려고 합니다. 그 중 첫 번째 글인 이번 포스트 에서는 어떤 기술스택을 활용하였고, 그 중에서도 CI를 구성한 방법에 대해 설명드리겠습니다. 기술 스택 및 CI/CD 전략 제가 사용하였던 기술 스택은 아래 이미지와 같습니다. Spring-boot로 개발된 서비스 소스를 Gitlab에 저장하고 Jenkins에서 이 소스를 내려받아서 빌드한 후 결과물인 docker image를 Azure의 컨테이너 저장소인 ACR(Azrue Container Repository...
AKS 상용 서비스 적용기 (2) - Argocd를 활용한 CD 구성

시작하는 글 안녕하세요, dragonpipe입니다. 이 번에는 지난 포스트에 이어 AKS(Azure Kubernetes Service) 상용 서비스에 적용한 후기 두 번째 내용으로, ArgoCD를 활용한 CD(Continueous Deployment) 방법에 대해 소개드리려고 합니다. ArgoCD란? ArgoCD는 이미 너무 유명해서 잘 알고 계실거라고 생각하는데요. 구글이나 여러 기술 사이트에 조금만 검색해도 상세한 설명이 쉽게 찾아 볼 수 있어서 따로 설명드리지는 않고 기본 정의만 아래에 추가 하였습니다. ArgoCD는 Kubernetes 환경에서의 애플리케이션 배포와 관리를 지원하는 도구로, GitOps 원칙에 기반하여 설계되었습니다. 기본적으로 Git 저장...

목록으로

DEVOCEAN

로그인 선택

미리보기

커뮤니티

글 등록

임시저장함

데보션 블로그 게재 요청