如何解析K8s简单的概念

今天就跟大家聊聊有关如何解析K8s简单的概念,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

目前创新互联建站已为数千家的企业提供了网站建设、域名、网页空间、网站托管运营、企业网站设计、镇沅网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。

K8s概念:
基本概念:
  • Cluster:集群。计算,存储网络资源的整合。

  • Master:负责分配,调度资源。

    • kube-apiserver:是K8s Cluster的前端接口,用来管理Cluster的资源。

    • kube-scheduler:负责决定将Pod放在那个Pod上运行。

    • kube-controller-manager:负责管理Cluster的各种资源,保证资源处于期望状态。

    • etcd:负责保存K8s Cluster的配置信息和各种资源的状态信息,当数据发送变化时,etcd会快速通知K8s相关组件。

    • Pod网络:负责Pod间的通信,常见的有Flannel,Calico等。

  • Node:用来运行应用,监听容器的状态,由Matser管理,支持物理机和虚拟机。

    • kubelet:是Node的Agent,当Scheduler确定在某个Node上运行Pod后,会将Pod的具体配置信息(image,volume等)发送给该节点的kubelet,kubelet根据这些信息创建和运行容器,并向Master报告运行状态。

    • Kubeproxy:Service在逻辑上代表了后端的多个Pod,外界通过Service访问Pod,Service接收到请求,如果有多个Pod副本,kube-proxy会实现负载均衡

    • Pod网络:负责Pod间的通信,常见的有Flannel,Calico等。

查看所有的组件:

[root@k8smaster ~]# kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
kube-system   coreDNS-bf7759867-8h5x8             1/1     Running   1          21h   10.244.0.5       k8smaster              
kube-system   coredns-bf7759867-slmsz             1/1     Running   1          21h   10.244.0.4       k8smaster              
kube-system   etcd-k8smaster                      1/1     Running   1          21h   192.168.43.45    k8smaster              
kube-system   kube-apiserver-k8smaster            1/1     Running   1          21h   192.168.43.45    k8smaster              
kube-system   kube-controller-manager-k8smaster   1/1     Running   1          21h   192.168.43.45    k8smaster              
kube-system   kube-flannel-ds-amd64-6zhtw         1/1     Running   1          20h   192.168.43.136   k8snode1               
kube-system   kube-flannel-ds-amd64-wnh9k         1/1     Running   1          20h   192.168.43.45    k8smaster              
kube-system   kube-flannel-ds-amd64-wqvz9         1/1     Running   1          20h   192.168.43.176   k8snode2               
kube-system   kube-proxy-2j8w9                    1/1     Running   1          20h   192.168.43.176   k8snode2               
kube-system   kube-proxy-kqxlq                    1/1     Running   1          20h   192.168.43.136   k8snode1               
kube-system   kube-proxy-nb82z                    1/1     Running   1          21h   192.168.43.45    k8smaster              
kube-system   kube-scheduler-k8smaster            1/1     Running   1          21h   192.168.43.45    k8smaster              
K8s资源抽象类型:
Pod:

  Pod是若干相关容器的组合,可以理解为一个组,组里面由一个或多个容器,容器之间是相关联的。

  Pod中的容器运行在同一个Host上,这些容器使用相同的网络命令空间,IP地址和端口,互相之间通过localhost来发现和通信。

  另外,这些容器还可以共享一块存储卷空间。

总结:

  • Pod是k8s中最小的工作单元,每个Pod包含一个或多个容器。

  • 同一Pod包含的容器运行在同一个Host上,称作为统一管理单元。

  • 同一Pod通过Mapped Container共享着相同的volumes,network,namespace,ip,port。

    • pid ns:处于同一Pod中的应用可以看到彼此的进程。

    • network ns:处于同一Pod中的应用可以访问一样的ip和port空间。

    • ipc ns:处于同一Pod的应用可以用systemV ipc或者posix消息队列进行通信。

    • UTC ns:处于同一Pod应用公用一个主机名。

Replication Controller(RC):

  • RC是用来管理Pod的,每个RC由一个或多个Pod组成;在RC被创建之后,系统将会保持RC中可用的Pod的个数与创建RC时定义的Pod个数一致,如果Pod个数小于定义的个数,RC会启动新的Pod,反之会杀死多余的Pod。

  • RC通过定义的Pod模板被创建,创建后对象叫做Pods(也可以理解为RC),可以在线修改Pod的属性,以实现动态缩减,扩展Pods的规模。

  • RC通过label关联对应的Pods,通过修改Pods的label可以删除对应的Pods在需要对Pods中的容器进行更新时,RC采用一个一个替换的原则来更新整个Pods中的Pod。

  • reschudeling:维护Pod副本,“多退少补”;即使是某些minion宕机。

  • scaling:通过修改RC的副本数来水平扩展或缩减运行的Pods。

  • Rolling updates:一个一个地替换Pods来更新服务。

  • multiple release tracks:如果需要在系统中运行multiple release服务,Replication Controller使用labels来区分multiple release tracks。

Label:
  • Label是用于区分Pod,Service,RC的Key/Value键值对。

  • Pod,Service,RC可以有多个Label,但是每个Label的Key只能对应一个Value。

  • 整个系统都是通过Label进行关联,得到真正需要操作的目标。

Service:

  Service是定义在集群中一组运行Pod集合的抽象资源,它提供了所有相同的功能,当一个Service资源被创建后,将会分配一个唯一的IP,也叫做集群IP,这个IP地址将存在于Service的整个生命资源中,Service一旦被创建,整个IP无法进行修改。

  Pod可以通过Service进行通信,并且所有的通信将会通过Service自动负载均衡到所有的Pod中的容器。

  • Service是真实应用服务的抽象。

  • Service通常用来将浮动的资源与后端真实提供服务的容器进行关联。

  • Service对外表现为一个单一的访问接口,外部不需要了解后端的规模与机制。

Controller:

  K8s通常不会直接创建Pod,而是通过Controller来管理Pod,Controller中定义了Pod的属性,为了满足不同的业务场景,K8s提供了多种Controller,包括Deployment,Replicaset,Daemonset,Statefulset,Job等。

  • Deployement:是最常用的Controller,用来管理Pod的多个副本。并且确保Pod按照期望状态运行。

  • Replicaset:实现了Pod的多副本管理,使用Deployment时会自动创建Replicaset,也就是说Deployment通过Replicaset实现管理Pod的多个副本,通常不需要主节使用Replicaset。

  • Daemonset:用于每个node最多只能运行一个Pod副本的场景。

  • Statefuleset:能够保证Pod的每个副本在整个生命周期中名称是不变的,而其他Controller不提供这个功能,当某个Pod发生故障需要删除并重启时,Pod的名称会发生变化,同时Statefulset会保证Pod副本按照指定的顺序启动,更新或删除。

  • Job:用于结束就删除的应用,而其他Controller中Pod通常时长期持续运行的。

Namespace:

  将一个物理的Cluster逻辑上划分成多个虚拟的Cluster,每个Cluster就是一个Namespace。不同的Namepace。每个Cluster的资源都是隔离开的。

查看所有Namespace

[root@k8smaster ~]# kubectl get namespace
NAME              STATUS   AGE
default           Active   19h
kube-node-lease   Active   19h
kube-public       Active   19h
kube-system       Active   19h
运行应用流程:
[root@k8smaster ~]# kubectl run http-app --image=httpd --replicas=2
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/http-app created
[root@k8smaster ~]# kubectl get deployments
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
http-app   0/2     2            0           49s
[root@k8smaster ~]# kubectl get pod -o wide
NAME                       READY   STATUS             RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
http-app-c5f548d75-44hxm   0/1     ImagePullBackOff   0          21m   10.244.2.3   k8snode2              
http-app-c5f548d75-kzlrt   0/1     ImagePullBackOff   0          21m   10.244.1.2   k8snode1              
流程:

  • kubectl发送部署请求给API Server。

  • API Server通知Controller Manager创建一个deployment资源。

  • Scheduler执行调度任务,将要创建的任务按照一定的策略调度到相关节点上。

  • Node节点上的Kubelet负责接调度任务,通过Kubelet在各自的节点上接收并运行pod。

    • node1:node1-http-app-c5f548d75-44hxm

    • node2:node2-http-app-c5f548d75-kzlrt

看完上述内容,你们对如何解析K8s简单的概念有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。


网站栏目:如何解析K8s简单的概念
本文来源:http://scyanting.com/article/gjdegh.html