Kubernetes安装部署

coder二哈

已于 2023-11-26 17:22:17 修改

阅读量996

点赞数 25

文章标签： kubernetes 容器云原生

于 2023-11-26 17:21:12 首次发布

本文链接：https://blog.csdn.net/er_ha_is/article/details/134630164

版权

设备名称软件环境（镜像）硬件环境
主机 Ubuntu16.04桌面版 CPU：2核内存：4G 磁盘：20G

一、Kubernetes基本概念

Kubernetes的名字来自希腊语，意思是“舵手”或“领航员”。k8s是将8个字母“ubernete”替换为“8”的缩写。Kubernetes是最开始由google设计开发，并最后贡献给Cloud Native Computing Foundation的开源容器集群管理项目。它的设计目标是在主机集群之间提供一个能够自动化部署、可拓展、应用容器可运营的平台。Kubernetes通常结合docker容器工具工作，并且整合多个运行着docker容器的主机集群。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。下图是对Kubernetes的总体概览，接下来从如下三个维度来认识Kubernetes。
在这里插入图片描述

维度1：操作对象
Kubernetes以RESTFul形式开放接口，用户可操作的REST对象有三个：

pod：是Kubernetes最基本的部署调度单元，可以包含container，逻辑上表示某种应用的一个实例。比如一个web站点应用由前端、后端及数据库构建而成，这三个组件运行在各自的容器中，那么我们可以创建包含三个container的pod。
service：是pod的路由代理抽象，用于解决pod之间的服务发现问题。因为pod的运行状态可动态变化(比如切换机器、缩容过程中被终止等)，所以客户端不能以写死IP的方式去访问该pod提供的服务。service的引入旨在保证pod的动态变化对客户端透明，客户端只需要知道service的地址，由service来提供代理。
replicationController：是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过replicationController，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个pod，并且保证实际运行pod数量总是与该复制数量相等(例如，当前某个pod宕机时，自动创建新的pod来替换)。
可以看到，service和replicationController只是建立在pod之上的抽象，最终是要作用于pod的，那么它们如何跟pod联系起来呢？这就要引入label的概念：label其实很好理解，就是为pod加上可用于搜索或关联的一组key/value标签，而service和replicationController正是通过label来与pod关联的。如下图所示，有三个pod都有label为”app=backend”的标签，创建service和replicationController时可以指定同样的label:”app=backend”，再通过label selector机制，就将它们与这三个pod关联起来了。例如，当有其他frontend pod访问该service时，自动会转发到其中的一个backend pod。
维度2：功能组件
Kubernetes集群包含有节点代理kubelet和Master组件(APIs，scheduler, etc)，一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图。

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

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

kube-dns：负责为整个集群提供DNS服务；
Ingress Controller：为服务提供外网入口；
Heapster：提供资源监控；
Dashboard：提供GUI；
Federation：提供跨可用区的集群；
Fluentd-elasticsearch：提供集群日志采集、存储与查询。
维度3：工作流
上文已经提到了Kubernetes中最基本的三个操作对象：pod，replicationController及service。下面分别从它们的对象创建出发，通过时序图来描述Kubernetes各个组件之间的交互及其工作流程。
Pod创建流程：
在这里插入图片描述

Controller创建流程：
在这里插入图片描述

Service创建流程：
在这里插入图片描述

二、Dashboard界面结构

Kubernetes Dashboard界面设计友好，自解释性强，可以看作GUI版的kubectl。Dashboard的界面很简洁，分为三个大的区域。
1、顶部操作区
在这里插入图片描述

在这里用户可以搜索集群中的资源、创建资源或退出。
2、左边导航菜单
通过导航菜单可以查看和管理集群中的各种资源。菜单项按照资源的层级分为两类：

Cluster级别的资源
在这里插入图片描述

Namespace级别的资源
在这里插入图片描述

默认显示的是default Namespace，可以进行切换：
在这里插入图片描述

3、中间主体区
在导航菜单中点击了某类资源，中间主体区就会显示该资源所有实例，比如点击Pods。
在这里插入图片描述

三、Kubernetes安装部署
Kubernetes安装部署的常用方式有两种：一种是源码安装。从网上直接下载源码包和编译工具，然后编译和安装。这种安装方法是最原始的，该安装方法在安装过程中可以选择Kubernetes的版本，用户可以了解Kubernetes的各个组件和作用。但是该方法安装复杂度高，且受国内网络环境影响。第二种是使用kubeasz工具安装Kubernetes集群，kubeasz为github上开源的一个用于安装Kubernetes集群的项目，kubeasz使用Ansible脚本部署，目前更新了21个版本，是比较成熟的部署方式。安装时可以采用all in one的方式，也可以采用分布式部署。使用kubeasz部署的优点包括：
1、提供安装包和部署脚本，避免去外网下载文件。
2、配置文件较少，能够全自动安装。
3、安装耗时较少，快速便捷。
本实验采用第二种方式安装部署。

四、Ansible概述
Ansible简单的说是一个配置管理系统(configuration management system)。只需要可以使用ssh访问你的服务器或设备就行。它也不同于其他工具，因为它使用推送的方式，而不是像puppet等那样使用拉取安装agent的方式，可以将代码部署到任意数量的服务器上。Ansible可以帮助我们完成一些批量任务，或者完成一些需要经常重复的工作。以下场景中都可以使用到ansible。

比如：同时在100台服务器上安装nginx服务，并在安装后启动它们。
比如：将某个文件一次性拷贝到100台服务器上。
比如：每当有新服务器加入工作环境时，你都要为新服务器部署某个服务，也就是说你需要经常重复的完成相同的工作。
Ansible特性如下：

模块化：调用特定的模块，完成特定任务
有Paramiko，PyYAML，Jinja2（模板语言）三个关键模块
支持自定义模块
基于Python语言实现
部署简单，基于python和SSH(默认已安装)，agentless
安全，基于OpenSSH
支持playbook编排任务
幂等性：一个任务执行1遍和执行n遍效果一样，不因重复执行带来意外情况
无需代理不依赖PKI（无需ssl）
可使用任何编程语言写模块
YAML格式，编排任务，支持丰富的数据结构
较强大的多层解决方案
Ansible的架构如下图所示：
在这里插入图片描述

主要组成部分和功能说明如下：

PLAYBOOKS：任务剧本（任务集），编排定义Ansible任务集的配置文件，由Ansible顺序依次执行，通常是JSON格式的YML文件。
INVENTORY：Ansible管理主机的清单/etc/anaible/hosts。
MODULES：Ansible执行命令的功能模块，多数为内置的核心模块，也可自定义。
PLUGINS：模块功能的补充，如连接类型插件、循环插件、变量插件、过滤插件等，该功能不常用。
API：供第三方程序调用的应用程序编程接口。
ANSIBLE：组合INVENTORY、API、MODULES、PLUGINS的绿框，可以理解为是Ansible命令工具，其为核心执行工具。