Kubernetes 部署 Mysql 8

mysql可以以docker的形式在集群内部署，也可以安装在集群之外，以服务的形式部署到集群内。

(1)、如果是在集群内部署，可以启动一个ReplicationController，用以对mysql pod进行监控，并同时启动一个Service，用以集群访问。

(2)、如果mysql是安装在集群之外，那么可以启动一个Endpoint和Service，将mysql引入集群之中。

下面分别对这两种方式进行部署。

创建mysql-rc.yaml和mysql-svc.yaml,分别如下：

mysql-rc.yaml

mysql-svc.yaml

在mysql-rc.yaml中，image参数可以指定mysql的版本，如8.0.11、5.7.22等。这里省略了，表示用latest。另外，可以指定镜像库，这里使用阿里云镜像库，在安装docker时进行了配置。env参数指定了mysql的root密码。

​ 在mysql-svc.yaml中，targetPort表示mysql pod中mysql窗口的目标端口，默认为3306，type类型为NodePort，表示将映射到本地端口，本地端口为nodePort: 30306。

接下来启动ReplicationController和Service，执行以下命令：

启动后可以查看mysql部署在了哪个node上，执行以下命令可以查看：

(6)、退出mysql和容器，执行quit退出mysql，按ctrl+p后，再按ctrl+q从容器中返回node主机。

设置好mysql后，可以远程连接node中的mysql，node的ip为127.0.0.1，映射的端口为30306，可以用navicat工具连接到这个myql。

Kubernetes是什么？

首先，它是一个全新的基于容器技术的分布式架构领先方案。这个方案虽然还很新，但它是谷歌十几年以来大规模应用容器技术的经验积累和升华的重要成果。确切地说，Kubernetes是谷歌严格保密十几年的秘密武器——Borg的一个开源版本。Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。十几年以来，谷歌一直通过Borg系统管理着数量庞大的应用程序集群。由于谷歌员工都签署了保密协议，即便离职也不能泄露Borg的内部设计，所以外界一直无法了解关于它的更多信息。直到2015年4月，传闻许久的Borg论文伴随Kubernetes的高调宣传被谷歌首次公开，大家才得以了解它的更多内幕。正是由于站在Borg这个前辈的肩膀上，汲取了Borg过去十年间的经验与教训，所以Kubernetes一经开源就一鸣惊人，并迅速称霸容器领域。其次，如果我们的系统设计遵循了Kubernetes的设计思想，那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块，都可以立刻从我们的视线中消失，我们不必再费心于负载均衡器的选型和部署实施问题，不必再考虑引入或自己开发一个复杂的服务治理框架，不必再头疼于服务监控和故障处理模块的开发。总之，使用Kubernetes提供的解决方案，我们不仅节省了不少于30%的开发成本，还可以将精力更加集中于业务本身，而且由于Kubernetes提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅度降低。

然后，Kubernetes是一个开放的开发平台。与J2EE不同，它不局限于任何一种语言，没有限定任何编程接口，所以不论是用Java、Go、C++还是用Python编写的服务，都可以被映射为Kubernetes的Service（服务），并通过标准的TCP通信协议进行交互。此外，Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。

最后，Kubernetes是一个完备的分布式系统支撑平台。Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。同时，Kubernetes提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此，Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

在正式开始本章的Hello World之旅之前，我们首先要学习Kubernetes的一些基本知识，这样才能理解Kubernetes提供的解决方案。

在Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征。

拥有唯一指定的名称（比如mysql-server）。

拥有一个虚拟IP（Cluster IP、Service IP或VIP）和端口号。

能够提供某种远程服务能力。

被映射到提供这种服务能力的一组容器应用上。

Service的服务进程目前都基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、

Web Server，或者是实现了某个具体业务的特定TCP Server进程。虽然一个Service通常由多个相关的服务进程提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes能够让我们通过Service（虚拟Cluster IP +Service Port）连接到指定的Service。有了Kubernetes内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否由于发生故障而被重新部署到其他机器，都不会影响对服务的正常调用。更重要的是，这个Service本身一旦创建就不再变化，这意味着我们再也不用为Kubernetes集群中服务的IP地址变来变去的问题而头疼了。

容器提供了强大的隔离功能，所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程都包装到相应的Pod中，使其成为在Pod中运行的一个容器（Container）。为了建立Service和Pod间的关联关系，Kubernetes首先给每个Pod都贴上一个标签（Label），给运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service定义标签选择器（Label Selector），比如MySQL Service的标签选择器的选择条件为name=mysql，意为该Service要作用于所有包含name=mysql Label的Pod。这样一来，就巧妙解决了Service与Pod的关联问题。

这里先简单介绍Pod的概念。首先，Pod运行在一个被称为节点（Node）的环境中，这个节点既可以是物理机，也可以是私有云或者公有云中的一个虚拟机，通常在一个节点上运行几百个Pod；其次，在每个Pod中都运行着一个特殊的被称为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中；最后，需要注意的是，并不是每个Pod和它里面运行的容器都能被映射到一个Service上，只有提供服务（无论是对内还是对外）的那组Pod才会被映射为一个服务。

在集群管理方面，Kubernetes将集群中的机器划分为一个Master和一些Node。在Master上运行着集群管理相关的一组进程kube-apiserver 、 kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、d性伸缩、安全控制、系统监控和纠错等管理功能，并且都是自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。在Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。

最后，看看传统的IT系统中服务扩容和服务升级这两个难题，以及Kubernetes所提供的全新解决思路。服务的扩容涉及资源分配（选择哪个节点进行扩容）、实例部署和启动等环节，在一个复杂的业务系统中，这两个难题基本上靠人工一步步 *** 作才得以解决，费时费力又难以保证实施质量。

在Kubernetes集群中，只需为需要扩容的Service关联的Pod创建一个RC（Replication Controller），服务扩容以至服务升级等令人头疼的问题都迎刃而解。在一个RC定义文件中包括以下3个关键信息。

目标Pod的定义。

目标Pod需要运行的副本数量（Replicas）。

要监控的目标Pod的标签。

在创建好RC（系统将自动创建好Pod）后，Kubernetes会通过在RC中定义的LabelPod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量，则会根据在RC中定义的Pod模板创建一个新的Pod，然后将此Pod调度到合适的Node上启动运行，直到Pod实例的数量达到预定目标。这个过程完全是自动化的，无须人工干预。有了RC，服务扩容就变成一个纯粹的简单数字 游戏 了，只需修改RC中的副本数量即可。后续的服务升级也将通过修改RC来自动完成。

Kubernetes 是Google开源的分布式容器管理平台，是为了更方便的在服务器中管理我们的容器化应用。

Kubernetes 简称 K8S，为什么会有这个称号？因为K和S是 Kubernetes 首字母和尾字母，而K和S中间有八个字母，所以简称 K8S，加上 Kubernetes 比较绕口，所以一般使用简称 K8S。

Kubernetes 即是一款容器编排工具，也是一个全新的基于容器技术的分布式架构方案，在基于Docker的基础上，可以提供从 创建应用>应用部署>提供服务>动态伸缩>应用更新 一系列服务，提高了容器集群管理的便捷性。

大家可以先看一下，下面一张图，里面有我们的 mysql，redis，tomcat，nginx 等配置信息，如果我们想要安装里面的数据，我们需要一个一个手动安装，好像也可以，反正也就一个，虽然麻烦了一点，但也不耽误。

但是随着技术的发展和业务的需要，单台服务器已经不能满足我们日常的需要了，越来越多的公司，更多需要的是集群环境和多容器部署，那么如果还是一个一个去部署，运维恐怕要疯掉了，一天啥也不干就去部署机器了，有时候，可能因为某一个环节出错，要重新，那真的是吐血。。。。。，如下图所示：

如果我想要部署，以下几台机器：

如果要一个一个去部署，人都要傻掉了，这什么时候是个头，如果是某里巴的两万台机器，是不是要当场提交辞职信，所以 K8S 就是帮助我们来做这些事情的，方便我们对容器的管理和应用的自动化部署，减少重复劳动，并且能够自动化部署应用和故障自愈。

并且如果 K8S 对于微服务有很好的支持，并且一个微服务的副本可以跟着系统的负荷变化进行调整，K8S 内在的服务d性扩容机制也能够很好的应对突发流量。

Docker-Compose 是用来管理容器的，类似用户容器管家，我们有N多台容器或者应用需要启动的时候，如果手动去 *** 作，是非常耗费时间的，如果有了 Docker-Compose 只需要一个配置文件就可以帮我们搞定，但是 Docker-Compose 只能管理当前主机上的 Docker，不能去管理其他服务器上的服务。意思就是单机环境。

Docker Swarm 是由Docker 公司研发的一款用来管理集群上的Docker容器工具，弥补了 Docker-Compose 单节点的缺陷， Docker Swarm 可以帮助我们启动容器，监控容器的状态，如果容器服务挂掉会重新启动一个新的容器，保证正常的对外提供服务，也支持服务之间的负载均衡。而且这些东西 Docker-Compose 是不支持的，

Kubernetes 它本身的角色定位是和 Docker Swarm 是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，当然也要一些不一样的特点， Kubernetes 是谷歌自己的产品，经过大量的实践和宿主机的实验，非常的成熟，所以 Kubernetes 正在成为容器编排领域的领导者，其 可配置性、可靠性和社区的广大支持，从而超越了 Docker Swarm ，作为谷歌的开源项目，它和整个谷歌的云平台协调工作。

在下图中，是K8S的一个集群，在这个集群中包含三台宿主机，这里的每一个方块都是我们的物理虚拟机，通过这三个物理机，我们形成了一个完整的集群，从角色划分，可以分为两种

打一个比较形象的比喻，我们可以把Pod理解成一个豆荚，容器就是里面的豆子，是一个共生体。

Pod里面到底装的是什么？

具体怎么部署Pod里面的容器，是按照我们项目的特性和资源的分配进行合理选择的。

pause容器：

Pause容器 全称infrastucture container（又叫infra）基础容器，作为init pod存在，其他pod都会从pause 容器中fork出来，这个容器对于Pod来说是必备的

一个Pod中的应用容器共享同一个资源：

在上图中如果没有 pause容器 ，我们的Nginx和Ghost，Pod内的容器想要彼此通信的话，都需要使用自己的IP地址和端口，才可以彼此进行访问，如果有 pause容器 ，对于整个Pod来说，我们可以看做一个整体，也就是我们的Nginx和Ghost直接使用localhost就可以进行访问了，他们唯一不同的就只是端口，这里面可能看着觉得比较简单，但其实是使用了很多网络底层的东西才实现的，感兴趣的小伙伴可以自行了解一下。

在 Kubernetes 中，每个Pod都会被分配一个单独的IP地址，但是Pod和Pod之间，是无法直接进行交互的，如果想要进行网络通信，必须要通过另外一个组件才能交流，也就是我们的 Service

Service 是服务的意思，在K8S中 Service 主要工作就是将多个不同主机上的Pod，通过 Service 进行连通，让Pod和Pod之间可以正常的通信

我们可以把 Service 看做一个域名，而相同服务的Pod集群就是不同的ip地址， Service 是通过 Label Selector 来进行定义的。

使用NodePort提供外部访问，只需要在每个Node上打开一个主机的真实端口，这样就可以通过Node的客户端访问到内部的Service。

Label 一般以 kv的方式附件在各种对象上，Label 是一个说明性的标签，它有着很重要的作用，我们在部署容器的时候，在哪些Pod进行 *** 作，都需要根据Label进行查找和筛选，我们可以理解Label是每一个Pod的别名，只有取了名称，作为K8S的Master主节点才能找到对应的Pod进行 *** 作。

用户通过 Kubectl 提交一个创建 Replication Controller 请求，这个请求通过 API Server 写入 etcd 中，这个时候 Controller Manager 通过 API Server 的监听到了创建的命名，经过它认真仔细的分析以后，发现当前集群里面居然还没有对应的Pod实例，赶紧根据 Replication Controller 模板定义造一个Pod对象，再通 过Api Server 写到我们 etcd 里面

到下面，如果被 Scheduler 发现了，好家伙不告诉我？？？，无业游民，这家伙一看就不是一个好人啊，它就会立即运行一个复杂的调度流程，为这个新的Pod选一个可以落户的Node，总算有个身份了，真是让人 *** 心，然后通过 API Server 将这个结果也写到etcd中，随后，我们的 Node 上运行的小管家 Kubelet 进程通过 API Server 检测到这个 新生的小宝宝——“Pod”，就会按照它，就会按照这个小宝宝的特性，启动这个Pod并任劳任怨的负责它的下半生，直到Pod的生命结束。

然后我们通过 Kubectl 提交一个新的映射到这个Pod的Service的创建请求， Controller Manager 会通过Label标签查询到相关联的Pod实例，生成Service的Endpoints的信息，并通过 API Server 写入到etcd中，接下来，所有 Node 上运行的Proxy进程通过 Api Server 查询并监听 Service对象 与其对应的 Endpoints 信息，建立一个软件方式的负载均衡器来实现 Service 访问到后端Pod的流量转发功能。

kube-proxy： 是一个代理，充当这多主机通信的代理人，前面我们讲过Service实现了跨主机、跨容器之间的网络通信，在技术上就是通过 kube-proxy 来实现的，service是在逻辑上对Pod进行了分组，底层是通过 kube-proxy 进行通信的

kubelet： 用于执行K8S的命令，也是K8S的核心命令，用于执行K8S的相关指令，负责当前Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里

etcd： 用于持久化存储集群中所有的资源对象，API Server提供了 *** 作 etcd的封装接口API，这些API基本上都是对资源对象的 *** 作和监听资源变化的接口

API Server ： 提供资源对象的 *** 作入口，其他组件都需要通过它提供 *** 作的API来 *** 作资源数据，通过对相关的资源数据“全量查询”+ “变化监听”，可以实时的完成相关的业务功能。

Scheduler ： 调度器，负责Pod在集群节点中的调度分配。

Controller Manager： 集群内部管理控制中心，主要是实现 Kubernetes 集群的故障检测和恢复的自动化工作。比如Pod的复制和移除，Endpoints对象的创建和更新，Node的发现、管理和状态监控等等都是由 Controller Manager 完成。

到这里K8S的基本情况我们就讲解完毕了，有喜欢的小伙伴记得 点赞关注 ，相比如Docker来说K8S有着更成熟的功能，经过谷歌大量实践的产物，是一个比较成熟和完善的系统。

关于K8S大家有什么想要了解或者疑问的地方欢迎大家留言告诉我。

我是牧小农，一个卑微的打工人，如果觉得文中的内容对你有帮助，记得一键三连，你们的三连是小农最大的动力。

---