#CNDT2021 で Kustomize の話をしたときの資料です。
目次 [toc] はじめに キャディでバックエンドエンジニアとCI/CDやIaC、自動テストなどDevOps的な仕事を兼務している山下です。 k8sを実際にサービスの運用に使おうとすると確実にぶつかる壁があります。それは構成管理です。 具体的にいうと、基本は設定を共通化しつつ、環境に応じて一部だけを差し替えて管理しようとするとk8sだけでは運用が難しくなってきます。 そうした課題を解決するのに、最も使われているツールはHelmです。 (Helmは構成管理だけでなく、パッケージマネージャーとしての機能もあり、より広範な存在ですが) しかし、キャディでは、Kustomizeというツールを使用し、構成管理を行なっています。 その理由やメリット、使い方を簡単に紹介出来ればと思います。 Kustomizeを選定した理由 HelmではなくKustomizeを選定した理由は大きく4つ存在します。 それは
はじめまして、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.
こんにちは。インフラエンジニアの北野です。 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に書いて
先週の記事に続き 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
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 を追加しておく
TL;DRKustomize はベースを Overlay 間で共有するものだけど、パッチを共有したいこともあるKustomization を使うとパッチを共有できないKustomize v3.7.0 以上で使える Component を使うとパッチが共有できるKustomize はベースを共有するKustomize は Kubernetes で複数の環境、例えばプロダクションとステージングやクラスタ A、クラスタ B でほぼ同じマニフェストファイルを使うけど一部だけ違う場合に共通部分のベースと差分をオーバーレイとして管理できるツールです。 下記の例は、base ディレクトリに共通なマニフェストファイルがあり、development と production のディレクトリにその環境でのみ必要なマニフェストファイルや共通なマニフェストへのパッチを置き、Overlay 側から、つまり deve
version指定失敗 KustomizeをCodeBuild上で実行しています。buildspec.ymlはこんな感じ↓で、公式サイトにあるダウンロードスクリプトを使用しています。公式サイトに書かれているスクリプトのURLはGitHubのブランチ指定にあたるURLセグメントがmasterになっているので、そこを変更してインストールするKustomizeのversion指定をしています。 buildspec.yml --- version: 0.2 env: variables: KUSTOMIZE_VERSION: "v4.2.0" phases: install: commands: - curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/kustomize/${KUSTOMIZE_VERSION}/
技術開発チームの基盤システム担当の小倉です。 最近、社内システム用のコンテナ基盤をDockerからマネージドKubernetesサービスであるAmazon EKSとAzure Kubernetes Serviceに移設しました。その際に、Kubernetesのマニフェストの管理にオープンソースのKustomizeを利用しました。 私自身は実際に動かすことでKustomizeについての理解が進みました。そのため、本ブログはハンズオン形式でKustomizeを紹介します。ぜひ、手元で動かしていただけましたら幸いです。 Kustomizeとは 公式ドキュメントから引用すると以下のとおりです。 KustomizeはKubernetesマニフェストを横断し、フォークすることなく設定オプションを追加、削除、更新します。スタンドアロンバイナリとしてもkubectlのネイティブ機能としても利用可能です。
こんにちは。Xイノベーション本部クラウドイノベーションセンターの柴田です。 本記事ではkustomizeでCustom Resourceを扱う方法を紹介します。 kustomizeとは kustomizeでCustom Resourceを適切に扱う kustomizeはデフォルトでCustom Resourceを適切に扱えない kustomizeでCustom Resourceを適切に扱う kustomizeで標準リソースとCustom Resourceを適切に扱う 独自のOpenAPIスキーマを設定すると標準リソースを適切に扱えなくなる kustomizeで標準リソースとCustom Resourceを適切に扱う 終わりに 参考 kustomizeとは kustomize はKubernetesのマニフェストファイルを加工・生成するためのツールです。 ユースケースとして例えば環境毎(開発
この記事は GRIPHONE Advent Calendar 2020 25日目の記事です。 SREの徳田です。 ふとkustomizeでbaseのリソースからあるリソースを削除したいな〜と思ったのですが、なかなかやり方や文献が出てこなかったので紹介も兼ねてここに書いておこうかなと思います。 TL;DR Strategic Merge Patchとして以下のパッチを適用する。 $patch: delete apiVersion: v1 kind: Namespace metadata: name: hoge Manifestの例 以下のようなディレクトリ構成・Manifestを用意しました。 $ tree . ├── base │ ├── kustomization.yaml │ ├── ns-fuga.yaml │ └── ns-hoge.yaml └── overlay └
背景 Kubernetes上でマイクロサービスアーキテクチャを実現する上で大量のmanifestの管理は避けて通れない。 この問題を解決するには、共通部分を使い回しやすくする仕組みが求められる。 Kubernetes上でmanifestを管理しやすくするツールは複数開発されており、Helmや、Kustomizeなどが有る。 冒頭で挙げた共通部分を使い回しやすくする上で、どのツールが適しているかについて簡単に検討する。 前提 いきなり、網羅的でなく恐縮ですが、HelmとKustomize以外のツールは今回の比較から除外します。 除外されたツールは主にKsoonet、Kapitan、Kubecfgを指します。 以下、理由になります。 KapitanとKubecfgはGitOpsツールのArgo CDが対応していないため(今回はGitOpsのワークフローで使用することを前提としている) Ksoo
この記事はOpenSaaS Studio Advent Calendar 2019の2日目の記事。今日も@stormcat24 が書きます。 背景 弊部署で開発しているSaaSプロダクトは基本的にOpenSaaS戦略に則り開発されている。OpenSaaSとはManagedのSaaSとして提供するという面と、OSSとして公開し、技術コミュニティの力を借りながらもその技術ドメインのデファクトの一つを目指すという考え方である。代表的なモデルとしてはKubernetesであったり、mongoDBやRedis、最近だとGrafanaもそうだ。彼らはOpenSaaSという言葉を標榜してはいないが、基本的に目指す方向は同じと思ってもらっていい。 OpenSaaSを標榜していると、マルチプラットフォーム(パブリッククラウド・プライベートクラウド問わず)対応からは逃れることはできない。とはいえ最初からマルチ
はじめに 今回は、これまでの回で学んだことを踏まえて、より複雑で実践的なアプリケーションをデプロイしてみましょう。 サンプルアプリケーションの概要 今回利用するサンプルアプリケーションは、技術ブログサイトをイメージして作成しました。4つのサービスに分かれており、それぞれ「Article」「AccessCount」「Rank」「WebSite」と呼びます。 アプリケーションのソースコードとデプロイ用のマニフェストはGitLab.comの以下のプロジェクトで公開されています。 https://gitlab.com/creationline/thinkit-kubernetes-sample1 WebSiteサービス:エンドユーザ向けのWebサイトを提供。記事の一覧と各記事のページが閲覧でき、前日のアクセスランキングがサイドバーに表示される。 Articleサービス:ブログ記事の一覧と取得、作成
Kustomizeを使うとき、 patches でファイルを指定してbaseファイルを部分的に変更することが多いと思う。しかし先日、 patches ではなく patchesJson6902 という指定をしているファイルを見かけたので、どう使うのか調べてみた。 patchesJson6902とは patchesJson6902は、名前の通りRFC6902に沿った方法でPatch処理を行うことができる。RFC6902ではJSON Patchについて定義されている。 tools.ietf.org Kustomizeは公式ドキュメントをたどりづらいが、Kubernetesのドキュメントの中に詳しい使い方が記載されている。 kubernetes.io patchesStrategicMerge と patchesJson6902 の違い Kustomizeでは、patchを行う際に patches
kustomize 2.1.0で機能追加、変更点があったのでまとめる kustomize/v2.1.0.md at master · kubernetes-sigs/kustomize · GitHub プラグイン機構の導入 kustomize の generator / transformer の振る舞いを変えてみる | TECHSCORE BLOG に詳しく書かれているのでご参照ください resources expanded, bases deprecated basesがdeprecatedになり、代わりにresourcesを使うようになった。 今までは例えばoverlayes/production/kustomization.yaml の中で bases: - ../base patches: - cpu_count.yaml のように書いていたのが、今後は以下のように書くことが推
こんにちは。テクノロジー本部バックエンド開発グループの山下です。 この記事は キャディ Advent Calendar 2020 の11日目です。 前日は大原さんの 図面を管理するために図面版 figma を開発している話 について でした。 今回は以前のKustomizeの記事に続き、 「GitOps概要と実践例 〜Kustomize + CircleCI 編〜」と題して、 GitOpsの概要を説明した上で、KustomizeとCirlceCIを利用したk8s上でのGitOpsの実践例について 書いていこうと思います。 [toc] GitOpsとは 概要 WeaveWorksのGuide To GitOpsより引用 GitOpsはきちんと説明するだけでもかなりの分量になるので、かなり思い切って要約すると 「Kubernetesクラスターの構成をコード化してGitで管理し、その情報だけを正
$ kustomize version {Version:kustomize/v4.0.1 GitCommit:516ff1fa56040adc0173ff6ece66350eb4ed78a9 BuildDate:2021-02-13T21:21:14Z GoOs:darwin GoArch:amd64} 問題の解説 kustomization.yaml の images 機能を使うとマニフェストの image タグを上書きできる。 やんごとなき理由から同じ image を複数回この機能で上書きしようとすると、 images フィールド内の順序が結果に影響する。 例えば kustomization.yaml を
これからkustomizeを使う人向けに、kustomizeとは何か、実際にどう使うのかを解説していきたいと思います。 kustomizeとは kustomizeとは、Kubernetesのマニフェスト管理ツールです。 開発環境、ステージング環境、本番環境などと各環境でマニフェストを作成すると、それぞれでマニフェストが異なることがあります。(レプリカ数とかリソースとか)そのような場合に、ベースとなるマニフェストは共通で、各環境での差分はそれぞれの環境ごとのマニフェストで管理できるようにするツールがkustomizeです。 ベースとなるマニフェストと各環境用のパッチファイルは以下のような構成で利用できます。 1. 2├── base # ベースとなるマニフェスト用ディレクトリ 3│ ├── deployment.yaml # ベースとなるDeployment 4│ └── kusto
このページに記載されている情報は古い可能性があります このページの更新日は英語版よりも古いため、記載されている情報が古い可能性があります。最新の情報をご覧になりたい方は英語版のページをご覧ください: Managing Secrets using Kustomize Kubernetes v1.14以降、kubectlはKustomizeを使ったオブジェクト管理をサポートしています。 KustomizeはSecretやConfigMapを作成するためのリソースジェネレーターを提供します。 Kustomizeジェネレーターは、ディレクトリ内のkustomization.yamlファイルで指定します。 Secretを生成したら、kubectl applyでAPIサーバー上にSecretを作成します。 始める前にKubernetesクラスターが必要、かつそのクラスターと通信するためにkubectl
本記事では、Kubernetesのmanifestを管理するためのkustomizeで利用できるpatchesについて、参照されているRFCを読みながら理解することを目指します。 patchesの具体例まず、patchesの具体的な利用を確認します。 以下のようなIngressにpatchを当てたいとします。 apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example spec: rules: - host: blog.ymgyt.io http: paths: - path: / backend: serviceName: service-1 servicePort: 5001 kustomization.yamlは以下のようになります。 apiVersion: kustomize.config.
Kustomize では外部の Git リポジトリにある manifest を参照し、 base として使うことができるようです。 bases に渡す manifest のパスを git@<Repository Path>.git/manifest のように記述することで参照できます。 apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: argocd resources: - namespace.yaml bases: - git@github.com:github.com/argoproj/argo-cd.git/manifests/crds?ref=v1.1.2 - git@github.com:github.com/argoproj/argo-cd.git/manifests/base?
はじめに 実務において、kubernetesのマニフェスト作成(管理)の方法としてHelm or Kustomizeという選択肢がとられている。 ここでは、クライアント組織への導入したときの話をしたいと思う。 クライアント組織の要求事項と特性を整理した上で、どちら(または同時使用)が適切か判断するための調査を行う Helm : https://helm.sh/ Kustomize : https://kustomize.io/ TL;DR 個人的にはHelmの使用を推奨したい アプリケーション / インフラ / SREと多くのレイヤーの人が関わる組織統制を考慮したときに、Helmを使用した方がバランスの取れた運用に近づくのではないか 調査 背景 大規模な組織であるクライアント組織では、開発に際して日々、多くのステークホルダーが関わっている その中で、開発組織や技術レベルに対して統制をとるこ
Kustomizeは本番環境、ステージング環境、開発環境など環境ごとに異なるYAMLを管理するのに非常に便利です。 しかし、KubernetesビルトインなL7 Loadbalancerの管理APIであるIngressについてはかなり以前から要望があったものの、Kustomizeはビルトインサポートしない方針を取ってきました。 今回はKustomizeの柔軟性のための機能について、Ingressの環境管理を例に整理します。 今回使用したコードはGithubに置いてあります。 Ingressの環境管理のつらみ IngressはKubernetesビルトインなL7 Loadbalancerの管理リソースです。 Ingress APIはもともとextention/v1beta1APIとしてKubernetesの初期から存在し、networking.k8s.io/v1beta1の長い期間を経て、2
こんにちは。インフラエンジニアの北野です。 kustomizeを使用する機会がありましたので、そこで得た知見を紹介したいと思います。 kustomizeを使ってIngressのマニフェストを管理しようとしたのですが、[patchesStrategicMerge:]では定義を想定通り生成できない事態に陥ったので、原因と対応方法について紹介します。 patchesStrategicMergeでの上書きは定義が消えるkustomizeでは、kubernetesと同じjson形式で記述できるpatchesStrategicMergeを使用することを基本的には推奨しますが、patchesStrategicMergeでは、Ingressの定義を想定通り生成できません。 何故なら、Ingressの定義のspec.rulesは配列の構造体となっており、一意となる名前も存在しないからです。そのため、spec
Kubernetes v1.21 での変更 Kustomize v2.1.0 での変更 Go モジュール トップレベルの go.mod ファイルで依存関係を定義するように変更されたようです。 kubectl や kubebuilder、kustomize などで使用するためとなります。 Resource ordering 要望の多かったリソースの読み取り時の深さの優先順位を保持するように変更。 kustomize のファイルを変更することでリソースの順序を制御できるようになったので、ユーザー定義のプラグインを特定の順番で実行できるようになりました。 この機能自体は何もしなくても有効になるようです。 ビルドコマンドで、--reorder フラグに legacy と none の値を指定できるようになりました(デフォルト値は legacy) generator や transformer の仕
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く