ローカルコンパイルKubernetes e 2 eテストの実行
9322 ワード
一、Kubernetes e 2 eテストの概要
Kubernetes e 2 e(end-to-end)テストは、ユニットテストと統合テストの補完であり、その主な目標は、Kubernetesの動作の一貫性と信頼性を確保し、ユニットと統合テストが不足している場合、ユーザーが本当にソフトウェアを使用する前にテストしにくいBugをキャプチャすることである.Kubernetes e 2 eテストはGinkgoとGomegaに基づいて実現された.
二、ローカルでKubernetes e 2 eテストを実行する
e 2 eテストをローカルで実行するには、多くの方法があります.公式にはkubetestに基づいて起動することをお勧めしますが、比較的環境要件が高いです.本稿では、e 2 eテストを実行するためのバイナリ実行可能プログラムをコンパイルし、ターゲットクラスタ内で実行する比較的簡単で汎用的な方法を紹介する.
2.1 e 2 eテスト実行可能プログラムのコンパイル
a.Linuxオペレーティングシステムの準備(例えばCentOS Linux 7)
b.Go言語のインストール
注:バージョンはK 8 sコードライブラリの要件と一致するようにします(https://github.com/kubernetes/kubernetes/blob/master/hack/lib/golang.sh
minimum_go_version
を検索して、現在のコード・ライブラリに必要な最低Golangバージョンを確認します.たとえば、K 8 s 1.19にはGolang 1.14.4バージョン以上が必要です.c.コードをローカルにクローンする
# mkdir $GOPATH/src/k8s.io
# cd $GOPATH/src/k8s.io
# git clone https://github.com/kubernetes/kubernetes.git
d.コンパイル
e2e.test
バイナリ# cd $GOPATH/src/k8s.io/kubernetes
# make all WHAT=test/e2e/e2e.test
+++ [0708 09:42:01] Building go targets for linux/amd64:
./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen
+++ [0708 09:42:06] Building go targets for linux/amd64:
./vendor/k8s.io/code-generator/cmd/deepcopy-gen
+++ [0708 09:42:14] Building go targets for linux/amd64:
./vendor/k8s.io/code-generator/cmd/defaulter-gen
+++ [0708 09:42:24] Building go targets for linux/amd64:
./vendor/k8s.io/code-generator/cmd/conversion-gen
+++ [0708 09:42:38] Building go targets for linux/amd64:
./vendor/k8s.io/kube-openapi/cmd/openapi-gen
+++ [0708 09:42:52] Building go targets for linux/amd64:
./vendor/github.com/go-bindata/go-bindata/go-bindata
+++ [0708 09:42:53] Building go targets for linux/amd64:
test/e2e/e2e.test
コンパイルされた実行可能プログラムは、
$GOPATH/src/k8s.io/kubernetes/_output/bin/e2e.test
にあります.e.対応バージョンのginkgoをコンパイル(オプション)
e2e.test
自体はすでにテストを実行するために使用できますが、ginkgoの高度な能力(例えば、どの使用例を実行するかを指定したり、いくつかの使用例をスキップしたりするなど)をよりよく利用するために、ginkgoを使用してe2e.test
を起動することをお勧めします.# make all WHAT=vendor/github.com/onsi/ginkgo/ginkgo
+++ [0709 11:18:10] Building go targets for linux/amd64:
vendor/github.com/onsi/ginkgo/ginkgo
コンパイルされた実行可能プログラムは、
$GOPATH/src/k8s.io/kubernetes/_output/bin/ginkgo
にあります.2.2 e 2 eテストの実行
ターゲットテストクラスタとしてKubernetesクラスタを用意し、
e2e.test
およびginkgo
をkubectlを介してクラスタにアクセスできるノードにコピーし、テストコマンドを実行します(ここではNetworkPolicyテストを実行する例).# ./ginkgo --focus="NetworkPolicy" ./e2e.test -- --disable-log-dump --provider="skeleton" --kubeconfig="/root/.kube/config" > >(tee e2e.log)
I0709 12:48:04.233600 20566 test_context.go:427] Tolerating taints "node-role.kubernetes.io/master" when considering if nodes are ready
I0709 12:48:04.233768 20566 e2e.go:129] Starting e2e run "b404a0ac-6071-481a-bf1c-4f721393a76a" on Ginkgo node 1
{"msg":"Test Suite starting","total":29,"completed":0,"skipped":0,"failed":0}
Running Suite: Kubernetes e2e suite
===================================
Random Seed: 1594270083 - Will randomize all specs
Will run 29 of 5208 specs
Jul 9 12:48:04.253: INFO: >>> kubeConfig: /root/.kube/config
Jul 9 12:48:04.256: INFO: Waiting up to 30m0s for all (but 0) nodes to be schedulable
Jul 9 12:48:04.268: INFO: Waiting up to 10m0s for all pods (need at least 0) in namespace 'kube-system' to be running and ready
Jul 9 12:48:04.295: INFO: 10 / 10 pods in namespace 'kube-system' are running and ready (0 seconds elapsed)
Jul 9 12:48:04.295: INFO: expected 2 pod replicas in namespace 'kube-system', 2 are Running and Ready.
Jul 9 12:48:04.295: INFO: Waiting up to 5m0s for all daemonsets in namespace 'kube-system' to start
Jul 9 12:48:04.308: INFO: 2 / 2 pods ready in namespace 'kube-system' in daemonset 'fabric-node' (0 seconds elapsed)
Jul 9 12:48:04.308: INFO: 2 / 2 pods ready in namespace 'kube-system' in daemonset 'kube-proxy' (0 seconds elapsed)
Jul 9 12:48:04.308: INFO: e2e test version: v0.0.0-master+$Format:%h$
Jul 9 12:48:04.311: INFO: kube-apiserver version: v1.18.2
Jul 9 12:48:04.311: INFO: >>> kubeConfig: /root/.kube/config
Jul 9 12:48:04.321: INFO: Cluster IP family: ipv4
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
------------------------------
[sig-network] NetworkPolicy [LinuxOnly] NetworkPolicy between server and client
should support a 'default-deny-ingress' policy [Feature:NetworkPolicy]
/root/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/network/network_policy.go:83
[BeforeEach] [sig-network] NetworkPolicy [LinuxOnly]
/root/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/framework/framework.go:174
STEP: Creating a kubernetes client
Jul 9 12:48:04.322: INFO: >>> kubeConfig: /root/.kube/config
STEP: Building a namespace api object, basename network-policy
Jul 9 12:48:04.346: INFO: No PodSecurityPolicies found; assuming PodSecurityPolicy is disabled.
STEP: Waiting for a default service account to be provisioned in namespace
[BeforeEach] [sig-network] NetworkPolicy [LinuxOnly]
/root/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/network/network_policy.go:55
[BeforeEach] NetworkPolicy between server and client
/root/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/network/network_policy.go:61
STEP: Creating a simple server that serves on port 80 and 81.
STEP: Creating a server pod server in namespace network-policy-4845
Jul 9 12:48:04.353: INFO: Created pod server-6hfz8
STEP: Creating a service svc-server for pod server in namespace network-policy-4845
Jul 9 12:48:04.372: INFO: Created service svc-server
STEP: Waiting for pod ready
Jul 9 12:48:04.396: INFO: The status of Pod server-6hfz8 is Pending, waiting for it to be Running (with Ready = true)
Jul 9 12:48:06.398: INFO: The status of Pod server-6hfz8 is Pending, waiting for it to be Running (with Ready = true)
Jul 9 12:48:08.398: INFO: The status of Pod server-6hfz8 is Pending, waiting for it to be Running (with Ready = true)
Jul 9 12:48:10.398: INFO: The status of Pod server-6hfz8 is Running (Ready = false)
Jul 9 12:48:12.398: INFO: The status of Pod server-6hfz8 is Running (Ready = false)
Jul 9 12:48:14.398: INFO: The status of Pod server-6hfz8 is Running (Ready = false)
......
共通コマンド
1.e 2 eテストで使用するミラーの表示
プライベート・ウェアハウス・ベースの事前準備(またはクラスタ・ノードへの事前配布)
# ./e2e.test -list-images
gcr.io/k8s-staging-csi/nfs-provisioner:v2.2.2
gcr.io/kubernetes-e2e-test-images/sample-apiserver:1.17
docker.io/library/busybox:1.29
k8s.gcr.io/etcd:3.4.7
gcr.io/kubernetes-e2e-test-images/nonewprivs:1.0
gcr.io/kubernetes-e2e-test-images/regression-issue-74839-amd64:1.0
gcr.io/kubernetes-e2e-test-images/cuda-vector-add:1.0
gcr.io/kubernetes-e2e-test-images/echoserver:2.2
gcr.io/kubernetes-e2e-test-images/ipc-utils:1.0
gcr.io/kubernetes-e2e-test-images/jessie-dnsutils:1.0
docker.io/library/nginx:1.14-alpine
k8s.gcr.io/pause:3.2
docker.io/library/redis:5.0.5-alpine
gcr.io/kubernetes-e2e-test-images/volume/nfs:1.0
gcr.io/authenticated-image-pulling/windows-nanoserver:v1
us.gcr.io/k8s-artifacts-prod/build-image/debian-iptables:v12.1.0
gcr.io/kubernetes-e2e-test-images/volume/iscsi:2.0
gcr.io/kubernetes-e2e-test-images/volume/rbd:1.0.1
docker.io/library/httpd:2.4.38-alpine
k8s.gcr.io/sd-dummy-exporter:v0.2.0
gcr.io/kubernetes-e2e-test-images/volume/gluster:1.0
gcr.io/kubernetes-e2e-test-images/apparmor-loader:1.0
gcr.io/kubernetes-e2e-test-images/cuda-vector-add:2.0
docker.io/library/httpd:2.4.39-alpine
k8s.gcr.io/prometheus-dummy-exporter:v0.1.0
gcr.io/k8s-authenticated-test/agnhost:2.6
docker.io/gluster/glusterdynamic-provisioner:v1.0
gcr.io/kubernetes-e2e-test-images/nonroot:1.0
k8s.gcr.io/prometheus-to-sd:v0.5.0
invalid.com/invalid/alpine:3.1
gcr.io/kubernetes-e2e-test-images/kitten:1.0
gcr.io/kubernetes-e2e-test-images/nautilus:1.0
docker.io/library/nginx:1.15-alpine
gcr.io/kubernetes-e2e-test-images/resource-consumer:1.5
us.gcr.io/k8s-artifacts-prod/e2e-test-images/agnhost:2.20
gcr.io/authenticated-image-pulling/alpine:3.7
gcr.io/kubernetes-e2e-test-images/metadata-concealment:1.2
docker.io/library/perl:5.26
2.コンシステンシテストの使用例リストの表示
# ./e2e.test -list-conformance-tests
- testname: Pod Lifecycle, post start exec hook
codename: '[k8s.io] Container Lifecycle Hook when create a pod with lifecycle hook
should execute poststart exec hook properly [NodeConformance] [Conformance]'
description: When a post start handler is specified in the container lifecycle using
a 'Exec' action, then the handler MUST be invoked after the start of the container.
A server pod is created that will serve http requests, create a second pod with
a container lifecycle specifying a post start that invokes the server pod using
ExecAction to validate that the post start is executed.
release: v1.9
file: test/e2e/common/lifecycle_hook.go
.....