K8S微服务架构

Posted 2023-03-30 苯酸铵酰糖化物&

1.关于Kubernetes

1.1 Kubernetes简介

Kubernetes（简称K8S）是一个开源的，用于管理云平台中多个主机上的容器化的应用，提供了应用部署、规划、更新、维护的一种机制。他的一个核心特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让apache一直运行，用户不需要关心怎么去做，Kubernetes会自动去监控，然后去重启，新建，总之，让apache一直提供服务）

在Kubernetes中，所有的容器均在Pod中运行，用户可以自己创建并管理Pod。一个Pod可以承载一个或多个相关的容器，同一个Pod>中的容器会部署在同一个物理机器上并且能够共享资源。一个Pod也可以包含0哥或多个磁盘卷组（volumes），这些卷组会以目录的形式提供给一个容器，或者被所有Pod中的容器共享，对于用户创建的每个Pod,系统会自动选择那个健康并且有足够容量的机器，然后创建类似容器的容器,当容器创建失败的时候，容器会被node agent自动的重启,这个node agent叫kubelet,但是，如果是Pod失败

或者机器，它不会自动的转移并且启动，除非用户定义了 replication controller。

Kubernetes支持一种特殊的网络模型，Kubernetes创建了一个地址空间，并且不动态的分配端口，它可以允许用户选择任何想使用>的端口，为了实现这个功能，它为每个Pod分配IP地址。

1.2 Kubernetes架构

kubernetes集群包含有节点代理kubelet和master组件（APls ，scheduler，etc）基于分布式的存储系统，下面这张是kubernetes架构图

在这张系统架构图中，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务。Kubernetes节点有运行应用容器必>备的服务，而这些都是受Master的控制。每次个节点上当然都要运行Docker。Docker来负责所有具体的映像下载和容器运行。

Kubernetes主要由以下几个核心组件组成：

1. etcd保存了整个集群的状态
2. apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制
3. controller manager负责维护集群状态，比如故障检测、自动扩展、滚动更新等
4. scheduler负责资源的调度，按照预先制定的调度策略将Pod调度到相应的机器上
5. kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理
6. Container runtime负责镜像管理以及pod和容器的真正运行
7. kube-proxy负责为service提供cluster内部的服务发现和负载均衡

除了核心组件，还有一些推荐的Add-ons：

1. kube-dns负责为整个集群提供DNS服务
2. Ingress Controller为服务提供外网入口
3. Heapster提供资源监控
4. Dashboard提供GUI
5. Federation提供跨可用区的集群
6. Fluentd-elasticsearch提供集群日志采集、存储与查询

1.3 Pod、Node、容器

K8s为每个Pod都分配了唯一的IP地址。称为PodIP。一个Pod里的多个容器共享Pod IP。K8s要求底层网路支持集群内任意两个Pod之间的TCP/IP直接通信，者通常是通过二层网络技术来实现（如Flannel、Openswith）。一个Pod容器与另外主机上的Pod容器能够直接通信

Pod其实有两种类型，普通的Pod及静态的Pod（static Pod）。后者比较特殊，并不存放在K8S的etcd中存储，而是存放在某一个具体的Node上的一个文件中，并且只在此Node上启动运行。而普通的Pod一旦被创建，就会被放入到etcd中存储，随后会被K8S Master调度到某个具体的Node上面进行绑定（Binding），随后该Pod被对应的Node上的kubelet进程实例化成一组Docker容器并启动起来。默认情况下，当Pod里的某个容器停止时，K8S会自动检测这个问题，并重启启动这个Pod（Pod里面的所有容器），如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其它节点上。

Pod、Node与容器的关系

1.4资源对象介绍

K8S里的所有资源对象都可以采用Yaml或JSON格式的文件定义或描述，下面的是某个Pod文件的资源定义文件

apiSerdion: v1

kind: Pod

matadata:

name: myweb

labels:

name: myweb

spec:

containers:

- name: myweb

image: kubeguide/tomcat-app:v1

ports:

- containerPort: 8080

env:

- name: mysql_SERVICE_HOST

value: 'mysql'

- name: MYSQL_SERVICE_PORT

value: '3306'

kind为Pod表明这是一个Pod的定义；matadata的name属性为Pod的名字，还能定义资源对象的标签Label，这里声明myweb拥有一个name=myweb的标签。

Pod里面所包含的容器组的定义则在spec中声明，这里定义一个名字为myweb，镜像为kubeguide/tomcat-app:v1的容器，该容器注入了名为MYSQL_SERVICE_HOST='mysql'和MYSQL_SERVICE_PORT='3306'的环境变量（env关键字）。Pod的IP加上这里的容器端口（containerPort）就组成了一个新的概念Endpoint（端口），它代表Pod的一个服务进程对外的通信地址。一个Pod也存在着具有多个Endpoint的情况，例如，Tomcat定义Pod时，可以暴露管理端口和服务端口这两个Endpoint。

2.部署Kubernetes集群

2.1 节点规划

环境说明（centos7.6 1810镜像）

IP地址	主机名	角色
192.168.200.10	Master	Master
192.168.200.20	Node	worker

2.2 配置互相通信

# ssh-keygen    #生成ssh 密钥对,一路回车，不输入密码

# ssh-copy-id 192.168.200.10             //把本地的ssh公钥文件安装到远程主机对应的账户

# ssh-copy-id 192.168.200.20    

          

2.3 基础环境配置

关闭防火墙和selinux

# systemctl stop firewalld && systemctl disable firewalld

# setenforce 0 && sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

清除iptables规则

# iptables -F && iptables -X && iptables -Z && iptables-save

关闭swap分区

# swapoff -a && sed -i '/ swap / s/^\\(.*\\)$/#\\1/g' /etc/fstab

配置路由转发

br_netfilter模块用于将桥接流量转发至iptables链，br_netfilter内核参数需要开启转发。

# modprobe br_netfilter

# echo "modprobe br_netfilter" >> /etc/profile

# cat > /etc/sysctl.d/k8s.conf <<EOF

net.bridge.bridge-nf-call-ip6tables = 1

net.bridge.bridge-nf-call-iptables = 1

net.ipv4.ip_forward = 1

EOF

# sysctl -p /etc/sysctl.d/k8s.conf

2.4 安装docker

配置docker-ce的离线yum源

# tar -zxvf k8s-docker.tar.gz -C /opt/

# tee /etc/yum.repos.d/k8s-docker.repo << 'EOF'

[k8s-docker]

name=k8s-docker

baseurl=file:///opt/k8s-docker

enabled=1

gpgcheck=0

EOF

# scp /etc/yum.repos.d/k8s-docker.repo 192.168.200.20:/etc/yum.repos.d/   //发送给从节点

# scp -r /opt/k8s-docker/ 192.168.200.20:/opt/

# yum install -y yum-utils device-mapper-persistent-data lvm2              //安装依赖包

# yum install docker-ce docker-ce-cli containerd.io -y               //安装docker-ce

# systemctl start docker && systemctl enable docker

2.5 安装kubernetes集群

# yum install -y kubelet-1.20.4 kubeadm-1.20.4 kubectl-1.20.4

# systemctl enable kubelet && systemctl start kubelet

注：每个软件包的作用

kubelet   ：运行在集群所有节点上，用于启动Pod和容器等对象的工具

kubeadm ：用于初始化集群，启动集群的命令工具

kubectl    :用于和集群通信的命令行，通过kubectl可以部署和管理应用，查看各种资源，创建、删除和更新各种组件

2.6 添加阿里云镜像加速地址并修改docker文件驱动

# tee /etc/docker/daemon.json << 'EOF'



  "registry-mirrors": ["https://rncxm540.mirror.aliyuncs.com"],

  "exec-opts": ["native.cgroupdriver=systemd"]



EOF

# systemctl daemon-reload  && systemctl restart docker

2.7 初始化集群

离线导入docker镜像，避免node节点找不到镜像。

# scp -r k8s-images-v1.20.4.tar.gz 192.168.200.20:/root/

# docker load -i k8s-images-v1.20.4.tar.gz  

使用kubeadm初始化k8s集群

# kubeadm init --kubernetes-version=1.20.4 \\

--apiserver-advertise-address=192.168.200.10 \\

--image-repository registry.aliyuncs.com/google_containers  \\

--service-cidr=10.10.0.0/16 --pod-network-cidr=10.122.0.0/16

注：--image-repository registry.aliyuncs.com/google_containers为保证拉取镜像不到国外站点拉取，手动指定仓库地址为registry.aliyuncs.com/google_containers。kubeadm默认从k8ss.grc.io拉取镜像。   我们本地有导入到的离线镜像，所以会优先使用本地的镜像。

安装完成。


# mkdir -p $HOME/.kube

# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

# sudo chown $(id -u):$(id -g) $HOME/.kube/config

# kubectl get nodes             //查看集群状态

此时集群状态还是NotReady状态，因为网络组件没有启动。

3.安装网络组件

安装Calico网络组件

//上传calico.yaml，使用yaml文件安装calico 网络插件

# kubectl apply -f /root/calico.yaml


//拉取镜像需要一定时间，所以我们查看pod状态为running则安装成功。

# kubectl get pod --all-namespaces


//再次查看集群状态。

# kubectl get node

4.k8s实战

4.1 实战1——安装kubernetes-dashboard

4.1.1 修改yaml文件

默认的dashboard没有配置NodePort映射

# vi recommended.yaml               //在第42行下方添加2行

      nodePort: 30000

  type: NodePort

4.1.2 添加dashboard管理员用户凭证

在原文件中追加以下内容：

# cat >> recommended.yaml << EOF

---

# ------------------- dashboard-admin ------------------- #

apiVersion: v1

kind: ServiceAccount

metadata:

  name: dashboard-admin

  namespace: kubernetes-dashboard

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  name: dashboard-admin

subjects:

- kind: ServiceAccount

  name: dashboard-admin

  namespace: kubernetes-dashboard

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: cluster-admin

EOF

4.1.3 安装dashboard

# kubectl apply -f recommended.yaml

# kubectl get pods --all-namespaces

4.1.4 查看登录令牌

# kubectl describe secrets -n kubernetes-dashboard dashboard-admin

token: 浏览器登录时使用以上token进行登录。

4.1.5 访问web界面

（推荐使用Firefox浏览器）https://192.168.200.10:30000/

出现此界面需要点击高级，添加例外即可成功跳转并使用token登录

首次登陆可能会比较慢，请勿反复刷新页面。

4.2 实战2——将node节点加入到集群中

4.2.1 在master上查看加入节点命令

# kubeadm token create --print-join-command

4.2.2 把node节点加入k8s集群

# kubeadm join 192.168.200.10:6443 --token 0do153.6z6lypz1sxx6jhux     --discovery-token-ca-cert-hash sha256:ab6719610f13e3e872784cde7b7a03e8c600baea6da617aced1ef0a1a05e5056

4.2.3 在node节点上查看集群状态

将master证书导入到node上，这样在node才可以使用kubectl命令管理k8s

# mkdir ~/.kube

拷贝master的配置文件到node

# scp ~/.kube/config 192.168.200.20:/root/.kube/

# kubectl get nodes               //查看集群状态


//可以看到node的ROLES角色为空，我们可以手工打上标签，这里不影响集群正常工作。

# kubectl label node node node-role.kubernetes.io/worker=worker

    此时访问web界面https://192.168.200.20:30000/也可以访问dashboard界面

4.3 实战3——通过kubernetes-dashboard创建容器

4.3.1 web界面点击+进行创建pod

4.3.2 创建nginx pod

4.3.3 点“Deploy”开始部署。

4.3.4 创建成功

查看分配的nodeport端口

浏览器访问：http://192.168.200.10:30717/ ，http://192.168.200.20:30717/

注：访问master,node都是可以的。

5.配置图形化管理工具Kuboard

Kuboard是一款免费的Kubernetes图形化管理工具，其力图帮助用户快速在Kubernetes上落地微服务。登录Master节点上传kuboard.tar和kuboard.yaml，使用kuboard.yaml文件部署Kuboard。

# docker load < kuboard.tar                        //导入本地镜像
# vi kuboard.yaml             //修改配置文件
# kubectl apply -f kuboard.yaml

在浏览器输入地址http://192.168.200.10:32567/(主从节点IP都可以访问)，即可进入Kuboard的认证界面，在Token文本框中输入令牌后可进入Kuboard控制台.

微服务架构总览

参考技术A 微服务是一种基于有界上下文的，松散耦合的面向服务的架构。

什么场景下适用微服务？什么阶段时适用微服务？

设计的微服务系统的组织，其产生的架构设计应等价于组织间的沟通结构。

这句话的意思是说，原始组织之间的结构最好能映射到设计的微服务系统架构上。比如一个系统包含订单、商品、用户等功能，现实中分别由A、B、C三个小组进行开发维护，那么如果要拆分为微服务的架构，最好就能拆分为订单服务、商品服务、用户服务三个微服务，对应A、B、C三个现实的小组结构。

微服务并不是适合任何阶段，最好的方式就是随着项目的扩大或者团队的扩大时，逐步演进到微服务。因为单体应用会随着规模的扩大而逐渐增加内耗，导致生产力降低。微服务的目标是在规模扩大时，使得生产力能维持在一个稳定的水准之上。

微服务生产力超过单体的拐点，一般来说是指当团队人数规模达到百人时。当然，这也不是绝对的，需要团队负责人自己视情况进行评估。

如果在项目一开始就设计微服务的架构，一路上会遇到极大的困难与风险。比如业务模块边界的划分、无法预估的业务或者技术复杂性，这些都会耗费更多的人力和时间，甚至最终导致项目失败。

建议的方式就是由单体演进，我们可以在单体阶段不断摸索和沉淀业务和技术上的问题，随着越来越清晰的认知，再加上日渐增加的复杂度，可以考虑逐步拆分部分服务出来，朝着微服务架构的方向演进。

微服务架构中服务与服务各有不同，相互之间也应该按照层级的方式进行编排。有的与业务无关的服务天然属于底层基础服务，有的与业务有关联的服务则属于聚合了基础服务的聚合服务。

在常见的公司微服务总体架构中，一般的架构表现就如下所示：

有了各个层级的服务之后，中台的概念和战略就显得很自然。

服务注册与发现是微服务架构得以运转的核心功能，它不提供任何业务功能，仅仅用来进行服务的发现和注册，并对服务的健康状态进行监控和管理。其核心的工作原理：

现在注册中心比较多，主流的有Eureka、Consul、Zookeeper、Nacos等。

网关是整个系统对外暴露的唯一入口，它封装了系统内的所有微服务，对外看来，别人只知道也只能通过网关才可以和系统进行交互。网关对所有请求进行非业务功能的处理，然后再将请求发送给内部指定的微服务进行业务上的处理。总的来说，网关最主要的功能如下：

现在常见的网关有Kong、Zuul、Spring Cloud Gateway等；

在实际应用中，一个微服务体系架构的系统可以有多个网关用来应对不同的使用场景，比如公司内网网关、外网网关、提供给第三方调用的网关等；

微服务在启动和运行的过程中，经常会需要读取一些配置信息，这些配置信息拥有如下的特点：

如上这些特点和需求，催生了配置中心的出现。现在主流的配置中心有Spring Cloud Config、Nacos、Apollo等；

在微服务架构中，一次调用请求可能贯穿多个服务，这些服务可能是由不同的团队使用不同的技术开发而成的，如果出现调用失败需要排查问题时，如何能快速地复现调用现场，发现问题出在哪个服务哪个服务器上就成了全链路监控需要解决的问题。

全链路监控的基本原理都是：

全链路监控主流工具有CAT、Zipkin、Pinpoint、Skywalking等；

在微服务架构体系中，服务之间的调用是很频繁的，一旦某些服务出现故障或者高延迟，会很可能造成级联故障，如果客户端还在不停重试，将会加剧问题的严重性，最终导致整个系统彻底崩溃。

断路器的设计与实现有助于防止多服务之间的级联故障，允许我们构建具有容错性和高弹性的微服务架构系统，当某些服务不可用时，提供服务熔断和服务降级功能，保证系统的其它部分仍能正常运行。

断路器的三个状态和含义如下：

主流常见的断路器有Hystrix、Sentinel等；

如果使用了容器技术，那么容器编排、发布、治理就成了避不开的话题。主流的技术如下：

各大容器云厂商基本都是使用基于k8s的容器治理方案，k8s也已经成为该领域事实上的标准了。

如上是自己在极客时间App上学习《微服务架构核心20讲》的笔记，该课程一天就能学完，没有实现微服务的细节，是高屋建瓴地讲解微服务架构的蓝图，带你鸟瞰整个微服务架构，推荐学习。