OpenShift企业版离线安装：下载RedHat-Repo源及镜像文件
为了安全起见，在很多企业，网络环境是不能连接外网的，而需要使用OpenShift的话，就需要离线部署。离线部署与在线部署最大区别，就是我们得自己准备介质源：YUM源与镜像仓库。只要你拥有红帽订阅，下载最新的介质，其实很简单。 一、同步YUM源RHEL主机注册到红帽订阅，并关联到相应的YUM仓库 12345678910$ subscription-manager register$ subscription-manager refresh$ subscription-manager list --available --matches '*OpenShift*'$ subscription-manager attach --pool=<pool_id>$ subscription-manager repos --disable="*"$ subscription-manager repos \ --enable="rhel-7-server-rpms" \ --enable="rhel-...
OpenShift-Router配置重新加载机制
OpenShift的Router是几乎所有南北流量的入口，对它的运行机制的了解非常重要，尤其是Router的配置更新加载机制。在服务请求出现异常情况下，我们能够快速分析出问题的原因，及时修复，保证应用的连续性。本章主要介绍OpenShift Router的配置加载机制。 OpenShift路由默认是基于Haproxy实现的。当Pod有更新或者证书更新等情况时会重新加载Haproxy的配置，来保证集群的路由信息是最新的。重载配置是否会对当前在线业务产生影响，这是系统管理员担心的问题。 一、 Haproxy配置重载的过程Haproxy在重新加载配置过程分两步。 生成最新的配置 重启Haproxy进程 Haproxy生成最新的配置OpenShift上以下三种资源的改变会触发Haproxy配置的更新 Routes改变 Pod IP/Endpoint 改变 证书改变 OpenShift Route有一个配置模板文件，最终的配置会根据这个模板文件来创建。该模板文件，默认路径为/var/lib/haproxy/conf/haproxy-config.template，也可以...
OpenShift使用MetalLB，打开了Service通向外界的大门
#背景在K8S/OpenShift中，如果要向集群外部暴露应用的服务，目前使用的方法有：NodePort、HostPort、Route、LoadBalancer、HostNetwork。 Route：为最常用的方法，但是一般只支持7层负载（默认），使用一个外部LB来负载多个Route实例，对外的访问的IP为该LB的IP。 NodePort：在私有集群中也常用来暴露服务，但是它必须使用30000以上的端口，数量有限，不便于管理，而且对于一些特殊的服务，如DNS，必须使用小端口号，那么使用NodePort则无法满足。 HostNetwork：对于集群中的一些特殊服务使用该方式，它将容器与宿主机的网络绑定，如OpenShift中的Router服务就是使用HostNetwork与Router节点绑定。它的缺点是pod必须与主机绑定，同时每个Node上只能运行一个Pod实例，因为端口无法被复用。 HostPort：与HostNetwork类似，将Pod指定的端口与Node对应的端口绑定。 LoadBalancer：一般只在公有云平台使用，可以使Service获得与主机同一平面...
OpenShift制作NginxLB-Operator实战
背景近期需要在OpenShift集群中部署Nginx服务做为负载均衡器，负载集群外部服务，如NTP、DNS、项目App等。因为不同的服务的配置都是不一样的，不仅后台服务的IP不一样，而且使用的协议也不一样，HTTP/TCP/UDP都有可能，如果按照传统的方式来实施的话，每一个应用单独定义Nginx配置，分别部署，每增加一个新的应用被负载都需要做一次复杂的过程，那么有没有办法能够让这过程变得简单呢，甚至能够自动化处理，我们只需要提供最简单的信息？下面我们来分析下常用的几种方法。 打包方案选择1. Template对于OpenShift熟悉的朋友，会马上想到使用Template模板来实现。Template模板是OpenShift特有的应用打包方式，它描述了一组对象，同时对这些对象的配置可以进行参数化处理，生成OpenShift 容器平台创建的对象列表。在模板中可以设置所有在项目中有权限创建的任何资源。 不足之处： OpenShift特有，如果是使用OpenShift容器平台的话，这个不足可忽略。 无法保证线上资源状态始终与参数设定的结果一致，如手动增加rc的副本...
OpenShift存储管理方案——Rook
存储的重要意义存储资源是容器云平台中的一个核心基础设施，为不同的应用服务提供可靠的持久化服务。大家都知道，容器运行过程中产生的数据是临时数据，并不可靠，一旦容器挂了，这些数据都会丢失。所以对数据可靠性有要求的应用就必须使用存储资源。存储的方案有很多种，常用的有本地盘存储、NFS、Ceph、Gluster FS等等。其中Ceph是一个开源的分布式文件系统，同时支持对象存储、块存储、文件存储,为云计算平台提供了最全面的存储方案。它以可靠、高性能等特性得到了很多企业的认可，并使用它来作为生产环境的存储。但是运维Ceph存储集群是一件较复杂工作，通过Rook项目，我们可以非常方便简单地实施Ceph存储方案，并且已有企业使用Rook来运维生产级别的存储方案。 Rook：CNCF云原生存储项目Rook于2018年1月加入了CNCF，成为了CNCF第15个项目，同时它也是CNCF首个云原生存储项目。Rook并不是自己开发一套存储方案，而是将现有的分布式存储系统云原生化，让它们能够实现自我管理，自我扩展，自我修复。 它使存储管理员的任务自动化：部署，引导，配置，配置，扩展，升级，迁移，灾难恢复...
OpenShift容器中读取Project信息
背景在日常运维管理中，经常需要获取OpenShift集群资源的信息，甚至创建、编辑或删除资源。我们都很清楚，使用oc命令就能够非常方便地完成这些操作。但是有时，我们希望通过调用接口来实现，以便于与其它组件或者应用进行集成。那么我们该如何做呢？本篇就以读取Project信息为例，展示如何通过HTTP请求操作OpenShift的资源。 操作 首先需要创建具有读取Project信息权限的clusterrole project_view 12345678910111213$ cat <<EOF | oc create -f -apiVersion: authorization.openshift.io/v1kind: ClusterRolemetadata: name: project_viewrules:- apiGroups: - project.openshift.io resources: - projects verbs: - getEOF 为需要调用的应用POD添加获取Project信息的权限 1$ oc adm policy add-clus...
OpenShift容器云平台建设之部署前准备
在企业级部署OpenShift前，需要先考虑以下几个问题： 使用的主机架构是什么?IBM Power还是x86。 集群多大的容量，运行多少个Pod? Limit Type 3.7 Limit 3.9 Limit 3.10 Limit 3.11 Limit 节点数 [1] 2,000 2,000 2,000 2,000 pod数 [2] 120,000 120,000 150,000 150,000 每台节点支持的pod数 250 250 250 250 每核支持的pod数 默认为10. 最大值为主机支持的pod数 默认为10. 最大值为主机支持的pod数 无默认值. 最大值为主机支持的pod数 无默认值. 最大值为主机支持的pod数 namespaces数量 10,000 10,000 10,000 10,000 Pipeline构建策略数量 N/A 10,000 (默认pod内存为512Mi) 10,000 (默认pod内存为512Mi) 10,000 (默认pod内存为512Mi) 每个namespace下创建的pod数...
OpenShift使用KeepAlived+LVS实现外部负载均衡器
OpenShift集群资源列表 主机名 类型 IP 相关节点IP master0 master 192.168.0.2 master1 master 192.168.0.3 master2 master 192.168.0.4 infra0 infra 192.168.0.5 infra1 infra 192.168.0.6 vip地址分配 master-vip vip 192.168.0.250 infra-vip vip 192.168.0.251 部署Master API负载均衡器作为集群内外访问的入口 在三个Master节点安装KeepAlived与LVS 12$ ansible masters -m package -a 'name=keepalived state=present'$ ansible masters -m package -a 'name=ipvsadm state=present' 选择master0作为VIP的Master节点 1234567891...
OpenShift应用补丁检查与升级
OpenShift版本补丁查看：https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html 自动查看新增的补丁版本脚本 # -*- coding: utf-8 -*- """ ------------------------------------------------- File Name： get_update_v3.11 ------------------------------------------------- """ last_index="RHSA-2020:2992" last_flag = False import requests from pyquery import PyQuery url="https://docs.openshift.com/container-platform/3.11/release_note...
OpenShift支持Calico-BGP-路由反射（RR）模式
一、Calico 是什么calico 是容器网络的一种解决方案，也是当前最流行的方案之一。和其他虚拟网络最大的不同是，它没有采用 overlay 网络做报文的转发，提供了纯 3 层的网络模型。三层通信模型表示每个容器都通过 IP 直接通信，中间通过路由转发找到对方。在这个过程中，容器所在的节点类似于传统的路由器，提供了路由查找的功能。 要想路由工作能够正常，每个虚拟路由器（容器所在的主机节点）必须有某种方法知道整个集群的路由信息，calico 采用的是BGP 路由协议，全称是 Border Gateway Protocol。 除了能用于 docker 这样的容器外，它还能集成到容器集群平台 OpenShift/kubernetes、公有云平台 AWS、GCE 等， 而且也能很容易地集成到 openstack 等 Iaas 平台。 二、Calico网络方式2.1 IPIP模式从字面来理解，就是把一个IP数据包又套在一个IP包里，即把 IP 层封装到 IP 层的一个 tunnel，看起来似乎是浪费，实则不然。它的作用其实基本上就相当于一个基于IP层的网桥！一般来说，普通的...