[쿠버네티스] Devops 직무 (k8s) 면접시 체크리스트

😍 Devops 직무에 대한 면접을 여러번 진행하면서 반복되는 질문 및 꼭 알아야 할 것 같은 질문들을 정리해봤습니다.

😍 아래 회사 이외에도 작지만 탄탄한 기술을 갖춘 회사들도 포함되어 있습니다.

😍  계속적으로 질문 받은 내용들을 업데이트 하겠습니다.

 

•  당근마켓
•  토스뱅크
•  하이퍼커넥트
•  쏘카
• 브랜디
• spoon라디오

 

😍 쿠버네티스 관련 질문

 

쿠버네티스 네트워크

• 질문 1. 같은 노드에서 POD끼리의 통신
• 질문 2. 다른 노드에서 POD끼리의 통신 
• 질문 3. 외부로 POD 통신
• 질문 4. CNI의 존재이유
• 질문 5. SERVICE 통신? iptables과 kube-proxy 
• 질문 6.  coreDNS ?  외부에서 접근할 경우 어떤 방식으로 작동하는가? 

쿠버네티스 Addon (istio,ELK 등)

 

• 질문 7. istio vs API Gateway와 비교해서 설명 요청 (장/단점)
• 질문 8. ELK 로깅 방안  disk full차면 어떻게 하는지? 
• 질문 9. Etcd 에 대한 이해 
• 질문 10. api-server, kubelet , scheduler , controller 

트러블 슈팅 경험 

• 개인의 경험에 맞추어 다음과 같이 기술하시오.

# etcd 디스크 full이 클러스터 전체 장애로 확산되다.

S사 유지보수 시 가장 인상깊은 경험은 쿠버네티스 클러스터가 전체 서비스 장애로 확산된 경험입니다.
이때 상황은 인프라 모니터링 중 kube-api서버 1개가 2주 전부터 메모리 사용률이 굉장히 높아지고 있었고 
장애 발생 시점 3시간 전, kubectl 명령어가 동작하지 않고 kube-api-server가 죽어버렸습니다.
그런 상황에서 해당 VM을 재부팅 하고 docker / kubelet을 재기동 하였습니다.

# 상황 해결을 위한 로그 확인

도착해서 바로 확인 곳은 kube-api server의 노드에 저장되어 있는 로그들이였습니다. 그 이유는 
kubectl 명령어가 듣지 않았기 때문입니다.
그리고 더불어서  etcd, kubelet 등의 구성 요소가 정상적으로 동작하고 있는지 확인 했습니다.

# 로그 확인 중 실마리 발견

kube-api server의 로그와 syslog에 etcd disk full 이라는 로그가 지속적으로 기록되어 있는것을 확인
하였고 etcd 상태를 확인 했지만 정상적으로 동작 하고 있었습니다.
etcdctl을 설치하여 member list와 endpoint status를 확인 하였더니 디스크가 Full 차있는것을 확인

# revision 삭제 -> defragment 진행

etcd는 db에 데이터를 저장할때 key value값뿐만 아니라 변경사항의 이력사항(history)까지 
revision과 함께 저장을 해놓기 때문에 revision에 대해 관리가 없이 운영 시 호스트 OS의 디스크 공간 부족으로 
etcd 프로세스가 언젠가 중단될 가능성이 있다.
불필요한 revision의 과도한 리소스 사용을 피하고자 etcd는 compaction 기능을 제공합니다.
compaction을 통해 Revision을 삭제로 인해 발생한 fragment를 정리 해주어야 디스크 공간이 확보되기 때문에
크론잡(CronJob)을 개발하여 defragmentation을 주기적으로 수행해 주거나, etcd_quota_backend_bytes 옵션을 넉넉하게 부여하여
(max 8G) etcd 클러스터의 가용성에 문제가 생기는 일이 없도록 했습니다.

 

✅  POD 통신의 원리

 

# Pod Network 
# 같은 노드에서 통신
먼저 다음과 같은 질문에 대해서 생각해보자
파드의 인터페이스는 어디로 연결되어 있는가?
노드의 calixxx는 IP가 없는데 어떻게 통신할까?
브릿지는 무엇일까?
ARP publishing이란 무엇일까?

# 다른노드의 POD와의 통신

오버레이 네트워크란 무엇일까?
파드에서 다른 노드에 위치한 파드까지 패킷이 전달되는데 어떤 통신과정을 거칠까?
다른 노드에 내가 원하는 IP의 파드가 있는지 어떻게 확인할까?
노드의 라우팅 테이블은 누가 고칠까?

# POD에서 외부로 통신 해야할때 (8.8.8.8이나 google.com)

SNAT란 무엇인가?
파드는 외부와 통신해야할때 svc를 거쳐야만 할까?
파드가 외부와 통신할때 터널링 인터페이스를 거칠까?
iptables는 무슨 역할을 하지?

 

 

✔️  같은 노드안에서 파드끼리 통신 -  호스트의 cali 인터페이스만을 가지고 통신한다.

• 노드의 인터페이스 까지 패킷이 전송되지 않음
• 호스트의 calixxx 인터페이스는 브릿지 네트워크 인터페이스로 ip주소를 가지지 않고 mac주소만 가지고 있음
• 인터페이스의 ip 없이 통신하는 방법은 arp-proxy 기술에 대한 이해가 필요함
• ARP Proxy 기능은 라우터가 자신이 알고있는 대역에 대한 ARP 응답을 라우터 자신의 MAC주소를 퍼블리싱 해서 목적지에 패킷을 보내는 기술을 말함

 

상대방의 Mac 주소는 ARP Proxy를 통해서 알게된다.

 

 

✔️  다른  노드에 있는 파드와 통신  - 오버레이 네트워크 방식으로 통신한다.

• 오버레이 네트워크 방식은 가상화된 터널을 통해 데이터를 전송함, 노드에는 터널링 인터페이스가 생성됨으로 해당 인터페이스의 트래픽을 dump 떠보면 다음과 같음
• 신규 헤더가 추가되면서 원본 헤더의 캡슐화가 수행되며 헤더 추가에 따른 오버헤드 발생이 필연적 
• 성능적 문제가 서비스의 규모에 따라 있을수 있지만 가상 네트워크를 통한 확장성과 IP관리에 용이함 
• AWS VPC CNI 는 해당 문제를 해결하기 위해 오버레이 네트워크 방식이 아닌 호스트와 동일한 네트워크를 POD가 사용함 ( 따라서 IP에 대한 제약이 노드 인스턴스의 종류에 따라 존재함, 이를 커버하기 위해 IPv4 prefix 위임 등을 사용)

✅   pod에서 외부로 나갈때는? 

✔️  파드에서 외부로 통신  -  iptables룰에 따라 SNAT까지 쳐서 노드의 IP로 둔갑하여 나간다.

 

 

 

 

✅   SERVICE 란 무엇인가?

# kube-proxy
서비스 (nodeport)로 생성시 노드의 포트로 lsof -i:((포트))

root@worker01:~# lsof -i:31452
COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kube-prox 20366 root   11u  IPv4 386694      0t0  TCP *:31452 (LISTEN)

이와 같이 kube-proxy가 프로세스를 만들어 포트를 열고 대기하고 있는것을 확인 할수 있다.

root@worker01:~# iptables -t nat -L
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
cali-OUTPUT  all  --  anywhere             anywhere             /* cali:tVnHkvAo15HuiPy0 */
KUBE-SERVICES  all  --  anywhere             anywhere             /* kubernetes service portals */

iptables 명령어로 inbound 되는 트래픽을 확인해 보면 다음과 같이 KUBE-SERVICES라는 체인을 생성하고 있는것을
확인할수 있다.

curl을 통해 노드포트로 트래픽을 부여했을 경우
root@worker01:~# iptables -t nat -L KUBE-SERVICES -nv  | column -t
Chain  KUBE-SERVICES  (2              references)
pkts   bytes          target          prot         opt  in  out  source           destination
0      0              KUBE-MARK-MASQ  all          --   *   *    !10.233.64.0/18  0.0.0.0/0    /*         Kubernetes       service   cluster  ip  +  port  for  masquerade  purpose  */  match-set  KUBE-CLUSTER-IP  dst,dst
14     840            KUBE-NODE-PORT  all          --   *   *    0.0.0.0/0        0.0.0.0/0    ADDRTYPE   match            dst-type  LOCAL
0      0              ACCEPT          all          --   *   *    0.0.0.0/0        0.0.0.0/0    match-set  KUBE-CLUSTER-IP  dst,dst

이와 같이 KUBE-SERVICES의 패킷의 흐름을 확인할수 있는데, 이후 다시 SNAT를 해서 KUBE-NODE-PORT의 타겟으로
패킷을 보낸다.
웹 파드에서 접속자의 IP 정보 확인(logs) 시 외부 클라이언트IP 가 아닌, 노드의 IP로 SNAT 되는것을 확인할수 있음.
KUBE-MARK-MASQ는 iptables의 MASQUERADE 옵션에 해당되는데,
왜 SNAT냐면 출발지가 Worker Node(Host)의 IP로 변환되기 때문이다.


root@worker01:~# iptables -t nat -L KUBE-NODE-PORT -nv
Chain KUBE-NODE-PORT (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    1    60 KUBE-MARK-MASQ  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Kubernetes nodeport TCP port for masquerade purpose */ match-set KUBE-NODE-PORT-TCP dst

마지막으로 SNAT된 KUBE-NODE-PORT의 패킷은 이와같이 DNAT 되어 서비스에 label되있는 pod들로 라우팅 된다.

root@worker01:~# ipvsadm -Ln
TCP  10.0.0.99:31452 rr
  -> 10.233.84.4:80               Masq    1      0          0         
  -> 10.233.91.6:80               Masq    1      0          0         
  -> 10.233.108.4:80              Masq    1      1          0

 

서비스 생성된 후에 POD와 연결이 되면 - KUBE-SERVICES 체인에 Cluster IP로 생성됨 

# conntrack -L --dst-nat 파드아이피

 

트래픽 확인 가능

 

 

 

 

 

 

✅  CNI ?

커널 스페이스의 cali123 가상 인터페이스는 커널에 도착하게 되면 라우팅 테이블을 조회하여 다음 트래픽의 목적지를 정할수 있습니다.

cali123 은 어떻게 아무런 인터페이스와도 연결이 되어있지 않는데 통신을 할수 있는것이지? 정답은 ARP-proxy 이는 arp publishing 기술이라고도 부르는데 “ Proxy ARP란 , 해당 네트워크에 존재하지 않는 proxy device가 ARP 요청을 대리하여 응답하는 기술을 말합니다.

 

# CNI를 사용하는 이유
  - veth pair을 생성해주고 각 pair을 연결해줍니다. 
  - pod의 네트워크 설정을 직접 해줍니다 (IP Setting 등 )
  - 파드의 내부에 라우팅 테이블을 설정합니다.
  - 호스트에 라우팅 테이블을 설정합니다.
  - 각 노드들에 정보들을 Advertising 해줍니다.
  
# Calico 
Calico는 IPIP 모드와 VXLAN 모드가 존재하며.
각 노드에 파드 네트워크 대역은 Bird에 의해서 BGP로 광고 전파/전달 되며, 
Felix에 의해서 호스트의 라우팅 테이블에 자동으로 추가/삭제 된다.
하지만 VXLAN 모드는 Bird 컴포넌트가 존재하지 않는데,  
해당 모드에선 etcd에서 네트워크 정보가 변경이 발생할때마다 FELIX를 통해 가져와 
라우팅 테이블을 업데이트 합니다. 잦은 라우팅 테이블 업데이트가 없기때문에 시스템 부하를 줄일 수 있습니다.

# CNI란 무엇일까?
쿠버네티스 Pod 들은 각각 노드끼리 가지고 있는 네트워크 인터페이스를 통해 다른 노드에 있는 POD와 통신을 한다고 배웠다.
하지만, 노드들은 어떤POD들이 어떤 노드에 있는지 어떻게 알수 있을까? 즉, 라우팅 테이블이 있어야 서로 통신할수 있을것이다.
이는 CNI를 설치하면 서로 통신할수 있다. CNI를 설치하면 해당 클러스터는 필요한 라우팅 정보를 서로 광고 해줄 뿐만 아니라 
라우팅 테이블을 호스트와 컨테이너에 추가하고 삭제하는 작업까지 대리한다.

컨테이너가 생성되면 브릿지(pair 쌍)를 생성하고 컨테이너에 IP를 할당하며 컨테이너 내부에 Default Route table을
만들어줘서 상대방 인터페이스로 arp 요청을 보냅니다. 이러한 방식으로 컨테이너는 CNI 덕분에 통신할수 있습니다.

 

 

AWS 관련 질문

 

✅ Devops 직무의 관련 질문 50% 이상이 AWS 및 타 Public Cloud 등의 인프라 설계 및 운영 경험과 장애 경험 

☑︎ 더 나아가서 장애 해결 프로세스를 이해하고 많은 경험을 가지고 있는가를 확인하고자 한다.

 

 

개념부터 용어부터

AWS VPC 네트워크 설계 

☑️ 퍼블릭 서브넷 : 인터넷과 통신 가능한 대역

☑️ 프라이빗 서브넷 : 인터넷과 단절된 대역 

☑️ 인터넷 게이트웨이 : 인터넷과 통신하기 위한 GW

☑️ NAT 게이트웨이 (내부에서 외부로) : 프라이빗 서브넷에서 인터넷으로 나가는 방법

☑️ 로드밸런서 (외부에서 내부로) : 인터넷에서 프라이빗 서브넷으로 들어오는 방법

 

 

 

 추가적으로 알면 좋음 

AWS 이외의 서비스와의 접근 방안 및 설계  

• TGW 사용시 서로다른 VPC의 중복 IP 에 대한 대처 방안
• VPN 연결 방안 (S2S VPN과 Client VPN 차이점) 
• VPC 엔드포인트 및 privatelink 용도