Docker DCA Practice Test - Questions Answers, Page 17

A Kubernetes node is allocated a /26 CIDR block (64 unique IPs) for its address space. This means that the node can assign up to 64 IP addresses to its resources, such as pods and containers. If every pod on this node has exactly two containers in it, then each pod will need two IP addresses, one for each container. Therefore, the node can support up to 32 pods, since 64 / 2 = 32. The other options are incorrect because they either exceed the available IP addresses or do not account for the number of containers per pod.

Reference:

* CIDR Blocks and Container Engine for Kubernetes - Oracle

* How kubernetes assigns podCIDR for nodes? - Stack Overflow

The command kubectl drain <node name> is the correct one to run on the node to gracefully terminate all pods on the node, while marking the node as unschedulable. This command will safely evict all the pods from the node before you perform maintenance on the node, such as installing patches or an OS upgrade1. It will respect the PodDisruptionBudgets you have specified, if any, and allow the pod's containers to gracefully terminate1. It will also mark the node as unschedulable, so that no new pods can be scheduled on the node until it is ready1.

The other commands are not correct because:

* docker swarm leave will make the node leave the swarm cluster, but it will not affect the Kubernetes workloads on the node2.

* docker node update -availability drain <node name> will change the availability of the node to drain, which means that no new tasks can be assigned to the node, but it will not terminate the existing pods on the node3.

* kubectl cordon <node name> will mark the node as unschedulable, but it will not evict the pods on the node4.

* Safely Drain a Node | Kubernetes

* [docker swarm leave | Docker Docs]

* [docker node update | Docker Docs]

* [kubectl cordon | Kubernetes Docs]

: The networking drivers that allow you to enable multi-host network connectivity between containers are bridge, macvlan, ipvlan, and overlay. These drivers create networks that can span multiple Docker hosts, and therefore enable containers on different hosts to communicate with each other. The other drivers, such as host, user-defined, and none, create networks that are either isolated or limited to a single host. Here is a brief overview of each driver and how it supports multi-host networking:

* bridge: The bridge driver creates a network that connects containers on the same host using a Linux bridge. However, it can also be used to create a network that connects containers across multiple hosts using an external key-value store, such as Consul, Etcd, or ZooKeeper. This feature is deprecated and not recommended, as it requires manual configuration and has some limitations. The preferred driver for multi-host networking is overlay1.

* macvlan: The macvlan driver creates a network that assigns a MAC address to each container, making it appear as a physical device on the network. This allows the containers to communicate with other devices on the same network, regardless of the host they are running on. The macvlan driver can also use 802.1q trunking to create sub-interfaces and isolate traffic between different networks2.

* ipvlan: The ipvlan driver creates a network that assigns an IP address to each container, making it appear as a logical device on the network. This allows the containers to communicate with other devices on the same network, regardless of the host they are running on. The ipvlan driver can also use different modes, such as l2, l3, or l3s, to control the routing and isolation of traffic between different networks3.

* overlay: The overlay driver creates a network that connects multiple Docker daemons together using VXLAN tunnels. This allows the containers to communicate across different hosts, even if they are on different networks. The overlay driver also supports encryption, load balancing, and service discovery. The overlay driver is the default and recommended driver for multi-host networking, especially for Swarm services4.

* Use bridge networks

* Use macvlan networks

* Use ipvlan networks

* Use overlay networks

Docker Universal Control Plane (UCP) has its own built-in authentication mechanism and integrates with LDAP services1. It also has role-based access control (RBAC), so that you can control who can access and make changes to your cluster and applications1. However, there is no mention of Docker ID being a supported user authentication method for UCP in the resources provided1234.

They provide granular control over where pods (or in this case, containers) are scheduled, based on the labels of the nodes1. In the context of Docker Swarm, this means that you could use node affinities to ensure that development and production containers are scheduled on separate nodes, thus meeting the company's security policy requirements12345.

The command 'docker ps http' is not the correct command to view the list of historical tasks for a service in Docker1. The 'docker ps' command is used to list containers1. If you want to view the list of historical tasks for a service, you should use the 'docker service ps' command2. This command lists the tasks that are running as part of the specified services and also shows the task history2. Therefore, to view the list of historical tasks for the 'http' service, you should use the command 'docker service ps http'2.

The statement is not entirely correct. In Kubernetes, a service of type ClusterIP routes traffic sent to its IP address to the pods selected by its label selector1. However, the port to which the traffic is routed in the pod is determined by the targetPort specified in the service definition1. If targetPort is not specified, it defaults to being the same as the port field1. In the provided YAML snippet, there is no targetPort specified for port 80, so we cannot confirm that the traffic will be routed to port 8080 in the pod. Therefore, without additional information about the pod configuration, we cannot verify the provided solution statement1.

Docker allows the use of insecure registries through a specific configuration in the Docker daemon. By listing the insecure registries in the 'daemon.json' configuration file under the 'insecure-registries' key, Docker can interact with these registries even without a trusted TLS certificate1. This is particularly useful when setting up a private Docker registry1. However, it's important to note that this configuration bypasses the security provided by TLS, and should be used with caution1.