Red Hat Summit2.6. AdminNetworkPolicy에 대한 모범 사례
이 섹션에서는 AdminNetworkPolicy 및 BaselineAdminNetworkPolicy 리소스에 대한 모범 사례를 제공합니다.
2.6.1. AdminNetworkPolicy 설계
링크 복사링크가 클립보드에 복사되었습니다!
AdminNetworkPolicy (ANP) 리소스를 구축할 때 정책을 생성할 때 다음 사항을 고려할 수 있습니다.
- 동일한 우선순위를 갖는 ANP를 생성할 수 있습니다. 동일한 우선순위로 두 개의 ANP를 만드는 경우 동일한 트래픽에 중복되는 규칙이 적용되지 않도록 해야 합니다. 값당 하나의 규칙만 적용되며, 동일한 우선순위 값에 두 개 이상의 규칙이 있는 경우 어떤 규칙이 적용되는지 보장할 수 없습니다. 중복되는 ANP가 생성될 때 어떤 정책이 우선하는지 보장할 수 없으므로, 우선순위가 명확하게 정의되도록 ANP를 서로 다른 우선순위로 설정합니다.
- 관리자는 시스템 네임스페이스가 아닌 사용자 네임스페이스에 적용되는 ANP를 만들어야 합니다.
중요
ANP 및 BaselineAdminNetworkPolicy (BANP)를 시스템 네임스페이스( default , kube-system , 이름이 openshift- 로 시작하는 모든 네임스페이스 등)에 적용하는 것은 지원되지 않으며, 이를 적용하면 클러스터가 응답하지 않고 기능하지 않는 상태가 될 수 있습니다.
-
0~100이지원되는 우선순위 범위이므로 ANP를30~70과같은 중간 범위로 설계할 수 있습니다. 이렇게 하면 이전과 이후의 우선순위에 대한 자리 표시자가 생깁니다. 중간 범위에서도 시간이 지남에 따라 인프라 요구 사항이 변화함에 따라 적절한 우선 순위 수준에서 새로운 ANP를 삽입할 수 있도록 간격을 두는 것이 좋습니다. ANP를 패킹한 경우 향후 변경 사항에 맞게 모든 ANP를 다시 만들어야 할 수도 있습니다. -
0.0.0.0/0또는::/0을사용하여 강력한거부정책을 만드는 경우 필수 트래픽에 대해 더 높은 우선순위의허용또는통과규칙이 있는지 확인하세요. -
어떤 상황에서든 연결이 허용되는지 확인하려면
작업필드로'허용'을사용하세요. ANP의허용규칙은 연결이 항상 허용되고NetworkPolicy가무시됨을 의미합니다. -
Pass를작업필드로 사용하여NetworkPolicy계층에 연결 허용 또는 거부에 대한 정책 결정을 위임합니다. - 여러 규칙의 선택기가 겹치지 않도록 하여 동일한 IP가 여러 정책에 나타나는 것을 방지합니다. 여러 정책에 나타나면 성능과 확장성 제한이 발생할 수 있습니다.
-
PortNumber와PortRange와 함께namedPorts를사용하지 마세요. 이렇게 하면 ACL이 6개 생성되어 클러스터의 비효율성이 발생합니다.
2.6.1.1. BaselineAdminNetworkPolicy 사용 시 고려 사항
링크 복사링크가 클립보드에 복사되었습니다!
클러스터 내에서는 하나의
BaselineAdminNetworkPolicy(BANP) 리소스만 정의할 수 있습니다. 관리자가 BANP를 설계할 때 고려할 수 있는 BANP의 지원되는 사용 사례는 다음과 같습니다.-
사용자 네임스페이스에서 클러스터 로컬 인그레스에 대한 기본 거부 정책을 설정할 수 있습니다. 이 BANP는 개발자가 허용하려는 유입 트래픽을 허용하기 위해
NetworkPolicy객체를 추가해야 하며, 유입에 대한 네트워크 정책을 추가하지 않으면 유입이 거부됩니다. -
사용자 네임스페이스에서 클러스터 로컬 송신에 대한 기본 거부 정책을 설정할 수 있습니다. 이 BANP는 개발자가 허용하려는 송신 트래픽을 허용하기 위해
NetworkPolicy객체를 추가하도록 강제하며, 네트워크 정책을 추가하지 않으면 해당 트래픽이 거부됩니다. -
클러스터 내 DNS 서비스로의 유출에 대한 기본 허용 정책을 설정할 수 있습니다. 이러한 BANP는 네임스페이스 사용자가 클러스터 내 DNS 서비스에 대해 출구 허용
네트워크 정책을설정할 필요가 없도록 보장합니다. -
모든 포드에 대한 내부 이그레스 트래픽을 허용하지만 모든 외부 엔드포인트(예:
0.0.0.0/0및::/0)에 대한 액세스를 거부하는 이그레스 정책을 설정할 수 있습니다. 이 BANP를 사용하면 사용자 작업 부하가 다른 클러스터 내부 엔드포인트로 트래픽을 보낼 수 있지만 기본적으로 외부 엔드포인트로는 보낼 수 없습니다. 그런 다음 개발자는NetworkPolicy를사용하여 애플리케이션이 외부 서비스의 명시적 집합으로 트래픽을 보낼 수 있습니다.
-
사용자 네임스페이스에서 클러스터 로컬 인그레스에 대한 기본 거부 정책을 설정할 수 있습니다. 이 BANP는 개발자가 허용하려는 유입 트래픽을 허용하기 위해
-
BANP 범위를 사용자 네임스페이스에 대한 트래픽만 거부하고 시스템 네임스페이스에 대한 트래픽은 거부하지 않도록 하세요. 이는 시스템 네임스페이스에 BANP를 재정의할
NetworkPolicy개체가 없기 때문입니다.
2.6.1.2. AdminNetworkPolicy와 NetworkPolicy 간 고려해야 할 차이점
링크 복사링크가 클립보드에 복사되었습니다!
-
NetworkPolicy개체와 달리 실수로 트래픽이 선택되는 것을 방지하기 위해 빈({}) 모든 항목을 포함하는 선택기를 사용하는 대신 ANP 및 BANP 내에서 워크로드를 참조하려면 명시적 레이블을 사용해야 합니다.
중요
인프라 네임스페이스에 빈 네임스페이스 선택기를 적용하면 클러스터가 응답하지 않고 작동하지 않는 상태가 될 수 있습니다.
-
ANP의 API 의미론에서는
NetworkPolicy객체의 암묵적 거부와 달리 정책을 생성할 때 허용 또는 거부 규칙을 명시적으로 정의해야 합니다. -
NetworkPolicy객체와 달리AdminNetworkPolicy객체의 수신 규칙은 클러스터 내부의 포드와 네임스페이스로 제한되므로 호스트 네트워크에서의 수신에 대한 규칙을 설정할 필요가 없습니다.
'%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}