rbac

为了便于将集群中的服务暴露到集群外部，需要使用Ingress。接下来使用Helm将Nginx Ingress部署到Kubernetes上。 Nginx Ingress Controller被部署在Kubernetes的边缘节点上。 这里将 master 作为边缘节点，打上 label [root@master /]# kubectl label node master node-role.kubernetes.io/edge= node/master labeled [root@master /]# kubectl get nodes NAME STATUS ROLES AGE VERSION master Ready edge,master 4d3h v1.15.1 slaver1 Ready <none> 4d2h v1.15.1 slaver2 Ready <none> 4d2h v1.15.1 安装 使用 yaml 配置文件安装 stable/nginx-ingress chart的值文件ingress-nginx.yaml如下： controller: replicaCount: 1 hostNetwork: true nodeSelector: node-role.kubernetes.io/edge: '' affinity: podAntiAffinity:

备份应用程序和数据是组织经常需要处理的事情。尽管Kubernetes可以确保应用程序服务的高可用性和可伸缩性，但这些好处并不能有效地保护数据。因此，必须对Kubernetes应用程序进行数据管理和备份，并应将其纳入标准操作流程中。 但是，备份Kubernetes应用程序需要一种独特的方法，该方法与传统的备份解决方案大不相同。使用Kubernetes，经常会将应用程序部署在集群中跨节点的多个容器中，要备份应用程序以及数据和存储量，你需要考虑所有各种Kubernetes对象和配置数据，还必须适应应用程序快速的开发和部署周期，DevOps的“左移(shift-left)”理念，数据保护，安全要求等。 鉴于这些独特的要求，备份Kubernetes似乎是一项艰巨的任务，但是你可以采取一些步骤来简化该过程。以下是五个最佳做法： 1.考虑Kubernetes架构 一个典型的Kubernetes应用程序由数百个组件组成-Pod，服务(service)，证书，密钥(secret)等等。任何Kubernetes备份解决方案不仅要能够备份和还原数据，而且还要能够备份和还原所有这些组件。至关重要的是，备份解决方案要通过API自动与Kubernetes控制平面进行交互，以便不仅能够发现集群上运行的Kubernetes应用，而且还可以与基础计算，网络和存储基础架构集成。 存储也是一个重要的考虑因素

还是没学会 今天继续研究. Using Helm NGINX Ingress controller can be installed via Helm using the chart stable/nginx from the official charts repository. To install the chart with the release name my-nginx : helm install stable/nginx-ingress --name my-nginx If the kubernetes cluster has RBAC enabled, then run: helm install stable/nginx-ingress --name my-nginx -- set rbac.create= true 好像不管用呢... 试过了 不太行 貌似. 来源： oschina 链接： https://my.oschina.net/u/4316097/blog/3863962

网上的方法一般都是 fuser -m /nfs 查出进程号，然后杀死进程号，或者fuser -km /nfs直接杀死，我试了下都不行 解决方法： 对于nfs文件系统来说，umount -l /nfs 关于fuser介绍： 用途 使用文件或文件结构识别进程。 语法 fuser [[ -c | -C | -f ] [ -x ] | -d ] [ -k | -K { SignalNumber | SignalName }] [ -u ] [ -V ] File ... 描述 此 fuser 命令列示了本地进程的进程号，那些本地进程使用 File 参数指定的本地或远程文件。对于阻塞特别设备，此命令列示了使用该设备上任何文件的进程。 每个进程号后面都跟随一个字母，该字母指示进程如何使用文件。 项目 描述 c 将此文件作为当前目录使用。 e 将此文件作为程序的可执行对象使用。 r 将此文件作为根目录使用。 s 将此文件作为共享库（或其他可装入对象）使用。 进程号被写入标准输出（在进程号之间有空格的行中）。一个换行符被写入标准错误（在每个文件操作数的最后一个输出之后）。其他所有输出被写入标准错误。 此 fuser 命令不会检测有 mmap 区域的进程，其中相关的文件描述符已从此被关闭。而且直到 FIFO（命名管道）完全打开，才会检测使用 FIFO 的进程。例如，执行 fuser

注意：以下的命令都是在kubernetes 1.15中执行的，如果是其他版本，不保证效果。 1、创建kubernetes-dashboard服务和对应的pod kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml 如果发现该链接失效，请访问 https://github.com/kubernetes/dashboard ，然后查找最新的链接。 2、查看创建的服务和pod 3、重新创建一个可以供外网访问的Service # cat kubernetes-dashboard.yaml apiVersion: v1 kind: Service metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kube-system spec: clusterIP: 10.97.14.63 externalTrafficPolicy: Cluster ports: - nodePort: 30443 port: 443 protocol: TCP targetPort: 8443

Java开发企业级权限管理系统 download： 百度云盘 全程手把手带你运用Java技术栈，打造一套基于最流行的RBAC拓展模型的，分布式的，有界面的，高灵活性，高拓展性的企业级权限管理系统。学完本课程你将可以轻松应对绝大多数企业开发中与权限管理及后台系统相关的需求。 技术储备要求 后端技术要求：有SSM、Maven、Redis基础 前端技术要求：有jQuery、Bootstrap、Mustache、zTree、Duallistbox基础 课程目錄 ： 第1章 课程整體概述（購置套餐更劃算） 本章首先引見爲什麼大公司都有權限管理係統，然後會對權限管理中盛行的RBAC模型及拓展做重點阐明，並給出理想中的權限管理係統應該是什麼樣子的。之後會對這門课程做總體内容引見與课程佈置，最後會引見這門课程會觸及到的技術，讓大家明白理解到這門课程到底能收獲些什麼（课程提供QQ交流群）。... 1-1 课前必讀（不看會錯過一個億） 1-2 课程導學試看 1-3 爲什麼企業級項目需求權限管理試看 1-4 權限管理的中心是什麼？ 1-5 理想中的權限管理應該是什麼樣的？試看 1-6 主流開源權限管理框架有哪些？ 1-7 课程佈置與學問點引見 第2章 Spring Security權限框架理論與實戰演練 本章首先讓大家學習到Spring Security權限框架的架構，之後大家能夠學習到Spring

至少两台机器。推荐4X16。（完全安装KubeSphere会吃掉10G+内存） k8s安装（略1.14.8）可参考我上一篇文章或者基于kubeadmin快速安装 KubeSphere2.1前置条件 1.k8s版本必须小于1.6大于等于1.13 我选择的是1.14.8 2.helm必须大于等于2.10 小于2.16 我选择2.15.2 安装流程： 1.helm安装（master节点） wget https://get.helm.sh/helm-v2.15.2-linux-amd64.tar.gz tar zxvf helm-v2.15.2-linux-amd64.tar.gz cd liniux-amd64 mv helm /usr/local/bin 2.tiller安装（master节点） kubectl -n kube-system create serviceaccount tiller kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller helm init --service-account tiller --skip-refresh --tiller-image registry.cn-shanghai

Role: kind : Role apiVersion : rbac.authorization.k8s.io/v1 metadata : namespace : gauss name : gauss-op rules : - apiGroups : [ "*" ] resources : [ "*" ] verbs : [ "*" ] RoleBinding: kind : RoleBinding apiVersion : rbac.authorization.k8s.io/v1 metadata : name : bach-gauss-rb namespace : gauss subjects : - kind : ServiceAccount name : bach-gauss roleRef : kind : Role name : gauss-op apiGroup : rbac.authorization.k8s.io ClusterRole: apiVersion : rbac.authorization.k8s.io/v1alpha1 kind : ClusterRole metadata : name : cluster-read-all rules : - apiGroups : - "" - apps - autoscaling - batch -

[toc] RBAC: Role-Based Access Control，基于角色的权限控制，有以下三种角色 Role：角色，定义了一组API对象的操作权限 Subject：被作用者，可以是人，也可以是机器，也可以是k8s的用户，最常使用的就是ServiceAccoun RoleBinding：定义了Subject和Role的绑定关系 简单地说，RoleBinding指定ServiceAccount对应的Role，Pod绑定这个ServiceAccount获得挂载的secret访问APIServrer，ApiServer验证相应的权限 Pod使用RBAC示例 演示pod使用绑定了Roler的ServiceAccount示例 1.创建一个ServiceAccount apiVersion: v1 kind: ServiceAccount metadata: namespace: default name: cqh 2.创建一个Role kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: cqh rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]