Add load balancer (AWS)

If you deploy MSR to AWS you should consider adding a load balancer to your installation.

  1. Set an environment variable to use in assigning an internal service name to the load balancer service:

    export MSR_ELB_SERVICE="msr-public-elb"
    
  2. Use Kubernetes to create an AWS load balancer to expose NGINX, the front end for the MSR web UI:

    kubectl expose deployment msr-nginx --type=LoadBalancer \
      --name="${MSR_ELB_SERVICE}"
    
  3. Check the status:

    kubectl get svc | grep "${MSR_ELB_SERVICE}" | awk '{print $4}'
    

    Note

    The output returned on AWS will be a FQDN, whereas other cloud providers may return an FQDN or an IP address.

    Example output:

    af42a8a8351864683b584833065b62c7-1127599283.us-west-2.elb.amazonaws.com
    

    Note

    • If nothing returns after you have run the command, wait a few minutes and run the command again.

    • If the command returns an FQDN it may be necessary to wait for the new DNS record to resolve. You can check the resolution status by running the following script, inserting the output string you received in place of $FQDN:

      while : ; do dig +short $FQDN ; sleep 5 ; done
      
    • If the command returns an IP address, you can access the load balancer at: https://<load-balancer-IP>/

  4. When one or more IP addresses display, you can interrupt the shell loop and access your MSR 3.0.x load balancer at: https://$FQDN/

    Note

    The load balancer will stop any attempt to tear down the VPC in which the EC2 instances are running. As such, in order to tear down the VPC you must first remove the load balancer:

    kubectl delete svc msr-public-elb
    
  5. Optional. Configure MSR to use Notary to sign images. To do this, update NGINX to add the DNS name:

    1. Modify your custom resource manifest to contain the following values:

      nginx:
        webtls:
          spec:
            dnsNames: ["nginx","localhost","${MSR_FQDN}"]
      
  6. Invoke the following command to run the webhook health check and apply the changes to the custom resource:

    kubectl wait --for=condition=ready pod -l \
    app.kubernetes.io/name="msr-operator" && kubectl apply -f cr-sample-manifest.yaml
    
  7. Verify completion of the reconciliation process for the custom resource:

    kubectl get msrs.msr.mirantis.com
    

    To troubleshoot the reconciliation process, run the following commands:

    kubectl describe msrs.msr.mirantis.com
    

    Review the MSR Operator Pod logs for more detailed results:

    kubectl logs <msr-operator-pod-name>