本記事では、Go言語でKubernetes Podで実行中のコンテナメトリクスを取得する方法をご紹介します。 Kubernetesでは、アドオンのコンポーネントであるmetrics-serverをデプロイすることで、Metrics APIを介してクラスタ内で実行中のPodやNodeのリソース使用量を取得することができます。 こちらのMetrics APIを利用して対象のPodで稼働中のコンテナメトリクスを取得するプログラムをGo言語で作成しつつ、各処理について説明します。 k8s.io/metricsモジュールの紹介 Kubernetes Organization配下のリポジトリであるmetricsリポジトリでは、k8s.io/metricsモジュールを提供しています。 このモジュールには、Kubernetes Metrics APIに関連する型定義とクライアントが実装されています。 本記

本記事では、client-goのkubernetes/fakeパッケージを使って、テスト関数を実装する例を紹介します。 テスト関数では、テスト対象の関数内の処理によりKubernetesオブジェクトが作成されているかどうかの確認を行います。 fake clientとは kubernetes/fakeパッケージが提供するClientsetを利用することで、実際にKubernetes APIへリクエストを送ることなく実行マシンのメモリ上でclientsetによるオブジェクト取得や作成といった動きを模倣できます。 client-goが提供するkubernetesパッケージのClientsetには様々なKubernetesのデフォルトリソースに関してKubernetes APIにリクエストするためのクライアントが含まれており、PodやDeploymentといったデフォルトリソースをGo言語で操作す

本記事ではYAML形式のKubernetesマニフェストを読み込み、対応する型を持ったGo言語のオブジェクトにデシリアライズする方法を説明します。 k8s.io/apimachineryモジュールが提供するyamlパッケージの機能を利用することでこれを実現できます。 実装例と解説 以下は、YAML形式で書かれたPodのマニフェストファイルを読み取り、core/v1のPod型を持つオブジェクトにデシリアライズし、client-goを使ってGo言語のオブジェクトからKubernetesのPodオブジェクトを作成する例になります。この例で作成するPodは次の2種類になります。 元々のマニフェストのフィールド値を持つPod 1のPod名を変更した新しいPod package main import ( "context" "flag" "fmt" "os" corev1 "k8s.io/api/c

はじめに KubernetesはGo言語で開発されており、開発に利用されるモジュールとしてclient-goが利用されることは割とよく知られているかと思います。 またclient-goを触ると必ず登場するのがapi・apimachineryというモジュールです。 自分がはじめてGo言語でKubernetes APIを操作するプログラムを書いた際には、これらのモジュールの機能・関係性がいまいちよく理解できずにいました。 本記事ではGo言語を使ってKubernetes APIを操作するプログラムを書く際に利用するclient-go・apimachinery・apiモジュールについてその機能と関係性について調べたことをまとめました。 client-go client-goはGo言語でkubeapi-serverへリクエストを送る際のクライアントとして機能します。 前提として、Kubernetes

こちらのコマンドのように対象のリソースに関わらず基本的に--filterのようなフラグ引数を渡すことができるようになっています。 フォーマット gcloudコマンドはコマンド実行が成功した場合、リソースの一覧を返します。 デフォルトではそれらの出力は綺麗に並べられた状態で標準出力に出力されます。 --format=jsonのように出力を整形したい形式を--formatフラグに指定することで、コマンドの出力フォーマットを任意の形式に変換することができます。 出力全体をフォーマットする --formatで指定可能な形式は2022/12時点で20種類以上が用意されています。 詳細はhttps://cloud.google.com/sdk/gcloud/reference/topic/formats を参照してください。 個人的に利用する頻度の高い形式の出力例を以下に記載しています。 json形式

はじめに こんにちは。今年は自宅でからすみ作りに挑戦している岡本です。 自分の所属チームであるMLOpsブロックでは、主にMLモデルを組み込んだシステムの開発・運用・保守を行なっています。 要件によってシステムの構成は様々ですが、基本的にBatch, API, DBが主な構成要素として存在することが多く、大別すると以下の2種類の構成を取っています。 オンライン推論を行うケース Batchではモデルの学習を行い、APIはリクエスト受けてから学習済みモデルで都度推論を行い、呼び出し元にレスポンスを返す オフライン推論を行うケース 予めBatchで推論を行った結果をDBに保存しておき、APIはDBのレコードを参照して呼び出し元にレスポンスを返す 基本的にいずれのケースにおいてもAPI, Batchの開発が必要となり、チームの人数に対して管理対象のシステムは少なくとも2つ以上増えていきます。そのた