サービスメッシュのIstio、十分に成熟した段階に到達したとしてCNCFの卒業プロジェクトに
Cloud Native Computing Foundation（CNCF）は、サービスメッシュのIstioが十分成熟した段階に到達したとして、「卒業」（Graduation）プロジェクトになったことを発表しました。 卒業となっても引き続きIstioはCNCF傘下で開発が進められるため、CNCFにおける卒業とは、インキュベーション（育成）段階からの卒業という意味だと言えます。 [NEWS] Cloud Native Computing Foundation Reaffirms #Istio Maturity with Project Graduation Read more: https://t.co/enhd4uT0sG#CNCF #servicemesh #cloudnative #oss pic.twitter.com/A355frCNTO — CNCF (@CloudNative
Istio、サイドカーパターンを不要にする「Ambient Service Mesh」機能をメインブランチに統合、正式な機能へ
Istioは、サービスメッシュを実現する新たな仕組みとして試験的に開発していた「Ambient Service Mesh」をメインブランチに統合し、正式な機能として組み込んで行く方針であることを発表しました。 現在のIstioは、各サービス（≒KubenetesのPod）ごとにプロキシを配置し、サービス間のネットワークをプロキシ経由で構成することによってサービスメッシュを構築しています。これによりサービス間の通信のトラフィックコントロール、暗号化、可観測性（オブザーバビリティ）などの機能が実現されるわけです。 この仕組みは、サービスの隣にプロキシを配置することから、「サイドカー」パターンなどと呼ばれています。 しかしPodごとにサイドカーをデプロイする必要があるため、これにかかる手間やリソースの消費が課題でした。 eBPFを用いたサイドカーフリーなCiliumへ注目が集まる そうした中で最
Istioが新たな仕組み「Ambient Mesh」を発表。サイドカーなしでサービスメッシュを実現
Istioは、サービスメッシュを実現する新たな仕組み「Ambient Mesh」を発表しました。 現在のIstioは、各サービス（≒KubenetesのPod）ごとにプロキシを配置し、サービス間のネットワークをプロキシ経由で構成することによってサービスメッシュを構築しています。これによりサービス間の通信のトラフィックコントロール、暗号化、可観測性（オブザーバビリティ）などの機能が実現されるわけです。 この仕組みは、サービスの隣にプロキシを配置することから、「サイドカー」パターンなどと呼ばれています。 新たな仕組み「Ambient Mesh」では、Pod群をホストしているノードにプロキシを配置し、このプロキシによってサービスメッシュの機能を実現します。 Podごとのプロキシ配置が不要になる、つまり「サイドカーレス」（Sidecar-less）なパターンとなることで、デプロイや管理の容易、コン
サービスメッシュのIstio、Cloud Native Computing Foundationへの提出を発表
サービスメッシュのIstio、Cloud Native Computing Foundationへの提出を発表 GoogleとIstioの開発チームは、IstioをCloud Native Computing Foundation（CNCF）のインキュベーションプロジェクトに提出することを発表しました。 Great news! With the support of @googleOSS and the Istio Steering Committee, we have applied to become a @CloudNativeFdn project! Take a look at our blog and learn more about this process: https://t.co/2rn2YMKEpl #CNCF pic.twitter.com/SHw677mYE4 —
サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発
2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo
AWS X-Ray を使った Istio 仮想サービスのトレースの可視化 | Amazon Web Services
ソリューションの概要 コレクタのアーキテクチャはプラガブルなレシーバー、プロセッサ 、エクスポータで構成されており、それらを組み合わせることでパイプラインを形成できます。 メトリックやトレースイベントはレシーバーを介してパイプラインに入り、0以上のプロセッサ を通過し、最後に1つ以上のエクスポータを介してパイプラインは終了します。レシーバーはソースデータ形式のワイヤプロトコルを実装しています。例えば、opentelemetry-collector プロジェクトの zipkin レシーバーは JSON 形式の Zipkin v1 または v2 スパンを OpenTelemetry 内部の表現にデコードするエンドポイントを公開しています。一方、エクスポータはターゲットバックエンド用にワイヤ転送プロトコルを実装しています。コレクタリポジトリは Zipkin 、Jaeger 、Prometheus
サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
このパターンには2つの背景があります。ひとつは、技術者がマイクロサービスアーキテクチャパターンを採用して、複数の(理想的には単一目的で、独立してデプロイ可能な)サービスで構成されるアプリケーションを開発するようになったことです。ふたつめは、企業がコンテナ(Dockerなど)、オーケストレータ(Kubernetesなど)、プロキシ/ゲートウェイ(Envoyなど)といった、クラウドネイティブなプラットフォームテクノロジを支持するようになったことです。 意図 サービスメッシュが解決しようとする問題は次のようなものです。 サービスディスカバリ、ルーティング、アプリケーションレベル(レイヤ7)の非機能通信要件を処理する言語対応の通信ライブラリを、個々のサービス用にコンパイルする必要性の排除 外部サービスのネットワークロケーション、セキュリティ認証、サービス品質(QoS)目標など、サービス通信設定の外
Istio 1.10リリース。スケーラビリティの向上やカナリアアップデートを容易に
Dockerコンテナで構成された分散アプリケーションに対してサービスメッシュ機能を提供するIstioの最新版「Istio 1.10」がリリースされました。 We’re pleased to announce the release of Istio 1.10! This is our second release of 2021 and like our last few releases we’ve continued to improve Day 2 operations for Istio users. Read all about the new release on our new and improved website!https://t.co/JDSDW5lKse pic.twitter.com/4nf9Vw9qPQ — Istio (@IstioMesh) May 18,
KubeflowによるMLOps基盤構築から得られた知見と課題 - ZOZO TECH BLOG
はじめに こんにちは。SRE部MLOpsチームの中山（@civitaspo）です。みなさんはGWをどのように過ごされたでしょうか。私は実家に子どもたちを預けて夫婦でゆっくりする時間にしました。こんなに気軽に実家を頼りにできるのも全国在宅勤務制度のおかげで、実家がある福岡に住めているからです。「この会社に入って良かったなぁ」としみじみとした気持ちでGW明けの絶望と対峙しております。 現在、MLOpsチームでは増加するML案件への対応をスケールさせるため、Kubeflowを使ったMLOps基盤構築を進めています。本記事ではその基盤構築に至る背景とKubeflowの構築方法、および現在分かっている課題を共有します。 目次 はじめに 目次 MLOpsチームを取り巻く状況 MLOps基盤の要件 MLOps基盤技術としてのKubeflow Kubeflowの構築 ドキュメント通りにKubeflowを構
Wasmで広がるEnvoyとIstioの世界
Kubernetes Meetup Tokyo #40 https://k8sjp.connpass.com/event/206303/
[AWS Black Belt Online Seminar] AWS App Mesh 資料及び QA 公開 | Amazon Web Services
Amazon Web Services ブログ [AWS Black Belt Online Seminar] AWS App Mesh 資料及び QA 公開 先日 (2020/07/31) 開催しました AWS Black Belt Online Seminar「AWS App Mesh」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200721 AWS Black Belt Online Seminar AWS App Mesh AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. サービスメッシュはマイクロサービスアーキテクチャを構築する当初から導入すべきでしょうか？それとも、ある程度の規模になってから導入するべきでしょうか？ A. マイクロサービスアーキテクチャを採用したワークロードを新規構築する様な場合は、
![[AWS Black Belt Online Seminar] AWS App Mesh 資料及び QA 公開 | Amazon Web Services](https://cdn-ak-scissors.b.st-hatena.com/image/square/934f1fa50f258190ac6e83167c9627c499f80c14/height=288;version=1;width=512/https%3A%2F%2Fd2908q01vomqb2.cloudfront.net%2Fb3f0c7f6bb763af1be91d9e74eabfeb199dc1f1f%2F2020%2F07%2F31%2FThumbnail-2.png)
米国防省、KubernetesをF-16ジェット戦闘機に載せてみた
Kubernetesを自動車に載せるというデンソーの発表事例を紹介した6月の記事「Kubernetesを自動車に載せる、デンソーが「Misaki」を発表。年内にもオープンソースとして公開」は多くの読者に読まれました。 このデンソーの発表の中で、（記事では省略していますが）先行事例として米国防省がKubernetesとIstioをF16ジェット戦闘機に載せたことが触れられています。 これは2019年11月にサンディエゴで行われたイベント「KubeCon＋CloudNativeCon North America 2019」で行われたセッション「How the Department of Defense Moved to Kubernetes and Istio」で紹介されたものです。 セッション中では国防省がコンテナとKubernetesを基盤にCI/CDに取り組んでいること、MVP（Mini
サービスメッシュのIstio、機能拡張にWebAssemblyを採用。EnvoyにV8エンジンのWebAssemblyランタイムを統合
サービスメッシュを実現する「Istio 1.5」正式版が登場しました。注目すべき新機能の1つは、Istioの拡張やカスタマイズを行うための統合的な手段としてWebAssemblyが採用されたことです。 Istioが実現するサービスメッシュは、Kubernetes上のさまざまなサービス間のトラフィックの管理やルーティング、ロードバランシング、暗号化通信や認証サービス、モニタリングなどを実現します。 Istioの拡張手段をEnvoy上でのWebAssemblyによる実装で統一へ これまで、Istioの機能を拡張して外部ツールと連係させたり動作をカスタマイズするためには、Mixerプラグインを用いたポリシーやテレメトリのカスタマイズと、Istio内部で使われているプロキシであるEnvoyの拡張機能を利用したデータプレーンのカスタマイズという2つの手段が提供されてきました。 今回正式リリースされた
Istio as an Example of When Not to Do Microservices
I’ve been pretty invested in helping organizations with their cloud-native journeys for the last five years. Modernizing and improving a team (and eventually an organization’s) velocity to deliver software-based technology is heavily influenced by its people, process and eventual technology decisions. A microservices approach may be appropriate when the culmination of an application’s architecture
Dockerコンテナ時代の第二章～Kubernetesの成熟とエコシステム発展の時代
Dockerの登場により急速に普及をはじめたコンテナ型仮想化の技術は現在、DockerコンテナそのものからKubernetesを軸としたオーケストレーションツールへと主役が移ってきています。 その様子は2017年12月に公開した記事「Dockerコンテナ時代の第一章の終わり、そして第二章の展望など」で紹介しました。 この記事の公開から2年が経過し、現在のコンテナ型仮想化技術は、マイクロサービスやクラウドネイティブなどの文脈とともにエンタープライズな分野でも使われるメインストリームな技術へと確実に進み続けています。 本記事では前記事で描いたDockerコンテナ時代の第一章に続く第二章として、コンテナ型仮想化技術のここ2年半ほどの動向をPublickeyなりにまとめてみました。 Docker 1.0の到達とKubernetesの登場 まずはDockerとKubernetesの登場とその後の主要
1年間のシステム運用を通して分かったIstioの嬉しさと活用における注意点 / Benefits and Usage Notes of Istio
English ver CloudNative Day…
SPIFFEで何が解決できるのか - Qiita
はじめに 昨年にSPIFFEの記事を書いてからSPIFFE自体もアップデートされている部分もありますので、最新の情報にあわせて改めてSPIFFEで何が解決できるのか？について簡単に整理したいと思います。 SPIFFEは何を解決するのか SPIFFEはZero Trust Networkの考え方にもとづくサービス間認証の仕様です。 これらは新しいものではなく、2002年に発表されたPlan9 security design、2005年に発表されたGoogleのLOASの流れを汲んでいます。 近年のMicroservice化されたシステムのようなworkload間の通信において 送信元が信頼できるか 、 メッセージの正当性を信じられるか というような課題を、どのような環境(cloud/on-prem, container/VM)であっても、各workloadは 同一インタフェースで確認できる
サービスメッシュを実現する「Istio 1.2」リリース。安定性向上、IPv6の実験的サポート、Datadogへのトレース送信など
サービスメッシュを実現する「Istio 1.2」リリース。安定性向上、IPv6の実験的サポート、Datadogへのトレース送信など サービスメッシュは、クラスタ内の個々のサービスに対してプロキシによる通信の仲介を通じてさまざまな機能を提供します。 例えば、ブルー／グリーンデプロイメントと呼ばれる、あるサービスを新版に切り替える際のトラフィックの動的な切り替えや、サービス間の通信を暗号化し、サービス間での認証をきちんと行うことでセキュリティを高めることも実現してくれます。 さらにプロキシを通じてサービスのモニタリングやログ収集を行うことで、サービスとアプリケーションの稼働状況を把握できるようにもしてくれます。 ビルトやテストなど、リリースのための自動化体制を強化 Istioは2018年8月にバージョン1.0が登場。次のバージョン1.1が登場したのはその7カ月後の2019年3月、そして今回のバ
RancherがKubernetesに続きIstioもサポート、ダッシュボードにトラフィックやテレメトリ表示など設定済み
RancherがKubernetesに続きIstioもサポート、ダッシュボードにトラフィックやテレメトリ表示など設定済み 分散処理のためのフレームワーク「Rancher」を開発するRancher Labsは、現在開発中の「Rancher 2.3」プレビュー版で、サービスメッシュ機能を提供する「Istio」のサポートを発表しました。 Announcing Preview Support for Istio with Rancher 2.3! Learn how Istio works in Rancher 2.3 Preview 2 here, and follow the installation steps to get started. #istio #kubernetes #k8s https://t.co/4vzc7B0RV8 — Rancher Labs (@Rancher_La
Istio導入のメリットとハマりどころを、実例に学ぶ～マイクロサービス化の先にある課題を解決する｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Istio導入のメリットとハマりどころを、実例に学ぶ～マイクロサービス化の先にある課題を解決する マイクロサービス化にともなサービス間の接続の複雑化、という課題への対処としてサービスメッシュとこれをもたらす「Istio」が注目されています。Istioをいち早く導入したユーザベースの阿南さんが、導入メリットと、使って分かった「ハマりどころ」を解説してくれました。 マイクロサービスを増やしていくならサービスメッシュ化を検討すべき KubernetesやIstioは今までの技術の集大成 運用したからこそわかるIstioのハマりポイント ハマりどころ1：設定の反映が遅延する ハマりどころ2：エンドポイント登録がnamespase単位で分かれていない ハマりどころ3：istio-proxyの制限にひっかかる 使っている人に聞いてみた「Istio-proxyを経由すると10ms遅くなる？」 Istio
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
