Digital certificates as used for SSL/TLS have multiple components. While there are lots of details that we could examine, all we really need here is a high-level overview, but each piece is important to understand what you should do and why.
When you began the process of obtaining your certificate, you first issued the command,
keytool -keystore keystore -alias myalias -genkey -keyalg RSA -keysize 2048
You described this as "creating your keystore," which is accurate, but it did something much more important also: it generated your private / public key pair. In this case, the new keystore contained a key pair using the RSA algorithm and with 2048 bits of entropy (a fancy way of saying how strong the key is, or how long it might take to break relative to other keys). This is important because the key pair is how you will demonstrate to the Certificate Authority (CA) that your next request is a renewal, is really from you, and is for the same certificate.
When you generated your certificate request,
keytool -certreq -alias myalias -keystore keystore -file myrequest.csr
you created a file that contained your web site's information (foo.com), along with a bunch of other stuff - including your public key. It all got encoded into a well-known format and sent off to the CA. The CA generated your certificate using your public key and their private key, which is how some random web browser can use this to know that they are on your web site and that it's safe to send data. Your certificate gets validated by your private key, which only you have, and by the CA's public key, which only works if it matches up with the private key that signed the certificate.
So, how does all this play into accomplishing your goal of renewing your certificate?
The short answer is, you don't renew, because a renewal isn't really a renewal.
A "renewal" is just a fancy way of saying that you're requesting a new certificate, with a new expiration date, using the same private key as for the old certificate. If you use the same command as before (with the -certreq option), it will create a new certificate request using your existing key pair. Send that off to GoDaddy (or any other CA) and they should be able to process your request with no problem.
When they send the certificate to you, issue the import command and you're good to go:
keytool -keystore keystore -import -alias myalias -file example.com.crt -trustcacerts
You should be able to import the new certificate into the same keystore as the old certificate, since they have different serial numbers. If you run into problems with the import, try using a new alias. Since an alias is usually just for your own reference, you can change the alias or go in and remove the old certificate from the keystore. It won't be used anymore, so it's safe to remove, but it doesn't usually hurt anything to keep it around either.
Note: you won't have to run the CA root import again unless GoDaddy updated their root certificate (it does happen, but not very often). This was the command you used to bring in the root certificate:
keytool -import -trustcacerts -alias myalias -keystore keystore -file gd_bundle.crt
Since you mentioned that you're using GoDaddy, here's the link to their renewal page. The only instructions they have that are close to the Jetty server you're using are those for Tomcat. While those aren't exact, the Tomcat page does include some instructions on the use of keytool.
GoDaddy Certificate Renewal support page