初始化kubernetes集群

pod分类

自主式pod

• 自我管理的pod，创建以后仍然需要提交给apiserver，由apiserver接收以后借助于调度器将其调度至指定的node节点,由node启动此pod
• 如果此pod出现故障，需要重启容器则由kubelet来完成
• 如果node节点故障了，那么此pod将会消失。其无法实现全局调度。所以不推荐使用此种pod

控制器管理的pod的种类以及区别

常见的pod控制器

• ReplicationController（副本控制器）
  当启动一个pod时，这个pod如果不够用可以再启一个副本，而后由控制器来管理同一类pod的各种副本与对象。一旦副本少了就会自动增加。采取多退少补的规则，精确符合我们所定义的期望
• 支持滚动更新
• ReplicaSet（复制集） 由一个名叫Deployment的声明式更新的控制器来管理
• Deployment（部署） Deployment只能管理无状态的应用
• StateFulSet（状态集） 有状态副本集,可以管理有状态的应用
• DaemonSet（守护程序）
• 如果需要在每个node上运行一个副本的时候可以用DaemonSet
• job（任务）
• Cronjob（定时任务）
• 以上每种控制器都是用来实现一钟独特的应用管理的

核心组件

Kubernetes主要由以下几个核心组件组成：

• etcd保存了整个集群的状态；
• apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

k8s核心组件

HPA

• Deployment还支持二级控制器
• HPA(HorizontalPodAutoscaler，水平pod自动伸缩控制器)
• 一般情况下我们可以确保一个node上有2个pod在运行，万一用户访问流量增加，2个pod不足以承载这么多访问量怎么办?此时我们就应该要增加pod资源,那么到底应该加几个?
• HPA控制器可自动监控pod、自动进行扩展。

service

• 假如有2个pod，pod有其生命周期，万一pod所在的节点宕机了，那么此pod将应该要在其他的节点上重建，而重建完的pod与原来的pod已经不是同一个pod了，只是两者都是运行的同一个服务而已。且每个容器都有其IP地址，重建的pod中的容器其IP地址与之前的pod中容器的IP地址是不一样的,如此一来就会存在一个问题,客户端如何访问这些pod中的容器呢?
• 服务发现
• pod是有生命周期的，一个pod随时都有可能离去，随时都有可能会有其他pod加进来，假如它们提供的是同一种服务，客户端是无法通过固定的手段来访问这些pod的,因为pod本身是不固定的,它们随时可能被替换掉,无论使用主机名还是P地址，都随时会被替换掉。
• 为了尽可能的降低客户端与pod问协调的复杂度，k8s为每-组提供同类服务的pod和其客户端之间添加了一个中间层,这个中间层是固定的,这+中间层就叫service
• service只要不被删除,其地址与名称皆是固定的,当客户端需要在其配置文件中写上访问某个服务时，它不再需要自动发现,只需要在配置文件中写明service的名称即可，而这个service是个调度器，其不但能够提供一个稳定的访问入口，还可以做反向代理，当service接收到客户端的请求后,会将其代理到后端的pod之上,一旦pod宕机了会立即新建一个pod，这个新建的pod会立即被service关联上,作为service后端的可用pod之一
• 客户端程序访问服务都是通过IP+端口或者主机名+端口的方式来实现的。而service关联后端的pod不是靠它的IP和主机名,而是靠pod的标签选择器。只要创建的pod的label是统一的,无论IP地址和主机如何改变，其都能被service所识别。如此一来,只要pod属于标签选择器，只要其在service的管理范围之内,则其就会被关联到service中，当这个动态的pod关联到service中之后，再进行动态的探测此pod的IP地址、端口,再将其作为自己后端可调度的可用服务器主机对象。因此，客户端的请求发送到service，然后由service代理到后端真实的pod中的容器进行响应。
• service不是一个程序,也不是一个组件，它只是一个iptables的dnat规则
• service作为k8s的对象，有其自身的名称，而service的名称相当于服务的名称，而这个名称可以被解析
  addOns附件
• dns pod
• 装完k8s后第一件事就需要在k8s集群上部署一个dns pod，以确保各service的名称能够被解析
• 可以动态改变,包括动态创建、动态删除、动态修改
• 比如把service的名称改了,dnspod会自动触发,将dns解析记录中的名称也给改掉;假如我们手动把service的ip地址给改了,改完以后会自动触发,将dns服务中的解析记录给改掉。
• 如此一来,客户端去访问pod资源的时候可以直接访问service的名称,然后由集群中专用的dns服务来负责解析。
• 这种pod是k8s自身的服务就需要用到的pod，所以我们把它称为基础性的系统架构级的pod对象，而且它们也被称为集群附件

初始化k8s集群

准备环境

主机	IP
master	192.168.100.30
node1	192.168.100.20
node2	192.168.100.40

关闭三台主机的防火墙

systemctl disable --now firewalld

关闭selinux：

 sed -i 's/enforcing/disabled/' /etc/selinux/config

关闭swap

[root@master ~]# vim /etc/fstab

//注释掉swap分区

在master中添加hosts

三台主机，都要做

[root@master ~]# cat >> /etc/hosts << EOF
> 192.168.100.30 master
> 192.168.100.20 node1
> 192.168.100.40 node2
> EOF

将桥接的ipv4流量传递到iptables的链

//三台主机都需要做

[root@master ~]#  cat > /etc/sysctl.d/k8s