|
本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文,但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况,请以原始 英文 版本为准,且原始英文版本为权威文本。 |
所需权限
服务到服务的身份验证和授权
为了允许 SUSE Observability 服务之间的通信,SUSE Observability 使用 Kubernetes 服务账户。为了能够验证它们的有效性和角色,helm 图表创建了一个 ClusterRole 和一个 ClusterRoleBinding 资源。创建这些集群范围的资源通常不允许非 Kubernetes/OpenShift 管理员的用户进行。在这种情况下,可以禁用创建,而需要由您的集群管理员手动 创建角色和角色绑定。
禁用集群范围资源的自动创建
在安装 SUSE Observability 时,可以通过将以下部分添加到用于安装 SUSE Observability 的 values.yaml 文件中来禁用集群范围资源的自动创建:
-
values.yaml
cluster-role:
enabled: false
|
如果已禁用集群角色和集群角色绑定的创建,请确保按照以下说明使用 以下说明 手动创建它们。 |
手动创建集群范围资源
如果您需要手动创建集群范围资源,请请求您的 Kubernetes/OpenShift 管理员在集群中创建以下 3 个资源。
|
请验证您为两个 |
-
clusterrolebinding-authentication.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: suse-observability-authentication
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- kind: ServiceAccount
name: suse-observability-api
namespace: suse-observability
Pod 安全标准
如果您的 Kubernetes 集群启用了 Pod 安全标准,您需要为 suse-observability 名称空间配置适当的安全策略。SUSE Observability 需要基线 Pod 安全标准才能正常运行。
配置 Pod 安全标准
将基线 Pod 安全标准应用于 suse-observability 名称空间:
kubectl label ns suse-observability pod-security.kubernetes.io/enforce=baseline --overwrite
kubectl label ns suse-observability pod-security.kubernetes.io/audit=baseline --overwrite
kubectl label ns suse-observability pod-security.kubernetes.io/warn=baseline --overwrite
|
如果在您的集群中启用了 Pod 安全标准,您必须确保在部署 SUSE Observability 之前正确配置 Elasticsearch 的先决条件。
由于基线 Pod 安全标准不允许特权容器,您需要按照 说明 在主机级别配置所需的 |
Elasticsearch
SUSE Observability 使用 Elasticsearch 存储其索引。Elasticsearch 运行的节点有一些额外的要求。
由于 vm.max_map_count Linux 系统设置通常低于 Elasticsearch 启动所需的值,因此使用了一个以特权模式运行并作为 root 用户的初始化容器。默认情况下启用 init 容器,以允许更改 vm.max_map_count 系统设置。
禁用特权 Elasticsearch init 容器
如果您或您的 Kubernetes/OpenShift 管理员不希望默认启用特权 Elasticsearch init 容器,可以在用于安装 SUSE Observability 的 values.yaml 文件中禁用此行为:
-
values.yaml
elasticsearch:
sysctlInitContainer:
enabled: false
|
如果禁用此选项,您需要确保将 |
要检查当前的 vm.max_map_count 设置,请运行以下命令。请注意,它运行的是一个特权 Pod:
kubectl run -i --tty sysctl-check-max-map-count --privileged=true --image=busybox --restart=Never --rm=true -- sysctl vm.max_map_count
如果当前 vm.max_map_count 设置低于 262144,则需要以其他方式增加该值,否则 Elasticsearch 将无法启动,其 Pod 将进入重启循环中。日志将包含如下错误消息:
bootstrap checks failed
max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
增加 Elasticsearch 的 Linux 系统设置
根据您的 Kubernetes/OpenShift 管理员的偏好,可以通过更改默认节点配置(例如通过 init 脚本)或让 DaemonSet 在节点启动后立即执行此操作,将 vm.max_map_count 设置为所有节点的更高默认值。前者非常依赖于您的集群设置,因此没有通用解决方案。
以下是一个可以用作 DaemonSet 更改 vm.max_map_count 设置的起始点的示例:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: set-vm-max-map-count
namespace: kube-system
labels:
k8s-app: set-vm-max-map-count
spec:
selector:
matchLabels:
name: set-vm-max-map-count
template:
metadata:
labels:
name: set-vm-max-map-count
spec:
# Make sure the setting always gets changed as soon as possible:
tolerations:
- effect: NoSchedule
operator: Exists
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
# Optional node selector (assumes nodes for Elasticsearch are labeled `elasticsearch:yes`
# nodeSelector:
# elasticsearch: yes
initContainers:
- name: set-vm-max-map-count
image: busybox
securityContext:
runAsUser: 0
privileged: true
command: ["sysctl", "-w", "vm.max_map_count=262144"]
resources:
limits:
cpu: 100m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
# A pause container is needed to prevent a restart loop of the pods in the daemonset
# See also this Kubernetes issue https://github.com/kubernetes/kubernetes/issues/36601
containers:
- name: pause
image: busybox
command: ["sleep", "infinity"]
resources:
limits:
cpu: 50m
memory: 50Mi
requests:
cpu: 50m
memory: 50Mi
为了限制应用于节点的数量,可以对节点进行标记。然后,可以在此 DaemonSet 和 Elasticsearch 部署上设置 NodeSelectors,仅在具有特定标签的节点上运行。对于 Elasticsearch,可以通过以下值指定节点选择器:
elasticsearch:
nodeSelector:
elasticsearch: yes
sysctlInitContainer:
enabled: false