k8s核心资源对象& NameSpace（指定版本回滚）

k8s核心的资源对象：

  • Pod：是运行以及调度的原子单位，也就是k8s中最小的资源单位，同一个pod可以同时运行多个container，多个container之间共享：（UTS（主机名和域名），IPC（消息队列和共享内存），NET（网络栈，端口等），namespace（名称空间）），但USR（用户和组），MNT（挂载点），PID（进行编号）是相互隔离的。
    pod有两种类型的pod：一类是由控制器控制的pod，一类是自主式pod（不受控制器管理，自己管理自己）

  • Deployment：最常见的pod控制器，它支持应用的扩缩容。滚动更新操作。（缺点：无法回滚到指定的版本）
  • Service： 为有生命周期的pod对象提供了一个固定的统一的访问接口，用于服务发现和服务访问。
    以下资源对象会在后续的博客中进行应用，以下只做了解
  • RC（Replcation Controller）：最早一代的pod控制器，在将来的版本中会将其删除。
  • RS （Replication Set）：新一代的pod控制器，用来替换RC，功能与RC基本相同，唯一的不同之处在于支持的标签选择器不同。RC只支持等值的选择器，RS还额外支持基于集合的选择器。
  • DaemonSet：用来确保每个节点都运行某个pod的一个副本。（每个节点只运行一个副本，不支持replicas字段）
  • Job：用来管理运行完成之后即可终止的应用，例如批量处理作业任务（可以理解为依次形的pod，只要任务执行完成后，就立即删除pod）
  • PV（PersistentVolume）：持久卷，统一的数据持久化目录，方便管理

* PVC（PersistentVolumeClaim）：应用pv持久化空间的一个申请，声明。

  • Stroage Class：（存储类）根本作用：根据pv定义的值自动创建pv。
  • StatefulSet：又称PetSet，也是一种pod控制器。
    特点：pod名称不变，每个副本启停有顺序。用于数据持久化（每个pod的数据都不一样），自动创建pv，pvc。
  • Secret和ConfigMap：用于保存轻量的敏感信息。比如数据库的用户名和密码或者认证密钥等。

* Ingress-nginx: 用于解决集群的负载情况，为集群提供一个统一的路口。安全，端口容器管理。

NameSpace（命名空间）

NameSpace（命名空间）是kubernetes系统中的另一个重要的概念，通过将系统内部的对象“分配”到不同的namespace中，形成逻辑上分组的不同项目，小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。
kubernetes集群在启动后，会创建一个名为“default”的NameSpace，如果不特别指明NameSpace，则用户创建的pod，RC, Service都被系统创建到“default”的NameSpace中。
kubernetes中的NameSpace主要用于空间，名称上的隔离，和docker中的NameSpace的概念完全不一样。

[[email protected] ~]# kubectl  get ns   //查看命名空间
NAME              STATUS   AGE
default           Active   27d        //默认命名空间为default
kube-node-lease   Active   27d
kube-public       Active   27d
kube-system       Active   27d

创建命名空间
##有两种创建方法：命令行和编写yaml文件
//方法一：命令行创建

[[email protected] ~]# kubectl  create  ns k8s1
namespace/k8s1 created

//方法二：编写yaml文件

[[email protected] ~]# vim k8s2-ns.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: k8s2
[[email protected] ~]# kubectl apply -f  k8s2-ns.yaml
namespace/k8s2 created

命名空间的应用
1，指定一个pod（httpd）运行在指定的名称空间中：

[[email protected] ~]# vim test-pod1.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: test-pod1
  namespace: k8s2            //在该字段下指定命名空间
spec:
  revisionHistoryLimit: 5
  replicas: 2
  template:
    metadata:
      labels:
        name: httpd-web
    spec:
      containers:
      - name: httpd
        image: httpd
        ports:
        - containerPort: 80
[[email protected] ~]# kubectl apply -f  test-pod1.yaml
deployment.extensions/test-pod1 created
//查看该命名空间下的pod：
[[email protected] ~]# kubectl  get pod -n k8s2    # -n：指定命名空间
NAME                         READY   STATUS    RESTARTS   AGE
test-pod1-55b448f88c-mhmqc   1/1     Running   0          4m6s
test-pod1-55b448f88c-xqsr7   1/1     Running   0          4m6s

PS：查看任何命名空间下的资源对象时，都需要指定对应的命名空间，否则默认查看的时default命名空间下的pod。

namespace应用之指定版本回滚
在上一章的资源的创建方式博客中我们用到了版本的升级和回滚操作，但是只能在前后两个版本之间，这是一个极大的缺点，而接下来的操作是可以指定某一个版本来进行回滚。

//在指定的命名空间下创建一个deployment资源对象，镜像用私有仓库中的镜像，进行更新和回滚操作，且验证网页。

1）搭建registry私有仓库，且上传自定义镜像，过程可以参考该博文部署私有仓库

2）创建资源对象：
[[email protected] ~]# vim namespace-pod1.yaml

apiVersion: v1
kind: Namespace                 #创建命名空间
metadata:
  name: test-namespace
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deploy1
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        name: nginx-web            #创建deployment
    spec:
      containers:
      - name: nginx
        image: 172.16.1.30:5000/nginx:v1
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: test-namespace
spec:
  type: NodePort             #创建service关联deployment
  selector:
    name: nginx-web
  ports:
  - name: nginx
    port: 80
    targetPort: 80
    nodePort: 30001
//运行该pod
[[email protected] ~]# kubectl apply -f namespace-pod1.yaml --record
namespace/test-namespace configured
deployment.extensions/nginx-deploy1 configured
service/nginx-svc configured
  • 参数：--record：记录版本信息。
//查看deployment版本信息：
[[email protected] ~]# kubectl  get deployments. -o wide -n test-namespace


//访问web界面：

3)进行更新操作，将镜像版本进行更新至v2版本：

[[email protected] ~]# cp namespace-pod1.yaml namespace-pod2.yaml
[[email protected] ~]# vim namespace-pod2.yaml 

[[email protected] ~]# kubectl apply -f  namespace-pod2.yaml  --record  #记录版本信息
namespace/test-namespace configured
deployment.extensions/nginx-deploy1 configured
service/nginx-svc configured
//查看当前镜像版本：
[[email protected] ~]# kubectl  get deployments. -o wide -n test-namespace


//镜像更新成功，访问网页：

4）进行回滚操作，回滚到指定版本1：

//回滚之前需要先查看历史版本信息：
[[email protected] ~]# kubectl  rollout  history deployment  -n test-namespace


因为我只更新了一次，所以只有两个版本，当然在生产环境中肯定有非常多的一个版本，所以我们必须要能够指定对应的版本。

//进行回滚：

[[email protected] ~]# kubectl  rollout undo deployment -n test-namespace  nginx-deploy1 --to-revision=1
deployment.extensions/nginx-deploy1 rolled back
  • --to-revision参数来指定版本，只需要选择对应的版本号即可。
    //查看deployment的版本，是否回滚成功：

    版本回滚成功，测试访问web界面：

    可以看到回滚成功，网页内容也进行了回滚操作。

//再次查看历史版本信息：

可以看到进行了回滚操作后，之前的版本1已经变成了最新版本3，版本是以顺序的方式进行排列。

———————— 本文至此结束，感谢阅读 ————————

k8s核心资源对象& NameSpace（指定版本回滚）

原文地址：https://blog.51cto.com/13972012/2455272

时间： 2024-08-01 08:16:47

k8s核心资源对象& NameSpace（指定版本回滚）的相关文章

k8s资源对象的升级、回滚、扩容、缩容

一.资源创建的方式之一,命令的方式创建资源,理解命令运行之后的动作,通过查看资源的方式,总结Pod名称的由来. 当我们执行创建资源的命令后,deployment这个控制器会通过replicaset控制器去管理pod,下面通过一个实例来分析,当我们执行创建资源的命令后,k8s都做了些什么(通过其NAME即可发现规律)? 运行一个deployment [[email protected] ~]# kubectl run test01 --image=nginx:latest --replicas=2

TortoiseSVN 版本回滚

尝试用TortoiseSVN进行版本回滚,回滚到的版本和实际的内容有出入,可能是点了太多次给点乱了,囧~ 不过发现一个比较靠谱的方法,如下: 右键点击文件TortoiseSVN->showlog->右键点击要回滚的版本->save revision to 并覆盖文件路径,即可回滚到相应版本 另,附:这里点击总是和想要回滚的版本有出入,记录下,有时间再研究~ http://keenwon.com/1072.html http://my.oschina.net/u/232727/blog/1

版本回滚

#查看log,获取版本号 git log #本地仓库回退到某个版本 git reset --hard baeertasdasdvf #新建需要回退的版本old_master分支做备份 git branch old_master #push到远程 git push origin old_master:old_master #本地仓库回退到某个版本 git reset --hard baeertasdasdvf #删除远程的master分支 git push origin :master #根据ol

svn 日志版本回滚

[[email protected] online]# svn diff -r 9:8 Index: index.html =================================================================== --- index.html (revision 9) +++ index.html (revision 8) @@ -10,4 +10,3 @@ kkkkkkkkkkk kkkkkkkk ggggggg -10 [[email prote

#4.Git版本回滚

实际工作中,我们脑子里怎么可能记得一个几千行的文件每次都改了什么内容,不然要版本控制系统干什么.版本控制系统肯定有某个命令可以告诉我们历史记录, >1.在Git中,我们用git log命令查看: >2.如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline参数: 每提交一个新版本,实际上Git就会把它们自动串成一条时间线.如果使用可视化工具查看Git历史,就可以更清楚地看到提交历史的时间线. >3.如何回退到上一个版本或指定版本 Git必须知道当前版本是哪个版本

产品功能对标 - 服务上线、下线，版本回滚

一.版本上线 当您完成 API 的创建后,您可以将 API 发布到测试或者线上.也可以将测试或者线上的 API 下线.您需要注意以下几点: API 创建完成后,发布到某环境,通过二级域名或者独立域名访问时,需要在请求的Header指定要请求的环境,参见 请求示例. 当您要发布某个 API 时,如果该 API 在测试或者线上已经有版本在运行,您的此次发布将使测试或者线上的该 API 被覆盖,实时生效.但是历史版本及定义会有记录,您可以快速回滚. 您可以将测试或者线上的某个 API 下线,下线之后,

svn 版本回滚

取消对代码的修改分为两种情况: 第一种情况:改动没有被提交(commit). 这种情况下,使用svn revert就能取消之前的修改. svn revert用法如下: # svn revert [-R] something 其中something可以是(目录或文件的)相对路径也可以是绝对路径. 当something为单个文件时,直接svn revert something就行了:当something为目录时,需要加上参数-R(Recursive,递归),否则只会将something这个目录的改动

git版本回滚

先说今天遇到的问题,看到一个config.php的配置文件一直在修改的状态下,但是和远程的config.php是不一致的,我不需要提交它,但是看它在 modified的状态下,很不爽,想删除它,git   rm  config.php,然后git push了下,结果不仅把本地的config.php干掉了,把远程的config.php也给干掉了,,原来这个git rm有这样的功效,而且我 删除的不只是这一个文件,还有n个文件. 想到要回滚到最近的一次提交.做这个工作前,提醒下,在本地直接把代码备份

git远程库代码版本回滚方法

最近使用git时, 造成了远程库代码需要回滚到之前版本的情况,为了解决这个问题查看了很多资料. 问题产生原因: 提交了错误的版本到远程库. 以下是解决的方法, 供大家参考: 1.对本地代码库进行回滚 git log 查看提交历史,找出要回滚到的commit-id git reset --hard commit-id :回滚到commit-id git reset --hard HEAD~3:将最近3次的提交回滚 2.远程代码库回滚 进行这一步的时候遇到了困难,尝试了多种方法, 查看很多资料都提到