#CNDT2021 で Kustomize の話をしたときの資料です。
はじめまして、LINEヤフー株式会社でKubernetes as a ServiceのPlatform Engineerを務めている小林と申します。 私は業務で使っているという都合もあり、 kustomize(※)というOSSの開発者もしています。 ※ kustomize:kustomizeは、KubernetesのYAMLマニフェストファイルをテンプレート化せずに管理するためのツールです。ベースとなるマニフェストに対して、パッチやオーバーレイといった方法で変更を加えることができます。これにより環境ごとの設定差分を管理し、再利用可能なマニフェストファイル群を作成することが可能となります。 前回のKubeConにて、OSSへの貢献から Kubernetes Contributor Awards という賞を受賞させて頂きましたので、私のLINEヤフー株式会社でのKubernetesやOSSとの
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化されていると、構築が大変捗りますよね。 しかし、実務において、使用するクラスターは一つだけではなく、開発環境、本番環
やりたいこと 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 と
はじめに 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 を追加しておく
こんにちは。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セット、というように対応していれば良いのですが、実際の運用ではそうもいかないことがあります。それこそ前回取り扱ったアプリケーションのように、開発環境と本番環境、あるいはステージング環境で微妙にマニフェストが異なる…ということはよくあります。このときにファイルを用いて差分管理して
先週の記事に続き 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
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}/
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
技術開発チームの基盤システム担当の小倉です。 最近、社内システム用のコンテナ基盤を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 └
Kustomizeを使うとき、 patches でファイルを指定してbaseファイルを部分的に変更することが多いと思う。しかし先日、 patches ではなく patchesJson6902 という指定をしているファイルを見かけたので、どう使うのか調べてみた。 patchesJson6902とは patchesJson6902は、名前の通りRFC6902に沿った方法でPatch処理を行うことができる。RFC6902ではJSON Patchについて定義されている。 tools.ietf.org Kustomizeは公式ドキュメントをたどりづらいが、Kubernetesのドキュメントの中に詳しい使い方が記載されている。 kubernetes.io patchesStrategicMerge と patchesJson6902 の違い Kustomizeでは、patchを行う際に patches
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Helm VS Kustomize 背景 Kubernetes上でマイクロサービスアーキテクチャを実現する上で大量のmanifestの管理は避けて通れない。 この問題を解決するには、共通部分を使い回しやすくする仕組みが求められる。 Kubernetes上でmanifestを管理しやすくするツールは複数開発されており、Helmや、Kustomizeなどが有る。 冒頭で挙げた共通部分を使い回しやすくする上で、どのツールが適しているかについて簡単に検討する。 前提 いきなり、網羅的でなく恐縮ですが、HelmとKustomize以外のツールは今
はじめに sweeep株式会社エンジニアの関田です。 今回はKubernetesでよく使われるマニフェスト管理ツールのkustomizeを使ってみたので 簡単に紹介したいと思います。 Kustomizeのドキュメントはこちらになります。 Kustomize Reference また、今回例で使用するマニフェストファイルは以下になります。 Github Kustomizeとは Kustomizeとはマニフェストファイル管理ツールで、 dev、stg、prd環境などにそれぞれマニフェストファイルを書くと同じ内容のものが何箇所も出てきます。 Kustomizeはそのような場合の管理を簡単に行えるようにできるツールになります。 インストール Installation 上記にいろいろなインストール方法が書いてあります。 今回はMacのHomebrewでインストールしていきます。
はじめに 解決したい課題 抱えていた問題点 理想的な開発フロー 前提条件 kustomize を使った環境構築 Argo CD による GitOps 運用 リポジトリ構成の分離 設計方針 Feature 環境で実現する内容 Feature 環境の動的リソース作成方法 kustomize の標準機能での課題 独自ツールを活用 kustomize build の出力先ディレクトリ構成 Feature 環境用ディレクトリ構成 As-Is(現状構成) To-Be(新構成) GitHub Flow ベースの開発フロー 運用で得られたTips 1. Cloud リソースの再利用方針 2. DNS/SSL 設定の自動化 3. RDBマイグレーションの衝突 4. BigQuery スキーママイグレーションの競合 おわりに 導入効果 今後の展望 はじめに こんにちは、enechainでeScanという電力取
はじめに 今回は、これまでの回で学んだことを踏まえて、より複雑で実践的なアプリケーションをデプロイしてみましょう。 サンプルアプリケーションの概要 今回利用するサンプルアプリケーションは、技術ブログサイトをイメージして作成しました。4つのサービスに分かれており、それぞれ「Article」「AccessCount」「Rank」「WebSite」と呼びます。 アプリケーションのソースコードとデプロイ用のマニフェストはGitLab.comの以下のプロジェクトで公開されています。 https://gitlab.com/creationline/thinkit-kubernetes-sample1 WebSiteサービス:エンドユーザ向けのWebサイトを提供。記事の一覧と各記事のページが閲覧でき、前日のアクセスランキングがサイドバーに表示される。 Articleサービス:ブログ記事の一覧と取得、作成
こんにちは。インフラエンジニアの北野です。 kustomizeを使用する機会がありましたので、そこで得た知見を紹介したいと思います。 kustomizeを使ってIngressのマニフェストを管理しようとしたのですが、[patchesStrategicMerge:]では定義を想定通り生成できない事態に陥ったので、原因と対応方法について紹介します。 patchesStrategicMergeでの上書きは定義が消えるkustomizeでは、kubernetesと同じjson形式で記述できるpatchesStrategicMergeを使用することを基本的には推奨しますが、patchesStrategicMergeでは、Ingressの定義を想定通り生成できません。 何故なら、Ingressの定義のspec.rulesは配列の構造体となっており、一意となる名前も存在しないからです。そのため、spec
こんにちは。テクノロジー本部バックエンド開発グループの山下です。 この記事は キャディ 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: - [email protected]:github.com/argoproj/argo-cd.git/manifests/crds?ref=v1.1.2 - [email protected]:github.com/argoproj/argo-cd.git/manifests
はじめに 実務において、kubernetesのマニフェスト作成(管理)の方法としてHelm or Kustomizeという選択肢がとられている。 ここでは、クライアント組織への導入したときの話をしたいと思う。 クライアント組織の要求事項と特性を整理した上で、どちら(または同時使用)が適切か判断するための調査を行う Helm : https://helm.sh/ Kustomize : https://kustomize.io/ TL;DR 個人的にはHelmの使用を推奨したい アプリケーション / インフラ / SREと多くのレイヤーの人が関わる組織統制を考慮したときに、Helmを使用した方がバランスの取れた運用に近づくのではないか 調査 背景 大規模な組織であるクライアント組織では、開発に際して日々、多くのステークホルダーが関わっている その中で、開発組織や技術レベルに対して統制をとるこ
Kubernetes v1.21 での変更 Kustomize v2.1.0 での変更 Go モジュール トップレベルの go.mod ファイルで依存関係を定義するように変更されたようです。 kubectl や kubebuilder、kustomize などで使用するためとなります。 Resource ordering 要望の多かったリソースの読み取り時の深さの優先順位を保持するように変更。 kustomize のファイルを変更することでリソースの順序を制御できるようになったので、ユーザー定義のプラグインを特定の順番で実行できるようになりました。 この機能自体は何もしなくても有効になるようです。 ビルドコマンドで、--reorder フラグに legacy と none の値を指定できるようになりました(デフォルト値は legacy) generator や transformer の仕
概要 最近、GKEの導入を進めており、GKEへのデプロイは、Cloud Buildから行うようにしています。 Manifestの管理は、Kustomizeを活用しています。 よく課題となるが、GCPのサービスアカウントといった秘匿性のある情報の管理です。 例えば、GKE上のコンテナからCloud SQL Proxy経由でCloud SQLに接続する場合、 Cloud SQL ProxyのコンテナにGCPのサービスアカウントを食わせる必要があると思います。 参考:https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/blob/master/cloudsql/mysql_wordpress_deployment.yaml#L49 このサービスアカウントは、KMSで暗号化することでGitHubでも管理できるようにしていま
Kubernetesのマニフェストを書いていくと、環境(本番やStagingなど)ごとに重複するコードが出てきます。 そのため環境差分だけどこかに切り出したいなーと思うことがあるでしょう。 そういったときに使えるのがKustomizeというツールです。 今回はKustomizeでできることを 自分が知り限りの範囲で列挙 していきます。(適宜更新していきます。) インストール方法は公式ドキュメントをご覧ください。 今回ここでご紹介する機能以外にも機能があるので 興味がありましたらドキュメントをご覧ください。 環境ごとにイメージのタグを変える 例えば nginx というコンテナイメージがあるとして 本番では v1.8.0、Stagingでは v1.9.0 をデプロイしたいとします。 普通にマニフェストを書くと、イメージのタグが違うだけのDeploymentのマニフェストが2つできて無駄です。
直面した問題 manifest管理にkustomizeを利用した際、ArgoCDのargocd-repo-serverがいきなり再起動(おそらくOutOfMemoryError)したり、 ArgoCD上のApplicationのStatusがUnknownになったり、今まで発生しなかった問題が発生した。 問題① 事象 ArgoCDはkustomizeもサポートしているのかぁと感心していると、突然argocd-repo-serverが再起動! $ kubectl get pod -n argocd -w NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10h argocd-applicationset-controller-7796bb8958-2jmvg 1/1 Running 0 1
Kustomize で Helm をデプロイできる helmCharts について紹介します。 私の環境の Helm については ArgoCD の Application に inline で記載していて、Kustomize の様にマニフェストの YAML で管理できてい状態でした。そのため Helm Charts に変更しようと考えていましたが、 Kustomize と Helm Charts では管理の仕方が異なるのでどちらかに寄せたいなと考えている最中でした。 Kustomize の helmCharts を使うことで Kustomize のディレクトリ構成と同じようにに Helm を管理できマニフェストの見通しが良くなりました。 モチベーション Helm については ArgoCD の Application に inline で管理していたが Kustomize と同じように He
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く