TIL - 쿠버네티스

쿠버네티스 시작 전 준비사항

• 서버들이 사설 네트워크로 연결 돼있어야 한다.
• 서버들이 nas를 통해 공유 저장공간을 가져야 한다.

개념

• kubeadm: 클러스터를 부트스트랩

• kublet: 클러스터의 모든 머신에서 실행되는 파드, 컨테이너 시작같은 작업을 수행하는 컴포넌트

• kubectl: 클러스터와 통신하기 위한 커맨드 라인 유틸리티

  보통 파드 하나에 컨테이너 하나가 들어간다. 한 파드에 여러 컨테이너가 들어갈 수도 있다. 클러스터는 컨테이너 노드의 덩어리들이다.

설치

클러스터 내부 요소들은 기본 6443포트를 통해 통신한다. 보안그룹에서 6443을 먼저 뚫어주자.

마스터 서버에서 클러스터 구성
kubeadm init --control-plane-endpoint "마스터_서버_공인IP_OR_공인HOST:6443" --upload-certs --pod-network-cidr=10.10.0.0/16 -v=5
10.10.0.0/16 클러스터 내부 개인 네트워크주소이다.

마스터 서버의 사용자를 쿠버네티스 관리자 계정으로 지정

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

마스터 서버에서는 다음 명령어를 통해 노드를 확인 할 수 있다.

• kubectl get nodes -A
• kubectl get nodes -A -o wide

워커노드 등록, 마스터 서버가 아닌 서버들에서 아래 명령어 실행

• kubeadm join 마스터_서버_IP:6443 --token 토큰1 \ --discovery-token-ca-cert-hash sha256:토큰2
  이 명령어는 마스터를 등록하면 자동으로 쿠버네티스가 보여준다. 그걸 복사해서 마스터가 아닌 서버에 붙여넣기 하면 됨.

칼리코(Container Network Interface) 설치

• kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.24.1/manifests/tigera-operator.yaml
• mkdir /kube
• cd /kube
• vi calico-resources.yaml

# This section includes base Calico installation configuration.
# For more information, see: https://projectcalico.docs.tigera.io/master/reference/installation/api#operator.tigera.io/v1.Installation
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    bgp: Disabled
    ipPools:
    - cidr: 10.10.0.0/16
      encapsulation: VXLAN

---

# This section configures the Calico API server.
# For more information, see: https://projectcalico.docs.tigera.io/master/reference/installation/api#operator.tigera.io/v1.APIServer
apiVersion: operator.tigera.io/v1
kind: APIServer 
metadata: 
  name: default 
spec: {}

• kubectl create -f calico-resources.yaml

쿠버네티스로 이미지 띄우기
쿠버네티스로 이미지를 띄우려면 이미지가 도커허브에 올라와있어야 한다.

• kubectl run webserver --image=nginx

kubectl get pods를 확인해보면 파드가 존재하는 거 확인 가능

kubectl exec -it webserver -- bash로 컨테이너 쉘로 진입가능하다

deployment

• kubectl create deployment webserver --image=이미지 --replicas=2

이 명령어를 통해 deployment 1개, replicaset 1개, pod2개가 생긴다.

재밌는 점은 pod를 하나 지워버리면 순식간에 pod가 복구된다. replicaset을 지워도 replicaset이 다시 부활한다.

즉 deployment를 통해 생성한 컨테이너를 없애려면 deployment를 죽여야한다.

롤링 업데이트 전략

번거롭게 왜 replicaset이 중간에 끼어있는 지 궁금해졌다.

애플리케이션이 새로운 버전이 나와서 클러스터의 파드들을 새 이미지로 교체해야한다.
kubectl set image deployment/webserver 컨테이너이름=새이미지

이 명령어를 실행하면

1. 새이미지를 desire하는 replicaset이 새로 생성된다.
2. 구이미지의 replicaset은 desire가 0이 된다.

replicaset이 새로 생겨서 기존 파드들의 이미지도 바뀌게 된다. 여러 파드들이 한번에 다 종료되고 새로 바뀌는 게 아니라, 마치 그라데이션처럼 새 이미지가 퍼져나간다.
종료상태가 되는 파드가 없기 때문에 무중단 배포를 할 수 있는 것이다.

일관성있는 세션

파드들의 내부 IP는 파드에 변화가 생기면 바뀐다. replicaset도 이미지가 바뀌면 IP가 바뀔 수도 있다.

우리의 애플리케이션에 접속하는 클라이언트가 접속을 하면 쿠버네티스가 여러 노드들 중에 임의로 요청을 넘길 것이다.

근데 클라이언트가 로그인을 하면 세션은 특정 노드만 가지게 된다. 다음 요청을 쿠버네티스가 세션키를 갖고 있는 '그 노드'로 토스해줄 것이라는 보장이 없다.

이를 해결하는 방법은 2가지이다.

• 세션을 외부로 뺀다. (db, redis,...)
• sessionAffinity를 ClientIP로 수정

요청을 특정 노드와 묶어버리기

• kubectl edit service webserver
• sessionAffinity: ClientIP로 수정

서비스에 여러번 접속하면 특정 노드로만 접속이 되는 것을 알 수 있다.