Thanks Prashanth. Our application requires clients to talk directly to these redis instances or pods in k8s cluster from outside the cluster so the dns name (which is purely a k8s internal concept) wont work.
Is it possible to create a service for redis1 and redis2 dynamically as they come up ? If the PetSet get allocated unique labels to each replica in the PetSet, then i could very easily create Service with selector as those labels. So potentially i could create three services, each with selector redis1, redis2 and redis3 respectively with nodeport type as some fixed port. That way if redis1 died, a new pod would come up as redis1 and still be served by its existing service and disk1 ? Is that doable ? -Mayank On Wednesday, June 1, 2016 at 3:30:30 PM UTC-7, Prashanth B wrote: > > > > On Tuesday, May 31, 2016 at 10:52:32 PM UTC-7, Mayank wrote: >> >> Hi All >> We are evaluating a use case which requires each pod to be exposed as a >> service or on some well known nodeport. I understand that there is some >> work going on for 1.3 in the name of PetSet. I wanted to know if it >> fulfills everything we need or what the community/designers are thinking >> about those use cases and its current status in master branch:- >> >> 1. My application is composed of n pods >> 2. We want each pod to be exposed on some well known nodeport or >> expose as a service that can be accessible from outside k8s. So traffic >> can be directed to the pod directly and the specific pod is always >> accessible at predetermined well known nodeport or ip. >> 3. If those pods die and come up back, they should still be visible >> on the same nodeport or service ip. >> 4. If i add more pods to my application, they should dynamically get >> assigned a well known service ip from predefined set of ip pool >> >> > This will work as described with the following limitations: > 1. Each pod gets a *cluster local* unique DNS name > 2. A DNS name is attached to some storage > 3. New pods will get DNS names and storage from the "pool", the "pool" is > managed by the petset > > So if you create a petset called redis with 2 replicas, your pods will get > redis1, redis2 attached to disk1 disk2. If you scale up, you'll find redis3 > attached to disk3, and so on. > >> >> 1. The application with n pods can still be updated using rolling >> update as a unit of deployment. >> >> Petset is in alpha for 1.3. Explicity the things that won't work in > alpha, from what you've descirbed: > 1. No ips or ports, anywhere. This is distant. Does your use case not work > with DNS/hostnames? > 2. No externally accessible DNS. Petset guarantees id within the cluster, > externally reachable identities have been discussed before, but no concrete > roadmap. > 3. Petset doesn't handle updates yet. This is on the roadmap for beta, but > till then the update will have to be manual (petset still uses labels, so > orphan a pet, update it, rejoin to cluster). > > Please let me know if this makes sense and whether the current PetSet >> supports this or a modified form of it can be supported. I am open to >> hearing what other use cases the community has and how we are solving it >> Mayank >> > -- You received this message because you are subscribed to the Google Groups "Containers at Google" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-containers. For more options, visit https://groups.google.com/d/optout.
