openshift常用命令
该文档是在OCP3.9版本上操作
前奏
缩写表
OCP: OpenShift Container Platform(openshift容器平台)
SCC: Security Context Constraints
OCP中的project等于k8s中的namespace
集群管理
节点管理
[root@master ~]# oc login -u system:admin
[root@master ~]# oc project default
注：system:admin用户相当于win的administrator或linux的root用户，即拥有集群最高权限的用户，该用户只能在"本机"登录，不支持远程登录
# 在master节点上列出所有已知节点
[root@master ~]# oc get nodes
NAME STATUS ROLES AGE VERSION
master.lab.example.com Ready master 17d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 17d v1.9.1+a0ce1bc657
node2.lab.example.com Ready compute 17d v1.9.1+a0ce1bc657
# 列出单个节点的信息
[root@master ~]# oc get node node1.lab.example.com
NAME STATUS ROLES AGE VERSION
node1.lab.example.com Ready compute 17d v1.9.1+a0ce1bc657
# STATUS列释义
Ready 节点通过返回 StatusOK 来通过master节点执行的健康检查
NotReady 节点未通过主节点执行的健康检查
SchedulingDisabled 无法安排Pod放置在节点上
# 获取特定节点的更多信息
固定格式：oc describe node <NODE_NAME>
[root@master ~]# oc describe node node1.lab.example.com
Name: node1.example.com # 节点的名称
Roles: master # 节点的角色，要么master要么compute
Labels: beta.kubernetes.io/arch=amd64 # 应用于节点的标签
Annotations: volumes.kubernetes.io/controller-managed-attach-detach=true # 应用于节点的注释
Taints: <none> # 应用于节点的污点
Conditions: # 节点条件
Addresses: # 节点的IP地址和主机名
Capacity: # pod资源和可分配资源
System Info: # 有关节点主机的信息
....
Non-terminated Pods: (6 in total) # 节点上的 pod
# 删除节点
oc delete node <NODE_NAME>
# 检查该节点是否已从节点列表中删除
oc get nodes
注：删除节点后将只为处于节点状态是Ready的节点上调度Pod
# 更新节点上的标签
oc label -h
oc label node <NODE_NAME> <KEY1>=<VALUE1> <KEY2>=<VALUE2> <KEY3>=<VALUE3>
# 列出节点上的pod
## 列出一个或多个节点上的所有或选定的pod：
格式：oc adm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
示例：[root@master ~]# oc adm manage-node node1.lab.example.com --list-pods
Listing matched pods on node: node1.lab.example.com
NAMESPACE NAME READY STATUS RESTARTS AGE
default docker-registry-2-4xjp6 1/1 Running 1 4h
default router-2-4whd8 1/1 Running 4 2d
farm mysql 1/1 Running 1 4h
openshift-ansible-service-broker asb-1-deploy 0/1 Error 0 17d
openshift-template-service-broker apiserver-65cdn 1/1 Running 8 17d
raleigh hello-1-build 0/1 Completed 0 4h
## 列出选定节点上的所有或选定的pod：
oc adm manage-node --selector=<node_selector> \
--list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
# 将节点标记为不可调度或可调度
## 将一个或多个节点标记为不可调度：
格式：oc adm manage-node <node1> <node2> --schedulable=false
示例：oc adm manage-node node1.lab.example.com --schedulable=false
## 要将当前不可调度的一个或多个节点标记为可调度：
格式：oc adm manage-node <node1> <node2> --schedulable
或者
oc adm manage-node <node1> <node2> --schedulable=true
撤离节点上的pod
撤离pod允许您从给定节点迁移所有或选定的pod。必须首先将节点标记为不可调度才能执行pod疏散
撤离节点上的所有或选定的pod：
oc adm drain <node> [--pod-selector=<pod_selector>]
可使用--force选项强制删除裸pod，当--force=true时即使存在不受RC、ReplicaSet、job、daemonset 或 StatefulSet 管理的pod也会继续删除
oc adm drain <node> --force=true
可使用--grace-period以秒为单位设置每个pod正常终止的时间段。如为负数则使用pod中指定的默认值：
oc adm drain <node> --grace-period=-1
可使用--ignore-daemonsets并将其设置true来忽略daemonset管理的pod：
oc adm drain <node> --ignore-daemonsets=true
可使用--timeout设置放弃前等待的时间长度(0是无限长)
oc adm drain <node> --timeout=5s
可使用--delete-local-data并将其设置为true以继续删除，即使有使用emptyDir的pod（节点耗尽时删除的本地数据）：
oc adm drain <node> --delete-local-data=true
列出不实际执行撤离情况下迁移的对象(就是探测性的跑一次而不真正执行)
格式：oc adm drain <node> --dry-run=true
[root@master ~]# oc adm drain node1.lab.example.com --dry-run=true
node "node1.lab.example.com" cordoned (dry run)
node "node1.lab.example.com" drained (dry run)
可使用--selector=<node_selector>选项来撤出与选择器匹配的节点上的pod，而不是指定特定的节点名称
### 重启节点
```shell
要重新启动节点而不导致平台上运行的应用程序中断，首先撤离pod很重要。
对于路由层高度可用的Pod，不需要做任何其他事情。对于需要存储的其他Pod，通常是数据库，确保它们可以在一个Pod暂时离线的情况下保持运行至关重要。
虽然每个应用程序为有状态的Pod实现弹性是不同的，但在所有情况下，配置调度程序以使用节点反关联性以确保 Pod正确分布在可用节点之间是很重要的
基础设施节点
基础设施节点是标记为运行 OCP环境部分的节点。目前，管理节点重启的最简单方法是确保至少有三个节点可用于运行基础架构。
以下场景演示了一个常见错误，当只有两个节点可用时，该错误可能导致在OCP上运行的应用程序服务中断。
1、节点A被标记为不可调度，并且所有pod都被撤离
2、在该节点上运行的registry pod现在重新部署在节点B上。这意味着节点B现在正在运行两个registry pod
3、节点B现在被标记为不可调度并被疏散
4、暴露节点B上的两个pod端点的服务会在短时间内丢失所有端点，直到它们重新部署到节点A
使用三个基础设施节点的相同过程不会导致服务中断。但由于pod调度，最后一个被撤离并重新进入轮换状态的节点将运行零registrys
其他两个节点将分别运行两个和一个registries。最好的解决方案是依靠pod反亲和。这是K8s中的一个功能
#### 使用pod反亲和性
```shell
Pod反亲和性 和 节点反亲和性 稍有不同。
如果没有其他合适的位置来部署pod，则可能违反节点反亲和性
Pod反亲和性可以设置为必需或首选
示例
apiVersion: v1
kind: Pod
metadata:
name: with-pod-antiaffinity
spec:
affinity:
podAntiAffinity: # 用于配置pod反关联性的Stanza
preferredDuringSchedulingIgnoredDuringExecution: # 定义首选规则
- weight: 100 # 指定首选规则的权重。最高权重的节点是首选
podAffinityTerm:
labelSelector:
matchExpressions:
- key: docker-registry # 确定何时应用反关联性规则的pod标签的描述。指定标签的键和值
operator: In # 运算符表示现有pod上的标签与matchExpression新pod规范中参数中的一组值之间的关系(In、NotIn、Exists、DoesNotExist)
values:
- default
topologyKey: kubernetes.io/hostname
配置释义：
此示例假设Docker registry pod的标签为docker-registry=default。Pod反亲和性可使用任何Kubernetes匹配表达式
最后一步是在/etc/origin/master/scheduler.json中的predicates部分启用 MatchInterPodAffinity 调度程序
有了这个，如果只有两个基础设施节点可用并且一个重新启动，则Docker registry pod将被阻止在另一个节点上运行
oc get pods 将pod报告为未就绪，直到有合适的节点可用。一旦一个节点可用并且所有pod都回到就绪状态，就可以重新启动下一个节点
设置每个节点的最大pod数
在/etc/origin/node/node-config.yaml文件中，两个参数控制一个节点可以调度的最大pod数量：pods-per-core 和 max-pods
当这两个选项同时使用时，两者中较低者会限制节点上的pod数量。超过这些值可能会导致：
1、提高了 OCP 和 Docker 上的 CPU 利用率
2、缓慢的 pod 调度
3、潜在的内存不足情况（取决于节点中的内存量）
4、耗尽IP地址池
5、资源过度使用，导致用户应用程序性能不佳
pods-per-core根据节点上的处理器内核数设置节点可运行的pod数。例如，如果在4核的节点上pods-per-core设置为10，则该节点上允许的最大pod数将为40
kubeletArguments:
pods-per-core:
- "10" # 为0会禁用此限制
max-pods将节点可以运行的pod数量设置为固定值，而不管节点的属性如何。Cluster Limits记录了max-pods
kubeletArguments:
max-pods:
- "250"
重置docker存储
当您下载Docker映像并运行和删除容器时，Docker并不总是释放映射的磁盘空间。因此随着时间的推移会耗尽节点上的空间，这可能会阻止OCP创建新的pod或导致创建pod需要几分钟时间
例如，以下显示了6分钟后仍处于 ContainerCreating 状态的pod，并且事件日志显示了FailedSync事件
$ oc get pod
NAME READY STATUS RESTARTS AGE
cakephp-mysql-persistent-1-build 0/1 ContainerCreating 0 6m
mysql-1-9767d 0/1 ContainerCreating 0 2m
mysql-1-deploy 0/1 ContainerCreating 0 6m
$ oc get events
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
6m 6m 1 cakephp-mysql-persistent-1-build Pod Normal Scheduled default-scheduler Successfully assigned cakephp-mysql-persistent-1-build to ip-172-31-71-195.us-east-2.compute.internal
2m 5m 4 cakephp-mysql-persistent-1-build Pod Warning FailedSync kubelet, ip-172-31-71-195.us-east-2.compute.internal Error syncing pod
2m 4m 4 cakephp-mysql-persistent-1-build Pod Normal SandboxChanged kubelet, ip-172-31-71-195.us-east-2.compute.internal Pod sandbox changed, it will be killed and re-created.
此问题的一种解决方案是重置Docker存储以删除Docker不需要的artifacts
1、在要重启Docker存储的节点上将节点标记为不可调度:
oc adm manage-node <node> --schedulable=false
2、关闭Docker 和 atomic-openshift-node服务：
systemctl stop docker atomic-openshift-node
3、删除本地卷目录：
rm -rf /var/lib/origin/openshift.local.volumes
注：该命令清除本地image缓存，因此需要重新提取image，包括ose-* images。这可能会导致映像存储恢复时pod启动时间变慢
4、删除/var/lib/docker目录：
rm -rf /var/lib/docker
5、重置 Docker 存储：
docker-storage-setup --reset
6、重新创建Docker存储：
docker-storage-setup
7、重新创建/var/lib/docker目录：
mkdir /var/lib/docker
8、重启 Docker 和atomic-openshift-node服务：
systemctl start docker atomic-openshift-node
9、将节点标记为可调度：
oc adm manage-node <node> --schedulable=true
管理用户
用户是与OCP API交互的实体。这些可是开发人员或管理集群的管理员。可以将用户分配到组，从而设置应用于所有组成员的权限。
例如可授予组API访问权限，从而授予组的所有成员API访问权限
本节介绍用户帐户的管理，包括如何在OCP中创建新用户帐户以及如何删除它们
创建一个新用户，然后为该用户添加一个角色：
**** 这里和官方的不同，待定 ****
获取当前用户列表：
[root@master ~]# oc get user
NAME UID FULL NAME IDENTITIES
joe 4fabb703-2f44-11ed-84b2-52540000fa0a htpasswd_auth:joe
lene 535565ed-2f44-11ed-84b2-52540000fa0a htpasswd_auth:lene
获取当前的identities列表：
[root@master ~]# oc get identity
NAME IDP NAME IDP USER NAME USER NAME USER UID
htpasswd_auth:joe htpasswd_auth joe joe 4fabb703-2f44-11ed-84b2-52540000fa0a
htpasswd_auth:lene htpasswd_auth lene lene 535565ed-2f44-11ed-84b2-52540000fa0a
# 创建组
虽然用户是向OCP发出请求的实体，但可将用户组织成一个或多个由一组用户组成的组。组对于一次管理多个用户很有用，例如授权策略或一次向多个用户授予权限
手动创建组：
格式：oc adm groups new <group_name> <user1> <user2>
示例：oc adm groups new ceshi joe lene
验证：
[root@master ~]# oc get group
NAME USERS
ceshi joe, lene
删除成员：
[root@master ~]# oc adm groups remove-users ceshi lene
[root@master ~]# oc get group
NAME USERS
ceshi joe
删除组：
[root@master ~]# oc delete group ceshi
[root@master ~]# oc get group
No resources found.
为用户或组添加标签：
格式：oc label user/<user_name> <label_name>
如果用户名是theuser并且标签是level=gold：
示例：oc label user/theuser level=gold
删除标签
oc label user/<user_name> <label_name>-
显示用户或组的标签
oc describe user/<user_name>
删除一个用户
oc delete user joe
删除用户身份
用户的身份与您使用的标识提供者有关。从oc get user中的用户记录中获取提供者名称
[root@master ~]# oc get user
NAME UID FULL NAME IDENTITIES
joe 4fabb703-2f44-11ed-84b2-52540000fa0a htpasswd_auth:joe
lene 535565ed-2f44-11ed-84b2-52540000fa0a htpasswd_auth:lene
如下示例中，身份提供者名称为htpasswd_auth：
oc delete identity htpasswd_auth:joe
重点：
如果您跳过此步骤则用户将无法再次登录
如完成这些步骤后，当用户再次登录时将在OCP中创建一个新帐户
如果您是想阻止用户再次登录（例如员工离开公司并且您想永久删除帐户），您还可以从身份验证后端删除用户（如htpasswd、kerberos或其他）用于配置的身份提供者
例如，如果您使用的是htpasswd则删除OCP配置的htpasswd文件中包含用户名和密码的条目
[root@master ~]# cat /etc/origin/master/htpasswd
joe:$apr1$zRbqvtna$esVozt8ceWh1ZXbHoaqef0 # 删除需要删除的用户即可
lene:$apr1$uanqgxEV$FxF/jDHyF.yo2B9yfUpjg0
配置服务账户
服务帐户是存在于每个项目中的API对象。要管理服务帐户可使用带有sa 或 serviceaccount 对象类型的 oc 命令或使用 Web 控制台
获取当前项目中现有服务帐户的列表：
[root@master ~]# oc project all
[root@master ~]# oc project
Using project "default" on server "https://master.lab.example.com:443".
[root@master ~]# oc get sa
NAME SECRETS AGE
builder 2 18d
default 3 18d
deployer 2 18d
registry 3 18d
router 2 18d
[root@master ~]# oc project samples
Now using project "samples" on server "https://master.lab.example.com:443".
[root@master ~]# oc get sa
NAME SECRETS AGE
builder 2 18h
default 2 18h
deployer 2 18h
创建新的服务帐户：
[root@master ~]# oc create sa robot
注：创建服务帐户后，会自动向其中添加两个secrets：
1、API令牌
2、OpenShift Container Registry的凭据
查看服务帐户：
[root@master ~]# oc describe sa robot
# 启用服务帐户身份验证
服务帐户使用由私有 RSA 密钥签名的令牌对 API 进行身份验证。身份验证层使用匹配的公共 RSA 密钥验证签名
要启用服务帐户令牌生成，请更新主服务器上 /etc/origin/master/master-config.yml 文件中的 serviceAccountConfig 节以指定 privateKeyFile（用于签名）和 publicKeyFiles 列表中的匹配公钥文件：
serviceAccountConfig:
...
masterCA: ca.crt # 用于验证 API 服务器的服务证书的 CA 文件
privateKeyFile: serviceaccount.private.key # 私有RSA密钥文件（用于令牌签名）
publicKeyFiles:
- serviceaccount.public.key # 公共RSA密钥文件(用于令牌验证)。如果提供了私钥文件则使用公钥组件。可指定多个公钥文件，如可通过其中一个公钥验证令牌则将接受该令牌。这允许签名密钥的轮换，同时仍接受前一个签名者生成的令牌
管理安全上下文约束
安全上下文约束允许管理员控制Pod的权限,您必须具有 集群管理员 权限才能管理SCC
列出SCC的当前列表：
[root@master ~]# oc get scc # 共7种
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES
anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny 10 false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
hostaccess false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret]
hostmount-anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret]
hostnetwork false [] MustRunAs MustRunAsRange MustRunAs MustRunAs <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
nonroot false [] MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
privileged true [*] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [*]
restricted false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
# 检查安全上下文约束对象
查看有关特定SCC的信息，包括SCC应用于哪些用户、服务帐户和组
格式：oc describe scc <7种当中任意一种>
[root@master ~]# oc describe scc restricted
Name: restricted
Priority: <none>
Access:
Users: <none> # 列出SCC应用于哪些用户和服务帐户
Groups: system:authenticated # 列出SCC应用于哪些组
Settings:
Allow Privileged: false
Default Add Capabilities: <none>
....
....
# 授予对特权SCC的访问权限
某些情况下管理员可能希望允许管理员组之外的用户或组访问以创建更多特权pod。为此您可以：
1、确定您希望有权访问SCC的用户或组
仅当用户直接创建 Pod 时才向用户授予访问权限。 对于代表用户创建的 Pod，在大多数情况下由系统本身创建，应授予对相关控制器进行操作的服务帐户的访问权限。
代表用户创建 pod 的资源示例有 Deployment、StatefulSet、DaemonSet 等。
2、示例
$ oc adm policy add-scc-to-user <scc_name> <user_name>
$ oc adm policy add-scc-to-group <scc_name> <group_name>
注：scc_name是7种当中的一种，user_name是普通用户或特权用户
# 例如要允许e2e用户访问privileged这个SCC
oc adm policy add-scc-to-user privileged e2e-user
# 授予服务帐户对特权 SCC 的访问权限
首先创建一个服务帐户。 例如要在myproject项目中创建服务帐户mysvcacct：
$ oc create serviceaccount mysvcacct -n myproject
然后将服务帐户mysvcacct添加到特权SCC
oc adm policy add-scc-to-user privileged system:serviceaccount:myproject:mysvcacct
另一种格式：
oc adm policy add-scc-to-user anyuid -z <SERVICEACCOUNT_NAME> -n <PROJECT_NAME>
命令释义：
[root@master ~]# oc adm policy add-scc-to-user --help
-z, --serviceaccount=[]: service account in the current namespace to use as a user
当前命名空间中的服务帐户作为用户使用
.
.
.
.
游走在各发行版间老司机QQ群：905201396
不要嫌啰嗦的新手QQ群：756805267
Debian适应QQ群：912567610
