Cloud9に接続できるようになった。Cloud9IDEで以下のスクリプトを実行。./lab-ide-build.shこれでkubectlコマンドなどがインストールされました。credentials」を無効にする。これで、ワークショップを続ける準備が整いました!102-your-first-clusterkopsを使ってKubernetesクラスタを作成する複数のマスターノードとワーカーノードを複数の可用性ゾーンに分散して、可用性の高いクラスタを作成する。ゴシッププロトコルを使用できる。クラスタはセットアップが簡単で簡単で、ドメイン、サブドメイン、またはRoute53ホストゾーンを登録する必要がない。ローリングアップデートを実演するなどもあるので、マルチマスタークラスタを作成するほうがよい。次のコマンドでマルチマスター、マルチノード、およびmulti-az構成でクラスターを作成します。オプションを使用し、マスターノードの数を指定することにより、マルチマスタークラスタを作成できます。オプションを使用して指定されたAZに分散されます。オプションを使用して、マスターノードのゾーンを明示的に指定することもできます。オプションは、ワーカーノードの配布にも使用されます。オプションを使用して、ワーカーの数が指定されます。Failedクラスタの作成には時間がかかりますね。すべてのマスターが異なるAZにまたがっていることは確認できました。20分ぐらいでワーカーノードもすべて起動しました。CLI)を使用して、複数のKubernetesクラスタを管理できます。各クラスタの構成は、「kubeconfigファイル」と呼ばれる構成ファイルに格納されています。CLIは、kubeconfigファイルを使用して、クラスタを選択し、クラスタのAPIサーバと通信するために必要な情報を検索します。これでコンテキストを変更するだけで、さまざまな環境にアプリケーションを展開できる。アプリケーション開発の典型的なフローは次のようになります。example.cluster.k8s.local出力には、クラスタごとに1つずつ、kubectlで利用可能な別のコンテキストが表示されます。現在のコンテキストを示す。current-contextexample.cluster.k8s.local複数のクラスタが存在する場合は、コンテキストを変更できます。CLIをkubectl(「キューブコントロール」)コマンドで探索することができる。Serverと対話します。プラットフォームとしてのKubernetesには、APIオブジェクトにマップされる多数の抽象的な要素があります。クラスタの望ましい状態を記述するために使用できます。APIの概念と、それを介して相互作用する方法について説明する。前提条件さきほど作成した、3つのマスターノードと5つのワーカーノードを持つクラスタを使用します。必要な設定ファイルが置いてあります。nodes以下の様にクラスタが出力されます。53s以上でわかったpodの名前から、次のようにポッドの追加情報を取得します。デフォルトでは、ポッドはdefaultというnamespaceに作成されます。kube-systemというnamespaceはKubernetesのシステムのポッド用に予約されています。kube-systemという名前空間内のすべてのポッドのリストは、次のように表示できます。deletedポッドポッドは、作成、スケジュール設定、および管理が可能な最小の展開可能なユニットです。これは、アプリケーションに属するコンテナの論理的な集合です。ポッドは名前空間に作成されます。ポッド内のすべてのコンテナは、名前空間、ボリューム、およびネットワーキングスタックを共有します。これにより、localhostを使ってポッド内のコンテナ同士が互いを「見つける」ことができる。ポッドの作成Kubernetesの各リソースは、構成ファイルを使用して定義できます。Nginxポッドは次のような設定ファイルで定義できます。ports:次のようにポッドを作成します。22sポッドが正常に起動したことを確認します(ポート8080で実行中のものがないことを確認してください)。IDEでプレビューと実行中のアプリケーションのプレビューをクリック。プレビュータブが開き、NGINXのメインページが表示されるのを確認。ポッド内のコンテナがログを生成する場合は、次のコマンドを使用して表示できます。$メモリおよびCPUリソースリクエストポッド内のコンテナには、メモリとCPUのリクエストと制限を割り当てることができる。制限は、コンテナが使用できるメモリ/CPUの最大量。Podのメモリ/CPUリクエストおよび制限は、Pod内のすべてのコンテナのメモリ/CPUリクエストおよび制限の合計。要求が指定されていない場合、デフォルトに制限されます。制限のデフォルト値はノードの容量。スケジューリングにはメモリとCPUの制限は考慮されていない。ポッド内のコンテナがメモリ要求を超えていない場合、ノードはノード上で操作を継続できる。ポッド内のコンテナがメモリ要求を超えると、ノードがメモリ不足になるたびに追い出し対象になる。ポッド内のコンテナがメモリの制限を超えると、それらは終了する。Podを再起動できる場合、他のタイプのランタイムエラーと同様に、kubeletはそれを再起動する。コンテナは、長時間にわたってCPU制限を超えてもしなくてもよい。過度の使用のために殺されることはないメモリとCPUのリクエスト/制限は、以下を使用して指定可能。spec.containers.resources.limits.cpuメモリリソースはバイト単位で要求される。E,P,T,G,M,K。電源の-2当量で表すことができEi,Pi,Ti,Gi,Mi,Ki。CPUはCPU単位で要求できます。それはまた、0.5やる500メートルなどのmillicpuを分数や小数単位で要求することができる。CPU要求が割り当てられず、制限はない。これは、以前に開始したポッドを使用して確認できる。jsonpath={.spec.containers[].resources}map[requests:map[cpu:100m]]メモリとCPUを割り当てる以下の設定ファイルを使用して、Podにメモリ要求と制限を割り当てる。80この設定ファイルの唯一の変更はspec.containers[].resourcesセクションの追加です。制限はlimitsセクションで指定され、要求はrequestsセクションで指定される。createdリクエストと制限の詳細を取得。memory:100Mi]]NGINXコンテナは、メモリとCPUがかなり少なくて済みます。したがって、これらの要求数と制限数は正常に機能し、ポッドは正しく開始されます。度は、同様の番号を使ってWildFlyポッドを開始しようとしましょう。同じ設定ファイルが表示されます。8080このポッド内のWildFlyコンテナに割り当てられるメモリの最大量は200MBに制限されています。このポッドを作成してみよう。createdポッドの状態を確認。1mOOMKilledでコンテナがメモリ不足で終了したことを示します。pod-resources2.yamlでspec.containers[].resources.limits.memoryの値を300Miに変更します。既存のPodを削除し、新しいPodを作成します。25sこれで、Podが正常に開始されます。Podに割り当てられたリソースの詳細を取得。serviceKubernetesは、コンテナによって使用されていない場合、要求と制限の差を便宜的に排除します。これにより、Kubernetesがノードをオーバーサブスクライブできるようになり、使用率が向上すると同時に、保証が必要なコンテナのリソース保証が維持されます。Kubernetesは、QoSクラスの1つをPodに割り当てます。GuaranteedBurstableBestEffortQoSクラスは、KubernetesによってPodのスケジュール設定と撤回に使用されます。スケジュールされます。これが最優先事項です。ポッドがBurstableQoSを満たさずGuaranteed、少なくとも1つのコンテナにメモリまたはCPU要求がある場合、ポッドにはQoSクラスが与えられます。これは中間的な優先事項です。スケジュールされます。これが最も低く、デフォルトの優先順位です。厳しくない要件のポッドは、より弱いQoSを使用することも、QoSを使用しないこともあります。80ここでは要求値は指定されておらず、デフォルト値はlimitになる。80ここでは、リクエスト値と制限値の両方を指定しました。found.Deploymentポッドの4つのレプリカなどの「望ましい状態」は、Deploymentオブジェクトに記述することができます。Kubernetesクラスタ内のDeploymentコントローラは、望まれた状態と実際の状態が一致していることを確認します。ワーカーノードに障害が発生したり再起動したりすると、Deploymentによってポッドが再作成されます。ポッドが死ぬと、新しいポッドが開始されて、望ましい状態とと実際の状態のマッチが確実に行われます。レプリカ数のアップスケーリングとダウンスケーリングが可能です。これは、ReplicaSetを使用して実現されます。Deploymentはレプリカセットを管理し、それらのポッドに更新を提供します。次の例では、NGINXベースイメージの3つのレプリカでDeploymentを作成する。以下のテンプレートを確認して、試してみる。443このDeploymentでは、NGINXイメージのインスタンスが3つ作成されます。createdこの--recordフラグは、各リビジョンの変更を追跡します。outデプロイメントはレプリカの数を管理するレプリカセットを作成します。既存のデプロイメントとレプリカセットを見てみましょう。2mデプロイメントのスケーリングDeploymentのレプリカ数は、次のコマンドを使用してスケーリングできる。3mデプロイメントのアップデートPodの仕様を編集することで、Deploymentのより一般的なアップデートを行うことができます。この例では、最新のnginxイメージに変更しましょう。最初に、次のように入力してテキストエディタを開きます。deployment/nginx-deployment次に、imageをnginx:1.12.1からnginx:latestに変更します。これにより、展開のロール更新が実行されます。リビジョン、イメージのバージョン、ポートなどの展開の詳細を追跡するには、次のように入力します。0デプロイメントのロールバック以前のバージョンにロールバックするには、まず更新履歴を確認します。deployment/nginx-deployment前のリビジョンにのみロールバックする場合は、次のコマンドを入力します。backDeploymentをロールバックしてnginx:1.12.1イメージを使用します。nginx:1.12.1特定のリビジョンにロールバックする場合は、次のように入力します。deletedServiceポッドは一時的です。各ポッドには一意のIPアドレスが割り当てられます。複製コントローラに属するポッドが消滅した場合は、再作成され、異なるIPアドレスが与えられます。Setを使用して追加のポッドを作成することもできます。これにより、WildFlyなどのアプリケーションサーバーが、そのIPアドレスを使用してMySQLなどのデータベースにアクセスすることが困難になります。サービスとは、論理的なポッドセットとそのポッドにアクセスするためのポリシーを定義する抽象化です。サービスに割り当てられたIPアドレスは時間の経過とともに変化しないため、他のポッドに依存することができます。通常、サービスに属するポッドは、ラベルセレクタによって定義されます。これは、ポッドがレプリカセットにどのように属しているかと同様のメカニズムです。ラベルを使用してポッドを選択するというこの抽象化は、疎結合を可能にする。デプロイメント内のポッドの数は拡大または縮小されますが、アプリケーションサーバーはそのサービスを使用して引き続きデータベースにアクセスできます。Kubernetesサービスは、論理的なポッドセットを定義し、マイクロサービスを介してそれらにアクセスできるようにします。ServiceのDeploymentを作成Podは、ラベルがPodに接続されている疎結合モデルを使用してServiceに属し、Serviceはそれらのラベルを使用してPodを選択します。最初にDeploymentを作成して、ポッドの3つのレプリカを作成しましょう。BalancerのHTTPヘッダーで応答するechoアプリケーションを作成します。デプロイメントを作成するには、次のように入力します。echo-podと添付されているラベルによって決定されます。コンテナ上の8080のターゲットポートへのインバウンドポート80を定義します。Kubernetesは、TCPプロトコルとUDPプロトコルの両方をサポートしています。Serviceを公開するtype属性を使用して外部IPにサービスを公開することができます。この属性は、次のいずれかの値をとります。クラスタ内のIPアドレスで公開されるサービス。定義されたポートで各ノードのIPアドレスに公開されるサービス。クラウドにデプロイされている場合は、クラウド固有のロードバランサを使用して外部に公開される。externalNameフィールドにサービスが添付されています。値を持つCNAMEにマップされます。Balancer(ELB)上にecho-appサービスを公​​開します。LoadBalancer次のコマンドを実行してサービスを作成します。Balancer(ELB)のアドレスとして表示されます。ELBがプロビジョニングされ、利用可能になるまでには約2〜3分かかるので数分待ってからサービスにアクセスするとよい。request-出力に示されているclient_addressの値に注意してください。これは、リクエストを処理するポッドのIPアドレスです。このコマンドを複数回呼び出すと、この属性に異なる値が表示されます。これで、deploymentのポッドの数を増減できます。ポッドが終了して別のホストで再起動することがあります。Serviceは、ポッドに付いているラベルがServiceによって使用されているため、それらのポッドを対象とすることができます。サービスの削除サービスを削除するには、次のコマンドを実行します。service.yamlバックエンドの展開も明示的に削除する必要があります。echo-deployment.yamlデーモンセットデーモンセットは、Podのコピーが選択されたノードセットで実行されるようにします。デフォルトでは、クラスタ内のすべてのノードが選択されます。選択基準を指定して、限られた数のノードを選択することができる。新しいノードがクラスタに追加されると、ポッドがクラスタ上で開始されます。ノードが削除されると、ガベージコレクションによってポッドが削除されます。デーモンセットを作成する次は、Prometheusコンテナを実行するDaemonSetの例です。テンプレートから始めましょう。80次のコマンドを実行することでReplicaSetとpodsが作成されます。--record--recordフラグは各リビジョンの変更を追跡します。57s特定のノードにDaemonSetsを制限するPrometheusポッドがクラスタノードに正常に展開されたことを確認します。ip-172-20-37-172.ec2.internalノードラベルの1つを次のように変更します。labeled次に、次のコマンドでDaemonSetテンプレートを編集します。中に変更したラベルに一致するnodeSelectorを含めるように変更。prometheus-node更新が実行された後、Prometheusを特定のノードで実行するように設定しました。2mデーモンセットを削除するDaemonSetを削除するには、次のコマンドを実行します。daemonset.yamlジョブジョブは1つまたは複数のポッドを作成し、指定された数のポッドが正常に完了するようにします。ジョブは、ポッドの正常終了を追跡します。指定した数のポッドが正常に完了すると、ジョブ自体は完了です。ハードウェア障害のためにポッドに障害が発生したり削除されたりすると、ジョブは新しいポッドを開始します。指定した数のポッドが正常に完了すると、ジョブが完了したことを意味します。これは、特定の数のポッドが常に実行されていることを保証するレプリカセットまたはデプロイメントとは異なります。したがって、レプリカセットまたは配備内のポッドが終了すると、そのポッドは再び再開されます。これにより、レプリカセットまたはデプロイメントは長期実行プロセスとなります。これは、NGINXなどのWebサーバーに適しています。指定した数のポッドが正常に完了すると、ジョブは完了します。これは、一度だけ実行する必要のあるタスクに適しています。ジョブは画像フォーマットを別のものに変換することができる。レプリケーションコントローラでこのポッドを再起動すると、重複した作業が発生するだけでなく、場合によっては有害な可能性があります。ジョブはレプリカセットを補完します。レプリカセットは、終了する予定のないポッド(Webサーバーなど)を管理し、ジョブは終了すると予想されるポッド(バッチジョブなど)を管理します。仕事を持つポッドにのみ適しているRestartPolicyに等しいですOnFailureかNever。非並列ジョブポッドに障害が発生しない限り、1ジョブにつき1つのポッドしか開始されません。ポッドが正常に終了するとすぐにジョブが完了します。これがジョブの仕様です。NeverUbuntuのコンテナを作成し、20秒間スリープ状態になります。次のコマンドを使用してジョブを作成します。createdジョブを見てみます。0s出力はジョブがまだ成功していないことを示しています。ポッドの状態を確認して確認します。24sまず、ジョブのポッドが実行中であることを示します。ポッドは数秒後に正常に終了し、Completedステータスが表示されます。ジョブの状態をもう一度見てみましょう。1m出力はジョブが正常に実行されたことを示します。podsコマンドに表示されません。代わりに、次のように追加のオプションを渡すことで表示できます。job.yamlパラレルジョブ非並列ジョブはジョブごとに1つのポッドのみを実行します。このAPIは、ジョブに対して複数のポッドを並行して実行するために使用されます。完了させるポッドの数は設定ファイルの.spec.completions属性によって定義されます。並行して実行するポッドの数は、構成ファイルの.spec.parallelism属性によって定義されます。これらの属性の両方のデフォルト値は1です。1〜.spec.completionsの各値に対して成功したポッドが1つある場合、ジョブは完了です。そのため、固定完了カウントジョブとも呼ばれます。Neverこのジョブ仕様は、非並行ジョブ仕様に似ています。.spec.completionsと.spec.parallelism。6つのポッドが正常に完了すると、ジョブは完了します。同時に最大2つのポッドが並行して実行されます。次のコマンドを使用して並列ジョブを作成します。job-parallel.yaml次のようにジョブのステータスを確認します。1m出力は約20秒ごとに2つのポッドが作成されることを示しています。別の端末ウィンドウで、作成されたポッドの状態を確認します。podsは完成したポッドのリストは表示されません。ポッドの一覧を表示するコマンドを以下に示します。jobs完了後のジョブのステータスを示します。3mジョブを削除すると、すべてのポッドも削除されます。ジョブを次のように削除します。JobはAPIバージョンbatch/v2alpha1で作成できます。クラスタのバージョンを確認しましょう。Platform:"linux/amd64"}Cronジョブを作成するCronジョブは、Cron形式で書かれたスケジュールに従って実行されるジョブです。主な使用例は2つあります。指定した時点でジョブを1回実行する特定の時点で繰り返しジョブの仕様です。World"というメッセージを毎分出力します。kubectlのCLIバージョンが1.8などだった場合は必須です。このオプションを指定しないと、エラーが表示されます。created次のようにジョブのステータスを確認します。1m別の端末ウィンドウで、作成されたポッドの状態を確認します。deletedNamespaceNamespaceを使用すると、物理クラスタを複数のチームで共有することができます。Namespaceは、作成されたリソースを論理的に名前のついたグループに分割することを可能にします。各ネNamespaceは以下の機能を提供します。名前の衝突を回避するためのリソースのためにユニークなスコープ信頼できるユーザーへの適切な権限を確保するポリシーリソース消費の制約を指定する機能これにより、Kubernetesクラスタは複数のグループによってリソースを共有し、各グループごとに異なるレベルのQoSを提供できます。ある名前空間で作成されたリソースは、他の名前空間から隠されています。潜在的にそれぞれ異なる制約を持つ複数の名前空間を作成できます。デフォルトNamespace名前空間のリストは、次のコマンドを使用して表示できます。2mデフォルトでは、Kubernetesクラスタ内のすべてのリソースはdefaultNamespaceに作成されます。kube-publicはすべてのユーザーが読み取ることができる名前空間で、認証されていないユーザーも含まれます。kubeadmで起動されたクラスタは、cluster-infoConfigMapがあります。このクラスタはkopsを使用して作成されるため、このConfigMapは存在しません。Kubernetesシステムによって作成されたオブジェクトの名前空間です。jsonpath={.items[].metadata.namespace}defaultカスタムNamespace新しい名前空間は、設定ファイルまたはkubectlを使用して作成できます次の設定ファイルを使用して名前空間を作成できます。created次の-nように追加のスイッチを用意することによって、ネームスペース内の配置を照会することができます。jsonpath={.metadata.namespace}dev別の方法として、名前空間はkubectlを使っても作成することができます。各ネームスペースにはリソースクォータを割り当てることができます。クォータを指定すると、ネームスペース内のすべてのリソースで消費できるクラスタリソースの量を制限できます。リソースクォータは、ResourceQuotaオブジェクトで定義できます。名前空間にResourceQuotaオブジェクトが存在すると、リソースクォータが強制されます。名前空間内には最大でも1つのResourceQuotaオブジェクトが存在します。現在、複数のResourceQuotaオブジェクトが許可されています。これはkubernetes#55430として提出されています。クォータは、CPUやメモリなどの計算リソース、PersistentVolumeやPersistentVolumeClaimなどのストレージリソース、および指定されたタイプのオブジェクトの数に指定できます。ResourceQuotaを作成するResourceQuotaは、構成ファイルまたはkubectlを使用して作成できます。次の設定ファイルを使用してResourceQuotaを作成できます。"5"この設定ファイルは、ネームスペースに次の要件を設定します。この名前空間内のサービスの総数は5を超えることはできませんこの名前空間内のConfigMapの総数は5を超えることはできません新しいResourceQuotaを作成します。使用してResourceQuotaを作成することもできます。どちらの場合も、この場合、これらの制限はdefaultネームスペースに置かれます。別の名前空間は、構成ファイルで指定するか、またはCLIkubectlで--namespaceオプションを使用して指定することができます。5mResourceQuotaの詳細については、次を参照してください。5出力には、default名前空間に3つのPodと1つのサービスが既に存在していることが示されています。ResourceQuotaを使用してリソースを拡大ResourceQuotaが作成されたので、これが作成された新しいリソースや拡張された既存のリソースにどのように影響するのかを見てみましょう。私たちは既にデプロイメントを持っていますnginx-deployment。割り当てられたクォータを超えるようにレプリカの数をスケーリングし、何が起こるかを見てみましょう。Deploymentのレプリカ数を調整します。scaledコマンド出力には、展開がスケーリングされていることが示されます。jsonpath={.status.availableReplicas}33つのレプリカしか利用できないことを示しています。詳細は次を参照してください。availability.現在の理由が出力に表示されます。80このポッドを作成する前に、以前実行していたポッドまたはデプロイメントを削除する必要があります。memoryエラーメッセージは、ResourceQuotaが有効であり、Podがメモリリソースを明示的に指定しなければならないことを示します。設定ファイルを次のように更新します。80ここに定義された明示的メモリリソースがあります。createdポッドは正常に作成されます。memory:100m]]ResourceQuotaの詳細については、次を参照してください。5CPUとメモリリソースがどのように増分された値になっているかに注意してください。ResourceQuotaでポッドを作成するために明示的なCPUリソースが必要ない方法の詳細を提供します。deletedこれで、ワークショップを続ける準備が整いました!次回は201-cluster-monitoringからです。ハンズオンをやりました。月別アーカイブはてなブログをはじめよう!oza__shuさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。