Thank you again for your videos. I assume like many Software Engineers, I have bought several udemy etc classes and books. However none have made me understand Kubernetes and DevOps tools like your videos. I just started a new position, and if you are accepting ideas for topics to cover, I'd like to see more topics on the following tools: GitOPs pipelines , Rancher, Fleet, Argo, security for containers and Pods, lastly Hashi products (TerraForm,Packer, and vault). I hope one or two of these entirely selfish ideas, inspire you.
Watched over 16 hours of videos reguarding K8s. I got what i needed in this 14 1/2 minute video. Still a few lingering questions but this helped a lot.
I thought I had started to wrap my head around services and namespaces but then I got to the 5:00 mark and now I'm confused why you need entirely different instances of these resources for a single ingress; seems like it's mainly to isolate networking control permissions within a separate service and namespace? So I asked ChatGPT: "Applying the ingress controller under a separate namespace and service from the rest of the deployment in Kubernetes offers several benefits: Isolation and Segregation: By placing the ingress controller in its own namespace, you create a logical separation between the ingress controller and the other components of your application. This isolation helps in managing and securing the ingress controller independently. It also prevents accidental modifications or interference from other components. Security and Access Control: Placing the ingress controller in a separate namespace allows you to apply different security policies and access controls specifically for the ingress controller. You can define granular RBAC (Role-Based Access Control) rules to restrict access to the ingress controller's resources, making it more secure and minimizing the risk of unauthorized access. Scalability and Resource Management: Ingress controllers often handle a large amount of incoming traffic and routing rules. By isolating the ingress controller in its own namespace, you can assign dedicated resources (CPU, memory) to it and manage its scaling separately from other application components. This ensures that the ingress controller has sufficient resources to handle the ingress traffic effectively without impacting other parts of the system. Ease of Maintenance and Upgrades: Separating the ingress controller into its own namespace simplifies maintenance tasks. You can upgrade or roll back the ingress controller independently of other components, reducing the impact on the overall application. It also allows you to monitor and troubleshoot the ingress controller more effectively since its logs and metrics are contained within a dedicated namespace. Organizational and Operational Clarity: Grouping related components together in separate namespaces promotes better organization and clarity within your Kubernetes cluster. It helps distinguish between infrastructure-related components (like ingress controllers) and application-specific components, making it easier for team members to understand and manage the system. Overall, applying the ingress controller under a separate namespace and service enhances security, isolation, scalability, and maintainability of the ingress infrastructure, enabling better management and control over traffic routing in Kubernetes deployments." Isn't technology amazing?
Thank you for the video. While turning away from main camera might create a dynamic setting for tutorial, the audio quality significantly drops every time you so, making the sound uneven.
Hi Marcel. Your videos are really awesome and I'm learning a lot of new things from them which has actually helped me in my professional career. I really appreciate your efforts in making the content for us! I had a query regarding the ingress and ingress controller mapping. Let's say I have 3 different nginx ingress controllers in my cluster and I want to use a specific ingress controller for a specific ingress. How do I define which exact controller to use for an ingress. I know it is done using class annotation or "ingressClassName" attribute under the ingress spec section but which value goes there to identify the ingress controller. I didn't found much info on this on the internet (maybe I'm not looking at the right direction)
When you create an ingress controller, in the YAML somewhere would be a new CRD called ingressclass. You can see them once a controller is deployed with "kubectl get ingressclass" When deploying three ingress controllers you need to make sure each one has a different ingressclass name. They will then manage ingress resources based on the classname when someone applies an ingress. kubernetes.github.io/ingress-nginx/#what-is-an-ingressclass-and-why-is-it-important-for-users-of-ingress-nginx-controller-now
@@MarcelDempers Hey Marcel! Thank you so much for taking your to provide such a detail explanation. 🙏 So basically, the below 3 conditions must be met to use a specific ingress controller for a specific ingress: 1. The ingress controller has the container argument "--controller-class=" in it's pod's spec section with any value. 2. The ingress class has the attribute "controller" in it's spec section with the exact same value as defined in the "--controller-class" of the ingress controller's container argument. 3. The ingress uses the "IngressClass" name which has the desired controller mapped to it by using the attribute "ingressClassName" in it's spec section. Thanks again! ☺🤜
I was hoping to bypass the Cloud Provider LB service (too expensive) and expose my service in cloud to the internet. Unfortunately many tutorials like this one only show local k8s setups which are fairly easy and does not reflect real world cloud provider k8s challenges. Hope you will cover that in future video.
This is a good instruction video. Here the speech seed is natural, there is no editing out of pauses and no rapid switch between several cameras. The other videos are challenging to watch due to fast speaking and continuous switching of video feed between cameras.
Hey I don't want to expose my application to the public through ingress but still I need ingress to expose the service to the private network how to do it?
Thanks for the guide, I have created k8s cluster in aws on ec2 1 master 2 node (for testing), when i am creating loadbalancer it shows pending from last 10 hrs EXTERNAL-IP - how can i solve this ?
It sounds like your cluster is not created correctly. The cluster needs IAM roles to issue load balancers. Check your controller manager pod logs for the error details
this only work if you use the controle plane managed by AWS EKS. You can run a cluster only using EC2s but wont be able to utilise the cloud intergrations.
Is there a way to expose the service without using cloud provider's load balancer ? I am using digital ocean and the loadbalancer for some reason doesn't return Allow Origins header. I wan't more control over it. Is there a way to expose it via an ingress controller acting as a reverse proxy with a public IP ?
Great video. I have a question on using TLS with an ingress controller. I currently do TLS termination within the application itself, so I have TLS passthrough configured in my HAProxy and ingress controller. I have an HAProxy in front of my ingress controller running on port :443. Does my ingress controller also need to listen on 443 or can HAproxy rewrite the port to :80 once it enters my cluster?
If your application sits behind ingress and does the TLS termination, then NGINX will need to be configured to pass through as well and only 443 will work I believe.
... hmmm. I tried the path based routing, leaving my app to list on / and /load and then wanted to intercept say /v1 and forward that to the v1 app/service pushing it to it's / and /load did not work. I ended having to modify my app/Flask to listen to /v1/ and /v1/load, that combined with a matching ingress worked. any chance you can put something together, showing the flask routes and the matching ingress setup.
This should work, keep in mind the guide is for an older version of ingress so you may need to consult the docs. This works, adjust the ingress path to /v1 github.com/marcel-dempers/docker-development-youtube-series/tree/k8s/kubernetes/tutorials/basics/yaml
Thanks for the great content! I have 1 beginner's question: Can Ingress be used as an actual load balancer like HA proxy? Does Ingress effectively replace HA proxy and other types of load balancing systems??
Ingress is a kubernetes concept. An ingress controller can be an HA proxy or NGINX etc. It performs traffic routing in the cluster and abstracts routing rules away from users. Users define ingresses instead of configuring proxies.
Thanks for the wonderful video. Can i used multiple ingress resources in k8s and with one nginx or ha-proxy ingress-controller is enough to route simple fanout or domain based routing (domain based routing) for many ingress resources.
1000% 💪🏽ingress controllers are perfect for this use case. Every application can have its own ingress resource in its own Git repo, alongside its deployment YAML :)
If I use multiple ingress controller in one kubernetes cluster how can I mention it . For example ha-proxy should serve some ingress resource and nginx serve some ingress resources
@@ArunKumar-jv4qt you have to mention the ingress.the class name in ingress resources. For example for Nginx kxxxx.io/ingress.class: nginx For haproxy Kxxxx.io/ingress.class: haproxy
hey marcel, I want to ask you some question, do you ever get demonetized on your video because of your music, if you have, what is the name of the video? I wanna know because I'm still scared using soundcloud music
Good question, It's something I've studied early before starting. The key is using music with the right licensing. Soundcloud descriptions should contain info and what you need to look for is creative commons (CC). Not all CC licenses cover commercial use, but there are many. Under no circumstances should you use any music unless it contains an appropriate CC license like this creativecommons.org/licenses/by/3.0/ . And also remember to give the artist credit 💪🏽
hi there, can we use Ingress to redirect request based on port number to say RabbitMQ(5671) instead of paths in rules section. Just a small curious query.
I've run through a few tutorials on Ingress and I assumed yours would work on Windows, but I still run into the same issue where Ingress does not work on Windows. Is that accurate or is it possible I have done something incorrectly. I am following along with your video and the only issue I am observing is that I unable to access the the service using marcel test dns
@@MarcelDempers I appreciate how quickly you responded thank you so much for that. As for how I’m running this… I’m on Windows 10 using VS Code I have docker-desktop installed and kubectl config is set to use the cluster in docker-desktop. I do not understand what you mean by “multi-os cluster” as I am fairly new to Kubernetes but I am only using the setup I have described and following your guide from there. I thought that your video was being run on windows as well.
@@HeyThisIsAndrew Oh alright, i was thinking you are trying to deploy Ingress controller to windows :) If you are running Windows with Docker desktop then its running Kubernetes on Linux under the hood (either through WSL or Hyper-V) Keep in mind this is only for test environments. To access the service you'll need to make sure its type=LoadBalancer, and see that you can access the health endpoint or default backend in the browser over localhost .
I followed your example but my application is not available from my host (Kubernetes is running on 3 VM's on my machine). On which IP are you redirecting marcel.test to? one of the node's IP? I still have a connection refused on ports 80 and 443 :(
I use a service type=LoadBalancer as described here github.com/marcel-dempers/docker-development-youtube-series/blob/master/kubernetes/ingress/controller/nginx/service.yaml You can get the service IP by running 'kubectl describe -n ingress-nginx ingress-nginx'
@@headshooterch It sounds to me like your cluster is not configured correctly or is in a bad state. A service type LB should give you a public IP\DNS with an exposed port that's routable. If that does not work, then you may want to consult your cloud provider\k8s vendor
@@MarcelDempers actually I have a bare-metal install on my computer, which was causing the issue due to my local loadbalancer config. Now it's fixed, thanks for your help!
You would need to use services, type=ClusterIP for internal or type=LoadBalancer for public facing workloads... Some cloud providers offer annotations for type=LoadBalancer which may give you a cloud based load balancer with a private IP address (for internal VNET\VPC workloads) More info kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer
before container, we used to have Nginx to route both JS and Spring boot RESTful API requests (i.e. both frontend and backend), with container and Kubernetes, how does this change the design? I have an Nginx pod that contains all the frontend JS pages as well as the Nginx.conf that route the requests to the respective end points, how do I make use of Ingress?
That really depends how complex your current NGINX pod is. Ingress controllers are designed to replace the need for creating your own NGINX pods and managing them yourself. Ideally you would create frontend.com as a domain and point it to an Ingress controller and route all the "/" traffic to the pod that has the Web pages (could be nginx or any web server that serves static content). Then define a domain called "api.frontend.com" and have that point to Ingress controller as well which serves backend traffic (golang,nodejs,csharp,python) .. OR You can have serve your frontend over frontend.com/web and backend over frontend.com/api This is fundamentally what ingress controllers are designed to do. Hope that helps 💪🏽
Thanks for sharing, we used to route all the backend requests using Nginx. Based on what you have shared, to avoid redeploying the Nginx pod just because there is a new backend API, we should use Ingress, thanks man!
There's another question, how about the API call from the frontend application? Are those suitable use cases to use Ingress? As this introduce other problems like session management especially when it comes to authentication. Or shall we keep ingress to API that is independent from the frontend application?
@@derencevoo9146 The Ingress controller is designed for all of this. It's designed to be the entry point for multiple backends, including front end apps. One of the pitfalls in distributed systems is Sticky Sessions. This problem is not introduced by Ingress or Kubernetes, but even in traditional systems. It makes it hard to scale and will introduce a bunch of other problems. My best advice is to put time and energy to ensure your services are as stateless as possible, decouple sessions from the process and move it to some external datastore outside of Kubernetes. If you decouple one app, the rest will follow and a good practise to preach for engineers. If one app has sticky sessions it leads to a slippery slope where more and more services will follow and nothing will scale but a nightmare :)
If I use multiple ingress controller in one kubernetes cluster how can I mention it . For example ha-proxy should serve some ingress resource and nginx serve some ingress resources
Tried nginx and haproxy ingress controller and end up with crashlooperror. Analysed logs getting error as unable to connect api server timeout. Any other thing should we do on baremetal or vms for perfect working. any firewall issues? Looks all ok. Without ingress all application works. Only ingress is failing.
Interesting, sounds like some fundamental issue in your cluster setup. An ingress controller (HA+Ingress) should work out the box on any cloud provider. I believe the controllers need connectivity to K8s API servers as they need to monitor ingress object events. It sounds like this connectivity may not be working in your bare metal setup. You may need to consult the vendors, check through their github issues to see if any existing issues (closed,open) may help.
Ingress in Kubernetes does not support it as far as I believe, but there is a workaround for partial support in the NGINX flavor. It requires a bit of configuration kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/
type: LoadBalancer. Checkout the Docs for the 3 types you can define kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
Thanks for the content, but the title is bit misleading. Literally nothing about ingress, just bunch of kubectl apply commands. Was hoping to get some more detailed walkthrough, especially how to expose TCP/UDP services, for example, maybe throwing in a bit of Helm... Off topic - seems in order to understand Kubernetes I will have to go back to University after 25 years and get PhD in order to understand it. Nine (9) configuration files for one(1) thing - what a madness, and yes I know they can be merged, but not sure who can read it then. It reminds me on XML and SOAP madness back in the days - pure horror :(
I think your videos are kinda hard to follow, and the reason is that you "read the yaml" too much. For example, at around 6:00 when you were going through the service account. - You don't have to go through the roles one-by-one and tell what they do. - That part is already clear from the yaml script. - What you need to do instead is to tell us what the purpose of each roles are. - If you don't wanna do that then you might as well skip the whole file. The narration is also monotone: we can't tell what's important and what isn't when you do that. - When you explain something, slow down and stress. - When you're just narrating your activities (like "I'm applying this manifest here"), speed up or don't do it at all. I see that you spend lots of time editing as well as adding music, etc. But the effort is kinda misguided. Instead of spending time zooming on the parts of the screen where you're typing so that it's easier to copy your steps, spend time improving your explanation instead. But that's just my opinions, of course. I can see your style being attractive to someone who's trying to "copy the steps" Best of luck!
love your energy and your passion for kubernetes!
Thank you again for your videos. I assume like many Software Engineers, I have bought several udemy etc classes and books. However none have made me understand Kubernetes and DevOps tools like your videos. I just started a new position, and if you are accepting ideas for topics to cover, I'd like to see more topics on the following tools: GitOPs pipelines
, Rancher, Fleet, Argo, security for containers and Pods, lastly Hashi products (TerraForm,Packer, and vault). I hope one or two of these entirely selfish ideas, inspire you.
Watched over 16 hours of videos reguarding K8s. I got what i needed in this 14 1/2 minute video. Still a few lingering questions but this helped a lot.
I really love the way you present the content ... hats off to you.
Strongly agree!
Hands down the BEST tutorials on RUclips!!! Take my money!!!
I thought I had started to wrap my head around services and namespaces but then I got to the 5:00 mark and now I'm confused why you need entirely different instances of these resources for a single ingress; seems like it's mainly to isolate networking control permissions within a separate service and namespace? So I asked ChatGPT:
"Applying the ingress controller under a separate namespace and service from the rest of the deployment in Kubernetes offers several benefits:
Isolation and Segregation: By placing the ingress controller in its own namespace, you create a logical separation between the ingress controller and the other components of your application. This isolation helps in managing and securing the ingress controller independently. It also prevents accidental modifications or interference from other components.
Security and Access Control: Placing the ingress controller in a separate namespace allows you to apply different security policies and access controls specifically for the ingress controller. You can define granular RBAC (Role-Based Access Control) rules to restrict access to the ingress controller's resources, making it more secure and minimizing the risk of unauthorized access.
Scalability and Resource Management: Ingress controllers often handle a large amount of incoming traffic and routing rules. By isolating the ingress controller in its own namespace, you can assign dedicated resources (CPU, memory) to it and manage its scaling separately from other application components. This ensures that the ingress controller has sufficient resources to handle the ingress traffic effectively without impacting other parts of the system.
Ease of Maintenance and Upgrades: Separating the ingress controller into its own namespace simplifies maintenance tasks. You can upgrade or roll back the ingress controller independently of other components, reducing the impact on the overall application. It also allows you to monitor and troubleshoot the ingress controller more effectively since its logs and metrics are contained within a dedicated namespace.
Organizational and Operational Clarity: Grouping related components together in separate namespaces promotes better organization and clarity within your Kubernetes cluster. It helps distinguish between infrastructure-related components (like ingress controllers) and application-specific components, making it easier for team members to understand and manage the system.
Overall, applying the ingress controller under a separate namespace and service enhances security, isolation, scalability, and maintainability of the ingress infrastructure, enabling better management and control over traffic routing in Kubernetes deployments."
Isn't technology amazing?
wonderful and pragmatic, thanks bro
your taste in music is amazing
I am only 2 minutes into the video, and I already gave thumbs up. It shows you put some time into preparing it!
Thank you for the video.
While turning away from main camera might create a dynamic setting for tutorial, the audio quality significantly drops every time you so, making the sound uneven.
Thanks🍻 , this is addressed in newer videos 💪🏽
You are a gem 💎.. Treat to watch your vedios
Sir u r like God🙏🙏🙏🙏🙏
Such an amazing content sir
Tq soooo much
Thanks a lot for this quick and informative tutorial
Awesome video! intro was especially good. only thing that needs a bit of an improvement is the audio volume
Hi Marcel. Your videos are really awesome and I'm learning a lot of new things from them which has actually helped me in my professional career. I really appreciate your efforts in making the content for us!
I had a query regarding the ingress and ingress controller mapping. Let's say I have 3 different nginx ingress controllers in my cluster and I want to use a specific ingress controller for a specific ingress. How do I define which exact controller to use for an ingress. I know it is done using class annotation or "ingressClassName" attribute under the ingress spec section but which value goes there to identify the ingress controller. I didn't found much info on this on the internet (maybe I'm not looking at the right direction)
When you create an ingress controller, in the YAML somewhere would be a new CRD called ingressclass. You can see them once a controller is deployed with "kubectl get ingressclass"
When deploying three ingress controllers you need to make sure each one has a different ingressclass name.
They will then manage ingress resources based on the classname when someone applies an ingress.
kubernetes.github.io/ingress-nginx/#what-is-an-ingressclass-and-why-is-it-important-for-users-of-ingress-nginx-controller-now
@@MarcelDempers
Hey Marcel! Thank you so much for taking your to provide such a detail explanation. 🙏
So basically, the below 3 conditions must be met to use a specific ingress controller for a specific ingress:
1. The ingress controller has the container argument "--controller-class=" in it's pod's spec section with any value.
2. The ingress class has the attribute "controller" in it's spec section with the exact same value as defined in the "--controller-class" of the ingress controller's container argument.
3. The ingress uses the "IngressClass" name which has the desired controller mapped to it by using the attribute "ingressClassName" in it's spec section.
Thanks again! ☺🤜
Great vid, quick, good explanation and provided source files, The transition between code and side cam are also really nice.
I found the side cam swapping so distracting I had to stop watching.
I was hoping to bypass the Cloud Provider LB service (too expensive) and expose my service in cloud to the internet. Unfortunately many tutorials like this one only show local k8s setups which are fairly easy and does not reflect real world cloud provider k8s challenges. Hope you will cover that in future video.
Great content, you have a new subscriber.
this was amazing please make a video about Gatekeeper
It's looking awesome. Marcel can you please make the video on Nginx reverse proxy setup on K8s.
This is a good instruction video. Here the speech seed is natural, there is no editing out of pauses and no rapid switch between several cameras. The other videos are challenging to watch due to fast speaking and continuous switching of video feed between cameras.
Marcel, you are the man. Fantastic video! Thank you.
Amazing video! Thanks for the good lesson and the quality content!
This devops guy is awesome keep making videos like this
Can you make an indepth video about ConfigMaps?
Top notch explanation.
Great ! Can we use the nginx ingress for hybrid cloud
Hey I don't want to expose my application to the public through ingress but still I need ingress to expose the service to the private network how to do it?
Thanks for the guide, I have created k8s cluster in aws on ec2 1 master 2 node (for testing), when i am creating loadbalancer it shows pending from last 10 hrs EXTERNAL-IP - how can i solve this ?
It sounds like your cluster is not created correctly. The cluster needs IAM roles to issue load balancers. Check your controller manager pod logs for the error details
this only work if you use the controle plane managed by AWS EKS. You can run a cluster only using EC2s but wont be able to utilise the cloud intergrations.
Is there a way to expose the service without using cloud provider's load balancer ? I am using digital ocean and the loadbalancer for some reason doesn't return Allow Origins header. I wan't more control over it. Is there a way to expose it via an ingress controller acting as a reverse proxy with a public IP ?
Great video. I have a question on using TLS with an ingress controller.
I currently do TLS termination within the application itself, so I have TLS passthrough configured in my HAProxy and ingress controller. I have an HAProxy in front of my ingress controller running on port :443.
Does my ingress controller also need to listen on 443 or can HAproxy rewrite the port to :80 once it enters my cluster?
If your application sits behind ingress and does the TLS termination, then NGINX will need to be configured to pass through as well and only 443 will work I believe.
@@MarcelDempers OK great, that's what I figured. Thanks for the quick reply!
Nicely explained
Should the port number for all those services be 80 where I want route my ingress..??
It can be anything, but keeping the service ports consistent helps.
... hmmm. I tried the path based routing, leaving my app to list on / and /load
and then wanted to intercept say /v1 and forward that to the v1 app/service pushing it to it's / and /load did not work.
I ended having to modify my app/Flask to listen to /v1/ and /v1/load, that combined with a matching ingress worked.
any chance you can put something together, showing the flask routes and the matching ingress setup.
This should work, keep in mind the guide is for an older version of ingress so you may need to consult the docs. This works, adjust the ingress path to /v1
github.com/marcel-dempers/docker-development-youtube-series/tree/k8s/kubernetes/tutorials/basics/yaml
Thanks for the great content!
I have 1 beginner's question:
Can Ingress be used as an actual load balancer like HA proxy? Does Ingress effectively replace HA proxy and other types of load balancing systems??
Ingress is a kubernetes concept. An ingress controller can be an HA proxy or NGINX etc. It performs traffic routing in the cluster and abstracts routing rules away from users. Users define ingresses instead of configuring proxies.
@@MarcelDempers Is it a bridging program between HA Proxy and the Kubernetes core?
Kind of. ingress controllers simply automates the management of the proxy
Thanks for the class 😊
Your voice sounds lower when you look at your right camera. The visual effect is good, but the sound needs improvement.
Thanks for the wonderful video. Can i used multiple ingress resources in k8s and with one nginx or ha-proxy ingress-controller is enough to route simple fanout or domain based routing (domain based routing) for many ingress resources.
1000% 💪🏽ingress controllers are perfect for this use case. Every application can have its own ingress resource in its own Git repo, alongside its deployment YAML :)
So it’s evident one ingress controller can use multiple ingress resources
If I use multiple ingress controller in one kubernetes cluster how can I mention it . For example ha-proxy should serve some ingress resource and nginx serve some ingress resources
@@ArunKumar-jv4qt you have to mention the ingress.the class name in ingress resources. For example for Nginx
kxxxx.io/ingress.class: nginx
For haproxy
Kxxxx.io/ingress.class: haproxy
great..thank you.
hey marcel, I want to ask you some question, do you ever get demonetized on your video because of your music, if you have, what is the name of the video? I wanna know because I'm still scared using soundcloud music
Good question, It's something I've studied early before starting. The key is using music with the right licensing. Soundcloud descriptions should contain info and what you need to look for is creative commons (CC). Not all CC licenses cover commercial use, but there are many. Under no circumstances should you use any music unless it contains an appropriate CC license like this creativecommons.org/licenses/by/3.0/ . And also remember to give the artist credit 💪🏽
you are super, I love your content!
your videos are awesome.
NOTE TO SELF: Don't turn away from your mic, no one can here me.
hi there, can we use Ingress to redirect request based on port number to say RabbitMQ(5671) instead of paths in rules section. Just a small curious query.
As far as I'm aware, you can only to path based routing in ingress
I've run through a few tutorials on Ingress and I assumed yours would work on Windows, but I still run into the same issue where Ingress does not work on Windows. Is that accurate or is it possible I have done something incorrectly. I am following along with your video and the only issue I am observing is that I unable to access the the service using marcel test dns
Ingress (NGINX) is a linux container which will not run on Windows. Are you trying to route from Linux to Windows containers in a multi-OS cluster ?
@@MarcelDempers I appreciate how quickly you responded thank you so much for that.
As for how I’m running this…
I’m on Windows 10 using VS Code
I have docker-desktop installed and kubectl config is set to use the cluster in docker-desktop.
I do not understand what you mean by “multi-os cluster” as I am fairly new to Kubernetes but I am only using the setup I have described and following your guide from there. I thought that your video was being run on windows as well.
@@HeyThisIsAndrew Oh alright, i was thinking you are trying to deploy Ingress controller to windows :)
If you are running Windows with Docker desktop then its running Kubernetes on Linux under the hood (either through WSL or Hyper-V) Keep in mind this is only for test environments.
To access the service you'll need to make sure its type=LoadBalancer, and see that you can access the health endpoint or default backend in the browser over localhost .
Stucked at port-forward step. its not going ahead after hitting command.
I followed your example but my application is not available from my host (Kubernetes is running on 3 VM's on my machine). On which IP are you redirecting marcel.test to? one of the node's IP? I still have a connection refused on ports 80 and 443 :(
I use a service type=LoadBalancer as described here github.com/marcel-dempers/docker-development-youtube-series/blob/master/kubernetes/ingress/controller/nginx/service.yaml
You can get the service IP by running 'kubectl describe -n ingress-nginx ingress-nginx'
yes I also used a service of type LoadBalancer, but it's still not working, ports 80 and 443 are not exposed by the cluster
@@headshooterch It sounds to me like your cluster is not configured correctly or is in a bad state. A service type LB should give you a public IP\DNS with an exposed port that's routable. If that does not work, then you may want to consult your cloud provider\k8s vendor
@@MarcelDempers actually I have a bare-metal install on my computer, which was causing the issue due to my local loadbalancer config. Now it's fixed, thanks for your help!
How to setup 2 load balancers, one for public traffic and other for private traffic using nginx ingress controller?
You would need to use services, type=ClusterIP for internal or type=LoadBalancer for public facing workloads... Some cloud providers offer annotations for type=LoadBalancer which may give you a cloud based load balancer with a private IP address (for internal VNET\VPC workloads)
More info kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer
THANK YOU *insert michael scott gif
before container, we used to have Nginx to route both JS and Spring boot RESTful API requests (i.e. both frontend and backend), with container and Kubernetes, how does this change the design? I have an Nginx pod that contains all the frontend JS pages as well as the Nginx.conf that route the requests to the respective end points, how do I make use of Ingress?
That really depends how complex your current NGINX pod is. Ingress controllers are designed to replace the need for creating your own NGINX pods and managing them yourself. Ideally you would create frontend.com as a domain and point it to an Ingress controller and route all the "/" traffic to the pod that has the Web pages (could be nginx or any web server that serves static content). Then define a domain called "api.frontend.com" and have that point to Ingress controller as well which serves backend traffic (golang,nodejs,csharp,python) .. OR
You can have serve your frontend over frontend.com/web and backend over frontend.com/api
This is fundamentally what ingress controllers are designed to do.
Hope that helps 💪🏽
Thanks for sharing, we used to route all the backend requests using Nginx. Based on what you have shared, to avoid redeploying the Nginx pod just because there is a new backend API, we should use Ingress, thanks man!
There's another question, how about the API call from the frontend application? Are those suitable use cases to use Ingress? As this introduce other problems like session management especially when it comes to authentication. Or shall we keep ingress to API that is independent from the frontend application?
@@derencevoo9146 The Ingress controller is designed for all of this. It's designed to be the entry point for multiple backends, including front end apps. One of the pitfalls in distributed systems is Sticky Sessions. This problem is not introduced by Ingress or Kubernetes, but even in traditional systems. It makes it hard to scale and will introduce a bunch of other problems. My best advice is to put time and energy to ensure your services are as stateless as possible, decouple sessions from the process and move it to some external datastore outside of Kubernetes. If you decouple one app, the rest will follow and a good practise to preach for engineers. If one app has sticky sessions it leads to a slippery slope where more and more services will follow and nothing will scale but a nightmare :)
If I use multiple ingress controller in one kubernetes cluster how can I mention it . For example ha-proxy should serve some ingress resource and nginx serve some ingress resources
Lookup the kubernetes.io/ingress.class annotation for ingress objects
Tried nginx and haproxy ingress controller and end up with crashlooperror. Analysed logs getting error as unable to connect api server timeout. Any other thing should we do on baremetal or vms for perfect working. any firewall issues? Looks all ok. Without ingress all application works. Only ingress is failing.
Interesting, sounds like some fundamental issue in your cluster setup. An ingress controller (HA+Ingress) should work out the box on any cloud provider. I believe the controllers need connectivity to K8s API servers as they need to monitor ingress object events. It sounds like this connectivity may not be working in your bare metal setup. You may need to consult the vendors, check through their github issues to see if any existing issues (closed,open) may help.
Can use ingress nginx to open other ports not http & https? For example to the port of MySQL Pod.
Ingress in Kubernetes does not support it as far as I believe, but there is a workaround for partial support in the NGINX flavor. It requires a bit of configuration kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/
You could possibly use a NodePort to get it out to the edge
Awesome!!!! Thank You
What's the Service type in example-service?
type: LoadBalancer. Checkout the Docs for the 3 types you can define kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
Why not just use helm to install the NGINX ingress controller
Wow 🎉
Seems like the ingress node breaks ha...😢
Quality staff. But background music is very distracting.
Kong ang full konga api
So what did you explain actually? Applying a bunch of config files?
Sound fades when you turn to the right. Takes away from an otherwise good presentation.
Why on earth one wants to put annoying music on the background?
Interesting topic, wanted to follow through, but that noise started to annoy too much.
Cuben eddies
this was a bit fast
Thanks for the content, but the title is bit misleading. Literally nothing about ingress, just bunch of kubectl apply commands. Was hoping to get some more detailed walkthrough, especially how to expose TCP/UDP services, for example, maybe throwing in a bit of Helm...
Off topic - seems in order to understand Kubernetes I will have to go back to University after 25 years and get PhD in order to understand it. Nine (9) configuration files for one(1) thing - what a madness, and yes I know they can be merged, but not sure who can read it then. It reminds me on XML and SOAP madness back in the days - pure horror :(
I think your videos are kinda hard to follow, and the reason is that you "read the yaml" too much.
For example, at around 6:00 when you were going through the service account.
- You don't have to go through the roles one-by-one and tell what they do.
- That part is already clear from the yaml script.
- What you need to do instead is to tell us what the purpose of each roles are.
- If you don't wanna do that then you might as well skip the whole file.
The narration is also monotone: we can't tell what's important and what isn't when you do that.
- When you explain something, slow down and stress.
- When you're just narrating your activities (like "I'm applying this manifest here"), speed up or don't do it at all.
I see that you spend lots of time editing as well as adding music, etc. But the effort is kinda misguided.
Instead of spending time zooming on the parts of the screen where you're typing so that it's easier to copy your steps, spend time improving your explanation instead.
But that's just my opinions, of course. I can see your style being attractive to someone who's trying to "copy the steps"
Best of luck!
Too complex and god knows why we make things so complicated that even inventor also don't understand. Kubernetes sucks...
Not for beginners
Man, i do appreciate your contents, but the music is really annoying and ugly.