目录
为什么叫K8S |
全称叫kubernetes,省略8个字母之后叫k8s,k8s的作用是自动部署,自动扩展和管理容器化部署的应用程序的一个开源系统,k8s是负责自动化运维管理多个容器化程序的集群,是一个功能强大的容器编排工具,以分布式和集群化的方式进行容器管理 |
K8S版本 | 1.15 1.18 1.20 最新的是1.28,市面上的主流是1.18和1.20 |
源码包地址 | k8s是google的borg系统作为原型,后期经由go语言编写的开源软件 |
Docker微服务,可以满足微服务使用,那么为什么还要使用k8s | |
1 | 传统的部署方式:一般意义上的二进制部署,安装到运行到运行维护,需要专业的人员,如果出了故障还需要人工重新部署拉起,而且如果业务量增大,只能水平的拓展,再部署一个 |
2 | 容器化部署,我可以用dockerfile编写好自定义的容器,随时基于镜像都可以运行,数量少还能管得过来,数量一旦太多,管理起来太复杂,而且docker一般是单机运行,没有容灾和高可用 |
K8S的作用
简单,而且是高效的部署容器化的应用 | |
1 | 解决了docker的单机部署和无法集群化的特点 |
2 | 解决了随着容器数量的增加,对应增加的管理成本 |
3 | 容器的高可用,提供了一种容器的自预计值 |
4 | 解决了容器没有预设模版,以及无法快速,大规模部署,以及大规模的容器调度 |
5 | K8S提供了集中化配置管理的中心 |
6 | 解决了容器的生命周期的管理工具 |
7 | 提供了图形化的工具,可以用图形化工具对容器进行管理 |
k8s是基于开源的容器集群管理系统,在docker容器技术的基础之上,为容器化的集群提供部署,运行,资源调度,服务发现,动态伸缩等一系列完整的功能 |
大规模容器管理
1 | 对docker等容器技术应用的包 到部署,运行,停止,销毁,全生命周期管理 |
2 | 集群方式运行,跨机器的容器管理 |
3 | 解决docker的跨机器运行的网络问题 |
4 | K8S可以自动修复,使得整个容器集群可以在用户期待的状态下运行 |
K8S的特性
弹性伸缩 | 可以基于命令,或者图形化界面以及cpu的使用情况,自动的对不熟的程序进行扩容和缩容,可以以最小化成本运行 |
自我修复 | 如果出现节点故障,它可以自动重新启动失败的容器,替换和重新部署 |
自带服务发现与负载均衡 | k8s为多个容器提供一个统一的访问入口(内部地址和内部的DNS名称),自动负载均衡关联的所有容器 |
自动发布和回滚 | K8S采用滚动(一个一个更新,跟测试服一样)的策略更新应用,如果更新过程中出现问题,可以根据回滚点来进行回滚 |
集中化的配置管理与秘钥管理 | k8s集群内的各个组件都是要进行密钥对验证的,但是k8s的安全性不够,核心的组件还是不建议部署,部署一些自定义应用 |
存储编排 | 1.可以自动化的吧容器部署在节点上 2.也可以通过命令行或者yml文件(自定义pod)实现指定节点部署 3.也可以通过网络存储,如:NFS,GFS分布式 |
对任务批次处理 | 提供一次性的任务,定时任务,满足需要批量出和分析的场景 |
K8S的核心组件与架构
1.kube-apiserver
k8s集群之中每个组件都是要靠密钥队来进行验证,组件之间的通信由apiserver来解决,API是应用接口服务,k8s的所有资源请求和调用操作都是kube-apiserver来完成,所有对象资源的增删改查和监听的操作都是kube-apiserver处理完之后交给etcd来进行,api-server是k8s所有请求的入口服务,api-server接收k8s的所有请求(包括命令行和图形化界面),然后根据用户的具体请求,通知对应的组件展示或者运行命令,API-server相当于整个集群的大脑 |
作用:所有服务请求的统一访问入口
1.提供认证,授权,访问控制,API注册发和发现等机制,其中封装了核心对象的增删改查操作
2.外部的客户端和内部的组件可以通过调用REST API接口的方式获取数据信息,这些数据信息都存储到了Etcd中
2. Kube-controller-manager
运行管理控制器,是k8s集群中处理常规任务的后台线程,是集群中所有资源对象的自动化控制中心,一个资源对应一个控制器,controller-manager负责管理这些控制器 |
作用:负责执行各种控制器
1.作为控制管理器,负责管理k8s各种资源对象的控制器
2.通过apiserver监控整个k8s集群资源的状态,并确保集群始终处于预期的工作状态
控制器 | 名称 | 作用 | 补充说明 |
Node Controller | 节点控制器 | 负责节点的发现以及节点故障时的发现和响应 | 定期检查node的健康状态,标识出失效的node |
Replication Controller | 副本控制器 | 保证replication controller定义的副本数量与实际运行pod的数量一致 | 可以理解成确保集群中有且仅有N个pod实例,N是RC中定义的pod副本数量 |
Endpoints Controller | 端点控制器 | 监听service和对应pod的副本变化,端点就是服务暴露出的访问点,要访问这个服务,必须知道它的Endpoints,就是内部每个服务的IP地址+端口 | 端点是一个服务暴露出来的访问点,如果需要访问一个服务,则必须知道它的endpoint |
Service Account&Token Controllers | 服务账户和令牌控制器 | 为命名空间创建默认账户和API访问令牌,namespace,访问不同的命名空间 | |
ResourceQuota Controller | 资源配额控制器 | 可以对命名空间的资源使用进行控制月可以对pod的资源进行控制 | |
Namespace Controller | 命名空间控制器 | 管理namespace的声明周期 | 定期清理无效的namespace,以及namespace下的API对象,比如:pod,service,secrte等 |
Service Controller | 服务控制器 | 属于K8S集群与外部的云平台之间的一个接口控制器 |
3.kube-scheduler
资源调度组件,根据调度算法(预先策略和有限策略)为新创建的pod选择一个合适的node节点,可以理解为k8s的所有node节点的调度器,用来部署和调度node 预先策略:人工定制,指定的node节点上部署 优先策略:限制条件,根据调度算法选择一个合适的node,node的节点的资源情况,node的资源控制情况等等,选一个资源最富裕,负载最小的node来部署 |
作用:可以视为资源调度器,负责集群中的pod资源调度,通过调度算法(预选策略和优选策略)为部署的pod选择最适合的node节点
预先策略和优选策略:首先过滤掉不满足条件的节点,这个过程称为预选,然后对通过的节点按照优先级排序,这个是优选,最后从中选择优先级最高的节点,如果中间任何一个步骤有错误,则直接返回错误
4. ETCD
k8s的存储服务,etcd分布式键值存储系统(key:value),k8s的关键配置和用户配置,先通过APIserver调用etcd当中的存储信息,然后再实施(这个集群当中,能对etcd存储进行读写权限,只有API-server) |
作用:可以看做k8s集群的数据库,是一种键值对存储结构的分布式数据库,负责存储k8s集群的所有重要信息,只有API-server有读写权限
ETCD是高可用的键值存储系统,通过raft已执行算法处理日志复制来保证强一致性
kubenetes中的重要数据都持久化到Etcd中,所有架构中的各个组件都是无状态
node组件
kubelet | node节点的监控器,以及预master节点的通讯器,也可以理解为master在node节点上的眼线,kubelet会定时向API-server汇报自己监控的node节点上的运行服务的状态,API-server会把节点状态保存ETCD存储当中,接受来自matser节点的调度命令,如果发现自己的状态和master节点的状态不一致,就会调用docker的接口,同步数据。 对接点上容器的生命周期进行管理,保证节点上的镜像不会占满磁盘空间,退出的容器的资源,进行回收 |
kube-proxy | 实现每个node节点上的pod网络代理 作用:负责节点上的网络规划和四层负载均衡工作,负责写入iptables(快淘汰了),现在六项的是ipvs实现服务映射 pod不是容器,pod是基于容器创建 kube-proxy:本身不直接给pod提供网络代理,proxy是sevice资源的载体 kube-proyx:实际上代理的是pod的集群网络(虚拟网络) K8S的每个node节点上都有一个kube-proxy组件 |
docker容器引擎 | 运行容器,负责本机的容器创建和管理 K8S要创建pod时,kube-scheduler调度到节点上(node节点),节点上的监督器kubelet指示docker启动特定的容器,kubelet把容器的信息收集,发送给主节点,只需要在主节点发布指令,节点上的kubelet就会指示docker拉取镜像,启动或者停止容器 |
推荐的插件(补充知识)
|
Kubernetes核心概念之资源对象
pod | pod是运行在节点上的,是k8s当中创建或者部署的最小/最简单的基本单位,一个pod只代表集群上正在运行的一个进程 同一个pod内的每个容器就是一个豌豆 pod是由一个或者多个容器组成,pod的容器共享网络,存储和计算资源,可以部署在不同的docker主机上,一个pod里面可以允许多个容器,也可以是一个容器,在生产环境中,一般都是单个容器或者具有关联 |
deployment | 无状态应用部署,作用就是灌篮和控制pod,以及replicaset(运行几个容器)管控他的运行状态 |
replicaset | 保证pod的副本数量,受控与deployment,在k8s中,部署服务(实际上就是pod),deployment部署的服务就是pod,replicaset就是来定义pod的容器数量,可以保证pod的不可重复性,在当前命名空间不能重复,不同命名空间名称可以重复 官方建议使用deployment进行服务部署 |
daemonsrt | 确保所有节点运行同一类的pod |
statefulset | 有状态应用部署(用的比较少) |
job | 可以在pod中设置一次性任务,运行完即退出 |
cronjob | 一至在运行的周期性任务 |
service
service在k8s整个集群当中,每创建一个pod之后,都会为其中运行的容器分配一个集群内的IP地址,由于业务的变更,容器可能会发生变化,ip地址也会发生变化,service的作用就是提供整个pod对外统一的IP地址
service就是一个网关(路由器),通过访问service就可以访问pod内部的容器集群
service能实现负载均衡和代理--kube-proxy来实现负载均衡
service是k8s微服务的核心,屏蔽了服务的细节,统一的对外暴露的端口,真正实现了"微服务"
service的流量调度
userspace(用户空间,已废弃不用),iptables(即将废弃),ipvs(目前1.20都用ipvs)
Service 的四种类型及使用方式
- ClusterIP:是 Service 的默认类型,它会为 Service 创建一个 Cluster IP,这个 IP 只能在集群内部访问。 通过 ClusterIP,用户可以访问该 Service 关联的 Pod。
- NodePort:在每个节点上绑定一个端口,从而将 Service 暴露到集群外部。 用户可以通过任意一个节点的 IP 地址和该端口号来访问 Service。
- LoadBalancer:在云厂商提供的负载均衡器上创建一个 VIP,从而将 Service 暴露到集群外部。 用户可以通过该 VIP 地址来访问 Service。
- ExternalName:可以将 Service 映射到集群外部的一个 DNS 名称上,从而将 Service 暴露到集群外部。
label标签
k8s的特色管理方式,用于分类管理资源对象,可以给node,pod,service,namespace起标签,label标签可以自定义 label选择器:等于,不等于,使用定义的标签名 |
lngress
k8s集群对外暴露提供访问的方式接口,在第七层,属于应用层,转发的是http请求(http/https) service是四层转发,转发的是流量 流程:https://.... > ingress > service > pod > 容器 |
namespace
在k8s上可以通过namespace来实现资源隔离,项目隔离通过namespace可以把集群划分为多个资源不可共享的虚拟集群组,不同命名空间里面的资源名称可以重复 |
https密钥 配置
[root@k8s1 ~]# cd /opt
[root@k8s1 opt]# ls
containerd harbor-offline-installer-v2.8.1.tgz
docker-compose-linux-x86_64 rh
[root@k8s1 opt]# mv docker-compose-linux-x86_64 docker-compose
[root@k8s1 opt]# mv docker-compose /usr/local/bin/
[root@k8s1 opt]# chmod 777 /usr/local/bin/docker-compose
[root@k8s1 opt]# tar -xf harbor-offline-installer-v2.8.1.tgz
[root@k8s1 opt]# cd harbor/
[root@k8s1 harbor]# ls
common.sh harbor.v2.8.1.tar.gz harbor.yml.tmpl install.sh LICENSE prepare
[root@k8s1 harbor]# cp harbor.yml.tmpl harbor.yml
[root@k8s1 harbor]# vim harbor.yml
5 hostname: bub.test.com
17 certificate: /data/cert/server.crt
18 private_key: /data/cert/server.key
34 harbor_admin_password: 123456
[root@k8s1 cert]# openssl genrsa -des3 -out server.key 2048
#openssl genrsa:生成密钥RSA
#-des3:机密的算法,Triple DES加密的算法,生产的私钥进行加密
#-out server.key:生成私钥文件
#2048:密钥的位数是2048位
Generating RSA private key, 2048 bit long modulus
.................................+++
.................................+++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:
#密码输入两遍123456
[root@k8s1 cert]# openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CN
State or Province Name (full name) []:JS
Locality Name (eg, city) [Default City]:NJ
Organization Name (eg, company) [Default Company Ltd]:TEST
Organizational Unit Name (eg, section) []:TEST
Common Name (eg, your name or your server's hostname) []:hub.kgc.com
Email Address []:admin@test.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
#备份
[root@k8s1 cert]# cp server.key server.key.old
[root@k8s1 cert]# ls
server.csr server.key server.key.old
[root@k8s1 cert]# openssl rsa -in server.key.old -out server.key
Enter pass phrase for server.key.old:
writing RSA key
#清除密码
[root@k8s1 cert]# openssl x509 -req -days 1000 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=CN/ST=JS/L=NJ/O=TEST/OU=TEST/CN=hub.kgc.com/emailAddress=admin@test.com
Getting Private key
[root@k8s1 cert]# chmod 777 server.*
[root@k8s1 opt]# cd /opt/harbor/
[root@k8s1 harbor]# ./prepare
prepare base dir is set to /opt/harbor
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.
#守护进程掉了,重启docker就行
[root@k8s1 harbor]# systemctl restart docker
[root@k8s1 harbor]# ./prepare
[root@k8s1 harbor]# ./install.sh
#安装好后登录网页查看
[root@k8s1 harbor]# cd /
[root@k8s1 /]# scp -r data/ root@192.168.233.82:/
到docker2上操作
[root@k8s2 ~]# systemctl restart docker
[root@k8s2 ~]# mkdir -p /etc/docker/certs.d/hub.test.com
[root@k8s2 hub.test.com]# docker pull nginx
[root@k8s1 cert]# cp server.crt server.csr server.key /etc/docker/certs.d/hub.test.com/
[root@k8s2 cert]# cd /etc/docker/certs.d/hub.test.com/
[root@k8s2 hub.test.com]# ls
server.crt server.csr server.key
[root@k8s2 hub.test.com]# vim /lib/systemd/system/docker.service
13 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd. sock --insecure-registry=hub.test.com
[root@k8s2 hub.test.com]# systemctl daemon-reload
[root@k8s2 hub.test.com]# systemctl restart docker
[root@k8s2 hub.test.com]# vim /etc/hosts
192.168.233.81 hub.test.com
[root@k8s2 hub.test.com]# yum -y install tel
[root@k8s2 hub.test.com]# telnet hub.test.com 443
[root@k8s2 hub.test.com]# docker login -u chen -p Cwh123456 https://hub.test.com