Archive

标签为 ‘k8s’的文章

K8s – 交付Dubbo服务

服务交付架构

Dubbo是基于java开发的,是一个分布式微服务框架(服务调用),如果没有分布式需求,是不需要Dubbo的。

  • Registry:不管是消费者还是提供者,都需要联系注册中心,只是提供者是注册,而消费者是订阅;
  • Consumer:通过RPC调用Provider提供的方法(如下图的invoke),就像调用本地方法一样;
  • Monitor:监控消费者和提供者的信息;
  • 开发会把代码托管到Git上,进行代码托管,以及版本管理;
  • 运维会通过工具(这里是Jenkins)从Git上拉代码,并编译代码打包成Docker镜像,上传到Harbor数据库中;
  • 运维再通过k8s的资源配置清单,应用到K8s集群中,把服务生成Pod并提供服务;
  • Pod利用Dubbo微服务自动去注册中心注册(ZK,ZooKeeper,类似ETCD),这里的ZK同ETCD一样,不会部署在K8s内,因为是有状态服务;
  • Dubbo微服务的提供者集群和消费者集群部署在K8s中,方便利用K8s的机制并根据实际情况进行灵活的扩容/缩容;
  • 用户通过Ingress规则,找到相应消费者集群,完成服务互动;
完整阅读

K8s – Dashboard

这里只介绍如何部署Dashboard,至于使用方法,会在之前的文章:K8s – Core Resource Management Method GUI部分进行总结;

安装部署Dashboard

上传Dashboard的Image

root@f0-15:~# docker pull docker.io/k8scn/kubernetes-dashboard-amd64:v1.8.3
v1.8.3: Pulling from k8scn/kubernetes-dashboard-amd64
a4026007c47e: Pull complete 
Digest: sha256:ebc993303f8a42c301592639770bd1944d80c88be8036e2d4d0aa116148264ff
Status: Downloaded newer image for k8scn/kubernetes-dashboard-amd64:v1.8.3
docker.io/k8scn/kubernetes-dashboard-amd64:v1.8.3
root@f0-15:~# docker images |grep dashboard
k8scn/kubernetes-dashboard-amd64   v1.8.3                     fcac9aa03fd6   4 years ago   102MB
root@f0-15:~# docker tag fcac9aa03fd6 harbor.frank.com/public/dashboard:v1.8.3
root@f0-15:~# docker push harbor.frank.com/public/dashboard:v1.8.3
完整阅读

K8s – Traefik-Ingress

coreDNS实现了服务在集群被自动发现,那么如何实现服务在集群被自动发现呢?这里有两种方法,这里只关注Ingress资源:

  • 使用nodeport service,在这种方法中,kube-proxy只能使用iptables模型,不能使用ipvs模型;
  • 使用Ingress资源,只能调度并暴露7层应用,特质http或https;

常用的Ingress控制器主要有以下几种,这里使用traefik:

  • Ingress-nginx
  • HAProxy
  • Traefik

注意:ingress资源和ingress控制器不是一个东西(具体可以看最下面的流程图):

  • ingress资源:专用于暴露7层应用(http/https)到k8s集群外的一种核心资源;
  • ingress控制器:简化版本的nginx(调度流量)+go脚本(动态识别yaml,主要用于监控ingress配置清单的变化以做出应对),traefik就是其中之一;

安装部署Traefik

上传Traefik的Image

完整阅读

K8s – CoreDNS

服务发现

服务之间互相定位的过程,以适应如下服务特点:

  • 动态性强;
  • 更新发布频繁;
  • 支持自动伸缩;

在k8s集群里,pod ip是不断变化的,如何找到对应的pods?首先集群网络抽象了集群IP,Service资源绑定Cluster IP并暴露这个资源,Service本身根据标签选择器,来锁定一组pods,并通过ipvs算法分配这组pods的资源。也可以参考上一篇的总结:管理Service资源

那么新的问题来了,虽然可以通过Service找到pod,但如果有很多不同的Services,很难把所有Services与Customer IP的关系记下来,这个是不是很像DNS被创造出来的初衷^_^~?那我们是否可以通过类似DNS的机制,绑定Service和Cluster IP呢?答案是肯定的:

  • Kube-dns,k8s v1.10之前默认使用;
  • Coredns,k8s v1.11以后默认使用;

安装部署CoreDNS

完整阅读

K8s – CNI Network Component

我看的教程算是2020年初的,所以根据现在的时间,已经过去两年半了,下面的信息不一定很准确,后面如果哪里不正确,随着学习的深入,再更改和说明。CNI的全程是Container Network Interface,主要为了解决Pod资源在不同宿主机之间互通的。

常见CNI组件

所有CNI都部署在node节点;

  • Flannel,19年的市场占有率38%;
  • Calico,19年的市场占有率35%;
  • Canal:结合了flannel和calico;19年的市场占有率5%;
  • Contiv:思科开源的;
  • OpenContrail:Juniper开源的;
  • NSX-T:vmware开源的;
  • Kube-router:试图取代kube-proxy,但使用的不多;

Flannel

安装部署Flannel

可以从Github上直接下载,目前Link在这里:https://github.com/flannel-io/flannel/releases/download/v0.11.0/flannel-v0.11.0-linux-amd64.tar.gz,但国内环境可能不好,所以需要科学上网或者多尝试几次;分别在node13和node14上部署Flannel:

完整阅读
blonde teen swallows load.xxx videos