1주차 - Docker & EKS 기초

월간-CS | 쿠버네티스 비기너 클래스
이민석's avatar
Jul 23, 2024
1주차 - Docker & EKS 기초

사전 준비

실습을 위해서 다음의 파일들이 준비되어야 합니다.

프로그램 설치

본 스터디에서는 기본적으로 eksctl을 사용했습니다.

  1. AWS CLI : aws의 리소스들을 cli를 이용해서 사용 가능

  2. kubectl : k8s 오브젝트들을 cli를 이용해서 제어 가능

  3. eksctl : aws eks cluster 생성부터 node group, vpc 설정까지 편리하게 사용 가능

개인적인 생각

본 스터디에서는 eksctl을 메인으로 하여 다양한 설정을 실제로 진행하는 좋은 구성을 가지고 있었습니다.

그 외에 aws console, terraform을 이용한 프로비저닝 방법에 대한 특징을 “개인적인 생각”으로 정리해보았습니다.

방식

특징

aws console

eksctl보다 조금 어렵게 프로비저닝 가능하다.
하지만 aws에서 무엇을 만드는지 알 수 있다.

eksctl

손쉽게 프로비저닝 가능하다.
하지만 eksctl이 aws에서 무엇을 만드는지는 따로 알아야 한다.

Terraform

가장 어려운 방식으로 프로비저닝이 가능하다.
하지만 IaC인 만큼 다양한 운영환경서비스에서 일관성있는 클러스터 운영이 용이하다.

실습 환경 준비하기

  1. EKS Cluster 생성하기

  2. EKS Cluster를 위한 OIDC Provider 설정하기

  3. EC2 Keypair 생성하기

EKS Cluster 생성하기

NodeGroup이 없는 상태의 EKS Cluster를 배포합니다.

eksctl create cluster           \
   --name=<custer_name>         \
   --region=<region_name>       \
   --zone=<az_zones>,<az_zones> \
   --without-nodegroup  

EKS Cluster를 위한 OIDC Provider 설정하기

Kubernetes의 ServiceAccount를 사용하기 위해서 AWS IAM Roles과 연결하기 위한 OIDC Provider를 설정해주세요.

eksctl utils associate-iam-oidc-provider 
   --region <region_name>   \
   --cluster <cluster_name> \
   --approve

EKS Keypair 생성하기

AWS CLI를 이용해서 EKS Keypair를 생성해주세요.
실제로 생성된 EKS NodeGroup(EC2)에 접속하기 위해서 사용됩니다.

aws ec2 create-key-pair \
   --key-name <key_name>

EKS NodeGroup 생성하기

AWS EKS NodeGroup을 생성할 때,
아래와 같은 명령어로 다양한 설정을 할 수 있습니다.

eksctl create node_group --help

추후에 배울 ExternalDNS, ASG, FullECRAccess,ApMesh. AlbIngressController 등에 관련된 권한을 몇 가지 add-ons flags를 사용하여 제어할 수 있습니다.

Cluster and nodegroup add-ons flags:
   --install-neuron-plugin   Install..
   --asg-access              enable IAM policy..
   --exteranl-dns-access     enable IAM policy..
   --full-ecr-access         enable full access..
   --appmesh-access          enable full access..
   --alb-ingress-access      enable full access..

실제로 아래의 명령어를 사용하여 EKS NodeGroup을 생성할 수 있습니다.

eksctl create nodegroup        \
   --cluster=<cluster_name>    \
   --name=<nodegroup_name>     \
   --node-type=t3.medium       \
   --nodes=2                   \
   --nodes-min=2               \
   --nodes-max=4               \
   --ssh-access                \
   --ssh-public-key=kube-demo  \
   --managed                   \
   --asg-access                \
   --external-dns-access       \
   --full-ecr-access           \
   --appmesh-access            \
   --alb-ingress-access

연결 확인하기

아래 명령어를 사용하여 cluster, nodegroup, nodes들에 대한 테스트를 할 수 있습니다.

eksctl get cluster
eksctl get nodegroup cluster=<cluster_name>

kubectl get nodes -o wide
kubectl config view --minify

Docker 기본 상식

K8s에서는 어플리케이션을 배포하기 위해서 컨테이너 기술을 사용합니다. 본 시리즈에서는 가장 대표적인 컨테이너 기술 중 하나인 docker를 사용합니다.

전체적으로 Docker가 무엇이며, 어떤 구조의 기술이며, DockerHub를 사용한 간단한 어플리케이션 실행을 배웠습니다.

Docker에 대하여

일반적으로 HW → OS → Library & Dependency로 구성된 환경을 사용하게 됩니다. 따라서 복수의 어플리케이션은 단일 환경에서 공존하며 실행됩니다.

하지만 가상화(Hypervisor) 기술을 사용한 기술인 VM이나 컨테이너(e.g. Docker, Containerd) 등을 사용하면 복수 어플리케이션이 개별적인 환경에서 실행됩니다.

과거 What is the Kata Container? 를 작성하면서 배웠듯,
VM과 컨테이너는 가상화 기기 위에 OS가 올라가는가로 구분할 수 있습니다.

이에 따라 당연히 컨테이너가 더 가볍지만, VM이 더 안전합니다.

강의에서는 컨테이너를 사용하는 6가지 이유에 대해서 아래와 같이 정리해주었습니다.

  1. 유연성(Flexible)

  2. 경량화(Light-weight)

  3. 이식성(Portable)

  4. 느슨한 결합성(Loosely-coupled)

  5. 확장성(Scalable)

  6. 보안(Secure)

하지만 엄연히 따지면 모든 컨테이너는 같은 운영체제(OS)를 사용하므로, 해당 부분이 치명적인 보안 취약점으로 작용할 수 있습니다.

Docker 구조

Docker는 크게 Client, Host, Registry로 구분됩니다.

  1. Client : build, pull, run 등의 명령어로 docker host와 통신

  2. Host : registry와 통신하여 images를 가져오거나 업로드하거나, 이를 기반으로 container화하는 영역을 실행

  3. Registry : 이미지 저장 및 공유

DockerHub 사용하기

docker login

cat ~/.docker/config.json

docker pull stacksimplify/dockerinfo-springboot-helloworld-rest-api:1.0.0-RELEASE

docker images

docker run --name app1 -p 80:8000 -d stacksimplify/dockerinfo-springboot-helloworld-rest-api:1.0.0-RELEASE


curl -X GET http://localhost:80/hello

docker ps -a

docker exec -it app1 /bin/sh

IMAGE_ID=<IMAGE_ID>
docker rmi $IMAGE_ID 

K8s 기본 상식

K8s 기본 구조

What is the Amazon EKS?를 비롯한 다양한 시리즈에서 배웠듯, 이번 강의에서도 기본적인 K8s 아키텍처를 배울 수 있었습니다.

K8s는 기본적으로 마스터 노드와 워커 노드로 구분됩니다.

  1. 마스터 노드

  2. 워커 노드

또한 마스터 노드는 아래와 같은 구성요소로 이루어져 있습니다.

  1. kube controller manager

  2. cloud controller manager

  3. kube-apiserver

  4. kube-scheduler

  5. etct

  6. container runtime (docker)

그리고 워커 노드는 다음과 같이 구성되어 있습니다.

  1. kubelet

  2. kube-proxy

  3. container runtime

Amazon EKS

Amazon EKS는 Control Plane과 Data Plane으로 구분합니다.

Control Plane은 일바적으로 K8s 마스터 노드를 포함하여 높은 수준의 가용성, 확장성 등을 보장합니다.

Data Plane 중 대표적인 유형인 Managed Node Group의 경우 N개의 워커 노드를 포함할 수 있습니다.

K8s Fundamental

쿠버네티스에서 어플리케이션을 배포하고 노출시키기 위해서 기본적으로 Pod, ReplicaSet, Deployment, Service 등으로 구성됩니다.

해당 부분은 Workload Management에 대하여 - 쿠버네티스 문서 딥다이브 | Deployment, StatefulSet, etc 에서 다루고 있어서 제외하겠습니다.

본 강의에서 대표적으로 다룬 내용은 다음과 같습니다.

  1. kubectl을 이용해서 pods 생성하기

  2. kubectl을 이용해서 replicaset 생성하기

  3. kubectl을 이용해서 deployment 생성하기

  4. kubectl을 이용해서 services 생성하기

현재 실무에서는 ArgoCD를 이용하여 Helm Chart를 릴리즈하고 관리 중입니다. 이 과정에서 Helm Chart는 자동으로 K8s Manifest 파일을 만들게 됩니다.

강의에서 알려준 방법은 Helm Chart, K8s Manifest와 같은 선언적인 파일이 아닌 cli 레벨에서의 상호작용을 통해서 K8s에 대한 기본적인 이해도를 기르는데 도움이 되어 보였습니다.

하지만 실제로는 IaC를 통해서 많은 이점을 누릴 수 있는 만큼 K8s Manifest나 Helm을 사용하는 것이 좋다고 생각합니다.

Share article

Unchaptered