はじめに 昨今コンテナ仮想化、特にDockerの勢いはますます大きくなりつつあります。Dockerの持つ簡便で高速なデプロイや、HashiCorp製品をはじめとしたDevOpsツールとの親和性の高さ、イメージの構築・配布・共有に関する可視性・追跡性の高さなどに魅力を感じている方が多いことから、Dockerを開発者のツールとしてだけではなく、組織で共有するインフラとして採用していく流れが主流になりつつあります。その際にあらわれてくる諸々の課題を解決するツールの発展が今急速に進んでいます。 今回から数回に渡って、RancherというDocker管理ソフトウェアをご紹介します。Rancherは従来開発者の手元のPCや単一のホストで実験的に利用されることの多かったDockerコンテナを、本格的な実運用インフラのレベルまで向上させることを目標としたソフトウェアです。 第一回となる今回は、Ranche
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事について 簡易検証の必要があり、手元のWindows端末に用意したk8s cluster環境(vagrant)にhelmのtillerをセットアップした手順を整理したものです。(Qiitaで記事を作成する練習もかねてます。) 前提 Helm v2.9.1 ※検証作業時には2.10はRC版のみだったため2.9.1を利用。 ※kubernetes cluster環境はインターネットに接続な構成。 参考文献 RBACが有効なGKEでHelmを使う https://www.sambaiz.net/article/160/ Helm Do
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 の動作を確認するため、複数の nginx インスタンスを手元の Mac に立ち上げてみます。 Docker for Mac で Kubernetes を有効にする Docker アイコン > Preferences > Kubernetes > Enable Kubernetes > ラジオボタンを Kubernetes にする Apply Install これで Kubernetes の CLI である kubectl もインストールされます。 Kubernetes の状態を知るには kubectl get を使いますが、そもそもどんなリソースがあるか知らないと使えません。ブラウザで情報を閲覧出来る Kubernetes Dashboard をインストールすると便利です。 $ kubectl version Client Version: version.Info{
これはなに タイトルのとおり、Kubernetesクラスター外のIPアドレスに対してルーティングしてくれるServiceオブジェクトを作る方法を書きます。 KubernetesのServiceにはExternalNameというタイプがありまして、これを使うと、外部のサービスにDNS名でアクセスすることができます。これに対して、このエントリーでやりたいことは、IPアドレスを直に指定してアクセスするということです。 そんなことやりたいときなんてあります?と思われるかもしれませんが、自分の場合たまたまあったんです…。 TL;DR Selectorの無いClusterIPタイプのServiceを作って、さらにEndpointオブジェクトでアクセス先のサービスのIPを指定すれば良いです。 (もっといいやり方があったら教えてください) 2018/09/06 追記: ExternalNameでもIPを扱
はじめに Azureポータル画面からAKSのkubernetesクラスターを作成しました。手順を共有します。 作成前リソース確認 クラスター作成に伴って何が自動的に作成されることを確認するために、作成する前に一度すべてのリソースを確認します。 ※これは必須手順ではありません。 Azureポータルにログインします。 左側の「すべてのリソース」をクリックし、Azureにすでに存在されているすべてのリソースが表示されます。(コンテナーレジストリのみ) クラスター作成 ポータル画面左側の「すべてのサービス」をクリックし、「計算」カテゴリの「Kubernetesサービス」をクリックします。 Kubernetesサービス一覧に、まだ何も存在しません。「追加」ボタンをクリックします。 基本情報を入力します。 項目 入力値 説明
How do you find the cluster/service CIDR for a Kubernetes cluster, once it is already running? I know for Minikube, it is 10.0.0.1/24. For GKE, you can find out via gcloud container clusters describe XXXXXXX --zone=XXXXXX | grep -e clusterIpv4Cidr -e servicesIpv4Cidr But how do you find out on a generic Kubernetes cluster, particularly via kubectl?
シナリオ(実際に手元で必要になった状況) オープンソースのツールをhelmチャートを使用して導入しようとしている。helmを使用して導入したところいくつかの Persistent Volume Claim(PVC)が同じような条件(サイズ、ポリシー)で作られた。ただ対応するPVが存在していないので、バインド待ちの状況となっている。 namespace pvc-namespace persistent volume claim pvc-a : 10 GiB, RWO pvc-b : 10 GiB, RWO Persistent Volume(PV)を作成したいが普通に作ってしまうとどのPVCにバインドされるかわからない。あらかじめバインド対象のPVCを明示する形でPVを作成したい。 方法 Persistent Volumeを作成するときの定義ファイルにclaimRef属性を追加して、対象の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く