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