Namespace主要作用实现或。
● 多套环境的资源隔离：默认情况下，kubernetes集群中的所有的Pod都是可以相互访问的。但是在实际中，可能不想让两个Pod之间进行互相的访问，那此时就可以将两个Pod划分到不同的namespace下。kubernetes通过将集群内部的资源分配到不同的Namespace中，可以形成逻辑上的"组"，以方便不同的组的资源进行隔离使用和管理。
● 多租户的资源隔离：可以通过kubernetes的授权机制，将不同的namespace交给不同租户进行管理，这样就实现了多租户的资源隔离。此时还能结合kubernetes的资源配额机制，限定不同租户能占用的资源，例如CPU使用量、内存使用量等等，来实现租户可用资源的管理。
- 查看namespace
资源限制结合第一部分提到的资源配额机制(CPU使用量、内存使用量等等)，即在此处进行设置。
- 创建namespace
- 删除namespace
- 使用yaml文件进行配置
再执行创建或删除命令
总之，Namespace实际上就是一种边界，用来实现资源的隔离。
首先清楚kubernetes的逻辑关系：kubernetes本身是集群 --> 集群通过运行程序对外提供服务 --> 程序必须运行在容器中 --> 容器必须存在于Pod中 --> Kubernetes集群通过管理pod控制其中的容器 --> 进而管理其中的程序。
Pod是kubernetes集群进行管理的最小单元。Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。
kubernetes在集群启动之后，集群中的各个组件也都是以Pod方式运行的。可以通过下面命令查看：
- 创建并运行
命令格式
- 查看pod信息
events内容用来查错，其内容描述了pod内容器的操作。
- 访问pod
- 删除指定pod
发现删除之后又重新运行了一个新pod。这是pod控制器在发挥作用。查看Pod控制器：
nginx就是在kubectl run时指定的pod控制器名称。要想彻底删除pod，要删除其pog控制器：
- 通过yaml文件进行操作
然后执行其创建和删除命令：
Label是kubernetes系统中的一个重要概念。它的作用就是在资源上添加标识，用来对它们进行区分和选择。
【例如】现在有两组一堆pod，像将它们分为两组，一组负责前端，一组负责后端，对着两组进行分别的管理，比如前端的这一组同时创建或同时删除，后端同理。
提到分组可能会想到Namespace，为这两组pod设置不同的Namespace。但是不同Namespace下的pod无法进行通信，但理论上一个网站的前后端应该能正常通信，因此无法使用Namespace。
因此可以使用Label(标签)，为pod打上标签。再通过标签选择器进行选择，带有tier:front标签的pod是前端的pod，带有tier:back标签的pod是后端的pod。
因此，所谓的标签，就是一种标识选择机制。为pod添加标识，通过标识对pod进行选择和区分。
- Label的特点：
- 一个Label会以key/value键值对的形式附加到各种资源对象(如Node、Pod、Service等等)上；
- 一个资源对象可以定义任意数量的Label ，同一个Label也可以被添加到任意数量的资源对象上去；
- Label通常在资源对象定义时确定，当然也可以在对象创建后动态添加或者删除。
可以通过Label实现资源的多维度分组，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。
一些常用的Label 示例如下：
- 版本标签：“version”:“release”, “version”:“stable”…
- 环境标签：“environment”:“dev”，“environment”:“test”，“environment”:“pro”
- 架构标签：“tier”:“frontend”，“tier”:“backend”
标签定义完毕之后，还要考虑到标签的选择，这就要使用到Label Selector，即：当前有两种Label Selector：
- 基于等式的Label Selector
- 基于集合的Label Selector
name in (master, slave): 选择所有包含Label中的key="name"且value="master"或"slave"的对象；
name not in (frontend): 选择所有包含Label中的key="name"且value不等于"frontend"的对象。
- 为pod打标签
也可以给他打多个标签，接着上步执行：
- 更新Pod标签
现在想把版本号从1.0更新到2.0，如果直接做如下的修改，结果是什么？
显示version这个键已经有一个值v1.0了，提示我们要加上–overwrite(覆盖)。加上–overwrite参数试一下：
- 查看pod标签
- 筛选标签
- 删除标签
- 通过配置文件对pod进行标签操作
然后执行命令：
在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。在kubernetes中Pod控制器的种类有很多，每个控制器对应一种应用场景，此处只介绍一种：Deployment。
Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。
为了防止之前创建的资源干扰视线，在操作Deployment前删除test-ns命名空间下的所有资源：
- 创建pod
- 查看Deployment信息
查看一下标签为：run=nginx-deployment的pod：
Deployment与Pod建立联系是通过标签Label，Deployment本身包含标签选择器，进而得知自己要管理哪些pod。
- 删除Deployment
- 通过配置文件操作Deployment
然后执行命令：
上一部分创建了一个副本量为3的pod组，如想访问其中一个pod，需要知道它的ip+端口：
现在删除这个pod：发现Pod控制器有创建了一个新的pod，并且它的IP地址也发生了变化。
但我的程序若想对外提供服务，需要提供我的IP地址。假如在运行过程中pod宕机了，重建之后所对应的IP地址会发生改变，然而这对外部是不透明的，因此服务会失效。因此虽然每个Pod都会分配一个单独的Pod IP，然而却存在如下两问题：
① Pod IP 会随着Pod的重建产生变化；
② Pod IP 仅仅是集群内可见的虚拟IP，外部无法访问。
这样对于访问这个服务带来了难度。因此，kubernetes设计了Service来解决这个问题。
Service可以看作是一组同类Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。
- 创建集群内部可访问的Service
- expose：暴露操作；
- deploy deployment_name：通过Deployment控制器来寻找pod。这是因为pod组随时可能发生变化，而这些变化都是通过Deployment控制器管理的，如果Service直接寻找pod会存在问题，因此实际上是Service指定要暴露Deployment控制器管理中的哪个Pod；
- –name=service_name：指定Service名称；
- –type=service_type：指定Service类型，默认是ClusterIP；
- –port=80：指定端口号(service暴露的端口)；
- –target-port=80：指定目标端口号(对应pod的端口)；
- -n namespace_name：指定操作的命名空间。
这里产生了一个CLUSTER-IP，这就是service的IP，在Service的生命周期中，这个地址是不会变动的。可以通过这个IP访问当前service对应的pod：
- 创建集群外部也可访问的Service
上面创建的Service的type类型为ClusterIP，这个ip地址只用集群内部可访问；如果需要创建外部也可以访问的Service，需要修改type为NodePort。
发现此时出现了一对port。其中80端口是暴露给内部的，而31115端口是Node节点暴露给集群外部的端口号，此时便可通过mater节点IP:31115在外部访问到集群服务。例如在的电脑主机上通过浏览器访问下面的地址：http://192.168.12.100:31115/
- 删除service
- 通过配置文件设置service
然后执行命令：
删除service：
参考：B站大学
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/cjjbc/43705.html