如果您想了解Kubernetes发布SpringBoot项目过程总结和kubernetes部署springcloud的知识,那么本篇文章将是您的不二之选。我们将深入剖析Kubernetes发布Spri
如果您想了解Kubernetes 发布 SpringBoot 项目过程总结和kubernetes部署springcloud的知识,那么本篇文章将是您的不二之选。我们将深入剖析Kubernetes 发布 SpringBoot 项目过程总结的各个方面,并为您解答kubernetes部署springcloud的疑在这篇文章中,我们将为您介绍Kubernetes 发布 SpringBoot 项目过程总结的相关知识,同时也会详细的解释kubernetes部署springcloud的运用方法,并给出实际的案例分析,希望能帮助到您!
本文目录一览:- Kubernetes 发布 SpringBoot 项目过程总结(kubernetes部署springcloud)
- 8.2、springboot启动过程总结
- Docker 学习(五)-Kubernetes 集群搭建 - Spring Boot 应用
- Docker 学习(六)-Kubernetes - Spring Boot 应用
- Docker、kubernetes、微服务、SpringBoot/Cloud... 好乱!到底要不要学?
Kubernetes 发布 SpringBoot 项目过程总结(kubernetes部署springcloud)
SpringBoot 项目创建完成后,通常会打成 jar 包运行,如果不使用 Kubernetes 可以直接通过 java -jar 或者脚本启动,如果需要发布到 Kubernetes 环境,那么需要编写 Dockerfile、构建镜像、推送到远程 harbor、编写 Kubernetes yaml 等步骤,假设目前你已经完成 SpringBoot 项目开发环境正常运行和打包,下面我会详细介绍如何完成镜像构建和运行这个过程。
1 编写 Dockerfile
-
基于 centos7 构建 jdk 镜像,如果已经构建完成,请忽略该步骤,在构建 java 镜像过程建议使用 jdk 8u191 以上的版本,早期的 jdk 版本对容器的兼容性不好,严格来说,这是 java 本身的问题,早期的版本主要对内存和 CPU 的限制有问题,不支持自定义 CPU 数量以及设置 java heap 百分比;另外 java 虚拟机安装包中包含 jdk 和 jre 两部分,建议裁掉 jdk,只保留 jre 运行时环境,尽量减少镜像大小。
FROM docker.hub.com/dev/centos:7
MAINTAINER <shj@qq.com>
ADD java.tar.gz /usr/local/
ENV JAVA_HOME=/usr/local/java
ENV JRE_HOME=$JAVA_HOME/jre
ENV CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib:$CLASSPATH
ENV JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF8 -Duser.timezone=GMT+08"
ENV PATH=.:$JAVA_HOME/bin:$PATH
-
在包含 Dockerfile 所在目录执行如下命令
docker build -t jdk:8u231 .
docker push jdk:8u231
2 基于 java 镜像构建 jar 包镜像
-
构建应用镜像,这里只展示应用 jar 包和启动脚本,可以通过 java -jar 启动,也可以使用脚本启动,建议使用脚本启动,这样更容易维护;另外创建 Kubernetes 资源对象时,可以利用 lifecycle 来管理运行前和关闭前的一些动作,比如在容器停止前优雅的关闭应用程序或者通知其它系统,可以通过在 PreStop 中完成。
FROM docker.hub.com/dev/jdk:8u231
MAINTAINER <shj@qq.com>
ADD elb.jar /usr/local/src/elb.jar
ADD startup.sh /usr/local/src/elb/
-
在包含 Dockerfile 所在目录执行如下命令
docker build -t elb:2.0 .
docker push elb:2.0
3 编写 Kubernetes yaml
3.1 编写配置文件 ConfigMap yaml 文件
-
配置建议存储到 Kubernetes ConfigMap 中,一来维护起来简单,不用修改镜像,二来对于后期的集群部署,一份配置多节点服务使用,降低运维成本。
apiVersion: v1
data:
system.properties: |
######################系统配置######################
server.tomcat.uri-encoding = UTF-8
spring.http.encoding.charset = UTF-8
spring.http.encoding.enabled = true
.......
db.properties: |
######################数据库配置#####################
.......
logback.xml: |
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="5 seconds" debug="false">
.........
</configuration>
kind: ConfigMap
metadata:
name: elb-config
namespace: default
-
编写完成执行 kubectl apply -f yaml 文件。
3.2 编写配置文件 Department yaml 文件
-
编写 Kubernetes Deployment 资源对象,Deployment 能够管理服务多个副本; -
一定要把服务日志挂载到宿主机,这样出现服务出现异常后,便于查看日志分析问题; -
日志服务出现乱码,可以通过修改容器编码格式解决 en_U S .utf8 ; 服务器时间不对,可以通过挂载本地时间或在 Dockerfile 镜像中添加时间环境变量解决。 -
编写完成后执行 kubectl apply -f yaml 文件,通过 kubectl get pod 查看服务是否正常启动。
apiVersion: apps/v1
kind: Deployment
metadata:
name: elb-deployment
spec:
selector:
matchLabels:
app: elb
replicas: 1
template:
metadata:
labels:
app: elb
spec:
containers:
- name: elb
image: docker.hub.com/dev/elb:2.0
imagePullPolicy: Always
#command: ["/bin/bash","-c", "java -jar /usr/local/src/elb/elb.jar"]
command: ["/bin/bash","-c", "/usr/local/src/elb/start.sh"]
ports:
- containerPort: 8080
env:
- name: LANG
value: en_US.utf8
volumeMounts:
- mountPath: /etc/localtime
name: date-config
- mountPath: /conf/elb
name: elb-config
- mountPath: /logs/elb
name: elb-log
volumes:
- name: date-config
hostPath:
path: /etc/localtime
- name: elb-log
hostPath:
path: /logs/elb/
- name: elb-config
configMap:
name: elb-config
items:
- key: system.properties
path: system.properties
- key: logback.xml
path: logback.xml
- key: db.properties
path: db.properties
3.3 编写 Service 对外暴露端口
-
正常线上环境应该使用 Service ClusterIP 类型,通过 Ingress-nginx 代理,因为通过 NodePort 对外暴露端口,不仅存在安全问题,而且不容易管理。这里是为了演示使用,对外暴露了 NodePort 端口,编写完成后,执行 kubectl apply -f yaml 文件,即完成了 svc 的创建。这时通过 IP 和 NodePort 即可访问服务。
apiVersion: v1
kind: Service
metadata:
name: spt-service
labels:
app: sbt-service
spec:
type: NodePort
ports:
- name: http
port: 8080
targetPort: 8080
nodePort: 30111
selector:
app: elb
4 总结
如上所示已经完成 SpringBoot 项目的镜像构建以及 Kubernetes yaml 文件的编写和运行,即便如此,依然会遇到各种各样的问题,出现问题后注意通过 kubectl logs 观察服务日志输出,通过输出分析异常所在,一般情况下异常都是服务本身导致,比如镜像路径,执行脚本不存在等。如果从服务本身找不到问题,可以分析下基础镜像是否正常,比如运行一个简单服务,验证基础镜像正确性。
推荐阅读
如何使用 Ingress-nginx 进行前后端分离?
深入探究 K8S ConfigMap 和 Secret
Kubernetes 入门培训(内含 PPT)
原创不易,随手关注或者” 在看 “,诚挚感谢!
本文分享自微信公众号 - 云原生技术爱好者社区(programmer_java)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与 “OSC 源创计划”,欢迎正在阅读的你也加入,一起分享。
8.2、springboot启动过程总结
springboot启动过程总结:
1、SpringBoot启动过程
有两大步:①传入spring应用,然后创建spring应用 ②把spring应用跑起来
- 创建 SpringApplication
- 保存一些信息。
- 判定当前应用的类型。Servlet or 响应式编程
- bootstrappers:初始启动引导器(List<Bootstrapper>):去spring.factories文件中找 org.springframework.boot.Bootstrapper
- 找 ApplicationContextInitializer;去spring.factories找 ApplicationContextInitializer
- 封装到 List<ApplicationContextInitializer<?>> initializers
- 找ApplicationListener应用监听器。去spring.factories找 ApplicationListener
- 封装到 List<ApplicationListener<?>> listeners
简单来说,应用创建的过程,就是把一些关键的主键去spring.factories文件给我们读取信息读取出来,提前保存到springapplication里
- 运行 SpringApplication
- StopWatch 停止监听器
- 记录应用的启动时间
- 创建引导上下文(Context环境)createBootstrapContext()
- 获取到所有之前保存的 bootstrappers 挨个执行他们的 intitialize() 来完成对引导启动器上下文环境设置
- 让当前应用进入headless模式。java.awt.headless (headless是自力更生的意思,不依赖别人)
- 获取所有RunListener(运行监听器)【为了方便所有Listener进行事件感知】
- getSpringFactoriesInstances 去spring.factories找 SpringApplicationRunListener.
- 遍历所有的 SpringApplicationRunListener调用 starting 方法;
- 相当于通知所有感兴趣系统正在启动过程的人,项目正在 starting。(即告诉我这个项目正在启动)
- 保存命令行参数;ApplicationArguments
- 准备环境 ,调用 prepareEnvironment();
- 返回或者创建基础环境信息对象。StandardServletEnvironment
- 配置环境信息对象。
- 读取所有的配置源的配置属性值。
- 绑定环境信息
- 遍历每个监听器,调用 listener.environmentPrepared();通知所有的监听器当前环境准备完成
- 创建IOC容器(调用createApplicationContext())
- 根据项目类型(Servlet)创建容器,
- 当前会创建 AnnotationConfigServletWebServerApplicationContext
- 准备ApplicationContext IOC容器的基本信息 调用prepareContext()
- 保存环境信息
- IOC容器的后置处理流程。
- 应用初始化器:applyInitializers;
- 遍历所有的 ApplicationContextInitializer。调用 initialize.。来对ioc容器进行初始化扩展功能
- 遍历所有的 listener 调用 contextPrepared。实际上是EventPublishRunListenr:通知所有的监听器contextPrepared容器的上下文环境已经准备好了
- 所有的监听器 调用contextLoaded。通知所有的监听器 contextLoaded;容器的上下文环境已经加载好了
- 刷新IOC容器。refreshContext
- 创建容器中的所有组件
- 容器刷新完成后要做的工作(调用 afterRefresh())
- 遍历所有监听器 调用 listeners.started(context); 通知所有的监听器started 项目已经启动了(通知监听器又一个事干好了)所以在这里就可以访问8080了
- 调用所有runners; (调用 callRunners())
- 获取容器中的ApplicationRunner
- 获取容器中的CommandLineRunner
- 合并所有runner并且按照@Order进行排序
- 遍历所有的runner。调用 run方法
- 如果从`准备环境 ,调用 prepareEnvironment()到这里` 有异常,
- 调用Listener 的 failed
- 没有任何异常就 调用所有监听器的 running 方法 listeners.running(context); 通知所有的监听器 running项目已经进入running状态了
- running如果有问题。继续通知 failed 。调用所有 Listener 的failed;通知所有的监听器failed 当前项目运行失败
只要看到这个getSpringFactoriesInstances()方法,都是去spring.factories文件找东西
springboot启动过程涉及到的组件有:
ApplicationContextInitializer, ApplicationListener, SpringApplicationRunListener,
ApplicationRunner,CommandLineRunner
我们就可以通过自定义组件,来监控springboot整个启动过程,然后在某个时刻做一些事情
Docker 学习(五)-Kubernetes 集群搭建 - Spring Boot 应用
Docker 学习
Docker 学习 - VMware Workstation 本地多台虚拟机互通,主机网络互通搭建
Docker 学习 - Docker 搭建 Consul 集群
Docker 学习 - 简单的私有 DockerHub 搭建
Docker 学习 - Spring Boot on Docker
Docker 学习 - Kubernetes - 集群部署
Docker 学习 - Kubernetes - Spring Boot 应用
简介
kubernetes,简称 K8s,是用 8 代替 8 个字符 “ubernete” 而成的缩写。是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes 的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes 提供了应用部署,规划,更新,维护的一种机制。
基本概念
Kubernetes 中的绝大部分概念都抽象成 Kubernetes 管理的一种资源对象
- Master:Master 节点是 Kubernetes 集群的控制节点,负责整个集群的管理和控制。Master 节点上包含以下组件:
- kube-apiserver:集群控制的入口,提供 HTTP REST 服务
- kube-controller-manager:Kubernetes 集群中所有资源对象的自动化控制中心
- kube-scheduler:负责 Pod 的调度
-
Node:Node 节点是 Kubernetes 集群中的工作节点,Node 上的工作负载由 Master 节点分配,工作负载主要是运行容器应用。Node 节点上包含以下组件:
- kubelet:负责 Pod 的创建、启动、监控、重启、销毁等工作,同时与 Master 节点协作,实现集群管理的基本功能。
- kube-proxy:实现 Kubernetes Service 的通信和负载均衡
- 运行容器化 (Pod) 应用
-
Pod: Pod 是 Kubernetes 最基本的部署调度单元。每个 Pod 可以由一个或多个业务容器和一个根容器 (Pause 容器) 组成。一个 Pod 表示某个应用的一个实例
- ReplicaSet:是 Pod 副本的抽象,用于解决 Pod 的扩容和伸缩
- Deployment:Deployment 表示部署,在内部使用 ReplicaSet 来实现。可以通过 Deployment 来生成相应的 ReplicaSet 完成 Pod 副本的创建
- Service:Service 是 Kubernetes 最重要的资源对象。Kubernetes 中的 Service 对象可以对应微服务架构中的微服务。Service 定义了服务的访问入口,服务的调用者通过这个地址访问 Service 后端的 Pod 副本实例。Service 通过 Label Selector 同后端的 Pod 副本建立关系,Deployment 保证后端 Pod 副本的数量,也就是保证服务的伸缩性。
Kubernetes 主要由以下几个核心组件组成:
- etcd 保存了整个集群的状态,就是一个数据库;
- apiserver 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API 注册和发现等机制;
- controller manager 负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
- scheduler 负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上;
- kubelet 负责维护容器的生命周期,同时也负责 Volume(CSI)和网络(CNI)的管理;
- Container runtime 负责镜像管理以及 Pod 和容器的真正运行(CRI);
- kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡;
当然了除了上面的这些核心组件,还有一些推荐的插件:
- kube-dns 负责为整个集群提供 DNS 服务
- Ingress Controller 为服务提供外网入口
- Heapster 提供资源监控
- Dashboard 提供 GUI
组件通信
Kubernetes 多组件之间的通信原理:
- apiserver 负责 etcd 存储的所有操作,且只有 apiserver 才直接操作 etcd 集群
-
apiserver 对内(集群中的其他组件)和对外(用户)提供统一的 REST API,其他组件均通过 apiserver 进行通信
- controller manager、scheduler、kube-proxy 和 kubelet 等均通过 apiserver watch API 监测资源变化情况,并对资源作相应的操作
- 所有需要更新资源状态的操作均通过 apiserver 的 REST API 进行
-
apiserver 也会直接调用 kubelet API(如 logs, exec, attach 等),默认不校验 kubelet 证书,但可以通过
--kubelet-certificate-authority
开启(而 GKE 通过 SSH 隧道保护它们之间的通信)
比如最典型的创建 Pod 的流程:
- 用户通过 REST API 创建一个 Pod
- apiserver 将其写入 etcd
- scheduluer 检测到未绑定 Node 的 Pod,开始调度并更新 Pod 的 Node 绑定
- kubelet 检测到有新的 Pod 调度过来,通过 container runtime 运行该 Pod
- kubelet 通过 container runtime 取到 Pod 状态,并更新到 apiserver 中
集群部署
使用 kubeadm 工具安装
1. master 和 node 都用 yum 安装 kubelet,kubeadm,docker
2. master 上初始化:kubeadm init
3. master 上启动一个 flannel 的 pod
4. node 上加入集群:kubeadm join
准备环境
Centos7 192.168.50.21 k8s-master
Centos7 192.168.50.22 k8s-node01
Centos7 192.168.50.23 k8s-node02
修改主机名(3 台机器都需要修改)
hostnamectl set-hostname k8s-master
hostnamectl set-hostname k8s-node01
hostnamectl set-hostname k8s-node02
关闭防火墙
systemctl stop firewalld.service
配置 docker yum 源
yum install -y yum-utils device-mapper-persistent-data lvm2 wget
cd /etc/yum.repos.d
wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
配置 kubernetes yum 源
cd /opt/
wget https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
wget https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
rpm --import yum-key.gpg
rpm --import rpm-package-key.gpg
cd /etc/yum.repos.d
vi kubernetes.repo
输入以下内容
[kubernetes]
name=Kubernetes Repo
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
enabled=1
yum repolist
master 和 node 安装 kubelet,kubeadm,docker
yum install docker
yum install kubelet-1.13.1
yum install kubeadm-1.13.1
master 上安装 kubectl
yum install kubectl-1.13.1
docker 的配置
配置私有仓库和镜像加速地址,私有仓库配置参见 https://www.cnblogs.com/woxpp/p/11871886.html
vi /etc/docker/daemon.json
{
"registry-mirror":[
"http://hub-mirror.c.163.com"
],
"insecure-registries":[
"192.168.50.24:5000"
]
}
启动 docker
systemctl daemon-reload
systemctl start docker
docker info
master 上初始化:kubeadm init
vi /etc/sysconfig/kubelet
KUBELET_EXTRA_ARGS="--fail-swap-on=false"
kubeadm init \
--apiserver-advertise-address=192.168.50.21 \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.13.1 \
--pod-network-cidr=10.244.0.0/16
初始化命令说明:
--apiserver-advertise-address
指明用 Master 的哪个 interface 与 Cluster 的其他节点通信。如果 Master 有多个 interface,建议明确指定,如果不指定,kubeadm 会自动选择有默认网关的 interface。
--pod-network-cidr
指定 Pod 网络的范围。Kubernetes 支持多种网络方案,而且不同网络方案对 --pod-network-cidr 有自己的要求,这里设置为 10.244.0.0/16 是因为我们将使用 flannel 网络方案,必须设置成这个 CIDR。
--image-repository
Kubenetes 默认 Registries 地址是 k8s.gcr.io,在国内并不能访问 gcr.io,在 1.13 版本中我们可以增加–image-repository 参数,默认值是 k8s.gcr.io,将其指定为阿里云镜像地址:registry.aliyuncs.com/google_containers。
--kubernetes-version=v1.13.1
关闭版本探测,因为它的默认值是 stable-1,会导致从 https://dl.k8s.io/release/stable-1.txt 下载最新的版本号,我们可以将其指定为固定版本(最新版:v1.13.1)来跳过网络请求。
初始化过程中
[preflight] You can also perform this action in beforehand using ''kubeadm config images pull'' 是在下载镜像文件,过程比较慢。
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 24.002300 seconds 这个过程也比较慢 可以忽略
[init] Using Kubernetes version: v1.13.1
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using ''kubeadm config images pull''
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.50.21]
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.50.21 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.50.21 127.0.0.1 ::1]
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 24.002300 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.13" in namespace kube-system with the configuration for the kubelets in the cluster
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master" as an annotation
[mark-control-plane] Marking the node k8s-master as control-plane by adding the label "node-role.kubernetes.io/master=''''"
[mark-control-plane] Marking the node k8s-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: 7ax0k4.nxpjjifrqnbrpojv
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
Your Kubernetes master has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of machines by running the following on each node
as root:
kubeadm join 192.168.50.21:6443 --token 7ax0k4.nxpjjifrqnbrpojv --discovery-token-ca-cert-hash sha256:95942f10859a71879c316e75498de02a8b627725c37dee33f74cd040e1cd9d6b
初始化过程说明:
1) [preflight] kubeadm 执行初始化前的检查。
2) [kubelet-start] 生成 kubelet 的配置文件”/var/lib/kubelet/config.yaml”
3) [certificates] 生成相关的各种 token 和证书
4) [kubeconfig] 生成 KubeConfig 文件,kubelet 需要这个文件与 Master 通信
5) [control-plane] 安装 Master 组件,会从指定的 Registry 下载组件的 Docker 镜像。
6) [bootstraptoken] 生成 token 记录下来,后边使用 kubeadm join 往集群中添加节点时会用到
7) [addons] 安装附加组件 kube-proxy 和 kube-dns。
8) Kubernetes Master 初始化成功,提示如何配置常规用户使用 kubectl 访问集群。
9) 提示如何安装 Pod 网络。
10) 提示如何注册其他节点到 Cluster。
异常情况:
[WARNING Service-Docker]: docker service is not enabled, please run ''systemctl enable docker.service''
[WARNING Swap]: running with swap on is not supported. Please disable swap
[WARNING Hostname]: hostname "k8s-master" could not be reached
[WARNING Hostname]: hostname "k8s-master": lookup k8s-master on 114.114.114.114:53: no such host
[WARNING Service-Kubelet]: kubelet service is not enabled, please run ''systemctl enable kubelet.service''
运行
systemctl enable docker.service
systemctl enable kubelet.service
会提示以下错误
[WARNING Hostname]: hostname "k8s-master" could not be reached
[WARNING Hostname]: hostname "k8s-master": lookup k8s-master on 114.114.114.114:53: no such host
error execution phase preflight: [preflight] Some fatal errors occurred:
配置 host
cat >> /etc/hosts << EOF
192.168.50.21 k8s-master
192.168.50.22 k8s-node01
192.168.50.23 k8s-node02
EOF
再次运行初始化命令会出现
[ERROR NumCPU]: the number of available CPUs 1 is less than the required 2 --设置虚拟机CPU个数大于2
[ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables contents are not set to 1
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
设置好虚拟机 CPU 个数,重启后再次运行:
kubeadm init \
--apiserver-advertise-address=192.168.50.21 \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.13.1 \
--pod-network-cidr=10.244.0.0/16
[init] Using Kubernetes version: v1.13.1
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using ''kubeadm config images pull
解决办法:docker.io 仓库对 google 的容器做了镜像,可以通过下列命令下拉取相关镜像
先看下需要用到哪些
kubeadm config images list
配置 yum 源
[root@k8s-master opt]# vi kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.1
imageRepository: registry.aliyuncs.com/google_containers
apiServer:
certSANs:
- 192.168.50.21
controlPlaneEndpoint: "192.168.50.20:16443"
networking:
# This CIDR is a Calico default. Substitute or remove for your CNI provider.
podSubnet: "172.168.0.0/16"
kubeadm config images pull --config /opt/kubeadm-config.yaml
初始化 master
kubeadm init --config=kubeadm-config.yaml --upload-certs
xecution phase preflight: [preflight] Some fatal errors occurred:
[ERROR FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml]: /etc/kubernetes/manifests/kube-apiserver.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml]: /etc/kubernetes/manifests/kube-controller-manager.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml]: /etc/kubernetes/manifests/kube-scheduler.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-etcd.yaml]: /etc/kubernetes/manifests/etcd.yaml already exists
[ERROR Port-10250]: Port 10250 is in use
kubeadm 会自动检查当前环境是否有上次命令执行的 “残留”。如果有,必须清理后再行执行 init。我们可以通过”kubeadm reset” 来清理环境,以备重来。
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
== 原因 ==
这是因为 kubelet 没启动
== 解决 ==
systemctl restart kubelet
如果启动不了 kubelet
kubelet.service - kubelet: The Kubernetes Node Agent
则可能是 swap 交换分区还开启的原因
- 关闭 swap
swapoff -a
- 配置 kubelet
vi /etc/sysconfig/kubelet
KUBELET_EXTRA_ARGS="--fail-swap-on=false"
再次运行
kubeadm init \
--apiserver-advertise-address=192.168.50.21 \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.13.1 \
--pod-network-cidr=10.244.0.0/16
配置 kubectl
kubectl 是管理 Kubernetes Cluster 的命令行工具,前面我们已经在所有的节点安装了 kubectl。Master 初始化完成后需要做一些配置工作,然后 kubectl 就能使用了。
依照 kubeadm init 输出的最后提示,推荐用 Linux 普通用户执行 kubectl。
- 创建普通用户 centos
#创建普通用户并设置密码123456
useradd centos && echo "centos:123456" | chpasswd centos
#追加sudo权限,并配置sudo免密
sed -i ''/^root/a\centos ALL=(ALL) NOPASSWD:ALL'' /etc/sudoers
#保存集群安全配置文件到当前用户.kube目录
su - centos
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
#启用 kubectl 命令自动补全功能(注销重新登录生效)
echo "source <(kubectl completion bash)" >> ~/.bashrc
需要这些配置命令的原因是:Kubernetes 集群默认需要加密方式访问。所以,这几条命令,就是将刚刚部署生成的 Kubernetes 集群的安全配置文件,保存到当前用户的.kube 目录下,kubectl 默认会使用这个目录下的授权信息访问 Kubernetes 集群。
如果不这么做的话,我们每次都需要通过 export KUBECONFIG 环境变量告诉 kubectl 这个安全配置文件的位置。
配置完成后 centos 用户就可以使用 kubectl 命令管理集群了。
查看集群状态:
kubectl get cs
部署网络插件
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
kubectl get 重新检查 Pod 的状态
部署 worker 节点
在 master 机器保存生成号的镜像文件
docker save -o master.tar registry.aliyuncs.com/google_containers/kube-proxy:v1.13.1 registry.aliyuncs.com/google_containers/kube-apiserver:v1.13.1 registry.aliyuncs.com/google_containers/kube-controller-manager:v1.13.1 registry.aliyuncs.com/google_containers/kube-scheduler:v1.13.1 registry.aliyuncs.com/google_containers/coredns:1.2.6 registry.aliyuncs.com/google_containers/etcd:3.2.24 registry.aliyuncs.com/google_containers/pause:3.1
注意对应的版本号
将 master 上保存的镜像同步到节点上
scp master.tar node01:/root/
scp master.tar node02:/root/
将镜像导入本地,node01,node02
docker load< master.tar
配置 host,node01,node02
cat >> /etc/hosts << EOF
192.168.50.21 k8s-master
192.168.50.22 k8s-node01
192.168.50.23 k8s-node02
EOF
配置 iptables,node01,node02
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
- 关闭 swap,node01,node02
swapoff -a
- 配置 kubelet,node01,node02
vi /etc/sysconfig/kubelet
KUBELET_EXTRA_ARGS="--fail-swap-on=false"
systemctl enable docker.service
systemctl enable kubelet.service
启动 docker,node01,node02
service docker strat
部署网络插件,node01,node02
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
获取 join 指令,master
kubeadm token create --print-join-command
kubeadm token create --print-join-command
kubeadm join 192.168.50.21:6443 --token n9g4nq.kf8ppgpgb3biz0n5 --discovery-token-ca-cert-hash sha256:95942f10859a71879c316e75498de02a8b627725c37dee33f74cd040e1cd9d6b
在子节点运行指令 ,node01,node02
kubeadm join 192.168.50.21:6443 --token n9g4nq.kf8ppgpgb3biz0n5 --discovery-token-ca-cert-hash sha256:95942f10859a71879c316e75498de02a8b627725c37dee33f74cd040e1cd9d6b
[preflight] Running pre-flight checks
[discovery] Trying to connect to API Server "192.168.50.21:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://192.168.50.21:6443"
[discovery] Requesting info from "https://192.168.50.21:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "192.168.50.21:6443"
[discovery] Successfully established connection with API Server "192.168.50.21:6443"
[join] Reading configuration from the cluster...
[join] FYI: You can look at this config file with ''kubectl -n kube-system get cm kubeadm-config -oyaml''
[kubelet-start] WARNING: unable to stop the kubelet service momentarily: [exit status 4]
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.13" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-node01" as an annotation
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
Run ''kubectl get nodes'' on the master to see this node join the cluster.
在 master 上查看节点状态
kubectl get nodes
这种状态是错误的 ,只有一台联机正确
查看 node01,和 node02 发现 node01 有些进程没有完全启动
删除 node01 所有运行的容器,node01
docker stop $(docker ps -q) & docker rm $(docker ps -aq)
重置 kubeadm ,node01
kubeadm reset
获取 join 指令,master
kubeadm token create --print-join-command
再次在 node01 上运行 join
查看 node01 镜像运行状态
查看 master 状态
nodes 状态全部为 ready,由于每个节点都需要启动若干组件,如果 node 节点的状态是 NotReady,可以查看所有节点 pod 状态,确保所有 pod 成功拉取到镜像并处于 running 状态:
kubectl get pod --all-namespaces -o wide
配置 kubernetes UI 图形化界面
创建 kubernetes-dashboard.yaml
# Copyright 2017 The Kubernetes Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# ------------------- Dashboard Secret ------------------- #
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-certs
namespace: kube-system
type: Opaque
---
# ------------------- Dashboard Service Account ------------------- #
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kube-system
---
# ------------------- Dashboard Role & Role Binding ------------------- #
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: kubernetes-dashboard-minimal
namespace: kube-system
rules:
# Allow Dashboard to create ''kubernetes-dashboard-key-holder'' secret.
- apiGroups: [""]
resources: ["secrets"]
verbs: ["create"]
# Allow Dashboard to create ''kubernetes-dashboard-settings'' config map.
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
# Allow Dashboard to get, update and delete Dashboard exclusive secrets.
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs"]
verbs: ["get", "update", "delete"]
# Allow Dashboard to get and update ''kubernetes-dashboard-settings'' config map.
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["kubernetes-dashboard-settings"]
verbs: ["get", "update"]
# Allow Dashboard to get metrics from heapster.
- apiGroups: [""]
resources: ["services"]
resourceNames: ["heapster"]
verbs: ["proxy"]
- apiGroups: [""]
resources: ["services/proxy"]
resourceNames: ["heapster", "http:heapster:", "https:heapster:"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: kubernetes-dashboard-minimal
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: kubernetes-dashboard-minimal
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kube-system
---
# ------------------- Dashboard Deployment ------------------- #
kind: Deployment
apiVersion: apps/v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kube-system
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: kubernetes-dashboard
template:
metadata:
labels:
k8s-app: kubernetes-dashboard
spec:
containers:
- name: kubernetes-dashboard
image: registry.cn-hangzhou.aliyuncs.com/rsqlh/kubernetes-dashboard:v1.10.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8443
protocol: TCP
args:
- --auto-generate-certificates
# Uncomment the following line to manually specify Kubernetes API server Host
# If not specified, Dashboard will attempt to auto discover the API server and connect
# to it. Uncomment only if the default does not work.
# - --apiserver-host=http://my-address:port
volumeMounts:
- name: kubernetes-dashboard-certs
mountPath: /certs
# Create on-disk volume to store exec logs
- mountPath: /tmp
name: tmp-volume
livenessProbe:
httpGet:
scheme: HTTPS
path: /
port: 8443
initialDelaySeconds: 30
timeoutSeconds: 30
volumes:
- name: kubernetes-dashboard-certs
secret:
secretName: kubernetes-dashboard-certs
- name: tmp-volume
emptyDir: {}
serviceAccountName: kubernetes-dashboard
# Comment the following tolerations if Dashboard must not be deployed on master
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
---
# ------------------- Dashboard Service ------------------- #
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kube-system
spec:
type: NodePort
ports:
- port: 443
targetPort: 8443
nodePort: 30000
selector:
k8s-app: kubernetes-dashboard
执行以下命令创建 kubernetes-dashboard:
kubectl create -f kubernetes-dashboard.yaml
如果出现
Error from server (AlreadyExists): error when creating "kubernetes-dashboard.yaml": secrets "kubernetes-dashboard-certs" already exists
Error from server (AlreadyExists): error when creating "kubernetes-dashboard.yaml": serviceaccounts "kubernetes-dashboard" already exists
Error from server (AlreadyExists): error when creating "kubernetes-dashboard.yaml": roles.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" already exists
Error from server (AlreadyExists): error when creating "kubernetes-dashboard.yaml": rolebindings.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" already exists
Error from server (AlreadyExists): error when creating "kubernetes-dashboard.yaml": deployments.apps "kubernetes-dashboard" already exists
运行 delete 清理
kubectl delete -f kubernetes-dashboard.yaml
查看组件运行状态
kubectl get pods --all-namespaces
ErrImagePull 拉取镜像失败
手动拉取 并重置 tag
docker pull registry.cn-hangzhou.aliyuncs.com/rsqlh/kubernetes-dashboard:v1.10.1
docker tag registry.cn-hangzhou.aliyuncs.com/rsqlh/kubernetes-dashboard:v1.10.1 k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
重新创建
ImagePullBackOff
默认情况是会根据配置文件中的镜像地址去拉取镜像,如果设置为 IfNotPresent 和 Never 就会使用本地镜像。
IfNotPresent :如果本地存在镜像就优先使用本地镜像。
Never:直接不再去拉取镜像了,使用本地的;如果本地不存在就报异常了。
spec:
containers:
- name: kubernetes-dashboard
image: registry.cn-hangzhou.aliyuncs.com/rsqlh/kubernetes-dashboard:v1.10.1
imagePullPolicy: IfNotPresent
查看映射状态
kubectl get service -n kube-system
创建能够访问 Dashboard 的用户
新建文件 account.yaml
,内容如下:
# Create Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kube-system
---
# Create ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: admin-user
namespace: kube-system
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk ''{print $1}'')
复制 token 登陆
configmaps is forbidden: User "system:serviceaccount:kube-system:admin-user" cannot list resource "configmaps" in API group "" in the namespace "default"
授权用户
kubectl create clusterrolebinding test:admin-user --clusterrole=cluster-admin --serviceaccount=kube-system:admin-user
NodePort
方式,可以到任意一个节点的 XXXX
端口查看
Docker 学习 - Kubernetes - Spring Boot 应用
本文参考:
https://www.cnblogs.com/tylerzhou/p/10971336.html
https://www.cnblogs.com/zoujiaojiao/p/10986320.html
原文出处:https://www.cnblogs.com/woxpp/p/11875547.html
Docker 学习(六)-Kubernetes - Spring Boot 应用
接上一篇
https://www.cnblogs.com/woxpp/p/11872155.html
新建
k8s-demo.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: k8s-springboot-demo
labels:
app: k8s-springboot-demo
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: k8s-springboot-demo
template:
metadata:
labels:
app: k8s-springboot-demo
spec:
containers:
- name: k8s-springboot-demo
image: service-test:latest
ports:
- containerPort: 8080
protocol: TCP
livenessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 30
timeoutSeconds: 30
imagePullPolicy: IfNotPresent
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
---
apiVersion: v1
kind: Service
metadata:
name: k8s-springboot-demo
namespace: default
labels:
app: k8s-springboot-demo
spec:
ports:
- port: 8080
targetPort: 8080
selector:
app: k8s-springboot-demo
type: NodePort
创建 service
kubectl create -f k8s-demo.yaml
查看实列运行情况
kubectl get po,svc,deploy -o wide
测试访问
NodePort
方式,可以到任意一个节点的 30516
端口查看
Docker、kubernetes、微服务、SpringBoot/Cloud... 好乱!到底要不要学?
Docker、微服务日益火热的今天,相信标题上这些名词大家都不陌生。但也相信有很多同学并不够清楚他们的概念,不理解它们的关系,也可能有这样的疑惑:不知道跟我有没有关系?要不要学习?怎么去学习?学哪些东西?没关系,今天我们就从头捋捋,让大家都能得到自己的答案。
Docker 诞生于 2013 年,之后就是迅速串红、火的已经发烫。它为什么会火呢?有什么牛 x 的技术吗?并没有,docker 的技术都是 linux 内核早已存在的技术,像 LXC 呀,cgoup 呀,namespace 呀,都是很早就存在的。那 docker 有啥高明的地方?很重要的一个就是 image,它定义了一个交付标准,早期 docker 官网首页的三个最大的单词:build,ship,run。诠释了 docker 和核心:image 的构建,image 的传输,image 的运行。docker 就是定义并且实现了这些标准。那为什么直到 2013 年 docker 才出现呢?以前怎么没有人有这样的想法?其实想法一直都有,只是 docker 出现的时机更好,往往决定性的因素并不是技术本身,而是互联网的发展,市场的需要。
时至今日 - 2018 年,Docker 已历经 5 年发展,Docker 公司揭露了今年最新的 Docker 年度数据报告,至今在 Docker 上的容器镜像下载次数已经超过了 370 亿次,容器化的应用有高达 350 万个,目前在 LinkedIn 网站上的 Docker 相关职缺也有 15,000 个。全球活跃的 Docker 使用者社群已有 200 多个,包括台湾也有。
随着 docker、容器的日渐成熟,容器编排的问题就凸显出来,大量的容器怎么去管理,怎么调度,怎么启停都成了迫切需要解决的问题。有需求就有人去解决,ApacheMesos、kubernetes、docker swarm 陆续登场,大有三足鼎立之势,而随着各自的发展,到了 2017 年下半年,google 的亲儿子 kubernetes 的呼声越来越高,社区也更加活跃、成熟。2017 年底,docker swarm 和 ApacheMesos 陆续宣称支持 kubernetes,预示着容器编排大战的结束,kubernetes 已然成为容器编排领域的事实标准。
服务编排框架的成熟,使得容器的管理越来越方便、高效,容器带来的好处也随之凸显:提升资源利用率节省成本、更高效的持续集成,持续交付、解放运维、快速扩缩容,应对突发流量...
服务编排框架的成熟也让微服务的概念得以落地,同时也催生了 java 界微服务化的方案,像 SpringBoot,SpringCloud。然而服务编排一定是对微服务的编排吗?也就是我们容器里运行的一定是微服务吗?不是的,我们可以运行任何服务,我们现有的业务可以不做任何改造就运行到容器中,让 kubernetes 去管理、调度。至于微服务呢,只是有了 kubernetes,让微服务变得容易管理了。让我们有条件把服务拆分的足够小,足够简单。再也不用担心运维管理的复杂了。了解了 docker,服务编排,微服务的关系,我们在看看他们在企业的落地情况。
下面是数人云 2018 年初做的 it 行业系统调查报告
这张图纵向的是系统更新频率,其中互联网行业的更新频率最高,有 92% 的服务要每月都更新,并且其中一定有很多的服务要一个月更新多次。
这张图统计的是目前企业 it 系统支撑所存在的问题。我们看两个比重最大的问题,一个是系统的复杂性越来越高,一个是运维管理复杂。在传统单体架构或者 SOA 架构下,应用如果频繁升级更新,开发团队会非常痛苦。为什么呢?企业的业务系统经过多年发展,系统往往会非常庞大,复杂性越来越高,要改动其中任何一小部分,都需要重新部署整个应用,敏捷开发和快速交付根本无从谈起。还有传统企业在长期的 IT 建设过程中,往往会使用到不同的技术,这导致技术栈之间差异很大,统一的管理和运维变将得非常复杂。随着这样一些问题越来越凸显,企业向微服务架构转型的需求也越来越强烈。
这张图是目前微服务架构在企业的落地情况:有 6% 的企业已经部分引入了 Spring Cloud 开发框架。另外,9% 的受访企业采用了 Dubbo 等其他微服务框架。此外,还有 51% 的企业在考虑往云原生方向转型,包括公有云、私有云。由此可见,绝大部分企业是有架构转型的需求的。
这张图是 2017 年 docker 的使用情况。在接受调研的企业中,在生产环境中采用 Docker 的比例为 9%,测试环境使用达 22%。而且规模越大的企业,尤其是服务器规模在 500 台以上的,是 Docker 容器的主要采用者。另外,正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高,Docker 使用正在快速普及。而容器和微服务相辅相成,他们成熟的时间点也非常契合。
接下来我们看几个大厂在 docker 上的进程。
由此可见,docker,服务编排将是企业发展的必经之路。也是我们每一位开发、架构、运维同学必须了解的内容。如果你正在找工作,docker,k8s,微服务也一定能给你的简历增加一个大大的亮点!
这么多的内容我们要怎么去系统的学习呢?
别着急,慕课网给我们准备了很好的入门课程哦:《Docker+Kubernetes 微服务容器化实践》
真心的希望这门课程能够帮助到大家!让我们一起努力,变成更好的自己!
作者:刘果国
链接:https://www.imooc.com/article/28359?block_id=tuijian_wz
来源:慕课网
本文原创发布于慕课网 ,转载请注明出处,谢谢合作
关于Kubernetes 发布 SpringBoot 项目过程总结和kubernetes部署springcloud的问题就给大家分享到这里,感谢你花时间阅读本站内容,更多关于8.2、springboot启动过程总结、Docker 学习(五)-Kubernetes 集群搭建 - Spring Boot 应用、Docker 学习(六)-Kubernetes - Spring Boot 应用、Docker、kubernetes、微服务、SpringBoot/Cloud... 好乱!到底要不要学?等相关知识的信息别忘了在本站进行查找喔。
本文标签: