由HorizontalPodAutoscaler对象定义的横向pod自动伸缩器(autoscaler)指定系统应如何根据从属于该复制控制器(replication controller)或部署配置(deployment configuration)的pod收集的度量标准(metrics)自动增加或减少复制控制器或部署配置的规模。
Red Hat OpenShijft Container Platform (OpenShift)是一个容器应用程序平台,它为开发人员和IT组织提供了一个云应用程序平台,用于在安全的、可伸缩的资源上部署新应用程序,而配置和管理开销最小。
随着企业越来越多地了解到部署容器化应用程序的优点,有必要纠正 JVM 在云中表现不好的误解,尤其是在内存管理方面。虽然许多JVM可能不能完美地配置成在弹性云环境中运行,但各种可用的系统属性允许对JVM进行调优,以帮助最大限度地利用其主机环境。如果一个容器化的应用程序是使用OpenShift部署的,那么该应用程序可以利用Kubernetes Vertical Pod Autoscaler (VPA),这是一个alpha特性。VPA就是一个例子,JVM的默认内存管理设置可能会降低在云中运行应用程序的好处。这篇博文将介绍配置和测试一个与VPA一起使用的容器化Java应用程序的步骤,这将演示JVM在云中运行时的适应性。
RC确保pod指定数量的副本一直运行。如果pod被杀死或被管理员显式删除,复制控制器将自动部署相应的pod。类似地,如果运行的pod数量超过所需的数量,它会根据需要删除pod,以匹配指定的副本计数。
事件驱动的计算并不是什么新生事务。数据库世界中的人们使用数据库触发器已有多年了。这个概念很简单: 每当您添加,更改或删除数据时,都会触发一个事件以执行各种功能。新的事件是这些类型的事件和触发器在其他领域的应用程序中激增,例如自动扩展,自动修复,容量规划等。事件驱动架构的核心是对系统上的各种事件做出反应并采取相应的行动。
OpenShift被其供应商Red Hat称为“ 企业级Kubernetes”。其实Kubernetes是OpenShift不可或缺的一部分,并围绕它构建了更多功能。
Zipkin使用MySQL数据库进行存储,这反过来又需要创建一个OpenShift 共享存储。假定已经有了:
用于调度,并控制pod不能在计算资源少于指定数量的情况下运行。调度程序试图找到一个具有足够计算资源的节点来满足pod请求。
前言 之前,笔者发表的《非开发人员看Devops--从一张图谈起》的文章,在不到24小时内,阅读量已经达到1100,说明大家对DevOps和OpenShift此还是很感兴趣的。 笔者另外一篇文章《同时面向运维和开发的企业级PaaS平台--OpenShift》,介绍了OpenShift的相关概念和架构,并截取了在实验中的操作截图。很多朋友反映图比较小,看不清楚,而且命令行显示相对比较枯燥,因此这次笔者展示红帽公司技术专家陈耿的OpenShift视频,以便理解。如果读者对OpenShift此前不了解的话,在
大卫说:笔者在年初分享过一篇文章《大卫看Docker-第一篇》。文中介绍了Docker一些基本概念。本文同时作为《大卫看Docker-第二篇》而存在。 随着容器技术的兴起,越来越多的人都在
OpenShift 支持 RBAC(Role Based Access Controll),基于角色的访问控制。它涉及诸多概念,本文尝试着做一些概念上的梳理,很多细节还需要进一步研究。
我们的文章包括了MySQL on Kubernetes在不同平台不同场景下的情况。相关文章的列表如下:
默认情况下,Docker网络使用仅使用主机虚机网桥bridge,主机内的所有容器都连接至该网桥。连接到此桥的所有容器都可以彼此通信,但不能与不同主机上的容器通信。通常,这种通信使用端口映射来处理,其中容器端口绑定到主机上的端口,所有通信都通过物理主机上的端口路由。
理解OpenShift(5):从 Docker Volume 到 OpenShift Persistent Volume
一、Openshift3.9发布 今天,Openshift3.9正式发布。 Openshfit3.9对应Docker的版本是1.13,对应Kubernetes 1.9。 我们看一下与OCP3.6和3.
Kubernetes 环境下的 Istio 使用了 Sidecar 模型进行部署,把一个辅助容器(也就是 Sidecar)附加到业务 Pod 之中。这一过程让 Sidecar 容器和业务容器共享同样的网络栈,可以视为同一主机上的两个进程。这样一来,Istio 就能够接管业务应用的所有网络调用,就有了增强服务间通信能力的基础。
红帽OpenShift 4.6最新版刚出来, 最新的监控技术栈经过了较大的调整并且GA(生产可用)了.
我们将评估这种系统的期望特性。在此基础上,我们将尝试比较目前使用的两个最流行的容器编排系统Apache Mesos和Kubernetes。
前言 本文仅代表原作者PanMichael的个人观点。 在Openshift的技术交流中,我认识了陈沙克。作为Openshift的用户,陈总对Openshift的理解程度很深。本文为沙克公司的同事所写,已取得授权转载。 大魏注: 文章中所提的南北流量,实际上就是客户端对应用FQDN发起访问,通过Openshift的router解析的过程。在Openshift中,有router的概念。router的作用是对外暴露service的FQDN。 那么,router的本质是什么? router本质上,一个route
OCP将OpenShift集群中的为由主节点管理的对象统称为资源,如:node、service、pod、project、deployment、user。
聂健是大魏的红帽同事,本文已获得授权转载,欢迎读者阅读他的技术blog:https://www.cnblogs.com/ericnie/
注:不建议使用openshift 1.11(即kubernetes 3.11)安装istio,可能会出现如下兼容性问题,参见此issue
容器的SDN 很多人都说2017将是容器年,大卫也这么认为。但在很长一点时间里,容器与虚拟化都是相互依存,相互补充的问题。 之前笔者发表过一篇文章,放开眼界,看看开源界的新动向。里面清晰描述了未来两年内,整个开源界将会被主流目标客户采用的几项技术: High-Performance Message Infrastructure、Interoperable Storage Encryption Private IaaS、Container Networking、Open-Source Virtualizati
由于我是在自己笔记本上建了两台虚机,资源有限,这里就拿双节点模拟一下集群,其中master节点也是计算节点、infra节点,运行etcd和nfs。node节点运行etcd和lb。
持续交付 如果要打造一个持续交付的流水线,首先要考虑多环境的问题。一般一个应用程序会有多个环境,比如开发环境、集成测试环境、系统测试环境、用户验收测试环境、类生产环境、生产环境。如何在OpenShif
API Manager和API网关公有云托管方式。客户将自己的API后端集成到API网关
随着环境中运行的微服务数量的增加,主动监控微服务的所有实例的运行状况变得更加重要。使用像OpenShift这样的容器管理技术,可以利用运行状况检查,来自动决定是否使用新容器来丢弃和替换不健康的容器。通过快速更换不健康的容器,OpenShift极大地提高了服务的整体正常运行时间。
在本系列的第三篇文章中,我介绍了Kubernetes的基础知识:首先学习如何驱动,我强调您应该学会驱动Kubernetes,而不是构建它。我还解释了在Kubernetes中为应用程序建模必须学习的基本元素是最少的。我想强调这一点:您需要学习的原语集是您可以学习的最简单的原语集,以实现生产质量的应用程序部署(即高可用性[HA],多个容器,多个应用程序)。换句话说,学习Kubernetes内置的一组原语比学习集群软件,集群文件系统,负载平衡器,疯狂的Apache配置,疯狂的Nginx配置,路由器,交换机,防火墙和存储后端要容易得多,这一切您将需要在传统IT环境(用于虚拟机或裸机)中为简单的HA应用程序建模。
关于OpenShift是什么,你可以用你喜欢的名字叫它。容器云,Kubernetes的社区发行版,基于Docker,K8s的PaaS平台,DevOps平台等等
由于篇幅和时间有限,本文还会有第二篇。 一、Openshift支持的各种SDN CNI Openshift Container Platform(简称OCP),在V3.6之前,SDN是由OVS实现的,当时也只支持OVS。 OCP从V3.6开始,正式支持多种容器网络接口,Container Network Interface 简称CNI。CNI可以作为第三方插件,部署到OCP上。当然,OCP默认还是使用OVS,除非在安装OCP时进行容器网络接口的选择。 目前OCP支持的CNI有: Cisco Contiv (
etcd 是 CoreOS 团队发起的开源项目,是一个管理配置信息和服务发现(service discovery)的项目,它的目标是构建一个高可用的分布式键值(key-value)数据库,基于 Go 语言实现。
世上的高手 世上高手大约有两种: 第一种如下图这为老先生,一辈子纵横江湖数十载,所学武功实用有效,招数简明而力道雄厚,善于“简单粗暴”迅速解决问题。在老爷子的心目中:能用黑虎掏心解决的问题,干啥非要耍
默认情况下,运行容器使用容器内的临时存储。Pods由一个或多个容器组成,这些容器一起部署,共享相同的存储和其他资源,可以在任何时候创建、启动、停止或销毁。使用临时存储意味着,当容器停止时,写入容器内的文件系统的数据将丢失。
Openshift对接云管平台的目的 Openshift是红帽一款优秀的PaaS解决方案。目前国内的行业客户,如金融、电信、制造等,在云平台的构建上,逐渐从IaaS的建设转移到PaaS上。但这并不代表IaaS已经不重要了。但是,客户构建云平台,最关键一点是,入口需要是唯一的,也就是Unified Protal,而不能IaaS一套、PaaS一套,虚拟化一套入口。因此,目前越来越多的客户,着力于构建统一的混合云架构。 CloudForms是红帽的混合云管平台,可以对接vPhere、RHV、Openstack、O
一、HA方式部署Openshift 一个典型的OCP高可用架构是:master至少应为三个,且为奇数个(上面有etcd); 基础架构节点不少于两个,上面运行日志、监控、router、INTEGRATE
OpenShift metric子系统支持捕获和长期存储OpenShift集群的性能度量,收集节点以及节点中运行的所有容器的指标。
OpenShift的OVS网络组件有三种模式:ovs-subnet、ovs-multitenant、ovs-networkpolicy。
横向比较,Openshift在全球IT圈内,Forrester最新的报告认为从技术表现和市场表现看,Openshift 3.10是业内最好的容器云平台。
在网上搜索规范化的 K8S 的部署架构图画法时,发现了 Redhat 的一篇博客。觉得非常不错,遂翻译分享之。
在Linux 系统上,当一个应用通过域名连接远端主机时,DNS 解析会通过系统调用来进行,比如 getaddrinfo()。和任何Linux 操作系统一样,Pod 的 DNS 定义在 resolv.conf 文件中,其示例如下:
干货巨献:Openshift3.9的网络管理大全.加长篇---Openshift3.9学习系列第二篇
https://docs.openshift.com/container-platform/3.11/dev_guide/pod_autoscaling.html
这个demo使用Spring Sleuth来收集tracing 数据并将其发送到OpenZipkin, OpenZipkin作为OpenShift服务部署,并由一个持久的MySQL数据库镜像支持。可以从Zipkin控制台查询tracing 数据,该控制台通过OpenShift route公开。日志集成也可以使用trace id将相同业务请求的分布式执行捆绑在一起。
一、持续交付工具链全图 上图源自网络。上图很清晰地列出了CD几个阶段使用的工具。 CD的工具链很长,但并不是每个模块所有工具都那么流行;换言之,我们在每个模块用好一种工具就足够了。 Build 在SC
书籍英文版下载链接为 https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/,作者 Burr Sutter 和 Christian Posta。
前言: 本文仅代表作者个人观点,用户生产上的Openshift网络规划,还要需要咨询红帽架构师或实施专家。本文仅作为参考,并且不对个案的结果负责。 本文的网络介绍,是基于Openshift3.6版本,此前版本的Opeshift在网络细节方面略有不同。 本文在书写过程中,咨询了红帽郭跃军、张春良、张亚光、周荣等专家,在此表示感谢! 在本文中OCP指:Openshift Container Platform、OCP Node指Openshift集群的计算节点。 整体架构 Openshift Container
在之前的文章《OpenShift企业测试环境应用部署实战》中, 介绍了把禅道部署到企业测试环境的过程. 而这次是要对禅道进行升级, 其实严格说来不仅仅升级, 而是把开源版禅道11.5 升级为 企业版禅道3.3. 本文记录了升级的全过程.
在项目迭代的过程中,不可避免需要”上线“。上线对应着部署,或者重新部署;部署对应着修改;修改则意味着风险。 目前有很多用于部署的技术,有的简单,有的复杂;有的得停机,有的不需要停机即可完成部署。本文笔者简单讨论一下目前比较流行的几种部署方案,或者说策略。如有不足之处请指出,如有谬误,请指正^_^。 Blue/Green Deployment(蓝绿部署) 蓝绿部署无需停机,并且风险较小。 (1) 部署版本1的应用(一开始的状态) 所有外部请求的流量都打到这个版本上。 (2) 部署版本2的应用 版本2的代码与版
领取专属 10元无门槛券
手把手带您无忧上云