조대협의 블로그

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..

Istio #1마이크로 서비스 아키텍처와 서비스 매쉬조대협 (http://bcho.tistory.com) 마이크로 서비스 아키텍쳐는 여러가지 장점을 가지고 있는 아키텍쳐 스타일이기는 하지만, 많은 단점도 가지고 있다. 마이크로 서비스는 기능을 서비스라는 단위로 잘게 나누다 보니, 전체 시스템이 커질 수 록 서비스가 많아지고, 그로 인해서 서비스간의 연결이 복잡해지고 여러가지 문제를 낳게 된다 출처 : https://www.slideshare.net/BruceWong3/the-case-for-chaos?from_action=save 서비스간의 전체 연결 구조를 파악하기 어려우며 이로 인해서 장애가 났을때, 어느 서비스에서 장애가 났는지 추적이 어려워진다. 또한 특정 서비스의 장애가 다른 서비스에 영향을 주..

쿠버네티스 리소스(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월에 포스팅된 내용을 기반으로 한다. 쿠버네티스는 새버전 릴리즈가 빠른 편이고 버전마다 기능이나 아키텍쳐의..

마이크로 서비스 아키텍쳐와 컨테이너조대협 (http://bcho.tistory.com)모노리틱 아키텍처마이크로 서비스 아키텍쳐를 이해하려면 먼저 이에 상반되는 모노리틱 아키텍쳐를 이해할 필요가 있다. 모노리틱 아키텍쳐는 전통적인 아키텍쳐 스타일로 애플리케이션이 하나의 서버에 배포 되고, 데이타 베이스도 마찬가지로 하나의 데이타 베이스에 모든 데이타를 저장하는 방식이다. 예전에 하나의 큰 서버를 놓고, 그 안에 하나의 애플리케이션으로 개발하는 방식인데, 수퍼돔과 같이 큰 머신을 하나 놓고, 오라클 데이타베이스에 모든 데이타를 저장하고, 애플리케이션 바이너리를 하나로 개발하는 방식이다. 중앙 관리된 구조에서 통제가 편리하고, 같은 솔루션을 사용한다는데 있어서 장점이 있다. 마이크로 서비스 아키텍처마이크로 서..

구글 클라우드 해커톤 세션으로 진행한 강의 내용입니다50분 정도 인데, 짧게 쿠버네티스에 대한 설명과, 마이크로서비스에 대한 설명그리고 쿠버네티스 에코 시스템인 Spinnaker, Istio, KNative 등에 대해서 설명합니다

쿠버네티스 #19보안 4/4 - Pod Security Policy조대협 (http://bcho.tistory.com) SecurityContext가 컨테이너나 Pod의 보안 기능을 정의 하는 것이라면, Pod Security Policy (이하 PSP)는 보안 기능에 대한 정책을 정의 하는 것이다.예를 들어, 정책으로 Pod를 생성할때는 반드시 root 사용자를 사용하지 못하도록 강제한다던지, Privileged 모드를 사용못하도록 강제할 수 있다. 현재는 (2018년9월1일) 베타 상태이기 때문에 다소의 기능 변경이 있을 수 있음을 염두하고 사용하도록 하자. 개념개념이 복잡하기 때문에 먼저 기본적인 개념을 이해한 후에, 각 상세를 살펴보도록 하자. 먼저 아래 그림을 보자 PSP는 생성후에, 사용자에게..

쿠버네티스 #18보안 3/4 - Security Context조대협 (http://bcho.tistory.com)보안 컨택스트보안 컨택스트 (Security context)는 쿠버네티스의 Pod나 컨테이너에 대한 접근 제어 설정(Access Control Setting)이나, 특수 권한 (Privilege)를 설정하는 기능을 제공한다. 단어가 추상적이기 때문에 바로 이해하기 약간 어려울 수 있는데, 몇가지 예를 들어보면, 컨테이너 내에서 동작하는 프로세스의 사용자 ID (UID)나, 그룹 ID (GID)를 설정하거나, 프로세스에 커널에 대한 접근 권한을 부여하는 것과 같은 기능을 수행할 수 있다. 구체적으로 보안 컨택스트가 지원하는 기능은 다음과 같다. 예제와 병행해서 살펴보도록 하자예제에 사용된 코드는..

쿠버네티스 #17보안 2/4 - 네트워크 정책조대협 (http://bcho.tistory.com)네트워크 정책 (Network Policy)쿠버네티스의 보안 기능중의 하나가 네트워크 정책을 정의함으로써 Pod로 부터 들어오거나 나가는 트래픽을 통제할 수 있다. Network Policy라는 기능인데, 일종의 Pod용 방화벽정도의 개념으로 이해하면 된다.특정 IP나 포트로 부터만 트래픽이 들어오게 하거나 반대로, 특정 IP나 포트로만 트래픽을 내보내게할 수 있는 등의 설정이 가능한데, 이 외에도 다음과 같은 방법으로 Pod에 대한 Network Policy를 설정할 수 있다. Ingress 트래픽 컨트롤 정의어디서 들어오는 트래픽을 허용할것인지를 정의하는 방법은 여러가지가 있다. ipBlock CIDR I..

쿠버네티스 #16 보안 1/4 - 사용자 계정 인증 및 권한 인가조대협 (http://bcho.tistory.com) 이번글 부터는 몇회에 걸쳐 쿠버네티스 계쩡 인증,인가, 네트워크등 보안에 관련된 부분을 알아보도록 하겠다.모든 시스템이 그렇듯이, 쿠버네티스 역시 보안이 매우 중요하다. 쿠버네티스는 보안에 관련된 여러가지 기능을 제공하는데, 각각에 대해서 살펴 보도록 하자사용자 인증 및 권한 관리인증과 인가 (Authentication & Authorization)먼저 인증과 인가에 대한 개념에 대해서 이해 하자 인증(Authentication)은 사용자가 누구인지를 식별하는 것이다. 흔히 생각하는 사용자 로그인을 생각하면 된다. 인가는 인증된 사용자가 해당 기능을 실행할 수 있는 권한이 있는지를 체크하..