कुबर्नेट्स 1.16: मुख्य नवकल्पनांचे विहंगावलोकन

आज, बुधवारी, होईल Kubernetes चे पुढील प्रकाशन - 1.16. आमच्या ब्लॉगसाठी विकसित झालेल्या परंपरेनुसार, ही दहावी वर्धापन दिन आहे जेव्हा आम्ही नवीन आवृत्तीमधील सर्वात महत्त्वपूर्ण बदलांबद्दल बोलत आहोत.

हे साहित्य तयार करण्यासाठी वापरलेली माहिती घेतली आहे Kubernetes सुधारणा ट्रॅकिंग टेबल, चेंजलॉग-१.१४ आणि संबंधित समस्या, पुल विनंत्या आणि कुबर्नेट्स एन्हांसमेंट प्रपोजल (KEP). तर चला!..

नोड्स

K8s क्लस्टर नोड्स (कुबेलेट) च्या बाजूला खरोखर मोठ्या संख्येने लक्षणीय नवकल्पना (अल्फा आवृत्ती स्थितीत) सादर केल्या आहेत.

प्रथम, तथाकथित «क्षणभंगुर कंटेनर» (तात्कालिक कंटेनर), पॉड्समधील डीबगिंग प्रक्रिया सुलभ करण्यासाठी डिझाइन केलेले. नवीन यंत्रणा तुम्हाला विशेष कंटेनर लाँच करण्याची परवानगी देते जे सध्याच्या पॉड्सच्या नेमस्पेसमध्ये सुरू होतात आणि थोड्या काळासाठी राहतात. कोणत्याही समस्या सोडवण्यासाठी आणि डीबग करण्यासाठी इतर शेंगा आणि कंटेनरशी संवाद साधणे हा त्यांचा उद्देश आहे. या वैशिष्ट्यासाठी नवीन कमांड लागू करण्यात आली आहे kubectl debug, तत्वतः समान kubectl exec: फक्त कंटेनरमध्ये प्रक्रिया चालवण्याऐवजी (जसे exec) ते पॉडमध्ये कंटेनर लाँच करते. उदाहरणार्थ, ही आज्ञा नवीन कंटेनरला पॉडशी जोडेल:

kubectl debug -c debug-shell --image=debian target-pod -- bash

तात्पुरत्या कंटेनरबद्दल तपशील (आणि त्यांच्या वापराची उदाहरणे) मध्ये आढळू शकतात संबंधित KEP. सध्याची अंमलबजावणी (K8s 1.16 मध्ये) ही अल्फा आवृत्ती आहे आणि बीटा आवृत्तीमध्ये हस्तांतरित करण्याच्या निकषांपैकी "[Kubernetes] च्या किमान 2 प्रकाशनांसाठी Ephemeral Containers API ची चाचणी करणे."

NB: त्याचे सार आणि त्याच्या नावातही, वैशिष्ट्य आधीपासून अस्तित्वात असलेल्या प्लगइनसारखे दिसते kubectl-डीबगज्याबद्दल आम्ही आधीच लिहिले आहे. अशी अपेक्षा आहे की तात्पुरत्या कंटेनरच्या आगमनाने, वेगळ्या बाह्य प्लगइनचा विकास थांबेल.

आणखी एक नावीन्य - PodOverhead - प्रदान करण्यासाठी डिझाइन केलेले शेंगांसाठी ओव्हरहेड खर्चाची गणना करण्यासाठी यंत्रणा, जे वापरलेल्या रनटाइमवर अवलंबून मोठ्या प्रमाणात बदलू शकते. उदाहरण म्हणून, लेखक हे केईपी काटा कंटेनर्समध्ये परिणाम होतो, ज्यासाठी अतिथी कर्नल, काटा एजंट, इनिट सिस्टम, इ. जेव्हा ओव्हरहेड इतके मोठे होते, तेव्हा त्याकडे दुर्लक्ष केले जाऊ शकत नाही, याचा अर्थ पुढील कोटा, नियोजन इत्यादीसाठी ते विचारात घेण्याचा मार्ग असणे आवश्यक आहे. मध्ये अंमलबजावणी करण्यासाठी PodSpec फील्ड जोडले Overhead *ResourceList (मधील डेटाशी तुलना करते RuntimeClass, जर एखादा वापरला असेल तर).

आणखी एक उल्लेखनीय नावीन्य आहे नोड टोपोलॉजी व्यवस्थापक (नोड टोपोलॉजी व्यवस्थापक), Kubernetes मधील विविध घटकांसाठी हार्डवेअर संसाधनांचे वाटप फाइन-ट्यूनिंग करण्याच्या दृष्टिकोनास एकत्रित करण्यासाठी डिझाइन केले आहे. हा उपक्रम उच्च-कार्यक्षमता समांतर संगणन आणि ऑपरेशन्सच्या अंमलबजावणीतील विलंब कमी करण्यासाठी विविध आधुनिक प्रणालींच्या (दूरसंचार, मशीन लर्निंग, वित्तीय सेवा इ. क्षेत्रातून) वाढत्या गरजांमुळे चालतो, ज्यासाठी ते प्रगत CPU वापरतात आणि हार्डवेअर प्रवेग क्षमता. Kubernetes मधील असे ऑप्टिमायझेशन आतापर्यंत भिन्न घटकांमुळे (CPU व्यवस्थापक, डिव्हाइस व्यवस्थापक, CNI) प्राप्त केले गेले आहे आणि आता त्यांना एकच अंतर्गत इंटरफेस जोडला जाईल जो दृष्टीकोन एकत्र करेल आणि नवीन समान - तथाकथित टोपोलॉजी-चे कनेक्शन सुलभ करेल. जागरूक - कुबेलेट बाजूला घटक. तपशील - मध्ये संबंधित KEP.

टोपोलॉजी व्यवस्थापक घटक आकृती

पुढील वैशिष्ट्य - कंटेनर चालू असताना तपासत आहे (स्टार्टअप प्रोब). तुम्हाला माहिती आहेच की, ज्या कंटेनरला लॉन्च व्हायला बराच वेळ लागतो, त्यांना अद्ययावत स्थिती मिळणे कठीण आहे: ते प्रत्यक्षात काम सुरू होण्याआधी एकतर "मारले" जातात किंवा ते दीर्घकाळासाठी डेडलॉकमध्ये संपतात. नवीन चेक (वैशिष्ट्य गेटद्वारे सक्षम केले StartupProbeEnabled) रद्द करते - किंवा त्याऐवजी, स्थगित करते - पॉड चालू होईपर्यंत इतर कोणत्याही तपासण्यांचा प्रभाव. या कारणास्तव, वैशिष्ट्य मूलतः म्हटले गेले पॉड-स्टार्टअप लाइव्हनेस-प्रोब होल्डऑफ. ज्या शेंगा सुरू होण्यास बराच वेळ लागतो त्यांच्यासाठी, तुम्ही तुलनेने कमी कालावधीत राज्याचे मतदान करू शकता.

याव्यतिरिक्त, RuntimeClass साठी सुधारणा बीटा स्थितीमध्ये त्वरित उपलब्ध आहे, "विषम क्लस्टर्स" साठी समर्थन जोडून. सी रनटाइमक्लास शेड्युलिंग आता प्रत्येक नोडला प्रत्येक रनटाइमक्लाससाठी समर्थन असणे अजिबात आवश्यक नाही: पॉडसाठी तुम्ही क्लस्टर टोपोलॉजीचा विचार न करता रनटाइमक्लास निवडू शकता. पूर्वी, हे साध्य करण्यासाठी - जेणेकरुन त्यांना आवश्यक असलेल्या प्रत्येक गोष्टीसाठी समर्थन नोड्सवर पॉड्स संपतील - नोडसेलेक्टर आणि सहनशीलतेसाठी योग्य नियम नियुक्त करणे आवश्यक होते. IN केईपी हे वापराच्या उदाहरणांबद्दल आणि अर्थातच, अंमलबजावणी तपशीलांबद्दल बोलते.

नेटवर्क

Kubernetes 1.16 मध्ये प्रथमच (अल्फा आवृत्तीमध्ये) दिसणारी दोन महत्त्वपूर्ण नेटवर्किंग वैशिष्ट्ये आहेत:

• आधार ड्युअल नेटवर्क स्टॅक - IPv4/IPv6 - आणि पॉड्स, नोड्स, सेवांच्या पातळीवर त्याचे संबंधित “समज”. यामध्ये पॉड्समधील पॉड्समधील IPv4-ते-IPv4 आणि IPv6-ते-IPv6 इंटरऑपरेबिलिटी, पॉड्सपासून बाह्य सेवांपर्यंत, संदर्भ अंमलबजावणी (ब्रिज सीएनआय, पीटीपी सीएनआय आणि होस्ट-लोकल आयपीएएम प्लगइन्समध्ये), तसेच कुबर्नेट्स क्लस्टर्स चालू असलेल्या रिव्हर्स कंपॅटिबलचा समावेश आहे. फक्त IPv4 किंवा IPv6. अंमलबजावणी तपशील मध्ये आहेत केईपी.

  पॉड्सच्या सूचीमध्ये दोन प्रकारचे IP पत्ते (IPv4 आणि IPv6) प्रदर्शित करण्याचे उदाहरण:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• एंडपॉइंटसाठी नवीन API - EndpointSlice API. हे विद्यमान एंडपॉईंट API च्या कार्यप्रदर्शन/स्केलेबिलिटी समस्यांचे निराकरण करते जे कंट्रोल-प्लेनमधील विविध घटकांवर परिणाम करतात (apiserver, etcd, endpoints-controller, kube-proxy). नवीन API डिस्कव्हरी API गटामध्ये जोडले जाईल आणि हजारो नोड्स असलेल्या क्लस्टरमध्ये प्रत्येक सेवेवर हजारो बॅकएंड एंडपॉईंट सर्व्ह करण्यास सक्षम असेल. हे करण्यासाठी, प्रत्येक सेवा N ऑब्जेक्टवर मॅप केली जाते EndpointSlice, ज्यापैकी प्रत्येक डीफॉल्टनुसार 100 पेक्षा जास्त एंडपॉइंट नसतात (मूल्य कॉन्फिगर करण्यायोग्य आहे). EndpointSlice API त्याच्या भविष्यातील विकासासाठी संधी देखील प्रदान करेल: प्रत्येक पॉडसाठी एकाधिक IP पत्त्यांसाठी समर्थन, एंडपॉइंटसाठी नवीन राज्ये (केवळ नाही Ready и NotReady), एंडपॉइंट्ससाठी डायनॅमिक सबसेटिंग.

शेवटच्या रिलीझमध्ये सादर केलेले एक बीटा आवृत्तीवर पोहोचले आहे अंतिम करणारा, नाव दिले service.kubernetes.io/load-balancer-cleanup आणि प्रकारासह प्रत्येक सेवेशी संलग्न आहे LoadBalancer. अशी सेवा हटवण्याच्या वेळी, सर्व संबंधित बॅलन्सर संसाधनांची "क्लीनअप" पूर्ण होईपर्यंत ते संसाधनाचे वास्तविक हटवणे प्रतिबंधित करते.

API मशिनरी

वास्तविक "स्थिरीकरण मैलाचा दगड" कुबर्नेट्स API सर्व्हरच्या क्षेत्रामध्ये आहे आणि त्याच्याशी परस्परसंवाद आहे. हे मुख्यत्वे आभारी आहे ज्यांना विशेष परिचयाची गरज नाही त्यांना स्थिर स्थितीत स्थानांतरीत करणे CustomResource Definitions (CRD), ज्यांना Kubernetes 1.7 (आणि हे जून 2017 आहे!) च्या दूरच्या दिवसांपासून बीटा स्थिती आहे. समान स्थिरीकरण संबंधित वैशिष्ट्यांवर आले:

• "उपस्त्रोत" со /status и /scale CustomResources साठी;
• रूपांतरण CRD साठी आवृत्त्या, बाह्य वेबहुकवर आधारित;
• अलीकडे सादर (K8s 1.15 मध्ये) डीफॉल्ट मूल्ये (डिफॉल्टिंग) आणि स्वयंचलित फील्ड काढणे (छाटणी) CustomResources साठी;
• संधी OpenAPI v3 स्कीमा वापरून OpenAPI दस्तऐवज तयार करणे आणि प्रकाशित करणे जे सर्व्हरच्या बाजूला CRD संसाधने प्रमाणित करण्यासाठी वापरले जाते.

आणखी एक यंत्रणा जी कुबर्नेट्स प्रशासकांना फार पूर्वीपासून परिचित झाली आहे: प्रवेश वेबहुक - देखील बराच काळ बीटा स्थितीत राहिले (K8s 1.9 पासून) आणि आता स्थिर घोषित केले आहे.

इतर दोन वैशिष्ट्ये बीटापर्यंत पोहोचली आहेत: सर्व्हर-साइड लागू и बुकमार्क पहा.

आणि अल्फा आवृत्तीमध्ये एकमेव लक्षणीय नवीनता होती अस्वीकार पासून SelfLink — निर्दिष्ट ऑब्जेक्टचे प्रतिनिधित्व करणारा आणि त्याचा भाग असलेला एक विशेष URI ObjectMeta и ListMeta (म्हणजे कुबर्नेट्समधील कोणत्याही वस्तूचा भाग). ते ते का सोडून देत आहेत? सोप्या पद्धतीने प्रेरणा आवाज या फील्डच्या अस्तित्वासाठी वास्तविक (जबरदस्त) कारणांची अनुपस्थिती म्हणून. अधिक औपचारिक कारणे म्हणजे कार्यप्रदर्शन ऑप्टिमाइझ करणे (अनावश्यक फील्ड काढून टाकून) आणि जेनेरिक-एपिसर्व्हरचे कार्य सुलभ करणे, ज्याला असे फील्ड एका विशिष्ट पद्धतीने हाताळण्यास भाग पाडले जाते (हे एकमेव फील्ड आहे जे ऑब्जेक्टच्या आधी सेट केले जाते. अनुक्रमित आहे). खरी अप्रचलितता (बीटामध्ये) SelfLink Kubernetes आवृत्ती 1.20, आणि अंतिम - 1.21 द्वारे होईल.

डेटा संचयन

स्टोरेज क्षेत्रातील मुख्य कार्य, मागील प्रकाशनांप्रमाणेच, परिसरात दिसून येते CSI समर्थन. येथे मुख्य बदल होते:

• प्रथमच (अल्फा आवृत्तीमध्ये) दिसू लागले विंडोज वर्कर नोड्ससाठी CSI प्लगइन समर्थन: स्टोरेजसह कार्य करण्याचा सध्याचा मार्ग कुबरनेट कोरमधील इन-ट्री प्लगइन्स आणि पॉवरशेलवर आधारित मायक्रोसॉफ्टच्या फ्लेक्सव्हॉल्यूम प्लगइन्सची जागा घेईल;

  
  Windows साठी Kubernetes मध्ये CSI प्लगइन लागू करण्याची योजना

• संधी CSI व्हॉल्यूमचा आकार बदलणे, K8s 1.12 मध्ये परत सादर केले गेले, ते बीटा आवृत्तीत वाढले आहे;
• स्थानिक क्षणभंगुर व्हॉल्यूम (CSI इनलाइन व्हॉल्यूम सपोर्ट).

Kubernetes च्या मागील आवृत्तीत सादर केले व्हॉल्यूम क्लोनिंग कार्य (विद्यमान PVC वापरून DataSource नवीन PVC तयार करण्यासाठी) देखील आता बीटा स्थिती प्राप्त झाली आहे.

शेड्युलर

शेड्युलिंगमध्ये दोन लक्षणीय बदल (दोन्ही अल्फामध्ये):

• EvenPodsSpreading - संधी लोड्सच्या “योग्य वितरण” साठी लॉजिकल ऍप्लिकेशन युनिट्सऐवजी पॉड्स वापरा (जसे की डिप्लॉयमेंट आणि रेप्लिकासेट) आणि हे वितरण समायोजित करणे (कठीण आवश्यकता म्हणून किंवा मऊ स्थिती म्हणून, म्हणजे प्राधान्य). हे वैशिष्ट्य सध्या पर्यायांद्वारे मर्यादित असलेल्या नियोजित पॉड्सच्या विद्यमान वितरण क्षमतांचा विस्तार करेल PodAffinity и PodAntiAffinity, प्रशासकांना या बाबतीत अधिक चांगले नियंत्रण देणे, याचा अर्थ उत्तम उच्च उपलब्धता आणि ऑप्टिमाइझ केलेले संसाधन वापर. तपशील - मध्ये केईपी.
• वापरा बेस्टफिट पॉलिसी в विनंती केलेले ToCapacityRatio प्राधान्य कार्य पॉड नियोजन दरम्यान, जे परवानगी देईल वापरा बिन पॅकिंग (“कंटेनरमध्ये पॅकिंग”) दोन्ही मूलभूत संसाधनांसाठी (प्रोसेसर, मेमरी) आणि विस्तारित (जसे की GPU). अधिक तपशीलांसाठी, पहा केईपी.

  
  शेड्युलिंग पॉड्स: सर्वोत्तम योग्य धोरण वापरण्यापूर्वी (थेट डीफॉल्ट शेड्युलरद्वारे) आणि त्याचा वापर (शेड्युलर विस्तारक द्वारे)

शिवाय, द्वारे प्रतिनिधित्व मुख्य कुबर्नेट्स डेव्हलपमेंट ट्री (झाडाच्या बाहेर) बाहेर तुमचे स्वतःचे शेड्युलर प्लगइन तयार करण्याची क्षमता.

इतर बदल

कुबर्नेट्स 1.16 रिलीझमध्ये देखील हे लक्षात घेतले जाऊ शकते साठी पुढाकार आणणे पूर्ण क्रमाने उपलब्ध मेट्रिक्स, किंवा अधिक तंतोतंत, त्यानुसार अधिकृत नियम K8s इन्स्ट्रुमेंटेशनसाठी. ते मुख्यत्वे संबंधितांवर अवलंबून असतात प्रोमिथियस दस्तऐवजीकरण. विविध कारणांमुळे विसंगती निर्माण झाली (उदाहरणार्थ, सध्याच्या सूचना दिसण्यापूर्वी काही मेट्रिक्स तयार केल्या गेल्या होत्या), आणि विकासकांनी ठरवले की "उर्वरित प्रोमिथियस इकोसिस्टमच्या अनुषंगाने" सर्वकाही एकाच मानकावर आणण्याची वेळ आली आहे. या उपक्रमाची सध्याची अंमलबजावणी अल्फा स्थितीत आहे, जी कुबर्नेट्सच्या पुढील आवृत्त्यांमध्ये बीटा (1.17) आणि स्थिर (1.18) मध्ये प्रगती केली जाईल.

याव्यतिरिक्त, खालील बदल लक्षात घेतले जाऊ शकतात:

• विंडोज समर्थन विकास с देखावा या OS साठी Kubeadm उपयुक्तता (अल्फा आवृत्ती), संधी RunAsUserName विंडोज कंटेनरसाठी (अल्फा आवृत्ती), सुधारणा समूह व्यवस्थापित सेवा खाते (gMSA) बीटा आवृत्ती पर्यंत समर्थन, समर्थन vSphere व्हॉल्यूमसाठी माउंट/संलग्न करा.
• पुनर्नवीनीकरण केले API प्रतिसादांमध्ये डेटा कॉम्प्रेशन यंत्रणा. पूर्वी, या हेतूंसाठी HTTP फिल्टर वापरला जात होता, ज्याने अनेक निर्बंध लादले होते ज्यामुळे ते डीफॉल्टनुसार सक्षम होण्यापासून प्रतिबंधित होते. "पारदर्शक विनंती कॉम्प्रेशन" आता कार्य करते: क्लायंट पाठवत आहेत Accept-Encoding: gzip हेडरमध्ये, जर त्याचा आकार 128 KB पेक्षा जास्त असेल तर त्यांना GZIP-संकुचित प्रतिसाद मिळेल. गो क्लायंट आपोआप कॉम्प्रेशनला सपोर्ट करतात (आवश्यक हेडर पाठवत आहेत), त्यामुळे त्यांना ताबडतोब रहदारी कमी झाल्याचे लक्षात येईल. (इतर भाषांसाठी थोडासा बदल आवश्यक असू शकतो.)
• शक्य झाले बाह्य मेट्रिक्सवर आधारित एचपीए वरून/शून्य पॉड्सपर्यंत स्केलिंग करणे. जर तुम्ही ऑब्जेक्ट्स/बाह्य मेट्रिक्सवर आधारित स्केल केले, तर जेव्हा वर्कलोड्स निष्क्रिय असतात तेव्हा संसाधने वाचवण्यासाठी तुम्ही स्वयंचलितपणे 0 प्रतिकृती स्केल करू शकता. हे वैशिष्ट्य विशेषतः ज्या प्रकरणांमध्ये कामगार GPU संसाधनांची विनंती करतात आणि विविध प्रकारच्या निष्क्रिय कामगारांची संख्या उपलब्ध GPU च्या संख्येपेक्षा जास्त आहे अशा प्रकरणांसाठी उपयुक्त असावी.
• नवीन ग्राहक - k8s.io/client-go/metadata.Client - वस्तूंच्या "सामान्यीकृत" प्रवेशासाठी. हे सहजपणे मेटाडेटा पुनर्प्राप्त करण्यासाठी डिझाइन केले आहे (म्हणजे उपविभाग metadata) क्लस्टर संसाधनांमधून आणि त्यांच्यासह कचरा संकलन आणि कोटा ऑपरेशन्स करा.
• कुबर्नेट्स तयार करा आता तू करू शकतेस वारसाशिवाय (“अंगभूत” इन-ट्री) क्लाउड प्रदाते (अल्फा आवृत्ती).
• kubeadm युटिलिटीला जोडले ऑपरेशन दरम्यान सानुकूलित पॅच लागू करण्याची प्रायोगिक (अल्फा आवृत्ती) क्षमता init, join и upgrade. ध्वज कसा वापरायचा याबद्दल अधिक जाणून घ्या --experimental-kustomize, मध्ये पहा केईपी.
• apiserver साठी नवीन एंडपॉइंट - readyz, - आपल्याला त्याच्या तयारीबद्दल माहिती निर्यात करण्यास अनुमती देते. एपीआय सर्व्हरकडे देखील आता ध्वज आहे --maximum-startup-sequence-duration, तुम्हाला त्याचे रीस्टार्ट नियमन करण्याची अनुमती देते.
• दोन Azure साठी वैशिष्ट्ये घोषित स्थिर: समर्थन उपलब्धता झोन (उपलब्धता झोन) आणि क्रॉस संसाधन गट (आरजी). याव्यतिरिक्त, Azure जोडले आहे:
  • प्रमाणीकरण समर्थन एएडी आणि एडीएफएस;
  • भाष्य service.beta.kubernetes.io/azure-pip-name लोड बॅलन्सरचा सार्वजनिक IP निर्दिष्ट करण्यासाठी;
  • संधी सेटिंग्ज LoadBalancerName и LoadBalancerResourceGroup.
• AWS आता आहे समर्थन Windows वर EBS साठी आणि ऑप्टिमाइझ केलेले EC2 API कॉल DescribeInstances.
• कुबेडम आता स्वतंत्र आहे स्थलांतरित होते CoreDNS आवृत्ती अपग्रेड करताना CoreDNS कॉन्फिगरेशन.
• बायनरीज इ संबंधित डॉकर प्रतिमेमध्ये केले वर्ल्ड-एक्झिक्युटेबल, जे तुम्हाला रूट अधिकारांच्या गरजेशिवाय ही प्रतिमा चालविण्यास अनुमती देते. तसेच, etcd स्थलांतर प्रतिमा थांबवले etcd2 आवृत्ती समर्थन.
• В क्लस्टर ऑटोस्केलर 1.16.0 बेस इमेज म्हणून डिस्ट्रोलेस वापरण्यासाठी स्विच केले, कार्यप्रदर्शन सुधारले, नवीन क्लाउड प्रदाते (डिजिटल ओशन, मॅग्नम, पॅकेट) जोडले.
• वापरलेल्या/आश्रित सॉफ्टवेअरमधील अद्यतने: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्स 1.15: मुख्य नवकल्पनांचे विहंगावलोकन";
• «कुबर्नेट्स 1.14: मुख्य नवकल्पनांचे विहंगावलोकन";
• «कुबर्नेट्स 1.13: मुख्य नवकल्पनांचे विहंगावलोकन";
• «कुबर्नेट्स 1.12: मुख्य नवकल्पनांचे विहंगावलोकन».

स्त्रोत: www.habr.com