Toggle menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

KubernetesINACTION/밑줄긋기: Difference between revisions

From ZeroWiki
imported>rabierre
No edit summary
imported>rabierre
No edit summary
Line 89: Line 89:
** 컨테이너는 자체 리눅스 PID 네임스페이스를 사용하며 고유의 시퀀스 번호를 가지고 완전히 분리된 프로세스 트리를 갖고 있다.
** 컨테이너는 자체 리눅스 PID 네임스페이스를 사용하며 고유의 시퀀스 번호를 가지고 완전히 분리된 프로세스 트리를 갖고 있다.
** 격리된 프로세스를 가진 것과 마찬가지로 각 컨테이너는 격리된 파일시스템을 갖고 있다.
** 격리된 프로세스를 가진 것과 마찬가지로 각 컨테이너는 격리된 파일시스템을 갖고 있다.
=== 2.3 쿠버네티스에 첫 번째 애플리케이션 실행하기 ===
=== 쿠버네티스 클러스터 설치 ===
* 직접 설치해보자 - [[서지혜]]
=== 쿠버네티스에 첫 번째 애플리케이션 실행하기 ===
* p97
* p97
** 쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다. 대신 함꼐 배치된 다수의 컨테이너라는 개념을 사용한다. 이 컨테이너의 그룹의 이름을 파드라고 한다.
** 쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다. 대신 함꼐 배치된 다수의 컨테이너라는 개념을 사용한다. 이 컨테이너의 그룹의 이름을 파드라고 한다.

Revision as of 16:18, 25 July 2021

쿠버네티스 소개

  • p37
  • 몇 년 전만 하더라도 대부분의 소프트웨어 어플리케이션은 하나의 프로세스 또는 몇 개의 서버에분산된 프로세스로 실행되는 거대한 모놀리스(monolith)였다.
    • 쿠베 전에는 통합을 하려는 시도로 Hadoop등이 각광을 받긴했었지. 근데 이것도 모노리스라고해야하나 - 김준석
  • p38
  • 쿠버네티스는 개발자가 운영 팀의 도움 없이도 자신의 애플리케이션을 원하는 만큼 자주 배포할 수 있도록 한다.
  • 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
  • 서비스 디스커버리, 스케일링, 로드밸런싱, 자가 치유, 리더 선출 같은 것들이 포함된다.
  • p62
  • 마스터 노드는 전체 쿠버네이트 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 실행한다. 워커 노드는 실제 배포되는 컨테이너 애플리케이션을 실행한다
    • 마스터-워커 구성은 클러스터 시스템들의 기본 아키텍쳐로구만 - 서지혜
  • p63
  • 저자는 (...) 동작 방식부터 설명하는 방식을 싫어한다.
    • 나는 지금 그게 알고싶은디 - 서지혜
  • p66
  • kube-proxy는 서비스를 제공하는 모든 컨테이너에서 서비스 연결이 로드밸런싱되도록 한다.
    • 네트워크 설정에서 해방이다 만세!! - 김준석
  • p68
  • 인프라에 장애가 발생한 노드가 없어도 정상적인 시스템 작동이 가능하도록 충분한 예비 자원이 있는 경우 운영 팀은 새벽 3시에 일어난 장애에 즉시 대응할 필요가 없다.
    • 동남아가 제발 하드좀 잘 관리해줬으면.. 예비 자원좀 - 김준석


도커와 쿠버네티스 첫걸음

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

  • p73
  • busybox는 echo, ls, gzip 등과 같은 표준 UNIX 명령줄 도구들을 합쳐 놓은 단일 실행파일(executable)이라 할 수 있다.
  • p76
FROM node:7
ADD app.js /app.js

ENTRYPOINT ["node", "app.js"]
  • p79
    • 이미지라는 것이 하나의 큰 바이너리 더어리가 아니라 여러개의 레이어로 구성된다는 것을 아마도 눈치챘을 것이다. 서로 다른 이미지가 여러 개의 레이어를 공유할 수 있기 때문에 이미지의 저장과 전송에 효과적이다.
    • 기본 이미지를 구성하는 모든 레이어는 단 한 번만 저장될 것이다. 또한 이미지를 가져올 때도 도커는 각 레이어를 개별적으로 다운로드 한다. 컴퓨터에 여러개의 레이어가 이미 저장돼 있다면 도커는 저장되지 않은 레이어만 다운로드 한다.
  • p84
    • 컨테이너는 자체 리눅스 PID 네임스페이스를 사용하며 고유의 시퀀스 번호를 가지고 완전히 분리된 프로세스 트리를 갖고 있다.
    • 격리된 프로세스를 가진 것과 마찬가지로 각 컨테이너는 격리된 파일시스템을 갖고 있다.

쿠버네티스 클러스터 설치

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

  • p97
    • 쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다. 대신 함꼐 배치된 다수의 컨테이너라는 개념을 사용한다. 이 컨테이너의 그룹의 이름을 파드라고 한다.
    • 각 파드는 자체 IP, 호스트 이름, 프로세스 등이 있는 논리적으로 분리된 머신이다.
  • p100
    • 외부에서 파드에 접근을 가능하게 하려면 서비스 오브젝트를 통해 노출해야 한다.
    • 파드와 마찬가지로 일반적인 서비스(Cluster IP 서비스)를 생성하면 이것은 클러스터 내부에서만 접근 가능하기 때문에 Load Balancer 유형의 특별한 서비스를 생성해야 한다.
  • p103
    • kubectl run 명령을 수행하면 레플리케이션컨트롤러를 생성하고 레플리케이션컨트롤러가 실제 파드를 생성한다.
    • 띄어쓰기 좀.. - 서지혜
  • p107
    • 서비스는 다수 파드 앞에서 로드밸런서 역할을 한다. 파드가 하나만 있으면 서비스는 이 파드 하나에 정적 주소를 제공한다.