రెండు సైట్లలో మూడు మేనేజర్లు మరియు ఐదు వర్కర్లు, ఒక సొరంగం ద్వారా కలిపి ఉన్నారు, మరియు docker service ls రెండు వైపులా నడుస్తున్న పనులను చూపిస్తుంది, అయితే సేవల మధ్య కాల్స్ సమయం మించిపోతున్నాయి. Swarm లాగ్‌లలో ఏదీ తప్పుగా కనిపించడం లేదు. ఆ కలయిక డేటా ప్లేన్ సమస్య సంజ్ఞ: కంట్రోల్ ప్లేన్ నోడ్‌లను కనుగొంది, మరియు ఎన్‌క్యాప్సులేట్ చేసిన ఫ్రేమ్‌లు ప్రయాణాన్ని ఎప్పటికీ పూర్తి చేయలేదు.

overlay కంటే ముందు mesh ఉండాలి

Swarm యొక్క overlay ఎన్‌క్యాప్సులేట్ చేసిన ఫ్రేమ్‌లను నేరుగా నోడ్ చిరునామాల మధ్య నెట్టుతుంది, అంటే ప్రతి నోడ్‌కు మరే ఇతర నోడ్ అనువాదం లేకుండా చేరుకోగల చిరునామా, సొరంగం అందించే ఇంటర్‌ఫేస్‌లో అవసరం. క్లయింట్లను మాత్రమే ప్రచురిత పోర్టుకు తీసుకువెళ్లే సొరంగం సరిపోదు. దిగువ పొర రెండు దిశలలోనూ నోడ్ నుండి నోడ్‌కు మార్గం చూపాలి.

Swarm ను తాకే ముందు దీన్ని పరీక్షించండి. ప్రతి నోడ్ నుండి తోటి సొరంగ చిరునామాకు మార్గాన్ని తనిఖీ చేయండి, ping చేయండి, ఆపై కంట్రోల్ పోర్టును పరీక్షించండి. ping పనిచేసి పోర్టు పనిచేయకపోతే, సొరంగం బాగుంది మరియు మార్గంలో ఒక ఫిల్టర్ ఉంది.

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

మార్గం tun0 లేదా wg0 కు బదులుగా భౌతిక ఇంటర్‌ఫేస్ వైపు చూపితే, overlay దూర సైట్ చేరుకోలేని చిరునామాకు ఎన్‌క్యాప్సులేట్ చేస్తుంది, మరియు లక్షణం ప్యాకెట్ నష్టం లాగా కనిపిస్తుంది.

ప్రతి నోడ్ ఏ చిరునామాను ప్రకటిస్తుందో తనిఖీ చేయండి

డీమన్ ఒక చిరునామాను ప్రకటిస్తుంది, మరియు తోటివారు దాన్ని డేటా ప్లేన్ కోసం ఉపయోగిస్తారు. బహుళ నెట్‌వర్క్‌ల హోస్ట్‌లో సొరంగం మరేదో మోస్తున్నప్పుడు LAN లేదా పబ్లిక్ చిరునామాను ప్రకటించడం సులభం. ఊహించకుండా దాన్ని తనిఖీ చేయండి, మరియు డిఫాల్ట్ తప్పు అయితే చేరేటప్పుడు --advertise-addr తో దాన్ని పిన్ చేయండి. తనే చేరుకోగల చిరునామాను ప్రకటించే నోడ్ కూడా swarm లో చేరుతుంది, మరియు వైఫల్యం తర్వాత సైట్ల మధ్య మాట్లాడలేని సేవలుగా కనిపిస్తుంది.

ప్రకటిత చిరునామాను తర్వాత మార్చడం కాన్ఫిగ్ సవరణ కాదు, ఎందుకంటే నోడ్ నిష్క్రమించి మళ్లీ చేరాలి.

ప్రతి నోడ్ ప్రకటిత చిరునామాను మీ నోట్స్‌లో నమోదు చేయండి, ఎందుకంటే ఇది చాలా అసమాన వైఫల్యాలను వివరిస్తుంది.

Masquerade సాధారణ నిందితుడు

నోడ్‌ల మధ్య మరియు సొరంగం మధ్య గేట్‌వే ఉన్నప్పుడు, భౌతిక ఇంటర్‌ఫేస్ నుండి బయటకు వెళ్లే ప్రతిదానికీ masquerade వర్తించడం సాధారణ పొరపాటు. అది overlay లోని అంతర్గత చిరునామాలను కూడా తిరిగి రాస్తుంది, కాబట్టి ప్రతి తోటి గేట్‌వే నుండి వచ్చినట్లు కనిపిస్తుంది మరియు VXLAN తోటివారు ఒకరినొకరు గుర్తించడం ఆపేస్తారు. ఫలితం సాధారణ ping ఇంకా పనిచేస్తుండగా పోయిన లేదా ఒక-దిశ ఎన్‌క్యాప్సులేట్ ట్రాఫిక్.

overlay యొక్క ప్రిఫిక్స్‌ను గేట్‌వే ద్వారా మార్గం చూపి అనువదించకుండా ఉంచండి. మరో ప్రిఫిక్స్ కోసం అనువాదం నిజంగా అవసరమైతే, అక్కడికే పరిమితం చేయండి, overlay ఉపయోగించే పరిధికి ఎప్పటికీ కాదు.

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

నియమాల క్రమాన్ని మరియు వచనాన్ని రెండింటినీ తనిఖీ చేయండి, ఎందుకంటే గొలుసులో ముందున్న విశాలమైన MASQUERADE తర్వాతి సన్నని మినహాయింపును ఓడిస్తుంది.

VXLAN కి ప్యాకెట్‌లో స్థలం అవసరం

VXLAN తాను మోసే ఫ్రేమ్‌లకు 50 బైట్లు జోడిస్తుంది. 1500 బైట్ల దిగువ పొర 1500 బైట్ల అంతర్గత ఫ్రేమ్‌ను మోసినప్పుడు ఏ మార్గం అందించని ఎన్‌క్యాప్సులేట్ ప్యాకెట్ ఏర్పడుతుంది, మరియు వైఫల్యం పరిమాణ సమస్య లాగా కాకుండా అప్పుడప్పుడు సేవా అన్వేషణ లాగా కనిపిస్తుంది. గానీ రెండు చివరల్లో సొరంగం MTU ను తగ్గించండి, లేదా డ్రైవర్ సరిపోయే పేలోడ్‌ను ప్రకటించేలా overlay MTU ను సెట్ చేయండి.

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

ingress నెట్‌వర్క్ స్వయంచాలకంగా సృష్టించబడుతుంది, కాబట్టి దాన్ని మార్చడం అంటే అక్కడే సవరించడం కాదు, తీసి మళ్లీ సృష్టించడం.

సొరంగం ఒక వైపు మాత్రమే సరిచేస్తే, చిన్న MTU ఇంకా ముఖ్యమైనదే.

లాగ్‌లు కాదు, డేటా ప్లేన్ చూడండి

రెండు చివరల్లో VXLAN పోర్టును క్యాప్చర్ చేయండి. ఒక వైపు నుండి బయలుదేరి మరో వైపు చేరుకునే ఫ్రేమ్‌లు దిగువ పొర బాగుందని మరియు సమస్య overlay లోపల ఉందని అర్థం. బయలుదేరి ఎప్పటికీ చేరుకోని ఫ్రేమ్‌లు మార్గం లేదా ఫిల్టర్ అని అర్థం. అసలు బయలుదేరని ఫ్రేమ్‌లు మూల చిరునామా తప్పు అని అర్థం.

కొన్ని సెకన్ల తర్వాత మాయమయ్యే సేవా అన్వేషణ వైఫల్యాలు సాధారణంగా ప్యాకెట్ బడ్జెట్ లేదా అస్థిర మార్గాన్ని సూచిస్తాయి, raft క్వోరమ్‌ను కాదు.

పనిచేస్తున్న విండో యొక్క క్యాప్చర్‌ను ఉంచండి, ఎందుకంటే విరిగిన దానితో పోల్చడం కాన్ఫిగ్ మళ్లీ చదవడం కంటే వేగంగా ఉంటుంది.

సంబంధిత వ్యాసాలు