$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE $ sudo docker pull gcr.io/google_containers/hyperkube:v1.3.7 $ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE gcr.io/google_containers/hyperkube v1.3.7 24db5b90d9c0 8 days ago 404.7 MB
This can take some time based on your network, disk, and cpu speed. It is possible for an error to occur during Salt provision of cluster and this could loop forever. Validating master Validating node-1 .............................................. Waiting for each node to be registered with cloud provider Flag --api-version has been deprecated, flag is no longer respected and will be deleted in the next release Validating we can run kubectl commands. Connection to 192.168.121.223 closed.
Kubernetes cluster is running.
The master is running at:
https://10.245.1.2
Administer and visualize its resources using Cockpit:
https://10.245.1.2:9090
For more information on Cockpit, visit http://cockpit-project.org
The user name and password to use is located in /root/.kube/config
... calling validate-cluster Found 1 node(s). NAME STATUS AGE kubernetes-node-1 Ready 6m Cluster not working yet. Validate output: NAME STATUS MESSAGE ERROR scheduler Healthy ok controller-manager Healthy ok etcd-1 Healthy {"health": "true"} etcd-0 Healthy {"health": "true"} Cluster validation succeeded Done, listing cluster services:
Kubernetes master is running at https://10.245.1.2 Heapster is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/heapster KubeDNS is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/kube-dns kubernetes-dashboard is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard Grafana is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana InfluxDB is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
你可以在单元测试期间使用KUBE_GOFLAGS变量来设置 go flags. 运行全部的单元测试。
1 2
cd kubernetes make test # Run all unit tests.
运行单个包或者多个的单元测试。
1 2
make test WHAT=pkg/api # run tests for pkg/api make test WHAT="pkg/api pkg/kubelet" # run tests for pkg/api and pkg/kubelet
对包里面具体参数的单元测试。
1 2 3 4 5
# Runs TestValidatePod in pkg/api/validation with the verbose flag set make test WHAT=pkg/api/validation KUBE_GOFLAGS="-v" KUBE_TEST_ARGS='-run ^TestValidatePod$' # Runs tests that match the regex ValidatePod|ValidateConfigMap in pkg/api/validation make test WHAT=pkg/api/validation KUBE_GOFLAGS="-v" KUBE_TEST_ARGS="-run ValidatePod\|ValidateConfigMap$"
反复运行单元测试
1 2
# Have 2 workers run all tests 5 times each (10 total iterations). make test PARALLEL=2 ITERATION=5
Unit test coverage
获取测试覆盖率，以下命令会生成一个 html 文档，当然也可以对一个 package 做这样的操作。
1 2
make test KUBE_COVER=y make test WHAT=pkg/kubectl KUBE_COVER=y
Benchmark unit tests
典型的 benchmark 指令如下：
1
go test ./pkg/apiserver -benchmem -run=XXX -bench=BenchmarkWatch
# Install etcd and add to PATH # Option a) install inside kubernetes root hack/install-etcd.sh # Installs in ./third_party/etcd echo export PATH="$PATH:$(pwd)/third_party/etcd" >> ~/.profile # Add to PATH # Option b) install manually grep -E "image.*etcd" cluster/saltbase/etcd/etcd.manifest # Find version # Install that version using yum/apt-get/etc echo export PATH="$PATH:<LOCATION>" >> ~/.profile # Add to PATH
# Build binaries for testing go run hack/e2e.go -v --build # Create a fresh cluster. Deletes a cluster first, if it exists go run hack/e2e.go -v --up # Run all tests go run hack/e2e.go -v --test # Run tests matching the regex "\[Feature:Performance\]" go run hack/e2e.go -v --test --test_args="--ginkgo.focus=\[Feature:Performance\]" # Conversely, exclude tests that match the regex "Pods.*env" go run hack/e2e.go -v --test --test_args="--ginkgo.skip=Pods.*env" # Run tests in parallel, skip any that must be run serially GINKGO_PARALLEL=y go run hack/e2e.go --v --test --test_args="--ginkgo.skip=\[Serial\]" # Flags can be combined, and their actions will take place in this order: # --build, --up, --test, --down # # You can also specify an alternative provider, such as 'aws' # # e.g.: KUBERNETES_PROVIDER=aws go run hack/e2e.go -v --build --up --test --down # -ctl can be used to quickly call kubectl against your e2e cluster. Useful for # cleaning up after a failed test or viewing logs. Use -v to avoid suppressing # kubectl output. go run hack/e2e.go -v -ctl='get events' go run hack/e2e.go -v -ctl='delete pod foobar'
As per the comments, the practical default level is V(2). Developers and QE environments may wish to run at V(3) or V(4). If you wish to change the loglevel, you can pass in -v=X where X is the desired maximum level to log.
这是开发对 glog 的 conventions.
glog.Errorf() - Always an error
glog.Warningf() - Something unexpected, but probably not an error
glog.Infof() has multiple levels:
glog.V(0) - Generally useful for this to ALWAYS be visible to an operator
Programmer errors
Logging extra info about a panic
CLI argument handling
glog.V(1) - A reasonable default log level if you don’t want verbosity.
Information about config (listening on X, watching Y)
Errors that repeat frequently that relate to conditions that can be corrected (pod detected as unhealthy)
glog.V(2) - Useful steady state information about the service and important log messages that may correlate to significant changes in the system. This is the recommended default log level for most systems.
Logging HTTP requests and their exit code
System state changing (killing pod)
Controller state change events (starting pods)
Scheduler log messages
glog.V(3) - Extended information about changes
More info about system state changes
glog.V(4) - Debug level verbosity (for now)
Logging in particularly thorny parts of code where you may want to come back later and check it
