技术小白的Kubernetes学习自白
技术小白的Kubernetes学习自白
- Kubernetes
- 前言
- 历史
- K8S组件
- K8S的一些关键字解释
- Borg
- BorgMaster
- scheduler
- Kubernetes基础概念
- K8S架构
- Service
- DNS服务器
- Socket通信
- DHCP
- DHCP和STATIC
- Pod
- Pod概念
- 自主式Pod
- 控制器管理的Pod
- 网络通讯方式
- LVS
- Service和Pod如何及建立联系/服务发现
- APISERVER
- Node
- kubelet
- kube-proxy
- Replication Controller(RC)
- Scheduler
- Etcd
- ETCD内部架构图
- v2
- v3
- CoreDNS
- Dashboard
- B/S结构
- C/S结构
- B/S vs C/S
- Ingress Controller
- Federation
- Prometheus
- ELK
- 安装/下载
- 构建软路由
- 云原生
- koolshare配置
Kubernetes
前言
视情况更新和完善学习笔记，trying…
历史
Kubernetes特点
- 轻量级，消耗资源少
- 开源
- 弹性伸缩
- 负载均衡: IPVS
K8S组件
K8S的一些关键字解释
Borg
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YI5k3WD0-1583118152623)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581407966287.png)]
BorgMaster
调度器或者高可用节点最好保持在3个以上的奇数。
因为etcd集群数量必须为单节点个数，所以对应master一般都是单数。
最好是 3，5，7，9
scheduler
调度器
scheduler先把数据写入Paxos键值对数据库。Borglet监听Paxos数据库。故通过Paxos为中间商实现scheduler请求
Kubernetes基础概念
kubernetes和borg有一定的相似之处
K8S架构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DHeqoc2W-1583118152625)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581408449730.png)]
从这个表格可以看出来 几乎所有的服务都是通过api server进行分发的。
服务分类
有状态服务：DBMS
无状态服务：LVS APACHE
高可用集群副本数据最好是 >= 3 奇数个
k8s内部是一个扁平化的网络，容器之间是可以互相访问的
Service
- 拥有唯一指定的名称
- 拥有一个虚拟IP(Cluster IP，Service IP 或 VIP) 和端口号。每个服务进程都有一个独立的EndPoint(IP+Port)访问点。K8S能够让我们通过Service(虚拟Cluster IP + Service Port)连接到指定的Service。有了K8S内建的透明负载均衡和故障恢复机制。不管后端有多少服务进程，也不管某个服务进程是否由于发生故障而被重新部署到其他机器，都不会影响对服务的正常调用。更重要的是，这个Service本身一旦创建就不再变化，这意味着我们再也不用为K8S集群中服务的IP地址变来变去的问题苦恼了。
- 能够提供某种远程服务能力
- 被映射到提供这种服务能力的一组容器应用上
DNS服务器
域名解析
先访问的是DNS服务器 然后 它解析过之后，返回服务器的ip 给用户访问
Socket通信
DHCP
DHCP（动态主机配置协议）是一个局域网的网络协议。指的是由服务器控制一段lP地址范围，客户机登录服务器时就可以自动获得服务器分配的lP地址和子网掩码。默认情况下，DHCP作为Windows Server的一个服务组件不会被系统自动安装，还需要管理员手动安装并进行必要的配置。
DHCP和STATIC
Dhcp：动态获取ip 一般都是客户端
Static：静态获取ip 一般都是服务端
Dhcp Client —— dhcp 所有客户端的信息
Static IP —— 静态IP，不通过dhcp动态分配IP
Pod
Pod概念
自主式Pod
将每个服务进程都包装到相应的Pod中，使其成为在Pod中运行的一个容器(Container)，其中会有一个名为Pause的容器，其余的容器称为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷。最小的封装集合，是Kubernetes的最小管理单位。
Pause容器和业务容器之间的通信和数据交换更为高效。
同一个Pod共享一个网络栈，相当于本地网络，两个容器之间可以通过localhost访问。(就是本地网络下两个容器之间的数据交互，内部可以访问，外部无法访问)
类似docker里的 link 和 volume
Pod中会有多个容器(container)
控制器管理的Pod
Pod控制器类型
-
RelicationController & ReplicaSet & Deployment
1.1 HPA (HorizontalPodAutoScale)
-
StatefulSet
-
DaemonSet
-
Job, Cronjob
RelicationController & ReplicaSet & Deployment & HPA (HorizontalPodAutoScale)
ReplicationController 用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也自动回收。在新版本中Kubernetes中建议使用ReplicaSet来取代ReplicationController
ReplicaSet 与 RC没有本质区别，只是名字不一样，并且ReplicaSet 支持集合式的 selector
一般建议使用Deployment来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题(比如 ReplicaSet 不支持rolling-update|滚动更新 但 Deployment支持)
Horizontal Pod Autoscaling 仅仅适用于 Deployment 和ReplicaSet，在V1版本中仅支持根据 Pod 的 CPU 利用率所扩容，在vlalpha版本，支持根据内存和用户自定义的 metric 扩容缩。实现弹性伸缩。利用多个Pod分摊cpu的负载，达到降低cpu使用率的效果。
StatefulSet
StatefulSet 是为了解决有状态服务的问题(对应 Deployments 和 ReplicaSets 是为无状态服务而设计)，其应用场景包括：
- 稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于PVC实现
- 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service (即没有 Cluster IP 的 Service ) 来实现
- 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要根据定义的顺序依次进行(即从 0 到 N-1，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态)，基于 init containers 来实现。
- 有序收缩，有序删除 (即从 N-1 到 0)
DaemonSet
DaemonSet 确保全部 (或者一些) Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
使用 DaemonSet 的一些典型用法：
- 运行集群存储 daemon，例如在每个 Node 上运行 glusterd，ceph。
- 在每个 Node 上运行日志收集 daemon，例如fluentd，logstash。
- 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter
Job, Cronjob
Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束
Cron Job管理基于时间的 Job，即
- 在给定时间点只运行一次
- 周期性地在给定时间点运行
这两个类似Linux的定时任务，at和crontab的区别，运行一次和运行多次，是否可以复用
网络通讯方式
Kubernetes 的网络模型假定了所有 Pod 都在一个可以直接连通的扁平的网络空间中，这在 GCE(Google Computer Engine) 里面是现成的网络模型，Kubernetes 假定这个网络已经存在。而在私有云里搭建 Kubernetes 集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的 Docker 容器之间的互相访问先打通，然后运行Kubernetes
- 同一个 Pod 内的多个容器之间：lo(localhost)
- 各 Pod 之间的通讯：Overlay Network
- Pod 与 Service 之间的通讯：各节点的 Iptables 规则，最新版本可以通过LVS
Flannel
Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的 Docker 容器给都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络(Overlay Network)，通过这个覆盖网络，将数据包原封不动地传递到目标容器内。不同机器上运行的docker容器(IP不同，可以通过网桥修改分配IP)。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dwD4zhfs-1583118152626)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581415395239.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JiEr9ynZ-1583118152627)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581415437865.png)]
ETCD 和 Flannel 之间的关联
- 存储管理 Flannel 可分配的 IP 地址段资源
- 监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表
ETCD拥有非常优秀的集群化
不同情况下网络通信方式
同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈
Pod1 至 Pod2
- Pod1 与 Pod2不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。
- Pod1 与 Pod2 在同一台机器，由docker0网桥直接转发请求至 Pod2，不需要经过 Flannel
Pod 至 Service 的网络：目前基于性能考虑，全部为iptables 维护和转发| 最新版本，可以通过LVS维护和转发
Pod 到 外网：Pod 向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求。
外网访问 Pod : Service
组件通讯示意图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DBB7mDv2-1583118152627)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581423162201.png)]
LVS
Service和Pod如何及建立联系/服务发现
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7XSYl1dE-1583118152627)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581413907960.png)]
通过类似CSS选择器的功能。每个Pod都会有一个Label标签，比如MySQL的标签 name=mysql，运行php的标签 name=php。Service通过这些标签，就知道和对应的Pod建立联系了
APISERVER
相当于一个交通中心
Node
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HY2knY7a-1583118152628)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581409191224.png)]
需要安装 kubelet，kube-proxy，Docker/虚拟机
kubelet
作用：CRI(Container Runtime Interface)
直接跟容器引擎交互实现容器的生命周期
kube-proxy
- 实现Pod与Pod之间的访问，实现负载均衡。
- 操作对象为防火墙，去实现Pod的映射
- 支持IPVS(LVS)
Replication Controller(RC)
副本控制器。维护副本数(达到期望的量)
Scheduler
调度器，复制介绍任务，选择合适的节点进行分配任务
Etcd
ETCD内部架构图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-psfqZ2iW-1583118152628)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581408991826.png)]
采用go语言编写的键值对数据库
etcd官方将它定位成一个可信赖的分布式键值对存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转。
etcd属于分布式一致性k-v数据库，一般用于保存配置信息等
天生具有集群化特性。
v2
需要备份
v3
最新版本，数据存在磁盘当中。
CoreDNS
可以为集群中的SVC创建一个域名IP的对应关系解析，是实现负载均衡的其中一个组件
Dashboard
给 K8S 集群提供一个 B/S 结构访问体系
B/S结构
B/S (Browser/Server)：又称浏览器/服务器模式。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。客户机上只要安装一个浏览器，如Internet Explorer，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server 同数据库进行数据交互。
C/S结构
C/S(Client/Server)：又称客户/服务器模式。服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统，如Oracle、Sql Server等。客户端需要安装专用的客户端软件。
B/S vs C/S
一、C/S
1.优点：
（1）安全性：需要其特定的客户端，所以面向对象比较确定，将所进行的信息安全处于一个可控的范围
（2）效率：客户端的服务器直接相连，省却了中间环节，数据的传输比较快
（3）个性化：有特定的客户端，所以可以在较大程度上满足客户的个性化要求
（4）稳定性：结构比较稳定，有较强的事务处理能力，可以实现较复杂的业务逻辑
2.缺点：
（1）特定的客户端：对pc机有一定的要求，如：操作系统，并且它就像订在墙上的石头桌子，不可再利用
（2）中间环节：因为省却了中间环节，所以当客户端达到一定的量时，同时访问服务器，造成服务器的相应变慢，效率变低
二、B/S
1.优点：
（1）范围：零安装，拥有一个浏览器，即可访问，面向的范围更广
（2）维护性：维护简单，更新页面，即可实现面向所有用户的更新
（3）共享性：通过浏览器访问，共享性强，就像买来的餐桌，可以再利用
2.缺点：
（1）安全性：面向的范围广，所以安全性比较低
（2）个性化：因为面型的范围广，所以它是一种公共审美，无法满足个性化的需求
Ingress Controller
官方只能实现四层代理，Ingress可以实现七层代理
Federation
提供一个可以跨集群中心多K8S统一管理功能
Prometheus
提供K8S集群的监控能力
ELK
提供K8S集群日志统一分析介入平台
安装/下载
构建软路由
云原生
文章中所有的图片来源自互联网，如侵请联系作者删除
koolshare配置
安装好koolshare后
目的
实现3个机器以内网访问koolshare，通过koolshare访问外网。
centos7的ip配置在
/etc/sysconfig/network-scripts/ifcfg-ens33
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
# 改为静态static
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=ens33
UUID=d0e94d00-aeaa-4f88-b79a-8501e330662e
DEVICE=ens33
ONBOOT=yes
IPADDR=192.168.66.10
# 配置该机器的ip
NETMASK=255.255.255.0
# 掩网
GATEWAY=192.168.66.1
# 网关
DNS1=192.168.66.1
DNS2=114.114.114.114