kustomizeでconfigMapを取り扱うときの注意 - Qiita
configMapGeneratorの動作を考える 現在、kustomizeでConfigMapを処理する方法は2つの方法があり kustomizeのconfigMapGeneratorが若干クセのある動作をするので 軽くまとめておく tl;dr 雑に 基本的にはconfigMapGeneratorを使おう configMapの編集するたびに確実にconfigmapを違う名前にしたいのだったら configMapGeneratorを書く configMapの更新で名前が変わったら困るなら configMapもresourcesに書く 前提 kustomization.yaml deployment.yaml configmap k8s manifestとしてはdeployment + configMapという最小構成を考える 2つの方法の違いを見ていく resources の中に書いてre
kubernetes kubectlがめんどくさすぎたが既に最新版で補完機能があった話 - Qiita
追記 2016/08/03 の更新でgcloud付属のkubectlが1.3.3になった kubectlを別個に入れる必要なく利用できるようになりました。 gcloud付属のkubectl >= 1.3.0になったらまるで役に立たない情報。 tl;dr gcloud付属のkubectlにはまだcompletionがないから 最新版を持ってきてkubectlの補完機能を使って幸せになろう。 kubectl 1.3.0を[ここからDownload] (https://coreos.com/kubernetes/docs/latest/configure-kubectl.html) $ source <(kubectl completion zsh) 便利 logsでpod nameだけじゃなくて multi container podの場合、中で何が動いてるかも判定してくれる。(nginx,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
kustomizeでsecretGenerator内でcatを使うときに改行コードを気にしたくない - Qiita
Dockerを使って一瞬でMySQLのmaster-slave構成を手に入れる - Qiita
