KubeWeekly #200

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

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

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

# The Headlines 

## 2019 CNCF Annual Report  - Cloud Native Computing Foundation
<table>
<tr>
  <td colspan="2"><a href="https://www.cncf.io/blog/2020/01/21/2019-cncf-annual-report/">2019 CNCF Annual Report  - 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>The Cloud Native Computing Foundation (CNCF) annual report for 2019 is now available. The report highlights the growth of the community, events, projects, and more, over the past year. As...</td>
</tr>
</table>

2019年のCNCFのレポートの紹介。
CNCFは4年目ということで、様々な数字が紹介されている。

[レポート本体](https://www.cncf.io/cncf-annual-report-2019/)も非常に見やすくまとめられている。

## Istio as an Example of When Not to Do Microservices
<table>
<tr>
  <td colspan="2"><a href="https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/">Istio as an Example of When Not to Do Microservices</a></td>
</tr>
<tr>
  <td><img src="https://blog.christianposta.com/images/bio-photo.jpg"></td>
  <td>I’ve been pretty invested in helping organizations with their cloud-native journeys for the last five years. Modernizing and improving a team (and eventually an organization’s) velocity to deliver software-based technology is heavily influenced by its people, process and eventual technology decisions. A microservices approach may be appropriate when the culmination of an application’s architecture has become a bottleneck (as a result of the various people/process/tech factors) for making changes and “going faster”, but it is not the only approach.

</td>
</tr>
</table>

何でもかんでもマイクロサービスにすべきではない、という話の1つとしてIstioの例を紹介している。
Istioは徐々にマイクロサービスからモノリスへと変化してきているとのこと。

マイクロサービスの利点は数多く紹介されるが、その代償として複雑さが増すということが挙げられる。
このトレードオフをよく考えてマイクロサービスにすべきかを検討する必要がある。

# The Technical

## An Ultimate Kubernetes Hands-on Labs
<table>
<tr>
  <td colspan="2"><a href="https://collabnix.github.io/kubelabs/">An Ultimate Kubernetes Hands-on Labs</a></td>
</tr>
<tr>
  <td><img src="https://raw.githubusercontent.com/collabnix/dockerlabs/master/ic_launcher.png"></td>
  <td>Kubernetes - Beginners Intermediate Advanced</td>
</tr>
</table>

Kubernetesを学ぶためのハンズオン資料。
実際の作業を通してKubernetesを学ぶための教材。ありそうでなかったコンテンツ。
同じフォーマットでほぼ全てのリソースのハンズオンが用意されているのはありがたい。

もう少し作りかけのところもあるが、期待できるプロジェクトです。

## CSI Ephemeral Inline Volumes
<table>
<tr>
  <td colspan="2"><a href="https://kubernetes.io/blog/2020/01/21/csi-ephemeral-inline-volumes/">CSI Ephemeral Inline Volumes</a></td>
</tr>
<tr>
  
  <td>Author: Patrick Ohly (Intel)
Typically, volumes provided by an external storage driver in Kubernetes are persistent, with a lifecycle that is completely independent of pods or (as a special case) loosely coupled to the first pod which uses a volume (late binding mode). The mechanism for requesting and defining such volumes in Kubernetes are Persistent Volume Claim (PVC) and Persistent Volume (PV) objects. Originally, volumes that are backed by a Container Storage Interface (CSI) driver could only be used via this PVC/PV mechanism.</td>
</tr>
</table>

CSI Ephemeral Inline Volumesの紹介。
これはkubernetesの1.15から使える機能で、CSIの仕組みでPodと同じ生存期間のボリュームを扱うためのものです。

Podと同じ生存期間のボリュームの例として、動的にPodに対して払い出されるSecretや、ローカルディスクのようなもの、不揮発メモリなどが挙げられています。

この記事では特に不揮発メモリとコンテナイメージをボリュームとしてマウントする例について紹介されています。

## Threat Alert: Exploiting Open Docker Daemons for DDoS Attacks
<table>
<tr>
  <td colspan="2"><a href="https://blog.aquasec.com/threat-alert-ddos-attack-docker-daemons">Threat Alert: Exploiting Open Docker Daemons for DDoS Attacks</a></td>
</tr>
<tr>
  <td><img src="https://blog.aquasec.com/hubfs/Blog/Ddos%20attack%20Docker%20Daemons/DDos%20blog%20image_2.jpg#keepProtocol"></td>
  <td>Aqua’s research team identified attacks that exploited misconfigured open Docker daemons to hijack environments in order to launch targeted DDoS attacks.</td>
</tr>
</table>

設定ミスによりインターネットに晒されているDocker Daemonに侵入してDDoS攻撃を行うbotnetが形成されているという話。
またそれらの攻撃の例としてudpfloodとslowhttptestを紹介している。
これらはオープンソースのツールを改造して作られたもののようです。

## Kyma - An easy way to extend enterprise applications on Kubernetes.
<table>
<tr>
  <td colspan="2"><a href="https://kyma-project.io/blog/2020/1/16/integration-testing-in-k8s">Kyma - An easy way to extend enterprise applications on Kubernetes.</a></td>
</tr>
<tr>
  <td><img src="https://kyma-project.io/facebookLogo.png"></td>
  <td>Kyma is an open-source project designed natively on Kubernetes. It allows you to extend enterprise applications in a quick and modern way, using serverless computing or microservice architecture.</td>
</tr>
</table>

Kubernetesクラスタ上での統合テストの環境として以前は[Helm test](https://helm.sh/docs/topics/chart_tests/)という、簡単にいうと特定のannotationのついたJobを実行するというものを使っていたが、色々足りないとところが出てきたので[Octopus](https://github.com/kyma-incubator/octopus/blob/master/README.md)というツールを作ったという話。

OctopusはKubernetesでテストを扱うためのコントローラです。TestDefinitionやClusterTestSuiteといったCRDを使ってテストを定義します。

Octopusの利点として下記を挙げています

- 実施するテストをラベルで選択できる
- 失敗したテストについて自動でリトライできる
- テストを指定した回数実行できる
- 並行してテストできる
- テスト結果を可視化できる

## Guide to Kubernetes Egress Network Policies · StackRox: Cloud-Native, Container, and Kubernetes Security
<table>
<tr>
  <td colspan="2"><a href="https://www.stackrox.com/post/2020/01/kubernetes-egress-network-policies/">Guide to Kubernetes Egress Network Policies · StackRox: Cloud-Native, Container, and Kubernetes Security</a></td>
</tr>
<tr>
  <td><img src="https://res.cloudinary.com/stackrox/v1579130829/kubernetes-egress-network-policies-blog-banner_b7bxqf.jpg"></td>
  <td>Learn about the differences between Kubernetes egress vs ingress network policies and how to allow egress traffic (from a pod to an external network endpoint outside the cluster)</td>
</tr>
</table>

NetworkPolicyの特にegressのルールについて紹介。
まずはingressについて設定し、その後egressを設定することを勧めている。
ハンズオン形式で、わかりやすくegressの設定方法が紹介されている。

[この話の前提となるingressについての記事はこちら](https://www.stackrox.com/post/2019/04/setting-up-kubernetes-network-policies-a-detailed-guide/)

## Kubernetes on MIPS
<table>
<tr>
  <td colspan="2"><a href="https://kubernetes.io/blog/2020/01/15/kubernetes-on-mips/">Kubernetes on MIPS</a></td>
</tr>
<tr>
  <td><img src="https://kubernetes.io//images/blog/2020-01-15-Kubernetes-on-MIPS/kubernetes-on-mips.png"></td>
  <td>Authors: TimYin Shi, Dominic Yin, Wang Zhan, Jessica Jiang, Will Cai, Jeffrey Gao, Simon Sun (Inspur)
Background MIPS (Microprocessor without Interlocked Pipelined Stages) is a reduced instruction set computer (RISC) instruction set architecture (ISA), appeared in 1981 and developed by MIPS Technologies. Now MIPS architecture is widely used in many electronic products.
Kubernetes has officially supported a variety of CPU architectures such as x86, arm/arm64, ppc64le, s390x. However, it’s a pity that Kubernetes doesn’t support MIPS.</td>
</tr>
</table>

MIPS向けのKubernetesの紹介。
もともとKubernetesは様々なCPUのアーキテクチャに対応していますx86, arm/arm64, ppc64le, s390x。しかしMIPSはサポートしていませんでした。
そこでMIPS環境でもKubernetesが動くように手動でバイナリを生成し、コンフォーマンステストを通してみた、　といった内容の記事です。

# The Editorial

## Applying GitOps to OpenFaaS with Flux Helm Operator
<table>
<tr>
  <td colspan="2"><a href="https://www.openfaas.com/blog/openfaas-flux/">Applying GitOps to OpenFaaS with Flux Helm Operator</a></td>
</tr>
<tr>
  <td><img src="https://www.openfaas.com/images/2020-openfaas-flux/background.jpg"></td>
  <td>In this tutorial I’ll show you how to set up a GitOps workflow for OpenFaaS with FluxCD and Helm v3.</td>
</tr>
</table>

OpenFaaSでGitOps実現のためにFlux CDとHelm Operatorを組み合わせる例を紹介。
Fluxはマニフェストの変更の検知に加え、コンテナイメージの更新も検知することができます。またGitOpsの仕組みでSecretを管理する際には[Sealed Secrets Controller](https://github.com/bitnami-labs/sealed-secrets)が便利です。

## 4 things cloud-native Java must provide
<table>
<tr>
  <td colspan="2"><a href="https://opensource.com/article/20/1/cloud-native-java">4 things cloud-native Java must provide</a></td>
</tr>
<tr>
  <td><img src="https://opensource.com/sites/default/files/lead-images/coffee_tea_laptop_computer_work_desk.png"></td>
  <td>Java is still the pervasive development language among enterprise developers, even though it is not developers' preferred cloud-native runtime and is falling behind other languages, according to GitHub's Octoverse.</td>
</tr>
</table>

クラウドネイティブ環境においてJava言語に求められる要件について

- 開発生産性の向上（zero-configuration, live coding, easy injection of extensions)
- リアクティブプログラミング（EventBus or Vert.x)
- サーバレスへの最適化(起動の高速化と小さいフットプリント)
- 共通のオープンソースソフトウェアの採用(Kubernetes, Vert.x, RESTEasy, Kafka, Jaeger, Prometheus, Infinispan,...)

## Multitenancy at Cruise, with Karl Isenberg

<table>
<tr>
  <td colspan="2"><a href="https://kubernetespodcast.com/episode/087-multitenancy-at-cruise/">Multitenancy at Cruise, with Karl Isenberg
</a></td>
</tr>
<tr>
  <td><img src="https://kubernetespodcast.com/_assets/images/Kubernetes-Podcast-Logo_1400x1400.png"></td>
</tr>
</table>

GoogleのKubernetes Podcast。
自動運転車を扱うCruise社におけるマルチテナンシーについて。ゲストは、Cruise社のKarl Isenberg。

## Reviewing 2019 in Docs
<table>
<tr>
  <td colspan="2"><a href="https://kubernetes.io/blog/2020/01/21/reviewing-2019-in-docs/">Reviewing 2019 in Docs</a></td>
</tr>
<tr>
  
  <td>Author: Zach Corleissen (Cloud Native Computing Foundation)
Hi, folks! I’m one of the co-chairs for the Kubernetes documentation special interest group (SIG Docs). This blog post is a review of SIG Docs in 2019. Our contributors did amazing work last year, and I want to highlight their successes.
Although I review 2019 in this post, my goal is to point forward to 2020. I observe some trends in SIG Docs–some good, others troubling.</td>
</tr>
</table>

KubernetesのSIG Docsのco-chairによる、2019年振り返り記事。よかったこと。悪かったことがまとめられている。

悪かったこととしては、古い情報が残された記事に加え、図が少ないことがが利用者の満足度を下げていることが挙げられています。
またサードパーティのドキュメントへのコントリビューションの基準が明確でないことも挙げています。
さらに、kubernetesのドキュメントには専属のテクニカルライターが1名しかいないことも大きな問題として認識しているようです。

SIG DocsのChairというのがいかに難しい仕事で、現状のリソースでは、ドキュメントを維持することが難しい旨を主張しています。

## Linkerd 2019 year in review - Cloud Native Computing Foundation
<table>
<tr>
  <td colspan="2"><a href="https://www.cncf.io/blog/2020/01/20/linkerd-2019-year-in-review/">Linkerd 2019 year in review - 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>Linkerd crossed the chasm in 2019. Read about the features, talks, podcasts, security audit, and swag that made the year epic for your fav service mesh.</td>
</tr>
</table>

Linkerdの2019年の振り返り

Linkerdにとっては2019年は大きな変化が起きた年で、これまで「様子見」フェーズだったプロジェクトが「試してみよう」フェーズへと移行しました。
2019に実装された新機能や、セキュリティ監査結果,LinkerdについてのPodcastなどを紹介しています。

## Fedora CoreOS out of preview - Fedora Magazine
<table>
<tr>
  <td colspan="2"><a href="https://fedoramagazine.org/fedora-coreos-out-of-preview/">Fedora CoreOS out of preview - Fedora Magazine</a></td>
</tr>
<tr>
  <td><img src="https://fedoramagazine.org/wp-content/uploads/2019/07/introducing-fedora-coreos.png"></td>
  <td>Fedora CoreOS is a new Fedora Edition built specifically for running containerized workloads securely and at scale. It's now available for general use.</td>
</tr>
</table>

Fedora CoreOSのpreview版が終了し一般利用可能なバージョンが使えるようになりました。
基なっているのはFedora Atomic Hostと CoreOS Container Linuxです。

CoreOS Container Linuxから乗り換える場合は設定ファイルであるContainer Linux Configを Fedora CoreOS Configに書き換える必要があるので注意が必要です。
Fedora Atomic HostはすでにEOLを迎えているので速やかにFedora CoreOSに移行すべきですが、in-placeでのアップデートは非推奨です。Fedora CoreOS Configを書き直して新しいマシンを作るのがオススメです。CoreOS Container Linuxと同様に設定ファイルには差異があるので注意が必要です。