#CNDT2021 で Kustomize の話をしたときの資料です。
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
目次 [toc] はじめに キャディでバックエンドエンジニアとCI/CDやIaC、自動テストなどDevOps的な仕事を兼務している山下です。 k8sを実際にサービスの運用に使おうとすると確実にぶつかる壁があります。それは構成管理です。 具体的にいうと、基本は設定を共通化しつつ、環境に応じて一部だけを差し替えて管理しようとするとk8sだけでは運用が難しくなってきます。 そうした課題を解決するのに、最も使われているツールはHelmです。 (Helmは構成管理だけでなく、パッケージマネージャーとしての機能もあり、より広範な存在ですが) しかし、キャディでは、Kustomizeというツールを使用し、構成管理を行なっています。 その理由やメリット、使い方を簡単に紹介出来ればと思います。 Kustomizeを選定した理由 HelmではなくKustomizeを選定した理由は大きく4つ存在します。 それは
2019/07/04に kustomize の v3.0.0 がリリースされ、それまで暗黙の仕組みっぽかったプラグイン機構がオフィシャルになった。 …と言っても大きくアナウンスされているような節はなく、ドキュメントについても、 https://github.com/kubernetes-sigs/kustomize/tree/master/docs/plugins このページのみで、また他に自作する方法のエントリが見当たらなかったので書く。なおこのエントリはやや社内向けでもある。 宣言的なmanifest管理 kubernetesのmanifestを管理する機構として、代表的なものは helm か kustomize だと思う。以前はプロジェクトで helm を使っていたけど、 base に記述した設定を overlay で差分パッチを当てつつmanifestを生成する手法はいいな、という
こんにちは、松浦です。 シナジーマーケティングでは Kubernetes のマニフェスト管理については kustomize を主に利用しています。今回は、 kustomize にまつわる内容を扱います。 kustomize には、 kustomize build 時にリソース定義の生成を行う generator (ConfigMapGenerator, SecretGenerator)や、変換処理などを行う transformer (コンテナイメージ名やタグを変える images やラベルを各リソースに付与する commonLabels など)が用意されています。デフォルトの状態でも十分に使い勝手の良いものですが、ときに generator や transformer の振る舞いに変更を加えたり、新たに処理を追加したいこともあるかもしれません。そのような場合にどういう手段が用意されているの
はじめまして、LINEヤフー株式会社でKubernetes as a ServiceのPlatform Engineerを務めている小林と申します。 私は業務で使っているという都合もあり、 kustomize(※)というOSSの開発者もしています。 ※ kustomize:kustomizeは、KubernetesのYAMLマニフェストファイルをテンプレート化せずに管理するためのツールです。ベースとなるマニフェストに対して、パッチやオーバーレイといった方法で変更を加えることができます。これにより環境ごとの設定差分を管理し、再利用可能なマニフェストファイル群を作成することが可能となります。 前回のKubeConにて、OSSへの貢献から Kubernetes Contributor Awards という賞を受賞させて頂きましたので、私のLINEヤフー株式会社でのKubernetesやOSSとの
KubernetesのYAMLを環境毎のに分ける時にkubectlに標準で入っているkustomizeを使ってるのですが、サンプルなどに書かれている patchesStrategicMerge では以下のようなYAML内の値に変数を埋め込めないな。と考えていました。 kustomizeのリポジトリを見ていたら vars という設定を見つけたので、これをを上手く使えないか考えた方法を書いていきます。 github.com 利用ケース Varsの設定の読み方 ファイル構造 ファイルの中身(overlays側) overlays/${ENV}/cronjob_meta.yml overlays/${ENV}/kustomization.yml ファイルの中身(base側) base/cronjob.yml base/kustomization.yml base/varreference.yml
対象のフィールドの値を null としてパッチすることでフィールドそのものを削除できます。 kustomize version {Version:3.5.4 GitCommit:3af514fa9f85430f0c1557c4a0291e62112ab026 BuildDate:2020-01-17T14:23:25+00:00 GoOs:darwin GoArch:amd64} 例えば次のような Pod マニフェストがあるとします。 apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: LOG_LEVEL
やりたいこと Podのコンテナで使われているコンテナイメージのタグ値をつかって、そのPodに環境変数を設定したいです。 以下のように同じ値をそれぞれの設定箇所に書けばシンプルに実現できますが、保守性の観点から同じ値を複数箇所に書くのは避けたいのです。(絶対に環境変数値の更新を忘れる) --- apiVersion: apps/v1 kind: Deployment metadata: name: sample spec: replicas: 1 selector: matchLabels: app: sample template: metadata: labels: app: sample spec: containers: - name: sample image: nginx:1.20 env: - name: HOGE value: "1.20" 1箇所書けばイメージタグ値にも環境
「Kubernetes 完全ガイド 第2版」で「第14章 マニフェストの汎用化を行うオープンソースソフトウェア」を読んでいたら「第1版」では紹介されていなかった(正確には名前は載っていた)kustomize の解説が新しく追加されていた.本書を読みながら概要を理解したため,GitHub に公開されている kustomize の Examples を試しながら理解を深めていく.今回は「helloWorld」を試す. github.com Kubernetes完全ガイド 第2版 (Top Gear) 作者:青山 真也インプレスAmazon 前提 今回は Docker Desktop for Mac "Edge" を使って,以下の Kubernetes 環境で試した.kustomize コマンドは brew install kustomize で使えるようにした.なお,現在は kubectl と
Kubernetes native configuration management Kustomize introduces a template-free way to customize application configuration that simplifies the use of off-the-shelf applications. Now, built into kubectl as apply -k.
今までkubernetesのmanifestはテンプレートエンジンを使って環境毎にビルドして使っていましたが kubectl1.14にkustomizeが統合された(?)のもあり kustomizeでビルドする感じに移行したので、やったことをメモ Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA - Kubernetes kustomizeのベスト・プラクティスが知りたい、、、 環境 GKE 1.13系 kustomize v2.0.3 sops 3.3.0 管理方針 ディレクトリ構成 baseとoverlaysで管理する 環境変数 configMapGeneratorとsecretGeneratorを使う 環境変数にConfig
こんにちは。インフラエンジニアの北野です。 kustomizeを使用する機会がありましたので、そこで得た知見を紹介したいと思います。 kustomizeについて知りたいかたの一助になれば幸いです。 kustomizeとはKustomizeは、複数のKubernetesクラスターを管理する状況において、リソースの構成や設定などをYAML形式で記述したマニフェストファイルをシンプルに管理できる便利なツールです。 Kubernetesではリソースの構成や設定などをYAML形式で記述したマニフェストで管理を行います。 マニフェストに定義した構成や設定を、マスターノードに登録することで、「Infrastructure as Code」を実現しています。 インフラの設計や設定がCode化されていると、構築が大変捗りますよね。 しかし、実務において、使用するクラスターは一つだけではなく、開発環境、本番環
こんにちは。SREの菅原です。 突然ですがKustomize便利ですよね。 弊社ではKubernetesのManifest管理にKustomizeを使っています。Kustomizeの機能は複数ありどれも便利なのですが、今回はその中でもComponentsという機能を使って便利なのかどうなのかという話をしたいと思います。 KustomizeのComponentsについて Componentsの便利なところ Componentsで躓いたところ まとめ KustomizeのComponentsについて ※KustomizeのComponentsについて話したいので、Kustomize自体の説明は省きます。 Kustomize Componentsはv3.7.0から使えるようになった機能です。 kubectl.docs.kubernetes.io どのような機能かというと、componentsとい
はじめに 前回は、これまで説明したDeploymentやServiceを使って実際にJavaアプリケーションを動作しました。ここでは「kustomize」というツールを利用してマニフェストを統合しました。 今回は、この「kustomize」について少し掘り下げて説明し、実際にkubernetesマニフェストを整理していきます。 kubernetesマニフェストの肥大化 これまで、kubernetes上にアプリケーションを展開するためにマニフェストファイルを書いてきました。アプリケーション1つにマニフェストファイルが1セット、というように対応していれば良いのですが、実際の運用ではそうもいかないことがあります。それこそ前回取り扱ったアプリケーションのように、開発環境と本番環境、あるいはステージング環境で微妙にマニフェストが異なる…ということはよくあります。このときにファイルを用いて差分管理して
はじめに sweeep株式会社エンジニアの関田です。 今回はKubernetesでよく使われるマニフェスト管理ツールのkustomizeを使ってみたので 簡単に紹介したいと思います。 Kustomizeのドキュメントはこちらになります。 Kustomize Reference また、今回例で使用するマニフェストファイルは以下になります。 Github Kustomizeとは Kustomizeとはマニフェストファイル管理ツールで、 dev、stg、prd環境などにそれぞれマニフェストファイルを書くと同じ内容のものが何箇所も出てきます。 Kustomizeはそのような場合の管理を簡単に行えるようにできるツールになります。 インストール Installation 上記にいろいろなインストール方法が書いてあります。 今回はMacのHomebrewでインストールしていきます。
はじめに おはようございます、もきゅりんです。 先日、EKSでWeave Fluxを使ってGitOpsしてみる によって、かなり楽にk8sでCI/CDを体験することができました。 しかし、実用の場面ではstg, prodといった複数の環境ごとに設定の調整することを考慮しなくてはなりません。 ということで、Kustomize *1 を使ったFluxでGitOpsを再びEKSでやってみました。 Using Flux with Kustomize を元に進めていきます。 このチュートリアルのシナリオとしては、staging と production と2つのk8s clusterがあり、それぞれに設定される最小のpod数がstgが1つ、prodが2つとなっていますが、この稿では、1clusterで2回デプロイすることで対応します。 環境について EKS Workshpの GETTING STAR
はじめに k8sにはkustomize(カスタマイズ)というツールがある。 k8sでyamlを量産していると運用においてつらいことがいくつか出てくる。 yamlをたくさん書くのがつらい。共通化したい。 環境が複数ある時のyaml管理がつらい。ベースは同じだけど環境ごとに微妙に変数や設定を変更したい。 これらの問題を緩和するツールの一つがkustomizeである。 概要 basesとoverlaysを区別して記述することで上記の課題を解決していく。 各環境で共通設定となる記述をする → bases 個環境で差分となる設定を記述する → overlays 下図でいうとそのままapplyすれば本番環境になるし、ステージ環境用にapplyすればステージ環境用なる。みたいにする。 もちろん何をベースとしたいかは開発者次第なので上図の限りではない。 baseで設定してない項目をoverlaysに書いて
Helmfile のドキュメントを読んでいたら Advanced Features として「Deploy Kustomization with Helmfile(Helmfile で kustomize をデプロイする)」という機能が載っていた.最初はどういう意味?と疑問だったけど,簡単に言うと helmfile apply コマンドを使って kustomize プロジェクトをデプロイできる機能だった. 試したことをまとめていく! github.com Helmfile で kustomize をデプロイする ☸️ さっそく base/ と overlays/ から構成された通常の kustomize プロジェクトを準備する.今回は kakakakakku/sandbox-kustomize を使う.そして Helmfile の設定ファイルである helmfile.yaml を追加しておく
先週の記事に続き kustomize の Examples を試していく.前回は「helloWorld」を試した.今回は ConfigMap リソースでローリングデプロイのような挙動を実現できる kustomize の configGeneration を試す. kakakakakku.hatenablog.com 前提 今回も Docker Desktop for Mac "Edge" を使って,以下の Kubernetes 環境で試した. $ kubectl version --short Client Version: v1.18.6 Server Version: v1.18.6 $ kustomize version --short {3.8.1 2020-07-16T05:11:04+01:00 } Examples「configGeneration」とは? kustomize
TL;DRKustomize はベースを Overlay 間で共有するものだけど、パッチを共有したいこともあるKustomization を使うとパッチを共有できないKustomize v3.7.0 以上で使える Component を使うとパッチが共有できるKustomize はベースを共有するKustomize は Kubernetes で複数の環境、例えばプロダクションとステージングやクラスタ A、クラスタ B でほぼ同じマニフェストファイルを使うけど一部だけ違う場合に共通部分のベースと差分をオーバーレイとして管理できるツールです。 下記の例は、base ディレクトリに共通なマニフェストファイルがあり、development と production のディレクトリにその環境でのみ必要なマニフェストファイルや共通なマニフェストへのパッチを置き、Overlay 側から、つまり deve
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く