AZURE OPENSHIFT DNSConfig 和 Ingress/Egress NetworkPolicy?

AZURE OPENSHIFT DNSConfig and Ingress/Egress NetworkPolicy?

伙计们,我是 openshift 的新手,我部署了一个 Azure Redhat Openshift 集群,并且可以管理员身份访问 Web 控制台。

我已经通过直接提供 github url 使用内置 S2I 模式在 Openshift 集群中部署了一个示例应用程序,并且该应用程序已成功部署。

现在我的要求是实施 DNSConfig 和 Ingress/Egress NetworkPolicy。

我是新手,无法理解 DNSConfig 和 Ingress/Egress NetworkPolicy 到底是什么。

有人可以向我解释一下那些是什么以及我们如何将它们实施到部署在该 Azure openshift 控制台中的演示应用程序中。

请帮忙。

提前致谢。

最好的办法是熟悉官方文档。

Pod's DNS Config:

Pod's DNS Config allows users more control on the DNS settings for a Pod.

The dnsConfig field is optional and it can work with any dnsPolicy settings. However, when a Pod's dnsPolicy is set to "None", the dnsConfig field has to be specified.

Below are the properties a user can specify in the dnsConfig field:

  • nameservers: a list of IP addresses that will be used as DNS servers for the Pod. There can be at most 3 IP addresses specified. When the Pod's dnsPolicy is set to "None", the list must contain at least one IP address, otherwise this property is optional. The servers listed will be combined to the base nameservers generated from the specified DNS policy with duplicate addresses removed.

  • searches: a list of DNS search domains for hostname lookup in the Pod. This property is optional. When specified, the provided list will be merged into the base search domain names generated from the chosen DNS policy. Duplicate domain names are removed. Kubernetes allows for at most 6 search domains.

  • options: an optional list of objects where each object may have a name property (required) and a value property (optional). The contents in this property will be merged to the options generated from the specified DNS policy. Duplicate entries are removed.

Network Policies:

If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster. NetworkPolicies are an application-centric construct which allow you to specify how a pod is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network.

The entities that a Pod can communicate with are identified through a combination of the following 3 identifiers:

  1. Other pods that are allowed (exception: a pod cannot block access to itself)

  2. Namespaces that are allowed

  3. IP blocks (exception: traffic to and from the node where a Pod is running is always allowed, regardless of the IP address of the Pod or the node)

When defining a pod- or namespace- based NetworkPolicy, you use a selector to specify what traffic is allowed to and from the Pod(s) that match the selector.

Meanwhile, when IP based NetworkPolicies are created, we define policies based on IP blocks (CIDR ranges).

这些主题在链接文档中有更详细的解释。您还可以找到一些示例来帮助您在用例中实施它。