気になっているニュースを適当に書き連ねてみた．
- 2017年6月・7月号 https://qiita.com/AkihiroSuda/items/dc60347f1ad79a747fa2
- 2017年4月・5月号 http://qiita.com/AkihiroSuda/items/e4785014c6c50496f11b
- 2017年3月号 http://qiita.com/AkihiroSuda/items/746328a8ee59301807b6
- Docker 1.13号 http://qiita.com/AkihiroSuda/items/d762b8cdc1d704f8efdf
- Docker 1.12号 http://qiita.com/AkihiroSuda/items/ba3e118389e0a550c000
Mesosphere社，Rancher社のいずれとも，Kubernetesに重きをおいた製品を出してきた．
Docker社は，未だKubernetes関連の製品は発表していないが，Kubernetesに関するOSSの取り組みは活発に実施しているように見える．
Docker・Moby 関連
Docker 17.09
17.07のリリースが8/30までずれこんだため，17.08は無し．
9/27にリリースされた17.09では，さほど大きい変更はなされなかった．
ただし，aufs.ko が読み込まれている場合でも，AUFSよりOverlay2を優先して使うようになった．https://github.com/moby/moby/pull/34430
(なったと言うか，私がした．もしデグレしたら {"storage-driver": "aufs"} を /etc/docker/daemon.jsonに書いてください．)
ちなみにOverlay2は CONFIG_OVERLAY_FS_REDIRECT_DIR=y なカーネルではまともに動かないが，17.10で修正見込み．https://github.com/moby/moby/pull/34342
LinuxKitがKubernetesをサポート
※LinuxKit: Docker社などが中心となって開発しているコンテナホスト専用OS
Kubernetes関連のコード自体は以前からlinuxkit/linuxkitリポジトリに入っていたが，より正式な位置に格上げされる．(リポジトリはlinuxkit/linuxkitから分かれるかもしれない． https://github.com/linuxkit/linuxkit/issues/2463)
CRI-containerdにも対応している．
Docker社が今後，Kubernetesとどう関わっていくつもりなのかは，DockerCon EU(10月@コペンハーゲン)で発表があるかもしれない．
新コマンド: docker trust (Notary統合)
docker trust sign foo/bar:bazコマンドを実行するだけで，イメージへの署名・pushを簡単に実施できるようになった．
Docker 17.10から利用可能となる見込み．
Multi-platform image
従来は例えばgolangのAMD64版イメージ(golang)，S390X版イメージ(s390x/golang)，Windows版イメージ(golang:nanoserver)は別々に分かれていたが，今後は単一のgolangイメージに統一される．
もちろん，実行されるバイナリは，プラットフォームによって異なる．
Moby Technical Steering Committee発足準備
※Moby: Dockerの上流となっているcommunity-drivenなプロジェクト． 大まかには，Docker : Moby Project ≒ RHEL : Fedora と考えてよい．
Moby, containerd, LinuxKitなどの関連プロジェクト間の連絡を支援する組織として，Moby Technical Steering Committeeが10月中に発足する見込み．
従来，Docker社CTOのSolomon Hykesが務めてきた，BDFL (Benevolent Dictator for Life, 「優しい終身の独裁者」)のポストは廃止される．
BuildKitのDockerfile対応
※ BuildKit: 中間言語(LLB)のDAGを用いる，高速な次世代 docker build
中間言語(LLB)に加え，Dockerfileのビルドも可能になった．
DockerfileはLLBのDAGにコンパイルされ，並列実行される．
Dockerfileフロントエンドに固有の部分は，コンテナイメージとして分離されているので，Dockerfile以外の高級言語の実装も容易．
将来的には，Kubernetesなどを用いた分散ビルドも対応予定．
単にランダムなホストにロードバランスするのではなく，どのホストがどのグラフ頂点のキャッシュを持っているかなどの情報も勘案したスケジューリングが可能となる予定．
Kubernetes関連
Kubernetes 1.8
RBAC正式サポート，TLSのローテーションなどセキュリティ関連の改善が重要そう．
Pivotal Container Service (PKS)
GKE互換のクラスタを，オンプレミスや，GCP以外のクラウドにも簡単に構築できる．
Rancher関連
Rancher 2.0 alpha
http://rancher.com/announcing-rancher-2-0/
https://rancher.com/docs/rancher/v2.0/en/faq/
Rancher 1.Xは，Cattle, Kubernetes, Docker Swarm, Mesosを比較的対等に扱っていたように思えるが，Rancher 2.0ではKubernetesが中心に据えられるようになった．
Rancher 2.0では，CattleはKubernetesのフロントエンドとして動作する．
system-docker 削除中
system servicesはcontainerdを用いて動くようになる．
Mesos・Mesosphere関連
DC/OSがKubernetesをサポート
OpenFaaS (旧alexellis/faas)
alexellis/faas -> openfaas/faas
https://github.com/openfaas/faas/pull/220
https://www.openfaas.com/
最近流行っている気がする．
ランタイム関連
containerd
Dockerではなくcontainerdをランタイムとして，Kubernetesを実行できるようになった．
今のところ，containerdはβ版，CRI-containerd (containerdとKubernetesの中間モジュール)はα版．
CRI-O
containerdに類似する代替ランタイムであるCRI-OはRC版に達した．
2018年は，containerdとCRI-Oの競争が話題になりそう．
CRIランタイムとして使う分には，containerdもCRI-Oもあまり違いはない．
containerdは，CRIよりも細分化された独自APIを持っており，また，下位ランタイムやスナップショッタなどのプラグインを簡単に差し替えできるように設計されているため，CRI-Oよりもユースケースが広い．
NVIDIA container runtime
runcの代替ランタイムとして，DockerやKubernetesから使うことができる．
nvidia-dockerより簡単に使えるようになりそう．
自分自身のこと
Moby (Docker)，BuildKitに加えて，containerdのメンテナにしてもらった．