SlideShare a Scribd company logo

이스티오 (Istio) 자습서 v0.5.0

Jo Hoon
Jo Hoon

이스티오를 셀프스터디하기 위한 목적으로 작성된 문서입니다. 원래 v1.0.0을 2023년에 내려고 했는데 여러가지 업무가 많아서 현재 상태로 우선 릴리즈합니다.

1 of 73
Download to read offline
이스티오 (Istio)
이스티오를 설명하는 자습서 (v0.5.0)
이스티오는 서비스 메시 도구로서 트래픽 관리, 옵저빌리티와 같은 기능을
제공합니다. istioctl을 통해 간편하게 설치할 수 있으며, CRD를 통해서도 설치가
가능하다는 장점이 있습니다. VirtualService와 Gateway를 통해 인그레스 트래픽을
처리할 수 있으며, 중간에 filter를 활용해서 트래픽 제어가 가능합니다. 같이 배포되는
키알리(Kiali)i 대시보드를 통해 서비스 트래픽 흐름을 웹 UI로 확인할 수 있습니다.
이스티오 사용 시 사이드카 패턴을 파드에 적용하여 엔보이(Envoy) 프록시가 붙기 때문에
CPU나 메모리 추가로 리소스를 사용한다는 우려가 있습니다. 최근 추가된 기능인
이스티오 엠비언트 메시(Ambient Mesh) 를 통해서 엔보이 프록시가 사이드카 패턴으로
파드에 붙는 구조가 아닌 노드에 ztunnel(제로 트러스트 터널)이라는 데몬을 통해서,
쿠버네티스 클러스터가 사용가능한 CPU와 메모리를 절감하면서 서비스 메시 구성이
가능합니다.
[그림 1] 키알리 대시보드를 통해서 확인되는 서비스 트래픽 흐름
1. 이스티오 배포
이스티오를 배포하는 방법은 크게 2가지로 나눌 수 있습니다.
2
직접 배포하거나, 관리형 또는 설치형으로 패키지되어 있는 제품을 사용하는 것입니다.
[그림 2] 업체마다 관리형 또는 설치형으로 패키지되어 있는 이스티오
(https://istio.io/latest/about/ecosystem/)
따라서 이 문서에서는 범용성을 위해서 직접 설치/배포 하는 방법으로 진행하도록 하겠습니다.
1.1. 이스티오 요구 사항
이스티오 설치를 위해 다양한 요구 사항이 있으나, 대부분의 CSP 및 on-prem 환경에서는 이를
충족합니다. 하지만 구성에 따라 Port를 선택적으로 구성해야 해야 할 수 있으니 확인을
먼저하는 것이 좋습니다.
3
일반적으로 이 부분 보다 구성시에 생각보다 많이 발생하는 CPU와 Memory에 대한 고려가
필요하며, 이스티오 구성시에 함께 구성되는 애플리케이션에 대한 고려가 더 중요합니다.
예를 들면 프로메테우스(Prometheus)가 기존에 배포된 것이 있다면 이스티오 구성에서 이를
제외하고 기존 것에서 메트릭을 가지고 오도록 구성해야 합니다.
이스티오 1.16.1을 기준으로 이스티오 배포시에 다음과 같은 리소스를 사용하며,
애플리케이션에 따라 사용하는 리소스는 균등하게 증가하게 됩니다.
이스티오 설치 전 (e2-standard-2 / 2 vCPU, 8GB)
➜ ~ (☸️ |hj-istio-classic:default) kubectl top node --use-protocol-buffers
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
gke-istio-classic-p-e5ef5921-o0yt 112m 5% 668Mi 11%
gke-istio-classic-p-e5ef5921-osfg 68m 3% 611Mi 10%
gke-istio-classic-p-e5ef5921-vp1c 68m 3% 616Mi 10%
이스티오 설치 후 (e2-standard-8 / 8 vCPU, 32GB)
➜ ~ (☸️ |hj-gke-istio:default) k top node --use-protocol-buffers
NAME CPU(cores) CPU% MEMORY(bytes)
MEMORY%
gke-istio-pool-default-pool-79cada87-8x1m 99m 1% 817Mi 2%
gke-istio-pool-default-pool-79cada87-r03v 110m 1% 800Mi 2%
1.2. 이스티오 배포 모델
이스티오는 다음과 같이 단일 클러스터로 구성도 가능합니다.
[그림 3] 1개의 서비스 메시로 단일 클러스터를 관리
4
하지만 실무 환경에서 고가용성(HA, High Availability)를 고려한다면 멀티 클러스터 구성하는
것이 좋습니다.
[그림 4] 1개의 서비스 메시로 멀티 클러스터를 관리
5
이에 대한 자세한 예제는 다음의 링크를 참조하시기 바랍니다.
1.3. 이스티오 설치
이스티오는 일반적으로 istioctl을 통해서 진행합니다.
따라서 istioctl 바이너리를 내려받아야 하는데, 다음과 같은 방법으로 이를 내려 받습니다.
1.3.1 내려받을 디렉터리로 이동합니다. 현재는 홈디렉터리를 이용합니다.
➜ ~ (☸️ |hj-istio-classic:default) cd ~
1.3.2 istioctl을 포함한 패키지를 내려받습니다.
➜ ~ (☸️ |hj-istio-classic:default) curl -L https://istio.io/downloadIstio
| ISTIO_VERSION=1.16.1 TARGET_ARCH=x86_64 sh -
6

Recommended

MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法Tetsutaro Watanabe
 
[OpenInfra Days Korea 2018] Day 2 - CEPH 운영자를 위한 Object Storage Performance T...
[OpenInfra Days Korea 2018] Day 2 - CEPH 운영자를 위한 Object Storage Performance T...[OpenInfra Days Korea 2018] Day 2 - CEPH 운영자를 위한 Object Storage Performance T...
[OpenInfra Days Korea 2018] Day 2 - CEPH 운영자를 위한 Object Storage Performance T...OpenStack Korea Community
 
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
 
kube-system落としてみました
kube-system落としてみましたkube-system落としてみました
kube-system落としてみましたShuntaro Saiba
 
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティスAmazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティスAmazon Web Services Japan
 
確実な再起動からはじめる クラウドネイティブオペレーション
確実な再起動からはじめる クラウドネイティブオペレーション確実な再起動からはじめる クラウドネイティブオペレーション
確実な再起動からはじめる クラウドネイティブオペレーションToru Makabe
 

More Related Content

What's hot

[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기
[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기
[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기YongSung Yoon
 
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築Junji Nishihara
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティスAmazon Web Services Japan
 
MySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことMySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことyoku0825
 
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal3分でわかるAzureでのService Principal
3分でわかるAzureでのService PrincipalToru Makabe
 
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤Amazon Web Services Japan
 
ワタシハ Azure Functions チョットデキル
ワタシハ Azure Functions チョットデキルワタシハ Azure Functions チョットデキル
ワタシハ Azure Functions チョットデキルTsuyoshi Ushio
 
elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리Junyi Song
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報Masahiko Sawada
 
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)NTT DATA Technology & Innovation
 
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?VMware Tanzu Korea
 
Planet-scale Data Ingestion Pipeline: Bigdam
Planet-scale Data Ingestion Pipeline: BigdamPlanet-scale Data Ingestion Pipeline: Bigdam
Planet-scale Data Ingestion Pipeline: BigdamSATOSHI TAGOMORI
 
FIWARE勉強会 20190913
FIWARE勉強会 20190913FIWARE勉強会 20190913
FIWARE勉強会 20190913Nobuyuki Matsui
 
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデートAmazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデートAmazon Web Services Japan
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンKentaro Yoshida
 
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会ShuheiUda
 

What's hot (20)

MongoDB Oplog入門
MongoDB Oplog入門MongoDB Oplog入門
MongoDB Oplog入門
 
[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기
[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기
[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기
 
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
 
MongoDBの監視
MongoDBの監視MongoDBの監視
MongoDBの監視
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
 
MySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことMySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいこと
 
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal
 
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
 
いまさら聞けないPostgreSQL運用管理
いまさら聞けないPostgreSQL運用管理いまさら聞けないPostgreSQL運用管理
いまさら聞けないPostgreSQL運用管理
 
Amazon ElastiCacheのはじめ方
Amazon ElastiCacheのはじめ方Amazon ElastiCacheのはじめ方
Amazon ElastiCacheのはじめ方
 
ワタシハ Azure Functions チョットデキル
ワタシハ Azure Functions チョットデキルワタシハ Azure Functions チョットデキル
ワタシハ Azure Functions チョットデキル
 
elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
 
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
 
Planet-scale Data Ingestion Pipeline: Bigdam
Planet-scale Data Ingestion Pipeline: BigdamPlanet-scale Data Ingestion Pipeline: Bigdam
Planet-scale Data Ingestion Pipeline: Bigdam
 
FIWARE勉強会 20190913
FIWARE勉強会 20190913FIWARE勉強会 20190913
FIWARE勉強会 20190913
 
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデートAmazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
 
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
 

Similar to 이스티오 (Istio) 자습서 v0.5.0

Hyperledger fabric practice(pdf)
Hyperledger fabric practice(pdf)Hyperledger fabric practice(pdf)
Hyperledger fabric practice(pdf)wonyong hwang
 
Build the OpenStack Cloud with Neutron Networing, IceHouse
Build the OpenStack Cloud with Neutron Networing, IceHouseBuild the OpenStack Cloud with Neutron Networing, IceHouse
Build the OpenStack Cloud with Neutron Networing, IceHousejieun kim
 
Hyperledger Fabric practice (v2.0)
Hyperledger Fabric practice (v2.0) Hyperledger Fabric practice (v2.0)
Hyperledger Fabric practice (v2.0) wonyong hwang
 
Nginx basic configurations
Nginx basic configurationsNginx basic configurations
Nginx basic configurationsJohn Kim
 
ARTIK 710 IoT class 02
ARTIK 710 IoT class 02ARTIK 710 IoT class 02
ARTIK 710 IoT class 02정출 김
 
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트OpenStack Korea Community
 
도커(Docker) 메트릭스 & 로그 수집
도커(Docker) 메트릭스 & 로그 수집도커(Docker) 메트릭스 & 로그 수집
도커(Docker) 메트릭스 & 로그 수집Daegwon Kim
 
시스템/네트워크 관리자가 바로 쓸 수 있는 파이썬
시스템/네트워크 관리자가 바로 쓸 수 있는 파이썬시스템/네트워크 관리자가 바로 쓸 수 있는 파이썬
시스템/네트워크 관리자가 바로 쓸 수 있는 파이썬위키북스
 
하이퍼레저 패브릭 데이터 구조
하이퍼레저 패브릭 데이터 구조하이퍼레저 패브릭 데이터 구조
하이퍼레저 패브릭 데이터 구조Logpresso
 
Kubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideKubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideChan Shik Lim
 
Python socket programming
Python socket programmingPython socket programming
Python socket programmingTae Young Lee
 
Actual PoC guide for Virtual Desktop Infrastructure (Korean)
Actual PoC guide for Virtual Desktop Infrastructure (Korean)Actual PoC guide for Virtual Desktop Infrastructure (Korean)
Actual PoC guide for Virtual Desktop Infrastructure (Korean)Changhyun Lim
 
오픈소스로 만드는 DB 모니터링 시스템 (w/graphite+grafana)
오픈소스로 만드는 DB 모니터링 시스템 (w/graphite+grafana)오픈소스로 만드는 DB 모니터링 시스템 (w/graphite+grafana)
오픈소스로 만드는 DB 모니터링 시스템 (w/graphite+grafana)I Goo Lee
 
PCF Installation Guide
PCF Installation GuidePCF Installation Guide
PCF Installation Guideseungdon Choi
 
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)Osc Osc
 
oVirt installation guide_v4.3
oVirt installation guide_v4.3oVirt installation guide_v4.3
oVirt installation guide_v4.3CheolHee Han
 
Apache Tomcat ( 아파치 톰캣 ) 설치 가이드
Apache Tomcat ( 아파치 톰캣 ) 설치 가이드Apache Tomcat ( 아파치 톰캣 ) 설치 가이드
Apache Tomcat ( 아파치 톰캣 ) 설치 가이드Opennaru, inc.
 
OpenStack DevStack Install - 2부 (Multi-nodes)
OpenStack DevStack Install - 2부 (Multi-nodes)OpenStack DevStack Install - 2부 (Multi-nodes)
OpenStack DevStack Install - 2부 (Multi-nodes)Ian Choi
 

Similar to 이스티오 (Istio) 자습서 v0.5.0 (20)

Hyperledger fabric practice(pdf)
Hyperledger fabric practice(pdf)Hyperledger fabric practice(pdf)
Hyperledger fabric practice(pdf)
 
Build the OpenStack Cloud with Neutron Networing, IceHouse
Build the OpenStack Cloud with Neutron Networing, IceHouseBuild the OpenStack Cloud with Neutron Networing, IceHouse
Build the OpenStack Cloud with Neutron Networing, IceHouse
 
Kafka slideshare
Kafka   slideshareKafka   slideshare
Kafka slideshare
 
Hyperledger Fabric practice (v2.0)
Hyperledger Fabric practice (v2.0) Hyperledger Fabric practice (v2.0)
Hyperledger Fabric practice (v2.0)
 
Nginx basic configurations
Nginx basic configurationsNginx basic configurations
Nginx basic configurations
 
ARTIK 710 IoT class 02
ARTIK 710 IoT class 02ARTIK 710 IoT class 02
ARTIK 710 IoT class 02
 
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
 
도커(Docker) 메트릭스 & 로그 수집
도커(Docker) 메트릭스 & 로그 수집도커(Docker) 메트릭스 & 로그 수집
도커(Docker) 메트릭스 & 로그 수집
 
시스템/네트워크 관리자가 바로 쓸 수 있는 파이썬
시스템/네트워크 관리자가 바로 쓸 수 있는 파이썬시스템/네트워크 관리자가 바로 쓸 수 있는 파이썬
시스템/네트워크 관리자가 바로 쓸 수 있는 파이썬
 
OpenStack Swift Debugging
OpenStack Swift DebuggingOpenStack Swift Debugging
OpenStack Swift Debugging
 
하이퍼레저 패브릭 데이터 구조
하이퍼레저 패브릭 데이터 구조하이퍼레저 패브릭 데이터 구조
하이퍼레저 패브릭 데이터 구조
 
Kubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideKubernetes on Premise Practical Guide
Kubernetes on Premise Practical Guide
 
Python socket programming
Python socket programmingPython socket programming
Python socket programming
 
Actual PoC guide for Virtual Desktop Infrastructure (Korean)
Actual PoC guide for Virtual Desktop Infrastructure (Korean)Actual PoC guide for Virtual Desktop Infrastructure (Korean)
Actual PoC guide for Virtual Desktop Infrastructure (Korean)
 
오픈소스로 만드는 DB 모니터링 시스템 (w/graphite+grafana)
오픈소스로 만드는 DB 모니터링 시스템 (w/graphite+grafana)오픈소스로 만드는 DB 모니터링 시스템 (w/graphite+grafana)
오픈소스로 만드는 DB 모니터링 시스템 (w/graphite+grafana)
 
PCF Installation Guide
PCF Installation GuidePCF Installation Guide
PCF Installation Guide
 
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)
 
oVirt installation guide_v4.3
oVirt installation guide_v4.3oVirt installation guide_v4.3
oVirt installation guide_v4.3
 
Apache Tomcat ( 아파치 톰캣 ) 설치 가이드
Apache Tomcat ( 아파치 톰캣 ) 설치 가이드Apache Tomcat ( 아파치 톰캣 ) 설치 가이드
Apache Tomcat ( 아파치 톰캣 ) 설치 가이드
 
OpenStack DevStack Install - 2부 (Multi-nodes)
OpenStack DevStack Install - 2부 (Multi-nodes)OpenStack DevStack Install - 2부 (Multi-nodes)
OpenStack DevStack Install - 2부 (Multi-nodes)
 

More from Jo Hoon

[GitOps] Argo CD on GKE (v0.9.2).pdf
[GitOps] Argo CD on GKE (v0.9.2).pdf[GitOps] Argo CD on GKE (v0.9.2).pdf
[GitOps] Argo CD on GKE (v0.9.2).pdfJo Hoon
 
Prometheus on EKS
Prometheus on EKSPrometheus on EKS
Prometheus on EKSJo Hoon
 
Prometheus on NKS
Prometheus on NKSPrometheus on NKS
Prometheus on NKSJo Hoon
 
[GuideDoc] Deploy EKS thru eksctl - v1.22_v0.105.0.pdf
[GuideDoc] Deploy EKS thru eksctl - v1.22_v0.105.0.pdf[GuideDoc] Deploy EKS thru eksctl - v1.22_v0.105.0.pdf
[GuideDoc] Deploy EKS thru eksctl - v1.22_v0.105.0.pdfJo Hoon
 
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요Jo Hoon
 
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요Jo Hoon
 
CDN on GKE with Ingress
CDN on GKE with IngressCDN on GKE with Ingress
CDN on GKE with IngressJo Hoon
 
The myths of deprecating docker in kubernetes
The myths of deprecating docker in kubernetesThe myths of deprecating docker in kubernetes
The myths of deprecating docker in kubernetesJo Hoon
 
온프레미스 쿠버네티스에서도 로드밸런서를 (w MetalLB)
온프레미스 쿠버네티스에서도 로드밸런서를 (w MetalLB)온프레미스 쿠버네티스에서도 로드밸런서를 (w MetalLB)
온프레미스 쿠버네티스에서도 로드밸런서를 (w MetalLB)Jo Hoon
 
[네전따 27회] 네트워크 자동화 어렵지 않아요
[네전따 27회] 네트워크 자동화 어렵지 않아요[네전따 27회] 네트워크 자동화 어렵지 않아요
[네전따 27회] 네트워크 자동화 어렵지 않아요Jo Hoon
 
[Cook book] ansible 4_dell emc networking
[Cook book] ansible 4_dell emc networking[Cook book] ansible 4_dell emc networking
[Cook book] ansible 4_dell emc networkingJo Hoon
 
Wiki academy sysadmin 10_day
Wiki academy sysadmin 10_dayWiki academy sysadmin 10_day
Wiki academy sysadmin 10_dayJo Hoon
 
Wiki academy sysadmin 4_day
Wiki academy sysadmin 4_dayWiki academy sysadmin 4_day
Wiki academy sysadmin 4_dayJo Hoon
 
Wiki academy sysadmin 3_day
Wiki academy sysadmin 3_dayWiki academy sysadmin 3_day
Wiki academy sysadmin 3_dayJo Hoon
 
Wiki academy sysadmin 2_day
Wiki academy sysadmin 2_dayWiki academy sysadmin 2_day
Wiki academy sysadmin 2_dayJo Hoon
 
Wiki academy sysadmin 1_day
Wiki academy sysadmin 1_dayWiki academy sysadmin 1_day
Wiki academy sysadmin 1_dayJo Hoon
 
Wiki academy sysadmin 9_day
Wiki academy sysadmin 9_dayWiki academy sysadmin 9_day
Wiki academy sysadmin 9_dayJo Hoon
 
Wiki academy sysadmin 8_day
Wiki academy sysadmin 8_dayWiki academy sysadmin 8_day
Wiki academy sysadmin 8_dayJo Hoon
 
Wiki academy sysadmin 7_day
Wiki academy sysadmin 7_dayWiki academy sysadmin 7_day
Wiki academy sysadmin 7_dayJo Hoon
 
Wiki academy sysadmin 6_day
Wiki academy sysadmin 6_dayWiki academy sysadmin 6_day
Wiki academy sysadmin 6_dayJo Hoon
 

More from Jo Hoon (20)

[GitOps] Argo CD on GKE (v0.9.2).pdf
[GitOps] Argo CD on GKE (v0.9.2).pdf[GitOps] Argo CD on GKE (v0.9.2).pdf
[GitOps] Argo CD on GKE (v0.9.2).pdf
 
Prometheus on EKS
Prometheus on EKSPrometheus on EKS
Prometheus on EKS
 
Prometheus on NKS
Prometheus on NKSPrometheus on NKS
Prometheus on NKS
 
[GuideDoc] Deploy EKS thru eksctl - v1.22_v0.105.0.pdf
[GuideDoc] Deploy EKS thru eksctl - v1.22_v0.105.0.pdf[GuideDoc] Deploy EKS thru eksctl - v1.22_v0.105.0.pdf
[GuideDoc] Deploy EKS thru eksctl - v1.22_v0.105.0.pdf
 
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
 
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
 
CDN on GKE with Ingress
CDN on GKE with IngressCDN on GKE with Ingress
CDN on GKE with Ingress
 
The myths of deprecating docker in kubernetes
The myths of deprecating docker in kubernetesThe myths of deprecating docker in kubernetes
The myths of deprecating docker in kubernetes
 
온프레미스 쿠버네티스에서도 로드밸런서를 (w MetalLB)
온프레미스 쿠버네티스에서도 로드밸런서를 (w MetalLB)온프레미스 쿠버네티스에서도 로드밸런서를 (w MetalLB)
온프레미스 쿠버네티스에서도 로드밸런서를 (w MetalLB)
 
[네전따 27회] 네트워크 자동화 어렵지 않아요
[네전따 27회] 네트워크 자동화 어렵지 않아요[네전따 27회] 네트워크 자동화 어렵지 않아요
[네전따 27회] 네트워크 자동화 어렵지 않아요
 
[Cook book] ansible 4_dell emc networking
[Cook book] ansible 4_dell emc networking[Cook book] ansible 4_dell emc networking
[Cook book] ansible 4_dell emc networking
 
Wiki academy sysadmin 10_day
Wiki academy sysadmin 10_dayWiki academy sysadmin 10_day
Wiki academy sysadmin 10_day
 
Wiki academy sysadmin 4_day
Wiki academy sysadmin 4_dayWiki academy sysadmin 4_day
Wiki academy sysadmin 4_day
 
Wiki academy sysadmin 3_day
Wiki academy sysadmin 3_dayWiki academy sysadmin 3_day
Wiki academy sysadmin 3_day
 
Wiki academy sysadmin 2_day
Wiki academy sysadmin 2_dayWiki academy sysadmin 2_day
Wiki academy sysadmin 2_day
 
Wiki academy sysadmin 1_day
Wiki academy sysadmin 1_dayWiki academy sysadmin 1_day
Wiki academy sysadmin 1_day
 
Wiki academy sysadmin 9_day
Wiki academy sysadmin 9_dayWiki academy sysadmin 9_day
Wiki academy sysadmin 9_day
 
Wiki academy sysadmin 8_day
Wiki academy sysadmin 8_dayWiki academy sysadmin 8_day
Wiki academy sysadmin 8_day
 
Wiki academy sysadmin 7_day
Wiki academy sysadmin 7_dayWiki academy sysadmin 7_day
Wiki academy sysadmin 7_day
 
Wiki academy sysadmin 6_day
Wiki academy sysadmin 6_dayWiki academy sysadmin 6_day
Wiki academy sysadmin 6_day
 

이스티오 (Istio) 자습서 v0.5.0

  • 2. 이스티오는 서비스 메시 도구로서 트래픽 관리, 옵저빌리티와 같은 기능을 제공합니다. istioctl을 통해 간편하게 설치할 수 있으며, CRD를 통해서도 설치가 가능하다는 장점이 있습니다. VirtualService와 Gateway를 통해 인그레스 트래픽을 처리할 수 있으며, 중간에 filter를 활용해서 트래픽 제어가 가능합니다. 같이 배포되는 키알리(Kiali)i 대시보드를 통해 서비스 트래픽 흐름을 웹 UI로 확인할 수 있습니다. 이스티오 사용 시 사이드카 패턴을 파드에 적용하여 엔보이(Envoy) 프록시가 붙기 때문에 CPU나 메모리 추가로 리소스를 사용한다는 우려가 있습니다. 최근 추가된 기능인 이스티오 엠비언트 메시(Ambient Mesh) 를 통해서 엔보이 프록시가 사이드카 패턴으로 파드에 붙는 구조가 아닌 노드에 ztunnel(제로 트러스트 터널)이라는 데몬을 통해서, 쿠버네티스 클러스터가 사용가능한 CPU와 메모리를 절감하면서 서비스 메시 구성이 가능합니다. [그림 1] 키알리 대시보드를 통해서 확인되는 서비스 트래픽 흐름 1. 이스티오 배포 이스티오를 배포하는 방법은 크게 2가지로 나눌 수 있습니다. 2
  • 3. 직접 배포하거나, 관리형 또는 설치형으로 패키지되어 있는 제품을 사용하는 것입니다. [그림 2] 업체마다 관리형 또는 설치형으로 패키지되어 있는 이스티오 (https://istio.io/latest/about/ecosystem/) 따라서 이 문서에서는 범용성을 위해서 직접 설치/배포 하는 방법으로 진행하도록 하겠습니다. 1.1. 이스티오 요구 사항 이스티오 설치를 위해 다양한 요구 사항이 있으나, 대부분의 CSP 및 on-prem 환경에서는 이를 충족합니다. 하지만 구성에 따라 Port를 선택적으로 구성해야 해야 할 수 있으니 확인을 먼저하는 것이 좋습니다. 3
  • 4. 일반적으로 이 부분 보다 구성시에 생각보다 많이 발생하는 CPU와 Memory에 대한 고려가 필요하며, 이스티오 구성시에 함께 구성되는 애플리케이션에 대한 고려가 더 중요합니다. 예를 들면 프로메테우스(Prometheus)가 기존에 배포된 것이 있다면 이스티오 구성에서 이를 제외하고 기존 것에서 메트릭을 가지고 오도록 구성해야 합니다. 이스티오 1.16.1을 기준으로 이스티오 배포시에 다음과 같은 리소스를 사용하며, 애플리케이션에 따라 사용하는 리소스는 균등하게 증가하게 됩니다. 이스티오 설치 전 (e2-standard-2 / 2 vCPU, 8GB) ➜ ~ (☸️ |hj-istio-classic:default) kubectl top node --use-protocol-buffers NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% gke-istio-classic-p-e5ef5921-o0yt 112m 5% 668Mi 11% gke-istio-classic-p-e5ef5921-osfg 68m 3% 611Mi 10% gke-istio-classic-p-e5ef5921-vp1c 68m 3% 616Mi 10% 이스티오 설치 후 (e2-standard-8 / 8 vCPU, 32GB) ➜ ~ (☸️ |hj-gke-istio:default) k top node --use-protocol-buffers NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% gke-istio-pool-default-pool-79cada87-8x1m 99m 1% 817Mi 2% gke-istio-pool-default-pool-79cada87-r03v 110m 1% 800Mi 2% 1.2. 이스티오 배포 모델 이스티오는 다음과 같이 단일 클러스터로 구성도 가능합니다. [그림 3] 1개의 서비스 메시로 단일 클러스터를 관리 4
  • 5. 하지만 실무 환경에서 고가용성(HA, High Availability)를 고려한다면 멀티 클러스터 구성하는 것이 좋습니다. [그림 4] 1개의 서비스 메시로 멀티 클러스터를 관리 5
  • 6. 이에 대한 자세한 예제는 다음의 링크를 참조하시기 바랍니다. 1.3. 이스티오 설치 이스티오는 일반적으로 istioctl을 통해서 진행합니다. 따라서 istioctl 바이너리를 내려받아야 하는데, 다음과 같은 방법으로 이를 내려 받습니다. 1.3.1 내려받을 디렉터리로 이동합니다. 현재는 홈디렉터리를 이용합니다. ➜ ~ (☸️ |hj-istio-classic:default) cd ~ 1.3.2 istioctl을 포함한 패키지를 내려받습니다. ➜ ~ (☸️ |hj-istio-classic:default) curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.16.1 TARGET_ARCH=x86_64 sh - 6
  • 7. % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 101 100 101 0 0 366 0 --:--:-- --:--:-- --:--:-- 378 100 4856 100 4856 0 0 8028 0 --:--:-- --:--:-- --:--:-- 8028 Downloading istio-1.16.1 from https://github.com/istio/istio/releases/download/1.16.1/istio-1.16.1-osx.tar.gz ... Istio 1.16.1 Download Complete! Istio has been successfully downloaded into the istio-1.16.1 folder on your system. Next Steps: See https://istio.io/latest/docs/setup/install/ to add Istio to your Kubernetes cluster. To configure the istioctl client tool for your workstation, add the /Users/mz01-hj/tmp/istio-1.16.1/bin directory to your environment path variable with: export PATH="$PATH:/Users/mz01-hj/tmp/istio-1.16.1/bin" Begin the Istio pre-installation check by running: istioctl x precheck Need more information? Visit https://istio.io/latest/docs/setup/install/ 1.3.3 내려받은 디렉터리로 이동한 후에 istioctl을 바로 실행할 수 있도록 istioctl을 실행 디렉터리에 복사합니다. ➜ ~ (☸️ |hj-istio-classic:default) cd istio-1.16.1 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) cp bin/istioctl /usr/local/bin 1.3.4 구성된 istioctl을 버전을 확인하기 위해서 istioctl을 실행합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl version no running Istio pods in "istio-system" 1.16.1 7
  • 8. (optional) 설치 전에 현재 클러스터에 istio를 설치하는데 문제가 있는지 파악하길 원한다면, 다음의 명령어를 수행하시기 바랍니다. . ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl x precheck ✔ No issues found when checking the cluster. Istio is safe to install or upgrade! To get started, check out https://istio.io/latest/docs/setup/getting-started/ 1.3.5 이스티오 설치 이스티오 설치에는 demo 프로파일(profile)을 사용하지만, 테스트 성격에 따라 더 적은 구성 요소를 설치하는 프로파일을 선택할 수 있습니다. 예를 들면 default 프로파일로 진행하는 경우에는 istio-egressgateway가 설치되지 않습니다. 이에 대한 자세한 내용은 설치 후에 설정 부분에서 살펴 보겠습니다. [표 1] 이스티오 프로파일 별 설치되는 구성 요소 (링크) 또한 openshift 와 같은 특정 플랫폼에 적합한 프로파일도 선택 가능합니다. [그림 5] 이스티오 구성을 위한 플랫폼 별 가이드 (링크) 8
  • 9. 그러면 demo 프로파일을 통해서 이스티오를 설치합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl install --set profile=demo -y ✔ Istio core installed ✔ Istiod installed ✔ Ingress gateways installed ✔ Egress gateways installed ✔ Installation complete Making this installation the default for injection and validation. Thank you for installing Istio 1.16. Please take a few minutes to tell us about your install/upgrade experience! https://forms.gle/99uiMML96AmsXY5d6 1.3.6 이스티오가 default 네임스페이스 내에서 동작할 수 있도록 설정 정확히 말하자면 default 네임스페이스 엔보이(Envoy)로 이루어진 사이드카(Sidecar)를 자동으로 삽입할 수 있도록 설정하는 것인데, 필요하다면 수동으로 이를 주입할 수 있습니다. 이에 대해서는 다음의 문서를 참고하시기 바랍니다. 9
  • 10. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl label namespace default istio-injection=enabled namespace/default labeled 1.3.7 설치된 이스티오 구성 요소 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po,svc -n istio-system NAME READY STATUS RESTARTS AGE pod/istio-egressgateway-79598956cf-bk5t6 1/1 Running 0 118s pod/istio-ingressgateway-854c9d9c5f-zpkvr 1/1 Running 0 118s pod/istiod-fd94754fb-6j6bd 1/1 Running 0 2m7s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istio-egressgateway ClusterIP 10.112.12.251 <none> 80/TCP,443/TCP 118s service/istio-ingressgateway LoadBalancer 10.112.12.147 34.67.165.125 15021:32058/TCP,80:31561/TCP,443:30443/TCP,31400:30750/TCP,15443:30994/TCP 118s service/istiod ClusterIP 10.112.15.136 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 2m7s 1.4. 이스티오 동작 확인을 위한 샘플 애플리케이션 배포 및 노출 이스티오의 구성 요소들이 동작하는 것을 확인하기 위해서 샘플 애플리케이션을 배포해 보겠습니다. 배포할 애플리케이션은 이스티오에서 공식적으로 제공하는 bookinfo 이며, 아키텍처는 다음과 같습니다. [그림 6] bookinfo 애플리케이션 기본 아키텍처 [링크] 10
  • 11. 1.4.1 bookinfo 샘플 애플리케이션 배포 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml service/details created serviceaccount/bookinfo-details created deployment.apps/details-v1 created service/ratings created serviceaccount/bookinfo-ratings created deployment.apps/ratings-v1 created service/reviews created serviceaccount/bookinfo-reviews created deployment.apps/reviews-v1 created 11
  • 12. deployment.apps/reviews-v2 created deployment.apps/reviews-v3 created service/productpage created serviceaccount/bookinfo-productpage created deployment.apps/productpage-v1 created [그림 7] bookinfo 애플리케이션에 이스티오 구성 요소가 추가된 아키텍처 [링크] 1.4.2 배포한 bookinfo 애플리케이션 확인 NAME READY STATUS RESTARTS AGE pod/details-v1-5ffd6b64f7-z8drw 2/2 Running 0 38s pod/productpage-v1-979d4d9fc-q7vgf 2/2 Running 0 34s pod/ratings-v1-5f9699cfdf-4p7rn 2/2 Running 0 37s pod/reviews-v1-569db879f5-h2c2m 2/2 Running 0 36s pod/reviews-v2-65c4dc6fdc-k4mhx 2/2 Running 0 35s pod/reviews-v3-c9c4fb987-bcktq 2/2 Running 0 35s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/details ClusterIP 10.112.12.255 <none> 9080/TCP 39s service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 136m service/productpage ClusterIP 10.112.1.204 <none> 9080/TCP 35s 12
  • 13. service/ratings ClusterIP 10.112.11.95 <none> 9080/TCP 38s service/reviews ClusterIP 10.112.1.237 <none> 9080/TCP 37s 1.4.3 클러스터 내부에서 배포된 앱의 웹페이지가 보이는지 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>" <title>Simple Bookstore App</title> 1.4.4 외부에서 접속할 수 있도록 애플리케이션을 노출 기본(classic)에서는 apiVersion: networking.istio.io를 사용하지만, 중장기적으로는 apiVersion: gateway.networking.k8s.io를 사용할 것으로 예상됩니다. gateway로 구성하는 예제는 부록을 참고하시기 바랍니다. [그림 7] Istio Ingress Gateway (링크) 13
  • 14. 이스티오 ingress gateway를 통해서 배포된 앱이 접속되도록 Istio Gateway와 VirtualService를 설정합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml gateway.networking.istio.io/bookinfo-gateway created virtualservice.networking.istio.io/bookinfo created 1.4.5 배포된 Istio Gateway와 VirtualService 설정을 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get gateways.networking.istio.io NAME AGE bookinfo-gateway 7m47s ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get virtualservices.networking.istio.io NAME GATEWAYS HOSTS AGE bookinfo ["bookinfo-gateway"] ["*"] 7m54s 14
  • 15. 1.4.6 이스티오에서 제공하는 분석 도구로 구성에 이슈가 없는지 분석 만약 다른 네임스페이스를 하고 싶다면 -n <네임스페이스 이름>을 통해서 가능합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl analyze ✔ No validation issues found when analyzing namespace: default. Tip!☸ istio-injection=enabled 레이블이 활성화 되어 있지 않는다면, 다음과 같은 정보를 표시합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl analyze Info [IST0102] (Namespace default) The namespace is not enabled for Istio injection. Run 'kubectl label namespace default istio-injection=enabled' to enable it, or 'kubectl label namespace default istio-injection=disabled' to explicitly mark it as not needing injection. 1.4.7 외부에서 bookinfo에 접속할 수 있는 IP와 포트를 확인하기 위해 이미 배포된 이스티오 ingress gateway의 IP와 포트 정보를 다시 확인합니다. CSP따라 EXTERNAL-IP가 도메인 형태로 제공될 수 있습니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get svc -n istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-egressgateway ClusterIP 10.112.12.251 <none> 80/TCP,443/TCP 17h istio-ingressgateway LoadBalancer 10.112.12.147 34.67.165.125 15021:32058/TCP,80:31561/TCP,443:30443/TCP,31400:30750/TCP,15443:30994/TCP 17h istiod ClusterIP 10.112.15.136 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 17h 1.4.8 배포된 bookinfo가 외부에서 보이는지 확인 IP와 포트를 확인했다면, 다음의 명령어로 출력 값이 정상적으로 뜨는지 확인합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl -s http://34.67.165.125/productpage | grep /title <title>Simple Bookstore App</title> 15
  • 16. 그리고 해당 IP와 포트를 웹브라우저에 입력해서 다음과 같은 화면이 나오는지 확인합니다. [그림 8] bookinfo의 productpage Tip!☸ IP와 포트등을 인자로 받아오기 위해서는 다음의 명령어를 사용해 보는 것도 좋습니다. # IP로 되어 있는 경우 $ export INGRESS_HOST_IP=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') # Domain 이름으로 되어 있는 경우 export INGRESS_HOST_NAME=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}') $ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}') $ export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}') ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl -s http://$INGRESS_HOST_IP:$INGRESS_PORT/productpage | grep /title <title>Simple Bookstore App</title> 1.5. 이스티오 동작을 좀 더 면밀하게 확인하기 위한 애드온 설치 16
  • 17. 애드온을 설치하는 가장 큰 목적은 이스티오를 통해서 파악된 마이크로 서비스 아키텍처(MSA) 형태의 애플리케이션의 통신 상태를 파악하고, 필요에 따라 이를 조치하고자 함에 있습니다. 이를 위해 도입부에서 언급한 키알리 대시보드와 그에 필요한 추가 OSS를 함께 설치하고 확인해 보겠습니다. 1.5.1 키알리 대시보드 노출 변경 기본 설정으로 배포하게 되면 키알리가 ClusterIP로 배포되기 때문에 접근을 위해서 다시 port-forward를 해줘야 하는 불편함이 있습니다. 그래서 노출을 LoadBalancer로 변경하기 위해서 다음의 스크립트를 실행합니다. *주의* 해당 설정은 이스티오 1.6.1에만 적용되므로 다른 버전을 사용하는 경우에는 직접 서비스를 변경해 주어야 합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) awk 'NR==424{print " type: LoadBalancer # "}1' samples/addons/kiali.yaml > kiali+LB.yaml ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) cp kiali+LB.yaml samples/addons/kiali.yaml 변경 후에 파일을 확인하면, 424번 줄에 LoadBalancer 설정이 추가되어 있음을 확인할 수 있습니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) cat samples/addons/kiali.yaml | nl | grep LoadBalancer 424 type: LoadBalancer # Change from clusterIP to LoadBalancer 1.5.2 이스티오 애드온 설치 Kiali dashboard, Prometheus, Grafana 그리고 Jaeger 를 개별 설치 구성하길 원한다면, 개별 링크를 참조하시기 바랍니다. 그리고 Jaeger가 아니라 Zipkin으로 구성하길 원한다면, samples/addons/extras/zipkin.yaml을 Jaeger 대신에 구성하길 바랍니다. 다만 이 경우 Jaeger-collector를 따로 구성해 줘야 합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f samples/addons serviceaccount/grafana created configmap/grafana created 17
  • 18. service/grafana created deployment.apps/grafana created configmap/istio-grafana-dashboards created configmap/istio-services-grafana-dashboards created deployment.apps/jaeger created service/tracing created service/zipkin created service/jaeger-collector created serviceaccount/kiali created configmap/kiali created clusterrole.rbac.authorization.k8s.io/kiali-viewer created clusterrole.rbac.authorization.k8s.io/kiali created clusterrolebinding.rbac.authorization.k8s.io/kiali created role.rbac.authorization.k8s.io/kiali-controlplane created rolebinding.rbac.authorization.k8s.io/kiali-controlplane created service/kiali created deployment.apps/kiali created serviceaccount/prometheus created configmap/prometheus created clusterrole.rbac.authorization.k8s.io/prometheus created clusterrolebinding.rbac.authorization.k8s.io/prometheus created service/prometheus created deployment.apps/prometheus created 1.5.3 배포된 이스티오 애드온을 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po,svc -n istio-system NAME READY STATUS RESTARTS AGE pod/grafana-56bdf8bf85-2hx5b 1/1 Running 0 3m19s pod/istio-egressgateway-79598956cf-bk5t6 1/1 Running 0 24h pod/istio-ingressgateway-854c9d9c5f-zpkvr 1/1 Running 0 24h pod/istiod-fd94754fb-6j6bd 1/1 Running 0 24h pod/jaeger-c4fdf6674-brk6r 1/1 Running 0 3m14s pod/kiali-849958788-ghtxm 1/1 Running 0 2m55s pod/prometheus-85949fddb-bt4lv 2/2 Running 0 2m46s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/grafana ClusterIP 10.112.7.128 <none> 3000/TCP 3m22s service/istio-egressgateway ClusterIP 10.112.12.251 <none> 80/TCP,443/TCP 24h service/istio-ingressgateway LoadBalancer 10.112.12.147 34.67.165.125 15021:32058/TCP,80:31561/TCP,443:30443/TCP,31400:30750/TCP,15443:30994/TCP 24h service/istiod ClusterIP 10.112.15.136 <none> 18
  • 19. 15010/TCP,15012/TCP,443/TCP,15014/TCP 24h service/jaeger-collector ClusterIP 10.112.8.242 <none> 14268/TCP,14250/TCP,9411/TCP 3m10s service/kiali LoadBalancer 10.112.11.184 34.72.240.154 20001:31461/TCP,9090:32663/TCP 2m58s service/prometheus ClusterIP 10.112.8.140 <none> 9090/TCP 2m48s service/tracing ClusterIP 10.112.6.73 <none> 80/TCP,16685/TCP 3m13s service/zipkin ClusterIP 10.112.6.194 <none> 9411/TCP 3m12s Tip!☸ 배포된 구성 요소들을 개별적으로 접근해서 확인하고자 한다면, istioctl dashboard <이름> 명령어를 통해서 Port Forward를 구성할 수 있습니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl dashboard grafana http://localhost:3000 [그림 8] istioctl dashboard grafana를 통해서 접근한 그라파나 대시보드 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istioctl dashboard prometheus http://localhost:9090 19
  • 20. [그림 9] istioctl dashboard prometheus를 통해서 접근한 프로메테우스 대시보드 1.5.4 배포된 키알리 대시보드에 접속해서 동작 상태를 확인 키알리 대시보드는 20001번 포트를 사용합니다. [그림 10] 로드밸런서로 노출된 키알리 대시보드 1.5.5 키알리 대시보드의 Graph 메뉴로 이동하고 default 네임스페이스를 선택 현재는 발생한 부하가 없기 때문에 표시되는 애플리케이션 서비스 메시가 없는 것이 정상입니다. [그림 11] 키알리 대시보드의 그래프 메뉴 20
  • 21. 1.5.6 부하발생기(loadgenerator)를 내려받고 실행 주소: https://github.com/sysnet4admin/_Lecture_k8s_learning.kit/blob/main/A/A.011/01.istio/loa dgenerator.sh ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl -LO https://raw.githubusercontent.com/sysnet4admin/_Lecture_k8s_learning.kit/main/A/A.0 11/01.istio/loadgenerator.sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 240 100 240 0 0 906 0 --:--:-- --:--:-- --:--:-- 930 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) sh loadgenerator.sh 1.5.7 키알리 대시보드의 그래프 메뉴로 돌아가서 애플리케이션에 대한 서비스 메시가 잘 그려지는지 확인 [그림 12] 키알리 대시보드의 그래프 메뉴에 그려진 bookinfo 서비스 메시 21
  • 22. Tip!☸ 다소 시간이 흐른 후에 확인했다면 위와 같은 화면을 볼 수 없기 때문에 이런 경우에는 다시 한번 loadgenerator.sh를 실행하고 키알리 대시보드를 확인하면 됩니다. 2. 이스티오 메뉴 이번에는 이스티오 메뉴들을 살펴보면서 이스티오에서 제공하는 서비스들을 살펴보도록 하겠습니다. 다만 일부 서비스들은 계속 트래픽이 발생하는 상태에서 동작이 확인되기 때문에 우선 현재 bookinfo에 메뉴를 살펴보는 동안 계속 트래픽이 발생하도록 설정하기 위해서 다음의 스크립트를 내려받고 실행합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl -LO https://raw.githubusercontent.com/sysnet4admin/_Lecture_k8s_learning.kit/main/A/A.0 11/01.istio/loadgenerator-infinite.sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 308 100 308 0 0 7620 0 --:--:-- --:--:-- --:--:-- 9058 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) sh loadgenerator-infinite.sh Press CTRL+C to stop... 22
  • 23. 이제 이스티오 메뉴를 살펴볼 준비가 모두 완료되었습니다. 2.1. Overview(처음 접속 화면) 처음 접속 화면에서는 네임스페이스 별로 간단한 상태를 확인할 수 있습니다. 따라서 상태를 확인할 수 있는 시간 범위 및 측정 단위 시간을 지정할 수 있습니다. 기본 값으로는 15초마다 상태 값을 수집하고 1분 전까지의 상태를 보여줍니다. [그림 13] 키알리 대시보드의 접속 화면 [그림 14] 많은 네임스페이스가 생성되어 있는 쿠버네티스 클러스터 23
  • 24. Tip!☸ 현재 버전에서 오른쪽 위에 발생하는 경보는 Grafana 정보를 가져오지 못해서 발생하는 것이며, 이는 매니페스트(Manifest)가 아닌 helm으로 배포시에 grafana의 주소를 추가함으로써 해결할 수 있습니다. [그림 15] 키알리 대시보드의 메시지 센터에서 보이는 그라파나 URL 관련 에러 24
  • 25. 2.2. Graph 이스티오를 통해서 모니터링되는 애플리케이션들의 통신 구성을 네임스페이스 별로 확인할 수 있습니다. 또한 워크로드(Workloads)와 서비스(Services)를 아이콘 형태로 구분할 수 있으며, 묶여진 애플리케이션(Applications)도 쉽게 그래프에서 확인 가능합니다. [그림 16] 키알리 대시보드의 그래프 메뉴 이렇게 확인된 아이콘을 누르게 되면. 아이콘에 해당 하는 연결 경로 및 추가적인 정보를 파악할 수 있습니다. [그림 17] 키알리 대시보드의 그래프 메뉴에서 특정 워크로드(v2)를 선택한 경우 표시되는 화면 25
  • 26. 추가적으로 표시하는 방법을 다양하게 바꿀 수 있는데 그 중에서 Show Edge Labels - Traffic Distribution, Traffic Rate, Show - Traffic Animation, Security를 눌러서 확인해 보면 어떤 역할을 하는지 시각적으로 알 수 있습니다. [그림 18] 키알리 대시보드의 그래프 메뉴에서 표시 옵션을 추가한 경우 변경 표시되는 화면 26
  • 27. 2.3. Applications 이스티오를 통해서 모니터링되는 애플리케이션들 별로 사용되는 gateway와 virtualserivce를 알 수 있습니다. [그림 19] 키알리 대시보드의 애플리케이션 메뉴 27
  • 28. 또한 자세히 보고자 원하는 애플리케이션을 선택하는 경우 Traffic, Metrics 그리고 Traces에 관한 자세한 내용도 함께 확인할 수 있습니다. [그림 20] 애플리케이션 productpage의 Overview 메뉴 [그림 21] 애플리케이션 productpage의 Traffic, Inbound와Outbound Metrics 그리고 Traces 28
  • 29. 이 중에 특히 Traces는 애플리케이션의 병목(Bottleneck) 현상을 줄이고 성능 극대화 하는 자료로 매우 적합합니다. 이와 같은 Trace 관련 정보를 확인하기 위해서는 표시된 원형 Traces 중에 자세히 보고자 하는 것을 선택해서 누르게 되면, 자세한 Trace 내용 및 관련된 정보를 확인할 수 있습니다. [그림 22] 특정 Trace의 자세한 내용 29
  • 30. 이것을 Span 단위로 확인하기 위해서는 바로 옆의 메뉴인 Span Details을 누르면, 되게 여기서 필요한 부분을 확인해서 조치하면 됩니다. [그림 23] 특정 Trace의 Span 별로 확인 가능한 자세한 내용 30
  • 31. 2.4. Workloads 워크로드(번역: 작업량)는 애플리케이션에서 실제 업무를 수행하는 단위를 부르는 명칭입니다. 따라서 쿠버네티스의 관점으로 볼 때 Pod들을 모아서 동작시키는 Deployment와 같은 오브젝트들이 이에 해당 한다고 볼 수 있습니다. [그림 24] 키알리 대시보드의 워크로드 메뉴 31
  • 32. 또한 자세히 보고자 원하는 워크로드를 선택하는 경우 Traffic, Metrics, Traces 외에도 Logs와 Envoy 관한 자세한 내용도 확인할 수 있습니다. [그림 25] 워크로드 productpage-v1의 Overview 메뉴 [그림 26] 워크로드 productpage-v1의 Logs 메뉴 32
  • 33. [그림 27] 워크로드 productpage-v1의 Envoy 메뉴 33
  • 34. 2.5. Services 서비스는 노출된 워크로드를 부르는 명칭입니다. 실제로 쿠버네티스에서 만들어진 워크로드를 노출할 수 있도록 생성하는 서비스와 동일한 개념입니다. [그림 28] 키알리 대시보드의 서비스 메뉴 자세히 보고자 원하는 서비스를 선택하는 경우 Traffic, Inbound Metrics, Traces 에 관한 세부적인 내용도 확인할 수 있습니다. [그림 29] 서비스 productpage의 Overview 메뉴 34
  • 35. [그림 30] 서비스 productpage의 Traffic과 Inbound Metrics 메뉴 2.6. Istio Config 이스티오의 고유 구성 요소인 VirtualService와 Gateway에 대해서 매니페스트(Manifest, YAML) 수준으로 볼 수 있습니다. [그림 31] 이스티오 설정(Config) 메뉴 35
  • 36. [그림 32] VirtualService 타입의 YAML 내용 [그림 33] Gateway 타입의 YAML 내용 36
  • 37. 3. 이스티오 기능 별 구분 이스티오의 메뉴들을 살펴보았으니, 이제 이스티오에서 제공하는 기능 별로 구성하여 해당 내용을 살펴볼 차례입니다. 우선 진행하기에 앞서 현재 배포되어 있는 bookinfo가 혼동의 소지가 있으니 이를 삭제하고 확인한 후에 진행하도록 하겠습니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml service "details" deleted serviceaccount "bookinfo-details" deleted deployment.apps "details-v1" deleted service "ratings" deleted serviceaccount "bookinfo-ratings" deleted deployment.apps "ratings-v1" deleted service "reviews" deleted serviceaccount "bookinfo-reviews" deleted deployment.apps "reviews-v1" deleted deployment.apps "reviews-v2" deleted deployment.apps "reviews-v3" deleted service "productpage" deleted serviceaccount "bookinfo-productpage" deleted deployment.apps "productpage-v1" deleted ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete -f 37
  • 38. samples/bookinfo/networking/bookinfo-gateway.yaml gateway.networking.istio.io "bookinfo-gateway" deleted virtualservice.networking.istio.io "bookinfo" deleted ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po,svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 141d 3.1. 트래픽 관리 (Traffic management) 트래픽 라우팅은 단일 클러스터 내에서나 클러스터 간에 성능에 영향을 미치는 요소이며, 더 나은 배포 전략을 필요로 할 수 있습니다. Istio의 트래픽 라우팅 규칙을 사용하면 서비스 간 트래픽 및 API 호출의 흐름을 쉽게 제어할 수 있습니다. Istio는 Circuit Breaker, Timeout, 재시도(retries)와 같은 서비스 수준 속성의 구성을 간소화하고, 백분율 기반 트래픽 분할을 통해 A/B 테스트, 카나리(canary) 배포, 단계적 롤아웃(rollouts)과 같은 중요한 작업을 쉽게 설정할 수 있게 해줍니다. [출처: https://istio.io/latest/about/service-mesh/ ] 3.3.1 단순 서비스를 통해 2개의 Pod로 트래픽 분산 2개의 Pod가 1개의 서비스로 연결되어 트래픽이 양쪽 Pod로 배포되는 것을 확인합니다. 3.3.1.1 hello Pod 및 curl 사용을 위한 net Pod 배포 hello-v1과 hello-v2를 응답해 주는 Pod를 배포합니다. 그리고 클러스터 내부에서 curl 명령을 사용하기 위한 net Pod를 배포합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: hello-v1 labels: app: hello version: v1 spec: 38
  • 39. containers: - image: sysnet4admin/hello:v1 name: hello-v1 --- apiVersion: v1 kind: Pod metadata: name: hello-v2 labels: app: hello version: v2 spec: containers: - image: sysnet4admin/hello:v2 name: hello-v2 --- apiVersion: v1 kind: Pod metadata: name: net labels: app: net spec: containers: - image: sysnet4admin/net-tools-ifn name: net EOF pod/hello-v1 created pod/hello-v2 created pod/net created 3.3.1.2 배포된 hello Pod(s) 및 동작 확인 배포된 것을 확인합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po,svc NAME READY STATUS RESTARTS AGE pod/hello-v1 2/2 Running 0 92s pod/hello-v2 2/2 Running 0 90s pod/net 2/2 Running 0 88s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 141d 39
  • 40. 배포된 Pod들의 label을 확인합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po --show-labels NAME READY STATUS RESTARTS AGE LABELS hello-v1 2/2 Running 0 56m app=hello,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=hello,ser vice.istio.io/canonical-revision=v1,version=v1 hello-v2 2/2 Running 0 56m app=hello,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=hello,ser vice.istio.io/canonical-revision=v2,version=v2 net 2/2 Running 0 56m app=net,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=net,service .istio.io/canonical-revision=latest 배포된 Pod의 label 중에 version을 사용하여 각 Pod 별로 응답이 오는지 다음의 명령으로 확인합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl exec -it net -- curl $(kubectl get po -l version=v1 -o wide | awk 'NR==2' | awk '{print $6}') hello-v1 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl exec -it net -- curl $(kubectl get po -l version=v2 -o wide | awk 'NR==2' | awk '{print $6}') hello-v2 3.3.1.3 hello 서비스를 연결 기본 서비스에서는 라운드로빈(Round-Robin)으로 응답합니다. 배포된 Pod들의 label 중에 app을 확인합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get po --show-labels NAME READY STATUS RESTARTS AGE LABELS hello-v1 2/2 Running 0 56m app=hello,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=hello,ser vice.istio.io/canonical-revision=v1,version=v1 hello-v2 2/2 Running 0 56m app=hello,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=hello,ser vice.istio.io/canonical-revision=v2,version=v2 net 2/2 Running 0 56m 40
  • 41. app=net,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=net,service .istio.io/canonical-revision=latest app을 selector로 사용하여 hello 서비스를 생성합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: v1 kind: Service metadata: name: hello-svc labels: app: hello spec: selector: app: hello ports: - name: http protocol: TCP port: 80 EOF service/hello-svc created 생성된 서비스를 통해서 응답이 잘 분배되는지 확인합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec -it net -- curl hello-svc.default.svc.cluster.local; done | tee /tmp/hello-svc ; echo -e "n-=- RESULT -=-" ; echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ; echo "v2: $(grep v2 /tmp/hello-svc | wc -l)" ; rm -f /tmp/hello-svc hello-v1 hello-v2 hello-v1 hello-v2 hello-v2 hello-v1 hello-v2 hello-v2 hello-v1 hello-v1 41
  • 42. -=- RESULT -=- v1: 5 v2: 5 Tip!☸ 언제나 5:5로 분배되지는 않습니다. 이와 가깝게 분배되는 것이 정상적인 동작입니다. 3.3.2 VirtualService로 트래픽 균등 분산 VirtualService CRD를 통해서 기본으로 가는 경로를 hello-v1으로 하고 URI의 prefix가 v2 이면 hello-v2로 연결되도록 구성합니다. 3.3.2.1 VirtualService 생성 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: v1 kind: Service metadata: name: hello-svc-v1 labels: app: hello spec: selector: app: hello version: v1 ports: - name: http protocol: TCP port: 80 --- apiVersion: v1 kind: Service metadata: name: hello-svc-v2 labels: app: hello spec: selector: app: hello version: v2 ports: - name: http protocol: TCP port: 80 --- 42
  • 43. apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: hello-vs spec: hosts: - "hello-svc.default.svc.cluster.local" http: - match: - uri: prefix: /v2 route: - destination: host: "hello-svc-v2.default.svc.cluster.local" - route: - destination: host: "hello-svc-v1.default.svc.cluster.local" EOF service/hello-svc-v1 created service/hello-svc-v2 created virtualservice.networking.istio.io/hello-vs created Tip!☸ route는 ACL(Access Control List) 적용과 유사하게 위에서부터 순서대로 아래로 내려오며 적용됩니다. 따라서 좁은 범위에서 넓은 범위로 적용되어야 합니다. 3.3.2.2 배포된 VirtualService 확인 배포된 VirtualService의 내용을 확인합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get virtualservices.networking.istio.io -o yaml | grep -A12 spec: spec: hosts: - hello-svc.default.svc.cluster.local http: - route: - destination: host: hello-svc-v1.default.svc.cluster.local - match: - uri: prefix: /v2 route: 43
  • 44. - destination: host: hello-svc-v2.default.svc.cluster.local 3.3.2.3 생성한 VirtualService에 트래픽을 발생시키기 hello-svc.default.svc.cluster.local로 트래픽을 발생 후 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec -it net -- curl hello-svc.default.svc.cluster.local; done | tee /tmp/hello-svc ; echo "-=- RESULT -=-" ; echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ; echo "v2: $(grep v2 /tmp/hello-svc | wc -l)" ; rm -f /tmp/hello-svc hello-v1 hello-v1 hello-v1 hello-v1 hello-v1 hello-v1 hello-v1 hello-v1 hello-v1 hello-v1 -=- RESULT -=- v1: 10 v2: 0 hello-svc.default.svc.cluster.local/v2 로 트래픽을 발생 후 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec -it net -- curl hello-svc.default.svc.cluster.local/v2; done | tee /tmp/hello-svc ; echo "-=- RESULT -=-" ; echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ; echo "v2: $(grep v2 /tmp/hello-svc | wc -l)" ; rm -f /tmp/hello-svc hello-v2 (URI: /v2) hello-v2 (URI: /v2) hello-v2 (URI: /v2) 44
  • 45. hello-v2 (URI: /v2) hello-v2 (URI: /v2) hello-v2 (URI: /v2) hello-v2 (URI: /v2) hello-v2 (URI: /v2) hello-v2 (URI: /v2) hello-v2 (URI: /v2) -=- RESULT -=- v1: 0 v2: 10 3.3.3 VirtualService에 weight를 붙여서 트래픽 비율을 조정 단순히 경로만 지정하는 것이 아니라 분산되는 트래픽을 양을 weight 값으로 조절해 봅니다. 3.3.3.1 우선 적용된 VirtualService가 서비스로 트래픽을 바로 넘겨 버리기 때문에 현재 상태에서는 가중치 별로 부하 분산 테스트를 할 수 없습니다. 따라서 기존의 VirtualService를 삭제합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete virtualservices.networking.istio.io hello-vs virtualservice.networking.istio.io "hello-vs" deleted 3.3.3.2 가중 치에 따른 트래픽 분산 테스트를 위한 VirtualService를 적용(apply)합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: hello-vs-canary spec: hosts: - "hello-svc.default.svc.cluster.local" http: - route: - destination: host: "hello-svc-v1.default.svc.cluster.local" weight: 90 - destination: host: "hello-svc-v2.default.svc.cluster.local" weight: 10 45
  • 46. EOF virtualservice.networking.istio.io/hello-vs-canary configured Tip!☸ 카나리(canary)는 일부 트래픽만 새로운 애플리케이션에 보내서 확인하는 대표적인 안전 배포 방법입니다. 3.3.3.2 VirtualService에 적용되어 있는 내용 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get virtualservices.networking.istio.io -o yaml | grep -A16 spec: spec: hosts: - hello-svc.default.svc.cluster.local http: - route: - destination: host: hello-svc-v1.default.svc.cluster.local weight: 90 - destination: host: hello-svc-v2.default.svc.cluster.local weight: 10 kind: List metadata: resourceVersion: "" selfLink: "" 3.3.3.3 트래픽 분배가 가중치에 따라 다르게 적용되는지 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec -it net -- curl hello-svc.default.svc.cluster.local; done | tee /tmp/hello-svc ; echo "-=- RESULT -=-" ; echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ; echo "v2: $(grep v2 /tmp/hello-svc | wc -l)" ; rm -f /tmp/hello-svc hello-v1 hello-v1 hello-v1 hello-v1 hello-v1 hello-v2 hello-v1 hello-v1 46
  • 47. hello-v1 hello-v1 -=- RESULT -=- v1: 9 v2: 1 Tip!☸ 언제나 9:1로 분배되지는 않습니다. 이와 가깝게 트래픽이 분배되는 것이 정상적인 동작입니다. 배포한 VirtualService를 삭제합니다. 이는 다음에 진행할 DestinationRule보다 VirtualSerivce가 먼저 적용되기 때문입니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete vs hello-vs-canary virtualservice.networking.istio.io "hello-vs-canary" deleted Tip!☸ vs는 VirtualSerivce의 약자입니다. 3.3.4 DestinationRule 가중치와 같은 방법으로 트래픽을 분산하는 것이 외에, 트래픽에 도달하는 방법 자체를 정의할 수 있습니다. 그 중에 가장 많이 사용되는 로드밸런서를 단순히 사용하는게 아니라 로드밸런싱의 방법을 바꿔가면서 테스트하여 DestinatioRule을 이해해 보겠습니다. 3.3.4.1 간단한 방식(simple) 최소한의 알고리즘이 없는 경우 5:5 또는 6:4가 아니라 7:3 혹은 그 이상 안 좋은 결과를 보여줄 수 있습니다. 그러니 가능한 간단한 로직이라도 넣는게 좋습니다. Round-Robin 방식을 적용하고 테스트합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: hello-dr-rr spec: host: hello-svc.default.svc.cluster.local 47
  • 48. trafficPolicy: loadBalancer: simple: ROUND_ROBIN EOF destinationrule.networking.istio.io/hello-dr-rr created ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec -it net -- curl hello-svc.default.svc.cluster.local; done | tee /tmp/hello-svc ; echo "-=- RESULT -=-" ; echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ; echo "v2: $(grep v2 /tmp/hello-svc | wc -l)" ; rm -f /tmp/hello-svc hello-v1 hello-v1 hello-v2 hello-v2 hello-v1 hello-v1 hello-v2 hello-v1 hello-v2 hello-v1 -=- RESULT -=- v1: 6 v2: 4 적용된 DestinationRule인 hello-dr-rr을 삭제합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete destinationrules.networking.istio.io hello-dr-rr destinationrule.networking.istio.io "hello-dr-rr" deleted LEAST_REQUEST 방식을 적용하고 테스트합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: hello-dr-lr spec: host: hello-svc.default.svc.cluster.local trafficPolicy: 48
  • 49. loadBalancer: simple: LEAST_REQUEST EOF destinationrule.networking.istio.io/hello-dr-lr created ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec -it net -- curl hello-svc.default.svc.cluster.local; done | tee /tmp/hello-svc ; echo "-=- RESULT -=-" ; echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ; echo "v2: $(grep v2 /tmp/hello-svc | wc -l)" ; rm -f /tmp/hello-svc hello-v1 hello-v2 hello-v2 hello-v1 hello-v2 hello-v1 hello-v1 hello-v2 hello-v1 hello-v2 -=- RESULT -=- v1: 5 v2: 5 Tip!☸ 2개의 방식 차이 그리고 다른 방식에 대해서는 다음의 링크를 참조하세요 적용된 DestinationRule인 hello-dr-lr을 삭제합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete destinationrules.networking.istio.io hello-dr-lr destinationrule.networking.istio.io "hello-dr-lr" deleted 3.3.4.2 해시를 사용하는 방식 (consistentHash) useSourceIp를 적용하고 테스트합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: hello-dr-hash-sip spec: host: hello-svc.default.svc.cluster.local trafficPolicy: 49
  • 50. loadBalancer: consistentHash: useSourceIp: true EOF destinationrule.networking.istio.io/hello-dr-hash-sip created ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec -it net -- curl hello-svc.default.svc.cluster.local; done | tee /tmp/hello-svc ; echo "-=- RESULT -=-" ; echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ; echo "v2: $(grep v2 /tmp/hello-svc | wc -l)" ; rm -f /tmp/hello-svc hello-v2 hello-v2 hello-v2 hello-v2 hello-v2 hello-v2 hello-v2 hello-v2 hello-v2 hello-v2 -=- RESULT -=- v1: 0 v2: 10 적용된 DestinationRule인 hello-dr-hash-sip을 삭제합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete destinationrules.networking.istio.io hello-dr-hash-sip destinationrule.networking.istio.io "hello-dr-hash-sip" deleted maglev를 적용하고 테스트합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: hello-dr-hash-maglev spec: host: hello-svc.default.svc.cluster.local trafficPolicy: 50
  • 51. loadBalancer: consistentHash: maglev: EOF destinationrule.networking.istio.io/hello-dr-hash-maglev created ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) for i in {1..10}; do kubectl exec -it net -- curl hello-svc.default.svc.cluster.local; done | tee /tmp/hello-svc ; echo "-=- RESULT -=-" ; echo "v1: $(grep v1 /tmp/hello-svc | wc -l)" ; echo "v2: $(grep v2 /tmp/hello-svc | wc -l)" ; rm -f /tmp/hello-svc hello-v2 hello-v2 hello-v2 hello-v1 hello-v1 hello-v1 hello-v1 hello-v1 hello-v2 hello-v1 -=- RESULT -=- v1: 6 v2: 4 Tip!☸ 2개의 방식 차이 그리고 다른 방식에 대해서는 다음의 링크를 참조하세요 다음 진행을 위해 적용된 DestinationRule인 hello-dr-hash-maglev을 삭제합니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete destinationrules.networking.istio.io hello-dr-hash-maglev destinationrule.networking.istio.io "hello-dr-hash-maglev" deleted 3.3.4.3 subset 다음과 같이 레이블에 따라 로드밸런서 설정을 다르게 가지고 갈 수 있습니다. 이 부분은 샘플만 이해하고 넘어가도록 하겠습니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: bookinfo-ratings-dr-sbs 51
  • 52. spec: host: ratings.prod.svc.cluster.local trafficPolicy: loadBalancer: simple: LEAST_REQUEST # 기본 로드밸런서 subsets: - name: testversion labels: version: v3 trafficPolicy: loadBalancer: consistentHash: useSourceIp: true # 레이블 version: v3인 경우 적용되는 로드밸런서 EOF 3.3.4.4 connectionPool & outlierDetection (Circuit breaking) 문제가 지속적으로 발생하는 경우 문제 발생 지점으로 계속 연결시켜주기 보다 더이상 연결이 되지 않도록 하는 것이 좋습니다. 이를 위해서 Connection Pool과 Outlier Detection을 다음과 같이 설정할 수 있습니다. ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: bookinfo-redis spec: host: myredissrv.prod.svc.cluster.local trafficPolicy: connectionPool: # 접속 pool 사이즈 조정 Tcp: # tcp 말고 http도 가능 maxConnections: 100 # TCP 최대 접속수 connectTimeout: 30ms # TCP timeout 값 outlierDetection: # 서킷 브레이커 동작 조건 나열 consecutiveErrors: 3 # 3번이 넘어가지는 체크 interval: 30s # 3번의 문제가 얼마의 기간동안 발생하는지 체크 baseEjectionTime: 30m # 얼마나 오랫동안 접속이 안되도록 할 것인가 설정 maxEjectionPercent: 50 # 완전히 서비스를 중단하는게 아니라 50%는 놔두도록 설정 EOF 52
  • 53. 3.3.5 Gateway 도달하는 순서로 본다면 외부에서 가장 처음에 도달하게 되는 Ingressgateway 이고 그 이후에 이를 실제로 내부와 연결해주는 역할을 하는 것이 gateway 입니다. 따라서 실제로 서비스 메시인 istio의 내부 경로를 만들어주는 첫 단계라고 볼 수 있습니다. 그리고 독립적인 사용보다는 VirtualService와의 연동을 통해서 내부 Pod와 연결되게 됩니다. 이를 표현하면 다음과 같은 단계를 통해서 접속되게 됩니다. 사용자 -> istio-ingressgateway (LB) -> Gateway -> Virtual Service -> Destination Rules -> Pod(s) 3.3.5.1 hello 앱에 접속하기 위핸 Gateway와 Virtual Service를 배포 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: hello-gw spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: hello-vs spec: hosts: - "*" 53
  • 54. gateways: - hello-gw http: - match: - uri: prefix: /v2 route: - destination: host: "hello-svc-v2.default.svc.cluster.local" - route: - destination: host: "hello-svc-v1.default.svc.cluster.local" EOF gateway.networking.istio.io/hello-gw created virtualservice.networking.istio.io/hello-vs created 3.3.5.2 배포된 Gateway(gw)와 Virtual Service(vs) 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get gw,vs NAME AGE gateway.networking.istio.io/hello-gw 3m29s NAME GATEWAYS HOSTS AGE virtualservice.networking.istio.io/hello-vs ["hello-gw"] ["*"] 3m29s 3.3.5.3 외부에서 접속하는 IP (다른 CSP는 도메인) 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl get svc -n istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) grafana ClusterIP 10.112.7.128 <none> 3000/TCP istio-egressgateway ClusterIP 10.112.12.251 <none> 80/TCP,443/TCP istio-ingressgateway LoadBalancer 10.112.12.147 xx.67.xxx.xxx X istiod ClusterIP 10.112.15.136 <none> X jaeger-collector ClusterIP 10.112.8.242 <none> X kiali LoadBalancer 10.112.11.184 xx.72.xxx.xxx X prometheus ClusterIP 10.112.8.140 <none> 9090/TCP tracing ClusterIP 10.112.6.73 <none> 80/TCP,16685/TCP zipkin ClusterIP 10.112.6.194 <none> 9411/TCP 54
  • 55. 3.3.5.4 편리한 사용을 위해 IP를 변수로 치환 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) istio_ingress_IP=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0].ip}") 3.3.5.5 외부에서 HTTP 호출이 되는지 확인 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl $istio_ingress_IP hello-v1 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) curl $istio_ingress_IP/v2 hello-v2 (URI: /v2) 3.3.5.6 사용한 모든 앱과 서비스 그리고 이스티오 CRD 리소스 삭제 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete po,svc -l app=hello pod "hello-v1" deleted pod "hello-v2" deleted service "hello-svc" deleted service "hello-svc-v1" deleted service "hello-svc-v2" deleted ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete gw hello-gw gateway.networking.istio.io "hello-gw" deleted ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) kubectl delete vs hello-vs virtualservice.networking.istio.io "hello-vs" deleted 3.2. 관측 가능성 (Observability) 서비스의 복잡성이 증가함에 따라 사용 패턴과 성능을 파악하기가 어려워지고 있습니다. Istio는 서비스 메시 내의 모든 통신에 대한 상세한 텔레메트리(Telemetry)를 생성합니다. 이러한 텔레메트리는 서비스 동작에 대한 관측 가능성(Observability)을 제공하여 운영자가 애플리케이션을 문제 해결, 유지 관리, 최적화할 수 있도록 지원합니다. 더 좋은 점은 애플리케이션을 변경할 필요 없이 거의 모든 계측 기능을 사용할 수 있다는 55
  • 56. 것입니다. 운영자는 Istio를 통해 모니터링되는 서비스가 상호 작용하는 방식을 전반적으로 이해할 수 있습니다. Istio의 텔레메트리에는 상세한 메트릭(metrics), 분산 추적(distributed traces), 전체 접속 로그(access logs)가 포함됩니다. Istio를 사용하면 철저하고 종합적인 서비스 메시에 대한 관측 가능성을 확보할 수 있습니다. [출처: https://istio.io/latest/about/service-mesh/ ] 3.2.1 stan의 로봇 샵 배포 (Stan's Robot Shop) IBM Instana 관측 가능성을 위해 제작된 MSA 앱을 배포 3.2.1.1 MSA 디렉터리를 생성하고 이동한 후에 로봇 샵을 git clone 함 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) mkdir MSA ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) cd MSA ➜ MSA (☸️ |hj-istio-classic:default) git clone https://github.com/instana/robot-shop.git Cloning into 'robot-shop'... remote: Enumerating objects: 2949, done. remote: Counting objects: 100% (6/6), done. remote: Compressing objects: 100% (6/6), done. remote: Total 2949 (delta 0), reused 3 (delta 0), pack-reused 2943 Receiving objects: 100% (2949/2949), 103.14 MiB | 10.68 MiB/s, done. Resolving deltas: 100% (1570/1570), done. 3.2.1.2 로봇 샵의 레포지토리에서 헬름 디렉터리로 이동한 후에 해당 내용을 확인 ➜ MSA (☸️ |hj-istio-classic:default) cd robot-shop/K8s/helm ➜ helm git:(master) (☸️ |hj-istio-classic:default) ls -rlt total 32 -rw-r--r-- 1 mz01-hj staff 137 Jun 29 12:21 Chart.yaml -rw-r--r-- 1 mz01-hj staff 6652 Jun 29 12:21 README.md 56
  • 57. drwxr-xr-x 30 mz01-hj staff 960 Jun 29 12:21 templates -rw-r--r-- 1 mz01-hj staff 1108 Jun 29 12:21 values.yaml 3.2.1.3 로봇 샵을 위한 robot-shop 네임스페이스를 만들고, 해당 네임스페이스 이스티오 인젝션을 주입 ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl create ns robot-shop namespace/robot-shop created ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl label namespace robot-shop istio-injection=enabled namespace/robot-shop labeled 3.2.1.4 헬름으로 로봇 샵을 배포 ➜ helm git:(master) (☸️ |hj-istio-classic:default) helm install robot-shop --namespace robot-shop . NAME: robot-shop LAST DEPLOYED: Thu Jun 29 13:02:32 2023 NAMESPACE: robot-shop STATUS: deployed REVISION: 1 TEST SUITE: None 3.2.1.5 배포되어진 로봇 샵 관련 Pod와 서비스를 확인 ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl get po,svc -n robot-shop NAME READY STATUS RESTARTS AGE pod/cart-7d568797bf-96cnb 2/2 Running 0 2m13s pod/catalogue-7675c4c9f6-m6vxk 2/2 Running 0 2m12s pod/dispatch-684fcb8f68-gppbm 2/2 Running 0 2m13s pod/mongodb-769dcffb9f-cvq8x 2/2 Running 0 2m13s pod/mysql-77f486876b-zcf6f 2/2 Running 0 2m13s pod/payment-7d67fb95cb-vpp7x 2/2 Running 0 2m13s pod/rabbitmq-58ff49565-xkmnj 2/2 Running 0 2m13s pod/ratings-b47dd9576-64cql 1/2 Running 0 2m13s pod/redis-0 2/2 Running 0 2m13s pod/shipping-58f86cd444-2d4n2 1/2 Running 0 2m13s pod/user-864784697b-g2lm6 2/2 Running 0 2m13s pod/web-5bb847c66b-vqd9w 2/2 Running 0 2m13s 57
  • 58. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) service/cart ClusterIP 10.112.8.234 <none> 8080/TCP service/catalogue ClusterIP 10.112.1.84 <none> 8080/TCP service/dispatch ClusterIP None <none> 55555/TCP service/mongodb ClusterIP 10.112.6.1 <none> 27017/TCP service/mysql ClusterIP 10.112.13.219 <none> 3306/TCP service/payment ClusterIP 10.112.6.179 <none> 8080/TCP service/rabbitmq ClusterIP 10.112.3.186 <none> X service/ratings ClusterIP 10.112.5.5 <none> 80/TCP service/redis ClusterIP 10.112.2.125 <none> 6379/TCP service/shipping ClusterIP 10.112.15.87 <none> 8080/TCP service/user ClusterIP 10.112.12.148 <none> 8080/TCP service/web LoadBalancer 10.112.6.225 xx.27.xx.xx 8080:30423/TCP 3.2.1.6 배포된 로봇 샵 MSA를 웹브라우저에 web 서비스의 IP를 입력해서 확인 3.2.1.7 로봇 샵이 이스티오를 통해서 외부와 연결되고 동작할 수 있도록 게이트웨이와 버추얼서비스 배포 ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl -n robot-shop apply -f ../Istio/gateway.yaml gateway.networking.istio.io/robotshop-gateway created virtualservice.networking.istio.io/robotshop created 3.2.1.8 배포된 게이트웨이와 버추얼서비스를 확인 ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl get gw,vs -n 58
  • 59. robot-shop NAME AGE gateway.networking.istio.io/robotshop-gateway X NAME GATEWAYS HOSTS AGE virtualservice.networking.istio.io/robotshop ["robotshop-gateway"] ["*"] X 3.2.1.9 외부에서 이스티오의 ingressgateway를 통해서 접속 가능한지 확인하기 위해 IP 주소 확인 ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl -n istio-system get svc istio-ingressgateway NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) istio-ingressgateway LoadBalancer 10.112.12.147 xx.67.xxx.xxx X 3.2.1.10 웹브라우저에 ingressgateway IP를 입력한 후에 아이템 몇개를 `add to cart` 버튼을 통해서 카트에 넣음 3.2.1.11 로봇 샵 MSA의 동작을 확인하기 위해 이스티오 키알리 대시보드의 IP 주소를 확인 ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl -n istio-system get svc kiali NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) kiali LoadBalancer 10.112.11.184 xx.74.xxx.xxx 20001 59
  • 60. 3.2.1.12 확인한 키알리 대시보드의 IP를 웹브라우저에 입력하고 Graph로 이동 Tip!☸ 위와 같이 나오지 않는 경우 부하가 발생하지 않은 경우임으로, 3.1.2.10 `add to cart`를 다시 진행한 후에 확인합니다. 3.2.1.13 확인이 모두 끝났다면 다음 진행을 위해서 배포한 리소스를 삭제 ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl -n robot-shop delete -f ../Istio/gateway.yaml gateway.networking.istio.io "robotshop-gateway" deleted virtualservice.networking.istio.io "robotshop" deleted ➜ helm git:(master) (☸️ |hj-istio-classic:default) helm uninstall -n robot-shop robot-shop release "robot-shop" uninstalled ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl delete ns robot-shop namespace "robot-shop" deleted 60
  • 61. Tip!☸ 리소스의 여유가 있다면, 꼭 삭제하지 않아도 됩니다. 다만 추후 진행되는 랩에서 실습이 진행되는 네임스페이스는 반드시 분리되어야 합니다. ➜ helm git:(master) (☸️ |hj-istio-classic:default) kubectl top node --use-protocol-buffers NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% gke-istio-classic-p-e5ef5921-58mv 255m 13% 2051Mi 33% gke-istio-classic-p-e5ef5921-n9e6 211m 10% 2194Mi 36% gke-istio-classic-p-e5ef5921-oqvk 176m 9% 1733Mi 28% 3.2.1 구글 클라우드의 앤토스 은행 3.2.3.1 MSA 디렉터리로 이동한 후에 온라인 브티크를 online-boutique 이름으로 git clone 함 ➜ MSA (☸️ |hj-istio-classic:default) git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git Cloning into 'bank-of-anthos'... remote: Enumerating objects: 14635, done. remote: Counting objects: 100% (620/620), done. remote: Compressing objects: 100% (262/262), done. remote: Total 14635 (delta 453), reused 489 (delta 350), pack-reused 14015 Receiving objects: 100% (14635/14635), 6.67 MiB | 11.09 MiB/s, done. Resolving deltas: 100% (10162/10162), done. ➜ MSA (☸️ |hj-istio-classic:default) 3.2.3.1 MSA 디렉터리로 이동한 후에 온라인 브티크를 online-boutique 이름으로 git clone 함 ➜ MSA (☸️ |hj-istio-classic:default) cd bank-of-anthos ➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl apply -f ./extras/jwt/jwt-secret.yaml secret/jwt-key created ➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl apply -f ./kubernetes-manifests configmap/accounts-db-config created service/accounts-db created statefulset.apps/accounts-db created service/balancereader created 61
  • 62. deployment.apps/balancereader created configmap/environment-config created configmap/service-api-config created configmap/demo-data-config created serviceaccount/bank-of-anthos created service/contacts created deployment.apps/contacts created service/frontend created deployment.apps/frontend created configmap/ledger-db-config created service/ledger-db created statefulset.apps/ledger-db created service/ledgerwriter created deployment.apps/ledgerwriter created deployment.apps/loadgenerator created service/transactionhistory created deployment.apps/transactionhistory created service/userservice created deployment.apps/userservice created 3.2.2.3 배포된 파드와 서비스를 확인함. 특히 frontend-external의 External-IP를 확인 ➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl get po,svc NAME READY STATUS RESTARTS AGE pod/accounts-db-0 2/2 Running 0 7m10s pod/balancereader-84cc84cff9-jsts6 2/2 Running 0 7m6s pod/contacts-675865b4bd-bq2kx 2/2 Running 0 7m7s pod/frontend-5c7bd5c94b-6qm55 2/2 Running 0 7m6s pod/ledger-db-0 2/2 Running 0 7m5s pod/ledgerwriter-69b446d5b8-pztrf 2/2 Running 0 7m4s pod/loadgenerator-84dcf4dfcb-stm7v 2/2 Running 0 7m4s pod/transactionhistory-6c69cf5759-swjsd 2/2 Running 0 7m2s pod/userservice-8b588679c-tvqrb 2/2 Running 0 7m2s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/accounts-db ClusterIP 10.112.15.190 <none> 5432/TCP 7m10s service/balancereader ClusterIP 10.112.12.80 <none> 8080/TCP 7m10s service/contacts ClusterIP 10.112.3.10 <none> 8080/TCP 7m7s service/frontend LoadBalancer 10.112.6.19 34.170.55.76 80:31252/TCP 7m6s service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 190d service/ledger-db ClusterIP 10.112.15.176 <none> 5432/TCP 7m5s service/ledgerwriter ClusterIP 10.112.14.65 <none> 8080/TCP 7m4s service/transactionhistory ClusterIP 10.112.15.53 <none> 8080/TCP 7m3s service/userservice ClusterIP 10.112.14.240 <none> 8080/TCP 7m2s 62
  • 63. 3.2.2.4 배포된 애플리케이션을 frontend-external의 External-IP의 주소로 접속해 확인 3.2.3.5 서비스 메시의 상태를 확인하기 위해, 키알리 대시보드 주소를 확인 ➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl -n istio-system get svc kiali NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) kiali LoadBalancer 10.112.11.184 xx.74.xxx.xxx 20001 63
  • 64. 3.2.3.6 확인된 주소로 이동한 후에 메뉴에서 Graph - default 네임스페이스를 선택 64
  • 65. 3.2.3.7 키알리 default 네임스페이스에 보여지는 앤토스 은행의 연결 구조를 확인 3.2.3.1 MSA 디렉터리로 이동한 후에 온라인 브티크를 online-boutique 이름으로 git clone 함 ➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl delete -f ./kubernetes-manifests configmap "accounts-db-config" deleted service "accounts-db" deleted statefulset.apps "accounts-db" deleted service "balancereader" deleted deployment.apps "balancereader" deleted configmap "environment-config" deleted configmap "service-api-config" deleted configmap "demo-data-config" deleted serviceaccount "bank-of-anthos" deleted service "contacts" deleted deployment.apps "contacts" deleted service "frontend" deleted deployment.apps "frontend" deleted configmap "ledger-db-config" deleted service "ledger-db" deleted statefulset.apps "ledger-db" deleted service "ledgerwriter" deleted 65
  • 66. deployment.apps "ledgerwriter" deleted deployment.apps "loadgenerator" deleted service "transactionhistory" deleted deployment.apps "transactionhistory" deleted service "userservice" deleted deployment.apps "userservice" deleted ➜ bank-of-anthos git:(main) (☸️ |hj-istio-classic:default) kubectl delete -f ./extras/jwt/jwt-secret.yaml secret "jwt-key" deleted 3.2.3.1 MSA 디렉터리로 이동한 후에 온라인 브티크를 online-boutique 이름으로 git clone 함 66
  • 67. 3.2.3 구글 클라우드의 온라인 부티크 구글 클라우드 플랫폼에서 마이크로서비스를 위해 데모로 작성한 애플리케이션 [그림] 온라인 부티크의 아키택처 3.2.3.1 MSA 디렉터리로 이동한 후에 온라인 브티크를 online-boutique 이름으로 git clone 함 ➜ robot-shop git:(master) (☸️ |hj-istio-classic:default) cd ~/istio-1.16.1/MSA ➜ MSA (☸️ |hj-istio-classic:default) git clone https://github.com/GoogleCloudPlatform/microservices-demo.git online-boutique Cloning into 'online-boutique'... remote: Enumerating objects: 11993, done. remote: Counting objects: 100% (4584/4584), done. remote: Compressing objects: 100% (367/367), done. remote: Total 11993 (delta 4430), reused 4226 (delta 4216), pack-reused 7409 Receiving objects: 100% (11993/11993), 31.71 MiB | 7.51 MiB/s, done. Resolving deltas: 100% (9050/9050), done. ➜ MSA (☸️ |hj-istio-classic:default) 67
  • 68. 3.2.3.2 내려받은 온라인 부디크 디렉터리로 이동한 후에 메니페스트를 통해 애플리케이션을 배포 ➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl apply -f ./release/kubernetes-manifests.yaml deployment.apps/emailservice created service/emailservice created deployment.apps/checkoutservice created service/checkoutservice created deployment.apps/recommendationservice created service/recommendationservice created deployment.apps/frontend created service/frontend created service/frontend-external created deployment.apps/paymentservice created service/paymentservice created deployment.apps/productcatalogservice created service/productcatalogservice created deployment.apps/cartservice created service/cartservice created deployment.apps/loadgenerator created deployment.apps/currencyservice created service/currencyservice created deployment.apps/shippingservice created service/shippingservice created deployment.apps/redis-cart created service/redis-cart created deployment.apps/adservice created service/adservice created 3.2.3.3 배포된 파드와 서비스를 확인함. 특히 frontend-external의 External-IP를 확인 ➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl get po,svc NAME READY STATUS RESTARTS AGE pod/adservice-5464cc8db4-f8m7n 2/2 Running 0 3m36s pod/cartservice-6458db7c7c-8lbzv 2/2 Running 0 3m51s pod/checkoutservice-55b497bfb8-n8dk6 2/2 Running 0 4m8s pod/currencyservice-6f868d85d8-mf4n5 2/2 Running 0 3m46s pod/emailservice-5cf5fc5898-9lx98 2/2 Running 0 4m11s pod/frontend-bfdf66596-c4txn 2/2 Running 0 4m2s pod/loadgenerator-6568b868f-slfjd 2/2 Running 0 3m47s pod/paymentservice-5ff68d9c7d-gfwdj 2/2 Running 0 3m57s pod/productcatalogservice-5b9c9f6488-wpxvb 2/2 Running 0 3m54s pod/recommendationservice-c58857d6-28bkh 2/2 Running 0 4m5s 68
  • 69. pod/redis-cart-79b899577-47msg 2/2 Running 0 3m39s pod/shippingservice-6f65f85b8b-lw8d7 2/2 Running 0 3m43s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/adservice ClusterIP 10.112.9.239 <none> 9555/TCP 3m36s service/cartservice ClusterIP 10.112.12.212 <none> 7070/TCP 3m50s service/checkoutservice ClusterIP 10.112.2.75 <none> 5050/TCP 4m7s service/currencyservice ClusterIP 10.112.2.98 <none> 7000/TCP 3m45s service/emailservice ClusterIP 10.112.15.61 <none> 5000/TCP 4m11s service/frontend ClusterIP 10.112.12.97 <none> 80/TCP 4m1s service/frontend-external LoadBalancer 10.112.13.102 34.31.23.25 80:32084/TCP 4m service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 189d service/paymentservice ClusterIP 10.112.8.120 <none> 50051/TCP 3m56s service/productcatalogservice ClusterIP 10.112.1.199 <none> 3550/TCP 3m53s service/recommendationservice ClusterIP 10.112.1.193 <none> 8080/TCP 4m4s service/redis-cart ClusterIP 10.112.1.101 <none> 6379/TCP 3m39s service/shippingservice ClusterIP 10.112.14.55 <none> 50051/TCP 3m42s 3.2.3.4 배포된 애플리케이션을 frontend-external의 External-IP의 주소로 접속해 확인 69
  • 70. 3.2.3.5 서비스 메시의 상태를 확인하기 위해, 키알리 대시보드 주소를 확인 ➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl -n istio-system get svc kiali NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) kiali LoadBalancer 10.112.11.184 xx.74.xxx.xxx 20001 3.2.3.6 확인된 주소로 이동한 후에 메뉴에서 Graph - default 네임스페이스를 선택 70
  • 71. 3.2.3.7 키알리 default 네임스페이스에 보여지는 온라인 부티크의 연결 구조를 확인 3.2.3.8 간단하게 배포된 애플리케이션 삭제 ➜ online-boutique git:(main) (☸️ |hj-istio-classic:default) kubectl delete -f ./release/kubernetes-manifests.yaml deployment.apps "emailservice" deleted service "emailservice" deleted deployment.apps "checkoutservice" deleted service "checkoutservice" deleted deployment.apps "recommendationservice" deleted service "recommendationservice" deleted deployment.apps "frontend" deleted service "frontend" deleted service "frontend-external" deleted deployment.apps "paymentservice" deleted service "paymentservice" deleted deployment.apps "productcatalogservice" deleted service "productcatalogservice" deleted deployment.apps "cartservice" deleted service "cartservice" deleted deployment.apps "loadgenerator" deleted deployment.apps "currencyservice" deleted service "currencyservice" deleted deployment.apps "shippingservice" deleted service "shippingservice" deleted 71
  • 72. deployment.apps "redis-cart" deleted service "redis-cart" deleted deployment.apps "adservice" deleted service "adservice" deleted 3.2.3.9 애플리케이션 삭제 이후에 키알리 대시보드에서도 보이지 않는지 확인 72
  • 73. 3.3. 보안 기능들 (Security capabilities) 마이크로서비스는 중간자 공격에 대한 보호(man-in-the-middle attacks), 유연한 액세스 제어, 감사 도구, 상호 TLS 등 특별한 보안 요구 사항들이 필요합니다. Istio에는 운영자가 이러한 모든 문제들을 해결할 수 있는 포괄적인 보안 솔루션이 포함되어 있습니다. 강력한 신원 확인, 강력한 정책, TLS 암호화, 인증, 권한 부여 및 감사(AAA) 들을 위한 도구를 제공하여 서비스와 데이터를 보호합니다. Istio의 보안 모델은 기본적으로 안전을 기반으로 하여, 신뢰할 수 없는 네트워크에서도 보안을 고려한 애플리케이션을 배포할 수 있도록 강력한 보호 기능을 제공하려고 합니다. [출처: https://istio.io/latest/about/service-mesh/ ] 4. 이스티오 앰비언트 메시 부록 ➜ istio-1.16.1 (☸️ |hj-istio-classic:default) TBD 73