pod

Kubernetes之Service https://blog.lecury.cn/2016/06/20/Kubernetes之Service/ 在Kubernetes中Pod是终将消失的，从创建到销毁的过程中，它们是无法自动重启的。而ReplicationController可以用来动态的创建和销毁Pod（比如说在进行滚动升级的时候，可以进行扩展和收缩）。每一个Pod都得到一个属于自己的IP，但这些IP不能一直有效存在，因为这些IP随着Pod的销毁而变得没有了意义。那么这就导致了一个问题，如果一些Pods为集群内部的其他Pods（我们称它们为前端）提供服务，那么这些前端怎么发现、追踪这些后端集合中的服务呢？Service就是做这个事情的。 Service是一个抽象概念，它定义了一些逻辑上的Pods集合，并且定义了访问这些Pods集合的策略，也被称作为micro-service。Service通常通过Label标签选择器来对应相应的Pods集合（也有一些没有标签选择器的，请看下文介绍）。 举个例子，考虑一个运行的镜像，它在集群中有三个副本，这些副本是可以相互替代的，前端并不关心它现在与哪个后端服务打交道。实际上Pods组成的后端服务集合可以是变化的，比如说通过scale进行副本增加或者副本减少，但我们的前端不应该关心或者跟踪后端服务的变化，Service这一层抽象可以做到这一点。

目录 之前手动部署一个镜像到k8s集群中，发现一些配置出错了，导致pod一直在不停的重启，下面记录强制删除pod的命令 先说下网上大部分强制删除操作吧，我试了好几次不管用，尴尬 kubectl delete pod -n namespace podname --force --grace-period=0 言归正传，记录下强制删除pod的命令 当你的pod是通过deployment来创建的，可以这样删除 kubectl delete deployments.apps -n namespace podname 当你是直接通过rc来部署时（也是我自己这样部署的）,编辑rc，将启动数量改为0，那么你的pod就会被删掉了 kubectl edit replicationcontroller podname -n namespace 来源： https://www.cnblogs.com/levcon/p/12655586.html

作者 | 贾之光 阿里巴巴高级开发工程师 本文整理自《CNCF x Alibaba 云原生技术公开课》第 30 讲， 点击直达课程页面 。 关注“阿里巴巴云原生”公众号，回复关键词**“入门”**，即可下载从零入门 K8s 系列文章 PPT。 一、RuntimeClass 需求来源 容器运行时的演进过程 我们首先了解一下容器运行时的演进过程，整个过程大致分为三个阶段： 第一个阶段：2014 年 6 月 Kubernetes 正式开源，Docker 是当时唯一的、也是默认的容器运行时； 第二个阶段：Kubernetes v1.3 rkt 合入 Kubernetes 主干，成为了第二个容器运行时。 第三个阶段：Kubernetes v.15 与此同时，越来越多的容器运行时也想接入到 Kubernetes 中。如果还是按 rkt 和 Docker 一样内置支持的话，会给 Kubernetes 的代码维护和质量保障带来严重挑战。 社区也意识到了这一点，所以在 1.5 版本时推出了 CRI，它的全称是 Container Runtime Interface。这样做的好处是：实现了运行时和 Kubernetes 的解耦，社区不必再为各种运行时做适配工作，也不用担心运行时和 Kubernetes 迭代周期不一致所带来的版本维护问题。比较典型的，比如 containerd 中的 cri

本文不对Kubernetes做过多介绍，直接讲Kubernetes的各种YAML基本撰写规范。 基本概念请见： http://www.infoq.com/cn/articles/Kubernetes-system-architecture-introduction 所有的Resource的定义文档在这里都有 http://kubernetes.io/v1.0/docs/api-reference/definitions.html 例如：你要查询Pod声明里面有哪些字段，那么很有用. 不多废话。 1. 创建Container / Pod## Kubernetes的编排基本单元是Pod，故而哪怕你只有一个Container，也要创建一个Pod来容纳这个Container. apiVersion: v1 kind: Pod metadata: name: hello-world # pod资源名称，集群unique的 spec: # specification of the pod’s contents restartPolicy: Never # 运行这个容器一次，然后就结束这个pod containers: - name: hello # 只是这个container的nickname image: "ubuntu:14.04" # image 名, 默认使用Docker Hub

StorageClass 之前我们部署了 PV 和 PVC 的使用方法，但是前面的 PV 都是静态的，什么意思？就是我要使用的一个 PVC 的话就必须手动去创建一个 PV ，我们也说过这种方式在很大程度上并不能满足我们的需求，比如我们有一个应用需要对存储的并发度要求比较高，而另外一个应用对读写速度又要求比较高，特别是对于 StatefulSet 类型的应用简单的来使用静态的 PV 就很不合适了，这种情况下我们就需要用到动态 PV ，也就是我们今天要讲解的 StorageClass 。 创建 要使用 StorageClass ，我们就得安装对应的自动配置程序，比如我们这里存储后端使用的是 nfs ，那么我们就需要使用到一个 nfs-client 的自动配置程序，我们也叫它 Provisioner ，这个程序使用我们已经配置好的 nfs 服务器，来自动创建持久卷，也就是自动帮我们创建 PV 。 自动创建的 PV 以 ${namespace}-${pvcName}-${pvName} 这样的命名格式创建在 NFS 服务器上的共享数据目录中 而当这个 PV 被回收后会以 archieved-${namespace}-${pvcName}-${pvName} 这样的命名格式存在 NFS 服务器上。 当然在部署 nfs-client 之前，我们需要先成功安装上 nfs 服务器

目录 将制作的镜像推送到docker的私有仓库 k8s部署该镜像 k8s创建命名空间及secret 创建demo服务的yaml文件，我们service和deployment放在一个yaml文件中 启动 查看pod 环境：（docker ,k8s集群），继续上次docker 启动的java程序的镜像为例( https://www.cnblogs.com/levcon/p/12442662.html ) 将制作的镜像推送到docker的私有仓库 docker tag demo-img:latest localhost:5000/demo-img:1.0 docker push localhost:5000/demo-img:1.0 k8s部署该镜像 k8s创建命名空间及secret 创建命名空间cl-test，这里名字根据自己的命名规范自己定义，我这是测试用的 kubectl create namespace cl-test 创建完ns后，我们要给这个ns创建secret kubectl create secret docker-registry regcred --docker-server=your resroty ip:5000 --docker-username=root --docker-password=xxxx@ --docker-email=xxxx@163.com

HorizontalPodAutoscaler, k8s的版本是1.14.　 需求是这样的，如果应用的cpu使用率到达60%上则自动增加应用数，如果cpu使用率下降则自动将应用数减少。 先定义Deployment，如下List-1，加上Limit限制资源，好等会做压测的时候自动扩容。 List-1 apiVersion: apps/v1beta2 kind: Deployment metadata: name: {{ template "consumer.fullname" . }}-mjduan labels: app: {{ template "consumer.name" . }}-mjduan spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: app: {{ template "consumer.name" . }}-mjduan template: metadata: labels: app: {{ template "consumer.name" . }}-mjduan spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

[root@master ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE 192.168.3.228:5000/test/s v1 fdcfe04e9ea4 3 days ago 398MB sshd v1 fdcfe04e9ea4 3 days ago 398MB 192.168.3.228:5000/test/n v1 588bb5d559c2 5 days ago 127MB nginx 1.16 588bb5d559c2 5 days ago 127MB registry 2 708bc6af7e5e 2 months ago 25.8MB registry latest 708bc6af7e5e 2 months ago 25.8MB 192.168.3.228:5000/test/1 v1 708bc6af7e5e 2 months ago 25.8MB mkdir -p /opt/yml/test cd /opt/yml/test vim k8s_pod.yml apiVersion: v1 kind: Pod metadata: name: nginx lablels: app: web spec: containers: - name: n1 image: 192.168.3.228:5000/test

本文大部分是原理，后期打算开个专栏，咱也玩玩知识付费~ 一、发展史 在云计算领域有几个很常见的词汇：IaaS、PaaS、SaaS。IaaS就是基础平台即服务，国内有阿里云等；PaaS是平台即服务，在早些时候新浪云SAE较为有名；SaaS就是软件即服务，最大的Office厂商MS的Office365就是一个很好的代表。在最开始的时候PaaS基本就是人肉运维，慢慢的又出现了一系列的自动化工具，再后来专门做PaaS的一家公司创造了Docker。Docker变成了PaaS的一个标准，但是随着容器化的发展也出现了一系列的问题。容器化后容器的映射关系变得异常艰难，而且这仅仅是容器化发展的一个小小的问题。那么随着容器化的步伐，衍生出了一些列的资源管理器，最开始是Apache Mesos，Mesos由加州的伯克利大学研发出来，随后被推特选中，大规模的在推特盛行。在2019年5月，特推在旧金山开展了技术发布会，在该会上产品负责人宣布推特以后全部使用Kubernetes。第二款资源管理软件是Docker自家推出的Docker Swarm平台。Docker Swarm是一个非常轻量的资源管理平台。但是Swarm功能较为简单，而且国内云厂商阿里云在2019年7月宣布在选择资源管理框架的时候不支持Swarm，默认Kubernetes

Pod安全策略对于强化K8S集群安全至关重要。本文将延续之前的文章继续深入介绍Pod安全策略。 首先，简单介绍了如何将Pod与Pod安全策略相关联，并使用RBAC来展示具体步骤。然后介绍如何在Rancher中启用默认的PSP和创建自定义PSP。最后将使用一种工具来简化生产中Pod安全策略的使用，极大提升生产力，赶紧戳文咯~ 本文来自 RancherLabs 在 之前的文章 中，我们演示了如何使用受限的PSP策略作为默认值在Rancher中启用PSP。我们还展示了如何防止特权Pod被接纳到集群中。 我们有意省略了有关基于角色的访问控制（RBAC）以及如何将Pod与特定PSP连接的具体细节。那么，这篇文章让我们继续深入研究PSP。 将Pod与Pod 安全策略匹配 你可能已经注意到，PSP模式没有与任何Kubernetes命名空间、Service Account或Pod相关联。实际上，PSP是集群范围的资源。那么，我们如何指定哪些Pod应该由哪些PSP来管理呢？下图显示了所有参与组件、资源以及准入流程的工作方式。 也许一开始听起来很复杂。现在，我们来详细介绍一下。 部署Pod时，准入控制将根据请求deployment的对象来应用策略。 Pod本身没有任何关联的策略——执行该Deployment的是service account。在上图中，Jorge使用webapp-sa service