1. 什么是pod?
- pod相当于逻辑主机,每个pod都有自己的ip地址
- pod内的容器共享相同的ip和端口空间
- 默认情况下,每个容器的文件系统与其他容器完全隔离
- 可以理解为:容器组,同时pod相当于逻辑主机,进入pod后仿佛进入一个linux主机,命令都可用(linux系统下),该“主机”内又有很多容器,进入后又仿佛是又进了一个linux主机。
1.1 pod的分类
pod分为两种类型:
- 自主式pod
- 控制器管理的pod
1,自我管理的pod,创建以后仍然需要提交给apiserver,由apiserver接收以后借助于调度器将其调度至指定的node节点,由node启动此pod,如果此pod出现故障,需要重启容器则由kubelet来完成;如果node节点故障了,那么此pod将会消失。其无法实现全局调度。所以不推荐使用此种pod。
2,Pod控制器是管理pod的中间层,使用Pod控制器之后,只需要告诉Pod控制器,想要多少个什么样的Pod就可以了,它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障,它会基于指定策略重新编排Pod
1.2 常见的pod控制器
replicationController:当启动一个pod时,这个pod如果不够用可以再启一个副本,而后由控制器来管理同一类pod的各种副本与对象。一旦副本少了就会自动增加。采取多退少补的规则,精确符合我们所定义的期望;支持滚动更新。(比较原始的pod控制器,已经被废弃,由ReplicaSet替代)
-
replicaset:由一个名叫Deployment的声明式更新的控制器来管理
-
Deployment:Deployment只能管理无状态的应用
-
StateFulSet:有状态副本集,可以管理有状态的应用
-
DaemonSet:如果需要在每个node上运行一个副本的时候可以用DaemonSet
-
Job:它创建出来的pod只要完成任务就立即退出,不需要重启或重建,用于执行一次性任务
-
Cronjob:它创建的Pod负责周期性任务控制,不需要持续后台运行
以上所有控制器都是用来实现一种特定的应用管理的。
2. kubernetes的核心组件
2.1 HPA
Deployment还支持二级控制器HPA(HorizontalPodAutoscaler,水平pod自动伸缩控制器)一般情况下我们可以确保一个node上有2个pod运行,万一用户访问流量增加,2个pod不足以承受这么多的流量怎么办?此时我们就应该要增加pod资源,那么到底应该加几个?HPA控制器可自动监控pod、自动进行扩展。
2.2 service
假如有2个pod,pod有其生命周期,万一pod所在的节点宕机了,那么此pod将应该要在其他的节点上重建,而重建完的pod与原来pod已经不是同一个pod了,只是两者都是运行的同一服务而已。且每个容器都有其IP地址,重建的pod中的容器其IP地址与之前的pod中容器的IP地址是不一样的,如此一来就会存在一个问题,客户端如何访问这些pod中的容器呢?
措施:服务发现:就比如集贸市场的注册摊位和声明地址,注册摊位就是买东西的摊位,有一天这个摊位的商贩换地方了,就会在原来的摊位上留下一个摊位声明告诉顾客自己换地方了,但是它出售的商品还是一样的。只是换个地方买而已,这就是服务发现。
pod是有生命周期的,一个pod随时都有可能离去,随时都有可能会有其他pod加入进来,假如它们提供的同一种服务,客户端是无法通过固定的手段来访问这些pod的,因为pod本身是不固定的,它们随时可能被替换掉,无论使用主机名还是IP地址,都随时会被替换掉。为了尽可能的降低客户端与pod间协调的复杂度,k8s为每一组提供同类服务的pod和其客户端之间添加了一个中间层,这个中间层是固定的,这个中间层就叫service。
service只要不被删除,其地址与名称皆是固定的,当客户端需要在其配置文件中写上访问某个服务时,它不再需要自动发现,只需要在配置文件中写明service的名称即可,而这个service是个调度器,其不但能够提供一个稳定的访问入口,还可以做反向代理,当service接收到客户端的请求后,会将其代理到后端的pod之上,一旦pod宕机了会立即新建一个pod,这个新建的pod会立即被service关联上,作为service后端的可用pod之一。
客户端程序访问服务都是通过IP+端口号或主机名+端口的方式来实现的。而service关联后端的pod不是靠它的IP和主机名。而是靠pod的标签选择器。只要其在service所识别。如此一来,只要pod属于标签选择器,只要其在service的管理范围之内,则其就会被关联到service中,当这个动态的pod关联到service中,当这个动态的pod关联到service中之后,再进行动态的探测此pod的IP地址、端口号,再将其作为自己后端可调度的可用服务器主机对象。因此,客户端的请求发送到service,然后service代理到后端真实的pod中的容器进行响应。
service不是一个程序,也不是一个组件,它只是一个iptables的dnat规则,service作为k8s的对象,有其自身的名称,而service的名称相当于服务的名称,而这个名称可以被解析。
3. kubernetes网络模型
- 节点网络
- service网络
- pod网络
k8s的三种网络模型分属于三个网段,由此延伸出来三个问题
同一个pod内的多个容器间如何通信?
lo网卡进行通信,因为同一个pod内的容器共用一个网路名称空间,而且在同一个网段。
各pod间如何通信?
- 物理桥接,但是在一定规模下容易产生网络风暴,不建议使用
- Overlay Network 通过隧道的方式转发报文
- pod与service间如何通信?首先各节点之间是相互通信的,节点也就是真机之间的通信,因为service网络是一个iptables规则,且与真机是相连的,而pod和service是我们初始化的时候通过flannel网络进行互联,且属于同一网段。
4. kubectl命令使用
kubectl命令官方文档:https://kubernetes.io/zh/docs/reference/kubectl/.
4.1 create命令
//语法
kubectl create deployment NAME --image=image -- [COMMAND] [args...]
kubectl create deployment NAME --image=image -- [COMMAND] [args...] //格式
[root@master ~]# kubectl create deployment test1 --image busybox
deployment.apps/test1 created //使用busybox镜像创建一个test1的pod
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-6799fc88d8-thr6q 1/1 Running 0 3h28m
test1-78d64fd9b9-8gmbc 0/1 CrashLoopBackOff 3 114s //可以看到处于退出状态,因为busybox使用的是sh,没有任务就会退出
[root@master ~]# kubectl create deployment test2 --image busybox -- sleep 60
deployment.apps/test2 created
test2-7c95bf5bcb-tqgn5 1/1 Running 0 17s //正在运行
[root@master ~]# kubectl create deployment web --image nginx --replicas 3 // 创建使用nginx镜像创建三个pod,名字为web
deployment.apps/web created
[root@master ~]# kubectl get pod
web-96d5df5c8-2kqfx 1/1 Running 0 57s
web-96d5df5c8-ld842 1/1 Running 0 57s
web-96d5df5c8-vtwks 1/1 Running 0 57s
[root@master ~]# kubectl get pods -o wide //查看pod运行的节点位置
web-96d5df5c8-2kqfx 1/1 Running 0 2m2s 10.244.2.3 node2.example.com <none> <none>
web-96d5df5c8-ld842 1/1 Running 0 2m2s 10.244.1.6 node1.example.com <none> <none>
web-96d5df5c8-vtwks 1/1 Running 0 2m2s 10.244.2.4 node2.example.com <none> <none>
[root@master ~]# kubectl create deployment web01 --image nginx --port=80 //暴露80端口号
4.2 run命令