According to this, it is possible to configure mirroring for a Traefik server.
Now I am using a Traefik ingress controller and want to configure mirroring. One possible solution seems to be using the CRD IngressRoute. While that would probably work, it is possible to configure mirroring also per annotation? This would allow me to rely on the Kubernetes Ingress abstraction instead of using CRDs.
The background of that is, that I don't want to make assumptions about which technology is used an ingress controller.
Related
I'm trying to migrate our ingress controllers from the old stable/nginx-ingress to the newer kubernetes/ingress-nginx
I have followed their instructions for zero downtime deployments.
Create a second nginx-controller with the kubernetes/ingress-nginx helm chart.
The instanceClassName has to be different than the original.
original instanceClassName: nginx
new instanceClassName: nginx2
Update dns to point to the new nginx 2 ELB.
Get rid of the old nginx-controller
This is all great, but all of our services/deployments are attached to instanceClassName: nginx. We can update the DNS, but then the services attached to it won't receive traffic. We can update the services at the same time, but they update at different times. This will cause an outage of some type while updating.
All of the research I have done seems to stop at that controller level. It doesn't go deeper and explain how to keep all the services connected during the switch.
How can I get both nginx controllers to route traffic to the application at the same time? I have not been able to get that to happen at the service or nginx controller level.
Or maybe I'm thinking about incorrectly, and it can work in a different way.
thanks.
There are multiple methods and I have given below with Istio and providing alternate method documentations for your reference.
You can avoid down time while migrating via splitting the traffic. There are few traffic splitting tools. Kubernetes has traffic splitting in-built feature with Istio and it will help you to direct a percentage of traffic to the new ingress controller while keeping the rest of the traffic on the old ingress controller.
Install Istio in your cluster and configure your ingress resources to use Istio gateway instead of the ingress controllers directly.
Install Istio in your cluster.
Configure your ingress resources to use the Istio gateway.
Create virtual service for your ingress resources and gradually increase the traffic to the new ingress controller and also make sure to update your DNS records to point to the new ingress controllers IP.
Reference and for further information please check the official Istio page and Istio Service Mesh Workshop.
For alternative methods please refer below options:
Canary Deployments and Type Loadbalancer
Currently, we are using a loadbalancer type srevice for routing external requests to one of our pods.
We would like to move this to an ingress type service ( there is already an external load balancer setup along with an ingress controller - and we do have other pods configured to receive external requests via this ingress controller)
What we have now is the below url, used by the clients to connect externally:
ws://streamevents.app.com:7080/stomp
wss://streamevents.app.com:7443/stomp
We would like to move it to
ws://streameventsv2.app.com/stomp
wss://streameventsv2.app.com/stomp
This way, we can free up the loadbalancer IP and do not need specific ports. We do want to support both url's together for a while - since clients are already connecting to the old one. How could we achieve this?
Options I can think of (we use helm):
Create a separate chart and deployment with the Ingress service - the old one still uses the LoadBalancer
Same chart - expose the service both ways (is this really possible?)
Change the current one to Ingress - and somehow also make sure we route requests to the old url to the new ingress (how?)
Or any other possible approaches?
I'm guessing you own the helm chart and hence you can make changes to it. If so, you can expose your service both using Ingress and LoadBalancer service. You don't need any changes in any other resources in the helm chart other than adding an Ingress resource. You can remove the LoadBalancer object when you can stop supporting it.
We have a microservices architecture. We are planning to move this to Kubernetes cluster with Docker as container Runtime.(On Premise, No cloud)
Now I am able to figure out everything but one thing is not clear.
Basically we have around 10 aggregators which we have exposed via Nginx. So we are planning to Use Nginx Ingress(Project which is maintained by Kubernetes).
My doubt is currently we have complex Nginx config like different log files for different domains, generate custom headers, using Nginx Caching with purging logic with Persistent Volumes etc. Currently, we have 5-6 config files for Nginx.
Is it all possible via Ingress? From what I have read, we cant directly provide Nginx conf, we have to provide all config via ingress only? Also is it possible to break the ingress config in multiple files?
If yes, can someone provide some reference?
Remember that you have to have an ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect. In your case you need to deploy an Ingress controller such as ingress-nginx.
You can have multiple ingress rules for the same hostname with different paths. You can spread the Ingress configuration for a common host across multiple Ingress resources using Mergeable Ingress resources. Such resources can belong to the same or different namespaces. This enables easier management when using a large number of paths. See the Mergeable Ingress Resources example on our GitHub.
As an alternative to Mergeable Ingress resources, you can use VirtualServer and VirtualServerRoute resources for cross-namespace configuration. See the Cross-Namespace Configuration example on our GitHub.
Take a look: cross-namespace-configuration/, ingress-controller-configmap.
Good morning guys, so I took down a staging environment for a product on GCP and ran the deployment scripts again, the backend and frontend service have been setup. I have an ingress resource and a load balancer up, however, the service is not running. A look at the production app revealed there was something like an nginx-ingress-controller. I really don't understand all these and how it was created. Can someone help me understand because I have not seen anything online that makes it clear for me. Am I missing something?
loadBalancer: https://gist.github.com/davidshare/5a571e56febe7dacd580282b373f3095
Ingress Resource: https://gist.github.com/davidshare/d0f53912bc7da8310ec3d64f1c8a44f1
Ingress allows access to your Kubernetes services from outside the Kubernetes cluster. There are different kubernetes aka K8 resources alternatively you can use like (Node Port / Loadbalancer) which you can use to expose.
Ingress is independent resource to your service , you can specify routing rules declaratively, so each url with some context can be mapped to different services.
This makes it decoupled and isolated from the services you want to expose.
So to work ingress it needs an Ingress Controller for your cluster.
Like deployment resource in K8, ingress can be created simply by
kubectl create -f ingress.yaml
First, you have to implement Ingress Controller in order to apply Ingress resource, as described in #Shubhu answer. Ingress controller, as an edge router, applies specific logical structure with aim to route external traffic to your Kubernetes cluster underlying services via basic pattern routing rules defined in Ingress resource.
If you select Nginx Ingress Controller then it might be useful to proceed with installation guide approaching some specific prerequisites based on cloud provider environment. In order to simplify Nginx Ingress controller installation procedure it is also possible to use Helm package manager and install appropriate stable/nginx-ingress Helm chart.
I already have some services in my k8s cluster and want to mantain them separately. Examples:
grafana with custom dashboards and custom dockerfile
prometheus-operator instead of basic prometheus
jaeger pointing to elasticsearch as internal storage
certmanager in my own namespace (also I use it for nginx-ingress legacy routing)
Is it possible to use existing instances instead of creating istio-specific ones? Can istio communicate with them or it's hardcoded?
Yes - it is possible to use external services with istio. You can disable grafana and prometheus just by setting proper flags in values.yaml of istio helm chart (grafana.enabled=false, etc).
You can check kyma-project project to see how istio is integrated with prometheus-operator, grafana deployment with custom dashboards, and custom jaeger deployment. From your list only certmanager is missing.
Kubernetes provides quite a big variety of Networking and Load Balancing features from the box. However, the idea to simplify and extend the functionality of Istio sidecars is a good choice as they are used for automatic injection into the Pods in order to proxy the traffic between internal Kubernetes services.
You can implement sidecars manually or automatically. If you choose the manual way, make sure to add the appropriate parameter under Pod's annotation field:
annotations:
sidecar.istio.io/inject: "true"
Automatic sidecar injection requires Mutating Webhook admission controller, available since Kubernetes version 1.9 released, therefore sidecars can be integrated for Pod's creation process as well.
Get yourself familiar with this Article to shed light on using different monitoring and traffic management tools in Istio.