docker
/
docker-mailserver
mirror of https://github.com/tomav/docker-mailserver.git
1
0
Fork 0
Code Issues Releases Wiki Activity

rephrasing for exposing DMS section

This commit is contained in:
georglauterbach 2024-03-08 17:47:32 +01:00
parent aa6894e5fa
commit 48fddf3e21
No known key found for this signature in database
GPG Key ID: F367F7C43C118578
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/content/config/advanced/kubernetes.md
View File

@ -363,11 +363,11 @@ The major problem with exposing DMS to the outside world in Kubernetes is to [pr
- You can dedicate a publicly routable IP address to the DMS configured `Service` (_e.g. with a load balancer like [MetalLB][metallb-web]_).
- That IP is required to be dedicated to allow your mail server to have matching `A` and `PTR` records (_which other mail servers will use to verify trust when they receive mail sent from your DMS instance_).
The upside is that the manifests files and the configuration do not become more complex; the downside is that you require a dedicated IPv4 address and you are stuck to the node that has this IP address bound.
This approach has the advantage of being relatively simple. The disadvantage is that you require a dedicated IPv4 address, and you are limited to the node with this IP address.
=== "External-IP Service"
Another simple way is to expose DMS as a `Service` with [external IPs][Kubernetes-network-external-ip]. This approach is very similar to the former approach. Here, an external IP is given to the service directly by you. With the approach above, you tell your load-balancer to do this.
Another simple way is to expose DMS as a `Service` with [external IPs][Kubernetes-network-external-ip]. This approach is very similar to the previous approach (Load Balancer + Public IP). Here, an external IP is given to the service directly by you. With the previous approach, you tell your load-balancer to do this for you.
```yaml
---