🌠AWS EC2 쿠버네티스 클러스터 구축

kube-apiserver 지속 재시작 종료.

Restart 스탯을 보면 몇번이나 재 시작한것을 볼 수가 있다..
도대체 뭐가 문제인지도 모르겠고.. 클러스터를 구성하는 마스터 노드의 메모리가 부족한건가 싶기도했음..

t2.medium

ec2인스턴스를 t3.small로 처음에 지정했다가 t2.meduim으로 변경해서 인스턴스를 생성하였다.

---

클러스터 구축

내가 공부하면서 GKE환경에서 구축했던 클러스터 환경과
https://velog.io/@99_insung/GKE-VM

🍀해외 사이트서 발견한 EC2 인스턴스로 클러스터 환경을 구축한 블로그를 둘다 이용하였음.
https://nvtienanh.info/blog/cai-dat-kubernetes-cluster-tren-ubuntu-server-22-04
국내 블로그(포트 개방확인, 여기서는 systemd를 사용함)

https://velog.io/@koo8624/Kubernetes-AWS-EC2-%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4%EC%97%90-Kubernetes-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

EC2 HA 를 활용
https://blog.zooneon.dev/kubeadm-cloud-provider-aws/

1. 업데이트

sudo apt update
sudo apt upgrade -y

2. hostname

많은 ec2 클러스터 환경 구축에서 호스트 이름을 설정하던데 나는 하지 않았다.
sudo hostnamectl set-hostname <호스트이름>

3. swapoff

# 현재 시스템에 적용(리부팅하면 재 설정 필요)
sudo swapoff -a
# 리부팅 필수
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

free -h 를 통해서 확인

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       167Mi       7.1Gi       1.0Mi       437Mi   7.3Gi
Swap:             0B          0B          0B

4. 커널 모듈 로드

sudo tee /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF

• overlay : Overlay 파일 시스템 모듈 로드.
  • 컨테이너 런타임 (Docker, containerd) 에서 사용 되는 레이어드 파일 시스템 중 하나
  • 컨테이너 이미지와 파일 시스템 관리에 사용
• br_netfilter: 브리지 넷필터 모듈 로드
  • Linux 브리지 네트워크와 네트워크 패킷 필터링 지원
  • 컨테이너 네트워크 설정에 사용

sudo modprobe overlay
sudo modprobe br_netfilter

Kubernetes 커널 매개변수 설정

sudo tee /etc/sysctl.d/kubernetes.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

5. 컨테이너 런타임 설치

sudo apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt install -y containerd.io

6. 컨테이너 런타임 구성 추가

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1
sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd

7. 쿠버네티스 설치

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"
sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

8. kubeadm init

sudo kubeadm init \
  --pod-network-cidr=10.10.0.0/16 \
  --control-plane-endpoint=호스트네임 # 해당 부분은 제외함

여기서 마스터 노드 설정이 제대로 되지 않았고, 트러블 슈팅하느라 오래 걸림 (포트 개방이 필수)
포스팅 : https://velog.io/@99_insung/EC2-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-%EA%B5%AC%EC%B6%95

9. 설치 완료후 .kube 설정 (마스터 노드만)

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

설정 후 확인

kubectl cluster-info
kubectl get nodes

kube-apiserver 강제 종료 현상 및 반복 재실행

포스팅 : https://velog.io/@99_insung/EC2-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-%ED%8C%8C%EB%93%9C-%EA%B0%95%EC%A0%9C%EC%A2%85%EB%A3%8C%ED%98%84%EC%83%81

10. 설치 완료 후 클러스터 join(워커 노드만)

11. 마스터 노드에서 확인

kubectl get nodes

처음에 모두 NotReady 상태로 노드리스트 상태가 존재한다.

12. 네트워크 플러그인 추가 (Calico)

curl https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml -O

설치 후 yaml파일 안에 ipv4 CIDR 설정을 kubeadm init에 서 설정했던 cidr 값과 맞춤

---
# The default IPv4 pool to create on startup if none exists. Pod IPs will be
# chosen from this range. Changing this value after installation will have
# no effect. This should fall within `--cluster-cidr`.
- name: CALICO_IPV4POOL_CIDR
  value: '10.10.0.0/16'
# Disable file logging so `kubectl logs` works.
- name: CALICO_DISABLE_FILE_LOGGING
  value: 'true'

kubectl apply -f calico.yaml : 적용하여 네트워크 플러그인 실행

실행 완료 후 kubectl get nodes를 다시 해보면 각 노드들이 정상 동작하였다.

NAME               STATUS   ROLES           AGE   VERSION
worker-2   Ready    <none>          8h    v1.28.2
worker-1    Ready    <none>          8h    v1.28.2
master-1    Ready    control-plane   8h    v1.28.2

13. kube-system 확인

calico-node가 계속 0/1 READY 상태라서 트러블 슈팅하는데 많이 애 먹었었다.
포스팅 : https://velog.io/@99_insung/Calico-BGP-%ED%8A%B8%EB%9F%AC%EB%B8%94-%EC%8A%88%ED%8C%85

---

ingress-nginx-controller

git clone https://github.com/kubernetes/ingress-nginx/

kubectl apply -k `pwd`/ingress-nginx/deploy/static/provider/baremetal/

kubectl get pod -n ingress-nginx : 설치 확인
kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io ingress-nginx-admission : 현재 오류되는 기능 제거

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: jpapractice-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: "/"
spec:
  rules:
    - host: insung-jpadocker.store  # 실제 도메인 설정
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: jpapractice-service
                port:
                  number: 80

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jpapractice-deployment
spec:
  replicas: 3  
  selector:
    matchLabels:
      app: jpapractice
  template:
    metadata:
      labels:
        app: jpapractice
    spec:
      containers:
        - name: jpapractice
          image: adultkim/jpapractice:latest  
          env:  
            - name: active
              value: "prod"
          ports:
            - containerPort: 8081

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: jpapractice-service
spec:
  selector:
    app: jpapractice
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8081  # Port your Spring Boot application is running on
  type: LoadBalancer # 로드밸런서를 아직 할당안해서 실행 후에 NodePort로 변경함

이렇게 간단하게 웹 애플리케이션을 배포하였고,

$ kubectl get all -o wide
NAME                                          READY   STATUS    RESTARTS   AGE     IP             NODE               NOMINATED NODE   READINESS GATES
pod/jpapractice-deployment-5b4596d8d9-27nv5   1/1     Running   0          7h33m   10.10.32.132   ip-172-31-31-33    <none>           <none>
pod/jpapractice-deployment-5b4596d8d9-cdwhr   1/1     Running   0          7h33m   10.10.32.133   ip-172-31-31-33    <none>           <none>
pod/jpapractice-deployment-5b4596d8d9-lb9mx   1/1     Running   0          7h33m   10.10.120.68   ip-172-31-16-104   <none>           <none>

NAME                          TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE     SELECTOR
service/jpapractice-service   NodePort    10.99.56.67   <none>        80:30353/TCP   7h33m   app=jpapractice
service/kubernetes            ClusterIP   10.96.0.1     <none>        443/TCP        9h      <none>

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS    IMAGES                        SELECTOR
deployment.apps/jpapractice-deployment   3/3     3            3           7h33m   jpapractice   adultkim/jpapractice:latest   app=jpapractice

NAME                                                DESIRED   CURRENT   READY   AGE     CONTAINERS    IMAGES                        SELECTOR
replicaset.apps/jpapractice-deployment-5b4596d8d9   3         3         3       7h33m   jpapractice   adultkim/jpapractice:latest   app=jpapractice,pod-template-hash=5b4596d8d9

서비스를 LoadBalancer를 사용하면 배포한 service의 외부 IP가 계속 Pending 상태였다.
NodePort로 변경 후에 내부 환경에서 접속이 되는지 확인함.
-> 클러스터 내부에서 요청을 노출하여 확인