I think this gives you an extra point of abstraction and security, because if you point your services always to same hostname (i.e. mongodb) it's more difficult to make a mistake between testing and production. So, if you try to access a database from testing environment with production chain you won't be able to access because it will still be pointing to testing and you'll get wrong credentials (if you use different credentials for your environments, of course). So this could prevent mistakes for example, if you copy configmap from production to testing by mistake, or if you are executing...you know...a hotfix.
Kind of a stupid question, but I'm really new to this. What about when you run the service/database on localhost ? You can't map the 127.0.0.1 as IP address for the endpoint.
I have used this method without the need to use the service object , I only used endpoint , and I could connect to google cloudsql db , I dont knwo why we use service here in this specific example
And another great video from you Dinesh! Thanks for this series, really appreciate the effort that goes into creating such an easy-to-follow explanation.
How can I restrict the outgoing (egress) calls using Kubernetes dns service. can I use Kubernetes dns service to whitelist the domains for my pods ?
Please create a playlist of all sandeep's videos. could not find one on channel.
can we add external fttp service also ? my application is using external fttp service ..
But what if CNAME (strictly) and dynamic port are required together?
When you combine this with an Ingress, you can also perform the portmapping. You do however need to have an Ingress Controller available.
The associated article URL is the wrong one for this topic.
Using configmaps don't perform the same level of abstraction ?
I think this gives you an extra point of abstraction and security, because if you point your services always to same hostname (i.e. mongodb) it's more difficult to make a mistake between testing and production.
So, if you try to access a database from testing environment with production chain you won't be able to access because it will still be pointing to testing and you'll get wrong credentials (if you use different credentials for your environments, of course). So this could prevent mistakes for example, if you copy configmap from production to testing by mistake, or if you are executing...you know...a hotfix.
How we can target databricks dynamic clusters from k8s .how we can define service monitor for it.
Kind of a stupid question, but I'm really new to this. What about when you run the service/database on localhost ? You can't map the 127.0.0.1 as IP address for the endpoint.
Detailed explanation!! thanks Sandeep!!!
I have used this method without the need to use the service object , I only used endpoint , and I could connect to google cloudsql db , I dont knwo why we use service here in this specific example
thanks for series, so i tried on the v21 but not work
Can this be used to access database installed on my local machine?(outside of the cluster). I tried it but getting connection time out error.
4:04 Wouldn't you use different passwords for dev and prod anyway?
Great series, short with some nice ideas
And another great video from you Dinesh! Thanks for this series, really appreciate the effort that goes into creating such an easy-to-follow explanation.
this is a great series. thank you
great explanation
fantastic
what is end point in k8?
Highly useful!
Hum, I am using env vars for ip and port, but I like this solution
tnx google it was really awesome
Excellent.
Please write a controller that finds and updates the IP address for a hostname and sets it to an endpoint so I don't have to do it myself.