namespace
namespace 是k8s里面的命名空间,可以去资源起到隔离的效果
Namespace是kubernetes系统中的一种非常重要资源,它的主要作用是用来
实现多套环境的资源隔离或者多租户的资源隔离。
默认情况下,kubernetes集群中的所有的Pod都是可以相互访问的。但是在实际中,
可能不想让两个Pod之间进行互相的访问,那此时就可以将两个Pod划分到不同的namespace下。
kubernetes通过将集群内部的资源分配到不同的Namespace中,可以形成逻辑上的"组",
以方便不同的组的资源进行隔离使用和管理。
可以通过kubernetes的授权机制,将不同的namespace交给不同租户进行管理,
这样就实现了多租户的资源隔离。此时还能结合kubernetes的资源配额机制,限定不同租户能占用的资源
例如CPU使用量、内存使用量等等,来实现租户可用资源的管理
默认ns
k8s默认的ns
kubectl get ns
获取yaml及其状态
kubectl get ns default -o yaml
kubectl describe ns default
# 注意此处的Status : Active 表示为正在使用
# 这里的finalizers: 删除Pod的时候需要注意以下,如果删除不掉可能是这个问题
label
Label是kubernetes系统中的一个重要概念。它的作用就是在资源上
添加标识,用来对它们进行区分和选择。
Label的特点:
一个Label会以key/value键值对的形式附加到各种对象上,
如Node、Pod、Service等等
一个资源对象可以定义任意数量的Label ,同一个Label也可以被添加到任意
数量的资源对象上去
Label通常在资源对象定义时确定,当然也可以在对象创建后动态添加或者删除
可以通过Label实现资源的多维度分组,以便灵活、方便地进行资源分配、调度、
配置、部署等管理工作。
一些常用的Label 示例如下:
版本标签:"version":"release", "version":"stable"…
环境标签:"environment":"dev","environment":"test","environment":"prod"
架构标签:"tier":"frontend","tier":"backend"
标签定义完毕之后,还要考虑到标签的选择,这就要使用到Label Selector,即:
• Label用于给某个资源对象定义标识
• Label Selector用于查询和筛选拥有某些标签的资源对象
当前有两种Label Selector:
基于等式的Label Selector
name = slave: 选择所有包含Label中key="name"且value="slave"的对象
env != production: 选择所有包括Label中的key="env"且value
不等于"production"的对象
基于集合的Label Selector
name in (master, slave): 选择所有包含Label中的key="name"
且value="master"或"slave"的对象
name not in (frontend): 选择所有包含Label中的key="name"且value
不等于"frontend"的对象
标签的选择条件可以使用多个,此时将多个Label Selector进行组合,
使用逗号","进行分隔即可。例如:
• name=slave,env!=production
• name not in (frontend),env!=production
label 操作
kubectl label pod nginx version=1.0
pod/nginx labeled
# 为pod资源更新标签
kubectl label pod nginx version=2.0 --overwrite
pod/nginx labeled
# 查看标签
kubectl get pod nginx --show-labels
# 筛选标签
kubectl get pod -l version=2.0 --show-labels
kubectl get pod -l version!=2.0 --show-labels
No resources found in dev namespace.
#删除标签
kubectl label pod nginx-pod version-
pod/nginx-pod labeled
rs[现在用的很少了]
基础理念
# 作用
ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定
集合。 因此,它通常用来保证给定数量的、完全相同的 Pod 的可用性。
# 工作原理
ReplicaSet 是通过一组字段来定义的,包括一个用来识别可获得的
Pod 的集合的选择算符、一个用来标明应该维护的副本个数的数值、
一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板等等。
每个 ReplicaSet 都通过根据需要创建和删除 Pod 以使得副本个
数达到期望值,进而实现其存在价值。
当 ReplicaSet 需要创建新的 Pod 时,会使用所提供的 Pod 模板。
ReplicaSet 通过 Pod 上的 metadata.ownerReferences 字段连接到附属 Pod,
该字段给出当前对象的属主资源。 ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了
属主 ReplicaSet 的标识信息。正是通过这一连接,ReplicaSet 知道它所维护的 Pod 集合的状态,
并据此计划其操作行为。
ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有
OwnerReference 或者其 OwnerReference 不是一个控制器,
且其匹配到某 ReplicaSet 的选择算符,则该 Pod 立即被此 ReplicaSet 获得
使用场景
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
然而,Deployment 是一个更高级的概念,
它管理 ReplicaSet,并向 Pod 提供声明式的更新以及许多其他有用的功能。
因此,我们建议使用 Deployment 而不是直接使用 ReplicaSet,
除非你需要自定义更新业务流程或根本不需要更新。
这实际上意味着,你可能永远不需要操作 ReplicaSet 对象:
而是使用 Deployment,并在 spec 部分定义你的应用。
示例:
vim frontend.yaml
---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# 按你的实际情况修改副本数
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: registry.cn-hangzhou.aliyuncs.com/ywflyfish/gb-frontend:v3
---
kubectl create -f frontend.yaml
kubectl get rs
可以查看 ReplicaSet 的状态:
kubectl describe rs/frontend
可以查看pod的yaml
kubectl get pod frontend-g54fz -o yaml
输出将类似这样,frontend ReplicaSet 的信息被设置在 metadata 的 ownerReferences 字段中
rc
作用
ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。
换句话说,ReplicationController确保一个 Pod 或一组同类的 Pod 总是可用的。
工作原理
当 Pod 数量过多时,ReplicationController 会终止多余的 Pod。
当 Pod 数量太少时,ReplicationController 将会启动新的 Pod。
与手动创建的 Pod 不同,由 ReplicationController 创建的 Pod 在失败、
被删除或被终止时会被自动替换。
例如,在中断性维护(如内核升级)之后,你的 Pod 会在节点上重新创建。
因此,即使你的应用程序只需要一个 Pod,你也应该使用 ReplicationController 创建 Pod
ReplicationController 类似于进程管理器,但是 ReplicationController
不是监控单个节点上的单个进程,而是监控跨多个节点的多个 Pod。
在讨论中,ReplicationController 通常缩写为 "rc",并作为 kubectl 命令的快捷方式。
一个简单的示例是创建一个 ReplicationController 对象来可靠地无限期地运行 Pod 的一个实例
更复杂的用例是运行一个多副本服务(如 web 服务器)的若干相同副本。
实例:
vim nginx.yaml
---
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
kubectl apply -f nginx.yaml
watch kubectl get pod
kubectl get rc
kubectl describe replicationcontrollers/nginx
kubectl describe pod nginx-gk6bz