K8s的命名空间
K8s支持在同一物理集群中构建多个虚拟集群，这些虚拟集群称为命名空间（Namespace）。命名空间可以用于多个用户分布在多个团队或项目的环境中，将资源进行隔离，是一种在多个用户之间划分群集资源的方法。
默认情况下，同一命名空间中的对象将具有相同的访问控制策略，没有必要使用多个命名空间来分隔略有不同的资源。例如，同一软件的不同版本，可以使用标签来区分同一命名空间中的资源。我们可以通过以下命令列出集群中的当前命名空间。
Kubernetes有以下3个初始的命名空间。
（1）default：没有设置其他命名空间的对象的默认命名空间。（2）kube-system K8s：系统创建的对象的命名空间。
（3）kube-public：可供所有用户（包括未经过身份验证的用户）读取，此命名空间主要用于群集使用，以防某些资源在整个群集中可见且可公开读取。
我们可以通过kubectl设置请求的命名空间，例如，要临时设置请求的命名空间，可以使用指令“--namespace”，具体如下。
$ kubectl --namespace=
run nginx --image=nginx $ kubectl --namespace=
我们也可以设置命名空间的首选项，在上下文中为所有后续kubectl命令永久保存命名空间，指令如下。
$ kubectl config set-context S(kubectl config current-context) --namespacc=
可以通过config view来验证配置是否生效。
# Validate it
$ kubectl config view | grep namespace
当创建服务时，它会创建相应的DNS条目。此条目是表单“
不过，并非所有对象都在命名空间中，大多数K8s资源（如Pod、服务、复制控制器等）都在某些命名空间中。但是，命名空间资源本身并不在命名空间中，而且低级资源（如节点和persistentVolumes）不在任何命名空间中。
要查看哪些K8资源在命名空间中，哪些不在，可以通过如下指令。
# In a namespace
$ kubectl api-resources --namespaced=true# Not in a namespace
$ kubectl api-resources --namespaced-false8.4.5 K8s 与 Docker
K8s与Docker
通过之前几节的学习，我们应该对K8s和Docker有了大致了解，一个是容器编排系统，一个是容器化技术。顾名思义，容器编排系统是管理容器，那么是否K8s就是管理Docker的呢？答案是肯定的，但不绝对，肯定的是K8s可以提供一整套生产级别的基于Docker容器的编排、调度、资源管理、监控等功能的容器管理方式，但是K8s绝不只是针对Docker这一种容器引擎。
通过前面的内容我们可以看出，K8s通过Pod来操作容器，这样设计的目的是什么？其实最根本的目的就是提供一套更加通用操作容器的抽象，将容器与K8s隔离，无论使用什么样的容器，只要是标准的容器runtime，K8s就可以通过Pod直接对容器进行管理，通过K8s将容器进行迁移、复制、扩展等操作，而不需要关心具体的容器指令。
有人说是因为Docker的流行才造就了K8s，但其实Google早在很多年前就在使用容器技术，而且内部有了名声在外的Borg系统，后来才有了K8s这样一个功能丰富、实践性强的优秀的开源系统产生，虽说后来Docker确实是目前容器化最主流的技术，但K8s从一开始就并没有将自己设计为只针对Docker的容器管理系统。
总体来说，Docker是一种容器技术，而K8s用来管理容器，Docker可以在K8s的管理下运行，两者相辅相成，K8s+Docker的组合是现今最主流的微服务容器化部署方案。
K8s与Docker Swarm
提到Docker Swarm可能大家比较陌生，但Docker的早期使用者一定知道，因为在两年前Docker Swarm还是有一定的名气的，下面先来了解一下Docker Swarm。
Docker Swarm是Docker官方出品的Docker集群管理工具，通常简称Swarm。同样，Docker Swarm也是一个开源的容器编排平台，由于与Docker同源，因此Docker Swarm对Docker社区版和Docker企业版的支持更加良好，更加契合Docker的大部分功能，使用的指令也和Docker相同，熟悉Docker的读者可以快速上手Docker Swarm。K8s与DockerSwarm都提供了许多容器编排相同的功能，对微服务进行集群的部署和管理，同时还包括高可用、负载均衡等功能，那为什么现今Docker官方出品的Docker Swarm没有成为容器编排的主流呢？
我们先来了解一下Docker Swarm的优势。首先是速度，相比Docker Swarm，K8s在设计上更加复杂，并且为集群提供了一组统一的API，相对会减慢容器扩展和部署速度。而Docker Swarm更加简单，所以Docker Swarm可以更加快速地部署容器。
其次是简单，Docker Swarm可以自定义配置，并将其放入代码库中轻松部署。此外，Docker Swarm更加契合Docker，如属于可以跟踪容器的连续版本，检查差异或回滚到前面的版本。不过，随着K8s的用户体量越来越大，Docker也开始支持K8s作为“一等公民”，并鼓励两大平台相互迁移，旨在创造一个更健康的生态系统，但是这一优势现今并不明显。
最后，Docker团队在文档建设方面十分出色，这一点很多开源团队或企业都会忽视，无论是Docker还是Docker Swarm在文档上都做得十分出色，感兴趣的读者可以前往Docker官网进行查看。当然，Docker Swarm的落寞还与它的缺点有关，下面列举几个Docker Swarm的主要问题。
（1）依赖平台：Docker Swarm是一个基于Linux的平台。虽然Docker支持Windows和Mac OS X，但它需要在虚拟机才能在非Linux平台上运行。Windows上的Docker容器中运行的应用程序无法在Linux上运行，反之亦然。
（2）不提供存储选项：Docker Swarm不提供将容器连接到存储的无障碍方式，这是主要缺点之一，需要在主机上提供大量临时的手动配置。
（3）较弱的监控：Docker Swarm提供有关容器的基本信息，如果只是在寻找基本的监控解决方案，那么Stats命令就足够了；如果正在寻找高级监控，那么使用Docker本身实时收集有关容器的更多数据是不可行的。
因此，在生产环境中使用Docker Swarm并不像我们所设想的那样简单，但是Docker Swarm确实消除了系统中的一些复杂性，也带来了一系列问题。如果解决这些问题，使用K8s会是一个不错的选择，除去安装过程的繁琐，K8s会满足我们更多的需求。当然，通常我们在项目中都会使用云厂商来部署应用，如阿里云、AWS、Azure和GoogleCloud等，完全不需要担心安装的问题。
相比Docker Swarm，K8s提供声明性的配置方式，用户可以知道系统应该处于什么状态以避免错误。作为传统工具的源代码控制，单元测试等不能与命令式配置一起使用，但可以与声明性配置一起使用，这使得K8s具有不可变的声明性，所以扩展时更加容易。通过K8s，我们可以轻松地完成服务器级别的水平扩展，快速地添加或分离应用到新的服务器，也可以支持手动或自动的方式进行扩展，更改正在运行的容器数量。
K8s还可以检查节点和容器的运行状况，并在出现错误而导致崩溃时提供自我修复和自动替换。K8s在多个Pod之间分配负载，以便在意外流量期间快速平衡资源。在K8s中，数据可以在容器之间共享，但如果Pod被终止，就会自动删除卷。而且数据是远程存储的，如果将Pod移动到另一个节点，数据将保留，直到用户删除为止。
最后，与Docker Swarm相比，K8s本质上是支持所有标准的容器runtime，而Docker Swarm只支持Docker，不过从目前市场上Docker受欢迎程度来讲，这似乎并不能算作一个优势。毕竟连K8s也一直在争当Docker的“一等公民”，这样在容器市场上才会拥有更多的位置。
当然，从来没有一个万能工具，永远不要指望软件能够以你想要的方式工作，虽然K8s是目前的主流平台，但也不是说Docker Swarm不好，我们在做服务架构时需要更多考虑真实的项目场景，选择更加适合的技术和工具。
云商的支持
在一些小型项目中，或者有私有云的大厂项目中，企业都会搭建自己的K8s平台和Docker镜像中心来进行相关项目的容器部署和管理，但在大多数时候，我们通常会使用一些云服务商现成的服务。目前，市面上一些主流的云商都是支持容器技术和K8s服务的，使用起来十分方便，下面一起来看一下各大厂商的支持。
1. AWS（亚马逊云）
AWS是亚马逊公司所创建的云计算平台，目前在全球云计算服务市场上拥有最多的用户量，除了基础的虚拟机等云服务，AWS也推出了Amazon ECS（Elastic Container Service），这是一项高度可扩展的快速容器管理服务，可轻松运行、停止和管理Amazon EC2实例集群上的 Docker 容 器，同时也提供 Amazon ECR （ Elastic Container Registry），可以方便安全地管理和部署Docker容器映像，ECR与ECS可以集成使用，大大简化了生产工作中的开发流程。关于容器编排，亚马逊同样提供 Amazon EKS （ Elastic Container Service forKubernetes），可以让用户在AWS上轻松运行K8s，而无须关注和维护K8s本身的控制层面。
2. Google Cloud（谷歌云）
谷歌云是谷歌推出的云计算平台，谷歌自身的核心产品都是由谷歌云部署和管理的，如谷歌搜索、谷歌地图等，大名鼎鼎的YouTube也是在谷歌云上运行的。与AWS类似，谷歌云也提供了基础的镜像注册服务（Google Container Registry），不过在容器层面，谷歌并没有提供过于基础的容器服务，而是提供了基于谷歌的计算引擎专门针对Docker容器进行优化的操作系统（Container-Optimized OS），来更快速、高效、安全地运行Docker容器，最后自然是容器编排。关于K8s，谷歌云提供了GKE（Google Kubernetes Engine）来提供可靠、高效和安全的K8s集群服务。
3. Microsoft Azure（微软云）
微软云是笔者最近一个项目接触到的云厂商，是由微软公司提供的云计算服务，微软云确实做得不错，并不比AWS和Googl e Cloud差，而且关于容器技术还提供了更多丰富的功能，首先微软云提供了容器注册服务，来对容器的镜像资源进行管理，对于容器，微软云提供了ACI（Azure Container Instances）服务，相比谷歌云的操作系统更加方便，使用者无须关注容器所运行的服务器，可以直接在Azure上运行容器的实例。
关 于 容 器 编 排 ， 微 软 云 也 提 供 了 AKS （ Azure KubernetesService），完全托管了K8s，与ACI集成后，可以更加灵活地扩展应用容器，大大简化了K8s的管理和部署等操作。除了这些，微软云还提供了Web App for Containers和Azure Service Fabric等针对容器化应用的服务，可以让用户在Windows和Linux上轻松部署和运行容器化应用程序，简化微服务开发和管理。
4. 阿里云
阿里云是阿里巴巴旗下的云计算服务平台产品，其作为国产大型的云厂商之一，在对容器化技术的支持上做得同样出色，无论是中文友好还是网络快速，都是国内项目在云服务商选择时的不二之选。与微软云相似，阿里云也提供了容器镜像服务（免费），对于容器，阿里云提供了弹性容器实例ECI（Elastic Container Instance）服务，敏捷安全的Serverless容器运行服务，用户无须管理底层服务器，只需提供打包好的镜像，即可运行容器，并且仅为容器实际运行消耗的资源付费。同样，对于K8s，阿里云也提供了ACK（容器服务K8s版），提供高性能可伸缩的容器应用管理能力，支持企业级的Kubernetes容器化应用的全生命周期管理。
除了上述这些云厂商，还有IBM Cloud、腾讯云和华为云等云厂商都支持容器化和容器编排等技术，这也足以证明容器化技术在逐渐成为应用服务部署方式的主流。让我们在技术选型上可以更加大胆放心地选择容器化技术，同时也为微服务架构下服务运行和部署打通了新的道路。
本文给大家讲解的内容是K8s的命名空间；
- 下篇文章给大家讲解的是持续集成、部署与交付；
- 觉得文章不错的朋友可以转发此文关注小编；
- 感谢大家的支持！