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
  • 프론트엔드 구성 요소는 백엔드와 완전히 다른 스케일링 요구 사항을 갖고있어 개별적으로 확장하는 경향이 있다.
  • 사이트카 컨테이너의 다른 예제로는 로그 로테이터와 수집기, 데이터 프로세서, 통신 어댑터 등이 있다.

YAML또는 JSON 디스크립터로 파드 생성

• 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

레플리케이션과 그 밖의 컨트롤러: 관리되는 파드 배포

파드를 안정적으로 유지하기

• p154
  • 컨테이너의 주 프로세스에 크래시(crash)가 발생하면 Kubelet이 컨테이너를 다시 시작한다.
  • 컨테이너가 서브 Process라서 모니터링이 가능한듯 - 김준석
  • 애플리케이션이 무한 루프나 교착 상태에 빠져서 응답을 하지 않는 상황이라면 어떨까? 이런 경우 애플리케이션이 다시 시작되도록 하려면 애플리케이션 내부의 기능에 의존하지 말고 외부에서 애플리케이션의 상태를 체크해야한다.
  • 우리 회사사람들은 다 내부에서 가능한걸로 봄. - 김준석
• p155
  • 파드의 스펙에 각 컨테이너의 라이브니스 프로브를 지정할 수 있다. 쿠버네티스는 주기적으로 프로브를 실행하고 프로브가 실패할 경우 컨테이너를 다시 시작한다.
  • 정의 밑줄 - 김준석
  • 쿠버네티스는 세가지 매커니즘을 사용해 컨테이너에 프로브를 실행한다. HTTP GET / TCP 소켓 / Exec
  • 아무래도 HTTP GET이 REST에 맞겠지 - 김준석
• p157

$ kubectl logs mypod --previous

• • Cheat sheet 추가 - 김준석
  • 숫자 137은 두 숫자를 합한 값으로, 128 + X 다.
  • 유용한 정보 +1 SIGTERM(15) SIGKILL(9) - 김준석

레플리케이션컨트롤러 소개

• p154
  • 컨테이너의 주 프로세스에 크래시가 발생하면 Kublelet이 컨테이너를 다시 시작한다.
  • 컨테이너 모니터링은 어떻게 하는걸까 - 서지혜
• p155
  • 애플리케이션이 더 이상 제대로 동작하지 않는다는 신호를 쿠버네티스에 보내서, 쿠버네이트가 애플리케이션을 다시 시작하도록 하는 방법이 있다면 좋을 것이다.
  • 그래서 라이브니스 프로브 설정을 해야하는군 - 서지혜
  • 쿠버네티스는 라이브니스 프로브를 통해 컨테이너가 살아 있는지 확인할 수 있다.
  • 쿠버네티스는 세 가지 메커니즘을 사용해 컨테이너에 프로브를 실행한다.
  • HTTP GET 프로브는 지정한 IP 주소, 포트, 경로에 HTTP GET 요청을 수행한다. ... 응답 코드가 오류를 나타내지 않는 경우에 프로브가 성공했다고 간주된다.
  • TCP 소켓 프로브는 컨테이너의 지정된 포트에 TCP 연결을 시도한다. 연결에 성공하면 프로브가 성공한 것
    • TCP는 응답까지는 보지 않는구나 - 서지혜
  • Exec 프로브는 컨테이너 내의 임의의 명령을 실행하고 명령의 종료 상태 코드를 확인한다. 상태 코드가 0이면 프로브가 성공한 것이다.
• p158
  • 크래시된 컨테이너의 애플리케이션 로그 얻기

$ kubectl logs mypod --previous

• p159
  • 숫자 137은 두 숫자를 합한 값으로, 128 + x다. ...이 예에서 x는 SIGKILL 시그널 번호인 9이며, 프로세스가 강제로 종료됐음을 의미한다.
• p162
  • 프로브에 자체적인 재시도 루프를 구현하는 것은 헛수고다.
  • 그럼 왜 임계값 정하라고 하는건데 - 서지혜
  • 파드들은 Kubelet 에서만 관리되는데, Kubelet은 노드에서 실행되기 때문에 노드 자체가 고장 나면 아무것도 할 수 없다.
• p164
  • 레플리케이션컨트롤러는 실행 중인 파드 목록을 지속적으로 모니터링하고, 특정 "유형"의 실제 파드 수가 의도하는 수와 일치하는지 항상 확인한다.
  • deploy??랑 뭐가 다른건지 모르겠네 - 김준석
  • 레플리케이션컨트롤러는 파드 유형이 아니라 특정 레이블 셀렉터와 일치하는 파드 세트에 작동한다.
  • 강조 밑줄 - 김준석
  • 레이블은 다른 서비스에서 보통 옵셔널하게 다뤄지는데 쿠베에서는 중요함 - 서지혜
• p165
  • 레플리케이션컨트롤러에는 세 가지 필수 요소가 있다. 레이블 셀렉터 / 레플리카 수 / 파드 템플릿
  • https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/ 디플로에먼트를 주로 봐서 RC와 헷갈림. 디플로이먼트(Deployment) 는 파드와 레플리카셋( ReplicaSet)에 대한 선언적 업데이트를 제공한다. 이렇게 보면 deploy가 나와야할것 같은데? - 김준석
  • https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicationcontroller 에서 ReplicaSet을 구성하는 Deployment가 권장하는 방법이라고 하네요 - 서지혜
• p166
  • 레이블 셀렉터와 파드 템플릿을 변경해도 기존 파드에는 영향을 미치지 않는다.
  • 갯수 관리만 중시하고 변경으로 인해 범위를 벗어난 파드에 대한 삭제/정지는 안하는듯 - 김준석
  • label이 잘못 지정된 Service들을 변경하고 싶은데.. 하필 타입이 LoadBalancer 라 마음이 찢어지는 중.. - 서지혜
• p172
  • 레플리케이션컨트롤러는 노드의 파드가 다운됐음을 감지하자마자 파드를 대체하기 위해 새 파드를 기동한다.
  • K8S를 쓰는 이유중 자동 복구 - 김준석
• p173
  • 노드가 몇 분 동안 접속할 수 없는 상태로 유지될 경우 해당 노드에 스케줄된 파드는 상태가 알수 없음으로 변경된다.
  • Default로 통신하는 시간 때문에 node가 not ready로 바뀌는것과 별개로 시간이 걸리는듯 - 김준석
  • 즉각적인 인간의 개입이 필요하지 않다. 시스템이 자동으로 스스로 치유한다.
  • 동어 반복같은데 - 서지혜
• p175

$ kubectl label pod kubia-dmdck app=foo --overwrite

• • 치트 시트 - 김준석
• p177
  • 파드가 오작동한다는 것을 안다면 파드를 레플리케이션컨트롤러의 범위 밖으로 빼내 컨트롤러가 새 파드로 교체하도록 한 다음, 원하는 방식으로 파드를 디버그하거나 문제를 재연해볼 수 있다.
  • 3장에서 forwarding을 이용해 pod를 디버깅하자는것의 연장선인듯. 괜찮은 생각인것 같다 - 김준석
  • 아직 특정 pod만 오작동하는 경우는 만나지 못했지만 이런일이 있으면 사용해 봐야겠다. - 서지혜
• p179
  • export KUBE_EXPORT ="/usr/bin/nano"
  • use vim? - 김준석
  • 파드를 수평으로 스케일링 하는 것이 무척 쉬운 일임을 의미한다.
  • 물론 기반시스템이 그렇게 만들어져있어야하겠지 - 김준석

kubectl scale rc kubia --replicas=10

• • 치트 시트 - 김준석

kubectl scale rc kubia --cascade=false

• • cascade - 김준석
  • ReplicationController 이제 안쓰니까 의미 없는 옵션이 아닐지... - 서지혜

레플리케이션컨트롤러 대신 레플리카셋 사용하기

• p183
  • 레플리카셋이라는 유사한 리소스가 도입됐다. 이는 차세대 레플리케이션컨트롤러이며, 레플리케이션컨트롤러를 완전히 대체할 것이다.
  • ???? 뭐여? - 김준석
  • 책의 쿠베 버전이 낮아서..ㅋㅋㅋ - 서지혜
  • 레플리카셋은 레플리케이션컨트롤러와 똑같이 동작하지만 좀 더 풍부한 표현식을 사용하는 파드 셀렉터를 갖고 있다.
  • 레이블이 없어도 셀렉트할 수 있게 된다 - 서지혜
• p185
  • API버전 속성에 대해
  • 각 API (ReplicaSet / Deployment 등) API호환을 적어놓은 블로그들이 있는것로 기억함 - 김준석
  • 이 버전 관리하는거 너무 귀찮다... - 서지혜
• p186
  • 셀렉터에 표현식을 추가할 수 있다. In / NotIn / Exsists / DoesNotExist
• p188
  • 레플리카셋을 삭제하면 모든 파드가 삭제된다.
  • 레플리카셋은 cascade=false 옵션 없나? - 서지혜

데몬셋을 사용해 각 노드에서 정확히 한개의 파드 실행하기

• p188
  • 클러스터의 모든 노드에, 노드당 하나의 파드만 실행되길 원하는 경우
  • just one - 김준석
  • 시스템 수준의 작업을 수행하는 인프라 관련 파드가 이런 경우다. 예를 들면 모든 노드에서 로그 수집기와 리소스 모니터를 실행하려는 경우가 좋은 예다. 또 다른 좋은 예는 쿠버네티스의 kube-proxy 프로세스이며, 서비스를 작동시키기 위해 모든 노드에서 실행돼야 한다.
  • 로그 수집기, 통신 등 -김준석
• p189
  • 데몬셋은 그림 4.8과 노드 수만큼 파드를 만들고 각 노드에 배포된다.
  • 새 노드가 클러스터에 추가되면 데몬셋은 즉시 새 파드 인스턴스를 새 노드에 배포한다.
  • 정의 밑줄 - 김준석
  • 데몬셋 정의의 일부인 파드 템플릿에서 node-selector 속성을 지정하면된다.
• p192

$ kubectl get ds

• • 생각해보니 ds 검색해본적이 없네 - 김준석
  • 해봤으나 권한이 없었다고 합니다 - 서지혜

완료 가능한 단일 태스크를 수행하는 파드 실행

• p194
  • 작업을 완료한 후에는 종료되는 태스크만 실행하려는 경우가 있을 것이다.
  • 그게 바로 job입니다 - 김준석
  • 이러한 잡의 예로는 데이터를 어딘가에 저장하고 있고, 이 데이터를 변환해서 어딘가로 전송해야 하는 경우를 들 수있다.
  • 뒤에 cron이 나오지만 job은 데이터 백업 / 통계 / 업데이트 에 주로 사용됨. - 김준석
• p196
  • 잡 파드는 무한정 실행하지 않으므로 기본 정책을 사용할 수 없다. 따라서 restartPolicy를 onFailure나 Never로 명시적으로 설정해야 한다.
  • 유의사항 밑줄 - 김준석
• p197
  • 잡은 두 개 이상의 파드 인스턴스를 생성해 병렬 또는 순차적으로 실행하도록 구성할 수 있다. 이는 잡 스펙에 completions와 parallelism 속성을 설정해 수행한다.
  • 몇번 완료해야해? 한번에 몇개 수행할까? - 김준석
  • activeDeadlineSeconds 속성을 설정해파드의 실행 시간을 제한할 수 있다.
  • 이걸 써야할때가 있나 싶음 - 김준석
  • hang 걸리는 잡 종료시킬 때 사용할 수 있을거같네요 - 서지혜

잡을 주기적으로 또는 한 번 실행되도록 스케줄링하기

• p200
  • 리눅스나 유닉스 같은 운영체제에서 이런 작업을 크론 작업이라 한다. 쿠버네티스에서도 이를 지원한다.
  • 다들 아는 그 cron - 김준석
• p201
  • 스케줄 설정하기
  • 분 시 일 월 요일
    • 콤마로 구분. 0은 일요일 0,30 * * * * 0,6 매달 일요일, 토요일 매시각 0분, 30분 마다. - 김준석

*/30 * * * * 0,6

이렇게 할 수도 있습니다 - 서지혜

• • 일반적인 상황에서 크론잡은 스케줄에 설정한 각 실행에 항상 하나의 잡만 생성하지만 두 개의 잡이 동시에 생성되거나 전혀 생성되지 않을 수 있다.
  • 이 책의 버전이 1.8기준이라 그런가. cronjob의 경우 replace policy가 있어서 만약 앞서 존재하는 job이 끝나지 않았다면 replace를 하거나 해당 작업이 끝날때까지 pending 할 수 있다. - 김준석
  • 추가적으로 job이 제대로 끝났는지 completion 혹은 failure pod를 보관하는게 있는데 여기선 소개 안하네 - 김준석

서비스: 클라이언트가 파드를 검색하고 통신을 가능하게 함

서비스 소개

• p206
  • 쿠버네티스의 서비스는 동일한 서비스를 제공하는 파드 그룹에 지속적인 단일 접점을 만들려고 할 때 생성하는 리소스다. 각 서비스는 서비스가 존재하는 동안 절대 바뀌지 않는 IP주소와 포트가 있다. 클라이언트는 해당 IP와 포트로 접속한 다음 해당 서비스를 지원하는 파드 중 하나로 연결된다.
  • 정의 밑줄 - 김준석
• p208
  • 서비스 연결은 서비스 뒷단의 모든 파드로 로드밸런싱된다. 레이블셀렉터를 기억할 것이다.
  • 동작 밑줄 - 김준석
• p210
  • 서비스의 클러스터 IP로 요청을 보내고 응답을 로그로 남기는 파드를 만드는 것이다.
  • 쿠버네티스 노드로 ssh 접속하고 curl 명령을 실행할 수 있따.
  • kubectl exec 명령어로 기존 파드에서 curl 명령을 실행할 수 있다.
  • 위 세개다 쓰는듯. 파드에서 curl을 하는것은 번거로워서 가장 늦게 하긴 함. - 김준석
• p211
  • 명령어의 더블 대시(--)는 kubectl 명령줄 옵션의 끝을 의미한다.
  • 번역이 이상한데 공식 홈페이지의

Note: The double dash (--) separates the arguments you want to pass to the command from the kubectl arguments.

kubectl 에서 넘기고싶은걸 -- 로 구분할수 있다는 거임. - 김준석

• p212
  • 서비스의 세션 어피니티 속성을 기본값 None 대신 ClientIP로 구성한다.
  • 하.. 티맥스에서 음성 메세지를 받을때 계속 같은 파드로 붙게 해달라고해서 이걸 본적이 있긴했지 - 김준석
• p213
  • 여러 포트가 있는 서비스를 만들 때는 각 포트의이름을 지정해야 한다.
  • 정의 밑줄 - 김준석
• p216

$ kubectl exec kubia-3inly env

• • KUBERNETES_SERVICE_HOST 와 KUBERNETEST_SERVICE_PORT 가 있는걸 첨알았네 - 김준석
• p217
  • 서비스 이름의 대시(-)는 밑줄(_)로 변환되고 서비스 이름이 환경변수 이름의 접두어로 쓰이면서 모든 문자는 대문자로 표시된다.
  • 이름 변환 규칙 밑줄- 김준석
  • DNS를 통한 서비스 검색
  • FQDN을 통한 서비스 연결
  • 서비스명.네임스페이스.svc.cluster.local0-9* 이었던가.. 여튼 DNS / FQDN을 쓰진 않지만 동작은 같은걸로 앎. DNS에서 가져오고 FQDN으로 서비스명 매치 - 김준석

클러스터 외부에 있는 서비스 연결

• p221
  • 서비스는 파드에 직접 연결되지 않는다. 대신 엔트포인트 리소스가 그 사이에 있다.
  • ep? 이거 또 번역이.. among us도 아니고 - 김준석
  • 엔드포인트 리소스는 서비스로 노출되는 파드의 IP 주소와 포트 목록이다.
  • svc가 ep 오브젝트를 들고있다고 하면 될것을.. - 김준석
• p224
  • 외부 서비스의 별칭으로 사용되는 서비스를 만들려면 유형 필드를 ExternalName으로 설정해 서비스 리소스를 만든다.
  • 내부에서 Name을 설정해본 이력이 없어서.. - 김준석
  • ExternalName 서비스는 DNS 레벨에서만 구현된다. 서비스에 관한 간단한 CNAME DNS레코드가 생성된다.
  • DNS 레벨에서만 함 - 김준석

외부 클라이언트에 서비스 노출

• 외부에서 서비스를 액세스할 수 있는 몇 가지 방법이 있다.

1. 1. 노드포트로 서비스 유형 설정
   2. 서비스 유형을 노드포트 유형의 확장인 로드밸러서로 설정
   3. 단일IP 주소로 여러 서비스를 노출하는 인그레스 리소스 만들기

• • 정의 밑줄 - 김준석
• 노드포트 서비스를 만들면 쿠버네티스는 모든 노드에 특정 포트를 할당하고 서비스를 구성하는 파드로 들어오는 연결을 전달한다.
  • 노드셀렉터로 설정된 노드? 모든 노드인가? - 김준석
• 외부 로드밸런서로 서비스 노출
  • 이것도 사용해본적은 없는데.. 결국 노드를 열고 거기로 로드밸런서한테 패스받아서 자동으로 분배 해준단 얘기지? - 김준석

인그레스 리소스로 서비스 외부 노출

• p245
  • 인그레이스는 비교적 새로운 쿠버네티스 기능이므로 향후 많은 개선과 새로운 기능를 기대할 수 있다.
  • https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122 1.19까지 사용가능하고 deprecated됨? - 김준석

파드가 연결을 수락할 준비가 됐을 때 신호 보내기

• p246
  • 쿠버네티스에서는 라이브니스 프로브와 비슷하게 파드에 레디니스 프로브를 정의할 수 있다.
  • 쿠버네티스가 아니라 서비스에서는 이라고 해야하지 않나 - 김준석
  • 레드니스 프로브 유형 / 프로세스 exec / http get / TCP 소켓
  • 이건 라이브니스랑 같네 - 김준석
  • 라이브니스 프로브와달리 컨테이너가 준비 상태 점검에 실패하더라도 컨테이너가 종료되거나 다시 시작되지 않는다.
  • 레디니스 프로브는 요청을 처리할 준비가 된 파드의 컨테이너만 요청을 수신하도록 한다
  • 이것도 나쁘지 않은 옵션이긴 한데 해본적이 없음 - 김준석
• p252
  • 레디니스 프로브를 항상 정의하라
  • 연결자체가 안되면 뻗어버리는 서비스가 많은데 이건 좋은 선택일까? - 김준석

헤드리스 서비스로 개별 파드 찾기

*

서비스 문제 해결

• p257
  • 서비스에 액세스 할수 있는지 확인하려고 서비스 IP로 핑을 할 필요 없다.
  • 첨에암것도 모를때 Ping 날리고 그랬지 - 김준석

볼륨: 컨테이너에 디스크 스토리지 연결

• p259
  • 파드 내부의 각 컨테이너는 고유하게 분리된 파일시스템을 가진다. 파일시스템은 컨테이너 이미지에서 제공되기 때문이다.
  • 도커 컨테이너 기본사이즈가 10gb를 받는다고한것 같은데 이걸 사용하는거던가? - 김준석
• p260
  • 새로 시작한 컨테이너는 이전에 실행했던 컨테이너에 쓰여진 파일시스템의 어떤 것도 볼 수가 없다.
  • 이는 파드가 시작되면 볼륨이 생성되고, 파드가 삭제되면 볼륨이 삭제된다는 것을 의미한다.
  • 지금은 컨테이너 간의 파일 시스템 공유를 위해 파드의 라이프사이클을 따르는 볼륨을 생성하는듯 - 서지혜
  • 정의 밑줄 - 김준석

볼륨 소개

• p260
  • 쿠버네티스 볼륨은 파드의 구성 요소로 컨테이너와 동일하게 파드 스펙에서 정의된다.

spec: containers: volumnMount:

구조 리마인드 - 김준석

• • 볼륨은 쿠버네티스 오브젝트가 아니므로 자체적으로 생성, 삭제될 수 없다.
    • 설명참 애매하네 - 김준석
  • 볼륨은 파드의 모든 컨테이너에서 사용 가능하지만 접근하려는 컨테이너에서 각각 마운트 돼야한다. 각 컨테이너에서 파일시스템의 어느 경로에나 볼륨을 마운트할 수 있다.
    • 설명 밑줄. - 김준석
• p263
  • 볼륨을 채우거나 마운트하는 프로세스는 파드의 컨테이너가 시작되기 전에 수행된다.
  • preload같은? 이거 컨테이너의 init 보다 먼저인가? - 김준석
  • 다양한 유형의 볼륨이 사용 가능하다.
  • emptyDir
  • hostPath
  • gitRepo
  • nfs
  • gceePersistentDisk, awsElasticBlockStore, azureDisk
  • cinder, cephfs, iscsi, flocker, glusterfs, quobyte, rbd, flexVolume, csphereVolume, photonPersistentDisk, scaleIO
  • configMap, secret, downwardAPI - 이것도 볼륨으로 치다니 김준석
  • persistentVolumeClaim

볼륨을 사용한 컨테이너 간 데이터 공유

• p264
  • emptyDir
    • 이름에서 알 수 있듯이 볼륨이 빈 디렉터리로 시작된다.
    • emptyDir 볼륨은 동일 파드에서 실행 중인 컨테이너 간 파일을 공유할 때 유용하다.
• p268
  • 볼륨으로 사용한 emptyDir은 파드를 호스팅하는 워커 노드의 실제 디스크에 생성되므로 노드 디스크가 어떤 유형인지에 따라 성능이 결정됐다.
  • 이 작업을 위해 다음과 같이 emptyDir의 medium을 memory로 지정한다.
    • 빠르겠는데? - 김준석
• p269
  • gitRepo 볼륨이 생성된 후에는 참조하는 리포지터리와 동기화하지 않는다.
  • CI 에서 사용할 수 있겠는데? - 서지혜
  • 유지보수 중단! - 김준석
• p271
  • 사이트카 컨테이너 소개
  • 새로운 로직을 메인 애플리케이션 코드에 밀어 넣어 복잡성을 더하고 재사용성을 떨어뜨리는 대신에 파드에 사이드카를 추가하면 기존 컨테이너 이미지를 사용할 수 있다.
  • 이런거 좀 해설좀 자세히 해줬으면. 사이드카와 메인nginx사이 같은 공유공간을 가지고 있는데 사이드카 컨테이너가 gitRepo 볼륨을 가지고 주기적으로 밀어넣어서 웹페이지를 갱신한단 소리겠지? - 김준석
• p272
  • 프라이빗 깃 리포지터리를 컨테이너에 복제하려면.. 다른 유사 방법을 사용해야 한다

워커 노드 파일시스템의 파일 접근

• p273
  • 파일시스템을 통해 노드 디바이스를 접근하기 위해 노드의 파일시스템을 사용해야 한다.
  • 정의 밑줄 - 김준석
  • hostPath 볼륨은 노드 파일시스템의 특정 파일이나 디렉터리를 가리킨다.
  • 특정 노드에 역할(log보관, db)를 지정해서 하기때문에 우리쪽에선 자주 쓰인다 - 김준석
  • hostPath 볼륨의 콘텐츠는 삭제되지 않는다.파드가 삭제되면 다음 파드가 호스트의 동일 경로를 가리키는 hostPath 볼륨을 사용하고, 이전 파드와 동일한 노드에 스케줄링된다는 조건에서 새로운 파드는 이전 파드가 남긴 모든 항목을 볼 수 있다.
  • 하지만 노드에만 남기 때문에 노드간 공유는 안된다 - 서지혜
  • 볼륨의 콘텐츠는 특정 노드의 파일시스템에 저장되므로 데이터베이스 파드가 다른 노드로 다시 스케줄링되면 더 이상 이전 데이터를 볼 수 없다. hostPath 볼륨은 파드가 어떤 노드에 스케줄링되느냐에 따라 민감하기 때문에 일반적인 파드에 사용하는 것은 좋은 생각이 아니다.
  • 잘 알려진 주의사항 밑줄 - 김준석
• p275
  • 다른 파드를 살펴보면 대부분이 노드의 로그파일이나 kubeconfig, CA인증서를 접근하기 위해 이 유형의 볼륨을 사용한다는 것을 볼 수 있다.
  • 그렇네 - 김준석