Kubernetes e2e test and test framework

6377 ワード

前言


Kubernetesの成功には多くのエンジニアの共同参加が欠かせないが、彼らの間でどのように効率的に協力するかは、私たちが探究する価値がある.最近、彼らのe 2 eテストとフレームワークを研究し、使用したのは、まだ啓発的だ.

どのようにして良いe 2 eテストですか?


異なる人が書いたテスト用例は千差万別で、特に用例が開発者によって作成される可能性がある場合、その状況は考えられる.ほとんどの開発者は、多くのテスト例シーンの薫陶を経験したことがない可能性があります.したがって、高品質のe 2 eテスト例をどのように出力し続けるかは、確かに課題である.しかし、Kubernetesコミュニティは非常に聡明で、彼らはいくつかの共通のものを抽象化して、みんなが守ることを望んでいます.例えば
  • は「flaky」テストを拒否しました.つまり、たまに失敗しますが、位置決めが非常に難しい問題です.
  • エラー出力は詳細で、特に断言する場合は関連情報が必要です.ただし、特にcaseが失敗していない場合は、無効な情報をあまり印刷しないでください.
  • make case run in anywhere.この点は重要です.あなたのcaseはコミュニティに提出されているので、さまざまな環境で、さまざまな時間帯で実行される可能性があります.様々なcloud provider、さまざまなシステム負荷状況に直面しています.だからあなたのcaseはできるだけ安定しなければなりません.例えばAPICall、非同期であれば、同期だと仮定しないでください.例えばretryメカニズムなどを多用します.
  • テストケースは、十分に速く実行されます.2分を超えると、このテストに[SLOW]ラベルを付ける必要があります.このラベルのテスト例では、実行できるシーンに制限があります.誰が自分の書いた用例ができるだけ実行されることを望んでいないのだろうか.激励的なルールです.

    • また、コミュニティはルールを定めただけでなく、一連のインフラを開発し、維持し、上記のルールの定着を支援しています.次にお話しするe 2 eフレームワークはその1つです.

    e 2 e検収試験


    テストをしたことがある人はすべて知っているはずです.複雑なシステムテストに直面するとき、私たちは通常多くのテスト環境を持っていますが、テストコードは通常1部しかありません.したがって、テスト用例をよりよく区別するためには、通常、用例を分類するためにラベルを付ける方法が採用される.これはKubernetesのe 2 eにあり、これも例外ではありません.
    Kubernetesはデフォルトでテスト用例を以下のように分類し,開発者が実際に用例を開発する際に適切に使用する必要がある.
  • ラベルがない場合、デフォルトのテスト例は安定しており、同時実行をサポートし、十分に速い
    • を実行します.
  • [Slow]の実行が比較的遅い例である.(特定の時間のしきい値については、Kubernetesの異なるドキュメントは一致しません.ここでは修正が必要です)
  • [Serial]では、リソースの使用量が多すぎたり、ノードを再起動する必要がある
    • などの同時テスト例はサポートされていません.
  • [Disruptive]は、他のテストケースの失敗または破壊的なテストケース
    • を引き起こす.
  • [Flaky]不安定な使用例であり、修復が困難である.従来のCI jobsでは、これらのテストケース
    • は実行されないため、慎重に使用してください.
  • [Feature:.+]特定の非デフォルトKubernetesクラスタ機能または非コア機能のテスト例をめぐって、開発が容易で、特定の機能が
    • に適している.
    もちろん、上記のラベルに加えて、Kubernetesクラスタの最小機能セット、つまり私たちがよく言うMATテストを検収するために使用される[Conformance]という重要なラベルもあります.プライベートで導入されたk 8 sクラスタがあれば、この例で検収することができます.方法も簡単で、次の手順で実行できます.
    # under kubernetes folder, compile test cases and ginkgo tool
make WHAT=test/e2e/e2e.test && make ginkgo

# setup for conformance tests
export KUBECONFIG=/path/to/kubeconfig
export KUBERNETES_CONFORMANCE_TEST=y
export KUBERNETES_PROVIDER=skeleton

# run all conformance tests
go run hack/e2e.go -v --test --test_args="--ginkgo.focus=\[Conformance\]"

    注意、kubernetesのテストで使用したミラーはすべてGCRに置かれています.もしあなたのクラスタが国内にあり、FQ機能を持っていない場合は、podがミラーをダウンロードできないために起動に失敗する可能性があります.

    Kubernetes e2e test framework


    Kubernetesのe 2 eテストフレームワークを研究し、私たちのこれまでの経験に比べて、個人的には、次のいくつかの特性が参考になると思います.

    All e 2 e compiled into one binary、単一独立バイナリ


    サービス・エンド・プログラムのAPIテストでは、各サービスに対してginkgo suiteを作成してテスト・インスタンスの範囲を定義することがよくあります.これにより、インスタンスの目標は非常に明確になりますが、サービス数が増えるにつれて、このようなsuiteはますます多くなります.組織的には、やや乱雑に見え、テストサービスの出力に不利です.
    例えば、QAは新しい機械室の配置、またはプライベート機械室のサービス検証を行う必要があるシーンを考えています.この場合、通常、指定されたクラスタにcopyのすべてのコードが実行される必要があり、非常に不便であり、コードの漏洩も起こりやすい.
    kubernetesにも明らかにこの需要があるので、彼らは書き方を変えて、すべてのテスト例をe 2 eにコンパイルします.testのバイナリは、上記のシーンに対して、この実行可能なファイルを直接使用して操作することができ、非常に便利です.
    もちろん、実行可能なファイルの便利さには、外部パラメータの自由な注入と、全体的なテスト例の丹念なマークが欠かせません.そうでなければ、テストコードの書き込みが規範化されていないため、特定の環境に対して頻繁に修正する必要があり、不便である.

    Each case has a uniqe namespaceは、各caseに一意の空間を持つ


    各テスト例に独立した空間を作成することは、kubernetes e 2 e frameworkの大きなエッセンスです.各テスト例は1つの空間を独占し、互いに衝突しないため、合併の悩みを根本的に回避し、ginkgoのCLIを利用して実行すると、実行効率が大幅に向上します.
    また、このコードの方式も非常に優美で、参考になります.
    func NewFramework(baseName string, options FrameworkOptions, client clientset.Interface) *Framework {
   f := &Framework{
      BaseName:                 baseName,
      AddonResourceConstraints: make(map[string]ResourceConstraint),
      Options:                  options,
      ClientSet:                client,
   }

   BeforeEach(f.BeforeEach)
   AfterEach(f.AfterEach)

   return f
}

    ginkgoのBeforeEachのネスト特定を利用して、Describeの下でframeworkの初期化(以下)を定義しますが、各Itが実行される前に、上のBeforeEachが実際に実行されるので、競合はありません.
    var _ = framework.KubeDescribe("GKE local SSD [Feature:GKELocalSSD]", func() {
   f := framework.NewDefaultFramework("localssd")
   It("should write and read from node local SSD [Feature:GKELocalSSD]", func() {
   ...
   })
})

    もちろんe 2 eフレームワークはcaseが実行した環境クリーンアップを担当し、必要に応じて柔軟に構成されています.たとえば、caseが失敗してフィールドを保持し、namespaceを削除しないことを望む場合は、flagパラメータdelete-namespace-on-failureをfalseに設定して実装できます.

    Asynchronous wait,非同期待機


    ほとんどのKubernetes操作は非同期なので、製品コードでもテスト例でも、この非同期待機ライブラリ:kubernetes/vendor/k 8 sが広く使用されています.io/apimachinery/pkg/util/wait.このライブラリは、実現が簡単で、精悍で、とても勉強に値します.
    また,テストの非同期検証に対してginkgo(gomega)自身が提供するEventualyも,非常に使いやすい.

    Suitable logs、適切なlogを印刷


    Kubernetes e 2 eは主にglogライブラリとframeworkの2つの方式でlogを出力する.Logfメソッド.glog自体はgolang公式に提供されているlogライブラリで、使用が柔軟です.しかし、ここで主にお勧めするのはFrameworkです.Logf.この方法を使用するロゴはGinkgoWriterに出力されるのでginkgoWriterを使用するとRunSpecsWithDefaultAndCustomReportersメソッドの場合、logはコンソールだけでなくjunit形式のxmlファイルにも保存され、jenkinsでテスト結果を表示するのに便利です.

    Clean code、テストコードもきれいで、優美です


    多くの場合、テストコードはlowだと思っていますが、実はそうではありません.コードは優劣を問わず、良し悪しはコードを書く人に頼る.そして、テストコードもいいし、美しく書くべきだと思います.そうしないと、どうやって追い詰められますか?!の
    私たちはKubernetes e 2 eから多くの良い参考を見ることができます.例えば、
  • 主幹方法を抽出し、試験用例本体
    • を強調する.
  • データ駆動方式で共通性試験用例
    • を書く.
  • 注釈は整っていて、多少
    • に適しています
  • 低レベルlog
    • を出力しない
  • コード長短適宜
  • メソッド名の定義が明確で、可読性が強い

    • Kubernetes環境適応性のe 2 eテストフレームワーク


    現実的には、k 8 sの周りで仕事をする必要がある場合は、自分のテストフレームワークが必要かもしれません.さまざまなカスタムコントローラor watcherをテストしても、k 8 sで実行されるプライベートサービスをテストしても構いません.このフレームワークはすべてあなたに適用されます.
    https://github.com/CarlJi/golearn/tree/master/src/carlji.com/experiments/k8s_e2e_mat_framework
    論理的変更は小さく,既存のkubernetes e 2 eフレームワークに基づいて最小集合を抽出しただけである.すばやく使用できます.
    親切ではないでしょうか.
    童鞋,点赞吧(⊙o⊙)?

    リファレンスドキュメント

  • https://github.com/thtanaka/kubernetes/blob/master/docs/devel/writing-good-e2e-tests.md
  • https://github.com/thtanaka/kubernetes/blob/master/docs/devel/e2e-tests.md

    • Contact me ?


    Email: [email protected]
    Blog: http://www.cnblogs.com/jinsdu/
    Github: https://github.com/CarlJi
    転載先:https://www.cnblogs.com/jinsdu/p/7465434.html
    I hate it(最小単点修正区間クエリー)
    hdu 1754——I Hate It(線分樹、単点更新、最大値を求める)