Kubernetes: Route incomming traffic to specific Pod
up vote
0
down vote
favorite
I want to deploy many Pods in Google Kubernetes Engine and then establish a TCP connection to each specific Pod by Subdomain like pod-name-or-label.mydomain.com or path routing like protocol://mydomain.com:7878/pod-name-or-label.
I have looked in different directions like Istio or nginx-ingress, but that seems to me to be too complicated.
Is not there a simple solution for that?
kubernetes network-programming kubernetes-ingress gke istio
add a comment |
up vote
0
down vote
favorite
I want to deploy many Pods in Google Kubernetes Engine and then establish a TCP connection to each specific Pod by Subdomain like pod-name-or-label.mydomain.com or path routing like protocol://mydomain.com:7878/pod-name-or-label.
I have looked in different directions like Istio or nginx-ingress, but that seems to me to be too complicated.
Is not there a simple solution for that?
kubernetes network-programming kubernetes-ingress gke istio
A standalonePod
is not the way to go for this and is most certainly an anti-pattern. Your best bet is to move up a couple abstractions to theDeployment
resource, and then you can deploy multiple copies of yourPod
with some variation in labels between them to dictate ingress and routing.
– ericstaples
Nov 8 at 17:51
Pod is not something to work with in production , define a deployment and expose it using nodePort , then use session persistence with kube-proxy set to serve from local node only.
– Ijaz Ahmad Khan
Nov 8 at 18:18
This article shows how to create Kubernetes Services in a Google Kubernetes Engine cluster And how to create a service of Nodeport.
– Milad
Nov 8 at 22:58
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I want to deploy many Pods in Google Kubernetes Engine and then establish a TCP connection to each specific Pod by Subdomain like pod-name-or-label.mydomain.com or path routing like protocol://mydomain.com:7878/pod-name-or-label.
I have looked in different directions like Istio or nginx-ingress, but that seems to me to be too complicated.
Is not there a simple solution for that?
kubernetes network-programming kubernetes-ingress gke istio
I want to deploy many Pods in Google Kubernetes Engine and then establish a TCP connection to each specific Pod by Subdomain like pod-name-or-label.mydomain.com or path routing like protocol://mydomain.com:7878/pod-name-or-label.
I have looked in different directions like Istio or nginx-ingress, but that seems to me to be too complicated.
Is not there a simple solution for that?
kubernetes network-programming kubernetes-ingress gke istio
kubernetes network-programming kubernetes-ingress gke istio
edited Nov 8 at 21:29
Rico
23.6k94864
23.6k94864
asked Nov 8 at 17:05
micha
115
115
A standalonePod
is not the way to go for this and is most certainly an anti-pattern. Your best bet is to move up a couple abstractions to theDeployment
resource, and then you can deploy multiple copies of yourPod
with some variation in labels between them to dictate ingress and routing.
– ericstaples
Nov 8 at 17:51
Pod is not something to work with in production , define a deployment and expose it using nodePort , then use session persistence with kube-proxy set to serve from local node only.
– Ijaz Ahmad Khan
Nov 8 at 18:18
This article shows how to create Kubernetes Services in a Google Kubernetes Engine cluster And how to create a service of Nodeport.
– Milad
Nov 8 at 22:58
add a comment |
A standalonePod
is not the way to go for this and is most certainly an anti-pattern. Your best bet is to move up a couple abstractions to theDeployment
resource, and then you can deploy multiple copies of yourPod
with some variation in labels between them to dictate ingress and routing.
– ericstaples
Nov 8 at 17:51
Pod is not something to work with in production , define a deployment and expose it using nodePort , then use session persistence with kube-proxy set to serve from local node only.
– Ijaz Ahmad Khan
Nov 8 at 18:18
This article shows how to create Kubernetes Services in a Google Kubernetes Engine cluster And how to create a service of Nodeport.
– Milad
Nov 8 at 22:58
A standalone
Pod
is not the way to go for this and is most certainly an anti-pattern. Your best bet is to move up a couple abstractions to the Deployment
resource, and then you can deploy multiple copies of your Pod
with some variation in labels between them to dictate ingress and routing.– ericstaples
Nov 8 at 17:51
A standalone
Pod
is not the way to go for this and is most certainly an anti-pattern. Your best bet is to move up a couple abstractions to the Deployment
resource, and then you can deploy multiple copies of your Pod
with some variation in labels between them to dictate ingress and routing.– ericstaples
Nov 8 at 17:51
Pod is not something to work with in production , define a deployment and expose it using nodePort , then use session persistence with kube-proxy set to serve from local node only.
– Ijaz Ahmad Khan
Nov 8 at 18:18
Pod is not something to work with in production , define a deployment and expose it using nodePort , then use session persistence with kube-proxy set to serve from local node only.
– Ijaz Ahmad Khan
Nov 8 at 18:18
This article shows how to create Kubernetes Services in a Google Kubernetes Engine cluster And how to create a service of Nodeport.
– Milad
Nov 8 at 22:58
This article shows how to create Kubernetes Services in a Google Kubernetes Engine cluster And how to create a service of Nodeport.
– Milad
Nov 8 at 22:58
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
For Istio, You can use VirtualService to control the routing rules to the target subset with defining by DestinationRules.
The DestinationRule will route to the target Pods by the specified label pods.
The request flow will like to:
+--------------------+
| |
| Istio Gateway |
| |
| |
+---------+----------+
|traffic incoming
|
+---------v----------+
| |
| VirtualService |
| |
| |
+---------+----------+
|route to subset by the routing rules
v
+--------------------+
| |
| DestinationRules |
| |
| |
+---------+----------+
|route traffic to target pods
v
+--------------------+
| |
| |
| Pods |
| |
+--------------------+
so as @ericstaples said you should create different Deployments with different pod labels to achieve separating traffic to the target pods, Example:
- create a deployment with pod label: t1
- create a subset in DestinationRule: select t1 label pod as subset s1
- control your traffic in VirtualService that route to
s1
subset s1
route to the target pods
also for expose Gateway, you can use ClusterIP or NodePort like ** Kubernetes** other service did, see more of Istio Traffic.
There are some references maybe it's helpful:
https://istio.io/docs/concepts/traffic-management/
https://istio.io/docs/tasks/traffic-management/request-routing/
add a comment |
up vote
0
down vote
Now i have that solution with istio installed on the cluster:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: echo-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "dev.sample.com"
With that gateway i can apply that Deployment, Service, VirtualService
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-echo-1000-deployment
labels:
echoservice: echo-1000
spec:
replicas: 1
selector:
matchLabels:
echoservice: echo-1000
template:
metadata:
labels:
echoservice: echo-1000
spec:
containers:
- image: gcr.io/google-containers/echoserver:1.10
imagePullPolicy: IfNotPresent
name: my-echo-run-container
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: my-echo-1000-service
labels:
echoservice: echo-1000
spec:
ports:
- port: 8080
name: http
selector:
echoservice: echo-1000
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-echo-1000-vservice
spec:
hosts:
- "dev.sample.com"
gateways:
- echo-gateway
http:
- match:
- uri:
exact: /echo-1000
route:
- destination:
host: my-echo-1000-service
port:
number: 8080
Get the LoadbalancerIP from istio-ingressgateway and make an entry in /etc/hosts for dev.sample.com
Now i can get the echoserver in specific Pod with http://dev.sample.com/echo-1000
Is that a good solution or is there a better one?
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
For Istio, You can use VirtualService to control the routing rules to the target subset with defining by DestinationRules.
The DestinationRule will route to the target Pods by the specified label pods.
The request flow will like to:
+--------------------+
| |
| Istio Gateway |
| |
| |
+---------+----------+
|traffic incoming
|
+---------v----------+
| |
| VirtualService |
| |
| |
+---------+----------+
|route to subset by the routing rules
v
+--------------------+
| |
| DestinationRules |
| |
| |
+---------+----------+
|route traffic to target pods
v
+--------------------+
| |
| |
| Pods |
| |
+--------------------+
so as @ericstaples said you should create different Deployments with different pod labels to achieve separating traffic to the target pods, Example:
- create a deployment with pod label: t1
- create a subset in DestinationRule: select t1 label pod as subset s1
- control your traffic in VirtualService that route to
s1
subset s1
route to the target pods
also for expose Gateway, you can use ClusterIP or NodePort like ** Kubernetes** other service did, see more of Istio Traffic.
There are some references maybe it's helpful:
https://istio.io/docs/concepts/traffic-management/
https://istio.io/docs/tasks/traffic-management/request-routing/
add a comment |
up vote
0
down vote
For Istio, You can use VirtualService to control the routing rules to the target subset with defining by DestinationRules.
The DestinationRule will route to the target Pods by the specified label pods.
The request flow will like to:
+--------------------+
| |
| Istio Gateway |
| |
| |
+---------+----------+
|traffic incoming
|
+---------v----------+
| |
| VirtualService |
| |
| |
+---------+----------+
|route to subset by the routing rules
v
+--------------------+
| |
| DestinationRules |
| |
| |
+---------+----------+
|route traffic to target pods
v
+--------------------+
| |
| |
| Pods |
| |
+--------------------+
so as @ericstaples said you should create different Deployments with different pod labels to achieve separating traffic to the target pods, Example:
- create a deployment with pod label: t1
- create a subset in DestinationRule: select t1 label pod as subset s1
- control your traffic in VirtualService that route to
s1
subset s1
route to the target pods
also for expose Gateway, you can use ClusterIP or NodePort like ** Kubernetes** other service did, see more of Istio Traffic.
There are some references maybe it's helpful:
https://istio.io/docs/concepts/traffic-management/
https://istio.io/docs/tasks/traffic-management/request-routing/
add a comment |
up vote
0
down vote
up vote
0
down vote
For Istio, You can use VirtualService to control the routing rules to the target subset with defining by DestinationRules.
The DestinationRule will route to the target Pods by the specified label pods.
The request flow will like to:
+--------------------+
| |
| Istio Gateway |
| |
| |
+---------+----------+
|traffic incoming
|
+---------v----------+
| |
| VirtualService |
| |
| |
+---------+----------+
|route to subset by the routing rules
v
+--------------------+
| |
| DestinationRules |
| |
| |
+---------+----------+
|route traffic to target pods
v
+--------------------+
| |
| |
| Pods |
| |
+--------------------+
so as @ericstaples said you should create different Deployments with different pod labels to achieve separating traffic to the target pods, Example:
- create a deployment with pod label: t1
- create a subset in DestinationRule: select t1 label pod as subset s1
- control your traffic in VirtualService that route to
s1
subset s1
route to the target pods
also for expose Gateway, you can use ClusterIP or NodePort like ** Kubernetes** other service did, see more of Istio Traffic.
There are some references maybe it's helpful:
https://istio.io/docs/concepts/traffic-management/
https://istio.io/docs/tasks/traffic-management/request-routing/
For Istio, You can use VirtualService to control the routing rules to the target subset with defining by DestinationRules.
The DestinationRule will route to the target Pods by the specified label pods.
The request flow will like to:
+--------------------+
| |
| Istio Gateway |
| |
| |
+---------+----------+
|traffic incoming
|
+---------v----------+
| |
| VirtualService |
| |
| |
+---------+----------+
|route to subset by the routing rules
v
+--------------------+
| |
| DestinationRules |
| |
| |
+---------+----------+
|route traffic to target pods
v
+--------------------+
| |
| |
| Pods |
| |
+--------------------+
so as @ericstaples said you should create different Deployments with different pod labels to achieve separating traffic to the target pods, Example:
- create a deployment with pod label: t1
- create a subset in DestinationRule: select t1 label pod as subset s1
- control your traffic in VirtualService that route to
s1
subset s1
route to the target pods
also for expose Gateway, you can use ClusterIP or NodePort like ** Kubernetes** other service did, see more of Istio Traffic.
There are some references maybe it's helpful:
https://istio.io/docs/concepts/traffic-management/
https://istio.io/docs/tasks/traffic-management/request-routing/
answered Nov 10 at 18:29
chengpohi
11.5k1229
11.5k1229
add a comment |
add a comment |
up vote
0
down vote
Now i have that solution with istio installed on the cluster:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: echo-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "dev.sample.com"
With that gateway i can apply that Deployment, Service, VirtualService
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-echo-1000-deployment
labels:
echoservice: echo-1000
spec:
replicas: 1
selector:
matchLabels:
echoservice: echo-1000
template:
metadata:
labels:
echoservice: echo-1000
spec:
containers:
- image: gcr.io/google-containers/echoserver:1.10
imagePullPolicy: IfNotPresent
name: my-echo-run-container
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: my-echo-1000-service
labels:
echoservice: echo-1000
spec:
ports:
- port: 8080
name: http
selector:
echoservice: echo-1000
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-echo-1000-vservice
spec:
hosts:
- "dev.sample.com"
gateways:
- echo-gateway
http:
- match:
- uri:
exact: /echo-1000
route:
- destination:
host: my-echo-1000-service
port:
number: 8080
Get the LoadbalancerIP from istio-ingressgateway and make an entry in /etc/hosts for dev.sample.com
Now i can get the echoserver in specific Pod with http://dev.sample.com/echo-1000
Is that a good solution or is there a better one?
add a comment |
up vote
0
down vote
Now i have that solution with istio installed on the cluster:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: echo-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "dev.sample.com"
With that gateway i can apply that Deployment, Service, VirtualService
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-echo-1000-deployment
labels:
echoservice: echo-1000
spec:
replicas: 1
selector:
matchLabels:
echoservice: echo-1000
template:
metadata:
labels:
echoservice: echo-1000
spec:
containers:
- image: gcr.io/google-containers/echoserver:1.10
imagePullPolicy: IfNotPresent
name: my-echo-run-container
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: my-echo-1000-service
labels:
echoservice: echo-1000
spec:
ports:
- port: 8080
name: http
selector:
echoservice: echo-1000
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-echo-1000-vservice
spec:
hosts:
- "dev.sample.com"
gateways:
- echo-gateway
http:
- match:
- uri:
exact: /echo-1000
route:
- destination:
host: my-echo-1000-service
port:
number: 8080
Get the LoadbalancerIP from istio-ingressgateway and make an entry in /etc/hosts for dev.sample.com
Now i can get the echoserver in specific Pod with http://dev.sample.com/echo-1000
Is that a good solution or is there a better one?
add a comment |
up vote
0
down vote
up vote
0
down vote
Now i have that solution with istio installed on the cluster:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: echo-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "dev.sample.com"
With that gateway i can apply that Deployment, Service, VirtualService
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-echo-1000-deployment
labels:
echoservice: echo-1000
spec:
replicas: 1
selector:
matchLabels:
echoservice: echo-1000
template:
metadata:
labels:
echoservice: echo-1000
spec:
containers:
- image: gcr.io/google-containers/echoserver:1.10
imagePullPolicy: IfNotPresent
name: my-echo-run-container
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: my-echo-1000-service
labels:
echoservice: echo-1000
spec:
ports:
- port: 8080
name: http
selector:
echoservice: echo-1000
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-echo-1000-vservice
spec:
hosts:
- "dev.sample.com"
gateways:
- echo-gateway
http:
- match:
- uri:
exact: /echo-1000
route:
- destination:
host: my-echo-1000-service
port:
number: 8080
Get the LoadbalancerIP from istio-ingressgateway and make an entry in /etc/hosts for dev.sample.com
Now i can get the echoserver in specific Pod with http://dev.sample.com/echo-1000
Is that a good solution or is there a better one?
Now i have that solution with istio installed on the cluster:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: echo-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "dev.sample.com"
With that gateway i can apply that Deployment, Service, VirtualService
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-echo-1000-deployment
labels:
echoservice: echo-1000
spec:
replicas: 1
selector:
matchLabels:
echoservice: echo-1000
template:
metadata:
labels:
echoservice: echo-1000
spec:
containers:
- image: gcr.io/google-containers/echoserver:1.10
imagePullPolicy: IfNotPresent
name: my-echo-run-container
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: my-echo-1000-service
labels:
echoservice: echo-1000
spec:
ports:
- port: 8080
name: http
selector:
echoservice: echo-1000
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-echo-1000-vservice
spec:
hosts:
- "dev.sample.com"
gateways:
- echo-gateway
http:
- match:
- uri:
exact: /echo-1000
route:
- destination:
host: my-echo-1000-service
port:
number: 8080
Get the LoadbalancerIP from istio-ingressgateway and make an entry in /etc/hosts for dev.sample.com
Now i can get the echoserver in specific Pod with http://dev.sample.com/echo-1000
Is that a good solution or is there a better one?
answered Nov 12 at 16:03
micha
115
115
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53212748%2fkubernetes-route-incomming-traffic-to-specific-pod%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
A standalone
Pod
is not the way to go for this and is most certainly an anti-pattern. Your best bet is to move up a couple abstractions to theDeployment
resource, and then you can deploy multiple copies of yourPod
with some variation in labels between them to dictate ingress and routing.– ericstaples
Nov 8 at 17:51
Pod is not something to work with in production , define a deployment and expose it using nodePort , then use session persistence with kube-proxy set to serve from local node only.
– Ijaz Ahmad Khan
Nov 8 at 18:18
This article shows how to create Kubernetes Services in a Google Kubernetes Engine cluster And how to create a service of Nodeport.
– Milad
Nov 8 at 22:58