[쿠버네티스 관련] k3s 관련하여 여쭙습니다.

   조회 6410   추천 0    

안녕하세요~ 상단 메뉴중 쿠버네티스 관련 문의를 올릴만한 곳이 없어서 이 곳에 질문 남깁니다.
쿠버네티스 입문중인 중생(?)입니다...

기존에 운영하던 서버를 신규장비로 교체하면서 쿠버네티스를 도입하려고 합니다.
k8s를 직접 설치하자니 머리 꾀나 아플듯 하고.. 간단히 설치해서 활용 가능한 k3s로 결정하고 셋업을 진행중입니다.

로컬에서 virtualbox 및 네이버의 ncloud에서 테스트 시에 바로 세팅이 완료되어서 별 이슈 없겠거니 하고 이용중인 업체에 신규서버 2대를 신청하여
똑같이 세팅을 하는데 당최 master에 worker가 붙지 않네요...

신규 신청한 서버는 IDC의 같은 스위치에 물려 있으며 ssh 등의 통신은 정상적으로 이뤄지는데 왜 클러스터링이 되지 않는지 알수가 없습니다.
같은 네트웍 상에 있으면 묻지도 따지지도 않고 바로 붙어야 하는게 아닌가 싶은데...

worker node에서 systemctl status k3s-agent 해보면 아래와 같은 에러 메세지가 뜹니다.

Dec 18 14:11:38 ubuntu k3s[4080]: time="2020-12-18T14:11:38.740997340Z" level=info msg="Starting k3s agent v1.18.6+k3s1 (6f56fa1d)"
Dec 18 14:11:38 ubuntu k3s[4080]: time="2020-12-18T14:11:38.741250190Z" level=info msg="module overlay was already loaded"
Dec 18 14:11:38 ubuntu k3s[4080]: time="2020-12-18T14:11:38.741282971Z" level=info msg="module nf_conntrack was already loaded"
Dec 18 14:11:38 ubuntu k3s[4080]: time="2020-12-18T14:11:38.741306851Z" level=info msg="module br_netfilter was already loaded"
Dec 18 14:11:38 ubuntu k3s[4080]: time="2020-12-18T14:11:38.741787670Z" level=info msg="Running load balancer 127.0.0.1:42287 -> [xxx.yyy.xxx.yyy:6443]"
Dec 18 14:11:38 ubuntu k3s[4080]: time="2020-12-18T14:11:38.743225850Z" level=error msg="failed to get CA certs at https://127.0.0.1:42287/cacerts: Get https://127.0.0.1:42287/cacerts: read tcp 127.0.0.1:35382->127.0.0.1:42287: read: connection reset by peer"
Dec 18 14:11:40 ubuntu k3s[4080]: time="2020-12-18T14:11:40.745048831Z" level=error msg="failed to get CA certs at https://127.0.0.1:42287/cacerts: Get https://127.0.0.1:42287/cacerts: read tcp 127.0.0.1:35390->127.0.0.1:42287: read: connection reset by peer"
Dec 18 14:11:42 ubuntu k3s[4080]: time="2020-12-18T14:11:42.746850585Z" level=error msg="failed to get CA certs at https://127.0.0.1:42287/cacerts: Get https://127.0.0.1:42287/cacerts: read tcp 127.0.0.1:35398->127.0.0.1:42287: read: connection reset by peer"|
Dec 18 14:11:44 ubuntu k3s[4080]: time="2020-12-18T14:11:44.748546343Z" level=error msg="failed to get CA certs at https://127.0.0.1:42287/cacerts: Get https://127.0.0.1:42287/cacerts: read tcp 127.0.0.1:35406->127.0.0.1:42287: read: connection reset by peer"
Dec 18 14:11:46 ubuntu k3s[4080]: time="2020-12-18T14:11:46.750159432Z" level=error msg="failed to get CA certs at https://127.0.0.1:42287/cacerts: Get https://127.0.0.1:42287/cacerts: read tcp 127.0.0.1:35414->127.0.0.1:42287: read: connection reset by peer"

load balancer에서 정상적으로 master로 매핑은 이뤄졌는데 CA certs를 가져오지 못합니다.

아 참.. 상호 서버간 모든 포트는 열려있는 상태입니다.

혹시나 해서 master 실행 시에 --tls-san 으로 master의 IP를 추가해 줘봐도 똑같고...
멘붕 삽질중에 있습니다.. 누군가 약간의 팁이라도 주시면 감사하겠습니다.

또한 궁금한 몇가지 사항을 함께 적어봅니다.

1. k8s의 master 노드와 worker 는 서로 다른 네트워크에 위치하게 구성이 가능한가?
예를들면 마스터와 워커가 서로 다른 IDC의 다른 IP 대역에 위치하는거죠.. k8s가 NAT을 통한 네트워크 구성을 싫어한다고 알고있는데...
어찌어찌 하면 불가할 것 같지는 않은데 그렇게 설계된 시스템이 아니라면 굳이 하지는 않겠습니다.

2. master 노드가 죽으면.. worker에 돌아가고있던 아이들도 같이 증발하는가..?
이건 여러 방면으로 검색을 해봐도 명확히 설명된 것을 찾지 못해서 바보같은 질문일수도 있지만..
master에서 모든 리소스를 관리하기에 당연히 마스터가 죽으면 워커들도 죽을 것 같기도 하면서도..
또 워커에서 잘 돌고있는 아이는 그냥 잘 돌아가지 않을까? 알쏭달쏭 하여 이렇게 질문을 남겨봅니다.

짧은글 일수록 신중하게.
찬이 2020-12
k3s는 안써봐서 모르겠습니다만.. 가볍고 고 가용성이 지원되지 않는걸로 기억하는데 요즘엔 어떻게 바뀌었을지 모르겠네요...
일단 해당 에러는 master node의 주소가 잘못 지정되어서 127.0.0.1을 타는거 같은대 k3s는 안써봐서 설정법은 모르겠습니다.

궁금한 사항에 대해서 k8s기준으로 말씀드리면
1. Overlay Network설정에 따라 다릅니다.
Calico기준으로 https://docs.projectcalico.org/networking/determine-best-networking 보시면 환경에 따른 설명이 있습니다.

2. 마스터가 죽는다고 모든 서비스가 즉시 죽어버리진 않습니다.
containerd가 살아있는 한 기존에 스케쥴링 되었던 파드는 돌아갑니다.
단 더이상 파드 스케쥴링은 못하기 때문에 제 역할을 하지 못해 오류가 생기면, 시간이 지나면 죽을겁니다.

k3s는 개인적으로 비추드립니다.. 저는 k8s를 수년간 운영해 보았습니다. 일단 k3s가 sqlite db를 쓰는걸로 보아 아직도 단일 마스터 노드인거 같은데.. k8s를 쓰면서 마스터노드가 최소 3대는 있어야 합니다. 운영하다보면 마스터를 잠깐 죽여야 하는 경우가 있을 수 있는데 그런 경우 골치 아파집니다.

그리고 스토리지에 대한 신경을 쓰셔야 합니다. k8s의 목적이 고 가용성인데 노드에 상관없이 파드를 스케쥴링하고 데이터를 유지하려면(DB 등) rook-ceph과 같은 스토리지 클러스터를 사용해야 합니다. 참고로 rook-ceph사용시 스토리지(osd)노드는 다른 파드가 스케쥴링 되지 않게 별도의 노드가 있어야 합니다. xfs사용시 커널 버그가 있어서요.

참고로.. 예시로 DB를 들긴 했지만 실제로 DB는 pvc위에서 돌리지 않고 별도의 노드에서 hostPath로 돌리는걸 추천합니다.
물론 DB에 대한 고 가용성은 메뉴얼로 관리하셔야 합니다. rook-ceph위에서 DB를 돌리기엔 네트워크 부하 및 장비성능이 많이 들어서요.
     
오월의행복 2020-12
찬이님 친절한 답변 감사드립니다.

일단 master node의 주소 설정 문제는 아닌것 같습니다.
똑같은 세팅 방법과 설정으로 로컬 vm및 ncloud 에서 정상적으로 클러스터 구성을 했었습니다.
약간 의심되는건 IDC에서 서버 세팅시 뭔가..  뭔지 모를 뭔가가 있지 않나 싶습니다;;
k3s의 경우 agent에서 master로의 통신을 할 때 "Running load balancer 127.0.0.1:42287 -> [xxx.yyy.xxx.yyy:6443] 이런식으로 local의 특정 포트와 master의 6443포트를 매핑해서 쓰는 것 같더라구요.
테스트 했던 환경에서는 모두 저 메세지가 뜨면서 잘 작동을 하는데...

알려주신대로 overlay network 에 관해서 좀 공부 해보겠습니다 키워드 감사합니다.

위의 답변을 듣고나니 약간의 고민이 되긴 합니다만.. k8s를 도입할 수 있는 상황은 아니고..
docker를 매뉴얼로 운영하기보단 오케스트레이션 반쪽으로라도 사용 해보고싶어서 알아보다가 계획한 일인데 좀더 고민을 해봐야할까요...?^^;

k3s가 etcd를 이용하지 않고 sqlite를 default로 사용하긴 하나 데이터스토리지로 외부의 mysql, posgresql 등도 지원하긴 합니다..
etcd의 성능은 못 내겠지만요...ㅎㅎ

DB 관련해서도 좋은 팁 감사드립니다.
PVC와 hostPath중 어떤 것을 활용해야할지 약간 고민중이었는데 마침 답변을 주셨습니다 ㅠㅠ

약간 덧붙이자면 굳이 k3s를 도입하려 했던 이유가.. 기존에는 서버 한대에 Apache + Mysql + PHP 를 세팅하여 virtual host로 여러 웹사이트를 운영했는데
시간이 지나다보니 모든 웹사이트가 apache나 php의 버전 의존성이 있어서 업데이트를 한먼 하려해도 dependency가 너무 많아서 각 웹사이트나 앱등을
별도 환경으로 깔끔하게 구성해보고자 했습니다.. docker를 혼용해서 사용하고 있었는데 (apache reverse proxy) 아예 docker 기반으로 변화를 주려 하는거죠..

좀 더 연구해봐야겠습니다.
감사합니다!
          
찬이 2020-12
그럼 master node에서 netstat -anplt 로 6443이 떠있는지 확인해 보시고
worker에서 nc -z MASTER_IP 6443 && echo OK || echo FAIL 명령으로 연결 여부를 확인해 보세요.
6443이 안뜨면 마스터가 안뜬거고... 두번째꺼가 FAIL이면 무언가가 막고.. 같은 스위치라면 방화벽밖엔 없을텐데.. 설정 내용을 모르니 전 모르겠습니다..^^

etcd를 쓰는 이유는 성능보다는 고-가용성 때문입니다. etcd는 알아서 peer끼리 복제하기에..

간단하게 쓰신다면 어떻게 쓰시든 큰 상관 없을거같습니다.
어찌되었던 docker쓰다가 k8s쓰면.. 신세계입니다ㅎㅎ
               
오월의행복 2020-12
말씀 주신대로 netstat에서 6443은 떠있는 상태이구요..
worker에서의 명령어는 FAIL이 뜨네요..
하도 안되길래 방화벽 + iptables까지 모두 끄고 테스트해봐도 죽어도 연결이 안되요...
ping이나 ssh 등은 정상적으로 붙는데.. 이해가 안가네요..
제 선에서는 확인할 길이 없는 것 같습니다. 월요일에 IDC에 연락해봐야지요..

etcd는 master끼리 서로 복제를 하는군요.. 메모리기반이라 빠릿빠릿하게 바로바로 복제를 잘 하나봅니다.
늦은 시간인데 답변 주셔서 너무 감사드려요!! 좋은 주말 보내십시오^^
               
오월의행복 2020-12
원인은 알아냈습니다만 왜 그렇게 작동하는지 모르겠네요...
일단 작동하는 로컬VM과 클라우드의 경우 netstat 을 했을 떄 0.0.0.0:6443으로 포트가 LISTEN 중인데...
작동하지 않는 문제의 서버에서는 127.0.0.1:6443으로만 열려있습니다.
k3s의 설치 및 실행 스크립트는 동일한 것을 사용하였는데 이렇게 다른 결과가 나오니 참 당황스럽네요..

------------------ 추가

그게 원인이 아니었네요...
ncloud에서는 0.0.0.0으로 리슨을 하고있는데
로컬 virtualbox vm에서는 또 127.0.0.1로 리슨을 하고있는데도 잘 작동을 합니다;;
환장하겠네요..


QnA
제목Page 880/5727
2014-05   5253397   정은준1
2015-12   1778384   백메가
2015-06   4099   임형우
2016-07   4976   황혼을향해
2011-11   9434   박문형
2015-06   4593   BJ후늬
2011-11   6456   2CPU최주희
2016-07   5845   늘파란
2016-07   4042   김윤술
2021-03   4312   서울사람
2015-06   4174   제온5472
2016-07   13074   누굴까
2016-07   6689   prasha
2018-11   3822   파소나
2022-11   1884   naan
2015-07   4238   voworks
2016-08   4112   김건우
2017-08   3292   병따개님
2021-04   3403   트니아빠
2015-07   4502   PiPPuuP
2018-11   4567   으라차차차
2016-08   6605   겨울나무