架构

所有与 REST API 的通信频道以及 etcd 和 API 服务器等 master 组件 之间都使用 TLS 保护。TLS 提供具有 X.509 服务器证书和公钥基础架构的强大加密、数据完整性和验证服务器。默认情况下，会为每个 OpenShift Container Platform 部署创建一个新的内部 PKI。内部 PKI 使用 2048 位 RSA 密钥和 SHA-256 签名。也支持公共主机的 自定义证书。

OpenShift Container Platform 使用 Golang 的 crypto/tls 的标准库实现，且不依赖于任何外部加密和 TLS 库。另外，客户端依赖于用于 GSSAPI 验证和 OpenPGP 签名的外部库。GSSAPI 通常由 MIT Kerberos 或 Heimdal Kerberos 提供，它们都使用 OpenSSL 的 libcrypto。OpenPGP 签名验证由 libgpgme 和 GnuPG 处理。

不安全的版本 SSL 2.0 和 SSL 3.0 不受支持，且不可用。OpenShift Container Platform 服务器和 oc 客户端默认只提供 TLS 1.2。TLS 1.0 和 TLS 1.1 可以在服务器配置中启用。服务器和客户端都首选使用经过身份验证的加密算法和完美转发保密性实现现代加密套件。禁用使用已弃用和不安全的算法（如 RC4、3DES 和 MD5）的密码套件。有些内部客户端（例如，LDAP 身份验证）限制了启用了 1.2 和更多密码套件的 TLS 1.0 的设置。

以下列出的 OpenShift Container Platform 服务器和 oc 客户端的启用密码套件按首选顺序排序：

在 OpenShift Container Platform 中，Kubernetes 在一组容器或主机间管理容器化应用，并提供部署、维护和应用程序的扩展机制。容器运行时软件包、实例化和运行容器化应用。Kubernetes 集群由一个或多个 master 和一组节点组成。

您可以选择将 master 配置为高可用性 (HA)，以确保集群没有单点故障。

master 是包含 control plane 组件的主机或主机，包括 API 服务器、控制器管理器服务器和 etcd。master 用于管理其 Kubernetes 集群中的节点，并调度 pod 以便在这些节点上运行。

2.1.2.1. Control Plane 静态 Pod

核心 control plane 组件、API 服务器和控制器管理器组件，作为 kubelet 操作 的静态 pod 运行。

对于在同一主机上还存在 etcd 的 master，etcd 也会变为静态 pod。在不是 master 的 etcd 主机上仍然支持基于 RPM 的 etcd。

另外，节点组件 openshift-sdn 和 openvswitch 现在可以使用 DaemonSet 而不是 systemd 服务运行。

图 2.1. control plane 主机架构更改

即使作为静态 pod 运行 control plane 组件，master 主机仍然会从 /etc/origin/master/master-config.yaml 文件中提供其配置，如 Master 和 Node Configuration 所述。

启动序列概述

Hyperkube 是一个包含所有 Kubernetes 的二进制文件（kube-apiserver, controller-manager, scheduler, proxy, 和 kubelet）。在启动时，kubelet 创建 kubepods.slice。接下来，kubelet 在 kubepods.slice 中创建 QoS 级别片段 burstable.slice 和 best-effort.slice。当 pod 启动时，kubelet 使用格式为 pod< UUID-of-pod>.slice 的 pod 级别片段，并将该路径传递给容器运行时接口(CRI)的另一端的运行时。然后，Docker 或 CRI-O 会在 pod 级别片段中创建容器级别的片段。

镜像 Pod

master 节点上的 kubelet 会自动在 API 服务器上为每个 control plane 静态 pod 创建镜像 pod，以便 kube-system 项目中的集群可见。默认情况下，openshift-ansible 安装程序会安装这些静态 pod 的清单，位于 master 主机上的 /etc/origin/node/pods 目录中。

这些 pod 定义了以下 hostPath 卷：

/etc/origin/master	包含所有证书、配置文件和 admin.kubeconfig 文件。
/var/lib/origin	包含二进制文件的卷和潜在的内核转储。
/etc/origin/cloudprovider	包含特定于云供应商的配置（AWS、Azure 等）。
/usr/libexec/kubernetes/kubelet-plugins	包含其他第三方卷插件。
/etc/origin/kubelet-plugins	包含系统容器的其他第三方卷插件。

您可以在静态 pod 上执行的操作集合有限。例如：

$ oc logs master-api-<hostname> -n kube-system

返回 API 服务器的标准输出。然而：

$ oc delete pod master-api-<hostname> -n kube-system

不会实际删除 pod。

再如，集群管理员可能需要执行一个常见操作，如增加 API 服务器的日志级别，以便在出现问题时提供更详细的数据。您必须编辑 /etc/origin/master/master.env 文件，其中 OPTIONS 变量中的 --loglevel 参数可以被修改，因为此值被传递给容器中运行的进程。更改需要重启容器中运行的进程。

重启主服务

要重启在 control plane 静态 pod 中运行的 control plane 服务，请在 master 主机上使用 master-restart 命令。

重启 master API：

# master-restart api

重启控制器：

# master-restart controllers

重启 etcd：

# master-restart etcd

查看主服务日志

要查看在 control plane 静态 pod 中运行的 control plane 服务的日志，请为对应的组件使用 master-logs 命令：

# master-logs api api

# master-logs controllers controllers

# master-logs etcd etcd

节点为容器提供运行时环境。Kubernetes 群集中的每个节点都需要由主控机管理的服务。节点也具有运行 pod 所需的服务，包括容器运行时、kubelet 和服务代理。

OpenShift Container Platform 从云供应商、物理系统或虚拟系统创建节点。Kubernetes 与代表这些节点的节点对象进行交互。主控机（master）使用来自节点对象的信息执行健康检查，以此验证节点。在通过健康检查前，节点会被忽略，master 会继续检查节点，直到节点有效。Kubernetes 文档包含有关节点状态和管理的更多信息。

管理员可以使用 CLI 在 OpenShift Container Platform 实例中管理节点。要在启动节点服务器时定义完整的配置和安全选项，请使用 专用节点配置文件。

apiVersion: v1 1
kind: Node 2
metadata:
  creationTimestamp: null
  labels: 3
    kubernetes.io/hostname: node1.example.com
  name: node1.example.com 4
spec:
  externalID: node1.example.com 5
status:
  nodeInfo:
    bootID: ""
    containerRuntimeVersion: ""
    kernelVersion: ""
    kubeProxyVersion: ""
    kubeletVersion: ""
    machineID: ""
    osImage: ""
    systemUUID: ""

2.1.3.4. 节点引导

节点的配置从 master 启动，这意味着节点会从 master 拉取其预定义配置和服务器证书。这可通过减少节点之间的区别以及集中更多配置并让集群在所需状态进行聚合，从而加快节点启动速度。证书轮转和集中式证书管理会被默认启用。

图 2.2. 节点 bootstrap 工作流概述

当节点服务启动时，节点会在加入集群前检查 /etc/origin/node/node.kubeconfig 文件和其他节点配置文件是否存在。如果不存在，节点将从 master 中拉取配置，然后加入集群。

ConfigMap 用于在集群中存储节点配置，这会在节点主机上的 /etc/origin/node/node-config.yaml 填充配置文件。有关默认节点组及其 ConfigMap 集合的定义，请参阅在安装集群中定义节点组和主机映射。

节点 Bootstrap 工作流

自动节点 bootstrap 过程使用以下工作流：

1. 默认情况下，会在集群安装过程中创建一组 clusterrole、clusterrolebinding 和 serviceaccount 对象以用于节点引导：

   • system:node-bootstrapper 集群角色用于在节点引导期间创建证书签名请求(CSR)：

     $ oc describe clusterrole.authorization.openshift.io/system:node-bootstrapper

     输出示例

     Name:			system:node-bootstrapper
     Created:		17 hours ago
     Labels:			kubernetes.io/bootstrapping=rbac-defaults
     Annotations:		authorization.openshift.io/system-only=true
     			openshift.io/reconcile-protect=false
     Verbs			Non-Resource URLs	Resource Names	API Groups		Resources
     [create get list watch]	[]			[]		[certificates.k8s.io]	[certificatesigningrequests]

   • 以下 node-bootstrapper 服务帐户是在 openshift-infra 项目中创建的：

     $ oc describe sa node-bootstrapper -n openshift-infra

     输出示例

     Name:                node-bootstrapper
     Namespace:           openshift-infra
     Labels:              <none>
     Annotations:         <none>
     Image pull secrets:  node-bootstrapper-dockercfg-f2n8r
     Mountable secrets:   node-bootstrapper-token-79htp
                          node-bootstrapper-dockercfg-f2n8r
     Tokens:              node-bootstrapper-token-79htp
                          node-bootstrapper-token-mqn2q
     Events:              <none>

   • 以下 system:node-bootstrapper 集群角色绑定用于节点 bootstrapper 集群角色和服务帐户：

     $ oc describe clusterrolebindings system:node-bootstrapper

     输出示例

     Name:			system:node-bootstrapper
     Created:		17 hours ago
     Labels:			<none>
     Annotations:		openshift.io/reconcile-protect=false
     Role:			/system:node-bootstrapper
     Users:			<none>
     Groups:			<none>
     ServiceAccounts:	openshift-infra/node-bootstrapper
     Subjects:		<none>
     Verbs			Non-Resource URLs	Resource Names	API Groups		Resources
     [create get list watch]	[]			[]		[certificates.k8s.io]	[certificatesigningrequests]

2. 另外，在集群安装过程中，openshift-ansible 安装程序会在 /etc/origin/master 目录中创建 OpenShift Container Platform 证书颁发机构和各种其他证书、密钥和 kubeconfig 文件。注意的两个文件有：

   /etc/origin/master/admin.kubeconfig	使用 system:admin 用户。
   /etc/origin/master/bootstrap.kubeconfig	用于不是 master 节点的 bootstrap 节点。

   1. 在安装程序使用 node-bootstrapper 服务帐户时，会创建 /etc/origin/master/bootstrap.kubeconfig，如下所示：

      $ oc --config=/etc/origin/master/admin.kubeconfig \
          serviceaccounts create-kubeconfig node-bootstrapper \
          -n openshift-infra

   2. 在 master 节点上，/etc/origin/master/admin.kubeconfig 用作引导文件，并复制到 /etc/origin/node/boostrap.kubeconfig。在另外一个非 master 节点上，/etc/origin/master/bootstrap.kubeconfig 文件会复制到每个节点主机上的 /etc/origin/node/boostrap.kubeconfig 的所有其他节点上。

   3. 然后，使用 --bootstrap-kubeconfig 标记将 /etc/origin/master/bootstrap.kubeconfig 传递给 kubelet，如下所示：

      --bootstrap-kubeconfig=/etc/origin/node/bootstrap.kubeconfig

3. kubelet 首先使用提供的 /etc/origin/node/bootstrap.kubeconfig 文件启动。在初始内部连接后，kubelet 创建证书签名请求(CSR)并将其发送到 master。

4. CSR 通过控制器管理器（特别是证书签名请求）进行验证和批准。如果批准，kubelet 客户端和服务器证书会在 /etc/origin/node/ceritificates 目录中创建。例如：

   # ls -al /etc/origin/node/certificates/

   输出示例

   total 12
   drwxr-xr-x. 2 root root  212 Jun 18 21:56 .
   drwx------. 4 root root  213 Jun 19 15:18 ..
   -rw-------. 1 root root 2826 Jun 18 21:53 kubelet-client-2018-06-18-21-53-15.pem
   -rw-------. 1 root root 1167 Jun 18 21:53 kubelet-client-2018-06-18-21-53-45.pem
   lrwxrwxrwx. 1 root root   68 Jun 18 21:53 kubelet-client-current.pem -> /etc/origin/node/certificates/kubelet-client-2018-06-18-21-53-45.pem
   -rw-------. 1 root root 1447 Jun 18 21:56 kubelet-server-2018-06-18-21-56-52.pem
   lrwxrwxrwx. 1 root root   68 Jun 18 21:56 kubelet-server-current.pem -> /etc/origin/node/certificates/kubelet-server-2018-06-18-21-56-52.pem

5. 在 CSR 批准后，node.kubeconfig 文件会在 /etc/origin/node/node.kubeconfig 中创建。
6. kubelet 使用 /etc/origin/node/node.kubeconfig 文件以及 /etc/origin/node/certificates/ 目录中的证书重启，直到它准备好加入集群。

节点配置工作流

为节点配置提供使用以下工作流：

1. 最初，节点的 kubelet 是在节点置备时创建的 /etc/origin/node/ 目录中的 bootstrap-node-config.yaml 启动。
2. 在每个节点上，节点服务文件使用 /usr/local/bin/ 目录中的本地脚本 openshift-node 来通过提供的 bootstrap-node-config.yaml 启动 kubelet。
3. 在每个 master 上，目录 /etc/origin/node/pods 包含 apiserver 的 pod 清单，控制器和 etcd 在 master 上作为静态 pod 创建。

4. 在集群安装过程中，会创建一个同步 DaemonSet，在每个节点上创建一个同步 pod。sync（同步）pod 会监控文件 /etc/sysconfig/atomic-openshift-node 中的更改。它专门用于监视要设置的 BOOTSTRAP_CONFIG_NAME。BOOTSTRAP_CONFIG_NAME 由 openshift-ansible 安装程序设置，它是根据节点所属节点配置组的 ConfigMap 名称。

   默认情况下，安装程序会创建以下节点配置组：

   • node-config-master
   • node-config-infra
   • node-config-compute
   • node-config-all-in-one
   • node-config-master-infra

   在 openshift-node 项目中为每个组创建一个 ConfigMap。

5. 同步 pod 根据 BOOTSTRAP_CONFIG_NAME 中设置的值提取适当的 ConfigMap。
6. 同步 pod 将 ConfigMap 数据转换为 kubelet 配置，并为该节点主机创建一个 /etc/origin/node/node-config.yaml。如果对此文件进行了更改（或者是文件的初始创建），则 kubelet 会重启。

修改节点配置

通过编辑 openshift-node 项目中的相应 ConfigMap 来修改节点的配置。不要直接修改 /etc/origin/node/node-config.yaml。

例如，对于 node-config-compute 组中的节点，使用以下内容编辑 ConfigMap：

$ oc edit cm node-config-compute -n openshift-node

OpenShift Container Platform 可以使用实施容器镜像 registry API 的任何服务器作为镜像源，包括 Docker Hub、由第三方运行的私有 registry 和集成的 OpenShift Container Platform registry。

OpenShift Container Platform 提供了一个集成的容器镜像 registry，称为 OpenShift Container Registry (OCR)，它可按需自动置备新的镜像存储库。这为用户提供一个内置位置，供其应用构建用于推送生成的镜像。

每当一个新镜像推送到 OCR 时，registry 就会通知 OpenShift Container Platform，同时传递有关新镜像的所有信息，如命名空间、名称和镜像元数据。OpenShift Container Platform 的不同部分对新镜像做出反应，创建新的构建和部署。

OCR 也可以作为独立组件部署，它只作为容器镜像 registry，而无需构建和部署集成。详情请参阅安装独立 OpenShift Container Registry 部署的内容。

OpenShift Container Platform可以使用由第三方 registry 提供的镜像创建容器，但是这些registry 可能不会象OpenShift Container Platform中集成的registry一样提供相同的镜像通知支持。在这种情况下，OpenShift Container Platform将在创建镜像流时从远程 registry 中获取 tag。oc import-image <stream>就可以更新获取的 tag。当检测到新的镜像时，以前的构建和部署将会被重新创建。

Red Hat Quay 为您提供了一个企业级的容器镜像 registry。它可以作为一个托管的服务，也可以在您自己的数据中心或环境中安装它。Red Hat Quay中的高级 registry 功能包括跨区域复制、镜像扫描及镜像回滚（roll back）功能。

请通过 Quay.io 网站设置您自己的托管 Quay registry 帐户。之后，按照 Quay 教程登录到 Quay registry，并开始管理镜像。另外，请参阅 Red Hat Quay 入门，以了解有关设置您自己的 Red Hat Quay registry 的信息。

您可以象访问其他远程镜像 registry 一样，通过 OpenShift Container Platform 访问您的 Red Hat Quay registry。要了解如何设置将凭证作为安全 registry 访问 Red Hat Quay，请参阅 允许 Pod 从其他安全 registry 中引用镜像。

Red Hat Container Catalog （registry.access.redhat.com)是一个托管的镜像 registry，通过它可以获得所需的容器镜像。OpenShift Container Platform 3.11 Red Hat Container Catalog 从 registry.access.redhat.com 移到 registry.redhat.io。

新的 registry（Registry.redhat.io）需要进行身份验证才能访问OpenShift Container Platform上的镜像及内容。当迁移到新registry后，现有的registry仍将在一段时间内可用。

新registry使用标准的OAuth机制进行身份验证：

您可以在 docker login 中使用您的凭证（用户名和密码，或身份验证令牌）来访问新 registry 中的内容。

所有镜像流均指向新的registry。由于新 registry 需要进行身份验证才能访问，因此 OpenShift 命名空间中有一个名为 imagestreamsecret 的新机密。

您需要将凭据放在两个位置：

访问新 registry:

OpenShift Container Platform Web控制台是可从Web浏览器访问的用户界面。开发人员可以使用 Web 控制台来视觉化、浏览和管理 项目 的内容。

Web 控制台作为 pod 在 master 上运行。这个 pod 提供了运行Web控制台所需的静态环境。管理员也可以使用扩展 自定义 Web 控制台，您可以在 web控制台加载时运行脚本和加载自定义样式表。

当您从浏览器访问 Web 控制台时，它会首先加载所有所需的静态资产。然后，它使用 openshift start 选项 --public-master 或在 openshift-console-config 配置映射中定义的 webconsole-config 配置映射中的相关参数 masterPublicURL 向 OpenShift Container Platform API 发出请求。Web 控制台使用 WebSockets 来保持与 API 服务器的持久连接，并在可用后立即收到更新的信息。

图 2.3. Web 控制台请求架构

为 web 控制台配置的主机名和 IP 地址列入白名单，以便安全地访问 API 服务器，即使浏览器将请求视为 跨原始状态。要使用其他主机名从 web 应用程序访问 API 服务器，您必须通过将 --cors-allowed-origins 选项指定 openshift start 或从相关的 master 配置文件参数 corsAllowedOrigins 指定主机名来列入白名单。

corsAllowedOrigins 参数由配置字段控制。不会对值进行固定或转义。以下是如何获得主机名和转义点的示例：

corsAllowedOrigins:
- (?i)//my\.subdomain\.domain\.com(:|\z)

您可从 web 控制台中的 Help 图标访问 CLI 下载：

集群管理员可以 进一步自定义这些链接。

查看 OpenShift Container Platform 的已测试的集成。

登录后，Web 控制台为开发人员提供当前所选项目的概览 ：

图 2.4. Web 控制台项目概述

对于基于 Java 镜像的 pod，Web 控制台还会提供对基于 hawt.io的 JVM 控制台的访问，用于查看和管理所有相关集成组件。在 Browse → Pods 页面中的 pod 详情中会显示 Connect 链接，提供带有名为 jolokia 的端口的容器。

图 2.5. 带有到 JVM 控制台的链接的 Pod

连接 JVM 控制台后，会显示不同的页面，具体取决于哪些组件与连接的 pod 相关。

图 2.6. JVM 控制台

可用的页面如下：

StatefulSet 控制器为其 pod 提供唯一的身份，并确定部署和扩展顺序。StatefulSet 对于唯一标识符、持久性存储、安全部署和扩展以及安全删除和终止很有用。

图 2.7. OpenShift Container Platform 中的 StatefulSet

OpenShift Container Platform 应用程序的基本单元称为容器。Linux 容器技术是一种轻量型机制，用于隔离运行中的进程，使它们只能跟指定的资源交互。

许多应用程序实例可以在单一主机上的容器中运行，而且相互之间看不到对方的进程、文件和网络等。通常，每个容器都提供单一服务（通常称为“微服务”），如 Web 服务器或数据库，但容器可用于任意工作负载。

多年来，Linux 内核一直在整合容器技术的能力。当前，Docker 项目为主机上的 Linux 容器开发了便捷的管理接口。OpenShift Container Platform 和 Kubernetes 添加了在多主机安装间编配 Docker 格式的容器的功能。

虽然在使用 OpenShift Container Platform 时不直接与 Docker CLI 或服务交互，但了解它们的功能和术语对于了解它们在 OpenShift Container Platform 中的角色以及您的应用程序在容器内如何工作非常重要。docker RPM 作为 RHEL 7 的一部分 7 以及 CentOS 和 Fedora 提供，因此您可以与 OpenShift Container Platform 分开进行试验。有关指南，请参阅 Red Hat 系统上的 Docker 格式化容器镜像 入门部分。

OpenShift Container Platform 中的容器基于 Docker 格式的容器镜像。镜像是一种二进制文件，包含运行单一容器的所有要求以及描述其需求和功能的元数据。

您可以将其视为一种打包技术。容器只能访问其镜像中定义的资源，除非创建时授予容器其他访问权限。通过将同一镜像部署到跨越多个主机的多个容器内，并在它们之间进行负载平衡，OpenShift 容器平台可以为镜像中打包的服务提供冗余和横向扩展。

您可以直接使用 Docker CLI 构建镜像，但 OpenShift Container Platform 还提供构建器镜像，通过向现有镜像添加代码或配置来协助创建新的镜像。

由于应用程序会随时间推移开发，因此单个镜像名称实际上可以指代许多不同版本的"same"镜像。每个不同的镜像都由它的唯一哈希值引用（一个较长的十六进制数，如 fd44297e2ddb050ec4f…），通常被缩短为 12 个字符（如 fd44297e2ddb）。

镜像版本标签策略

除了版本号外，Docker 服务还允许应用标签（如 v1、 v2.1、GA 或默认 最新）来进一步指定所需的镜像，因此您可以看到同一镜像被称为 centos （表示 latest 标签）、centos:centos7 或 fd44297e2ddb。

如何标记镜像指示更新策略。具体来说，镜像更新频率较低。使用以下项来确定您选择的 OpenShift Container Platform 镜像策略：

容器镜像注册表是用于存储和检索 Docker 格式的容器镜像的服务。registry 包含一个或多个镜像存储库的集合。每个镜像存储库包含一个或多个标记的镜像。Docker 提供自己的注册表，Docker Hub，您也可以使用私有或第三方注册表。红帽在 registry.redhat.io 上为订阅者提供了一个 registry。OpenShift Container Platform 还可提供其内部 registry，用于管理自定义容器镜像。

下图中描述了容器、镜像和 registry 之间的关系：

OpenShift Container Platform 利用 Kubernetes 的 pod 概念，它是共同部署在同一主机上的一个或多个容器，也是可被定义、部署和管理的最小计算单元。

对容器而言，Pod 大致相当于机器实例（物理或虚拟）。每个 pod 分配有自己的内部 IP 地址，因此拥有完整的端口空间，并且 pod 内的容器可以共享其本地存储和网络。

Pod 有生命周期，它们经过定义后，被分配到某一节点上运行，然后持续运行，直到容器退出或它们因为其他原因被删除为止。根据策略和退出代码，Pod 可在退出后删除，或被保留下来以启用对容器日志的访问。

OpenShift Container Platform 将 pod 基本上视为不可变；在运行期间无法更改 pod 定义。OpenShift Container Platform 通过终止现有的 pod，再利用修改后的配置和/或基础镜像重新创建 pod，从而实现更改。Pod 也被视为是可抛弃的，不会在重新创建时保持原来的状态。因此，pod 通常应由更高级别的 控制器 管理，而不是直接由用户管理。

以下是一个提供长时间运行的服务的 pod 示例定义，该服务实际上是 OpenShift Container Platform 基础架构的一部分，即集成的容器镜像 registry。它展示了 pod 的许多特性，其中大多数已在其他主题中阐述，因此这里仅简略提及：

apiVersion: v1
kind: Pod
metadata:
  annotations: { ... }
  labels:                                1
    deployment: docker-registry-1
    deploymentconfig: docker-registry
    docker-registry: default
  generateName: docker-registry-1-       2
spec:
  containers:                            3
  - env:                                 4
    - name: OPENSHIFT_CA_DATA
      value: ...
    - name: OPENSHIFT_CERT_DATA
      value: ...
    - name: OPENSHIFT_INSECURE
      value: "false"
    - name: OPENSHIFT_KEY_DATA
      value: ...
    - name: OPENSHIFT_MASTER
      value: https://master.example.com:8443
    image: openshift/origin-docker-registry:v0.6.2 5
    imagePullPolicy: IfNotPresent
    name: registry
    ports:                              6
    - containerPort: 5000
      protocol: TCP
    resources: {}
    securityContext: { ... }            7
    volumeMounts:                       8
    - mountPath: /registry
      name: registry-storage
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-br6yz
      readOnly: true
  dnsPolicy: ClusterFirst
  imagePullSecrets:
  - name: default-dockercfg-at06w
  restartPolicy: Always                 9
  serviceAccount: default               10
  volumes:                              11
  - emptyDir: {}
    name: registry-storage
  - name: default-token-br6yz
    secret:
      secretName: default-token-br6yz

init 容器 是在 pod 应用程序容器启动前启动的 pod 中的容器。Init 容器可以共享卷，执行网络操作，并在剩余的容器启动前执行计算。Init 容器也可以阻止或延迟应用程序容器的启动，直到满足一些前提条件为止。

当 pod 启动时，在网络和卷初始化后，初始容器会按顺序启动。每个 init 容器都必须成功退出，然后调用下一个容器。如果 init 容器启动（因为运行时无法启动）或退出失败，则会根据 Pod 重启策略 来重试它。

直到所有 init 容器都成功前，pod 无法就绪。

有关一些 init 容器使用示例，请参阅 Kubernetes 文档。

以下示例概述了一个包含两个 init 容器的简单 pod。第一个 init 容器会等待 myservice，第二个则等待 mydb。两个容器都成功后，Pod 就会启动。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice 1
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb 2
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

每个 init 容器都具有 app 容器的所有字段， 但 readinessProbe 除外。init 容器必须退出才能继续，且无法定义除完成之外的就绪度。

init 容器可以在 pod 上包含 activeDeadlineSeconds 和 livenessProbe，以防止 init 容器永远失败。活动截止时间包括 init 容器。

Kubernetes 服务 充当内部负载均衡器。它标识一组复制的 pod，以代理其接收的连接。可以在服务中任意添加或删除支持 pod，同时服务始终保持可用，从而使依赖于服务的任何对象能够以一致的地址引用它。默认服务 clusterIP 地址来自 OpenShift Container Platform 内部网络，它们用于允许 pod 相互访问。

要允许从外部访问该服务，可以将集群外部的 externalIP 和 ingressIP 地址分配给该服务。这些 externalIP 地址也可以是虚拟 IP 地址，提供对该服务 的高可用性 访问权限。

服务被分配一个 IP 地址和端口对，访问时代理到适当的后备 pod。服务使用标签选择器来查找运行的所有容器，这些容器在特定端口上提供特定的网络服务。

与 pod 一样，服务是 REST 对象。以下示例显示了上方定义的 pod 的服务定义：

apiVersion: v1
kind: Service
metadata:
  name: docker-registry      1
spec:
  selector:                  2
    docker-registry: default
  clusterIP: 172.30.136.123   3
  ports:
  - nodePort: 0
    port: 5000               4
    protocol: TCP
    targetPort: 5000         5

Kubernetes 文档包含更多与服务相关的信息。

networkConfig:
  externalIPNetworkCIDRs:
  - 192.0.1.0.0/24

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "name": "http",
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376
            }
        ],
        "externalIPs" : [
            "192.0.1.1"         1
        ]
    }
}

networkConfig:
  ingressIPNetworkCIDR: 172.29.0.0/16

kubernetesMasterConfig:
  servicesNodePortRange: ""

$ oc get pods -o wide

NAME               READY  STATUS    RESTARTS   AGE    IP            NODE
frontend-1-287hw   1/1    Running   0          7m     172.17.0.3    node_1
frontend-1-68km5   1/1    Running   0          7m     172.17.0.6    node_1

apiVersion: v1
kind: Service
metadata:
  labels:
    app: ruby-helloworld-sample
    template: application-template-stibuild
  name: frontend-headless 1
spec:
  clusterIP: None 2
  ports:
  - name: web
    port: 5432
    protocol: TCP
    targetPort: 8080
  selector:
    name: frontend 3
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

$ oc get svc

NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
frontend            ClusterIP   172.30.232.77    <none>        5432/TCP   12m
frontend-headless   ClusterIP   None             <none>        5432/TCP   10m

$ dig frontend.test A +search +short

172.30.232.77

$ dig frontend-headless.test A +search +short

172.17.0.3
172.17.0.6

标签用于组织、组或选择 API 对象。例如，pod 使用标签进行"标记"，服务使用标签选择器标识其代理的 pod。这使得服务能够引用 pod 组，甚至可以将带有不同容器的 pod 视为相关的实体。

大多数对象都可以在其元数据中包含标签。因此标签可用于对特定应用程序的不同对象进行分组，例如，所有 pod、服务、复制控制器 和 部署配置 都可以分组。

标签是简单的键/值对，如下例所示：

labels:
  key1: value1
  key2: value2

考虑：

定义为使用 role=webserver 标签的 pod 的服务或复制控制器会将这两个 pod 视为同一组的一部分。

Kubernetes 文档包含有关标签的更多信息。

后端服务的服务器称为其端点，并由名称与服务同名的 Endpoints 类型的对象指定。当服务由 pod 支持时，这些 pod 通常由服务规格中的标签选择器指定，OpenShift Container Platform 会自动创建指向这些 pod 的 Endpoints 对象。

在某些情况下，您可能想要创建服务，但它由外部主机支持，而不是由 OpenShift Container Platform 集群中的 pod 支持。在这种情况下，您可以取消服务中的 selector 字段，并 手动创建 Endpoints 对象。

请注意，OpenShift Container Platform 不允许大多数用户手动创建端点对象，指向为 pod 和服务 IP 保留的网络块中的 IP 地址。只有集群管理员或其他有权在 端点/限制 下创建 资源的用户才能 创建此类 Endpoint 对象。

与 OpenShift Container Platform 的交互与用户相关联。OpenShift Container Platform 用户对象代表一个执行者，可以通过向 它们或组 添加角色来授予 系统中的权限。

可能存在的用户类型有几种：

每一用户必须通过 某种形式的身份验证才能访问 OpenShift Container Platform。无身份验证或身份验证无效的 API 请求会被验证为由 匿名系统用户 发出的请求。经过身份验证后，策略决定用户 被授权执行的操作。

Kubernetes 命名空间提供范围集群中资源的机制。在 OpenShift Container Platform 中，项目 是一个带有额外注解的 Kubernetes 命名空间。

命名空间为以下对象提供唯一范围：

系统中的大多数对象都通过命名空间来设定范围，但一些对象不在此列且没有命名空间，如节点和用户。

Kubernetes 文档中提供有关命名空间的更多信息。

项目是附带额外注解的 Kubernetes 命名空间，是管理常规用户资源访问权限的中央载体。通过项目，一个社区的用户可以在与其他社区隔离的前提下组织和管理其内容。用户必须由管理员授予对项目的访问权限；或者，如果用户有权创建项目，则自动具有自己创建项目的访问权限。

项目可以有单独的 name, displayName, 和 description。

每个项目限制了自己的一组：

集群管理员可以 创建项目，并将项目 的管理权限委派给 用户社区的任何成员。集群管理员也可以允许开发人员 创建自己的项目。

开发人员和管理员可以使用 CLI 或 Web 控制台 与项目交互。

构建 (build)是将输入参数转换为结果对象的过程。此过程最常用于将输入参数或源代码转换为可运行的镜像。BuildConfig 对象是整个构建过程的定义。

OpenShift Container Platform 通过从构建镜像创建 Docker 格式的容器，并将它们推送到 容器镜像 registry 中。

构建对象共享共同特征：构建的输入、完成构建过程需要、记录构建过程、从成功构建中发布资源并发布构建的最终状态。构建会使用资源限制，具体是指定资源限值，如 CPU 使用量、内存使用量，以及构建或 Pod 执行时间。

OpenShift Container Platform 构建系统提供对构建策略的可扩展支持，它们基于构建 API 中指定的可选择类型。可用的构建策略主要有三种：

默认情况下，支持 Docker 构建和 S2I 构建。

构建生成的对象取决于用于创建它的构建器（builder）。对于 Docker 和 S2I 构建，生成的对象为可运行的镜像。对于 Custom 构建，生成的对象是构建器镜像作者指定的任何事物。

另外，也可利用 Pipeline 构建策略来实现复杂的工作流：

有关构建命令列表，请参阅开发人员指南。

如需有关 OpenShift Container Platform 如何使用 Docker 进行构建的更多信息，请参阅上游文档。

镜像流及其关联标签提供了一个用于从 OpenShift Container Platform 中引用容器镜像的抽象 集。镜像流及其标签用于查看可用镜像，确保您使用所需的特定镜像，即使存储库中的镜像发生变化也是如此。

镜像流不含实际镜像数据，它提供了相关镜像的一个单独的虚拟视图，类似于镜像存储库。

您可以在添加新镜像时，配置构建和部署来监控镜像流的通知，并通过分别执行构建或部署来做出反应。

例如，如果部署正在使用某个镜像并且创建了该镜像的新版本，则会自动执行部署以获取镜像的新版本。

但是，如果没有更新 Deployment 或 Build 使用的镜像流标签，则即使更新了容器镜像 registry 中的容器镜像，构建或部署仍会继续使用之前的（已知良好）镜像。

源镜像可存储在以下任一位置：

当您定义引用镜像流标签（如构建或部署配置）的对象时，您指向镜像流标签，而不是 Docker 存储库。当您构建或部署应用程序时，OpenShift Container Platform 会使用镜像流标签查询 Docker 存储库，以查找与镜像关联的 ID，并使用正确的镜像。

镜像流元数据会与其他集群信息一起存储在 etcd 实例中。

以下镜像流包含两个标签：34 个指向 Python v3.4 镜像和 35 （指向 Python v3.5 镜像）的 34:

$ oc describe is python

Name:			python
Namespace:		imagestream
Created:		25 hours ago
Labels:			app=python
Annotations:		openshift.io/generated-by=OpenShiftWebConsole
			openshift.io/image.dockerRepositoryCheck=2017-10-03T19:48:00Z
Docker Pull Spec:	docker-registry.default.svc:5000/imagestream/python
Image Lookup:		local=false
Unique Images:		2
Tags:			2

34
  tagged from centos/python-34-centos7

  * centos/python-34-centos7@sha256:28178e2352d31f240de1af1370be855db33ae9782de737bb005247d8791a54d0
      14 seconds ago

35
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:2efb79ca3ac9c9145a63675fb0c09220ab3b8d4005d35e0644417ee552548b10
      7 seconds ago

使用镜像流有以下几大优势：

有关策展的镜像流集合，请参阅 OpenShift 镜像流和模板库。

使用镜像流时，务必要了解镜像流标签指向什么以及如何对标签和镜像的更改产生影响。例如：

docker.io/openshift/jenkins-2-centos7:3.6.0

docker.io/openshift/jenkins-2-centos7@sha256:ab312bda324

apiVersion: v1
kind: ImageStream
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftNewApp
  creationTimestamp: 2017-09-29T13:33:49Z
  generation: 1
  labels:
    app: ruby-sample-build
    template: application-template-stibuild
  name: origin-ruby-sample 1
  namespace: test
  resourceVersion: "633"
  selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
  uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
  dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample 2
  tags:
  - items:
    - created: 2017-09-02T10:15:09Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d 3
      generation: 2
      image: sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5 4
    - created: 2017-09-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
      generation: 1
      image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
    tag: latest 5

<image-stream-name>@<image-id>

origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d

  tags:
  - items:
    - created: 2017-09-02T10:15:09Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
      generation: 2
      image: sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
    - created: 2017-09-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
      generation: 1
      image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
    tag: latest

<image stream name>:<tag>

origin-ruby-sample:latest

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true 1
      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"

apiVersion: v1
kind: ImageStreamMapping
metadata:
  creationTimestamp: null
  name: origin-ruby-sample
  namespace: test
tag: latest
image:
  dockerImageLayers:
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:ee1dd2cb6df21971f4af6de0f1d7782b81fb63156801cfde2bb47b4247c23c29
    size: 196634330
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:ca062656bff07f18bff46be00f40cfbb069687ec124ac0aa038fd676cfaea092
    size: 177723024
  - name: sha256:63d529c59c92843c395befd065de516ee9ed4995549f8218eac6ff088bfa6b6e
    size: 55679776
  - name: sha256:92114219a04977b5563d7dff71ec4caa3a37a15b266ce42ee8f43dba9798c966
    size: 11939149
  dockerImageMetadata:
    Architecture: amd64
    Config:
      Cmd:
      - /usr/libexec/s2i/run
      Entrypoint:
      - container-entrypoint
      Env:
      - RACK_ENV=production
      - OPENSHIFT_BUILD_NAMESPACE=test
      - OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git
      - EXAMPLE=sample-app
      - OPENSHIFT_BUILD_NAME=ruby-sample-build-1
      - PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - STI_SCRIPTS_URL=image:///usr/libexec/s2i
      - STI_SCRIPTS_PATH=/usr/libexec/s2i
      - HOME=/opt/app-root/src
      - BASH_ENV=/opt/app-root/etc/scl_enable
      - ENV=/opt/app-root/etc/scl_enable
      - PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
      - RUBY_VERSION=2.2
      ExposedPorts:
        8080/tcp: {}
      Labels:
        build-date: 2015-12-23
        io.k8s.description: Platform for building and running Ruby 2.2 applications
        io.k8s.display-name: 172.30.56.218:5000/test/origin-ruby-sample:latest
        io.openshift.build.commit.author: Ben Parees <bparees@users.noreply.github.com>
        io.openshift.build.commit.date: Wed Jan 20 10:14:27 2016 -0500
        io.openshift.build.commit.id: 00cadc392d39d5ef9117cbc8a31db0889eedd442
        io.openshift.build.commit.message: 'Merge pull request #51 from php-coder/fix_url_and_sti'
        io.openshift.build.commit.ref: master
        io.openshift.build.image: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
        io.openshift.build.source-location: https://github.com/openshift/ruby-hello-world.git
        io.openshift.builder-base-version: 8d95148
        io.openshift.builder-version: 8847438ba06307f86ac877465eadc835201241df
        io.openshift.s2i.scripts-url: image:///usr/libexec/s2i
        io.openshift.tags: builder,ruby,ruby22
        io.s2i.scripts-url: image:///usr/libexec/s2i
        license: GPLv2
        name: CentOS Base Image
        vendor: CentOS
      User: "1001"
      WorkingDir: /opt/app-root/src
    Container: 86e9a4a3c760271671ab913616c51c9f3cea846ca524bf07c04a6f6c9e103a76
    ContainerConfig:
      AttachStdout: true
      Cmd:
      - /bin/sh
      - -c
      - tar -C /tmp -xf - && /usr/libexec/s2i/assemble
      Entrypoint:
      - container-entrypoint
      Env:
      - RACK_ENV=production
      - OPENSHIFT_BUILD_NAME=ruby-sample-build-1
      - OPENSHIFT_BUILD_NAMESPACE=test
      - OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git
      - EXAMPLE=sample-app
      - PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - STI_SCRIPTS_URL=image:///usr/libexec/s2i
      - STI_SCRIPTS_PATH=/usr/libexec/s2i
      - HOME=/opt/app-root/src
      - BASH_ENV=/opt/app-root/etc/scl_enable
      - ENV=/opt/app-root/etc/scl_enable
      - PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
      - RUBY_VERSION=2.2
      ExposedPorts:
        8080/tcp: {}
      Hostname: ruby-sample-build-1-build
      Image: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
      OpenStdin: true
      StdinOnce: true
      User: "1001"
      WorkingDir: /opt/app-root/src
    Created: 2016-01-29T13:40:00Z
    DockerVersion: 1.8.2.fc21
    Id: 9d7fd5e2d15495802028c569d544329f4286dcd1c9c085ff5699218dbaa69b43
    Parent: 57b08d979c86f4500dc8cad639c9518744c8dd39447c055a3517dc9c18d6fccd
    Size: 441976279
    apiVersion: "1.0"
    kind: DockerImage
  dockerImageMetadataVersion: "1.0"
  dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d

$ oc describe is/<image-name>

$ oc describe is/python

Name:			python
Namespace:		default
Created:		About a minute ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-10-02T17:05:11Z
Docker Pull Spec:	docker-registry.default.svc:5000/default/python
Image Lookup:		local=false
Unique Images:		1
Tags:			1

3.5
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      About a minute ago

$ oc describe istag/<image-stream>:<tag-name>

$ oc describe istag/python:latest

Image Name:	sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Docker Image:	centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Name:		sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Created:	2 minutes ago
Image Size:	251.2 MB (first layer 2.898 MB, last binary layer 72.26 MB)
Image Created:	2 weeks ago
Author:		<none>
Arch:		amd64
Entrypoint:	container-entrypoint
Command:	/bin/sh -c $STI_SCRIPTS_PATH/usage
Working Dir:	/opt/app-root/src
User:		1001
Exposes Ports:	8080/tcp
Docker Labels:	build-date=20170801

oc tag <image-name:tag> <image-name:tag>

$ oc tag python:3.5 python:latest

Tag python:latest set to python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25.

$ oc describe is/python

Name:			python
Namespace:		default
Created:		5 minutes ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-10-02T17:05:11Z
Docker Pull Spec:	docker-registry.default.svc:5000/default/python
Image Lookup:		local=false
Unique Images:		1
Tags:			2

latest
  tagged from python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      About a minute ago

3.5
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      5 minutes ago

$ oc tag <repositiory/image> <image-name:tag>

$ oc tag docker.io/python:3.6.0 python:3.6

Tag python:3.6 set to docker.io/python:3.6.0.

$ oc tag <image-name:tag> <image-name:latest>

$ oc tag python:3.6 python:latest

Tag python:latest set to python@sha256:438208801c4806548460b27bd1fbcb7bb188273d13871ab43f.

$ oc tag -d <image-name:tag>

$ oc tag -d python:3.5

Deleted tag default/python:3.5.

$ oc tag <repositiory/image> <image-name:tag> --scheduled

$ oc tag docker.io/python:3.6.0 python:3.6 --scheduled

Tag python:3.6 set to import docker.io/python:3.6.0 periodically.

$ oc tag <repositiory/image> <image-name:tag>

复制控制器确保任何时候都运行指定数量的 pod 副本。如果 pod 退出或被删除，复制控制器会做出反应，实例化更多 pod 来达到定义的数量。同样，如果运行中的数量超过所需的数目，它会根据需要删除相应数量的 Pod，使其与定义的数量相符。

复制控制器配置包括：

选择器是分配给由复制控制器管理的 pod 的一组标签。这些标签包含在复制控制器实例化的容器集定义中。复制控制器使用选择器来决定已在运行的 pod 实例数量，以便根据需要进行调整。

复制控制器不会基于负载或流量执行自动扩展，因为复制控制器不会跟踪它们。相反，这需要外部自动缩放器调整其副本数。

复制控制器是名为 ReplicationController 的核心 Kubernetes 对象。

以下是 ReplicationController 定义示例：

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1  1
  selector:    2
    name: frontend
  template:    3
    metadata:
      labels:  4
        name: frontend 5
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

与 复制控制器 类似，副本集确保在任何给定时间运行指定数量的 pod 副本。副本集与复制控制器之间的区别在于，副本集支持基于集合的选择器要求，而复制控制器只支持基于相等的选择器要求。

副本集是一个被称为 ReplicaSet 的核心 Kubernetes 对象。

以下是 ReplicaSet 定义示例：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: 1
    matchLabels: 2
      tier: frontend
    matchExpressions: 3
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

作业类似于复制控制器，其目的在于出于指定的原因创建 pod。不同之处在于复制控制器是为持续运行的容器集设计的，而作业则用于一次性容器集。作业跟踪所有成功完成，并且达到指定数量的完成时，作业本身将完成。

以下示例计算 π 到 2000 个位置，输出它，然后完成：

apiVersion: extensions/v1
kind: Job
metadata:
  name: pi
spec:
  selector:
    matchLabels:
      app: pi
  template:
    metadata:
      name: pi
      labels:
        app: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

有关如何使用作业（job）的更多信息，请参阅作业。

在复制控制器的基础上，OpenShift Container Platform 添加了对软件开发和部署生命周期的支持以及部署的概念。在最简单的情形中，部署仅创建一个新复制控制器，并允许它启动 pod。但是，OpenShift Container Platform 部署也提供从镜像的现有部署过渡到新部署的功能，还可定义要在创建复制控制器之前或之后运行的 hook。

OpenShift Container Platform DeploymentConfig 对象定义以下部署详情：

每次触发部署时，无论是手动还是自动，部署器 Pod 均管理部署（包括缩减旧复制控制器、扩展新复制控制器以及运行 hook）。部署 pod 在完成部署后会无限期保留，以便保留其部署日志。当部署被另一个部署替换时，以前的复制控制器会被保留，以便在需要时轻松回滚。

有关如何创建和与部署交互的详细信息，请参阅 Deployment。

以下是含有一些省略和标注的 DeploymentConfig 定义示例：

apiVersion: v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange 1
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  2
  strategy:
    type: Rolling      3

模板描述了一组可参数化和处理的对象，用于生成对象列表，供 OpenShift Container Platform 用于创建。要创建的对象可以包含用户有权在项目内创建的任何对象，如 服务、构建配置和 部署配置。模板还可定义一系列标签（label），以应用到该模板中定义的每个对象。

有关创建和使用 模板的详细信息，请参阅模板指南。

身份验证层识别与 OpenShift Container Platform API 请求关联的用户。然后，授权层使用与请求用户相关的信息来确定是否应允许该请求。

作为管理员，您可以使用 主（master）配置文件 配置身份验证。

OpenShift Container Platform 中的用户是可以向 OpenShift Container Platform API 发出请求的实体。通常，这代表与 OpenShift Container Platform 交互的开发人员或管理员的帐户。

用户可以分配到一个或多个组中，每个组代表特定的用户集合。在 管理授权策略 时，可以同时为多个用户授予权限，例如允许访问 项目内 的对象，而不必逐一向用户授予权限。

除了显式定义的组外，还有 OpenShift 自动调配的 系统组或虚拟组。在 查看集群绑定 时可以看到它们。

在默认虚拟组集合中，特别注意以下内容：

对 OpenShift Container Platform API 的请求通过以下方式进行身份验证：

任何具有无效访问令牌或无效证书的请求都会被身份验证层以 401 错误形式拒绝。

如果没有出示访问令牌或证书，身份验证层会将 system:anonymous 虚拟用户和 system:unauthenticated 虚拟组分配给请求。这使得授权层能够决定匿名用户可以发出哪些（如有）请求。

$ oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>

$ oc new-project <project> --as=<user> \
--as-group=system:authenticated --as-group=system:authenticated:oauth

OpenShift Container Platform master 包含内置的 OAuth 服务器。用户获取 OAuth 访问令牌来对自身进行 API 身份验证。

当用户请求新的 OAuth 令牌时，OAuth 服务器使用配置的 身份提供程序 来确定发出请求的人员的身份。

然后，它会确定该身份所映射到的用户，为该用户创建一个访问令牌，再返回要使用的令牌。

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
 name: demo 1
secret: "..." 2
redirectURIs:
 - "http://www.example.com/" 3
grantMethod: prompt 4
')

serviceaccounts.openshift.io/oauth-redirecturi.<name>

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ..., 1
    "name": ..., 2
    "group": ... 3
  }
}

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
"serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

$ oc get events | grep ServiceAccount

1m         1m          1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

$ oc describe sa/proxy | grep -A5 Events

Events:
  FirstSeen     LastSeen        Count   From                                    SubObjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                                    -------------   --------        ------                  -------
  3m            3m              1       service-account-oauth-client-getter                     Warning         NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Reason                  Message
NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Reason                  Message
NoSAOAuthRedirectURIs   [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Reason                  Message
NoSAOAuthRedirectURIs   [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens

{
  "issuer": "https://<master>", 1
  "authorization_endpoint": "https://<master>/oauth/authorize", 2
  "token_endpoint": "https://<master>/oauth/token", 3
  "scopes_supported": [ 4
    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ 5
    "code",
    "token"
  ],
  "grant_types_supported": [ 6
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ 7
    "plain",
    "S256"
  ]
}

$ curl -H "X-Remote-User: <username>" \
     --cacert /etc/origin/master/ca.crt \
     --cert /etc/origin/master/admin.crt \
     --key /etc/origin/master/admin.key \
     -I https://<master-address>/oauth/authorize?response_type=token\&client_id=openshift-challenging-client | grep -oP "access_token=\K[^&]*"

$ curl -u <username>:<password>
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -skv / 1
/ -H "X-CSRF-Token: xxx" 2

*   Trying 10.64.33.43...
* Connected to 10.64.33.43 (10.64.33.43) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: 10.64.33.43 (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=10.64.33.43
*        start date: Thu, 09 Aug 2018 04:00:39 GMT
*        expire date: Sat, 08 Aug 2020 04:00:40 GMT
*        issuer: CN=openshift-signer@1531109367
*        compression: NULL
* ALPN, server accepted to use http/1.1
* Server auth using Basic with user 'developer'
> GET /oauth/authorize?client_id=openshift-challenging-client&response_type=token HTTP/1.1
> Host: 10.64.33.43:8443
> Authorization: Basic ZGV2ZWxvcGVyOmRzc2Zkcw==
> User-Agent: curl/7.47.0
> Accept: */*
> X-CSRF-Token: xxx
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location:
https://10.64.33.43:8443/oauth/token/implicit#access_token=gzTwOq_mVJ7ovHliHBTgRQEEXa1aCZD9lnj7lSw3ekQ&expires_in=86400&scope=user%3Afull&token_type=Bearer 1
< Pragma: no-cache
< Set-Cookie: ssn=MTUzNTk0OTc1MnxIckVfNW5vNFlLSlF5MF9GWEF6Zm55Vl95bi1ZNE41S1NCbFJMYnN1TWVwR1hwZmlLMzFQRklzVXRkc0RnUGEzdnBEa0NZZndXV2ZUVzN1dmFPM2dHSUlzUmVXakQ3Q09rVXpxNlRoVmVkQU5DYmdLTE9SUWlyNkJJTm1mSDQ0N2pCV09La3gzMkMzckwxc1V1QXpybFlXT2ZYSmI2R2FTVEZsdDBzRjJ8vk6zrQPjQUmoJCqb8Dt5j5s0b4wZlITgKlho9wlKAZI=; Path=/; HttpOnly; Secure
< Date: Mon, 03 Sep 2018 04:42:32 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host 10.64.33.43 left intact

$ curl -u <username>:<password> /
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' / 1
-skv -H "X-CSRF-Token: xxx" --stderr - |  grep -oP "access_token=\K[^&]*" 2

hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc

基于角色的访问控制(RBAC)对象确定是否允许用户在项目内执行给定的 操作。

这允许平台管理员使用 集群角色和绑定 来控制谁对 OpenShift Container Platform 平台本身和所有项目具有各种访问权限级别。

开发人员可以 利用本地角色和绑定来控制 谁有权访问 其项目。请注意，授权是独立于 身份验证 的一个步骤，身份验证更在于确定执行操作的人员的身份。

授权通过使用以下几项来管理：

集群管理员可以使用 CLI 视觉化规则、角色和绑定。

例如，请考虑以下摘录，其中显示了 admin 和 basic-user 默认集群角色 的规则集：

$ oc describe clusterrole.rbac admin basic-user

Name:		admin
Labels:		<none>
Annotations:	openshift.io/description=A user that has edit rights within the project and can change the project's membership.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources							Non-Resource URLs	Resource Names	Verbs
  ---------							-----------------	--------------	-----
  appliedclusterresourcequotas					[]			[]		[get list watch]
  appliedclusterresourcequotas.quota.openshift.io		[]			[]		[get list watch]
  bindings							[]			[]		[get list watch]
  buildconfigs							[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs/instantiate					[]			[]		[create]
  buildconfigs.build.openshift.io/instantiate			[]			[]		[create]
  buildconfigs/instantiatebinary				[]			[]		[create]
  buildconfigs.build.openshift.io/instantiatebinary		[]			[]		[create]
  buildconfigs/webhooks						[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io/webhooks			[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs							[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds							[]			[]		[create delete deletecollection get list patch update watch]
  builds.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds/clone							[]			[]		[create]
  builds.build.openshift.io/clone				[]			[]		[create]
  builds/details						[]			[]		[update]
  builds.build.openshift.io/details				[]			[]		[update]
  builds/log							[]			[]		[get list watch]
  builds.build.openshift.io/log					[]			[]		[get list watch]
  configmaps							[]			[]		[create delete deletecollection get list patch update watch]
  cronjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  daemonsets.extensions						[]			[]		[get list watch]
  deploymentconfigrollbacks					[]			[]		[create]
  deploymentconfigrollbacks.apps.openshift.io			[]			[]		[create]
  deploymentconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/instantiate					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/instantiate		[]			[]		[create]
  deploymentconfigs/log						[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/log			[]			[]		[get list watch]
  deploymentconfigs/rollback					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/rollback			[]			[]		[create]
  deploymentconfigs/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io/scale			[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/status					[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/status			[]			[]		[get list watch]
  deployments.apps						[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/rollback				[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/status					[]			[]		[create delete deletecollection get list patch update watch]
  endpoints							[]			[]		[create delete deletecollection get list patch update watch]
  events							[]			[]		[get list watch]
  horizontalpodautoscalers.autoscaling				[]			[]		[create delete deletecollection get list patch update watch]
  horizontalpodautoscalers.extensions				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimports						[]			[]		[create]
  imagestreamimports.image.openshift.io				[]			[]		[create]
  imagestreammappings						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreammappings.image.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams							[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/layers						[]			[]		[get update]
  imagestreams.image.openshift.io/layers			[]			[]		[get update]
  imagestreams/secrets						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io/secrets			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/status						[]			[]		[get list watch]
  imagestreams.image.openshift.io/status			[]			[]		[get list watch]
  imagestreamtags						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamtags.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  jenkins.build.openshift.io					[]			[]		[admin edit view]
  jobs.batch							[]			[]		[create delete deletecollection get list patch update watch]
  limitranges							[]			[]		[get list watch]
  localresourceaccessreviews					[]			[]		[create]
  localresourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  localsubjectaccessreviews					[]			[]		[create]
  localsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  localsubjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  namespaces							[]			[]		[get list watch]
  namespaces/status						[]			[]		[get list watch]
  networkpolicies.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  persistentvolumeclaims					[]			[]		[create delete deletecollection get list patch update watch]
  pods								[]			[]		[create delete deletecollection get list patch update watch]
  pods/attach							[]			[]		[create delete deletecollection get list patch update watch]
  pods/exec							[]			[]		[create delete deletecollection get list patch update watch]
  pods/log							[]			[]		[get list watch]
  pods/portforward						[]			[]		[create delete deletecollection get list patch update watch]
  pods/proxy							[]			[]		[create delete deletecollection get list patch update watch]
  pods/status							[]			[]		[get list watch]
  podsecuritypolicyreviews					[]			[]		[create]
  podsecuritypolicyreviews.security.openshift.io		[]			[]		[create]
  podsecuritypolicyselfsubjectreviews				[]			[]		[create]
  podsecuritypolicyselfsubjectreviews.security.openshift.io	[]			[]		[create]
  podsecuritypolicysubjectreviews				[]			[]		[create]
  podsecuritypolicysubjectreviews.security.openshift.io		[]			[]		[create]
  processedtemplates						[]			[]		[create delete deletecollection get list patch update watch]
  processedtemplates.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  projects							[]			[]		[delete get patch update]
  projects.project.openshift.io					[]			[]		[delete get patch update]
  replicasets.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  replicasets.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers.extensions/scale			[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/status					[]			[]		[get list watch]
  resourceaccessreviews						[]			[]		[create]
  resourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  resourcequotas						[]			[]		[get list watch]
  resourcequotas/status						[]			[]		[get list watch]
  resourcequotausages						[]			[]		[get list watch]
  rolebindingrestrictions					[]			[]		[get list watch]
  rolebindingrestrictions.authorization.openshift.io		[]			[]		[get list watch]
  rolebindings							[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.authorization.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.rbac.authorization.k8s.io			[]			[]		[create delete deletecollection get list patch update watch]
  roles								[]			[]		[create delete deletecollection get list patch update watch]
  roles.authorization.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  roles.rbac.authorization.k8s.io				[]			[]		[create delete deletecollection get list patch update watch]
  routes							[]			[]		[create delete deletecollection get list patch update watch]
  routes.route.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  routes/custom-host						[]			[]		[create]
  routes.route.openshift.io/custom-host				[]			[]		[create]
  routes/status							[]			[]		[get list watch update]
  routes.route.openshift.io/status				[]			[]		[get list watch update]
  scheduledjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  secrets							[]			[]		[create delete deletecollection get list patch update watch]
  serviceaccounts						[]			[]		[create delete deletecollection get list patch update watch impersonate]
  services							[]			[]		[create delete deletecollection get list patch update watch]
  services/proxy						[]			[]		[create delete deletecollection get list patch update watch]
  statefulsets.apps						[]			[]		[create delete deletecollection get list patch update watch]
  subjectaccessreviews						[]			[]		[create]
  subjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  subjectrulesreviews						[]			[]		[create]
  subjectrulesreviews.authorization.openshift.io		[]			[]		[create]
  templateconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  templateconfigs.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances						[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  templates							[]			[]		[create delete deletecollection get list patch update watch]
  templates.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]


Name:		basic-user
Labels:		<none>
Annotations:	openshift.io/description=A user that can get basic information about projects.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources						Non-Resource URLs	Resource Names	Verbs
  ---------						-----------------	--------------	-----
  clusterroles						[]			[]		[get list]
  clusterroles.authorization.openshift.io		[]			[]		[get list]
  clusterroles.rbac.authorization.k8s.io		[]			[]		[get list watch]
  projectrequests					[]			[]		[list]
  projectrequests.project.openshift.io			[]			[]		[list]
  projects						[]			[]		[list watch]
  projects.project.openshift.io				[]			[]		[list watch]
  selfsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  selfsubjectrulesreviews				[]			[]		[create]
  selfsubjectrulesreviews.authorization.openshift.io	[]			[]		[create]
  storageclasses.storage.k8s.io				[]			[]		[get list]
  users							[]			[~]		[get]
  users.user.openshift.io				[]			[~]		[get]

以下摘录查看本地角色绑定，显示了绑定到不同用户和组的以上角色：

$ oc describe rolebinding.rbac admin basic-user -n alice-project

Name:		admin
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind	Name		Namespace
  ----	----		---------
  User	system:admin
  User	alice


Name:		basic-user
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	basic-user
Subjects:
  Kind	Name	Namespace
  ----	----	---------
  User	joe
  Group	devel

下方展示了集群角色、本地角色、集群角色绑定、本地角色绑定、用户、组和服务帐户之间的关系。

OpenShift Container Platform 在评估授权时结合了几个因素：

OpenShift Container Platform 通过以下步骤评估授权：

控制授权的 RBAC 角色和绑定有两个级别：

这种双级层次结构允许通过集群角色重新利用多个项目，同时允许通过本地角色在单个项目中自定义。

在评估过程中，同时使用集群角色绑定和本地角色绑定。例如：

角色是策略 规则 的集合，这是一组可以对一组资源执行的允许动词。OpenShift Container Platform 包含一组默认的集群角色，可以绑定到集群范围 或 本地的 用户和组。

项目管理员可以视觉化角色，包括使用 CLI 关联的操作动词和资源列表 来查看本地角色和绑定。

了解如何为项目创建本地角色。

$ oc auth reconcile -f <file> 1

除了控制用户可执行的操作的 RBAC 资源 外，OpenShift Container Platform 还提供 安全性上下文约束 (SCC)来控制 Pod 可以执行的操作以及它有权访问的内容。管理员可以使用 CLI 管理 SCC。

SCC 在管理对持久存储的访问时也非常有用。

SCC 是定义 Pod 运行必须满足的一组条件的对象，以便其能被系统接受。它们允许管理员控制以下内容：

默认情况下，在集群中添加七个 SCC，集群管理员可使用 CLI 查看它们：

$ oc get scc

NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
privileged         true      [*]       RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]

集群管理员也可以使用 CLI 查看各个 SCC 的定义。例如，对于特权 SCC：

$ oc get -o yaml --export scc/privileged

allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities: 1
- '*'
apiVersion: v1
defaultAddCapabilities: [] 2
fsGroup: 3
  type: RunAsAny
groups: 4
- system:cluster-admins
- system:nodes
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: 'privileged allows access to all privileged and host
      features and the ability to run as any user, any group, any fsGroup, and with
      any SELinux context.  WARNING: this is the most relaxed SCC and should be used
      only for cluster administration. Grant with caution.'
  creationTimestamp: null
  name: privileged
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: [] 5
runAsUser: 6
  type: RunAsAny
seLinuxContext: 7
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups: 8
  type: RunAsAny
users: 9
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
- system:serviceaccount:openshift-infra:build-controller
volumes:
- '*'

SCC 上的 users 和 groups 字段控制可以使用哪些 SCC。默认情况下，集群管理员、节点和构建控制器被授予特权 SCC 的访问权限。所有经过身份验证的用户被授予受限 SCC 的访问权限。

Docker 具有允许用于 Pod 的每个容器的默认功能列表。容器使用此默认列表中的功能，但 Pod 清单作者可以通过请求额外的功能或丢弃一些默认功能来修改它。allowedCapabilities、defaultAddCapabilities 和 requiredDropCapabilities 字段用于控制来自 Pod 的此类请求，并指定可以请求哪些功能、必须为每个容器添加哪些功能，以及必须禁止哪些功能。

特权 SCC：

受限 SCC：

SCC 由设置和策略组成，它们控制容器集可以访问的安全功能。这些设置分为三个类别：

volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs

rules:
- apiGroups:
  - security.openshift.io 1
  resources:
  - securitycontextconstraints 2
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
  resourceNames:
  - myPermittingSCC 3

在 OpenShift Container Platform 项目中，您可以确定您可以对所有命名空间范围的资源（包括第三方资源）执行的操作动词。运行：

$ oc policy can-i --list --loglevel=8

输出将帮助您确定收集信息的 API 请求。

要以用户可读格式接收信息，请运行：

$ oc policy can-i --list

输出中会提供一个完整的列表。

要确定您可以执行特定的动词 ， 请运行：

$ oc policy can-i <verb> <resource>

用户范围 可以提供有关给定范围的更多信息。例如：

$ oc policy can-i <verb> <resource> --scopes=user:info

管理存储与管理计算资源不同。OpenShift Container Platform 使用 Kubernetes 持久性卷 (PV) 框架来允许集群管理员为集群提供持久性存储。开发者可以使用持久性卷声明 (PVC) 来请求 PV 资源而无需具体了解底层存储基础架构。

PVC 特定于 某个项目，开发人员会创建和使用 PV。PV 资源本身并不特定于某一个项目; 它们可以在整个 OpenShift Container Platform 集群间共享，并可以被任何项目使用。当 PV 绑定到 PVC 后，但该 PV 不能绑定到额外的 PVC。这会使绑定的 PV 限定为 一个命名空间 （绑定项目是什么）。

PV 由一个 persistentVolume API 对象定义，它代表了集群管理员置备的已存在的网络存储。它与一个节点一样，是一个集群资源。PV 是卷插件，与 Volumes 资源类似，但PV 的生命周期独立于任何使用它的 pod。PV 对象获取具体存储（NFS、iSCSI 或者特定 cloud-provider 的存储系统）的实现详情。

PVC 由 PersistentVolumeClaim API 项定义，它代表了开发人员对存储的一个请求。它与一个 pod 类似，pod 会消耗节点资源， PVC 消耗 PV 资源。例如，pod 可以请求特定级别的资源（如 CPU 和内存），而 PVC 可以请求特定 的存储容量 和访问模式 （例如，可以在读/写或多次只读时挂载它们）。

PV 是集群中的资源。PVC 是对这些资源的请求，也是对该资源的声明检查。PV 和 PVC 之间的交互有以下生命周期。

每个 PV 都会包括一个 spec 和 status，它们分别代表卷的规格和状态，例如：

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0003
  spec:
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    nfs:
      path: /tmp
      server: 172.17.0.2

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
  annotations:
    volume.beta.kubernetes.io/mount-options: rw,nfsvers=4,noexec 1
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

每个 PVC 都会包括一个 spec 和 status，它们分别代表了声明的规格和状态，例如：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: gold

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

您可以通过在 PV 和 PVC 规格中包含 API 字段来静态置备原始块卷。

要使用块卷，您必须首先启用 BlockVolume 功能门。要为 master 启用功能门，请将 feature-gates 添加到 apiServerArguments 和 controllerArguments 中。要为节点启用功能门，在 kubeletArguments 中添加 功能门。例如：

kubeletArguments:
   feature-gates:
     - BlockVolume=true

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 1
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 1
  resources:
    requests:
      storage: 10Gi

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:  1
        - name: data
          devicePath: /dev/xvda 2
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc 3

除了持久性存储外，Pod 和容器还需要临时或临时本地存储才能进行操作。此临时存储的生命周期不会超过每个 pod 的生命周期，且此临时存储无法在 pod 间共享。

在 OpenShift Container Platform 3.10 之前，使用容器的可写层、日志目录和 EmptyDir 卷向 pod 公开临时本地存储。Pod 使用临时本地存储进行涂销空间、缓存和日志。与缺少本地存储相关的问题包括：

与持久性卷不同，临时存储是无结构和共享、空间而不是实际的数据，除了系统、容器运行时和 OpenShift Container Platform 的其他使用之外，临时存储也不例外。临时存储框架允许 pod 指定其临时本地存储需求，OpenShift Container Platform 会在适当的位置调度 pod，并防止节点过度使用本地存储。

虽然临时存储框架允许管理员和开发人员更好地管理这个本地存储，但它不提供任何与 I/O 吞吐量和延迟有关的内容。

主分区中始终提供临时本地存储。创建主分区（root 和运行时）有两种基本方法。

集群管理员可以通过 设置配额 在非终端状态的所有 Pod 中定义临时存储的限制范围和临时存储请求数量来管理项目中的临时存储。开发人员也可以在 Pod 和容器级别上设置此计算资源的 请求和限值。

您可以使用 /bin/df 作为监控临时容器数据所在卷的临时存储使用情况的工具，即 /var/lib/origin 和 /var/lib/docker。如果集群管理员将 /var/lib/docker 放置在单独的磁盘中，则使用 df 命令，则仅显示 /var/lib/origin 的可用空间。

使用 df -h 命令显示 /var/lib 中已用和可用空间的人类可读值：

$ df -h /var/lib

Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1    69G   32G   34G  49% /

准入(Admission)插件会在资源持久性前截获对 master API 的请求，但在请求被验证并被授权后。

在请求被接受至集群中之前，每个准入插件会按顺序运行。如果序列中的任何插件拒绝了请求，则整个请求将立即被拒绝，并且将返回一个错误给最终用户。

准入插件可能会在一些情况下修改传入对象，以应用系统配置的默认值。另外，准入插件可能会修改相关资源，作为请求处理的一部分来执行各种操作，如递增配额使用量。

OpenShift Container Platform 为 Kubernetes 和 OpenShift Container Platform 资源使用单一准入链。这意味着顶级 admissionConfig.pluginConfig 元素现在可以包含插件配置，它们被包括在 kubernetesMasterConfig.admissionConfig.pluginConfig 中。

kubernetesMasterConfig.admissionConfig.pluginConfig 应该被移到 admissionConfig.pluginConfig 中。

所有支持的准入插件都在单一链中排序。您没有设置 admissionConfig.pluginOrderOverride 或 kubernetesMasterConfig.admissionConfig.pluginOrderOverride。反之，启用默认为关闭的插件，可以添加其插件相关的配置，或者添加 DefaultAdmissionConfig 小节，如下所示：

admissionConfig:
  pluginConfig:
    AlwaysPullImages: 1
      configuration:
        kind: DefaultAdmissionConfig
        apiVersion: v1
        disable: false 2

将 disable 设置为 true 将禁用默认为 on 的准入插件。

集群管理员可以配置一些准入插件来控制某些行为，例如：

使用容器的准入控制器也支持 init 容器。

除了默认的准入控制器外，您还可以使用 准入 webhook 作为准入链的一部分。

准入 webhook 会在创建时调用 webhook 服务器来模拟 pod，如注入标签，或在准入过程中验证 pod 配置的特定方面。

准入 webhook 在资源持久性前截获到 master API 的请求，但在请求被身份验证和授权后。

在 OpenShift Container Platform 中，您可以使用准入 webhook 对象，在 API 准入链中调用 Webhook 服务器。

您可以配置两类准入 Webhook 对象：

配置 webhook 和外部 Webhook 服务器超出了本文档的范围。但是，webhook 必须与一个接口关联才能与 OpenShift Container Platform 正常工作。

当对象实例化时，OpenShift Container Platform 会发出一个 API 调用来接受该对象。在准入过程中，变异准入控制器 可以调用 Webhook 来执行任务，如注入关联性标签。在准入过程结束时，验证准入控制器 可以调用 webhook 来确保正确配置了对象，如验证关联性标签。如果验证通过，OpenShift Container Platform 会按照配置来调度对象。

当 API 请求进入时，变异或验证准入控制器将使用配置中的外部 webhook 列表，并并行调用它们：

准入控制器和 webhook 服务器之间的通信需要使用 TLS 保护。生成 CA 证书并使用证书为 webhook 服务器使用的服务器证书签名。PEM 格式的 CA 证书使用某种机制（如 Service Serving 证书 Secret ）提供给准入控制器。

下图说明了此过程有两个准入 Webhook，它们调用多个 webhook。

准入 Webhook 的一个简单示例用例是资源的各种验证。例如，您有一个基础架构要求所有 pod 都有一组通用的标签，如果 pod 没有这些标签，则您不想保留任何 pod。您可以编写 webhook 来注入这些标签和另一个 Webhook，以验证标签是否存在。然后，OpenShift Container Platform 将调度具有标签的 pod，并传递验证并拒绝因为缺少标签而未通过的 pod。

一些常见用例包括：

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: MutatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace:  5
        name: 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: ValidatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace: default  5
        name: kubernetes 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: ValidatingWebhookConfiguration
  metadata:
    name: namespacereservations.admission.online.openshift.io
  webhooks:
  - name: namespacereservations.admission.online.openshift.io
    clientConfig:
      service:
        namespace: default
        name: webhooks
       path: /apis/admission.online.openshift.io/v1beta1/namespacereservations
      caBundle: KUBE_CA_HERE
    rules:
    - operations:
      - CREATE
      apiGroups:
      - ""
      apiVersions:
      - "b1"
      resources:
      - namespaces
    failurePolicy: Ignore

apiVersion: v1
kind: Pod
metadata:
  labels:
    role: webhook
  name: webhook
spec:
  containers:
    - name: webhook
      image: myrepo/myimage:latest
      imagePullPolicy: IfNotPresent
      ports:
- containerPort: 8000

apiVersion: v1
kind: Service
metadata:
  labels:
    role: webhook
  name: webhook
spec:
  ports:
    - port: 443
      targetPort: 8000
  selector:
role: webhook

限制范围提供了一种机制，可以强制对 Kubernetes 命名空间 中的资源实施 min/max 限制。

通过在命名空间中添加限制范围，您可以强制单个 pod 或容器消耗的最小和最大 CPU 和内存量。

对于 CPU 和内存限值，如果您指定了 max 值，但没有在 LimitRange 对象中指定 min 限制，则资源可能会消耗超过 max 值的 CPU/内存资源。

Kubernetes 可以限制在命名空间 中创建的对象数量，以及 命名空间中 跨对象请求的资源总量。这可通过多个团队（一个命名空间中的每个团队）共享一个 Kubernetes 集群，作为防止一个团队利用另一个集群资源团队的机制。

有关 ResourceQuota 的更多信息，请参阅集群管理。

Kubernetes 资源是 pod 或容器可以请求的、分配给或消耗的 Kubernetes 资源。示例包括内存(RAM)、CPU、磁盘时间和网络带宽。

如需更多信息，请参阅开发人员指南。

Secret 用于存储敏感信息，如密钥、密码和证书。它们可以被相关的 pod 访问，但与它们的定义分开。

持久性卷是由集群管理员置备的基础架构中的对象(PersistentVolume)。持久性卷为有状态应用程序提供持久的存储。

PersistentVolumeClaim 对象是 Pod 作者对存储的请求。Kubernetes 将声明与可用卷池匹配，并将它们绑定到一起。然后，声明被 pod 用作卷。Kubernetes 确保卷与需要它的 pod 位于同一个节点上。

Kubernetes 可确保 pod 能够相互联网，并从内部网络为每个 pod 分配一个 IP 地址。这样可保证 pod 中所有容器的行为如同它们在同一主机上一样。为每个 pod 指定专属的 IP 地址，意味着在端口分配、联网、命名、服务发现、负载均衡、应用程序配置和迁移方面，可以像物理主机或虚拟机一样来对待 pod。

不需要在 pod 间创建链接，我们不推荐使用 IP 地址直接与 pod 进行通信。相反，建议您创建一个服务（service），然后使用服务进行交互。

如果您 运行多个服务 （如用于多个 pod 的前端和后端服务），以使 frontend pod 与后端服务通信，则要为用户名、服务 IP 等创建环境变量。如果删除并重新创建服务，可以为该服务分配一个新的 IP 地址，并且需要重新创建 frontend pod 来获取服务 IP 环境变量的更新值。另外，必须在任何 frontend pod 之前创建后端服务，以确保正确生成服务 IP，并将它作为环境变量提供给 frontend pod。

因此，OpenShift Container Platform 具有一个内置 DNS，以便服务 DNS 以及服务 IP/端口能够访问这些服务。OpenShift Container Platform 支持在回答服务的 DNS 查询的 master 上运行 SkyDNS 来拆分 DNS。默认情况下，主设备侦听端口 53。

当节点启动时，以下消息表示 Kubelet 被正确地解析到 master：

0308 19:51:03.118430    4484 node.go:197] Started Kubelet for node
openshiftdev.local, server at 0.0.0.0:10250
I0308 19:51:03.118459    4484 node.go:199]   Kubelet is setting 10.0.2.15 as a
DNS nameserver for domain "local"

如果没有显示第二条消息，则 Kubernetes 服务可能不可用。

在节点主机上，每个容器的名称服务器都有添加到前端的 master 名称，容器的默认搜索域将是 . < pod_namespace& gt; .cluster.local。容器随后会在节点上的任何其他名称服务器之前将任何名称服务器查询定向到主名称服务器，这是 Docker 格式的容器的默认行为。主控机将在具有以下格式的 .cluster.local 域中应答查询：

这可以防止重启 frontend pod 以便获取新服务，这将为服务创建新 IP。这也无需使用环境变量，因为 pod 可以使用服务 DNS。另外，由于 DNS 不会改变，您也可以将数据库服务引用为 db.local。也支持通配符查找，因为查找会解析到服务 IP，并且无需在任何 frontend pod 之前创建后端服务，因为服务名称（以及 DNS）已提前建立。

此 DNS 结构还包括无头服务，其中门户 IP 没有分配给服务，kube-proxy 不会为其端点提供负载均衡或提供路由。服务 DNS 仍可被使用，并响应多个 A 记录，一个用于服务的每个 pod，允许客户端在每个 Pod 间进行循环。

OpenShift Container Platform 使用软件定义网络 (SDN) 方法来提供一个统一的集群网络，它允许 OpenShift Container Platform 集群中的不同 pod 相互间进行通信。此 pod 网络是由 OpenShift SDN 建立和维护的，它使用 Open vSwitch (OVS) 配置覆盖网络。

OpenShift SDN 提供三个 SDN 插件来配置 pod 网络：

在 OpenShift Container Platform master 上，OpenShift SDN 维护一个节点 registry，存储在 etcd 中。当系统管理员注册节点时，OpenShift SDN 从集群网络分配未使用的子网，并将该子网存储在 registry 中。删除节点时，OpenShift SDN 将从 registry 中删除子网，并考虑重新分配的子网。

在默认配置中，集群网络是 10.128.0.0/14 网络(i.e. 10.128.0.0 - 10.131.255.255)，节点将被分配 /23 子网（如 10.128.0.0/23、10.128.2.0/23、10.128.4.0/23 等）。这意味着集群网络有 512 个子网可用于分配给节点，给定节点分配 510 地址，可分配给其上运行的容器。集群网络的大小和地址范围可以配置，因为 是主机子网大小。

请注意，master 上的 OpenShift SDN 不会配置本地(master)主机来访问任何集群网络。因此，master 主机无法通过集群网络访问 pod，除非它也作为节点运行。

当使用 ovs-multitenant 插件时，OpenShift SDN master 还监视项目的创建和删除，并为它们分配 VXLAN VNID，稍后节点会正确隔离流量。

在节点上，OpenShift SDN 首先在上述 registry 中注册带有 SDN master 的本地主机，以便主节点将子网分配给节点。

接下来，OpenShift SDN 会创建和配置三个网络设备：

每次在主机上启动 pod 时，OpenShift SDN：

OpenShift SDN 节点也从 SDN 主控机监控子网更新。当添加新子网时，节点在 br0 上添加 OpenFlow 规则，以便远程子网中具有目的地 IP 地址的数据包进入 vxlan0 （ br0上的端口 1），然后传输到网络上。ovs-subnet 插件通过 VNID 0 在 VXLAN 间发送所有数据包，但是 ovs-multitenant 插件将适当的 VNID 用于源容器。

假设您有两个容器：A 和 B。其中容器 A 的 eth0 的对等虚拟以太网设备名为 vethA，而容器 B 的 eth0 的对等设备名为 vethB。

现在假定容器 A 存在于本地主机上，容器 B 也在本地主机上。然后，从容器 A 到容器 B 的数据包流如下：

eth0 (A’的 netns) → vethA → br0 → vethB → eth0 (B’的 netns)

接下来，假设容器 A 位于本地主机，容器 B 位于集群网络上的远程主机上。然后，从容器 A 到容器 B 的数据包流如下：

eth0 (in A's netns)→ vethA → br0 → vxlan0 → network ^[1] → vxlan0 → br0 → vethB → eth0 （在 B 的 netns）

最后，如果容器 A 连接到外部主机，流量类似如下：

eth0 （在 A 的 netns） → vethA → br0 → tun0 →(NAT)→ eth0 （物理设备） → Internet

几乎所有数据包交付决策都通过 OVS 网桥 br0 中的 OpenFlow 规则来执行，这简化了插件网络架构并提供灵活的路由。对于 ovs-multitenant 插件，这还提供强制的 网络隔离。

您可以使用 ovs-multitenant 插件来实现网络隔离。当数据包退出分配给非默认项目的 pod 时，OVS 网桥 br0 标签与项目分配的 VNID 的数据包。如果数据包定向到节点集群子网中的另一 IP 地址，OVS 网桥仅允许在 VNID 匹配时将数据包传送到目的地 pod。

如果通过 VXLAN 隧道从另一节点收到数据包，则 Tunnel ID 用作 VNID，并且 OVS 网桥仅允许将数据包传送到本地 pod（如果隧道 ID 与目标 pod 的 VNID 匹配）。

目标为其他集群子网的数据包使用其 VNID 标记，并传送到 VXLAN 隧道上，后者具有拥有集群子网的节点的隧道目标地址。

如前文所述，VNID 0 在那个流量中具有特权，但允许任何 VNID 0 的流量输入任何分配了 VNID 0 的容器集，并且允许 VNID 0 的流量进入任何 pod。只有 default OpenShift Container Platform 项目被分配一个 VNID 0；所有其他项目都被分配了一个唯一的、启用了隔离的 VNID。集群管理员可以选择使用管理员 CLI 控制项目的 pod 网络。

OpenShift SDN 会被默认安装并配置，作为基于 Ansible 的安装过程的一部分。如需更多信息，请参阅 OpenShift SDN 部分。

Kuryr （或更具体为 Kuryr-Kubernetes）是一个使用 CNI 和 OpenStack Neutron 构建的 SDN 解决方案。其优点包括能够使用多种 Neutron SDN 后端，并在 Kubernetes pod 和 OpenStack 虚拟机(VM)之间提供互联性。

Kuryr-Kubernetes 和 OpenShift Container Platform 集成主要针对在 OpenStack 虚拟机上运行的 OpenShift Container Platform 集群设计。

HAProxy 模板路由器实施是模板路由器插件的参考实施。它使用 openshift3/ose-haproxy-router 存储库运行 HAProxy 实例以及模板路由器插件。

模板路由器有两个组件：

控制器和 HAProxy 存储在由部署配置管理的 pod 中。oc adm router 命令自动设置路由器的过程。

控制器监控路由和端点是否有变化，以及 HAProxy 的健康状况。当检测到更改时，它会构建一个新的 haproxy-config 文件并重启 HAProxy。haproxy-config 文件基于路由器的模板文件和 OpenShift Container Platform 的信息构建。

HAProxy 模板文件可以根据需要自定义，以支持 OpenShift Container Platform 当前不支持的功能。HAProxy 手册 描述了 HAProxy 支持的所有功能。

下图显示了如何通过插件处理 master 的数据，最后进入 HAProxy 配置中：

图 5.4. HAProxy 路由器数据流

HAProxy 模板路由器指标

HAProxy 路由器以 Prometheus 格式 公开或发布指标，供外部指标收集和聚合系统（如 Prometheus, statsd）消耗。路由器可以被配置为提供 HAProxy CSV 格式 指标，或者根本不提供路由器指标。

指标从路由器控制器以及 HAProxy 每 5 秒从 HAProxy 收集。当路由器部署并随着时间增加时，路由器指标计数器从零开始。每次重新加载 haproxy 时，HAProxy 指标计数器都会重新设置为零。路由器收集每个 frontend、后端和服务器的 HAProxy 统计信息。为减少资源使用超过 500 台服务器时，将报告后端而非服务器，因为后端可以有多个服务器。

统计信息是 可用 HAProxy 统计 的子集。

以下 HAProxy 指标会定期收集，并转换为 Prometheus 格式。对于每个前端，都会收集"F"计数器。当为每个后端收集计数器并为每个服务器收集"S"服务器计数器时。否则，会为每个后端收集"B"计数器，并且不收集服务器计数器。

如需更多信息，请参阅 路由器环境变量。

在下表中：

栏 1 - HAProxy CSV 统计中的索引

列 2

列 3 - 计数器

列 4 - Counter description

路由器控制器提取下列项目：它们只能通过 Prometheus 格式指标使用。

OpenShift Container Platform 利用内置到 Kubernetes 的功能 来支持转发到 pod 的端口转发。这通过使用 HTTP 和多路流协议（如 SPDY 或 HTTP/2）来实施。

开发人员可以使用 CLI 端口转发至容器集。CLI 侦听用户指定的本地端口，并通过上述协议进行转发。

Kubelet 处理来自客户端的端口转发请求。在收到请求后，它会升级响应并等待客户端创建端口转发流。当它收到新流时，它会在流和 pod 端口之间复制数据。

从架构上看，有不同的选项可用于转发到 pod 端口。OpenShift Container Platform 中支持的实现当前直接调用节点主机上的 nsenter 来进入 pod 的网络命名空间，然后调用 socat 在流和 pod 端口之间复制数据。但是，自定义实现可能会包括运行一个 "helper" pod，然后运行 nsenter 和 socat，因此不需要在主机上安装这些二进制文件。

OpenShift Container Platform 利用 Kubernetes 中内置的功能来支持在容器中执行命令。这通过使用 HTTP 和多路流协议（如 SPDY 或 HTTP/2）来实施。

开发人员可以使用 CLI 在容器中执行远程命令。

Kubelet 处理来自客户端的远程执行请求。在收到请求后，它会升级响应，评估请求标头来确定要接收哪些流（stdin、stdout 和/或 stderr）来预期接收并等待客户端创建流。

在 Kubelet 收到所有流后，它会执行容器中的命令，根据情况在流和命令 stdin、stdout 和 stderr 之间复制。当命令终止时，Kubelet 关闭升级的连接以及底层的连接。

从架构上讲，容器中运行命令有不同的选项。在 OpenShift Container Platform 中当前支持的实现人员直接在节点主机上调用 nsenter，以在执行 命令前输入容器的命名空间。但是，自定义实现可能会包括使用 docker exec，或运行一个 "helper" 容器，然后运行 nsenter，以便 nsenter 不是必须在主机上安装的所需二进制文件。

OpenShift Container Platform 路由以主机名（如 www.example.com ）公开一个服务，以便外部客户端可根据名称访问该服务。

主机名的 DNS 解析是独立于路由处理的。您的管理员可能已配置了 DNS 通配符条目，该条目 将解析到运行 OpenShift Container Platform 路由器的 OpenShift Container Platform 节点。如果您使用不同的主机名，您可能需要单独修改其 DNS 记录，以解析为运行路由器的节点。

每个路由都由一个名称（最多 63 个字符）、服务选择器和可选安全配置组成。

OpenShift Container Platform 管理员可以将 路由器 部署到 OpenShift Container Platform 集群中的节点，它 允许开发人员创建的路由 供外部客户端使用。OpenShift Container Platform 中的路由层是可插拔的，默认提供了几个路由器插件。

路由器使用服务选择器来查找服务，以及支持该服务的端点。当路由器和服务提供负载均衡时，OpenShift Container Platform 会使用路由器负载均衡。路由器在其服务的 IP 地址中检测到相关的更改，并相应地调整其配置。这可用于自定义路由器，将 API 对象的修改传递给外部路由解决方案。

请求的路径以 DNS 解析到一个或多个路由器的主机名开始。建议的方法定义一个指向多个路由器实例支持的一个或多个虚拟 IP(VIP)地址的通配符 DNS 条目的云域。使用云域之外的名称和地址的路由需要配置单独的 DNS 条目。

当 VIP 地址少于路由器时，与地址数量对应的路由器 处于活跃状态，其余是 被动 的。被动路由器也被称为 热子路由器。例如，有两个 VIP 地址和三个路由器，您有一个 "active-active-passive" 配置。有关路由器 VIP 配置的更多信息，请参阅 高可用性。

路由可以在 一组 路由器间分片。管理员可以基于集群范围设置分片，用户可在其项目中为命名空间设置分片。分片( sharding)使得操作员能够定义多个路由器组。组中的每个路由器仅提供流量子集。

OpenShift Container Platform 路由器通过协议提供外部主机名映射和服务的负载平衡，这些协议可直接区分信息到路由器；路由器必须存在于协议中以确定要发送的位置。

路由器插件假设它们默认可以绑定到主机端口 80(HTTP)和 443(HTTPS)。这意味着路由器必须放在不其他使用这些端口的节点上。或者，可通过设置 ROUTER_SERVICE_ HTTP_PORT 和 ROUTER_SERVICE _HTTPS_PORT 环境变量将路由器配置为侦听其他端口。

由于路由器绑定到主机节点上的端口，因此如果路由器使用主机网络（默认值），则每个节点上仅能侦听这些端口的路由器。配置了集群网络，以便所有路由器可以访问集群中的所有 pod。

路由器支持以下协议：

要建立安全连接，必须协商与客户端和服务器通用的 密码。随着时间推移，新的安全的密码将变得可用，并集成到客户端软件中。当旧的客户端已过时时，可以丢弃旧的安全密码。默认情况下，路由器支持广泛的可用客户端。路由器可以配置为使用支持所需客户端的所选密码集合，不包括不太安全的密码。

如需 已验证的可用路由器插件，请参阅可用的路由器插件部分。

部署路由器时提供了有关部署这些 路由器的说明。

实施粘性会话取决于底层路由器配置。默认 HAProxy 模板使用 balance source 指令实施粘性会话，该指令根据源 IP 平衡。另外，模板路由器插件为底层实施提供服务名称和命名空间。这可用于更高级的配置，例如实施在同级服务器集合之间同步的记忆程序。

粘性会话可确保来自用户会话的所有流量都进入同一 pod，从而创建更好的用户体验。虽然满足用户的请求，但 pod 会缓存数据，它们可用于后续请求。例如，对于具有五个后端 pod 和两个负载均衡的路由器的集群，您可以确保同一 pod 从同一 Web 浏览器接收 Web 流量，而不考虑处理它的路由器。

虽然需要将路由流量返回到同一 pod，但无法保证它。但是，您可以使用 HTTP 标头设置 Cookie 来确定上一次连接中使用的 pod。当用户向应用发送另一请求时，浏览器会重新发送 Cookie 和路由器知道将流量发送到何处。

集群管理员可以关闭 passthrough 路由与其他连接分开的粘性，或者完全关闭粘性。

默认情况下，直通路由的粘性会话使用 source 负载均衡策略来实施。可以修改所有透传路由的默认，使用 ROUTER_TCP_BALANCE_SCHEME环境变量，对于独立的路由，使用 haproxy.router.openshift.io/balance 特定于路由的注解。

其他类型的路由默认使用 leastconn 负载均衡策略，可以使用 ROUTER_LOAD_BALANCE_ALGORITHM 环境变量 进行修改。可以使用 haproxy.router.openshift.io/balance 特定于路由的注解，可以修改单个路由。

另外，模板路由器插件为底层实施提供服务名称和命名空间。这可用于更高级的配置，例如实施在同级服务器集合之间同步的粘性程序。

此路由器实施的具体配置存储在路由器容器的 /var/lib/haproxy/conf 目录中的 haproxy-config.template 文件中。文件 可以自定义。

对于本节中列出的所有项目，您可以在路由器部署配置中设置环境变量以更改其配置，或使用 oc set env 命令：

$ oc set env <object_type>/<object_name> KEY1=VALUE1 KEY2=VALUE2

例如：

$ oc set env dc/router ROUTER_SYSLOG_ADDRESS=127.0.0.1 ROUTER_LOG_LEVEL=debug