2021/01/28 k8s核心组件及工作流程

最新推荐文章于 2024-06-28 17:09:52 发布

48N6E

最新推荐文章于 2024-06-28 17:09:52 发布

阅读量717

点赞数 1

分类专栏： K8S进阶

本文链接：https://blog.csdn.net/qq_42227818/article/details/113358341

版权

K8S进阶专栏收录该内容

32 篇文章 20 订阅

订阅专栏

在这里插入图片描述

K8S用etcd（CP）存储数据，比如pod在哪个节点上
APIserver接收请求，整个集群的访问入口，还有安全访问控制authentication authorization，etcd的数据只能api去写入。
所有的数据想要同步只能通过apiserver来做。
scheduler把业务容器调度到最合适的节点上去

在这里插入图片描述
加入告诉K8S集群要启动两个副本，谁去保证有2个副本在启动，这是controller manager管理的，假如有一个挂了，它会再次启动。不管怎么样，它去保证副本数是2，副本控制器replication controller。
controller manager其实是一类控制器的总称，总合起来就可以让集群按照我们期望的方式去执行

在这里插入图片描述

工作节点上的各种状态，管理节点需要知道（比如跑了什么服务，状态是什么）kubelet类似master插在node地方上的大使，汇报想要的数据源。
kubelet功能分三个：启动pod，node节点状态（会监控一些数据源调用apiserver，传到etcd数据库里），健康检查。
proxy是去维护iptables规则。有一些负载均衡的任务
在这里插入图片描述

**所有命令都是通过apiserver，去做一些鉴权，写入etcd，之后，scheduler调度器监听apiserver是否有没有调度的pod，找遍所有节点，哪个节点打分最高就调度到哪个节点。调度好了通过apiserver写到etcd里。
kubelet也是通过监听apiserver bound pod，假如容器调度到自身了，就调用docker运行起来。docker跑起来后也是通过apiserver写入到etcd里
**

在这里插入图片描述

apiserver是所有的请求入口，control manage控制中枢，存储，scheduler主管调度，kubelet负责运行。
除了etcd，其他都是无数据无状态的，更好做高可用

其他组件需要监听

在这里插入图片描述

第2章集群安装

2.1 集群安装详解

在这里插入图片描述
是集成在一个节点的简易K8S，是去测试的一个

在这里插入图片描述
现在两个是比较建议的

在这里插入图片描述

创建三台机器

在这里插入图片描述

一般都是间隔一个版本去用，比如现在1.17那就使用1.15

三台主机进行修改hosts

在这里插入图片描述
修改/etc/hosts

在这里插入图片描述

开启forward转发

关闭swap，否则kubelet启动不起来

在这里插入图片描述

加载br_netfilter，是内核层面的包

有一个K8S的源

在这里插入图片描述

在这里插入图片描述

这一个镜像加速

在这里插入图片描述

指定的版本是1.16.2

三台节点都去执行一下

在这里插入图片描述
只在master节点操作

这里如果是多台，就需要改成lb的地址

在这里插入图片描述

让kubeadmin打印初始化的配置
在这里插入图片描述
这里的源改成阿里云的源

在这里插入图片描述
pod网段，默认是没有的，需要加一下，pod网段是跟宿主机无关的，虚拟网络，不管本地虚拟机是192.168的网段还是别的，都是可以用这个地址，只要这个段和物理机不要重复就行

在这里插入图片描述
这是kubeadm安装需要的初始化文件

在这里插入图片描述

需要使用的镜像列表

在这里插入图片描述
拉取镜像

在这里插入图片描述
三个核心的组件

在这里插入图片描述
coredns是做内部dns解析的

在这里插入图片描述
阿里云的源不能用就用下面的方式

在这里插入图片描述
下面是dockerhub上，别人推的google镜像mirror

在这里插入图片描述

初始化master节点

手动如果去安装的话，controller-manager。scheduler，proxy都需要去配置，怎么和apiserver去调用通信，kubeadm的工具都帮你完成了、
master节点已经完成初始化了

在这里插入图片描述

现在看到有一个节点，状态是notready，因为网络插件还没有安装

先把s’lave节点添加进去

在这里插入图片描述
输出什么就在slave节点上添加

在这里插入图片描述
因为每个K8S集群都需要一个CNI的一个网络插件

在这里插入图片描述
常用的插件有flannel，calico

在这里插入图片描述
多尝试几次，这个网站比较慢

在这里插入图片描述

在这里插入图片描述
需要修改一些配置

在这里插入图片描述

以防下载flannel镜像下载错误，可以换成私有的的地址

在这里插入图片描述

flannel是在每个节点都需要执行的

在这里插入图片描述

这里已经是ready状态了

在这里插入图片描述

看一下日志

在这里插入图片描述

150行，改一下地址

在这里插入图片描述

default正在创建中

可以直接去访问这个ip的

修改service为nodeport类型

在这里插入图片描述

新加了一个dashboard

在这里插入图片描述

仪表盘的认证

在这里插入图片描述

在这里插入图片描述

拿到token

在这里插入图片描述

2.2 理解k8s的组件和资源

master上有三个核心组件，apiserver，controler manager,schedule，etcd
在这里插入图片描述
都是在master节点上

在这里插入图片描述
kubelet是一个systemd的管理服务

在这里插入图片描述

node和pod都是K8S的资源类型

在这里插入图片描述

kubectl api-resources可以查看所有的资源

在这里插入图片描述

pod和node

在这里插入图片描述
namespace，默认default

在这里插入图片描述
名称空间是K8S集群虚拟的概念。
整个K8S可以看作一个资源池，每个namespace就是对资源池的划分，也就是一个小池，里面有各种资源，pod，service

在这里插入图片描述

这里有true和false，是否是必须在一个名称空间里
在这里插入图片描述
node不是必须在一个名称空间里的，它是可以跨namespace的

在这里插入图片描述
这里其实是简写

在这里插入图片描述

同一个namespace有不同的资源

在这里插入图片描述

想要知道get方法如何使用

在这里插入图片描述

CKA考试的时候会用kubectl很多命令

创建名称空间，不知道如何使用可以加-h

在这里插入图片描述

第3章使用k8s管理业务应用实践

3.1 使用Pod管理业务应用入门

K8S调度最小单元是pod，（豆荚），pod里裹着容器
在这里插入图片描述
docker并不是唯一的容器引擎，还有RKT，也可以作为容器引擎。K8S作为一个管理平台，去管理容器，都要去兼容。就设计了pod，在pod这一层和容器进行了一个解耦。
容器网络，container网络模式可以去建立容器，管理网络加入到已经存在的容器里，也就是多个容器去共享一个网络空间。pod里的多容器支持的场景更加灵活。

在这里插入图片描述
使用yaml格式定义pod资源

在这里插入图片描述

在这里插入图片描述
如果改成JSON格式要表示这个yaml，也就是kv对

这个-杠对应的是一个数组

其实yaml比json省空间

在这里插入图片描述
env，这是几个环境变量

在这里插入图片描述
kind是定义K8S哪种类型

apiversion通常表示这个功能的成熟程度，成熟之后就用v1

资源类型和apiversion对照表

在这里插入图片描述

explain可以看这个pod的解释，把pod支持的每个属性都打印出来了

在这里插入图片描述
metadata是固定的，pod对象名字name是myblog，名称空间namespace是luffy，label标签，component:myblog

在这里插入图片描述
spec特定的一些属性，containers 容器是可以多个的，需要一个myblog镜像，一个mysql数据库，这里的name是容器的名字，可以跟pod的name属性无关

docker是用-e 传变量的

同一个pod容器是可以通过localhost通信的

在这里插入图片描述
mysql运行的时候，初始化一个数据库

克隆一下项目地址
在这里插入图片描述

在这里插入图片描述

去创建一个镜像仓库

启动

在这里插入图片描述
本地仓库起来了

在这里插入图片描述
把yaml文件拷贝到机器上

在这里插入图片描述
制作一个mysql-utf8的镜像

在这里插入图片描述

在这里插入图片描述

制作dockerfile

在这里插入图片描述

python项目镜像构建打tag并且推送到自建仓库上

在这里插入图片描述
现在yaml里的镜像都有了

拷贝yaml

在这里插入图片描述
创建pod

在这里插入图片描述
创建一个luffy的namespace

正在创建中

在这里插入图片描述

去slaveka

describe里有事件

在这里插入图片描述
两个容器

在这里插入图片描述

访问podip端口

在这里插入图片描述
mysql需要做一下初始化

如果是用docker就只能到K8S-slave1节点上进入容器
在这里插入图片描述
默认进入的是myblog容器

在这里插入图片描述
想进入mysql容器可以-c

正常访问里面的数据库

在这里插入图片描述
再次进入myblog容器对mysql执行初始化，使用django的migrate

这里的mysql就是localhost

现在就可以访问了

在这里插入图片描述

现在有三个容器，mysql，myblog，pause容器。
每个K8S创建pod的时候，都会去创建pause容器，基础设施的这样一个容器，它的作用就是创建网络名称空间，以后新加入pod里的容器都会用这个pause的网络名称空间。同一个pod内部容器都共享网络名称空间
在这里插入图片描述
pod容器里会去共享网络名称空间

mysql和myblog的ip地址都是一样的

在这里插入图片描述

容器名，pod名，名称空间，随机字符串

在这里插入图片描述

这个事件默认是一个小时，一个小时再看就没有数据了

也可以查看yaml

进入到一个pod里查看哪个容器的一些信息

logs查看容器日志

显示最新的10行

在这里插入图片描述

3.2 使用Pod管理业务应用进阶

在这里插入图片描述
镜像如何更新到K8S里去

修改成v2版本

没有这个镜像，拉取镜像失败了

在这里插入图片描述

改回v1

通过文件删除，delete -f

也可以直接删除pod
在这里插入图片描述
mysql数据需要持久化

在这里插入图片描述
在K8S里需要一个volumeMounts。这个关键字是和container一个级别的

这个volume定义的是每个container都可以使用的，是定义一个全局的，具体容器想用哪个都可以去挂载。

在这里插入图片描述
hostpath是主机上的目录，定义了一个volume叫mysql-data，类型是hostpath，挂载的宿主机就是path:/opt/mysql/data

这里是把上面定义的volume挂载上，

这两个名字应该是一致的。mountpath就是代表挂载到容器内的，也就是把宿主机的/opt/mysql/data挂载到/var/lib/mysql

在这里插入图片描述
但是现在只是针对slave1节点，pod飘到slave2节点就没有数据了

在这里插入图片描述
避免这个情况，就需要nodeselector做定义

nodeselector作用域也是整个pod，固定飘在mysql标签的节点上

在这里插入图片描述
把原来的删掉

在这里插入图片描述

在这里插入图片描述

describe命令去查看为什么pending

查看node的标签

slave1的标签就多了一个

现在已经running了

node打上标签后，就检测到了合适的节点，就调度成功了

mysql的数据就可以在slave上的目录看到

在这里插入图片描述
这只是其中一种方式

在这里插入图片描述

这种方式需要定点，把pod和某一个node绑定死，想要实现pod来回调度，通过pv+pvc连接分布式存储的方案。现在ceph用的比较多，但是运维起来比较麻烦
在这里插入图片描述
K8S提供了健康检查的方式去判断服务是否运行正常。
livenessprobe，存活性探针

在这里插入图片描述
访问myblog的8002端口,路由是/blog/index

在这里插入图片描述
两次探针检测间隔时间，默认10秒

在这里插入图片描述
超时时间

httpget只是其中一种检测方式，这个url只要超过2秒未返回，或者状态码不是200-300之间，就认为是错误的

在这里插入图片描述
livenessprobe主要是去判断容器是否存活，如果不健康，则kublet会把容器杀掉，并根据容器重启策略重启。
如果没有livenessprobe探针，就默认永远成功

在这里插入图片描述

如果探测失败，去把pod杀掉，去做restartpod

在这里插入图片描述

可用性探针就是判断容器是否能提供正常服务。ready是否为true

加入pod执行失败了

在这里插入图片描述
如果容器ready为false，endpoint controller控制器将此pod的endpoint从对于的service 的endpoint、列表删除。这个失败了，kubelet不会把pod删除掉，只是把流量断了

在这里插入图片描述
除了httpget方式，其他还有exec和tcpsocket，exec可以定义一个脚本，判断脚本返回值来决定true和flase。如果是0，容器就是健康的。
tcpsocket，就是pod建立tcp链接，建立成功，就代表容器健康

在这里插入图片描述

给myblog应用加上livenessprobe和readinessprobe

!在这里插入图片描述
再去生成

这里是1，mysql容器没有加健康检查，所以认为是1

在这里插入图片描述

这里现在都是500，没有做数据库migrate，也就是path访问不了

在这里插入图片描述

执行migrate

容器的异常退出或健康检查失败后，根据写的重启策略做重启

args可以理解为docker时候的CMD，这里的1号进程退出码是0，因为正常退出

在这里插入图片描述

在这里插入图片描述

10秒钟就会退出，completed就是完成sleep了

在这里插入图片描述
crashloopbackoff，就是被杀掉了

always就是不管什么原因，容器进程退出后，就会帮你去重启

onfailure只有当容器异常退出，才会去重启

在这里插入图片描述

这个状态保持不动了，onfailure只针对非正常退出的场景

让脚本返回1，认为非正常退出

在这里插入图片描述
不重启就认为是ok的

exit 1就是非正常，变成error了

在这里插入图片描述

ifnotpresent 这里是给容器设置一个镜像的拉取策略

在这里插入图片描述
always。不管有没有都去拉
ifnotpresent，本地没有就去拉取

对于pod 可以做一些资源限制

request是请求的，是资源调度阶段，容器的最小分配，limit是上限

、只是做一个调度的时候的判断依据

在这里插入图片描述

这个cpu只能写一个时间比，相对的值

在这里插入图片描述

docker-run的时候相关的限制

在这里插入图片描述

3.3 使用Pod管理业务应用优化篇

这个是完善以后的yaml
在这里插入图片描述

优化的地方，账号密码现在是明文

在这里插入图片描述
这个容器更新频率是很低的，只是一个数据库，不应该和业务容器在一起

中间件不适合频繁更新，是为多个资源提供服务的。yaml不应该存在敏感信息

以host网络模式启动容器

在这里插入图片描述
node选择器

在这里插入图片描述

删除目前的pod

在这里插入图片描述

在这里插入图片描述
创建一个mysql pod

在这里插入图片描述

apply可以把镜像替换掉

在这里插入图片描述

在这里插入图片描述

现在就都跑起来了

在这里插入图片描述
现在就可以访问到页面了

在这里插入图片描述

现在是两个pod

在这里插入图片描述

在这里插入图片描述
configmap和secret可以实现让配置文件和yaml文件分离，yaml文件不变，configmap和secret术语进行改变

在这里插入图片描述

namespace一定要和pod是一个

在这里插入图片描述、

2个术语

虽然K8S的所有资源都可以通过yaml创建，但是也可以通过kubectl这个命令创建configmap资源

可以基于文件，目录创建configmap
![在这里插入图片描述](https://img-blog.csdnimg.cn/20210208220000676.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMjI3ODE4,si
从文件里创建，key1类似mysql_host

在这里插入图片描述
也可以从环境变量里创建

也可以从环境变量里窗口
在这里插入图片描述
不知道怎么用还可以到官网查

在这里插入图片描述
secret和configmap的区别，secret管理敏感类信息，默认会base64编码存储

在这里插入图片描述
注意echo -n做一下base64加密

两次不一样

做一下解码。多一个换行

在这里插入图片描述

制作secret.yaml文件

这样就拿到数据

在这里插入图片描述
还可以通过文件创建

内容跟第一种方式一致，这是自动的去做的base64

原来的env是key和value都能看，现在把配置写在了configmap，secret里

在这里插入图片描述
name是以前env里的key，value是从name叫myblog的configmap去引用源mysql_host的key

mysqluser就有点不一样了，就是从secret里引用

在这里插入图片描述

现在这个模板就可以不管什么环境都可以去部署了

在这里插入图片描述

在这里插入图片描述

把旧的删除

创建新的

输入env查看变量

configmap和secret不能跨namespace使用，且更新后，pod内的env不会去更新

在这里插入图片描述
通过configmap和secret解决了变量的敏感信息带来的安全隐患

在这里插入图片描述

K8S默认就建立了很多namespace

可以直接拿它的来进行参考

在这里插入图片描述
这里更新了，kubelet会自动更新

在这里插入图片描述

3.4 pod状态与生命周期

在这里插入图片描述
kubectl创建的时候，apiserver接收请求，至少一个容器启动，running，如果一个容器以非正常状态退出，进入failed，策略如果是onfailure，kubelet再杀掉，重新启动
一般是网络问题

main是pod里主容器，一般是业务容器，infa是基础设施容器pause，init是pod的初始化容器
在这里插入图片描述
初始化容器的作用，验证业务依赖的组件是否正常启动。修改目录的权限（要求在容器内部有一定目录权限）

是和container一个级别的，可以定义多个初始化容器

第一个容器
更新系统配置

在这里插入图片描述
安全上下文

在这里插入图片描述
还有一个容器是fix-permissions，因为是用1000这个用户启动进程，如果不给目录1000的权限，可能会失败

在这里插入图片描述
这个目录一般是通过宿主机去挂载的，如果外部用的是root，可能挂载失败，没有权限，就需要fix-permissions把权限给它

在这里插入图片描述
main这个容器在启动的时候，还有生命周期，post start 启动后，pre stop停止前。类似关卡，一般容器运行main后，lieness和readiness做检测。
先启动初始化容器init，然后再去启动main容器

在这里插入图片描述
从0开始先执行init container，poststart 和maincontainer几乎同一时间运行，进行健康检查，然后停止前做操作

在这里插入图片描述
定义一个初始化容器

这里定义了本地路径挂载，把宿主机的tmp目录挂载到了容器的loap目录

初始化容器往目录里写了数据

在这里插入图片描述
主容器

在这里插入图片描述
开始后，停止前是定义在lifecycle生命周期里的，和readinessprobe同级别

在这里插入图片描述

直接运行

在这里插入图片描述
在slave1上

在这里插入图片描述
end之后重启了。是因为默认是always

在这里插入图片描述
主动杀掉pod才会触发pre-stop

在这里插入图片描述

第4章 Pod控制器

4.1 使用Pod控制器管理Django应用

1.K8S为了与特定的容器进行解耦，引入了pod概念。
2.k8s使用yaml文件创建资源。
3.通过kubectl create|get|exec|logs|delete等操作K8S资源，必须指定namespce
4.每启动一个pod，为了实现网络空间共享，会先创建infra容器，并把其他容器网络加入该容器。
5.通过livenessprobe和readinessprobe去对容器的存活性和就绪性做健康检查，livenessprobe主要是为了解决pod是否会不断的重启。readinness是关乎pod是否是ready，不ready，上层的 ingress controller会把流量断开。
6.request和limit限制资源
7.pod通过initcontainer和lifecycle分别来执行初始化、pod启动，删除时候的操作，使得功能更加全面和灵活。
8.编写yaml讲究方法，学习K8S，养成从官方网站查询只是的习惯。

在这里插入图片描述
每个namespace都有一些资源，然后去定义pod，service，configmap

4.每启动一个pod，为了实现网络空间共享，会先创建infra容器，并把其他容器网络加入该容器。
他们两个加入infra容器，就可以通过127.0.0.1的来访问了
在这里插入图片描述

只用到pod吗，会面临一些问题：
1.业务应用启动多个副本，
2.pod重建后，ip变化，外部如何访问到pod服务
3.pod挂了，可以自动帮你把pod转移到集群中可用的节点启动起来
4.如果pod是收集节点的数据，需要运行在每个节点上
在这里插入图片描述

工作负载是管理pod的中间层，确保pod资源符合预期的状态，pod出现问题，会尝试重启，重启无效，会新建pod

**replicat是代替用户创建指定数量的pod。
deployment是在repicaset之上的，用于管理无状态的应用，比如nginx，跑到哪里都可以。
daemonset确保集群中的每一个节点只运行特定的pod副本，通常能够用于实现系统级后台的任务。比如EFK服务。
job只要完成就立即退出，不需要重启或重建。
cronjob 周期性任务控制，不需要持续后台运行。
statefulset 管理有状态的应用，集群服务，es集群，zk集群，这样的每个集群里的节点都需要通信，节点之间还需要hostname命名要求的。
**
在这里插入图片描述
deployment是目前使用最多的副本控制器

metadata一般定义名字，名称空间，label标签

在这里插入图片描述
replicas期望的副本数
selector选择器，选择匹配标签是app=mysql的pod

模板理由metadata，，这都是固定的格式
上面是给deployment打label，下面是给pod打label，

10行和14行，这两个标签不一样会匹配不到，应该是一样的
在这里插入图片描述
现在定义了一个deployment，里面去管理了一个pod，找matchlabels，app=mysql的一个pod，正好在template里定义了一个app=mysql的pod

在这里插入图片描述
下面都是pod的定义

在这里插入图片描述
在yaml文件格式上也可以看到，是管理pod上层的pod控制器

在这里插入图片描述

myblog的deployment

在这里插入图片描述

在这里插入图片描述
创建myblog

deployment下的两个pod

在这里插入图片描述
进入容器初始化数据库

在这里插入图片描述
链接不上数据库

要用host模式，先把原来的删除

在这里插入图片描述

现在已经ready了

在这里插入图片描述

**创建deployment的时候，会创建replicas，会保证一个副本的数量 **

前面是replicas，后面是deployment

在这里插入图片描述
查看一下api-resources

在这里插入图片描述

删掉一个pod，查看副本控制器会如何管理

在这里插入图片描述
pod会重建一个

scale是伸缩一个资源，这个资源是deployment，–replicas副本数

在这里插入图片描述

现在数量就是2个了

pod驱逐eviction，某些节点失联，会把pod驱逐到其他节点上

在这里插入图片描述
默认5分钟，kubecrotroller-manager会去检查节点是否ready，不ready会把pod调度到其他节点上

在这里插入图片描述

不想要默认5分钟，把这个参数定义到上面的yaml文件即可

节点如果内存不足也会驱逐其他pod

在这里插入图片描述
跟盘至少保持80%以上的容量

4.2 实现Django应用的滚动更新与服务回滚

deployment管理pod

在这里插入图片描述
现在只有一个版本叫v1

现在做一个v2版本

如果是给pod更新，那么直接更改镜像版本就行

这是第一种方式

在线编辑

现在用的是v1版本

在这里插入图片描述

这里改成v2版本

在这里插入图片描述
保存以后会自动更新

在这里插入图片描述
新启动一个，杀掉一个

在这里插入图片描述
也可以通过给deployment设置镜像

deployment后面的名字就是这里的name

在这里插入图片描述

在这里插入图片描述
如果不标注会有默认的策略

在这里插入图片描述
后面的这一串，其实就是hash整个deploy yaml文件得出来的

目标是从v1版本升级到v2版本，通过rs去逐步过度的过程

maxsurge最大激增数
maxunavailable最大可用数

在这里插入图片描述
maxsurge，在更新过程中，最多可以比预先设定值多出几个pod数量，向上取整，5个+5*0.25=6.3，=7个

在这里插入图片描述
K8S整个更新过程中，最大副本数不能超过2+2*0.25=3

第一步，类似这样的情况，之前2 个还在，新启动一个新版本的

不能少于两个pod，在更新的时候，旧的保持不动，等新的ready，再把旧的删除
在这里插入图片描述

新启动一个pod，把老的下掉

K8S提供了自己的一套revision回滚机制

现在有两个版本

在这里插入图片描述
删掉deploy

在这里插入图片描述

再去创建

第一次创建

在更新中

现在就是两个版本

现在是v2版本

在这里插入图片描述

也是异步更新

在这里插入图片描述

现在就回到了v1版本了

在这里插入图片描述

第5章负载均衡与服务发现

5.1 负载均衡与服务发现实现原理

在这里插入图片描述
不在K8S及群里，访问这个是不通的

这是一个service的yaml

上面service的80端口转发到下面pod的8002端口

跟deployment一样，service也是有选择器的，找所有app=myblog的pod

现在label是app=myblog，后面是对应的rs出来的哈希值
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
现在就有service了

查看这个ip地址反代了哪些pod

只要-l有数据，就会加到enpoint

可以加别名，避免一直敲

删掉的话会立即创建一个pod，ip地址就会改变

在这里插入图片描述
这里K8S强制删除，就不会等待docker指令，就直接操作etcd数据库把数据删除

在这里插入图片描述

K8S创建svc的时候，就会去创建同名的endpoints，也可以称为ep，endpoint-controller会控制流量的转发，如果pod健康就绪性检查没过，endpoint-controller会把pod删除

在这里插入图片描述
从上层的cluster ip反代到下面的pod ip

访问上层的cluster ip

给mysql也创建service

在这里插入图片描述

在这里插入图片描述
使用hostnetwork，有可能引发宿主机端口冲突

在这里插入图片描述

在这里插入图片描述
这样等于写死了ip，不是最终j解决方案

在这里插入图片描述
利用servicename来访问

在这里插入图片描述
这样是可以访问到的

在这里插入图片描述

这样就可以实现去ip化，方便迁移

原来这里的ip地址，换成mysql

在这里插入图片描述
删掉这一行

在这里插入图片描述
删掉重新创建

在这里插入图片描述
修改configmap

在这里插入图片描述
需要加双引号

在这里插入图片描述
mysql新启动了pod，但是myblogready是0了

现在就已经切换

重启了一次拿到最新的configmap数据

在这里插入图片描述

为什么可以通过servicename去访问，肯定有对应的dns服务器去做解析，coredns

系统相关的组件都在kube-system里

查看容器里的dns服务，这个ip从哪来

这里有一个kube-dns 的service，只要是kubeadm安装的，会固定10.96.0.10这ip，容器启动会把dns配置注入到容器里作为dns解析
在这里插入图片描述
还有一个搜索域

mysql因为匹配到了上面的搜索域才能被访问到，这也是为什么直接访问mysql短名也能被访问到的原因

在这里插入图片描述
这是namespace

这样可以完成一跨域的访问

在这里插入图片描述
default的namespace里有一个kuberbetes的一条服务，这个也是K8s初始化安装的时候的service

在这里插入图片描述
clusterip可以通过宿主机直接访问，-k不带证书访问，默认访问K8S服务组件是要带证书的

假如从luffy的名称空间里去访问default的，在这样实现了跨namespace访问

之前把mysql服务从host模式，改成了service，configmap把ip也去掉了，但是现在还不能通过浏览器去访问

service有一种类型是clusterip 还有一种是nodeport，端口是30000到32767
在这里插入图片描述

在这里插入图片描述

通过30294端口可以从外部访问

在这里插入图片描述

其他宿主机ip也可以

nodeport是集群里的每个节点都会监听

kube-proxy是agent运行在每个节点上，每个节点都会去部署应用

在这里插入图片描述
有三种模式

用户空间的，让kube-proxy在用户空间监听一个端口，所有的service转到这个端口，kube-proxy对其转发，所有报文都从一遍用户态，性能不高

在这里插入图片描述
不给kube-proxy指定，就会使用 iptables模式，用iptables来实现把流量转发到具体pod的规则

ipvs同样基于内核的netilter，但是采用哈希表，数量达到一定不过规模的时候，速度有优势，K8S1。18来引入，需要开启宿主机的ipvs模块
在这里插入图片描述

kube-proxy去针对一系列ptables规则去转发到pod，所以kube-proxy是daemonset服务，每个节点都需要

在这里插入图片描述

但是没看到具体往哪里pod转发的规则

在这里插入图片描述
random随机模式 0–probability可能性，有0.5的几率转发到KUBE-SVC-4RG7UZRJ，剩下的转发到另外一个

这个地址是clusterip，所有往这里去的流量转发到KUBE-SVC-4RG7UZRJ

在这里插入图片描述
dnat是目标地址转换

总结起来i就是访问clusterip的流量，有50%的纪律访问10.244.1.29，剩下的访问18上

也就是kube-proxy用iptables来实现流量转发，也就是通过 ipables的规则来实现一个lb，nodeport其实也跟clusterip一样
在这里插入图片描述
通过kubeproxy调用iptables规则，也就是内核的netfilter，来做一个lb
**加粗样式**
iptables加iptables规则，ipvs加ipvs规则

**加粗样式**
pod的ip需要前面的上层的lb自动更新，才有service概念

在这里插入图片描述
利用服务发现能力，通过组件之间的servicename来访问

pod启动的时候把dns注入到容器里

service没法通过集群外部访问，nodeport就可以实现让外部机器访问

为什么clusterip和nodeport可以转发到内部服务，就是因为kube-proxy

在这里插入图片描述

第6章 Ingerss实现七层原理

6.1 通过ingress实现业务应用7层代理

K8S的service，clusterip和nodePort都是4层负载。实现7层的负载就需要ingress。
ingress控制器，外部的流量通过7层转发到集群内部的组件，ingress是一个统称，实现有很多，nginx，countour，haproxy，trafik，istio。
现在用nginx，trafik，istio比较多
在这里插入图片描述

**这个控制组件是在K8S里用pod方式运行的，这个pod就会根据用户写的ingress规则，这个规则就对应ingress yaml文件。ingress是K8S里，新的resources，controller控制器去通过apiserver动态的查询ingress定义的文件，转换成nginx配置文件，通过reload方式让nginx生效 **
在这里插入图片描述
ingress对象，就是把nginx的配置抽象成了imgress资源

rules里是个数组，里面定义path，通过哪个域名去访问

可以直接配置servicename去访问

在这里插入图片描述
port是前面port

在这里插入图片描述
外部访问K8S集群服务，首先从ingress域名tea.foo.bar.com,下面的service知道访问哪些pod（通过abel selector）

在这里插入图片描述
实现逻辑
1.ingress controller去通过apiserver交互，动态感知ingress规则变化
2.读取ingress规则，按照规则，生成nginx配置
3.生成以后，写入到nginx-ingress-controller（等于一个nginx服务），nginx-ingress-controller写入到nginx.conf
4.最后reload

在这里插入图片描述
安装ingress-controler

在这里插入图片描述

修改部署节点

默认是这样一个label

在这里插入图片描述

改成ingress=true

加一个hostnetwork

在这里插入图片描述
创建了一系列资源

和ingress相关的资源都放在ingress-nginx这个名称空间里

在这里插入图片描述
controller也是用deployment，是workload使用范围最广的一个

在这里插入图片描述

如果现在要通过ingres访问到myblog应用的时候该如何去做

之前的ingress=true已经打在K8S-Master上了，所以之前的pod调度成功了，不然iu是pendding
只要执行这个命令，节点上就打上标记了

在这里插入图片描述

可以查看ingress

这是两个endpoint

ingress会去动态生成upstrem的配置，查看nginx的配置

生成的配置文件还是很多的

这里加上hostnetwork=true，宿主机的端口80就被监听了
在这里插入图片描述

ingess是运行在10节点上

生产环境一般用lb

修改本机hosts

在这里插入图片描述

如果要https的，可以先自己自签名

crt就是一个证书文件，key就是私钥

在这里插入图片描述
secret就是来存储一些敏感信息

在这里插入图片描述
指定一下secretname即可

这里就多监听了一个443

现在就可以了

在这里插入图片描述
多路径如何去实现

在这里插入图片描述

/跟一定要放在最后

在这里插入图片描述

这样就实现了多个转发

在这里插入图片描述
删除

在这里插入图片描述
nginx url 重写

直接访问是这样的，admin这个路径是原样转发到后面的路径

在这里插入图片描述
如果想要实现url这样重写

在这里插入图片描述

加了一个申明，rewrite-target重写的目标

name是rewrite-path

在这里插入图片描述

foo这个规则转发到admin，$1就是括号匹配到的

访问fooo转发到admin里

配置一下解析

在这里插入图片描述
先转到这个地址

在这里插入图片描述

转到了这个路径上

在这里插入图片描述
重写的不能和默认的ingress放在一起，只要是写了rewrite之后，是针对下面所有配置生效的，要实现规则，要保留两个ingress的数，一个是原生的，一个是针对重写的

在这里插入图片描述

第7章小结

6.1 通过ingress实现业务应用7层代理

kubeadm有两个核心的命令，init，join
在这里插入图片描述
kube-proxy是daemon-set的组件，利用iptablees或者ipvs实现了防火墙

configmap存储一些基础的数据，kv，secret去存储敏感数据，密码，证书
在这里插入图片描述
工作负载，还有daemonset，statsflust有状态服务（es，redis集群），conjob

去ip化，方便迁移

在这里插入图片描述
inges-controller调用apiserver拿到ingress配置转换成了nginx配置，controller里运行了一个nginx服务，动态reload

在这里插入图片描述

48N6E

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
3
评论
2021/01/28 k8s核心组件及工作流程

K8S用etcd（CP）存储数据，比如pod在哪个节点上APIserver接收请求，整个集群的访问入口，还有安全访问控制authentication authorization，etcd的数据只能api去写入。所有的数据想要同步只能通过apiserver来做。scheduler把业务容器调度到最合适的节点上去加入告诉K8S集群要启动两个副本，谁去保证有2个副本在启动，这是controller manager管理的，假如有一个挂了，它会再次启动。不管怎么样，它去保证副本数是2，副本控制器r...
复制链接

扫一扫