Closed oomichi closed 5 years ago
CFPは20分セッションで登録したはずなのに40分セッションで通ってしまった。 ので40分を前提にシナリオを組む。
OpenStack Nova, QA Core Developer
OpenStack QA ex-PTL
Kubernetes Approver of test/ in kubernetes/kubernetes repository
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.
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 で正しいか
- Overviews
- How to run E2E tests
- How to run Conformance tests
- Change E2E, build and run
想定される質問 上のフロー図の中のどこかでgithubとか外部のレポジトリを使うのでしょうか? それとも全ての作業がopenlabの中で閉じてるのでしょうか? 開発者としては普段使ってる開発スキームから逸脱したくないと思うはずなのでそのあたりが知りたい。 開発者がgithubにPR出したら、自動でテストされるのが理想ですかね。
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 が統合される、というのが一般的な開発プロセスになります。
https://docs.openlabtesting.org/#how-to-join-openlab テストパターンを追加したいなど、OpenLab に興味がありましたら、OpenLab に参加してください。 まずは OpenLab メンバーになる必要があります。 メンバー申請は github 上で次の手順で実施します。
https://github.com/theopenlab/openlab/issues/new/choose で Join in OpenLab
を選びます。
Full Name, Github account id, Email, 企業名などを入力し、Issue をSubmitします。 例: https://github.com/theopenlab/openlab/issues/193
後日、OpenLab のGovernance Teamから github 上の theopenlab オーガニゼーションへの招待がきます。
github では各リポジトリが <オーガニゼーション名>/<リポジトリ名> で管理されています。
個人リポジトリの場合はオーガニゼーション名が個人の github id になります。
OpenLab では theopenlab がオーガニゼーション名となり、たとえば openlab-zuul-jobs リポジトリは下図のような URL で管理されています。
メンバーになった後、プロジェクトの進行状況を https://github.com/orgs/theopenlab/projects/1 などで確認します。
なお、メンバーになったかどうかは下図のように People に自身が含まれていることでも確認できます。
現時点では私も含め24名のメンバーが参加しています。
freenode.net 上の #askopenlab IRC チャネルで質問や議論したりするのもよいでしょう。
Kubernetes on OpenStack のようなインテグレーションのシナリオに関する実際のユースケースやアイディアを持っているのでしたら、それらを PoC することを計画し、後は OpenLab にそのアイディアやユースケースをシェアすればよいです。他の人があなたのユースケースに興味を持ってくれれば、彼らはあなたの要求をピックアップし、そのテストに関連した作業と OpenLab Web Site での結果のアップデートを行ってくれます。 その結果は https://openlabtesting.org/explore/ にアップロードされます。 テスト要求も同様に github 上の Issue 登録で行います。
Test Request
を選びます。
このような Open Source の組合せテストを実施するうえで難しいことの一つに、失敗したテストジョブに対して誰がどのような行動と責任を取ればよいのか、ということがあります。 それぞれの Open Source は別々のコミュニティで開発されており、一方のOSSのバージョンアップに伴う変更がそれに依存する他のOSSの挙動に影響を与えることが多々あります。 その結果がインテグレーションした際に不具合として顕在化します。OpenLab のテストジョブはそのような不具合を顕在化させるものとも言えますが、その不具合を直すために両コミュニティに対して働きかけることが重要であり、難しいことでもあります。 インテグレーション上の課題を両コミュニティに理解してもらい、課題解決に向けた協力を取り付けていく必要があるためです。 Kubernetes on OpenStack のテストジョブは先ほどお話したとおり、cloud-provider-openstack という Kubernetes コミュニティで開発されている OSS で使われており、そこには OpenStack Foundation 開発者をはじめ OpenStack、Kubernetes 両コミュニティに関わっている開発者が参加しています。 これによりテストジョブが失敗した際にどのようにそれを修正していくのか、両コミュニティと相談・調整することが可能となります。 しかし、現実にはそれでも自分が思った通りには調整できないことが多いです。 私自身 OpenStack 全体の QA をリードしていましたが、OpenStack 内だけでも意見を集約させ、合意形成していくことは難しかったです。 テストの追加を OpenLab に提案する際には、テストジョブが失敗した際にどのようにコミュニティに働きかけていくのかも検討しておく必要があります。
TODO: 調べること
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」が理解できない
OpenStack 連携として現在 cloud-provider-openstack は以下の機能を実装しています。
Octavia Ingress Controller OpenStack ベースのパブリッククラウドプロバイダーである Catalyst Cloud (New Zealand) が開発をメインで行っている。 Kubernetes における Ingress: 外部ユーザ・クライアントアプリケーションからの HTTP サービスへのアクセスを許容するための機能である。 OpenStack におけるデフォルトの LoadBalancer実装が Octavia だったため、Ingress の実体としてOctavia を使うようになった。 Kubernetes Service を使うと外部アクセスとLoadBalancerが 1対1 (one-to-one mapping) になってしまい顧客のコストが高くなるため、Ingress を使うようになった。
Cinder CSI Plugin Kubernetes CSI (Container Storage Interface) 実装の一つとして OpenStack/Cinder プラグインが存在する。 OpenStack/Cinder 以外には AWS EBS (Elastic Block Storage) や GCE Persistent Disk 向けのプラグインなどが存在する。 CSI とは、任意のブロックやファイルストレージを COs (Container Orchestration Systems: e.g: Kubernetes) 上で動作するコンテナ化されたワークロードで利用するための標準仕様である。 CSI を利用することによって、3rdパーティのストレージベンダーは Kubernetes 本体のコードを直接変更することなく、プラグインのコードを書きデプロイするだけで、新たなストレージシステムを Kubernetes で利用可能になる。 Kubernetes v1.13 から CSI Spec のGA である v1.0.0 が利用可能になっている。
Cinder Standalone Provisioner CSI プラグインが出来る前から存在する OpenStack/Cinder 連携のためのプラグイン。 Kubernetes v1.13 で CSI の GA である v1.0.0 をサポートするようになったため、コミュニティでは現在では前述の Cinder CSI Plugin に注力するようになっている。 Kubernetes における PVC 要求に対して、その実体を Cinder で実現するために Cinder Volume の作成とマッピングを行う。 このアプローチによって Kubernetes クラスタが OpenStack 上にあろうとなかろうと、Cinder のストレージサービスを使うことができる。 Cinder Volumes のコネクション情報をネイティブなVolume Sources とマッピングすることで、特別なCinder のサポートを必要とせずに標準の kubelet に PV をアタッチ・マウントすることが可能となる。
Manila CSI Plugin v1.15 で実装された機能(https://github.com/kubernetes/cloud-provider-openstack/pull/536 ) ドキュメントが未だ整備されていない。 Cinder CSI Plugin 同様、Manila の CSI Plugin 実装。
Manila Provisioner Cinder Standalone Provisioner と同様、今後は Manila CSI Plugin にシフトする見込み。
Keystone Webhook Authentication Authorization k8s-keystone-auth では Kubernetes クラスタの Administrator だけが OpenStack プロジェクトネーム、もしくはロールを知る必要があり、それはユーザ管理を行う OpenStack プロジェクト Administrator に依存する。結果、OpenStack ユーザは Kubernetes クラスタへのアクセス権を持つことができる。 (英文が悪すぎないか・・)
これ以外にも Barbican KMS Plugin がありますが、現在アクティブに開発が行われておらず、テストジョブやドキュメントも充実していないことから今回の説明からは割愛します。
先ほど cloud-provider-openstack が実装する機能について概要を説明しましたが、それぞれの機能はOpenLab 上のテストジョブを使って開発されています。 前のセクションで説明した Zuul ダッシュボード http://status.openlabtesting.org/jobs で表示されていたテストジョブの一部がそれです。 cloud-provider-openstack の各機能とテストジョブの組合せは以下の通りです。
これら特定の機能向けのテストジョブ以外に一般的な Kubernetes の機能を確認するため、相互運用認証用のテストセットである conformance tests を実行しています。
次にそれぞれのテストジョブで実際にどのようなテストが行われているのか、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:
の内容が実際に行われているテストになります。
基本的にシェルスクリプトでテストされていることがわかるでしょう。 テストシナリオは下記の通りです。
他の機能のテストジョブについても同様にシェルスクリプトでシナリオが書かれており、基本機能の動作確認が行われています。
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 程度になっています。
全 4,400 の e2e テストの内、221 が Conformance テストとなっています。 conformance テストは次の条件を満たした e2e テストの一部になります。
つまり、どんな環境でも確実に動作することが期待される e2e テストのみ、Conformance テストと分類されていることになります。 皆さんが e2e テストを使ってご自身の Kubernetes クラスタの動作を確認する場合、まずは Conformance テストを実行し、全ての Conformance テストが成功した後、他の e2e テストにテスト範囲を広げるという段階的な動作確認を行うことをお薦めします。
現在、クラウドプロバイダーの多くが Kubernetes のマネージドサービスを提供するようになり、多くの Kubernetes クラスタが存在するようになりました。 このような状況において Kubernetes クラスタの利用者視点での心配事の一つとして、プロバイダー間の相互運用性があります。価格や性能などそのときの利用者の要求に合わせて、Kubernetes クラスタの構築先を自由に変更したいというものです。 Certified Kubernetes Conformance Program はそのような要求に対応するため、プロバイダーが提供する Kubernetes クラスタの相互運用性を認証するための仕組みです。 現在80社以上が認証され、認証されると下記の Certified Kubernetes のロゴを製品に載せることが可能になります。
この Certified Kubernetes Conformance Program は、認証対象となるサービス・製品がこれまでお話してきた Conformance テストを通ることが条件となっています。
現在、e2e テストから Conformance テストへの昇格提案が多くされています。 できるだけ多くの Kubernetes の機能が、クラウドプロバイダー間で同じように使えることを目的としているためです。 しかし、その PullRequest のレビューにおいて上記の全条件を人がチェックしていくことは難しいという課題があります。 そこで v1.15 開発では pull-kubernetes-verify テストジョブに conformance-requirements というコードチェックを追加しました。 現時点では第一の条件「全てのクラウドプロバイダで動作すること」のチェックのみ実装しています。 これにより一部のクラウドプロバイダのみで動作する e2e テストが conformance テストとなることを防げるようになりました。また、既存の e2e テストの一部が、特定のクラウドプロバイダのみで動作するという課題を顕在化させることにも役立ちました。 今後は他の条件チェックも行えるよう conformance-requirements を拡張していく予定です。
https://github.com/oomichi/try-kubernetes#run-e2e-test をコピーする。
--check-version-skew=false
の件も載せる。
最後に本日のセッションをまとめます。 本セッションでは Kubernetes on OpenStack 実装である cloud-provider-openstack のテストを運営している OpenLab についてご紹介し、合わせて cloud-provider-openstack の概要をお話しました。 また cloud-provider-openstack のテストでも使われている Kubernetes のe2e テスト、conformance テストについても紹介し、皆様の Kubernetes クラスタの動作確認にも活用いただけることをお話しました。 詳細を含めて次の3つにまとめます。
上記 [2] 〜 [5] を確認しました。
[3] cloud-provider-openstack 概要
[5] Summary
レビュー、ありがとうございます。
Octavia Ingress Controller:ServiceだとLBと1体1になると書かれてますが、Ingressを使うとそれが防げる?OctaviaのインスタンスはK8Sクラスタ1つに対して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
そこで今回のプレゼンテーションからは削除しようと思います。
Summaryに対するコメントというより全体に対するコメントなのですが、本セッションのねらいと対象読者、参加者に何を持ち帰ってもらいたいのか?がちょっとわかりませんでした。というのも、最後のSummaryをみると、1. 〜 3. のそれぞれのつながりが感じづらいと思ったからです。 Summaryの 1. 〜 3. それぞれの説明はそれぞれでわかるのですが、このセッションでこれら3つをまとめて取り扱っている意図がもう少し伝わるような説明がほしいと思いました。 あるいは、つながりはあまりなく、CNDTのセッション説明(JULY 23(TUE) Room F [2F1] 13:20 - 14:00) に「本セッションではOpenStack/Kubernetes連携の概要、コミュニティでの開発状況などを紹介します。」とあるように、それぞれを紹介するためのセッションということであれば、Summaryの冒頭でその旨を言った上で 1. 〜 3. を述べるのが良いかもしれません。
鋭いご指摘、ありがとうございます。 そうですね、今回なぜこのようなシナリオで話したのか、その前提を先に言ったほうがマトメが理解しやすいかもしれません。 そのような形でシナリオを修正しようと思います。
Open Source Summit Japan 向けスライド作成が完了した。
7月18日(木) 14:00 OpenSourceSummit Japan、 7月23日(火) OpenStack Days Tokyo で発表する OpenLab セッションの準備を行う。