暂无个人介绍
Security Context主要用于限制容器的行为,从而保障系统和其他容器的安全。这一块的能力不是 Kubernetes 或者容器 runtime 本身的能力,而是 Kubernetes 和 runtime 通过用户的配置,最后下传到内核里,再通过内核的机制让 SecurityContext 来生效。所以这里介绍的内容,会比较简单或者说比较抽象一点。 1.容器级别的Security Context:仅对指定容器生效 2.Pod级别的Security Context:对指定Pod中的所有容器生效 3.Pod Security Policies(PSP):对集群内所有Pod生效
Runtime之Class结构 runtime(内存管理) 运行时刻是指一个程序在运行(cc或者在被执行)的状态。也就是说,当你打开一个程序使它在电脑上运行的时候,那个程序就是处于运行时刻。在一些编程语言中,把某些可以重用的程序或者实例打包或者重建成为“运行库"。这些实例可以在它们运行的时候被链接或者被任何程序调用。 开发者有时候会在什么东西应该在编译的时候加载进来以及什么东西该在运行的时候使用之间做出抉择,前者有时候被称为编译时期。 一段时间以来,技术类作者都拒绝使用"运行时刻"作为一种术语,他们坚持类似于"一个程序在运行"之类的说法,用以避免需要一个专门的术语。后来,这个术语逐渐地蔓延到通
Readiness 指针用来判断这个容器是否启动完成,即 pod 的 condition 是否 ready。如果探测的一个结果是不成功,那么此时它会从 pod 上 Endpoint 上移除,也就是说从接入层上面会把前一个 pod 进行摘除,直到下一次判断成功,这个 pod 才会再次挂到相应的 endpoint 之上。
k8s对Pods之间如何进行组网通信提出了要求,k8s对集群的网络有以下要求: • 所有的Pods之间可以在不使用NAT网络地址转换的情况下相互通信 • 所有的Nodes之间可以在不使用NAT网络地址转换的情况下相互通信 • 每个Pod自己看到的自己的ip和其他Pod看到的一致
Pod实际上是容器的集合,在k8s中对运行容器的要求为:容器的主程序需要一直在前台运行,而不是后台运行。应用可以改造成前台运行的方式,例如Go语言的程序,直接运行二进制文件;java语言则运行主类;tomcat程序可以写个运行脚本。或者通过supervisor的进程管理工具,即supervisor在前台运行,应用程序由supervisor管理在后台运行。具体可参考supervisord。
PersistentVolumeClaim(简称PVC)是用户存储的请求,PVC消耗PV的资源,可以请求特定的大小和访问模式,需要指定归属于某个Namespace,在同一个Namespace的Pod才可以指定对应的PVC。 当需要不同性质的PV来满足存储需求时,可以使用StorageClass来实现。 每个 PVC 中都包含一个 spec 规格字段和一个 status 声明状态字段。
PersistentVolume(PV)用于为用户和管理员提供如何提供和消费存储的API,PV由管理员在集群中提供的存储。它就像Node一样是集群中的一种资源。PersistentVolume 也是和存储卷一样的一种插件,但其有着自己独立的生命周期。PersistentVolumeClaim (PVC)是用户对存储的请求,类似于Pod消费Node资源,PVC消费PV资源。Pod能够请求特定的资源(CPU和内存),声明请求特定的存储大小和访问模式。PV是一个系统的资源,因此没有所属的命名空间。
网络策略(Network Policy )是 Kubernetes 的一种资源。Network Policy 通过 Label 选择 Pod,并指定其他 Pod 或外界如何与这些 Pod 通信。 Pod的网络流量包含流入(Ingress)和流出(Egress)两种方向。默认情况下,所有 Pod 是非隔离的,即任何来源的网络流量都能够访问 Pod,没有任何限制。当为 Pod 定义了 Network Policy,只有 Policy 允许的流量才能访问 Pod。
Liveness 指针是存活指针,它用来判断容器是否存活、判断 pod 是否 running。如果 Liveness 指针判断容器不健康,此时会通过 kubelet 杀掉相应的 pod,并根据重启策略来判断是否重启这个容器。如果默认不配置 Liveness 指针,则默认情况下认为它这个探测默认返回是成功的。
容器之所以被称为特殊的进程,是因为容器这个进程是有边界的。上一篇博客提到容器是一种沙盒技术,即能够向集装箱一样把应用装起来,这样应用与应用之间因为存在边界而不至于互相干扰,而被装进集装箱的应用也能被方便的搬运——这就是PaaS最理想的状态。容器技术的核心功能,就是通过约束和修改进程的动态表现,从而为其人为打造“边界”。在Linux中,Cgroup技术是用来制造约束的主要手段,而Namespace技术则是修改进程视图的主要方法,即让进程看到的资源信息与实际资源信息不同,俗称“障眼法”。
用于创建容器镜像的工具称为容器镜像构建器。有时容器引擎执行此任务,也可以使用一些独立工具来构建容器镜像。
Linux 内核从版本 2.4.19 开始陆续引入了 namespace 的概念。其目的是将某个特定的全局系统资源(global system resource)通过抽象方法使得namespace 中的进程看起来拥有它们自己的隔离的全局系统资源实例(The purpose of each namespace is to wrap a particular global system resource in an abstraction that makes it appear to the processes within the namespace that they have their
标签其实就一对 key/value ,被关联到对象上,比如Pod,标签的使用我们倾向于能够标示对象的特殊特点,并且对用户而言是有意义的(就是一眼就看出了这个Pod是尼玛数据库),但是标签对内核系统是没有直接意义的。标签可以用来划分特定组的对象(比如,所有女的),标签可以在创建一个对象的时候直接给与设置,也可以在后期随时修改,每一个对象可以拥有多个标签,但是,key值必须是唯一的 "labels": { "key1" : "value1", "key2" : "value2" }
Requests是容器请求要使用的资源,Kubernetes 会保证 Pod 能使用到这么多的资源。请求的资源是调度的依据,只有当节点上的可用资源大于 Pod 请求的各种资源时,调度器才会把 Pod 调度到该节点上(如果 CPU 资源足够,内存资源不足,调度器也不会选择该节点)。 需要注意的是,调度器只关心节点上可分配的资源,以及节点上所有 Pods 请求的资源,而不关心节点资源的实际使用情况,换句话说,如果节点上的 Pods 申请的资源已经把节点上的资源用满,即使它们的使用率非常低,比如说 CPU 和内存使用率都低于 10%,调度器也不会继续调度 Pod 上去。
Limits 是 Pod 能使用的资源上限,是实际配置到内核 cgroups 里面的配置数据。对于内存来说,会直接转换成 docker run 命令行的--memory大小,最终会配置到 cgroups 对应任务的/sys/fs/cgroup/memory/……/memory.limit_in_bytes 文件中。
我们知道的是,在K8S上的网络通信包含以下几类: • 容器间的通信:同一个Pod内的多个容器间的通信,它们之间通过lo网卡进行通信。 • Pod之间的通信:通过Pod IP地址进行通信。 • Pod和Service之间的通信:Pod IP地址和Service IP进行通信,两者并不属于同一网络,实现方式是通过IPVS或iptables规则转发。 • Service和集群外部客户端的通信,实现方式:Ingress、NodePort、Loadbalance
一个永不终止的控制循环,它持续管理着集群的状态,通过apiserver获取系统的状态,并且不断尝试以达到预期状态,比如副本控制器,namespace控制器,serviceaccounts控制器。
Kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。 Kubernetes一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着(比如用户想让apache一直运行,用户不需要关心怎么去做,Kubernetes会自动去监控,然后去重启,新建,总之,让apache一直提供服务),管理员可以加载一个微型服务,让规划器来找到合适的位置,同时,Kubernetes也系统提升工具以及人性化方面,让用户能够方便的部署
Kubernetes中一个应用服务会有一个或多个实例(Pod),每个实例(Pod)的IP地址由网络插件动态随机分配(Pod重启后IP地址会改变)。为屏蔽这些后端实例的动态变化和对多实例的负载均衡,引入了Service这个资源对象
netns是在linux中提供网络虚拟化的一个项目,使用netns网络空间虚拟化可以在本地虚拟化出多个网络环境,目前netns在lxc容器中被用来为容器提供网络。 使用netns创建的网络空间独立于当前系统的网络空间,其中的网络设备以及iptables规则等都是独立的,就好像进入了另外一个网络一样。
csi 是一个标准的容器存储接口,规定了如何实现一个容器的存储接口,CSI 本身的定义是基于 gRPC 的,所以有一套样例库可以使用,这里分析一下 kuberntes 实现 csi 的方式,为了兼容 CSI kubernete 其实搞得挺绕的,目前这个 CSI 还是定制中包括后期的 Snapshot 的接口怎么设计等等还在讨论中。kubernetes CSI 主要基于几个外部组件和内部功能的一些改动。
operator是描述、部署和管理kubernetes应用的一套机制,从实现上来说,operator=CRD+webhook+controller
FlexVolume 是 Kubernetes v1.8+ 支持的一种存储插件扩展方式。类似于 CNI 插件,它需要外部插件将二进制文件放到预先配置的路径中(如 /usr/libexec/kubernetes/kubelet-plugins/volume/exec/),并需要在系统中安装好所有需要的依赖。可以想到,这是一种out-tree的扩展方式,不需要新增加一种存储插件,去更改k8s的源码。
基于角色的访问控制(Role-Based Access Control, 即”RBAC”)使用”rbac.authorization.k8s.io” API Group实现授权决策,允许管理员通过Kubernetes API动态配置策略。
首先 kubernetes 的 Job 是一个管理任务的控制器,它可以创建一个或多个 Pod 来指定 Pod 的数量,并可以监控它是否成功地运行或终止; 我们可以根据 Pod 的状态来给 Job 设置重置的方式及重试的次数; 我们还可以根据依赖关系,保证上一个任务运行完成之后再运行下一个任务; 同时还可以控制任务的并行度,根据并行度来确保 Pod 运行过程中的并行次数和总体完成大小。
GPU全称是Graphics Processing Unit,图形处理单元。它的功能最初与名字一致,是专门用于绘制图像和处理图元数据的特定芯片,后来渐渐加入了其它很多功能。
决定etcd性能的关键因素,包括: 延迟( agency):延迟是完成操作的时间。 吞吐量 (throughput):吞吐量是在某个时间期间之内完成操作的总数量。当etcd接收并发客户端请求时,通常平均延迟随着总体吞吐量增加而增加。
etcd is a distributed, consistent key-value store for shared configuration and service discovery, with a focus on being: Secure: automatic TLS with optional client cert authentication[可选的SSL客户端证书认证:支持https访问 ] Fast: benchmarked 10,000 writes/sec[单实例每秒 1000 次写操作] Reliable: properly distributed usi
DNS,英文全程"Domain Name System,中文全程:域名系统,作为将域名和IP地址相互映射的一个分布式数据库,能够使人更方便地访问互联网。DNS基于C/S架构(多数基于套接字架构的都是C/S架构),同时使用TCP和UDP的53号端口,当前,对于每一级域名长度限制是63个字符,域名总长度则不能超过253个字符。 我们都知道,IP地址是由32位的二进制数字组成。用户与因特网上某台主机通行时,显然不愿意使用难以记忆的32位的二进制主机地址。相反,大家更愿意使用比较容易记住的主机名称。这时DNS的出现就将繁琐复杂32位二进制数字解析大家易于接受的字符串形式。
DNS(域名系统)是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库,能够使人更方便地访问互联网。DNS使用TCP和UDP端口53。
通过提供通用设备插件机制和标准的设备API接口。这样设备厂商只需要实现相应的API接口,无需修改Kubelet主干代码,就可以实现支持GPU、FPGA、高性能 NIC、InfiniBand 等各种设备的扩展。该能力在Kubernetes 1.8和1.9版本处于Alpha版本,在1.10会进入Beta版本。
Deployment为pod和replica set(下一代replication controller)提供声明式更新。只需要在deployment中描述想要的目标状态,deployment controller就会帮您将pod和replicasSet的实际状态改变到您的目标状态。也可以定义一个全新的deployment来创建replicasSet或者删除已有的deployment并创建一个新的来替换。
DaemonSet:守护进程控制器 DaemonSet 也是 Kubernetes 提供的一个 default controller,它实际是做一个守护进程的控制器,它能帮我们做到以下几件事情: 首先能保证集群内的每一个节点都运行一组相同的 pod; 同时还能根据节点的状态保证新加入的节点自动创建对应的 pod; 在移除节点的时候,能删除对应的 pod; 而且它会跟踪每个 pod 的状态,当这个 pod 出现异常、Crash 掉了,会及时地去 recovery 这个状态。
CronJobs提供了在特定的时间或者间隔内处理业务逻辑的方法。一般创建一个Cronjob有两种方式,第一种是定义Java类,由Hybris生成脚本并加入数据库。第二种是直接编写groovy脚本语言并插入数据库,这种应该适合逻辑比较少的时候,比如只有一两句逻辑的时候,一般用得比较少。
主要管理容器运行所需的配置文件,环境变量,命令行参数等可变配置。用于解耦容器镜像和可变配置,从而保障工作负载(Pod)的可移植性。
CNI插件负责将网络接口插入容器网络命名空间(例如,veth对的一端),并在主机上进行任何必要的改变(例如将veth的另一端连接到网桥)。然后将IP分配给接口,并通过调用适当的IPAM插件来设置与“IP地址管理”部分一致的路由。
Ambassador是一个基于envoy proxy构建的,kubernetes原生的开源微服务网关。Ambassador在构建之初就致力于支持多个独立的团队,这些团队需要为最终用户快速发布、监控和更新服务。Ambassador还可以用来处理Kubernetes ingress和负载均衡的能力。
Operator Framework给用户提供了webhook和controller框架,包括消息通知、失败重新入队等等,开发人员仅需关心被管理应用的运维逻辑实现 主流的Operator Framework项目 -kubebuilder:https:github.com/kubernetes-sigs/kubebuilder -operator-sdk:https:github.com/operator-framework/operator-sdk -两者没有本质上的区别,都是使用的controller-tools和controller-runtime。细节上kubebuilder相应的测试、
Annotations(注解) 是 key/value 形式附加于对象的注解。不同于 Labels 用于标志和选择对象,Annotations 则是用来记录一些附加信息,用来辅助应用部署、安全策略以及调度策略等。比如 deployment 使用 annotations 来记录 rolling update 的状态。
CNI的全称是 Container Network Interface,即容器网络的 API 接口。 它是 K8s 中标准的一个调用网络实现的接口。Kubelet 通过这个标准的 API 来调用不同的网络插件以实现不同的网络配置方式。实现了这个接口的就是 CNI 插件,它实现了一系列的 CNI API 接口。常见的 CNI 插件包括 Calico、flannel、Terway、Weave Net 以及 Contiv。
在介绍微服务时,首先得先理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是微、什么是服务,微,狭义来讲就是体积小、著名的;2 pizza 团队很好的诠释了这一解释(2 pizza 团队最早是亚马逊 CEO Bezos提出来的,意思是说单个服务的设计,所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 )。 而所谓服务,一定要区别于系统,服务一个或者一组相对较小且独立的功能单元,是用户可以感知最小功能集。
Service Mesh 会完成完整的服务间调用流程,如服务发现负载均衡,最后将请求发送给目标服务。这表现为 Sidecar。 Sidecar 这个词中文翻译为边车,或者车斗,也有一个乡土气息浓重的翻译叫做边三轮。Sidecar 这个东西出现的时间挺长的,它在原有的客户端和服务端之间加多了一个代理。 多个服务调用的情况,在这个图上我们可以看到 Service Mesh 在所有的服务的下面,这一层被称之为 服务间通讯专用基础设施层。Service Mesh 会接管整个网络,把所有的请求在服务之间做转发。在这种情况下,我们会看到上面的服务不再负责传递请求的具体逻辑,只负责完成业务处理。服务间通讯的
Sentinel 是阿里巴巴开源,面向分布式付五架构的轻量级流量控制组件。在微服务中,服务的调用一般分为Consumer和Provoder,在使用过程中,我们需要对Provoder进性限流保护,来保证不会被过快的调用或者流量激增所打垮,我们可以配置QPS模式的限流,来让多余的流量直接拒绝,同时我们也可以对Provider进性授权保护(不受信任的应用直接拒绝),系统保护(Load超出阈值停止服务),热点保护(增强板的限流保护)
消息队列中间件是分布式系统中重要的组件,主要解决应用耦合、异步消息、流量削锋等问题,实现高性能、高可用、可伸缩和最终一致性架构。目前市面上比较有名的中间件有:RabbitMQ、kafka、RocketMQ Apache RocketMQ是分布式消息和流数据平台,一个这函证具备低延退、高并发、高可用、高可靠,可支撑万亿级数据洪峰的分布式消息中间件,是企业数字化转型必须的核心、是基础性软件,已服务于阿里巴巴逾十年。
Nacos是阿里巴巴推出来的一个新开源项目,这是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。 Nacos帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
Istio是Service Mesh 一种实现,提供的功能包括有: 1、服务发现、负载均衡 2、故障恢复、指标收集和监控 3、A/B测试、灰度发布 4、限流、访问控制和端到端认证
分布式配置中心还是Nacos,既可以作为服务注册和发现,也可以作为配置中心来使用。Spring Cloud Config用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,分为服务端和客户端两个部分。其中服务端又称为分布式配置中心,是一个独立的微服务应用,用来连接配置仓库并为客户端提供获取配置信息;而客户端则是微服务架构中的各个微服务应用或基础设施,它们通过指定配置中心来管理应用资源和业务相关的配置内容。服务器存储后端的默认实现使用git,也可以使用SVN仓库或者本地文件系统。
提交了问题
2020-02-09
提交了问题
2020-02-09
提交了问题
2020-02-09
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
发表了文章
2020-02-20
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
回答了问题
2020-05-18
提交了问题
2020-05-17
提交了问题
2020-05-17
提交了问题
2020-05-17
提交了问题
2020-05-17
提交了问题
2020-05-17