pod

引言 大多数安全措施都是为了防止漏洞逃跑而设计的， 在此之前，我们也分享了一些第三方安全扫描的文章（请移步到历史文章中查看），尽早识别应用程序的风险意味着您可以防止或限制它部署到您的系统中（安全左移策略）。有了这些知识或工具，容器中任何可能造成损坏的漏洞都可以安全地留在由您的安全策略围栏后面。 但是，当这些漏洞已经逃跑时，我们能做什么呢? 如何确保已经在Kubernetes pods中运行的容器和应用程序符合您当前的风险和策略? 背景（运行时安全管控） 由于大多数应用程序严重依赖于包管理器和开源存储库，因此它们很容易受到来自这些源的恶意或不安全代码的***。想象我们交付的软件 Application 是一张饼，我们自己开发的代码仅占其中很小一部分，见下图： 最近，当Javascript社区得知npm module中流行的事件流包被一个针对比特币钱包平台的恶意包更新时，他们非常愤怒。在被发现和报道之前的三个月里，这个包被下载了近800万次。 虽然来自社区包管理器的此类事件并不常见，但并不少见。一年前，npm发现并删除了39个恶意包。所以很多包在我们安全策略发现之前可能已经进入到了生产环境 解决方案 在介绍如何对运行时进行安全控制之前，先回顾一下常见漏洞扫描工具的原理：这里以JFrog Xray 为例： 通用二进制分析工具和策略引擎JFrog Xray

StatefulSet StatefulSet：Pod控制器。 ​ RC,RS,Deployment,DS。---------->无状态的服务。 ​ template（模板）：根据模板创建出来的Pod,他们的状态都是一模一样的（除了名称，IP，域名之外） ​ 可以理解为：任何一个Pod，都可以被删除，然后用新生成的Pod进行替换。 有状态的服务：需要记录前一次或者多次通信中的相关事件，以作为一下通信的分类标准。比如：mysql等数据库服务。(Pod的名称，不能随意变化。数据持久化的目录也是不一样，每一个Pod都有自己独有的数据持久化存储目录。) ​ mysql：主从关系。 如果把之前无状态的服务比喻为牛，羊等牲畜。把有状态比喻为：宠物。 每一个Pod对应一个PVC,每一个PVC对应一个PV。 ​ storageclass：自动创建PV。 ​ 需要解决：自动创建PVC------------>volumeClaimTemplates [root@master ~]# vim statefulset.yaml apiVersion: v1 kind: Service metadata: name: headless-svc labels: app: headless-svc spec: ports: - port: 80 selector: app: headless-pod

kube-APIserver组件介绍 kube-APIserver提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。 kube-APIserver的功能 提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更) 提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd） 是资源配额控制的入口 拥有完备的集群安全机制 kube-apiserver工作原理图 kubernetes API的访问 k8s通过kube-apiserver这个进程提供服务，该进程运行在单个k8s-master节点上。默认有两个端口 本地端口 该端口用于接收HTTP请求 该端口默认值为8080，可以通过API Server的启动参数“--insecure-port”的值来修改默认值 默认的IP地址为“localhost”，可以通过启动参数“--insecure-bind-address”的值来修改该IP地址 非认证或授权的HTTP请求通过该端口访问API Server 安全端口 该端口默认值为6443，可通过启动参数“--secure-port”的值来修改默认值 默认IP地址为非本地（Non-Localhost）网络端口

提及云计算，绝大多数人的反应是这样的：它是一门新兴技术，是互联网发展的未来趋势，云计算核心技术比较多，学习不易。不过如果你真的想要学好云计算，也是有其规律可循的，从基础到进阶、由简单到复杂，不断的学习加练习，你就可以学好它。 Kubernetes，简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes提供了应用部署、规划、更新、维护的一种机制，Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。 使用Kubernetes可以：自动化容器的部署和复制；随时扩展或收缩容器规模；将容器组织成组，并且提供容器间的负载均衡；很容易地升级应用程序容器的新版本；提供容器弹性，如果容器失效就替换它等等。Kubernetes核心概念知识： Pod-容器组 Pod是Kubernetes的基本操作单元，指定多个有关联容器（有调用关系依赖）构成一个Pod。Pod包含的容器运行在同一个Minion上（Worker Node），Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统。 Deployment-部署 Deployment是最近几个版本才有的，部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以创建

web界面（Dashboard） 之前在kubernetes中完成的所有操作都是通过命令行工具kubectl完成的，为了提供更丰富的用户体验，kubernetes还开发了一个基于web的用户界面（Dashboard）。用户可以使用Dashboard部署容器化的应用，还可以监控应用的状态，执行故障排查以及管理kubernetes中各种资源。 在kubernetes Dashboard中可以查看集群中应用的运行状态，也能够创建和修改各种kubernetes资源（比如Deployment，Job，Daemonset等等），用户可以对Deployment实现弹性伸缩，执行滚动升级，重启pod或者使用向导创建新的应用。 可以说，kubernetes Dashboard提供了kubectl的绝大部分功能。 Dashboard 同时展示了kubernetes集群中的资源状态信息和所有报错信息。 官方参考文档： https://kubernetes.io/zh/docs/tasks/access-application-cluster/web-ui-dashboard/ GitHub项目下载地址： https://github.com/kubernetes/dashboard 一，部署Dashboard UI kubernetes 默认没有部署Dashboard，可通过以下命令下载：

前言 作为一名网络工程的大学生，在前段时间学习了云计算和大数据的相关技术后，我迫切的想要获得更多的自动化持续交互的相关技术。目前非常火热的Kubernetes技术简称（K8s）是由谷歌开源的Docker容器集群管理系统，功能非常强大，也激起了我浓厚的学习兴趣。 以后我会将这一系列关于Kubernetes的技术文章和学习心得一并分享出来，供大家一块学习和交流。 1. Kubernetes是什么 首先， 我们在学习Kubernetes之前一定要先了解一下什么是Kubernetes。 第一，它是一个全新的基于容器技术的分布式架构领先方案，并且是由谷歌保密十几年之久的秘密武器-Borg的一个开源版本。 Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自 动化，以及跨多个数据中心的资源利用率的最大化。 然后，Kubernetes是一个开放的开发平台。与J2EE不同，它不局限于 任何一种语言 ，没有限定任何编程接口，所以不论是用Java、Go、C++还是用Python编写的服务，都可以被映射为Kubernetes的Service（服务），并通过标准的TCP通信协议进行交互。 此外，Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。 最后

1: Node隔离和恢复 操作功能： Node隔离和恢复 操作步骤： node隔离： yaml文件： apiVersion: v1 kind: Node metadata: name: kubernetes-minion1 labels: kubernetes.io/hostname: kubernetes-minion1 spec: unschedulable: true 然后，通过kubectl replace 命令完成对Node状态的修改：（kubectl replace -f unschedule_node.yaml） 查看Node的状态，可以观察到在Node的状态中增加了一项SchedulingDisabled 状态查看命令： kubectl get nodes 这样后续创建的Pod，系统将不会再向该Node进行调度 同样可以不适用配置文件，直接使用kubectl path命令来完成： kubectl patch node kubernetes-minion1 -p '{＂spec＂:{＂unschedulable＂:true}}' 备注： 将某个Node脱离调度范围时，在其上运行的pod并不会自动停止，管理员需要手动停止在该Node上运行的Pod node恢复： 如果需要将某个Node重新纳入集群调度范围，则将unschedulable设置为false

什么是StatefulSet？ StatefulSet表示一组具有唯一持久身份标识和稳定主机名的有状态Pod，无论Pod在哪一个Node上运行，身份标识及持久化的数据其都会保留。一般用于持久化存储、固定网络标记、有序部署、有伸缩等场景。 什么是有状态应用？ 有状态应用是将数据或应用程序状态持久化到关联的存储中，例如MySQL、Kafka、Zookeeper等应用场景，需要对其进行唯一持久身份的标识及数据的永久保存到存储中。 StatefulSet操作 像Deployment一样StatefulSet管理基于相同容器规范的Pod。但唯一不同的是StatefulSet为其每个Pod维护一个标识身份，StatefulSet需要Headless Service来负责Pod的网络身份。每个Pod具有一个存储类及存储声明，无论Pod被调度到哪一个节点，相关的存储挂载将伴随Pod。在删除Pod或者Stateful时，不会删除掉关联的PersistentVolume及PersistentVolumes。 通过yaml资源定义清单创建 kubectl apply -f nginx-statefulset.yaml apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80

Kubernetes 调试 deployment 的思路原文： https://learnk8s.io/troubleshooting-deployments 1、组件匹配规则 当你希望在Kubernetes中部署一个应用程序，你通常需要定义三个组件： Deployment——这是创建名为Pods的应用程序副本的方法 Serivce——内部负载均衡器，将流量路由到Pods Ingress——可以描述流量如何从集群外部流向Service 在Kubernetes中，你的应用程序通过两层负载均衡器暴露：内部和外部。内部负载均衡器称为Service，而外部负载均衡器则称为Ingress。 端口和标签需要匹配规则： Service selector应该匹配Pod的标签 Service targerPort应该匹配在Pod内容器的containerPort Service 端口可以是任意数字。多个Service可以使用同个端口，因为它们已经分配了不同的IP地址 Ingress的servicePort应该匹配在Service中的port Service的名称应该匹配在Ingress中的serviceName的字段 假设你想部署一个简单的Hello World应用程序，那么对于此类应用程序，其YAML文件与以下类似： apiVersion: apps/v1 kind: Deployment

1. spec: containers: - name: example resources: requests: cpu: 100m memory: 64Mi limits: cpu: 200m memory: 128Mi 例如，一个带有3个容器的pod，每个容器请求0.1核CPU和64MB内存（如上面的spec所示），将总共请求0.3核CPU和192MB内存。因此，如果你正在运行带有多个容器的pod，请注意对pod的总请求，总的请求越高，那么调度限制（找到一个具有可用资源的节点来匹配pod的总请求）就会更严格。 限制阈值应该设置得比请求数高，并且应该设置为只在特殊情况下才会达到的值。例如，如果有内存泄漏，你可能想要有意地清除某些东西，以阻止它破坏整个集群。 来源： https://www.cnblogs.com/hixiaowei/p/9692353.html