There are a number of different deployment stategies proved out in this repository.
A minimal installation of Istio is required, i.e. IstioD only, istio-ingress gateway is no longer required. Please follow the steps in the Kong Istio Gateway instructions for more on doing a 'minimal' install.
This repo assumes Kong istio gateway is installed and configured in the services deployed
Installation instructions for Kong Istio Gateway
In-depth examples of Kong-Istio integration
Main docs:
Installation docs:
The CLI can be useful also:
Please customise the ingress configuration appropriately and see the link above to the ArgoCD docs.
The kubectl plugin can be useful also:
The following deploys ArgoCD and the Extensions Controller (required below):
kubectl create ns argocd && kustomize build . | kubectl apply -f - -n argocdMain docs:
Installation docs:
The Argo CD Extension for Rollouts is also required in order to promote deployments via the ArgoCD UI
The following deploys Argo Rollouts in its own namespace and installs > the Argo CD Rollouts extension:
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
kubectl apply -n argocd -f ArgoCDExtension/ArgoCDExtension.yaml
kubectl apply -f blue-green.yamlThis will automatically deploy the initial version of the image as configured in the Kustomization file for this overlay. Once the inital image is deployed we can proceed with a deployment of the "Green" image.
Lets configure the new image in the kustomize overlay and commit to GitHub
( cd k8s/overlays/staging-blue-green/ && kustomize edit set image particule/simplecolorapi:2.0 )
git add . && git commit -m "pushing blue/green deployment" && git pushWith the Blue/Green strategy ArgoCD will eventually (if webhook is not configured) deploy the "Green" instance of the service (not exposed externally) and it should be testable via port forwarding, E.g.
kubectl port-forward svc/argo-demo-preview 8080:80 -n argo-demo-staging
curl -s http://127.0.0.1:8080Both the ArgoCD Rollouts extention, or the Argo Rollouts dashboard could be used to promote the Rollout as per the screenshots above. Alternatively the CLI could be used:
kubectl argo rollouts -n argo-demo-staging promote argo-demoThe promoted code can be tested via the Ingress as follows:
export PROXY_IP=$(minikube service -n kong-istio kong-istio-kong-proxy --url | head -1)
curl -s -k $PROXY_IP -H "Host: rollouts-blue-green.lab"CLI Commands when running Argo without ArgoCD
Deploy overlay with Argo Rollouts CRD
kubectl apply -k k8s/overlays/staging-blue-green/Update image via Argo Rollouts CLI
kubectl argo rollouts -n argo-demo-staging set image argo-demo argo-demo=particule/simplecolorapi:2.0Monitoring via the Argo Rollouts kubectl plugin
kubectl argo rollouts -n argo-demo-staging get rollout argo-demo -wkubectl apply -f canary-istio-vs.yamlThis will automatically deploy the initial version of the image as configured in the Kustomization file for this overlay. Once the inital image is deployed we can proceed with a deployment of the "Canary" image.
Lets continuously monitor the Ingress requests in another terminal.
while true; do curl -s -k https://rollouts-canary-vs.lab/ | jq .color; sleep 0.1; doneLets configure the new image in the kustomize overlay and commit to GitHub
( cd k8s/overlays/prod-canary-vs/ && kustomize edit set image particule/simplecolorapi:2.0 )
git add . && git commit -m "pushing blue/green deployment" && git pushStraight away we should start seeing 1 in 10 requests going to the Canary deployment, i.e. returning a "blue" response from the API. The deployment can be progressed with via the UI or using the following command
kubectl argo rollouts -n argo-demo-prod-vs promote argo-demoAs the rollout progresses this is reflected in the responses from the Canary deployment. See the help option on the Argo rollouts command for more info:
kubectl argo rollouts -hThis repo contains examples for 3 of the options for deploying code with the Canary strategy in Argo rollouts. Those are the:
-
-
suitable for UI canary deployments potentially ( TODO: need to look into sticky sessions )
-
-
Istio - host level traffic splitting (VirtualServices)
-
Less CRDS that subset level traffic splitting
-
-
Istio - subset level traffic splitting (VirtualServices and DestinationRules)
With the implementation of the Gateway APIs in Kubernetes, this space will change and there will be more native capabilites in the Kubernetes CRDS. Support in Kong similar to that in Nginx currently, is likely to accompany those Gateway API implmentations. Removing the need to to use Istio for this purpose. Its another option. Istio covers North/South as well as East/West traffic management, Kong would only support traffic management for North/South traffic I suspect though.