Kube Weekly #192

KubeWeeklyは毎週Kubernetesに関する興味深いニュースを提供しています。（https://kubeweekly.io/ ）この記事は 2019/11/11に発行された [Kube Weekly #192](https://kubeweekly.io/2019/11/11/kubeweekly-192/)を読んで、感じたことをメモ的にまとめたものです。
私の勘違いや説明不足による誤解もあるかと思いますので、この記事読んで「おっ」と思ったらURLを辿って本文を確認してください。

(過去のKubeWeekly読書メモは[こちら](https://qiita.com/tags/kubeweekly))

※この記事は、[Z Lab](https://qiita.com/organizations/zlab)の業務の一環として(KubeCon出張中に)作成したものです。



# The Headlines

## We built network isolation for 1,500 services to make Monzo more secure
<table>
<tr>
  <td colspan="2"><a href="https://monzo.com/blog/we-built-network-isolation-for-1-500-services">We built network isolation for 1,500 services to make Monzo more secure</a></td>
</tr>
<tr>
  <td><img src="https://images.ctfassets.net/ro61k101ee59/4TVZDWCvNFXt9iki2yK6En/e51d9e15c9886781fd14cbf6e42a2666/_Blogpost__We_built_network_isolation_for_1_500_services_Saving_Money__1_.png"></td>
  <td>We've been working on isolating the 1,500 services that power Monzo. The sheer size and complexity of our platform made this difficult. But by protecting us against compromised services, it makes Monzo more secure.</td>
</tr>
</table>

サービス間通信を許可制にする方法。基本的にはNetworkPolicyを使うが、誤ったポリシーを導入すると提供しているサービスに影響が出てしまう。
そこで、CalicoのNeetworkPolicyを使いパケットを落とすことではなくログを出力するようにし、落ちているパケットを事前にわかるようにして移行を進めていった話。

またそのほかにもサービスのNetWorkPolicyをうまく設定するための方法を紹介している。

## CNCF Prometheus Project Journey - Cloud Native Computing Foundation
<table>
<tr>
  <td colspan="2"><a href="https://www.cncf.io/cncf-prometheus-project-journey/">CNCF Prometheus Project Journey - Cloud Native Computing Foundation</a></td>
</tr>
<tr>
  <td><img src="https://www.cncf.io/wp-content/uploads/2017/12/icon_cncf_twitter.png"></td>
</tr>
</table>

PrometheusのProject Journey
ここまでのPrometheusの歩みを数値をベースに紹介しているレポート。この記事では特に印象的なグラフをいくつか紹介している。

# The Technical

## Inviting Security to the Party - Part I - Delivery Hero Tech
<table>
<tr>
  <td colspan="2"><a href="https://tech.deliveryhero.com/inviting-security-to-the-party-part-i/">Inviting Security to the Party - Part I - Delivery Hero Tech</a></td>
</tr>
<tr>
  <td><img src="https://tech.deliveryhero.com/wp-content/uploads/2019/10/IMG_20191029_150007.jpg"></td>
  <td>In the last year, our Restaurant Partner Solutions (RPS) vertical faced a massive cultural change when our containers orchestration migrated from ECS to EKS. Currently, YAML+terraform is the language spoken in our tribe. Before that, we used to speak JSON+cloudformation and it would take roughly one week to create a new service. Since our migration …</td>
</tr>
</table>

とある会社のKubernetesセキュリティの事例。コンテナのスキャンにanchore-engineを使い、admission-controlでスキャンを実施し、その通知はSlackのbotで通知するようにしている。
anchoreのこういった機能はエンタープライズ版にのみ存在するが、この会社ではそれは使わずOSSを組み合わせたり、自作したりして実現しているようです。

## Kubernetes Beyond by Andrea Tosatto
<table>
<tr>
  <td colspan="2"><a href="/talks/cncf-italy/2019/07/04/kubernetes-beyond-andrea-tosatto.html">Kubernetes Beyond by Andrea Tosatto</a></td>
</tr>
<tr>
  <td><img src="https://devcampy.com//img/kubernetes-beyond-andrea.png"></td>
</tr>
</table>

[以前紹介しました](https://qiita.com/inajob/items/357c1ccb7ecf4e069a20#kubernetes-beyond-by-andrea-tosatto)

> CRDをつかってKubernetesをどのように拡張するか、という内容の動画の紹介。

## Provision a Kubernetes Cluster in Amazon EKS with Weaveworks eksctl and AWS CDK
<table>
<tr>
  <td colspan="2"><a href="https://blog.reactioncommerce.com/deploying-kubernetes-clusters-in-aws-eks-with-the-aws-cloud-development-kit/">Provision a Kubernetes Cluster in Amazon EKS with Weaveworks eksctl and AWS CDK</a></td>
</tr>
<tr>
  <td><img src="https://blog.reactioncommerce.com/content/images/2019/10/cloud-computing-4099960_1920.jpg"></td>
  <td>The Reaction Commerce infrastructure team uses Infrastructure as Code (IaC) tooling to describe the resources that need to be provisioned (especially cloud computing resources such as Amazon Web Services) by means of code. We do so because manual provisioning is error prone. What is not automated will come back and</td>
</tr>
</table>

宣言的に構成を管理できる [AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/home.html), Weaveworksのeksctlのそれぞれを使いEKSを構築する手法を紹介。

同じように宣言的にEKSを構築することができるが、シェルスクリプトがメインになりがちなeksctl, TypeScriptなどの言語で構成を記述できるAWS CDKでそれぞれ特徴があることがわかります。

## Migrating your app to Kubernetes: what to do with files?
<table>
<tr>
  <td colspan="2"><a href="https://medium.com/flant-com/stateful-app-files-in-kubernetes-d015311e5e6b">Migrating your app to Kubernetes: what to do with files?</a></td>
</tr>
<tr>
  <td><img src="https://miro.medium.com/max/780/0*yo1rbNvYrj0sko1y.png"></td>
  <td>Workarounds and recommendations for your stateful app</td>
</tr>
</table>

従来から存在するステートを持つアプリケーションをKubernetes上で動作するように改変する際によく使うワークアラウンドの紹介。
この記事で紹介しているのはあくまでワークアラウンドであり、本当は12FactorAppを見直して1から設計を見直すのが良いとされている。
しかし、移行に必要な作業量を考えるとこのようなワークアラウンドが有用な場合もあるということのようです。

## KUDO, with Gerred Dillon
<table>
<tr>
  <td colspan="2"><a href="https://kubernetespodcast.com/episode/078-kudo/">KUDO, with Gerred Dillon</a></td>
</tr>
<tr>
  <td><img src="https://kubernetespodcast.com/_assets/images/Kubernetes-Podcast-Logo_1400x1400.png"></td>
</tr>
</table>

[KUDO](https://kudo.dev/)というKubernetesオペレータを作成するためのフレームワークを作っているGerred Dillonを招いてのKuberenetes Podcast

## Announcing Backyards 1.0 · Banzai Cloud
<table>
<tr>
  <td colspan="2"><a href="https://banzaicloud.com/blog/backyards-release-1-0/">Announcing Backyards 1.0 · Banzai Cloud</a></td>
</tr>
<tr>
  <td><img src="https://banzaicloud.com/img/m-logo-inverse.png"></td>
  <td>Bringing cloud native to the enterprise, simplifying the transition to microservices on Kubernetes</td>
</tr>
</table>


[Backyards](https://github.com/banzaicloud/backyards-cli)というBonzai Cloudが作るサービスメッシュが1.0となった話。
これはIstioを元にしたソリューションで、Istioのデプロイを簡単に行い、またサービスメッシュの設定をWebUIやCLIで簡単に行うことができるというもののようです。

## Announcing Contour 1.0: A Proxy for Your Multi-Tenant Future
<table>
<tr>
  <td colspan="2"><a href="https://projectcontour.io/announcing-contour-1.0/">Announcing Contour 1.0: A Proxy for Your Multi-Tenant Future</a></td>
</tr>
<tr>
  <td><img src="https://projectcontour.io//img/Contour.svg"></td>
  <td>The Journey from 0.1 to 1.0</td>
</tr>
</table>

2年の時を経てContourの1.0がリリースされます。CRD名がIngressRouteからHTTPProxyに変わったり、今まで同一PodにいたContourとEnvoyを別々にするなどの大きな変更があったようです。

## From image security to workload security | Snyk
<table>
<tr>
  <td colspan="2"><a href="https://snyk.io/blog/from-image-security-to-workload-security/">From image security to workload security | Snyk</a></td>
</tr>
<tr>
  <td><img src="https://snyk.io/wp-content/uploads/container-scans.png"></td>
  <td>This is the third part of a four part series about building your Kubernetes AppSec strategy. Part I Part II In one of our previous posts we discussed how</td>
</tr>
</table>

software development lifecycle（SDLC)という切り口でコンテナ全般のセキュリティチェックについて紹介しているブログシリーズの第3弾
Kubernetesのマニフェストはデフォルトの設定では、危険なものがいくつか存在する。それらを software development lifecycle (SDLC) のどの段階で検知するのか？という話。

# The Editorial

## Vitess, the database clustering system powering YouTube, graduates CNCF incubation - SiliconANGLE
<table>
<tr>
  <td colspan="2"><a href="https://siliconangle.com/2019/11/05/vitess-database-clustering-system-powering-youtube-graduates-cncf-incubation/">Vitess, the database clustering system powering YouTube, graduates CNCF incubation - SiliconANGLE</a></td>
</tr>
<tr>
  <td><img src="https://d15shllkswkct0.cloudfront.net/wp-content/blogs.dir/1/files/2019/11/data-center.png"></td>
  <td>Vitess, the database clustering system powering YouTube, graduates CNCF incubation - SiliconANGLE</td>
</tr>
</table>

データベースクラスタリングシステムである[Vitess](https://vitess.io/)がCNCFの Graduated Projectとなった。

## Longhorn Accepted into CNCF
<table>
<tr>
  <td colspan="2"><a href="https://rancher.com/blog/2019/longhorn-accepted-into-cncf/">Longhorn Accepted into CNCF</a></td>
</tr>
<tr>
  <td><img src="https://rancher.com/img/blog/2019/longhorn-cncf/longhorn-how-it-works.png"></td>
  <td>Today I am very excited to announce that Rancher Labs' Project Longhorn has been accepted by the Cloud Native Computing Foundation as a sandbox project.</td>
</tr>
</table>

Kubernetes向けのブロックストレージであるLonghornがCNCF sandbox Projectに採択された。

## Serverless Specification CloudEvents Reaches Version 1.0 - Cloud Native Computing Foundation
<table>
<tr>
  <td colspan="2"><a href="https://www.cncf.io/announcement/2019/10/28/serverless-specification-cloudevents-reaches-version-1-0/">Serverless Specification CloudEvents Reaches Version 1.0 - Cloud Native Computing Foundation</a></td>
</tr>
<tr>
  <td><img src="https://www.cncf.io/wp-content/uploads/2017/12/icon_cncf_twitter.png"></td>
  <td>Specification for events has reached maturity, creating an industry-wide collaboration for open source serverless technologies  SAN FRANCISCO, Calif. – October 28, 2019 – The Cloud Native Computing Foundation® (CNCF®), which...</td>
</tr>
</table>

CloudEventの仕様が1.0となった。またCNCFのSandbox Project からIncubation Projectになった。
CloudEventはKnative, EventFlow, Vert.x, Kyma, Event Gatewayなどですでに採用されているようです。

## What Service Meshes Are, and Why Istio Leads the Pack
<table>
<tr>
  <td colspan="2"><a href="https://www.datacenterknowledge.com/open-source/what-service-meshes-are-and-why-istio-leads-pack">What Service Meshes Are, and Why Istio Leads the Pack</a></td>
</tr>
<tr>
  <td><img src="https://www.datacenterknowledge.com/sites/datacenterknowledge.com/files/Majd%20Bakar%20google%20data%20center%20GDC%202019%20getty.jpg"></td>
  <td>Cloud-native technologies like containers and microservices have made infrastructure infinitely more complex. Service meshes are there to help.</td>
</tr>
</table>

サービスメッシュの紹介、実装の紹介。特にIstioについて、特徴紹介や現時点での問題点などを紹介している。
GoogleのIstioではマネージメントプレーンが存在していたが、今のIstioにはそれがない。というのは初めて知った。ほかにも機能が多すぎて難しすぎるなど、Istioの課題についても述べられている。

## Knative = Kubernetes Networking++
<table>
<tr>
  <td colspan="2"><a href="https://ahmet.im/blog/knative-better-kubernetes-networking/">Knative = Kubernetes Networking++</a></td>
</tr>
</table>

knativeのServingの特にネットワーク周りの動作を解説。
Deployment+Serviceとは何が違うのか？Istioは必須なのか？などなど

## The Two Most Important Challenges with an API Gateway when Adopting Kubernetes | Ambassador
<table>
<tr>
  <td colspan="2"><a href="https://www.getambassador.io/resources/challenges-api-gateway-kubernetes/">The Two Most Important Challenges with an API Gateway when Adopting Kubernetes | Ambassador</a></td>
</tr>
</table>

マイクロサービス化を行う上で欠かすことができないAPI Gatewayの紹介となぜそれが必要なのかという話。
Ambassadorのブログだが、特別Ambassadorに特化した話ではない。Ingressや他のAPI Gatewayでも当てはまりそう。

## Hands-on guide: developing and deploying Node.js apps in Kubernetes
<table>
<tr>
  <td colspan="2"><a href="https://learnk8s.io/nodejs-kubernetes-guide">Hands-on guide: developing and deploying Node.js apps in Kubernetes</a></td>
</tr>
<tr>
  <td><img src="https://learnk8s.io/a/0f203e870172f5bd70954e7365433e4a.jpg"></td>
  <td>Learning how to design and architect applications that leverage Kubernetes is the most valuable skill that you could learn to be successful in deploying and scaling your traffic to millions of requests and beyond.</td>
</tr>
</table>

nodejsとMongoDBを使ったアプリケーションをDocker化し、Dockerで動作確認をしたのちに、Kubernetesのリソースを記述し、デプロイするまでの流れを紹介した非常に丁寧なドキュメント。
リファクタリング、クラウド環境へのデプロイは、e-mailすると無料でもらえるそうです。