Kubernetes中Namespace与Pod

一、Namespace

1）Namespace概述

Namespace是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的（默认是default），而node, persistentVolumes等则不属于任何namespace。

Namespace常用来隔离不同的用户，比如Kubernetes自带的服务一般运行在kube-system namespace中。

Kubernetes中的名称空间与docker中的名称空间不同。K8s中的名称空间只是做了一个逻辑上的隔离。

2）Namespace常用的命令

（1）查询

[ ~]# kubectl get namespaces
//查看K8s中存在的名称空间
NAME              STATUS   AGE
default           Active   6d21h
kube-node-lease   Active   6d21h
kube-public       Active   6d21h
kube-system       Active   6d21h
//namespace包含两种状态”Active”和”Terminating”。在namespace删除过程中，namespace状态被设置成”Terminating”。
[ ~]# kubectl describe namespaces default 
//查看default名称空间的详细信息
[ ~]# kubectl get pod --namespace=default 
[ ~]# kubectl get pod -n default 
//查看default名称空间中的pod资源（两者都可以）
[ ~]# kubectl get pod
//如果不指定，则默认也是查看default名称空间中的资源

（2）创建、删除

使用命令行创建

[ ~]# kubectl create namespace beijing
//创建一个名称空间，名称为beijing
//创建完成后，可以通过“kubectl get namespaces”命令查看到
[ ~]# kubectl delete namespace beijing
//删除新创建的名称空间

使用yaml文件创建

[ ~]# vim namespace.yaml 
apiVersion: v1
kind: Namespace
metadata:
  name: test
[ ~]# kubectl apply -f namespace.yaml 
[ ~]# kubectl delete -f namespace.yaml

注意：
（1）删除一个名称空间时会自动删除所有属于该namespace的资源；
（2）default和kube-system名称空间不可以被删除；
（3）namespace资源对象进用于资源对象的隔离，并不能隔绝不同名称空间的Pod之间的通信。如果需要隔离Pod之间的通信可以使用网络策略资源这项功能；

名称空间就先简单介绍这么多，如果以后有需要会更新的！

二、Pod

1）什么是Pod？

在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod,Pod是最小的，管理，创建，计划的最小单元.

一个Pod就相当于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用可能是在同一个物理主机或虚拟机上。

Pod 的context可以理解成多个linux命名空间的联合：
PID 命名空间（同一个Pod中应用可以看到其它进程）；
网络命名空间（同一个Pod的中的应用对相同的IP地址和端口有权限）；
IPC 命名空间（同一个Pod中的应用可以通过VPC或者POSIX进行通信）；
UTS 命名空间（同一个Pod中的应用共享一个主机名称）；

Pod和相互独立的容器一样，Pod是一种相对短暂的存在，而不是持久存在的，正如我们在Pod的生命周期中提到的，Pod被安排到结点上，并且保持在这个节点上直到被终止（根据重启的设定）或者被删除，当一个节点死掉之后，上面的所有Pod均会被删除。特殊的Pod永远不会被转移到的其他的节点，作为替代，他们必须被replace（代替）。

2）Pod资源的共享及通信

Pod的中的应用均使用相同的网络命名空间及端口，并且可以通过localhost发现并沟通其他应用，每个Pod都有一个扁平化的网络命名空间下IP地址，它是Pod可以和其他的物理机及其他的容器进行无障碍通信。

除了定义了在Pod中运行的应用之外，Pod还定义了一系列的共享的磁盘，磁盘让这些数据在容器重启的时候不回丢失并且可以将这些数据在Pod中的应用进行共享。

3）Pod的管理

Pod通过提供一个高层次抽象而不是底层的接口简化了应用的部署及管理，Pod 作为最小的部署及管理单位，位置管理，拷贝复制，资源共享，依赖关系都是自动处理的。

4）为什么不直接在一个容器上运行所有的程序？

（1）透明，Pod中的容器对基础设施可见使的基础设施可以给容器提供服务，例如线程管理和资源监控，这为用户提供很多便利
（2）解耦，解除软件依赖关系,独立的容器可以独立的进行重建和重新发布，Kubernetes 甚至会在将来支持独立容器的实时更新；
（3）易用，用户不需要运行自己的线程管理器，也不需要关心程序的信号以及异常结束码等；
（4）高效，因为基础设施承载了更多的责任，所以容器可以更加高效；

总之就是一句话：如果说运行多个服务，其中一个服务出现问题，那么就需重启整个Pod，与docker这种容器化的初衷是违背的！

5）手动创建Pod（不使用控制器）

创建pod时镜像获取策略：
always：（默认使用）镜像标签为latest或镜像不存在时，总是会从指定的仓库中获取镜像；
IfNotPresent：仅当本地镜像不存在时才会从目标仓库中下载；
Never：禁止从仓库中下载镜像，即只使用本地镜像;

三种状态，在创建时可以任意指定！

[ ~]# kubectl create namespace test
//创建一个名为test的名称空间（不是必须的）
[ ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: test             //指定其所在的名称空间
spec:
  containers:
  - name: test-app
    image: 192.168.1.1:5000/httpd:v1
[ ~]# kubectl apply -f pod.yaml 
//根据yaml文件生成所需的Pod
[ yaml]# kubectl get pod -n test       
//需要指定名称空间进行查看（否则默认情况下在default名称空间下查找）
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          11s

注意：对于标签为latest或者不存在时，其默认的下载策略为Always，而对于其他标签的镜像，默认策略为IfNotPresent。

[ ~]# vim pod.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: test
  labels:
    name: test-web
spec:
  containers:
  - name: test-app
    image: 192.168.1.1:5000/httpd:v1
    imagePullPolicy: IfNotPresent           //指定pod镜像的策略
    ports:
    - protocol: TCP
      containerPort: 80     //只是一个声明，没有任何作用
[ ~]# kubectl delete -f pod.yaml          
//需要将原本的删除否则无法进行下载          
[ ~]# kubectl apply -f pod.yaml 
//重新指定yaml文件进行下载

创建一个service进行关联

[ ~]# vim pod-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: test-svc
  namespace: test
spec:
  selector:
    name: test-web
  ports:
  - port: 80
    targetPort: 80                 //注意这个端口时生效的，即使是错误的
[ ~]# kubectl apply -f pod-svc.yaml 
[ ~]# kubectl get svc -n test
NAME       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
test-svc   ClusterIP   10.108.187.128   <none>        80/TCP    35s
[ ~]# curl 10.108.187.128           //访问测试
lvzhenjiang

如果访问不到，

[ ~]# kubectl describe svc -n test pod-svc
//查看service的详细信息，找到Endpoints字段即可发现

6）pod的重启策略、健康检查

Pod的重启策略：
Always：（默认情况下使用）但凡Pod对象终止就将其重启；
OnFailure：仅在Pod对象出现错误时才将其重启；
Never：从不重启；