而对于eureka来说，要实现eureka的高可用，那就不是修改replicas这么方便了。由于部署的多个eureka之间需要将自己注册到彼此，因此要做一些特殊改动。
主要是用到了StatefulSet和headless service这两个k8s对象
StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
有序收缩，有序删除（即从N-1到0）
StatefulSet中每个Pod的DNS格式为
Headless Service 和普通service的一个显著的区别是，Headless Service的对应的每一个Endpoints，即每一个Pod，都会有对应的DNS域名
例如：我们可以用过这种域名来访问某个具体的pod：
在实际使用中，将service的clusterIP设置成None，就表明这个service是一个Headless Service。
通过 StatefulSet，我们得到了一些列pod，每个pod的name为statefulSetName-{0N-1}，
加入我们创建了一个名称叫eureka的StatefulSet，并且设置replicas =3，那么部署到k8s后，k8s会为我们生成三个名称依次为eureka-0，eureka-1，eureka-2的pod。
通过Headless Service，我们可以通过pod名称来访问某个pod，
例如，我们在namespace=test的命名空间下创建了一个名称为register-server的service，并且关联了之前StatefulSet创建的pod，那么我们可以在集群内任意地方
通过eureka-0register-servertestsvcclusterlocal这个域名访问到eureka-0这个pod。
有了前面的基础，现在部署eureka集群的方式就逐渐清晰了。
首先明确部署eureka的关键点：需要让每个eureka注册到另外的eureka上。
也就是eurekaclientserviceUrldefaultZone这个配置，是一组eureka的地址。
通过StatefulSet，我们可以明确知道生成的每个eureka的名称，
通过Headless Service，我们又可以访问到每个eureka，所以eurekaclientserviceUrldefaultZone的值就是
有个这个配置，那么我们部署StatefulSet，和Headless Service
那么我们能基本能得到一个可用的eureka集群
除了会有以下问题：
红框中的可用副本（available-replicas）会出现在不可用unavailable-replicas中
原因是我们默认是通过ip的方式来注册eureka（eurekainstanceprefer-ip-address配置默认为true），但是eureka的注册地址又是域名的形式，两者不一致。
要解决这个问题，还需做一些额外的配置。
1在applicationyaml中，将eurekainstanceprefer-ip-address设置成false。
2StatefulSetyaml中，增加环境变量配置，将pod的名称绑定到环境变量
3在applicationyaml中指定eureka的 hostname,其中MY_POD_NAME取到了第二部中绑定的当前pod名称
eureka:
instance:
hostname: ${MY_POD_NAME}register-server
如上配置后，便可以得到一个eureka集群。
后面是一些配置文件：
整体文件配置：
serviceyaml
StatefulSetyaml
applicationyml
bootstrapyml
将一般的微服务注册到eureka集群中，可以通过eureka的service来访问eureka，即：将eurekaclientserviceUrldefaultZone设置成register-servertestsvcclusterlocal，使用了k8s的service负载均衡，将服务注册到任意一个活着的eureka上，然后eureka集群内部会做同步，最终注册到eureka集群内部所有eureka上
参考文档
Helm安装Rancher
Rancher简介
Rancher是一套容器管理平台，它可以帮助组织在生产环境中轻松快捷的部署和管理容器。 Rancher可以轻松地管理各种环境的Kubernetes，满足IT需求并为DevOps团队提供支持。
Kubernetes不仅已经成为的容器编排标准，它也正在迅速成为各类云和虚拟化厂商提供的标准基础架构。Rancher用户可以选择使用Rancher Kubernetes Engine(RKE)创建Kubernetes集群，也可以使用GKE，AKS和EKS等云Kubernetes服务。 Rancher用户还可以导入和管理现有的Kubernetes集群。
Rancher支持各类集中式身份验证系统来管理Kubernetes集群。例如，大型企业的员工可以使用其公司Active Directory凭证访问GKE中的Kubernetes集群。IT管理员可以在用户，组，项目，集群和云中设置访问控制和安全策略。 IT管理员可以在单个页面对所有Kubernetes集群的健康状况和容量进行监控。
Rancher为DevOps工程师提供了一个直观的用户界面来管理他们的服务容器，用户不需要深入了解Kubernetes概念就可以开始使用Rancher。 Rancher包含应用商店，支持一键式部署Helm和Compose模板。Rancher通过各种云、本地生态系统产品认证，其中包括安全工具，监控系统，容器仓库以及存储和网络驱动程序。下图说明了Rancher在IT和DevOps组织中扮演的角色。每个团队都会在他们选择的公共云或私有云上部署应用程序。
集群环境
Helm环境
添加Chart仓库地址
通过Helm安装Rancher
注意：这里指定了hostname=rancherminminmsncom，必须使用域名访问才行。
注意：rancher默认使用>MinIO 是全球领先的对象存储先锋，以 Apache License v20 发布的对象存储服务器，是为云应用和虚拟机而设计的分布式对象存储服务器。在标准硬件上，读/写速度上高达183GB/s和171GB/s。它与 Amazon S3 云存储服务兼容。 它最适用于存储非结构化数据，如照片、视频、日志文件、备份和容器/虚拟机映像。 对象的大小可以从几KB 到最大5TB。
MinIO是一个非常轻量的服务,可以很简单的和其他应用的结合，类似 NodeJS, Redis 或者 MySQL。
MinIO支持多种灵活的部署方式，支持Docker Compose、Docker Swam、Kubernetes等，详见官网： >
1 什么是kubernetes
Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
2 kubernetes核心组件说明
Kubernetes 集群中主要存在两种类型的节点，分别是 master 节点 ，以及 minion 节点 。
Minion 节点是实际运行 Docker 容器的节点，负责和节点上运行的 Docker 进行交互，并且提供了代理功能。
Master 节点负责对外提供一系列管理集群的 API 接口，并且通过和 Minion 节点交互来实现对集群的 *** 作管理。
apiserver ：用户和 kubernetes 集群交互的入口，封装了核心对象的增删改查 *** 作，提供了 RESTFul 风格的 API 接口，通过 etcd 来实现持久化并维护对象的一致性。
scheduler ：负责集群资源的调度和管理，例如当有 pod 异常退出需要重新分配机器时，scheduler 通过一定的调度算法从而找到最合适的节点。
controller-manager ：主要是用于保证 replicationController 定义的复制数量和实际运行的 pod 数量一致，另外还保证了从 service 到 pod 的映射关系总是最新的。
kubelet ：运行在 minion 节点，负责和节点上的 Docker 交互，例如启停容器，监控运行状态等。
proxy ：运行在 minion 节点，负责为 pod 提供代理功能，会定期从 etcd 获取 service 信息，并根据 service 信息通过修改 iptables 来实现流量转发（最初的版本是直接通过程序提供转发功能，效率较低。），将流量转发到要访问的 pod 所在的节点上去。
etcd ：key-value键值存储数据库，用来存储kubernetes的信息的。
flannel ：Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，需要另外下载部署。
我们知道当我们启动 Docker 后会有一个用于和容器进行交互的 IP 地址，如果不去管理的话可能这个 IP 地址在各个机器上是一样的，并且仅限于在本机上进行通信，无法访问到其他机器上的 Docker 容器。
Flannel 的目的就是为集群中的所有节点重新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得同属一个内网且不重复的 IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信。
3 Kubernetes的核心概念
Pod
运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。
Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。
Replication Controller
Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。
集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量，反之，则会启动少于指定数量个数的容器，保证数量不变。
Replication Controller是实现d性伸缩、动态扩容和滚动升级的核心。
Service
Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。
Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。
Label
Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的K/V键值对。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。
Node
Node是Kubernetes集群架构中运行Pod的服务节点（或agent）。
Node是Kubernetes集群 *** 作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。
4 前置条件设置
三台Centos7系统的虚拟机（1个master+2个node）,三台机器上的防火墙，SELINUX全部关掉。我的实验坏境可以上网，默认的YUM源就可以用。
5 部署规划
192168101 # master节点(etcd,kubernetes-master)
192168102 # node1节点(etcd,kubernetes-node,docker,flannel)
192168103 # node2节点(etcd,kubernetes-node,docker,flannel)
6 开始安装
step1：在master上安装
yum install kubernetes-master etcd flannel -y
step2：在node上安装
yum install kubernetes-node etcd flannel -y
step3：etcd集群配置
在master节点上编辑etcd配置文件
在node1节点上编辑etcd配置文件
在node2节点上编辑etcd配置文件
到此etcd集群就部署完了，然后每个节点上启动
systemctl start etcd
step4：验证
step6：启动Master上的三个服务
step7：kubernetes node安装
node2 节点重复上述 *** 作
step8：分别启动kubernetes node服务
7 网络配置
因为kubernetes集群中网络部分是插件形式安装的，我们这里选用flannel
上述安装步骤已经install 了
为flannel创建分配的网络
8 执行kubectl 命令检查
在master上执行下面，检查kubernetes的状态
9 常用排错命令如下
环境信息:*** 作系统：CentOS Linux release 761810 (Core)；docker：19035；kubernetes：v1212
master01 :1921681230
node01 :1921681241
node02: 1921681242
cat < >/etc/hosts
1921681230 master01
1921681241 node01
1921681242 node02
EOF
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/^SELINUX=/SELINUX=disabled/' /etc/selinux/configswapoff -ased -i '/ swap / s/^()$/#1/g' /etc/fstab
在每台机器上安装依赖包
yum install -y epel-release
yum install -y conntrack ntpdate ntp ipvsadm ipset jq iptables curl sysstat libseccomp wget
在每台机器上执行同步时间：
ntpdate time1aliyuncom
modprobe ip_vs_rr
modprobe br_netfilter
cat > /etc/sysctld/kubernetesconf << EOF
netbridgebridge-nf-call-iptables=1
netbridgebridge-nf-call-ip6tables=1
netipv4ip_forward=1
netipv4tcp_tw_recycle=0
vmswappiness=0 # 禁止使用 swap 空间，只有当系统 OOM 时才允许使用它
vmovercommit_memory=1 # 不检查物理内存是否够用
vmpanic_on_oom=0 # 开启 OOM
fsinotifymax_user_instances=8192
fsinotifymax_user_watches=1048576
fsfile-max=52706963
fsnr_open=52706963
netipv6confalldisable_ipv6=1
netnetfilternf_conntrack_max=2310720
EOF
sysctl -p /etc/sysctld/kubernetesconf
安装kubernetes和docker;安装k8s和docker;所有节点添加k8s和docker的yum源;Yum安装docker，启动docker;yum安装kubeadm，kubelet和kubectl;部署主节点，部署网络插件，工作节点注册到主节点;在每台机器上都需要 *** 作
cat < >/etc/yumreposd/kubernetesrepo
[kubernetes]
name=Kubernetes repo
baseurl=>注意把10170208111 替换成自己linux虚拟机的ip地址
# kubeadm init \
--apiserver-advertise-address=10170208111 \
--image-repository registryaliyuncscom/google_containers \
--kubernetes-version=v1194 \
--service-cidr=109600/12 \
--pod-network-cidr=1024400/16 \
--token-ttl=0
安装方式建议实用kubeadm安装方式
kubectl taint nodes --all node-rolekubernetesio/master-
wget > SpringCloud微服务包含多个SpringBoot可运行的应用程序，在单应用程序下，版本发布时的打包部署还相对简单，当有多个应用程序的微服务发布部署时，原先的单应用程序部署方式就会显得复杂且不可控。那么我们就会思考使用简单的部署方式，解决自动化发布、自动化部署、微服务监控等问题。
我们目前使用的解决方案是，Maven+GitLab+Docker+Kubernetes来实现可持续自动化部署(CI/CD)微服务的功能。下面将从工程中Maven打包文件配置、Dockfile文件编写开始到Kubernetes配置来说明如何实现Spring微服务可持续自动化部署功能。
在项目打包部署时，我们系统的配置文件需要根据不同的环境来区分开发、测试、生产环境的配置，在之前的SpringBoot工程中，我们用到springprofilesactive配置属性，使用applicationyml、application-devyml、application-testyml、application-sityml、application-uatyml、application-prodyml来区分不同环境的配置文件。在SpringCloud中，我们用到了Nacos注册中心，Nacos的Config默认读取的是bootstrapyml配置文件，如果将Nacos Config的配置写到applicationyml里面，工程启动时就会一直报错。下面是SpringCloud加载配置文件的顺序：
bootstrapyml（bootstrapproperties）先加载，用于应用程序上下文的引导阶段，可以用来配置applicationyml中使用到的参数，由父Spring ApplicationContext加载。
applicationyml（applicationproperties）后加载，用于配置各工程模块中使-用到的参数。
所以在SpringCloud工程中我们通过使用bootstrapyml、bootstrap-devyml等不同的配置文件来区分不同的环境，有些框架是放到同一个yml配置文件中，然后不同的配置放到不同的springprofilesactive下面，类似于下面这种:
```
spring: profiles: dev 开发配置项: 开发配置项spring: profiles:test测试配置项: 测试配置项
```
```
ssssssss
```
建议所有节点提前导入rancher镜像，减少部署时间，以rancher 256为例：
rancher-server 在 k8s 环境中只提供 >
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）