Question: So first of all I'll need a service for backend too right?

Asked By
Asked At
2018-01-21 00:58:45

Found 15 possible answers.

User Answered At Possible Answer
yomateo 2018-01-21 00:58:59 basically plan on having a service for every pod (or pod(s) purpose)
vanpivix 2018-01-21 01:00:07 So 1 service for every deployment
yomateo 2018-01-21 01:00:36 yep .. if the docker image tha tyou're going to be running needs to talk .. yes there are ways to run w/out it in some cases but don't worry about it .. you're on the right track
vanpivix 2018-01-21 01:05:01 So atm I have the url for backend as an env variable in frontend , the url should be backend-service.default.svc.cluster.local ?
yomateo 2018-01-21 01:05:13 yep you can test it by hopping on any pod and running an nslookup ... so if you have multiple clusters or rename or whatev you should be able to widdle that down to backend-service.default.svc
vanpivix 2018-01-21 01:07:37 omg it works :sob: Thanks man
yomateo 2018-01-21 01:07:57 dope now you are ready to take over the world my friend
vanpivix 2018-01-21 01:08:46 before that I need some sleep :sweat_smile: see you around :spock-hand:
yomateo 2018-01-21 01:09:02 bows
jg346 2018-01-21 10:02:28 @jg346 uploaded a file: grafik.png and commented: @mauilion i think i found a viable solution to my ingress problem. @mrballcb @pl @robert.te.kaat maybe this is interesting for you too now i can direct http traffic at the ingress node and it will route the traffic directly to the correct node ------ and verify that the ingress stuff only runs on the ingress node: dashboard -> all namespaces -> pods
  example/nodetype: ingress
  effect: NoSchedule
  value: ingress
  operator: Equal
- key: dedicated
YAML add this to the nginx-ingress controller and default backend PodSpec: label the ingress node (to stick the ingress pods on it): kubectl label nodes kube-test-node-ingress example/nodetype=ingress taint the ingress node with NoSchedule (to avoid running other pods on it): kubectl taint nodes kube-test-node-ingress dedicated=ingress:NoSchedule @mauilion correct text: oops this was only half-typed kubectl label nodes kube-test-node-ingress example/nodetype=ingress you taint a node with NoSchedule:
pl 2018-01-21 10:34:50 @jg346 that's one of the options I give people for very quick setup on bare metal :-)
vanpivix 2018-01-21 11:29:27 So tell me if I understand correctly. Now I can access my service at nodeip:somerandomport , and it'll be the kube-proxy in that node that will decide which of the 2 running replicas of my container to direct the traffic to, right?
  type: NodePort
    app: kube-front
    # targetPort: 3000
    protocol: TCP
  - port: 3000
    app: kube-front
  name: frontend-service
kind: Service
And a service:
apiVersion: v1
        - name: private-repo-secret
          - containerPort: 3000
        name: kube-front
        image: myrepo/kube/front
          value: " "
        - name: BACKEND_ENDPOINT
      - env:
        app: kube-front
  replicas: 2
      app: kube-front
  name: frontend-deployment
kind: Deployment
Suppose I have a deployment:
apiVersion: apps/v1beta2
jg346 2018-01-21 11:57:44 @pl good to hear. are there any unforeseeable downsides using this approach?
pl 2018-01-21 11:58:59 @jg346 not really, though I'd advise using more than one ingress host and external lower-level LB pointing to them, with ingress on hostPort
jg346 2018-01-21 12:11:46 yeah. adding more ingress nodes and scaling the ingress deployments seems to be very easy with this setup :thumbsup:

Related Questions