pod

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

一、创建POD时指定相应标签 apiVersion: v1 kind: Pod metadata: name: kubia-manual namespace: test labels: app: web_html #定义了app标签为：web_html env: prod #定义了env标签为：prod spec: containers: - name: kubia image: luksa/kubia ports: - containerPort: 8080 protocol: TCP 二、通过标签查看POD [root@test-nodes1 ~]# kubectl get pod --show-labels -n test #查看所有pod的标签 NAME READY STATUS RESTARTS AGE LABELS kubia-manual 1/1 Running 0 47h app=web_test,env=prod nginx-dp-856666d759-bfrgj 1/1 Running 0 3d9h app=nginx-proxy,env=test,pod-template-hash=856666d759 nginx-dp-856666d759-c5p4l 1/1 Running 0 3d9h app=nginx-proxy,env=test,pod

由于需要现在要更改包名，但是在网上找了N多资料都比较老，16年的资料却是残缺不全,尤其 ios10 出了 .entitlement 的机制 ,很多琐碎的小细节 很容易忘记。所以我自己总结了一篇, 环境为 Xcode Version 9.0 (9A235)。 注意：请在修改前使用git 备份工程，如果使用的SVN 要把 代码从仓库拖出来修改。 1，修改文件名（将bubble 修改成 bubblewrap ） -----> 2, 将旧项目文件夹和Tests文件夹还有UITest文件夹修改为新的名称,修改后如下图所示（我这里没有UITests，） （注意：UITests和Tests要不要动，只修改前面的bubble,而且要把里面的.m文件名也修改） 3， 右击 你的项目.xcodeproj ，选择“show content package”(中文：显示包内容)，看到如下目录,并将project.pbxproj文件以 文本编辑 打开。 4，替换新旧项目名：按command+f（这主要是修改项目文件路径等） 勾选 替换 ，点击 全部 5，进入项目，修改项目名（ 注意：如果使用的是cocopods，从 你的项目.xcworkspace 进入 ） 按回车 修改 bubble-->bubblewrap(如果打开工程后发现，工程文件变红了，也就是丢失了，参考直接跳到本文末，有解决方法) 点

现象 测试同学反馈页面某功能有时候不能使用。 分析 根据页面返回结果和URL，从开发同学那里了解到该现象是新环境里a服务调b服务返回异常导致的。从多次请求的结果看来，大概50%的几率返回异常。按常理判断如果b服务有多个节点的，可能有其中个别节点异常会导致此现象发生，但是b服务只有一个节点，请求的同时，观察b服务的日志，在a调用结果异常的情况下，b没有任何日志输出，正常情况日志输出返回结果，说明请求没有到达b服务，如果对调用链路不熟的情况下完全可以抓包明确请求是否到达。那么调用失败的请求是去哪里了呢？调用链路如下： 图1 图1可以看出a调用b的地址是从consul-server上拿到的，在consul-server控制台看到的情况入下图： 图2 注：图中gw-mini是服务b 图2 中看到单节点的b服务，在consul注册中心上注册了两个实例，实际是这样吗？继续看下图： 图3 图3中b服务是单节点，ip是10.100.73.72，而consul-server中的另外一个地址10.100.73.75是其他服务的ip地址。在consul上b服务下面的两个实例健康检查都是正常状态，难怪a调用b老是出现异常的返回结果，a拿到的地址list里面有一个地址是不对的。为什么consul上b服务会有两个实例？看看异常实例10.100.73.75的详情，如下图： 图4 健康检查URL是b服务的没错

kubernetes 的安全 标签（空格分隔）： kubernetes系列 一： kubernetes的安全机制 二： kubernetes的权限下发devuser 三： kubernetes的 准入控制 ##一： kubernetes的安全机制 1.1 kubernetes的apiserver Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部 各个组件通信的中介，也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计 的。Kubernetes 使用了认证（Authentication）、鉴权（Authorization）、准入控制（AdmissionControl）三步来保证API Server的安全 1.2 Authentication HTTP Token 认证：通过一个 Token 来识别合法用户 HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串 - Token 来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个 Token 对应一个用户名存储在 API Server 能访 问的文件中。当客户端发起 API 调用请求时，需要在 HTTP Header 里放入 Token HTTP Base 认证：通过

pod控制器分类： 1、ReplicationController 2、ReplicaSet 3、Deployment 4、StatefulSet 5、DaemonSet 6、Job,Cronjob 7、HPA pod控制器：一般包括3部分 1、标签选择器 2、期望的副本数（DaemonSet控制器不需要） 3、pod模板 deploy控制器构建于rs控制器之上，新特性包括： 1、事件和状态查看 2、回滚 3、版本记录 4、暂停和启动 5、支持两种自动更新方案 Recreate删除重建 RollingUpdate回滚升级（默认方式） 创建deploy $ kubectl run --help $ kubectl run nginx --image=nginx --port=80 --replicas=2 #用命令直接创建 $ kubectl run nginx --image=nginx --port=80 --dry-run -o yaml apiVersion: apps/v1 kind: Deployment metadata: labels: run: nginx name: nginx spec: replicas: 1 selector: matchLabels: run: nginx template: metadata: labels: run: nginx

什么是 DaemonSet？ 编写 DaemonSet 规约 必需字段 Pod 模板 Pod Selector 仅在某些节点上运行 Pod 如何调度 Daemon Pod 与 Daemon Pod 通信 更新 DaemonSet DaemonSet 的可替代选择 init 脚本 裸 Pod 静态 Pod Replication Controller 什么是 DaemonSet？ DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。 使用 DaemonSet 的一些典型用法： 运行集群存储 daemon，例如在每个节点上运行 glusterd、ceph。 在每个节点上运行日志收集 daemon，例如fluentd、logstash。 在每个节点上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet

kubernetes 的调度 标签（空格分隔）： kubernetes系列 一： kubernetes的调度 二： kubernetes的节点的亲和性 三： kubernetes的污点与容忍 四： kubernetes的固定节点 一：kubernetes的调度 1.1 scheduler 的介绍 Scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。听起来非常简单，但有很多要考虑的问题： 1.公平：如何保证每个节点都能被分配资源 2. 资源高效利用：集群所有资源最大化被使用 3. 效率：调度的性能要好，能够尽快地对大批量的 pod 完成调度工作 4. 灵活：允许用户根据自己的需求控制调度的逻辑 Sheduler 是作为单独的程序运行的，启动之后会一直坚挺 API Server，获取 PodSpec.NodeName 为空的 pod，对每个 pod 都会创建一个 binding，表明该 pod 应该放到哪个节点上 1.2 调度过程 调度分为几个部分：首先是过滤掉不满足条件的节点，这个过程称为 predicate ；然后对通过的节点按照优先级排序，这个是 priority；最后从中选择优先级最高的节点。如果中间任何一步骤有错误，就直接返回错误 Predicate 有一系列的算法可以使用： PodFitsResources

一、介绍 Kubernetes 是当前炙手可热的技术,它已然成为可开源界的PASS管理平台的标准，当下文章对大多数是对X86平台搭建Kubernetes平台，下面笔者进行在LinuxONE上搭建开源的Kubernetes平台。 搭建K8S 平台主流的有两种方法， 第一种是基于二进制的搭建，通过一步一步的搭建可以加深对K8S各个服务的理解。 官方推荐的自动化部署工具 kubeadm 本次使用官方推荐的Kubeadm 的搭建方法， kubedm 把K8S 自身的服务都被K8S自身的pod，除此之外事先的基础服务是用system服务的方式运行。 master节点安装组件： docker、kubelet、kubeadm 基于本地的system服务运行 kube-proxy 是 动态的可被k8s 管理的pod api-server、kube-controller、etcd、 是托guan在pod node节点组件 docker、kubelet 基于本地的system服务运行 kube-proxy 是 动态的可被k8s 管理的pod flannel 是 动态的可被k8s 管理的pod 二、安装 1. 环境 安装的环境可以使用虚拟机也可以使用Lpar，我这是使用的Openstack环境下面的虚拟机。虚拟机的规格为4C10G50G 系统版本 IP地址 主机名 K8s version Red Hat

前面介绍了k8s的deployment和statefulset这两种控制器。 deployment是属于无状态的服务，nginx，Tomcat，没有关联的pod statefulset是属于有状态的服务。mysql，zk、etcd，集群形式的pod 下面我们来介绍一下第三种方式DaemonSet这种控制器模式 DaemonSet 的典型应用场景： 在集群的每个节点上运行存储 Daemon，比如：glusterd 或 ceph。 在每个节点上运行日志收集 Daemon，比如：flunentd 或 logstash。 在每个节点上运行监控 Daemon，比如：Prometheus Node Exporter 或 collectd。 DaemonSet 与 Deployment 的区别 Deployment 部署的副本 Pod 会分布在各个 Node 上，每个 Node 都可能运行好几个副本。 DaemonSet 的不同之处在于：每个 Node 上最多只能运行一个副本。 总结： DaemonSet这种控制器方式，主要是用来对node节点上面每个节点平均分配一个pod的，比如每个node节点上面运行的监控agent，或者是收集日志的agent。。。 -----------------------------------------------------------------------