namespace

LXC、LXD、Docker的区别与联系(by quqi99)

空扰寡人 提交于 2019-12-07 16:36:45
版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明 ( http://blog.csdn.net/quqi99 ) 容器 namespace技术用来进行做进程间的隔离,linux namespace包括:mount namespace, uts namespace, ipc namespace, pid namespace, network namespace, user namespace六种,用于将mount点、UTS(hostname, domain name)、IPC资源、进程、网络、用户等六种资源做到进程级别的隔离。容器作为一个普通的进程,使用namespace技术作隔离。 pivot_root根文件系统切换。mount –bind /etc /tmp/test/etc方式允许从任何其他位置访问任何文件或目录,但是其他用户仍然能看到这些mount点,而mount namespace可以做到mount点在各个进程之间隔离。尽管如此,目前没有对文件/目录做进程间隔离的namespace,所以有必要制作根文件系统再采用pivot_root命令在容器内替换为这个根文件系统(注:chroot只是在指定的根文件系统下运行命令)。 cgroups技术用来做资源限制,这些资源包括CPU、内存、存储、网络等。

Kubernetes核心原理笔记

杀马特。学长 韩版系。学妹 提交于 2019-12-07 16:20:29
                  kubernetes权威指南阅读笔记 笔记来自kubernetes权威指南,如需更详细的教程还请阅读原书,笔记只记录相关重要知识点,当然一下总结也包含一些自己的总结,有异议可以留言交流 Kubernetes API Server原理分析:   1.Kubernetes API Server通过一个进程名为kube-apiserver的进程提供服务,默认进程在本机端口(--insecure-port)提供REST 服务,同时通过HTTPS安全端口(--secure-port=6443)来启动安全机制   2.如果只想对外提供部分REST服务,则可以在master或者其他任何节点通过运行kubectl proxy进程启动一个内部代理实现,支持 --reject-paths、--accept=hosts 限制访问路径和访问来源   3.Kubernetes API Server最主要的REST接口是资源对象的 增、删、改、查 ,除此之外,它还提供了一类特殊的REST接口——Kubernetes Proxy API 接口,这类接口的作用是代理请求,即Kubernetes API Server把收到的REST请求转发到某个Node上的kubelet守护进程的REST端口上,由kubelet进程负责响应,部分接口列表:/api/v1/proxy/nodes/

Django对导航栏登录注册以及主页的优化

强颜欢笑 提交于 2019-12-07 06:28:37
一 优化导航栏 1 增加文章以及注册的入口,修改代码mysite/templates/header.html <!--模板中声明引入静态文件的标签,只有使用它,static标签才能使用--> {% load staticfiles %} <div class="container"> <nav class="navbar navbar-default" role="navigation"> <div class="navbar-header"> <a class="navbar-brand" href="https://blog.csdn.net/chengqiuming"><img src="{% static '/images/logo.png' %}" width="100px"></a> </div> <div> <ul class="nav navbar-nav" role="navigation"> <!--blog是urlpatterns中定义的namespace,blog_title是视图函数--> <li><a href="{% url 'blog:blog_title' %}">博客</a></li> <!-- 增加文章入口--> <li><a href="{% url 'article:article_titles' %}">文章</a></li> </ul>

k8s学习记录(二) 容器化部署学习记录

拥有回忆 提交于 2019-12-07 06:01:33
基本流程 物理vm先打通该服务 打docker镜像 docker run先跑起来 写yaml改造成k8s ref: 通过shell执行kubectl exec并在对应pod容器内执行shell命令 坑一 像ubuntu这种系统级应用,必须要在yaml文件里添加command与args使其持续化运行 1 apiVersion: apps/v1 2 kind: Deployment 3 metadata: 4 name: split-deployment 5 labels: 6 app: split 7 spec: 8 selector: 9 matchLabels: 10 app: splitVideo 11 replicas: 1 12 template: 13 metadata: 14 labels: 15 app: splitVideo 16 spec: 17 containers: 18 - name: split 19 image: registry.cn-shanghai.aliyuncs.com/graviti-devops/video-stream-split:latest 20 command: ["/bin/bash","-c","--"] 21 args: ["./splitVideo.sh","5","video/","graviti-spark-01",

关于using namespace 的一些体会

浪子不回头ぞ 提交于 2019-12-07 04:15:17
//test.h namespace myname { typedef int cin ; } // fig19_01.cpp // demonstrating string assignment and concatenation #include //#include #include "test.h" using namespace std; using namespace myname; //自己命名的一个空间 int main() { //string s1( "cat" ), s2, s3; char *s1="cat", *s2, *s3; s2 = s1; s3 = s1; //s3.assign( s1 ); std::cout<< "s1:" << s1 << "\ns2:" << s2 << "\ns3:" << s3 << endl; cout<< "this is a test, using namespace std "<> i; //这样用就会产生错误 error C2872: 'cin' : ambiguous symbol std::cout << i; return 0; } 名词空间namespace 1) namespace只能在全局范畴定义,但它们之间可以互相嵌套。 2) 在namespace定义的结尾,右大括号的后面不必要跟一个分号。 3

C++ 匿名namespace的作用以及它与static的区别

一笑奈何 提交于 2019-12-06 20:18:31
一、匿名namespace的作用 在C语言中,如果我们在多个tu(translation unit)中使用了同一个名字做为函数名或者全局变量名,则在链接阶段就会发生重定义错误,为了解决这个问题,我们可以在定义这些标识符(identifier)的时候加上static关键字修饰以限制它只在一个tu范围内可见。 C++继承了C语言中static关键字的这个用途,我们依旧可以使用static来避免多个tu中使用同一个标识符带来的重定义问题。此外C++还提供了另一种特有的方式,那就是匿名namespace:一个没有指定名字的namespace被称为一个匿名namespace;在一个tu中可以出现多个匿名namespace,并且相同层次的匿名namespace实际上被合成为同一个;出现在不同tu的匿名namespace中的相同标识符相互独立不会发生冲突,因此我们可以把那些只希望在同一个tu范围可见的全局标识符放入一个匿名namespace中,效果与前面加static相同。 二、匿名namespace与static的区别 一个全局标识符被static修饰后它的linkage变为internal linkage,这就是为什么不同tu中的相同标识符不会发生冲突的原因。 而匿名namespace却并不会改变在它内部定义的标识符的linkage,它用来避免名字冲突所采用的手段同C+

Thinkphp5.1 导入第三方包的问题

旧时模样 提交于 2019-12-06 18:59:30
一般刚接触tp5.1的,会很不适应,虽然版本号只是比5.0多了0.1,但是差别挺大,废弃了不少方法,官方的教程又很简单,很多东西没说全,在此鄙视一下框架作者,最起码体谅一下小白嘛,搞了好多天才把5.1使用vendor里面引入第三方包的问题搞好,惨啊,在此分享,让后来的小白别走太多弯路。 一、在thinkPHP 5.1.X新版取消了Loader::import方法以及import和vendor助手函数 ,推荐全面采用命名空间方式的类以及自动加载机制,如果必须使用请直接改为php内置的include或者require语法。(抱怨一下,这种问题要在官方文档里面说明一下嘛,鄙视作者,整5.1的时候这些方法挨个试了一遍,又是搜又是看教程结果全部卵用,无奈。) 原来的import("Vendor.Classes.PHPExcel.IOFactory");或Vendor('phpoffice.phpexcel.Classes.PHPExcel.IOFactory');方法已经不再使用。 二,在thinkPHP 5.1.X中的处理方法,必须使用composer方式安装第三方模块 。否则在vendor目录下的内容无法自动加载。也就是到了这一版必须用Composer,方法加载去掉了,其实这样也好,比较靠拢主流框架,比如laravel,如果用好TP5.1在转向laravel很容易,而且用工具管理包

Kubernetes NFS-Client Provisioner部署

允我心安 提交于 2019-12-06 18:24:10
部署NFS-Client Provisioner的初衷,就是为了根据PVC的需求自动创建符合要求的PV。 首先,必须拥有自己的NFS Server, 而且k8s集群能够正常访问之。 之后,在k8s master上应用以下yaml文件: 1 RBAC.yaml apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: default --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: nfs-client-provisioner-runner rules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] -

Kubernetes NFS-Client Provisioner部署

余生颓废 提交于 2019-12-06 18:24:03
部署NFS-Client Provisioner的初衷,就是为了根据PVC的需求自动创建符合要求的PV。 首先,必须拥有自己的NFS Server, 而且k8s集群能够正常访问之。 之后,在k8s master上应用以下yaml文件: 1 RBAC.yaml apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: default --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: nfs-client-provisioner-runner rules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] -

四 k8s里面部署java项目

徘徊边缘 提交于 2019-12-06 18:19:15
一 创建nfs(maste节点操作,两个node节点也需要安装) 1 首先安装一个nfs服务器,配置共享目录, [yx@tidb-tidb-02 ~]$ cat /etc/exports /home/yx/hnf *(rw,no_root_squash) 然后启动nfs 2 然后在master上面创建一个nfs pv的动态供给,需要三个文件class.yaml deployment.yaml rbac.yaml 这三个文件去网上下载 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy rbac是让nfs有权限访问apiserver,其中需要更改的地方是deploynment.yaml里面的nfsip地址和nfs所共享的目录 kubectl create -f rbac.yaml kubectl create -f class.yaml kubectl create -f deployment.yaml #第一次创建的时候回提示存在,不知道什么原因,然后删除,再次创建即可 最后查看是否创建成功 [yx@tidb-tidb-03 nfs]$ kubectl get pods NAME READY STATUS RESTARTS AGE nfs-client