- OpenShift 教程
- OpenShift - 首页
- OpenShift - 概述
- OpenShift - 类型
- OpenShift - 架构
- OpenShift - 环境设置
- OpenShift - 基本概念
- OpenShift - 入门
- OpenShift - 自动构建
- OpenShift - CLI
- OpenShift - CLI 操作
- OpenShift - 集群
- OpenShift - 应用伸缩
- OpenShift - 管理
- OpenShift - Docker 和 Kubernetes
- OpenShift - 安全性
- OpenShift 有用资源
- OpenShift 快速指南
- OpenShift - 有用资源
- OpenShift - 讨论
OpenShift 快速指南
OpenShift - 概述
OpenShift 是一个由 Red Hat 托管的云开发平台即服务 (PaaS)。它是一个开源的基于云的、用户友好的平台，用于创建、测试和运行应用程序，并最终将其部署到云中。
OpenShift 能够管理用不同语言编写的应用程序，例如 Node.js、Ruby、Python、Perl 和 Java。OpenShift 的关键特性之一是它具有可扩展性，这有助于用户支持用其他语言编写的应用程序。
OpenShift 带有各种虚拟化概念作为其抽象层。OpenShift 背后的基本概念是基于虚拟化的。
虚拟化
一般来说，虚拟化可以定义为创建虚拟系统，而不是任何事物的物理或实际版本，从系统、存储或操作系统开始。虚拟化的主要目标是使 IT 基础设施更具可扩展性和可靠性。虚拟化的概念已经存在了几十年，并且随着当今 IT 行业的发展，它可以应用于从系统级、硬件级到服务器级虚拟化的广泛层级。
工作原理
它可以描述为一种技术，其中任何应用程序或操作系统都与其实际物理层分离。虚拟化技术的关键用途之一是服务器虚拟化，它使用称为管理程序的软件从底层硬件中抽象出层。在虚拟化上运行的操作系统的性能与在物理硬件上运行时一样好。但是，虚拟化的概念很流行，因为大多数运行的系统和应用程序不需要使用底层硬件。
物理架构与虚拟架构
虚拟化类型
应用程序虚拟化 - 在此方法中，应用程序与底层操作系统分离。此方法非常有用，因为可以在隔离环境中运行应用程序，而无需依赖底层操作系统。
桌面虚拟化 - 此方法用于减少工作站负载，其中用户可以使用桌面上的瘦客户端远程访问桌面。在此方法中，桌面主要在数据中心运行。一个典型的例子可以是虚拟桌面映像 (VDI)，它在大多数组织中使用。
数据虚拟化 - 它是抽象化并摆脱传统数据和数据管理方法的一种方法。
服务器虚拟化 - 在此方法中，与服务器相关的资源被虚拟化，包括物理服务器、进程和操作系统。启用此抽象的软件通常称为管理程序。
存储虚拟化 - 它是将多个存储设备合并到一个存储设备中的过程，该存储设备由单个中央控制台管理。
网络虚拟化 - 它是将所有可用网络资源组合起来的方法，方法是将可用带宽和通道分成多个部分，每个部分彼此独立。
OpenShift
OpenShift 是一个支持云的应用程序平台即服务 (PaaS)。它是一种开源技术，可帮助组织将其传统的应用程序基础设施和平台从物理、虚拟媒介迁移到云中。
OpenShift 支持各种各样的应用程序，这些应用程序可以轻松地开发和部署在 OpenShift 云平台上。OpenShift 主要为开发人员和用户提供三种平台。
基础设施即服务 (IaaS)
在此格式中，服务提供商提供具有某些预定义虚拟硬件配置的硬件级虚拟机。在这个领域有多个竞争对手，从 AWS 谷歌云、Rackspace 等开始。
在经过漫长的设置和投资过程后，使用 IaaS 的主要缺点是，您仍然负责安装和维护操作系统和服务器软件包、管理基础设施网络以及处理基本的系统管理。
软件即服务 (SaaS)
使用 SaaS，您无需担心底层基础设施。它就像即插即用一样简单，用户只需注册服务即可开始使用。此设置的主要缺点是，用户只能执行服务提供商允许的少量自定义。SaaS 最常见的例子是 Gmail，用户只需登录即可开始使用。用户还可以对其帐户进行一些小的修改。但是，从开发人员的角度来看，它不是很有用。
平台即服务 (PaaS)
它可以被视为 SaaS 和 IaaS 之间的中间层。PaaS 评估的主要目标是开发人员，他们可以在其中使用一些命令启动开发环境。这些环境的设计方式是为了满足所有开发需求，从拥有带数据库的 Web 应用程序服务器开始。要做到这一点，您只需要一个命令，服务提供商就会为您完成所有工作。
为什么要使用 OpenShift？
OpenShift 为企业单位提供了一个通用平台，可以在云上托管其应用程序，而无需担心底层操作系统。这使得在云上使用、开发和部署应用程序变得非常容易。关键特性之一是，它为各种开发和测试提供托管的硬件和网络资源。使用 OpenShift，PaaS 开发人员可以自由设计其所需的环境及其规范。
OpenShift 在服务计划方面提供了不同类型的服务级别协议。
免费 - 此计划限于三年，每个计划 1GB 空间。
青铜 - 此计划包含 3 年，最多可扩展至 16 年，每年 1GB 空间。
银 - 这是青铜的 16 年计划，但是存储容量为 6GB，无需额外费用。
除了上述功能外，OpenShift 还提供名为 OpenShift Enterprise 的本地版本。在 OpenShift 中，开发人员可以利用设计可扩展和不可扩展的应用程序，这些设计使用 HAproxy 服务器实现。
特性
OpenShift 支持多种功能。其中一些是 -
- 多语言支持
- 多数据库支持
- 可扩展的 Cartridge 系统
- 源代码版本管理
- 一键部署
- 多环境支持
- 标准化的开发人员工作流程
- 依赖项和构建管理
- 自动应用程序扩展
- 响应式 Web 控制台
- 丰富的命令行工具集
- 远程 SSH 登录到应用程序
- Rest API 支持
- 自助式按需应用程序堆栈
- 内置数据库服务
- 持续集成和发布管理
- IDE 集成
- 应用程序的远程调试
OpenShift - 类型
OpenShift 诞生于其名为 OpenShift V2 的基础，该基础主要基于年和 Cartridge 的概念，其中每个组件都有其规范，从机器创建到应用程序部署，从构建到部署应用程序。
Cartridge - 它们是构建新应用程序的焦点，从应用程序类型到环境运行它们所需的依赖项，都在此部分满足。
年 - 它可以定义为具有关于资源、内存和 CPU 的某些规范的裸机或服务器。它们被认为是运行应用程序的基本单元。
应用程序 - 这些仅指将在 OpenShift 环境中部署和运行的应用程序或任何集成应用程序。
随着我们深入本节，我们将讨论 OpenShift 的不同格式和产品。在早期，OpenShift 有三个主要版本。
OpenShift Origin - 这是 OpenShift 的社区版本或开源版本。它也被称为其他两个版本的的上游项目。
OpenShift Online - 它是在 AWS 上托管的公共 PaaS 即服务。
OpenShift Enterprise - 是 OpenShift 的强化版本，具有 ISV 和供应商许可证。
OpenShift Online
OpenShift Online 是 OpenShift 社区的产物，用户可以使用它在公共云上快速构建、部署和扩展容器化应用程序。它是 Red Hat 的公共云应用程序开发和托管平台，它支持应用程序的自动化供应、管理和扩展，帮助开发人员专注于编写应用程序逻辑。
在 Red Hat OpenShift Online 上设置帐户
步骤 1 - 打开浏览器并访问网站 https://manage.openshift.com/
步骤 2 - 如果您有 Red Hat 帐户，请使用以下 URL 使用 Red Hat 登录 ID 和密码登录 OpenShift 帐户。 https://developers.redhat.com
步骤 3 - 如果您没有 Red Hat 帐户登录，请使用以下链接注册 OpenShift 在线服务。
登录后，您将看到以下页面。
一旦您准备就绪，Red Hat 将显示一些基本帐户详细信息，如下面的屏幕截图所示。
最后，登录后，您将看到以下页面。
OpenShift 容器平台
OpenShift 容器平台是一个企业级平台，它帮助多个团队（例如开发团队和 IT 运维团队）构建和部署容器化基础设施。所有在 OpenShift 中构建的容器都使用非常可靠的 Docker 容器化技术，可以部署在任何数据中心或公开托管的云平台上。
OpenShift 容器平台以前称为 OpenShift 企业版。它是一个基于 Red Hat 的本地私有平台即服务，构建于以 Docker 为动力的应用程序容器的核心概念之上，其中编排和管理由 Kubernetes 负责。
换句话说，OpenShift 将 Docker 和 Kubernetes 集成到企业级。它是一个容器平台软件，供企业单位在其选择的架构中部署和管理应用程序。例如，在 AWS 实例上托管 OpenShift 实例。
OpenShift 容器平台提供 **两种软件包级别**。
**OpenShift 容器本地版** - 适用于希望在本地机器上部署和测试应用程序的开发人员。此软件包主要由开发团队用于开发和测试应用程序。
**OpenShift 容器实验室版** - 旨在扩展应用程序评估，从开发到部署到预生产环境。
OpenShift 专属版
这是添加到 OpenShift 产品组合中的另一个产品，其中客户可以选择在其选择的任何公共云上托管容器化平台。这为最终用户提供了真正的多云产品体验，他们可以在满足其需求的任何云上使用 OpenShift。
这是 Red Hat 最新的产品之一，最终用户可以使用 OpenShift 在托管在云上的 OpenShift 上构建、测试、部署和运行其应用程序。
OpenShift 专属版的功能
OpenShift 专属版在公共云上提供定制的解决方案应用程序平台，并且继承自 OpenShift 3 技术。
**可扩展和开放** - 因为它基于 Docker 的开放概念并在云上部署，因此可以根据需要扩展自身。
**可移植性** - 由于它使用 Docker 构建，因此在 Docker 上运行的应用程序可以轻松地从一个地方运送到另一个支持 Docker 的地方。
**编排** - 使用 OpenShift 3，容器编排和集群管理的关键功能之一是通过 Kubernetes 支持的，Kubernetes 是从 OpenShift 版本 3 开始提供的。
**自动化** - 此版本的 OpenShift 启用了源代码管理、构建自动化和部署自动化功能，使其在市场上作为平台即服务提供商非常受欢迎。
OpenShift 的竞争对手
**Google App Engine** - 这是 Google 用于开发和托管 Web 应用程序的免费平台。Google 的 App Engine 提供快速开发和部署平台。
**Microsoft Azure** - Azure 云由 Microsoft 在其数据中心托管。
**Amazon Elastic Cloud Compute** - 它们是 Amazon 提供的内置服务，有助于在云上开发和托管可扩展的 Web 应用程序。
**Cloud Foundry** - 是一个开源 PaaS 平台，用于 Java、Ruby、Python 和 Node.js 应用程序。
**CloudStack** - Apache 的 CloudStack 是 Citrix 开发的一个项目，旨在成为 OpenShift 和 OpenStack 的直接竞争对手。
**OpenStack** - Red Hat 提供的另一种用于云计算的云技术。
**Kubernetes** - 它是一种直接的编排和集群管理技术，旨在管理 Docker 容器。
OpenShift - 架构
OpenShift 是一个分层系统，其中每一层都使用 Kubernetes 和 Docker 集群与其他层紧密绑定。OpenShift 的架构设计为能够支持和管理 Docker 容器，这些容器使用 Kubernetes 托管在所有层之上。与早期的 OpenShift V2 版本不同，新的 OpenShift V3 版本支持容器化基础设施。在此模型中，Docker 帮助创建轻量级的基于 Linux 的容器，而 Kubernetes 支持在多个主机上编排和管理容器的任务。
OpenShift 的组件
OpenShift 架构的关键组件之一是在 Kubernetes 中管理容器化基础设施。Kubernetes 负责基础设施的部署和管理。在任何 Kubernetes 集群中，我们都可以拥有多个主节点和多个工作节点，从而确保设置中没有单点故障。
Kubernetes 主节点组件
**etcd** - 它存储配置信息，集群中的每个节点都可以使用这些信息。它是一个高可用性的键值存储，可以在多个节点之间分布。它只能由 Kubernetes API 服务器访问，因为它可能包含敏感信息。它是一个分布式的键值存储，所有节点都可以访问。
**API 服务器** - Kubernetes 是一个 API 服务器，它使用 API 提供集群上的所有操作。API 服务器实现了一个接口，这意味着不同的工具和库可以轻松地与之通信。kubeconfig 是一个与服务器端工具一起提供的软件包，可用于通信。它公开了 Kubernetes API”。
**控制器管理器** - 此组件负责大多数调节集群状态并执行任务的控制器。它可以被认为是一个在非终止循环中运行的守护进程，负责收集信息并将其发送到 API 服务器。它致力于获取集群的共享状态，然后进行更改以将服务器的当前状态更改为所需状态。关键控制器包括复制控制器、端点控制器、命名空间控制器和服务帐户控制器。控制器管理器运行不同类型的控制器来处理节点、端点等。
**调度器** - 它是 Kubernetes 主节点的关键组件。它是在主节点中负责分配工作负载的服务。它负责跟踪集群节点上的工作负载利用率，然后将工作负载放置在具有可用资源并接受工作负载的节点上。换句话说，这是负责将 Pod 分配给可用节点的机制。调度器负责工作负载利用率并将 Pod 分配给新的节点。
Kubernetes 工作节点组件
以下是工作节点服务器的关键组件，它们对于与 Kubernetes 主节点通信是必需的。
**Docker** - 每个节点的第一个要求是 Docker，它有助于在相对隔离但轻量级的操作环境中运行封装的应用程序容器。
**Kubelet 服务** - 这是每个节点中的一项小型服务，负责在控制平面服务之间中继信息。它与 etcd 存储交互以读取配置详细信息并写入值。它与主节点组件通信以接收命令和工作。然后，kubelet 进程承担维护工作状态和节点服务器状态的责任。它管理网络规则、端口转发等。
**Kubernetes 代理服务** - 这是一项在每个节点上运行的代理服务，有助于使服务可供外部主机使用。它有助于将请求转发到正确的容器。Kubernetes 代理服务能够执行基本的负载均衡。它确保网络环境是可预测且可访问的，但同时也是隔离的。它管理节点上的 Pod、卷、密钥、创建新的容器健康检查等。
集成的 OpenShift 容器注册表
OpenShift 容器注册表是 Red Hat 的内置存储单元，用于存储 Docker 镜像。随着 OpenShift 最新集成版本的推出，它提供了一个用户界面来查看 OpenShift 内部存储中的镜像。这些注册表能够保存带有指定标签的镜像，这些镜像稍后将用于从中构建容器。
常用术语
**镜像** - Kubernetes（Docker）镜像是容器化基础设施的关键构建块。目前，Kubernetes 仅支持 Docker 镜像。Pod 中的每个容器在其内部运行其 Docker 镜像。在配置 Pod 时，配置文件中的镜像属性与 Docker 命令具有相同的语法。
**项目** - 它们可以定义为在早期版本的 OpenShift V2 中存在的域的重命名版本。
**容器** - 它们是在镜像部署到 Kubernetes 集群节点后创建的。
**节点** - 节点是 Kubernetes 集群中的工作机器，也称为主节点的从属节点。它们是工作单元，可以是物理机、虚拟机或云实例。
**Pod** - Pod 是 Kubernetes 集群节点中容器及其存储的集合。可以创建一个包含多个容器的 Pod。例如，将数据库容器和 Web 服务器容器保留在 Pod 内。
OpenShift - 环境设置
在本章中，我们将学习 OpenShift 的环境设置。
系统要求
为了设置企业级 OpenShift，需要拥有一个有效的 Red Hat 帐户。由于 OpenShift 在 Kubernetes 主节点和工作节点架构上运行，因此我们需要在不同的机器上设置它们，其中一台机器充当主节点，另一台机器充当工作节点。为了设置两者，有一些最低系统要求。
主节点配置
以下是主节点配置的最低系统要求。
在物理机、虚拟机或任何云环境中托管的基础机器。
至少 Linux 7 及其所需的软件包。
2 个 CPU 内核。
至少 8 GB RAM。
30 GB 的内部硬盘存储空间。
工作节点配置
- 与主节点相同的物理或虚拟基础镜像。
- 机器上至少安装 Linux 7。
- 安装 Docker，版本不低于 1.6。
- 1 个 CPU 内核。
- 8 GB RAM。
- 15 GB 硬盘用于托管镜像，15 GB 用于存储镜像。
OpenShift 设置的分步指南
在以下说明中，我们将设置 OpenShift 实验室环境，该环境可以稍后扩展到更大的集群。由于 OpenShift 需要主节点和工作节点设置，因此我们需要至少两台机器托管在云、物理机或虚拟机上。
**步骤 1** - 首先在两台机器上安装 Linux，其中 Linux 7 应为最低版本。如果拥有有效的 Red Hat 订阅，则可以使用以下命令完成此操作。
# subscription-manager repos --disable = "*"
# subscription-manager repos --enable = "rhel-7-server-rpms"
# subscription-manager repos --enable = "rhel-7-server-extras-rpms"
# subscription-manager repos --enable = "rhel-7-server-optional-rpms"
# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"
# yum install wget git net-tools bind-utils iptables-services bridge-utils
# yum install wget git net-tools bind-utils iptables-services bridge-utils
# yum install python-virtualenv
# yum install gcc
# yum install httpd-tools
# yum install docker
# yum update
在两台机器上安装了所有上述基本软件包后，下一步将在相应的机器上设置 Docker。
**步骤 2** - 配置 Docker，使其仅允许在本地网络上进行不安全的通信。为此，编辑 /etc/sysconfig 内的 Docker 文件。如果文件不存在，则需要手动创建它。
# vi /etc/sysconfig/docker OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24
在主节点上配置 Docker 后，我们需要设置两台机器之间的无密码通信。为此，我们将使用公钥和私钥身份验证。
**步骤 3** - 在主节点上生成密钥，然后将 id_rsa.pub 密钥复制到工作节点的 authorized_keys 文件中，这可以通过以下命令完成。
# ssh-keygen
# ssh-copy-id -i .ssh/id_rsa.pub [email protected]
完成上述所有设置后，接下来是在主节点上设置 OpenShift 版本 3。
步骤 4 − 在主节点机器上，运行以下 curl 命令。
# sh <(curl -s https://install.openshift.com/ose)
以上命令将为 OSV3 设置环境。下一步是在机器上配置 OpenShift V3。
如果您无法直接从互联网下载，则可以从 https://install.openshift.com/portable/oo-install-ose.tgz 下载为 tar 包，安装程序可以在本地主节点机器上运行。
一旦我们准备好设置，那么我们需要开始在机器上实际配置 OSV3。此设置非常具体，用于测试实际生产环境，我们已经配置了 LDAP 和其他内容。
步骤 5 − 在主节点机器上，配置位于 /etc/openshift/master/master-config.yaml 下面的以下代码。
# vi /etc/openshift/master/master-config.yaml identityProviders: - name: my_htpasswd_provider challenge: true login: true provider: apiVersion: v1 kind: HTPasswdPasswordIdentityProvider file: /root/users.htpasswd routingConfig: subdomain: testing.com
接下来，创建一个标准用户用于默认管理。
# htpasswd -c /root/users.htpasswd admin
步骤 6 − 由于 OpenShift 使用 Docker 镜像仓库来配置镜像，我们需要配置 Docker 镜像仓库。它用于在构建后创建和存储 Docker 镜像。
使用以下命令在 OpenShift 节点机器上创建一个目录。
# mkdir /images
接下来，使用默认的管理员凭据登录主节点机器，这些凭据在设置镜像仓库时创建。
# oc login Username: system:admin
切换到默认创建的项目。
# oc project default
步骤 7 − 创建一个 Docker 镜像仓库。
#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -
编辑用户权限。
#oc edit scc privileged users: - system:serviceaccount:openshift-infra:build-controller - system:serviceaccount:default:registry
创建和编辑镜像仓库。
#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images
步骤 8 − 创建默认路由。
默认情况下，OpenShift 使用 OpenVswitch 作为软件网络。使用以下命令创建默认路由。它用于负载均衡和代理路由。路由器类似于 Docker 镜像仓库，也运行在镜像仓库中。
# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -
接下来，编辑用户的权限。
#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'
步骤 9 − 配置 DNS。
为了处理 URL 请求，OpenShift 需要一个可用的 DNS 环境。此 DNS 配置需要创建一个通配符，该通配符用于创建指向路由器的 DNS 通配符。
# yum install bind-utils bind
# systemctl start named
# systemctl enable named
vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
10.38.55.13;
;
};
zone "lab.com" IN {
type master;
file "/var/named/dynamic/test.com.zone";
allow-update { none; };
};
步骤 10 − 最后一步是在 OpenShift V3 主节点机器上设置 github 服务器，这是可选的。这可以通过以下命令序列轻松完成。
#yum install curl openssh-server
#systemctl enable sshd
# systemctl start sshd
# firewall-cmd --permanent --add-service = http
# systemctl reload firewalld
#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-
#yum install gitlab-ce
# gitlab-ctl reconfigure
完成以上设置后，您可以通过测试和部署应用程序进行验证，我们将在后续章节中详细了解。
OpenShift - 基本概念
在开始实际设置和部署应用程序之前，我们需要了解 OpenShift V3 中使用的一些基本术语和概念。
容器和镜像
镜像
这些是 OpenShift 的基本构建块，由 Docker 镜像构成。在 OpenShift 上的每个 Pod 中，集群都有自己的镜像在其内部运行。当我们配置 Pod 时，我们有一个字段将从镜像仓库中提取。此配置文件将拉取镜像并在集群节点上部署它。
apiVersion: v1
kind: pod
metadata:
name: Tesing_for_Image_pull -----------> Name of Pod
spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull
为了拉取并从中创建一个镜像，请运行以下命令。OC 是在登录后与 OpenShift 环境通信的客户端。
$ oc create –f Tesing_for_Image_pull
容器
当 Docker 镜像部署到 OpenShift 集群时，就会创建容器。在定义任何配置时，我们在配置文件中定义容器部分。一个容器可以有多个镜像在其内部运行，并且集群节点上运行的所有容器都由 OpenShift Kubernetes 管理。
spec: containers: - name: py ------------------------> Name of the container image: python----------> Image going to get deployed on container command: [“python”, “SUCCESS”] restartPocliy: Never --------> Restart policy of container
以下是定义包含多个镜像运行的容器的规范。
apiVersion: v1
kind: Pod
metadata:
name: Tomcat
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Always
-name: Database
Image: mongoDB
Ports:
- containerPort: 7501
imagePullPolicy: Always
在以上配置中，我们定义了一个多容器 Pod，其中包含两个 Tomcat 和 MongoDB 镜像。
Pod 和服务
Pod
Pod 可以定义为 OpenShift (Kubernetes) 集群节点内容器及其存储的集合。通常，我们有两种类型的 Pod，从单容器 Pod 到多容器 Pod。
单容器 Pod − 这些可以通过 OC 命令或基本的配置文件轻松创建。
$ oc run <name of pod> --image = <name of the image from registry>
使用以下简单的 yaml 文件创建它。
apiVersion: v1
kind: Pod
metadata:
name: apache
spec:
containers:
- name: apache
image: apache: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Always
创建上述文件后，它将使用以下命令生成一个 Pod。
$ oc create –f apache.yml
多容器 Pod − 多容器 Pod 是那些在其内部运行多个容器的 Pod。它们使用 yaml 文件创建，如下所示。
apiVersion: v1
kind: Pod
metadata:
name: Tomcat
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Always
-name: Database
Image: mongoDB
Ports:
- containerPort: 7501
imagePullPolicy: Always
创建这些文件后，我们可以简单地使用与上面相同的方法来创建容器。
服务 − 正如我们有一组容器在 Pod 内运行一样，我们也有一个服务，可以将其定义为 Pod 的逻辑集合。它是 Pod 之上的一个抽象层，它提供一个单一的 IP 和 DNS 名称，通过该名称可以访问 Pod。服务有助于管理负载均衡配置并非常轻松地扩展 Pod。在 OpenShift 中，服务是一个 REST 对象，其定义可以发布到 OpenShift 主节点上的 apiService 以创建新实例。
apiVersion: v1
kind: Service
metadata:
name: Tutorial_point_service
spec:
ports:
- port: 8080
targetPort: 31999
构建和流
构建
在 OpenShift 中，构建是将镜像转换为容器的过程。它是将源代码转换为镜像的过程。此构建过程基于预定义的策略将源代码构建为镜像。
构建处理多种策略和源。
构建策略
源到镜像 − 这基本上是一个工具，它有助于构建可重现的镜像。这些镜像始终处于就绪状态，可以使用 Docker run 命令运行。
Docker 构建 − 这是使用 Dockerfile 通过运行简单的 Docker build 命令构建镜像的过程。
自定义构建 − 这些是用于创建基本 Docker 镜像的构建。
构建源
Git − 当使用 git 仓库构建镜像时，使用此源。Dockerfile 是可选的。源代码中的配置如下所示。
source: type: "Git" git: uri: "https://github.com/vipin/testing.git" ref: "master" contextDir: "app/dir" dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"
Dockerfile − Dockerfile 用作配置文件中的输入。
source: type: "Dockerfile" dockerfile: "FROM ubuntu: latest RUN yum install -y httpd"
镜像流 − 拉取镜像后创建镜像流。镜像流的优点是它会查找新版本镜像的更新。它用于比较由标签标识的任意数量的 Docker 格式的容器镜像。
镜像流可以在创建新镜像时自动执行操作。所有构建和部署都可以监视镜像操作并相应地执行操作。以下是我们如何定义构建流。
apiVersion: v1
kind: ImageStream
metadata:
annotations:
openshift.io/generated-by: OpenShiftNewApp
generation: 1
labels:
app: ruby-sample-build
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
tags:
- items:
- created: 2016-01-29T13:40:11Z
dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
generation: 1
image: vklnld908.int.clsa.com/vipin/test
tag: latest
路由和模板
路由
在 OpenShift 中，路由是一种通过创建和配置外部可访问的主机名来将服务暴露给外部世界的方法。路由和端点用于将服务暴露给外部世界，用户可以从中使用名称连接（DNS）访问定义的应用程序。
在 OpenShift 中，路由是通过 OpenShift 管理员在集群上部署的路由器创建的。路由器用于将 HTTP (80) 和 https (443) 端口绑定到外部应用程序。
以下是路由支持的不同类型的协议 −
- HTTP
- HTTPS
- TSL 和 Websocket
在配置服务时，选择器用于配置服务并使用该服务查找端点。以下是如何使用适当的协议创建服务及其路由的示例。
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {"name": "Openshift-Rservice"},
"spec": {
"selector": {"name":"RService-openshift"},
"ports": [
{
"protocol": "TCP",
"port": 8888,
"targetPort": 8080
}
]
}
}
接下来，运行以下命令，服务将创建。
$ oc create -f ~/training/content/Openshift-Rservice.json
这是创建后服务的样子。
$ oc describe service Openshift-Rservice Name: Openshift-Rservice Labels: <none> Selector: name = RService-openshift Type: ClusterIP IP: 172.30.42.80 Port: <unnamed> 8080/TCP Endpoints: <none> Session Affinity: None No events.
使用以下代码为服务创建路由。
{
"kind": "Route",
"apiVersion": "v1",
"metadata": {"name": "Openshift-service-route"},
"spec": {
"host": "hello-openshift.cloudapps.example.com",
"to": {
"kind": "Service",
"name": "OpenShift-route-service"
},
"tls": {"termination": "edge"}
}
}
当使用 OC 命令创建路由时，将创建一个新的路由资源实例。
模板
模板在 OpenShift 中定义为一个标准对象，可以多次使用。它使用占位符列表进行参数化，这些占位符用于创建多个对象。它可以用于创建任何内容，从 Pod 到网络，用户有权创建。如果来自 CLI 或 GUI 界面中的镜像的模板上传到项目目录，则可以创建对象列表。
apiVersion: v1
kind: Template
metadata:
name: <Name of template>
annotations:
description: <Description of Tag>
iconClass: "icon-redis"
tags: <Tages of image>
objects:
- apiVersion: v1
kind: Pod
metadata:
name: <Object Specification>
spec:
containers:
image: <Image Name>
name: master
ports:
- containerPort: <Container port number>
protocol: <Protocol>
labels:
redis: <Communication Type>
身份验证和授权
身份验证
在 OpenShift 中，在配置主节点和客户端结构时，主节点自带 OAuth 服务器的功能。OAuth 服务器用于生成令牌，该令牌用于对 API 进行身份验证。由于 OAuth 是主节点的默认设置，因此我们默认使用“允许所有”身份提供程序。存在不同的身份提供程序，可以在 /etc/openshift/master/master-config.yaml 中进行配置。
OAuth 中存在不同类型的身份提供程序。
- 允许所有
- 拒绝所有
- HTPasswd
- LDAP
- 基本身份验证
允许所有
apiVersion: v1
kind: Pod
metadata:
name: redis-master
spec:
containers:
image: dockerfile/redis
name: master
ports:
- containerPort: 6379
protocol: TCP
oauthConfig:
identityProviders:
- name: my_allow_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
拒绝所有
apiVersion: v1
kind: Pod
metadata:
name: redis-master
spec:
containers:
image: dockerfile/redis
name: master
ports:
- containerPort: 6379
protocol: TCP
oauthConfig:
identityProviders:
- name: my_allow_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HTPasswd
为了使用 HTPasswd，我们需要首先在主节点机器上设置 Httpd-tools，然后以与其他身份提供程序相同的方式进行配置。
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
授权
授权是 OpenShift 主节点的一项功能，用于验证用户。这意味着它会检查尝试执行操作的用户，以查看该用户是否有权对给定项目执行该操作。这有助于管理员控制对项目的访问。
授权策略使用以下内容进行控制 −
- 规则
- 角色
- 绑定
授权评估使用以下内容进行 −
- 身份
- 操作
- 绑定
使用策略 −
- 集群策略
- 本地策略
OpenShift - 入门
OpenShift 包含两种创建和部署应用程序的方法，可以通过 GUI 或 CLI。在本章中，我们将使用 CLI 创建一个新应用程序。我们将使用 OC 客户端与 OpenShift 环境通信。
创建新应用程序
在 OpenShift 中，有三种创建新应用程序的方法。
- 从源代码
- 从镜像
- 从模板
从源代码
当我们尝试从源代码创建应用程序时，OpenShift 会查找应该存在于存储库中的 Dockerfile，该文件定义了应用程序构建流程。我们将使用 oc new-app 创建应用程序。
使用存储库时首先要记住的是，它应该指向存储库中的一个源，OpenShift 将从中拉取代码并构建它。
如果仓库克隆在安装了 OC 客户端的 Docker 机器上，并且用户位于同一目录下，则可以使用以下命令创建它。
$ oc new-app . <Hear. Denotes current working directory>
以下是尝试从远程仓库构建特定分支的示例。
$ oc new-app https://github.com/openshift/Testing-deployment.git#test1
这里，test1 是我们尝试在 OpenShift 中创建新应用程序的分支。
在仓库中指定 Docker 文件时，我们需要定义如下所示的构建策略。
$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git
从镜像
在使用镜像构建应用程序时，镜像存在于本地 Docker 服务器、内部托管的 Docker 仓库或 Docker Hub 上。用户只需要确保能够无问题地从 Hub 拉取镜像。
OpenShift 能够确定使用的源，无论是 Docker 镜像还是源流。但是，如果用户希望，他可以明确定义它是镜像流还是 Docker 镜像。
$ oc new-app - - docker-image tomcat
使用镜像流 -
$ oc new-app tomcat:v1
从模板
模板可用于创建新的应用程序。它可以是已有的模板，也可以是创建新的模板。
以下 YAML 文件基本上是一个可用于部署的模板。
apiVersion: v1
kind: Template
metadata:
name: <Name of template>
annotations:
description: <Description of Tag>
iconClass: "icon-redis"
tags: <Tages of image>
objects:
- apiVersion: v1
kind: Pod
metadata:
name: <Object Specification>
spec:
containers:
image: <Image Name>
name: master
ports:
- containerPort: <Container port number>
protocol: <Protocol>
labels:
redis: <Communication Type>
开发和部署 Web 应用程序
在 OpenShift 中开发新应用程序
为了在 OpenShift 中创建新应用程序，我们必须编写新的应用程序代码并使用 OpenShift OC 构建命令进行构建。如前所述，我们有多种创建新镜像的方法。在这里，我们将使用模板来构建应用程序。此模板将在使用 oc new-app 命令运行时构建新应用程序。
以下模板将创建 - 两个前端应用程序和一个数据库。此外，它将创建两个新服务，并且这些应用程序将部署到 OpenShift 集群。在构建和部署应用程序时，最初我们需要在 OpenShift 中创建一个命名空间并在该命名空间下部署应用程序。
创建一个新的命名空间
$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" -- description = "This is an example project to demonstrate OpenShift v3"
模板
{
"kind": "Template",
"apiVersion": "v1",
"metadata": {
"name": "openshift-helloworld-sample",
"creationTimestamp": null,
"annotations": {
"description": "This example shows how to create a simple openshift
application in openshift origin v3",
"iconClass": "icon-openshift",
"tags": "instant-app,openshift,mysql"
}
}
},
对象定义
模板中的密钥定义
"objects": [
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {"name": "dbsecret"},
"stringData" : {
"mysql-user" : "${MYSQL_USER}",
"mysql-password" : "${MYSQL_PASSWORD}"
}
},
模板中的服务定义
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "frontend",
"creationTimestamp": null
},
"spec": {
"ports": [
{
"name": "web",
"protocol": "TCP",
"port": 5432,
"targetPort": 8080,
"nodePort": 0
}
],
"selector": {"name": "frontend"},
"type": "ClusterIP",
"sessionAffinity": "None"
},
"status": {
"loadBalancer": {}
}
},
模板中的路由定义
{
"kind": "Route",
"apiVersion": "v1",
"metadata": {
"name": "route-edge",
"creationTimestamp": null,
"annotations": {
"template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
}
},
"spec": {
"host": "www.example.com",
"to": {
"kind": "Service",
"name": "frontend"
},
"tls": {
"termination": "edge"
}
},
"status": {}
},
{
"kind": "ImageStream",
"apiVersion": "v1",
"metadata": {
"name": "origin-openshift-sample",
"creationTimestamp": null
},
"spec": {},
"status": {
"dockerImageRepository": ""
}
},
{
"kind": "ImageStream",
"apiVersion": "v1",
"metadata": {
"name": "openshift-22-ubuntu7",
"creationTimestamp": null
},
"spec": {
"dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
},
"status": {
"dockerImageRepository": ""
}
},
模板中的构建配置定义
{
"kind": "BuildConfig",
"apiVersion": "v1",
"metadata": {
"name": "openshift-sample-build",
"creationTimestamp": null,
"labels": {name": "openshift-sample-build"}
},
"spec": {
"triggers": [
{ "type": "GitHub",
"github": {
"secret": "secret101" }
},
{
"type": "Generic",
"generic": {
"secret": "secret101",
"allowEnv": true }
},
{
"type": "ImageChange",
"imageChange": {}
},
{ "type": "ConfigChange”}
],
"source": {
"type": "Git",
"git": {
"uri": https://github.com/openshift/openshift-hello-world.git }
},
"strategy": {
"type": "Docker",
"dockerStrategy": {
"from": {
"kind": "ImageStreamTag",
"name": "openshift-22-ubuntu7:latest”
},
"env": [
{
"name": "EXAMPLE",
"value": "sample-app"
}
]
}
},
"output": {
"to": {
"kind": "ImageStreamTag",
"name": "origin-openshift-sample:latest"
}
},
"postCommit": {
"args": ["bundle", "exec", "rake", "test"]
},
"status": {
"lastVersion": 0
}
}
},
模板中的部署配置
"status": {
"lastVersion": 0
}
{
"kind": "DeploymentConfig",
"apiVersion": "v1",
"metadata": {
"name": "frontend",
"creationTimestamp": null
}
},
"spec": {
"strategy": {
"type": "Rolling",
"rollingParams": {
"updatePeriodSeconds": 1,
"intervalSeconds": 1,
"timeoutSeconds": 120,
"pre": {
"failurePolicy": "Abort",
"execNewPod": {
"command": [
"/bin/true"
],
"env": [
{
"name": "CUSTOM_VAR1",
"value": "custom_value1"
}
]
}
}
}
}
}
"triggers": [
{
"type": "ImageChange",
"imageChangeParams": {
"automatic": true,
"containerNames": [
"openshift-helloworld"
],
"from": {
"kind": "ImageStreamTag",
"name": "origin-openshift-sample:latest"
}
}
},
{
"type": "ConfigChange"
}
],
"replicas": 2,
"selector": {
"name": "frontend"
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"name": "frontend"
}
},
"spec": {
"containers": [
{
"name": "openshift-helloworld",
"image": "origin-openshift-sample",
"ports": [
{
"containerPort": 8080,
"protocol": "TCP”
}
],
"env": [
{
"name": "MYSQL_USER",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-user"
}
}
},
{
"name": "MYSQL_PASSWORD",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-password"
}
}
},
{
"name": "MYSQL_DATABASE",
"value": "${MYSQL_DATABASE}"
}
],
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"imagePullPolicy": "IfNotPresent",
"securityContext": {
"capabilities": {},
"privileged": false
}
}
],
"restartPolicy": "Always",
"dnsPolicy": "ClusterFirst"
},
"status": {}
},
模板中的服务定义
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "database",
"creationTimestamp": null
},
"spec": {
"ports": [
{
"name": "db",
"protocol": "TCP",
"port": 5434,
"targetPort": 3306,
"nodePort": 0
}
],
"selector": {
"name": "database
},
"type": "ClusterIP",
"sessionAffinity": "None" },
"status": {
"loadBalancer": {}
}
},
模板中的部署配置定义
{
"kind": "DeploymentConfig",
"apiVersion": "v1",
"metadata": {
"name": "database",
"creationTimestamp": null
},
"spec": {
"strategy": {
"type": "Recreate",
"resources": {}
},
"triggers": [
{
"type": "ConfigChange"
}
],
"replicas": 1,
"selector": {"name": "database"},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {"name": "database"}
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"name": "database"
}
},
"spec": {
"containers": [
{
"name": "openshift-helloworld-database",
"image": "ubuntu/mysql-57-ubuntu7:latest",
"ports": [
{
"containerPort": 3306,
"protocol": "TCP"
}
],
"env": [
{
"name": "MYSQL_USER",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-user"
}
}
},
{
"name": "MYSQL_PASSWORD",
"valueFrom": {
"secretKeyRef" : {
"name" : "dbsecret",
"key" : "mysql-password"
}
}
},
{
"name": "MYSQL_DATABASE",
"value": "${MYSQL_DATABASE}"
}
],
"resources": {},
"volumeMounts": [
{
"name": "openshift-helloworld-data",
"mountPath": "/var/lib/mysql/data"
}
],
"terminationMessagePath": "/dev/termination-log",
"imagePullPolicy": "Always",
"securityContext": {
"capabilities": {},
"privileged": false
}
}
],
"volumes": [
{
"name": "openshift-helloworld-data",
"emptyDir": {"medium": ""}
}
],
"restartPolicy": "Always",
"dnsPolicy": "ClusterFirst”
}
}
},
"status": {}
},
"parameters": [
{
"name": "MYSQL_USER",
"description": "database username",
"generate": "expression",
"from": "user[A-Z0-9]{3}",
"required": true
},
{
"name": "MYSQL_PASSWORD",
"description": "database password",
"generate": "expression",
"from": "[a-zA-Z0-9]{8}",
"required": true
},
{
"name": "MYSQL_DATABASE",
"description": "database name",
"value": "root",
"required": true
}
],
"labels": {
"template": "application-template-dockerbuild"
}
}
上述模板文件需要一次性编译。我们需要先将所有内容复制到一个文件中，并在完成后将其命名为 YAML 文件。
我们需要运行以下命令来创建应用程序。
$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"
openshift-helloworld-sample
---------
This example shows how to create a simple ruby application in openshift origin v3
* With parameters:
* MYSQL_USER = userPJJ # generated
* MYSQL_PASSWORD = cJHNK3se # generated
* MYSQL_DATABASE = root
--> Creating resources with label app = ruby-helloworld-sample ...
service "frontend" created
route "route-edge" created
imagestream "origin-ruby-sample" created
imagestream "ruby-22-centos7" created
buildconfig "ruby-sample-build" created
deploymentconfig "frontend" created
service "database" created
deploymentconfig "database" created
--> Success
Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
Run 'oc status' to view your app.
如果我们希望监视构建，可以使用 -
$ oc get builds NAME TYPE FROM STATUS STARTED DURATION openshift-sample-build-1 Source Git@bd94cbb Running 7 seconds ago 7s
我们可以使用 - 检查 OpenShift 上已部署的应用程序。
$ oc get pods NAME READY STATUS RESTARTS AGE database-1-le4wx 1/1 Running 0 1m frontend-1-e572n 1/1 Running 0 27s frontend-1-votq4 1/1 Running 0 31s opeshift-sample-build-1-build 0/1 Completed 0 1m
我们可以使用以下命令检查应用程序服务是否根据服务定义创建。
$ oc get services NAME CLUSTER-IP EXTERNAL-IP PORT(S) SELECTOR AGE database 172.30.80.39 <none> 5434/TCP name=database 1m frontend 172.30.17.4 <none> 5432/TCP name=frontend 1m
OpenShift - 自动构建
在 OpenShift 中，我们有多种自动化构建管道的方法。为此，我们需要创建一个 BuildConfig 资源来描述构建流程。BuildConfig 中的流程可以与 Jenkins 作业定义中的作业定义进行比较。在创建构建流程时，我们必须选择构建策略。
BuildConfig 文件
在 OpenShift 中，BuildConfig 是一个用于连接 API 并创建新实例的 REST 对象。
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "<Name of build config file>"
spec:
runPolicy: "Serial"
triggers:
-
type: "GitHub"
github:
secret: "<Secrete file name>"
- type: "Generic"
generic:
secret: "secret101"
-
type: "ImageChange"
source:
type: "<Source of code>"
git:
uri: "https://github.com/openshift/openshift-hello-world"
dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
strategy:
type: "Source"
sourceStrategy:
from:
kind: "ImageStreamTag"
name: "openshift-20-centos7:latest"
output:
to:
kind: "ImageStreamTag"
name: "origin-openshift-sample:latest"
postCommit:
script: "bundle exec rake test"
在 OpenShift 中，有四种类型的构建策略。
- 源到镜像策略
- Docker 策略
- 自定义策略
- 管道策略
源到镜像策略
允许从源代码开始创建容器镜像。在此流程中，实际代码首先下载到容器中，然后在其中进行编译。编译后的代码部署到同一个容器中，并从该代码构建镜像。
strategy:
type: "Source"
sourceStrategy:
from:
kind: "ImageStreamTag"
name: "builder-image:latest"
forcePull: true
有多种策略策略。
- 强制拉取
- 增量构建
- 外部构建
Docker 策略
在此流程中，OpenShift 使用 Dockerfile 构建镜像，然后将创建的镜像上传到 Docker 仓库。
strategy:
type: Docker
dockerStrategy:
from:
kind: "ImageStreamTag"
name: "ubuntu:latest"
Docker 文件选项可用于多个位置，从文件路径、无缓存和强制拉取开始。
- 从镜像
- Dockerfile 路径
- 无缓存
- 强制拉取
自定义策略
这是不同类型的构建策略之一，其中没有强制要求构建的输出将是镜像。它可以比作 Jenkins 的自由风格作业。通过它，我们可以创建 Jar、rpm 和其他包。
strategy:
type: "Custom"
customStrategy:
from:
kind: "DockerImage"
name: "openshift/sti-image-builder"
它包含多个构建策略。
- 公开 Docker 套接字
- 密钥
- 强制拉取
管道策略
管道策略用于创建自定义构建管道。这主要用于在管道中实现工作流。此构建流程使用 Groovy DSL 语言使用自定义构建管道流程。OpenShift 将在 Jenkins 中创建一个管道作业并执行它。此管道流程也可用于 Jenkins。在此策略中，我们使用 Jenkinsfile 并将其附加到构建配置定义中。
Strategy:
type: "JenkinsPipeline"
jenkinsPipelineStrategy:
jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"
使用构建管道
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "test-pipeline"
spec:
source:
type: "Git"
git:
uri: "https://github.com/openshift/openshift-hello-world"
strategy:
type: "JenkinsPipeline"
jenkinsPipelineStrategy:
jenkinsfilePath: <file path repository>
OpenShift - CLI
OpenShift CLI 用于从命令行管理 OpenShift 应用程序。OpenShift CLI 能够管理端到端应用程序生命周期。通常，我们将使用 OC（OpenShift 客户端）与 OpenShift 通信。
OpenShift CLI 设置
为了在不同的操作系统上设置 OC 客户端，我们需要经历不同的步骤序列。
Windows 版 OC 客户端
步骤 1 - 从以下链接下载 oc cli https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2
步骤 2 - 将包解压缩到机器上的目标路径。
步骤 3 - 编辑系统的路径环境变量。
C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH% C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86; C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\ v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ATI Technologies\ATI.ACE\C ore-Static;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;
步骤 4 - 验证 Windows 上的 OC 设置。
C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version oc v3.6.0-alpha.2+3c221d5 kubernetes v1.6.1+5115d708d7 features: Basic-Auth
Mac OS X 版 OC 客户端
我们可以从与 Windows 相同的位置下载 Mac OS 设置二进制文件，然后将其解压缩到某个位置，并在环境 PATH 变量下设置可执行文件的路径。
或者
我们可以使用 Home brew 并使用以下命令进行设置。
$ brew install openshift-cli
Linux 版 OC 客户端
在同一页面上，我们有用于 Linux 安装的 tar 文件，可用于安装。之后，可以设置一个路径变量指向该特定可执行文件位置。
https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2
使用以下命令解压缩 tar 文件。
$ tar –xf < path to the OC setup tar file >
运行以下命令以检查身份验证。
C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login Server [https://127.0.0.1:8443]:
CLI 配置文件
OC CLI 配置文件用于管理多个 OpenShift 服务器连接和身份验证机制。此配置文件还用于存储和管理多个配置文件以及在它们之间切换。一个普通的配置文件如下所示。
$ oc config view
apiVersion: v1
clusters:
- cluster:
server: https://vklnld908.int.example.com
name: openshift
contexts:
- context:
cluster: openshift
namespace: testproject
user: alice
name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
user:
token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232
设置 CLI 客户端
用于设置用户凭据
$ oc config set-credentials <user_nickname> [--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>] [--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]
用于设置集群
$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>] [--certificate-authority = <path/to/certificate/authority>] [--api-version = <apiversion>] [--insecure-skip-tls-verify = true]
示例
$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232
用于设置上下文
$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>] [--user = <user_nickname>] [--namespace = <namespace>]
CLI 配置文件
在一个 CLI 配置文件中，我们可以有多个配置文件，其中每个配置文件都有不同的 OpenShift 服务器配置，之后可用于在不同的 CLI 配置文件之间切换。
apiVersion: v1
clusters: --→ 1
- cluster:
insecure-skip-tls-verify: true
server: https://vklnld908.int.example.com:8443
name: vklnld908.int.example.com:8443
- cluster:
insecure-skip-tls-verify: true
server: https://vklnld1446.int.example.com:8443
name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
cluster: vklnld908.int.example.com:8443
namespace: openshift-project
user: vipin/vklnld908.int.example.com:8443
name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
cluster: vklnld908.int.example.com:8443
namespace: testing-project
user: alim/vklnld908.int.example.com:8443
name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}
users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232
在上述配置中，我们可以看到它分为四个主要部分，从定义两个 OpenShift 主机的实例的集群开始。第二个上下文部分定义了两个名为 vipin 和 alim 的上下文。当前上下文定义了当前正在使用的上下文。如果我们在此处更改定义，则可以将其更改为其他上下文或配置文件。最后，定义了用户定义及其身份验证令牌，在本例中为 vipin。
如果我们想检查当前正在使用的配置文件，可以使用 - 进行检查。
$ oc status oc status In project testing Project (testing-project) $ oc project Using project "testing-project" from context named "testing- project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".
如果我们想切换到其他 CLI，可以使用以下命令从命令行进行切换。
$ oc project openshift-project Now using project "Openshift-project" on server " https://vklnld908.int.example.com:8443".
使用上述命令，我们可以在配置文件之间切换。在任何时候，如果我们希望查看配置，我们可以使用 $ oc config view 命令。
OpenShift - CLI 操作
OpenShift CLI 能够执行所有基本和高级配置、管理、添加和应用程序部署。
我们可以使用 OC 命令执行不同类型的操作。此客户端帮助您在任何与 OpenShift 或 Kubernetes 兼容的平台上开发、构建、部署和运行应用程序。它还包括用于在 'adm' 子命令下管理集群的管理命令。
基本命令
下表列出了基本 OC 命令。
| 序号 | 命令和描述 |
|---|---|
| 1 | 类型 概念和类型的介绍 |
| 2 | 登录 登录服务器 |
| 3 | new-project 请求一个新的项目 |
| 4 | new-app 创建一个新的应用程序 |
| 5 | 状态 显示当前项目的概述 |
| 6 | 项目 切换到另一个项目 |
| 7 | 项目 显示现有项目 |
| 8 | 解释 资源文档 |
| 9 | 集群 启动和停止 OpenShift 集群 |
登录
登录到您的服务器并保存登录信息以供后续使用。客户端的新用户应运行此命令以连接到服务器，建立经过身份验证的会话并将连接保存到配置文件。默认配置将保存在您主目录下的“.kube/config”中。
登录所需的信息（例如用户名和密码、会话令牌或服务器详细信息）可以通过标志提供。如果未提供，则命令将根据需要提示用户输入。
用法
oc login [URL] [options]
示例
# Log in interactively oc login # Log in to the given server with the given certificate authority file oc login localhost:8443 --certificate-authority = /path/to/cert.crt # Log in to the given server with the given credentials (will not prompt interactively) oc login localhost:8443 --username = myuser --password=mypass
选项 -
-p, --password = " - 密码，如果未提供将提示输入
-u, --username = " - 用户名，如果未提供将提示输入
--certificate-authority = " - 证书颁发机构的证书文件的路径
--insecure-skip-tls-verify = false - 如果为真，则不会检查服务器证书的有效性。这将使您的 HTTPS 连接不安全
--token = " - 用于对 API 服务器进行身份验证的承载令牌
要获取有关任何命令的完整详细信息，请使用oc <命令名称> --help命令。
构建和部署命令
下表列出了构建和部署命令。
| 序号 | 命令和描述 |
|---|---|
| 1 | 推出 管理 Kubernetes 部署或 OpenShift 部署 |
| 2 | 部署 查看、启动、取消或重试部署 |
| 3 | 回滚 将应用程序的一部分恢复到以前的状态 |
| 4 | new-build 创建一个新的构建配置 |
| 5 | start-build 启动一个新的构建 |
| 6 | cancel-build 取消正在运行、挂起或新的构建 |
| 7 | import-image 从 Docker 仓库导入镜像 |
| 8 | 标签 将现有镜像标记到镜像流中 |
应用程序管理命令
下表列出了应用程序管理命令。
| 序号 | 命令和描述 |
|---|---|
| 1 | 获取 显示一个或多个资源 |
| 2 | 描述 显示特定资源或一组资源的详细信息 |
| 3 | 编辑 编辑服务器上的资源 |
| 4 | 设置 有助于在对象上设置特定功能的命令 |
| 5 | 标签 更新资源上的标签 |
| 6 | 注释 更新资源上的注释 |
| 7 | 公开 将复制的应用程序公开为服务或路由 |
| 8 | 删除 删除一个或多个资源 |
| 9 | 缩放 更改部署中的 Pod 数量 |
| 10 | 自动缩放 自动缩放部署配置、部署、复制控制器或副本集 |
| 11 | 密钥 管理密钥 |
| 12 | 服务帐户 管理项目中的服务帐户 |
故障排除和调试命令
下表列出了故障排除和调试命令。
| 序号 | 命令和描述 |
|---|---|
| 1 | 日志 打印资源的日志 |
| 2 | Rsh 在 Pod 中启动 Shell 会话 |
| 3 | Rsync 在本地文件系统和 Pod 之间复制文件 |
| 4 | 端口转发 将一个或多个本地端口转发到 Pod |
| 5 | 调试 启动 Pod 的新实例以进行调试 |
| 6 | 执行 在容器中执行命令 |
| 7 | 代理 运行到 Kubernetes API 服务器的代理 |
| 9 | 附加 附加到正在运行的容器 |
| 10 | 运行 在集群上运行特定镜像 |
| 11 | Cp 复制文件和目录到容器或从容器复制文件和目录 |
高级命令
下表列出了高级命令。
| 序号 | 命令和描述 |
|---|---|
| 1 | adm 用于管理集群的工具 |
| 2 | create 通过文件名或标准输入创建资源 |
| 3 | replace 通过文件名或标准输入替换资源 |
| 4 | apply 通过文件名或标准输入将配置应用于资源 |
| 5 | patch 使用策略性合并补丁更新资源的字段 |
| 6 | process 将模板处理成资源列表 |
| 7 | export 导出资源以便在其他地方使用 |
| 8 | extract 将密钥或配置映射提取到磁盘 |
| 9 | idle 使可扩展资源空闲 |
| 10 | observe 观察资源的变化并对其做出反应（实验性） |
| 11 | policy 管理授权策略 |
| 12 | auth 检查授权 |
| 13 | convert 在不同的API版本之间转换配置文件 |
| 14 | import 导入应用程序的命令 |
设置命令
下表列出了设置命令。
| 序号 | 命令和描述 |
|---|---|
| 1 | Logout 结束当前服务器会话 |
| 2 | Config 更改客户端的配置文件 |
| 3 | Whoami 返回有关当前会话的信息 |
| 4 | Completion 为指定的shell（bash或zsh）输出shell补全代码 |
OpenShift - 集群
OpenShift使用两种安装方法来设置OpenShift集群。
- 快速安装方法
- 高级配置方法
设置集群
快速安装方法
此方法用于运行快速未经人工干预的集群设置配置。为了使用此方法，我们需要首先安装安装程序。这可以通过运行以下命令来完成。
交互式方法
$ atomic-openshift-installer install
当希望运行交互式设置时，此方法很有用。
无人值守安装方法
此方法用于希望设置无人值守的安装方法时，用户可以在~/.config/openshift/下定义一个配置yaml文件并将其命名为installer.cfg.yml。然后，可以运行以下命令来安装–u标签。
$ atomic-openshift-installer –u install
默认情况下，它使用位于~/.config/openshift/下的配置文件。另一方面，Ansible用作安装的备份。
version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log
deployment:
ansible_ssh_user: root
hosts:
- ip: 172.10.10.1
hostname: vklnld908.int.example.com
public_ip: 24.222.0.1
public_hostname: master.example.com
roles:
- master
- node
containerized: true
connect_to: 24.222.0.1
- ip: 172.10.10.2
hostname: vklnld1446.int.example.com
public_ip: 24.222.0.2
public_hostname: node1.example.com
roles:
- node
connect_to: 10.0.0.2
- ip: 172.10.10.3
hostname: vklnld1447.int.example.com
public_ip: 10..22.2.3
public_hostname: node2.example.com
roles:
- node
connect_to: 10.0.0.3
roles:
master:
<variable_name1>: "<value1>"
<variable_name2>: "<value2>"
node:
<variable_name1>: "<value1>"
这里，我们有特定于角色的变量，如果希望设置一些特定变量，可以定义这些变量。
完成后，我们可以使用以下命令验证安装。
$ oc get nodes NAME STATUS AGE master.example.com Ready 10d node1.example.com Ready 10d node2.example.com Ready 10d
高级安装
高级安装完全基于Ansible配置，其中包含有关主节点和节点配置的完整主机配置和变量定义。这包含有关配置的所有详细信息。
一旦我们完成了设置并且剧本准备就绪，我们只需运行以下命令即可设置集群。
$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml
向集群添加主机
我们可以使用以下方法将主机添加到集群中：
- 快速安装程序工具
- 高级配置方法
快速安装程序工具在交互模式和非交互模式下均有效。使用以下命令。
$ atomic-openshift-installer -u -c </path/to/file> scaleup
应用程序配置文件的缩放格式可以用于添加主节点和节点。
高级配置方法
在此方法中，我们更新Ansible的主机文件，然后在此文件中添加新的节点或服务器详细信息。配置文件如下所示。
[OSEv3:children] masters nodes new_nodes new_master
在同一个Ansible主机文件中，添加有关新节点的变量详细信息，如下所示。
[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"
最后，使用更新的主机文件，运行新配置并调用配置文件以使用以下命令完成设置。
$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml
管理集群日志
OpenShift集群日志只不过是从集群的主节点和节点机器生成的日志。这些可以管理任何类型的日志，从服务器日志、主节点日志、容器日志、Pod日志等。有多种技术和应用程序可用于容器日志管理。
列出了可以实现日志管理的一些工具。
- Fluentd
- ELK
- Kabna
- Nagios
- Splunk
ELK栈- 在尝试从所有节点收集日志并以系统格式呈现它们时，此栈很有用。ELK栈主要分为三大类。
ElasticSearch- 主要负责从所有容器收集信息并将其放入中心位置。
Fluentd- 用于将收集的日志馈送到elasticsearch容器引擎。
Kibana- 用于以图形界面形式将收集的数据作为有用的信息呈现的图形界面。
需要注意的一点是，当此系统部署在集群上时，它会开始从所有节点收集日志。
日志诊断
OpenShift有一个内置的oc adm dignostics命令与OC一起使用，可以用于分析多种错误情况。此工具可以由集群管理员从主节点使用。此实用程序在故障排除和诊断已知问题方面非常有用。它在主节点客户端和节点上运行。
如果没有任何参数或标志运行，它将查找客户端、服务器和节点机器的配置文件，并将其用于诊断。可以通过传递以下参数单独运行诊断：
- AggregatedLogging
- AnalyzeLogs
- ClusterRegistry
- ClusterRoleBindings
- ClusterRoles
- ClusterRouter
- ConfigContexts
- DiagnosticPod
- MasterConfigCheck
- MasterNode
- MetricsApiProxy
- NetworkCheck
- NodeConfigCheck
- NodeDefinitions
- ServiceExternalIPs
- UnitStatus
可以简单地使用以下命令运行它们。
$ oc adm diagnostics <DiagnosticName>
升级集群
集群的升级涉及升级集群中的多个内容，并使集群更新为新的组件和升级。这包括：
- 主节点组件的升级
- 节点组件的升级
- 策略的升级
- 路由的升级
- 镜像流的升级
为了执行所有这些升级，我们需要首先准备好快速安装程序或实用程序。为此，我们需要更新以下实用程序：
- atomic-openshift-utils
- atomic-openshift-excluder
- atomic-openshift-docker-excluder
- etcd包
在开始升级之前，我们需要备份主节点上的etcd，这可以通过使用以下命令来完成。
$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd $ etcdctl backup \ --data-dir $ETCD_DATA_DIR \ --backup-dir $ETCD_DATA_DIR.bak.<date>
主节点组件的升级
在OpenShift主节点中，我们通过更新etcd文件并然后转到Docker来开始升级。最后，我们运行自动执行器以使集群处于所需位置。但是，在开始升级之前，我们需要首先在每个主节点上激活原子OpenShift包。这可以通过使用以下命令来完成。
步骤1- 删除atomic-openshift包
$ atomic-openshift-excluder unexclude
步骤2- 升级所有主节点上的etcd。
$ yum update etcd
步骤3- 重新启动etcd的服务并检查它是否已成功启动。
$ systemctl restart etcd $ journalctl -r -u etcd
步骤4- 升级Docker包。
$ yum update docker
步骤5- 重新启动Docker服务并检查它是否已正确启动。
$ systemctl restart docker $ journalctl -r -u docker
步骤6- 完成后，使用以下命令重新启动系统。
$ systemctl reboot $ journalctl -r -u docker
步骤7- 最后，运行atomic-executer以将包重新添加到yum排除列表中。
$ atomic-openshift-excluder exclude
没有强制升级策略的必要，只有在建议升级时才需要升级，这可以通过以下命令检查。
$ oadm policy reconcile-cluster-roles
在大多数情况下，我们不需要更新策略定义。
节点组件的升级
主节点更新完成后，我们可以开始升级节点。需要注意的一点是，升级时间应该很短，以避免集群出现任何问题。
步骤1- 从要执行升级的所有节点中删除所有原子OpenShift包。
$ atomic-openshift-excluder unexclude
步骤2- 接下来，在升级前禁用节点调度。
$ oadm manage-node <node name> --schedulable = false
步骤3- 将当前主机上的所有节点复制到其他主机。
$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets
步骤4- 升级主机上的Docker设置。
$ yum update docker
步骤5- 重新启动Docker服务，然后启动Docker服务节点。
$systemctl restart docker $ systemctl restart atomic-openshift-node
步骤6- 检查两者是否都已正确启动。
$ journalctl -r -u atomic-openshift-node
步骤7- 升级完成后，重新启动节点机器。
$ systemctl reboot $ journalctl -r -u docker
步骤8- 重新启用节点上的调度。
$ oadm manage-node <node> --schedulable.
步骤9- 运行atomic-openshift executer以将OpenShift包重新放到节点上。
$ atomic-openshift-excluder exclude
步骤10- 最后，检查所有节点是否都可用。
$ oc get nodes NAME STATUS AGE master.example.com Ready 12d node1.example.com Ready 12d node2.example.com Ready 12d
OpenShift - 应用伸缩
自动扩展是OpenShift中的一项功能，其中部署的应用程序可以根据某些规范在需要时扩展和缩减。在OpenShift应用程序中，自动扩展也称为Pod自动扩展。自动扩展类型如下所示。
垂直扩展
垂直扩展就是向单个机器添加越来越多的功能，这意味着添加更多的CPU和硬盘。这是OpenShift的旧方法，现在不受OpenShift版本的支持。
水平扩展
当需要通过增加机器数量来处理更多请求时，此类型的扩展很有用。
在OpenShift中，有两种启用扩展功能的方法。
- 使用部署配置文件
- 运行镜像时
使用部署配置文件
在此方法中，扩展功能通过部署配置yaml文件启用。为此，OC自动扩展命令与副本的最小值和最大值一起使用，这些副本需要在集群的任何给定时间点运行。我们需要一个对象定义来创建自动扩展器。以下是Pod自动扩展器定义文件的示例。
apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
name: database
spec:
scaleRef:
kind: DeploymentConfig
name: database
apiVersion: v1
subresource: scale
minReplicas: 1
maxReplicas: 10
cpuUtilization:
targetPercentage: 80
一旦我们有了文件，我们需要以yaml格式保存它并运行以下命令进行部署。
$ oc create –f <file name>.yaml
运行镜像时
也可以在没有yaml文件的情况下使用以下oc autoscale命令在oc命令行中进行自动扩展。
$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75 deploymentconfig "database" autoscaled
此命令也会生成类似的文件，以后可以将其用作参考。
OpenShift中的部署策略
OpenShift中的部署策略定义了具有不同可用方法的部署流程。在OpenShift中，以下是重要的部署策略类型。
- 滚动策略
- 重新创建策略
- 自定义策略
以下是一个部署配置文件的示例，该文件主要用于在OpenShift节点上进行部署。
kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
name: "database"
spec:
template:
metadata:
labels:
name: "Database1"
spec:
containers:
- name: "vipinopenshifttest"
image: "openshift/mongoDB"
ports:
- containerPort: 8080
protocol: "TCP"
replicas: 5
selector:
name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
imageChangeParams:
automatic: true
containerNames:
- "vipinopenshifttest"
from:
kind: "ImageStreamTag"
name: "mongoDB:latest"
strategy:
type: "Rolling"
在上面的Deploymentconfig文件中，我们的策略为Rolling。
我们可以使用以下OC命令进行部署。
$ oc deploy <deployment_config> --latest
滚动策略
滚动策略用于滚动更新或部署。此过程还支持生命周期钩子，用于将代码注入任何部署流程。
strategy:
type: Rolling
rollingParams:
timeoutSeconds: <time in seconds>
maxSurge: "<definition in %>"
maxUnavailable: "<Defintion in %>"
pre: {}
post: {}
重新创建策略
此部署策略具有滚动部署策略的一些基本功能，并且还支持生命周期钩子。
strategy:
type: Recreate
recreateParams:
pre: {}
mid: {}
post: {}
自定义策略
当用户希望提供自己的部署流程或流程时，这非常有用。所有自定义都可以根据需要进行。
strategy:
type: Custom
customParams:
image: organization/mongoDB
command: [ "ls -l", "$HOME" ]
environment:
- name: VipinOpenshiftteat
value: Dev1
OpenShift - 管理
在本章中，我们将涵盖如何管理节点、配置服务帐户等主题。
主节点和节点配置
在 OpenShift 中，我们需要使用 `start` 命令以及 `oc` 来启动新的服务器。在启动新的主节点时，我们需要使用 `master` 以及 `start` 命令，而在启动新节点时，我们需要使用 `node` 以及 `start` 命令。为了做到这一点，我们需要为主节点和节点创建配置文件。我们可以使用以下命令为主节点和节点创建一个基本配置文件。
主节点配置文件
$ openshift start master --write-config = /openshift.local.config/master
节点配置文件
$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>
运行以下命令后，我们将获得可作为配置起点的基本配置文件。稍后，我们可以使用相同的配置文件来启动新服务器。
apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
logoutURL: ""
masterPublicURL: https://172.10.12.1:7449
publicURL: https://172.10.2.2:7449/console/
servingInfo:
bindAddress: 0.0.0.0:7449
certFile: master.server.crt
clientCA: ""
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
bindAddress: 0.0.0.0:53
etcdClientInfo:
ca: ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.key
urls:
- https://10.0.2.15:4001
etcdConfig:
address: 10.0.2.15:4001
peerAddress: 10.0.2.15:7001
peerServingInfo:
bindAddress: 0.0.0.0:7001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
servingInfo:
bindAddress: 0.0.0.0:4001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
kubernetesStoragePrefix: kubernetes.io
kubernetesStorageVersion: v1
openShiftStoragePrefix: openshift.io
openShiftStorageVersion: v1
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: MasterConfig
kubeletClientInfo:
ca: ca.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.key
port: 10250
kubernetesMasterConfig:
apiLevels:
- v1beta3
- v1
apiServerArguments: null
controllerArguments: null
masterCount: 1
masterIP: 10.0.2.15
podEvictionTimeout: 5m
schedulerConfigFile: ""
servicesNodePortRange: 30000-32767
servicesSubnet: 172.30.0.0/16
staticNodeNames: []
masterClients:
externalKubernetesKubeConfig: ""
openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
clusterNetworkCIDR: 10.1.0.0/16
hostSubnetLength: 8
networkPluginName: ""
serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
assetPublicURL: https://172.10.2.2:7449/console/
grantConfig:
method: auto
identityProviders:
- challenge: true
login: true
name: anypassword
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
masterPublicURL: https://172.10.2.2:7449/
masterURL: https://172.10.2.2:7449/
sessionConfig:
sessionMaxAgeSeconds: 300
sessionName: ssn
sessionSecretsFile: ""
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
policyConfig:
bootstrapPolicyFile: policy.json
openshiftInfrastructureNamespace: openshift-infra
openshiftSharedResourcesNamespace: openshift
projectConfig:
defaultNodeSelector: ""
projectRequestMessage: ""
projectRequestTemplate: ""
securityAllocator:
mcsAllocatorRange: s0:/2
mcsLabelsPerProject: 5
uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
subdomain: router.default.svc.cluster.local
serviceAccountConfig:
managedNames:
- default
- builder
- deployer
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
servingInfo:
bindAddress: 0.0.0.0:8443
certFile: master.server.crt
clientCA: ca.crt
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 3600
节点配置文件
allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
execHandlerName: native
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
mtu: 1450
networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com
podManifestConfig:
path: "/path/to/pod-manifest-file"
fileCheckIntervalSeconds: 30
servingInfo:
bindAddress: 0.0.0.0:10250
certFile: server.crt
clientCA: node-client-ca.crt
keyFile: server.key
volumeDirectory: /root/openshift.local.volumes
节点配置文件看起来像这样。一旦我们准备好这些配置文件，就可以运行以下命令来创建主节点和节点服务器。
$ openshift start --master-config = /openshift.local.config/master/master- config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node- config.yaml
管理节点
在 OpenShift 中，我们有 `oc` 命令行实用程序，主要用于执行 OpenShift 中的所有操作。我们可以使用以下命令来管理节点。
列出节点
$ oc get nodes NAME LABELS node1.example.com kubernetes.io/hostname = vklnld1446.int.example.com node2.example.com kubernetes.io/hostname = vklnld1447.int.example.com
描述节点详细信息
$ oc describe node <node name>
删除节点
$ oc delete node <node name>
列出节点上的 Pod
$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
评估节点上的 Pod
$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]
配置身份验证
在 OpenShift 主节点中，有一个内置的 OAuth 服务器，可用于管理身份验证。所有 OpenShift 用户都从该服务器获取令牌，这有助于他们与 OpenShift API 通信。
OpenShift 中有不同类型的身份验证级别，可以与主配置文件一起配置。
- 允许所有
- 拒绝所有
- HTPasswd
- LDAP
- 基本身份验证
- 请求头
在定义主节点配置时，我们可以定义身份策略，在其中可以定义我们希望使用的策略类型。
允许所有
允许所有
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
拒绝所有
这将拒绝所有用户名和密码的访问。
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HTPasswd
HTPasswd 用于根据加密的文件密码验证用户名和密码。
要生成加密文件，请使用以下命令。
$ htpasswd </path/to/users.htpasswd> <user_name>
使用加密文件。
oauthConfig:
...
identityProviders:
- name: htpasswd_authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /path/to/users.htpasswd
LDAP 身份提供程序
这用于 LDAP 身份验证，其中 LDAP 服务器在身份验证中起关键作用。
oauthConfig:
...
identityProviders:
- name: "ldap_authontication"
challenge: true
login: true
provider:
apiVersion: v1
kind: LDAPPasswordIdentityProvider
attributes:
id:
- dn
email:
- mail
name:
- cn
preferredUsername:
- uid
bindDN: ""
bindPassword: ""
ca: my-ldap-ca-bundle.crt
insecure: false
url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"
基本身份验证
当用户名和密码的验证针对服务器到服务器的身份验证进行时，使用此方法。身份验证在基本 URL 中受到保护，并以 JSON 格式呈现。
oauthConfig:
...
identityProviders:
- name: my_remote_basic_auth_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: BasicAuthPasswordIdentityProvider
url: https://www.vklnld908.int.example.com/remote-idp
ca: /path/to/ca.file
certFile: /path/to/client.crt
keyFile: /path/to/client.key
配置服务帐户
服务帐户提供了一种灵活的方式来访问 OpenShift API，公开用于身份验证的用户名和密码。
启用服务帐户
服务帐户使用公钥和私钥对进行身份验证。对 API 的身份验证使用私钥进行，并根据公钥进行验证。
ServiceAccountConfig: ... masterCA: ca.crt privateKeyFile: serviceaccounts.private.key publicKeyFiles: - serviceaccounts.public.key - ...
创建服务帐户
使用以下命令创建服务帐户
$ Openshift cli create service account <name of server account>
使用 HTTP 代理
在大多数生产环境中，对 Internet 的直接访问受到限制。它们要么未公开到 Internet，要么通过 HTTP 或 HTTPS 代理公开。在 OpenShift 环境中，此代理机器定义设置为环境变量。
这可以通过在位于 **`/etc/sysconfig`** 下的主节点和节点文件上添加代理定义来完成。这与我们对任何其他应用程序所做的类似。
主节点机器
/etc/sysconfig/openshift-master
HTTP_PROXY=http://USERNAME:[email protected]:8080/ HTTPS_PROXY=https://USERNAME:[email protected]:8080/ NO_PROXY=master.vklnld908.int.example.com
节点机器
/etc/sysconfig/openshift-node
HTTP_PROXY=http://USERNAME:[email protected]:8080/ HTTPS_PROXY=https://USERNAME:[email protected]:8080/ NO_PROXY=master.vklnld908.int.example.com
完成后，我们需要重新启动主节点和节点机器。
用于 Docker 拉取
/etc/sysconfig/docker
HTTP_PROXY = http://USERNAME:[email protected]:8080/ HTTPS_PROXY = https://USERNAME:[email protected]:8080/ NO_PROXY = master.vklnld1446.int.example.com
为了使 Pod 在代理环境中运行，可以使用以下方法：
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
可以使用 `oc env` 命令更新现有的环境变量。
OpenShift 使用 NFS 的存储
在 OpenShift 中，持久卷和持久卷声明的概念构成了持久存储。这是关键概念之一，其中首先创建持久卷，然后声明相同的卷。为此，我们需要在底层硬件上拥有足够的容量和磁盘空间。
apiVersion: v1
kind: PersistentVolume
metadata:
name: storage-unit1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
path: /opt
server: 10.12.2.2
persistentVolumeReclaimPolicy: Recycle
接下来，使用 `oc create` 命令创建持久卷。
$ oc create -f storage-unit1.yaml persistentvolume " storage-unit1 " created
声明已创建的卷。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: Storage-clame1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
创建声明。
$ oc create -f Storage-claim1.yaml persistentvolume " Storage-clame1 " created
用户和角色管理
用户和角色管理用于管理用户、他们的访问权限以及对不同项目的控制。
创建用户
可以使用预定义模板在 OpenShift 中创建新用户。
kind: "Template"
apiVersion: "v1"
parameters:
- name: vipin
required: true
objects:
- kind: "User"
apiVersion: "v1"
metadata:
name: "${email}"
- kind: "Identity"
apiVersion: "v1"
metadata:
name: "vipin:${email}"
providerName: "SAML"
providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
name: "vipin:${email}"
user:
name: "${email}"
使用 `oc create -f <文件名>` 创建用户。
$ oc create –f vipin.yaml
使用以下命令删除 OpenShift 中的用户。
$ oc delete user <user name>
限制用户访问
ResourceQuotas 和 LimitRanges 用于限制用户访问级别。它们用于限制集群上的 Pod 和容器。
apiVersion: v1
kind: ResourceQuota
metadata:
name: resources-utilization
spec:
hard:
pods: "10"
使用以上配置创建配额
$ oc create -f resource-quota.yaml –n –Openshift-sample
描述资源配额
$ oc describe quota resource-quota -n Openshift-sample Name: resource-quota Namespace: Openshift-sample Resource Used Hard -------- ---- ---- pods 3 10
定义容器限制可用于限制已部署容器将使用的资源。它们用于定义某些对象的最大和最小限制。
用户项目限制
这主要用于用户在任何时间点可以拥有的项目数量。它们基本上是通过将用户级别定义为青铜、白银和黄金类别来完成的。
我们需要首先定义一个对象，该对象保存青铜、白银和黄金类别可以拥有的项目数量的值。这些需要在 `master-confif.yaml` 文件中完成。
admissionConfig:
pluginConfig:
ProjectRequestLimit:
configuration:
apiVersion: v1
kind: ProjectRequestLimitConfig
limits:
- selector:
level: platinum
- selector:
level: gold
maxProjects: 15
- selector:
level: silver
maxProjects: 10
- selector:
level: bronze
maxProjects: 5
重新启动主节点服务器。
将用户分配到特定级别。
$ oc label user vipin level = gold
根据需要将用户移出标签。
$ oc label user <user_name> level-
向用户添加角色。
$ oadm policy add-role-to-user<user_name>
从用户中删除角色。
$ oadm policy remove-role-from-user<user_name>
向用户添加集群角色。
$ oadm policy add-cluster-role-to-user<user_name>
从用户中删除集群角色。
$ oadm policy remove-cluster-role-from-user<user_name>
向组添加角色。
$ oadm policy add-role-to-user<user_name>
从组中删除角色。
$ oadm policy remove-cluster-role-from-user<user_name>
向组添加集群角色。
$ oadm policy add-cluster-role-to-group<groupname>
从组中删除集群角色。
$ oadm policy remove-cluster-role-from-group <role> <groupname>
集群管理员用户
这是最强大的角色之一，用户能够管理整个集群，从创建到删除集群。
$ oadm policy add-role-to-user admin <user_name> -n <project_name>
拥有终极权限的用户
$ oadm policy add-cluster-role-to-user cluster-admin <user_name>
OpenShift - Docker 和 Kubernetes
OpenShift 建立在 Docker 和 Kubernetes 之上。所有容器都构建在 Docker 集群之上，该集群基本上是 Linux 机器上的 Kubernetes 服务，使用 Kubernetes 编排功能。
在此过程中，我们构建 Kubernetes 主节点，它控制所有节点并将容器部署到所有节点。Kubernetes 的主要功能是使用不同类型的配置文件来控制 OpenShift 集群和部署流程。与 Kubernetes 中使用 `kubectl` 的方式相同，我们使用 `oc` 命令行实用程序在集群节点上构建和部署容器。
以下是用于在集群中创建不同类型对象的不同类型的配置文件。
- 镜像
- Pod
- 服务
- 复制控制器
- 副本集
- 部署
镜像
Kubernetes（Docker）镜像是容器化基础设施的关键构建块。截至目前，Kubernetes 仅支持 **Docker** 镜像。Pod 中的每个容器在其内部运行其 Docker 镜像。
apiVersion: v1 kind: pod metadata: name: Tesing_for_Image_pull -----------> 1 spec: containers: - name: neo4j-server ------------------------> 2 image: <Name of the Docker image>----------> 3 imagePullPolicy: Always ------------->4 command: [“echo”, “SUCCESS”] -------------------> 5
Pod
Pod 是 Kubernetes 集群节点内容器及其存储的集合。可以在其中创建一个包含多个容器的 Pod。以下是在同一 Pod 中保留数据库容器和 Web 界面容器的示例。
apiVersion: v1
kind: Pod
metadata:
name: Tomcat
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7500
imagePullPolicy: Always
服务
服务可以定义为 Pod 的逻辑集合。它可以定义为 Pod 之上的抽象，它提供单个 IP 地址和 DNS 名称，通过该名称可以访问 Pod。使用服务，可以很容易地管理负载均衡配置。它有助于 Pod 非常轻松地扩展。
apiVersion: v1
kind: Service
metadata:
name: Tutorial_point_service
spec:
ports:
- port: 8080
targetPort: 31999
复制控制器
复制控制器是 Kubernetes 的关键功能之一，负责管理 Pod 生命周期。它负责确保在任何时间点都运行指定数量的 Pod 副本。
apiVersion: v1
kind: ReplicationController
metadata:
name: Tomcat-ReplicationController
spec:
replicas: 3
template:
metadata:
name: Tomcat-ReplicationController
labels:
app: App
component: neo4j
spec:
containers:
- name: Tomcat
image: tomcat: 8.0
ports:
- containerPort: 7474
副本集
副本集确保应运行多少个 Pod 副本。它可以被视为复制控制器的替代品。
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: Tomcat-ReplicaSet
spec:
replicas: 3
selector:
matchLables:
tier: Backend
matchExpression:
- { key: tier, operation: In, values: [Backend]}
app: App
component: neo4j
spec:
containers:
- name: Tomcat-
image: tomcat: 8.0
ports:
containerPort: 7474
部署
部署是复制控制器的升级和更高版本。它们管理副本集的部署，副本集也是复制控制器的升级版本。它们能够更新副本集，并且还能够回滚到以前的版本。
apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
name: Tomcat-ReplicaSet
spec:
replicas: 3
template:
metadata:
lables:
app: Tomcat-ReplicaSet
tier: Backend
spec:
containers:
name: Tomcat-
image: tomcat: 8.0
ports:
- containerPort: 7474
所有配置文件都可以用于创建其各自的 Kubernetes 对象。
$ Kubectl create –f <file name>.yaml
以下命令可用于了解 Kubernetes 对象的详细信息和描述。
用于 Pod
$ Kubectl get pod <pod name> $ kubectl delete pod <pod name> $ kubectl describe pod <pod name>
用于复制控制器
$ Kubectl get rc <rc name> $ kubectl delete rc <rc name> $ kubectl describe rc <rc name>
用于服务
$ Kubectl get svc <svc name> $ kubectl delete svc <svc name> $ kubectl describe svc <svc name>
有关如何使用 Docker 和 Kubernetes 的更多详细信息，请访问我们的 Kubernetes 教程，网址为：kubernetes。
OpenShift - 安全性
OpenShift 安全性主要是两个主要处理安全约束的组件的组合。
- 安全上下文约束 (SCC)
- 服务帐户
安全上下文约束 (SCC)
它主要用于 Pod 限制，这意味着它定义了 Pod 的限制，例如它可以执行哪些操作以及它可以在集群中访问哪些内容。
OpenShift 提供了一组预定义的 SCC，管理员可以使用、修改和扩展这些 SCC。
$ oc get scc NAME PRIV CAPS HOSTDIR SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY anyuid false [] false MustRunAs RunAsAny RunAsAny RunAsAny 10 hostaccess false [] true MustRunAs MustRunAsRange RunAsAny RunAsAny <none> hostmount-anyuid false [] true MustRunAs RunAsAny RunAsAny RunAsAny <none> nonroot false [] false MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> privileged true [] true RunAsAny RunAsAny RunAsAny RunAsAny <none> restricted false [] false MustRunAs MustRunAsRange RunAsAny RunAsAny <none>
如果用户希望使用任何预定义的 scc，可以通过简单地将用户或组添加到 scc 组来完成。
$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>
服务帐户
服务帐户主要用于控制对 OpenShift 主节点 API 的访问，当从任何主节点或节点机器发出命令或请求时，该 API 会被调用。
任何时候，当应用程序或进程需要受限 SCC 未授予的功能时，您都必须创建一个特定的服务帐户并将该帐户添加到相应的 SCC。但是，如果 SCC 不符合您的要求，那么最好创建满足您特定要求的新 SCC，而不是使用最合适的 SCC。最后，将其设置为部署配置。
$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin
容器安全
在 OpenShift 中，容器的安全基于容器平台的安全性以及容器运行位置的概念。当我们谈论容器安全以及需要注意的事项时，会有很多事情需要考虑。
**镜像来源** - 存在一个安全的标签系统，用于准确且无可争议地识别生产环境中运行的容器的来源。
**安全扫描** - 镜像扫描程序会自动检查所有镜像是否存在已知的漏洞。
**审计** - 定期对生产环境进行审计，以确保所有容器都基于最新的容器，并且主机和容器都已安全配置。
**隔离和最小权限** - 容器以有效运行所需的最低资源和权限运行。它们无法过度干扰主机或其他容器。
运行时威胁检测 - 一种在运行时检测针对容器化应用程序的活动威胁并自动对其做出响应的功能。
访问控制 - 使用 Linux 安全模块（例如 AppArmor 或 SELinux）来强制执行访问控制。
容器安全可以通过几种关键方法实现。
- 通过 OAuth 控制访问
- 通过自助服务 Web 控制台
- 通过平台证书
通过 OAuth 控制访问
在这种方法中，通过获取 OAuth 服务器（内置于 OpenShift 主机）提供的安全令牌进行身份验证来实现对 API 访问的控制。作为管理员，您可以修改 OAuth 服务器配置。
有关 OAuth 服务器配置的更多详细信息，请参阅本教程的第 5 章。
通过自助服务 Web 控制台
此 Web 控制台安全功能内置于 OpenShift Web 控制台中。此控制台确保所有协同工作的团队在未经身份验证的情况下无法访问其他环境。OpenShift 中的多租户主节点具有以下安全功能：
- 已启用 TCL 层
- 使用 x.509 证书进行身份验证
- 保护主节点上的 etcd 配置
通过平台证书
在这种方法中，每个主机的证书在安装期间通过 Ansible 进行配置。由于它通过 Rest API 使用 HTTPS 通信协议，因此我们需要 TCL 安全连接到不同的组件和对象。这些是预定义的证书，但是，也可以在主节点集群上安装自定义证书以进行访问。在主节点的初始设置期间，可以通过使用 **openshift_master_overwrite_named_certificates** 参数覆盖现有证书来配置自定义证书。
示例
openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt",
"keyfile": "/path/on/host/to/master.key",
"cafile": "/path/on/host/to/mastercert.crt"}]
有关如何生成自定义证书的更多详细信息，请访问以下链接：
https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux
网络安全
在 OpenShift 中，软件定义网络 (SDN) 用于通信。网络命名空间用于集群中的每个 Pod，其中每个 Pod 获取自己的 IP 和一系列端口以在其上获取网络流量。通过这种方法，可以隔离 Pod，因此它无法与其他项目中的 Pod 通信。
隔离项目
集群管理员可以通过从 CLI 使用以下 **oadm 命令**来实现此目的。
$ oadm pod-network isolate-projects <project name 1> <project name 2>
这意味着上面定义的项目无法与集群中的其他项目通信。
卷安全
卷安全明确表示保护 OpenShift 集群中项目的 PV 和 PVC。在 OpenShift 中主要有四个部分来控制对卷的访问。
- 补充组
- fsGroup
- runAsUser
- seLinuxOptions
补充组 - 补充组是常规的 Linux 组。当进程在系统中运行时，它以用户 ID 和组 ID 运行。这些组用于控制对共享存储的访问。
使用以下命令检查 NFS 挂载。
# showmount -e <nfs-server-ip-or-hostname> Export list for f21-nfs.vm: /opt/nfs *
使用以下命令检查挂载服务器上的 NFS 详细信息。
# cat /etc/exports /opt/nfs *(rw,sync,no_root_squash) ... # ls -lZ /opt/nfs -d drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs # id nfsnobody uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)
/opt/nfs/ 导出可由 UID **454265** 和组 **2325** 访问。
apiVersion: v1
kind: Pod
...
spec:
containers:
- name: ...
volumeMounts:
- name: nfs
mountPath: /usr/share/...
securityContext:
supplementalGroups: [2325]
volumes:
- name: nfs
nfs:
server: <nfs_server_ip_or_host>
path: /opt/nfs
fsGroup
fsGroup 代表文件系统组，用于添加容器补充组。补充组 ID 用于共享存储，而 fsGroup 用于块存储。
kind: Pod
spec:
containers:
- name: ...
securityContext:
fsGroup: 2325
runAsUser
runAsUser 使用用户 ID 进行通信。这用于在 Pod 定义中定义容器镜像。如果需要，可以在所有容器中使用单个 ID 用户。
运行容器时，将定义的 ID 与导出上的所有者 ID 进行匹配。如果在外部定义了指定的 ID，则它对 Pod 中的所有容器都成为全局的。如果它与特定 Pod 定义在一起，则它对单个容器具有特殊性。
spec:
containers:
- name: ...
securityContext:
runAsUser: 454265