# 边缘节点配置
## 前言
为了配置kubernetes中的traefik ingress的高可用,对于kubernetes集群以外只暴露一个访问入口,需要使用keepalived排除单点问题。本文参考了[kube-keepalived-vip](https://github.com/kubernetes/contrib/tree/master/keepalived-vip),但并没有使用容器方式安装,而是直接在node节点上安装。
## 定义
首先解释下什么叫边缘节点(Edge Node),所谓的边缘节点即集群内部用来向集群外暴露服务能力的节点,集群外部的服务通过该节点来调用集群内部的服务,边缘节点是集群内外交流的一个Endpoint。
**边缘节点要考虑两个问题**
- 边缘节点的高可用,不能有单点故障,否则整个kubernetes集群将不可用
- 对外的一致暴露端口,即只能有一个外网访问IP和端口
## 架构
为了满足边缘节点的以上需求,我们使用[keepalived](http://www.keepalived.org/)来实现。
在Kubernetes中添加了service的同时,在DNS中增加一个记录,这条记录需要跟ingress中的`host`字段相同,IP地址即VIP的地址,本示例中是`172.20.0.119`,这样集群外部就可以通过service的DNS名称来访问服务了。
选择Kubernetes的三个node作为边缘节点,并安装keepalived,下图展示了边缘节点的配置,同时展示了向Kubernetes中添加服务的过程。
![边缘节点架构](https://box.kancloud.cn/df05e48fc9567a230b46bd8d2873557d_1096x876.png)
## 准备
复用kubernetes测试集群的三台主机。
172.20.0.113
172.20.0.114
172.20.0.115
## 安装
使用keepalived管理VIP,VIP是使用IPVS创建的,[IPVS](http://www.linux-vs.org)已经成为linux内核的模块,不需要安装
LVS的工作原理请参考:http://www.cnblogs.com/codebean/archive/2011/07/25/2116043.html
不使用镜像方式安装了,直接手动安装,指定三个节点为边缘节点(Edge node)。
因为我们的测试集群一共只有三个node,所有在在三个node上都要安装keepalived和ipvsadmin。
```bash
yum install keepalived ipvsadm
```
## 配置说明
需要对原先的traefik ingress进行改造,从以Deployment方式启动改成DeamonSet。还需要指定一个与node在同一网段的IP地址作为VIP,我们指定成172.20.0.119,配置keepalived前需要先保证这个IP没有被分配。。
- Traefik以DaemonSet的方式启动
- 通过nodeSelector选择边缘节点
- 通过hostPort暴露端口
- 当前VIP漂移到了172.20.0.115上
- Traefik根据访问的host和path配置,将流量转发到相应的service上
## 配置keepalived
参考[基于keepalived 实现VIP转移,lvs,nginx的高可用](http://limian.blog.51cto.com/7542175/1301776),配置keepalived。
keepalived的官方配置文档见:http://keepalived.org/pdf/UserGuide.pdf
配置文件`/etc/keepalived/keepalived.conf`文件内容如下:
```ini
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from kaadmin@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id LVS_DEVEL
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.20.0.119
}
}
virtual_server 172.20.0.119 80{
delay_loop 6
lb_algo loadbalance
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 0
protocol TCP
real_server 172.20.0.113 80{
weight 1
TCP_CHECK {
connect_timeout 3
}
}
real_server 172.20.0.114 80{
weight 1
TCP_CHECK {
connect_timeout 3
}
}
real_server 172.20.0.115 80{
weight 1
TCP_CHECK {
connect_timeout 3
}
}
}
```
`Realserver`的IP和端口即traefik供外网访问的IP和端口。
将以上配置分别拷贝到另外两台node的`/etc/keepalived`目录下。
我们使用转发效率最高的`lb_kind DR`直接路由方式转发,使用TCP_CHECK来检测real_server的health。
设置keepalived为开机自启动:
```bash
chkconfig keepalived on
```
**启动keepalived**
```
systemctl start keepalived
```
三台node都启动了keepalived后,观察eth0的IP,会在三台node的某一台上发现一个VIP是172.20.0.119。
```bash
$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether f4:e9:d4:9f:6b:a0 brd ff:ff:ff:ff:ff:ff
inet 172.20.0.115/17 brd 172.20.127.255 scope global eth0
valid_lft forever preferred_lft forever
inet 172.20.0.119/32 scope global eth0
valid_lft forever preferred_lft forever
```
关掉拥有这个VIP主机上的keepalived,观察VIP是否漂移到了另外两台主机的其中之一上。
## 改造Traefik
在这之前我们启动的traefik使用的是deployment,只启动了一个pod,无法保证高可用(即需要将pod固定在某一台主机上,这样才能对外提供一个唯一的访问地址),现在使用了keepalived就可以通过VIP来访问traefik,同时启动多个traefik的pod保证高可用。
配置文件`traefik.yaml`内容如下:
```yaml
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: traefik-ingress-lb
namespace: kube-system
labels:
k8s-app: traefik-ingress-lb
spec:
template:
metadata:
labels:
k8s-app: traefik-ingress-lb
name: traefik-ingress-lb
spec:
terminationGracePeriodSeconds: 60
hostNetwork: true
restartPolicy: Always
serviceAccountName: ingress
containers:
- image: traefik
name: traefik-ingress-lb
resources:
limits:
cpu: 200m
memory: 30Mi
requests:
cpu: 100m
memory: 20Mi
ports:
- name: http
containerPort: 80
hostPort: 80
- name: admin
containerPort: 8580
hostPort: 8580
args:
- --web
- --web.address=:8580
- --kubernetes
nodeSelector:
edgenode: "true"
```
注意,我们使用了`nodeSelector`选择边缘节点来调度traefik-ingress-lb运行在它上面,所有你需要使用:
```
kubectl label nodes 172.20.0.113 edgenode=true
kubectl label nodes 172.20.0.114 edgenode=true
kubectl label nodes 172.20.0.115 edgenode=true
```
给三个node打标签。
查看DaemonSet的启动情况:
```Bash
$ kubectl -n kube-system get ds
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR AGE
traefik-ingress-lb 3 3 3 3 3 edgenode=true 2h
```
现在就可以在外网通过172.20.0.119:80来访问到traefik ingress了。
## 使用域名访问Kubernetes中的服务
现在我们已经部署了以下服务:
- 三个边缘节点,使用Traefik作为Ingress controller
- 使用keepalived做的VIP(虚拟IP)172.20.0.119
这样在访问该IP的时候通过指定不同的`Host`来路由到kubernetes后端服务。这种方式访问每个Service时都需要指定`Host`,而同一个项目中的服务一般会在同一个Ingress中配置,使用`Path`来区分Service已经足够,这时候只要为VIP(172.20.0.119)来配置一个域名,所有的外部访问直接通过该域名来访问即可。
如下图所示:
![使用域名来访问Kubernetes中的服务](https://box.kancloud.cn/348a05e30aaddb4f3a8dac3576a56707_1136x614.png)
## 参考
- [kube-keepalived-vip](https://github.com/kubernetes/contrib/tree/master/keepalived-vip)
- http://www.keepalived.org/
- [keepalived工作原理与配置说明](http://outofmemory.cn/wiki/keepalived-configuration)
- [LVS简介及使用](http://www.cnblogs.com/codebean/archive/2011/07/25/2116043.html)
- [基于keepalived 实现VIP转移,lvs,nginx的高可用](http://limian.blog.51cto.com/7542175/1301776)
- 序言
- 云原生
- 云原生(Cloud Native)的定义
- CNCF - 云原生计算基金会简介
- CNCF章程
- 云原生的设计哲学
- Play with Kubernetes
- 快速部署一个云原生本地实验环境
- Kubernetes与云原生应用概览
- 云原生应用之路——从Kubernetes到Cloud Native
- 云原生编程语言
- 云原生编程语言Ballerina
- 云原生编程语言Pulumi
- 云原生的未来
- Kubernetes架构
- 设计理念
- Etcd解析
- 开放接口
- CRI - Container Runtime Interface(容器运行时接口)
- CNI - Container Network Interface(容器网络接口)
- CSI - Container Storage Interface(容器存储接口)
- Kubernetes中的网络
- Kubernetes中的网络解析——以flannel为例
- Kubernetes中的网络解析——以calico为例
- 具备API感知的网络和安全性管理开源软件Cilium
- Cilium架构设计与概念解析
- 资源对象与基本概念解析
- Pod状态与生命周期管理
- Pod概览
- Pod解析
- Init容器
- Pause容器
- Pod安全策略
- Pod的生命周期
- Pod Hook
- Pod Preset
- Pod中断与PDB(Pod中断预算)
- 集群资源管理
- Node
- Namespace
- Label
- Annotation
- Taint和Toleration(污点和容忍)
- 垃圾收集
- 控制器
- Deployment
- StatefulSet
- DaemonSet
- ReplicationController和ReplicaSet
- Job
- CronJob
- Horizontal Pod Autoscaling
- 自定义指标HPA
- 准入控制器(Admission Controller)
- 服务发现
- Service
- Ingress
- Traefik Ingress Controller
- 身份与权限控制
- ServiceAccount
- RBAC——基于角色的访问控制
- NetworkPolicy
- 存储
- Secret
- ConfigMap
- ConfigMap的热更新
- Volume
- Persistent Volume(持久化卷)
- Storage Class
- 本地持久化存储
- 集群扩展
- 使用自定义资源扩展API
- 使用CRD扩展Kubernetes API
- Aggregated API Server
- APIService
- Service Catalog
- 资源调度
- QoS(服务质量等级)
- 用户指南
- 资源对象配置
- 配置Pod的liveness和readiness探针
- 配置Pod的Service Account
- Secret配置
- 管理namespace中的资源配额
- 命令使用
- Docker用户过度到kubectl命令行指南
- kubectl命令概览
- kubectl命令技巧大全
- 使用etcdctl访问kubernetes数据
- 集群安全性管理
- 管理集群中的TLS
- kubelet的认证授权
- TLS bootstrap
- 创建用户认证授权的kubeconfig文件
- IP伪装代理
- 使用kubeconfig或token进行用户身份认证
- Kubernetes中的用户与身份认证授权
- Kubernetes集群安全性配置最佳实践
- 访问Kubernetes集群
- 访问集群
- 使用kubeconfig文件配置跨集群认证
- 通过端口转发访问集群中的应用程序
- 使用service访问群集中的应用程序
- 从外部访问Kubernetes中的Pod
- Cabin - Kubernetes手机客户端
- Kubernetic - Kubernetes桌面客户端
- Kubernator - 更底层的Kubernetes UI
- 在Kubernetes中开发部署应用
- 适用于kubernetes的应用开发部署流程
- 迁移传统应用到Kubernetes中——以Hadoop YARN为例
- 最佳实践概览
- 在CentOS上部署Kubernetes集群
- 创建TLS证书和秘钥
- 创建kubeconfig文件
- 创建高可用etcd集群
- 安装kubectl命令行工具
- 部署master节点
- 安装flannel网络插件
- 部署node节点
- 安装kubedns插件
- 安装dashboard插件
- 安装heapster插件
- 安装EFK插件
- 生产级的Kubernetes简化管理工具kubeadm
- 使用kubeadm在Ubuntu Server 16.04上快速构建测试集群
- 服务发现与负载均衡
- 安装Traefik ingress
- 分布式负载测试
- 网络和集群性能测试
- 边缘节点配置
- 安装Nginx ingress
- 安装配置DNS
- 安装配置Kube-dns
- 安装配置CoreDNS
- 运维管理
- Master节点高可用
- 服务滚动升级
- 应用日志收集
- 配置最佳实践
- 集群及应用监控
- 数据持久化问题
- 管理容器的计算资源
- 集群联邦
- 存储管理
- GlusterFS
- 使用GlusterFS做持久化存储
- 使用Heketi作为Kubernetes的持久存储GlusterFS的external provisioner
- 在OpenShift中使用GlusterFS做持久化存储
- GlusterD-2.0
- Ceph
- 用Helm托管安装Ceph集群并提供后端存储
- 使用Ceph做持久化存储
- 使用rbd-provisioner提供rbd持久化存储
- OpenEBS
- 使用OpenEBS做持久化存储
- Rook
- NFS
- 利用NFS动态提供Kubernetes后端存储卷
- 集群与应用监控
- Heapster
- 使用Heapster获取集群和对象的metric数据
- Prometheus
- 使用Prometheus监控kubernetes集群
- Prometheus查询语言PromQL使用说明
- 使用Vistio监控Istio服务网格中的流量
- 分布式跟踪
- OpenTracing
- 服务编排管理
- 使用Helm管理Kubernetes应用
- 构建私有Chart仓库
- 持续集成与发布
- 使用Jenkins进行持续集成与发布
- 使用Drone进行持续集成与发布
- 更新与升级
- 手动升级Kubernetes集群
- 升级dashboard
- 领域应用概览
- 微服务架构
- 微服务中的服务发现
- 使用Java构建微服务并发布到Kubernetes平台
- Spring Boot快速开始指南
- Service Mesh 服务网格
- 企业级服务网格架构
- Service Mesh基础
- Service Mesh技术对比
- 采纳和演进
- 定制和集成
- 总结
- Istio
- 安装并试用Istio service mesh
- 配置请求的路由规则
- 安装和拓展Istio service mesh
- 集成虚拟机
- Istio中sidecar的注入规范及示例
- 如何参与Istio社区及注意事项
- Istio教程
- Istio免费学习资源汇总
- 深入理解Istio Service Mesh中的Envoy Sidecar注入与流量劫持
- 深入理解Istio Service Mesh中的Envoy Sidecar代理的路由转发
- Linkerd
- Linkerd 使用指南
- Conduit
- Condiut概览
- 安装Conduit
- Envoy
- Envoy的架构与基本术语
- Envoy作为前端代理
- Envoy mesh教程
- SOFAMesh
- SOFAMesh中的Dubbo on x-protocol
- SOFAMosn
- 使用 SOFAMosn 构建 SOFAMesh
- 大数据
- Spark standalone on Kubernetes
- 运行支持Kubernetes原生调度的Spark程序
- Serverless架构
- 理解Serverless
- FaaS-函数即服务
- OpenFaaS快速入门指南
- 边缘计算
- 人工智能