C12s/c12s-kubespray
3
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
c12s-kubespray/docs/test_cases.md
Kenichi Omichi 486b223e01
Replace kube-master with kube_control_plane (#7256) 
This replaces kube-master with kube_control_plane because of [1]:

  The Kubernetes project is moving away from wording that is
  considered offensive. A new working group WG Naming was created
  to track this work, and the word "master" was declared as offensive.
  A proposal was formalized for replacing the word "master" with
  "control plane". This means it should be removed from source code,
  documentation, and user-facing configuration from Kubernetes and
  its sub-projects.

NOTE: The reason why this changes it to kube_control_plane not
      kube-control-plane is for valid group names on ansible.

[1]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint/README.md#motivation
2021-03-23 17:26:05 -07:00

1.4 KiB
Raw Blame History

Node Layouts

There are four node layout types: default, separate, ha, and scale.

default is a non-HA two nodes setup with one separate kube-node and the etcd group merged with the kube_control_plane.

separate layout is when there is only node of each type, which includes a kube_control_plane, kube-node, and etcd cluster member.

ha layout consists of two etcd nodes, two masters and a single worker node, with role intersection.

scale layout can be combined with above layouts (ha-scale, separate-scale). It includes 200 fake hosts in the Ansible inventory. This helps test TLS certificate generation at scale to prevent regressions and profile certain long-running tasks. These nodes are never actually deployed, but certificates are generated for them.

Note, the canal network plugin deploys flannel as well plus calico policy controller.

Test cases

The CI Matrix displays OS, Network Plugin and Container Manager tested.

All tests are breakdown into 3 "stages" ("Stage" means a build step of the build pipeline) as follows:

  • unit_tests: Linting, markdown, vagrant & terraform validation etc...
  • part1: Molecule and AIO tests
  • part2: Standard tests with different layouts and OS/Runtime/Network
  • part3: Upgrade jobs, terraform jobs and recover control plane tests
  • special: Other jobs (manuals)

The steps are ordered as unit_tests->part1->part2->part3->special.