Kubernetes は、クラスターのクラウドへのコンテナーのデプロイに関するすべてのようです。触れていないように見えるのは、開発環境とステージング環境(など)です。
開発中は、いくつかの重要な変更を加えて、本番環境に可能な限り近づけたいと考えています。
同様に、非パブリック環境で継続的インテグレーションを行うこともできます。
Kubernetesはこのような種類の開発環境をサポートしていますか?それとも、実稼働中も機能することを期待して構築する必要があるものですか?
更新(2016-07-15)
Kubernetes 1.3のリリースでは、開発用にローカルマシンでKubernetesを実行するための Minikube が推奨される方法になりました。
Dockerを介してローカルでKubernetes を実行できます。ノードを実行したら、単純なWebサーバーを備えたポッドを起動し、ホストマシンからボリュームをマウントできます。 Webサーバーにアクセスすると、ボリュームから読み取り、ローカルディスク上のファイルを変更した場合、最新バージョンを提供できます。
これを行うためのツールに取り組んでいます。基本的な考え方は、リモートKubernetesクラスター(実質的にステージング環境)があり、その後ローカルでコードを実行すると、リモートクラスターにプロキシされることです。透過的なネットワークアクセス、コピーされた環境変数、ボリュームへのアクセス...をリモート環境に可能な限り近づけますが、コードはローカルで完全に制御されます。
たとえば、ライブ開発を行うことができます。 http://telepresence.io のドキュメント
一種の「ホットリロード」は追加する予定ですが、今日ほど簡単ではありません。ただし、冒険心がある場合は、rsyncをdocker exec、kubectl exec、またはosc exec(すべてほぼ同じことを行います)を使用して、ローカルディレクトリが変更されるたびにローカルディレクトリをコンテナに同期できます。次のようにrubeをkubectlまたはosc execで使用できます。
# rsync using osc as netcat
$ rsync -av -e 'osc exec -ip test -- /bin/bash' mylocalfolder/ /tmp/remote/folder
Skaffold で始めたばかりです
コードの変更をローカルクラスターに自動的に適用すると非常に便利です。
ローカルクラスターを展開するための最良の方法は、MinikubeまたはMacおよびWindows用のDockerのみで、どちらにもKubernetesインターフェイスが含まれています。
別の素晴らしい出発点はこれです Vagrant setup 、esp。ホストOSがWindowsの場合。明らかな利点は
欠点-多くのRAMが必要であり、VirtualBoxはVirtualBoxです...良くも悪くも。
利点と欠点が混在するのは、NFSを介したファイルのマッピングです。このセットアップでは、2組のRC定義を作成しました。1つはアプリケーションサーバーのドッカーイメージをダウンロードするだけです。もう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、「devstable」、stage、prod。それらの違いは
多くのbashエイリアスとオートコンプリートを作成すると非常に便利です。rec users
と入力するだけで、kubectl delete -f ... ; kubectl create -f ...
を実行できます。セットアップ全体を開始する場合は、recfo
と入力し、ダースサービスを再作成し、最新のdockerイメージを取得し、Staging envから最新のdbダンプをインポートして、スペースを節約するために古いDockerファイルをクリーンアップします。
ホストマシンからボリュームをマウントする方法については、 https://github.com/kubernetes/kubernetes/issues/12278 を参照してください。
docker run -v hostPath:ContainerPath
ニースのローカル開発フィードバックループを持つことは、Kubernetesエコシステムの急速な開発のトピックです。
この質問を分解すると、この目標をうまくサポートできると思うツールがいくつかあります。
Docker for Mac Kubernetes ( Docker Desktop は一般的なクロスプラットフォーム名です)は、ローカル開発に最適なオプションを提供します。仮想化には、 HyperKit を使用します。これは、VirtualBoxの代わりにmacOSのネイティブHypervisorフレームワーク上に構築されます。
Kubernetes機能は、最初に 2018年1月 でEdgeチャンネルのベータ版としてリリースされ、 2018年4月 で認定Kubernetesになり、安定版に卒業してから長い道のりを歩んできましたチャンネル 2018年7月 。
私の経験では、特にmacOSで、特にRBAC、Helm、ハイパーバイザー、プライベートレジストリなどの問題に関しては、Minikubeよりも作業がはるかに簡単です。
コードを配布し、ローカルで更新をプルする限り、 Helm は最も一般的なオプションの1つです。 CI/CDを介してアプリケーションをHelmチャートとして公開できます(また、それらが参照する基礎となるDockerイメージも)。次に、これらのチャートをHelmチャートレジストリからローカルに取得し、ローカルクラスターでアップグレードできます。
Azure Draft のようなツールを使用して、単純なローカルデプロイを行い、ビルドパックのような共通言語テンプレートから基本的なHelmチャートを生成して、パズルのピースを自動化することもできます。
Skaffold はAzure Draftに似ていますが、より成熟しており、範囲がはるかに広く、Googleによって作成されています。非常にプラグ可能なアーキテクチャを備えています。将来的には、Kubernetesのローカルアプリ開発にもっと多くの人が使用すると思います。
Reactを使用したことがある場合、Skaffoldを「 Create React App for Kubernetes」と考えています。
Docker Compose は、Kubernetesとは無関係ですが、一部の企業が本番環境で実行するKubernetes環境に類似したシンプルで簡単で移植可能なローカル開発環境を提供するために使用する1つの代替手段です。ただし、このルートを使用するということは、本番環境とローカル開発のセットアップを分岐させることを意味します。
Kompose は、Docker ComposeからKubernetesへのコンバーターです。これは、既にローカルでコンテナのコレクションとしてアプリケーションを実行しているユーザーにとって便利なパスになる可能性があります。
Kubernetesでの構成 は、 最近オープンソース化された (2018年12月)Dockerからの提供で、カスタムコントローラーを介してDocker ComposeファイルをKubernetesクラスターに直接展開できます。
Kubespary は、ローカルクラスターのセットアップに役立ちます。ほとんどの場合、ローカルマシンでvagrantベースのクラスターを使用しました。
Kubespray configuration これらの変数を調整して、目的のkubernetesバージョンにすることができます。
https://github.com/okteto/okteto および Okteto Cloud をご覧ください。価値提案は、ホットリロード、インクリメンタルビルド、デバッガーを使用できるdockerの前にローカルで作業するよりも古典的な開発経験を持つことですが、ローカルの変更はすべてリモートコンテナーに即座に同期されます。リモートコンテナを使用すると、クラウドの速度にアクセスでき、新しいレベルのコラボレーションが可能になり、本番のような環境で開発が統合されます。また、ローカルインストールの負担がなくなります。
ロバートによって以前に指定されたように、minikubeは行く方法です。
ここ は、minikubeを使い始めるためのクイックガイドです。一般的な手順は次のとおりです。
Minikubeをインストール
Minikubeクラスターを作成します(Windowsの場合はVirtualBoxまたはDocker for MacまたはHyperVの仮想マシンで)
アプリケーションファイルのDockerイメージを作成します(Dockerfileを使用)
展開を作成してイメージを実行します
アクセスできるように、アプリケーションを公開するサービスを作成します。
開発目的で「portainer」を使用できます。コマンドまたはyamlマニフェストを覚える必要はありません。
minkube
を使用することの欠点は、マシン上に別の仮想マシンを生成することです。また、最新のminikube
バージョンでは、システムに2 CPUと2GBのRAMが最低限必要です。これにより、十分なリソースを備えたシステムがない場合はかなり重くなります。
これが、私がkubernetesでの開発のためにmicrok8s
に切り替えた理由です。 microk8s
は、DNS、ローカルストレージ、ダッシュボード、istio、イングレスなど、マイクロサービスのテストに必要なすべてをサポートしています。
ローカル環境から隔離された高速で軽量なアップストリームKubernetesインストールになるように設計されています。この分離は、Kubernetes、Docker.io、iptables、およびCNIのすべてのバイナリを単一のスナップパッケージにパッケージ化することで実現されます。
単一ノードkubernetesクラスターは、1つのコマンドで1分以内にインストールできます。
snap install microk8s --classic
システムでdockerまたはkubeletサービスが実行されていないことを確認してください。 Microk8s
は、必要なすべてのサービスを自動的にインストールします。
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
リモートkubernetesクラスターを使用して、このクラスターに接続するようにローカルマシンを構成できます。 kubectl cpコマンドを使用して、開発中のコードのホットリロードのために実行中のポッドにコードをコピーします。