I have a question regarding Kubernetes networking.
I know that in Docker swarm if I want to run difference containers on difference servers, I need to create an overlay network, and then all the containers (from all the servers) will be attached to this network and they can communicate with each other (for example, I can ping from container A to container B).
I guess that in Kubernetes there isn't an overlay network - but another solution. For example, I would like to create 2 linux containers on 2 servers (server 1: ubuntu, server 2: centos7), so how do the pods communicate with each other if there isn't an overlay network?
And another doubt - can I create a cluster which consists of windows and linux machines with kubernetes?I mean, a multi platform kubernetes which all the pods communicate with each other.
Thanks a lot!!
In kubernetes, pods communicate with each other through service. To access any pod within cluster, it must be exposed using clusterIP service. So if you created service before creating pods, you will have env variable for each available service within container. Using that you can ping or access services and in turn pods.
For example:
Suppose you have two pods U1 and C1 and those are exposed by service named U-SVC and C-SVC respectively.
So if you want to access C1 from U1, you will have C-SVC service env variables(C-SVC_SERVICE_HOST,C-SVC_SERVICE_PORT) within container which you can use for access.
Also if DNS server set for your cluster, you can access service without env varibles.
Related
CASE 1: Suppose there is a pod running locally (running some workload/app )on a device1 and another pod running in EC2 instance running on AWS EKS instance . How can both of them communicate
CASE 2: Suppose there is a pod running locally (running some workload/app )on a device1 and another device 2 . How can both of them communicate ?
Pods can run locally using minikube or even directly using kubectl commands.
Problem :I know that pods within the same cluster can communicate with another Pod by directly addressing its IP address but how can pods on different clusters can communicate and what protocols they can use? .Please help me with this .
You can expose the service publicly if you are looking for easy option and setup.
You can use the External IP (service type load balancer) or you can use the ingress controllers(nginx, kong, traefik) to expose the services.
For multi-cluster communication and service discovery you can use the service mesh like Istio and linkerD :
https://istio.io/latest/blog/2020/multi-cluster-mesh-automation/
LinkerD multicluster east-west setup: https://linkerd.io/2.11/features/multicluster/
The pods can communicate with each other if they are exposed publicly via
External IP e.g https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address/
User Service to expose your pod publicly https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/
If you require the pods to communicate using private ip using internal network, you can consider using VPC peering (connect all 3 networks that Device 1, Device 2 and Cloud/AWS VPC). This will require some networking knowledge to setup.
The setup below is all done on Google Cloud.
I have a Docker setup running on a VM instance having a Hyperledger Fabric Network of 3 Orderers and 2 peers of a single organization.
I have a Kubernetes Cluster running on GKE having just 2 peer pods.
What I want to achieve is:
I want the peer pod of Kubernetes to be able to communicate with the network setup in Docker.
i.e. I want at least 1 peer of the Kubernetes to be able to join the network channel on the Docker
Network and be able to perform some transaction/query.
Till now what I have done is exposed the services of the 2 peer pods in Kubernetes i.e. ClusterIP -> NodePort.
I have done some reading as to what options are there such as having an Nginx proxy and other things, but I am new to this and still in a beginner phase so a few things are still confusing to me.
Any help would be appreciated.
Since you have two separate container setups (and two different container technologies), containers in one space have to communicate with the other as though they're outside the cluster. You can't join arbitrary Docker containers on another instance into the Kubernetes network environment, nor can you join Kubernetes pods into a single-host Docker network environment.
Using a NodePort or LoadBalancer-type Service as you already have is close to the best you can do, particularly if the underlying protocol isn't HTTP. If you need a multi-host setup, migrating the whole thing into GKE might be a better long-term answer.
Am trying to implement a cluster of containerised applications in the production using docker in the swarm mode.
Let me describe a very minimalist scenario.
All i have is just 5 aws-ec2 instances.
None of these nodes have a public IP assigned and all have private IPs assigned part of a subnet.
For example,
Manager Nodes
172.16.50.1
172.16.50.2
Worker Nodes
172.16.50.3
172.16.50.4
172.16.50.5
With the above infrastructure, have created a docker swarm with the first node's IP (172.16.50.1) as the --advertise-addr so that the other 4 nodes join the swarm as manager or worker with their respective tokens.
I didn't want to overload the Manager Nodes by making them doing the role of worker nodes too. (Is this a good idea or resource under-utilization?).
Being the nodes are 4 core each, am hosting 9 replicas of my web application which are distributed in the 3 worker nodes each running 3 containers hosting my web app.
Now with this setup in hand, how should i go about exposing the entire docker swarm cluster with a VIP (virtual IP) to the external world for consumption?
please validate my below thoughts:
1. Should I have a classic load-balancer setup like keeping a httpd or nginx or haproxy based reverse proxy which has a public IP assigned
and make it balance the load to the above 5 nodes where our
docker-swarm is deployed?
One downside I see here is that the above reverse-proxy would be Single Point of Failure? Any ideas how this could be made fault-tolerant/hightly available? should I try a AnyCast solution?
2. Going for a AWS ALB/ELB which would route the traffic to the above 5 nodes where our swarm is.
3. If keeping a separate Load Balancer is the way to go, then what does really docker-swarm load-balancing and service discovery is all
about?
what is docker swarm's answer to expose 1 virtual IP or host name to the external clients to access services in the swarm cluster?
Docker-swarm touts a lot about overlay networks but not sure how it
relates to my issue of exposing the cluster via VIP to clients in the
internet. Should we always keep the load balancer aware of the IP
addresses of the nodes that join the docker swarm later?
please shed some light!
On further reading, I understand that the Overlay Network we are creating in the swarm manager node only serves inter container communication.
The only difference from the other networking modes like bridge, host, macvlan is that the others enables communication among containers with in a single host and while the Overlay network facilitates communication among containers deployed in different subnets too. i.e., multi-host container communication.
with this knowledge as the headsup, to expose the swarm to the world via a single public IP assigned to a loadbalancer which would distribute requests to all the swarm nodes. This is just my understanding at a high level.
This is where i need your inputs and thoughts please...explaining the industry standard on how this is handled?
So I've got a Plex server running on my Docker swarm!! If I kill a node magically it'll start Plex somewhere else. This is great! Now comes the fun part...
With old-school containers I would just port forward port 32400 on my router to the server that was running Plex and it would work find. Now that Plex can run in multiple different places I need to figure out how to forward the port to some static resource. I could use HAProxy to bind some bridge interface and run it on every node to provide failover...but I'd like to see if there's an easier way to accomplish this.
What's the best way to forward ports to services in Docker Swarm?
Port forwarding is built into the new swarm mode. There's a section on load balancing in the documentation:
The swarm manager uses ingress load balancing to expose the services
you want to make available externally to the swarm. The swarm manager
can automatically assign the service a PublishedPort or you can
configure a PublishedPort for the service in the 30000-32767 range.
External components, such as cloud load balancers, can access the
service on the PublishedPort of any node in the cluster whether or not
the node is currently running the task for the service. All nodes in
the swarm cluster route ingress connections to a running task
instance.
Swarm mode has an internal DNS component that automatically assigns
each service in the swarm a DNS entry. The swarm manager uses internal
load balancing to distribute requests among services within the
cluster based upon the DNS name of the service.
Update
The following article discusses how to integrate a proxy load balancer into the docker engine
https://technologyconversations.com/2016/08/01/integrating-proxy-with-docker-swarm-tour-around-docker-1-12-series/
What I want to do is run kubernetes within docker and expose the kubernetes services externally. I followed the docs on getting kubernetes running within docker. As long as I connect from the localhost, I can access my services. However, connecting from a different computer doesn't work. If I spin up a docker image directly, then I can access it. Only things running within kubernetes aren't exposed. Is this possible?
Ensure your nodes have externally reachable IP addresses.
Then create a service of type NodePort:
https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/services.md#type-nodeport
And direct traffic to nodes at the allocated port.