Rancher

日前，VMware在VMworld 2019大会上宣布，VMware计划推出全新的产品和组合服务VMware Tanzu。Rancher Labs联合创始人及CEO梁胜参加了 VMworld 2019，并于Blog上发表了对于这一事件的思考及观点。文章译编时有修改。 原文标题： And Then There were Three--IBM, VMware, and Rancher 原文链接： https://rancher.com/blog/2019/and-then-there-were-three 当我们在2014年创建Rancher的时候，我们的愿景就是帮助企业IT更便捷且自由地从任何基础设施提供商中获取和利用计算资源。云计算时代，计算资源常被称为“牛”，这也是我们将公司及产品命名为“Rancher（牧场主）”的原因。极其幸运的是，随着技术的不断发展，我们能够使用许多很棒的技术诸如Kubernetes，因而能够提供给客户跨越任何基础架构的计算资源的一致性访问能力。时至今日，我们仍然坚定不移地保持自己的愿景和初心，而且Rancher如今已经成为IT业界最领先和功能最完善强大的Kubernetes管理平台。数以万计的企业依赖Rancher平台来管理自己在生产环境中的部署关键应用的众多Kubernetes集群。作为Rancher的一员，我们为今天如此的成就感到无比骄傲和自豪。 在此

据Sysdig发布的容器报告，容器以及如Kubernetes等编排工具的使用增长了５１％以上，大家开始将工作负载在集群中进行托管并管理。鉴于集群中短暂的状态，对于端到端的集群有一个十分重要的需求，即能够详细监控节点、容器以及pod。 IT工程师需要管理应用程序、集群（节点和数据），并且需要减少手动配置service、目标和数据存储的工作量，同时在应用程序每次关闭和返回时进行监控。这就需要一个无缝部署以及管理高可用监控系统（如Prometheus），其中可以与Operator一起处理抓取目标的动态配置、服务发现以及用于告警集群中各种目标的配置规则。同时，使用Operator模式编写代码以减少人工干预。 本文，我们将关注Prometheus Operator是如何工作的，service monitor在Prometheus Operator中是如何发现目标和获取指标的。 在集群监控中Prometheus Operator所扮演的角色 能够使用原生Kubernetes配置选项无缝安装Prometheus Operator 能够在Kubernetes命名空间中创建和摧毁一个Prometheus实例，某个特定的应用程序或者团队能够轻松地使用Operator 能够预配置配置文件，包括Kubernetes资源的版本、持久性、保留策略和replica 能够使用标签发现目标service

官网参考： https://rancher.com/docs/k3s/latest/en/quick-start/ K8S非常消耗资源，在性能一般的机器上不适合部署。K8S的精简版K3S就是为了针对这种情况，将很多性能一般的机器（例如树莓派）加入到集群 1 安装raspberry操作系统 默认用户名/密码：pi/raspberry 1.1 修改主机名 sudo hostnamectl set-hostname node1 1.2 设置root密码 sudo passwd root 1.3 启用root进行远程连接 sudo vi /etc/ssh/sshd_config 增加一行： PermitRootLogin yes 设置开启自启ssh+重启：systemctl enable ssh && systemctl restart ssh 1.4 调整主机时间为最新时间 集群的所有主机的时间必须保证不能差太多，否则https会出现证书错误等等异常 date -s "2019-11-25 15:21:21" 1.5 修改默认的vi配置（上下左右和backspace键混乱） vi /etc/vim/vimrc.tiny 修改set compatible，将其改为set nocompatible 再添加一行：set backspace=2 1.6（可选） 以root用户登录

介 绍 Kubernetes在Github上拥有超过4万颗星，7万以上的commits，以及像Google这样的主要贡献者。Kubernetes可以说已经快速地接管了容器生态系统，成为了容器编排平台中的真正领头羊。 理解Kubernetes和它的Abstractions 在基础设施层，Kubernetes集群好比是一组扮演特定角色的物理或虚拟机器。其中扮演Master角色的机器作为全部操作的大脑，并由运行在节点上的编排容器控制。 Master组件管理pod的生命周期，pod是Kubernetes集群中部署的基本单元。pod完成周期，Controller会创建一个新的。如果我们向上或向下（增加减少）Pod副本的数量，Controller会相应的创建和销毁pod来满足请求。Master角色包含了下面组件： °kube-apiserver – 为其他master组件提供APIs °etcd – 具有一致性且高可用的key/value存储，用于存储所有内部集群数据 °kube-scheduler – 使用pod规范中的信息来确定运行pod的节点 °kube-controller-manager – 负责节点管理（检测节点是否失败）、pod复制和端点创建 °cloud-controller-manager – 运行与底层云提供商交互的controller

北京时间9月19日，Kubernetes发布了一个编号为CVE-2019-11251的漏洞，该漏洞被标记为中等安全问题。其影响的Kubernetes版本为v1.13.10、v1.14.6和v1.15.3。经过分析，Rancher安全风险评估团队认为，此次Kubernetes CVE不会影响Rancher产品的安全问题，因此无需立即发布2.1.x和2.2.x版本，且我们将在下一个季度的第一个维护版本中升级Rancher UI中使用的kubectl版本。 CVE-2019-11251 如果您无法确定自己使用的版本是否受到安全漏洞的影响，您可以运行kubectl version –client这一命令，如果它返回的Kubernetes版本为v1.13.10、v1.14.6 和 v1.15.3，那么建议您尽快升级，详情参阅： https://kubernetes.io/docs/tasks/tools/install-kubectl/ 漏洞详情 这一漏洞和CVE-2019-1002101以及CVE-2019-11246十分类似。该漏洞允许两个symlink的组合将文件复制到其目标目录之外。这使得攻击者可以使用目标树之外的symlink放置netfarious文件。 在Kubernetes 1.16中，通过移除在kubectl cp中对symlink的支持修复了这一问题

北京时间2019年10月17日，Kubernetes发布了新的补丁版本，修复了新近发现的两个安全漏洞：CVE-2019-11253和CVE-2019-16276。Rancher第一时间响应，就在当天紧随其后发布了Rancher v2.3.1和Rancher v2.2.9。更新的版本中不仅支持Kubernetes新的补丁版本，还修复了一些原有的bug并对部分功能进行了优化。 目前，Rancher的Latest和Stable版本信息如下： Kubernetes CVE漏洞详情 CVE-2019-11253： CVE-2019-11253是kube-apiserver中的一个拒绝服务漏洞，它允许授权用户发送恶意的YAML或JSON有效负载，然后导致kube-apiserver消耗过多的CPU或内存，从而可能崩溃并变得不可用。 CVE-2019-16276： 在Go的net/ http库中CVE-2019-16276会导致无效的请求头被HTTP服务器规范化并解释为有效。如果Go HTTP服务器前的反向代理允许并转发某无效的请求头，但又不对其进行规范化，则Go服务器对这些请求头的解释可能与反向代理不同。 Kubernetes发布了下述这些新版本，解决上述安全漏洞： v1.13.12 v1.14.8 v1.15.5 v1.16.2 为了您的集群安全

本周三晚20:30，Kubernetes Master Class在线培训第三期《Kubernetes应用商店：Harbor与Istio》即将开播，进入 http://live.vhall.com/231749318 即可免费预约注册！ 美国著名的企业生产力解决方案领先供应商Workiva，投入使用开源的企业级Kubernetes管理平台Rancher，通过无缝连接到Rancher，指数级减少了构建和部署容器及Kubernetes服务所需的时间和精力。本文将分享Workiva的需求与痛点、以及他们的经验。 Workiva是美国著名的互联数据、报告和合规解决方案的领先云提供商（纽约证券交易所上市代码 NYSE: WK）。Workiva提供直观的云平台Wdesk，帮助全球超过3000家企业实现工作方式的现代化，其中包括70％以上的财富500强(FORTUNE 500®)公司。 需求与痛点 Wdesk建立在数据管理引擎上，提供受控协作、数据连接、细化权限和完整的审计轨迹，有助于降低风险，提高生产力，让用户对数据驱动的决策充满信心。通过Rancher协调管理多个Kubernetes集群，使Wdesk能够快速满足客户日益增长的规模需求。 在选择容器管理平台时，Workiva需要一个可靠的解决方案来管理他们大量的生产工作负载，并且要求100%的零停机。同时，Workiva也需要具有复杂的

近期，Kubernetes仪表盘和外部IP代理接连被发现存在安全问题。针对这两个漏洞，Kubernetes发布了相应的补丁版本供会受漏洞影响的用户解决问题。本文将更深入解读这两个安全漏洞的原理、会对您的Kubernetes部署造成的影响以及相应的应对之策。 通过kubernetes仪表盘访问自定义TLS证书 Kubernetes仪表盘漏洞（CVE-2018-18264）会影响v1.10.0或更早的仪表盘版本。因为这一漏洞，用户可以“跳过”登录过程，假设配置的服务帐户，最后获得仪表盘所使用的自定义TLS证书。如果您已将Kubernetes仪表盘配置为需要登录并将其配置为使用自定义TLS证书，那么这一漏洞会影响到您，您需要及时注意。 该漏洞的运作原理 此漏洞可以分为两部分来解释。 第一个是，因为登陆时用户可以选择“跳过”这一选项，那么任何用户都可以绕过登录过程，该过程在v1.10.0或更早版本中始终默认启用。这样一来，用户就完全跳过登录过程并能使用仪表盘配置的服务帐户。 第二个是，使用仪表盘配置的服务帐户，必须最低限度地有权限访问自定义TLS证书（以secret的形式存储）。未经身份验证的登录，加上仪表板使用配置的服务帐户来检索这些secret的能力，组合在一起的结果就是这一安全问题。 使用仪表盘v1.10.1补丁时，默认情况下将不再启用“跳过”选项

今天，Kubernetes发布了一系列补丁版本，修复新近发现的两个安全漏洞CVE-2019-1002101（kubectl cp命令安全漏洞）和CVE-2019-9946（CNI端口映射插件漏洞）。Rancher也紧急更新，发布一系列新版以支持Kubernetes补丁版本。 本文将介绍CVE-2019-1002101和CVE-2019-9946的详情、原理、受影响版本及升级建议，以及Rancher提供给用户的应对之策。 CVE-2019-1002101 漏洞详情及原理 CVE-2019-1002101是kubectl cp命令中存在的安全漏洞，严重等级为【高】，攻击者可以使用kubectl cp命令替换或删除用户工作站上的文件，在用户计算机的任何路径上写入恶意文件。 kubectl cp命令允许在容器和用户计算机之间复制文件。为了从容器中复制文件，Kubernetes会在容器内创建一个tar，通过网络复制它，然后kubectl会在用户的机器上解压缩它。 而如果容器中的tar二进制文件是恶意的，它可以运行任何代码并输出意外的恶意结果。在用户调用kubectl cp时，攻击者可以使用它将文件写入用户计算机上的任何路径，只有本地用户的系统权限有可能限制这一操作。 受影响的版本及升级建议 什么版本用户会被此次漏洞影响？试着运行kubectl version—client进行查看，除了1