Blog

今月に入り CNCF（Cloud Native Computing Foundation）が認定する 5 つの Kubernetes 関連資格を全て制覇し、Kubestronaut の称号を獲得しました。Kubernetes 認定資格はここ数年で試験内容のアップデートが続いており、日本語の具体的な攻略記事がまだまだ少ないと感じたため本記事を執筆することにしました。Kubestronaut の称号を得ることは、Kubernetes に関して運用・開発・セキュリティといったあらゆる側面から深く理解していることの証明になります。今回のブログでは、Kubernetes に興味を持っている方、実際に Kubestronaut を目標にしている方に向けて、私が実践した学習ロードマップや準備のプロセス、高得点を狙うための試験対策についてまとめたいと思います。本記事の内容は 2026 年 2 月時点のものです。試験内容は頻繁にアップデートされるため、受験の際は必ず公式サイトで最新の試験ガイドを確認してください。

OpenTelemetry Collector はテレメトリデータを効率的に送信するためにデータをバッチ化する仕組みを備えています。従来、この役割は Batch Processor と呼ばれる Processor のコンポーネントが担っており、全ての Collector に設定することが推奨されていました。一方で、Batch Processor はエクスポート失敗時にバッチ全体がドロップされる問題や、gRPC の ResourceExhausted エラー等、本番運用においていくつかの深刻な課題が顕在化していました。これを受け、コアメンテナの Bogdan 氏はバッチ処理を Exporter レイヤへ移行することを提案しました。2026 年 1 月現在、Batch Processor は非推奨化となり、後継である Exporter Helper の sending_queue にバッチ機能が統合されています。今回のブログでは Batch Processor から Exporter Helper へのバッチ機能移行について紹介したいと思います。

サービス規模が大きくなるにつれ、ログ・メトリクス・トレースといったテレメトリデータの収集経路は複雑になりがちです。ベンダ固有のエージェントや独自スクリプトが混在していると、管理コストが増大するだけでなく、運用環境に合わせたツールの移行も難しくなります。こうした課題に対し、OpenTelemetry Collector はテレメトリデータの収集・加工・転送までを一元管理するテレメトリパイプラインを提供します。今回のブログでは OpenTelemetry Collector のコンポーネントや、パイプラインの基本的な設計・運用パターンについて紹介したいと思います。

Flutter は単一のコードベースからモバイル、Web、デスクトップといった複数のプラットフォームに向けて、ネイティブコンパイルされたアプリケーションを構築できる UI フレームワークです。Flutter は独自のエンジンとシンプルなパイプライン設計により、React Native や WebView と比較して高いレンダリングパフォーマンスを発揮するとされています。クロスプラットフォームでありながら Flutter が高性能な描画を実現できる原理について気になったので、今回のブログでは Alibaba Cloud の記事を参考に、レンダリングプロセスと最適化戦略について Deep Dive してみます。

Kubernetes v1.33 では長らく利用されてきた Endpoints API が正式に Deprecated となり、EndpointSlice API が標準化されます。Endpoints / EndpointSlice はどちらも Pod のネットワークエンドポイントを管理するための API です。Endpoints を参照するコンポーネントが存在する場合、どのような影響があるのかについて理解しておく必要があります。例えば、Endpoints から EndpointSlice に移行すると、API グループが core から discovery.k8s.io に変わるため、カスタムコントローラはじめ client-go を利用している場合は、実装そのものを修正する必要があります。また、v1/Endpoints を直接 get / watch / list するコンポーネントの場合、必要に応じて RBAC を修正する必要があります。今回のブログでは、Endpoints と EndpointSlice の違いや、移行することにどのようなメリットがあるのかについて紹介したいと思います。