Japan Container Days v18.04 に行ってきた

# Japan Container Days v18.04 に行ってきた

日本のコンテナ系コミュニティイベント「Japan Container Days v18.04」に参加してきました。
Containerとは記載しているものの、ほぼ全てのセッションがKubernetesに関する発表のように思います。
さすが、デファクトスタンダードとなっている勢いでしょうか。

Docker, Kubernetes を勉強している途中なので、ビギナー視点での感想をまとめます。

Japan Container Days URL : <https://containerdays.jp/> 



# サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術

[サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術](https://speakerdeck.com/masayaaoyama/saibaezientoniokerupuraibetokontenaji-pan-akewozhi-eruji-shu)

- すでに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”で加速するアプリケーション開発](https://www.slideshare.net/techblogyahoo/yahoo-japan-kubernetesasaservice)

- Kubernetesの恩恵にあずかるためには、アプリケーション側の考え方や設計方法を変更する必要がある。
- インフラ側の努力だけでは難しく、開発者を巻き込んだ、改善が必要。技術だけではなく、ソフト面でのアプローチも必要か
- Yahooさんの事例は、開発者ごとにKubernetesクラスタを提供
- 自動的にノードの修復する。クラスタのアップグレードをゼロダウンタイムで！（すごい）
- Kubernetesの外部公開方法は何を使用しているんだろう？ オンプレミスなのでLoadBalancerは存在しない、何か特殊なことをしているのかな
- Kubernetes on Kubernetes。社内の利用者が利用するKubernetesクラスタを、Kubernetesが管理する。



# Kubernetes x PaaS — コンテナアプリケーションのNoOpsへの挑戦 

[Kubernetes x PaaS — コンテナアプリケーションのNoOpsへの挑戦](https://www.slideshare.net/yokawasa/kubernetes-x-paas-noops)

- Kubernetesに搭載するコンテナは、ステートレスであるべき。ステートフルなワークロードを扱う場合は、  
  コンテナ外のサービスに外だしして、上手にステートレスに仕上げたほうが良い。  
  パブリッククラウドの各種サービスを使用するとよい
- Open Service Broker API  
  KubernetesPodから外部のサービスとの連携をしやすくするために策定されたAPI仕様
  ​

# HORISONAL POD AUTOSCALERS

[Horizontal Pod Autoscalers](https://speakerdeck.com/koudaiii/number-containerdaysjp)

- Podのオートスケールに対応する話。
- Custom Metricを使用する必要があるらしい。Kubernetesで Custom Metric を提供するのは、複雑とのこと。  
  マニュアル通りにやっても動作しないとか。OSSあるあるですね



# Container Networking Deep Dive 

[Container Networking Deep Dive](https://www.slideshare.net/hichihara/container-networking-deep-dive-94307233)

- 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徹底比較!](https://speakerdeck.com/makocchi/about-container-runtimes-japan-container-days-v18-dot-04)

- 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の資料まとめ

https://medium.com/@yukotan/japan-container-days-v18-04-%E3%81%AE%E8%B3%87%E6%96%99-4f380fb7b696