エンタープライズレベルのコンテナクラウドプラットフォームの実装と実践

エンタープライズレベルのコンテナクラウドプラットフォームの実装と実践

IT 業界の発展と変化に伴い、IT アプリケーションの基盤となるサポートも、メインフレーム、ミニコンピュータ、PC サーバー、仮想化テクノロジから今日のコンテナ化へと進化してきました。アジャイル開発、継続的デプロイメント、多様化したテクノロジー スタックの継続的な反復に基づいて、従来の基盤アーキテクチャはますます複雑になり、運用および保守管理では対応できなくなってきています。運用保守担当者は次第に終わりのない「消火」運用保守モードに陥っていった。

コンテナ技術の出現により、これらすべてが根本的に変化しました。コンテナの効率的なオーケストレーションと管理は、コンテナの無限の栄光を実現するための前提条件です。長年の開発を経て、Kubernetes は業界の事実上の標準になりました。 Kubernetes をうまく活用してエンタープライズ開発を促進する方法は、多くの企業、特にスタートアップ企業にとって無視できない難しい問題となっています。

この記事では、Amazon EKS を使用してエンタープライズ レベルのコンテナ クラウド プラットフォームを構築する方法を紹介します。一連の実践的な操作を通じて、Amazon Web Services が企業にコンテナ化されたアプリケーションを効率的に導入および管理するのにどのように役立つかを直感的に理解できます。

1. 従来のアプリケーションアーキテクチャのコンテナ化への道

「伝統的」という言葉を聞くと、まず頭に浮かぶのは「後進的」で「保守的」ですが、現実には、従来のアプリケーションの大部分は、依然としてこれらの従来のアーキテクチャ上で問題なく動作しています。サービス対象のオブジェクトは、特定の要因により、システム全体のリソースに対する需要に大きな変化が生じることはなく、システム機能の反復的な開発に対する頻繁な要求も発生しません。

しかし、インターネット、ビッグデータ、AIなどの技術の発展により、あらゆる産業が情報化からインテリジェンス化への変革に取り組んでいます。変革プロセスにおいて、アプリケーション シナリオの増加と頻繁な反復開発により、「従来の」アーキテクチャはますます大規模になりました。その結果、運用・保守担当者は「火消し」に追われ、システムサービスはますます不安定になり、システムコストは制御不能にまで高騰しました。

これらの問題を根本的に、そして完全に解決するにはどうすればいいでしょうか?コンテナ化/マイクロサービスは、多くの企業が大きな期待を寄せている方向性です。

コンテナ化は本当に効果的でしょうか?

次の写真を例に挙げてみましょう。これは非常に一般的なアーキテクチャです。 Tomcat は複数のサーバーに展開され、リバース プロキシ ソフトウェア (Nginx) を使用して各 Tomcat にリクエストを均等に分散します。 11.11 のプロモーションにより、既存の 3 台の Tomcat を 10 台に拡張する必要がある場合、運用および保守担当者はどのようなタスクを完了する必要がありますか? (サーバーのハードウェアが準備できていることを前提とします)

従来のシステムを拡張する手順:

  1. OSをインストールし、セキュリティと権限を設定する
  2. IPを割り当ててインターネットに接続する
  3. Tomcatをデプロイする
  4. 上記の手順を7回繰り返します

容量拡張を 1 回行うだけでも、経験豊富な運用および保守担当者が数時間を費やして完了する必要があります。これを 100 ノードに拡張する場合、ワークロードは指数関数的に増加します。

コンテナ化されたシステムを拡張する手順:

この作業にコンテナ化技術を使用すれば、多くの人的資源を節約できます。

1. OSをインストールし、Kubernetesで管理する

2. 1つのコマンドで数秒で拡張が完了します

  1. kubectl スケール rc tomcat --replicas= 10

3. 終了

単純な比較から、コンテナ化技術は、リソース割り当て、システムの安定性（自己修復）、運用保守管理の面で企業のコストと運用保守のプレッシャーを効果的に削減し、企業が技術的な俊敏性と進歩を維持できることがわかります。

2. コンテナ化されたアプリケーションのシナリオ

これまで、企業にとってのコンテナ化の価値について説明してきました。次に、コンテナ化に適したシナリオを分析していきます。

コンテナ化の重要な特徴は、軽量かつステートレスであることです。しかし、従来のエンタープライズ アプリケーション ソフトウェアは、多くのビジネス モジュールを搭載し、機能プロセスが複雑であるため、コンテナ化変換には適していません。どのような特定のアプリケーション シナリオがより適していますか?主に以下のシナリオが含まれます（もちろん、これらは一般的な状況のほんの一部です。軽量でステートレスな特性を満たすビジネスシナリオでは、コンテナ化技術を試すことができます）

2.1 アプリケーションのパッケージ化

2.2 マルチバージョンハイブリッド展開

2.3 アップグレードのロールバック

2.4 マルチテナントリソースの分離

2.5 内部開発環境

これまで、Docker に代表されるコンテナ化のさまざまな利点について説明してきましたが、実際の運用環境では、企業が Docker を通じてコン​​テナ化を実装するだけでは、高可用性、柔軟な拡張、高い同時実行性などのシナリオの要件を満たすことはできません。 Kubernetes の登場により、Docker を本番環境で大規模に使用できるようになりました。 Kubernetes は、アプリケーションの展開、計画、更新、保守のためのメカニズムを提供し、コンテナ化されたアプリケーションの展開と管理をよりシンプルかつ効率的にします。

Kubernetes の機能:

  • 移植性: パブリッククラウド、プライベートクラウド、ハイブリッドクラウド、マルチクラウドをサポート
  • 拡張可能: モジュール式、プラグイン式、マウント可能、組み合わせ可能
  • 自動化: 自動デプロイメント、自動再起動、自動レプリケーション、自動スケーリング/拡張

Kubernetes と Docker を組み合わせることで、エンタープライズ コンテナ化への道が容易になり、ビジネス ニーズをより迅速に満たすことができます。しかし、すべての物事には二面性があります。すべてのプロジェクトがコンテナ化に適しているわけではなく、変更によって未知の影響が生じる可能性があります。技術と生産を尊重することによってのみ、コンテナ化の道をより着実に歩むことができます。

Kubernetes は優れていますが、関連する技術的蓄積があまりない多くのスタートアップ企業や従来型企業にとって、Kubernetes の学習コストは高すぎます。企業は、高可用性、ネットワーク、コンピュータ ルーム、および基盤となるアーキテクチャのその他の側面で一連の問題に直面し、コンテナ化への道は困難に満ちています。

3. Amazon EKS は、企業がコンテナ化の変革を迅速に実現できるよう支援します

独自のコンテナ化されたプラットフォームを迅速かつ効率的に構築するにはどうすればよいでしょうか?以下の段落は、Amazon Cloud Technology 公式 Web サイトにおける Amazon EKS の紹介です。

Amazon EKS は、独自の Kubernetes コントロールプレーンやノードをインストール、運用、保守することなく、Amazon Web Services プラットフォーム上で Kubernetes を簡単に実行できるようにするマネージドサービスです。 Kubernetes は、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するためのオープンソース システムです。

Amazon EKS は、高可用性を確保するために、複数のアベイラビリティーゾーンにわたって Kubernetes コントロールプレーンインスタンスを実行します。 Amazon EKS は、異常なコントロールプレーンインスタンスを自動的に検出して置き換え、それらのインスタンスに対して自動バージョンアップグレードとパッチ適用を提供します。

Amazon EKS は、次のような多くの AWS サービスと統合して、アプリケーションのスケーラビリティとセキュリティを提供します。

  • コンテナイメージ用の Amazon ECR
  • 負荷分散のためのElastic Load Balancing
  • 認証のためのIAM
  • 分離のための Amazon VPC

Amazon EKS はオープンソースの Kubernetes ソフトウェアの最新バージョンを実行するため、Kubernetes コミュニティの既存のプラグインとツールをすべて使用できます。 Amazon EKS で実行されるアプリケーションは、オンプレミスのデータセンターで実行されているか、パブリッククラウドで実行されているかに関係なく、あらゆる標準 Kubernetes 環境で実行されるアプリケーションと完全に互換性があります。つまり、コードを変更することなく、標準の Kubernetes アプリケーションを Amazon EKS に簡単に移行できます。

4. 理論と実践を組み合わせてコンテナ化をより直感的にする

いろいろな理論について話し合った後、実際に遊んでみましょう。以下では、Amazon EKS でのコンテナ化されたデプロイメントを段階的に実行するシナリオを設計し、各ステップの技術的な詳細を紹介します。

1) Nginxを使用して3つのページを作成します: web1、web2、web3

2) 3 つの Web ページは、Amazon EKS によってサービス グループとして管理されます。

3) http 経由でアクセスし、3 つの異なるページをポーリングして効果を確認します。

注: web1、web2、web3 は実際には 1 つのビジネスである必要があります。実験効果を示すために、投票効果は別のページに表示されます。

4.1 環境整備：

4.1.1. Amazon Web Servicesアカウントが必要です

4.1.2.アカウントのリソース制限をチェックして、IGW、VPC、EIP などが十分にあることを確認します。

4.1.3. Amazon cli (eksctl を含む) をインストールし、kubectl を設定します。

4.1.3. 1. Amazon CLI のインストール:

  1.  curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
  3.  awscliv2.zip を解凍します。
  5.  sudo ./aws/インストール

インストール結果を確認する

  1. $ aws --バージョン

インストール方法参考リンク:

https://docs.aws.amazon.com/zh_cn/cli/latest/userguide/cli-chap-install.html

4.1.3.2 kubectlを構成する

  1. aws eks --region cn-northwest- 1 update-kubeconfig --name my-zhy-eks

公式設定方法リンク:

https://docs.amazonaws.cn/eks/latest/userguide/create-kubeconfig.html

4.2 Amazon EKS クラスターを作成する:

4.2.1 コマンドの作成

#コマンド、パラメータコメント

--node-type ワーカーノードタイプ

--nodes ワーカーノードの数

CLUSTER_NAME クラスター名

AWS_REGION cn-northwest-1: 寧夏リージョン; cn-north-1: 北京地域

~~~~~~~~~~~~コマンドの作成~~~~~~~~~~~·

  1.  AWS_REGION=cn-northwest- 1
  3.  AWS_DEFAULT_REGION=cn-northwest- 1
  5. クラスター名=my-zhy-eks

  1.  eksctl クラスターを作成します --name=${CLUSTER_NAME} --version 1.15 --nodes= 3 --node-type t3.medium --managed --alb-ingress-access --region=${AWS_REGION}

4.22 実行成功時の出力:

  1.  ##################
  3.  eksctl クラスターを作成します --name=${CLUSTER_NAME} --version 1.15 --nodes= 3 --node-type t3.medium --managed --alb-ingress-access --region=${AWS_REGION}
  5.  [ℹ] eksctl バージョン0.32 。 0
  7.  [ℹ] 地域 cn-northwest- 1を使用
  9. [ℹ] 可用性ゾーンを [cn-northwest-1b cn-northwest-1c cn-northwest-1a] に設定
  11. [ℹ] cn-northwest-1bのサブネット -パブリック: 192.168 。 0.0 / 19プライベート: 192.168 . 96.0 / 19
  13.  [ℹ] cn-northwest-1cのサブネット -パブリック: 192.168 。 32.0 / 19プライベート: 192.168 . 128.0 / 19
  15.  [ℹ] cn-northwest-1aのサブネット -パブリック: 192.168 。 64.0 / 19プライベート: 192.168 . 160.0 / 19
  17.  [ℹ] Kubernetesバージョン1.15を使用
  19. [ℹ] マネージドノードを使用して「cn-northwest-1」リージョンに EKS クラスター「my-zhy-eks」を作成しています
  21. [ℹ] は、クラスター自体と初期管理ノードグループ用に2つの別々のCloudFormationスタックを作成します。
  23.  [ℹ] 問題が発生した場合は、CloudFormation コンソールを確認するか、 「eksctl utils describe-stacks --region=cn-northwest-1 --cluster=my-zhy-eks」を試してください。
  25.  [ℹ] 「cn-northwest-1」のクラスター「my-zhy-eks」では CloudWatch ログは有効になりません
  27. [ℹ] 'eksctl utils update-cluster-logging --enable-types={SPECIFY-YOUR-LOG-TYPES-HERE (eg all)} --region=cn-northwest-1 --cluster=my-zhy-eks'で有効にできます
  29. [ℹ] Kubernetes API エンドポイント アクセスは、「cn-northwest-1」のクラスター「my-zhy-eks」に対してデフォルトの {publicAccess= true 、 privateAccess= false } を使用します。
  31.  [ℹ] 2 つの連続タスク: { クラスター コントロール プレーン「my-zhy-eks」を作成、 2 つの連続サブタスク: { タスクなし、管理対象ノードグループ「ng-e5146e45」を作成 } }
  33.  [ℹ] クラスター スタック「eksctl-my-zhy-eks-cluster」を構築しています
  35. [ℹ] スタック「eksctl-my-zhy-eks-cluster」をデプロイしています
  37. [ℹ] 管理対象ノードグループ スタック「eksctl-my-zhy-eks-nodegroup-ng-e5146e45」を構築しています
  39. [ℹ] スタック「eksctl-my-zhy-eks-nodegroup-ng-e5146e45」をデプロイしています
  41. [ℹ] コントロールプレーンが使用可能になるまで待機しています...
  43.  [✔] kubeconfig を「/root/.kube/config」として保存しました
  45. [ℹ] タスクなし
  47. [✔] 「my-zhy-eks」のすべての EKS クラスター リソースが作成されました
  49. [ℹ] ノードグループ「ng-e5146e45」には3 つのノードがあります
  51. [ℹ] ノード「ip-192-168-5-37.cn-northwest-1.compute.internal」が準備完了です
  53. [ℹ] ノード「ip-192-168-58-97.cn-northwest-1.compute.internal」が準備完了です
  55. [ℹ] ノード「ip-192-168-65-234.cn-northwest-1.compute.internal」が準備完了です
  57. [ℹ] 「ng-e5146e45」で少なくとも3 つのノードが準備完了になるのを待機しています
  59. [ℹ] ノードグループ「ng-e5146e45」には3 つのノードがあります
  61. [ℹ] ノード「ip-192-168-5-37.cn-northwest-1.compute.internal」が準備完了です
  63. [ℹ] ノード「ip-192-168-58-97.cn-northwest-1.compute.internal」が準備完了です
  65. [ℹ] ノード「ip-192-168-65-234.cn-northwest-1.compute.internal」が準備完了です
  67. [ℹ] kubectl コマンドは"/root/.kube/config"で動作するはずです。'kubectl get nodes' を試してください。
  69.  [✔] 「cn-northwest-1」リージョンの EKS クラスター「my-zhy-eks」が準備完了
  71. ##############

4.2.3 Eksctl を実行した後、約 10 分間待つ必要があります。このモデルの手順は非常にシンプルですが、実際には、Amazon Web Services は cloudformation を呼び出してバックグラウンドで多くの作業を実行し、それを完了します。次の図は、cloudformation のスタック手順を示しています。

画像出典: Amazon Web Servicesグローバル Web サイトのスクリーンショット

4.2.4 Amazon EKS 完了、クラウドフォーメーションステータス

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

4.2.5 ノードステータス情報の照会

  1. # kubectl ノードを取得する
  3. 名前 ステータス 役割 年齢 バージョン
  5. ip- 192 - 168 - 5 - 37 .cn-northwest- 1 .compute.internal Ready <なし> 11m v1. 15.12 -eks-31566f
  7.  ip- 192 - 168 - 58 - 97 .cn-northwest- 1 .compute.internal Ready <なし> 11m v1. 15.12 -eks-31566f
  9.  ip- 192 - 168 - 65 - 234 .cn-northwest- 1 .compute.internal Ready <なし> 11m v1. 15.12 -eks-31566f

4.2.6.クラスターノードを拡張する方法

以前、eksctl を使用して 3 ノードのクラスターを作成しました。業務の増加に伴い、容量を拡大したい場合はどうすればよいでしょうか?現在のクラスターを 10 ノードに拡張する具体的なコマンドは次のとおりです。

  1.  NODE_GROUP=$(eksctl get nodegroup --cluster ${CLUSTER_NAME} --region=${AWS_REGION} -o json | jq -r '.[].Name' )
  3.  eksctl scale nodegroup --cluster=${CLUSTER_NAME} --nodes= 10 --name=${NODE_GROUP} --region=${AWS_REGION}

結果を確認する

  1. eksctl ノードグループを取得します --cluster ${CLUSTER_NAME} --region=${AWS_REGION}
  3.  eksctl クラスターを取得する
  5. 名前 地域
  7. my-zhy-eks cn-北西- 1

4.3. Amazon ECR の使用

企業の場合、多くの画像がカスタマイズされます。 Amazon Web Services ではカスタマイズされたプライベートイメージ管理はどのように実行されますか? Amazon ECR を使用するとイメージ管理が容易になります。次の手順では、httpd イメージを使用してプライベート httpdok イメージをカスタマイズおよび生成し、Amazon ECR にアップロードする方法を示します。

4.31.まず Amazon ECR リポジトリを作成し、それを選択して「プッシュ コマンドの表示」をクリックします。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

4.3.2. 「puhs コマンドの表示」の手順に従って、ローカルで作成したイメージを Amazon ECR にアップロードします。

画像出典: Amazon Web Servicesグローバル Web サイトのスクリーンショット

具体的なコマンド手順:

  1.  # aws ecr get-login-password --region cn-northwest- 1 | docker login --username AWS --password-stdin <account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn

ローカル画像を表示

  1. # Docker イメージ
  3. リポジトリ タグ イメージ ID 作成 サイズ
  5. httpdok v1 df353399ffe4 7秒前 299MB

画像のタグ付け

  1. # docker タグ httpdok:latest <account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn/httpdok:latest

ローカル Docker イメージを表示すると、ECR 接続文字列を含む新しいイメージが表示されていることがわかります。

  1.  # Docker イメージ
  3. リポジトリ タグ イメージ ID 作成 サイズ
  5. <account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn/httpdok 最新 9028c4373343 4分前 299MB
  7.  httpdok 最新 9028c4373343 4分前 299MB

イメージをECRにプッシュする

  1. # docker push <account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn/httpdok:latest
  3. プッシュはリポジトリ [<account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn/httpdok] を参照します。

Amazon Web Services コンソールに戻ると、アップロードされた画像を確認できます。

画像出典: Amazon Web Servicesグローバル Web サイトのスクリーンショット

4.4 Amazon EKSインスタンスのデモ

Amazon EKS へのコンテナのデプロイを始めましょう。 Nginx を使用して、Amazon EKS にイメージをデプロイし、アクセスをポーリングする方法を説明します。

4.4.1. 3つのnginxポッドレプリカセットを起動する

YAMLファイルを準備する

  1. cat <<EOF > nginx-deployment.yaml
  3.  APIバージョン: アプリ/v1
  5. 種類: デプロイメント
  7. メタデータ:
  9. 名前: nginx-deployment
  11. ラベル:
  13. アプリ: nginx
  15. 仕様:
  17. レプリカ: 3
  19. セレクタ：
  21. 一致ラベル:
  23. アプリ: nginx
  25. テンプレート：
  27. メタデータ:
  29. ラベル:
  31. アプリ: nginx
  33. 仕様:
  35. コンテナ:
  37.  - 名前: nginx
  39. イメージ: nginx: 1.14 。 2
  41. ポート:
  43.  - コンテナポート: 80
  45. 終了

デプロイするには次のコマンドを実行します

  1. kubectl を適用 -f nginx-deployment.yaml

作成ステータスを確認する

  1. kubectl ポッドを取得 -o ワイド

4.4.2. LoadBalancerサービスを作成する

YAMLファイルを準備する

  1. cat <<EOF > ロードバランサー.yaml
  3.  APIバージョン: v1
  5. 種類: サービス
  7. メタデータ:
  9. 名前: nginx-service
  11. 仕様:
  13. タイプ: ロードバランサー
  15. セレクタ：
  17. アプリ: nginx
  19. ポート:
  21.  - プロトコル: TCP
  23. ポート: 80
  25. ターゲットポート: 80
  27. 終了

デプロイするには次のコマンドを実行します

  1. kubectl 作成 -f ロードバランサー.yaml

作成ステータスを確認する

  1. kubectl サービスを取得する
  3. 名前 タイプ クラスター IP 外部 IP ポート 年齢
  5. nginx-service ロードバランサー10.100 。 212.244 ae8e75d7e149044eb905b6bbff796e7e- 629951941 .cn-northwest- 1 .elb.amazonaws.com.cn 80 : 31248 /TCP 7分53秒

ウェブページの表示を監視する

  1. curl -silent ae8e75d7e149044eb905b6bbff796e7e- 629951941 .cn-northwest- 1 .elb.amazonaws.com.cn | grep タイトル
  3. <title>nginx へようこそ!</title>

この時点で、EKS 上で Nginx クラスターの使用を開始しました。しかし、負荷バランスの作業効果を示唆するために。負荷分散の効果をよりよく観察するために、次の小さな実験を続けます。

4.5.投票効果の表示

4.5.1.ポッド情報を取得する

  1. kubectl ポッドを取得する
  3. 名前 準備完了 ステータス 再起動 年齢
  5. nginx-deployment-574b87c764-92jbs 1 / 1実行中0 10h
  7.  nginx-deployment-574b87c764-hmz9t 1 / 1実行中0 10h
  9.  nginx-deployment-574b87c764-nqpmc 1 / 1実行中0 10h

次のコマンドは、ポッド内のnginx welcomeインターフェースのindex.htmlの場所を決定します。

  1.  kubectl exec -it nginx-deployment-574b87c764-92jbs -- /usr/sbin/nginx -t
  3.  kubectl exec -it nginx-deployment-574b87c764-92jbs --cat /etc/nginx/nginx.conf を実行します。
  5.  kubectl exec -it nginx-deployment-574b87c764-92jbs -- ls /usr/share/nginx/html
  7.  kubectl exec -it nginx-deployment-574b87c764-92jbs --cat /usr/share/nginx/html/index.html を実行します。
  9.  kubectl exec -it nginx-deployment-574b87c764-92jbs -- cp/usr/share/nginx/html/index.html /usr/share/nginx/html/index.html.bk

注: kubectl excel の形式は次のとおりです。

  1.  kubectl exec -it <podName> -c <containerName> -n <namespace> -- シェルコマンド

4.5.3. index.html コンテンツを変更する

ファイル name.html をローカルで編集し、3 つの Pod のコンテナーにアップロードします。

kubectl cp name.html nginx-deployment-574b87c764-nqpmc:usr/share/nginx/html/index.html

注: ポッドとローカル間でファイルを転送するためのコマンド形式

  1. ポッドはファイルをローカルにダウンロードします
  3. kubectl cp -n ネームスペース名 POD名:Podファイル名 ローカルファイル名

ファイルをローカルのPodにアップロードする

  1. kubectl cp ローカルファイル名 -n ネームスペース名 POD名:Podファイル名

最終的なクエリ出力結果、複数のクエリでは、ロードバランスによって接続がランダムに異なるポッドノードに割り当てられていることがわかります。

  1.  curl -silent ae8e75d7e149044eb905b6bbff796e7e- 629951941 .cn-northwest- 1 .elb.amazonaws.com.cn | grep ノード

5. 結論

この記事を通じて、コンテナ化についての予備的な理解と、Amazon EKS 用に構築されたエンタープライズ コンテナ化プラットフォームについての予備的な理解が得られます。 Docker と Kubernetes は、エンタープライズ システムとビジネスの開発に欠かせない推進力を持っています。

しかし、Kubernetes の学習曲線と企業における Kubernetes の人材の蓄積には、どちらも長い「時間」コストが必要です。クラウド コンピューティング サプライヤーの成熟したプラットフォームと製品の助けを借りて、企業内での技術人材の蓄積コストを削減し、半分の労力で 2 倍の結果を達成できます。

この実践的な演習を通じて、Amazon EKS に基づくコンテナ化されたプラットフォームを作成するには、1 つのコマンドだけが必要であることがわかります。 Amazon EKS を使用すると、Kubernetes の作成、実行、保守が簡単かつ信頼性が高まります。 AWS Fargate を使用すると、企業は仮想マシン (EC2) を管理する必要性を完全に排除し、Kubernetes の最上位ビジネスアーキテクチャのロジックのみに集中できるようになります。これにより、基盤となるアーキテクチャのさまざまな問題に悩まされることなく、ビジネス開発に多くの時間を費やすことができます。また、これにより、運用および保守担当者は、終わりのない「消火」運用および保守モードから逃れることができます。

準備はできたか？コンテナ船が出航しました！さあ、一緒にさらなる可能性を探りましょう！

[[358188]]

参考資料:

https://docs.amazonaws.cn/eks/latest/userguide/what-is-eks.html

https://eksctl.io/usage/creating-and-managing-clusters/

https://github.com/liangruibut/EKS-Workshop-China

https://docs.amazonaws.cn/en_us/eks/latest/userguide/create-kubeconfig.html

https://amazonaws-china.com/cn/premiumsupport/knowledge-center/eks-kubernetes-services-cluster/

https://www.eksworkshop.com/beginner/130_exposing-service/ingress_controller_alb/

https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/alb-ingress.html

[編集者：張燕妮 TEL: (010) 68476606]

<<:  テンセントテックパーク開発者会議が間もなく開催され、世界中から200人以上の専門家がクラウドコンピューティングについて議論します

>>:  クラウドコンピューティングはモノのインターネットの重要な柱である

推薦する

アップル、サムスンに10億ドル以上の損害賠償を勝ち取る

サンノゼ（カリフォルニア州）（ロイター） - 米アップルは金曜日、サムスンに対する法廷での圧倒的勝利...

Google Cloud はマルチクラウドとエッジコンピューティングに賭け、Amazon と Microsoft に追いつく

[[429493]] Google Cloud は、クラウド コンピューティング市場で Amazon...

raksmart - 香港で30%オフ/米国CN2で40%オフ/新しい100G高防御/10Gbps帯域幅

ベテランホスティングプロバイダー raksmart の 5 月のプロモーションが早くも開始されました...

クラウドストレージの構築とプライベートクラウドとパブリッククラウドの違いの比較

クラウド ストレージのような比喩は少し大げさに聞こえるかもしれませんが、それでもクラウドに関連する漠...

アカウントマネージャーとアカウントオペレーターの違いをご存知ですか?

ブログでは、アカウントレベルの操作に関する記事を多数更新しています。それらを注意深く読んだ友人は、多...

SEOERの道は困難です。困難に直面しても前進し続けてください。

SEO に携わるほとんどの同僚にとって、現段階で SEO を行うことは確かに非常に困難であり、将来は...

広告で最大の効果を達成する方法についての簡単な説明

多くの中小企業は、強力な広告を打つことを好みますが、結果は満足のいくものではありません。その理由は、...

We-mediaソーシャルコンテンツマーケティング

最近、企業のソーシャル セルフ メディア運用の全体計画を立てました。セルフ メディア運用を構築する際...

Apple、2014年のiTunesベスト・オブ・ザ・イヤーリストを発表

年末も近づき、そろそろ一年を総括する時期になりました。少し前に、Apple は 2014 年に iT...

主流の SEO クエリ ウェブサイトのさまざまな古いウェブサイトがどのように K アウトされたかの分析例

私はプロの SEO 担当者ではなく、経験豊富なウェブマスターです。今日は、あるウェブサイトを例に、S...

テンセントクラウドがインドネシアにデータセンターを開設、東南アジアでのクラウドサービス展開をさらに拡大

4月12日、テンセントクラウドはインドネシアで初のクラウドコンピューティングデータセンターを正式に開...

デリミタ - 6 ドル/kvm/1g メモリ/40g ハードディスク/1T トラフィック/G ポート/アトランタ

デリミタは、2010年に米国（5121558）と英国（07086361）に登録され、超格安サーバーの...

SEO はどれくらい持続しますか?

GOOGLEが中国市場から撤退して以来、Baiduは国内市場の大部分を占めることに成功している。最近...

スマートウォッチはモバイルインターネットの新たな領域か？

昨年末、Googleは特許取得済みの製品であるGoogle Eyesを正式にリリースし、インターネッ...

#618#メガレイヤー:香港専用サーバー(10MCN2)400元、米国クラスター(30Mcn2+4Cセグメント)888元

megalayerは618の真ん中で独立サーバーの特別プロモーションを提供します。更新価格は変わりま...