Merge pull request #2152 from tssurya/ds-merge-2nd-may-2024

OCPBUGS-33080: Downstream Merge May 2nd 2024

.github/workflows/static.yml

@@ -0,0 +1,49 @@
+# Simple workflow for deploying static content to GitHub Pages
+name: Deploy static content to Pages
+
+on:
+  # Runs on pushes targeting the default branch
+  push:
+    branches: ["master"]
+
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  # Single deploy job since we're just deploying
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: 3.x
+      - run: pip install mkdocs-material
+      - run: pip install $(mkdocs-get-deps)
+      - run: mkdocs build
+      - name: Setup Pages
+        uses: actions/configure-pages@v5
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          # Upload site folder
+          path: './site'
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

CODEOWNERS

@@ -1 +1 @@
-* @trozet @dcbw @girishmg @jcaamano @tssurya
+* @ovn-org/ovn-kubernetes-members

REVIEWING.md

@@ -35,7 +35,8 @@ Be trustworthy. During a review, your actions both build and help maintain the t
 
 ## Process
 
-* Approvers are automatically assigned based on the [CODEOWNERS](./CODEOWNERS) file.
+* Reviewers are automatically assigned via the load-balancing algorithm using contributors from the ovn-org/ovn-kubernetes-members team.
+* Reviewers may opt out of reviewing of any PR or the reviewing process altogether by contacting committers or setting their github profile status as "busy" and removing themselves from any currently assigned PR.
 * Reviewers should wait for automated checks to pass before reviewing
 * At least 1 approved review is required from a maintainer before a pull request can be merged
 * All CI checks must pass
@@ -44,7 +45,7 @@ Be trustworthy. During a review, your actions both build and help maintain the t
   * A maintainer may choose to carry a PR forward on their own, but they should ALWAYS include the original author's commits
   * A maintainer may choose to open additional PRs to help lay a foundation on which the stuck PR can be unstuck. They may either rebase the stuck PR themselves or leave this to the author
 * Maintainers should not merge their pull requests without a review
-* Maintainers should let the Mergify bot merge PRs and not merge PRs directly
+* Once a reviewer has approved the PR, the reviewer should add a committer for final PR approval and merge.
 * In times of need, i.e. to fix pressing security issues or fix critical panic issues, the Maintainers may, at their discretion, merge PRs without review. They must add a comment to the PR explaining why they did so.
 
 

docs/blog/index.md

@@ -0,0 +1,2 @@
+# Blog
+

docs/design/architecture.md

@@ -0,0 +1,210 @@
+# OVN Kubernetes Architecture
+
+There are two deployment modes for ovn kubernetes depending on
+which the architecture is drastically different:
+
+* default mode (centralized control plane architecture)
+* interconnect mode (distributed control plane architecture)
+
+End users can pick either of these modes depending on their use
+cases and what suits them well. Let's look at both these modes
+in depth so that you are empowered to make your choice between
+these two modes of deployment.
+
+## OVN Kubernetes Components - Default Mode
+
+<p align="center">
+  <img src=../../../ovn-kubernetes/images/ovnkube-centralized-components.png alt="ovn-kubernetes-centralized-components"/>
+</p>
+
+
+The control plane has the `ovnkube-master` pod in the `ovn-kubernetes` namespace
+which are running only on the control plane nodes in your cluster:
+
+* ovnkube-master pod
+    * ovnkube-master container:
+        * OVN-Kubernetes component
+        * Watches K8s API for objects - namespaces, pods, services, endpoints,
+        network policies, CRs
+        * Translates K8s objects into OVN logical entities
+        * Stores OVN entities in NorthBound Database (NBDB)
+        * Manages pod subnet allocation to nodes (pod IPAM)
+    * nbdb container:
+        * Native OVN component
+        * Runs the OVN NBDB database
+        * Stores the logical elements created by ovnkube-master
+        * 3 replicas across control plane nodes running using RAFT leadership
+        algorithm in HA mode
+    * northd container:
+        * Native OVN component
+        * Converts the OVN logical elements from NBDB to OVN logical flows in SBDB
+    * sbdb container:
+        * Native OVN component
+        * Stores the logical flows created by northd
+        * 3 replicas across control plane nodes running using RAFT leadership algorithm
+        in HA mode
+
+The data plane includes the `ovnkube-node` and `ovs-node` pods in the `ovn-kubernetes`
+namespace which are running on all your nodes in the cluster.
+
+* ovnkube-node pod
+    * ovnkube-node container:
+        * OVN Kubernetes component
+        * Runs the CNI executable (CNI ADD/DEL)
+        * Digests the IPAM annotation set on pod by ovnkube-master
+        * Creates the veth pair for the pod
+        * Creates the ovs port on bridge
+        * Programs the necessary iptables and gateway service flows on a per node basis.
+    * ovn-controller container:
+        * Native OVN component
+        * Connects to SBDB running in control plane using TLS
+        * Converts SBDB logical flows into openflows
+        * Write them to OVS
+* ovs-node pod
+    * ovs-daemons container:
+        * OVS Native component
+        * OVS daemon and database running as a container
+        * virtual switch that pushes the network plumbing to the edge on the node
+
+## Default Mode Architecture
+
+Now that we know the pods and components running in the default mode, let's tie up
+loose ends and show how these components run on a standard HA Kubernetes cluster.
+
+### Control Plane Nodes:
+
+<p align="center">
+  <img src=../../../ovn-kubernetes/images/ovnkube-centralized-arch-cp.png alt="ovn-kubernetes-centralized-components-control-plane"/>
+</p>
+
+### Worker Nodes:
+
+<p align="center">
+  <img src=../../../ovn-kubernetes/images/ovnkube-centralized-arch-dp.png alt="ovn-kubernetes-centralized-components-data-plane"/>
+</p>
+
+## OVN Kubernetes Components - Interconnect mode
+
+<p align="center">
+  <img src=../../../ovn-kubernetes/images/ovnkube-distributed-components.png alt="ovn-kubernetes-distributed-components"/>
+</p>
+
+The control plane has the `ovnkube-control-plane` pod in the `ovn-kubernetes` namespace
+which is super light weight and running only on the control plane nodes in your cluster:
+
+* ovnkube-control-plane pod
+    * ovnkube-cluster-manager container:
+        * OVN-Kubernetes component
+        * Watches K8s API for objects - nodes mainly
+        * Allocates pod subnet to each node
+        * Allocates join subnet IP to each node
+        * Allocates transit subnet IP to each node
+        * Consolidates zone statuses across all nodes for features like EgressFirewall
+        and EgressQoS
+
+The data plane includes the `ovnkube-node` and `ovs-node` pods in the `ovn-kubernetes`
+namespace running on all your nodes in the cluster making this architecture localized
+and more distributed.
+
+* ovnkube-node pod
+    * ovnkube-controller container:
+        * OVN-Kubernetes component
+        * Allocates podIP from the podSubnet to each pod in its zone (IPAM)
+        * Watches K8s API for objects - nodes, namespaces, pods, services, endpoints,
+        network policies, CRs
+        * Translates K8s objects into OVN logical entities - stores them in OVN databases
+        * Stores OVN entities in NorthBound Database (NBDB)
+        * Manages pod subnet allocation to nodes (pod IPAM)
+        * Runs the CNI executable (CNI ADD/DEL)
+        * Digests the IPAM annotation set on pod
+        * Creates the veth pair for the pod
+        * Creates the ovs port on bridge
+        * Programs the necessary iptables and gateway service flows on a 
+    * nbdb container:
+        * Native OVN component
+        * Runs the OVN NBDB database
+        * Stores the logical elements created by ovnkube-controller
+        * runs only 1 replica, contains information local to this node
+    * northd container:
+        * Native OVN component
+        * Converts the OVN logical elements from NBDB to OVN logical flows in SBDB
+    * sbdb container:
+        * Native OVN component
+        * Stores the logical flows created by northd
+        * runs only 1 replica, contains information local to this node
+    * ovn-controller container:
+        * Native OVN component
+        * Connects to SBDB running in control plane using TLS
+        * Converts SBDB logical flows into openflows
+        * Write them to OVS
+* ovs-node pod
+    * ovs-daemons container:
+        * OVS Native component
+        * OVS daemon and database running as a container
+        * virtual switch that pushes the network plumbing to the edge on the node
+
+Thus as we can see, the databases, northd and ovn kubernetes controller components
+now run per zone rather than only on the control-plane.
+
+## Interconnect Mode Architecture
+
+### What is Interconnect?
+
+[OVN Interconnection](https://docs.ovn.org/en/latest/tutorials/ovn-interconnection.html)
+is a feature that allows connecting multiple OVN deployments with OVN managed GENEVE tunnels.
+Native ovn-ic feature allows for an `ovn-ic`, OVN interconnection controller, that is a
+centralized daemon which communicates with global interaction databases (IC_NB/IC_SB) to
+configure and exchange data with local NB/SB databases for interconnecting with other OVN
+deployments. See [this](https://man7.org/linux/man-pages/man8/ovn-ic.8.html) for more details.
+
+### Adopting OVN-Interconnect into OVN-Kubernetes
+
+In order to effectively adapt the capabilities of the interconnect feature in the kubernetes
+world, ovn-kubernetes components will replace `ovn-ic` daemon. Also note that the term `zone`
+which will be used heavily in these docs just refers to a single OVN deployment. Now that we
+know the pods and components running in the interconnect mode, let's tie up loose ends and
+show how these components run on a standard HA Kubernetes cluster. By default each node in
+the cluster is a `zone`, so each `zone` contains 1 node. There is no more RAFT since each
+node has its own database.
+
+### Control Plane Nodes:
+
+<p align="center">
+  <img src=../../../ovn-kubernetes/images/ovnkube-distributed-arch-cp.png alt="ovn-kubernetes-distributed-components-control-plane"/>
+</p>
+
+### Worker Nodes:
+
+<p align="center">
+  <img src=../../../ovn-kubernetes/images/ovnkube-distributed-arch-dp.png alt="ovn-kubernetes-distributed-components-data-plane"/>
+</p>
+
+### Why do we need Interconnect mode in OVN-Kubernetes?
+
+This architecture brings about several improvements:
+
+* Stability: The OVN Northbound and Southbound databases are local to each node. Since
+they are running in the standalone mode, that eliminates the need for RAFT, thus avoiding
+all the “split-brain” issues. If one of the databases goes down, the impact is now isolated
+to only that node. This has led to improved stability of the OVN Kubernetes stack and
+simpler customer escalation resolution.
+* Scale: As seen in the above diagram, the ovn-controller container connects to the
+local Southbound database for logical flow information. On large clusters with N nodes,
+this means each Southbound database is handling only one connection from its own local
+ovn-controller. This has removed the scale bottlenecks that were present in the centralized
+model helping us to scale horizontally with node count.
+* Performance: The OVN Kubernetes brain is now local to each node in the cluster and it is
+storing and processing changes to only those Kubernetes pods, services, endpoints objects
+that are relevant for that node (note: some features like NetworkPolicies need to process
+pods running on other nodes). This in turn means the OVN stack is also processing less data
+thus leading to improved operational latency. Another benefit is that the control plane
+stack is now lighter-weight.
+* Security: Since the infrastructure network traffic between ovn-controller and OVN Southbound
+database is now contained within each node, overall cross-node and cross-cluster
+(HostedControlPlane, ManagedSaaS) chatter is decreased and traffic security can be increased.
+
+## Default Mode versus Interconnect Mode
+
+* When you want your databases to stay centralized and don't mind much about linear scaling of number of nodes in your cluster, choose the default mode
+* Note that there is no different to OVS between the two deployment modes.
+* FIXME: This section needs to be written well