Openshift-Build构建详解
Build是什么Build是Openshift容器平台上将输入转化为输出的过程，通常情况下是将代码转化为镜像的过程。
Build的配置叫BuildConfig，它将定义构建策略及构建参数。设置的构建策略和参数确定了Build的构建过程。
Openshift构建有四种主要策略
Docker 构建
源代码构建（S2i)
自定义构建
Pipeline构建可以实现复杂的工作流
Docker构建、S2i构建、Pipeline构建是默认支持的。
不同的构建有六种源
Git
Dockerfile
Binary
Image
Input secrets
External artifacts
其中Binary和Git不能同时使用。 Dockerfile和Image可以单独使用，也可以与Git或Binary一起使用。 如果使用Binary作为BuildConfig.spec.source.type，只能通过命令行工具oc start-build来构建。
BuildConfig实例
123456789101112131415161718192021222324252627282930kind: &qu ...
Openshift-F5集成（南北流量走F5）
使用F5与Openshift集成目的外部流量访问应用时，通过F5 BIG-IP硬件设备直接代理到集群中的Pod。这样做的好处，很明显。
使用硬件负载均衡器替换掉软件负载均衡器，提高性能。
F5有更灵活的配置，可以实现更复杂的流量控制
Openshift操作Openshift通过BIG-IP Controller来控制BIG-IP设备。由于Openshift是基于Kubernetes的，所以它们使用同一个Controller（k8s-bigip-ctlr）。BIG-IP Controller为集群中的应用配置BIG-IP对象，提供南北流量的服务。
BIG-IP Controller有两种方式来使用F5 BIG-IP设备
为Openshift中的Service提供代理流量
为Openshift中的Route提供代理流量
为Openshift中的Service提供代理流量_(不介绍具体部署操作)_这种方式，我们测试下来发现，需要为对外提供服务的Service绑定到F5的不同端口，同时外部访问应用时需要指定端口号。如：app1.openshift.example.com:8000, a ...
Openshift-F5集成（总结）——与Router方案对比
这篇文章来自9月份自己在F5年度会议上分享的PPT，感谢过程中帮忙一起联调的小伙伴。PPT也分享出来，地址如下：openshift与F5的联合解决方案Openshift-F5集成（南北流量走F5）Openshift-F5集成（续）——实现灰度发布
Openshift的基础概念Openshift简介红帽® OpenShift 是一款性能强大的开源企业级PaaS产品。不仅是企业级的Kubernetes，可以构建、部署与管理容器应用，还提供从开发到投入生产的整个应用生命周期内使用的完整解决方案，帮助客户享受快速创新带来的收益，同时保持企业级平台的稳定性、可靠性和安全性。Openshift支持多种环境下部署，无论是在企业内部，公共云，或是托管环境中。
Openshift Pod
Pod是Openshift调度的最小单元
一个Pod包含一个或多个容器
Pod内的容器共享网络，IP不固定
实例：
12345678910111213apiVersion: v1kind: Podmetadata: name: MyApp labels: app: MyApp spec: ...
Openshift-F5集成（续）——实现灰度发布
上篇：Openshift-F5集成（南北流量走F5）中介绍了如何实现使用F5替换掉Openshift中的Route，但是它的可控性是弱的。本篇则通过手动创建VS及iRule来实现更强的流量控制，实现识别客户端IP来访问相应的服务。
为什么要使用灰度发布
什么是灰度发布灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。ABtest就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度发布的价值使用灰度发布可以在产品正式上线前针对特定一些目标用户进行开放，获得这些目标用户的反馈，及早发现问题，修复问题，完善产品的不足。如果发现新的版本价值不大，能够及早更换思路，避免产品直接上线后产生不好的影响。
Openshift Route自带的灰度发布功能
Openshift Route自带的灰度发布，是通过Route下“挂载”两个或两个以上Service，并调整各个Service的权值进行控制流量的分布。
例如应用有 ...
Openshift-GitLab安装及使用Nodeport支持ssh访问
部署Gitlab
创建gitlab项目1oc new-project gitlab
创建cicd serviceaccount1$ oc create serviceaccount cicd -n gitlab
导入Gitlab模板12wget https://gitee.com/xhua/OpenshiftOneClick/raw/3.11/openshift-templates/gitlab-template.yamloc create -f openshift-template.json -n openshift
创建持久化存储（如果没有pv的情况下）123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384$ cat gitlab-pv.yamlapiVersion: v1items:- apiVersion: v1 ...
Openshift-HPA（Horizontal-Pod-Autoscaler）自动伸缩过程及算法
1、HPA介绍HPA（Horizontal Pod Autoscaler）是Openshift中的一个非常重要的对象，它定义了系统如何根据收集对应的Pod的状态（CPU/Memory）对DeploymentConfig、ReplicationController对象进行扩容与缩容。
HPA依赖于收集到的Pod资源的使用状态，所以要使HPA生效，Openshift必须安装好cluster metrics应用。
被监控的pod必须设置好了spec.containers.resources.requests属性，HPA才能正常工作。
仅支持CPU/Memory使用率的判断，如果自定义监控项，只能使用经验值，不能使用使用率。
支持对象：DeploymentConfig、ReplicationController、Deployment、Replica Set。
2. HPA伸缩过程及算法
HPA进行伸缩过程
收集该HPA控制下所有Pod最近的cpu使用情况（CPU utilization）
对比在扩容条件里记录的cpu限额（CPUUtilization）
调整实例数（ ...
Openshift-Jenkins共享并支持pipeline
诉求
使用Openshift的pipeline构建流水线，在Openshift上统一管理
使用一个公共的Jenkins，而不需要每个Project下都创建一个新的jenkins。以节约资源
在创建新的项目时，尽量少地改动完成以上的需求
问题openshift默认的BuildConfig如果设置为jenkinsPipelineStrategy策略，将会在当前project下查找jenkins服务，如果没有的话，将会使用master-config中设置的默认jenkins模板所在位置在当前project下创建一个新的jenkins应用，便使用该应用执行相关的pipeline。每个项目都会创建一个新的jenkins。
解决思路
禁用Openshfit默认的JenkinsPipeline机制，不在当前项目下面自动创建Jenkins
在创建一个新的project时，创建名为jenkins的service，同时将它指向公共的Jenkins服务。
同时为了在当前Project界面下能够跳转到jenkins的界面，再创建一个jenkins Route，支持跳转到jenkins进行查看运行日志与过程 ...
Openshift-Network-QoS——Pod网络控制
Pod网络（速）控制的必要性高速公路上，当流量大时，如果汽车仍然不限制速度的话，将会很容易发生车祸，我们都会自觉地减速缓慢通过，只有减速才能安全行驶。在平台的集群中也是一样，一台主机上会有大量容器运行，容器相当于高速速上的汽车，对外的网络通信都使用主机出口这条高速路，如果某（几）个容器突然访问流量大增，而且没有作任何网络限速，会占用了主机的网络，严重影响其它容器的网络，进而影响其它业务。
前提
Openshift打开多租户网络模式修改/etc/origin/master/master-config.yaml将networkPluginName设置为redhat/openshift-ovs-multitenant12345... hostSubnetLength: 9 networkPluginName: redhat/openshift-ovs-multitenant serviceNetworkCIDR: 172.30.0.0/16...
如果已存在的集群，切换网络策略，请参考Openshift网络插件动态切换
为Pod添加网络限 ...
Openshift-Nginx-Router替换默认Haproxy-Router
什么是Router
Router在Openshift集群的一个不可非常重要的组件，它作为外部请求访问集群内部资源的入口，为Openshift上的应用提供边缘负载均衡。
Router可以为应用提供HTTP和websocket流量的负载均衡，同时支持HTTPS连接。Openshift上有一个特殊的资源叫Route，通过它可以方便地配置Router。
Openshift集群默认使用Haproxy应用作为Router的实现，它通过容器的形式运行在相应的Node上，同时Router Pod网络使用的宿主机的网络，即hostNetwork=true。
除了Haproxy,我们还可以使用Nginx来实现Router，这也是本文的重点。
不管是Haproxy还是Nginx方案都是使用了软件负载均衡器，还可以使用F5等硬件负载均衡器来替换Router，达到性能的提升。
Nginx Router与默认Router比较
如何替换Openshift默认Router卸载当前Router
用system:admin登录集群1$ oc login -u system:admin
选择default项目1$ o ...
Openshift-Route证书HTTPS配置
后台应用为http服务Termination Type: EdgeInsecure Traffic: Allow
后台应用为https服务Termination Type: PassthroughInsecure Traffic: None