Skip to main content

24 posts tagged with "Kubernetes"

View All Tags

· 13 min read

이번에는 경량 Kubernetes라고 이야기하는 K3s를 Raspberry Pi 클러스터상에 구동하려고 한다. 순수하게 개인의견으로 작성하였고 절대 제품이나 부품홍보를 하고자 하는 의도는 전혀 없다.

K3s?

K3s는 Rancher Lab에서 최소자원을 사용하는 Kubernetes 클러스터 구성을 위한 솔루션으로 시작되었고 2019년 3월 12일 현재 0.2버전이 릴리즈된 상태이다. 바이너리 전체가 40mb가 되지 않고 설치가 쉽다는 점에서 최근 트위터 상에서 이슈가 되고 있는 프로젝트라고 할 수 있다.

주로 Edge, IoT 등 저전력, 저사양 기반 ARM계열 컴퓨팅에 최적화 되어 있고 실제 실험적이긴 하지만 간단한 기능이나 baremetal 기반 클러스터 테스트를 집에서 해보기에는 딱 좋은 프로젝트라 할 수 있다. 이미 vSphere, OpenStack기반으로 테스트는 차고 넘치게 해봤지만 일단 물리적인 케이스부터 보고나면 하드웨어를 좋아하는 사람들에게는 아주 재미있는 장난감이 아닐수 없을 것이다.

K3s Github 상세 설명에 보면 Cloud Provider, Storage Plugin은 제거하였고 default 저장소가 etcd가 아닌 sqlite3으로 되어있다고 한다.

사전 준비사항

  • 최소 2개 이상의 Raspberry Pi 2B/3B/3B+, 4ea
    오픈마켓에서 할인쿠폰 적용해서 Raspberry Pi 3B+, 4ea를 166,820원(대당 42,000원) 정도에 구매하였다.
    최저가 검색으로 대당 46,000원 정도 했던것 같다.

  • Stackable Case
    iUniker Raspberry Pi Cluster Case 강추!! (개인적으로 쿨러와 디자인이 맘에 듬)
    배송비포함 29.19달러, 약 33,000원

  • micro SDHC 4ea
    16GB로도 충분하지만 삼성전자 micro SDHC CLASS10 UHS-I EVO (32GB), 4ea를 오픈마켓에서 사게되면 배송료 포함해서 8,500원 * 4ea = 34,000원에 구매가 가능하다. 오픈마켓에서는 개당 배송료를 내야한다. 하지만 쿠팡에서는 2ea를 로켓배송으로 15,380원에 구매가 가능하므로 약 31,000원에 4개를 구매할수 있다.

  • 멀티충전기
    1만원대 후반에서 2만원 초반이면 6포트 충전기를 구매할수 있는데 구매했던 가장 큰 기준은 Pi 4대를 동시에 2.5A 전류를 안정적으로 공급하려면 최대 10A를 지원하는 멀티 충전기를 사야했었고 4-5포트 짜리 충전기들은 대부분 최대 전류가 8A로 충족하지 못해 4포트만 사용하더라도 안정적인 전류 공급을 위해 6포트 충전기로 선택하였다.
    쿠팡 로켓배송 - 포*지 가정용 6포트 급속 멀티 충전기, 22,900원

  • micro 5pin 20cm 2.4A 지원 케이블 4ea
    Pi 권장 전류가 2.5A라고 했지만 2.4A, 3A 짜리중에 저렴한 2.4A 지원 숏케이블로 구매하였다.
    오픈마켓에서 배송료 포함, 7800원

  • UTP Cat5e 30cm 케이블 4ea
    그냥 제일싼걸로 오픈마켓에서 배송료 포함 4,100원에 구매하였다.

  • 기가비트 지원되는 5포트 이상 스위치 허브(공유기)
    집에 있던 공유기 활용 (iptime A1004) 하였지만 최저 5포트 이상 스위치 허브중 제일 싼 모델은 16,000원대로 가격 형성중이다.

실제 위 스펙으로 대충 구매를 진행하게 되면 18.4 + 3.3 + 3.1 + 2.3 + 0.8 + 0.4 + 1.6 = 29.9만원 정도 소요가 될 것으로 예상된다. 집에 굴러다는 부품이나 충전기, 케이블, SD카드들을 활용하면 25만원 이내로도 충분히 가능하다.

구매 제품 조립

조립은 그다지 어렵지 않은데 케이스 구매시 제공되는 방열판(CPU, GPU, RAM)을 꼼꼼하게 붙이고 쿨러를 GPIO에 연결한다.
그렇게 어려운 점은 없지만 본체를 케이스에 고정할때 너트가 작아 손이 큰 사람은 조금 힘들 수도 있을 것 같다.

케이스의 CPU 쿨러가 화룡점정이다.

cases
heat
cooler 3stack charger full complete

OS 설치

SD카드에 설치는 MacOS상에서 진행하였다.

Raspbian Lite를 내려받아 Etcher를 사용하여 OS를 설치한다.

자세한 추가적인 설치방법은 다음 링크를 통해서도 확인이 가능하다.
Installing operating system images

환경 설정

Mac에서는 /Volumes/boot에 마운트가 된다. OS마다 다르지만 Linux에서는 /mnt/boot, Windows에서는 boot 로 마운트가 된다.

SSH Service 자동 활성화를 위해 위 OS별 mount된 root 경로에 ssh 빈 파일을 생성하게 되면 reboot이후에 SSH 접속이 가능해진다.

$ sudo touch /Volumes/boot/ssh

또한 container 사용을 위해 root경로의 cmdline.txt 파일 마지막에 cgroup 설정을 추가한다.

cgroup_memory=1 cgroup_enable=memory

SD카드를 만들고 각각의 Pi에 장착후에 UTP케이블과 전원을 모두 연결한다. 부팅이 완료되면 default id/pass 인 pi/raspberry로 로그인 하고 sudo raspi-config 를 통해 패스워드 변경, hostname 설정, GPU memory split 설정 등을 완료하자.
나중에는 PXE booting 및 ansible 자동화로 구현하면 무인환경 설치가 가능할것 같다. (Edge Computing)

┌───────────────────┤ Raspberry Pi Software Configuration Tool (raspi-config) ├────────────────────┐
│ │
│ 1 Change User Password Change password for the current user │
│ 2 Network Options Configure network settings │
│ 3 Boot Options Configure options for start-up │
│ 4 Localisation Options Set up language and regional settings to match your location │
│ 5 Interfacing Options Configure connections to peripherals │
│ 6 Overclock Configure overclocking for your Pi │
│ 7 Advanced Options Configure advanced settings │
│ 8 Update Update this tool to the latest version │
│ 9 About raspi-config Information about this configuration tool │
│ │
│ │
│ │
│ <Select> <Finish> │
│ │
└──────────────────────────────────────────────────────────────────────────────────────────────────┘
  • 1 Change User Password
  • 2 Network Options - hostname
    • k3s-master, k3s-slave-01, k3s-slave-02, k3s-slave-03
  • 4 Localisation Options - TimeZone
    • Asia, Seoul
  • 7 Advanced Options - GPU Memory split
    • 16mb

모두 완료가 되었으면 pi들을 재기동하자.

$ sudo reboot

k3s 클러스터 생성

Server 기동

armhf(arm hard float) 지원이 되는 최신 릴리즈 v0.2.0를 다운받는다.

$ wget -O k3s https://github.com/rancher/k3s/releases/download/v0.2.0/k3s-armhf && \
chmod +x k3s && \
sudo mv k3s /usr/local/bin/k3s

Master node 기동 (백그라운드)

$ sudo k3s server &

해당 node를 Control plane 형태로 분리시켜 workload에서 제외하려면 --disable-agent 옵션을 사용한다.

& k3s server --disable-agent

정상적으로 k3s 기동이 완료되면 /etc/rancher/k3s/k3s.yaml에서 Kubeconfig를 확인할수 있다. 그리고 node 상태도 확인이 가능하다.

$ sudo k3s kubectl get nodes
NAME STATUS ROLES AGE VERSION
k3s-master Ready <none> 21h v1.13.4-k3s.1

node 추가

/var/lib/rancher/k3s/server/manifests 에서 TOKEN을 확인한다.

$ sudo cat /var/lib/rancher/k3s/server/node-token
K100fa5235031f2b8e92e01b8bd3255142422a7aeaa47657ad4c68969d35cddbf3a::node:431342ac6204466e8f81445edb8c2e3a

worker node에 접속한다음 동일하게 최신 릴리즈 v0.2.0를 다운받는다.

$ wget -O k3s https://github.com/rancher/k3s/releases/download/v0.2.0/k3s-armhf && \
chmod +x k3s && \
sudo mv k3s /usr/local/bin/k3s

위에서 나온 TOKEN값과 Kube API Endpoint정보로 node들을 차례로 추가 시키면 모든 작업이 완료된다.

$ export NODE_TOKEN="K100fa5235031f2b8e92e01b8bd3255142422a7aeaa47657ad4c68969d35cddbf3a::node:431342ac6204466e8f81445edb8c2e3a"
$ export MASTER_IP="https://192.168.0.14:6443"
$ sudo k3s agent --server https://${MASTER_IP}:6443 --token ${NODE_TOKEN} &

완성된 클러스터를 확인한다. 외부 로컬에서 확인하려면 /etc/rancher/k3s/k3s.yaml 파일을 ~/.kube/config에 추가하면 된다. 클러스터 내부에서 kubectl 명령은 k3s 바이너리 내부에 포함되어 있으므로 sudo k3s kubectl 명령을 사용하였다.

$ sudo k3s kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k3s-master Ready <none> 22h v1.13.4-k3s.1 192.168.1.14 <none> Raspbian GNU/Linux 9 (stretch) 4.14.79-v7+ containerd://1.2.4+unknown
k3s-slave01 Ready <none> 21h v1.13.4-k3s.1 192.168.1.15 <none> Raspbian GNU/Linux 9 (stretch) 4.14.79-v7+ containerd://1.2.4+unknown
k3s-slave02 Ready <none> 10h v1.13.4-k3s.1 192.168.1.16 <none> Raspbian GNU/Linux 9 (stretch) 4.14.79-v7+ containerd://1.2.4+unknown
k3s-slave03 Ready <none> 10h v1.13.4-k3s.1 192.168.1.17 <none> Raspbian GNU/Linux 9 (stretch) 4.14.79-v7+ containerd://1.2.4+unknown

node 상세정보를 보면 기본적으로 K8s v1.13.4, runtime은 containerd를 사용하고 있음을 알 수 있다.

$ sudo k3s kubectl get svc --all-namespaces
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 21h
kube-system kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP,9153/TCP 21h
kube-system traefik LoadBalancer 10.43.19.160 192.168.1.14,192.168.1.15 80:32304/TCP,443:31690/TCP 21h

Rancher쪽에서도 오늘날짜(3/12)로 F5가 Nginx를 인수하는것을 예견했던 것일까?
Service를 확인하면 traefik이 기본으로 되어있다. 아래처럼 기본적으로 loadbalancer로 활용되고 있는 traefik을 Helm Chart CRD를 통해 배포된것을 확인할 수 있다. 또한 얼마전 졸업한 CoreDNS도 보인다.

$ sudo k3s kubectl get pod --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-7748f7f6df-qflx9 1/1 Running 0 21h
kube-system helm-install-traefik-dqqg9 0/1 Completed 0 21h
kube-system svclb-traefik-598fd65c97-4xtkf 2/2 Running 0 21h
kube-system svclb-traefik-598fd65c97-vbsqv 2/2 Running 0 19h
kube-system traefik-6876857645-2sqg9 1/1 Running 0 21h

$ sudo k3s kubectl get crd
NAME CREATED AT
addons.k3s.cattle.io 2019-03-11T16:46:22Z
helmcharts.k3s.cattle.io 2019-03-11T16:46:22Z
listenerconfigs.k3s.cattle.io 2019-03-11T16:46:22Z

정리

아주 적은비용(?)으로 취미삼아 k3s 클러스터를 구성해봤다.
아직 ARM계열에서 kubernetes workload를 구동하는 것은 시기상조이긴 하지만 기존에 kubeadm을 가지고 pi에 배포하는것에 비하면 설치 난이도나 자원사용량 측면에서 장점이 많은 프로젝트이다.
해외 블로그나 트위터를 보면 최근 k3s에 대한 관심도가 높아지는것을 확인할 수 있는데 단순히 취미생활만이 아니라 IoT, Edge에서의 Serverless Workload 수행이라던지 ARM 계열 최적화된 모습만으로도 충분히 가능성은 보여준것 같다.
Rancher 2.0 이후로 Kubernetes 연관된 관심도가 떨어졌었는데 엔지니어들의 관심을 끄는데는 성공한듯 하고 AWS의 Greengrass, Firecracker와 동일선상에서 봐도 견줄만한 가치가 있다고 생각된다.

· 14 min read

https://github.com/GoogleCloudPlatform/microservices-demo에서 소개된 Demo Application인 Hipster Shop을 Kubernetes 기반으로 배포하고 관련 오픈소스들을 더 알아보고자 한다.

위 링크에 가서 보면 알수 있지만 Hipster Shop 아래 그림처럼 10개의 Microservice로 구성되어 있고 상품을 검색 및 구매할 수있는 웹 기반 이커머스 Application으로 구성 되어있다.

arch

각각의 서비스는 gRPC 로 통신하고 외부 사용자만 HTTP로 접근한다. 모든 서비스는 서로 다른 언어(Go, C#, Node.js, Python, Java)로 구성되어 있고 대부분의 Microservice들은 Istio service mesh 형태로 구성할수 있도록 되어있다. Skaffold를 통해 배포하고 OpenCensus라고 하는 gRPC/HTTP기반 Tracing tool을 활용하여 Google Stackdriver로 보내도록 되어있지만 Prometheus에 통합하는 방향으로 작성하기 위해서 Prometheus 기반으로 Metric을 수집하는 Fork된 데모 Application을 검색을 통해 찾을수 있었다.
https://github.com/census-ecosystem/opencensus-microservices-demo

OpenCensus

OpenCensus(OC)는 Microservice 및 Monolith 서비스를 Tracing 및 Metric Monitoring 할 수 있는 라이브러리를 제공하는 오픈소스이다.

아래와 같이 다양한 언어를 지원 한다.

  • Java , Go, Python, C++, Nodejs, Erlang, Ruby, PHP, C#

또한 수집된 데이터를 Prometheus, Stackdriver Tracing and Monitoring, DataDog, Graphite, Zipkin, Jaeger, Azure Insights 등 과 같은 백엔드 Application으로 내보낼 수 있기 때문에 개발자, 운영자 측면에서 좋은 선택사항이 될 수 있다.

Microservice와 같은 분산 시스템에서 개발자/운영자 관점의 가장 중요한 미션은 각각의 수행되는 서비스들의 실행 시간을 확인하고 상호 API간 통신이 얼마나 걸리는지를 확인하고 Span(아래 그림참조)에서 가장 지연이 발생하는 서비스를 빨리 찾아내 확인하고 조치하는 것이라 할 수 있다.

span

OpenCensus는 주로 두가지 기능으로 활용된다.
첫번째는 Metric 수집이고 두번째는 Tracing 기능이다.
Log같은 경우 현재 미지원이지만 다음 메이저 릴리즈에 추가될 예정이라고 하니 조금더 지켜보면 좋을것 같다.

  • Metrics

    • 데이터베이스 및 API의 응답시간, 요청 content length, open file descriptor 수와 같이 추적하고자하는 정량 데이터를 말한다. Metric 을 시각화해서 보면 응용 프로그램 및 서비스의 성능과 품질을 측정하는 데 도움이 될 수 있다. 예를 들면 요청 응답시간의 평균값이나 cache hit/miss 수와 같은 것들이 될 수 있다.
  • Traces

    • 서비스 요청에 대한 애플리케이션 또는 서비스 구조를 확인할수 있고 모든 서비스 간 데이터 흐름을 시각화하여 아키텍처상의 병목 현상을 파악하는 데 도움이 된다.

Hipster Shop Demo

위에서 언급했던 내용처럼 GCP에서 작성한 Hipster Shop Demo는 minikube 및 GCP 데모로 되어있고 코드안에 기본 Metric 설정이 Stackdriver으로 되어있어 Prometheus Exporter 적용을 하려면 코드 수정이 필요하기 때문에 Prometheus기반으로 작성된 Forked Repo를 살펴보기로 하였다.

Requirement

현재 가지고 있는 MacOS 환경에서 구동하였다. 최소 스펙은 따로 기재하지 않았으나 K8s 1.11 이상을 권장한다.

  • kubectl : v1.10.7
  • Minikube : v0.34.1
  • Kubernetes : v1.13.3
  • skaffold : v0.24

minikube 기동

최소 3 CPU, 6Gb Memory가 필요하다. 그냥 minikube를 구동시기면 4 CPU, 8Gb 로 구동이 되기 때문에 별다른 옵션 없이 default로 구동하면 된다.

$ minikube start
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
minikube Ready master 6h v1.13.3

Repository Clone

$ git clone https://github.com/census-ecosystem/opencensus-microservices-demo.git
$ cd opencensus-microservices-demo

내부 구조를 살펴보면 기본적으로 skaffold를 활용하여 배포를 진행을 하는 것을 알수있다.
skaffold는 로컬에서 Kubernetes 기반 어플리케이션 개발과 배포(CD)를 빠르게 도와주는 CLI tool이다. 소스코드의 변화를 감지하여 build, registry push/tagging, deploy까지 자동으로 할 수 있는 로컬 기반 도구이다.

skaffold dev는 로컬 환경의 반복적인 개발에 활용하고 실제 배포는 CI Process에서 skaffold run을 통해 배포를 진행할 수 있다.

skaffold demo

Kubernetes 배포툴에 대해 비교한 글은 블로그 링크를 통해 확인할 수 있다.

아래에서는 skaffold에 대한 자세한 내용은 미뤄두고 배포하는 도구로서만 설명한다.

기본적으로 구성을 하고자 하는 내용은 helm처럼 template 파일을 사용하게 되는데 프로젝트 root에 skaffold.yaml 에 build를 위한 image name, tag, src 위치등 기본적인 내용을 기재한다. 파일내용을 살펴보면 build에 관련된 내용들을 작성하고 deploy할 manifests의 위치까지 지정하도록 되어있다. 로컬환경에서 확인을 위해 grafana, prometheus, jaeger가 추가된 것을 확인할 수 있다.

apiVersion: skaffold/v1alpha2
kind: Config
build:
tagPolicy:
gitCommit: {}
artifacts:
- imageName: gcr.io/opencensus-microservices-demo/emailservice
workspace: src/emailservice
- imageName: gcr.io/opencensus-microservices-demo/productcatalogservice
workspace: src/productcatalogservice
- imageName: gcr.io/opencensus-microservices-demo/recommendationservice
workspace: src/recommendationservice
- imageName: gcr.io/opencensus-microservices-demo/shippingservice
workspace: src/shippingservice
- imageName: gcr.io/opencensus-microservices-demo/checkoutservice
workspace: src/checkoutservice
- imageName: gcr.io/opencensus-microservices-demo/paymentservice
workspace: src/paymentservice
- imageName: gcr.io/opencensus-microservices-demo/currencyservice
workspace: src/currencyservice
- imageName: gcr.io/opencensus-microservices-demo/cartservice
workspace: src/cartservice
- imageName: gcr.io/opencensus-microservices-demo/frontend
workspace: src/frontend
- imageName: gcr.io/opencensus-microservices-demo/loadgenerator
workspace: src/loadgenerator
- imageName: gcr.io/opencensus-microservices-demo/adservice
workspace: src/adservice
- imageName: gcr.io/opencensus-microservices-demo/grafana
workspace: src/grafana
- imageName: gcr.io/opencensus-microservices-demo/prometheus
workspace: src/prometheus
- imageName: gcr.io/opencensus-microservices-demo/jaeger
workspace: src/jaeger
deploy:
kubectl:
manifests:
- ./kubernetes-manifests/**.yaml

Go로 작성된 Frontend microservice을 살펴보자. [./src/frontend/main.go]

library 추가 및 http handler 초기화

Go기반 exporter 패키지(jaeger,prometheus)를 추가적으로 import 하고 http handler를 위한 ochttp 패키지를 추가하였다.

import (
...
"go.opencensus.io/exporter/jaeger"
"go.opencensus.io/exporter/prometheus"
"go.opencensus.io/plugin/ochttp"
"go.opencensus.io/plugin/ochttp/propagation/b3"
...
)
func main() {
...
var handler http.Handler = r
handler = &logHandler{log: log, next: handler}
handler = ensureSessionID(handler)
// add opencensus instrumentation
handler = &ochttp.Handler{
Handler: handler,
Propagation: &b3.HTTPFormat{}}
log.Infof("starting server on " + addr + ":" + srvPort)
log.Fatal(http.ListenAndServe(addr+":"+srvPort, handler))
}

exporter 등록(Jaeger Tracing 및 Prometheus exporter)

예시처럼 각각의 서비스에 jaeger와 prometheus exporter Endpoint를 쉽게 등록할수 있다.
또한 initTracing() 에서는 데모를 위해 trace.AlwaysSample()을 사용하였다. 실제 운영환경에서는 다음 링크를 참고해서 사용하는 것을 권고하고 있다.

...
func initJaegerTracing(log logrus.FieldLogger) {
// Register the Jaeger exporter to be able to retrieve
// the collected spans.
exporter, err := jaeger.NewExporter(jaeger.Options{
Endpoint: "http://jaeger:14268",
Process: jaeger.Process{
ServiceName: "frontend",
},
})
if err != nil {
log.Fatal(err)
}
trace.RegisterExporter(exporter)
}

func initTracing(log logrus.FieldLogger) {
// This is a demo app with low QPS. trace.AlwaysSample() is used here
// to make sure traces are available for observation and analysis.
// In a production environment or high QPS setup please use
// trace.ProbabilitySampler set at the desired probability.
trace.ApplyConfig(trace.Config{
DefaultSampler: trace.AlwaysSample(),
})
initJaegerTracing(log)
}

func initPrometheusStatsExporter(log logrus.FieldLogger) *prometheus.Exporter {
exporter, err := prometheus.NewExporter(prometheus.Options{})

if err != nil {
log.Fatal("error registering prometheus exporter")
return nil
}

view.RegisterExporter(exporter)
return exporter
}
func startPrometheusExporter(log logrus.FieldLogger, exporter *prometheus.Exporter) {
addr := ":9090"
log.Infof("starting prometheus server at %s", addr)
http.Handle("/metrics", exporter)
log.Fatal(http.ListenAndServe(addr, nil))
}
...

Demo Application 배포

minikube에 Hipster Shop Demo를 배포한다. 단순하게 skaffold run 명령으로 진행하면 된다.

$ skaffold run

현재 사용중인 2018 Macbook Pro(3.1 GHz Intel Core i7, 16GB) 상의 Docker기반 minikube 환경으로도 배포를 하였는데 시간이 꽤 소요되었다.(20분이상)
코드를 실시간으로 수정하고 빌드, 배포되는 것은 skaffold dev 명령으로 확인할 수 있다. 진행되는 과정을 보면 draft.sh 프로젝트와도 꽤 유사하다고 볼 수 있다.

에러없이 run이 실행되고 난후 minikube에 배포된 pod와 service를 확인한다. 중간에 loadgenerator가 init인 이유는 minikube 자원이 부족해서 발생하는 현상이다.

$ kubectl get pod
NAME READY STATUS RESTARTS AGE
adservice-7c7d687dcb-xzr4m 1/1 Running 1 4h
cartservice-f54bcb9ff-tcfgn 1/1 Running 4 4h
checkoutservice-576446687b-95bwj 1/1 Running 1 4h
currencyservice-5bd99bf97d-28mtz 1/1 Running 1 4h
emailservice-6cb587798d-wwzdh 1/1 Running 1 4h
frontend-6bf9796f7b-ch9pl 1/1 Running 4 4h
grafana-6678c5c5d9-2qx75 1/1 Running 1 4h
jaeger-5b66bdf7f7-csdzx 1/1 Running 2 4h
loadgenerator-7c4f446774-68djg 0/1 Init:0/1 1 4h
paymentservice-fc4c8589-wrfg7 1/1 Running 1 4h
productcatalogservice-84878c8b9c-jhgnw 1/1 Running 1 4h
prometheus-58d98b7578-87td6 1/1 Running 1 4h
recommendationservice-8564f9d894-smlpf 1/1 Running 1 4h
redis-cart-798bc66d58-xn6ff 1/1 Running 1 4h
shippingservice-789656f6bc-rgzrp 1/1 Running 1 4h

$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
adservice ClusterIP 10.107.196.115 <none> 9555/TCP,9090/TCP 4h
cartservice ClusterIP 10.98.151.164 <none> 7070/TCP 4h
checkoutservice ClusterIP 10.97.9.197 <none> 5050/TCP 4h
currencyservice ClusterIP 10.103.112.225 <none> 7000/TCP 4h
emailservice ClusterIP 10.97.184.174 <none> 5000/TCP 4h
frontend ClusterIP 10.103.40.138 <none> 80/TCP,9090/TCP 4h
frontend-external LoadBalancer 10.108.170.241 <pending> 80:31944/TCP 4h
grafana ClusterIP 10.104.141.254 <none> 3000/TCP 4h
grafana-external LoadBalancer 10.102.166.138 <pending> 3000:30459/TCP 4h
jaeger ClusterIP 10.98.71.173 <none> 9411/TCP,5775/UDP,6831/UDP,6832/UDP,5778/TCP,16686/TCP,14268/TCP 4h
jaeger-external LoadBalancer 10.96.164.126 <pending> 16686:32362/TCP 4h
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6h
paymentservice ClusterIP 10.109.31.241 <none> 50051/TCP 4h
productcatalogservice ClusterIP 10.101.124.106 <none> 3550/TCP 4h
prometheus ClusterIP 10.103.107.213 <none> 9090/TCP 4h
recommendationservice ClusterIP 10.104.225.28 <none> 8080/TCP 4h
redis-cart ClusterIP 10.101.24.157 <none> 6379/TCP 4h
shippingservice ClusterIP 10.104.224.18 <none> 50051/TCP 4h

서비스 접속 및 Metric/Tracing 확인

로컬 minikube환경이기 때문에 external service가 pending이므로 service를 minikube NAT IP로 expose 시킨다.

$ minikube service frontend-external
$ minikube service grafana-external
$ minikube service jaeger-external
$ minikube service list
|-------------|-----------------------|-----------------------------|
| NAMESPACE | NAME | URL |
|-------------|-----------------------|-----------------------------|
| default | adservice | No node port |
| default | cartservice | No node port |
| default | checkoutservice | No node port |
| default | currencyservice | No node port |
| default | emailservice | No node port |
| default | frontend | No node port |
| default | frontend-external | http://192.168.99.101:31944 |
| default | grafana | No node port |
| default | grafana-external | http://192.168.99.101:30459 |
| default | jaeger | No node port |
| default | jaeger-external | http://192.168.99.101:32362 |
| default | kubernetes | No node port |
| default | paymentservice | No node port |
| default | productcatalogservice | No node port |
| default | prometheus | No node port |
| default | recommendationservice | No node port |
| default | redis-cart | No node port |
| default | shippingservice | No node port |
| kube-system | kube-dns | No node port |
|-------------|-----------------------|-----------------------------|

3개의 서비스로 각각 접속이 되는것을 확인할수 있다. Grafana 대시보드로 들어가면 현재 수집되는 prometheus source(http://prometheus:9090)를 통해 OpenCensus기반 Application Metric을 확인할 수 있다.

hipster_grafana

그림에서 보면 전체 서비스 응답에 대한 99% 백분위 지연시간이 944ms 인것을 확인할 수 있다.

또한 Jaeger를 통해 DAG(Directed acyclic graph) 및 서비스간 Tracing 을 확인할 수 있다.

DAG

tracing

정리

OpenCensus 기반으로 개발자가 코드를 작성하고 Microservice를 minikube에서 배포하고 Prometheus, Jaeger Exporter 연동을 통해 시스템뿐만이 아닌 Application기반 Metrics/Stats을 수집하고 개발자가 작성한 코드를 직접 Tracing하는 간단한 데모를 진행하였다. (Istio를 포함해서 Public환경에 배포해봐도 좋은 공부가 될 것 같다)

향후 OpenMetricOpencensus가 실제 개발자 기반으로 활성화되고 적용이 된다면 Telemetric 측면에서 많은 Use-Case가 도출될 수 있을것 같다.

위에서 언급했듯이 Prometheus기반 Kubernetes 클러스터를 운영하고 있는 팀의 경우 개발자의 작성 코드를 최소화할 수 있는 도구로서 충분히 활용될 수 있어 보인다.

꼭 Cloud Native 기반 Web 개발이 아니더라도 기존 공장, 금융, 병원 등 의 IoT나 센서/설비를 위한 비즈니스에도 Backend로서 확장성있는 도구로서 활용이 될 수 있을것 같다.

· 9 min read

Knative Routing

Knative는 앞에서도 몇번 언급하였지만 기본적으로 Routing을 사용하여 외부에 노출할 서비스들에 대한 HTTP Endpoint를 제공한다. 어떻게 보면 기본적으로 API Gateway 역할을 하기도 하고 Ingress 역할을 하기도 한다. 보통 Service mesh인 Istio를 사용하여 ingress를 구현하는것이 당연하다고 생각하기도 하지만 Istio의 모든 기능이 Knative에 필요하지는 않고 설치되는것 자체가 리소스 소모가 꽤 된다는것은 설치 해본사람은 알고 있을것이다.

Service

Kubernetes

ingress
이미지출처 : https://www.nginx.com/blog/announcing-nginx-ingress-controller-for-kubernetes-release-1-3-0/

Kubernetes에서는 일반적으로 서비스 접속을 구현하게 되면 기본적으로 Pod와 Service를 생성하고 Ingress를 사용하여 클러스터 내부로 들어오는 트래픽을 처리하게 된다.

Knative

Serving
이미지출처 : https://blog.openshift.com/knative-serving-your-serverless-services/

Knative에서는 앞선 Knative 관련 포스팅에서도 설명했듯이 Automatic scaling up and down to zero 특성을 가지고 있기에 Pod가 최초 실행되어있지 않은 상태에서 트래픽이 들어오게 되면 Knative Serving Activator에 의해서 Pod가 없는 Revision을 확인하고 Cold Start 형태로 프로비저닝하게 된다. 나는 이게 진정한 서버리스라고 생각하지만 주변에 반박하시는 분들도 간혹 있다.

이후 Pod가 Warm 상태가 되고 나면 Istio Route(Ingress Gateway)를 통해 트래픽이 Pod로 전달되어 통신이 이뤄지게 된다.

현재 Knative는 현재 Ingress Gateway 의존성을 가지고 있고 Envoy기반 Service Mesh인 Istio, Envoy기반 API Gateway인 Gloo 두가지 옵션으로 Ingress 구현이 가능하다.

Istio

Knative는 기본적으로 Ingress Gateway기능을 탑재하고 있는데 이는 Istio의 기능중 하나다.
Istio는 다음과 같은 Core Feature를 가진다. 상세한 내용은 https://istio.io/docs/concepts/what-is-istio/ 에서 확인하면 된다.

  • Traffic management
  • Security
  • Policies and Telemetry
  • Performance and Scalability

Istio는 48개의 CRDs(CustomResourceDefinition objects)를 가지고 있는데 이중 Knative Serving에서 사용하는건 VirtualService 단 하나다.

Gloo

Gloo는 Kubernetes-native ingress controller이자 Next Generation API Gateway 를 위해 시작된 프로젝트이다. 실제 Redhat에서 Openshift기반 Microservice 및 Istio 개발업무를 하다가 최근에 solo.io의 CTO로 이직한 Christian Posta가 밀고 있는 프로젝트이기도 하다.

gloo

Gloo는 Envoy Proxy 기반으로 동작하며 기존 Legacy부터 Container서비스, FaaS(AWS Lambda, Azure Functions, GCP Functions)영역의 Application들을 REST, gRPC, SOAP, Web Socker기반으로 Aggregate 해서 Function 기반 추상화를 구현해 주는 오픈소스 프로젝트라 정의 할 수 있다.

Istio의 Ingress기능외의 여러가지 부가 기능(Telemetry, Security, Policy Enforcement)들은 Knative에서는 필요로 하지 않는다.

Knative API Gateway 로서 Istio가 아닌 Gloo가 조금더 경량화된 대안으로 결정되었고 Gloo를 통해 Knative 설치가 가능하게 되었다. 단, Knative Eventing 컴포넌트는 현재 지원하지 않는다고 한다.

Install Knative with Gloo

참고: Install with Gloo

간단하게 gloo와 Knative 설치를 해보자.

Requirements

Install Glooctl

gloo CLI (glooctl) Download
https://github.com/solo-io/gloo/releases

또는 직접 Download

$ curl -sL https://run.solo.io/gloo/install | sh
Attempting to download glooctl version v0.8.1
Downloading glooctl-darwin-amd64...
Download complete!, validating checksum...
Checksum valid.
Gloo was successfully installed 🎉

Add the gloo CLI to your path with:
export PATH=$HOME/.gloo/bin:$PATH

Now run:
glooctl install gateway # install gloo's function gateway functionality into the 'gloo-system' namespace
glooctl install ingress # install very basic Kubernetes Ingress support with Gloo into namespace gloo-system
glooctl install knative # install Knative serving with Gloo configured as the default cluster ingress
Please see visit the Gloo Installation guides for more: https://gloo.solo.io/installation/

PATH 등록

$ export PATH=$HOME/.gloo/bin:$PATH

gloo CLI 확인

$ glooctl --version
glooctl version 0.8.1

GCP 무료플랜으로 3-node 클러스터를 생성한다.

$ gcloud container clusters create gloo \
--region=asia-east1-a \
--cluster-version=latest \
--machine-type=n1-standard-2 \
--enable-autorepair \
--num-nodes=3

cluster 생성된것을 확인하고 cluster-admin 권한을 할당한다.

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-gloo-default-pool-f6bcc479-f8v9 Ready <none> 9m v1.11.7-gke.6
gke-gloo-default-pool-f6bcc479-fl78 Ready <none> 9m v1.11.7-gke.6
gke-gloo-default-pool-f6bcc479-gfgw Ready <none> 9m v1.11.7-gke.6

$ kubectl create clusterrolebinding cluster-admin-binding \
> --clusterrole=cluster-admin \
> --user=$(gcloud config get-value core/account)
Your active configuration is: [cloudshell-25974]
clusterrolebinding.rbac.authorization.k8s.io "cluster-admin-binding" created

Gloo와 Knative 설치를 한다. 미리 glooctl install knative --dry-run 으로 전체 manifest를 확인할 수 있다.

$ glooctl install knative

위에서 설치 과정은 생략했지만 Istio에 비해 CRD 개수가 적은 것을 알수있다. 또한 설치된 컴포넌트 역시 Istio에 비해서 간소화된 것을 알수 있다.

$ kubectl get pods --namespace gloo-system                                                                                         
NAME READY STATUS RESTARTS AGE
clusteringress-proxy-59fd6fb56-dmwwm 1/1 Running 0 7m
discovery-779884d4cc-xlql2 1/1 Running 6 7m
gloo-844fc79445-f4zvg 1/1 Running 6 7m
ingress-7d75c99874-s4m76 1/1 Running 6 7m

$ kubectl get pods --namespace knative-serving
NAME READY STATUS RESTARTS AGE
activator-746f6bb684-49tfh 1/1 Running 0 12m
autoscaler-955f679cd-tx5vw 1/1 Running 0 12m
controller-7fc84c6584-jbn69 1/1 Running 0 12m
webhook-7797ffb6bf-6pgsw 1/1 Running 0 12m

이전 포스팅에서도 사용했던 gcr.io/knative-sample/helloworld-go 이미지를 활용하여 샘플앱 Knative Service를 만든다.

service.yaml

$ vi service.yaml

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: gcr.io/knative-sample/helloworld-go
env:
- name: TARGET
value: "Go Sample v1"
$ kubectl apply --filename service.yaml
service.serving.knative.dev "helloworld-go" created

앞에서도 설명했지만 Automatic scaling up and down to zero 으로 Cold Start가 되고 잠시후에 아래와 같이 Knative Service를 확인할 수 있다.

$ kubectl get ksvc helloworld-go -n default  --output=custom-columns=NAME:.metadata.name,DOMAIN:.status.domain]($ kubectl get ksvc helloworld-go -n default  --output=custom-columns=NAME:.metadata.name,DOMAIN:.status.d
omain
NAME DOMAIN
helloworld-go helloworld-go.default.example.com

Gloo Ingress를 확인한다. GKE에서 설치했기 때문에 자동으로 LoadBalancer가 연동되어 있는것을 확인할 수 있다.

$ kubectl get svc -n gloo-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
clusteringress-proxy LoadBalancer 10.3.244.54 34.**.**.54 80:30978/TCP,443:32448/TCP 39m
gloo ClusterIP 10.3.243.231 <none> 9977/TCP 39m

$ glooctl proxy url --name clusteringress-proxy
http://34.**.**.54:80

위에서 얻은 두가지 정보로 생성된 app을 테스트한다. Cold Start(default timeout 5분) 때문에 응답이 늦어질 수도 있지만 잠시 기다리면 응답을 확인할 수 있다.

$ curl -H "Host: helloworld-go.default.example.com" http://34.**.**.54:80
Hello Go Sample v1!

물론 Revision이나 Route를 활용하여 Knative의 기능에 대해서도 확인이 가능하다.

정리

Gloo는 Knative ClusterIngress CRD를 기반으로 동작하는 Istio의 대안으로서 가능성을 보여주고 있다. 이외에도 The Service Mesh Orchestration Platform SuperGloo, Debugger for microservices Squash 등 다양한 Mesh Layer기반의 오픈소스들을 확인할수 있다. 또다른 스쳐지나갈수도 있는 오픈소스일수도 있겠지만 현재 개발되는 로드맵(https://www.solo.io/)을 보면 Knative가 고도화되는 여정에 같이 가는 모습을 확인할 수 있다.

next-generation API Gateway로서 다양한 프로토콜을 지원하기 때문에 (HTTP1, HTTP2, gRPC, REST/OpenAPISpec, SOAP, WebSockets, Lambda/Cloud Functions) 더욱더 Microservices 및 Serverless Workload를 수행하기에 더욱 적합한 오픈소스로 보인다.

다음 주제

현재 해보고 싶은것은 베어메탈 Kubernetes Cluster기반 BGP로 동작하는 MetalLBCillium on AWS 인데 시간나는 대로 테스트 해봐야 겠다.

· 15 min read

knctl

knctl 은 Knative CLI 툴로 간단하게 knative cluster를 만들고 Knative를 추상화해서 앱까지 배포할 수 있는 오픈소스이다.

참고

Knative 다시 살펴보기

앞선 포스팅에서도 이야기 했지만 기존 FaaS(AWS Lambda, Google Cloud Funtions, Azure Function) 과는 다른 Serverless 개념으로 받아들어야 한다.

다시 한번 특징을 나열해보면 아래와 같다.

  • Serverless Container의 신속한 배치
  • Automatic scaling up and down to zero
  • Istio를 백엔드로 활용하여 Routing 구현
  • 배포 된 코드 및 config의 특정 시점 스냅 샷

그리고 다음과 같은 CRDs(Custom Resource Definitions)로 구성된 오브젝트들로 정의된다.

  • Route는 사용자 서비스에 대한 HTTP endpoint와 Routing을 제공한다.
  • Revisions은 code(function)와 config로 구성된 불변의 스냅샷. Route를 통해 endpoint를 할당받지 못한 Revision은 자동으로 kubernetes resource에서 삭제됨
  • Configuration은 요구되는 Revision 최신 상태를 기록하고 생성하고 추적할수 있음. 소스 패키지(git repo나 archive)를 컨테이너로 변환하기 위한 내용이나 메타데이터등을 포함시킬수 있음.
  • ServiceRoutesConfigurations 리소스의 추상화된 집합체. 모든 워크로드의 lifecycle을 관리함. 트래픽을 항상 최신의 Revision으로 route되도록 정의할수 있음

하나씩 조금 자세히 이야기 하면 아래처럼 정리 할수 있다.

Route

Route는 사용자 서비스(Code와 Configuration의 Revision정보)의 네트워크 Endpoint를 제공한다. kubernetes namespace는 여러개의 Route를 가질수 있다. Route는 하나 이상의 Revisions을 가지면서 수명이 길고 안정적인 HTTP Endpoint를 제공한다. 기본구성은 Route 객체가 Configuration에 의해 생성된 최신의 Revision으로 트래픽을 자동으로 지정한다. 조금더 복잡한 경우로는 istio의 기능을 활용하여 트래픽을 백분율 기준으로 Route를 지정할 수 있다.

Revision

Revision은 Code와 Configuration의 불변의 스냅샷이다. 하나의 Revision은 컨테이너 이미지를 참조하고 선택적으로 Build를 참조할 수 있다. RevisionConfiguration이 업데이트 시 생성된다.
Route를 통해 http주소 지정이 불가능한 Revision은 폐기 되고 관련된 kubernetes 리소스가 삭제가 된다. 시간이 지남에 따라 Configuration이 생성한 Revision 히스토리가 제공되고 사용자는 이전 Revision로 쉽게 롤백 할 수 있다.

Configuration

Configuration은 최신의 Revision상태를 설명하고, 생성하고, 원하는 상태가 갱신될때 Revision의 상태를 추적한다. ConfigurationBuild를 참조하여 소스(git repo 또는 archive)를 컨테이너로 변환하는 방법에 대한 가이드가 포함되어 있거나 단순히 컨테이너 이미지 및 수정에서 필요한 메타 데이터 만 참조 할 수 있다.

Product Integration

2019년 2월 현재 0.3이 릴리스되고 있고 벌써 여러 제품에 통합이 되고 있다.

최근 IBMthink 2019에서 Managed Knative (Experimental)를 내놓기도 하였다.
https://www.ibm.com/blogs/bluemix/2019/02/announcing-managed-knative-on-ibm-cloud-kubernetes-service-experimental/

Istio를 포함한 Knative 마저도 품는 모습으로 managed kubernetes 영역에서 글로벌 플레이어들 모두 서로 치고나가는 모습들을 볼수 있다.

작년 11월에는 Gitlab 제품안에 serverless라는 extension형태의 서비스가 추가 되기도 하였고,
https://about.gitlab.com/press/releases/2018-12-11-gitlab-and-triggermesh-announce-gitlab-serverless.html

triggermesh 라는 곳에서는 serverless management platform이라는 이름으로 knative 기반 멀티 서버리스 플랫폼을 출시하기도 하였다.
https://triggermesh.com/serverless_management_platform/

Pivotal Function Service (PFS), Google GKE SERVERLESS ADD-ON 등은 아직 early access 신청만 받고 있는 상태이다.

오늘은 간단하게 배포할수 있는 툴 knctl과 관련 use-case를 소개하고자 한다.

Kubernetes Cluster 생성

일단 GKE Free tier에서 Cluster를 하나 생성하자.

gcloud container clusters create knative \
--region=asia-east1-a \
--cluster-version=latest \
--machine-type=n1-standard-2 \
--enable-autoscaling --min-nodes=1 --max-nodes=5 \
--enable-autorepair \
--scopes=service-control,service-management,compute-rw,storage-ro,cloud-platform,logging-write,monitoring-write,pubsub,datastore \
--num-nodes=3

cluster 생성된것을 확인하고 cluster-admin 권한을 할당한다.

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-knative-default-pool-d1a39347-5m5t Ready <none> 1m v1.11.7-gke.4
gke-knative-default-pool-d1a39347-l6zh Ready <none> 1m v1.11.7-gke.4
gke-knative-default-pool-d1a39347-qv5r Ready <none> 1m v1.11.7-gke.4

$ kubectl create clusterrolebinding cluster-admin-binding \
--clusterrole=cluster-admin \
--user=$(gcloud config get-value core/account)
Your active configuration is: [cloudshell-4728]
clusterrolebinding.rbac.authorization.k8s.io "cluster-admin-binding" created

knctl 설치

이번 포스팅에서는 Mac OS 설치 기준으로 작성하였다.

homebrew 설치

brew install starkandwayne/kubernetes/knctl

binary

https://github.com/cppforlife/knctl/releases

$ wget https://github.com/cppforlife/knctl/releases/download/v0.1.0/knctl-darwin-amd64
$ mv knctl-* /usr/local/bin/knctl
$ chmod +x /usr/local/bin/knctl

knctl 로 Knative 배포

설치한 knctl로 Knative 배포를 진행한다. 설치되는 내용을 지켜보고 있으면 istio를 먼저 배포하고 그다음에 Knative를 설치하는 것을 확인할 수 있다. 배포되는 모듈들의 상태를 하나하나 체크해서 배포하기 때문에 설치상에 과정들을 확인할 수 있다.

$ knctl install --exclude-monitoring

테스트를 위한 namespace hello-test를 생성한다.

$ kubectl create namespace hello-test
namespace "hello-test" created

knctl deploy 명령으로 최초 revision을 배포한다.
아래 결과를 보면 hello-00001 이라고 하는 최초의 revision을 작성하기 때문에 latest tag를 달고 배포를 하게 된다.

$ knctl deploy \
--namespace hello-test \
--service hello \
--image gcr.io/knative-samples/helloworld-go \
--env TARGET=Rev1

Name hello

Waiting for new revision to be created...

Tagging new revision 'hello-00001' as 'latest'

Tagging new revision 'hello-00001' as 'previous'

Annotating new revision 'hello-00001'

Waiting for new revision 'hello-00001' to be ready for up to 5m0s (logs below)...

hello-00001 > hello-00001-deployment-5cdbfc9bc9-hks6t | 2019/02/17 22:27:50 Hello world sample started.

Revision 'hello-00001' became ready

Continuing to watch logs for 5s before exiting

Succeeded
kubectl get svc knative-ingressgateway -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
knative-ingressgateway LoadBalancer 10.63.253.209 34.***.***.248 80:32380/TCP,443:32390/TCP,31400:32400/TCP,15011:30082/TCP,8060:31125/TCP,853:32009/TCP,15030:31102/TCP,15031:31631/TCP 6h

위처럼 Knative가 프로비저닝 되면서 ingress-gateway가 하나 생성이 되어있는 것을 확인할 수 있고 knctl로도 ingress를 확인이 가능하다.

$ knctl ingress list
Ingresses

Name Addresses Ports Age
knative-ingressgateway 34.***.***.248 80 6h
443
31400
15011
8060
853
15030
15031

1 ingresses

Succeeded

Knative custom domain 연결

Domain이 별도로 없기 때문에 Knative는 내부적으로 example.com이라고 하는 기본 domain을 사용한다. 그래서 실제 knctl curl 명령은 내부적으로 hello.hello-test.example.com으로 curl을 실행하게 되고 해당 결과를 아래와 같이 확인할 수 있다.

$ knctl curl --service hello -n hello-test
Running: curl '-sS' '-H' 'Host: hello.hello-test.example.com' 'http://34.***.***.248:80'

Hello Rev1!

Succeeded

kubernetes node가 3개이므로 3개의 pod가 생성된 것을 확인할 수 있다. 일정시간(default:5분)이 지나면 zero to scale 관점에서 pod가 종료되므로 다시 확인할때는 다시 curl 명령을 날리게 되면 다시 pod가 올라오게 된다. 해당 개념은 FaaS또는 AWS Lambda에서 Cold-Start와 동일한 것이라 볼 수 있다.

AWS Cold Start 참고 : https://novemberde.github.io/aws/2018/02/02/Lambda_coldStart.html

$ kubectl get po
NAME READY STATUS RESTARTS AGE
hello-00001-deployment-5cdbfc9bc9-hks6t 3/3 Running 0 4m

가지고 있는 도메인이 있다면 위에서 나온 34.***.***.248 IP를 domain에 매핑해보자. 아래에서는 기존 보유중인 skcloud.io 도메인을 연결하였다.

$ dig knative.skcloud.io
;; ANSWER SECTION:
knative.skcloud.io. 603 IN A 34.***.***.248

knctl domain을 이용하여 default domain을 knative.skcloud.io로 변경한다.

$ knctl domain create -d knative.skcloud.io --default
Succeeded

knctl routes 명령으로 해당 hello-test app의 Endpoint 정보를 확인할 수 있다.

$ knctl routes list -n hello-test
Routes in namespace 'hello-test'

Name Domain Traffic Annotations Conditions Age
hello hello.hello-test.knative.skcloud.io 100% -> hello - 3 OK / 3 1h

1 routes

Succeeded

5분이상 기다렸다가 curl로 확인하면 Cold-Start 되는 시간(몇초) 지연이 발생하고 결과를 확인할 수 있다. 이후에는 바로 응답을 확인할 수 있다.

$ curl http://hello.hello-test.knative.skcloud.io/
Hello Rev1!

revision 추가

이번에는 revision을 추가해보자. TARGET environment 변수를 Rev2로 수정하고 배포를 한다. 기존 hello-00002 revision이 최신 revision으로 갱신되어 배포가 되는것을 확인할 수 있다.

$ knctl deploy --service hello \
--image gcr.io/knative-samples/helloworld-go \
--env TARGET=Rev2
Name hello

Waiting for new revision (after revision 'hello-00001') to be created...

Tagging new revision 'hello-00002' as 'latest'

Tagging older revision 'hello-00001' as 'previous'

Annotating new revision 'hello-00002'

Waiting for new revision 'hello-00002' to be ready for up to 5m0s (logs below)...

hello-00002 > hello-00002-deployment-6cf86bbfc7-sblz9 | 2019/02/17 23:25:43 Hello world sample started.

Revision 'hello-00002' became ready

Continuing to watch logs for 5s before exiting

Succeeded

신규 revision 서비스를 추가된것을 확인할 수 있다. 마찬가지로 몇초간의 Cold-Start delay가 발생할 수도 있다.

$ curl http://hello.hello-test.knative.skcloud.io/
Hello Rev2!

$ knctl curl --service hello
Running: curl '-sS' '-H' 'Host: hello.hello-test.knative.skcloud.io' 'http://34.***.***.248:80'

Hello Rev2!

Succeeded

revision list를 확인해보면 현재 latest, previous TAG정보를 확인할 수 있다.

$ knctl revision list --service hello
Revisions for service 'hello'

Name Tags Annotations Conditions Age Traffic
hello-00002 latest - 1 OK / 4 14m 100% -> hello.hello-test.knative.skcloud.io
hello-00001 previous - 1 OK / 4 4h -

2 revisions

Succeeded

Blue/Green 배포

Blue/Green Deploy는 knctl rollout 명령으로 수행할수 있다.
rollout 할때 --managed-route=false 옵션을 줘야 특정 비율로 routing이 가능하다.
아래 예시는 TARGET environment 변수를 blue, green으로 바꿔가면서 배포를 진행하였다.

$ knctl deploy --service hello \
--image gcr.io/knative-samples/helloworld-go \
--env TARGET=blue \
--managed-route=false
Name hello

Waiting for new revision (after revision 'hello-00002') to be created...

Tagging new revision 'hello-00003' as 'latest'

Tagging older revision 'hello-00002' as 'previous'

Annotating new revision 'hello-00003'

Waiting for new revision 'hello-00003' to be ready for up to 5m0s (logs below)...

Revision 'hello-00003' became ready

Continuing to watch logs for 5s before exiting

hello-00003 > hello-00003-deployment-99478dcc5-jf267 | 2019/02/17 23:48:20 Hello world sample started.

Succeeded

revision list를 확인하면 아래와 같이 latest로 Traffic 전체가 routing 되는 것을 확인할 수 있다.

$ knctl revision list --service hello
Revisions for service 'hello'

Name Tags Annotations Conditions Age Traffic
hello-00005 latest - 4 OK / 4 44s 100% -> hello.hello-test.knative.skcloud.io
hello-00004 previous - 4 OK / 4 2m -
hello-00003 - - 1 OK / 4 5m -
hello-00002 - - 1 OK / 4 28m -
hello-00001 - - 1 OK / 4 4h -

5 revisions

Succeeded

이후에 rollout을 통해 previous로 90%, latest로 10%로 변경을 하면 즉시 반영이 되고 실제 트래픽도 분산되어 들어온다. %가 낮은 쪽으로 routing이 될 경우 Cold-Start가 발생하게 되면 delay는 발생하게 된다.

$ knctl rollout --route hello -p hello:latest=10% -p hello:previous=90%
Succeeded

$ knctl revision list
Revisions

Service Name Tags Annotations Conditions Age Traffic
hello hello-00005 latest - 2 OK / 4 1h 10% -> hello.hello-test.knative.skcloud.io
~ hello-00004 previous - 2 OK / 4 1h 90% -> hello.hello-test.knative.skcloud.io
~ hello-00003 - - 1 OK / 4 1h -
~ hello-00002 - - 1 OK / 4 1h -
~ hello-00001 - - 1 OK / 4 5h -

5 revisions

Succeeded

간단하게 curl 반복문을 작성하여 돌려보자.

#!/bin/sh
while true
do
curl -sS --max-time 3 http://hello.hello-test.knative.skcloud.io/
done

간단하게 위 sh을 돌리면 아래와 같이 Cold-Start delay가 발생할때 time out이 발생하고 이후 green revision으로 접속이 되는것을 볼 수 있다.

$ ./test.sh
curl: (28) Operation timed out after 3002 milliseconds with 0 bytes received
Hello blue!
Hello blue!
Hello blue!
Hello blue!
Hello blue!
curl: (28) Operation timed out after 3003 milliseconds with 0 bytes received
Hello blue!
Hello blue!
Hello blue!
Hello blue!
Hello blue!
Hello blue!
Hello green!
Hello blue!
Hello blue!
Hello blue!

정리

지금까지 knctl을 사용하여 간단하게 knative를 배포하고 custom domain을 연결하여 blue-green 배포까지 해봤다. 이외에도 Knative Build를 활용하여 Docker image 작업을 하거나 서비스 카탈로그 등을 연동하여 외부 DBaaS를 연동하는 use-case등을 찾아볼수 있다.

아직 초기 단계이지만 Knative는 istio와 함께 IBM, Google, Pivotal등 global player들의 차세대 오픈소스로 부상하고 있다고 볼 수 있다.

Zero to scale 이라는 슬로건아래 Serverless, FaaS 사상을 기반으로 build, serving, event, routing이라고 하는 Cloud Computing 추상화의 끝판으로 진화하고 있다. 앞으로 어떤 모습으로 진화될지 궁금하고 다음번에는 MQ나 Pub/sub를 연동하거나 멀티 클라우드 환경에서 동작하는 모습을 보여주는 것도 좋을것 같다. 희망사항이지만 올해 OpenInfraDay나 Kubernetes Day Korea 행사에서 Hands-on을 진행해보는것도 좋지 않을까?

· 15 min read

3번째 포스팅이다.

11/23 "Kubernetes Meetup" 1Day에서 발표한 이야기 연장선으로 작성한다.

고객에게 오퍼링을 위해 준비한 내용과 Kubernetes monitoring과 연계한 내용에 대해서 적어보려고 한다. 최근 발표를 다니면서 많이 받는 질문이 실제 사용할만 한가?라는 질문과 어떻게 활용해야 하는지에 대한 질문들을 많이 받는다. 오늘 최근 Spinnaker Summit 2018에서 중요하게 다뤘던 Kayenta 프로젝트를 가지고 이야기 해보려고 한다.

Kayenta

Kayenta는 자동 Canary 분석 오픈소스(Automated Canary Service(ACA))로 Spinnaker의 마이크로서비스중 하나로 동작한다.
Automated Canary Deployments에 사용되고 자세한 내용은 canary documentation을 확인하면 된다.

새 종류의 하나인 Canary는 1차 세계대전중에 인간이 해를 입기 전에 독성가스를 탐지하는 용도로 사용되었다고 한다. DevOps에서는 CD(Continuous Deployment) 프로세스의 일부로 사용되며 Canary 릴리즈는 새로운 버전의 Software를 Production에 배포하는 위험을 줄여주는 기술이라고 생각하면 된다.

Canary 신규 버전의 Software를 안정적인 기존 버전과 함께 배포하고 특정사용자나 일부 대상에게 트래픽 일부를 흘려 기존 사용자에게 영향을 최소하하고 새로운 버전의 문제를 신속하게 발견하고 이전의 안정된 버전으로 트래픽을 다시 라우팅시키는것이 주요 기능이라고 보면 된다.

보통 품질 테스트 용도로 현재 운영 버전과 신규 버전의 주요한 지표(주로 Prometheus Metric)를 비교하여 평가를 진행하는데 이를 단위 테스트나 통합 테스트를 대체하여 사용해서는 절대 안된다.
위에서 언급하였듯이 예기치 않은 위험을 최소화 하거나 문제를 신속하게 발견하는 것을 주 목적으로 하기 때문이다.

Spinnaker에서는 기본적으로 3가지 Cluster(Logical Application Group)를 사용한다.

  • Production Cluster - 현재 실행중인 운영 버전으로 Replica는 임의로 변경할 수 있다.
  • Baseline Cluster - Production Cluster와 동일한 버전으로 실행됨
  • Canary Cluster - 변경된 신규 버전의 Software로 실행됨

기본적으로 수동으로 진행할 경우에는 로그와 수집된 메트릭을 분석하고 객관적인 지표로 평가를 진행하는게 기본이다. 하지만 직접 사람이 하는 일이라 메트릭 데이터를 보다 보면 편견과 착오가 발생할 수 밖에 없다.

그래서 Netflix는 ACA(Automated Canary Service)라고 하는 자동화된 접근 방식을 통해 카나리 분석을 진행하고 있다. 수동으로 계산된 여러가지 지표를 가중치 기반으로 점수를 내리고 원하는 점수에 도달하면 배포하는 자동화된 방식이다.

Requirements

  • spinnaker cluster - 1.8+ (1.9.3 이상 추천)
  • halyard - 1.0+
  • kubernetes cluster - 1.9+
  • metric services - datadog, prometheus, stackdriver, signalfx
  • persistent storage - S3(or compatible S3), minio, GCS

Kayenta Service 추가하기

이번 포스팅에서는 아래 환경으로 작성하였다.

  • spinnaker cluster - 1.10.5
  • halyard - 1.11
  • kubernetes cluster - 1.9.7
  • metric services - prometheus
  • persistent storage - compatible S3(IBM Object Storage)

일단 기존 halyard config를 백업하자.

$ hal backup create
+ Create backup
Success
+ Successfully created a backup at location:
/Users/ddii/halbackup-Wed_Nov_28_13-35-31_KST_2018.tar

나중에 복구는 아래와 같이 하면 된다.

$ hal backup restore --backup-path <backup-name>.tar

기존 halyard config를 살펴보면 아래와 같이 canary.enabled=false 로 되어있는 것을 확인 할수 있다.

currentDeployment: default
deploymentConfigurations:
- name: default
canary
enabled: false

canary analysis을 활성화 한다.

$ hal config canary enable

그리고 default judgement algorithm은 NetflixACAJudge-v1.0 로 되어있다 다른 걸 이용하려면 다음과 같이 설정할수 있다.

$ hal config canary edit --default-judge CUSTOM_JUDGE

메트릭 소스로 prometheus를 설정한다. 물론 기존에 사용중인 prometheus endpoint url이 필요하다.

hal config canary prometheus enable
hal config canary prometheus account add my-prometheus --base-url http://YOUR_PROMETHEUS_SERVER:PORT

여기서는 IBM Cloud Object Storage(S3 Compatible)을 사용하였지만 aws로 설정한다.

$ hal config canary aws enable
$ hal config canary aws account add my-s3 --bucket spin-bucket --endpoint \
s3.seo-ap-geo.objectstorage.service.networklayer.com --access-key-id ACCESS_ID \
--secret-access-key
$ hal config canary aws edit --s3-enabled=true

여러개의 메트릭을 동시에 설정 및 수집이 가능하므로 그중 prometheus 및 관련 account를 기본으로 설정한다.

$ hal config canary edit --default-metrics-store prometheus
$ hal config canary edit --default-metrics-account my-prometheus
$ hal config canary edit --default-storage-account my-s3

모든 spinnaker cluster가 준비된 상태의 컨피그는 아래와 같다.

currentDeployment: default
deploymentConfigurations:
- name: default
canary:
enabled: true
serviceIntegrations:
- name: google
enabled: false
accounts: []
gcsEnabled: false
stackdriverEnabled: false
- name: prometheus
enabled: true
accounts:
- name: my-prometheus
endpoint:
baseUrl: http://YOUR_PROMETHEUS_SERVER:PORT
supportedTypes:
- METRICS_STORE
- name: datadog
enabled: false
accounts: []
- name: aws
enabled: true
accounts:
- name: my-s3
bucket: spin-bucket
rootFolder: kayenta
endpoint: s3.seo-ap-geo.objectstorage.service.networklayer.com
accessKeyId: ACCESS_ID
secretAccessKey: ACCESS_KEY
supportedTypes:
- OBJECT_STORE
- CONFIGURATION_STORE
s3Enabled: true
reduxLoggerEnabled: true
defaultMetricsAccount: my-prometheus
defaultStorageAccount: my-s3
defaultJudge: NetflixACAJudge-v1.0
defaultMetricsStore: prometheus
stagesEnabled: true
templatesEnabled: true
showAllConfigsEnabled: true

Spinnaker Cluster를 재배포하게 되면 아래와 같이 spin-kayenta deployments가 추가된 것을 확인할 수 있다.

$ hal deploy apply

$ kubectl get pod
NAME READY STATUS RESTARTS AGE
spin-clouddriver-555cfc9765-kvnl8 1/1 Running 0 6d
spin-deck-85845b5b48-49ncm 1/1 Running 0 6d
spin-echo-5f9dd4d8ff-mvt7g 1/1 Running 0 6d
spin-fiat-5b945645d8-s2qcq 1/1 Running 0 6d
spin-front50-5c57fcf587-tqz28 1/1 Running 0 6d
spin-gate-57576b8c45-w5v6r 1/1 Running 0 6d
spin-kayenta-6dcd7767d6-rgb9w 1/1 Running 0 6d
spin-orca-788df6b9cc-tk6lk 1/1 Running 0 6d
spin-redis-6c87c456fc-6qbl2 1/1 Running 0 6d
spin-rosco-f6f845d49-btjnd 1/1 Running 0 6d

이후 Dashboard에 접속하고 application중 하나의 Config에 들어가면 Features에 Canary메뉴가 생긴것을 확인할 수 있다. 사용설정하고 캐싱하는데 시간이 다소 필요하고 Tasks 메뉴에서 해당 job에 대한 내용을 확인할수 있다.

canary

이후 application delivery 메뉴를 보면 pipelines, canary configs, canary reports라는 메뉴가 생기게 된다.

delivery

simple deploy pipeline 추가

https://cloud.google.com/solutions/automated-canary-analysis-kubernetes-engine-spinnaker 가이드 처럼 구성해봐도 되나 stackdriver를 써야하고 prometheus metric을 활용한 가이드가 필요해서 적어보고자 한다.

새로 파이프라인을 추가한 다음

newpipe

Pipeline Actions - Edit Pipeline JSON 에서 https://raw.githubusercontent.com/ddiiwoong/canary-demo-spinnaker/master/simple-deploy.json 을 추가해준다.

해당 json pipeline을 추가하고 나면 다음과 같은 화면을 확인할수 있다. pipe1 pipe2

반드시 Deploy Config, Deploy Stage에서 배포할 Account 지정을 해야한다.

sampleapp image - ddiiwoong/canary-demo-spinnaker:latest

해당 pipeline내의 sampleapp은 python flask 기반으로 구성되어 간단히 internal 500 error를 원하는 비율을 configmap 변수로 구현할 수 있다. prometheus python client를 사용하여 Gauge, Counter, Metric 서버를 간단하게 구성을 해보았다. 그리고 코드내에서 500 error rate를 구한 이유는 18년 11월 기준 spinnaker kayenta 버전에서는 PromQL(rate,irate와 같은 함수) 지원이 되지 않는다. 개발중인 코드에 포함이 된것을 확인하였고 12월 kubecon때 정식 릴리즈에 포함될거라 생각한다.

#!/usr/bin/env python

from random import randrange
from flask import Flask
from prometheus_client import start_http_server, Gauge, Counter
import os

app = Flask('kayenta-tester')
c = Counter('requests', 'Number of requests served, by http code', ['http_code'])
g = Gauge('rate_requests', 'Rate of success requests')

responce_500 = 0
responce_200 = 0
rate_responce = 0

@app.route('/')
def hello():
global responce_500
global responce_200
global rate_responce
if randrange(1, 100) > int(os.environ['SUCCESS_RATE']):
c.labels(http_code='500').inc()
responce_500 = responce_500 + 1
rate_responce = responce_500 / (responce_500+responce_200) * 100
g.set(rate_responce)
return "Internal Server Error\n", 500
else:
c.labels(http_code = '200').inc()
responce_200 = responce_200 + 1
rate_responce = responce_500 / (responce_500+responce_200) * 100
g.set(rate_responce)
return "Hello World!\n"

start_http_server(8000)
app.run(host = '0.0.0.0', port = 8080)

해당앱을 Start Manual Execuction을 통해 배포한다. Comfirm Execution창에서 SUCCESS_RATE를 원하는 값(예:70%)으로 선택하고 배포를 하고 나면 Infrastructure - Clusters 메뉴에서 해당 샘플앱을 확인할 수 있다.

manaul deploy success rate manaul deploy2

실제 해당 서비스를 접속해보면 위에 설정한 SUCCESS_RATE 비율로 200화면과 500에러를 확인할 수 있다.

flaskweb flaskweb2

해당 메트릭의 통계를 확인하기 위해 curl을 반복적으로 실행하는 injection container 를 실행한다.

kubectl -n default run injector --image=alpine -- \
/bin/sh -c "apk add --no-cache --yes curl; \
while true; do curl -sS --max-time 3 \
http://sampleapp:8080/; done"

5분정도 후에 Prometheus로 접속하여 코드내 작성한 rate_requests 메트릭을 확인해본다.
PromQL은 아래 쿼리를 실행하였다.

rate_requests{app="sampleapp",version="prod"}

아래 그림과 같이 4개의 pod에서 70% 정도 200 OK, 30% 정도 500 Error가 발생하는 것을 확인할 수 있다.

500rate

이 메트릭을 Spinnaker 에서 확인하기 위해 Canary Pipeline을 만들자.

https://raw.githubusercontent.com/ddiiwoong/canary-demo-spinnaker/master/automated-canary.json를 JSON으로 Pipeline을 생성한다.

canary_auto

Stage별로 살펴 보기전에

  • Prerequisite
    Canary Config 구성이 먼저 필요하다. Delivery - Canary Configs 메뉴에서 신규 컨피그를 작성한다.
    • Configuration Name - kayenta-test
    • Filter Templates 메뉴를 먼저 생성한다. Canary, Baseline구분을 위해 version 정보를 선택하였다.
    • Metrics - Add Metric 은 분석을 위한 Prometheus Metric을 설정하는 단계로 error_rate가 증가(increase)하면 Pipeline을 중단시키고 Metric은 앞에서 확인한 rate_requests를 지정한다. Filter Template은 위에서 지정한 version을 선택한다. metric config
    • SCORING - 어짜피 예제는 한가지 Metric분석으로 0점 아니면 100점으로 나올것이므로 Maginal 75, Pass 95를 설정한다.
  1. 1st Stage
    • Configuration - Pipeline 실행시 초기 입력값(0-100, 10단위)으로 설정가능한 successRate 라는 Parameter를 설정한다.
  2. 2nd Stage
    • Find Baseline - 위에서 작성한 기본 Deploy Pipeline이 선택되었는지와 확인한다.
    • Deploy Canary Config - 앞에서 선택한 새로운 Parameter(successRate)를 신규 배포할 Canary Pod ConfigMap으로 설정하는 단계이다.
  3. 3rd Stage
    • Deploy Canary - yaml manifest로 Canary 버전을 배포한다. Replicas는 1로 설정하였고 배포될 Account(K8s Cluster)를 지정한다.
    • Deploy Baseline - yaml manifest로 Baseline 버전을 배포한다. 위와 동일하게 Replicas는 1로 설정하였고 배포될 Account(K8s Cluster)를 지정한다.
  4. 4th Stage
    • Canary Analysis - 중요한 Canary 분석 단계로 아래와 같이 설정을 확인한다. Prerequisite에서 설정한 Config(kayenta-test)를 선택하고 짧은 분석을 위해 1분(60초) 간격으로 3번 수행을 하도록 한다. Filter Template에서 지정한 version(version="${scope}") 분석을 위해 Baseline, Canary 설정을 하고 Location은 Namespaces로 생각하면 된다. aca config
  5. 5th Stage
    • Deploy to Production - Canary 분석이 통과하였을 경우 운영에 배포
    • Delete Canary, Delete Baseline - 성공이던 실패이던 Canary, Baseline 배포본을 삭제
  6. 6th Stage
    • Successful deployment - Canary 분석이 통과하였을 경우 최종 완료 표기하는 단계

설정이 마무리가 되면 저장을 하고 Canary 분석에 들어간다. 최초에 successRate을 70으로 배포했다면 그 이하로 설정했을 경우에는 아래와 같이 Score 0점으로 배포가 실패하고 Pipeline이 종료된다.

fail

70 이상으로 설정하게 되면 Score 100점으로 정상 배포됨을 확인할 수 있다.

success

정리

간단하게 Spinnaker 와 Prometheus Metric을 활용하여 Kayenta 기반 Canary 배포를 해봤다. 현재 Spinnaker 1.10에서 istio가 지원된다고 하니 다시 한번 확인하고 istio 기반 canary 배포와 함께 사용하는 방법을 더 연구해봐야 할 것 같다.

올해 AWS re:invent 끝나고 작년보다 큰 현자타임이 왔다. 오픈소스로 먹고사는 사람들의 기분은 다 비슷할거 같다고 생각이 든다. 12월 11일 부터 Kubecon이 열린다고 하니 Kubernetes 관련한 새로운 프로젝트와 기능들에 집중해서 남들보다 한발 나아가야하지 않을까? 오픈소스로 먹고사시는 분들 다들 힘냈으면 좋겠다.