mvc4 做网站,网站聊天系统怎么做,国外做测评的网站有哪些,上虞网站设计本文讲的是Kubernetes基础组件概述【编者的话】最近总有同学问Kubernetes中的各个组件的相关问题#xff0c;其实这些概念内容在官方文档中都有#xff0c;奈何我们有些同学可能英文不好#xff0c;又或者懒得去看#xff0c;又或者没有找到#xff0c;今天有时间就专门写… 本文讲的是Kubernetes基础组件概述【编者的话】最近总有同学问Kubernetes中的各个组件的相关问题其实这些概念内容在官方文档中都有奈何我们有些同学可能英文不好又或者懒得去看又或者没有找到今天有时间就专门写了这篇博客。【深圳站3天烧脑式Kubernetes训练营】培训内容包括Kubernetes概述、架构、日志和监控部署、自动驾驶、服务发现、网络方案等核心机制分析进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。本文主要介绍Kubernetes的基础组件先介绍Master节点上的控制管理组件再介绍Node节点上的计算组件最后是附加组件后边会找时间再写一篇介绍Kubernetes中的各种资源及使用。1 Master节点组件 Master节点组件是指运行在Kubernetes集群中的Master节点上提供整个集群的管理控制功能的组件例如调度组件kube-scheduler接口组件kube-apiserver等1.1 kube-apiserver kube-apiserver主要负责暴露Kubernetes API不管是kubectl还是HTTP调用来操作Kubernetes集群各种资源都是通过kube-apiserver提供的接口进行操作的。详细介绍、文档、配置参数API-Server配置。 1.2 kube-controller-manager 管理控制器负责整个Kubernetes的管理工作保证集群中各种资源的状态处于期望状态当监控到集群中某个资源状态不正常时管理控制器会触发对应的调度操作主要由以下几部分组成节点控制器Node Controller副本控制器Replication Controller端点控制器Endpoints Controller命名空间控制器Namespace Controller身份认证控制器Serviceaccounts Controller详细介绍、文档、配置参数Controller-Manager配置。 1.3 cloud-controller-manager 云管理控制器是Kubernetes 1.6新加入的组件组件抽象了一层IaaS平台的接口具体的实现由各云厂商负责提供主要负责与基础计算云平台IaaS的交互目前还处于测试开发阶段我们也还没有使用过该组件。该组件的具体实现包括节点控制器Node Controller路由控制器Route Controller负载均衡服务控制器Service Controller数据卷控制器Volume Controller1.4 kube-scheduler 调度器负责Kubernetes集群的具体调度工作接收来自于管理控制器kube-controller-manager触发的调度操作请求然后根据请求规格、调度约束、整体资源情况等因素进行调度计算最后将任务发送到目标节点的kubelet组件执行。详细介绍、文档、配置参数Scheduler配置。 1.5 etcd etcd是一款用于共享配置和服务发现的高效KV存储系统具有分布式、强一致性等特点。在Kubernetes环境中主要用于存储所有需要持久化的数据。2 Node节点组件 Node节点组件是指运行在Node节点上负责具体POD运行时环境的组件。2.1 kubelet kubelet是Node节点上最重要的核心组件负责Kubernetes集群具体的计算任务具体功能包括监听Scheduler组件的任务分配挂载POD所需Volume下载POD所需Secrets通过与docker daemon的交互运行docker容器定期执行容器健康检查监控、报告POD状态到kube-controller-manager组件监控、报告Node状态到kube-controller-manager组件2.2 kube-proxy kube-proxy主要负责Service Endpoint到POD实例的请求转发及负载均衡的规则管理。kube-proxy本身实际上并不负责请求转发和负载均衡而时从kube-apiserver获取Service和POD的状态更新生成对应的DNAT规则到本地的iptabels最终的转发和负载均衡动作有iptabels实施所以kube-proxy组件即使出现问题已经更新到iptabels的转发规则依然能够生效。详细介绍、文档、配置参数Kube-Proxy配置。 3 附加组件 BTW所谓的附加组件并不是说这类组件在kunernetes环境中可有可无只是为了区别于底层的基础计算组件。有了上边介绍的Master节点组件和Node节点组件后基础的Kubernetes环境算是已经构建好了kubectl调用apiserver发送创建pod的请求scheduler收到调度任务发送到符合要求的node节点node节点上的kubelet与docker daemon通讯创建docker容器。但是离真正可用的Kubernetes集群还有一定距离例如Container IP管理内部DNS解析简单的管理控制台等。 3.1 Flannel Flannel是由ConreOS主导设计的用于容器技术的覆盖网络Overlay Network在Flannel管理的容器网络中每一个宿主机都会拥有一个独立子网用于分配给其上的容器使用。通信方式是基于隧道协议的UDP和VXLAN等方式封包、解包及传输。原生的docker网络结构docker在启动的时候会创建一个网桥docker0(172.17.0.0)容器启动的时候会创建一对Veth pair这个Veth pair成对出现用于链接容器与docker0网桥可以将其理解成一根网线的两个插头一头插在容器内改名为eth0另一头插在宿主机的docker0网桥上这样同一台宿主机上的容器就可以互相访问了此时的路由表记录172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0但是对于不同的宿主机A和宿主机B来说它们的docker网络一模一样IP也是一样网络与网络之间也不通。Flannel来了之后在每个宿主机上增加了个P2P的虚拟网卡flannel0(172.17.0.0)一头对接docker0网桥一头由Flanneld服务监听。Etcd管理着整个Flannel网络的子网分配宿主机A和宿主机B分别用分到的子网172.17.1.0和172.17.2.0创建docker0网桥然后又悄悄地修改了一下docker daemon的启动参数--bip172.17.1.1/24同时添加路由表记录#宿主机A
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0
172.17.1.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0宿主机B 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0 172.17.2.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0 模拟下Flannel网络下宿主机A上的docker容器(172.17.1.10)发送数据到宿主机B上的docker容器(172.17.2.15)的过程根据源容器和目的容器的IP匹配路由规则同时匹配两个IP的路由规则是172.17.0.0/16如果是同一个宿主机上的容器访问匹配的是172.17.1.0或者172.17.2.0 数据从docker0网桥出来以后投递到flannel0网卡监听flannel0网卡的Flanneld服务收到数据后封装成数据包发送到宿主机B宿主机B上的Flanneld服务接收到数据包后解包还原成原始数据Flanneld服务发送数据到flannel0网卡根据目的容器地址匹配到路由规则172.17.2.0/24docker0 投递数据到docker0网桥进而进入到目标容器172.17.2.15。Flannel的Github上有张比较详细的原理图图中的Flanneld运行在每个宿主机上负责数据的发送、监听、封包、解包等任务。强调下Flannel的backend有UDP和VXLAN、GRE等实现默认使用UDP性能大约只有本地物理网络的一半VXLAN推荐使用性能损耗很小不过需要3.9的内核支持。详细介绍、文档、源码Flannel Github。 3.2 Calico Calico是纯三层的SDN实现它基于BPG协议和Linux的路由转发机制不依赖特殊硬件没有使用NAT或Tunnel等技术。能够方便的部署在物理服务器虚拟机如OpenStack或者容器环境下可以无缝集成像OpenStack这种IaaS云架构能够提供可控的VM、容器、裸机之间的IP通信同时它自带的基于Iptables的ACL管理组件非常灵活能够满足比较复杂的安全隔离需求。Clico网络模型的特点在Calico中的数据包并不需要进行封包和解封。Calico中的数据包只要被policy允许就可以在不同租户中的workloads间传递或直接接入互联网或从互联网中进到Calico网络中并不需要像overlay方案中数据包必须经过一些特定的节点去修改某些属性。因为是直接基于三层网络进行数据传输TroubleShooting会更加容易同时用户也可以直接用一般的工具进行操作与管理比如ping、Whireshark等无需考虑解包之类的事情。网络安全策略使用ACL定义基于iptables实现比起overlay方案中的复杂机制更直观和容易操作。Calico 的核心组件FelixCalico agent跑在每台需要运行workload的节点上主要负责配置路由及 ACLs等信息来确保endpoint的连通状态etcd分布式键值存储主要负责网络元数据一致性确保Calico网络状态的准确性BGP Client(BIRD)主要负责把Felix写入kernel的路由信息分发到当前Calico网络确保workload间的通信的有效性BGP Route Reflector(BIRD)大规模部署时使用摒弃所有节点互联的mesh模式通过一个或者多个BGP Route Reflector来完成集中式的路由分发详细介绍、文档、源码Calico Github。 3.3 DNS kube-dns负责Kubernetes集群内的域名解析解析服务通过dnsmasq实现。通过官方提供的Deployment和Service模板可以很方便地部署kube-dns服务并且可以任意伸缩POD实例来保证其高可用性。默认的kube-dns的service_ip10.96.0.10默认的域名后缀为cluster.local如果是kubeadm部署的Kubernetes集群kubelet的配置参数文件是/etc/systemd/system/kubelet.service.d/10-kubeadm.conf。DNS解析的A记录规则为my-svc.my-namespace.svc.cluster.local例如kube-dns的service的A记录为kube-dns.kube-system.svc.cluster.local。POD实例创建后其中的Container内的resolver.conf的配置如下search kube-system.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options timeout:1 rotate
options ndots:5因为添加了search domain在POD的容器内访问其他Service时可以用缩略域名访问如访问kube-dns服务kube-dns同namespace内访问kube-dns.kube-system跨namespace访问。详细介绍、文档Kube-Dns文档。 3.4 Dashboard Dashboard是官方提供的kubernetes集群的UI界面提供了一些基础的查看及简单操作随便用用还行。可以通过官方提供的YAML模板创建kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml。详细介绍、文档Kube-Dashboard文档。 原文发布时间为2017-04-26 本文作者史绍虎 本文来自云栖社区合作伙伴Dockerone.io了解相关信息可以关注Dockerone.io。 原文标题Kubernetes基础组件概述
