Can't get UDP packets to my container in kubernetes [MiniKube] - docker

I'm new to Kubernetes, but have managed to build myself a container that runs perfectly directly under Docker and also seems to run up fine in a k8s deployment.
The container is an implementation of a couple of UDP packet replicators from github installed on Ubuntu.
When it's running directly under Docker on my machine, I can send UDP packets to the container and have them replicated back to different ports on my machine proving that the replication works. (Sending and receiving the packets with netcat).
However, I think I am missing something in the k8s networking side of things.
I am using MiniKube on my machine and I am using the following k8s manifest to create the deployment with just one container.
apiVersion: apps/v1
kind: Deployment
metadata:
name: samplicator-deployment
labels:
app: samplicator
spec:
replicas: 1
selector:
matchLabels:
app: samplicator
template:
metadata:
labels:
app: samplicator
spec:
containers:
- name: samplicator-container-01
image: dgbes/udp-fan-out-tools:latest
command: ["samplicate"]
args: ["-p3160","192.168.1.159/3161","192.168.1.159/3162"]
ports:
- name: receiver
protocol: UDP
containerPort: 3160
I then create the deployment with: kubectl apply -f create-samplicator-deployment.yaml
I then set up a couple of UDP listeners with netcat on my host machine with nc -ulk -p 3161 and nc -ulk -p 3162.
If I then connect to the running container with kubectl exec --stdin --tty samplicator-deployment-{randomPodName} -- /bin/bash and manually use netcat send packets to my host machine I can see those arriving no problem.
I find the container/pod IP address with kubectl get pod -o wide.
When I try to send a packet to the samplicator process in the pod, though, I see nothing coming back to my host machine.
So, I then spawned a shell in the container/pod, checked that the samplicator process was running correctly (it was), and installed netcat in the container instance.
Using netcat -u {my host machine IP} 3161 I can send packets from the container to my host machien and they are received no problem.
So, it seems that the issue is getting the packets TO the container.
I confirmed this by running nc -ulk -p 3600 in the container shell and sending a packet from my host to that port in the container - nothing is received in the container.
I am aware that the ports need to be exposed on the container and that 'services' are used for this, but I thought that that was what the ports: section in the template spec of the deployment was doing.
That didn't create a service to expose the port, so I added a service definition to the end of my deployment manifest YAML as follows:
---
apiVersion: v1
kind: Service
metadata:
name: samplicator-service
spec:
selector:
app: samplicator
type: LoadBalancer
ports:
- name: receiver-service
protocol: UDP
port: 3160
targetPort: 3160
I'm obviously missing something here, and my apologies if my k8s terminology is a bit mangled - as I say I'm completely new to k8s.
Any pointers to how to correctly make that UDP port reachable?

I figured it out...
Service type=LoadBalancer doesn't work with MiniKube as it relies on an external cloud service apparently.
I noticed that my service was sat in a pending state with the ExternalIP never being allocated, which lead me to this answer.
The magic being to simply run the following command in a separate terminal window which then allowed the external IP to be allocated to the service.
minikube tunnel
Once that was run and the ExternalIP allocated, sending packets to that ExternalIP works perfectly.

Related

How to block outgoing traffic to ip in IP tables in K8S

I want block outgoing traffic to the ip (eg-DB) in IP tables in K8s.
I know that in K8s ip tables exist only at node level.
and I'm not sure in which file changes should be made and what is the command or changes required.
Please help me with this query.
Thanks.
You could deploy istio and specifically the istio egress gateway.
This way you will be able to manage outgoing traffic within the istio manifest
You can directly run the IPtable command (ex. iptables -A OUTPUT -j REJECT) on top of a node if that's fine.
however file depends on the OS : /etc/sysconfig/iptables this is for ipv4
i would suggest checking out the Network policy in Kubernetes using that you can block the outgoing traffic.
https://kubernetes.io/docs/concepts/services-networking/network-policies/
No extra setup is required like Istio or anything.
Cluster security you can handle using the network policy in the backend it uses IP tables only.
For example to block traffic on specific CIDR or IP by applying the YAML only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978

Kubernetes: Frontend-Pod cannot resolve dns of Backend-Service (using Minikube)

I am learning Kubernetes and i run into trouble reaching an API in my local Minikube (Docker driver).
I have a pod running an angluar-client which tries to reach a backend pod. The frontend Pod is exposed by a NodePort Service. The backend pod is exposed to the Cluster by a ClusterIP Service.
But when i try to reach the clusterip service from the frontend the dns transpile-svc.default.svc.cluster.local cannot get resolved.
error message in the client
the dns should work properly. i followed this https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/ and deployed a dnsutils pod from where i can nslookup.
winpty kubectl exec -i -t dnsutils -- nslookup transpile-svc.default
Server: 10.96.0.10
Address: 10.96.0.10#53
Name: transpile-svc.default.svc.cluster.local
Address: 10.99.196.82
This is the .yaml file for the clusterIP Service
apiVersion: v1
kind: Service
metadata:
name: transpile-svc
labels:
app: transpile
spec:
selector:
app: transpile
ports:
- port: 80
targetPort: 80
Even if i hardcode the IP into the request of the frontend i am getting an empty response.
I verified, that the backend pod is working correctly and when i expose it as a NodePort i can reach the api with my browser.
What am i missing here? Im stuck with this problems for quite some time now and i dont find any solution.
Since your frontend application is calling your application from outside the cluster you need to expose your backend application to outside network too.
There are two ways: either expose it directly by changing transpile-svc service to loadbalancer type or introduce an ingress controller(eg Nginx ingress controller with an Ingres object) which will handle all redirections
Steps to expose service as loadbalancer in minikube
1.Change your service transpile-svc type to LoadBalancer
2.Run command minikube service transpile-svc to expose the service ie an IP will be allocated.
3. Run kubectl get services to get external IP assigned. Use IP:POST to call from frontend application
DNS hostnames *.*.svc.cluster.local is only resolvable from within the kubernetes cluster. You should use http://NODEIP:NODEPORT or url provided by minikube service transpile-svc --url in the frontend javascript code which is running in a browser outside the kubernetes cluster.
If the frontend pod is nginx then you can configure the backend service name as below in the nginx configuration file as described in the docs
upstream transpile {
server transpile;
}
server {
listen 80;
location / {
proxy_pass http://transpile-svc;
}
}

GKE - Bypass Pod LoadBalancer (Pod's external IP) to Pod's container's IP at runtime for WebSocket purpose

I have the following situation:
I have a couple of microservices, only 2 are relevant right now.
- Web Socket Service API
- Dispatcher Service
We have 3 users that we'll call respectively 1, 2, and 3. These users connect themselves to the web socket endpoint of our backend. Our microservices are running on Kubernetes and each services can be replicated multiple times inside Pods. For this situation, we have 1 running container for the dispatcher, and 3 running containers for the web socket api. Each pod has its Load Balancer and this will be each time the entry point.
In our situation, we will then have the following "schema":
Now that we have a representation of our system (and a legend), our 3 users will want to use the app and connect.
As we can see, the load balancer of our pod forwarded the web socket connection of our users across the different containers. Each container, once it gets a new connection, will let to know the Dispatcher Service, and this one will save it in its own database.
Now, 3 users are connected to 2 different containers and the Dispatcher service knows it.
The user 1 wants to message user 2. The container A will then get a message and tell the Dispatcher Service: Please, send this to the user 2.
As the dispatcher knows to which container the user 2 is connected, I would like to send a request directly to my Container instead of sending it to the Pod. Sending it to the Pod is resulting in sending a request to a load balancer which actually dispatches the request to the most available container instance...
How could I manage to get the container IP? Can it be accessed by another container from another Pod?
To me, the best approach would be that, once the app start, it gets the current container's IP and then send it within the register request to the dispatcher, so the dispatcher would know that ContainerID=IP
Thanks!
edit 1
There is my web-socket-service-api.yaml
apiVersion: v1
kind: Service
metadata:
name: web-socket-service-api
spec:
ports:
# Port that accepts gRPC and JSON/HTTP2 requests over HTTP.
- port: 8080
targetPort: 8080
protocol: TCP
name: grpc
# Port that accepts gRPC and JSON/HTTP2 requests over HTTP.
- port: 8081
targetPort: 8081
protocol: TCP
name: rest
# Port that accepts WebSockets.
- port: 8082
targetPort: 8082
protocol: TCP
name: websocket
selector:
app: web-socket-service-api
type: LoadBalancer
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: web-socket-service-api
spec:
replicas: 3
template:
metadata:
labels:
app: web-socket-service-api
spec:
containers:
- name: web-socket-service-api
image: gcr.io/[PROJECT]/web-socket-service-api:latest
ports:
- containerPort: 8080
- containerPort: 8081
- containerPort: 8082
Dispatcher ≈ Message broker
As how I understand your design, your Dispatcher is essentially a message broker for the pods of your Websocket Service. Let all Websocket pods connect to the broker and let the broker route messages. This is a stateful service and you should use a StatefulSet for this in Kubernetes. Depending on your requirements, a possible solution could be to use a MQTT-broker for this, e.g. mosquitto. Most MQTT brokers have support for websockets.
Scale out: Multiple replicas of pods
each services can be replicated multiple times inside Pods. For this situation, we have 1 running container for the dispatcher, and 3 running containers for the web socket api.
This is not how Kubernetes is intented to be used. Use multiple replicas of pods instead of multiple containers in the pod. I recommend that you create a Deployment for your Websocket Service with as many replicas you want.
Service as Load balancer
Each pod has its Load Balancer and this will be each time the entry point.
In Kubernetes you should create a Service that load balance traffic to a set of pods.
Your solution
To me, the best approach would be that, once the app start, it gets the current container's IP and then send it within the register request to the dispatcher, so the dispatcher would know that ContainerID=IP
Yes, I mostly agree. That is similar to what I have described here. But I would let the Websocket Service establish a connection to the Broker/Dispatcher.
Any pod, has some information about itself. And one of the info, is it own IP address. As an example:
apiVersion: v1
kind: Pod
metadata:
name: envars-fieldref
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "sh", "-c"]
args:
- while true; do
echo -en '\n';
printenv MY_POD_IP;
sleep 10;
done;
env:
- name: MY_POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
Within the container, MY_POD_IP would contain the IP address of the pod. You can let the dispatcher know about it.
$ kubectl logs envars-fieldref
10.52.0.3
$ kubectl get po -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
envars-fieldref 1/1 Running 0 31s 10.52.0.3 gke-klusta-lemmy-3ce02acd-djhm <none> <none>
Note that it is not a good idea to rely on pod IP address. But this should do the trick.
Also, it is exactly the same thing to send a request to the pod or to the container.

communication between two PODs in a single node(minikube )

I have to communicate between two PODs in minikube which are exposed in two different ports but are in a single node.
For example:
POD A uses 8080 port and which is the landing page.
From POD A we access POD B via hyperlink which uses 8761 port.
Now, in kubernetes it assigns a port dynamically eg: POD A: 30069 and POD B: 30070
Problem here is: it does not automatically map kubernetes port for POD B (30070) while accessing POD B from POD A(30069). Instead POD B tries to open in 8761 port.
Apologies if my description is confusing. Please feel free to recheck if you could not relate to my question.
Thanks for your help
I have to communicate between two PODs in minikube which are exposed in two different ports but are in a single node.
Based on the facts that you want inter-pod communication and that pods reside on the same node, you could have several (rather questionable and fragile) approaches such as hostname and nodePort exposures. In order to be more in line with kubernetes approach and recommendations I'd advise to use Service instead of exposing ports directly from Pod level.
You can read more about Services in the official documenatation and example for Service usage would be like so:
kind: Service
apiVersion: v1
metadata:
name: my-pod-b-service
spec:
selector:
app: MyPodBApp
ports:
- protocol: TCP
port: 80
targetPort: 8761
This specification will create a new Service object named my-pod-b-service which targets TCP port 8761 on any Pod with the app=MyPodBApp label. With that any request coming from pod A for host: my-pod-b-service and port: 80 would be served by some pod B on port 8761 (note that port and targetPort can be the same, this is just an example).
As a side note, for pod A you would have something like:
kind: Service
apiVersion: v1
metadata:
name: my-pod-a-service
spec:
selector:
app: MyPodAApp
ports:
- protocol: TCP
port: 80
targetPort: 8080
Since you target services, you can map same incoming port (80) to both services, and kubernetes is taking care that each comes to appropriate pods, as long as pod selector is properly set on pods.
If there is a correct mapping between the deployment and service name then just a curl request to name:port can be used for communication.
For example,
create a deployment
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
expose it on port 8080
kubectl expose deployment hello-node --type=NodePort --port=8080
another deployment with same image but different name
create deployment hello-node2 --image=gcr.io/hello-minikube-zero-install/hello-node
expose it on port 8080 expose deployment hello-node2 --type=NodePort --port=8080
get pods and start a terminal inside hello-node2 deployment
kubectl get pods
kubectl exec -it <hello-node2-pod-name> -- /bin/bash
you will enter in the container of hello world 2 pod
curl hello-node:8080 returns Hello World!
Also if you have a close look, kubectl describe service hello-node
gives you with an IP field (which is different form Endpoints). This is actually an exposed IP for communication to the pod. Which means inside hello world 2 container if you run
curl <IP from service> : 8080
returns Hello World!
Hope this helps.

How can I access the Kubernetes service through ClusterIP

I am trying to create Kubernetes cluster using three VMs(Master – 10.x.x.4, Node1 – 10.x.x.150, Node2 – 10.x.x.160).
I was able to create the guestbook application successfully following this link: http://kubernetes.io/v1.0/examples/guestbook/. Only one change I made to frontend-service.yaml: to use NodePort. I can access the frontend service using nodes IP and port number(10.x.x.150:30724 or 10.x.x.160:30724). So everything is working as expected but I am not able to access the frontend service using ClusterIP address(in my case 10.x.x.79).
My understanding of NodePort is that the service can be accessed through cluster IP and also on a port on each node of the cluster. How can I access the service through ClusterIP so that I don’t have to access the each node? Am I missing something here?
service and pod details
$sudo kubectl describe service frontend
Name: frontend
Namespace: default
Labels: name=frontend
Selector: name=frontend
Type: NodePort
IP: 10.x.x.79
Port: <unnamed> 80/TCP
NodePort: <unnamed> 30724/TCP
Endpoints: 172.x.x.13:80,172.x.x.14:80,172.x.x.11:80
Session Affinity: None
No events.
$sudo kubectl describe pod frontend-2b5us
Name: frontend-2b5us
Namespace: default
Image(s): gcr.io/google_samples/gb-frontend:v3
Node: 10.x.x.150/10.x.x.150
Labels: name=frontend
Status: Running
Reason:
Message:
IP: 172.x.x.11
Replication Controllers: frontend (3/3 replicas created)
Containers:
php-redis:
Image: gcr.io/google_samples/gb-frontend:v3
State: Running
Started: Fri, 30 Oct 2015 04:00:40 -0500
Ready: True
Restart Count: 0
I tried to search but would not find any solution for my exact problem but I did find similar problem that looks like for GCE.
Why can't I access my Kubernetes service via its IP?
You do not have ClusterIP service. You do have a NodePort service. To access it, you connect to the NodePort on any of your nodes in the cluster, as you've already discovered. You do get load-balancing here. Even though you connect to a cluster node, the pod you get does not necessarily run on that particular node.
Read the relevant section in the documentation at https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services---service-types to learn about additional service types. You probably do not want NodePort on GCP.
Talking about ClusterIP. To access a ClusterIP service for debugging purposes, you can run kubectl port-forward. You will not actually access the service, but you will directly connect to one of the pods.
For example
kubectl port-forward frontend-2b5us 80 8080
Now connect to localhost:8080
More sophisticated command, which discovers the port on its own, given namespace -n weave and a selector. Taken from https://www.weave.works/docs/scope/latest/installing/
kubectl port-forward -n weave \
"$(kubectl get -n weave pod \
--selector=weave-scope-component=app \
-o jsonpath='{.items..metadata.name}')" \
4040
From where are you trying to access clusterIP? The clusterIP (by default) only works from within the cluster. It is a virtual IP, not routed.

Resources