Kubernetes中是有很多积木(Building Blocks),比如object model,pod,rs,deployment,namespace之类,这些都是Kubernetes中很重要的东西,学习Kubernetes,这些基础必须要掌握理解。
Kubernetes集群可以通过这个对象模型来表现出不同的持久化的整体,比如:
对于每个对象,我们用spec这个field声明我们期望的状态,Kubernetes会通过status这个field记录对象实际的状态并加以管理。随后,Kubernetes的controller manager会想办法让这个对象实际的状态和我们声明期望的状态相同。 我们一般用yaml格式文件来声明创建一个对象。
在创建一个对象时,我们需要把spec这个field提供给API Server,这个field会描述我们期望的状态以及一些基础的信息,比如名称。
创建对象的API请求必须有spec这个field以及其它详细信息,并且需要是JSON的格式。当我们用yaml格式提供一个对象的声明后,kubectl会把这个声明转换成JSON格式,然后传给API Server。
apiVersion指定了我们调用的api的endpoint;
通过kind field,我们指定了我们要创建的对象的类型;
通过metadata,我们给对象附加上了最基本的信息,比如名字;
你可能发现这里面有两个spec的field(spec和spec.template.spec),通过 spec,我们定义了我们对deployment的期望状态,在我们的例子中,我们想要确认,在任何时候,都有至少3个pod在运行。我们再在spec.template.spec里面定义我们要运行的每个pod都应该是什么状态,所以这就是为啥这里会有两个spec的原因。
一旦这个对象被创建了,kubernetes会直接给对象添加一个status的field,如下: 为什么先介绍Pod呢,因为Pod是Kubernetes中最小的一个对象,你要运行的应用程序(web app等)都要被包含在Pod中才能运行,其中一个Pod是一个或者多个容器的逻辑上的集合,通俗来讲,应用被制作成image镜像,镜像要运行在容器中,比如Docker容器,Pod中可以包涵多个运行的容器,所以在Kubernetes上没有Pod,应用程序就没有家。
在Pod中的容器拥有以下的特性:
Labels都是由键值对表示。
第一种:Equality-Based Selectors顾名思义,这种selector通过 == 或者 != 来进行选择,比如我们选择一个 env==dev 的对象,就会找出所有有env label,并且值为dev的。
第二种:Set-Based Selectors这种selector支持通过一系列的值来进行过滤,比如通过in, notin和exist。举例:env in (dev, qa) 效率瞬间提高呢,在管理Pod对象上,还有其他高效方法吗? 当产品促销,业务处于高峰或低峰时,我们经常需要扩容或缩容,为了实现自动化,Kubernetes增加相应处理对象。
像早期版本中的 ReplicationController,(RC)是master node上Controller Manager的一部分,主要作用是保证每个pod的replica都达到了预期值。不然的话会通过杀死或者新建pod的办法来达到。不过现在已经被ReplicaSet(RS)取代了。
Replica Set 是下一代的Replication Controller,好处在于同时支持equality 和 set based selector(rc只支持equality-based)。目前这是唯一的区别。
ReplicaSets可以独立使用,但它主要被 Deployments用作pod 机制的创建、删除和更新。当使用Deployment时,你不必担心创建pod的ReplicaSets,因为可以通过Deployment实现管理ReplicaSets。 Deployment提供了对于pod和rs的陈述性更新。DeploymentController是master node上Controller Manager的一部分,作用和Controller manager别的一样——确保当前的状态和期望的状态相同。
在下面这个例子中,我们的Deployment创建了一个 rs A,然后rs A又创建了3个pod,并且在每个pod中,都有一个跑了nginx:1.7.9镜像的容器。 接下来,在下一个Deployment中,我们修改了pod的template,把nginx从1.7.9升级到了1.9.1。因为我们升级了期望的状态,所以Deployment会创建一个新的RS B,这个过程被称为Deployment rollout: 当RS B创建完毕的时候,Deployment开始指向它: 在RS之上,Deployment提供了很多特性比如recording,通过这个特性,如果说更新出错,或者更新后的应用出了bug,我们可以rollback到原先的状态。 试想下如果我们有许多个用户,我们想把这些用户组织到不同的team或者project,该怎么办?
这时我们可以通过Kubernetes中的Namespace,它能把kubernetes集群分成好多个小集群。所有在Namespace中创建的resources/objects都是唯一的,不会跨命名空间,这样是不是很方便呢。
一般来说,Kubernetes会有两个默认Namespace:kube-system和default。kube-system一般会用来放一些Kubernetes系统的组件,default会用来放一些属于其它Namespace的对象。我们默认情况下是会连接到default命名空间。kube-public是一个特殊的namespace,可以被所有的用户读,一般用于特殊情况比如初始化一个集群。
我们可以通过使用资源配额(Resource Quotas)来限制每个Namespace的资源。
今天我们介绍了Kubernetes对象模型,以及pod labels Deployment这几个主要对象再Kubernetes中的用途、使用场景,后续咱们学习更多内容。
3月23日开始上课,点击阅读原文链接即可报名。
我们是在哪个node上运行哪个容器化的应用程序?
应用程序资源消耗
应用程序不同的策略
对于每个对象,我们用spec这个field声明我们期望的状态,Kubernetes会通过status这个field记录对象实际的状态并加以管理。随后,Kubernetes的controller manager会想办法让这个对象实际的状态和我们声明期望的状态相同。 我们一般用yaml格式文件来声明创建一个对象。
在创建一个对象时,我们需要把spec这个field提供给API Server,这个field会描述我们期望的状态以及一些基础的信息,比如名称。
创建对象的API请求必须有spec这个field以及其它详细信息,并且需要是JSON的格式。当我们用yaml格式提供一个对象的声明后,kubectl会把这个声明转换成JSON格式,然后传给API Server。
piVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
apiVersion指定了我们调用的api的endpoint;
通过kind field,我们指定了我们要创建的对象的类型;
通过metadata,我们给对象附加上了最基本的信息,比如名字;
你可能发现这里面有两个spec的field(spec和spec.template.spec),通过 spec,我们定义了我们对deployment的期望状态,在我们的例子中,我们想要确认,在任何时候,都有至少3个pod在运行。我们再在spec.template.spec里面定义我们要运行的每个pod都应该是什么状态,所以这就是为啥这里会有两个spec的原因。
一旦这个对象被创建了,kubernetes会直接给对象添加一个status的field,如下: 为什么先介绍Pod呢,因为Pod是Kubernetes中最小的一个对象,你要运行的应用程序(web app等)都要被包含在Pod中才能运行,其中一个Pod是一个或者多个容器的逻辑上的集合,通俗来讲,应用被制作成image镜像,镜像要运行在容器中,比如Docker容器,Pod中可以包涵多个运行的容器,所以在Kubernetes上没有Pod,应用程序就没有家。
在Pod中的容器拥有以下的特性:
在同一个host上一起进行调度
共享同一个network namespace
挂载同样的external storage(volumes)
Labels都是由键值对表示。
"labels": {
"key1" : "value1",
"key2" : "value2"
}
第一种:Equality-Based Selectors顾名思义,这种selector通过 == 或者 != 来进行选择,比如我们选择一个 env==dev 的对象,就会找出所有有env label,并且值为dev的。
第二种:Set-Based Selectors这种selector支持通过一系列的值来进行过滤,比如通过in, notin和exist。举例:env in (dev, qa) 效率瞬间提高呢,在管理Pod对象上,还有其他高效方法吗? 当产品促销,业务处于高峰或低峰时,我们经常需要扩容或缩容,为了实现自动化,Kubernetes增加相应处理对象。
像早期版本中的 ReplicationController,(RC)是master node上Controller Manager的一部分,主要作用是保证每个pod的replica都达到了预期值。不然的话会通过杀死或者新建pod的办法来达到。不过现在已经被ReplicaSet(RS)取代了。
Replica Set 是下一代的Replication Controller,好处在于同时支持equality 和 set based selector(rc只支持equality-based)。目前这是唯一的区别。
ReplicaSets可以独立使用,但它主要被 Deployments用作pod 机制的创建、删除和更新。当使用Deployment时,你不必担心创建pod的ReplicaSets,因为可以通过Deployment实现管理ReplicaSets。 Deployment提供了对于pod和rs的陈述性更新。DeploymentController是master node上Controller Manager的一部分,作用和Controller manager别的一样——确保当前的状态和期望的状态相同。
在下面这个例子中,我们的Deployment创建了一个 rs A,然后rs A又创建了3个pod,并且在每个pod中,都有一个跑了nginx:1.7.9镜像的容器。 接下来,在下一个Deployment中,我们修改了pod的template,把nginx从1.7.9升级到了1.9.1。因为我们升级了期望的状态,所以Deployment会创建一个新的RS B,这个过程被称为Deployment rollout: 当RS B创建完毕的时候,Deployment开始指向它: 在RS之上,Deployment提供了很多特性比如recording,通过这个特性,如果说更新出错,或者更新后的应用出了bug,我们可以rollback到原先的状态。 试想下如果我们有许多个用户,我们想把这些用户组织到不同的team或者project,该怎么办?
这时我们可以通过Kubernetes中的Namespace,它能把kubernetes集群分成好多个小集群。所有在Namespace中创建的resources/objects都是唯一的,不会跨命名空间,这样是不是很方便呢。
一般来说,Kubernetes会有两个默认Namespace:kube-system和default。kube-system一般会用来放一些Kubernetes系统的组件,default会用来放一些属于其它Namespace的对象。我们默认情况下是会连接到default命名空间。kube-public是一个特殊的namespace,可以被所有的用户读,一般用于特殊情况比如初始化一个集群。
我们可以通过使用资源配额(Resource Quotas)来限制每个Namespace的资源。
今天我们介绍了Kubernetes对象模型,以及pod labels Deployment这几个主要对象再Kubernetes中的用途、使用场景,后续咱们学习更多内容。
Kubernetes 实战培训
本次培训内容包括:Docker容器的原理与基本操作;容器网络与存储解析;Kubernetes的架构与设计理念详解;Kubernetes的资源对象使用说明;Kubernetes 中的开放接口CRI、CNI、CSI解析;Kubernetes监控、网络、日志管理;容器应用的开发流程详解等,点击识别下方二维码加微信好友了解 具体培训内容。
3月23日开始上课,点击阅读原文链接即可报名。