Kubernetes完全ガイド 第2版 impress top gearシリーズ [Kindle]

  • インプレス
4.14
  • (2)
  • (4)
  • (1)
  • (0)
  • (0)
本棚登録 : 78
感想 : 2
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・電子書籍 (1250ページ)

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 実践ガイドより少し奥へ踏み込んだ知識を身につけることができる。

  • ・P39:2.3.1 宣言的なコードによる管理(Infra as Code)
    k8sはYAMLやJSONで記述した宣言的なコード(マニュフェスト)によってデプロイするコンテナや周辺リソースを管理できる為、Infra as Codeを実現可能です。

    ・P52:3.3.1 k8sのサービスレベル目標(SLO)

    ・P58:3.4 パブリッククラウド上のマネージドk8sサービス

    ・P59:(GCPの)GKEで重要なコンセプトにNodePoolという機能があります。NodePoolとは、k8sクラスタ内のノードに対してラベル付けをしておくことで、グルーピングするような機能です。

    ・P65:(Amazon EKSで)運用負荷を減らしたい場合は、ワーカーノードの管理をAWSに任せるManaged Nodegroupsや、AWS Fargateをk8s Nodeとして利用するEKS on Fargateなどを利用すると良いでしょう。

    ・P66:EKSも最近はマネージド化が進んでいるため、EKSおよびAWSの今後のロードマップについてのドキュメント(下記)も参照してみて下さい。
    https://github.com/aws/containers-roadmap/projects/1

    ・P71:4.2 k8sの基礎
    k8sは、MasterとNodeの2種類のノードから成り立っています。

    MasterはAPIエンドポイントの提供、コンテナのスケジューリング、コンテナのスケーリングなどを担うノードです。

    もう一方のNodeはいわゆるDockerホストに相当し、実際にコンテナが起動するノードです。

    ・P73:4.3 k8sとリソース
    k8sを操作する為に登録する「リソース」は大きくわけて表4.2の5種類のカテゴリに分類されます。

    ・P76:4.5 CLIツール kubectl
    k8sでは、クラスタの操作はすべてk8s MasterのAPIを介して行われます。直接APIにリクエストを送信したり、クライアントライブラリを使用してもクラスタを操作できますが、手動で操作する場合にはCLIツールの「kubectl」を利用することが一般的です。

    ・P126:5.1 Workloads APIsカテゴリの概要
    Podを最小単位として、それらを管理する上位リソースがある親子関係になっています。

    ・P127:図5.1 各Workloads APIsカテゴリに分類されるリソースの関係

    ・P128:5.2.1 Podのデザインパターン

    ・P159:5.4.5 Deploymentのアップデート戦略

    ・P167:5.5.2 DamonSetのアップデート戦略

    ・P173:5.6.4 StatefulSetのアップデート戦略

    ・P179:5.7.1 ReplicaSetとの違いとJobの使い所
    バッチ的な処理の場合には積極的にJobを利用しましょう。

    ・P189:5.8 CronJob
    CronJobはCronのようにスケジュールされた時間にJobを実行します。

    ・P200:5.9 まとめ
    表5.8:各Workloads APIsカテゴリに分類されるリソースの使い分け方

    ・P202:6.1 Service APIsカテゴリの概要
    Service APIsカテゴリに分類されるリソースは、クラスタ上のコンテナに対するエンドポイントの提供や、ラベルに一致するコンテナのディスカバリに利用されるリソースです。

    内部的に利用されているものを除いて利用者が直接利用するものとしては、L4ロードバランシングを提供するServiceリソースと、L7ロードバランシングを提供するIngressリソースの2種類のリソースがあります。

    ・P227:6.5.2 NodePortの注意点
    NodePortで利用できるポートの範囲は、GKEを含む多くのk8s環境で30000〜32767(k8sのデフォルト値)となっており、想定外の値を設定しようとするとエラーになります。また、自動的に割り当てられるNodePortも同様の範囲内です。

    ・P234:6.6.4 GKEやクラウドプロバイダでの注意点

    ・P274:7.1 Config & Storage APIsカテゴリの概要
    Config & Storage APIsカテゴリに分類されるリソースは、コンテナに対して設定ファイル、パスワードなどの機密情報などをインジェクトしたり、永続化ボリュームを提供したりするためのリソースです。

    ・P298:7.4.3 SecretとConfigMap共通の話題
    SecretとConfigMapの使い分け

    ・P274:8.1 Cluster APIsカテゴリとMetadata APIsカテゴリの概要
    Cluster APIsカテゴリに分類されるリソースは、セキュリティ周りの設定やクォータ設定など、クラスタの挙動を制御するためのリソースです。

    Metadata APIsカテゴリに分類されるリソースは、クラスタ上にコンテナを起動させるのに利用するリソースです。

    ・P357:9.1.3 システムに割り当てられるリソースとEviction Manager
    k8sの内部ではEviction Managerというコンポーネントが動いており、システム全体が高負荷にならないように管理しています。

    ・P364:Cluster Autoscalerとリソース不足
    Cluster Autoscaleはk8sクラスタ自体のオートスケーリングを意味しており、需要に応じてk8s Nodeを自動的に追加していく機能になります。

    GKEもクラスタのオートスケーリングが可能な環境の一つであり、NodePool単位で機能の有効化や無効化が可能です。Pending状態のPodができたタイミングではじめてこのCluster Autoscalerが発動することになります。

    ・P376:Horizontal Pod Autoscaler(HPA)
    HPAはDeployment/ReplicaSet/ReplicationControllerのレプリカ数をCPU負荷などに応じて自動的にスケールさせるリソースです。

    ・P380:Vertical Pod Autoscaler(VPA)
    VPAはコンテナに割り当てるCPU/メモリのリソースの割当を自動的にスケールさせるリソースです。

    ・P387:10.1.1 3種類のヘルスチェック機構

    ・P389:10.1.2 3種類のヘルスチェック方式

    ・P410:10.5 Podの安全な停止とタイミング

    ・P416:11.1 ノードの停止とPodの停止

    ・P423:12.1 フィルタリングとスコアリング
    k8sのスケジューリングには「フィルタリング」の過程と「スコアリング」の過程があります。

    フィルタリング(Predicates)では、スケジューリングするPodが割当可能なノードを計算します。

    スコアリング(Priolity)では、フィルタリングされた後のノード一覧を順位付けし、もっとも適したノードを計算します。

    ・P468:13.1 ServiceAccount
    k8sではユーザに似たコンセプトとして、UserAccountとServiceAccountがあります。UserAccountはGKEではGoogleアカウントとリンクしていたり、EKSではIAM とリンクしたりするようになっており、k8sの管理対象ではありません。

    一方でServiceAccountはk8sの世界だけで完結するもので、Podで実行されるプロセスのために割り当てるものになります。Pod起動時には必ずServiceAccountを1つ割り当てる必要があり、ServiceAccountベースで認証/認可を行っています。

    ・P484:13.3 SecurityContext
    SecurityContextは、個々のコンテナに対するセキュリティ設定です。設定可能な項目は表13.4に示した通りです。

    ・P486:13.4 PodSecurityContext
    PodSecurityContextは、Pod(全てのコンテナ)に対するセキュリティ設定です。設定可能な項目は表13.5に示した通りです。

    ・P495:13.6 NetworkPolicy
    NetworkPolicyは、k8sクラスタ内でPod同士が通信する際のトラフィックルールを規定するものです。

    ・P507:13.7 認証/認可とAdmission Control
    Admission Controlはk8s APIサーバにリクエスト制御を追加で行う仕組みです。

    ・P511:13.9 Secretリソースの暗号化
    SecretリソースはBase64でエンコードされているだけなので、そのままではGitリポジトリなどにアップロードできないポリシーになっている企業も多く、別途暗号化を行う必要があります。

    ・P523:14.1 マニュフェストの汎用化 / 14.2 Helm
    システムが大規模になってくると、類似したマニュフェストを大量に作らなかればならず、再利用や一括変更といったことが困難になってきます。そこで必要になるのがマニュフェストの汎用化という考え方です。

    Helmはk8sのパッケージマネージャで、様々なパッケージ(Chart)が用意されています。ローリングアップデートなどにも対応しているものが多く、k8sで実行するのに適切な設定がされた状態で利用できるのも良いところです。

    ・P557:16.2 Fluentdによるログ集約
    k8s上で起動しているコンテナのログを中長期的に安定保存する為には、Fluentdを使ってクラスタ外部に転送する構成がおすすめです。

    ・P565:17.2 GitOps
    【コラム】マニュフェストリポジトリの配置について
    マニュフェストリポジトリは単一のリポジトリに配置するようにして下さい。

    ・P593:18.1 マイクロサービスアーキテクチャとは
    大きな問題として、システム全体のモニタリングが難しいという点が挙げられます。このような問題に対して解決策を提供するのが「サービスメッシュ」という考え方です。

    ・P594:18.2 サービスメッシュとは
    サービスメッシュとはマイクロサービス間に張り巡らされたメッシュ状の通信やその経路を制御する考え方です。サービスメッシュを実現するOSSとしてはIstioやLinkerdが有名です。

    ・P616:18.4 まとめ
    マイクロサービス化はメリット/デメリットがあり、また必ずしも今抱えている問題の解決策とはならない場合もあります。開発規模が小さい場合には無理にマイクロサービス化せず、最初はモノリシックアーキテクチャで始めて、規模が大きくなってきてからマイクロサービス化を検討するといった手順を考慮してみて下さい。

    サービスメッシュはいずれのソフトウェアでもPod間の通信経路にプロキシを挟むことで実現されます。

    ・P625:A.2 よくある質問とその答え

全2件中 1 - 2件を表示

著者プロフィール

【第1章、第3章1節ー3節、第4章4節担当】Kubernetes as a Serviceのプロダクトオーナー、Kubernetes/CloudNative領域のDeveloper Expertsとして従事。著書に『Kubernetes完全ガイド』等。現在はOSSへの貢献活動をはじめ、CloudNative Days TokyoのCo-chair、Kubernetes Meetup TokyoのOrganizerなどコミュニティ活動にも従事。Twitter: @amsy810/GitHub: MasayaAoyama

「2023年 『Kubernetesの知識地図 —— 現場での基礎から本番運用まで』 で使われていた紹介文から引用しています。」

青山真也の作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×