新搭建的Kubernetes集群如何承接外部访问的流量,是刚上手Kubernetes时常常会遇到的问题。 在公有云上,官方给出了比较直接的答案,使用LoadBalancer
类型的Service,利用公有云提供的负载均衡服务来承接流量, 同时在多台服务器之间进行负载均衡。而在私有环境中,如何正确的将外部流量引入到集群内部,却暂时没有标准的做法。 本文将介绍一种基于IPVS来承接流量并实现负载均衡的方法,供大家参考。
IPVS
IPVS是LVS项目的一部分,是一款运行在Linux kernel当中的4层负载均衡器,性能异常优秀。 根据这篇文章的介绍,使用调优后的内核,可以轻松处理每秒10万次以上的转发请求。目前在中大型互联网项目中, IPVS被广泛的使用,用于承接网站入口处的流量。
Kubernetes Service
Service是Kubernetes的基础概念之一,它将一组Pod抽象成为一项服务,统一的对外提供服务,在各个Pod之间实现负载均衡。 Service有多种类型,最基本的ClusterIP
类型解决了集群内部访问服务的需求,NodePort
类型通过Node节点的端口暴露服务, 再配合上LoadBalancer
类型所定义的负载均衡器,实现了流量经过前端负载均衡器分发到各个Node节点暴露出的端口, 再通过iptables
进行一次负载均衡,最终分发到实际的Pod上这个过程。
在Service的Spec中,externalIPs
字段平常鲜有人提到,当把IP地址填入这个字段后,kube-proxy
会增加对应的iptables
规则, 当有以对应IP为目标的流量发送到Node节点时,iptables
将进行NAT,将流量转发到对应的服务上。一般情况下, 很少会遇到服务器接受非自身绑定IP流量的情况,所以externalIPs
不常被使用,但配合网络层的其他工具,它可以实现给Service绑定外部IP的效果。
今天我们将使用externalIPs
… 阅读全文
【编者的话】微服务和容器化给复杂应用部署与管理带来了极大的挑战。Helm是目前Kubernetes服务编排领域的唯一开源子项目,做为Kubernetes应用的一个包管理工具,可理解为Kubernetes的apt-get / yum,由Deis 公司发起,该公司已经被微软收购。Helm通过软件打包的形式,支持发布的版本管理和控制,很大程度上简化了Kubernetes应用部署和管理的复杂性。
随着业务容器化与向微服务架构转变,通过分解巨大的单体应用为多个服务的方式,分解了单体应用的复杂性,使每个微服务都可以独立部署和扩展,实现了敏捷开发和快速迭代和部署。但任何事情都有两面性,虽然微服务给我们带来了很多便利,但由于应用被拆分成多个组件,导致服务数量大幅增加,对于Kubernetest编排来说,每个组件有自己的资源文件,并且可以独立的部署与伸缩,这给采用Kubernetes做应用编排带来了诸多挑战:
管理、编辑与更新大量的K8s配置文件
部署一个含有大量配置文件的复杂K8s应用
分享和复用K8s配置和应用
参数化配置模板支持多个环境
管理应用的发布:回滚、diff和查看发布历史
控制一个部署周期中的某一些环节
发布后的验证
Helm把Kubernetes资源(比如deployments、services或 ingress等) 打包到一个chart中,而chart被保存到chart仓库。通过chart仓库可用来存储和分享chart。Helm使发布可配置,支持发布应用配置的版本管理,简化了Kubernetes部署应用的版本控制、打包、发布、删除、更新等操作。
本文简单介绍了Helm的用途、架构与实现。
Helm产生原因
利用Kubernetes部署一个应用,需要Kubernetes原生资源文件如deployment、replicationcontroller、service或pod 等。而对于一个复杂的应用,会有很多类似上面的资源描述文件,如果有更新或回滚应用的需求,可能要修改和维护所涉及的大量资源文件,且由于缺少对发布过的应用版本管理和控制,使Kubernetes上的应用维护和更新等面临诸多的挑战,而Helm可以帮我们解决这些问题。
Helm架构
Helm基本架构如下:
Helm用途:
做为Kubernetes的一个包管理工具,Helm具有如下功能:
创建新的chart
chart打包成tgz格式
上传chart到chart仓库或从仓库中下载chart
在Kubernetes集群中安装或卸载chart
管理用Helm安装的chart的发布周期
Helm有三个重要概念:
chart:包含了创建Kubernetes的一个应用实例的必要信息
config:包含了应用发布配置信息
release:是一个chart及其配置的一个运行实例
Helm组件
Helm有以下两个组成部分:
Helm Client是用户命令行工具,其主要负责如下:
本地chart开发
仓库管理
与Tiller sever交互 … 阅读全文
BIND主配置文件由named进程运行时首先读取,文件名为named.conf,默认在/etc目录下。该文件只包括Bind的基本配置,并不包含任何DNS的区域数据。named.conf配置文件由语句与注释组成,每一条主配置语句均有自己的选项参数。这些选项参数以子语句的形式组成,并包含在花括号内,作为主语句的组成部分。每一条语句,包括主语句和子语句,都必须以分号结尾。注释符号可以使用类似于C语言中的块注释”/*”和”*/”符号对,以及行注释符”//”或”#”。BIND 9支持的主配置语句及功能如下表:
配置名 称
功 能
acl
定义一个访问控制列表,用于以后对列表中的IP进行访问控制
controls
定义有关本地域名服务器操作的控制通道,这些通道被rndc用来发送控制命令
include
把另一个文件中的内容包含进来做为主配置文件的内容
key
定义一个密匙信息,用于通过TSIG进行授权和认证的配置中
logging
设置日志服务器,以及日志信息的发送位置
options
设置DNS服务器的全局配置选项
server
定义了与远程服务器交互的规则
trusted-keys
定义信任的 DNSSED密匙
view
定义一个视图
zone
定义一个区域
其中:logging是有关日志配置的主语句,可以有众多的子语句,指明了日志记录的位置、日志的内容、日志文件的大小和日志的级别等内容,上一节我们已经讲过。
1.options语句
options语句设定可以被整个BIND使用的全局选项。这个语句在每个配置文件中只有一处,如果出现多个options语句,则第一个options的配置有效,并且会产生一个警告信息。如果没有options语句,每个子语句使用默认值。2.controls语句
controls主语句定义有关本地域名服务器操作的控制通道,这些通道被rndc用来发送控制命令。在上节的例子named.conf配置文件中有以下语句,现解释如下:
controls {
inet 127.0.0.1 port 953 //在127.0.0.1接口的953号端口进行监听
allow { … 阅读全文
容器技术火遍技术界,很多公司包括传统行业企业都已经从观望者转变为采用者。作为最早期采用容器技术的一批先锋者,京东从 2015 年的 9 千多实例扩大到如今容器作为业务上线默认选项,支撑全部业务运行以及中间件、数据库等。此外,在经历了从 OpenStack 到 Kubernetes 的迁移转变之后,京东容器引擎平台已经从 1.0 迭代到 2.0 版本,并且于今年陆续开源数个项目。
罗马不是一天建成的。
积累如此久并且支撑过 618 大促的京东容器技术是怎样的?有哪些革新又有哪些值得业界学习呢?已经开源的项目是怎样的呢?
容器技术整体概况
今年随着京东业务的飞速发展,京东容器数量上也对应迅速增加。不仅在去年完成京东业务全面运行在 JDOS 容器之上,并且在数据库,中间件等系统也全面容器化。同时,在这一年,京东上线了 JDOS 2.0 系统,开始了从 OpenStack 向 Kubernetes 的迁移。截止到 6 月 7 日,已经有 60% 的业务运行在了 JDOS 2.0 平台中。
此外不得不提及发生的主要变化:业务系统全面基于容器镜像全量上线发布;全面使用集群编排;在生产环境尝试和运行抢占式调度,并自研单层单体全局调度器 SchedulerX;让业务系统与硬件解耦与资源完全解耦,海量资源,从容大促。
自研单层单体全局调度器 … 阅读全文
SDN是Software-defined networking的缩写。在许多介绍Kubernetes的文档,特别是安装文档中, 当介绍到Kubernetes所需的容器网络时常常会提到这个缩写,告知用户需要使用某种SDN技术用以解决“每个Pod有独立IP, Pod之间可以不经过NAT直接互访”这一Kubernetes集群最基本的技术要求。
大多数非网络工程师背景的技术人员对SDN这个概念会比较陌生,当读到这个段落时,往往会选择把它当作Kubernetes的底层依赖, 照着文档所推荐的流程安装一款SDN工具,比如Flannel,Calico,Weave等。由于不了解这些工具的原理,同时缺乏实际的使用经验, 当出现文档以外的异常情况时,整个安装流程就卡住了。SDN俨然成为了Kubernetes大规模普及的拦路虎。那些按照文档顺利搭建起来的集群当中,还有不少使用了并不适合该集群所处环境的SDN技术,造成了额外的运维负担以及潜在的安全风险。 让我们不得不思考一个问题,怎样才是正确的在Kubernetes集群中使用SDN技术的方法?
今天我们来详细聊聊这个话题。
结论先行
在大多数的Kubernetes集群中,都不需要使用SDN技术,Kubernetes的容器网络要求可以使用更加简单易懂的技术来实现, 只有当企业有特定的安全或者配置要求时,才需要使用SDN技术。SDN应当作为一个附加选项,用以解决特定的技术问题。
理解Kubernetes的容器网络
下图是一张Kubernetes容器网络的示意图
可以看到在图中,每台服务器上的容器有自己独立的IP段,各个服务器之间的容器可以根据目标容器的IP地址进行访问。
为了实现这一目标,重点解决以下这两点:
各台服务器上的容器IP段不能重叠,所以需要有某种IP段分配机制,为各台服务器分配独立的IP段
从某个Pod发出的流量到达其所在服务器时,服务器网络层应当具备根据目标IP地址将流量转发到该IP所属IP段所对应的目标服务器的能力。
总结起来,实现Kubernetes的容器网络重点需要关注两方面,分配和路由。
Flannel的工作方式
这里我们以比较常见的Flannel为例子,看看SDN系统是如何解决分配和路由的问题的。
下图是Flannel的架构示意图
可以看到Flannel依赖etcd实现了统一的配置管理机制。当一台服务器上的Flannel启动时,它会连接所配置的etcd集群, 从中取到当前的网络配置以及其他已有服务器已经分配的IP段,并从未分配的IP段中选取其中之一作为自己的IP段。 当它将自己的分配记录写入etcd之后,其他的服务器会收到这条新记录,并更新本地的IP段映射表。
Flannel的IP段分配发生在各台服务器上,由flannel进程将结果写入到etcd中。路由也由Flannel完成,网络流量先进入Flannel控制的Tunnel中, 由Flannel根据当前的IP段映射表转发到对应的服务器上。
需要指出的是Flannel有多种backend,另外新增的kube-subnet-mgr参数会导致Flannel的工作方式有所不同,在这里就不详细展开了。 有兴趣的朋友可以去查阅Flannel的文档以及源代码了解更多的细节。
更见简化的网络配置方法
Flannel的工作方式有2点是需要注意的。一是所有服务器上运行的Flannel均需要etcd的读写权限,不利于权限的隔离和安全防护。 二是许多教程中所使用的默认backend类型为vxlan,虽然它使用了内核中的vxlan模块,造成的性能损失并不大, 但是在常见的二层网络的环境中,其实并不需要使用Tunnel技术,直接利用路由就可以实现流量的转发, 这时使用hostgw模式就可以达成目标。
大部分的Kubernetes集群服务器数量并不会超过100台,不论是在物理机房当中或是利用IaaS提供的VPC技术,我们会把这些服务器均放在同一个网段, 这时我们可以去掉Flannel这一层,直接使用Kubernetes内置的kubenet功能,配合上我们为Kubernetes定制的hostroutes工具, 即可实现容器网络的要求。
kubenet
kubenet是kubelet内置的网络插件中的一个,它非常的简单,会根据当前服务器对应的Node资源上的PodCIDR字段所设的IP段,配置一个本地的网络接口cbr0, 在新的Pod启动时,从IP段中分配一个空闲的IP,用它创建容器的网络接口,再将控制权交还给kubelet,完成后续的Pod创建流程。… 阅读全文
洪晓露 2020-08-27 15:51:59 78 收藏
文章标签: docker https centos linux git
版权
本文永久链接: https://www.xtplayer.cn/rancher/install/single-node-install-custom-ssl/
在线安装
Rancher 安装也可以使用自己生成的自签名证书,如果没有自签名证书,可通过脚本一键生成自签名 ssl 证书。
docker_data_dir=xxxx # 定义绝对路径
mkdir -p ${docker_data_dir}/data # rancher 数据目录
mkdir -p ${docker_data_dir}/auditlog # 审计日志目录
mkdir -p ${docker_data_dir}/ssl # 自定义 CA 证书目录… 阅读全文
HTTP over SSL
要保证 Web 浏览器到服务器的安全连接,HTTPS 几乎是唯一选择。HTTPS 其实就是 HTTP over SSL,也就是让 HTTP 连接建立在 SSL 安全连接之上。
SSL 使用证书来创建安全连接,有两种验证模式:
仅客户端验证服务器的证书,客户端自己不提供证书;
客户端和服务器都互相验证对方的证书。
一般第二种方式用于网上银行等安全性要求较高的网站,普通的 Web 网站只采用第一种方式。
web 服务的证书必须经过某权威
证书的签名,而这个权威
证书又可能经过更权威的证书签名。这么一级一级追溯上去,最顶层那个最权威的证书就称为根证书 ,根证书一般内置在浏览器中。这样,浏览器就可以利用自己自带的根证书去验证某个 web 服务的证书是否有效。如果要提供一个有效的证书,web 服务的证书必须从 VeriSign
这样的证书颁发机构签名。这样,浏览器就可以验证通过,否则浏览器给出一个证书无效的警告。一般安全要求较高的内网环境,可以通过创建自签名 SSL 证书来加密通信。
数字证书(Certificate)
在
… 阅读全文
本节将主要针对常用的几种特殊(直接域名、泛域名与子域)的域名解析记录介绍。
一、直接域名
许多用户有直接使用域名访问Web网站的习惯,即在浏览器中不输入www等主机名,而是直接使用如http://baidu.com/或http://csdn.net/等域名来访问。然而,并不是所有的Web网站都支持这种访问方式,只有DNS服务器能解析直接域名的网站才可以使用。可以在csdn.net区域文件中加入以下内容实现直接域名解析。
csdn.net. 600 IN A 114.112.73.194
此时,域名csdn.net可以解析为114.112.73.194,与www.csdn.net域名的解析结果一样,配置如下:
www.csdn.net. 600 IN A 114.112.73.194
csdn.net. 600 IN A 114.112.73.194
二、泛域名
如果在shop.taobao.com中加入以下语句,还可以实现一种泛域名的效果。
*.shop.taobao.com. 1800 IN CNAME shop.taobao.com.
泛域名是指一个域名下的所有主机和子域名都被解析到同一个地址上。在以上配置中,所有以”.shop.taobao.com”为后缀的域名的地址都将解析为shop.taobao.com。另外,默认情况下泛域名解析的优先级最高,如果区域文件中存在其他主机的资源记录,它们都将失效。图中所示的是泛域名的测试结果。
从图中可以看到,不管采用什么样的主机名,只要后缀是”.shop.taobao.com”,地址都将解析为shop.taobao.com。
三、子域
子域(Subdomain),是域名层次结构中的一个术语,是对某一个域进行细分时的下一级域。例如,shop.taobao.com是一个顶级域名,可以把aaa.shop.taobao.com配置成是它的一个子域。配置子域可以有两种方式,一种是把子域配置放在另一台DNS服务器上,还有一种是子域配置与父域配置放在一起,此时也称为虚拟子域。
配置如:
$ORIGIN shop.taobao.com.
*.shop.taobao.com. 1800 IN CNAME shop.taobao.com.
转至:http://book.51cto.com/art/200912/169363.htm… 阅读全文