Japan Container Days v18.04 に行ってきた
日本のコンテナ系コミュニティイベント「Japan Container Days v18.04」に参加してきました。
Containerとは記載しているものの、ほぼ全てのセッションがKubernetesに関する発表のように思います。
さすが、デファクトスタンダードとなっている勢いでしょうか。
Docker, Kubernetes を勉強している途中なので、ビギナー視点での感想をまとめます。
Japan Container Days URL : https://containerdays.jp/
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
- すでにKubernetesを使用して商用稼働しているとのこと。すごい。
- 社内のオンプレミス基盤としてOpenStack基盤が存在していて、AKEはOpenStack Integratedしている。
Cinder連携：Persistent Volumeの提供
Keystone連携：Kubernetesクラスタへの認証で、Keystoneと連携
Designate連携：Cluster名をもとにした名前解決 (?)
Heat連携：Kubernetesクラスタを構築する際にHeatを使用。Heat Custom Resource を独自実装 - Yahooさんの環境もだけども、オンプレミスでKubernetesクラスタを提供する際には、OpenStack基盤を使用しないと厳しい印象。
NodeをVMで提供したい場合に、オートスケールや自動構成などを考えると、OpenStackには魅力があるように感じる。 - ServiceのType "Load Balancer"を独自実装。オンプレミスはLoadBalancerが存在しないため、F5連携のものを開発。
Octaviaはレイテンシーが厳しかったため、採用しなかったとのこと。 - サイバーエージェントさんの事例では、開発者ごとにKubernetesクラスタを提供。akeコマンドでセルフサービス構成ができる。 それぞれでクラスタを立てつけるほうが良いのか、1クラスタを共有したほうがいいのか、どちらが良いのか・・・。
Yahoo! JAPANのKubernetes-as-a-Service”で加速するアプリケーション開発
Yahoo! JAPANのKubernetes-as-a-Service”で加速するアプリケーション開発
- Kubernetesの恩恵にあずかるためには、アプリケーション側の考え方や設計方法を変更する必要がある。
- インフラ側の努力だけでは難しく、開発者を巻き込んだ、改善が必要。技術だけではなく、ソフト面でのアプローチも必要か
- Yahooさんの事例は、開発者ごとにKubernetesクラスタを提供
- 自動的にノードの修復する。クラスタのアップグレードをゼロダウンタイムで！（すごい）
- Kubernetesの外部公開方法は何を使用しているんだろう？ オンプレミスなのでLoadBalancerは存在しない、何か特殊なことをしているのかな
- Kubernetes on Kubernetes。社内の利用者が利用するKubernetesクラスタを、Kubernetesが管理する。
Kubernetes x PaaS — コンテナアプリケーションのNoOpsへの挑戦
Kubernetes x PaaS — コンテナアプリケーションのNoOpsへの挑戦
- Kubernetesに搭載するコンテナは、ステートレスであるべき。ステートフルなワークロードを扱う場合は、
コンテナ外のサービスに外だしして、上手にステートレスに仕上げたほうが良い。
パブリッククラウドの各種サービスを使用するとよい - Open Service Broker API
KubernetesPodから外部のサービスとの連携をしやすくするために策定されたAPI仕様
HORISONAL POD AUTOSCALERS
- Podのオートスケールに対応する話。
- Custom Metricを使用する必要があるらしい。Kubernetesで Custom Metric を提供するのは、複雑とのこと。
マニュアル通りにやっても動作しないとか。OSSあるあるですね
Container Networking Deep Dive
Container Networking Deep Dive
- flannelとCALICOのNWをDeepDive
- かなり深いところまで解説していた。
- 実際にKubernetesを運用する際には、選択したNetworkPluginの詳細な動作を理解して運用しないと、なにか障害が起こった際に対応出来ないと思われる。
- 特に、CALICOはiptablesを多く使用するらしい。CALICOはオーバーレイ技術(VXLAN, GRE)を使用しないので高速だと言われているが、IPIPトンネリングを使用する場合は、これがパフォーマンスに影響があるとのこと。
BGPを使用して、物理ルータに経路情報をアドバタイズすると改善が期待できる？
CoreOS買収を経てさらに加速する エンタープライズKubernetesとしてのOpenShift
- タイトルにCoreOSと書いているが、現時点では何も話せないとのこと。
- 既存システムのコンテナ化における移行方式が参考になった
Lift & Shift型：既存システムはそのままコンテナ化。その後マイクロサービス化
追加&リファクタ型：既存システムには触らず、機能とデータをサービス化(API化)
その後コンテナ基板上で新機能/同等機能を速いサイクルで開発し段階移行
完全リライト型：既存の重要機能の一覧をつくり、同等機能をコンテナ基板上で作成し段階的に移行
Kubernetes運用設計ガイド
Mercariでの実際のユーザー事例
Kubernetesを採用する上での注意事項
Kubernetes自体の狙いとずれていないこと。チーム設計。アプリケーション開発者とインフラ管理者を密結合しない。
Mercariでは、以下のように分割していた。
アプリケーション開発者：ソースコード、コンテナイメージ作成
インフラ開発者：ノード管理、クラスタ管理アプリケーション開発者にコンテナイメージを作成する分解ポイントにする場合、
日本の企業だと、現場から反対意見が聞こえそうな気もする。
アプリケーション開発者にはソースコードにのみ専念する選択肢も悪くない気もする (CI/CDの完備などで。)1個のクラスタに開発環境と商用環境を混在していた。
難しいポイントだと思う。GUIデプロイは、あまり筋が良くないという意見。
GUIだと、前回デプロイを実施した時との差異を管理できない。
YAMLファイルでGitで管理したほうが、バージョン管理できるので良さそう
Dockerだけじゃないコンテナruntime徹底比較!
- Docker, Frakti, cri-o, containerdの比較
- Fraktiランタイムは初めて聞いたが、Hypervisor(vSphereなど)を使用してVMを構成し、そのなかにコンテナを稼働する機構らしい。
コンテナというより、VM。VMとなるので起動時間などはコンテナより遅くなりそう。その代わりKernelを共有しないので、セキュリティ的に優位点があるのか。 - コンテナランタイムには、2種類存在する。(呼び方は決まっていない) HighLevelRuntime, RowLevelRuntime.
- 結論、HighLevelRuntimeは、containerd(Docker)が最もパフォーマンスが良い。
- LowLevelRuntimeも、runc (Docker) が最もパフォーマンスが良い。
- まだまだRuntimeはDockerがよさそう。
Istioと共にマイクロサービスに立ち向かえ!
CyberAgentの青山さんと会話していて、前半聞くことができなかった。
要追記