Akraino community has a public Jenkins cluster. ICN leverages the Akraino public Jenkins to run CI jobs.
Hostname | CPU Model | Memory | BMC Firmware | Storage | 1GbE: NIC#, VLAN, (Connected extreme 480 switch) | 10GbE: NIC# VLAN, Network (Connected with IZ1 switch) | 40GbE: NIC# |
---|---|---|---|---|---|---|---|
Jump | Intel 2xE5-2699 | 64GB | 1.46.9995 | 3TB (Sata) | IF0: VLAN 110 (DMZ) | IF2: VLAN 112 (Private) | |
node1 | Intel 2xE5-2699 | 64GB | 1.46.9995 | 3TB (Sata) | IF0: VLAN 110 (DMZ) | IF2: VLAN 112 (Private) | |
node2 | Intel 2xE5-2699 | 64GB | 1.46.9995 | 3TB (Sata) | IF0: VLAN 110 (DMZ) | IF2: VLAN 112 (Private) | IF4: SRIOV |
Note: virtualization must already be enabled on the worker nodes that will be part of the Kubernetes cluster.
The 'Multitenant Secure Cloud Native Platform' provides the possibility to launch pods using Kata Containers. To use Kata Containers, Containerd is used in Kubernetes instead of the default docker-shim.
We use the next values for the kud-installer.yaml
to properly run tests with Containerd and Kata Containers.
CONTAINER_RUNTIME: "containerd" KUD_ENABLE_TESTS: "true" ENABLE_KATA_WEBHOOK: "false" KATA_WEBHOOK_RUNTIMECLASS: "kata-clh" |
If ENABLE_KATA_WEBHOOK
is set to true, then every pod that could run as a Kata container (e.g. infrastructure pods) will mutate to run as a Kata container. This could lead to some pods to be stuck in pending. If KUD_ENABLE_TESTS
is set to true, then the webhook will be started before the verification tests are run to force Kata eligible pods to run as a Kata container. The webhook will be uninstalled after the tests run if ENABLE_KATA_WEBHOOK
is set to false.
Notes:
We recommend to only enable the webhook provided by the Kata project for testing purposes as it may not meet production needs.
For this blueprint, we are only running bare-metal testing as we have hit timeouts when double-nesting Kata Containers.
`bashate` test is used to check the shell scripts coding style. i.e. Trailing Whitespace. We find all files with suffix `.sh` and run `bashate` against the files. All vendor directories are excluded.
BPA Operator:
A Configmap coming from the kud-installer.yaml
file is what the BPA operator reads from to determine what CRI to use and whether to run the testing.
The BPA operator has unit tests using the go framework. The unit tests check the following:
BPA Rest Agent:
All the test cases are tested as follows:
Metal3 verifier will check all the servers are provisioned, Metal3 verifier checks the status of the bare-metal servers for every 60 second for the provisioning status.
bpa_verifier.sh
script get the MAC addresses and IP addresses of the 2 nodes provisioned by metal3, then creates a fake DHCP lease file using the IP address and MAC address information. It also creates a provisioning CR using the MAC address information.e2e_test.sh
, creates dummy image file, creates test JSON file, checks bpa rest agent status, issues POST, GET, and PATCH requests sequentially.e2e_test.sh
checks uploaded MinIO image object size, and calls DELETE.KuD contains test cases to verify if the add-ons are running correctly. All the test cases can be found in tests directory in the multicloud-k8s project. For each of these, we bring up the deployment that is specific to the addon and perform add-on specific actions on the pod related to the deployment.
Status as of June 25th, 2021:
Layer | Result | Comments | Nexus |
os/lynis | PASS with exceptions | Exceptions:
| Logs |
os/vuls | PASS with exceptions | Exceptions:
| Logs |
k8s/conformance | PASS with exceptions | Exceptions:
| Logs |
k8s/kube-hunter | PASS | With aquasec/kube-hunter:edge image | Logs |
Release 5 Blueprint Scanning Status
Akraino CVE Vulnerability Exception Request
Akraino BluVal Exception Request
ICN Master bare-metal Deployment Verifier
All the testing results are in logs.