经过

我买了一本关于实践云原生DevOps的《在Kubernetes上实践云原生DevOps》的书，所以我想要实际动手学习。

虽然我并不完全不了解容器或Kubernetes，但由于很多时候都是根据感觉去进行操作，为了进一步确认，我希望能够认真学习并掌握。

这是关于对Kubernetes环境进行比较的第三章。

选择Kubernetes环境

在引入Kubernetes时的选择

• オンプレで自前構築

 

• クラウドインスタンスやベアメタルサーバ上に構築

 

• マネージドKubernetesを使用

 

Kubernetesを基盤にしたマネージドプラットフォーム

我們將介紹各自的特點和主要服務/產品。

集群的架构

在开始之前，让我们复习一下Kubernetes。

Kubernetes是将多个服务器组合成一个集群进行处理的。该集群是构建在什么样的基础上的？

控制平面

コントロールプレーンはクラスタの頭脳にあたる。Kubernetesがコンテナのスケジューリング、サービスの管理、APIリクエストの処理などの機能を実行するたに必要

由以下的组件构成，将执行控制平面组件的节点组成集群，并称之为主节点。

• kube-apiserver

コントロールプレーンのフロントエンドサーバ。APIリクエストを処理

etcd

ノードの詳細やクラスタに存在するリソースの詳細など、あらゆる情報を保存

kube-scheduler

新たに作成するPodを実行する場所を決定する

kube-controller-manager

Deploymentなどのリソースコントローラの実行を管理

kube-controller-manager

クラウドプロバイダと情報をやり取りして、ロードバランサやボリュームなどのリソースを管理

工作节点的组件

将执行用户工作负载的集群成员称为工作节点，并由以下组件组成。

• kubelete

ノードにスケジューリングされているワークロードを起動するコンテナランタイムの運用とステータス監視

kube-proxy

バックエンドのPodのグループに対してトラフィックをルーティングするIPアドレスを提供する

コンテナランタイム

実際にコンテナを起動終了し、必要な通信を処理する。DockerだけでなくrktやCRI-Oなどもサポートする

在中文中改述上述句子：

尽管主节点和工作节点在角色上有所区别，但本质上并没有太大的差异。在小型集群中，有一些节点既充当主节点又充当工作节点的角色（例如Docker Desktop和Minikube）。

高度可用性

• 高可用性のためには複数のマスタノードが必要で、個別のノードやコンポーネントの障害があっても正常に機能しなければならない

 

ノード間の通信障害でもetcdレプリカの過半数が利用可能であれば個別のノードに障害が発生しても稼働する事が出来る

控制平面故障

• アプリケーションがダウンすることはないが、誤動作する可能性はある

 

• すべてのマスタノードが停止してもアプリケーションは動くだろうが、Deploymentなどのコントローラは機能しなくなる

 

• コントロールプレーンの可用性は極めて重要であり、クォーラム（定足数）を維持できるように設計しなければならない

 

本番クラスタの場合は最低でも3つのマスタノードが必要

工作节点故障

• ワーカノードの障害はマスタノードに比べれば影響が少ない

 

• コントロールプレーンがPodを再配置する

 

• しかしワーカノードの数が少ないと個々のワーカノードのクラスタ全体への影響は大きくなる

 

複数のアベイラビリティゾーンやリージョンでの運用が望ましい

検証が大事

重要的是进行以下这样的测试并确认。

• ワーカノードをリブートしてみる

 

マスターノードをリブート

Kubernetes的自助式托管的费用

优点
* 最大的灵活性和控制

缺点

人员、技能和工时数量激增

• コントロールプレーン、ワーカノードの可用性担保

 

• 通信の暗号化や、ユーザの権限といったセキュリティ

 

• 認証、認可といった権限周り

 

• 各ノードのバージョン管理

 

• データのバックアップ戦略

 

• その環境の監視

 

• 頻繁なアップデートへの対応

 

Chaos Monkey などを使った継続的なテスト

導入後，Kubernetes的更新方式和資源擴展計劃等工作將持續進行，這讓我想起當初導入Openstack等私有雲時也有類似的情況。

実験やよほど変わった使い方をしない限りはセルフホスティングは薦めません。
GKEやEKSといったマネージドなら1日数ドル程度で動かせるので、まず試してはどうか。

ターンキー方式のKubernetesソリューション

• 納品後に直ちに稼働できる状態で引き渡される方式をターンキー方式という

 

• WebUIで数クリックするだけで本番グレードのKubernetes

stackpoint.ioや、ContainerShipが有名

Kubernetes安装程序

• マネージドでもターンキー方式でもない場合は、Kubernetesインストーラを使うことになる

kops,kubeadm,RKE等々

購入か構築か：本書の推奨事項

在选择时要考虑的要点

• 実行するソフトウェアを減らす

標準のテクノロジを選ぶ
差別化につながらない面倒な作業はアウトソーシングする
長続きする競争優位性を生み出す

可能ならマネージドKubernetes

クラスタの保守作業は 差別化につながらない面倒な作業 とみなす
競争優位性を生み出せるところに注力すべき

ベンダロックインの問題

KubernetesはOSSなので、むしろ標準のプラットフォームに乗せる事が出来たと考えていい
マネージドKubernetesよりも(例えばEC2などに)セルフホスティングしたKubernetesの方が、そのクラウドに依存してしまう

どうしてもセルフホスティングするのであれば、なるべく標準的なツールを使った方がいい

kopsやKubesprayがおススメ。成熟していてAWSやGoogle Cloudで本番グレードのKubernetesを構築できる

无集群的容器服务

コンテナのワークロードのオーバーヘッドを最小限にまで抑えられる方法。ユーザはkubectlのようなツール不要でコンテナをオンデマンドで実行できる。

亚马逊Fargate

• EC2に似ているが、VMの代わりにコンテナを動かす

 

• クラスタノードやコントロールプレーンを意識する必要なし

 

EKS on Fargate という構成も可能

Azure容器实例(ACI)

• Fargateに似ているが、AKSとの統合機能が魅力

AKSクラスタの設定を介してACIにPod作成をしてスパイクしのぎなどができる

バッチジョブの実行も可能

我对此有些见解
对此有何想法
对此的感受是
感触颇深
感到很有启发

「よほどの事情がない限りはマネージドKubernetesを使え」という、非常に強い意志を感じる章でした。「大規模なKubernetes環境を構築して運用」て、エンジニア冥利に尽きるとか思いがちですけど、それは差別化につながらない面倒な作業です。

Kubernetes自体は、Docker Desktopなんかでサンプルアプリを動かすだけならそんなに苦労しなくなってきたのかな？というのが僕自身の感想です。

ただ、本番グレードとなると上述したように可用性やセキュリティ、頻繁なアップデートへの追従など差別化につながらない面倒な作業がとても多く運用担当者の疲弊に繋がるでしょう。

尽管如此，如果在没有任何知识的情况下使用托管的 Kubernetes，那么在设计和故障排除时会遇到困难，因此学习仍然是必要的。

因此，下一章我们将学习“Kubernetes对象的基本操作”。

感谢您最后一直阅读到结束。