Istioのenvoyサイドカーをデバッグする - CADDi Tech Blog
SREチームの前多です。以前、Google Cloudが提供するサービスメッシュのAnthos Service Meshの入門記事を書きました。 caddi.tech この記事のまとめで私は、Istio (Anthos Service MeshのベースのOSS) を詳しく知るには、envoyのことをもっと知る必要があると書きました。 そしてサービスメッシュで何かエラーが起きているとき、それはサービスメッシュ自体ではなく インフラやアプリケーションのバグや設定ミスがサービスメッシュによってあぶり出されるということも述べました。 先日、サービスメッシュ上でPod間のgRPC通信が特定条件で失敗し、サイドカーがない場合のみ通信が成功するという事象が起きていました。 gRPCのライブラリのアップデートやIssueの調査しましたが、原因がわからずサイドカーを外すしかないかと思っていました。 最終手段
【Istio⛵️】Istioによって抽象化されるEnvoyのHTTPSリクエスト処理の仕組み - 好きな技術を布教したい 😗
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Istioのサイドカーメッシュを題材にしたEnvoyの設定の抽象化について 様々なサービスメッシュツール (特に、Istio、Consul、Cilium、など) でも流用できるEnvoyの知識について この記事から得られる知識 01. はじめに 02. 様々なリソースによるEnvoy設定の抽象化 サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 03. istio-proxyコンテナによるHTTPS処理 Istioコントロールプレーンの仕組み サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 04. EnvoyによるHTTPS処理 Envoyの設定の種類 フィルター フィルターの一覧 フィルターチェーンの仕
「KubeCon NA 2022」から、サイドカーレスを実装したサービスメッシュのIstioのセッションを紹介
「KubeCon + CloudNativeCon NA 2022」から、サービスメッシュのIstioのセッションを紹介する。IstioはGoogle、IBM、Lyftが初期の開発を行い、その後CiscoやRed Hat、Solo.ioなども加わって開発を継続しているサービスメッシュのオープンソースソフトウェアだ。2022年9月28日にCNCF配下のインキュベーションプロジェクトとして採用された。実は2020年にGoogleはOpen Usage Commonsというトレードマークの管理を行う非営利団体を立ち上げ、Istioを寄贈した。これは「Istioのガバナンスを中立的な組織に移譲して欲しい」というオープンソースコミュニティからは非難されることとなった。GoogleがOpen Usage Commonsを立ち上げたことに関しては以下の記事を参照されたい。 ●参考：GoogleがIsti
CNSC 2022、日立のエンジニアがNISTの仕様をベースにIstioのセキュアな設定を解説
CloudNative Srcurity Ceonference 2022から、日立のエンジニアによるNISTの仕様の解説とIstioの実装例の詳細を解説。 CloudNative Security Conference 2022から、サービスメッシュ（Istio）におけるセキュリティの詳細な設定を解説するセッションを紹介する。セッションを担当したのは株式会社日立製作所の研究開発グループの井出貴也氏だ。タイトルは「Istioを活用したセキュアなマイクロサービスの実現：アプリ透過型のユーザ及びサービス認証認可」で、前半でマイクロサービスのセキュリティについてNIST（National Institute of Standards and Technology、米国標準技術研究所）のガイドSP800-204について概要と特徴を紹介した後に、サービスメッシュのオープンソースソフトウェアであるIs
Istioサーキットブレーカーで備えるマイクロサービスの連鎖障害 - ZOZO TECH BLOG
はじめに こんにちは。SRE部 ECプラットフォームSREチームの大澤です。 先日、SREチームにてBFF機能を司る「ZOZO Aggregation API」の導入について紹介しました。 techblog.zozo.com BFFは複数のバックエンドと通信するアーキテクチャであるため、通信先のバックエンド障害に大きな影響を受けてしまいます。そのため、ZOZO Aggregation APIでは、各バックエンド間の通信障害をIstioによるタイムアウトとリトライ制御で可用性を担保していました。 今回は、新たにIstioサーキットブレーカーを導入することで、さらなる安定性・回復性の向上を果たした取り組みを紹介します。 サーキットブレーカーとは サーキットブレーカーとは、あるサービスの障害を検知した場合には通信を遮断、その後サービスの復旧を検知すると通信を復旧させる仕組みです。 複数のマイクロ
AWS X-Ray を使った Istio 仮想サービスのトレースの可視化 | Amazon Web Services
ソリューションの概要 コレクタのアーキテクチャはプラガブルなレシーバー、プロセッサ 、エクスポータで構成されており、それらを組み合わせることでパイプラインを形成できます。 メトリックやトレースイベントはレシーバーを介してパイプラインに入り、0以上のプロセッサ を通過し、最後に1つ以上のエクスポータを介してパイプラインは終了します。レシーバーはソースデータ形式のワイヤプロトコルを実装しています。例えば、opentelemetry-collector プロジェクトの zipkin レシーバーは JSON 形式の Zipkin v1 または v2 スパンを OpenTelemetry 内部の表現にデコードするエンドポイントを公開しています。一方、エクスポータはターゲットバックエンド用にワイヤ転送プロトコルを実装しています。コレクタリポジトリは Zipkin 、Jaeger 、Prometheus
AWS App MeshとIstioの比較 - クリエーションライン株式会社
サービスメッシュとは なんのために？なにを解決する？: サービスメッシュは、大規模な組織でのマイクロサービスの適用によって顕在する開発・運用上の問題に対処するためのツールです: オブザーバビリティ: システム全体がネットワークをまたいでしまい複雑になり開発時のトラブルシューティング・運用時の障害解決までの時間が増加する問題 障害分離: 分散ネットワークでのベストプラクティスであるリトライやタイムアウト等の実装が必要な問題 セキュリティ: ネットワーク通信増加によるセキュリティリスクの増加。アプリケーション間の通信のアクセス管理の問題。 この3領域の問題に対処するために導入・利用されます。 ネットワーク通信に関わる問題への対処をアプリケーションから切り離してインフラ層で実装するため、プロダクト開発者はよりプロダクト開発に集中でき、またシステム全体で一貫性のある実装・設定を維持しやすいため運用
Kubernetes Meetup Tokyo #42
9:45 KubeVirtによるIaaS基盤構築 (仮) (30min) - 相良 幸範, ヤフー株式会社47:18 KubernetesとGatlingを使って、負荷試験に秒間10kユーザーをシミュレーションする方法 (30min) - Zhaoqiang Wang (@alexwang2013), Tenka...
Istioによるサービスメッシュをどのようにプロダクションレディにするか - ZOZO TECH BLOG
はじめに SRE部 ECプラットフォームSREチームの小林 (@akitok_) です。 ZOZOTOWNでは、マイクロサービス間通信におけるトラフィック制御のために、Istioによるサービスメッシュを導入しています。本記事ではZOZOTOWNのマイクロサービスプラットフォーム基盤（以下、プラットフォーム基盤）において、Istioをいかにプロダクションレディな状態で本番に投入していったか、その取り組みを紹介します。 なお、Istioによるサービスメッシュを導入した背景については、以下の記事で紹介しています。 techblog.zozo.com はじめに What is Istio? Istioをプロダクションレディにするまでに直面した3つの課題 どのようにリソース消費量を見積もるか Data Planeサイジング Envoyプロキシのチューニング 負荷試験 Istioベンチマーク試験 サー
ZOZOTOWNマイクロサービスの段階的移行を支えるカナリアリリースとサービス間通信における信頼性向上の取り組み - ZOZO TECH BLOG
はじめに SRE部プラットフォームSREチームの川崎 @yokawasa です。 ZOZOTOWNではモノリシックなアーキテクチャーから、優先度と効果が高い機能から段階的にマイクロサービス化を進めています。本記事では、そのZOZOTOWNの段階的なマイクロサービス移行で実践しているカナリアリリースとサービス間通信の信頼性向上の取り組みについてご紹介します。 なお、ZOZOTOWNのリプレイス戦略ついてはこちらのスライドが参考になります。 speakerdeck.com さて、ZOZOTOWNマイクロサービスプラットフォーム（以下、プラットフォーム）はAWS上に構築しており、コンテナーアプリ基盤にマネージドKubernetesサービスであるEKSを採用しています。また、複数サービスを単一Kubernetesクラスターで稼働させる、いわゆるマルチテナントクラスター方式を採用しています。 下記イ
マイクロサービスを支える「Istio」の実力は？ サービスメッシュの利点と課題
独立したサービスを組み合わせて1つのアプリケーションを形作る「マイクロサービスアーキテクチャ」。サービスの構造に合わせて開発組織も個別に独立させることで、機能の追加拡張を容易にしたり、開発スピードの高速化を実現したりできるとして注目されている。 しかし、運用面での課題は少なくない。アプリケーション内でサービス同士が通信するため、アクセス制御やルーティングなどの実装／管理コストは増大する。分割されたサービスそれぞれに独立したソリューションを適用した場合、工数が肥大化したり、仕様や品質がサービスごとに変わったりして、開発スピードに影響を及ぼす恐れがある。 その課題を解決する手段の一つが、サービスの独立性という利点を生かしつつ、運用の一貫性を実現する「サービスメッシュ」と呼ばれるデザインパターンだ。2020年1月に行われた「Envoy Meetup Tokyo #1」の講演で、日立製作所の研究開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using AKS-managed Istio External Ingress Gateway with Gateway API
LiveWyer | Service Meshes Decoded: a performance comparison of Istio vs Linkerd vs Cilium
Istio-based service mesh add-on for Azure Kubernetes Service - Preview
Get Started with Istio Ambient Mesh
Istio - A Robust, Extensible Service Mesh for K8s