Red Hat Summit2.6. AdminNetworkPolicy 모범 사례
이 섹션에서는 AdminNetworkPolicy 및 BaselineAdminNetworkPolicy 리소스에 대한 모범 사례를 제공합니다.
2.6.1. AdminNetworkPolicy 설계
링크 복사링크가 클립보드에 복사되었습니다!
관리NetworkPolicy (ANP) 리소스를 빌드할 때 정책을 생성할 때 다음을 고려할 수 있습니다.
- 우선순위가 동일한 ANP를 생성할 수 있습니다. 동일한 우선 순위에 두 개의 ANP를 생성하는 경우 겹치는 규칙을 동일한 트래픽에 적용하지 마십시오. 값당 하나의 규칙만 적용되며 동일한 우선 순위 값에 둘 이상의 규칙이 적용될 때 적용되는 규칙이 보장되지 않습니다. ANP가 중복될 때 정책이 우선순위가 적용되는 보장이 없기 때문에 우선순위가 잘 정의되도록 ANP를 다른 우선순위로 설정합니다.
- 관리자는 시스템 네임스페이스가 아닌 사용자 네임스페이스에 적용되는 ANP를 생성해야 합니다.
중요
시스템 네임스페이스에 ANP 및 BaselineAdminNetworkPolicy (BANP)를 적용(기본값,kube-system, openshift- 로 시작하는 모든 네임스페이스)은 지원되지 않으므로 클러스터가 응답하지 않고 작동하지 않는 상태로 유지할 수 있습니다.
-
0-100이 지원되는 우선순위 범위이므로30-70과 같은 중간 범위를 사용하도록 ANP를 설계할 수 있습니다. 이로 인해 이전 및 이후의 우선순위에 대한 자리 표시자가 남습니다. 중간 범위에서도 시간이 지남에 따라 인프라 요구 사항이 진화할 때 적절한 우선 순위 수준에 필요한 경우 새 ANP를 삽입할 수 있도록 격차를 남겨 둘 수 있습니다. ANPs를 패키지하는 경우 향후 모든 변경 사항을 수용하기 위해 모든 항목을 다시 생성해야 할 수 있습니다. -
0.0.0.0/0또는::/0을 사용하여 강력한거부정책을 생성하는 경우 필수 트래픽에 대한 우선 순위허용또는Pass규칙이 있는지 확인합니다. -
무엇을하든 연결이
허용되도록 하려면작업필드로 허용을 사용합니다. ANP의허용규칙은 연결이 항상 허용되며NetworkPolicy는 무시됩니다. -
Pass를작업필드로 사용하여NetworkPolicy계층에 대한 연결을 허용하거나 거부하는 정책 결정을 위임합니다. - 동일한 IP가 여러 정책에 표시되지 않도록 여러 규칙의 선택기가 겹치지 않아 성능 및 확장 제한이 발생할 수 있습니다.
-
6개의 ACL을 생성하고 클러스터에서 비효율성을 유발하기 때문에
PortNumber및PortRange와 함께namedPorts를 사용하지 마십시오.
2.6.1.1. BaselineAdminNetworkPolicy 사용 고려 사항
링크 복사링크가 클립보드에 복사되었습니다!
클러스터 내에서 단일 BMC(
BaselineAdminNetworkPolicy) 리소스만 정의할 수 있습니다. 다음은 관리자가 BANP를 설계할 때 고려할 수 있는 BANP 사용 지원입니다.-
사용자 네임스페이스에서 cluster-local ingress에 대한 기본 거부 정책을 설정할 수 있습니다. 이 BANP는 개발자가 허용하려는 수신 트래픽을 허용하도록
NetworkPolicy오브젝트를 추가해야 하며 수신을 위한 네트워크 정책을 추가하지 않으면 거부됩니다. -
사용자 네임스페이스에서 cluster-local 송신에 대한 기본 거부 정책을 설정할 수 있습니다. 이 BANP는 개발자가 허용하려는 송신 트래픽을 허용하기 위해
NetworkPolicy오브젝트를 추가해야 하며 네트워크 정책을 추가하지 않으면 거부됩니다. -
클러스터 내 DNS 서비스로의 송신에 대한 기본 허용 정책을 설정할 수 있습니다. 이러한 BANP를 사용하면 네임스페이스가 지정된 사용자가 허용
NetworkPolicy를 클러스터 내 DNS 서비스로 설정할 필요가 없습니다. -
내부 송신 트래픽을 모든 pod로 허용하지만 모든 외부 끝점에 대한 액세스를 거부하는 송신 정책을 설정할 수 있습니다(예:
0.0.0.0/0및::/0). 이 BANP를 사용하면 사용자 워크로드가 다른 클러스터 내 엔드포인트로 트래픽을 보낼 수 있지만 기본적으로 외부 끝점에는 트래픽을 보낼 수 없습니다. 그런 다음 개발자가NetworkPolicy를 사용하여 애플리케이션이 명시적 외부 서비스 세트로 트래픽을 보낼 수 있습니다.
-
사용자 네임스페이스에서 cluster-local ingress에 대한 기본 거부 정책을 설정할 수 있습니다. 이 BANP는 개발자가 허용하려는 수신 트래픽을 허용하도록
-
BANP의 범위를 지정하여 사용자 네임스페이스에 대한 트래픽만 거부하고 시스템 네임스페이스에 대한 트래픽은 거부해야 합니다. 이는 시스템 네임스페이스에 BANP를 재정의할
NetworkPolicy오브젝트가 없기 때문입니다.
2.6.1.2. AdminNetworkPolicy와 NetworkPolicy 간의 차이점
링크 복사링크가 클립보드에 복사되었습니다!
-
NetworkPolicy오브젝트와 달리 명시적 레이블을 사용하여 빈({})을 사용하는 대신 ANP 및 BANP 내의 워크로드를 참조해야 합니다.
중요
인프라 네임스페이스에 적용되는 빈 네임스페이스 선택기로 인해 클러스터가 작동하지 않고 작동하지 않는 상태가 될 수 있습니다.
-
ANP용 API 의미에서는 암시적 거부가 있는
NetworkPolicy오브젝트와 달리 정책을 생성할 때 허용 또는 거부 규칙을 명시적으로 정의해야 합니다. -
NetworkPolicy오브젝트와 달리AdminNetworkPolicy오브젝트 인그레스 규칙은 클러스터 내 Pod 및 네임스페이스로 제한되므로 호스트 네트워크에서 수신 규칙을 설정할 수 없으며 필요하지 않습니다.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}