쿠버네티스 전문가 양성과정 12주차 5일(3/10)

최수환·2023년 3월 10일
0

Kubernetes

목록 보기
55/75
post-thumbnail

CKA

Kubeadm

  • 쿠버네티스 클러스터를 생성하고 관리하기 위한 쿠버네티스의 기본적인 설치 도구
  • 일반적으로는 Kubespray를 사용하지만 CKA만큼은 Kubeadm을 설치할 줄 알고, 사용할 줄 알아야 한다.

Kubeadm 설치

Kubeadm 설치 github참조

  • 버전차이 정책 참조
  • CNI로 Flannel(3rd party plugin)을 사용하기도 하지만 Network Policy를 지원하지 않기 때문에 Calico(Pod Network Addon)를 사용한다.

Upgrade

  • kubeadm으로 생성된 쿠버네티스 클러스터의 버전을 바꾸는 방법이다.
  • CKA의 단골 문제이다
  • ex) 1.26.0 -> 1.26.1

📒 Upgrade 개념 참조

< 컨트롤 플레인 업그레이드 >

sudo apt-mark unhold kubeadm
sudo apt install kubeadm=1.26.2-00 -y
sudo apt-mark hold kubeadm 
sudo kubeadm upgrade apply v1.26.2	
  • 업그레이드 하기 위해서는 우선적으로 kubeadm을 업그레이드 해야 한다.
  • 1.26.2버전으로 업그레이드
  • apt-mark hold 하는 이유는 자동으로 업데이트되어 다른 서비스와 버전차이가 나서 꼬이는 것을 방지하기 위해서 묶는 것이다
    -> 업그레이드 할때는 잠시동안 unhold해주면 된다
sudo apt-mark unhold kubelet kubectl
sudo apt install -y kubelet=1.26.2-00 kubectl=1.26.2-00
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload
sudo systemctl restart kubelet
  • 마찬가지로 kubelet과 kubectl도 업그레이드 해주어야 한다
  • 설치 이후에는 kubelet은 데몬이기 때문에 재시작 해주어야 한다
vagrant ssh kube-node1

sudo apt-mark unhold kubeadm
sudo apt install kubeadm=1.26.2-00 -y 
sudo apt-mark hold kubeadm 
sudo kubeadm upgrade node
  • node에 접속 후 마찬가지로 kubeadm을 업그레이드 해준다
sudo apt-mark unhold kubelet kubectl
sudo apt install kubelet=1.26.2-00 kubectl=1.26.2--0 -y
sudo apt-mark hold kubelet kubectl 
sudo systemctl daemon-reload
sudo systemctl restart kubelet
  • node의 kubelet과 kubectl도 업그레이드


-> 최종적으로 컨트롤 플레인과 node의 버전이 1.26.0에서 1.26.2로 업그레이드 된것을 알 수 있다.

etcd

  • 데이터베이스의 주기적인 백업을 위한 서비스

📕 etcd 참조
📕 etcd 설치 참조

sudo apt install etcd-client # etcdctl 명령어 설치
sudo -i # etcdctl 명령어는 오로지 관리자 권한으로만 실행 가능
# root계정으로 접속

cd /etc/kubernetes/pki/
# root게정의 key를 저장하는 디렉터리에 접속 후 키 확인  

ETCDCTL_API=3 etcdctl --endpoints 192.168.56.11:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key
# etcdctl명령어를 사용하려면 위의 명령어를 다 입력해야함 

alias etcdctl=' ETCDCTL_API=3 etcdctl --endpoints 192.168.56.11:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key'
# 위의 명령어를 항상 사용할 수 없으니 alias로 만든다.
  • root사용자에서 나왔다가 다시 들어가면 alias가 지워지므로 다시 설정해줘야 한다.

ETCD 클러스터 맴버 목록

etcdctl member list

백업

etcdctl snapshot save snapshotdb

복구

etcdctl snapshot restore snapshotdb
# 복구하기 위해서는 모든 api-server가 중단되어 있어야 한다

Network Policy

  • 잘 사용은 안하지만 CKA에서는 중요하게 다루는 내용이다
  • 네트워크 3계층, 4계층의 방화벽을 구현하기 위해서는 CNI가 지원되어야 한다.
    -> CNI가 지원되어야 Network Policy를 사용할 수 있다
    -> Flannel은 지원되지 않는다
    -> Calico , weave , AWS VPC 등은 CNI가 지원되기 때문에 Network Policy를 구현할 수 있다
  • 기본적으로 네트워크 정책은 'White List'이다.
    = 들어오는 모든 네트워크 트래픽에 대해 거부

📒 네트워크 정책 개념 참조

ex) . 네트워크 정책 리소스 생성 예시

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector: # 파드 선택, selector와 동일하게 작동 
    matchLabels:
      role: db
  policyTypes:
    - Ingress
    - Egress
  ingress: # = InBound , 네트워크의 Ingress리소스와는 아무 관련 x 
    - from: # 나한테 들어오는 것이므로, 어디에서 왔는지 정의
        - ipBlock:
            cidr: 172.17.0.0/16 # 해당 ip대역대에서 오는 것은 허용
            except:
              - 172.17.1.0/24 # 예외 ip대역대 설정 
        - namespaceSelector: # 네임스페이스 레이블이 일치
            matchLabels:
              project: myproject 
        - podSelector: # 파드의 레이블이 일치하는 
            matchLabels:
              role: frontend
      ports: # 6379포트로 들어오는 트래픽 허용 
        - protocol: TCP
          port: 6379
  egress: # = OutBound 
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 5978
  • 보통 일반적으로 egress (OutBound)는 사용하지 않는다
  • 보통 들어오는 트래픽을 Ingress로 통제하고 들어온 것에 대해서는 나가는 것을 모두 허용한다
  • Ingress로 들어오는 ports에 대해 설정할 수 있고 이 해당 port를 통해 들어오는 트래픽에 대해 ip대역, 네임스페이스 레이블, 파드의 레이블을 조건으로 두어 하나라도 만족하지 않는 트래픽은 통제한다.
    -> 세가지 조건을 모두 사용해도 되고, 일부 조건만 사용해도 된다.

1 . 기본적으로 모든 인그레스 트래픽 거부

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

2 . 모든 인그레스 트래픽 허용

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
spec:
  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress
  

3 . 사용 예시

kubectl create deploy myweb --image nginx
kubectl expose deploy myweb --name myweb-svc --port 80 --target-port 80
# 파드와 서비스 생성

kubectl get po --show-labels
# 생성된 파드는 자동으로 app: myweb 레이블을 가진다

vi netpol.yaml 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-wc1
spec:
  podSelector:
    matchLabels:
      app: myweb # 위에서 생성한 파드 선택 
  policyTypes:
    - Ingress # 인바운드 규칙 선택 
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: wc1 # 해당 레이블을 가진 트래픽에 대해 허용 
      ports: # 어떤 포트로 들어오는 트래픽에 대해서 허용 할 것인지
        - protocol: TCP
          port: 80
  • podselector로 어떤 파드들에 네트워크 정책 리소스를 붙일지 선택한다.
  • ingress 항목에서 podselector로 어떤 레이블을 가진 파드의 트래픽에 대해 허용할 것인지 선택
  • ingress 항목의 ports에서 80/TCP로 들어오는 트래픽에 대해서 허용
kubectl run wc1 --image ghcr.io/c1t1d0s7/network-multitool -l app=wc1 --rm -it -- sh
curl myweb-svc


-> 간단하게 app:wc1 레이블을 부착한 wc1이라는 client를 생성하고 파드에 연결된 서비스에 curl을 해보면 네트워크 정책에 의해 허용되어 정상적으로 웹이 뜨는 것을 볼 수 있다.

kubectl run wc2 --image ghcr.io/c1t1d0s7/network-multitool -l app=wc2 --rm -it -- sh
curl myweb-svc


-> 마찬가지로 app:wc2 레이블을 부착한 wc2라는 client를 생성하고 파드에 연결된 서비스에 curl을 해보면 네트워크 정책에 의해 거부되어 아무런 반응이 없는 것을 확인

profile
성실하게 열심히!

0개의 댓글