search

oomichi / try-kubernetes

12 stars 5 forks source link

Prepare OpenLab session for OpenStackDays/OpenSourceSummit Tokyo #84

Closed oomichi closed 5 years ago

oomichi commented 5 years ago

7月18日(木) 14:00 OpenSourceSummit Japan、 7月23日(火) OpenStack Days Tokyo で発表する OpenLab セッションの準備を行う。

oomichi commented 5 years ago

シナリオ作成

CFPは20分セッションで登録したはずなのに40分セッションで通ってしまった。 ので40分を前提にシナリオを組む。

  1. 自己紹介（1分） 
    OpenStack Nova, QA Core Developer
OpenStack QA ex-PTL
Kubernetes Approver of test/ in kubernetes/kubernetes repository
  2. OpenLab概要（10分） 
    https://openlabtesting.org/
OpenLab is the playground for open source ecosystem testing, development, and collaboration.
Especially for Open Infrastructure.
OpenLab is a community-led program to test and improve support for the cloud-related SDKs/Tools as well as platforms like Kubernetes, Terraform, CloudFoundry and more. 
The goal is to improve the usability, reliability and resiliency of tools and applications for hybrid and multi-cloud environments.
  3. Kubernetes on OpenStack testing（10分） 
    Kubernetes on OpenStack
- Octavia
- Keystone
- Cinder
Deployment
- OpenStack: Devstack
- Kubernetes: ?
Testing
- Conformance
- Different tests
調べること
- Kubernetes on OpenStack(devstack) on OpenStack IaaS で正しいか
- OpenStack(devstack) の部分は qemu ではなく nested kvm で正しいか
  4. E2E and Conformance tests of Kubernetes（10分） 
    - Overviews
- How to run E2E tests
- How to run Conformance tests
- Change E2E, build and run
  5. Summary（3分）
oomichi commented 5 years ago

assets_-Lgc3odgVkxxnaX3VQr0_-Lgc7_ezWA5WYK8pqYQI_-Lgc7awUJfkqzGXov2US_getting_started-1

atoato88 commented 5 years ago

想定される質問 上のフロー図の中のどこかでgithubとか外部のレポジトリを使うのでしょうか？ それとも全ての作業がopenlabの中で閉じてるのでしょうか？ 開発者としては普段使ってる開発スキームから逸脱したくないと思うはずなのでそのあたりが知りたい。 開発者がgithubにPR出したら、自動でテストされるのが理想ですかね。

oomichi commented 5 years ago

[2] OpenLab概要（10分）

OpenLab を一言で説明するとクラウド関連の Open Source の組合せテストを行うコミュニティ主体のテストベッドです。 ハイブリッドクラウド、マルチクラウド環境における各種ツールのユーザビリティ、信頼性を向上させるために運営されています。 一例として OpenStack 上に Kubernetes クラスタをデプロイし、その Kubernetes クラスタに対してシステムテストを実行するテストジョブがあります。

(メモ) https://openlabtesting.org/about-us/ 現在、Huawei、OpenStack Foundation、Vexxhost、Intel、Deutsche Teleckom、OpenTelekomCloud、Citynetwork などがOpenLab に対して、テスト実行用の仮想マシン、人的リソースの提供を行っています。 Governance Team は Huawei、OpenStack Foundation、Intel から代表者の3名で構成されています。 OpenStack に関連する企業・団体が多いことから OpenStack との組合せテストが多いですが、OpenStack 組合せが条件というわけではありません。 SparkとKubernetesの統合テストなどOpenStack を含まない組合せテストもあります。

実施されているテスト一覧

OpenLab では Zuul によってテストジョブを管理しています。 Zuul は OpenStack Foundation 配下で Open Source として開発されている CI/CD system であり、OpenStack 自体の開発でも利用されているものです。 OpenLab で実施されているテストは Zuul ダッシュボード http://status.openlabtesting.org/jobs から参照可能です。 一例として次のようなものがあります。

アップストリーム開発でのテスト利用

先ほどのテスト一覧に含まれていた cloud-provider-openstack-test は kubernetes/cloud-provider-openstack 開発でのテストジョブとして利用されています。 つまり、github の kubernetes/cloud-provider-openstack に対して PullRequest を提案すると、それを契機にその PullRequest を統合した形で OpenLab 上でテストジョブが流れ、その結果が github にレポートされるようになっています。 PullRequest 提案者やレビューアはテスト結果やそのログの内容を確認し、提案コードにも問題が無ければ PullRequest が統合される、というのが一般的な開発プロセスになります。

Capture

OpenLabへの参加方法

https://docs.openlabtesting.org/#how-to-join-openlab テストパターンを追加したいなど、OpenLab に興味がありましたら、OpenLab に参加してください。 まずは OpenLab メンバーになる必要があります。 メンバー申請は github 上で次の手順で実施します。

  1. https://github.com/theopenlab/openlab/issues/new/choose で Join in OpenLab を選びます。 Capture

  2. Full Name, Github account id, Email, 企業名などを入力し、Issue をSubmitします。 例: https://github.com/theopenlab/openlab/issues/193

  3. 後日、OpenLab のGovernance Teamから github 上の theopenlab オーガニゼーションへの招待がきます。 github では各リポジトリが <オーガニゼーション名>/<リポジトリ名> で管理されています。 個人リポジトリの場合はオーガニゼーション名が個人の github id になります。 OpenLab では theopenlab がオーガニゼーション名となり、たとえば openlab-zuul-jobs リポジトリは下図のような URL で管理されています。 Capture

  4. メンバーになった後、プロジェクトの進行状況を https://github.com/orgs/theopenlab/projects/1 などで確認します。 なお、メンバーになったかどうかは下図のように People に自身が含まれていることでも確認できます。 現時点では私も含め24名のメンバーが参加しています。 Capture

  5. freenode.net 上の #askopenlab IRC チャネルで質問や議論したりするのもよいでしょう。

テスト要求

Kubernetes on OpenStack のようなインテグレーションのシナリオに関する実際のユースケースやアイディアを持っているのでしたら、それらを PoC することを計画し、後は OpenLab にそのアイディアやユースケースをシェアすればよいです。他の人があなたのユースケースに興味を持ってくれれば、彼らはあなたの要求をピックアップし、そのテストに関連した作業と OpenLab Web Site での結果のアップデートを行ってくれます。 その結果は　https://openlabtesting.org/explore/ にアップロードされます。 テスト要求も同様に github 上の Issue 登録で行います。

  1. https://github.com/theopenlab/openlab/issues/new/choose で Test Request を選びます。 Capture
  2. テストの目的（インテグレーション、性能、スケーラビリティなど）、組合せる Open Source、概要、必要なリソース（VM/物理M、数）、利用するOS、ネットワーク設定やCPUアーキテクチャ、メモリ量などを入力し、Submit します。

チャレンジ（難しいこと）

このような Open Source の組合せテストを実施するうえで難しいことの一つに、失敗したテストジョブに対して誰がどのような行動と責任を取ればよいのか、ということがあります。 それぞれの Open Source は別々のコミュニティで開発されており、一方のOSSのバージョンアップに伴う変更がそれに依存する他のOSSの挙動に影響を与えることが多々あります。 その結果がインテグレーションした際に不具合として顕在化します。OpenLab のテストジョブはそのような不具合を顕在化させるものとも言えますが、その不具合を直すために両コミュニティに対して働きかけることが重要であり、難しいことでもあります。 インテグレーション上の課題を両コミュニティに理解してもらい、課題解決に向けた協力を取り付けていく必要があるためです。 Kubernetes on OpenStack のテストジョブは先ほどお話したとおり、cloud-provider-openstack という Kubernetes コミュニティで開発されている OSS で使われており、そこには OpenStack Foundation 開発者をはじめ OpenStack、Kubernetes 両コミュニティに関わっている開発者が参加しています。 これによりテストジョブが失敗した際にどのようにそれを修正していくのか、両コミュニティと相談・調整することが可能となります。 しかし、現実にはそれでも自分が思った通りには調整できないことが多いです。 私自身 OpenStack 全体の QA をリードしていましたが、OpenStack 内だけでも意見を集約させ、合意形成していくことは難しかったです。 テストの追加を OpenLab に提案する際には、テストジョブが失敗した際にどのようにコミュニティに働きかけていくのかも検討しておく必要があります。

oomichi commented 5 years ago

[3] Kubernetes on OpenStack testing（10分）

TODO: 調べること

Cloud Provider概要

Kubernetes のリソースの一部は IaaS に依存するものがあります。 たとえば、ServicesやIngressは IaaS 層のLoad Balancer との連携が必要になりますし、PersistentVolume の実態として IaaS 層のストレージが必要となります。 AWS、GCE、Azure や OpenStack などの IaaS 層との連携を行うのが Cloud Provider であり、OpenStack 向け Cloud Provider が cloud-provider-openstack になります。 たとえば Persistent Volume 連携では、Kubernetes API 上 PVC が作られたタイミングで Cinder で Volume を作成し、それを Kubernetes ノードが稼動する仮想マシンにアタッチし 当該 Pod で使えるようにします。 ★TODO：うらどり https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-standalone-provisioner.md#workflows を図示 いまいち「Create PV using ISCSI as raw volume type using connection info」が理解できない

cloud-provider-openstack 概要

OpenStack 連携として現在 cloud-provider-openstack は以下の機能を実装しています。

これ以外にも Barbican KMS Plugin がありますが、現在アクティブに開発が行われておらず、テストジョブやドキュメントも充実していないことから今回の説明からは割愛します。

cloud-provider-openstack の OpenLab テストジョブ

先ほど cloud-provider-openstack が実装する機能について概要を説明しましたが、それぞれの機能はOpenLab 上のテストジョブを使って開発されています。 前のセクションで説明した Zuul ダッシュボード http://status.openlabtesting.org/jobs で表示されていたテストジョブの一部がそれです。 cloud-provider-openstack の各機能とテストジョブの組合せは以下の通りです。

これら特定の機能向けのテストジョブ以外に一般的な Kubernetes の機能を確認するため、相互運用認証用のテストセットである conformance tests を実行しています。

Cinder CSI Pluginのテストジョブの例

次にそれぞれのテストジョブで実際にどのようなテストが行われているのか、Cinder CSI Pluginのテストジョブである cloud-provider-openstack-acceptance-test-csi-cinder を例に見ていきます。 テストジョブの定義は https://github.com/theopenlab/openlab-zuul-jobs/tree/master/playbooks に格納されており、Cinder CSI Plugin のものは https://github.com/theopenlab/openlab-zuul-jobs/tree/master/playbooks/cloud-provider-openstack-acceptance-test-csi-cinder になります。 tasks: の内容が実際に行われているテストになります。

https://github.com/theopenlab/openlab-zuul-jobs/blob/9b441914072b63a399a8ee1162d7d708c40cfd00/playbooks/cloud-provider-openstack-acceptance-test-csi-cinder/run.yaml#L9

基本的にシェルスクリプトでテストされていることがわかるでしょう。 テストシナリオは下記の通りです。

  1. cloud-provider-openstack のバイナリを作成
  2. OpenStack 情報（auth_url, project_id, username, password, regionなど）をベースに cloud-config 作成
  3. OpenStack 向けに cloud provider 情報を設定（CLOUD_PROVIDER, EXTERNAL_CLOUD_PROVIDERなど）
  4. Local kubernetes cluster を稼動
  5. kubectl 実行に必要な環境変数を設定
  6. cinder-csi-plugin の Docker イメージを作成
  7. kubectl で cinder-csi-plugin 関連リソースを作成（StatefulSet、Service、ServiceAccountなど）
  8. テスト用リソースを作成
    • Cinder CSI plugin を使った StorageClass
    • 上記 StorageClass を指定した PVC
    • 上記PVC を利用した nginx Pod
  9. 8 で作成した Pod が Running になっていることを kubectl describe で確認

他の機能のテストジョブについても同様にシェルスクリプトでシナリオが書かれており、基本機能の動作確認が行われています。

oomichi commented 5 years ago

[4] E2E and Conformance tests of Kubernetes（10分）

OpenStack 連携において一般的な Kubernetes の機能を確認するため、相互運用認証用のテストセットである conformance tests を実行していることを前のセクションでお話しました。 ここではオンプレミスの Kubernetes クラスタの動作確認にも利用できる e2e テストと Conformance テストについて説明します。 皆さんもこれらのテストを活用して Kubernetes クラスタの動作確認に利用いただければと思います。

E2E テストは Kubernetes 本体の開発を進める際に使われている endpoint-2-endpoint テストであり、Kubernetes API の振る舞いを確認するものになっています。 最新安定板である Kubernetes v1.15.0 では 4,400以上の e2e テストが存在します。 Kubernetes のテストジョブでは 4,400 全ての e2e テストが実行されているわけではありません。 e2e テストには alpha バージョンの API のテストや disruptive テストなどテスト対象の Kubernetes クラスタ環境自体に影響を与えるもの、テスト結果が安定しないもの・いわゆる Flakeテストも含まれており、そのようなテストはスキップされています。 多くはスキップされ、実際に実行されるテストは750 程度になっています。

Capture

全 4,400 の e2e テストの内、221 が Conformance テストとなっています。 conformance テストは次の条件を満たした e2e テストの一部になります。

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md#conformance-test-requirements より

つまり、どんな環境でも確実に動作することが期待される e2e テストのみ、Conformance テストと分類されていることになります。 皆さんが e2e テストを使ってご自身の Kubernetes クラスタの動作を確認する場合、まずは Conformance テストを実行し、全ての Conformance テストが成功した後、他の e2e テストにテスト範囲を広げるという段階的な動作確認を行うことをお薦めします。

Certified Kubernetes Conformance Program

現在、クラウドプロバイダーの多くが Kubernetes のマネージドサービスを提供するようになり、多くの Kubernetes クラスタが存在するようになりました。 このような状況において Kubernetes クラスタの利用者視点での心配事の一つとして、プロバイダー間の相互運用性があります。価格や性能などそのときの利用者の要求に合わせて、Kubernetes クラスタの構築先を自由に変更したいというものです。 Certified Kubernetes Conformance Program はそのような要求に対応するため、プロバイダーが提供する Kubernetes クラスタの相互運用性を認証するための仕組みです。 現在80社以上が認証され、認証されると下記の Certified Kubernetes のロゴを製品に載せることが可能になります。

certified_kubernetes_color

この Certified Kubernetes Conformance Program は、認証対象となるサービス・製品がこれまでお話してきた Conformance テストを通ることが条件となっています。

Conformance テストの品質保持

現在、e2e テストから Conformance テストへの昇格提案が多くされています。 できるだけ多くの Kubernetes の機能が、クラウドプロバイダー間で同じように使えることを目的としているためです。 しかし、その PullRequest のレビューにおいて上記の全条件を人がチェックしていくことは難しいという課題があります。 そこで v1.15 開発では pull-kubernetes-verify テストジョブに conformance-requirements というコードチェックを追加しました。 現時点では第一の条件「全てのクラウドプロバイダで動作すること」のチェックのみ実装しています。 これにより一部のクラウドプロバイダのみで動作する e2e テストが conformance テストとなることを防げるようになりました。また、既存の e2e テストの一部が、特定のクラウドプロバイダのみで動作するという課題を顕在化させることにも役立ちました。 今後は他の条件チェックも行えるよう conformance-requirements を拡張していく予定です。

Capture

How to run E2E/Conformance tests

https://github.com/oomichi/try-kubernetes#run-e2e-test をコピーする。

--check-version-skew=false の件も載せる。

oomichi commented 5 years ago

[5] Summary（3分）

最後に本日のセッションをまとめます。 本セッションでは Kubernetes on OpenStack 実装である cloud-provider-openstack のテストを運営している OpenLab についてご紹介し、合わせて cloud-provider-openstack の概要をお話しました。 また cloud-provider-openstack のテストでも使われている Kubernetes のe2e テスト、conformance テストについても紹介し、皆様の Kubernetes クラスタの動作確認にも活用いただけることをお話しました。 詳細を含めて次の3つにまとめます。

  1. クラウド関連 OSS の組合せテストに興味があれば、OpenLab に参加しましょう まずはメンバーになることを提案し、その後組合せテストを提案する流れになります。 テストジョブが失敗した際にどのようにコミュニティに働きかけていくのかも検討しておく必要があります。
  2. Kubernetes のリソース要求を OpenStack と連携して実現するのが cloud-provider-openstack になります 今後 Cinder/Manila CSI Plugin への開発注力となるため、Cinder/Manila Provisioner を使わずCinder/Manila CSI Plugin を利用するのがお薦め
  3. Kubernetes クラスタの構築確認にe2e テストが利用可能 ただし特定のプロバイダ向けや Alpha 機能のテストも含まれるため、Conformance テストから利用することがお薦め
atoato88 commented 5 years ago

上記 [2] 〜 [5] を確認しました。

気になったところ

oomichi commented 5 years ago

レビュー、ありがとうございます。

Octavia Ingress Controller：ServiceだとLBと1体1になると書かれてますが、Ingressを使うとそれが防げる？OctaviaのインスタンスはK8Sクラスタ1つに対して１つで、1つのOctaviaインスタンスが複数のIngressリソースの処理を受け持つということですか？

はい、その通りです。 Kubernetes における Ingress の目的がそもそも外部接続している LB を共有することで、LB のコストを削減することなので、そのLB 部分が OpenStack Octavia で実装される場合も同じ目的になります。 つまり、Ingress による複数の外部接続を Octavia インスタンスで処理することになります。 Ingress については、 https://kubernetes.io/docs/concepts/services-networking/ingress/#types-of-ingress の下記のサンプルがわかりやすいと思います。

同一URL(foo.bar.com)、異なるパス(/foo, /bar)を1つのIngressで処理

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: simple-fanout-example
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: service1
          servicePort: 4200
      - path: /bar
        backend:
          serviceName: service2
          servicePort: 8080

異なるURL(foo.bar.com, bar.foo.com) を1つのIngressで処理

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: name-virtual-host-ingress
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
  - host: bar.foo.com
    http:
      paths:
      - backend:
          serviceName: service2
          servicePort: 80

Barbican KMS Plugin：なんかイメージしづらい文章でした。可能なら図がほしいところですが、ざっくりと「どういう機能が提供されるのか？」をサマライズした日本語にしたほうが理解しやすいと思いました。

Barbican KMS の内容は README を翻訳しただけのもので、私自身良くわかっていないです。 実は Adisky さんに確認したところ、Barbican KMS の開発は現在アクティブに行われていないことがわかりました。 https://kubernetes.slack.com/archives/C0LSA3T7C/p1562691866184300?thread_ts=1562641954.159700&cid=C0LSA3T7C

そこで今回のプレゼンテーションからは削除しようと思います。

oomichi commented 5 years ago

Summaryに対するコメントというより全体に対するコメントなのですが、本セッションのねらいと対象読者、参加者に何を持ち帰ってもらいたいのか？がちょっとわかりませんでした。というのも、最後のSummaryをみると、1. 〜 3. のそれぞれのつながりが感じづらいと思ったからです。 Summaryの 1. 〜 3. それぞれの説明はそれぞれでわかるのですが、このセッションでこれら３つをまとめて取り扱っている意図がもう少し伝わるような説明がほしいと思いました。 あるいは、つながりはあまりなく、CNDTのセッション説明(JULY 23(TUE) Room F [2F1] 13:20 - 14:00) に「本セッションではOpenStack/Kubernetes連携の概要、コミュニティでの開発状況などを紹介します。」とあるように、それぞれを紹介するためのセッションということであれば、Summaryの冒頭でその旨を言った上で 1. 〜 3. を述べるのが良いかもしれません。

鋭いご指摘、ありがとうございます。 そうですね、今回なぜこのようなシナリオで話したのか、その前提を先に言ったほうがマトメが理解しやすいかもしれません。 そのような形でシナリオを修正しようと思います。

oomichi commented 5 years ago

Open Source Summit Japan 向けスライド作成が完了した。