VMwareが「Tanzu Application Engine」発表、Kubernetes上に抽象化されたアプリケーション基盤を提供。VMware Explore 2023
VMwareは米ラスベガスで開催中のイベント「VMware Explore 2023」で、Kubernetes上でアプリケーションの開発や実行を行う環境を提供する「Tanzu Application Engine」を発表しました。 Tanzu Application Engineは、VMwareが提供するマルチクラウド対応のKubernetes環境を提供する「Tanzu Application Platform」の新機能です。 Tanzu Application EngineはKubernetes環境上に、可用性、セキュアなコネクティビティ、スケーラビリティ、アプリケーションフレームワークなどの要件に対応したアプリケーション開発と実行のための抽象化された環境「Tanzu Application Spaces」をプロビジョニングする機能を提供します。 これによりアプリケーション開発者は環境構
楽天グループ株式会社が運営するフリマアプリ「ラクマ」のインフラ基盤を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)
EKSコンテナ移行のトラブル事例：ALBの設定とPodのライフサイクル管理 - MonotaRO Tech Blog
こんにちは、SREグループの岡田です。 モノタロウではモノタロウのクラウドネイティブ化の取り組みについて - MonotaRO Tech Blog にも記載されているようにシステムのモダナイズに取り組んでおり、その一環でEKSのPoCそして実際にECサイトの裏側のAPIを対象にコンテナ化に取り組みました。 この記事では移行時に起こったトラブルとハマったポイントの1事例をご紹介します。 前提 起こったトラブル トラブルシュート 1. 問題の整理と仮説 2. 検証 検証1.Podのステータスがterminate状態になってから削除されるまでの時間を変えてみる。 検証2.Pod Readiness Gateを試す。 検証3. ALBのDeregistration delay（登録解除までの待機時間）を短くしてみる。 分かった事 ALBを含めたPod入れ替え時の挙動 EKSにおけるトラブルシュート
The days of counting bits and clock ticks are history. CPU and memory may be cheap, but not enough to waste them — especially since it would be at our users’ expense. In this blog post, I’ll explain how we run our services in Kubernetes and manage their resources, how to make the most of them and what to look out for. Cover image by Jeremy Waterhouse at pexels.comKubernetes resourcesWhen we deploy
【ArgoCD🐙️】KubernetesのマルチテナントパターンとArgoCDの実践テナント設計 - 好きな技術を布教したい 😗
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Kubernetesのマルチテナントパターンの種類 マルチテナントパターンをArgoCDで実践する場合にオススメのパターン (★) ArgoCDのNamespacedスコープモードとClusterスコープモード ArgoCDのテナントが防いでくれる誤った操作の具体例 記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます！ この記事から得られる知識 01. はじめに 02. なぜマルチテナントが必要なのか シングルテナントの場合 マルチテナントの場合 03. Kubernetesのマルチテナントパターン マルチテナントパターンの一覧 Clusters as-a-Service Control Planes as-a-Service Namespaces as-a-Service カスタムリソ
Kubernetes v1.28: Planternetes
Authors: Kubernetes v1.28 Release Team Announcing the release of Kubernetes v1.28 Planternetes, the second release of 2023! This release consists of 45 enhancements. Of those enhancements, 19 are entering Alpha, 14 have graduated to Beta, and 12 have graduated to Stable. Release Theme And Logo Kubernetes v1.28: Planternetes The theme for Kubernetes v1.28 is Planternetes. Each Kubernetes release is
Kubernetes Novice Tokyo #27 (2023/09/12 19:00〜)
Kubernetes Novice Tokyoとは? Kubernetesに関連するテーマのLTを通して、Kubernetes初学者の方に対してアウトプットの機会を提供します。 ゲストスピーカーとしてKubernetesのエキスパートをお呼びして、テーマに関連したセッションをお願いしています。 想定する参加者 「Kubernetes初心者」の中で、下記のような思いを持つ人を主なターゲットとしています。 Kubenetesに関連するLTを行ってみたい Kubenetesに関して、アウトプットの練習をしてみたい Kubernetesについてわからないことが多いが、勉強会やMeetupに参加する中で理解を深めていきたい トークテーマ 今回のテーマは「フリーテーマ」です。 ご自身で学習した・調べた内容に関して、LT (5~10分) をお願い致します。 また、LT内容のサンプルとして発表内容案を以下
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
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 コントローラ
Gain total lifecycle visibility, reduce risks and stop attacks with the most comprehensive, fully integrated Cloud Native Application Protection Platform (CNAPP)
Kubernetesに最適化されたコンテナランタイム「cri-o」、十分成熟したプロジェクトとしてCNCFの卒業プロジェクトに
Kubernetesに最適化されたコンテナランタイム「cri-o」、十分成熟したプロジェクトとしてCNCFの卒業プロジェクトに Kubernetesなどの開発をホストしているCloud Native Computing Foundation（CNCF）は、Kubernetesに最適化されたコンテナランタイム「cri-o」が、十分に成熟したプロジェクトとして卒業プロジェクトになったことを発表しました。 Kubernetesが管理するコンテナはもともとDocker Engineをコンテナランタイムとして採用していましたが、2016年にrunCをコアにしたKubernetesに最適化したコンテナランタイムの開発が始まります。 また、CNCFがKubernetesとコンテナランタイムのあいだのインターフェイスを「CRI」として標準化し、このCRIとコンテナランタイムの標準であるOCIの両方に準拠し
KubeCon Europe 2023の共催イベントEdge Dayから、IntelとSpectro Cloudが実装した新しいプラットフォームを紹介する。 Kubernetesがサーバーサイドのコンテナオーケストレーションだとすれば、若干取り残されている感があるのが、エッジのプラットフォームだろう。エッジで使われるOS、プラットフォームは物理的に小さなフォームファクターで、メモリーやプロセッサなどのリソースに制限がある中でさまざまな使われ方が存在する。オープンソースソフトウェアだけでもLinux Foundation配下のYocto、LF Edgeが推進するAkraino、EdgeX Foundry、車載向けのAGL（Automotive Grade Linux）、医療やエネルギーなどセキュリティが重視される領域を想定したELISAから、コマーシャルベースだとRed Hatが発表したRe
さくらインターネットの知名度向上のため、これまでのサービス形態と異なった形でユーザに提供してみようとなったわけです。そこでこれまでの会員IDでの利用形態に加え、会員登録なしで（事前準備なしで）利用可能なサービスとしてクラウドシェルをリリースしようと考えました。 また次のようなさくらインターネット側のニーズもありました。 さくらインターネットは社内でコンテナ技術を用いたサービスを何度か検討していましたが、なかなか正式運用まで至りませんでした。コンテナ技術やこれを利用するK8sといったオーケストレーションシステムの運用知見及び実績を積み、より良いサービス提供を目指したいと考えました。 さくらのクラウドシェル そして、これらのゴールをクラウドシェルで実現しようということになりました。 さくらのクラウドシェル（以降クラウドシェル）は、その名のとおりブラウザで利用可能なシェル環境です。手元の環境に不
GitHub - mercari/tortoise: Tortoise: Shell-Shockingly-Good Kubernetes Autoscaling
At Mercari, the responsibilities of the Platform team and the service development teams are clearly distinguished. Not all service owners possess expert knowledge of Kubernetes. Also, Mercari has embraced a microservices architecture, currently managing over 1000 Deployments, each with its dedicated development team. To effectively drive FinOps across such a sprawling landscape, it's clear that th
「基礎から学ぶコンテナセキュリティ」という書籍を書きました
# どういう書籍か コンテナの要素技術である Linux Namespaces などの Linux の機能について体験し、それらが機能していないコンテナではどういった脅威が生じ、どのような攻撃手法があるのかについて紹介した本です。 副題は「Dockerを通して理解するコンテナの攻撃例と対策」ですが、演習題材として Docker を使うという意味であり、Kubernetes などの環境では通用しないという意味ではありません。本書を通して得た知識は、Docker だけでなく、Kubernetes や Nomad などのコンテナ環境のセキュリティに適用できるように書いています。 # 他の書籍との違い コンテナとそのセキュリティに関する書籍はいくつかあります。有名どころだと次のようなものがあり、これらの中でセキュアなコンテナ運用について書かれています。 Docker/Kubernetes開発・運用
先日、Kubernetes Meetup Tokyo #59 で「KEP から眺める Kubernetes」というタイトルで発表しました。発表の後で Kubernetes の upstream のキャッチアップ方法について質問を受けました。その場で回答はしたのですが、ちょうど社内の共有会で似たような話をしたところだったので、加筆修正したものを公開しておきます。 はじめに Kubernetes の upstream を追いかけ始めて 1 年ちょっと経ったので、その経験をまとめます。Kubernetes の upstream やエコシステムを観察しているだけで、コントリビュータではありません。間違っている部分があったらごめんなさい...！ Kubernetes の開発体制や開発者の所属組織の分布、新しい機能を追加する際のプロセスの話を簡単にしてから私のキャッチアップ方法についてまとめています。
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
深層学習のための分散キャッシュシステム - Preferred Networks Research & Development
エンジニアの上野です。Cluster Servicesチームという、PFNのKubernetesベースの機械学習基盤を開発・運用するチームに所属して、基盤の改善や新機能の開発に務めています。本記事では、深層学習における学習データセット読み込み速度の改善を目指して開発し、現在もKubernetes上で運用中の分散キャッシュシステムを紹介します。 PFNの機械学習基盤については、ブログ「2022年のPFNの機械学習基盤」もご参照ください。 深層学習における学習データセット読み込み 深層学習を高速化するため、深層学習に向いたアクセラレータの開発が日々続けられています。PFNで開発しているMN-Coreシリーズや、NVIDIA社製GPUもそのひとつです。これらのアクセラレータは高速に行列演算を行うことができ、深層学習の1イテレーションにかかる時間を高速化、ひいては深層学習を活用する研究開発全体を加
Kubernetesエキスパートが注目する「Platform Engineering」とは何か？ 一体何が新しいのか？ 近年、多くの企業が取り組もうとしている「クラウドネイティブ」なインフラ構築やアプリ開発の領域では、コンテナやKubernetes、アジャイルやDevOpsなど、新しいテクノロジーやコンセプトが次々と登場し、進化を続けています。組織がそうした進化に追従しながら、継続的に「クラウドネイティブ」のメリットを得られるようにするための考え方として、今「Platform Engineering」が注目されています。今回は、ヤフーとサイバーエージェントでKubernetesのエキスパートとして、社内のプライベートクラウド整備に尽力する2人に、Platform Engineeringの考え方や、それに基づいて、実際に自社のプラットフォームをどう進化させているか、今後どうしていきたいかとい
こちらのPublickeyの記事だけ見て中身がよくわかってなさそうな人がちらほらいたので、KubeVirtを使うことの意味についてちょっと書いてみようと思う。 www.publickey1.jp ただのちっちゃなVM基盤が欲しい場合は、ほぼ不要なもの 勉強目的などを除き、仮想マシンの数が10に到底届かないような仕組みでKubeVirtを動かす場合、かなり勿体無いので採用する意味はあまりないと思う。Kubernetesを動かすことによるオーバーヘッドがかなり大きいし、正直物理的な冗長性が十分無視できるくらいの規模と言わざるを得ないので仮想化基盤としてKubeVirtを採用するメリットは薄い。EC2とかESXiとかProxmoxとか既存の仕組みを使えばいいんじゃない？と思う。 採用に値するであろうメリット1: IaaSを作りたい場合 KubeVirtの本質は、「KubernetesのAPIを使
Cloud Native Computing Foundationは、仮想マシンをKubernetesで管理可能にする「KubeVirt」がバージョン1.0に到達したことを発表しました。 Kubernetesは起動中の多数のコンテナを管理し、ワークロードを割り当てるなど、コンテナベースのオーケストレーションツールとして開発されました。 KubeVirtはそのKubernetesにおいて、コンテナと同じように仮想マシンを管理可能にするソフトウェアです。 QEMUとlibvirtで仮想化レイヤをコンテナ化 具体的には、QEMUとlibvirtが用いられた仮想化レイヤをKubernetesで扱わせることが可能になります。 これにより例えばデータベースのようなコンテナよりも仮想マシン上で実行することが望ましいと考えられるアプリケーションを、仮想マシンのままでKubernetesを用いて管理可能です
Cloud Native の作法
2023年7月13日 成熟度モデルを活用したCloud Nativeへの道筋 という副題で登壇します #開発生産性con_findy https://syu-m-5151.hatenablog.com/entry/2023/07/13/131433 開発生産性Conference の登壇資料 https://findy.connpass.com/event/283417/
コンテナセキュリティ
「コンテナセキュリティ - Forkwell Library#26」の資料です。 https://forkwell.connpass.com/event/287259/
Linux Daily Topics Canonical、Spark on Kubernetesソリューション「Charmed Spark」のベータ版を公開 Canonicalは7月3日、Kubernetes上でSparkジョブをデプロイ/実行するオープンソースソリューション「Charmed Spark」の最初のベータ版リリースを発表した。 Charmed Spark beta release is out – try it today | Canonical Charmed SparkはCanonical Data Fabricチームが開発を主導するソリューションのひとつで、Charmed Sparkのほかに「Charmed Kafka」「Charmed MongoDB」「Charmed OpenSearch」「Charmed PostgreSQL」「Charmed MySQ
サービスを運用している中で緩やかにメモリ使用率が上がっていく問題があり、それが解決されるまで一時的になんとかするために掲題のを作りました。 github.com 中身自体はZapierが作っていたpreoomkiller-controllerが元になっております。 github.com このコントローラーを導入すれば済む話じゃない？ってなりそうですが、こちらは「メモリ使用量」を閾値としており、更に更新も止まっていたのでせっかくなら勉強がてら作り直すかーとなった結果こうなりました。 この手のk8sに関するツールを今まで全く作ったことがなかったので、勉強に以下の本を読ませていただきました。 実践入門 Kubernetesカスタムコントローラーへの道 技術の泉シリーズ (技術の泉シリーズ（NextPublishing）) 作者:磯 賢大インプレス NextPublishingAmazon pre
はじめに こんにちは、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ではオンプレミ
Podman Desktop を使った Kubernetes コンテナーのデプロイとテスト - 赤帽エンジニアブログ
Red Hatでソリューションアーキテクトをしている田中司恩(@tnk4on)です。 この記事は Red Hat Developerの Deploy and test Kubernetes containers using Podman Desktop を、許可をうけて翻訳したものです。 本記事で紹介する Podman や Podman Desktop に関する情報を日本語で紹介するTwitter アカウントがあります。こちらもフォローして情報収集に活用ください。(ハッシュタグ #podmanjp) Podman(https://t.co/ipoaatoD4a)の非公式Twitterアカウント。#Podman に関する情報を日本語で配信中。ツイートは個人のものであり特定の組織や企業を代表するものではありません。The unofficial Twitter account for Podma
アプリ開発者のための kubectl 講座
これは何 Kubernetes クラスタ管理者とアプリケーション開発者が分業しているプロジェクトで，開発者が必ずしも Kubernetes に詳しくない場合を想定し，開発時に使いそうな kubectl のコマンドをまとめたものです。 クラスタ管理者から開発者にこのドキュメントを適宜改変して渡し，開発者がある程度自立して操作できるようになることで，管理者への問い合わせ負荷を減らすのが狙いです。 場合によってはハンズオンで講座を開いてもよいでしょう。 ドキュメント案 ここでは Amazon EKS でクラスタを構築する場合の例を示します。 別のインフラに構築している場合は適宜書き換えてください。 事前準備 インストール kubectl AWS CLI AWS 環境設定 AWS CLI からアカウントを操作できるような設定方法を書きましょう。 コンテキスト作成 操作する対象の Kubernete
CNCF連載 の4本目です。 はじめに数年前にクラウドネイティブ注目技術として挙げられたeBPFにかねてよりキャッチアップしたいなと思っていたので、この連載のタイミングでeBPFとその関連プロダクトに入門してみることにしました。 CNCFプロジェクト傘下のeBPFを活用したプロダクトとしてはCilium, Falcoなどが挙げられます。CiliumはKubernetesなどのクラウドネイティブな環境でネットワーク、オブサーバビリティの機能を提供するOSSなのですが、今回はそのいわばサブプロジェクト的な位置づけのセキュリティツールである、Tetragonに触ってみます。 Cilium, Tetragonの開発をメイン行っているIsovalent社は、書籍やハンズオンラボなどで自社の製品・eBPFについての学習リソースを多く提供しています。 https://isovalent.com/reso
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)
〜運用しやすいプレビュー環境を求めて〜 Gateway APIで作るサービスメッシュレスなプレビュー環境 - LIVESENSE ENGINEER BLOG
みなさん、プレビュー環境してますか？どうも、かたいなかです。 以前、記事や登壇でIstioベースのPreview環境の構築方法をご紹介しました。 made.livesense.co.jp 外向けに発表したものの、Istioの運用工数や学習コストがネックとなってしまい、実際の転職会議の開発環境の導入にはいたっていませんでした。 最近になってGateway APIの実装例も増えてきて、Istio以外にもプレビュー環境でのヘッダを元にしたルーティングの実現において、現実的な選択肢となりそうなツールが増えてきました。そこで、Gateway APIのEnvoyによる実装であるEnvoy Gatewayを用いて、サービスメッシュを使用しないプレビュー環境の構築を試してみたため、この記事では構成例をご紹介します。 なお、今回の記事の中ではプレビュー環境の説明等について前回の記事と同様の説明を再度する箇所
GitHub - loft-sh/devpod: Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use any cloud, kubernetes or just localhost docker.
DevPod reuses the open DevContainer standard (used by GitHub Codespaces and VSCode DevContainers) to create a consistent developer experience no matter what backend you want to use. Compared to hosted services such as Github Codespaces, JetBrains Spaces, or Google Cloud Workstations, DevPod has the following advantages: Cost savings: DevPod is usually around 5-10 times cheaper than existing servic
こんにちは。search infraチームのmrkm4ntrです。 我々のチームでは検索基盤としてElasticsearchクラスタをKubernetes上で多数運用しています。これらのElasticsearchクラスタを管理しているnamespaceはマルチテナントな我々のKubernetesクラスタの中で最大のリソースを要求しているnamespaceです。 一方でクラスタのサイズをピークタイムに合わせて固定していたため、そのリソース利用率は非常に低いという問題がありました。Elasticsearch EnterpriseやElastic Cloudにはオートスケーリング機能が存在するのですが、これはスケールイン/アウトのためのものではなく、ディスクサイズに関するスケールアップ/ダウンを提供するもので我々の要求を満たすものではありませんでした。 そこで今回は、HPAを用いたスケールイン/
KubernetesクラスターからAWSリソースへのアクセスを制御してくれる「IRSA」とは？ - Qiita
「アクセス制御」ってややこしいですよね。 AWSでもIAMが苦手！って方多そうですが、Kubernetesの世界でもアクセス制御を知っておかないとセキュリティ事故に繋がります。 今回はそれらの合わせ技となる、AWS上でKubernetesを使う際の両プラットフォーム間でのアクセス制御の組み合わせについてのお話です。 AWS上でKubernetesを使う際のセキュリティ課題 EKSを使ってKubernetesワークロードをAWS環境上でホストしてるよ！という方は多いんじゃないかと思います。 特にAWSでKubernetesを使っていると「PodからAWSリソースにアクセスさせたい」という要件が出てきます。 以下のようなプロダクトを例として想像してみましょう。 この例では同じEKSクラスター上でKubernetes Podを2種類がバックエンドアプリケーションとして稼働しています。 Pod①へ
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とは？ 一言でいうと「コンテナ管理ソフトウェア」です。 オープンソースソフトウェア（OSS）なので、オンプレミスや各種パブリッククラウドなど様々なインフラストラクチャ上で利用することができます。 概要図 Kubernetesの主要コンポーネントは以下です。 ※今回は分かりやすいよう、各コンポーネントを抽象的な役割名ではなく具体的な実装名で表現しています。 コントロールプレーン 「管理サーバー」と捉えると分かりやすいかも知れません。 自分でサーバーを立ててセットアップすることもできますが、パブリッククラウドではマネージドサービスとして提供されています。（例：AWSのEKSなど） kube-apiserver：コントロールプレーンのフロントエンドとなるAPIサー
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 のマネージドサービスであり、非常
4台のラズパイでk8sクラスタを組んだ
ラックについて 今回買ったラックは、なぜかネジを締めるとWIFIが繋がらなくなる事象が発生した。多分金属製だからと思われる。 面白いことに、手をラックの近くに置くとWIFIがつながる。（繋がらない場合もある） すべてのラズパイがWIFI接続というわけではなくmasterのみなのであんまり影響がないが、本事象は完全に想定外だったのでラック選びは要注意。 ラックの組み立て 説明書あったが、ネジの種類のラベルが貼っていなくて全然分からなかった。 ので、公式が動画を出しているのでこちらを参考に組み立てた。 なぜかネジが足りなかったり余ったりしているが、ガタガタしていないので一旦気にしない。 OSをSSDにインストール OSは「Ubuntu Server 22.04.2 LTS(64bit)」を使う。 歯車のところからWIFIやssh、キーボードレイアウトなど設定をよしなにやる。 Mac側の接続
どんなに著名なOSSであっても、利用法によってはパフォーマンスチューニングが必要になる場面が存在します。 今回は過去に体験した事例から、モニタリングの大切さについてご紹介します。 Talked by TechFeed Experts Night#20 〜 Webパフォーマンス・チューニング最前線 : 前編（概要、モニタリング、負荷テスト編）
https://techfeed.io/events/techfeed-experts-night-20 TechFeed Experts Night#20 〜 Webパフォーマンス・チューニング最前線 : 前編（概要、モニタリング、負荷テスト編）
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[EC2からKubernetes]�楽天ラクマのコンテナ化の歩み
How we choked our Kubernetes NodeJS services
Kubernetes Exposed: One Yaml away from Disaster
エッジでKubernetesを実装する新しいプラットフォームをIntelとSpectro Cloudが紹介
さくらのクラウドシェルにおけるK8s運用事例 | さくらのナレッジ
Kubernetes の upstream のキャッチアップ
サービスメッシュのIstio、十分に成熟した段階に到達したとしてCNCFの卒業プロジェクトに
Kubernetesエキスパートが注目する「Platform Engineering」とは何か？ 一体何が新しいのか？
KubeVirtの何が嬉しいのか - inductor's blog
「KubeVirt 1.0」正式リリース。Kubernetesで仮想マシンもコンテナも管理可能に
Canonical、Spark on Kubernetesソリューション「Charmed Spark」のベータ版を公開 | gihyo.jp
メモリ使用率によってk8sのPodをevictさせる君を作った - 生涯未熟
Istio Rate Limitを活用した流量制限の取り組み - ZOZO TECH BLOG
TetragonでeBPFとセキュリティオブサーバビリティ入門 | フューチャー技術ブログ
ElasticsearchをCPU利用率でオートスケールさせる
Kubernetes で Pod が使用できる Secret を制限する方法 - Qiita
Kubernetes入門！主要コンポーネントを概要図で学ぼう - Qiita
過去事例から見るモニタリングの大切さ #techfeed_live
k6による負荷試験 入門から実践まで