Slide 1

Slide 1 text

| © 2023 Cloud Ace, Inc サイドカーフリーな Service Mesh である Cilium が気 になるのでユースケースを考えてみた。

Slide 2

Slide 2 text

| © 2023 Cloud Ace, Inc 自己紹介 間瀬 真( @Makocchan_Re ) クラウドエース株式会社 技術本部 システム開発部 ユニットマネージャー ● 2022 年 9 月より現職にて Google Cloud を中心とし たシステムの提案や SI に従事 ● 前職では 11 年程オンプレ、クラウド上の自社サービス 開発や SI に従事 オンラインでの資格試験は自宅のお 風呂で受験します。 個人的にベストプ ラクティスです。

Slide 3

Slide 3 text

| © 2023 Cloud Ace, Inc 会社紹介 ※2023 年 7 月時点 
 クラウドエース株式会社 代表取締役社長 青木 誠 設立  :2016 年 11 月 1 日 資本金 :1 億円 従業員数: 300 名(グループ全体 540 名) Tokyo (HQ) Osaka, Nagoya, Fukuoka Taipei Shenzhen Hong Kong Bangkok Ho Chi Minh & Hanoi Gurugram Singapore Jakarta Berlin Sao Paulo Delhi Bangalore Mumbai Silicon Valley Johannesburg

Slide 4

Slide 4 text

| © 2023 Cloud Ace, Inc 本日内容 ◾話したいこと ● Kubernetes® 上の Cilium™ における特徴や機能 ● 現時点で Cilium を導入すると活きてきそうなケース ◾対象者 ● Cilium について興味があるが、よく知らない方 ● 興味あるわけではないけど、好奇心が旺盛な方

Slide 5

Slide 5 text

| © 2023 Cloud Ace, Inc Cilium を知ったきっかけとモチベーション ● Google Kubernetes Engine ( 以下、GKE )を使った開発プロジェクトに参画 した際に Cilium が実装されている Dataplane v2 を利用していた。 ● 開発中のトラブルシューティングをしていた際にログから Cilium の存在を知 る。 ● 当時のプロジェクトでは必須で利用しなければいけない理由は特になかった が、気になったので本来どのようなユースケースに向いていて、どんな課題 を解決するのか知りたくなった。

Slide 6

Slide 6 text

| © 2023 Cloud Ace, Inc Cilium ● アプリケーション間の接続や透過的に保護・モニ タリングすることができるソフトウェアで CNI Plugins と Service Mesh の側面を持っている。 ● eBPF® という Linux カーネルの機能を利用して いる。 ※本資料で紹介する Cilium のバージョンは v1.13.4 になります。

Slide 7

Slide 7 text

| © 2023 Cloud Ace, Inc ● コンテナを運用管理するためのソフト ウェア ● コンテナの死活監視、デプロイ、トラ フィック管理等を担う。 ● クラスタ構成となり、コントロールプレー ンとワーカーノードより構成される。 ● Pod と呼ばれる単位でコンテナアプリ ケーションをデプロイする。 Kubernetes コントロールプレーン コンポーネント コンポーネント 管理コンポーネント ワーカーノード kubelet kube-proxy アプリケーションPod ・コントロールプレーンの主な役割 クラスタへの要求の受付、状態の永続化、コンテナ起 動要求、起動先ノードの選定 etc.. ・kubelet: Pod の起動停止、Pod の死活監視 ・CNI plugin: Podの IP アドレス管理 ※CNI: Container Network Interface ・kube-proxy: Service の検出とネットワークルールの更 新 (以下、k8s と略) CNI plugin

Slide 8

Slide 8 text

| © 2023 Cloud Ace, Inc ● Extended Berkeley Packet Filter の略 ● プログラムをLinuxカーネル上で動作させることが 可能 ● 特定の syscall や NIC へのパケット到達といった イベントをトリガーに実行することが可能 ● カーネル空間とユーザ空間での切り替えにかか るオーバヘッドを削減する効果もある。 eBPF Kernel Space User Space Program eBPF 検証&コンパイルを 経てロード Process syscall による フック パケット到達によるフッ ク eBPF Maps 情報を保管 参照

Slide 9

Slide 9 text

| © 2023 Cloud Ace, Inc Service Mesh ● モニタリングやロギング、プロキシなどのアプリ ケーションに共通する関心事を効率的に実装する ためのコンポーネント ● k8s ではサイドカーコンテナとして、 Pod へアプリ ケーションコンテナと併せてデプロイされる。 ● Istio® を利用するケースが多いイメージ ● Istio では Envoy® というプロキシがサイドカーコ ンテナとしてデプロイされる。 Pod Pod アプリケーショ ンA アプリケーショ ンB サイドカー (envoy-proxy) サイドカー (envoy-proxy) エンドポイントの公開等 サイドカー経由での通信 Istio controllplane

Slide 10

Slide 10 text

| © 2023 Cloud Ace, Inc Cilium の特徴

Slide 11

Slide 11 text

| © 2023 Cloud Ace, Inc Node Cilium の特徴 - ネットワーキング Pod 送信元 Pod Pod Pod 宛先 Pod を Service1 として公開 10.72.1.128 : 8080 iptables kube-proxy Service を管理 Service1 -> 10.72.1.128 : 8080 Service1 -> 10.72.1.129 : 8080 http://Service1 .128 or .129 のどちらかへ DNATして送信 ● まずは Cilium を利用しない iptables による負荷分散を紹介 ● iptables は Service の IP から宛先Pod の IP アドレスへ変換する際にシーケンシャルに処 理する必要があるため、テーブルの情報量に比例してオーバーヘッドが増える。 だいぶ簡略化しています 10.72.1.129 : 8080

Slide 12

Slide 12 text

| © 2023 Cloud Ace, Inc Node Pod 送信元 Pod Cilium の特徴 - ネットワーキング eBPF Conntrack Map Cilium Agent Service の管理 Service Map ● Cilium を利用すると kube-proxy ではなく、Cilium が Service を管理する。 ● iptables を利用せずに負荷分散を行うことで、効率的に処理している。 Pod Pod 宛先 Pod を Service1 (10.96.0.10:80) として公開 10.72.1.128 : 8080 10.72.1.129 : 8080 http://Service1 .128 or .129 のどちらかへ DNATして送信 ID Frontend Type Backend ID Backend IP 1 10.96.0.10:80 Cluster IP 1 10.72.1.128 : 8080 1 10.96.0.10:80 Cluster IP 2 10.72.1.129 : 8080

Slide 13

Slide 13 text

| © 2023 Cloud Ace, Inc パフォーマンス公開情報 *1 出典 : (https://docs.cilium.io/en/v1.13/operations/performance/benchmark/) ● Cilium vs Calico において Cilium の方 が高速という結果が Cilium の Doc に て公開されている。 Cilium の Doc にて公開されている Cilium (①) と Calico (②) のリクエストレート比較ベンチマーク *1 ① ②

Slide 14

Slide 14 text

| © 2023 Cloud Ace, Inc Node Node Cilium の特徴 - Service Mesh ● Pod 毎のサイドカーモデルからサイド カーフリーモデルへ ● Pod がシンプルになり、コンテナが減る ことによって起動時間も改善 ● ノードリソースの節約 ● ユーザ空間とカーネル空間の切り替え にかかるオーバーヘッドを軽減 App envoy- proxy サイドカーモデル サイドカーフリーモデル Kernel eth0 サイドカーを経由しないとサービスメッ シュとしての機能を利用できないた め、基本的に全てのトラフィックを経由 させる。 App envoy- proxy Kernel eth0 Cilium プロキシが必要な通信のみ Envoy を経由させ ることでパフォーマンスを向上させる。 Cilium 自体がセキュリティ、モニタリングする機 能を提供しているため全ての通信を Envoy を経 由させる必要はない。 一部の通信のみ Pod Pod loopback

Slide 15

Slide 15 text

| © 2023 Cloud Ace, Inc ノードリソースの制約 サイドカーモデル サイドカーフリーモデル app envoy-proxy Istio によってデプロイされるサイドカー (envoy-proxy) における Resource request はデフォルトでは1コンテナあたり CPU 10m, Mem 40Mi ● サイドカーフリーになることにより、必要なリソースが削減される。 Node Node Pod

Slide 16

Slide 16 text

| © 2023 Cloud Ace, Inc パフォーマンス公開情報 isovalent 社が公開している Cilium のみ / Cilium + Envoy / Cilium + Istio でのパフォーマンス情報 * * 出典: (https://isovalent.com/blog/post/cilium-service-mesh/) ● モデルによるレイテンシの差は 1 ~ 2 ms の違いなので、レイテンシのメリッ トは小さいかもしれない。 ● Pod 毎にサイドカーが不要になること によるリソースの節約や Pod がシンプ ルになるメリットが個人的には大きい。

Slide 17

Slide 17 text

| © 2023 Cloud Ace, Inc ● CiliumEnvoyConfig / CiliumClusterwideEnvoyConfig とい うリソースとしてプロキシを設定 ● 現時点では利用できる Envoy の拡張 機能は制限されていることに注意 ● カナリア、B/G デプロイや JWT 検証 (jwt_authn)、外部認可 (ext_authz) 等 は利用可能 Cilium での Envoy の使い方 apiVersion: cilium.io/v2 kind: CiliumEnvoyConfig metadata: name: reviews spec: services: - name: reviews namespace: default - name: reviews-v2 namespace: default resources: # 以降、Envoyの static_resources 相当のものを記述 # 慣れないと結構書くの大変 listenするservice ※ Cilium がインストールされたクラスタに Istio をインストールすることは可能 CiliumEnvoyConfig の一部

Slide 18

Slide 18 text

| © 2023 Cloud Ace, Inc Cilium の特徴 - クラスターメッシュ ● 異なる k8s クラスタ間で連携が可 能。 ● 可用性を向上させたり、共有サー ビスを持つクラスタを複数のクラス タから共有するようなテナント分離 が可能。 ● ネットワークポリシー等、クラスタ間 で共有することが可能。 Pod Pod SVC SVC Pod SVC クラスタA クラスタB 共有サービスク ラスタ 可用性の確保 クラスタの共有

Slide 19

Slide 19 text

| © 2023 Cloud Ace, Inc ● L3 / L4 での制御に加えて、FQDNや L7 での制限が可能 ● HTTP に加えて、Kafka* のトピックに 対する produce, consume の制限 も可能 ● CiliumClusterWideNetworkPolicy でクラスタ全体に適用も可能 * 現時点でKafka のポリシーは beta Cilium の特徴 - ネットワークポリシー apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "l7-rule" spec: endpointSelector: matchLabels: app: myService ingress: - toPorts: - ports: - port: '80' protocol: TCP rules: http: - method: GET path: "/path1$" headers: - 'X-My-Header: true' L7 ポリシー例

Slide 20

Slide 20 text

| © 2023 Cloud Ace, Inc Cilium の特徴 - IPSecによる透過的暗号化 ● IPSec によって Pod 間の通信 を透過的に暗号化。 ● 異なるノードへの通信時には 暗号化されない。 ● PSK(Pre-Shared Key) は Secret として作成しておく必要 あり。 Node Pod Node Pod Cilium Cilium 🔑 🔑 PSK PSK 暗号化 平文 平文 復号化 root@master-cilium-sec:/home/cilium# tcpdump -l -n -i cilium_vxlan esp tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on cilium_vxlan, link-type EN10MB (Ethernet), snapshot length 262144 bytes 15:53:15.792945 IP 10.0.2.174 > 10.0.0.84: ESP(spi=0x00000003,seq=0x95), length 88 15:53:15.793154 IP 10.0.0.84 > 10.0.2.174: ESP(spi=0x00000003,seq=0x93), length 88 ESP: Encapsulated Security Payload    ペイロード部の暗号化を行う IPSec のプロトコル ※今回割愛しますが、 WireGuard による透過的暗号化にも対応しています。

Slide 21

Slide 21 text

| © 2023 Cloud Ace, Inc Cilium の特徴 - Hubbleによるモニタリング ● Cilium 上で動作するネットワーク を可視化するソフトウェア。 ● ブラウザ、CLI よりトラフィックの確 認が可能。 ● L3 / L4 / L7 の可視化が可能。 ● サイドカー無しでサービスマップや トラフィックを参照することが可能。 hubble-ui による可視化 CLI による可視化 トラフィック毎 の情報

Slide 22

Slide 22 text

| © 2023 Cloud Ace, Inc Prometheus との連携 Grafana Dashboard ● Cilium, Hubble のメトリクスを Prometheus にて収集が可能。 ● メトリクスを Grafana で可視化する ことで、L4, L7 に関するメトリクスが 参照可能。 一部拡大

Slide 23

Slide 23 text

| © 2023 Cloud Ace, Inc あなたのすぐそこにも Cilium

Slide 24

Slide 24 text

| © 2023 Cloud Ace, Inc ● Google Cloud ○ Cilium で実装されている Dataplane v2 が GKE で選択可能。 ○ 2023 / 7 / 13 に GKE Dataplane V2 observability が Public Preview に。 ● Alibaba Cloud ○ Ciliumで実装されている Terway CNI が Alibaba Cloud Container Service for Kubernetes で 選択可能。 ● Amazon Web Service ○ Amazon EKS Anywhere のネットワーキングが Cilium にて実装。 ● Azure ○ Azure CNI Powered by Cilium が Azure Kubernetes Service で選択可能。 パブリッククラウドでの導入状況 現時点では、Cilium の全ての機能が提供されているわけではないことに注意 ← 本機能について後頁にて紹介

Slide 25

Slide 25 text

| © 2023 Cloud Ace, Inc GKE Dataplane v2 ● 従来の Calico 、iptables によるネット ワーキングから Cilium へ。 ● Standard 版では利用するか選択可 能、Autopilot 版では新しいバージョン は(強制的に)有効に。 ● NetworkPolicy* での許可 or 拒否の通 信を Cloud Logging へ出力可能 * Cilium が提供する CiliumNetworkPolicy ではなく、 k8s が提供してい るNetworkPolicy です。 尚、FQDNNetworkPolicy という機能が提供されており、 FQDN によ るフィルタは可能ですが、現時点では Public Preview になります。 ネットワークポリシーロギングによって Cloud Logging へ 出力されるログサンプル 送信先、送信元 のIP や Port 送信先 Pod 情報 許可 or 拒否 送信元 Pod 情報

Slide 26

Slide 26 text

| © 2023 Cloud Ace, Inc 従来の GKE と GKE Dataplane v2 でのパフォーマンス比較 ● Dataplane v2 に関する設定以外はクラスタ間で条件を揃 えて実施した。 ※GKE Dataplane V2 observabilityは無し ● ダミーとなる Service と Pod を 100 , 500 , 1000 とシナリ オ別に用意してサンプルAPに対して負荷をかけて、10回程 度試行した際の応答時間 p(95) の平均を比較した。 ● 従来のものと Dataplane v2 間での違いはほとんど見られ ず、100 と 1000 のシナリオでの差も数十 ms 程度で大き な差は見られなかった。 実施環境、AP、マシンリソースによって結果は異なる ので内容を保証するものではありません。 低いほど早い 数十msの差

Slide 27

Slide 27 text

| © 2023 Cloud Ace, Inc まとめ ~ 本日持ち帰っていただきたいこと ~

Slide 28

Slide 28 text

| © 2023 Cloud Ace, Inc Cilium の特徴とメリット ➢ 従来より高速なネットワーキングを提供 ➢ サイドカーフリーとなることで k8s クラスタにおいて必要なリソース量が減り、 Pod の構成もシンプルに。 ➢ 上記に加え、Envoy によるプロキシ、高度なネットワークポリシーによるトラ フィック制御、透過的な通信の暗号化、モニタリングが実現可能であること。

Slide 29

Slide 29 text

| © 2023 Cloud Ace, Inc ➢ 大規模なワークロードで低いレイテンシを追求する必要があるケース ➢ サービスメッシュをモニタリングやセキュリティ目的で導入されている、 または導入したいと考えているケース ○ マイクロサービスのトラフィックを管理するような機能は現時点では Istio の方が多く、実装しやす いので、これら機能が必要な場合は Istio の方が管理しやすい。 ○ 既に Istio を使っていて、レイテンシの SLO 等要件を満たせている状態であれば導入するメリット は今のところは大きくないと思われる。 現時点で Cilium の導入が活きてそうなケース

Slide 30

Slide 30 text

| © 2023 Cloud Ace, Inc ご清聴ありがとうございました Cilium™ はThe Linux Foundation の商標です。 Kubernetes® は The Linux Foundation の登録商標です。 Istio® は The Linux Foundation の登録商標です。 Envoy™ はThe Linux Foundation の商標です。 eBPF Foundation および eBPF Foundation のロゴデザインは eBPF Foundation の登録商標です。