안승규의 블로그 (Stay hungry, stay foolish)

Istio 의 설치 순서는 다음과 같다.

사전에 Prometheus 와 EasticSearch 는 설치되어 있다고 가정한다.

1. istio operator 설치
2. istio control plane 을 위한 istio custom resource 생성
3. 서비스별 gateway 설치
4. Jaeger 설치
5. Kiali 설치

1. istio operator 설치

istio operator 를 설치하기 전에 istioctl 명령을 사용할 수 있게 파일을 다운로드 한다.

istio operator 는 helm chart 로 설치하며, 따로 helm repo 를 등록하지 않고 istio source 를 다운받아 설치한다.

먼저, istio 소스를 다운 받는다.

istio operator 를 helm 으로 설치한다.

istio 는 control plane 을 canary upgrade  가 가능하도록 revision tag 로 구분할 수 있게 권장하고 있다. 그리고 istio-operator 네임스페이스에 operator 를 설치하고, istio-system 네임스페이스에 istio control plane 을 설치한다.

operator 를 생성할 때 istio-operator 네임스페이스는 자동으로 생성되나 istio-system 네임스페이스는 operator 를 설치하기 전에 수동으로 생성해 놓아야 한다.

2. istio control plane 설치

istio control plane 은 istiod 라는 pod 로 설치된다. operator 가 있으므로 아래와 같이 custom resource 를 생성하면 자동으로 istio control plane 이 설치되는 구조이다.

custom resource 를 아래와 같이 생성한다.

• revision 은 control plane 을 구별하기 위해서 사용한다.
• meshConfig 는 istiod 와 envoy proxy 가 서로 연결되는 정보를 나타내며 discoveryAddress 는 control plane 인 istiod 의 service url 을 tracing 은 Jaeger 정보를 저장할 데이터소스 url 이다. 여기서는 jaeger tracing backend 로 elastic search 를 사용하고 있다. meshConfig 의 값은 istiod 가 설치되는 istio-system 네임스페이스에 istiod-1-9-1 이라는 이름의 ConfigMap 으로 저장된다.
• components 는 pilot(istiod), ingressGateway, egressGateway 에 대한 설치 정보이다. hpa 로 auto scaling 을 활용하기 위해서는 kubernetes cluster 에 metric-server 가 설치되어 있어야 한다.

아래와 같이 custom resource 를 생성한다.

사전에 node-selector 로 어느 서버에 istiod 와 gateway 를 설치할 수 있는지 지정할 수 있다.

설치 현황은 아래 명령으로 확인할 수 있다.

3. 서비스별 gateway 추가 설치

gateway 는 서비스별로 추가할 수 있다. 이 또한 custom resource 만 생성하면 되며 custom resource 는 아래와 같다.

• profile 값은 empty 로 지정한다. empty 는 istiod 를 설치하지 않겠다는 뜻이다.
• Gateway  에 label 은 중요하다. default label 값은 app=istio-ingressgateway 와 istio=ingressgateway 이다. Gateway 를 여러개 설치하면 서비스별로 VirtualService 와 연결해야 하는데 이 때 활용되는 것이 label 이다. 그러니 Gateway 별로 구별할 수 있게 label 을 서로 다르게 주는 것이 중요하다.
• 새로운 네임스페이스에 생성된 Gateway 에 istiod 와 연결할 url 정보를 주는 것이 중요하다. 그런데 그 정보를 갖고 있는 meshConfig 에 넣어도 새로운 네임스페이스에 istio-1-9-1 ConfigMap 이 생성되지 않는다. 그래서 istio-1-9-1 ConfigMap 은 수동으로 설치해 주어야 한다.

Gateway 를 설치할 네임스페이스 생성과 그 네임스페이스에 istio-system 에 있는 istio-1-9-1 ConfigMap 을 복사하여 생성한다.

custom resource 를 생성하여 Gateway 를 추가로 설치한다.

설치된 정보를 확인한다.

4. sidecar auto injection 을 위한 레이블 설정

Istio 를 Operator 를 사용해서 revision 값을 주면 sidecar 를 자동으로 injection 하기 위해서 더이상 istio-injection=enabled 와 같은 Label을 쓰지 않는다. 위에 처럼 label 을 변경줘야 한다. istio-injection=enabled 으로 설명하는 문서들이 있으면 demo 와 같은 simple 한 설치이거나 이전 설치 방법이다.

$ kubectl label ns default istio-injection=enabled # 소용없음
$ kubectl label ns default istio.io/rev=1-9-1

Jager 와 kiali 는 다음에...

마이크로서비스 아키텍처를 공부하다 보면 Circuit Breaker 에 대해서 알게 된다.

여태까지 나는 Circuit Breaker 는 단순히 서비스를 차단해주는 역할을 주라고 생각했는데 그게 아니었음.. ㅠㅠ

Circuit Breaker 의 진정한 목적은 Backpressure 를 downstream 에 적용하는 것이라고 할 수 있다. (apply backpressure downstream)

Backpressure 의 의미는 아래 글을 참조..

medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7

간단히 설명하면 A, B, C 라는 서비스가 각각 D 라는 하나의 서비스를 호출한다고 가정하자. 이 때 D 서비스의 처리량 이상을 A 서비스가 호출한다면, B, C 서비스도 더이상 D 서비스를 호출하여 응답을 받을 수 없다. 그래서 A 서비스가 D를 호출하는 것을 buffer 에 저장하여 잠시 늦추는 효과를 준다면 D 서비스는 이상없이 동작하게 되고 B, C 서비스도 정상적인 응답을 받을 수 있다.

여기서 A서비스에 적용한 것이 Backpressure 이다.

Backpressure 를 적용하기 위한 전략은 다음과 같다.

• Control the producer (slow down/speed up is decided by consumer)
• Buffer (accumulate incoming data spikes temporarily)
• Drop (sample a percentage of the incoming data)

오늘 하나 더 배움에 감사하며~~

CNCF Project 에 대한 내용을 간략한 아이콘 및 다이어 그램으로 설명한 자료입니다.

웬만한 프로젝트는 모두 보여준 듯 하네요. ^^

drive.google.com/file/d/1-uS_jEKakOUxjYKYV1CH3z7CYqOuqrPx/view?usp=sharing

KubeCon 2일째 주요 Keynote 내용은 OpenTelemetry, Scalable Kubernetes Cluster, CNCF Tools 입니다.

먼저 OpenTelemetry 에서는 아래의 내용들을 이야기 했죠.

OpenTelemetry 는 2019년에 발표했는데 OpenCensus 와 OpenTracing 을 합쳤습니다.

OpenTelemetry 가 나온 이유 중 하나는 Vendor lock in 을 피하기 위해서입니다.

개념은 아주 간단합니다. Collector 간의 연결입니다.

데이터 수집 -> 변경 -> 보내기 형태의 pipeline 구조로 구성됩니다.

Collector 가 multiple flow 를 받을 수 있습니다.

아래 OpenTelemetry 를 방문하면 더 많은 정보를 얻을 수 있습니다.

Scalable Kubernetes Cluster 는 여러 가지 고려 사항을 이야기 했습니다.

15,000 노드 클러스터인 경우에 고려할 사항은 etcd 입니다.

모든 정보가 etcd 에 저장될 텐데 그것을 처리할 수 있는 용량을 항상 고려해야 합니다.

apimachinery 도 고려해야 합니다.

많은 리소스들이 저장되어 있는데 이 중에서 리소스를 select 를 할 때 적절하게 조회하고 이를 관리할 수 있는 API 용량이 필요합니다.

Networking 부분에서는 돌아다니는 데이터 양을 고려해야 합니다.

Kube-proxy 가 노드마다 떠 있고 endpoint 가 수정될 때 마다 이를 api 서버로 보냅니다. 예를 들어 5000개의 서비스 pod 가 떠 있다면 1M 정도의 데이터 양을 보내는데 노드가 5000개 있다면 보내는 데이터 양은 5G 나 됩니다.

이를 해결하기 위해서 endpoint slicing 을 사용합니다.

Secret 과 ConfigMap 이 pod 가 생성되는 로컬에 저장되는 스토리지도 고려해야 합니다.

Contour, A High Performance Multitenant Ingress Controller for Kubernetes - MICHAEL MICHAEL, Steve Sloka, Nick Young, & James Peach, VMware

Kubernetes 에서 north-south 네트워크로 Ingress Controller 는 필수 입니다.

대부분은 Nginx Ingress Controller 를 사용할 텐데 CNCF Incubating Project 로 Contour 를 사용할 수 있습니다.

Contour 는 Envoy 를 중심으로 개발되었네요.

Craig 가 구글에서 나와서 만든 Heptio 에서 시작한 프로젝트인데 지금은 bitnami 가 지원하고 있는 것 같습니다.

​

아키텍처는 다음과 같습니다.

​

세부적인 내용은 https://projectcontour.io/ 를 확인하세요.

소스 Contributing 은 https://github.com/bitnami/charts/tree/master/bitnami/contour  이곳입니다. ^^

1. Diversity-Powered Reilience - Priyanka Sharma

Cloud Native Network Functions (CNF) Working Group Kick off

2. Keynote: Are Certifications Worth It? - Cheryl Hung

Certified Kubernetes Security Specialist 신규

3. The Cloud Native Journey @Apple - Alena Prokharchyk, Software Engineer, Apple

Apple  에서 Mesos -> Kubernetes 로 옮겨온 이유

애플에서 사용한 CNCF 프로젝트

현재 개발 우선순위

조직 변화

배운 내용

AWS 기반으로 CodeCommit 과 연동하여 개발을 하다보면 Windows 기반의 Eclipse 연동을 주로 사용합니다.

AWS 에서 IntelliJ 가 아닌 Eclipse plugin 을 사용하라고 가이드 하는 것은 아마도 Eclipse 가 오픈소스 IDE 툴 이기 때문에 aws plugin 을 만들어서 배포하기데 적절하기 때문이 아닌가 하고 생각이 드네요.

저는 Mac 기반의 Eclipse 를 사용하는데 AWS CodeCommit 과 연동시키는데 몇시간을 고생해서 해결한 내용을 설명하고자 합니다.

Eclipse 를 설치하기 전에 먼저 JDK 가 설치되어야 하는데, 이전 글에서 Mac 에 JDK 를 설치하는 것은 설명을 드렸습니다.

다음으로 Eclipse 설치는 그냥 Applications 아이콘에 복사만 하면 되므로 Eclipse 설치는 생략...

Eclipse 에서 AWS toolkt 설치는 "메뉴 >> Help >> Install New Software..." 창을 띄우고 "Work with" 레이블이 있는 Text 상자에  "https://aws.amazon.com/eclipse/site.xml" 를 입력해서 software 를 설치하면 됩니다.

​

AWS CodeCommit 을 사용하기 위해서는 "IAM >> Users" 의 Security Credentials 탭에서 "HTTPS Git credentials for AWS CodeCommit" 항목에 사용자를 등록하면 사용할 수 있습니다.

그리고 AWS CodeStar 에서 Project 를 하나 만들면, CodeCommit Repository 가 생성이 되고,  이 Project 의 Team 메뉴에 위의 IAM User 를 할당해 주면 해당 User 가 CodeCommit 을 사용할 수 있습니다. 

​

이제 Eclipse 의 주황색 아이콘을 클릭해서 CodeCommit 의 repository 로 부터 소스를 받아오겠습니다.

​

AWS Access Key ID, Secret Access Key 를 넣고 region 을 선택합니다. 그리고 CodeCommit 의 git id 와 패스워드를 입력하면 소스를 다운받을 수 있습니다.

​

하지만 다운을 받다가 에러가 발생하면서 실패하게 됩니다.

이 부분에서 고생을 많이 했었는데..

1. 처음에는 Oracle Java 에서 나는 문제로 오해해서 Mac 에 OpenJDK 를 설치했습니다. 그리고 Eclipse 를 띄울 때 OpenJDK 를 사용할 수 있게 수정했습니다.

그래도 똑같은 에러가 발생했습니다.

2. 그래서 JGit 의 버그로 생각하고 5.9 버전에서 낮은 버전으로 다시 설치했습니다.

그래도 에러가 발생.

3. IAM User 에서 https git credential 을 지우고 다시 생성하면 된다고 구글리에 나와 있어서 다시 했지만 또 에러.

마지막으로 아래 부분을 적용했더니 해결.

4. Eclipse "Preferences > General > Security > Secure Storage" 에서 OS X keystore 연동 체크박스를 해제

결국은 Mac 에서 keychain 연동할 때 eclipse 의 security storage 와의 이슈 때문이었습니다.

별거 아니지만 계속 고생할 수 있는 분들이 있을 거 같아 기록으로 남겨 봅니다. ^^

어제 AWS VPC 네트워크의 개념에 대해서 배워서 정리해 봤습니다.

저는 OpenStack 을 오랫동안 해왔기 때문에 OpenStack 의 Neutron 로 비교하면 이해가 더 쉽게 되더라고요.

먼저 네트워크 대역을 만들기 위해서는 VPC 가 필요합니다. virtual 하게 만드는 것이기 때문에 10.0.0.0/16 과 같이 사설망 대역을 사용합니다.

그리고 외부와의 통신을 위해서는 Internet gateway (IGW)를 생성합니다. 이것은 software gateway 라고 생각이 들고 여기까지는 VPC 와 상관이 없습니다. 그래서 이해하기 쉽게 IGW 를 VPC 바깥에 그렸습니다.

IGW 를 VPC 와 연결 (associate) 하는 순간에 port 가 생성되어 연결될 것으로 보입니다.

VPC 내에는 subnet 을 만들어 Network 대역을 다시 나눌 수 있는데 subent 은 10.0.0.0/24 처럼 VPC 대역 내여야 하고, 하나의 subent 은 AZ 의 하나에만 할당될 수 있습니다. AZ 내에 하나만 할 당 할 수 있는 이유는 EC2 VM 을 만들면 VPC 내의 Subnet 을 선택하고, VM에 ip 를 할당하면서 해당 IP 에 대해서 s/w 적으로 연결이 될텐데 여러 AZ 에 대역이 펼쳐져 있으면 통신이 꼬일 수 밖에 없습니다.

그러므로 실제로 중요한 것은 VPC 라기 보다는 Subnet 입니다. Subnet 의 정보를 가지고 다 처리를 하는데 다만 통합적으로 관리할려고 VPC 라는 개념을 가져온 것 뿐입니다. 

Subnet 은 라우팅을 잡아야 하는데, 내부적으로는 VM 을 관리하는 Baremetal Host 서버에 라우팅을 세팅하기 위한 방법이 필요합니다. (혹은 Baremetal 에 떠 있는 software network switch 에서 라우팅을 세팅)

그래서 라우팅 테이블을 만들고 Subnet 에 연결(assocation) 해주면 그 라우팅 정보를 가지고 있다가 VM 이 생성될 때 세팅을 해줄 수 있습니다.

정리해보면 다음과 같습니다.

1. IGW 는 VPC 에 attach 하는 부분이 필요하다. (router 에서 인터넷으로 가는 GW port 를 연결하는 작업)

2. Route table 을 Subnet 에 association 하는 부분이 필요하다 ( VM 이 생성될 때 통신될 수 있도록 라우팅을 세팅해야 하므로 해당 정보를 이용)

AWS 가 내부적으로 어떻게 구성되어 있는 지는 모르겠습니다. 하지만 OpenStack Neutron 을 보면 저런 방법을 사용하고 있기 때문에 아마도 동작 방식은 비슷하지 않을까 생각합니다.

며칠 전 Kubernetes Cluster 를 v1.16.3 에서 v1.18.5 로 업그레이드 하다가 발견된 이슈를 해결한 내용을 공유합니다.

제가 관리하고 있는 Kubernetes 는 Kubespray 로 설치했었고 업그레이드 역시 Kubespray 를 활용했습니다.

Kubespray 는 Kubernetes 설치에 kubeadm 을 사용하는데 kubeadm 은 마이너 버전 차이가 1 을 초과하면 업그레이드를 지원하지 않습니다.

그렇기 때문에 v1.16.x 에서 v1.18.x 로 업그레이드를 하려며 v1.16.x -> v1.17.x -> v1.18.x 로 단계적으로 업그레이드를 해야 합니다.

기존 설치된 버전은 kubespray 의 release-2.12 브랜치로 v1.16.3 이었고,  kubespray tags/v2.13.2 을 활용하면 v1.17.7 로 업그레이들 할 수 있습니다.

## deploy 디렉토리로 변경

$ cd ~/deploy/kubespray

## kubespray 다운로드 (tag 로 할 때)

$ git checkout master

$ git pull

$ git checkout -b tag_v2.13.2 tags/v2.13.2

$ sudo pip install -r requirements.txt

## inventory 복사 (업그레이드 할 때)

$ rm -rf inventory/k1-seungkyua/group_vars/*

$ cp -r inventory/sample/group_vars inventory/k1-seungkyua

## hosts.ini 수정

$ vi inventory/k1-seungkyua/inventory.ini

[all]

k1-master01 ansible_host=k1-master01 ip=192.168.30.13 iface=eno49

k1-master02 ansible_host=k1-master02 ip=192.168.30.14 iface=ens2f0

k1-master03 ansible_host=k1-master03 ip=192.168.30.15 iface=eno49

k1-node01 ansible_host=k1-node01 ip=192.168.30.12 iface=ens2f0

k1-node02 ansible_host=k1-node02 ip=192.168.30.17 iface=ens2f0

k1-node03 ansible_host=k1-node03 ip=192.168.30.18 iface=ens2f0

k1-node04 ansible_host=k1-node04 ip=192.168.30.21 iface=ens2f0

k1-node05 ansible_host=k1-node05 ip=192.168.30.20 iface=ens2f0

[etcd]

k1-master01

k1-master02

k1-master03

[kube-master]

k1-master01

k1-master02

k1-master03

[kube-node]

k1-node01

k1-node02

k1-node03

k1-node04

k1-node05

[calico-rr]

[k8s-cluster:children]

kube-master

kube-node

calico-rr

## k8s-cluster.yml 수정

$ vi inventory/k1-seungkyua/extra-vars.yml

enable_nodelocaldns: false

# 신규 설치시에만 세팅

# skydns_server: "{{ kube_service_addresses|ipaddr('net')|ipaddr(10)|ipaddr('address') }}"

kube_proxy_mode: ipvs

# hostname and hosts file

populate_inventory_to_hosts_file: false

override_system_hostname: false

# Helm deployment

helm_enabled: true

## copy admin.conf

kubeconfig_localhost: true

kubectl_localhost: true

## calico setting

ipip_mode: Never

peer_with_router: true

nat_outgoing: true

global_as_num: "65000"

peers:

  - router_id: "192.168.30.1"

    as: "65000"

# calico_ip_auto_method: "interface=eth.*"

# calico_ip_auto_method: "interface=ens6"

calico_ip_auto_method: "can-reach=8.8.8.8"

kubeadm_enabled: true

docker_insecure_registries:

  - tacorepo:5000

dashboard_enabled: true

# Local volume provisioner deployment

local_volume_provisioner_enabled: true

metrics_server_enabled: true

## rbd provisioner deployment

rbd_provisioner_enabled: true

rbd_provisioner_monitors: 192.168.30.23:6789,192.168.30.24:6789,192.168.30.25:6789

rbd_provisioner_pool: kubes

rbd_provisioner_secret: QVFBTmRVVlh5UmZoTlJBQTMyZTh6Qk5uajV1VElrMDJEbWFwWmc9PQ==

rbd_provisioner_user_secret: QVFDdC9CcFlpZ0o3TVJBQTV2eStjbDM5RXNLcFkzQyt0WEVHckE9PQ==

저의 경우에는 calico 를 활용하여 switch 와 bgp 로 통신하므로 bgp 설정을 넣었습니다.

## k8s 업그레이드 수행

$ ansible-playbook -e @inventory/k1-seungkyua/extra-vars.yml -b -f 30 -i inventory/k1-seungkyua/inventory.ini upgrade-cluster.yml

업그레이드를 돌리면 순차적으로 drain 과 uncordon 을 수행하는데 중간에 에러가 날 경우에는 kubelet 을 업그레이드 이전 버전으로 돌려놓아야 합니다.

예를 들어, master02 를 업그레이드 하다가 에러가 나면 아래의 작업을 수행해 줘야 합니다.

1. 에러가 나도 kubelet 의 버전은 올라가므로 kubelet 버전을 업그레이드 이전으로 다운그레이드 해야 합니다. 쉬운 방법은 다른 노드에 있는 kubelet 을 복사해서 kubelet 을 restart 해야 합니다.

systemctl restart kubelet

2. schedule 이 disabled 되어 있을 수 있으니 uncordon 해줘야 합니다.

kubectl uncordon k1-master02

## 업그레이드 시 에러 날 경우

PodDisruptionBudget 을 확인해야 함

istio 의 MIN AVAILABLE 은 전부 0 으로 세팅

elasticsearch 는 삭제

# kubectl get PodDisruptionBudget -A

NAMESPACE      NAME                          MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE

istio-system   istio-egressgateway           1               N/A               0                     76d

istio-system   istio-galley                  1               N/A               0                     76d

istio-system   istio-ingressgateway          1               N/A               0                     76d

istio-system   istio-pilot                   1               N/A               0                     76d

istio-system   istio-policy                  1               N/A               0                     76d

istio-system   istio-telemetry               1               N/A               0                     76d

logging        elasticsearch-k1-master-pdb   N/A             1                 0                     71d

Master의 root 디렉토리 확인

/root/.kube/http-cache 디렉토리 삭제

/root/.docker/config 파일 삭제 (도커 로그인정보를 가지고 있어서 docker pull 이 안될 수 있음)

coreDNS 가 10.233.0.3 이면 kubeadm 에서 coreDNS 는 10.233.0.10 이어야 한다는 업그레이드 에러 발생

kubeadm 명령어에 --print-config 옵션을 붙혀서 미리 한 번 실행하여 이상이 없는지 확인

# kubeadm upgrade apply -y v1.17.7 --config=/etc/kubernetes/kubeadm-config.yaml --ignore-preflight-errors=all --allow-experimental-upgrades --allow-release-candidate-upgrades --etcd-upgrade=false --certificate-renewal=true --force --v=9 --print-config

실행에 이상이 없으면 kubespray 의 roles/kubernetes/master/tasks/kubeadm-upgrade.yml 에 해당 옵션을 추가

kubelet upgrade 시에 에러가 발생하였음.

kubelet 버전은 v1.16.3 에서 v1.17.7 로 업그레이드가 되었으나 기존 옵션으로 kubelet 이 start 시에 에러가 남

kubelet --version 으로 v1.17.7 이면 v1.16.3 으로 kubelet 을 다시 복사하고 Kubelet restart

Istio 에 대한 문의도 있었고 또 모르시는 분들이 계셔서 글을 올립니다.

Istio 는 Kubernetes 에만 올릴 수 있고 Control plane 이 여러 pod 로 구성되어 있습니다.

1.4 버전까지는 아래 다이어그램에서 보이듯이 Control 에 해당하는 컴포넌트들이 각각의 프로세스로 실행되었습니다.  

​

하지만 1.5 버전 부터는 (현재는 1.6 버전이 최신입니다) 아래와 같이 New Architecture 로 변경되었습니다.

​

모든 컴포넌트가 istiod 라는 하나의 프로세스로 합쳐지고 Mixer 가 없어지고 Pilot 이 Mixer 의 기능까지도 함께 수행하는 것으로 되어 있습니다.

Istio 에서는 각 서비스를 관리하는 것도 중요하지만 사실 더 중요한 것은 여기 다이어그램에는 표시되지 않은 Ingress traffic 을 처리하는 Gateway 서버입니다. 모든 트래픽을 받아는 주는 관문 역할을 해야 하고, 백엔드의 Envoy Proxy 와도 연계되어야 하기 때문에 Isito 를 도입한다면 중요하게 고려되어야 할 서비스입니다. 

Istio 를 설치하는 방법은 아래 두가지 방법으로 하는 것이 편리합니다.

1. Download Istio

https://istio.io/latest/docs/setup/getting-started/

Istio 를 다운받아 istioctl 로 Configure Profile 을 활용하여 설치하는 방법입니다.

2. Standalone Operator Install

https://istio.io/latest/docs/setup/install/standalone-operator/

Istio Operator 를 설치하고 이를 기반으로 Istio 를 설치하는 방법입니다.