标签：container network Kubernetes communications Pod k8s ports
https://kubernetes.io/docs/concepts/cluster-administration/networking/
Cluster Networking
Networking is a central part of Kubernetes, but it can be challenging to understand exactly how it is expected to work.
There are 4 distinct networking problems to address:
- Highly-coupled container-to-container communications: this is solved by Pods and localhost communications.
- Pod-to-Pod communications: this is the primary focus of this document.
- Pod-to-Service communications: this is covered by services.
- External-to-Service communications: this is covered by services.
Kubernetes is all about sharing machines between applications.
Typically, sharing machines requires ensuring that two applications do not try to use the same ports.
Coordinating ports across multiple developers is very difficult to do at scale and
exposes users to cluster-level issues outside of their control.
Dynamic port allocation brings a lot of complications to the system
every application has to take ports as flags, the API servers have to know how to insert dynamic port numbers
into configuration blocks, services have to know how to find each other, etc.
Rather than deal with this, Kubernetes takes a different approach.
The Kubernetes network model
Every Pod gets its own IP address.
This means you do not need to explicitly create links between Pods and
you almost never need to deal with mapping container ports to host ports.
This creates a clean, backwards-compatible model
where Pods can be treated much like VMs or physical hosts from the perspectives of
port allocation, naming, service discovery, load balancing, application configuration, and migration.
Kubernetes imposes the following fundamental requirements on any networking
implementation (barring any intentional network segmentation policies):
- pods on a node can communicate with all pods on all nodes without NAT
- agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node
Note: For those platforms that support Pods running in the host network (e.g. Linux):
- pods in the host network of a node can communicate with all pods on all nodes without NAT
This model is not only less complex overall, but it is principally compatible with the desire for Kubernetes
to enable low-friction porting of apps from VMs to containers.
If your job previously ran in a VM, your VM had an IP and could talk to other VMs in your project.
This is the same basic model.
Kubernetes IP addresses exist at the Pod scope
containers within a Pod share their network namespaces, including their IP address and MAC address.
This means that containers within a Pod can all reach each other's ports on localhost.
This also means that containers within a Pod must coordinate port usage,
but this is no different from processes in a VM.
This is called the IP-per-pod model.
How this is implemented is a detail of the particular container runtime in use.
It is possible to request ports on the Node itself which forward to your Pod (called host ports),
but this is a very niche operation. How that forwarding is implemented is also a detail of the container runtime.
The Pod itself is blind to the existence or non-existence of host ports.
https://kubernetes.io/docs/concepts/services-networking/service/
标签：container,network,Kubernetes,communications,Pod,k8s,ports 来源： https://www.cnblogs.com/Searchor/p/14713619.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。