Kubernetesは、クラスターのクラウドにコンテナーをデプロイすることについてすべてのようです。触れられていないように見えるのは、開発環境とステージング環境（など）です。

開発中は、いくつかの重要な変更を加えて、できるだけ本番環境に近づける必要があります。

• ローカルに展開されている（または、少なくとも自分だけがアクセスできる場所）
• ページの更新時に最新のソースコードを使用します（Webサイトを想定しています。理想的には、ローカルファイルの保存時にページの自動更新を行います。これは、ソースコードをマウントしてYeomanなどを使用している場合に実行できます）。

同様に、非公開環境で継続的な統合を行うこともできます。

Kubernetesはそのような種類の開発環境をサポートしていますか、それとも本番環境で引き続き機能することを期待して構築する必要がありますか？

アップデート（2016-07-15）

Kubernetes 1.3のリリースに伴い、MinikubeがローカルマシンでKubernetesを実行して開発するための推奨される方法になりました。

Dockerを介してローカルでKubernetesを実行できます。ノードを実行したら、シンプルなウェブサーバーがあり、ホストマシンからボリュームをマウントするポッドを起動できます。Webサーバーにアクセスすると、ボリュームから読み取られ、ローカルディスク上のファイルを変更した場合は、最新バージョンを提供できます。

これを行うためのツールに取り組んでいます。基本的な考え方は、リモートのKubernetesクラスター、事実上ステージング環境があり、コードをローカルで実行すると、リモートのクラスターにプロキシされるというものです。透過的なネットワークアクセス、環境変数のコピー、ボリュームへのアクセスなど、リモート環境に可能な限り近づきますが、コードはローカルで実行され、フルコントロールの下で実行されます。

たとえば、ライブ開発を行うことができます。http://telepresence.ioのドキュメント

一種の「ホットリロード」は、追加を計画しているものですが、今日ほど簡単ではありません。ただし、冒険したい場合は、rsyncをdocker exec、kubectl exec、またはosc execで使用して（すべて大まかに同じことを行います）、ローカルディレクトリが変更されるたびにコンテナーに同期します。次のように、kubectlまたはosc execでrsyncを使用できます。

# rsync using osc as netcat
$ rsync -av -e 'osc exec -ip test -- /bin/bash' mylocalfolder/ /tmp/remote/folder

もう1つのすばらしい出発点は、このVagrantセットアップ、特にです。ホストOSがWindowsの場合。明らかな利点は

• 迅速で簡単なセットアップ
• マシンを破壊/再現しやすい
• リソースに対する暗黙の制限
• 複数のノードを作成して水平スケーリングをテストする機能

欠点-大量のRAMが必要で、VirtualBoxはVirtualBoxです...良くも悪くも。

利点と欠点が混在するのは、NFSを介してファイルをマッピングすることです。このセットアップでは、2つのRC定義セットを作成しました。1つは、アプリケーションサーバーのDockerイメージをダウンロードするだけです。もう1つは、HostOS-> Vagrant-> VirtualBox-> CoreOS-> Kubernetesポッドからファイルマッピングを設定する追加の7行です。Dockerイメージのソースコードを上書きします。

これの欠点は、NFSファイルキャッシュです。これを使用すると、問題が発生します。これがないと、問題が発生します。設定を行っmount_options: 'nolock,vers=3,udp,noac'ても、キャッシュの問題は完全に解消されませんが、ほとんどの場合は機能します。コンテナで実行されたGulpタスクの一部は、ホストOSで8秒かかる場合、5分かかることがあります。良い妥協はあるようmount_options: 'nolock,vers=3,udp,ac,hard,noatime,nodiratime,acregmin=2,acdirmin=5,acregmax=15,acdirmax=15'です。

コードの自動再読み込みについては、これは言語固有ですが、PythonにはDjangoのdevserverが、Node.jsにはNodemonが使用されています。フロントエンドプロジェクトの場合、もちろんgulp + browserSync + watchなどを使用して多くのことを実行できますが、多くの開発者にとって、Apacheからサービスを提供し、従来のハードリフレッシュを実行することは難しくありません。

Kubernetes用に4セットのyamlファイルを保持しています。開発、「開発可能」、ステージ、製品。それらの違いは

• 環境を明示的に設定する環境変数（dev / stage / prod）
• レプリカの数
• devstable、stage、prodはdockerイメージを使用します
• devはdockerイメージを使用し、NFSフォルダーをそれらのソースコードでマップします。

多くのbashエイリアスとオートコンプリートを作成することは非常に便利rec usersですkubectl delete -f ... ; kubectl create -f ...。入力するだけで実行できます。セットアップ全体を開始したい場合は、と入力recfoすると、12個のサービスが再作成され、最新のDockerイメージが取得され、Staging envから最新のdbダンプがインポートされ、古いDockerファイルがクリーンアップされてスペースが節約されます。

私はスキャフォールドを始めたばかりです

コードの変更をローカルクラスターに自動的に適用すると、非常に便利です。

ローカルクラスタをデプロイするには、MinikubeまたはMacとWindowsのDockerのどちらかを使用するのが最良の方法です。どちらにもKubernetesインターフェースが含まれています。

ホストマシンからボリュームをマウントする方法については、https：//github.com/kubernetes/kubernetes/issues/12278を参照してください。

docker run -v hostPath:ContainerPath

優れたローカル開発フィードバックループを持つことは、Kubernetesエコシステムにおける迅速な開発のトピックです。

この質問を分解すると、この目標を十分にサポートすると私が信じているツールがいくつかあります。

Mac Kubernetes用Docker

Docker for Mac Kubernetes（Docker Desktopは一般的なクロスプラットフォームの名前です）は、ローカル開発のための優れたオプションを提供します。仮想化には、VirtualBoxの代わりにmacOSのネイティブハイパーバイザーフレームワーク上に構築されたHyperKitを使用します。

Kubernetes機能は、2018年1月にエッジチャネルで最初にベータ版としてリリースされ、それから長い道のりを経て、2018年4月に認定されたKubernetesとなり、2018年7月に安定したチャネルに卒業しました。

私の経験では、特にmacOSで、特にRBAC、Helm、ハイパーバイザー、プライベートレジストリなどの問題に関しては、Minikubeよりもはるかに簡単に操作できます。

兜

コードの配布とローカルでの更新のプルに関する限り、Helmは最も人気のあるオプションの1つです。アプリケーションは、CI / CDを介してHelmチャート（およびそれらが参照する基礎となるDockerイメージ）として公開できます。次に、これらのチャートをHelmチャートレジストリからローカルにプルし、ローカルクラスターでアップグレードできます。

Azureドラフト

Azure Draftなどのツールを使用して、単純なローカルデプロイを行い、ビルドパックのような共通言語テンプレートから基本的なHelmチャートを生成して、パズルのピースを自動化することもできます。

スカフォード

SkaffoldはAzure Draftに似ていますが、より成熟しており、対象範囲ははるかに広く、Googleによって作成されています。それは非常にプラグイン可能なアーキテクチャを持っています。今後、Kubernetesのローカルアプリ開発にこれを使用する人が増えると思います。

Reactを使用したことがあれば、Skaffoldは「Kubernetes用のReactアプリを作成する」と考えています。

KubernetesでのKomposeまたはCompose

Docker Composeは、Kubernetesとは関係ありませんが、本番環境で稼働するKubernetes環境に類似した、シンプルで簡単な移植可能なローカル開発環境を提供するために一部の企業が使用する1つの代替手段です。ただし、このルートに進むことは、本番環境とローカル開発の設定を分岐させることを意味します。

Komposeは、Docker ComposeからKubernetesへのコンバーターです。これは、アプリケーションをローカルでコンテナーのコレクションとして既に実行しているユーザーにとって便利な方法です。

Compose on Kubernetesは、最近オープンソース化された（2018年12月）Dockerの提供物で、カスタムコントローラーを介してDocker Composeファイルを直接Kubernetesクラスターにデプロイできます。

Kubesparyは、ローカルクラスタの設定に役立ちます。ほとんどの場合、私はローカルマシンでvagrantベースのクラスターを使用しました。

Kubesprayの構成 これらの変数を調整して、目的のkubernetesバージョンを作成できます。

を使用する場合の欠点minkubeは、マシン上に別の仮想マシンが生成されることです。また、最新minikubeバージョンでは、最低2つのCPUと2GBのRAMをシステムから使用する必要があるため、十分なリソースを備えたシステムがない場合は、非常に重くなります。

これが私がmicrok8skubernetesでの開発に切り替えた理由であり、私はそれが大好きです。microk8sは、DNS、ローカルストレージ、ダッシュボード、istio、イングレスなど、マイクロサービスのテストに必要なすべてをサポートしています。

ローカル環境から分離された高速で軽量のアップストリームKubernetesインストールになるように設計されています。この分離は、Kubernetes、Docker.io、iptables、およびCNIのすべてのバイナリを単一のスナップパッケージにパッケージ化することで実現されます。

単一ノードのkubernetesクラスターは、1つのコマンドで1分以内にインストールできます。

snap install microk8s --classic

システムでdockerまたはkubeletサービスが実行されていないことを確認してください。Microk8s必要なすべてのサービスが自動的にインストールされます。

で他のアドオンを有効にするには、次のリンクをご覧くださいmicrok8s。

https://github.com/ubuntu/microk8s

次の方法でステータスを確認できます。

velotio@velotio-ThinkPad-E470:~/PycharmProjects/k8sClient$ microk8s.status
microk8s is running
addons:
ingress: disabled
dns: disabled
metrics-server: disabled
istio: disabled
gpu: disabled
storage: disabled
dashboard: disabled
registry: disabled

https://github.com/okteto/oktetoおよびOkteto Cloudをご覧ください。価値ある提案は、Dockerの前にローカルで作業するよりも古典的な開発体験をすることです。ホットリロード、インクリメンタルビルド、デバッガーを使用できますが、ローカルの変更はすべてリモートコンテナーにすぐに同期されます。リモートコンテナーを使用すると、クラウドの速度にアクセスでき、新しいレベルのコラボレーションが可能になり、開発を本番環境のような環境に統合できます。また、ローカルインストールの負担もなくなります。

以前にRobertが指定したように、minikubeが適しています。

ここで minikubeを始めるためのクイックガイドです。一般的な手順は次のとおりです。

• minikubeをインストールする

• minikubeクラスターを作成します（VirtualBoxまたはMac用のDocker、Windowsの場合はHyperVの仮想マシン）。

• アプリケーションファイルのDockerイメージを作成する（Dockerfileを使用）

• デプロイを作成してイメージを実行する

• アクセスできるようにアプリケーションを公開するサービスを作成します。