20、OpenShift网络管理全解析

最新推荐文章于 2025-12-03 09:32:21 发布

embedding5hiker

最新推荐文章于 2025-12-03 09:32:21 发布

阅读量6

点赞数

CC 4.0 BY-SA版权

分类专栏： OpenShift实战入门精要文章标签： OpenShift SDN插件 ovs-networkpolicy

本文链接：https://blog.youkuaiyun.com/embedding5hiker/article/details/155718946

OpenShift实战入门精要专栏收录该内容

28 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

OpenShift网络管理全解析

1. OpenShift SDN插件之ovs-networkpolicy

在OpenShift中，网络管理至关重要。之前的ovs - multitenant插件虽然能管理项目间的访问，但在更细粒度的访问控制上有所欠缺。而ovs - networkpolicy插件则能创建自定义的NetworkPolicy对象，对入站或出站流量进行限制。

1.1 迁移前准备

要从ovs - multitenant插件迁移到ovs - networkpolicy插件，需要隔离普通项目，并允许全局项目的流量。全局项目的NETID为0，可通过以下命令查看：

[root@openshift - master book]# oc get netnamespaces
NAME                NETID      EGRESS IPS
default             0          []
demo - 1            9793016    []
demo - 2            0          []
kube - public       10554334   []
kube - system       8648643    []
logging             11035285   []
management - infra  4781458    []
openshift           13291653   []
openshift - infra   12251614   []
openshift - node    38906      []

在这个例子中，只有default和demo - 2是全局项目。

1.2 脚本操作

为了简化操作，有一个辅助脚本可以创建必要的NetworkPolicy对象。操作步骤如下：
1. 下载脚本并使其可执行：

# curl -O https://raw.githubusercontent.com/openshift/origin/master/contrib/migration/migrate - network - policy.sh
# chmod +x migrate - network - policy.sh

运行脚本：

# ./migrate - network - policy.sh

运行结果示例：

NAMESPACE: default
Namespace is global: adding label legacy - netid = 0
NAMESPACE: demo - 1
networkpolicy "default - deny" created
networkpolicy "allow - from - self" created
networkpolicy "allow - from - global - namespaces" created
NAMESPACE: demo - 2
Namespace is global: adding label legacy - netid = 0

全局项目会被分配 pod.network.openshift.io/legacy - netid = 0 标签，可通过以下命令查看 allow - from - global - namespaces 网络策略的定义：

# oc export networkpolicy/allow - from - global - namespaces
apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
  creationTimestamp: null
  generation: 1
  name: allow - from - global - namespaces
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          pod.network.openshift.io/legacy - netid: "0"
  podSelector: {}
  policyTypes:
  - Ingress

1.3 后续操作

完成上述操作后，将 networkPluginName 设置为 redhat/openshift - ovs - networkpolicy ，其余步骤与之前启用OpenShift插件的步骤相同。之后可以进行网络连通性测试：
1. 查看项目和Pod的IP地址：

# oc project
Using project "demo - 1" on server "https://openshift - master.example.com:8443".
# oc describe po/httpd | grep IP:
IP: 10.129.0.26
# oc project demo - 2
# oc describe po/httpd | grep IP:
IP: 10.129.0.27

进行ping测试：

# oc rsh httpd ping 10.129.0.26
# oc rsh httpd ping 10.129.0.27

1.4 自定义网络策略

创建新的项目demo - 3，测试网络策略限制：

# oc new - project demo - 3
# oc create - f httpd - pod.yml
# oc describe po/httpd | grep IP:
IP: 10.129.0.28
# oc rsh httpd ping 10.129.0.26

由于demo - 3是普通项目，会受到网络策略限制。可以通过以下步骤允许demo - 3访问demo - 1：
1. 给demo - 3项目打标签：

# oc project demo - 1
# oc label namespace demo - 3 name = demo - 3

创建网络策略：

# cat networkpolicy - demo - 3.yml
kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: networkpolicy - demo - 3
spec:
  podSelector:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: demo - 3
# oc create - f networkpolicy - demo - 3.yml

再次测试访问：

# oc project demo - 3
# oc rsh httpd ping 10.129.0.26

1.5 默认网络策略配置

OpenShift可以为每个项目创建默认网络策略，操作步骤如下：
1. 创建项目模板：

# oc adm create - bootstrap - project - template - o yaml > demo - project - request.yml

修改模板以包含阻止所有入站流量的网络策略：

# cat demo - project - request.yml
apiVersion: v1
kind: Template
metadata:
  creationTimestamp: null
  name: demo - project - request
objects:
...
- apiVersion: extensions/v1beta1
  kind: NetworkPolicy
  metadata:
    name: default - deny
  spec:
    ingress:
...

创建模板：

# oc create - f demo - project - request.yml

配置OpenShift使用新模板：

# cat /etc/origin/master/master - config.yaml
projectConfig:
  defaultNodeSelector: node - role.kubernetes.io/compute = true
  projectRequestMessage: ''
  projectRequestTemplate: demo - 3/demo - project - request

重启主API服务：

# systemctl restart origin - master - api

创建新项目并测试网络策略：

# oc new - project demo - 4
# oc get networkpolicy

创建一个运行Apache的Pod并测试访问：

# cat httpd - pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: httpd
  labels:
    role: web
spec:
  containers:
  - name: httpd
    image: manageiq/httpd
    resources:
      requests:
        cpu: 400m
        memory: 128Mi
# oc create - f httpd - pod.yml
# oc describe po/httpd | grep IP:
IP: 10.129.0.29
# oc project demo - 3
# oc rsh httpd ping 10.129.0.29

2. Egress路由器

OpenShift中的路由器通常将外部客户端流量引入服务，再转发到Pod。而Egress路由器则相反，它将Pod的出站流量转发到外部网络的特定目的地。与基于HAProxy的入站路由器不同，Egress路由器基于Squid构建。

2.1 应用场景

资源屏蔽 ：多个应用使用不同的外部资源，运维团队可设置Egress路由器将流量重定向到同一资源。
流量审计 ：将特定网站的可疑请求重定向到审计系统进行分析。

2.2 类型

redirect ：将流量重定向到特定的目标IP。
http - proxy ：代理HTTP、HTTPS和DNS流量。

由于VirtualBox中macvlan接口的限制，无法在虚拟实验室或AWS中设置Egress路由器，最佳使用平台是裸金属。

3. 外部项目流量的静态IP

OpenShift调度器在决定Pod的放置时，会考虑Pod的均匀分布、节点亲和性和可用资源等因素。但它不考虑项目，这在大型组织中可能会导致问题。例如，处理银行账户信息的应用和其开发版本可能会在同一节点上，产生相同源IP的流量，使得企业防火墙难以区分和应用策略。

OpenShift的解决方案是为特定项目分配外部可路由的IP地址，并在企业防火墙上进行白名单设置，同时让调度对开发者透明。不过，由于VirtualBox的虚拟环境限制，难以演示此功能。

4. Egress网络策略

网络策略用于控制项目间Pod的访问，而Egress网络策略则可限制项目中所有Pod对特定外部资源的访问。例如，阻止Pod访问代码托管提供商和内容镜像，防止应用或系统库更新。与Egress路由器不同，Egress网络策略仅基于允许或拒绝进行控制，不进行流量重定向。

4.1 测试初始访问

# oc project demo - 1
# oc rsh httpd ping github.com
# oc rsh httpd ping google.com

此时没有应用Egress网络策略，对外部资源的访问不受限制。

4.2 创建自定义Egress网络策略

# cat demo - egress - policy.yml
kind: EgressNetworkPolicy
apiVersion: v1
metadata:
  name: demo - egress - policy
spec:
  egress:
  - type: Deny
    to:
      dnsName: github.com
# oc create - f demo - egress - policy.yml

再次测试访问：

# oc rsh httpd ping github.com
# oc rsh httpd ping google.com

可以看到GitHub无法访问。

4.3 修改策略

# oc edit egressnetworkpolicy/demo - egress - policy
spec:
  egress:
  - to:
      dnsName: github.com
    type: Allow
  - to:
      cidrSelector: 0.0.0.0/0
    type: Deny

再次测试：

# oc rsh httpd - egress ping github.com
# oc rsh httpd - egress ping google.com

策略按预期工作。需要注意的是，Egress规则按指定顺序评估，第一个匹配的规则生效。

5. DNS

在OpenShift中，之前通过环境变量连接Pod，但在动态环境中，这种方式有局限性。OpenShift提供了基于SkyDNS和dnsmasq的内部DNS进行服务发现。

5.1 DNS可发现资源

资源类型	域名
服务	`<service>.<project>.svc.cluster.local`
端点	`<service>.<project>.endpoints.cluster.local`

5.2 示例操作

创建项目和Pod：

# oc new - project demo - 1
# oc create - f httpd - pod.yml
# oc expose po/httpd --port 80
# oc new - project demo - 2
# oc create - f httpd - pod.yml
# oc expose po/httpd --port 80

测试访问：

# oc exec httpd - it bash
bash - 4.2$ dig httpd.demo - 1.svc.cluster.local
# oc project demo - 1
# oc exec httpd - it bash
bash - 4.2$ dig httpd.demo - 2.svc.cluster.local

还可以获取端点信息：

$ dig httpd.demo - 2.endpoints.cluster.local

OpenShift会将集群级子域名注入 /etc/resolv.conf ，因此可以使用更简短的名称访问资源。

5.3 DNS架构和查询流程

在主节点上查看监听端口：

# ss - tulpn | grep '53 '
udp UNCONN 0 0 *:8053 *:* users:(("openshift",pid = 1492,fd = 10))
tcp LISTEN 0 128 *:8053 *:* users:(("openshift",pid = 1492,fd = 13))

在节点上查看：

# ss - tulpn | grep '53 '
udp UNCONN 0 0 172.24.0.12:53 *:* users:(("dnsmasq",pid = 1202,fd = 4))
udp UNCONN 0 0 127.0.0.1:53 *:* users:(("openshift",pid = 2402,fd = 26))
udp UNCONN...

查看相关配置文件：

# oc exec httpd - it bash
bash - 4.2$ cat /etc/resolv.conf
nameserver 10.0.2.15
search demo - 1.svc.cluster.local svc.cluster.local cluster.local example.com
options ndots:5
# cat /etc/dnsmasq.d/node - dnsmasq.conf
server=/in - addr.arpa/127.0.0.1
server=/cluster.local/127.0.0.1
# cat /etc/dnsmasq.d/origin - upstream - dns.conf
server=10.0.2.2

mermaid格式流程图：

graph LR
    A[Pod] -->|DNS查询| B(dnsmasq)
    B -->|cluster.local/in - addr.arpa| C(SkyDNS)
    B -->|其他| D(上游DNS)

通过以上内容，我们详细了解了OpenShift网络管理的多个方面，包括SDN插件、Egress路由器、静态IP、Egress网络策略和DNS等，这些功能为OpenShift的网络管理提供了强大的支持。

OpenShift网络管理全解析

6. 网络管理综合应用案例

为了更好地理解OpenShift网络管理的实际应用，我们来看一个综合案例。假设我们有一个包含多个微服务的应用，分布在不同的项目中，需要对其进行网络管理以确保安全性和可用性。

6.1 项目和服务创建

首先，我们创建三个项目： app - frontend 、 app - backend 和 app - database ，并在每个项目中创建相应的服务和Pod。

# 创建前端项目
oc new - project app - frontend
oc create - f frontend - pod.yml
oc expose po/frontend --port 80

# 创建后端项目
oc new - project app - backend
oc create - f backend - pod.yml
oc expose po/backend --port 8080

# 创建数据库项目
oc new - project app - database
oc create - f database - pod.yml
oc expose po/database --port 3306

6.2 网络策略配置

为了确保安全性，我们需要配置网络策略。例如，只允许前端项目访问后端项目，后端项目访问数据库项目。

# 前端项目允许访问后端项目
cat <<EOF | oc create - f -
kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: allow - frontend - to - backend
  namespace: app - frontend
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app - backend
EOF

# 后端项目允许访问数据库项目
cat <<EOF | oc create - f -
kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: allow - backend - to - database
  namespace: app - backend
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app - database
EOF

6.3 Egress网络策略配置

假设我们要限制后端项目只能访问特定的外部API，我们可以配置Egress网络策略。

# 后端项目只允许访问特定API
cat <<EOF | oc create - f -
kind: EgressNetworkPolicy
apiVersion: v1
metadata:
  name: restrict - backend - egress
  namespace: app - backend
spec:
  egress:
  - type: Allow
    to:
      dnsName: api.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
EOF

6.4 DNS验证

我们可以验证各个服务之间是否可以通过DNS进行访问。

# 前端项目访问后端服务
oc project app - frontend
oc exec frontend - it bash
bash - 4.2$ curl backend.app - backend.svc.cluster.local:8080

# 后端项目访问数据库服务
oc project app - backend
oc exec backend - it bash
bash - 4.2$ mysql - h database.app - database.svc.cluster.local - P 3306

7. 网络管理的最佳实践

在OpenShift网络管理中，遵循一些最佳实践可以提高网络的安全性和性能。

7.1 最小权限原则

在配置网络策略时，应遵循最小权限原则。只允许必要的流量通过，限制不必要的访问。例如，在上述案例中，只允许前端访问后端，后端访问数据库，避免了其他不必要的流量。

7.2 定期审查和更新策略

随着应用的发展和变化，网络策略也需要定期审查和更新。例如，当有新的服务加入或旧的服务移除时，需要相应地调整网络策略。

7.3 监控和日志记录

使用监控工具和日志记录来实时监测网络流量和策略执行情况。例如，可以使用Prometheus和Grafana来监控网络流量，使用ELK Stack来记录和分析网络日志。

8. 常见问题及解决方法

在OpenShift网络管理过程中，可能会遇到一些常见问题，以下是一些解决方法。

问题描述	可能原因	解决方法
Pod之间无法通信	网络策略配置错误、DNS解析问题	检查网络策略配置，确保允许相应的流量；检查DNS配置，确保服务可以正确解析
Egress网络策略不生效	策略语法错误、网络插件问题	检查Egress网络策略的语法，确保正确配置；检查网络插件是否正常工作
服务无法通过DNS访问	DNS服务故障、配置错误	检查DNS服务的运行状态，确保其正常工作；检查 `/etc/resolv.conf` 和相关配置文件，确保配置正确

9. 未来发展趋势

随着云计算和容器技术的不断发展，OpenShift网络管理也将不断演进。

9.1 更智能的网络策略

未来的网络策略可能会更加智能，能够根据应用的行为和环境自动调整。例如，根据流量模式自动调整访问控制策略。

9.2 集成更多网络安全技术

OpenShift可能会集成更多的网络安全技术，如零信任架构、软件定义广域网（SD - WAN）等，以提供更高级别的网络安全保护。

9.3 更好的跨集群网络支持

随着企业采用多集群架构，OpenShift将提供更好的跨集群网络支持，确保不同集群之间的应用可以无缝通信。

10. 总结

OpenShift网络管理是一个复杂而重要的领域，涵盖了SDN插件、Egress路由器、静态IP、Egress网络策略和DNS等多个方面。通过合理配置和管理这些网络功能，可以提高应用的安全性、可用性和性能。在实际应用中，我们需要根据具体需求选择合适的网络管理方法，并遵循最佳实践来确保网络的稳定运行。同时，关注未来的发展趋势，不断学习和应用新的技术，以适应不断变化的云计算环境。

mermaid格式流程图：

graph LR
    A[创建项目和服务] --> B[配置网络策略]
    B --> C[配置Egress网络策略]
    C --> D[验证DNS访问]
    D --> E[遵循最佳实践]
    E --> F[解决常见问题]
    F --> G[关注未来趋势]

通过以上内容，我们对OpenShift网络管理有了更深入的理解，并且了解了如何在实际应用中进行网络管理和优化。希望这些信息对大家在OpenShift网络管理方面有所帮助。