k8s集群架构及基本操作

发布时间：2020-06-27 20:53:26 来源：网络阅读：624 作者：wx5b9c94b17c62a 栏目：云计算

首先在k8s集群中要知道有两个部署工具：
kubeadm：自动化部署k8s集群的工具。
kubectl： k8s命令行工具，用于接收用户输入的指令。

kubernetes是由什么组成的？

在硬件级别，一个kubernetes集群由很多节点组成，这些节点被分成以下两种类型：

主节点：它承载着kubernetes控制和管理整个集群系统的控制面板
工作节点： 它们运行用户实际部署的应用。

控制面板（master）

控制面板用于控制集群并使它工作。它包含多个组件，组件可以运行在单个主节点上或者通过副本分别部署在多个主节点以确保高可用性。

master中的组件有：

注意：master节点默认不参加工作，如果有需要我们可以将它设置为参加工作，但是一般不建议这么做，因为master节点用于负责控制并管理集群，所以非常重要，一般保持默认让它不参加工作即可。

APIserver：apiserver是k8s集群中的前端接口，各种客户端工具以及k8s其他组件可以通过它管理集群中的各种资源。
Scheduler：负责决定将pod放在那哪个node删运行。在调度的过程中，会考虑集群的节点状态，当前各个节点的负载状况，以及对应调度高可用，性能等需求。
Controller manager：负责管理k8s集群的各种资源。保证资源处于用户期望的状态。
ectd：多数据中心，负责保存k8s集群的配置信息和各种资源的状态信息，当数据发生变化的时候，etcd会通知k8s集群的其他组件。
Pod：是k8s集群里边最小的单位。每个pod里边运行一个或多个container（一般只运行一个）

Node节点组件有：

kubelet：是Node节点的代理，当Schedule确定某一个node上运行pod之后，会将pod的具体配置信息（image，volume）等发送给该节点的kubelet，kubelet根据这些信息创建和运行容器，并向master报告运行状态。
自动修复功能：如果某个节点中的容器宕机，它会自动杀死掉，然后重新创建一个容器。
kube-Proxy（负载均衡）：service在逻辑上代表了后端的多个pod，外界通过service访问pod。
service接收到的请求是如何转发到pod上？这就是kube-proxy要完成的工作。通过iptables规则来做到负载均衡。

k8s集群架构及基本操作
各组件之间是怎样交互的呢？：
首先用户通过kubectl发送部署命令，传到集群中APIserver，APIserver得到指令后，通知Controller Manager创建一个deployment的资源对象，得到确认后，又将指令传给APIserver，APIserver会与etcd进行沟通，etcd会调取集群中的各种资源信息，接下来由Schedule来执行调度，决定将pod分配给集群中的哪个节点来运行。最后kubelet会根据要求在各自节点上创建并运行pod。

k8s基本操作

k8s中各个组件的yaml文件存放位置：
k8s集群架构及基本操作

kubernetes默认的名称空间有以下四个：
k8s集群架构及基本操作

1）创建一个控制器，部署一个Deployment的资源对象
[root@master ~]# kubectl run nginx-deploy --image=nginx --port=80 --replicas=2

k8s集群架构及基本操作

参数解释：
kubectl run：运行一个资源对象，后面跟自定义名称
--image: 指定镜像，也就是你要部署的服务
--port: 指定该服务的端口
--replicas：创建2个副本

//查看Deployment资源对象
[root@master ~]# kubectl  get deployments. -o wide

k8s集群架构及基本操作

参数解释：
-o wide: 加上该参数，显示的内容更宽泛一点
READY：表示所达到的期望值，2/2 表示有2个可用。
AVAILABLE：表示为可用的数

它会自动的去下载镜像（nginx镜像），也可以提前将镜像上传到服务器上，从本地进行下载。

//查看pod运行到哪个节点之上：（包括显示pod的ip地址）
[root@master ~]# kubectl get pod -o wide

k8s集群架构及基本操作
以上pod分配的ip地址是在我们初始化集群时，指定官方提供的pod网络中的网段。

一个pod中会有两种容器（其中）：
USR，MNT，PID是相互隔离的
UTS，IPC，NET是相互共享的

2）service-暴露资源：（暴露端口给外网）
#如果外网想要访问k8s中提供的服务，就必须创建一个service的资源对象。

[root@master ~]# kubectl expose deployment  nginx-deploy --name=myweb --port=80 --type=NodePort
service/myweb exposed

参数解释：
expose：暴露端口
nginx-deploy：暴露名称为nginx-deploy的资源对象
--name：自定义名称myweb
--port：指定端口80
--type：指定类型nodeport

#其实上面就相当于是创建了个service。

//查看service映射出来的资源对象：
[root@master ~]# kubectl get service
k8s集群架构及基本操作

解释：
CLUSTER-IP：统一的一个集群接口，为集群内部通信的地址。
80:32326/TCP：80为服务端口，后面的端口是暴露给外网的（随机生成，范围是30000-32767）

//外网测试通过该暴露的端口来访问集群web界面：
url:http://172.16.1.30:30400/
k8s集群架构及基本操作

需要知道的是集群中的任何一台主机都是可以进行访问的，不是只有master。

3）手动删除节点上的容器，然后再次查看Deployment资源对象，查看Pod是否维持在用户所期望的数量？IP地址是否有变化？

[root@master ~]# kubectl  get pod -o wide  #查看pod分配的节点
NAME                            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx-deploy-59f5f764bb-h7pv2   1/1     Running   0          44m   10.244.1.2   node01   <none>           <none>
nginx-deploy-59f5f764bb-x2cwj   1/1     Running   0          44m   10.244.2.2   node02   <none>           <none>

在node01上删除容器：
[root@node01 ~]# docker ps

k8s集群架构及基本操作

[root@node01 ~]# docker rm -f 47e17e93d911

//再次查看Deployment资源对象：
[root@master ~]# kubectl  get deployments. -o wide
NAME           READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS     IMAGES   SELECTOR
nginx-deploy   2/2     2            2           48m   nginx-deploy   nginx    run=nginx-deploy

//查看pod
[root@master ~]# kubectl  get pod -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx-deploy-59f5f764bb-h7pv2   1/1     Running   0          50m   10.244.1.2   node01   <none>           <none>
nginx-deploy-59f5f764bb-x2cwj   1/1     Running   0          50m   10.244.2.2   node02   <none>           <none>

可以看pod还是维持在我们所期望的数量，并且pod的ip地址也是没有变化的，你会发现当你删除节点上的容器时，它会马上自动生成一个新的pod。这是为什么呢？
其实是通过集群中controller manager组件来保证资源处于用户所期望的状态，就是说当你定义副本时，你定义了2个，它会保证你一直运行着2个pod，如果少了，会进行增加。

kube-proxy实现负载均衡的底层原理

1）首先我们创建一个deployment+service的资源对象，定义副本数量3个

[root@master yaml]# vim nginx.yaml 
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: nginx
        image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  selector:
    app: web-server
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80
    nodePort: 30000

//执行yaml文件：
[root@master yaml]# kubectl apply -f  nginx.yaml 
deployment.extensions/nginx-deploy configured
service/nginx-svc created

//查看pod：
[root@master yaml]# kubectl  get pod 
NAME                            READY   STATUS    RESTARTS   AGE
nginx-deploy-56558c8dc7-gq9dt   1/1     Running   0          18s
nginx-deploy-56558c8dc7-jj5fv   1/1     Running   0          18s
nginx-deploy-56558c8dc7-z5sq4   1/1     Running   0          17s

//查看service：
k8s集群架构及基本操作
2）分别进入pod修改每个pod的默认访问界面（确保界面不同）。。。。。。。

3）访问界面，验证是否会有轮询效果：

[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No1
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No2
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No3
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No2
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No1
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No3
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No1
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No2

可以看到访问页面是会有轮询效果的，虽然靠的是kube-proxy组件来实现负载均衡的底层原理的，但主要通过iptables规则来实现负载均衡的。
详细过程如下：

//首先我们查看一下Cluster ip的地址：
k8s集群架构及基本操作

//接下来通过查看iptables规则：
[root@master yaml]# iptables-save
//找到集群ip的转发规则：
k8s集群架构及基本操作
##它会跳转到另一个规则，我们来查看这个值：

以上的值是它实现负载均衡随机算出的平均值，我们前面有3个副本，第一次是1/3的概率（%0.3），分配完，第二次和第三次就是1/2的概率了（%0.5）。第三次就没有详细的显示出它的一个概率了，但我们知道它的概率也是%0.5。