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)查询

[[email protected] ~]# 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”。
[[email protected] ~]# kubectl describe namespaces default
//查看default名称空间的详细信息
[[email protected] ~]# kubectl get pod --namespace=default
[[email protected] ~]# kubectl get pod -n default
//查看default名称空间中的pod资源(两者都可以)
[[email protected] ~]# kubectl get pod
//如果不指定,则默认也是查看default名称空间中的资源

(2)创建、删除

使用命令行创建

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

使用yaml文件创建

[[email protected] ~]# vim namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: test
[[email protected] ~]# kubectl apply -f namespace.yaml
[[email protected] ~]# 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:禁止从仓库中下载镜像,即只使用本地镜像;

三种状态,在创建时可以任意指定!

[[email protected] ~]# kubectl create namespace test
//创建一个名为test的名称空间(不是必须的)
[[email protected] ~]# 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
[[email protected] ~]# kubectl apply -f pod.yaml
//根据yaml文件生成所需的Pod
[[email protected] yaml]# kubectl get pod -n test
//需要指定名称空间进行查看(否则默认情况下在default名称空间下查找)
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          11s

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

[[email protected] ~]# 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     //只是一个声明,没有任何作用
[[email protected] ~]# kubectl delete -f pod.yaml
//需要将原本的删除否则无法进行下载
[[email protected] ~]# kubectl apply -f pod.yaml
//重新指定yaml文件进行下载

创建一个service进行关联

[[email protected] ~]# vim pod-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: test-svc
  namespace: test
spec:
  selector:
    name: test-web
  ports:
  - port: 80
    targetPort: 80                 //注意这个端口时生效的,即使是错误的
[[email protected] ~]# kubectl apply -f pod-svc.yaml
[[email protected] ~]# 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
[[email protected] ~]# curl 10.108.187.128           //访问测试
lvzhenjiang

如果访问不到,

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

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

Pod的重启策略:

  • Always:(默认情况下使用)但凡Pod对象终止就将其重启;
  • OnFailure:仅在Pod对象出现错误时才将其重启;
  • Never:从不重启;

三种状态,在创建时可以任意指定!

通过一个小案例进行查看:

[[email protected] ~]# vim cache.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: healcheck
  name:  healcheck
spec:
  restartPolicy: OnFailure                //重启策略
  containers:
  - name:  healcheck
    image: busybox:latest
    args:                           //启动pod时执行的命令
    - /bin/sh
    - -c
    - sleep 10; exit 1
[[email protected] ~]# kubectl apply -f cache.yaml
//生成pod
[[email protected] ~]# kubectl get pod -w | grep healcheck
//动态检测pod的状态
healcheck   0/1     CrashLoopBackOff   1          35s
healcheck   1/1     Running            2          36s
healcheck   0/1     Error              2          46s
//此时可以看出指定的重启策略已经生效

——————————————本文到此为止,感谢阅读——————————————

原文地址:https://blog.51cto.com/14157628/2465659

时间: 2024-09-29 19:41:46

Kubernetes中Namespace与Pod的相关文章

Kubernetes中强制删除Pod、namespace

Kubernetes中强制删除Pod.namespace 解决方法 可使用kubectl中的强制删除命令 # 删除POD kubectl delete pod PODNAME --force --grace-period=0 # 删除NAMESPACE kubectl delete namespace NAMESPACENAME --force --grace-period=0 若以上方法无法删除,可使用第二种方法,直接从ETCD中删除源数据 # 删除default namespace下的pod

kubernetes中的Pod简述与实践

Pod的概念详细的Pod解释可参考k8s官网,关于Pod的概念主要有以下几点:(1)Pod是kubernetes中你可以创建和部署的最小也是最简的单位.一个Pod代表着集群中运行的一个进程:(2)在Kubrenetes集群中Pod的使用方式:(3)Pod中如何管理多个容器 理解Pod上面已经说了"Pod是kubernetes中你可以创建和部署的最小也是最简的单位.一个Pod代表着集群中运行的一个进程."Pod中封装着应用的容器(有的情况下是好几个容器),存储.独立的网络IP,管理容器如

Kubernetes中,通过Service访问Pod快速入门

一.背景 理想状态下,我们可以认为Kubernetes Pod是健壮的.但是,理想与现实的差距往往是非常大的.很多情况下,Pod中的容器可能会因为发生故障而死掉.Deployment等Controller会通过动态创建和销毁Pod来保证应用整体的健壮性.众所周知,每个Pod都拥有自己的IP地址,当新的Controller用新的Pod替代发生故障的Pod时,我们会发现,新的IP地址可能跟故障的Pod的IP地址可能不一致.此时,客户端如何访问这个服务呢?Kubernetes中的Service应运而生

Kubernetes中Pod间共享内存方案

摘要:一些公共服务组件在追求性能过程中,与业务耦合太紧,造成在制作基础镜像时,都会把这些基础组件都打包进去,因此当业务镜像启动后,容器里面一大堆进程,这让Kubernetes对Pod的管理存在很大隐患.为了让业务容器瘦身,更是为了基础组件自身的管理更独立和方便,将基础组件从业务镜像中剥离并DaemonSet容器化部署.然而一些基础组件Agent与业务Pod之间通过共享内存的方式进行通信,同一Node中跨Pod的共享内存方案是首先要解决的问题. 为什么要将公共基础组件Agent进行DaemonSe

第三章 pod:运行于kubernetes中的容器

本章内容涵盖 创建. 启动和停止 pod 使用标签组织 pod 和其他资源 使用特定标签对所有 pod 执行操作 使用命名空间将多个 pod 分到不重叠的组中 调度 pod 到指定类型的工作节点 上一章 已经大致介绍了在 Kubemetes 中创建的基本组件,包括它们的基本功 能概述. 那么接下来我们将更加详细地介绍所有类型的 Kubemetes 对象(或资源), 以便你理解在何时. 如何及为何要使用每一个对象. 其中 pod 是 Kubemetes 中最为 重要的核心概念,而其他对象仅仅是在管

Kubernetes之深入了解Pod

1.yaml格式的Pod配置文件内容及注解 深入Pod之前,首先我们来了解下Pod的yaml整体文件内容及功能注解. 如下: # yaml格式的pod定义文件完整内容: apiVersion: v1 #必选,版本号,例如v1 kind: Pod #必选,Pod metadata: #必选,元数据 name: string #必选,Pod名称 namespace: string #必选,Pod所属的命名空间 labels: #自定义标签 - name: string #自定义标签名字 annota

如何在Kubernetes中管理有状态应用

在Kubernetes中,StatefulSet被用来管理有状态应用的API对象.StatefulSets在Kubernetes 1.9版本才稳定.StatefulSet管理Pod部署和扩容,并为这些Pod提供顺序和唯一性的保证.与Deployment相似的地方是,StatefulSet基于spec规格管理Pod:与Deployment不同的地方是,StatefulSet需要维护每一个Pod的唯一身份标识.这些Pod基于同样的spec创建,但互相之间不能替换,每一个Pod都保留自己的持久化标识.

Kubernetes中的RBAC

Kubernetes中,授权有ABAC(基于属性的访问控制).RBAC(基于角色的访问控制).Webhook.Node.AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式.需要在kube-apiserver设置–authorization-mode=RBAC参数,启用RABC模式,下面的操作版本为v1.10.1: 当应用没有指定serviceAccountName,它将使用default服务帐户. 在RABC API中,通过如下的步骤进行授权: 1)定义角色:定义角色

Kubernetes中的Secret配置

  Secret 概览 Secret 是一种包含少量敏感信息例如密码.token 或 key 的对象.这样的信息可能会被放在 Pod spec 中或者镜像中:将其放在一个 secret 对象中可以更好地控制它的用途,并降低意外暴露的风险. 用户可以创建 secret,同时系统也创建了一些 secret. 要使用 secret,pod 需要引用 secret.Pod 可以用两种方式使用 secret:作为 volume中的文件被挂载到 pod 中的一个或者多个容器里,或者当 kubelet 为 p