Building Better People: How to give real-time feedback that sticks.
グノシー におけるEKS活用事例
Building Better People: How to give real-time feedback that sticks.
Istioは、サービスメッシュを実現する新たな仕組み「Ambient Mesh」を発表しました。 現在のIstioは、各サービス（≒KubenetesのPod）ごとにプロキシを配置し、サービス間のネットワークをプロキシ経由で構成することによってサービスメッシュを構築しています。これによりサービス間の通信のトラフィックコントロール、暗号化、可観測性（オブザーバビリティ）などの機能が実現されるわけです。 この仕組みは、サービスの隣にプロキシを配置することから、「サイドカー」パターンなどと呼ばれています。 新たな仕組み「Ambient Mesh」では、Pod群をホストしているノードにプロキシを配置し、このプロキシによってサービスメッシュの機能を実現します。 Podごとのプロキシ配置が不要になる、つまり「サイドカーレス」（Sidecar-less）なパターンとなることで、デプロイや管理の容易、コン
コンポーネントの分類について考えたことをまとめた
どのようにコンポーネントを分類していくか 個々のコンポーネントがが単一の責任のみ負っている状態であれば、コードの見通しも良くなる上、後々のメンテナンスも容易です。 まずは「複数の関心ごとを１つにまとめない」という原則（単一責任の原則）から分類の指針を考えていきます。 フロントエンドにおける関心ごとですが、大別すると APIとの接続 View（表示とイベント実行） 状態管理 以上３つに集約されるのではないでしょうか。 では、これらの関心ごとをどの様に切り分けていけば良いのか考えていきます。 APIとの接続 まずはAPIとの通信ですが、こちらはコンポーネントの外で管理した方が良いと考えています。 各コンポーネントに通信に関わる処理がベタ書きされている状態だと、エンドポイントの変更等に弱くなり、通信処理の再利用も面倒です。 それに、「フロントの状態管理 / 表示」と「外部との接続」はそれぞれ別種
Kubernetes External SecretsからExternal Secrets Operatorに移行した話 〜他ツールとの比較・移行戦略・工夫したポイント〜 - ZOZO TECH BLOG
はじめに こんにちは、SRE部ECプラットフォーム基盤SREブロックの織田です。普段は主にZOZOTOWNのリプレイスやインフラを改善、運用しています。 本記事では、Secret管理コンポーネントであるKubernetes External Secrets（以降、KESと表記）の非推奨を受けて、どのような対応を実施したのか紹介します。 目次 はじめに 目次 なぜSecret管理コンポーネントを利用するのか？ Kubernetes External Secrets（KES）について KESとは？ KESを使ったKubernetes構成 KESの非推奨について 移行先の選定 優先事項の決定 移行先の検討、比較 移行先の決定 External Secrets Operator（ESO）について ESOのアーキテクチャ 移行における注意点や変更点 移行の実施 移行方法 工夫したポイント 最後に な
恐ろしく長い上に割と複雑なので最後まで読む人はほとんどいないと思うのですが、将来確実に忘れてしまう自分のために書いたので別に悲しくありません。 まえがき 背景 sigstoreの概要 sigstoreを構成するツール群 Cosign Rekor Fulcio 署名方法 コンテナイメージ 鍵ペアの生成 署名 検証 Blobs 鍵ペアの生成 署名 検証 署名の仕組み コンテナイメージ OCI Registryについて 署名の保存先 署名フォーマット 署名検証 検証が不十分な例 Blobs 参考 まとめ まえがき 鍵の管理不要でソフトウェア署名を可能にするKeyless Signingについて解説を書こうと思い、まず前提知識を書いていたら信じられないぐらい長くなったので前提知識だけで1つの記事になりました。 後述するsigstoreは急速に開発が進んでいるプロジェクトであり、ここで書いている記述
マイクロソフト、Linuxディストリビューションベンダ「Kinvolk」を買収。コンテナに最適化したLinuxやベアメタル対応のKubernetesのディストリビューションを提供
マイクロソフトは、LinuxやKubernetesのディストリビューションベンダとしてドイツのベルリンに本拠地を置く「Kinvolk」の買収を発表しました（マイクロソフトの発表、Kinvolkの発表）。 Kinvolkは2015年設立の新興ベンダです。クラウドネイティブに対応したオープンソースソフトウェアにフォーカスしており、同社が提供するコンテナに最適化されたLinuxディストリビューションの「Flatcar Container Linux」は、KivolkがCoreOSとともにコンテナランタイムのrktの開発に関わっていたことから、2018年2月にCoreOSがレッドハットに買収された際にCoreOSに代わるコンテナ向けLinux OSとしてコミュニティの受け皿になったとされています。 参考：Red Hatがコンテナ専業ベンダのCoreOS買収を発表、コンテナプラットフォームやKube
Kubernetes 8 Factors - Kubernetes クラスタの移行から学んだクラスタのポータビリティの重要性と条件 | Wantedly Engineer Blog
Kubernetes 8 Factors - Kubernetes クラスタの移行から学んだクラスタのポータビリティの重要性と条件 こんにちは、Wantedly で技術基盤に関わる Developer Experience Squad で Engineer をしている大坪（@potsbo）です。 今日は、WANTEDLY TECH BOOK 7 から「Kubernetes クラスタの移行から学んだクラスタのポータビリティの重要性と条件」という章を抜粋し加筆修正を加えたものを Blog にします。 「WANTEDLY TECH BOOK 1-7を一挙大公開」でも書いた通り、Wantedly では WANTEDLY TECH BOOK のうち最新版を除いた電子版を無料で配布する事にしました。Wantedly Engineer Blogでも過去記事の内容を順次公開予定であり、この Blog もそ
定量データと定性評価を用いた技術戦略の組織的実践 / Systematic implementation of technology strategies using quantitative data and qualitative evaluation
CNDS2024 https://event.cloudnativedays.jp/cnds2024/
こんにちは。青山（amsy810）です。 Kubernetesには複数のクラスタを扱うための技術がいくつかあります。 今回は幾つかのパターンに分けて紹介していきたいと思います。 また、将来的にこうなったら面白いかもという話をするために、すぐにプロダクション利用できない話やWebサービスでは使わないような話も含まれています。 【目次】 複数クラスタを利用する理由 複数クラスタを管理するパターン GitOpsで複数クラスタを管理するパターン 複数のKubernetesクラスタをFederateするパターン Virtual kubeletパターン マルチクラスタ時のロードバランサの扱い LoadBalancer の機能を利用して分散する DNS を利用して分散する Multi Cluster にまたがる Service Mesh を利用して転送する マルチクラスタでPod Networkを繋ぐ
急成長中のスタートアップ企業は、多様なAWSサービスをどう選択・活用し、ビジネス課題を解決しているのでしょうか。本連載では、スタートアップ企業の中でエンジニアリングをリードしている担当者がそのアーキテクチャをひも解き、AWS活用術を紹介していきます。第3回はfreeeのSREエンジニア藤原峻輝氏が担当、テーマは「コンテナ（Kubernetes）」です。記事の最後には、SAによるポイント解説もあります。（編集部） はじめに はじめまして、freee株式会社でSRE（Site Reliability Engineering）をしている藤原峻輝と申します（各種id：@renjikari）。SREはその名が示す通りサイトの信頼性向上を目指すロールであり、freee全体のサービスの信頼性をあげるために、障害対応の運用から新しいインフラ基盤を開発することまで担当しています。 freeeについて fre
Admission Webhookで快適なSecret管理 / Berglas Secret Admission Webhook
Microsoft’s Azure Linux distro is now generally available
After using Azure Linux internally for two years and running it in public preview since October 2022, Microsoft this week finally made its distribution generally available. Azure Linux is an open-source container host OS for the Azure Kubernetes Service (AKS) that is optimized for Azure and aimed at making it easier for developers to use Microsoft's tools to deploy and manage container workloads.
※この投稿は米国時間 2019 年 11 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 高度なスケーラビリティと構成の柔軟性を提供するコンテナ オーケストレーション プラットフォームを求めているお客様にとって、マネージド Kubernetes サービスである Google Kubernetes Engine（GKE）は優れた選択肢になります。GKE は、ステートフル アプリケーションのサポートに加えて、ネットワーキング、ストレージ、オブザーバビリティ（可観測性）のセットアップなど、コンテナ オーケストレーションのあらゆる側面を完全に制御できます。 しかしながら、お使いのアプリケーションがそうしたレベルのクラスタ構成やモニタリングを必要としない場合は、フルマネージドの Cloud Run が最適なソリューションになるかもしれません。フルマネージド Clou
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Istioが新たな仕組み「Ambient Mesh」を発表。サイドカーなしでサービスメッシュを実現
sigstoreによるコンテナイメージやソフトウェアの署名 - knqyf263's blog
Kubernetesにおけるマルチクラスタ関連手法の分類 - @amsy810's Blog
急成長のfreeeに学ぶ、進化するアーキテクチャ――Kubernetes×AWSで複雑化したマイクロサービス基盤を改善
気をつけたいKubernetesとの付き合い方 / Happy Kubernetes Life
GKE と Cloud Run、どう使い分けるべきか | Google Cloud 公式ブログ