Ta reda på varför en anslutning blockeras

När en applikation får timeout när den anropar något är boundaryns nätverksregler en av de första sakerna att utesluta. Öppna boundaryn och dess flik Nätverk. Den kräver boundaries/network/read, som Owner, Contributor och Reader alla har.

Se vad som blockerades

Överst på fliken redovisas verklig trafik:

1. Välj Period, från senaste 15 minuterna till senaste 7 dagarna. Standard är senaste 4 timmarna, och allt på fliken följer valet.
2. Läs de tre rutorna: hur många anslutningar som blockerades, hur många olika mål det gällde och när den senaste blockeringen skedde.
3. Under Blockerade anslutningar delar diagrammet upp blockeringarna i utgående och inkommande över tid. En topp som sammanfaller med en distribution svarar på frågan "var det min ändring?". Visa siffrorna som en tabell ger samma siffror som en tabell.
4. I loggen under diagrammet är varje rad en arbetslast, en andra ände, en port och en riktning, med antal försök och när det senaste skedde. Välj Varför? på en rad för att se orsaken och, när det finns en, ändringen som skulle tillåta anslutningen. När perioden rymmer fler rader än som kan visas säger loggen det; korta ner perioden för att se resten.
5. Vem pratar med vem visar varje anslutning i boundaryn under perioden, som Diagram eller Lista, med blockerade anslutningar markerade.

Den andra änden av en anslutning beskrivs, men namnges aldrig: "en annan gräns", "en adress utanför klustret", "plattformstjänster". Ingenting om en annan boundarys arbetslaster visas.

När fliken inte har något att visa

Uppgifterna om blockerad trafik kommer från klustrets nätverkslager, och alla kluster levererar inte sådana. På ett sådant kluster visar fliken Inte tillgängligt på det här klustret än i stället för en tom logg — en tom logg skulle felaktigt läsas som "ingenting blockerades". Plattformsadministratören kan slå på uppgifterna. Kontrollen nedan fungerar i båda fallen.

Fråga om en anslutning skulle fungera

Kan den här nå den där?, som är hopfälld längst ner på fliken, svarar utifrån boundaryns regler. Den behöver alltså ingen trafik och fungerar lika bra före en distribution som efter.

1. Välj Öppna.
2. Under Från väljer du Utgångspunkt — en containerinstans, app, funktion, databas eller ett byggjobb, eller En annan arbetslast i den här gränsen — sedan dess Resursgrupp och, om du vill, Arbetslast. Lämna arbetslasten tom för att fråga om vilken arbetslast som helst i gruppen, till exempel en som inte finns än.
3. Under Till väljer du Mål — en adress utanför klustret, en containerinstans, app, funktion eller databas i den här boundaryn, plattformstjänster, en annan gräns, ingress-kontrollern eller DNS. För en adress anger du en enda adress, inte ett intervall.
4. För en databas, på vilken sida som helst, väljer du dess Databasens brandvägg, samma val som databasens egen Brandvägg: Allt i den här gränsen (standard), Bara dess egen resursgrupp eller Allt i klustret. Svaret beror på det.
5. Välj Protokoll (TCP, UDP eller SCTP) och Port, och välj Kontrollera.

Svaret är Tillåten eller Blockerad, med en mening som förklarar varför. Regler som vägdes in listar varje regel som gäller arbetslasten i den riktningen. För en utgående anslutning till en adress utanför klustret på en stängd port visar Så här tillåter du den exakt vilken adress, vilket protokoll och vilken port en utgående regel skulle behöva; sådana regler går inte att lägga till i dag. När blockeringen är plattformens eget fel säger svaret det, och då finns det inget för dig att ändra. Orsakerna och reglerna finns i Nätverksregler och orsaker.

När resursgruppen finns på flera kluster

Kontrollen körs mot ett kluster. När resursgruppen du valt finns på fler än ett ber kontrollen dig ange klustret, och formuläret i portalen har inget fält för det. Fråga i stället via API:t, med klustrets ID i clusterId:

POST https://api.example.com/boundaries/<boundary-id>/network/check
Content-Type: application/json

{
  "from": { "kind": "app", "resourceGroup": "<namespace>", "name": "web" },
  "to": { "kind": "cidr", "value": "203.0.113.10" },
  "protocol": "TCP",
  "port": 5432,
  "clusterId": "<cluster-id>"
}

resourceGroup är resursgruppens namnrymdsnamn, rg-….