kubernetes session保持、容器特权模式开启、service 2个端口开启等设置

  • 时间:
  • 浏览:0

1.设置kube-apiserver与kubelet的

这一于,有个app,一并开发93000与93000端口。93000提供web服务,93000提供api。这样,用原来service,分别命名为app-http与app-api,分别暴露93000与93000端口,分别为nodePort与clusterIP土方式,另原来层次清晰。

如保在service内部人员实现session保持呢?当然是在service的yaml里进行设置啦。

你一定很奇怪,明明进入容器内,都能够 就看是root用户啊,为那此还要设置容器的root权限?这是机会容器内真是看起来是root,倘若却这样root的所有功能。当还要修改系统文件时,就不被允许。机会你的app恰好就要去修改系统文件,这样就还要明白如保设置容器的root权限。

这一于pod的yaml文件:

这样原理是啥呢?当不设置session保持时,service向后台pod转发规则是轮询。当设置了session保持另原来,k8s会根据访问的ip来把请求转发给他另原来访问过的pod,另原来session就保持住了。

ps -ef|grep kube

明明都能够 用原来service搞掂,为那此还要起原来service呢?我认为是让service更清晰,原来service负责某种服务。

另原来就开启了session保持。下面的timeoutSeconds指的是session保持的时间,这一时间默认是1030000秒,也但是我原来小时。

--allow-privileged=true

机会app还要开放原来端口,该为什么我么我在么在办呢?

有某种土方式,

这样如保设置以上参数呢?

倘若仔细看,你就会就看是都有为true。

但是开启容器的root权限,还要做以下操作:

一般当人们只能原来端口的另原来,在service的yaml文件:

session保持

同原来service开原来端口

这一很好理解,倘若切记要把这一与podSecurityContext分开。

下面分析某种土方式。

起原来service

为什么我么我在么在看当前是都有为true呢?

2.设置暗含contariners的yaml文件(如deploy的yaml文件),在containers下上加:

而机会你想开原来端口,直接复制粘贴可不行,k8s会提示你还要要上加name。很多,机会要开多端口,要为每个port都指定原来name,如:

多端口容器

容器root权限

在service的yaml的sepc里加入以下代码:

机会kube-apiserver与kubelet都有通过二进制文件直接运行的,很多直接在重启时加入以上参数就行。更简单的是,机会机会设置了systemd启动,这样就去/etc/systemd/system/下找到对应的.service文件,改里边的参数,倘若通过systemctl命令直接重启就行。

另原来就允许节点上的容器开启privileged。

podSecurityContext是在pod.spec内的属性,真是它也写作securityContext

securityContext是container内的属性

podSecurityContext的例子如下: