Uploaded image for project: 'TF Blueprints'
  1. TF Blueprints
  2. TFP-89

Enable standalone creation of manifests for K8s CNI (running inside K8s)

    XMLWordPrintable

Details

    • Improvement
    • Status: Open
    • Medium
    • Resolution: Unresolved
    • None
    • None
    • None
    • None

    Description

       

      Context

      Currently, there are two different K8s CNI architectures which are possible for integrating Tungsten Fabric (TF) as a CNI in K8s.

      Option 1: K8s CNI running via Docker Compose

      Architecture Description
      In this architecture, the TF containers which deliver the K8s CNI are run via Docker Compose on one of the hosts in the deployment.
       
      This architecture is what is deployed when the `Ansible Deployer` is used.
       
      There are a few key limitations with this architecture:
      • It is very hard to support a Highly Available CNI control plane in this design.
      • It is hard to integrate with other deployment types (such as RKE) because the CNI is not deployed inside K8s (which is how the majority of the other CNIs in the market are deployed).

       

      Option 2: K8s CNI running inside K8s

      Architecture Description
      In this architecture, the TF containers which deliver the K8s CNI are running inside K8s and are controlled by the K8s scheduler.
       
      This is the architecture which is used when deploying via the `1-line deployment` for both CentOS and Ubuntu.  
       
      There are a few benefits from running this architecture:
      • Because K8s manages the lifecycle and scheduling of the containers, it is easier to create an HA deployment.
      • The CNI implementation is entirely contained in a single deployment manifest, making it easier to implement in K8s clusters which are installed outside the control of TF.
      • Because the CNI implementation is self contained, it makes it easier to build integrations with other deployers, such as Rancher's RKE.

       

      Current State

      This section is going to be a bit dense, but I am going to attempt to provide a snapshot of the current state and the technical implications in play.

      The Proposal

      I think it is very important that the Tungsten Fabric community starts officially supporting the Option 2 deployment architecture as a first class citizen as this architecture is the default / best practice approach for installing a CNI in Kubernetes and enables the opportunity to deploy TF in a much wider range of K8s deployments.  I would like to build an integration with Rancher's RKE so we can use TF as a first class CNI in Rancher and this deployment architecture is a requirement for that work to be effective.

      Since we are already advertising this deployment architecture as a viable deployment strategy on both [CentOS|https://tungstenfabric.github.io/website/Tungsten-Fabric-Centos-one-line-install-on-k8s.html] ([manifest|https://raw.githubusercontent.com/Juniper/contrail-kubernetes-docs/master/install/kubernetes/templates/contrail-single-step-cni-install-centos.yaml]) and [Ubuntu|https://tungstenfabric.github.io/website/Tungsten-Fabric-Ubuntu-one-line-install-on-k8s.html] (manifest), I think it is important that we properly support those documented deployment architectures with the means to support the generation of the required manifests from the [latest upstream manifests|https://github.com/Juniper/contrail-container-builder/tree/master/kubernetes/manifests].

      I would like to create a PR which would do the following:

       

       

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            Unassigned Unassigned
            swill Will Stevens
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: