KubernetesINACTION/밑줄긋기

쿠버네티스 소개

• p37
• 몇 년 전만 하더라도 대부분의 소프트웨어 어플리케이션은 하나의 프로세스 또는 몇 개의 서버에분산된 프로세스로 실행되는 거대한 모놀리스(monolith)였다.
  • 쿠베 전에는 통합을 하려는 시도로 Hadoop등이 각광을 받긴했었지. 근데 이것도 모노리스라고해야하나 - 김준석
• p38
• 쿠버네티스는 개발자가 운영 팀의 도움 없이도 자신의 애플리케이션을 원하는 만큼 자주 배포할 수 있도록 한다.
  • DevOps는 저주다 - 서지혜
• p39
• 쿠버네티스는 하드웨어 인프라를 추상화하고 데이터 센터 전체를 하나의 거대한 컴퓨팅 리소스로 제공한다
  • 쿠버네티스가 하드웨어 인프라를 추상화하는 방법도 나중에 나오려나? 궁금하다 - 서지혜
• p40
• 모놀리스 어플리케이션의 일부분이 수평적으로 확장하기 매우 어렵거나 불가능하고, 어떻게든 분할할 수 없다면 전체 어플리케이션을 확장할 수 없다.
  • MSA의 가장 중요한 기본 사상이긴 한데.. 모놀리틱한 케이스에도 서비스가 이정도인건 거의 못본것 같고, DB에 대한 예시지.. - 김준석
• p41
• 마이크로서비스는 일반적으로 RESTFul API를 제공하는 HTTP와 같은 동기 프로토콜과 AMQP와 같은 비동기 프로토콜로 통신한다.
• 각 마이크로서비스는 대체로 정적인 외부 API를 제공하는 독립형 프로세스이기 때문에 개별적으로 개발, 배포할 수 있다.
  • 이번에 MSA를 추진하면서 적당한 프로토콜을 살펴보고 있는데 AMQP도 찾아봐야겠다. MSA 지향하면서 왜 중앙화 시스템을 얘기하는건지.. - 서지혜
• p44
• 시스템 관리자가 최신 보안 패치를 사용해 시스템을 최신 상태로 유지하는 데 주안점을 두는 데 반해, 많은 개발자는 그렇지 않다는 점이 두 시스템 간의 큰 차이를 만들게 된다.
  • 우리 회사에서는 개발자들 간에 보수와 진보로 나뉘어져 싸우는걸 보느라면은... 암호나 일단 제대로 걸라고요 - 김준석
• p45
• 개발자가 프로덕션 환경에서 애플리케이션을 실행하는 데 더 많이 관여하게 되면, 사용자가 무엇을 필요로 하고 어떤 문제가 있는지, 운영 팀이 애플리케이션을 유지하면서 직면하는 문제가 무엇인지 더 잘 이해할 수 있다.
  • 개발자가 운영도 하게되는 DevOps는 저주다 - 서지혜
  • 풀스택에 이은 총괄 노예의 새로운 단어 - 김준석
• p46
• 하드웨어 인프라를 전혀 알지 못하더라도 운영 팀을 거치지 않고 개발자가 애플리케이션을 직접 배포하는 방식이 가장 이상적이다. 이를 노옵스(NoOPs)라고 한다.
  • 이건 또 뭐여 - 서지혜
• p47
• 가상머신을 사용해 각 마이크로서비스의 환경을 격리하는 대신 개발자들은 리눅스 컨테이너 기술로 눈을 돌렸다.
• 컨테이너에서 실행되는 프로세스는 다른 모든 프로세스와 마찬가지로 호스트 운영체제 내에서 실행된다. 그러나 컨테이너의 프로세스는 여전히 다른 프로세스와 격리돼 있다.
  • 가상머신과 컨테이너의 차이가 뭐지?! - 서지혜
• 컨테이너를 가상머신과 비교하면 컨테이너는 훨씬 더 가벼워서 동일한 하드웨어에서 더 많은 수의 소프트웨어 구성 요소를 실행할 수 있다. 가상머신은 구성 요소 프로세스뿐만 아니라 시스템 프로세스를 실행해야 하기 때문에 추가 컴퓨팅 리소스가 필요하다.
  • 가상머신이 컨테이너보다 무거운가 보군! - 서지혜
• p49
• 컨테이너는 호스트 OS에서 실행되는 동일한 커널에서 시스템 콜을 수행한다.
  • 가상머신은 게스트OS가 하이퍼바이저로 추상화된 호스트OS를 사용하지만 컨테이너는 호스트OS를 직접 사용하기 때문에 더 가벼운 거구나 - 서지혜
• 이 커널은 호스트의 CPU 에서 x86의 명령을 수행하는 유일한 커널이다.
  • 컨테이너가 커널에 의존성이 있는것으로 보이지만, 리눅스 규약상 컨테이너는 자신이 묶인 커널에 대한 소스를 이진 코드로 내부적으로 어떤 커널 버전에서도 호환되게 가지고 있기 때문에 커널 버전에 상관없이 내부 어플리케이션은 돌아갈수 있다.가 정론인데.. 쿠베 이미지가 우분투 14, 16, 18/ centOS 외에 본적이 없어서 뻑나는지도 모르겠네. - 김준석
• p51
• 컨테이너 격리를 가능하게 하는 메커니즘 소개
• 두 가지 메커니즘으로 가능하다.
• 첫 번째는 리눅스 네임스페이스(namespace)로 각 프로세스가 시스템에 대한 독립된 뷰만 볼 수 있도록 한다. 두 번째는 리눅스 컨트롤 그룹(cgroups)으로, 프로세스가 사용할 수 있는 리소스의 양을 제한한다.
  • 리눅스에서만 동작할 것 같은 느낌 - 서지혜
  • chroot와 다른점은 마운트 패스 뿐 아니라 모든 리소스에대해 적용한다는것 - 김준석
• p52
• 컨테이너 기술은 오랫동안 사용돼 왔지만 도커 컨테이너 플랫폼의 등장으로 더 널리 알려지게 됐다.
  • Linux 컨테이너 기술은 2006년부터 연구되어왔고, 도커 초창기 라이브러리는 리눅스컨테이너 라이브러리를 참고하고있었다. 하지만 요즘은 linux 컨테이너에서 제공되지 않는 기능과 버전 종속성을 벗어나기 위해 독자적 라이브러리를 구축함 - 김준석
• p57
• 컨테이너의 프로세스가 기본 레이어 중 하나에 있는 파일에 쓰면 전체 파일의 복사본의 최상위 레이어에 만들어지고 프로세스는 복사본에 쓴다.
  • 현재는 overlayFS2를 쓰고있는것으로 앎. 당근 버전업은 overlayFS에 스펙을 추가한거고 도커 버전이 업되면 신경쓸일 없음. - 김준석
• p58
• 머신이 다른 버전의 리눅스 커널로 실행되거나 동일한 커널 모듈을 사용할 수 없는 경우 어플리케이션이 실행 될 수 없다.
  • 다른 커널 버전 OS에서 컨테이너가 전혀 돌아가지 않는다는 소리를 좀 해야할것 같은데. Linux Standard Base(LSB)로 ISO 표준 시스템 콜 API은 호환이 되어서 되긴할껀데.. 아마 minimum kernel 버전을 요구하는데도 있을거고.. https://en.wikipedia.org/wiki/Linux_Standard_Base - 김준석
• p59
• 구글은 10년동안 보그와 오메가를 비밀로 유지하다가 2014년 보그, 오메가, 기타 내부 구글 시스템으로 얻은 경험을 기반으로 하는 오픈소스 시스템인 쿠버네티스를 출시했다.
  • 구글이 Hadoop으로 배운게 컸나보네 - 서지혜
• p61
• 서비스 디스커버리, 스케일링, 로드밸런싱, 자가 치유, 리더 선출 같은 것들이 포함된다.
  • 리더 선출은 처음 들어보네 https://en.wikipedia.org/wiki/Leader_election 이거 zookeeper가 사용한다고 되어있는데 안써봄, 69P에 방법이 나와있네 - 김준석
• p62
• 마스터 노드는 전체 쿠버네이트 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 실행한다. 워커 노드는 실제 배포되는 컨테이너 애플리케이션을 실행한다
  • 마스터-워커 구성은 클러스터 시스템들의 기본 아키텍쳐로구만 - 서지혜
• p63
• 저자는 (...) 동작 방식부터 설명하는 방식을 싫어한다.
  • 나는 지금 그게 알고싶은디 - 서지혜
• p66
• kube-proxy는 서비스를 제공하는 모든 컨테이너에서 서비스 연결이 로드밸런싱되도록 한다.
  • 네트워크 설정에서 해방이다 만세!! - 김준석
• p68
• 인프라에 장애가 발생한 노드가 없어도 정상적인 시스템 작동이 가능하도록 충분한 예비 자원이 있는 경우 운영 팀은 새벽 3시에 일어난 장애에 즉시 대응할 필요가 없다.
  • 동남아가 제발 하드좀 잘 관리해줬으면.. 예비 자원좀 - 김준석

도커와 쿠버네티스 첫걸음

도커를 사용한 컨테이너 이미지 생성, 실행, 공유하기

• p73
  • [busybox]( https://en.wikipedia.org/wiki/BusyBox)는 echo, ls, gzip 등과 같은 표준 UNIX 명령줄 도구들을 합쳐 놓은 단일 실행파일(executable)이라 할 수 있다.
  • busybox는 ubuntu 부팅할때 접해볼수 있는데 개별 명령어 대신 busybox로 대체한다. 부팅디스크를 이용한 OS 구동때는 ram에 공간을 만드는데, 빡빡하게 용량을 관리하기 때문에 busybox를 쓴다. - 김준석
• p76

FROM node:7
ADD app.js /app.js
ENTRYPOINT ["node", "app.js"]

• Dockerfile을 쓴지 오래되긴 했다. - 김준석
• p79
  • 이미지라는 것이 하나의 큰 바이너리 더어리가 아니라 여러개의 레이어로 구성된다는 것을 아마도 눈치챘을 것이다. 서로 다른 이미지가 여러 개의 레이어를 공유할 수 있기 때문에 이미지의 저장과 전송에 효과적이다.
  • 기본 이미지를 구성하는 모든 레이어는 단 한 번만 저장될 것이다. 또한 이미지를 가져올 때도 도커는 각 레이어를 개별적으로 다운로드 한다. 컴퓨터에 여러개의 레이어가 이미 저장돼 있다면 도커는 저장되지 않은 레이어만 다운로드 한다.
• p80
  • Dockerfile을 이용하는 것이 훨씬 반복 가능하고 이미지 빌드를 자동화할 수 있는 방법이다.
  • image commit하는 사람도 의외로 많다. - 김준석
• p82

$ docker exec -it kubia-container bash

• 당연히 도커가 한번에 돌아가지 않기때문에 가장 많이 쓰는 구문 - 김준석
• p84
  • 컨테이너는 자체 리눅스 PID 네임스페이스를 사용하며 고유의 시퀀스 번호를 가지고 완전히 분리된 프로세스 트리를 갖고 있다.
  • container의 PID 밑 Conatainer 내부 init 프로세스를 기준으로 tree가 생긴다. - 김준석
  • 격리된 프로세스를 가진 것과 마찬가지로 각 컨테이너는 격리된 파일시스템을 갖고 있다.
  • default 위치로 host에서 접근을 할수 있는것으로 알고있고 파일 교환을 위한 mount path지정도 가능 - 김준석
• p85
  • 작업을 단순화하기 위해 사설 이미지 레지스트리를 설정하기보다는 공개적으로 사용할 수 있는 레지스트리 중 하나인 도커 허브에 이미지를 푸시한다.
  • 사설 이미지 레지스트리가 중요한데 - 김준석

쿠버네티스 클러스터 설치

• 직접 설치해보자 - 서지혜
• p87
  • 세 번째 옵션은 kubeadm 도구를 사용해 클러스터를 설치하는 방법으로, 부록B에서 설명한다. 이 책의 11장까지 읽어본 뒤 시도해볼 것을 추천한다.
  • 이걸 제일 많이 쓰는것 같은데 - 김준석
  • 또 다른 옵션은 AWS에 쿠버네티스를 설치하는 것이다.
  • 로드 테스트할때 AWS에 구성된걸 사용하더라 - 김준석
• p89
  • darwin을 windows로 변경하고 맨 뒤에 .exe를 추가한다.
  • 왜 mac의 darwin이 기본인가?
• p91
  • 빌링을 활성화한다. 신용카드 정보가 필요하지만 구글은 12개월 무료 평가판을 제공한다.
  • 자나깨나 빌링 조심 - 김준석
• p92
  • 각 노드는 도커, kubelet, kube-proxy를 실행한다.
  • 도커위에 kubelet, kube-proxy가 올라가있는거였던가 - 김준석
• p94
  • kubectl alias와 명령줄 자동완성 설정하기
  • kubectl kubectl 계속치면 k로 alias를 하게 되더라 - 김준석
  • k와 같은 짧은 별칭을 사용하더라도 생각보다 많은 명령어를 입력해야 한다.
  • 다른것도 다 alias를.. - 김준석

쿠버네티스에 첫 번째 애플리케이션 실행하기

• p97
  • 쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다. 대신 함꼐 배치된 다수의 컨테이너라는 개념을 사용한다. 이 컨테이너의 그룹의 이름을 파드라고 한다.
  • POD는 여러개의 컨테이너가 들어갈수 있음. - 김준석
  • 각 파드는 자체 IP, 호스트 이름, 프로세스 등이 있는 논리적으로 분리된 머신이다.
  • 머신이지만 os가 없는 느낌? 자원관리 등을 다 상위에서 해주니 논리적으로 머신이기만 함 - 김준석
• p98
  • ` kubectl get pods `
  • kgp - 김준석
• p99
  • kubectl 명령어를 실행하면 쿠버네티스의 API 서버로 REST HTTP 요청을 전달하고 클러스터에 새로운 레플리케이션컨트롤러 오브젝트를 생성한다.
  • 클라이언트 -> 서버 -> 명령 수행 - 김준석
• p100
  • 외부에서 파드에 접근을 가능하게 하려면 서비스 오브젝트를 통해 노출해야 한다.
  • 서비스 할당? - 김준석
  • 파드와 마찬가지로 일반적인 서비스(Cluster IP 서비스)를 생성하면 이것은 클러스터 내부에서만 접근 가능하기 때문에 Load Balancer 유형의 특별한 서비스를 생성해야 한다.
  • 로드밸런서 생성은 처음 본듯 - 김준석
• p101

kubectl expose rc kubia --type=LoadBalancer --name kubia-http

kubernetes 서비스에 관한 설명은 생략

• p103
  • kubectl run 명령을 수행하면 레플리케이션컨트롤러를 생성하고 레플리케이션컨트롤러가 실제 파드를 생성한다.
  • 띄어쓰기 좀.. - 서지혜
  • 마스터 노드가 단일 마스터 노드에서 호스팅 중인지 혹은 여러 대의 마스터 노드에 분산된 것인지 알 수 없다.
• p104
  • 레플리케이션컨트롤러는 사라진 파드를 대체하기 위해 새로운 파드를 생성할 것이다.
  • 파드는 일시적(ephermeral)이다.
  • 새로운 파드는 다른 IP 주소를 할당받는다. 이것이 바로 서비스가 필요한 이유다.
• p106

kubectl scale rc kubia --replicas=3

kubectl get rc

• p107
  • 서비스는 다수 파드 앞에서 로드밸런서 역할을 한다. 파드가 하나만 있으면 서비스는 이 파드 하나에 정적 주소를 제공한다.

• p109
  • 어떤 노드에 파드가 스케줄링됐는지 궁금할 수 있다. 쿠버네티스에서는 파드가 적절히 실행하는 데 필요한 CPU와 메모리를 제공하는 노드에 스케줄링됐다면, 어떤 노드에 파드가 실행 중인지는 중요하지 않다.
  • 파드를 조회할 때 파드 IP와 실행 중인 노드 표시하기
  • Template:$ kubectl get pods -o wide}
• p110
  • 쿠버네티스 또한 꽤 멋진 웹 대시보드를 함께 제공한다는 점을 알게 되면 기뻐할 것이다.

파드: 쿠버네티스에서 컨테이너 실행

파드 소개

• p114
  • 파드는 함께 배치된 컨테이너 그룹이며 쿠버네티스의 기본 빌딩 블록이다.
  • 모든 컨테이너는 항상 하나의 워커 노드에서 실행되며 여러 워커 노드에 걸쳐 실행되지 않는다.
  • 궁금했던 부분. 리소스를 테트리스는 어려운거군 - 서지혜
  • IPC 혹은 로컬 파일을 통해 통신하는 여러 프로세스로 구성돼, 같은 노드에서 실행해야 하는 애플리케이션을 상상해보자.
  • 모든 프로세스는 동일한 표준 출력으로 로그를 기록하기 때문에 어떤 프로세스가 남긴 로그인지 파악하는 것이 매우 어렵다.
• p116
  • UTC 네임스페이스
  • 비슷하게 파드의 모든 컨테이너는 동일한 IPC 네임스페이스 아래에서 실행되 IPC를 통해 서로 통신할 수 있다.
  • 플랫한 공유 네트워크 주소 공간에 상주하므로 모든 파드는 다른 파드의 IP주소를 사용해 접근하는 것이 가능하다.
• p117
  • 파드 사이에서 통신은 항상 단순하다. 두 파드가 동일 혹은 서로 다른 워커 노드에 있는지는 중요하지 않으며, 두 경우 모두 파드 안에 있는 컨테이너는 NAT 없는 플랫 네트워크를 통해 서로 통신하는 것이 가능하다,
  • 이거 파드 하나 들어가서 다른 서비스들 다 털 수 있는거 아닙니까 - 서지혜
  • 이것은 실제 노드 간 네트워크 토폴로지와 관계없이, 근거리 네트워크에 있는 컴퓨터 간의 통신과 비슷하다.
  • 파드는 논리적인 호스트로서 컨테이너가 아닌 환경에서의 물리적 호스트 혹은 VM과 매우 유사하게 동작한다.
• p118
  • 파드에서 컨테이너의 적절한 구성
  • 파드는 스케일링의 기본 단위다.
  • 최근에 여러 파드로 쪼개놓은 서버들을 굳이 굳이 한 파드로 만들어놓은 걸 보고 의아했던 기억 - 서지혜
• p119
  • 프론트엔드 구성 요소는 백엔드와 완전히 다른 스케일링 요구 사항을 갖고있어 개별적으로 확장하는 경향이 있다.
  • 사이트카 컨테이너의 다른 예제로는 로그 로테이터와 수집기, 데이터 프로세서, 통신 어댑터 등이 있다.
• p121

$ kubectl get po kubia-zxzij -o yaml

• • pod의 약자... - 서지혜
• p123
  • 거의 모든 쿠버네티스 리소스가 갖고 있는 세 가지 중요한 부분이 있다. Metadata, spec, status
  • Metadata: 이름, 네임스페이스, 레이블 및 파드에 관한 기타 정보를 포함한다.
  • Spec: 파드 컨테이너, 볼륨, 기타 데이터 등 파드 자체에 관한 실제 명세를 가진다.
  • Status: 파드 상태, 각 컨테이너 설명과 상태, 파드 내부 IP, 기타 기본 정보 등 현재 실행 중인 파드에 관한 현재 정보를 포함한다.
• p125

kubectl explain

• p126

$ kubectl create -f kubia-manual.yaml

• p128

$ kubectl logs kubia-manual -c kubia

• p130
  • 파드 수가 증가함에 따라 파드를 부분 집합으로 분류할 필요가 있다.
• p131
  • 레이블은 리소스에 첨부하는 키-값 쌍으로, 이 쌍은 레이블 셀렉터를 사용해 리소스를 선택할 때 활용된다.
• p133
  • kubectl get pods 명령은 레이블을 표시하지 않는 것이 기본값이라 --show-labels 스위치를 사용해 레이블을 볼 수 있다.
  • 모든 레이블을 나영하는 대신 특정 레이블에만 관심 있는 경우 해당 레이블을 -L 스위치로 지정해 각 레이블을 자체 열에 표시할 수 있다.
• p135

$ kubectl get po -l creation_method=manual

$ kubectl get po -l '!env'

• p137
  • 레이블 셀렉터는 파드 목록을 나열하는 것뿐만 아니라, 파드 부분 집합에 작업을 수행할 때도 유용하다.
• p139
  • 쿠버네티스의 전체적인 아이디어는 그 위에 실행되는 애플리케이션으로부터 실제 인프라스트럭처를 숨기는 것에 있기에 파드가 어떤 노드에 스케줄링 돼야 하는지 구체적으로 지정하고 싶지는 않은 것이다. 그로 인해 애플리케이션이 인프라스트럭처에 결합되기 때문이다. 그러나 정확한 노드를 지정하는 대신 필요한 노드 요구 사항을 기술하고 쿠버네티스가 요구 사항을 만족하는 노드를 선택하도록 한다. 이는 노드 레이블과 레이블 셀렉터를 통해 할 수 있다.
  • 노드를 포함한 모든 쿠버네티스 오브젝트에 레이블을 부착할 수 있다.
• p141
  • 레이블은 오브젝트를 묶는 데 사용할 수 있지만, 어노테이션은 그렇게 할 수 없다.
• p142
  • 레이블에는 짧은 데이터를, 그에 비해 어노테이션에는 상대적으로 큰 데이터를 넣을 수 있다(총 256kb)까지.
  • 레이블은 63 char 로 제한되더라 - 김준석
• p143
  • 여러 네임스페이스를 사용하면 많은 구성 요소를 가진 복잡한 시스템을 좀 더 작은 개별 그룹으로 분리할 수 있다. 또한 멀티테넌트 환경처럼 리소스를 분리하는 데 사용된다.
  • 리소스 이름은 네임스페이스 안에서만 고유하면 된다.
• p145
  • 네임스페이스를 사용해 서로 관계없는 리소스를 겹치지 않는 그룹으로 분리할 수 있다.
• p148
  • 쿠버네티스는 SIGTERM 신호를 프로세스에 보내고 지정된 시간(기본값 30초) 동안 기다린다. 시간 내에 종료되지 않으면 SIGKILL 신호를 통해 종료한다. 프로세스가 항상 정상적으로 종료되게 하기 위해서는 SIGTERM 신호를 올바르게 처리해야 한다.
• p151

$ kubectl delete all -all