バックエンド

Kubernetesとは何ですか？コンテナ化と展開のガイド

少し前に、私たちはモノリスWebアプリケーションを使用しました。巨大なコードベースは、新しい機能や機能で成長し、巨大で動きが遅く、管理が難しい巨人になりました。現在、開発者、アーキテクト、DevOpsの専門家の数が増えており、巨大なモノリスよりもマイクロサービスを使用する方がよいという意見が出ています。通常、マイクロサービスベースのアーキテクチャを使用するということは、モノリスをフロントエンドアプリとバックエンドアプリ（API）の少なくとも2つのアプリケーションに分割することを意味します。マイクロサービスを使用することを決定した後、疑問が生じます。どのような環境でマイクロサービスを実行するのが良いですか？サービスを安定させ、管理と展開を容易にするために何を選択する必要がありますか？簡単な答えは次のとおりです。Dockerを使用してください。

この記事では、コンテナを紹介し、Kubernetesについて説明し、CircleCIを使用してアプリをコンテナ化してKubernetesクラスタにデプロイする方法を説明します。

Docker？ Dockerとは何ですか？

Dockerは、DevOps（およびあなたの生活）をより簡単にするために設計されたツールです。 Dockerを使用すると、開発者はでアプリケーションを作成、デプロイ、実行できます。 コンテナ 。コンテナーを使用すると、開発者は、ライブラリやその他の依存関係など、必要なすべてのパーツを含むアプリケーションをパッケージ化し、すべてを1つのパッケージとして出荷できます。

ホストにデプロイされたアプリとコンテナーにパッケージ化されたアプリの比較

開発者はコンテナを使用して、イメージを任意のOSに簡単に（再）デプロイできます。 Dockerをインストールしてコマンドを実行するだけで、アプリケーションが稼働します。ああ、ホストOSの新しいバージョンのライブラリとの不整合について心配する必要はありません。さらに、同じホストでより多くのコンテナーを起動できます。同じアプリですか、それとも別のアプリですか。関係ありません。

Dockerは素晴らしいツールのようです。しかし、コンテナをどこでどのように起動する必要がありますか？

コンテナを実行する方法と場所には多くのオプションがあります。AWSElasticContainerService（AWS Fargateまたは水平および垂直の自動スケーリングを備えたリザーブドインスタンス）。 AzureまたはGoogleCloudで事前定義されたDockerイメージを使用するクラウドインスタンス（テンプレート、インスタンスグループ、自動スケーリングを使用）。 Dockerを使用して独自のサーバー上で;または、もちろん、Kubernetes！ Kubernetesは、2014年にGoogleのエンジニアによって仮想化とコンテナ用に特別に作成されました。

第11章の提出とは

Kubernetes？それは何ですか？

Kubernetesは、コンテナの実行、コンテナの管理、デプロイの自動化、デプロイのスケーリング、入力の作成と構成、ステートレスまたはステートフルアプリケーションのデプロイなどを可能にするオープンソースシステムです。基本的に、1つ以上のインスタンスを起動し、Kubernetesをインストールして、それらをKubernetesクラスターとして操作できます。次に、KubernetesクラスターのAPIエンドポイントを取得し、kubectlを構成します（Kubernetesクラスターを管理するためのツール）そしてKubernetesはすぐに利用できます。

では、なぜそれを使用する必要があるのでしょうか。

Kubernetesを使用すると、計算リソースを最大限に活用できます。 Kubernetesを使用すると、Kubernetesが帆を埋めて、船（インフラストラクチャ）のキャプテンになります。 Kubernetesを使用すると、サービスはHAになります。そして最も重要なことは、Kubernetesを使用すると、かなりのお金を節約できます。

有望に見えます！特にそれがお金を節約するなら！もっと話しましょう！

Kubernetesは日々人気を集めています。さらに深く掘り下げて、ボンネットの下にあるものを調べてみましょう。

フードの下：Kubernetesとは何ですか？

Kubernetesとは何ですか？内部でKubernetesを構成するコンポーネント

Kubernetesを構成するコンポーネント

Kubernetesはシステム全体の名前ですが、あなたの車のように、Kubernetesを機能させるために完全に調和して機能する小さな部品がたくさんあります。それらが何であるかを学びましょう。

マスターノード– Kubernetesクラスター全体のコントロールパネル。マスターのコンポーネントは、クラスター内の任意のノードで実行できます。主なコンポーネントは次のとおりです。

APIサーバー： すべてのRESTコマンドのエントリポイント。ユーザーがアクセスできるマスターノードの唯一のコンポーネントです。
データストア： Kubernetesクラスターで使用される強力で一貫性のある高可用性のKey-Valueストレージ。
スケジューラー： 新しく作成されたポッドを監視し、それらをノードに割り当てます。ノードへのポッドとサービスのデプロイは、スケジューラーが原因で発生します。
コントローラーマネージャー： クラスター内のルーチンタスクを処理するすべてのコントローラーを実行します。
ワーカーノード： プライマリノードエージェント。ミニオンノードとも呼ばれます。ポッドはここで実行されます。ワーカーノードには、コンテナー間のネットワークを管理し、マスターノードと通信し、スケジュールされたコンテナーにリソースを割り当てるために必要なすべてのサービスが含まれています。
Docker： 各ワーカーノードで実行され、イメージと開始コンテナーをダウンロードします。
クベレット： ポッドの状態を監視し、コンテナーが稼働していることを確認します。また、データストアと通信して、サービスに関する情報を取得し、新しく作成されたサービスに関する詳細を書き込みます。
キューバプロキシ： 単一のワーカーノード上のサービスのネットワークプロキシとロードバランサー。トラフィックルーティングを担当します。
Kubectl： ユーザーがKubernetesAPIサーバーと通信するためのCLIツール。

ポッドとサービスとは何ですか？

ポッド Kubernetesクラスターの最小単位であり、巨大な建物の壁にある1つのレンガのようなものです。ポッドは、一緒に実行する必要があり、リソース（Linux名前空間、cgroup、IPアドレス）を共有できるコンテナーのセットです。ポッドは長生きすることを目的としていません。

サービス は、多数のポッドの上に抽象化されたものであり、通常、他のサービスが仮想IPアドレスを介してポッドと通信するために上にプロキシが必要です。

簡単な展開例

さまざまな利害関係者がKubernetesを利用したアプリとどのようにやり取りするか

Kubernetesを実行するためのプラットフォームとして、単純なRuby onRailsアプリケーションとGKEを使用します。実際には、AWSまたはAzureでKubernetesを使用したり、独自のハードウェアでクラスターを作成したり、minikubeを使用してKubernetesをローカルで実行したりできます。このページ。

このアプリのソースファイルは次の場所にあります。このGitHubリポジトリ。

新しいRailsアプリを作成するには、以下を実行します。

rails new blog

config/database.yml fileで本番用にMySQL接続を構成するには：

ソリューションを使用した資本予算の例

production: adapter: mysql2 encoding: utf8 pool: 5 port: 3306 database: host: 127.0.0.1 username: password:

Articleモデル、コントローラー、ビュー、および移行を作成するには、以下を実行します。

rails g scaffold Article title:string description:text

Gemfileにgemを追加するには：

gem 'mysql2', '= 0.4.4' gem 'health_check'

Dockerイメージを作成するには、 Dockerfile そして実行します：

docker build -t REPO_NAME/IMAGE_NAME:TAG . && docker push REPO_NAME/IMAGE_NAME:TAG

Kubernetesクラスターを作成するときが来ました。 GKEページを開き、Kubernetesクラスターを作成します。クラスターが作成されたら、[接続ボタン]をクリックしてコマンドをコピーします。gCloudCLIツールがあることを確認してください（方法）および kubectl インストールおよび構成済み。コピーしたコマンドをPCで実行し、Kubernetesクラスターへの接続を確認します。 kubectl cluster-infoを実行します。

分析のためにTwitterデータを取得する方法

アプリをk8sクラスターにデプロイする準備が整いました。 MySQLデータベースを作成しましょう。 gCloudコンソールでSQLページを開き、アプリケーションのMySQLDBインスタンスを作成します。インスタンスの準備ができたら、ユーザーとDBを作成し、 インスタンス接続名 。

また、でサービスアカウントキーを作成する必要があります APIとサービス サイドカーコンテナからMySQLDBにアクセスするためのページ。あなたはそのプロセスに関するより多くの情報を見つけることができますここに。ダウンロードしたファイルの名前をservice-account.jsonに変更します。後でそのファイルに戻ります。

アプリケーションをKubernetesにデプロイする準備ができましたが、最初に作成する必要があります秘密アプリケーションの場合-機密データを保存するために作成されたKubernetesの秘密オブジェクト。以前にダウンロードしたservice-account.jsonをアップロードしますファイル：

kubectl create secret generic mysql-instance-credentials --from-file=credentials.json=service-account.json

アプリケーションのシークレットを作成します。

kubectl create secret generic simple-app-secrets  --from-literal=username=$MYSQL_PASSWORD  --from-literal=password=$MYSQL_PASSWORD  --from-literal=database-name=$MYSQL_DB_NAME  --from-literal=secretkey=$SECRET_RAILS_KEY

値を置き換えるか、環境変数を自分の値に設定することを忘れないでください。

デプロイメントを作成する前に、デプロイメントファイル。 3つのファイルを1つに連結しました。最初の部分は、ポート80を公開し、ポート80から3000に到達するすべての接続を転送するサービスです。サービスには、接続を転送するポッドをサービスが認識するセレクターがあります。

ファイルの次の部分はデプロイメントです。これは、デプロイメント戦略（ポッド内で起動されるコンテナー、環境変数、リソース、プローブ、各コンテナーのマウント、およびその他の情報）を記述しています。

最後の部分は、水平ポッドオートスケーラーです。 HPA 非常にシンプルな設定があります。デプロイセクションでコンテナのリソースを設定しない場合は、 HPA 動作しないでしょう。

GKE編集ページでKubernetesクラスターの垂直オートスケーラーを設定できます。また、非常にシンプルな構成になっています。

それをGKEクラスターに出荷する時が来ました！まず、移行を実行する必要がありますジョブ。実行：

kubectl apply -f rake-tasks-job.yaml –このジョブは、CI / CDプロセスに役立ちます。

kubectl apply -f deployment.yaml –サービス、展開、およびHPAを作成します。

次に、次のコマンドを実行してポッドを確認します：kubectl get pods -w

NAME READY STATUS RESTARTS AGE sample-799bf9fd9c-86cqf 2/2 Running 0 1m sample-799bf9fd9c-887vv 2/2 Running 0 1m sample-799bf9fd9c-pkscp 2/2 Running 0 1m

それでは、アプリケーションの入力を作成しましょう。

静的IPを作成します：gcloud compute addresses create sample-ip --global
入力を作成します（ファイル）：kubectl apply -f ingress.yaml
入力が作成されていることを確認し、IPを取得します：kubectl get ingress -w
アプリケーションのドメイン/サブドメインを作成します。

CI / CD

CircleCIを使用してCI / CDパイプラインを作成しましょう。実際、CircleCIを使用してCI / CDパイプラインを作成するのは簡単ですが、このようなテストなしの迅速で汚い完全自動展開プロセスは小さなプロジェクトでは機能しますが、深刻な場合はこれを行わないでください。、新しいコードに本番環境で問題がある場合は、お金を失うことになります。そのため、堅牢な展開プロセスの設計、完全なロールアウトの前にカナリアタスクを起動する、カナリアの開始後にログのエラーを確認するなどを検討する必要があります。

現在、小規模で単純なプロジェクトがあるため、完全に自動化されたテストなしのCI / CD展開プロセスを作成しましょう。まず、CircleCIをリポジトリと統合する必要があります—すべての手順を見つけることができますここに。次に、CircleCIシステムの手順を含む構成ファイルを作成する必要があります。構成とてもシンプルに見えます。主なポイントは、GitHubリポジトリに2つのブランチがあることです：masterおよびproduction。

マスターブランチ 開発用、新しいコード用です。誰かが新しいコードをマスターブランチにプッシュすると、CircleCIはマスターブランチのワークフロー（コードのビルドとテスト）を開始します。
生産部門 新しいバージョンを実稼働環境にデプロイするためのものです。本番ブランチのワークフローは次のとおりです。新しいコードをプッシュして（またはさらに良いことに、マスターブランチから本番にPRを開いて）、新しいビルドおよびデプロイメントプロセスをトリガーします。ビルド中に、CircleCIは新しいDockerイメージを作成し、それをGCRにプッシュして、デプロイメント用の新しいロールアウトを作成します。ロールアウトが失敗した場合、CircleCIはロールバックプロセスをトリガーします。

ビルドを実行する前に、CircleCIでプロジェクトを構成する必要があります。 APIで新しいサービスアカウントを作成し、GCloudの[サービス]ページで次の役割を果たします。GCRとGKEへのフルアクセス、ダウンロードしたJSONファイルを開いてコンテンツをコピーし、CircleCIのプロジェクト設定で名前を付けて新しい環境変数を作成します。 GCLOUD_SERVICE_KEYそして、service-accountファイルの内容を値として貼り付けます。また、次のenv変数を作成する必要があります：GOOGLE_PROJECT_ID （GCloudコンソールのホームページにあります）、GOOGLE_COMPUTE_ZONE （GKEクラスターのゾーン）、およびGOOGLE_CLUSTER_NAME （GKEクラスター名）。

CircleCIでの最後のステップ（デプロイ）は次のようになります。

kubectl patch deployment sample -p '{'spec':{'template':{'spec':{'containers':[{'name':'sample','image':'gcr.io/test-d6bf8/simple:''$CIRCLE_SHA1'''}]}}}}' if ! kubectl rollout status deploy/sample; then echo 'DEPLOY FAILED, ROLLING BACK TO PREVIOUS' kubectl rollout undo deploy/sample # Deploy failed -> notify slack else echo 'Deploy succeeded, current version: ${CIRCLE_SHA1}' # Deploy succeeded -> notify slack fi deployment.extensions/sample patched Waiting for deployment 'sample' rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment 'sample' rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment 'sample' rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment 'sample' rollout to finish: 1 old replicas are pending termination... Waiting for deployment 'sample' rollout to finish: 1 old replicas are pending termination... Waiting for deployment 'sample' rollout to finish: 1 old replicas are pending termination... Waiting for deployment 'sample' rollout to finish: 2 of 3 updated replicas are available... Waiting for deployment 'sample' rollout to finish: 2 of 3 updated replicas are available... deployment 'sample' successfully rolled out Deploy succeeded, current version: 512eabb11c463c5431a1af4ed0b9ebd23597edd9

結論

新しいKubernetesクラスターを作成するプロセスはそれほど難しくないようです。そして、CI / CDプロセスは本当に素晴らしいです！

従業員計算機の総コスト

はい！ Kubernetesは素晴らしいです！ Kubernetesを使用すると、システムがより安定し、管理しやすくなり、システムのキャプテンになります。言うまでもなく、Kubernetesはシステムを少しゲーム化し、マーケティングに+100ポイントを与えます。

基本を理解したので、さらに進んで、これをより高度な構成に変えることができます。今後の記事でさらに取り上げる予定ですが、それまでの間、課題があります。クラスター内にステートフルDB（バックアップを作成するためのサイドカーポッドを含む）を配置して、アプリケーション用の堅牢なKubernetesクラスターを作成し、JenkinsをCI / CDパイプライン用に同じKubernetesクラスターを作成し、Jenkinsがビルドのスレーブとしてポッドを使用できるようにします。入力用のSSL証明書を追加/取得するには、certmanagerを使用します。 Stackdriverを使用して、アプリケーションの監視およびアラートシステムを作成します。

Kubernetesは、拡張が容易で、ベンダーロックインがなく、インスタンスの料金を支払うため、コストを節約できるという点で優れています。ただし、すべての人が Kubernetesエキスパートまたは、新しいクラスターをセットアップする時間があります。別の見方をすると、仲間のApeeScapeer Amin Shah Gilaniが、Heroku、GitLab CI、および彼がすでに理解している大量の自動化を使用して、より多くのコードを記述し、実行することを主張します。少ない操作タスク 効果的な初期展開パイプラインを構築する方法 。

関連：