技术小白的Kubernetes学习自白

技术小白的Kubernetes学习自白

• Kubernetes
• • 前言
  • Borg
  • Kubernetes基础概念
  • • K8S架构
    • Service
    • Pod
    • • Pod概念
      • 网络通讯方式
      • Service和Pod如何及建立联系/服务发现
    • APISERVER
    • Node
    • Replication Controller(RC)
    • Scheduler
    • Etcd
    • CoreDNS
    • Dashboard
    • Ingress Controller
    • Federation
    • Prometheus
    • ELK
  • 安装/下载
  • 云原生
  • koolshare配置

Kubernetes

前言

视情况更新和完善学习笔记，trying…

历史

Kubernetes特点

1. 轻量级，消耗资源少
2. 开源
3. 弹性伸缩
4. 负载均衡: 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

1. 拥有唯一指定的名称
2. 拥有一个虚拟IP(Cluster IP，Service IP 或 VIP) 和端口号。每个服务进程都有一个独立的EndPoint(IP+Port)访问点。K8S能够让我们通过Service(虚拟Cluster IP + Service Port)连接到指定的Service。有了K8S内建的透明负载均衡和故障恢复机制。不管后端有多少服务进程，也不管某个服务进程是否由于发生故障而被重新部署到其他机器，都不会影响对服务的正常调用。更重要的是，这个Service本身一旦创建就不再变化，这意味着我们再也不用为K8S集群中服务的IP地址变来变去的问题苦恼了。
3. 能够提供某种远程服务能力
4. 被映射到提供这种服务能力的一组容器应用上

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控制器类型

1. RelicationController & ReplicaSet & Deployment

   1.1 HPA (HorizontalPodAutoScale)

2. StatefulSet

3. DaemonSet

4. 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

1. 同一个 Pod 内的多个容器之间：lo(localhost)
2. 各 Pod 之间的通讯：Overlay Network
3. 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

1. 实现Pod与Pod之间的访问，实现负载均衡。
2. 操作对象为防火墙，去实现Pod的映射
3. 支持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