DevOps Story

이 페이지는 Production Kubernetes에서 발췌한 내용을 번역, 요약한 내용입니다. Cluster Tier Kubernetes Cluster는 그 목적과 SLO/SLA 수준에 따라 보통 아래와 같이 4개의 Tier로 구분할 수 있다. 시스템을 낮은 티어에서부터 많이 사용해볼 수록 Production 환경에서 문제를 일으킬 가능성이 낮아진다. Testing 일시적(ephemeral); 1주 이내의 TTL을 가지며 자동 제거됨 Single-tenant; 단일 개발팀 로컬 환경의 클러스터(ex: minikube)에서 테스트하기 힘들 때 Application의 최초 컨테이너화 및 테스트 수행시 SLO, SLA 존재하지 않음 최신 또는 pre-alpha 버전의 Kubernetes 사용 Developm..

ApplicationSet이 왜 필요할까? K8s를 사용하는 조직이라면, 클러스터를 목적에 따라 여러개로 구분하여 활용하는 곳이 대부분일 것이다. 환경별(Dev, Staging, Prod 등) 클러스터를 따로 구성하거나, 규모가 큰 기업은 프로젝트, 팀 또는 계열사마다 따로 클러스터를 사용하는 경우를 예로 들 수 있다. 이제 Argo CD와 연결된 여러 개의 클러스터에 동일한 Application을 배포하는 경우에 대해 생각해보자. 예를 들어, Dev, Staging, Prod 클러스터에 Prometheus를 배포한다면, Argo CD에 이름만 다르고 내용은 같은 Application 3개를 추가해야 한다. 클러스터와 애플리케이션이 많아질 수록 이런 단순 반복 작업(Toil)이 늘어나기 때문에, 자동화가..

Cluster Bootstrap? 일반적으로 K8s 클러스터를 생성한 다음, 바로 Application을 배포하기 보단 원활한 클러스터 운영을 위해 시스템 애플리케이션 및 스택(Argo CD, Prometheus, Grafana 등)을 먼저 설치하는 경우가 많다. 클러스터가 얼마 되지 않고 앞으로 추가되는 경우도 없다면 큰 문제가 없지만, 계속해서 운영해야할 클러스터가 늘어난다면 이런 시스템 애플리케이션을 일종의 Bootstrap처럼 기본 제공하는 방안을 고려할 필요가 있다. 이 페이지는 Terraform을 통해 K8s 리소스(ex: Deployment, Service)를 생성하는 방법에 대해 설명한다. 다만 클러스터를 생성하는 과정은 벤더나 Public/Private 여부 등 환경에 따라 큰 차이가 있..

2022년 5월 4일, Kubernetes v1.24가 정식 릴리즈되었다. EKS, AKS와 같은 Managed K8s 서비스는 v1.22나 v1.23이 대부분이기 때문에 당장은 영향이 없겠지만, 어떤 점이 바뀌었는지를 파악하고 준비할 필요가 있다. k8s v1.24 변경점 마이너 버전업이지만 생각보다 많은 기능의 추가, 변경 및 삭제가 이루어졌는데 그 중에서 눈여겨볼 만한 변화는 다음과 같다. Dockershim 삭제 아마 이번 업데이트의 가장 큰 변화가 아닐까 생각된다. 기존 Docker의 CRI(Container Runtime Interface) 호환을 위해 존재했던 dockershim이 마침내 kubelet에서 제거되었다. 이미 작년부터 dockershim이 deprecation될 예정이라고 선언..

Terraform으로 Azure에 VM 인스턴스를 하나 생성해보자. 사실 생각보다 간단하지 않고, 생성해야 할 리소스가 꽤 많다. Resource Group Virtual Network Subnet Public IP Network Security Group 및 Rule Network Interface 및 Association Boot diagnostics 저장을 위한 Storage Account SSH Key VM Instance 위에서 나열한 리소스들을 다이어그램으로 표현하면 다음과 같다. 1. Terraform을 실행할 Directory를 생성한다. mkdir demo-vm && cd demo-vm 2. 아래와 같이 main.tf 파일을 작성한다. # Configure the Microsoft Azu..

Terraform을 통해 생성된 리소스의 상태(Terraform State)는 'terraform.tfstate' 라는 파일에 의해 관리된다. 이 파일이 저장되는 곳을 Terraform Backend라고 하는데, 기본적으로 terraform 명령어를 실행한 Local directory에 저장한다. 다만 설정을 통해 클라우드에 위치한 별도의 Storage(ex: AWS S3, Azure Storage Account)를 사용할 수 있다. 이 경우, Terraform을 실행하는 위치(개발자 Local PC, Bastion Host, Jenkins 등)와 관계없이 다양한 곳에서 항상 동일한 결과를 얻을 수 있다. 이번 시간엔 Azure에 Terraform Backend를 만들고, 이를 활용하는 방법에 대해서 설..

AWS와 마찬가지로 Azure 역시 Terraform을 통해 다양한 리소스를 생성할 수 있고, 원하는 인프라를 구성할 수 있다. 환경 설정 1. Terraform 설치 Terraform을 설치하는 방법에 대해선 링크를 참고한다. 2. Azure CLI 설치 Linux에서 아래 명령어로 Azure CLI를 설치할 수 있다. curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash 제대로 설치되었는지 다음 명령어를 수행한다. az version 3. Azure Login CLI를 통해 Azure에 로그인하기 위해 다음 명령어를 수행한다. az login 이후 브라우저를 통해 팝업되는 Login 메뉴에서 로그인을 진행한다. 로그인이 완료되면, CLI에서 현재 Subsc..

아래와 같이 PC A와 PC B가 서로 다른 네트워크에 위치했다고 가정하자. A가 B로 패킷을 보내려고 한다면, 어떤 것을 알고 있어야 할까. 복잡하게 생각할 것 없이 나와 직접 연결된 컴퓨터 중 B로 패킷을 전달해 줄 수 있는 Next Hop만 기억하면 된다. 중간 전달자 역할을 해줄 Next Hop 역시 다음 전달자에 대해서만 알면 궁극적으로 B까지 패킷을 전달할 수 있을 것이다. 이렇게 특정 IP 주소나 대역에 대해 Next Hop을 지정한 것을 Route라고 하며, Route를 한데 모아서 테이블로 구성한 것을 Route Table이라고 한다(사실 이렇게 단순한 원리로 동작하진 않지만, 이해를 돕기 위해 기본 개념만 설명하였다). Azure에서 VM을 생성하면 별다른 설정을 하지 않아도 기본 Ro..

Azure의 Resouce 권한 관리는 Role을 기반으로 이루어진다. 특정 Resource에 대한 접근은 해당 Identity에 Role이 부여가 되었는지 아닌지에 따라 결정된다는 뜻이다. 굳이 Azure뿐만이 아닌 다른 CSP(AWS, GCP)나 K8s 등에서도 보편적으로 사용하는 방식이다. Azure의 RBAC을 이해하기 위해선 Role, Security Principal, Scope에 대한 이해가 먼저 필요하다. Role Action은 특정 Resource 및 해당 속성에 대해 수행할 수 있는 작업(Read, Write 등)을 의미한다. 예를 들어 Virtual Machine 인스턴스를 가동에 대한 Action은 'Microsoft.Compute/virtualMachines/start/action..

Virtual Network AWS의 VPC(Virtual Private Cloud)와 동일한 개념으로, Azure 역시 Private Network를 구성하기 위해 Virtual Network(VNet) 라는 리소스를 제공한다. VNet 위에 VM 인스턴스 등의 리소스를 배포하여, 다른 VM이나 인터넷과 통신할 수 있다. VNet 생성시 어떤 Region에 구성할 것인지 선택해야 하며, 하나의 VNet은 다시 여러개의 Subnet으로 분할할 수 있다. 기본적으로 VNet 간에는 서로 다른 네트워크에 위치한 것으로 인식하며, 직접적인 Communication이 이루어지지 않는다. 예를 들어 VNet01(10.1.0.0/16)과 VNet02(10.2.0.0/16)이 있다고 가정하자. 각 VNet에 defa..