Merge pull request #7 from npinaeva/yaml-parser

Add yaml-analysis tool

.pre-commit-config.yaml

@@ -3,7 +3,7 @@ repos:
     rev: v1.51.2
     hooks:
       - id: golangci-lint
-        args: [--timeout=5m]
+        entry: bash -c 'cd yaml-analysis && golangci-lint run --timeout=5m'
   - repo: https://github.com/igorshubovych/markdownlint-cli
     rev: v0.34.0
     hooks:

README.md

@@ -3,3 +3,6 @@
 This repository contains tools for k8s Network Policy scale testing.
 In [./kube-burner](./kube-burner) folder you will find a network policy configurable workload that may be run by
 [kube-burner](https://github.com/cloud-bulldozer/kube-burner)
+
+In [./yaml-analysis](./yaml-analysis) folder you will find tools to analyze network policies based on their yamls,
+and predict if a given workload will be properly handled by a cluster based on provided scale profiles data.

kube-burner-workload/SCALE_PROFILES.md

@@ -2,31 +2,31 @@
 
 All variables that this framework has now may be presented as
 1. NetworkPolicy config
-  - LOCAL_PODS
-  - SINGLE_PORTS
-  - PORT_RANGES
-  - POD_SELECTORS
-  - PEER_NAMESPACES
-  - PEER_PODS
-  - CIDRS
+  - `LOCAL_PODS`
+  - `SINGLE_PORTS`
+  - `PORT_RANGES`
+  - `POD_SELECTORS`
+  - `PEER_NAMESPACES`
+  - `PEER_PODS`
+  - `CIDRS`
 
 These parameters define a scale impact of a single NetworkPolicy
 2. Namespace config and scale
-  - PODS_PER_NAMESPACE
-  - INGRESS
-  - EGRESS
-  - NAMESPACES
-  - NETPOLS_PER_NAMESPACE
+  - `PODS_PER_NAMESPACE`
+  - `INGRESS`
+  - `EGRESS`
+  - `NAMESPACES`
+  - `NETPOLS_PER_NAMESPACE`
 
 These variables define a namespace config and may be used to find scalability limit.
-PODS_PER_NAMESPACE also serves as a restriction for some NetworkPolicy parameters (like LOCAL_PODS) but increases per-namespace
-workload at the same time. NAMESPACES parameter also limits potential values of PEER_NAMESPACES.
+`PODS_PER_NAMESPACE` also serves as a restriction for some NetworkPolicy parameters (like `LOCAL_PODS`) but increases per-namespace
+workload at the same time. `NAMESPACES` parameter also limits potential values of `PEER_NAMESPACES`.
 
-There are some extra test parameters composed of the env variables:
-- Number of network policies = NAMESPACES * NETPOLS_PER_NAMESPACE * (I(INGRESS) + I(EGRESS))
-- Number of used peer namespace selectors = Number of network policies * POD_SELECTORS
-- Number of different peer namespace selectors = Binomial(NAMESPACES, PEER_NAMESPACES)
-- % of used different peer selectors = Number of used peer namespace selectors / Number of different peer namespace selectors
+There are some extra test parameters composed of the env variables, where `I()` is an indicator function:
+- Number of network policies = `NAMESPACES * NETPOLS_PER_NAMESPACE * (I(INGRESS) + I(EGRESS))`
+- Number of used peer namespace selectors = `Number of network policies * POD_SELECTORS`
+- Number of different peer namespace selectors = `Binomial(NAMESPACES, PEER_NAMESPACES)`
+- % of used different peer selectors = `Number of used peer namespace selectors / Number of different peer namespace selectors`
 
 When the last parameter is getting >= 100%, some peer namespace selectors will be repeated.
 
@@ -36,8 +36,8 @@ To find scalability limit for a cluster, we can iteratively increase the workloa
 clusters/platforms may have different definitions of failure). Considering we are trying to answer a question: 
 "How many network policies can I create?", we want the result to be a network policy count.
 
-Therefore, the easiest way to do so, is to save all parameters values, expect for NETPOLS_PER_NAMESPACE.
-Then by increasing the NETPOLS_PER_NAMESPACE number, we leave everything else exactly the same.
+Therefore, the easiest way to do so, is to save all parameters values, expect for `NETPOLS_PER_NAMESPACE`.
+Then by increasing the `NETPOLS_PER_NAMESPACE` number, we leave everything else exactly the same.
 
 You can copy a [helper spreadsheet](https://docs.google.com/spreadsheets/d/1Kq1w8c8Z_wlhBOb_EID2nhvmwEi8H6pSxvtpDcbf-1M/edit?usp=sharing) to track test results
 
@@ -50,6 +50,7 @@ workload can be handled.
 To do so, we can create a set of scale testing profiles by defining all variable values. We will code them as
 `<LOCAL_PODS>-<SINGLE_PORTS>-<PORT_RANGES>-<POD_SELECTORS>-<PEER_NAMESPACES>-<PEER_PODS>-<CIDRS>`
 Here are some examples:
+
 MINIMAL
 - CIDR-only                         (1-0-0-0-0-0-1)
 - port+range+CIDR                   (1-1-1-0-0-0-1)
@@ -64,4 +65,12 @@ MEDIUM
 - pod-selector-only                 (10- 0- 0-10-10-10- 0)
 - port+range+pod-selector           (10-10-10-10-10-10- 0)
 - pod-selector+CIDR                 (10- 0- 0-10-10-10-10)
-- port+range+pod-selector+CIDR      (10-10-10-10-10-10-10)
+- port+range+pod-selector+CIDR      (10-10-10-10-10-10-10)
+
+
+## Spreadsheet
+
+To simplify results tracking, you can copy a [spreadsheet](https://docs.google.com/spreadsheets/d/1Kq1w8c8Z_wlhBOb_EID2nhvmwEi8H6pSxvtpDcbf-1M/edit#gid=16759354)
+that shows an example of increasing workload and finding the best result.
+
+`export` sheets may be used with [yaml_analysis](../yaml-analysis) tools, check [README](../yaml-analysis/README.md) for more details.