KubeWeekly #183

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

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

# The Headlines

## Announcing the CNCF Kubernetes Project Journey Report - Cloud Native Computing Foundation
<table>
<tr>
  <td colspan="2"><a href="https://www.cncf.io/blog/2019/08/29/announcing-the-cncf-kubernetes-project-journey-report/">Announcing the CNCF Kubernetes Project Journey Report - Cloud Native Computing Foundation</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://www.cncf.io/wp-content/uploads/2017/12/icon_cncf_twitter.png"></td>
  <td>Today we are very excited to release our first Project Journey Report for Kubernetes. This is the first of several such reports we’ll be issuing for CNCF graduated projects. Here’s...</td>
</tr>
</table>

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

## [Bootstrapping a Kubernetes Cluster on AWS with Cluster API](https://blog.scottlowe.org/2019/08/27/bootstrapping-a-kubernetes-cluster-on-aws-with-clusterapi/)

ClusterAPIをつかってAWS上にmanagedなKubernetesクラスタを作成する手順の紹介。
Management ClusterというClusterAPIのコントローラを動かすためのクラスタをデプロイし、以降はそれを使ってmanagedなKubernetesクラスタを作ることができる。

# Surveys

サーベイのシーズンだそうで、それ用のコーナーが新設されていました。
意見がある人は是非回答してみてください。

- [Cloud Native Survey 2019](https://www.surveymonkey.com/r/cloudnativesurvey2019)
  - CNCFのサーベイ（抽選でAmazonギフト券がもらえます）
- [CNCF Storage Survey](https://www.surveymonkey.com/r/CNCF-Storage_Survey)
  - CNCFのストレージWGのサーベイ
- [Kubernetes SIG Docs Survey 2019](https://www.surveymonkey.com/r/8R237FN)
  - KubernetesのSIG Docsのサーベイ
- [General Messaging Survey](https://www.surveymonkey.com/r/YW2TDYK)
  - NATSチームのサーベイ（抽選でAmazonギフト券がもらえます）

# The Technical

## Helm v3 Beta 1 Released
<table>
<tr>
  <td colspan="2"><a href="https://helm.sh/blog/helm-v3-beta/">Helm v3 Beta 1 Released</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://helm.sh/img/favicon-152.png"></td>
  <td>Helm - The Kubernetes Package Manager.</td>
</tr>
</table>

Helmのv3のBeta 1がリリースされました。
Helm v2系との主な違いがざっと紹介されている。

Tillerを入れる必要がなくなり、公式リポジトリは[Helm Hub](https://hub.helm.sh/)に集約されるようです。

## Announcing etcd 3.4
<table>
<tr>
  <td colspan="2"><a href="https://kubernetes.io/blog/2019/08/30/announcing-etcd-3-4/">Announcing etcd 3.4</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://kubernetes.io//images/blog/2019-08-30-announcing-etcd-3.4/figure-1.png"></td>
  <td>Authors: Gyuho Lee (Amazon Web Services, @gyuho), Jingyi Hu (Google, @jingyih)
etcd 3.4 focuses on stability, performance and ease of operation, with features like pre-vote and non-voting member and improvements to storage backend and client balancer.
Please see CHANGELOG for full lists of changes.
Better Storage Backend etcd v3.4 includes a number of performance improvements for large scale Kubernetes workloads.
In particular, etcd experienced performance issues with a large number of concurrent read transactions even when there is no write (e.</td>
</tr>
</table>

etcd v3.4がリリースされました。未commit時に不必要にreadがブロックされるケースがなくなり性能向上されました。
それにともないコンパクションも効率化されました。またリーダー選出についてもアルゴリズムが改良されています。
他にもデータが空でクラスタに参加するメンバをLearnerという投票権のないものとして扱うような変更や、クラアントのロードバランス機能の刷新など多くの変更が行われています。

## ricoberger/vault-secrets-operator
<table>
<tr>
  <td colspan="2"><a href="https://github.com/ricoberger/vault-secrets-operator">ricoberger/vault-secrets-operator</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://repository-images.githubusercontent.com/204312226/3f197100-c9e0-11e9-8a4a-7d6f91c8f565"></td>
  <td>Create Kubernetes secrets from Vault for a secure GitOps based workflow. - ricoberger/vault-secrets-operator</td>
</tr>
</table>

Vaultからいい感じにSecretの値を読み取ってKubernetesのSecretリソースを作成してくれるオペレータ。
CRDであるVaultSecretにVaultのパスを書いておく仕組み。

## Adopting Istio for a multi-tenant kubernetes cluster in Production
<table>
<tr>
  <td colspan="2"><a href="https://medium.com/@vbanthia/adopting-istio-for-a-multi-tenant-kubernetes-cluster-in-production-df1a8260ca24">Adopting Istio for a multi-tenant kubernetes cluster in Production</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://miro.medium.com/max/1200/1*Bvfr-oVuu-UK_ku8u-PMog.png"></td>
  <td>This is the 3rd blog post for mercari’s bold challenge month</td>
</tr>
</table>

メルカリのエンジニアによるマルチテナント・シングルKubernetsクラスタにおけるIstioの話。

モノリスからマイクロサービスに移行するにあたり、サーキットブレイカーやレートリミットの機能が必要となった。またgRPCのロードバランスをアプリケーションに手を加えることなく実現したかった。
Istio導入にあたっては1度に1つの機能を導入するという戦略で行なった。
Istioが挿入するサイドカーのライフサイクル管理も気を使った。メインとなるマイクロサービスはサイドカーが起動した後に立ち上がり、サイドカーが終了した後に終了する必要がある。これを実現するためには、アドホックなフックを実装する必要があったようです。
またローリングアップデート時にサービス断を発生させないためにPodの終了時に30秒のSleepを入れたり、サイドカーのヘルスチェックを早めに失敗させるなどの工夫をしています。

などなど興味深い話がたくさん。メルカリでは少しずつgRPCのロードバランスのためにIstioを導入し始めている　というステータスのようです。

## DNS Spoofing on Kubernetes Clusters
<table>
<tr>
  <td colspan="2"><a href="https://blog.aquasec.com/dns-spoofing-kubernetes-clusters">DNS Spoofing on Kubernetes Clusters</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://blog.aquasec.com/hubfs/Spoofing%20in%20Kubernetes%20Resource%20Thumbnail.jpg#keepProtocol"></td>
  <td>Describes how an attacker can successfully spoof DNS responses to all apps running on a K8s cluster, and from there execute a MITM attack.</td>
</tr>
</table>

攻撃者がクラスタに忍び込んでDNSに細工をする方法を紹介。
コンテナが隔離されていたとしても、net_rawというCapabilityがついていると、同じノードに来たARPやDNSのパケットを盗み見たり、改ざんしたりすることができる。
このCapabilityはデフォルトでは有効となっているため、この攻撃を避けるためには意図的に無効にする必要がある。

## Network Architecture Design for Microservices on GCP
<table>
<tr>
  <td colspan="2"><a href="https://medium.com/@lainra/network-architecture-design-for-microservices-on-gcp-ce8d10d5396e">Network Architecture Design for Microservices on GCP</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://miro.medium.com/max/1200/1*QuqkEpEukZOQw85U7thxkw.png"></td>
  <td>A tale about thinking, planning, and designing a network architecture for large-scale microservices on GCP in a post-IPO company.</td>
</tr>
</table>

メルカリにてGCPでのネットワーク設計をどのように行なっているかという話。現状の問題と、それを解決するための方法という形で紹介されている。

- Challenge 1: Multi-tenancy design
- Challenge 2: Which network ownership model should we use to enforce IP address management?
- Challenge 3: How big do we need to think?
- Challenge 4: Private IPv4 addresses exhaustion
- Challenge 5: Identifying edge cases
- Challenge 6: Managing multiple regions in a Shared VPC
- Challenge 7: Making GCE instances private only

どれも興味深い挑戦です。

## Non-root containers, Kubernetes CVE-2019-11245 and why you should care | Twistlock
<table>
<tr>
  <td colspan="2"><a href="https://www.twistlock.com/labs-blog/non-root-containers-kubernetes-cve-2019-11245-care/">Non-root containers, Kubernetes CVE-2019-11245 and why you should care | Twistlock</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://www.twistlock.com/wp-content/uploads/2019/08/Non-root-containers-blog-banner-1.png"></td>
  <td>On May 31th, the Kubernetes Product Security Committee announced a security regression in Kubernetes for which they had assigned CVE-2019-11245. The problem caused containers that use images which are supposed to run with a non root user to run as root, on the second time they are used or upon restart of the container. Before …</td>
</tr>
</table>

kubeletのv1.13.6 と v1.14.2に入り込んだ脆弱性についての紹介。コンテナの2回目移行の実行において、non-rootユーザに指定していたとしてもrootユーザとして実行されてしまうという、ちょっと怖い脆弱性のようです。
また、それに関連してuser namespaceやrootless containersの取り組みも紹介されている。

## Architecting Kubernetes clusters — choosing a worker node size
<table>
<tr>
  <td colspan="2"><a href="https://learnk8s.io/kubernetes-node-size">Architecting Kubernetes clusters — choosing a worker node size</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://learnk8s.io/a/c4beabbc0e974fd220dd5f132fb7f428.png"></td>
  <td>When you create a Kubernetes cluster, one of the first questions that pops up is: "what type of worker nodes should I use, and how many of them?". This article looks at the pros and cons of either using many small or few large worker nodes in your cluster.</td>
</tr>
</table>

KubernetesクラスタののWorkerの数や大きさをどのように決めれば良いか？という内容の記事。
わかりやすいイラスト付きで利点・欠点を紹介してあり参考になります。

## Cronjob 101 part 2
<table>
<tr>
  <td colspan="2"><a href="https://medium.com/@cols.knil/cronjob-101-part-2-78503d3967b3">Cronjob 101 part 2</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://miro.medium.com/max/1200/1*_HISJmlPTO2yXBPDx93omg.jpeg"></td>
  <td>Hello there for the second part of cronjob 101.</td>
</tr>
</table>

cronjobについての紹介。

下記でcronjobからjobを作れるらしい。(知らなかった)

```
kubectl create job --from=cronjob/<cronjob_name> job_name
```

これを利用したcronjobの開発のワークフローを紹介している。
まずsuspendedでcronjobを作成し、上記の方法でjobとしてワンショット実行。うまく動かない場合はcronjobを変更し、再び上の方法でjobとして実行。を繰り返す。

こうすることでcronjobのテストのためにscheduleを細かくいじる必要がなくなる。

ほかにもCronJobを扱う上での便利なTipsがいくつか紹介されている。

# The Editorial

## kind, with Ben Elder
<table>
<tr>
  <td colspan="2"><a href="https://kubernetespodcast.com/episode/069-kind/">kind, with Ben Elder</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://kubernetespodcast.com/_assets/images/Kubernetes-Podcast-Logo_1400x1400.png"></td>
</tr>
</table>

Kubernetes Podcast。今回はkindの作者がゲスト。

## What's Next for Vault and Kubernetes
<table>
<tr>
  <td colspan="2"><a href="https://www.hashicorp.com/blog/whats-next-for-vault-and-kubernetes">What's Next for Vault and Kubernetes</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://www.datocms-assets.com/2885/1508522484-share.jpg?format=auto&w=900"></td>
  <td>We're excited to announce multiple features that deeply integrate HashiCorp Vault with Kubernetes. This post will share the initial set of features that will be released in the com...</td>
</tr>
</table>

Hashicorp VaultのKubernetes向け機能と、そのロードマップの紹介。
Helmでのリリースはもう提供されおり、さらにサイドカーを使うことでアプリケーションに手を加えることなくPodに秘密情報を受け渡す方法を提供する予定のようだ。
またKubernetesのSecretとの同期機能や、CSIプラグインとしての実装なども絶賛議論中とのこと。

## Kubernetes security audit: What GKE and Anthos users need to know | Google Cloud Blog
<table>
<tr>
  <td colspan="2"><a href="https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-security-audit-what-gke-and-anthos-users-need-to-know/">Kubernetes security audit: What GKE and Anthos users need to know | Google Cloud Blog</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://storage.googleapis.com/gweb-cloudblog-publish/original_images/Exploring_container_security.png"></td>
  <td>Read about the implications of the first Kubernetes security audit on GKE and Anthos.</td>
</tr>
</table>

CNCF主導のKubernetesのセキュリティ監査の結果を受けて、GKEやAnthosのユーザが何をすべきか？という内容の記事。
基本的にコントロールプレーンはmanagedなので利用者はNodeを適切にアップデートしてれば良い、とのこと。

また今回の監査で見つかった問題についてのIssueを網羅的にリンクしている[dashboardのIssue](https://github.com/kubernetes/kubernetes/issues/81146)も紹介されている。

## A beginner’s guide to container security
<table>
<tr>
  <td colspan="2"><a href="https://about.gitlab.com/2019/08/27/beginners-guide-container-security/">A beginner’s guide to container security</a></td>
</tr>
<tr>
  <td><img width="320px" src="https://about.gitlab.com/images/blogimages/container-security-beginners.jpg"></td>
  <td>Container adoption is growing, but traditional security methods can’t keep up.</td>
</tr>
</table>

コンテナを扱う際のセキュリティ強化のポイントについて。

コンテナ特有のセキュリティの配慮が必要だという説明ののちに、アメリカ合衆国商務省が定めたコンテナセキュリティのガイドラインの内容について、そのサマリを紹介している。

- コンテナでの開発フローに組織の文化や開発手法を適合させる
- ホストOSには最小のコンポーネントのみを入れる
- 同じ役割やセキュリティ要件のコンテナをグループ化し同じホストに配置する
- コンテナに特化した脆弱性の検知手法や、改ざん検知の仕組みを利用する
- 信頼性担保のためにハードウェアに搭載されているセキュリティモジュール（TPMなど）を利用する
- コンテナ用のランタイム防御システム（異常な振る舞いの検知ツールなど）を利用する