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

Horizontal 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だけじゃないコンテナ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の青山さんと会話していて、前半聞くことができなかった。

要追記

SpeakerDeckの資料まとめ