kube-proxy入門
Kubernetes Novice Tokyo #28 の登壇資料です イベントURL: https://k8s-novice-jp.connpass.com/event/293157/ 配信URL: https://www.youtube.com/watch?v=LSW51Cm0Wc0 コードリーディングメモ: https://zenn.dev/bells17/scraps/5e41da598a8266 参考資料: https://github.com/kubernetes/kubernetes/tree/v1.28.2 https://speakerdeck.com/ryusa/servicewotazunete3000xing-kuberneteskodorideingufalselu https://qiita.com/Tocyuki/items/6d90a1ec4dd8e991a
〜運用しやすいプレビュー環境を求めて〜 Gateway APIで作るサービスメッシュレスなプレビュー環境 - LIVESENSE ENGINEER BLOG
みなさん、プレビュー環境してますか？どうも、かたいなかです。 以前、記事や登壇でIstioベースのPreview環境の構築方法をご紹介しました。 made.livesense.co.jp 外向けに発表したものの、Istioの運用工数や学習コストがネックとなってしまい、実際の転職会議の開発環境の導入にはいたっていませんでした。 最近になってGateway APIの実装例も増えてきて、Istio以外にもプレビュー環境でのヘッダを元にしたルーティングの実現において、現実的な選択肢となりそうなツールが増えてきました。そこで、Gateway APIのEnvoyによる実装であるEnvoy Gatewayを用いて、サービスメッシュを使用しないプレビュー環境の構築を試してみたため、この記事では構成例をご紹介します。 なお、今回の記事の中ではプレビュー環境の説明等について前回の記事と同様の説明を再度する箇所
多様なプロダクトが存在する freee における health check 標準化 - freee Developers Hub
こんにちは。freee の Platform Solution チーム1 に所属している nkgw （Twitter） です。 この記事は freee 基盤チーム Advent Calendar 2023 の 15 日目の記事となります。 普段は、エンジニアリングマネージャーをしつつ、新規プロダクトのリリースサポートとか、プロダクトのキャパシティプランニングやコンピューティングリソース調整などをやってました。 今回、freee のプロダクトにおける health check の標準化について取り組みました。health check の要件と非標準化がもたらす具体的な問題を整理しつつ、freee では実際にはどのように health check を定義したのかを紹介します。 その前に... 詳細な内容の前に、弊社のような複数のプロダクトが相互に依存関係があるような環境下における health
OOMしたCronJobのメモリ制限を「いい感じ」に増やし、不必要な課金・障害対応を減らす - エムスリーテックブログ
初めまして、2024年3月後半にエムスリーのAI・機械学習チームで10日間インターンに参加させていただいた東（@azuma_alvin）です。 もしタイトルが何かに似ていると感じた方がいれば、只者ではないと思われます。 洗練されたデザインでかっこいいと思ったエムスリーオフィスの受付の写真 この記事では、KubernetesのCronJobでOOM（Out Of Memory）が発生した時に「いい感じ」にメモリ制限を増加させてくれるbroomの開発経緯とその実装についてお話しします。 また、インターン期間で感じたエムスリーという「ギーク集団」の中で開発する楽しさについてもお伝えできればと思います。 2週間でゼロ（nil）から開発したbroomは、OSSとしてGitHubで公開しているのでコントリビュートお待ちしております！ github.com CronJobのOOMとは CronJobのO
はじめに こんにちは、ECプラットフォーム基盤SREブロックの織田と、カート決済SREブロックの遠藤です。 本記事では、Istio Rate Limitの概要とZOZOTOWNでの導入事例を2つご紹介します。 目次 はじめに 目次 現在のZOZOTOWN Istio Rate Limitの概要 Istio Rate Limitとは？ 仕組み どのような制限ができるのか？ Circuit Breakerとの違い 導入事例 事例1. マイクロサービスから外部APIへのリクエスト制限 構成 設定と計測のポイント 1. レイテンシの計測 2. 1つのAPIに対して2重の制限を設定 事例2. オンプレミス環境のリクエスト制限 構成 設定と計測のポイント 1. 商品別の注文リクエスト数制限 2. 閾値決定のための負荷試験 今後の展望 感想 最後に 現在のZOZOTOWN ZOZOTOWNではオンプレミ
KEELチームの相原です。 今回はeBPFを利用してKubernetesクラスタの可観測性の隙間を埋めている話です。 前回のエントリではLLMにうつつを抜かしていたので本業(?)の話をしようと思います。 www.lifull.blog LIFULLの可観測性の現在地 eBPFとは 可観測性の隙間 NAT Loopback eBPFを実行するには BPF CO-RE libbpf-rsを利用したNAT Loopbackの検知 1. (ユーザ空間) コマンドライン引数として受け取ったDNSをTTLごとに名前解決してIPアドレスを取得する 2. (ユーザ空間) IPアドレスに変化がある度にカーネル空間で動くBPFプログラムにそのIPアドレスのリストを渡す 3. (カーネル空間) Kprobesで tcp_v4_connect/tcp_v6_connect にフックを仕込む 4. (カーネル空間)
はじめに これは、Kubernetesアドベントカレンダー2の20日目の記事です。 これの話です。 aws.amazon.com ただし俺はもうEKS全然使ってないから意味ない件😢 なんの話？ 待ってたとは 4年前に、AWSでコンテナ使ってる人ならお馴染みのaws/containers-roadmapにこんなIssue(もとい、Feature Request)を作りました。 github.com また、これに関連するIssueとしてはその半年ほど前に作られていて github.com 自分としてはこのIssueを立てる前から技術選定の時点でずっと悩んでいたポイントだったので、かれこれ5年近く待っていたことになります。ようやくリリースされて本当によかった。まあ今はいらないんだけど、、、 どんな内容か これまでのEKSの課題点 EKSでクラスター管理者や運用者を指定する上で欠かせないのが、K
1,800万人が利用する『家族アルバム みてね』におけるK8s基盤のアップグレード戦略と継続的改善 / FamilyAlbum's upgrade strategy and continuous improvement for K8s infrastructure
SRE NEXT 2023 https://sre-next.dev/2023/schedule/#jp093
はじめに テックリードの柿崎です。私たちは、機械学習のパラメータチューニングを効率よく行うため、KubernetesネイティブのワークフローエンジンであるArgo Workflowsを採用しています。この記事では、その導入手順の要点を紹介いたします。 導入の目的 Argo Workflows導入以前は機械学習のパラメータチューニングを行うにあたり以下の機能を独自に実装しており、属人化していました。 パラメータ探索のアルゴリズム インスタンスのスケーリング インスタンスの稼働状況の可視化 ジョブの進行状況の可視化 これらをより柔軟に活用できるようにして、開発、更新サイクルを早めていくことが導入の目的です。 前提条件 Kubernetes(EKS)はすでに構築済みであること Kubernetes、Helmについての基本的な知識があること Argo Workflowsの基本的な知識があること K
「Docker」と「Kubernetes」をベースとする環境で構築されたクラウドネイティブアーキテクチャが流行している。クラウドネイティブと相性の良いマイクロサービスには、次のような利点がある。 サービスごとに、アーキテクチャ、言語、プロセス、ツールを自由に選択できる ドメイン駆動型設計やイベント駆動型アーキテクチャなど、ソフトウェアコンポーネントで長年提唱されてきた多くのベストプラクティスが体系化されている 適切にカプセル化されているため、サービスを個別に更新できる 柔軟性が高く、短期間でのリリースが可能 マイクロサービスに対応した技術（DockerやKubernetesなど）は多くのハードウェアで動作する マイクロサービスはこうしたさまざまなメリットをもたらす。一方で、幾つかの重要な問題点があるため、アプリケーション開発チームは注意する必要がある。特に、信頼性の高いモノリスアプリケーシ
先日、Kubernetes Meetup Tokyo #59 で「KEP から眺める Kubernetes」というタイトルで発表しました。発表の後で Kubernetes の upstream のキャッチアップ方法について質問を受けました。その場で回答はしたのですが、ちょうど社内の共有会で似たような話をしたところだったので、加筆修正したものを公開しておきます。 はじめに Kubernetes の upstream を追いかけ始めて 1 年ちょっと経ったので、その経験をまとめます。Kubernetes の upstream やエコシステムを観察しているだけで、コントリビュータではありません。間違っている部分があったらごめんなさい...！ Kubernetes の開発体制や開発者の所属組織の分布、新しい機能を追加する際のプロセスの話を簡単にしてから私のキャッチアップ方法についてまとめています。
Announcing additional Linux controls for Amazon ECS tasks on AWS Fargate | Amazon Web Services
Containers Announcing additional Linux controls for Amazon ECS tasks on AWS Fargate Introduction An Amazon Elastic Container Service (Amazon ECS) task is a number of co-located containers that are scheduled on to AWS Fargate or an Amazon EC2 container instance. Containers use Linux namespaces to provide workload isolation—and with namespaces—even though containers are scheduled together in an Amaz
SREエンジニアが目指すGKE共通デプロイ基盤の完成形 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。開発部門 開発部 Data AI Strategyセクション データ基盤 Unitの小野です。 2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進していく中で、Google Kubernetes Engine (GKE)を使ったGKE共通デプロイ基盤の整備も進めてきました。 ※ DAOについての詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください SREエンジニアの責務の一つは、プロダクトのリリースサイクルを極限まで短くし、次々と新しいサービスを世の中にリリースすることです。ChatGPTのような誰でも簡単に扱えるAIモデルが誕生したことで、プロダクト開発競争は今後ますます激しくなっていくと予想しており、SREエンジニアの責務の重要性をヒシヒシと感じています。 そう
SREチームの橋本です。SRE連載の3月号となります。 Amazon ECSのコスト最適化においてはFargate Spotが有効な手段となりますが、いつ中断されるか分からない性質上、その監視も併せて実施していく必要があります。今回はそのFargate Spotを本番環境で運用しているプロジェクトにおける取り組みを紹介します。 背景 Fargate (Amazon ECS on AWS Fargate) を用いると負荷に合わせた容易なスケーリングが可能になる一方、このときCPU使用率の安全マージンや予測のブレなどにより、リソースがやや過剰になってしまうこともあります。 Fargate Spotの代表的なユースケースと言えばユーザーに露出しない開発環境ではないかと思いますが、このような場合にコストを考えると、タスクの中断をある程度許容しての本番環境でのFargate Spot運用も可能な選択
KubeCon + CloudNativeCon Europe 2024 参加レポート - ZOZO TECH BLOG
はじめに こんにちは。SRE部フロントSREブロックの三品です。 3月19日から3月22日にかけてKubeCon + CloudNativeCon Europe 2024（以下、KubeCon EUと呼びます）が行われました。今回弊社からはZOZOTOWNのマイクロサービスや基盤に関わるエンジニア、推薦システムに関わるエンジニアの合わせて4人で参加しました。 本記事では現地の様子や弊社エンジニアが気になったセッションや現地の様子について紹介していきます。 目次 KubeConEU2024の概要 セッションの紹介 現地の様子 ブースについて 参加に向けてのTips 最後に KubeCon EU 2024の概要 昨年4月にオランダ アムステルダムで行われたKubeCon EUの様子については昨年の参加レポートをご覧ください。 techblog.zozo.com 今年のKubeCon EUはフラ
Amazon Elastic Container Service (Amazon ECS) and AWS Fargate now integrate with Amazon Elastic Block Store (EBS), allowing you to easily provision and attach EBS volumes to Amazon ECS tasks running on both AWS Fargate and Amazon Elastic Compute Cloud (EC2) using Amazon ECS APIs. This capability makes it easier for you to deploy storage and data intensive applications such as ETL jobs, media trans
Certified Kubernetes Administrator (CKA) 取得記【エンジニアに役立つ資格】 | IIJ Engineers Blog
Certified Kubernetes Administrator (CKA) 取得記【エンジニアに役立つ資格】 2023年06月05日 月曜日 IIJ MVNO事業部の川崎と申します。 エンジニアブログへの寄稿は2回目でして、前回はNeural Networkをつかったいいね検出装置の紹介をしました。あれから数年、今やChatGPTをはじめとした（いわゆる）AI技術が栄華を極めており、時の流れとは早いものだなあと思う今日このごろです。 さて今回は「エンジニアに役立つ資格」という企画で再度寄稿の機会ができましたので、半年ほど前に合格したCertified Kubernetes Administrator (CKA) について投稿します。 ※ 本記事に記載している情報は、いずれも本ブログ執筆時点の情報である点をご留意ください CKAとは CKAとはLinux FoundationとClou
Pod が使用できる Secret を制限する方法 Kubrenetes では、ServiceAccount リソースに kubernetes.io/enforce-mountable-secrets アノテーションを true で設定することで、その ServiceAccount で実行する Pod が secrets フィールドで指定された同一 Namespace の Secret しか使用できない (マウントできない) ように制限する機能 1 が提供されています。 apiVersion: v1 kind: ServiceAccount metadata: name: test-sa annotations: kubernetes.io/enforce-mountable-secrets: "true" secrets: - name: mountable-secret-1 - nam
Kubernetes上でイベントドリブンなオートスケーリングを提供する「KEDA」、本番環境で使えるレベルに到達したとしてCNCFの卒業プロジェクトに
Kubernetes上でイベントドリブンなオートスケーリングを提供する「KEDA」、本番環境で使えるレベルに到達したとしてCNCFの卒業プロジェクトに Cloud Native Computing Foundation（CNCF）は、Kubernetes上でイベントドリブンなオートスケーリングを提供する「KEDA」（Kubernetes Event-driven Autoscaling）が、本番環境に十分使えるレベルに到達したとして、インキュベーションプログラムから卒業するプロジェクトになったと発表しました（CNCFの発表、KEDAの発表）。 [NEWS] Announcing the Graduation of #Kubernetes autoscaler #KEDA! https://t.co/qpSz3zyad5 pic.twitter.com/ETddPp8ENF — CNCF (
Kubernetes アプリケーションの公開 Part 1: Service と Ingress リソース | Amazon Web Services
Amazon Web Services ブログ Kubernetes アプリケーションの公開 Part 1: Service と Ingress リソース この記事は Exposing Kubernetes Applications, Part 1: Service and Ingress Resources (記事公開日: 2022 年 11 月 22 日) を翻訳したものです。 はじめに 連載「Kubernetes アプリケーションの公開」では、Kubernetes クラスターで実行されているアプリケーションを、外部からのアクセスのために公開する方法に焦点を当てます。 連載の Part 1 では、Kubernetes クラスターでインバウンドトラフィックの制御を定義する 2 つの方法である Service と Ingress リソースタイプについて探ります。Service コントローラ
そこまで大規模じゃない EKS環境を（あまり）頑張らずに 最新化し続けたい / FamilyAlbum EKS Continuous Improvement
Kubernetes活用の手引き 私たちの基盤構築・運用事例 Lunch LT https://findy.connpass.com/event/307447/
Kubernetes Pod の IP アドレスが枯渇しかけている場合に役立つ実証済みの解決策を紹介 | Google Cloud 公式ブログ
Gemini 1.5 モデル をお試しください。Vertex AI からアクセスできる、Google のもっとも先進的なマルチモーダル モデルです。 試す ※この投稿は米国時間 2024 年 4 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。 Kubernetes の大きな強みの 1 つは、Pod ごとに固有のネットワーク アドレスがあることです。これにより、Pod が VM のように機能するため、デベロッパーはポートの競合などの煩わしい問題を気にする必要がありません。Kubernetes のその特性のおかげで、デベロッパーやオペレーターは作業を簡略化できます。また、設計機能の 1 つとして高い信頼性を獲得しているため、コンテナ オーケストレーターとしての人気が非常に高くなっています。Google Kubernetes Engine（GKE）は、VPC 内
Overall of Container Security for Application Engineer
ちがいからみるプラットフォームエンジニアリング / Platform Engineering from a difference's point of view
Source:imgflip.comAs I write this on the 25th of April, I am still reeling from the announcement of IBM’s acquisition of Hashicorp. When I first heard the rumours yesterday, I was concerned about the future of possibly my favourite Infrastructure-as-code (IaC) tool. It has long been obvious that Hashicorp has been struggling to make money, making a $274 million loss in 2023. This undoubtedly led t
深層学習のための分散キャッシュシステム - Preferred Networks Research & Development
エンジニアの上野です。Cluster Servicesチームという、PFNのKubernetesベースの機械学習基盤を開発・運用するチームに所属して、基盤の改善や新機能の開発に務めています。本記事では、深層学習における学習データセット読み込み速度の改善を目指して開発し、現在もKubernetes上で運用中の分散キャッシュシステムを紹介します。 PFNの機械学習基盤については、ブログ「2022年のPFNの機械学習基盤」もご参照ください。 深層学習における学習データセット読み込み 深層学習を高速化するため、深層学習に向いたアクセラレータの開発が日々続けられています。PFNで開発しているMN-Coreシリーズや、NVIDIA社製GPUもそのひとつです。これらのアクセラレータは高速に行列演算を行うことができ、深層学習の1イテレーションにかかる時間を高速化、ひいては深層学習を活用する研究開発全体を加
どんなに著名なOSSであっても、利用法によってはパフォーマンスチューニングが必要になる場面が存在します。 今回は過去に体験した事例から、モニタリングの大切さについてご紹介します。 Talked by TechFeed Experts Night#20 〜 Webパフォーマンス・チューニング最前線 : 前編（概要、モニタリング、負荷テスト編）
LINEヤフーはDB自動チューニング術を紹介――「KubeCon」で気になった最新のKubernetes×データベース運用ノウハウ
LINEヤフーはDB自動チューニング術を紹介――「KubeCon」で気になった最新のKubernetes×データベース運用ノウハウ：「KubeCon＋CloudNativeCon North America 2023」レポート 「クラウドネイティブ」という言葉がなじんだ今、市場に登場した新たなデータベースやデータベースを支えるプラットフォームにまつわる情報を紹介していきます。今回は「KubeCon＋CloudNativeCon North America 2023」で気になった内容をお届けします。 「クラウドネイティブ」という言葉がなじんだ今、市場に登場した新たなデータベースやデータベースを支えるプラットフォームにまつわる情報を紹介する本連載。前回はNewSQLの一つである「YugabyteDB」のユーザーによるラウンドテーブルの様子をお届けしました。国内市場でもクラウドネイティブな新しい
Kubernetes as a platform vs. Kubernetes as an API | Amazon Web Services
Amazon Web Services ブログ Kubernetes as a platform vs. Kubernetes as an API はじめに Kubernetes とは何ですか？私はこの技術に初期から取り組んできましたが、8 年経っても、この問いにハッキリと答えられません。Kubernetes をコンテナオーケストレーターとして定義する人もいますが、その定義は果たして、Kubernetes を正しく表現できていると言えるでしょうか。私はそう思いません。この記事では、Kubernetes について、従来の考え方にとらわれない考え方や、技術の伸びしろを探ってみたいと思います。 Amazon Elastic Kubernetes Service (Amazon EKS) は、お客さまに代わって、Kubernetes クラスターを運用をする AWS のマネージドサービスであり、非常
イエーーーーーーイ！！！！！！本が！！！！！出るよ！！！！！！祝！同人活動１０周年！！！！ 念願の商業出版ダァ〜〜〜〜ッあッ〜〜〜〜〜！ぴーすぴーす！みんな元気？今日あったかいね！ さて商業出版めっちゃめでたいし、私的には超すごいこと何だけど、自分一人でここにこれたわけじゃないよな〜〜〜 ということで改めて私の同人作家としての歴史を振り返り各方面に感謝を述べていきたい。 名付けて「商業出版ありがとう大感謝祭！！！！！」イエア！！ まずは書籍のリンク貼っておきますペタ www.amazon.co.jp 商業出版を目指している方に向けては何も参考にならないかもしれない。ごめんなさい。 あと技術書ということで漫画や小説とはまた少し毛色が違う気もしますね。ご了承ください。 本を書き始めてからのスケジュール感とかペースとか辛かったことあれこれなど他の人の参考になりそうなことはまた別に書きます。 とい
あえて手動アップグレードを選ぶ〜マネージドサービス(GKE)で手作業による対応をした話〜 - MonotaRO Tech Blog
こんにちは。データ基盤グループ データエンジニアリングチームの宮口です。 この記事ではGoogle Cloud Platform（以下、GCP）のサービスの1つであるGoogle Kubernetes Engine（以下、GKE）のクラスタを手動アップグレードした話を紹介します。 私が所属するデータエンジニアリングチームでは、社内システムに保存されたデータをGCPのBigQueryにニアリアルタイムで同期するシステムや、BigQueryに保存されている大容量のデータを低レイテンシなAPIとして提供するシステムなど、モノタロウのビジネスを裏側で支えるシステムの管理を行っています。それらのシステムは全てのコンポーネントをコンテナ化しており、その実行環境としてGKEを採用しています。 また、それとは別に社内でGKE共通環境と呼んでいる、マルチテナント方式のクラスタによるアプリケーション実行基盤を
Kubernetes活用の手引き 私たちの基盤構築・運用事例 Lunch LT https://findy.connpass.com/event/307447/
DeNA 的 GKE 運用 ~ Pod 集約率編 ~ [DeNA インフラ SRE] | BLOG - DeNA Engineering
はじめに こんにちは。インフラエンジニアの松浦です。 IT 基盤部に所属し、全世界向けのゲームタイトルのインフラ運用を担当しています。 先日あるプロジェクトで Google Kubernetes Engine (以降 GKE) でインフラを構築することになり、そこで GKE のコスト削減のために、 ノード 数削減すなわち Pod 集約率の向上 (1台のノードで出来るだけ多くの Pod を動かす) に取り組みました。 今回はそこで行ったことをご紹介します。 概要 今回のプロジェクトでは、 Kubernetes (以降 K8s) の Horizontal Pod Autoscaler 使用してアプリケーション Pod をオートスケールさせます。 このため、スケールアウト・スケールイン後 (Pod の増減により クラスタオートスケーラー (以降 CA) がノードを増減させた後) でも、Pod 集
![DeNA 的 GKE 運用 ~ Pod 集約率編 ~ [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/1252489982a7fafcf1805c0cb00d4c02b4ee5b92/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2023%2F06%2Fgke-optimization%2Fcover.png)
サービスを運用している中で緩やかにメモリ使用率が上がっていく問題があり、それが解決されるまで一時的になんとかするために掲題のを作りました。 github.com 中身自体はZapierが作っていたpreoomkiller-controllerが元になっております。 github.com このコントローラーを導入すれば済む話じゃない？ってなりそうですが、こちらは「メモリ使用量」を閾値としており、更に更新も止まっていたのでせっかくなら勉強がてら作り直すかーとなった結果こうなりました。 この手のk8sに関するツールを今まで全く作ったことがなかったので、勉強に以下の本を読ませていただきました。 実践入門 Kubernetesカスタムコントローラーへの道 技術の泉シリーズ (技術の泉シリーズ（NextPublishing）) 作者:磯 賢大インプレス NextPublishingAmazon pre
マルチテナントのAWSアカウントとKubernetesにおけるコストの可視化 - ZOZO TECH BLOG
こんにちは、カート決済SREブロックの飯島と、ECプラットフォーム基盤SREブロックの織田です。 本記事では複数チームで運用する共通のAWSアカウントとKubernetesにおけるコストの可視化についてご紹介します。 背景 コスト可視化に対する課題 課題解決へのアプローチ AWSリソースのコスト可視化 AWSコスト配分タグ タグの定義と運用ルール タグの付け方 AWS Cost Explorer AWSコスト配分タグの活用例 Kubernetesクラスタのコスト可視化 Kubecost 比較検討 カスタムバンドル採用の決め手 アーキテクチャ 可視化の仕組み ダッシュボード 効果 コスト可視化の活用事例 最後に 背景 現在、ZOZOTOWNはモノリスなサービスを機能ごとに分け、マイクロサービスに移行しながらモダンアーキテクチャへのリプレイスを実施しています。マイクロサービスの移行先としてクラ
楽天グループ株式会社が運営するフリマアプリ「ラクマ」のインフラ基盤をAWS EC2 + AutoScalingGroupからKubernetes(EKS)に移行しました。このプロジェクトは約3年におよび、様々な調査や検証を行いました。 初めてKubernetesへの移行を考える企業にとって、大規模トラフィックを処理するための適切な構成を模索することは一筋縄ではいきませんでした。この発表では、どのような観点を持って調査を行い、どう構築していったか具体的な事例とともにお伝えします。
![[EC2からKubernetes]�楽天ラクマのコンテナ化の歩み](https://cdn-ak-scissors.b.st-hatena.com/image/square/fda7627eab224b9a0df97d9ab2fe2b0187bf8da5/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F961b083651954d1dad15bba4a49b4fb0%2Fslide_0.jpg%3F26769230)
Google Cloudで実践！ クラウドネイティブな開発 サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める 本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第6回では、サービスメッシュについて紹介します。 主に対象となる読者は、クラウドを利用してアプリケーションを開発するエンジニア、またはその基盤を構築するエンジニア、サービス開発に携わるプロダクトマネージャーを想定しています。 マイクロサービスアーキテクチャの課題 これまでの連載ではクラウドネイティブなアプリケーションの開発について紹介しました。小さい独立して動作するサービスが連携するマイクロサービスアーキテクチャは、スケーラビリティ、独立した開発の容易さ、
Discover 3 advantages of Podman over Docker | Red Hat Developer
Many think of Podman to be a replacement for Docker (if they have heard of Podman at all). But, this is not the case, as Podman is another option that provides better security and developer features. Podman is a cloud-native, daemonless tool that helps developers manage their Linux containers. Podman is all about security, but also minimizing the friction between your local development environment
「TiDB」が注目される理由――「TiDB User Day 2023」でプレイドやMicoworksが語った検証結果と課題
「TiDB」が注目される理由――「TiDB User Day 2023」でプレイドやMicoworksが語った検証結果と課題：「HTAP」の現状と未来 「クラウドネイティブ」という言葉がなじんだ今、市場に登場した新たなデータベースやデータベースを支えるプラットフォームにまつわる情報を紹介していきます。今回は「TiDB User Day 2023」で気になったセッションを中心に紹介します。 多くのエンジニアから「既存のデータベースサービスでは性能目標やメンテナンス時間などの要件を満たすことが難しい」という声を聞きます。アプリケーション開発のスピードが上がり、そのアジリティにデータベース技術も追随する必要がある点は筆者の過去連載でも述べましたが、開発現場でどのような課題意識をもって、新たなデータベースの検証をしているのでしょうか。 本稿では、そうしたリアルな検証事例や採用事例を聞くことができる
第1回目の今回は、Podのリソース割り当ての推奨値を提案する「KRR(Kubernetes Resource Recommender)」について紹介します。 はじめに こんにちは。3-shakeで技術顧問を勤めている青山真也(@amsy810)です。 3-shakeでは、CloudNative技術などを用いたSREの推進などを行っており、Kubernetesに関連した各種ソフトウェアへのキャッチアップなども積極的に行っています。 そこで、本連載では「OSS Insight」で公開されているソフトウェアや、最近話題になっているが、まだ詳細についてまとめられていないようなKubernetesに関連するツール・ソフトウェアを検証し、3-shakeのメンバーで紹介していきます。 第1回の今回は、Podのリソース割り当ての推奨値を提案する「KRR(Kubernetes Resource Recomm
100万コンテナのKubernetesプラットフォームを5年間スケーラブルに運用するために乗り越えていること
CloudNative Days Tokyo 2023 での登壇資料です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Istio Rate Limitを活用した流量制限の取り組み - ZOZO TECH BLOG
Kubernetesクラスタの可観測性の隙間を埋めるeBPF - LIFULL Creators Blog
4年以上待ってたEKSの改善がようやく出てきた件 - inductor's blog
Argo Workflowsを使った機械学習環境の構築手順 - アダコテック技術ブログ
開発者が注意すべき「マイクロサービスの問題点」、そのトップ10を解説
Kubernetes の upstream のキャッチアップ
Fargate Spotを本番運用するための監視の実践 - KAYAC engineers' blog
Amazon ECS and AWS Fargate now integrate with Amazon EBS
Kubernetes で Pod が使用できる Secret を制限する方法 - Qiita
The beginning of the end for Terraform?
過去事例から見るモニタリングの大切さ #techfeed_live
同人活動から商業出版までの道のり〜サンキューマイフレンズ〜 - 腹は減る
人間によるKubernetesリソース最適化の”諦め” そこに見るリクガメの可能性
メモリ使用率によってk8sのPodをevictさせる君を作った - 生涯未熟
[EC2からKubernetes]�楽天ラクマのコンテナ化の歩み
サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める | gihyo.jp
Podのリソース割り当ての推奨値を提案するKRR(Kubernetes Resource Recommender)