ServiceNow 배포를 위해 Kubernetes 가시성 에이전트 인스턴스와 Kubernetes 클러스터를 준비합니다.
시작하기 전에
- 다음 애플리케이션이 설치되고 활성화되었는지 확인합니다.
- 디스커버리 및 서비스 매핑 패턴
- 최신 버전 가시성용 에이전트 클라이언트 수집기 - 콘텐츠
- Kubernetes 명령줄 도구 kubectl이 설치되어 있고 클러스터와 통신하도록 구성되어 있는지 확인합니다. 자세한 내용은 kubectl 설명서를 참조하십시오.
- Helm 차트를 사용하여 설치하려는 경우 Helm 도구를 사용할 수 있는지 확인합니다. 자세한 내용은 Helm 설명서를 참조하십시오.
필요한 역할: ServiceNow 인스턴스에서 수행하는 단계에 대한 관리자
프로시저
-
ServiceNow 인스턴스에서 .
-
최소한 discovery_admin 역할을 가진 사용자를 만들거나 선택합니다.
-
Kubernetes 클러스터에서 배포할 Kubernetes 가시성 에이전트네임스페이스를 선택하거나 생성합니다.
네임스페이스를 만들려면 다음을 수행합니다.
- kubectl 명령줄 도구를 엽니다.
- NAMESPACE를 관련 값으로 바꾼 후 다음 명령을 실행합니다.
kubectl create namespace NAMESPACE
-
ServiceNow 인스턴스에 액세스하는 데 필요한 ServiceNow 자격 증명이 포함된 Kubernetes 비밀을 만듭니다.
주: 자격 증명이 이전 단계에서 만들거나 식별한 사용자와 일치하는지 확인합니다.
- kubectl 명령줄 도구를 엽니다.
- INSTANCE_NAME, USERNAME, PASSWORD 및 NAMESPACE를 관련 값으로 바꾼 후 다음 명령을 실행합니다.
kubectl create secret generic k8s-informer-cred-INSTANCE_NAME --from-literal=.user=USERNAME --from-literal=.password=PASSWORD -n NAMESPACE
주:
- 인포머가 프록시 서버를 통해 ServiceNow 인스턴스에 연결하는 경우 .proxyUser 및 .proxyPassword 키를 비밀에 추가하여 프록시 사용자와 암호를 제공할 수 있습니다. 예:
kubectl create secret generic k8s-informer-cred-INSTANCE_NAME --from-literal=.user=USERNAME --from-literal=.password=PASSWORD --from-literal=.proxyUser=PROXY_USER --from-literal=.proxyPassword=PROXY_PASSWORD -n NAMESPACE.
.proxyUser Kubernetes 가시성 에이전트 를 제공하지 않으면 인증이 필요하지 않다고 가정합니다. .proxyUser를 제공하고 .proxyPassword는 제공하지 않으면 시스템이 로그에 오류를 반환하고 인포머를 중단합니다.
- 조직에서 Amazon Elastic Kubernetes Service(EKS)를 사용하는 경우 AWS Secrets Manager에 비밀을 저장할 수 있습니다. 그러면 인포머가 ServiceNow Secrets Manager에서 AWS 인스턴스에 액세스하는 데 필요한 자격 증명을 가져옵니다. 자세한 내용은 Now Support 지식베이스의 CNO for Visibility: AWS Secrets Manager에 인스턴스 자격 증명 저장 [KB1581074] 문서를 참조하십시오.
- 조직에서 AKS(Azure Kubernetes 서비스)를 사용하는 경우 Key Vault에 비밀을 Microsoft Azure 저장할 수 있습니다. 그러면 인포머가 Azure Key Vault에서 인스턴스에 액세스하는 데 필요한 ServiceNow 자격 증명을 가져옵니다. 자세한 내용은 Now Support 지식베이스의 Microsoft Azure Key Vault에 인스턴스 자격 증명 저장 [KB1647736] 문서를 참조하십시오.
- 조직에서 를 사용하는 Google Kubernetes Engine(GKE)경우 Secret Manager에 Google Cloud 비밀을 저장할 수 있습니다. 그러면 인포머가 비밀 관리자에서 Google Cloud 인스턴스에 액세스하기 위한 자격 증명을 가져옵니다ServiceNow. 자세한 내용은 기술 자료의 CNO for Visibility: Google Cloud Secret Manager[KB1709597]에 사용자 인증 정보 저장 문서를 Now Support 참조하세요.
- 조직에서 사용자 지정 루트 CA(인증 기관)를 사용하는 경우 사용자 지정 CA를 인포머 포드에 마운트하여 인포머가 인스턴스와 ServiceNow 통신할 수 있도록 할 수 있습니다. 자세한 내용은 지식베이스에서 인포머를 인스턴스에 연결할 때 사용자 지정 루트 인증 기관 사용 [KB1710906] 문서를 Now Support 참조하십시오.
- 인포머는 기본 인증 대신 OAuth 2.0 인증을 사용하여 ServiceNow 인스턴스에 연결하여 보안을 강화할 수 있습니다. 인포머가 OAuth 2.0을 사용하는 경우 인스턴스는 각 자원 요청과 함께 로그인 자격 증명을 요구하지 않고 만료 시간이 있는 액세스 토큰을 발급합니다. 자세한 내용은 Now Support 지식베이스의 OAuth 프로토콜을 사용하여 CNO for Visibility 연결[KB1648198] 문서를 참조하십시오.
- 옵션:
조직의 정책에 따라 필요한 경우 인포머 docker 이미지를 조직의 이미지 리포지토리에 배치합니다.
주: 2024년 11월에 릴리스된 버전 3.9.0(인포머 버전 2.3.0)부터 Kubernetes 가시성 에이전트 docker 이미지는 arm64 및 amd64 아키텍처를 모두 지원합니다. 이전 이미지에서 새 이미지로 업그레이드해도 중단이 발생하지 않습니다. 그러나 새 이미지는 이전 이미지보다 이미지 리포지토리에 더 많은 저장 공간이 필요합니다.
- Docker 허브에서 이미지를 끌어와 조직의 리포지토리로 밀어넣습니다.
VERSION을 Now Support 지식베이스의 CNO for Visibility Helm 차트 및 Kubernetes YAML 파일 릴리스 [KB1564347] 문서에 제공된 최신 릴리스 번호로 바꿉니다.
Docker pull docker.io/servicenowdocker/informer:VERSION
Docker tag docker.io/servicenowdocker/informer:VERSION COMPANY_REPO:VERSION
Docker push COMPANY_REPO:VERSION
- 이미지 리포지토리에 인증이 필요한 경우 지정된 네임스페이스에 k8s-informer-repo-cred라는 비밀을 만듭니다.
예:
kubectl create secret docker-registry k8s-informer-repo-cred --docker-server https://index.docker.io/v2/ --docker-username DOCKER_USERNAME --docker-password DOCKER_TOKEN --docker-email=user@servicenow.com -n NAMESPACE
- 옵션:
클러스터에서 나가는 트래픽이 프록시를 통과하는 경우 클러스터에 사용된 프록시 호스트 이름과 포트를 식별합니다.
주: 조직의 Kubernetes 팀에 이 정보를 요청합니다. 이는 설치 프로세스 중에 제공해야 합니다.
- 옵션:
더 많은 데이터를 동시에 처리할 수 있습니다 Kubernetes 가시성 에이전트 .
결과
ServiceNow 인스턴스와 Kubernetes 클러스터를 배포할 준비가 되었습니다Kubernetes 가시성 에이전트.