持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第18天，点击查看活动详情
Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。 这些虚拟集群被称为命名空间。
命名空间 namespace 是 k8s 集群级别的资源，可以给不同的用户、租户、环境或项目创建对应的命名空间，例如，可以为 test、devlopment、production 环境分别创建各自的命名空间。
命名空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑命名空间。
大多数的Kubernetes中的集群默认会有一个叫default的namespace，实际上，应该是3个命名空间：
default：你的service和应用pod默认被创建于此。
kube-system：kubernetes系统组件使用。
kube-public：公共资源使用。但实际上现在并不常用。
namespacs 使用案例分享
#创建一个 test 命名空间
[root@k8smaster ~]# kubectl create ns test
#删除命名空间
[root@k8smaster ~]# kubectl delete ns test
#切换命名空间
[root@k8smaster ~]# kubectl config set-context --current --namespace=kube-system
[root@k8smaster ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
coredns-7ff77c879f-272f4 1/1 Running 3 12d
coredns-7ff77c879f-flkxx 1/1 Running 3 12d
#切换命名空间后，kubectl get pods 如果不指定-n，查看的就是 kube-system 命名空间的资源了。
#查看哪些资源属于命名空间级别的 在创建资源的时候没有指定命名空间就会在默认的命名空间 pod是命名空间级别的
[root@k8smaster ~]# kubectl api-resources --namespaced=true
namespace 资源限额
namespace 是命名空间，里面有很多资源，那么我们可以对命名空间资源做个限制，防止该命名空间部署的资源超过限制。
如何对 namespace 资源做限额呢？
[root@k8smaster ~]# mkdir pp
[root@k8smaster ~]# cd pp
[root@k8smaster ~]# vim namespace-pp.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-cpu-quota
namespace: test
spec:
hard:
requests.cpu: "2"
requests.memory: 2Gi
limits.cpu: "4"
limits.memory: 4Gi
创建的 ResourceQuota 对象将在 test 名字空间中添加以下限制： 每个容器必须设置内存请求（memory request），内存限额（memory limit），cpu 请求（cpu request）和 cpu 限额（cpu limit）。 所有容器的内存请求总额不得超过 2 GiB。 所有容器的内存限额总额不得超过 4 GiB。 所有容器的 CPU 请求总额不得超过 2 CPU。 所有容器的 CPU 限额总额不得超过 4 CPU。
[root@k8smaster pp]# kubectl apply -f namespace-pp.yaml
resourcequota/mem-cpu-quota created
[root@k8smaster pp]# kubectl describe ns test
Name: test
Labels: <none>
Annotations: <none>
Status: Active
Resource Quotas
Name: mem-cpu-quota
Resource Used Hard
-------- --- ---
limits.cpu 0 4
limits.memory 0 4Gi
requests.cpu 0 2
requests.memory 0 2Gi
No LimitRange resource.
#创建 pod 时候必须设置资源限额，否则创建失败，如下：
[root@k8smaster pp]# vim pod-test.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-test
namespace: test
labels:
app: tomcat-pod-test
spec:
containers:
- name: tomcat-test
ports:
- containerPort: 8080
image: tomcat
imagePullPolicy: IfNotPresent
resources:
requests:
memory: "100Mi"
cpu: "500m"
limits:
memory: "2Gi"
cpu: "2"
[root@k8smaster pp]# kubectl get pods -n test
NAME READY STATUS RESTARTS AGE
pod-test 1/1 Running 0 8s
[root@k8smaster pp]# kubectl describe pods pod-test -n test
什么是标签？
标签其实就一对 key/value ，被关联到对象上，比如 Pod，标签的使用我们倾向于能够表示对象的特殊特点，就是一眼就看出了这个 Pod 是干什么的，标签可以用来划分特定的对象（比如版本，服务类型等），标签可以在创建一个对象的时候直接定义，也可以在后期随时修改，每一个对象可以拥有多个标签，但是，key 值必须是唯一的。创建标签之后也可以方便我们对资源进行分组管理。如果对 pod 打标签，之后就可以使用标签来查看、删除指定的 pod。 在 k8s 中，大部分资源都可以打标签。
给 pod 资源打标签
#对已经存在的 pod 打标签 表示这个pod版本是v1
[root@k8smaster pp]# kubectl label pods pod-first release=v1
#查看标签是否打成功 查看指定的pod
[root@k8smaster pp]# kubectl get pods pod-first --show-labels
显示如下，说明标签达成功了
NAME READY STATUS RESTARTS AGE LABELS
pod-first 1/1 Running 0 139m release=v1
查看资源标签
#查看默认名称空间下所有 pod 资源的标签
[root@k8smaster pp]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-f89759699-tc62k 1/1 Running 2 4d20h app=nginx,pod-template-hash=f89759699
nginx-test-84b997bfc5-6vccl 1/1 Running 0 16h app=nginx,pod-template-hash=84b997bfc5
nginx-test-84b997bfc5-z6lqm 1/1 Running 0 16h app=nginx,pod-template-hash=84b997bfc5
pod-first 1/1 Running 0 140m release=v1
#查看默认名称空间下指定 pod 具有的所有标签
[root@k8smaster pp]# kubectl get pods pod-first --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-first 1/1 Running 0 141m release=v1
#列出默认名称空间下标签 key 是 release 的 pod，不显示标签
[root@k8smaster pp]# kubectl get pods -l release
NAME READY STATUS RESTARTS AGE
pod-first 1/1 Running 0 141m
#列出默认名称空间下标签 key 是 release、值是 v1 的 pod，不显示标签
[root@k8smaster pp]# kubectl get pods -l release=v1
NAME READY STATUS RESTARTS AGE
pod-first 1/1 Running 0 142m
#列出默认名称空间下标签 key 是 release 的所有 pod，并打印对应的标签值 key作为一列 value在这一列显示出来。
[root@k8smaster pp]# kubectl get pods -L release
NAME READY STATUS RESTARTS AGE RELEASE
nginx-f89759699-tc62k 1/1 Running 2 4d20h
nginx-test-84b997bfc5-6vccl 1/1 Running 0 16h
nginx-test-84b997bfc5-z6lqm 1/1 Running 0 16h
pod-first 1/1 Running 0 142m v1
#查看所有名称空间下的所有 pod 的标签
[root@k8smaster pp]# kubectl get pods --all-namespaces --show-labels
#把具有release标签的pod显示出来并且显示对应的key和value
[root@k8smaster pp]# kubectl get pods -l release=v1 -L release
NAME READY STATUS RESTARTS AGE RELEASE
pod-first 1/1 Running 0 145m v1
node 节点选择器
我们在创建 pod 资源的时候，pod 会根据 schduler 进行调度，那么默认会调度到随机的一个工作节点，如果我们想要 pod 调度到指定节点或者调度到一些具有相同特点的 node 节点，怎么办呢？ 可以使用 pod 中的 nodeName 或者 nodeSelector 字段指定要调度到的 node 节点
1、nodeName
指定 pod 节点运行在哪个具体 node 上，不经过调度器，不受Taint的限制。
#node1和2用docker下载tomcat busybox
[root@k8smaster node]# vim pod-node.yml
apiVersion: v1
kind: Pod
metadata:
name: demo-pod
namespace: default
labels:
app: myapp
env: dev
spec:
nodeName: k8snode
containers:
- name: tomcat-pod-java
ports:
- containerPort: 8080
image: tomcat
imagePullPolicy: IfNotPresent
- name: busybox
image: busybox:latest
command:
- "/bin/sh"
- "-c"
- "sleep 3600"
[root@k8smaster node]# kubectl apply -f pod-node.yml
pod/demo-pod created
#查看 pod 调度到哪个节点
[root@k8smaster node]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
demo-pod 2/2 Running 0 35s 10.244.2.18 k8snode <none>
2、nodeSelector
指定 pod 调度到具有哪些标签的 node 节点上
#给 node 节点打标签，打个具有 disk=ceph 的标签
[root@k8smaster node]# kubectl describe nodes k8snode2 查看node属性
[root@k8smaster node]# kubectl label nodes k8snode2 disk=ceph
node/k8snode2 labeled
#然后再查看去label哪里就能看到了
#定义 pod 的时候指定要调度到具有 disk=ceph 标签的 node 上
[root@k8smaster node]# vim pod-1.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo-pod-1
namespace: default
labels:
app: myapp
env: dev
spec:
nodeSelector:
disk: ceph
containers:
- name: tomcat-pod-java
ports:
- containerPort: 8080
image: tomcat
imagePullPolicy: IfNotPresent
[root@k8smaster node]# kubectl apply -f pod-1.yaml
pod/demo-pod-1 created
#查看 pod 调度到哪个节点
[root@k8smaster node]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE demo-pod-1 1/1 Running 0 8s 10.244.1.19 k8snode2 <none>
#如果标签和nodename都有的话 优先选择好的node。
污点和污点容忍
污点容忍
污点容忍就是某个节点可能被调度，也可能不被调度
node 节点亲和性
node 节点亲和性调度：nodeAffinity 用帮助文档查看亲和性字段下面的东西
[root@k8smaster node]# kubectl explain pods.spec.affinity
例 1：使用 requiredDuringSchedulingIgnoredDuringExecution 硬亲和性
#node1 node2都拉nginx
[root@k8smaster node]# vim pod-nodeaffinity-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-node-affinity-demo
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: zone
operator: In
values:
- foo
- bar
节点亲和性的功能在较低版本的k8s是不支持的。 affinity：亲和性，下面的node是node亲和性，然后requ硬亲和性，nodeselect是对象列表，我们用-链接，然后match也是对象列表，同上，key是zone，然后等值关系，值是foo和bar。
Affinity 翻译成中文是“亲和性”，它对应的是 Anti-Affinity，可以翻译成“互斥”。这两个词比较形象，可以把 pod 选择 node 的过程类比成磁铁的吸引和互斥，不同的是除了简单的正负极之外，pod 和 node 的吸引和互斥是可以灵活配置的。
Affinity的优点：
匹配有更多的逻辑组合，不只是字符串的完全相等 调度分成软策略(soft)和硬策略(hard)，在软策略下，如果没有满足调度条件的节点，pod会忽略这条规则，继续完成调度。
这里举个例子，比如： requiredDuringSchedulingIgnoredDuringExecution 表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，pod也会继续运行。
软策略和硬策略的区分是有用处的，硬策略适用于 pod 必须运行在某种节点，否则会出现问题的情况，比如集群中节点的架构不同，而运行的服务必须依赖某种架构提供的功能；软策略不同，它适用于满不满足条件都能工作，但是满足条件更好的情况，比如服务最好运行在某个区域，减少网络传输等。这种区分是用户的具体需求决定的，并没有绝对的技术依赖。
这个yaml意思是：我们检查当前节点中有任意一个节点拥有 zone 标签的值是 foo 或者 bar，就可以把 pod 调度到这个 node 节点的 foo 或者 bar 标签上的节点上,现在找不到，因为没打标签！
[root@k8smaster node]# kubectl apply -f pod-nodeaffinity-demo.yaml
pod/pod-node-affinity-demo created
[root@k8smaster node]# kubectl get pods -o wide | grep pod-node
pod-node-affinity-demo 0/1 Pending 0 11s <none> <none> <none>
# status 的状态是 pending，上面说明没有完成调度，因为没有一个拥有 zone 的标签的值是 foo 或者 bar，而且使用的是硬亲和性，必须满足条件才能完成调度。
[root@k8smaster node]# kubectl label nodes k8snode zone=foo
node/k8snode labeled
#给这个节点打上标签 zone=foo，在查看
[root@k8smaster node]# kubectl get pods -o wide 显示running了
pod-node-affinity-demo 1/1 Running 0 4m4s 10.244.2.19 k8snode <none>
例 2：使用 preferredDuringSchedulingIgnoredDuringExecution 软亲和性
[root@k8smaster node]# vim pod-nodeaffinity-demo-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-node-affinity-demo-2
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: nginx
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: zone1
operator: In
values:
- foo1
- bar1
weight: 60
#用的还是node亲和性，然后是软亲和性，如果所有的工作节点都没有这个标签，pod还是会调度
[root@k8smaster node]# kubectl apply -f pod-nodeaffinity-demo-2.yaml
pod/pod-node-affinity-demo-2 created
[root@k8smaster node]# kubectl get pods -o wide |grep demo-2
pod-node-affinity-demo-2 1/1 Running 0 29s 10.244.1.20 k8snode2 <none>
#上面说明软亲和性是可以运行这个 pod 的，尽管没有运行这个 pod 的节点定义的 zone1 标签
Node 节点亲和性针对的是 pod 和 node 的关系，Pod 调度到 node 节点的时候匹配的条件
写在最后
创作不易，如果觉得内容对你有帮助，麻烦给个三连关注支持一下我！如果有错误，请在评论区指出，我会及时更改！ 目前正在更新的系列：从零开始学k8s 感谢各位的观看，文章掺杂个人理解，如有错误请联系我指出~
