2020/05/02 企业部署实战1

前情回顾

容器的发展历史=>(docker一统天下，做成了标准化)

docker引擎给互联网应用带来的意义：3个统一，
docker引擎统一了基础设施环境-docker环境（不用关注什么型号的服务器，dell720，惠普g380，dell740，不用关注服务器上安装的操作系统版本，运行环境）要完整使用docker，建议内核3.8以上

docker引擎统一了程序打包（装箱）方式-docker镜像（不管用java，python还是nodejs，go，perl，都可以封装成docker镜像）

统一了程序部署方式 (如果是springboot程序就需要用java -jar，tomcatweb程序需要打包成var包，无论怎样启动，docker 就是docker run）

docker引擎也存在一些问题
1.单机使用，没有办法有效集群
2.随着容器数量的上升，管理成本攀升
3.没有有效的容灾/自愈机制
4.没有预设编排模版，无法实现快速、大规模容器调度
5.没有统一的配置管理中心工具（虽然可以用环境变量，但是没有统一的配置管理中心工具）
6.没有容器生命周期管理工具
7.没有图形化运维管理工具

所以我们需要一个容器编排工具。分析了优势列数，需要docker引的编排工具。
docker compose是基于docker引擎的单机编排工具，docker swarm是用来和其他编排工具抗衡的编排工具。
2015年mesosphere和marathon非常火，mesosphere不仅对容器可以编排，还可以对硬件进行编排整合。
2014年，google开源kubernetes，k8s编排

大纲

2.3 K8S的概述

k8s是google2014年开源，源自于谷歌自己的borg系统

有很多文档
basics基础文档，setup安装，如何使用k8s，参考文档，给docs文档做贡献

goggle把k8s捐给了cncf，云原生软件基金会

release就是github上维护的k8s发行版，一般是一年四个版本，一季度一个

1.16版本废弃了以前的很多API接口，这就导致很多周边软件可能有问题的，所以建议1.15

docker来源英语，是码头工人，码头打包好集装箱，k8s将这些集装箱运到生产一线



解决的痛点就是docker的缺点

K8S把docker引擎打包好的基础镜像，运载到生产第一线。docker是码头工人打包的集装箱，k8s就是把它运到一线的舵手

K8S的优势

k8s的优势也就是docker的劣势
1.自动装箱，水平扩展，自我修复
2.服务发现和负载均衡
3.自动发布（默认滚动发布模式，）（4种典型发布模式：蓝绿发布，滚动发布，灰度发布，“金狮桥发布"）和回滚
4.集中化配置管理和秘钥管理（k8s有集中配置中心）
5.存储编排
6.任务批处理运行

2.5 K8S快速入门–Pod和Pod控制器

k8s需要先理解4组概念：一组2个概念
1.Pod/Pod控制器
2.Name/Namespace
3.Label/Lanel选择器
4.Service/Ingress

Pod是k8s里能够运行的最小逻辑单元（也叫原子单元）
1个Pod里面可以运行多个容器，里面的容器它们共享UTS+NET+IPC名称空间（容器之所以称为容器，要隔离6个维度的名称空间，UTS,NET,IPC,PID,USR,MOUNT）
可以把Pod理解成豌豆荚，而同一Pod内的每个容器是一颗颗豌豆
一个Pod里运行多个容器，又叫：边车(SideCar)模式（类似侉子，挎斗不提供动力，动力又摩托车提供）

Pod控制器
Pod控制器是Pod启动的一种模版，用来保证在K8s里启动的Pod应始终按照人们的预期运行（比如副本数、生命周期、监控状态检查。。）
生产中建议用pod控制器来控制pod，尽管可以单独起一个pod，pod控制器是控制pod按照你预想的运行
K8S提供了众多的Pod控制器，常用的有以下几种：
Deployment 部署（常用）
DaemonSet 要求每一个运算节点都起一份 （常用）
ReplicaSet Deployment 管ReplicaSet ，ReplicaSet 管pod，本身ReplicaSet 不对外提供服务
Statefulset 管理有状态应用pod控制器
Job 管理任务
Cronjob 管理定时周期任务

K8S快速入门–name和namespace

由K8S内部来使用资源来定义每一种逻辑概念，每一种资源都应该有自己的名称，也就是Name。K8s因为是面向对象编程思维，每一种功能的实现都是资源的一种实例化，每一种资源应该有自己的名称

一般每一种资源有5个维度的信息去定义资源：
api版本（apiversion）、类别（kind），元数据（metadata）、定义清单（spec）、状态（status）等配置信息

一般资源名称定义在资源的元数据（metadata）信息里

namespace:
随着项目增多、人员增加、集群规模的扩大，需要一种能够隔离K8s内各种“资源”的方法，这就是名称空间。（名称空间可以做一定程度的隔离，但是没有那种严格的网络限制，只是把资源分组了）
名称空间可以理解为K8s内部的虚拟集群组。
不同名称空间内的“资源”，名称可以相同。相同名称空间内的同种“资源”，“名称”不能相同。
合理的使用K8S的名称空间，使得集群管理员能够更好的对交付到K8S里的服务进行分类管理和浏览。（因为分类了所以能更好管理集群资源）。
K8S里默认存在的名称空间有：default、kube-system、kube-public。
查询K8S里特定“资源”要带上相应的名称空间。

2.7 K8S快速入门–标签和标签选择器

Label：
标签是K8S特色的管理方式，便于分类管理资源对象。
一个标签可以对应多个资源，一个资源也可以有多个标签，它们是多对多的关系。
一个资源拥有多个标签，可以实现不同维度的管理。(资源有多个标签，比如特定的标签打上污点，特定的扩容）
标签的组成：key=value
与标签类似的，还有一种：“注解”(annotations)，标签的value值更严格些，63个字节不超过，所以范围是alphanumber，中间下划线，浮点，横线-。所以标签的值更严格一些

Label选择器：（过滤标签，并执行我们想要的操作）
给资源打上标签后，可以使用标签选择器过滤指定的标签
标签选择器目前有两个：基于等值关系（等于、不等于）和基于集合关系（属于、不属于、存在）。
许多资源支持内嵌标签选择器字段：
matchLabels
matchExpressions

2.8 K8S快速入门–Service和Ingress

Service：
在K8S的世界里，虽然每个Pod都会被分配一个单独的IP地址，但这个IP地址会随着Pod的销毁而消失。（Pod有生命周期，ip地址变动，为了避免调度问题，K8s抽象了一种资源service）。
Service（服务）就是用来解决这个问题的核心概念。
一个Service可以看作一组提供相同服务的Pod的对外访问接口。
Service作用于哪些Pod是通过标签来选择器来定义的。（用matchLabels来选择）

一个K8S集群对应三套网络（node节点网络，pod网络，service网络（cluster ip，由核心组件kube-proxy，来真正实现cluster网络和pod网络实现了一个联结关系））

service暴露Pod地址，其实是在osi第四层暴露的，暴露的是POD提供的ip和端口

Ingress：（k8s缺啥像NGINX提供的url，http，https，缺少7层反代的机制，所提供了Ingress）
Ingress是K8s集群里工作在OSI网络参考模型下，第7层的应用，对外暴露的接口。
Service只能进行L4流量调度，表现形式是IP+port。
Ingress则可以调度不同业务域、不同URL访问路径的业务流量。

ingress可以根据你的url比如http：//abc.com/shanghai 先去找service 再去找pod

2.9 K8S的三条网络详解

转到K8S软件组成的讲解
分为三大类：核心组件

核心组件里：
配置中心-》etcd集群
主控节点（master）：kube-apiserver，kube-controller-manager，kube-scheduler
运算节点（node）：kube-kubelet、kube-proxy服务
CLI客户端（kubectl）
大概有三种方法去管理k8s核心资源，陈述式管理，申明式管理，GUIweb管理

4个核心附件：
CNI网络插件-》flannel/calico
服务发现用插件->coredns
服务暴露用插件->traefik
GUI管理插件->dashboard

ETCD类似zookeeper，这种配置管理中心，主要是用来存储集群的元数据信息，k8s有状态，请求，资源配额情况都会存在etcd里。可以理解为非关系型数据库来存储k8s的数据

主控节点上分为3个服务，
kube-apiserver、对整个k8s的集群对象管理，只有通过k8sapi的来实现，所有的组件都要通过apiserver来进行通信
kube-controller-manager，控制器管理器，pod控制器就是一种控制器
kube-scheduler

kube-controller-manager，控制器管理器，pod控制器就是一种控制器。
k8s总共有很多控制器
node controller节点控制器
deployment controller pod控制器
service controller 服务控制器
volume controller 卷控制器
endpoint controller 接入点控制器
garbage controller 垃圾回收控制器
namespace controller 名称空间控制器
job controller任务控制器
resource quta controller 资源配额控制器
等，所有控制器都由kube-controller-manager管理

kube-scheduler：现在有一个请求，通过apiserver进入到scheduler创建一系列pod，首先apiserver先找controller-manager找到模版启动一批pod，controller-manager找到scheduler，挑选策略在哪里启动。有两种策略，预算策略，优选策略帮你选择
主要功能是接收调度Pod到合适的运算节点上。
预算策略（predict）
优选策略（priorities）

kubelet，就是定时从某个节点上获取pod的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口（docker接口）达到这个状态。kubelet要找apiserver去看pod期望状态是什么，如果期望状态和目前状态不一致，要想方设法变成一致

定时汇报当前节点的状态给apiserver，以供调度的时候使用。

镜像和容器的清理工作，保证节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源

kube-proxy：
是k8s在每个节点上运行网络代理，service资源的载体。
说白了就是建立了pod网络和集群网络（虚拟网络）的关系（clusterip-podip，关联起来了），本身并不是直接给pod提供网络（pod跑在什么网络里是kubelet提供的）。
常用三种流量调度模式：Userspace（废弃，k8s1.2版本的时候还在用，调度节点网络和pod网络，集群网络的时候，大量的内核态和用户态的转换，需要消耗巨大资源）
iptables(快废弃，9成都在用，如果一个主机有很多pod，那就是一个主机有一大堆iptables，iptables用的内核的net-filter模块，效率不是很高）
ipvs（推荐，lvs章文嵩博士开源，写到linux内核，走的是ipvs模块）ipvs调度流量，其实就是k8s内嵌了lvs，很清晰看到是哪边调度到哪个pod。
负责建立和删除包括更新调度规则、通知apiserver自己的更新，或者从apiserver哪里获取其他kube-proxy的调度规则变化来更新自己

k8s的三条网络：
1.节点网络就是宿主机网络
2.pod网络在上面都是宿主机上nat出来的
3.kube-proxy就是链接了pod网络和service网络，service网络是一层虚拟网络

现在分配的ip是service 192.1680.0.0/16 ,pod网络172.7.0.0/16（分配地址172.7.21.0/24,172.7.22.0/24），节点网络10.4.7.0/24。
node1 是10.4.7.21 node2 10.4.7.22。
现在就设置了三种私有地址

生产中也可以pod网络走172，节点网络走10，集群网络是虚的，192.168。
一看pod地址是172.7.21.0就知道在哪台宿主机上，10.4.7.21

10端一般表示idc的地址，一般4代表机房，7代表运行的项目和不同的环境，这样pod出问题挂了，就知道在哪个机房上

2.10 课程实验架构详解

这是一个逻辑上的架构图，
master主控节点：apiserver是组件，kubectl是cli工具，etcd是数据库，scheduler是调度器，controller-manager是控制器的的控制器

运算节点上有，kubelet，kube-proxy，里面有pod，pod下有container，pod是k8s的原子单元，pod里有若干container

生产上，主控节点2个3个。主控节点和运算节点只是逻辑上的概念，物理上完全可以部署在一台服务器上

部署架构。
规划5台主机，10.4.7.11, 10.4.7.12, 10.4.7.21, 10.4.7.22, 10.4.7.200

规划5台主机，10.4.7.11, 10.4.7.12, 10.4.7.21, 10.4.7.22, 10.4.7.200
运维主机10.4.7.200有很多作用，
docker的私有仓库
配置k8s资源清单的仓库
提供共享存储nfs
证书签发

先要部署etcd，要奇数个，1,3,5，7，因为是投票机制，在10。4.7.12上，10.4.7.21,10。4.7.22上都不是etcd。
主控节点和被控节点不加区分的部署在，10.4.7.21,10。4.7.22上，既当主控节点，也当被控节点

条件允许，可以把这部分主控节点单独分开出来。在k8s里有kubeadm，建议你把主控节点的服务加上污点，只跑主控的容器，kubeadm做到了可以把k8s的核心的组件，分成容器，托管给k8s自己。k8s可以跑自己的组件

上边两个代理承载了7层和4层的反向代理，7层是Ingress要用的，ingress有controller，4层其实反代的是apiserver，所以高可用很好做

这两个代理跑10.4.7.10的vip

2.11 K8S安装部署方式详解

常见的k8s安装部署方式三种：
1.Minikube 单节点微型K8S（实验使用）
2.二进制安装部署（生产首选）
3.使用酷本admin部署，K8S的部署工具，跑在K8S里

最简单获取MInikube是去官方网站



这是把minikube做了镜像拉下来，给了2个cpu，内存2.5G，磁盘50G

要是用k8s来学习，minikube足够，能把所有kube-system资源都列出来，相当于把k8s的关键组件都起来了

二进制部署一套k8s，对于熟练的工程师，需要一整天，非常复杂，etcd，apiserver，kubelet完全需要ssl证书通信，早期的版本可能用http通信，后面都不行了

2.12 K8S前置准备工作–准备虚拟机

虚拟出5台出来，这里配置下vwmare nat网络

确保windows主机也在一起

自动跃点设置10，因为有dns服务

这里都创建链接克隆

这里对虚拟机性能也是有所要求

第一步登录进去设置主机名

修改网络地址配置

地址配置

其他的主机也一样，10.4.7.12

修改网络地址

配置10.4.7.21

配置10.4.7.22

配置10.4.7.200



现在就可以用xshell连接了

2.13 K8S前置准备工作–bind9安装部署

虚拟机准备工作算是结束了，需要保证selinux都是关闭的

内核版本，要求是在3.8以上

防火墙服务都要关闭


epel源如果出错，所有的机器就都这样安装

base源也弄下

还需要安装一些必要工具


每台机器上都安装

为什么要用bind，是因为在k8s用ingress的时候，要做7层调度，会有域名，让容器都服从这个DNS解析

比如nslookup qq.com就回看到ip地址，dns就是把ip地址和域名做绑定

bind9是一个linux上开源的dns软件

只要hdss7-11这台主机上安装bind9

首先配置主配置文件

dns服务默认监听tcp53端口，不用ipv6地址

bind语法很严格，该空格空格，该分号分号，错一点都起不来服务

allow-query是允许哪些主机可以查dns解析，把localhost改成any

加一个配置forwarders，forwarders就是上一级dns是什么，如果本机查不到百度，就往上一级查，这里就是改成你的网关dns


recursion yes 就是dns采用递归算法（dns默认有2种来查询ip，递归，和迭代

dnssec关掉，节省资源


named-checkconf，没有报错就是最好的情况

自己的自建dns要管理起哪些域，主机域（10.4.7.11）和业务域

习惯的主机名可以就是地域+ip的后两位。比如10.4.7.21，4就是机房，一种数据互联，YZSJHK7-21.OPI.COM,.
opi.com是假的域，只有在主机的局域网内才生效

这里配置的主机域是host.com，只在自己局域网生效

做主机名的时候，一定要让你的主机上和主机名，看似跑的业务不关联（可能主机迁移了，从mysql业务做其他事情了，今天跑这个服务，明天可能跑别的服务了）

区域配置文件



加到最后

配置区域数据文件

TTL过期事件 10分钟600S，分号；代表注释
SOA第一条记录。
下面就是NS ,对应一条A记录，注意日期，serial

2019111001就是19年11月10号第一次修改

也是一样有，soa记录，ns记录，a记录

再检查是否有问题

现在dns服务就起来了

先dig下主机域

现在要让windows和linux客户端都能使用这个dns服务

把dns1改成11主机

能ping百度说明自建的dns，解析外面的不成问题

ping自己域里也没问题



这样短域名也ping通

主机域可以用短域名可以解析到，业务域太多了，不建议用短域名，统统FQDN

其他主机dns也改成11

最后都要重启下网络

把主机域加上域的短域名


每台主机都机加一下

windows也要用到这个域

如果不行，可以先打开telnet

现在和53端口可以通信的

把本地连接的自动跃点改成20

还是不行

本地连接的dns改一下

现在就可以了

ping 业务域也ping到了

2.14 K8S前置准备工作–准备签发证书环境

主机域和业务域要分开用。比如公司的业务是baidu.com,主机域就不要用hdss7-11.baidu.com，baidu.com是业务域，主机域是假的域，怎么好记怎么来

准备证书签发环境，k8s所有组件通信都是要依赖ssl，一般两种方式签发证书，opensssl，cfssl

要三个软件，下载到usr/bin下，给一个执行权限

wget cfssl
wget cfssl-json

wget cfssl-certinfo



现在就要开始签发证书了，自签证书首先需要跟证书，CA证书，Certification Authority 权威证书即跟证书，等于一个权威机构，

创建CA证书，先要创建ca证书的请求文件。ca-csr.json

**CN就是名字，这个机构叫oldboyEDU。签证书的时候就会有hotss字段。
algo ：rsa用rsa加密算法。
size：2048 长度2048
**

这个过期时间很重要，默认是一年，175200H是20年

签发证书的命令是cfssl gencert 生成证书

这样就生成了，把证书和私钥整在一起了

但是这个证书不是承载在文件里的，所以还需要加管道，承载式证书-bare
生成了ca-key.pem ca.pem，这两个是根证书和根证书的私钥

ca-csr走的是相对目录，所以要在certs目录下

这样就完成了CA证书的环境，以后就要给k8s组件签发证书了

2.15 K8S前置准备工作–docker环境安装

需要在这三台主机上部署docker环境

这次我们用简单命令，调用脚本

这三台需要装，21，22，200

如果出现问题，可以把原来yum源配置删除

配置一下docker，注意网络

创建docker目录

测试是否成功

在22的机器上

bip需要改一下


到200机器上执行



成功刚启动docker没有问题

2.16 K8S前置准备工作–私有仓库harbor搭建

docker部署好了就要部署docker的私有镜像仓库，现在比较流行harbor

建议选择1.7.5以上版本，之前的版本有很大的漏洞，选择1.7.6及其以上版本

建议offline，因为安装较快

在200主机上，创建一个src目录

把harbor软件包下载

-C指定解压到opt的目录里

做一个版本号的标记，然后做一个软连接

修改harbor配置文件

第一个要修改的是hostname 业务域是od.com

因为要装nginx，所以要把80端口错开，让harbor的服务监听180

默认的管理员密码，生产中需要改掉

调整log地址，rotate_count是滚动的数量，rotate-size每满多少滚一下

日志地址修改一下

data_volume也修改一下

创建目录

harbor本身也是用docker容器跑起来的，单机编排的，所以要依赖docker-compose


把harbor.yml配置好后，就可以用install.sh

执行一下

现在是把harbor镜像层load到本地，已经很快了，online还需要从往上拖，更慢


这样就安装好了，harbor起了一堆容器

docker ps -a，这些都是单机编排的

用harbor的话，不能直接用180端口，还需要nginx去反代

’

转发到本机的180端口

harbor的每一层镜像大小不一样，不配置1个G就很容易报错

检查配置文件，启动nginx

没有域名解析


修改dns，serial前滚一个序号，并且加一个A记录

重启变更

dig测试一下域名解析

现在就可以访问了

注意修改dns配置文件，serial要前滚一个序号

登录进去

新建项目

public应该是对应repository，不是用户名，dockerhub上你的名字就是仓库，私有仓库上其实并不是仓库

把harbor.od.com添加进来了，不安全的注册库，docker的仓库不论公有私有，默认都是走https协议

首先先去官网下载镜像

这个命令就等价于，docker pull nginx:v1.7.9–docker pull docker.io/library/nginx:v1.7.9

尝试给下载下来的打tagi

尝试推送到harbor仓库里

需要先登录


public里就有镜像了