조대협의 블로그

CRI & OCI 기본적으로 도커 기반의 쿠버네티스는 다음과 같은 구조로 작동을 했었다. Kubelet이 명령을 받으면, Docker runtime을 통해서 컨테이너를 생성하거나 삭제하는 것과 같은 생명 주기를 관리하는 구조를 가지고 있었다. 그런데, Docker 이외에도 여러가지 컨테이너 기술이 나오면서 쿠버네티스에서 이런 다양한 컨테이너 런타임에 대한 지원 요건이 생기기 시작하였고, 다양한 컨테이너 런타임을 지원하기 위해서 그때 마다 Kubelet의 코드를 수정해야 하는 문제가 생겼다. 그래서, kubelet의 코드를 수정하지 않고, 다양한 컨테이너 런타임을 지원하기 위해서, kubelet과 컨테이너 런타임 사이의 인터페이스를 통일화하는 스펙이 등장하였는데, 이것이 CRI (Container Runt..

쿠버네티스 Skaffold에서는 하나의 Configuration에서 Profile을 통하여, 배포 파이프라인을 여러개 만들어서 다른 환경에 배포할 수 있고, 각 환경은 kubernetesContext를 이용해서, 쿠버네티스 클러스터를 고를 수 있다. build: artifacts: - image: gcr.io/k8s-skaffold/skaffold-example deploy: kubectl: manifests: - k8s-pod profiles: - name: profile1 activation: - env: MAGIC_VAR=42 - name: profile2 activation: - env: MAGIC_VAR=1337 - kubeContext: minikube command: dev

쿠버네티스 애플리케이션을 위한 개발환경 설정하기#2 VS Code 조대협 (http://bcho.tistory.com)마이크로소프트 VS Code다음 소개할 도구는 마이크로소프트사의 VS Code 이다. 자바 언어가 아닌 Python,node.js 등의 개발에는 VS Code 가 많이 사용되는 데, 특히 쿠버네티스 관련 플러그인들이 많아서 쿠버네티스 연동에 있어서는 IntelliJ보다 훨씬 좋은 기능을 제공한다. 설치하기VS Code에, 쿠버네티스 개발환경을 설치해보자, 설치전에는 kubectl, docker, skaffold 가 미리 설치되어 있어야 한다. 다음 웹 브라우져에서 이 링크(vscode:extension/GoogleCloudTools.cloudcode)를 실행하면, VS 코드에서 아래와 같..

쿠버네티스 애플리케이션을 위한 개발환경#1 IntelliJ조대협 (http://bcho.tistory.com)일반적인 경우에는 로컬 환경에서 개발하고, 로컬에서 톰캣등을 띄워서 테스트하면 되지만, 만약 부가적으로 레디스나, DB등 복잡한 개발/테스트 환경이 필요한 경우에는 결국에는 컴파일된 애플리케이션을 서버로 올려서 테스트해야 한다. 쿠버네티스를 이용해서 개발된 애플리케이션을 컨테이너로 패키징하는 개발 환경을 꾸미게 되면 개발을 조금 더 효율적으로 할 수 있다. 그렇지만 반대로, 컨테이너로 패키징해서 매번 쿠버네티스 개발용 클러스터에 배포해야 하기 때문에 복잡성이 증대하는 단점이 있다. 아래 그림은 쿠버네티스 기반의 애플리케이션을 개발할는 일반적인 개발 과정이다. 코드 작성이 끝나면, 컴파일을 해야 하..

#26 쿠버네티스 오토 스케일러조대협 (http://bcho.tistory.com) 쿠버네티스에서는 리소스 부족을 처리하기 위해서, 오토 스케일러를 사용할 수 있다.. 쿠버네티스는 용도에 따라 몇가지 다른 오토스케일러를 제공하는데 각각을 살펴보도록 하자Vertical Pod Auto-scaler (VPA)Pod의 Resource(CPU,Memory) 적절 request를 결정하는 다른 방법으로는 Vertical Pod Auto-scaler(VPA)를 사용하는 방법이 있다. 현재 beta 기능인데, 쿠버네티스 1.11 버전 이상에 별도로 추가 설치해야 한다. 참고 : https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscalerVP..

조대협 (http://bcho.tistory.com) 쿠버네티스 스펙은 거의 다 보고 테스트 해봐서 멀티 클라우드와 쿠버네티스 에코 시스템을 살펴보다가 그동안 봐야지 하면서 쟁겨 놓았던 Rancher를 다시한번 볼 기회가 있어서 들여다 보았다. 퍼블릭 클라우드와 온프렘 상의 쿠버네티스의 설치 및 통합 관제를 가능하게 해주는 솔루션인데, 사실 이부분은 구글 클라우드의 Anthos와 개념상으로 겹치는 부분이 있어서 크게 메리트가 있을까 하는 의구심은 있었지만, 주변에 온프렘 설치를 Rancher를 많이 이용한다는 이야기를 들어서 한번 훝어 보았다. 일단 기본 설치는 간단하게 도커 이미지로 설치를 한 후에, 실행을하면 되기 때문에 별다른 설정이나 어려움은 없다. 새로운 클러스터 생성도 메이저 클라우드 3사를 ..

쿠버네티스 고급 스케쥴링#3 리소스 부족 (Resource starving) 관리 조대협 (http://bcho.tistory.com) request와 limit의 개념이 있기 때문에 생기는 문제인데, request 된 양에 따라서 컨테이너를 만들었다고 하더라도, 컨테이너가 운영이되다가 자원이 모자르면 limit 에 정의된 양까지 계속해서 리소스를 요청하게 된다. 컨테이너의 총 Limit의 양이 실제 시스템이 가용한 resource의 양보다 많을 수 있는 경우가 발생한다. 처음 CPU resource가 1 CPU 였는데, limit이 4이면,Pod 가 배포된 후에, 동작하다가 limit 양까지 증가되서 4 CPU가 되어 버릴 수 있다. 이때 node의 물리 CPU가 4 이면, CPU 리소스 부족이 발생할..

쿠버네티스 고급 스케쥴링 기법#2 Affinity조대협 (http://bcho.tistory.com) AffinityTaint가 Pod가 배포되지 못하도록 하는 정책이라면, affinity는 Pod를 특정 Node에 배포되도록 하는 정책이다. affinity는 Node를 기준으로 하는 Node affinity와, 다른 Pod가 배포된 위치(node) 를 기준으로 하는 Pod affinity 두 가지가 있다. Node affinity Node affinity는 Pod가 특정 node로 배포되도록 하는 기능이다. 예전에 label에서 설명했던 node selector 도 node의 label과 pod의 selector label이 매칭되는 node에만 배포하도록 하기 때문에, 사실상 Node affinity..

자연어 처리Word representation조대협 (http://bcho.tistory.com) 머신러닝을 위해서 단어를 수치화 하는 방법을 Word Representation이라고 한다.가장 쉬운 방법으로는 One-hot-encoding을 사용하는 방법이 있지만, 이 방법의 경우에는 단어간의 의미를 수식화할 수 없고, 특히나 단어가 많을 경우에는 단어를 표현하는 벡터(행렬)의 크기가 커지며, 그중에서 하나의 필드만 1로 처리하기 때문에 공간 소모가 심하다. 그래서 분포 가설(Distributed hypothesis)를 기반으로한 방식이 많이 사용되는데, 분포 가설(Distributed hypothesis) 란, 같은 문맥의 단어는 비슷한 의미를 갖는다는 개념으로 두 가지 방식이 많이 사용된다.Coun..

쿠버네티스 고급 스케쥴링 기법#1 스케쥴링과 Taint&Toleration조대협 (http://bcho.tistory.com)쿠버네티스 스케쥴링쿠버네티스에서 Pod 를 생성 요청 했을때, Pod를 적정 node에 배치하는 것을 스케쥴링이라고 한다. Pod를 어느 node에 배치할것인가에 대해서는 생각 보다 많은 고려가 필요하다. 먼저 Pod가 생성하기 위한 충분한 리소스 (CPU와 메모리)가 남아 있어야 하고, 디스크 볼륨을 사용할 경우, attach하고자 하는 디스크 볼륨이 해당 node에서 접근이 가능해야 한다.또한 애플리케이션 특성에 따라서, Pod의 배포에 대해 배려가 필요한 경우도 있다. 예를 들어 MySQL을 HA 모드로 배포하기 위해서 마스터, 슬레이브 노드 각각을 배포하고자 할때, 마스터 ..

쿠버네티스를 위한 CD 툴, Skaffold #2조대협 (http://bcho.tistory.com)Skaffold 설정 파일의 구조Skaffold의 개념과 기본적인 사용법을 이해하였으면, 다음으로 Skaffold 설정 파일에 대해서 알아보도록 하자.Skaffold의 설정 파일은 아래와 같이 크게 두가지가 있다. Pipeline config 우리가 앞에서 살펴본 skaffold.yaml 파일이 파이프라인 설정 파일에 해당한다. 컨테이너 빌드 및 레지트리 등록, 테스트 및 컨테이너 배포 일련의 파이프라인에 대한 행동을 정의한다. Global config ~/.skaffold/config 파일에 저장되어 있는 정보로 skaffold의 기본 설정 정보를 정의한다. 예를 들어 디폴트 도커 레지스트리 경로등을 정..

쿠버네티스용 Continuous Deployment 툴인 Skaffold조대협 (http://bcho.tistory.com)What is skaffold?쿠버네티스 기반에서 개발을 하고 테스트를 하려면 일반적으로 다음과 같은 절차를 거쳐야 한다.소스 코드를 수정한 후, 수정한 코드를 컴파일 한 다음에컴파일한 소스 코드를 포함해서 Dockerfile을 이용해서 컨테이너로 패키징 한후에컨테이너를 레파지토리 새로운 버전 태그를 붙여서 업로드 하고쿠버네티스의 기존 Deployment나 Pod의 yaml 파일에 image 명을 바꾼후kubectl -f apply 를 이용해서 변경된 파일을 반영하고,다음 public IP가 있는 서비스의 경우에는 public IP로 접속하고, 아닌 경우에는 SSH 터널링을 이용해서..

쿠버네티스 패키지 매니저 Helm#2-5 Helm Chart 배포조대협 (http://bcho.tistory.com) Helm 차트를 작성했으면, 다른 사용자들이 사용하기 쉽게 차트를 차트 리포지토리 (Chart repository)에 배포할 수 있다. Helm 파일 패키징파일을 배포하기 위해서는 먼저 차트 파일들을 *.tgz 파일 형태로 패키징해야 하는데, helm package 명령을 사용하면 된다. %helm package [차트 디렉토리] 형태로 사용하면 된다. 앞의 예제인 helloworld 차트를 패키징 하려면 아래와 같은 명령을 사용하면 된다.%helm package ./helloworldSuccessfully packaged chart and saved it to: /home/terrych..

쿠버네티스 패키지 매니저 Helm #2-4 Helm Chart Hook 조대협 (http://bcho.tistory.com) Hook은 차트 설치나, 삭제와 같이 차트의 라이프 사이클 중에, 차크 개발자가 동작을 추가해줄 수 있도록 해주는 기능이다. mySQL을 차트로 설치한 후에, mySQL에 테이블을 생성하고 데이타를 로딩하거나, 차트로 Pod를 설치하기전에 Configmap이나 Secret 의 값을 세팅해놓는 것과 같은 작업을 예를 들 수 있다. 등을 들 수 있다. Hook 으로 실행되는 리소스는 따로 있는 것이 아니라, 기존의 쿠버네티스 리소스 (Job, Cron Job 등)에 metadata.annotations.”helm.sh/hook” 으로 태그를 달아주면, 이 리소스들은 Hook으로 정의되..

쿠버네티스 패키지 매니저 Helm #2-3. Charts (디렉토리 구조)조대협 (http://bcho.tistory.com)디렉토리 구조Helm 차트의 디렉토리 구조는 다음과 같다. 직접 아래와 같은 디렉토리 구조에 파일을 각각 생성해도 되지만, 기본 템플릿을 helm create [차트명] 으로 생성할 수 있다.아래는 %helm create mychart 명령으로 생성한 디렉토리의 구조이다. mychart/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.md # OPTIONAL: A hum..

쿠버네티스 패키지 매니저 HELM #2-2. Chart 버전과 릴리즈 조대협 (http://bcho.tistory.com)업그레이드와 롤백Chart로 의해서 설치된 리소스들을 쿠버네티스에서 릴리즈라고 한다.예를 들어 같은 차트로 MySQL을 쿠버네티스 클러스터 내에 여러번 설치 할 수 있다. 각각 설치된 MySQL들을 릴리즈라고 하고, 릴리즈에 설정이 변경된 경우에, 차트를 수정해서 변경을 반영할 수 있다. 변경이 반영될때 마다 새로운 버전이 생성된다. 처음 helm install로 설치를 할때 --name 옵션으로 저장한 설치 이름이 릴리즈 명이 되고, 이 릴리즈를 업데이트 하고 싶으면 helm upgrade {Helm 릴리즈명} {차트 디렉토리} 를 실행하면, 해당 릴리즈를 업데이트하고, 새로운 버전..

쿠버네티스 패키지 매니저 HELM#2-1 .Chart조대협 http://bcho.tistory.comHelm Chart차트는 helm의 패키지 포맷으로, 하나의 애플리케이션을 설치하기 위한 파일들로 구성되어 있다. 예를 들어 tomcat을 설치하기 위한 쿠버네티스의 pod,service,deployment를 위한 YAML 파일등을 포함한다.템플릿과 밸류Helm 은 기본적으로 템플릿의 개념을 사용한다. 템플릿 파일을 만들어놓은 후에, 밸류 값을 채워 넣어서 쿠버네티스 리소스를 정의한 YAML 파일을 생성한다. 예제를 살펴보자Helm 은 기본적으로 템플릿의 개념을 사용한다. 템플릿 파일을 만들어놓은 후에, 밸류 값을 채워 넣어서 쿠버네티스 리소스를 정의한 YAML 파일을 생성한다. 예제를 살펴보자. 먼저 t..

2019년 6월 2일 700만 돌파 (6개월)2018년12월 10일 600만 돌파 (7개월)2018년 5월 10일 500만 돌파 (10개월)2017년 7월17일 405만 돌파 2016년10월20일300만 돌파2015년12월16일200만 돌파

쿠버네티스 패키지 매니저 HELMHelm의 일반적인 개념Helm은 리눅스의 apt 툴이나, node.js의 npm과 같은 쿠버네티스용 패키지 매니지먼트 도구 이다. 일반적으로 하나의 소프트웨어를 쿠버네티스에 배포하려면, 간단하게 컨테이너만을 배포해서는 사용하기 어려운 경우가 많다. 외부로 IP를 노출 시키기 위해서 쿠버네티스 서비스를 배포해야 하고,쿠버네티스 pod를 관리할 deployment가 필요하며, 디스크 볼륨과 기타 정책등 부가 적인 부분을 추가로 배포해야 한다. 이미 네트워크나 디스크 설정이 완료된 상태에서 애플리케이션을 업데이트 하는 경우에는 쿠버네티스 deployment나 다른 배포 도구를 이용해도 되지만, 처음부터 모든 것을 설치해야 하는 반복적인 작업이 있는 경우에는 배포 도구로 불가능..

참고 문서 : 구글 머신러닝 크래쉬 코스 피처 엔지니어링 #1 - 피처 크로스 조대협 (http://bcho.tistory.com) 일반적인 선형 모델의 경우에 선을 그어서 문제를 해결할 수 있다. 아래 그림과 같은 데이타 분포의 경우에는 파란선과 붉은선 사이에 선을 그으면 문제가 해결된다. 그러나 아래와 같은 데이타 모델의 경우에는 선을 하나 그어서 해결할 수 가 없다. (선형 모델의 경우에) 세로축을 x1, 가로축을 x2라고 할때, y = w1x1 + w2x2 + w3(x1x2) +b 로 세번째 피쳐를 앞의 두 피쳐를 곱한 값을 이용하게 되면, 문제를 해결할 수 있다. 즉 x1이 양수이고 x2가 양수이면 양수가 되고 , x2가 음수이면 x1*x2는 양수가 된다. 즉 파란색 점이 위치한 부분은 모두 양..

SRE #6-운영에서 반복적인 노가다 Toil조대협 (http://bcho.tistory.com)ToilToil의 사전적인 뜻은 “노역"이라는 뜻을 가지고 있는데, 비속어를 사용해서 표현하자면 운영 업무에서의 “노가다" 정도로 이해하면 된다. Toil 에 대한 정의를 잘 이해해야 하는데, Toil은 일종의 반복적인 쓸모없는 작업 정도로 정의할 수 있다.경비 처리나, 회의, 주간 업무 보고서 작성과 같은 어드민 작업은 Toil에 해당하지 않는다. Toil은 운영상에 발생하는 반복적인 메뉴얼 작업인데, 다음과 같은 몇가지 특징으로 정의할 수 있다.메뉴얼 작업이고 반복적이어야함Toil의 가장 큰 특징은 사람이 직접 수행하는 메뉴얼 작업이라는 것이다. 그리고 어쩌다 한번이 아니라 지속적으로 발생하는 반복적인 작..

SRE #5 - Error budget 조대협 (http://bcho.tistory.com) SLI와 SLO에 대한 개념을 이해 했으면 다음은 Error budget에 대한 개념을 이해해야 한다.Error budget은 단순하게 생각하면Error budget = [100% - availability target] 와 같다. 예를 들어 설명하면, 한달에 SLO가 99.999%를 목표치로 설정했다면, 한달간 SLO는 0.001%의 다운 타임을 허용하게되고, 이 0.001%가 Error budget이된다. 위의 표는 가용성에 따라서, 허용되는 장애 시간을 정리해놓은 표이다.앞의 예제에서 99.999% 가용률을 목표로 봤을 때 허용되는 장애시간은, 0.001%로 다운 타임은 한달에 25.9 초만 허용된다. 그러..

Azure Devops 조대협 (http://bcho.tistory.com) 페이스북 타임라인을 보다가. “Azure Devop가 나왔는데. JIRA 따위는 꺼져버려.." 라는 말이 있어서 몬가 궁금해서 살펴봤는데 이거 정말 물건이다. MS가 요즘 많이 변하하고 있다고 들었는데, 정말 잘 만든 제품인듯 Devops라고 해서 Monitoring,Logging쪽 제품으로 생각했는데, Task management, 부하 테스트, git repo & 빌드, 빌드 파이프라인, 웹테스트 툴 등이 들어있는데, 전반적으로 정말 좋은듯. 예전 IBM의 Jazz 플랫폼과 컨셉은 비슷한데, UI나 기능이나 반응 속도나 압권이고 거기다가 일부 플랜은 무료다!! 나 같은 개인 개발자(집에서는)에게는 딱이 아닐까 싶다. 대충 후..

2019년 샌프란시스코 구글 NEXT 2019에서 발표한 로깅 시스템에 대한 강의 입니다.구글 스택 드라이버 로깅에 대한 소개와, 삼성전자가 어떻게 스택 드라이버 툴을 이용해서 Devops로 적응했는지에 대한 사례입니다.영어 컨텐츠 입니다.

SRE #4-예제로 살펴보는 SLI/SLO 정의 방법조대협 (http://bcho.tistory.com) 앞에서 SRE의 주요 지표인 SLO/SLI의 개념에 대해서 설명하였는데, 그러면 실제 서비스에서는 어떻게 SLO/SLI를 정의하는지에 대해서 알아본다.SLI는 사용자 스토리당 3~5개 정도가 적당하다. 사용자 스토리는 로그인, 검색, 상품 상세 정보와 같이 하나의 기능을 의미한다고 보면된다. 아래 그림과 같은 간단한 게임 서비스가 있다고 가정하자. 이 서비스는 웹사이트를 가지고 있고, 그리고 앱을 통해서 접근이 가능한데, 내부적으로 API 서비스를 통해서 서비스가 된다. 내부 서비스에는 사용자 랭킹(Rank ), 사용자 프로파일 (User profiles) 등의 서비스가 있다. 이 서비스에서 "사용자..

SRE #3-SRE 주요 지표 (SLI/SLO)조대협 (http://bcho.tistory.com) 이글은 앞글 (https://bcho.tistory.com/1327)과 연결 됩니다.앞에 까지 SRE가 무엇이고, SRE가 하는일은 무엇이며, 어떻게 그 일을 수행 하는지에 대해서 알아보았다. SRE 프랙티스 에서는 의사 결정을 데이터에(data based decision) 따라 하기 때문에, 데이타 즉 지표를 정의하는 것이 중요하다. 그러면 SRE 에서는 어떻게 지표를 정의하고 활용하는지에 대해서 알아본다. SLI (Service Level Indicator)SLI는 서비스에 대한 수준을 측정하여, 정량적으로 정의한 지표이다. "REST API의 응답시간 = 300ms"와 같이 절대 값을 사용하기도 하지..

SRE는 어떻게 일하는가? 조대협 (http://bcho.tistory.com) 이글은 앞의 글 "SRE/DEOPS의 개념과 SRE는 무엇을 하는가?" (https://bcho.tistory.com/1325) 와 연결된 글입니다.How SRE does Devops?그럼 SRE들은 이런한 일들을 어떤 방법으로 수행할까? 앞에서 SRE가 해야 하는 일에 대해서 설명하면서 각각에 대해서 일부를 언급했지만, 다시 SRE가 해야하는 일을 하기 위해서는 어떻게(How) 해야 하는지에 대해서 다시 정리해보자.SRE는 앞에서 언급한 다섯가지 일을 하기 위해서 아래와 같이 다섯 가지 방법을 사용한다. (참고 : 구글 NEXT 발표자료 https://drive.google.com/file/d/1iOMaYIwlUBiGoG2..

AutoEncoder vs Variant AutoEncoder 조대협 (http://bcho.tistory.com) AbnormalAutoEncoder는 입력값을 기반으로 여기서 특징을 뽑아내고, 뽑아낸 특징으로 다시 원본을 재생하는 네트워크이다. 이미지 합성이나 압축, Abnormal Detection 등 여러 유스케이스에 사용이 될 수 있지만, 특히 추출된 특징 (latent coding)은 데이타의 특징을 이해하는데도 유용하게 사용될 수 있다. 이 글에서는 AutoEncoder와 요금 각광 받는 VAE (Variant Auto Encoder) 의 차이를 알아보고 특히 latent coding의 값이 어떻게 다르게 표현되며, 어떤 의미를 가지는지에 대해서 이해한다. 일반 오토 인코더의 모양은 다음과 ..

Site Reliability Engineering(SRE)#1 SRE/DEVOPS의 개념조대협 (http://bcho.tistory.com)배경Devops는 운영팀과 개발팀을 하나의 팀으로 묶어놓고 전체적인 개발 사이클을 빠르게 하고자 하는 조직 구조이자 문화이다. 이 Devops라는 컨셉이 소개된지는 오래되었지만, Devops의 개념 자체는 명확하지만 이 Devops를 어떻게 실전에 적용할것인 가는 여전히 어려운 문제였다.(예전에 정리한 Devops에 대한 개념들 1 , 2) 예전 직장들에 있을때 Devops의 개념이 소개되었고 좋은 개념이라는 것은 이해하고 있었지만, 여전히 운영팀은 필요하였고, 그 역할이 크게 바뀌지 않았다. 심지어 Devops를 하는 기업들도 보면 기존 개발팀/운영팀이 있는데, ..

SRE는 구글의 Devops의 프랙티스 로 구글의 서비스에 대한 배경과 철학을 읽을 수 있다.SRE의 기본 사상중의 하나는 서비스의 안정성이 완벽할 수 없으며, (아니 완벽하지 않게 만들며) 장애를 허용하는 모델이다.고 가용/고 성능 시스템을 만들기 위해서는 그만큼 많은 개발에 대한 노력이 소요되는데, 이로 인해서 기능 개발에 대한 속도가 느려지기 때문에, 사용자가 납득할만한 수준의 가용성을 제공하되 개발의 속도를 유지하는 철학이다.배경을 살펴보면 구글은 모바일을 기반으로 한 B2C 서비스를 주력으로 하기 때문에, 서비스가 99.999%의 가용성을 제공하더라도, 스마트폰과 통신망 자체가 그정도의 안정성을 제공하지 않기 때문에, 백앤드 서비스가 높은 가용성을 제공하더라도 사용자가 느끼는 가용성은 그 정도 ..