003.OpenShift网络

目录

一 OpenShift网络实现
    1.1 软件定义网络(SDN)
    1.2 Kubernetes SDN Pod
    1.3 Kubernetes SDN Service
    1.4 service对外暴露
    1.5 pod访问外部网络
二 OpenShift SDN练习
    2.1 前置准备
    2.2 本练习准备
    2.3 创建应用
    2.4 扩展应用
    2.5 测试访问
    2.6 检查服务
    2.7 检查pod
    2.8 设置外部访问
    2.9 验证外部访问
    2.10 使用pod shell
三 OpenShift router
    3.1 OpenShift route概述
    3.2 创建route
    3.3 查找默认subdomain
    3.4 routing类型和选项
    3.5 通配符子域
    3.6 管理route
四 创建Route练习
    4.1 前置准备
    4.2 本练习准备
    4.3 创建应用
    4.4 创建TLS证书
    4.5 创建route
    4.6 确认验证
    4.7 测试访问
    4.8 非安全形式访问
五 OpenShift网络综合实验
    5.1 前置准备
    5.2 本练习准备
    5.3 验证所需资源
    5.4 测试访问
    5.5 TS cluster故障
    5.6 测试访问
    5.7 TS route故障
    5.8 确认验证

回到顶部
一 OpenShift网络实现
1.1 软件定义网络(SDN)
默认情况下，Docker网络使用仅使用主机虚机网桥bridge，主机内的所有容器都连接至该网桥。连接到此桥的所有容器都可以彼此通信，但不能与不同主机上的容器通信。通常，这种通信使用端口映射来处理，其中容器端口绑定到主机上的端口，所有通信都通过物理主机上的端口路由。
当有大量主机和容器时，使用此模式，需要手动管理所有端口绑定非常不现实。
为了支持跨集群的容器之间的通信，OpenShift容器平台使用了软件定义的网络(SDN)方法。软件定义的网络是一种网络模型，它通过几个网络层的抽象来管理网络服务。SDN将处理流量的软件(称为控制平面)和路由流量的底层机制(称为数据平面)解耦。SDN支持控制平面和数据平面之间的通信。
在OpenShift Container Platform 3.9中（之后简称OCP），管理员可以为pod网络配置三个SDN插件:

ovs-subnet：默认插件，子网提供了一个flat pod网络，其中每个pod可以与其他pod和service通信。
ovs-multitenant：该为pod和服务提供了额外的隔离层。当使用此插件时，每个project接收一个惟一的虚拟网络ID (VNID)，该ID标识来自属于该project的pod的流量。通过使用VNID，来自不同project的pod不能与其他project的pod和service通信。
ovs-networkpolicy：此插件允许管理员使用NetworkPolicy对象定义自己的隔离策略。

cluster network由OpenShift SDN建立和维护，它使用Open vSwitch创建overlay网络，master节点不能通过集群网络访问容器，除非master同时也为node节点。
注意：VNID为0的project可以与所有其他pod通信，在OpenShift容器平台中，默认项目的VNID为0。
1.2 Kubernetes SDN Pod
kubernetes basic networking_v1
在默认的OpenShift容器平台安装中，每个pod都有一个惟一的IP地址。pod中的所有容器都对外表现在相同的主机上。给每个pod提供自己的IP地址意味着，在端口分配、网络、DNS、负载平衡、应用程序配置和迁移方面，pod被视为物理主机或虚拟机的独立节点（仅从网络层面看待）。
Kubernetes提供了service的概念，在任何OpenShift应用程序中，service都是必不可少的资源。service充当一个或多个pod前的负载平衡器。该service提供一个固定的IP地址，并且允许与pod通信，而不必跟踪单独的pod IP地址。
kubernetes services networking_v1
大多数实际应用程序都不是作为单个pod运行的。它们需要水平伸缩，这样应用程序就可以在许多pod上运行，以满足不断增长的用户需求。在OpenShift集群中，pod不断地在集群中的节点之间创建和销毁。每次创建pod时，它们都会获得一个不同的IP地址。一个service提供一个单独的、惟一的IP地址供其他pod使用，而不依赖于pod运行的节点，因此一个pod不必一定需要发现另一个pod的IP地址。客户端通过service的请求在不同pod之间实现负载均衡。
1.3 Kubernetes SDN Service
service背后运行的一组pod由OpenShift容器平台自动管理。每个service都被分配了一个唯一的IP地址供客户端连接。这个IP地址也来自OpenShift SDN，它与pod的内部网络不同，也只在集群中可见。每个与selector匹配的pod都作为endpoint添加到service资源中。当创建和销毁pods时，service后面的endpoint将自动更新。
service yaml语法：
复制代码

1 - apiVersion: v1
2 kind: Service #声明资源类型
3 metadata:
4 labels:
5 app: hello-openshift
6 name: hello-openshift #服务的唯一名称
7 spec:
8 ports:，
9 - name: 8080-tcp
10 port: 8080 #服务对外公开的端口客户机连接到服务端口
11 protocol: TCP
12 targetPort: 8080 #targetPort属性必须匹配pod容器定义中的containerPort，服务将数据包转发到pod中定义的目标端口。
13 selector: #该服务使用selector属性查找要转发数据包的pod。目标pod的元数据中需要有匹配的标签。如果服务发现多个具有匹配标签的pod，它将在它们之间实现负载
14 app: hello-openshift
15 deploymentconfig: hello-openshift

复制代码
1.4 service对外暴露
默认情况下，pod和service IP地址不能从OpenShift集群外部访问。对于需要从OpenShift集群外部访问服务的应用程序，可以通过以下三种方式。
HostPort/HostNetwork：在这种方法中，client可以通过主机上的网络端口直接访问集群中的应用程序pod。应用程序pod中的端口被绑定到运行该pod的主机上的端口。这种方法在集群中运行大量pod时，存在端口冲突的风险。
NodePort：这是一种较老的基于Kubernetes的方法，通过绑定到node主机上的可用端口，将service公开给外部客户端，然后node主机代理到service IP地址的连接。使用oc edit svc命令编辑服务属性，指定NodePort的类型，并为NodePort属性提供端口值。OpenShift然后通过node主机的公共IP地址和nodePort中设置的端口值代理到服务的连接。这种方法支持非http通信。
OpenShift routes：OpenShift中的推荐方式。它使用唯一的URL公开服务。使用oc expose命令公开用于外部访问的服务，或者从OpenShift web控制台公开服务。在这种方法中，目前只支持HTTP、HTTPS、TLS whit SNI和WebSockets。
附图：显示了NodePort服务如何允许外部访问Kubernetes服务。
kubernetes nodeport services_v1
service nodeport yaml语法：
复制代码

1 apiVersion: v1
2 kind: Service
3 metadata:
4 …
5 spec:
6 ports:
7 - name: 3306-tcp
8 port: 3306
9 protocol: TCP
10 targetPort: 3306 #pod目标端口，即需要和pod定义的端口匹配