kubectl을 외부(windows) 환경으로 빼 windows를 클라이언트로 만들고,VM의 클러스터와는 별개로 AWS EKS 클러스터를 윈도우의 kubectl에 연결하는 형태로 운영할 것이다.
#VM에서 내용 카피
cat .kube/config
#git bash로 옮기기
cd ~/.kube
vi config #카피한 내용 붙여넣기
#IP를 control node의 IP로 수정
server: https://192.168.56.11:6443
name: cluster.local
contexts:
- context:
EKS에서 쿠버네티스 클러스터를 생성하는 데에는 두 가지 방법이 있다.
1. eksctl을 통해 생성
2. 웹 인터페이스를 통해서 생성
웹 인터페이스에서 쿠버네티스 클러스터를 생성하는 것은 오히려 훨씬 복잡하고 커스터마이징이 어렵다. 따라서 eksctl을 이용해서 쿠버네티스를 배포할 것이다.
choco install eksctl
choco install awscli
choco install aws-iam-authenticator
설치가 완료 되었으면 AWS 콘솔의 "보안자격 증명" 페이지에서 액세스 키 만들기를 클릭한다.
CLI로 선택한 후 액세스 키를 생성한다. .csv 파일을 다운받아 두고 git bash에서 액세스한다.
aws configure
Access key와 Secret Access key는 발급 받은 것을 입력하면 되고, region과 output format도 그대로 둔다.
aws sts get-caller-identity --no-cli-pager
ID가 정상적으로 나오면 제대로 설정한 것이다.
AWS 명령어가 사용 가능하므로, eksctl 명령어를 통해서 클러스터를 생성할 수 있게 되었다.
eksctl create cluster --name myeks --region ap-northeast-2
myeks가 생성된 것을 확인할 수 있다. 보안그룹, VPC, EC2 등이 모두 생성되어 있음을 확인할 수 있다.
위가 노드, 아래가 컨트롤플레인이다.
kubectl config view
명령어로 확인해 보면 eks의 클러스터가 자동으로 추가되어 있는 것을 확인할 수 있다. user 부분도 사용자의 AWS IAM 계정과 연결되어 있다. aws-iam-authenticator라는 명령어를 이용해 실제로 인증을 하게 되는 부분이다. 여러가지 명령어를 이용해 쿠버네티스의 config 를 확인할 수 있다. 또한 kubectx나 kubens 같은 추가 패키지도 다운받아 사용할 수 있다.
kubectl config get-clusters #클러스터 목록 확인
kubectl config get-users #유저 확인
kubectl config get-contexts #컨텍스트 확인
kubectl config use-context <context명> #컨텍스트 전환
kubectl config current-context #현재 컨텍스트 확인
eks 클러스터를 삭제하는 방법은 다음과 같다.
eksctl delete cluster --name myeks
eks 클러스터는 m5.large 사이즈의 워커 노드가 만들어진다. 사용자는 yaml 파일로 eks 클러스터를 원하는 셩태로 생성할 수 있다. 필드는 여기서 확인 가능하다.
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: myeks
region: ap-northeast-2
version: "1.24" #쿠버네티스의 버전
# AZ(가용 영역), 설정하지 않으면 3개의 가용 영역에서 랜덤으로 생성된다
availabilityZones: ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"]
# IAM OIDC & Service Account
iam: #AWS IAM
withOIDC: true #Open ID Connection
serviceAccounts: #미리 생성할 서비스 어카운트
- metadata: #인그레스용
name: aws-load-balancer-controller #계정
namespace: kube-system #네임스페이스
wellKnownPolicies: #AWS Role, SA에 역할을 붙인다
awsLoadBalancerController: true
- metadata: #볼륨용
name: ebs-csi-controller-sa
namespace: kube-system
wellKnownPolicies: #AWS Role, SA에 역할을 붙인다
ebsCSIController: true
- metadata: #클러스터 오토스케일러용
name: cluster-autoscaler
namespace: kube-system
wellKnownPolicies: #AWS , SA에 역할을 붙인다
autoScaler: true
# Managed Node Groups, EKS는 관리형이므로 컨트롤플레인을 AWS에서 관리해 준다.
managedNodeGroups:
# On-Demand Instance
- name: mynodes-t3
instanceType: t3.medium #인스턴스 타입
minSize: 1 #최소 용량
desiredCapacity: 2 #기본 용량
maxSize: 3 #최대 용량
privateNetworking: true #프라이빗 네트워크로 구성
#ssh:
#allow: true
#publicKeyPath: ./keypair/myeks.pub #프라이빗 네트워크에 있으므로 굳이?
availabilityZones: ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"] #가용 영역
iam: #역할들을 ec2 인스턴스에도 세팅해준다.
withAddonPolicies:
autoScaler: true
albIngress: true
cloudWatch: true
ebs: true
# Fargate Profiles
fargateProfiles: #서버리스
- name: myfg
selectors:
- namespace: dev
labels:
env: dev
# CloudWatch Logging
cloudWatch: #컨트롤플레인 로깅
clusterLogging:
enableTypes: ["*"] #모든 로그를 cloudwatch에 담는다.
AWS는 기본적인 애드온을 하나하나 다 설치해주어야 한다. 이 때 이 AWS 기능과 쿠버네티스 기능을 연동시켜주어야 하는데, 그러기 위해선 파드 내에 SA도 있어야 하고 SA가 AWS API 권한도 있어야 한다. 또한 역할도 미리 만들어서 SA에 연결시켜둬야 한다. 나중에 생성 하는 것도 가능하지만, 나중에 만들려면 여러모로 불편하기 때문에 미리 만들어 둬야 한다.
EKS는 관리형이므로 컨트롤플레인을 AWS에서 관리해 준다. 관리 비용으로 시간당 0.1$씩 받는다. 보통 컨트롤 플레인만 관리형이고 워커 노드는 비관리형과 관리형으로 나뉜다. 비관리형은 업데이트 등을 수동으로 해야 한다. 관리형은 이런 것들을 AWS에서 관리해 준다. 보통 관리형을 사용한다.
스팟 인스턴스 설정 방법은 다음과 같다. 스팟 인스턴스는 잡이나 크론잡을 사용할 때 임시로 사용한다.
컨트롤플레인은 직접 접속해서 관리할 수 없지만 api-server와 같이 컨트롤플레인만의 구성 요소의 로그는 필수적으로 확인해야 한다. 이런 컨트롤플레인의 로그는 cloudwatch를 사용해서 확인이 가능하다.
zsh는 요즘 자주 사용하는 shell의 종류이다. git-bash를 이용하여 윈도우에서도 사용할 수 있다.
vi ~/.bashrc #bashrc 파일 생성
if [ -t 1 ]; then
exec zsh
fi #bash 설정, zshell을 사용하라는 뜻
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k
vi ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k" #테마 설정
마음에 드는 형태로 구성한다. (p10k configure로 다시 설정 가능하다.)
플러그인을 설정한다.
vi ~/.zshrc
plugins=(git kubectl kube-ps1 helm) #80번째 라인 수정
6개의 스택이 생성 완료되어 있는 것을 확인할 수 있다.
AWS IAM = API 서버 엔드포인트
ec2 서브넷은 프라이빗 서브넷에 붙어 있다. yaml 파일에서 설정해놨기 때문이다.
external IP가 none으로 되어 있다.(=인터넷에 직접적으로 연결되어 있지 않다.) 프라이빗으로 내부에 숨겨두는 것이 보안에 좋기 때문이다.
설정대로 오토 스케일링의 최소 최대가 설정되어 있는것을 확인 가능하다.
kubens kube-system
kubectl get sa aws-load-balancer-controller
kubectl describe sa aws-load-balancer-controller
부여하지 않았던 어노테이션이 부여되어 있는 것을 확인할 수 있다.
쿠버네티스 SA 계정과 AWS IAM 계정이 연결되어 있고, Role이 SA에 연동되어 있다는 의미이다.
각각의 AZ에는 프라이빗 서브넷과 퍼블릭 서브넷이 함께 있다. 해당 클러스터는 eks yaml파일에서 private 설정을 true로 만들어 놓았으므로 외부 접속이 불가능하다. 하지만 설정하지 않으면 기본적으로 pulbic으로 설정되어 있다. NodePort는 퍼블릭에 배치해 두었을 때 사용할 수 있다. 물론 30000-32767 포트를 보안 그룹에서 열어주어야 접속 가능하다.
kubectl create -f myapp-rs.yaml myapp-svc-lb.yaml
kubectl get svc
LoadBalancer 타입의 서비스를 만들면 쿠버네티스 클러스터가 CCM을 통해 AWS ELB에 로드밸런서를 만들어달라고 요청한다. ec2 인스턴스의 31628번 포트가 열려 로드밸런서에 연결된다. 이 프라이빗 서브넷에 위치한 EC2 인스턴스의 31628번 포트와 연결된 로드밸런서가 외부 네트워크와 연결해 로드밸런서를 타고 내부 네트워크로 들어온다. 워커 노드를 퍼블릭하게 노출시키면 안 되기 때문에 이 방법이 보안에 좋은 방법이다. 하지만 이 방법의 문제점은 로드밸런서가 클래식 타입이라는 점이다
주로 사용하는 것은 클래식이 아니라 어플리케이션 로드 밸런서(L7)와 네트워크 로드 밸런서(L4)이다. 결국 서비스의 로드밸런서는 네트워크 로드밸런서를 사용해야 한다. 이를 위해서는 애드온을 붙여야 한다. 인그레스도 만들어지지 않는다. 인그레스는 ELB에 만들어져야 하기 때문이다. 컨트롤러가 있어야 한다.
PVC도 볼륨을 만들지 못하기 때문에 애드온을 설치해주지 않으면 실행할 수 없다. 또한 메트릭 서버가 자동으로 설치되지 않기 때문에 hpa, top 커맨드가 불가능하다.
필요한 애드온은 다음과 같다.
온프레미스에서는 X.509 인증서로 인증했지만 AWS에서는 IAM으로 인증하도록 구성할 것이다. 쿠버네티스는 모두 같지만 클라우드와 연동시킬 때 달라지는 점은 없을 수 없다.