Needs to be cloned to Part 4. Part 4 redundancy section describe a pool of hot redundant servers that can be accessed round robin by clients for load balancing. This works where the servers in the hot set all have certs from the same CA and its the CA that is trusted by the Clients (not the individual certs.);

Added text explaining that unique certificates are required and if CA based certificate are used, then trust issue can be easily handled

I am not sure why any solution that adresses the original question would make sense for what the hostname/DNS name is in the certificate.

The DNS name in the certificate is used by the client to compare the hostname in the EndpointUrl used to connect with the certificate.
Does this DNS name of the server really change?
Are the intenal names used by clients to connect?

As I understand it - there are a couple of possibilities depending on where the client is and how the application is spun up, but typically each container is a lightweight Virtual machine. They can connect to other containers, ,a host or external network. Container are deployed in a pod on a host. If two containers are in the same pod, they can share storage and networking resources - each pod gets an IP address. A server and a client that are in different containers but in the same pod would communicate via LocalHost and a port number. A virtual machine (or physical one) can have multiple pods on it. Communication between pods looks like normal network connection, but it is over a virtual network (Kubernetes network) that is on that node. \ As I understand it there is a special DNS that further processes IP Address when communication is between nodes on a single machine. If communications is to a node that is not part of the virtual network on the given node, it is transfer to the external network for standard network processing. Kubernetes clusters have a specialized service for DNS resolution. A service automatically receives a domain name in the form <service>.<namespace>.svc.cluster.local. This service is required for to allow external access to the containers.

There is a related note from Jouni on 0009332:
The containers can share the hostname, although it's not necessarily straight forward how to accomplish it (via a configuration file on the persistent volume or the certificate - or an argument to the container if it's started manually from the Docker host).

They will need to share the connection address anyway, so that the clients can connect.

But, maybe it's a good idea to describe how the containerised applications should be configured.

had discussion in UA call today - so resulting notes (will also add some notes to the Part 4 issue)

• don't us specific tech in descriptions (i.e. discuss containers not kubernetes), Discussion could also include VMs especially when deployed behind a NAT (cloud has a number of VMs running but externally they are one address, just different ports.

The following updated was proposed for Part 2 - but pulled until additional text is provided in other parts (first to describe containers)

6.20 Container related deployment issues
The use of containers for deployment of applications (both Clients and Servers) is a growing trend. Containers can be used for scaling, in that multiple instances of the same OPC UA Application can be activated – each in their own container. Containers can be used for Hot redundant server, where each container is a distinct UA Server that can be used for load sharing. Hot redundant systems, which are further described in OPC 10000-4, All distinct OPC UA Applications are required to have a unique security footprint, thus even if multiple instances of the same OPC UA Application are running each shall have a unique ApplicationInstance and utilize a unique ApplicationInstanceCertificate, that describe the unique instance. The deployment of new container instance, would require security configuration to allow the new OPC UA Application to be trusted, unless the ApplicationInstanceCertificate are all CA based and the CA is trusted. In this case any new container would automatically be trusted.