一、Namespace

Kubernetes集群中可以拥有多个命名空间，它们在逻辑上彼此隔离，各命名空间下资源都不相同。
大多数的Kubernetes中的集群默认会有一个叫default的namespace。实际上，应该是3个：
• default：用户的service和app默认被创建于此空间。
• kube-system：kubernetes系统组件使用空间。
• kube-public：公共资源使用，但实际上现在并不常用。

创建Namespace

Kubernetes集群中一般有两种方式创建Namespace：

1. Kubectl创建Namespace：通过kubectl工具直接调用kube-apiserver去创建Namespace，创建速度最快。
   
2. Yaml文件创建Namespace：通过编写Yaml文件编辑kubernetest API调用配置，通过kubectl工 具读取配置传递到kube-apiserver中创建namespace，创建方式虽繁琐，可移植性强。
   创建文件 任意名称.yaml 并编辑内容如下图:
   

创建命令：kubectl apply -f 文件名.yaml

查看删除Namespace

Kubectl查看Namespace：kubectl get ns(#注：ns为namespace缩写，也可写入全称)
kubectl删除Namespace: kubectl delete ns 命名空间

二、深度理解Pod及其设计模式

Pod概念简述

Pod 是一组（一个或多个）容器； 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， 这些容器是相对紧密的耦合在一起的。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的应用。同时Pod是 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod设计理念

Pod 被设计成支持形成内聚服务单元的多个协作过程（形式为容器）。 Pod 中的容器被自动安排到 集群中的同一物理机或虚拟机上，并可以一起进行调度。 容器之间可以共享资源和依赖、彼此通 信、协调何时以及何种方式终止自身。

三、主要控制器资源

控制器简介

Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为。
Kuberentes常用控制器如下：
• ReplicationController（副本控制器）
• Deployment（无状态应用控制器）
• DaemonSet（守护进程控制器）
• StateFulSet（有状态应用控制器）
• Job/CronJob（任务控制器）

Replication Controller

Replication controller简称RC，是kubernetes系统中的核心概念之一，简单来说，它其实定义了一个期望的场景，即声明某种pod的副本数量在任意时刻都复合某个预期值，所以RC的定义包含以下部分：
• pod期待的副本数量
• 用于筛选目标pod的Label Selector
• 当pod的副本数量小于期望值时，用于创建新的pod的pod模板（template）

Deployment Controller

Deployment是kubernetes在1.2版本中引入的概念，用于更好的解决Pod的编排问题，Deployment在内部使用了ReplicaSet来实现目的，我们可以把Deployment理解为ReplicaSet的一次升级，两者的相似度超过90%。
Deployment的使用场景有以下几个：
• 创建一个Deployment对象来生成对应的ReplicaSet并完成Pod副本的创建
• 检查Deployment的状态来看部署动作是否完成（Pod副本数量是否达到了预期的值）
• 更新Deployment以创建新的Pod（比如镜像升级）
• 如果当前Deployment不稳定，可以回滚到一个早先的Deployment版本
• 暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后在恢复Deployment，进
行新的发布
• 扩展Deployment以应对高负载
• 查看Deployment的状态，以此作为发布是否成功的纸币哦
• 清理不在需要的旧版本ReplicaSet

StatefulSet

在kubernetes系统中，Pod的管理对象RC，Deployment，DaemonSet和Job都面向无状态的服务，但 现实中有很多服务时有状态的，比如一些集群服务，例如mysql集群。
集群一般都会有这四个特点：
• 每个节点都是有固定的身份ID，集群中的成员可以相互发现并通信
• 集群的规模是比较固定的，集群规模不能随意变动
• 集群中的每个节点都是有状态的，通常会持久化数据到永久存储中
• 如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损

DemonSet

DaemonSet 守护进程控制器，确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除DaemonSet 将会删除它创建的所有 Pod
使用DaemonSet 的一些典型用法：
• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph
• 在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash
• 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、 New Relic 代理，或 Ganglia gmond

Job/Cronjob

Job：Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束
CronJob：Cron Job 管理基于时间的 Job，即在给定时间点只运行一次，周期性地在给定时间点运行
典型的用法如下所示：
• 在给定的时间点调度 Job 运行
• 创建周期性运行的 Job，例如：数据库备份、发送邮件

四、Kubernetes Service 及负载均衡

Kubernetes Service简介

每个 Pod 都会获取它自己的 IP 地址，通常这些IP是随机的，同时Pod重启IP地址也会改变。Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 ，这一组Pod 能够被 Service 访问到。
对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 Endpoints API，只要 Service 中的一组 Pod 发生变更，应用程序IP地址就会被更新。
Service 暴露服务类型一般有如下几种：
• ClusterIP：通过集群的内部 IP 暴露服务，服务只能够在集群内部可以访问，这也是默认的ServiceType。
• NodePort：通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 ，可以从集群的外部访问一个NodePort 服务。
• LoadBalancer：使用第三方负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到NodePort 服务和 ClusterIP 服务。

Kubernetes Service简介

KubeProxy：Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式。
iptable代理模式：kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会安装 iptables 规则，从而捕获到该 Service 的 clusterIP（虚拟 IP） 和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某个上面。对于每个Endpoints 对象，它也会安装 iptables 规则，这个规则会选择一个backend Pod。

ingress：Ingress 是从Kubernetes集群外部访问集群内部服务的入口，提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。