🔥 TIL - Day 57

📌 도커의 한계 (왜 쿠버네티스를 쓰는가?)

여러 개의 서버 인스턴스에 컨테이너를 배포하고 운영,관리하기 위함이다.

확장의 문제

• 도커만으로는 스케일 아웃이 힘들다.
• 만약 도커만으로 스케일 아웃을 하려면 도커가 구동되는 인스턴스를 늘려주고 해당 인스턴스에 도커애 대한 설정을 해줘야 한다.

관리의 문제

• 스케일아웃을 위해 여러 인스턴스에 도커를 설치한다면 이를 통합해서 관리하는데 어려움이 생긴다.
• 다른 인스턴스의 도커 컨테이너 간 통신에 어려움이 있다.

📌 Kubernetes 아키텍처

• Master-node (slave) 구조
  • Master: 노드에 배포된 컨테이너를 관리
  • Node: 컨테이너가 배포되는 환경 (애플리케이션이 구동되는 환경)
  • Pod: 배포단위 중 가장 작은 단위 (컨테이너와 거의 같은 느낌?)
• API Server <-> Kubelet
• etcd: key-value 저장소
• scheduler: 애플리케이션을 어디에 배치할지 결정

📌 Master 생성

CPU 2개 이상, 메모리 1700MB이상 (t3.small)

도커 설치

1. apt 업데이트

sudo apt-get update

2. 라이브러리 설치

sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-release

3. 샤이닝키 다운로드

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

4. 레포지토리 추가

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" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

5. apt 업데이트

sudo apt-get update

6. 도커설치

sudo apt-get install -y docker-ce docker-ce-cli containerd.io

7. 실행권한 조정

sudo usermod -aG docker $USER

마스터 설치

1. EC2 인바운드 편집

TCP 6443 ➡️ 쿠버네티스 API 서버
TCP 2379-2480 ➡️ etcd 서버 클라이언트 API
TCP 10250 ➡️ kubelet API
TCP 10251 ➡️ kube scheduler
TCP 10252 ➡️ Kube-controller-manager
UDP 8472 ➡️ CNI 관련
UDP 8285 ➡️ CNI 관련

2. 구글 클라우드 공개 사이닝 키 다운로드

sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

3. 쿠버네티스 apt 레포지토리 추가

echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

4. apt 업데이트

sudo apt-get update

5. kubelet, kubeadm, kubectl 설치

sudo apt-get install -y kubelet kubeadm kubectl

6. 버전고정

sudo apt-mark hold kubelet kubeadm kubectl

7. 도커 데몬의 드라이버 교체

cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

8. 도커 데몬 재실행

sudo systemctl enable docker

sudo systemctl daemon-reload

sudo systemctl restart docker

# kubelet가 실행인지 확인
sudo systemctl status kubelet
# 실행중이 아닐 경우
sudo systemctl start kubelet

9. 클러스터 초기화

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

10. 클러스터 리셋 (에러발생시 초기화 🤮)

sudo kubeadm reset
rm -rf $HOME/.kube/config

11. 조인명령어를 복사해둔다. (노드를 연결하기 위해)

kubeadm join 172.31.14.147:6443 --token wza8ug.yfe906i22cih2dlb \
	--discovery-token-ca-cert-hash sha256:13244b42705b1bbc4fcb445cf39f2792bd05abfe31aacb520da5337aa8b9679a

12. kubectl 사용설정

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

13. kubectl 동작확인

kubectl get namespace

14. 마스터 재한 제거

kubectl taint nodes --all node-role.kubernetes.io/master-

📌 CNI

• 네트워크 플러그인
• 마스터와 노드들 간 네트워킹에 대한 설정

📌 coredns

• 같은 노드 혹은 다른 노드의 Pod 간 통신을 위해 도메인을 제공
• coredns의 상태가 Pedning 인 경우 CNI를 설치한다?

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

📌 쿠버네티스 노드 생성

1. EC2 생성 t3.small

2. 인바운드 설정

TCP 10250 ➡️ kubelet API
TCP 30000-32767 ➡️ NodePort
UDP 8472 ➡️ CNI관련
UDP 8285 ➡️ CNI관련

3. 노드에도 마스터와 동일하게 도커 설치

4. 쿠버네티스 설치 (클러스터 초기화 전까지만 설정)

5. 마스터 생성시 복사한 join 명령어를 실행 (sudo로 실행)

sudo kubeadm join 172.31.14.147:6443 --token wza8ug.yfe906i22cih2dlb \
	--discovery-token-ca-cert-hash sha256:13244b42705b1bbc4fcb445cf39f2792bd05abfe31aacb520da5337aa8b9679a

6. 마스터에서 노드가 잘 연결되었는 지 확인

kubectl get nodes

📌 Pod

• 1개 이상의 컨테이너로 구성된 배포할 수 있는 최소 단위이다.
  • 동일한 Pod에 속한 컨테이너 간에는 서로 스토리지와 네트워크를 공유한다.
• Pod는 고유한 IP를 가진다. (Pod마다 IP가 부여)
• 한 개 노드에 여러 개 Pod를 배치할 수 있다.
• 한 개 Pod에는서 한 개 이상의 컨테이너를 구동시킬 수 있다.

파드생성

1. 파드 생성을 위한 설정파일 생성

vi my-flask-pod.yaml

2. Pod 생성을 위한 yml 파일작성

apiVersion: v1
kind: Pod
metadata:
  labels: 
    app: 파드이름
spec:
  containers: # 여러 개 컨테이너 설정가능
  - name: 컨테이너 이름
    image: 도커허브에서 가져올 이미지
    ports:
    - containerPort: 5000

3. Pod 생성 (컨테이너 구동)

kubectl apply -f 파드설정파일_이름

[ 생성된 Pod 확인 -f: 파일명 ]
kubectl get -f 파드설정파일_이름

[ Pod 상세정보 ]
kubectl describe -f 파드설정파일_이름

[ Pod 로그확인 ]
kubectl logs -f 파드설정파일_이름

[ Pod 삭제 ]
kubectl delete -f 파드설정파일_이름

4. 외부에서 Pod에 접근할 수 있도록 설정 ➡️ Service

📌 Service

• 앞 단에서 외부요청을 받아 Pod와 연결해준다
• Pod의 DNS역할

1. 서비스 생성을 위한 yml 파일작성

vi my-flask-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: 서비스_이름
spec:
  selector: # 연결할 pod의 이름 (labels)
    app: 파드_이름
  ports:
    - protocol: TCP
      port: 5000
      targetPort: 5000
  type: NodePort

2. 서비스 생성 (외부 접근포트(NodePort) 확인)

kubectl apply -f my-flask-svc.yaml

kubectl get -f my-flask-svc.yaml

• 30000-32767 사이의 포트가 랜덤하게 할당된다. (NodePort)
  • 노드쪽 인바운드를 30000-32767으로 열어둔 이유
  • NodePort: 외부에서 접근가능한 포트
• 외부에서 node 인스턴스의 ip와 할당된 포트로 접근가능하다.
• 일단 배포는 됐다.

but 아직 문제가 있다.

• 어떤 문제로 인해서 Service가 다시 생성되면 NodePort가 변경된다.
  • 이 API를 사용하는 모든 곳의 코드를 변경해야 할 수도 있다.
• 포트를 고정시켜보자.

📌 Ingress

• like nginx
• 외부에서 서비스에 대한 접근을 관리한다.
• 포트가 아닌 서비스의 이름으로 서비스를 식별할 수 있다. (포트가 변경되도 엔드포인트는 같다.)

0. 인그레스 컨트롤러 설치 (ingress-nginx)

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.4/deploy/static/provider/baremetal/deploy.yaml

[ 인그레스 설치 확인 ]
kubectl get namespaces

[ 최신버전 오류삭제 ]
kubectl delete validatingwebhookconfiguration ingress-nginx-admission

1. 인그레스 설정파일 작성

vi micro-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: micro-ingres
  annotations: # nginx 형태로 ingress를 생성?
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: my-flask.bar.com # 외부에서 접근할 도메인
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: my-flask-svc # 서비스의 이름으로 식별
            port:
              number: 5000

2. 설정파일 적용 (포트확인)

kubectl apply -f micro-ingress.yaml

# ingress-controller 포트 확인
kubectl get all -n ingress-nginx 

# ingress-controller 도메인 확인
kubectl describe -f micro-ingress.yaml

3. ingress의 도메인과 포트로 접근한다.

4. 로컬의 호스트파일 변경 (로컬에서 접근 테스트)

sudo vi /etc/hosts

node인스턴스ip 인그레스_도메인

📌 ELB, 쿠버네티스 연동

ELB 생성

0. 로드밸랜서 생성

1. 인바운드: 모든 TCP

2. 네트워크 설정 (기본 서브넷 4개 모두 설정)

3. 타겟그룹 생성

• instance
• group name: kuber-target
• HTTP : IngressPort (HTTP:30969)
  ELB로 외부에서 80 포트로 요청이 왔을 때 이 요청을 EC2로 넘길 때 Ingress 포트를 호출하도록 설정
• Health check path: /healthz

4. 노드 인스턴스를 타겟그룹에 추가

5. 생성한 타겟그룹을 ELB에 설정

6. 타겟그룹, ELB 상태확인

7. ELB가 활성홛 됐다면 엔드포인트로 접근. (404 에러발생)

• Ingress 설정시 도메인을 설정해주었는데 현재 ELB의 엔드포인트로 접근했기 때문
• Ingress의 도메인을 ELB의 엔드포인트로 변경하든 Route53 도메인을 사용하든 바꿔줘야 한다.

8. Ingress 설정파일 수정 (도메인 수정)

vi micro-ingress.yaml

9. Route53의 CNAME레코드 url을 host에 그대로 넣어준다.

일단 쿠버네티스가 어떤건지 한 2.5%정도 알 것 같다.
이번 기회에 네트워크 CS 공부를 조금씩 해봐야겠다.