조대협의 블로그

[팁] 쿠버네티스 StatefulSet에서 Headless 서비스를 이용한 Pod discovery 조대협 (http://bcho.tistory.com) statefulset에서 데이타베이스와 같이 master,slave 구조가 있는 서비스들의 경우에는 service를 통해서 로드밸런싱을 하지 않고, service 를 통해서 로드 밸런싱을 하는 것을 잘 사용하지 않고 개별 pod의 주소를 알고 접속해야 한다. 그래서 개별 Pod의 dns 이름이나 주소를 알아야 한다. Pod들은 DNS이름을 가질 수 는 있으나, {pod name}.{service name}.{name space}.svc.cluster.local 식으로 이름을 가지기 때문에, pod 를 DNS를 이용해서 접근하려면 service name이..

minikube에서 서비스 테스트 하기미니쿠베를 로컬환경에 설치하고 쿠버네티스 서비스를 로드 밸런서 타입으로 배포하면, External IP할당이 되지 않는다. 그래서 아래 그림과 같이 External-IP가 계속 으로 보이게 된다. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 443/TCP 7d2hmy-service LoadBalancer 10.105.173.146 8080:31203/TCP 4m10s 그러면 미니쿠베에서 서비스를 테스트하려면 어떻게 해야 할까? 미니쿠베는 서비스를 테스트하기 위해서 service라는 명령을 제공한다. 아래 그림과 같이 minikube service {쿠버네티스 서비스명} 을 입력하..

StatefulSet을 이용하여 상태가 유지되는 Pod 관리하기조대협 (http://bcho.tistory.com)ReplicaSet으로 Stateful Pod 관리하기 앞에서 쿠버네티스의 Pod를 관리하기 위한 여러가지 컨트롤러 (Replica Set, ReplicationController,Job 등)에 대해서 알아보았다.이런 컨트롤러들은 상태가 유지되지 않는 애플리케이션(Stateless application)을 관리하기 위해 사용된다. Pod가 수시로 리스타트되어도 되고, Pod 내의 디스크 내용이 리스타트되어 유실되는 경우라도 문제가 없는 워크로드 형태이다. 웹서버나 웹애플리케이션 서버 (WAS)등이 그에 해당한다. 그러나 RDBMS나 NoSQL과 같은 분산 데이타 베이스등과 같이 디스크에 데이..

PodDisruptionBudget조대협 (http://bcho.tistory.com) Pod의 개수는 컨트롤러가 붙어 있을 경우에는 컨트롤러 스펙에 정의된 replica 수 만큼을 항상 유지 하도록 되어 있다. Pod의 수가 replica의 수를 유지 하지 못하고 줄어드는 경우가 있는데, 애플리케이션이 크래쉬 나거나, VM이 다운되는 등의 예상하지 못한 사고로 인한 경우가 있고, 또는 시스템 관리자가 업그레이드등의 이슈로 노드를 인위적으로 다운 시키는 것과 같이 예상 가능한 상황이 있다. 예상 가능한 상황에서 Pod가 없어지는 것을 Voluntary disruptions 라고 하고, 커널 패닉이나 VM 크래쉬같은 예기치 못한 상황에서 Pod가 없어지는 것을 Involuntary disruptions 라..

Istio #4 - 설치 및 BookInfo 예제조대협 (http://bcho.tistory.com)Istio 설치그러면 직접 Istio 를 설치해보자, 설치 환경은 구글 클라우드의 쿠버네티스 환경을 사용한다. (쿠버네티스는 오픈소스이고, 대부분의 클라우드에서 지원하기 때문에 설치 방법은 크게 다르지 않다.)쿠버네티스 클러스터 생성콘솔에서 아래 그림과 같이 istio 라는 이름으로 쿠버네티스 클러스터를 생성한다. 테스트용이기 때문에, 한존에 클러스터를 생성하고, 전체 노드는 3개 각 노드는 4 CPU/15G 메모리로 생성하였다. 다음 작업은 구글 클라우드 콘솔에서 Cloud Shell내에서 진행한다.커맨드 라인에서 작업을 할것이기 때문에, gCloud SDK를 설치(https://cloud.google...

Istio #2 - Envoy Proxy 조대협 (http://bcho.tistory.com) 그럼 앞에서 설명한 서비스 매쉬의 구조를 구현한 Istio를 살펴보기전에, Istio에 사용되는 envoy 프록시에 대해서 먼저 알아보자. (이 글은 예전에 포스팅한 내용이지만, Istio 글의 흐름상 다시 포스팅 한다.) Envoy Proxy 먼저 istio에 사용되는 envory proxy를 살펴보자. Envoy 프록시는 Lyft사에서 개발되었으면 오픈소스로 공개되었다. 기존 프록시 L4기능 뿐 아니라 L7 기능도 지원하면서 HTTP 뿐아니라 HTTP 2.0,TCP,gRPC까지 다양한 프로토콜을 지원한다. 성능 지표를 보면 아래 Twillo에서 2017년에 테스트 한 자료를 참고할만 한데, (원본 https..

EAI, ESB, API 게이트 웨이,서비스 매쉬조대협 (http://bcho.tistory.com) 서비스간의 연동은 작게 보면 마이크로 서비스 아키텍쳐로 인한 문제 같지만, 서비스간의 연동은 마이크로 서비스 아키텍쳐 이전에도 자주 있어왔던 전통적인 문제이다. 이러한 문제를 소프트웨어 개발 프레임웍이 아니라, 솔루션 차원에서 풀기 위한 여러가지 노력들이 있었다. 시스템 통합 문제메인 프레임 시대에서 유닉스 시스템으로 내려오면서 부터 시스템들은 업무 단위로 분리가 되기 시작했다. ERP,CRM 등과 같은 시스템으로, 은행은 대내,대외,정보계와 같이 시스템으로 잘게 잘게 나눠지기 시작했는데, 당연히 이렇게 나눠진 시스템 사이에는 통신이 필요하게 되었고, 시스템이 거대화 되가면서, 시스템간에 직접 P2P로 ..

쿠버네티스 리소스(CPU/Memory)할당과 관리조대협 리소스 관리 쿠버네티스에서 Pod를 어느 노드에 배포할지를 결정하는 것을 스케쥴링이라고 한다.Pod에 대한 스케쥴링시에, Pod내의 애플리케이션이 동작할 수 있는 충분한 자원 (CPU,메모리 등)이 확보되어야 한다. 쿠버네티스 입장에서는 애플리케이션에서 필요한 자원의 양을 알아야, 그 만한 자원이 가용한 노드에 Pod를 배포할 수 있다. 쿠버네티스에서는 이런 컨셉을 지원하기 위해서 컨테이너에 필요한 리소스의 양을 명시할 수 있도록 지원하고 있다. 현재(1.9 버전) 지원되는 리소스 타입은 CPU와 메모리이며, 아직 까지는 네트워크 대역폭이나 다른 리소스 타입은 지원하고 있지 않다.리소스 단위리소스를 정의하는데 사용되는 단위는 CPU의 경우에는 ms(..

쿠버네티스 보안 Best Practice 조대협 (http://bcho.tistory.com) 지금까지 여러가지 보안 기능에 대해서 알아보았다. 그러면 이러한 보안 기능을 어떻게 잘 사용할지 베스프 프렉틱스에 대해서 알아보자. 쿠버네티스 보안 베스트 프렉틱스는 쿠버네티스 공식 블로그 https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/ 에 2016년 8월에 포스팅과 https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/ 에 2018년 7월에 포스팅된 내용을 기반으로 한다. 쿠버네티스는 새버전 릴리즈가 빠른 편이고 버전마다 기능이나 아키텍쳐의..

아두이노 nodemcu로 온습도계를 만들어 보자 조대협 (http://bcho.tistory.com) nodeMCU 개발환경 설정이 끝났으면 간단한 애플리케이션을 하나 만들어보자온습도계를 만들어보도록 한다. 온습도를 측정하여 LED로 출력하는 모듈을 개발해보겠다.개발이 끝나고 나서 아두이노 개발환경에 대한 결론 부터 이야기 하자면, 쉽다. 대부분의 파츠들에 대한 SDK가 제공되기 때문에 손쉽게 개발이 가능하다. 단 해당 파츠에 맞는 SDK를 찾는데 들억는 시간이 더 많다.온습도계 센서 (DTH11)개발에 사용할 온습도계 센서는 DTH11이라는 센서이다. 아래와 같이 생겼는데, 좌측이 데이타, 가운데가 3.3V, 가장 우측이 GND이다. 온도와 습도 두개를 측정하는데 데이타 단자가 하나이다. 아날로그 신호..